Relatório de Estágio

COLÉGIO POLITÉCNICO DA UFSM Relatório de Estágio DESENVOLVIMENTO DE SISTEMA PARA CONTROLE DE ATIVIDADES COMPLEMENTARES DE GRADUAÇÃO DOS CURSOS DE SISTEMAS DE INFORMAÇÃO E CIÊNCIA DA COMPUTAÇÃO DA UFSM Gabriel Machado Lunardi Santa Maria, RS, Brasil 2012

COLÉGIO POLITÉCNICO DA UFSM DESENVOLVIMENTO DE SISTEMA PARA CONTROLE DE ATIVIDADES COMPLEMENTARES DE GRADUAÇÃO DOS CURSOS DE SISTEMAS DE INFORMAÇÃO E CIÊNCIA DA COMPUTAÇÃO DA UFSM Relatório de estágio de habilitação Profissional apresentado como requisito parcial para obtenção do título de Técnico em Informática do Colégio Politécnico da Universidade Federal de Santa Maria, RS, realizado sob orientação do Profº. Msc. Marcos Luis Cassal Gabriel Machado Lunardi Santa Maria, RS, Brasil 2012

1 SUMÁRIO 1. DADOS DE IDENTIFICAÇÃO...6 2. APRESENTAÇÃO...7 3. ANÁLISE DO SISTEMA...9 3.1. REQUISITOS...9 3.1.1. Formulário de solicitação de ACG... 9 3.1.2. Formulário de parecer do professor tutor... 11 3.1.3. Formulário de parecer do relator... 12 3.1.4. Formulário de parecer do colegiado... 12 3.1.5. Saídas Finais... 12 3.1.6. Usuários... 13 4. A PLATAFORMA DE DESENVOLVIMENTO BONITA...14 4.1. AMBIENTE DE DESENVOLVIMENTO...15 4.1.1. Instalação do Ambiente de Desenvolvimento... 15 4.2. AMBIENTE DE EXECUÇÃO FINAL...17 5. DESENVOLVIMENTO DO SISTEMA DE ACGS...18 5.1. MODELAGEM...18 5.2. IMPLEMENTAÇÃO...21 5.2.1. Variáveis... 21 5.2.2. Fluxos... 23 5.2.3. Atores... 26 5.2.4. Conectores... 28 5.2.5. Formulários de solicitação de ACG... 30 5.2.6. Formulários de parecer do professor tutor... 40 5.2.7. Formulário de alteração de atividade... 43 5.2.8. Formulário de parecer do relator... 45 5.2.9. Formulário de parecer do colegiado... 46 5.2.10. Exportação do processo... 47 6. INFRAESTRUTURA DO SERVIDOR...49 6.1. INSTALAÇÃO...49 6.1.1. Instalação do Ambiente de Execução TomCat... 49 6.2. CONFIGURAÇÃO...51 6.2.1. Importação do processo ACGs... 51

2 6.2.2. Usuários e Grupos... 51 6.2.3. Integração com a base de dados LDAP... 52 DIFICULDADES ENCONTRADAS...55 CONSIDERAÇÕES FINAIS...56 REFERÊNCIAS...57 ASSINATURAS...58

3 Índice de Figuras Figura 1 Estrutura final da Ferramenta...14 Figura 2 Arquitetura da Ferramenta...15 Figura 3 - Tela do Studio...16 Figura 4 - Tela da User Experience...17 Figura 5 - Definição do Pool...19 Figura 6 - Definição das Lanes...19 Figura 7 - Definição das tarefas...20 Figura 8 - Situação final da modelagem de tarefas...21 Figura 9 Adicionando variáveis...22 Figura 10 - Variáveis com tipos personalizados...23 Figura 11 - Fluxos Solicita ACG...24 Figura 12 - Fluxos Tutor avalia ACG...24 Figura 13 Reaupload de arquivos e situação final do diagrama...25 Figura 14 - Criação usuário inicializador...26 Figura 15 - Atribuindo um seletor a uma tarefa...27 Figura 16 - Inserção de filtro para randomização de usuários...28 Figura 17 - Definição de conector para upload de arquivos...29 Figura 18 - Criação de formulários...31 Figura 19 Formulário criado com sugestões de campos...31 Figura 20 - Variáveis em formulários...33 Figura 21 - retorna a data atual...33 Figura 22 - retorna nome do usuário logado...34 Figura 23 - retorna subcategoria de ACG com base na categoria...34 Figura 24 - retorna a concatenação de duas Strings...34 Figura 25 - retorna a data formatada...35 Figura 26 - retorna mensagem com quais arquivos devem ser anexados...35 Figura 27 - retorna os usuários do grupo passado como parâmetro...35 Figura 28 - retorna o link todas para visualização de arquivo...35 Figura 29 - Inclusão do script Java no projeto...36 Figura 30 - Utilizando os métodos implementados...36 Figura 31 Validação de campos...37 Figura 32 - Subcategorias de ACG dinâmicas...38

4 Figura 33 - Condição de existência do checkbox tutor...38 Figura 34 - Situação final formulário 1 de solicitação...39 Figura 35 - Situação final formulário 2 de solicitação...39 Figura 36 - Recuperando informações da solicitação...40 Figura 37 - customização de checkbox formulário 1 de avaliação pelo tutor...41 Figura 38 - construção do link para documentação...41 Figura 39 adicionando a lista de decisões...42 Figura 40 - Situação final formulário 1 de avaliação do tutor...43 Figura 41 - Situação final formulário 2 de avaliação do tutor...43 Figura 42 - Situação final formulário de alteração de atividade...44 Figura 43 - condição de existência do parecer do tutor...45 Figura 44 - Situação final formulário de avaliação pelo relator...46 Figura 45 - Situação final formulário de avaliação pelo colegiado...47 Figura 46 - Exportação da aplicação...48 Figura 47 - Estrutura de diretórios do servidor web...50 Figura 48 - Login implementado por Bonita...50 Figura 49 - Importação do processo para o ambiente de execução final...51 Figura 50 - Grupos de usuários...52 Figura 51 - desenvolvimento do novo módulo de login...53 Figura 52 - Alteração do arquivo jaas-standard.cfg...54

5 Índice de Tabelas Tabela 1 - Categorias e Subcategorias de ACG...11 Tabela 2 - Campos e dados do formulário 1 de solicitação de ACG...32 Tabela 3 - Campos e dados do formulário 2 de solicitação de ACG...32 Tabela 4 - Campos e dados do formulário 1 de avaliação pelo tutor...40 Tabela 5 - Campos e dados do formulário 2 de avaliação pelo tutor...40 Tabela 6 - Campos e dados do formulário de alteração pelo aluno...44 Tabela 7 - Campos e dados do formulário de avaliação pelo relator...45 Tabela 8- Campos e dados do formulário de avaliação pelo colegiado...46

6 1.DADOS DE IDENTIFICAÇÃO 1.1 Instituição de Ensino: Colégio Politécnico da UFSM. 1.2 Nome do Estagiário: Gabriel Machado Lunardi 1.3 Dados Pessoais do estagiário: Endereço: Avenida Oy Pavão da Silva, nº 140, casa. E-mail: glunardi@inf.ufsm.br. Telefone: (55) 91151719. 1.4 Curso: Técnico em Informática. 1.5 Área Profissional: Desenvolvimento Web. 1.6 Nome do órgão de Realização do Estágio: UFSM 1.7 Setor: Laboratório de Sistemas de Computação (LSC) 1.8 Endereço do Local de Estágio: Avenida Roraima, nº 1000, Cidade Universitária, Bairro Camobi, Prédio 7 Centro de Tecnologia. 1.9 Supervisora do Estágio: Andrea Schwertner Charão. 1.10 Orientador do Estágio: Marcos Luis Cassal. 1.11 Coordenador do curso: Marcos Luis Cassal. 1.12 Período de realização do Estágio: De 09 de Janeiro a 04 de Maio de 2012. 1.13 Carga horária desenvolvida no Estágio: 340 horas, realizando 20 horas semanais.

7 2. APRESENTAÇÃO Neste relatório serão apresentadas as atividades realizadas no primeiro semestre do ano de 2012, no período de Janeiro até Maio, no Laboratório de Sistemas de Computação (LSC), vinculadas ao estágio curricular do curso Técnico em Informática do Colégio Politécnico da UFSM. O LSC localiza-se no campus da Universidade Federal de Santa Maria (UFSM), no prédio do Centro de Tecnologia, sala 376. Nele são desenvolvidas atividades de ensino, pesquisa e extensão principalmente nas áreas de processamento paralelo, sistemas distribuídos, sistemas operacionais e arquitetura de computadores. Ao laboratório estão atrelados alunos que desenvolvem atividades extracurriculares sob orientação de um professor e juntos costumam contribuir com atividades que beneficiem os cursos. Nesse sentido, foi proposto um projeto por professores integrantes do laboratório em comum acordo com as coordenações dos cursos de Sistemas de Informação e Ciência da Computação para a criação de um sistema eletrônico de requisições e gerenciamento de atividades complementares de graduação (ACGs). Atualmente esse processo é manual, ou seja, o aluno preenche um formulário, anexa a documentação requerida dependendo da atividade e entrega na secretaria de curso. Em seguida a documentação é avaliada por um professor tutor (se houver), um relator (membro do colegiado), colegiado do curso e por fim pela coordenação, sendo que a atividade pode ser rejeitada em qualquer etapa após a solicitação. Como o processo de solicitação de ACG envolve passos bem definidos, optou-se por utilizar uma ferramenta que envolva o conceito de fluxo de trabalho, chamada Bonita Open Solution BPM (Business Process Management ou Gerenciamento de processos de negócio). Bonita é de código aberto e escrito em Java podendo ser estendido com o desenvolvimento de novos plug-ins para atividades específicas. Além disso, são geradas as páginas web correspondentes a cada etapa do processo modelado, dando origem a um sistema. O desenvolvimento iniciou-se com a captura de requisitos, modelagem do problema como um todo e em seguida com a integração ao servidor LDAP onde as informações de alunos, professores e secretários (usuários) estão armazenadas.

8 Além disso, algumas funcionalidades e customizações foram também desenvolvidas pela bolsista Jéssica Lasch de Moura, do Núcleo de Ciência da Computação (NCC). Esse desenvolvimento foi acompanhado e documentado nesse texto para servir como referência futura. No decorrer do relatório, serão detalhadas as atividades desenvolvidas no período do estágio

9 3.ANÁLISE DO SISTEMA Atualmente, o processo de solicitação de ACGs (Atividades Complementares de Graduação) dos cursos de Ciência da Computação e Sistemas de Informação da UFSM, é feito manualmente. Em busca de uma alternativa eletrônica para agilizar o processamento dessas solicitações, surge a proposta do desenvolvimento de um sistema web, foco desse relatório. A seguir serão apresentados os requisitos do sistema, que serviram de norteadores para o desenvolvimento. 3.1. REQUISITOS As solicitações e o gerenciamento de ACGs seguem passos bem definidos dentro do processo. O aluno realiza a solicitação e em seguida são feitas avaliações, na sequência, pelo professor tutor (responsável pela atividade, se houver), relator (membro do colegiado), colegiado e, por fim, o aluno é notificado da aprovação ou rejeição da atividade. Esse fluxo é o principal requisito do sistema e é atendido pela própria plataforma de desenvolvimento adotada, a qual será detalhada nos próximos itens. Como o sistema é voltado para web, o requisito de fluxo dará origem a uma sequência de páginas web que obedecerão outros requisitos. Cada passo do processo será composto por uma ou mais páginas contendo um formulário. É através das informações digitadas em cada formulário que as tarefas de avaliação serão completadas e seguirão para o próximo passo. A seguir são mostrados os requisitos para cada formulário de cada passo, as saídas finais e usuários. 3.1.1. Formulário de solicitação de ACG Esse formulário está atrelado a primeira etapa, ou seja, a solicitação da atividade por parte do aluno, o qual deverá conter as seguintes informações: - data da solicitação; - nome; - matrícula; - local da atividade; - carga horária; - data de início; - data de fim; - se possui professor tutor;

10 - professor tutor; - tipo de acg; - sub-tipo de acg; - upload de arquivos; A data de solicitação deve ser preenchida automaticamente, informação do servidor; O nome e a matrícula do aluno devem ser preenchidos com as informações já cadastradas no sistema; A carga horária deverá ser maior que zero; O campo de data inicial não deve ser superior ao campo de data final e nem superior a data atual do sistema; O professor responsável (tutor), caso exista, deverá ser selecionado a partir de um cadastro de usuários; O tipo de ACG deve ser selecionado a partir de categorias; O sub-tipo de ACG deve ser selecionado a partir da categoria selecionada anteriormente. A tabela 1 mostra os tipos (categorias) com seus respectivos subtipos de ACG. Tipo de ACG I participação em eventos II atuação em núcleos temáticos III atividades de extensão IV estágio extra-curricular V atividade de iniciação científica VI Publicação de trabalho Sub-tipo de ACG ouvinte expositor, apresentador, participação organização atividade técnica com projeto de ensino registrado no GAP, exceto monitoria Participação da feira das profissões Projeto para comunidade extre-curso (com projeto de extensão registrado no GAP) Estágio com empresas conveniadas ao curso Estágio na própria instituição (CPD, HUSM, Colégios técnicos, bolsista do NCC, entre outros) Atividade de iniciação científica com projeto de pesquisa registrado no GAP Resumo (uma página) publicação local Resumo (uma página) publicação regional Resumo (uma página) publicação nacional Resumo (uma página) publicação internacional Resumo expandido (até quatro páginas) publicação local Resumo expandido (até quatro páginas) publicação regional Resumo expandido (até quatro páginas) publicação nacional Resumo expandido (até quatro páginas) publicação internacional

11 Artigo completo (acima de quatro páginas) publicação local Artigo completo (acima de quatro páginas) publicação regional Artigo completo (acima de quatro páginas) publicação nacional Artigo completo (acima de quatro páginas) publicação internacional Participação de aluno regularmente VII Participação em órgãos matriculados no curso que tenham colegiados participação em órgãos colegiados e diretórios acadêmicos Monitoria com projeto de ensino registrado no VIII - Monitoria GAP IX Outra atividade a critério do Cursos de línguas estrangeiras colegiado Tabela 1 - Categorias e Subcategorias de ACG Além de tudo, deve ser possível fazer upload de vários arquivos, imagem ou PDF, e também deve haver um link para acesso aos arquivos nas etapas de avaliação. Por fim, é interessante que haja um texto explicativo, conforme o tipo de ACG, explicando quais comprovantes devem ser anexados. 3.1.2. Formulário de parecer do professor tutor O primeiro requisito dessa etapa corresponde a sua possibilidade de existência, ou seja, só será executada se o aluno informou a existência de um professor responsável na solicitação, caso contrário o fluxo segue diretamente para o relator. Esse formulário deverá conter: - data de avaliação (preenchida automaticamente); - todas as informações da solicitação do aluno; - se o professor tutor deseja alterar a carga horária; - se o professor tutor deseja alterar o tipo de ACG; - um parecer; - decisão (Aprovar/Rejeitar); Considerando que o professor tutor aceite a solicitação e não sugira modificações, o fluxo segue diretamente para o relator. Além disso, o professor poderá realizar modificações na carga horária e no tipo de ACG, voltando o fluxo para o aluno, o qual corrigirá as informações. Após a correção, o fluxo não termina e

12 segue para o relator. Por outro lado, caso a solicitação não seja aceita, o processo termina e o aluno é avisado da rejeição, com as alterações sugeridas ou não. 3.1.3. Formulário de parecer do relator O relator deve ser um membro do colegiado e não necessariamente um professor. Esse membro é sorteado e deverá visualizar todos os dados da solicitação do aluno bem como o parecer do professor tutor, caso exista. Independente da aprovação ou não do relator, o fluxo segue para o colegiado, onde todos os membros receberão a solicitação para uma votação. As informações necessárias para esse formulário são: - data de avaliação (preenchida automaticamente); - todas as informações da solicitação do aluno; - o parecer do professor tutor (caso tenha); - um parecer; - decisão (Aceitar/Rejeitar); 3.1.4. Formulário de parecer do colegiado Todos os membros do colegiado receberão determinada solicitação e emitirão a opinião favorável ou não ao parecer do relator. Havendo uma unanimidade o processo termina com a atividade aprovada (mais votos a favor) ou rejeitada (mais votos contra). Caso haja um empate, deve ser enviado um aviso a coordenação para a solicitação ser incluída numa reunião presencial para discussão. O formulário deverá conter: - data de avaliação (preenchida automaticamente); - todas as informações da solicitação; - parecer do professor tutor (se existir); - o parecer do relator; - a decisão do relator; - decisão (Aceitar/Rejeitar); 3.1.5. Saídas Finais O aluno deve dispor da possibilidade de visualizar a situação final de cada solicitação, ou seja, se foi aprovada ou rejeitada. Além disso, consultar um resumo dos processos juntamente com a carga horária acumulada (atividades aprovadas).

13 Ainda, a coordenação deverá listar os processos, ou seja, visualizar um histórico com resumo de carga horária por aluno. Esses dois últimos requisitos, como não são prioridade máxima, não foram implementados e farão parte de um desenvolvimento futuro. 3.1.6. Usuários Atualmente toda a rede dos dois cursos é baseada em serviços Linux e cada aluno, secretário ou professor possui uma conta de usuário para uso em laboratórios. Assim, é utilizada uma base de dados LDAP (Lightweight Directory Access Protocol) para o armazenamento das informações dos usuários e centralização das mesmas, evitando a redundância e inconsistência de dados. Portanto, a alternativa mais lógica é a integração do sistema com essa base de dados, onde estão todos os usuários. No entanto, são necessários os grupos colegiado, professores e tutores, informações que não estão na base LDAP. Assim, existem duas opções, a primeira corresponde em alterar a base de dados adicionando as informações de grupo e fazendo com que o sistema recupere esses dados durante o login. Já a segunda opção seria a utilização do recurso de gerenciamento de usuários fornecido pela própria plataforma de desenvolvimento.

14 4. A PLATAFORMA DE DESENVOLVIMENTO BONITA Bonita Open Solution BPM (Business Process Management), é uma ferramenta de código aberto escrito em Java distribuído sob a licença GPL v2 e que segue o padrão BPMN (Business Process Management Notation) para a construção de modelos de processos de negócio. O padrão BPMN utiliza uma notação de símbolos gráficos para a construção de diagramas, representando o fluxo de um processo. Essa característica da ferramenta abrange o primeiro grande requisito do sistema de solicitação de ACG, o fluxo de trabalho. Bonita possui um Studio para a modelagem e desenvolvimento de aplicações orientadas a processos, uma interface para o gerenciamento dos processos chamada User Experience e um mecanismo de execução, o Bonita Execution Engine. Bonita, como um todo, possui como característica a rápida construção de aplicações utilizando o mínimo de linha de código. A seguir será feita a distinção entre o ambiente de desenvolvimento e execução. Na figura 1 é possível visualizar a estrutura final do usuário, ou seja, os módulos User Experience e Studio bem como o mecanismo responsável pelo funcionamento Bonita Execution Engine. Figura 1 Estrutura final da Ferramenta (Fonte: MEDEIROS, E. BPM with Bonita Open Solution. July 6th, 2011) A figura 2 mostra a arquitetura da ferramenta, ou seja, uma visão mais detalhada em relação a figura 1 como a existência de um banco de dados interno, estrutura dos conectores, motor de execução, as aplicações desenvolvidas e os usuários como desenvolvedores e atores em processos.

15 Figura 2 Arquitetura da Ferramenta (Fonte: MEDEIROS, E. BPM with Bonita Open Solution. July 6th, 2011) 4.1. Ambiente de desenvolvimento Esse ambiente é composto pelo Studio de modelagem e por um ambiente de execução integrado que permite a utilização da User Experience. O Studio é um módulo da ferramenta que é utilizado em várias etapas do desenvolvimento como: customização de formulários, conexão com sistemas já existentes (MySQL, LDAP, Alfresco, etc), criação de scripts para tarefas específicas, exportação e importação de processos, enfim, é o ambiente responsável pelo desenvolvimento do sistema. A partir de um processo devidamente modelado, ou seja, com atores, conectores, scripts, formulários, fluxo de trabalho definidos é possível gerar o process web application correspondente clicando no botão Executar. Dessa forma, é disparado um serviço na porta 9090 responsável pelas requisições das páginas web possibilitando a execução dos processos. As páginas são fiéis ao fluxo estabelecido na modelagem. Por fim, através da User Experience, é possível gerenciar os casos do processo como se fossem emails, ou seja, cada ocorrência de processo. Os atores definidos na modelagem tornam-se usuários na execução do processo. 4.1.1. Instalação do Ambiente de Desenvolvimento O processo de instalação do ambiente de desenvolvimento é bastante simples, porém é importante que um requisito seja atendido. Como a ferramenta é

16 desenvolvida em Java, é necessário que exista uma plataforma de execução (máquina virtual Java JVM) até a versão 6. Os pacotes para download estão disponíveis no site: http://www.bonitasoft.com/products/bpm_downloads/all, em versões para Sistemas Linux e Windows. A versão utilizada para o desenvolvimento foi a 5.6.1 para Windows, disponível em Janeiro de 2012. Para a instalação no Windows ou Linux, basta executar o arquivo baixado. Todo o processo de desenvolvimento do sistema de ACGs deu-se localmente, ou seja, sem conexão a um servidor. A figura 3 mostra o Studio na primeira execução, respectivamente têm-se: botão executar processo, área de desenho, barra de elementos de desenho e editor de propriedades. Figura 3 - Tela do Studio Já a figura 4 traz uma visão geral da User Experience integrada, a qual permite o teste local dos processos. Têm-se: Link para administração de processos, usuários e grupos, caixa de entrada e ocorrências do processo em questão, respectivamente.

17 Figura 4 - Tela da User Experience 4.2. Ambiente de execução final O ambiente de execução é o responsável por todo o processo de transação, principalmente na User Experience. Ao instalar uma aplicação desenvolvida com o Bonita em um servidor, é necessário a instalação de um serviço que trabalhe com páginas web. Como a tecnologia utilizada é o Java existem duas opções, o TomCat ou Jboss. Em qualquer um deles é necessário instalar o ambiente de execução do Bonita para, posteriormente, instalar o processo desenvolvido, ou então baixar os servidores web já integrados com o motor de execução no site do Bonita. Concluindo, detalhes sobre a instalação desse ambiente serão mostrados na seção 6, onde a aplicação será instalada em um servidor de testes.

18 5. DESENVOLVIMENTO DO SISTEMA DE ACGS Nessa seção serão detalhadas as etapas de desenvolvimento. Dentro do Bonita a modelagem e implementação se fundem, ou seja, além de desenhar (modelar) uma tarefa é necessário definir atores, variáveis, conectores, scripts para funções não implementadas, dentre outros. Embora não exista essa clara distinção, as etapas foram divididas em modelagem e implementação no relatório. A primeira mostrará quais tarefas foram definidas a cada divisão do processo. A segunda, a construção dos fluxos condicionais, variáveis, customização de formulários, enfim, a implementação diretamente em cima da modelagem dando origem ao sistema de ACGs. 5.1. MODELAGEM A abordagem de desenho é bastante simples e prática bastando clicar e arrastar os elementos gráficos. Seguindo o padrão BPMN de modelagem, através da ferramenta, o primeiro passo é definir um pool que abrigará cada subdivisão dentro do processo. Em seguida são definidas as lanes Aluno, Tutor, Relator, Colegiado e Coordenação, as quais abrigarão as tarefas delegadas a cada subdivisão. Pools são compartimentos onde os elementos do fluxo são posicionados delimitando o escopo. Já lanes são elementos que são posicionados dentro dos pools para indicar mais de um perfil colaborando para a execução de um processo. A seguir são detalhados os passos da criação de Pools, Lanes e Tarefas, como as tarefas são de mesmo tipo (humanas), o processo de criação será descrito uma única vez já que é o mesmo para todas. Adicionar uma forma Pool na área de desenho > Selecionar a forma criada > Mudar o nome para Diagrama ACGS. A figura 5 mostra os passos.

19 Figura 5 - Definição do Pool Adicionar cinco formas lane ao pool criado anteriormente > Selecionar cada Lane > Mudar o nome de cada uma conforme mostrado na figura 6. Figura 6 - Definição das Lanes Arrastar tarefa humana > Selecionar tarefa > Alterar nome para Solicita ACG. Além disso, adicionar um evento de início, como indicado na figura 7.

20 Figura 7 - Definição das tarefas Os passos para adicionar uma nova tarefa são os mesmos nas próximas tarefas. Assim, a figura 8 traz a modelagem final do sistema, onde cada subdivisão do processo possui suas tarefas, com isso é possível ter uma visão gráfica do contexto. Na seção de implementação serão definidos os fluxos estendendo o processo de modelagem, daí a fusão entre modelagem e implementação.

21 Figura 8 - Situação final da modelagem de tarefas 5.2. IMPLEMENTAÇÃO Essa seção tem como foco detalhar cada passo da implementação. De início, serão definidas as variáveis e seu escopo, ou seja, local a lane ou local ao pool, pois são elas que darão origem aos formulários, fluxos, além da alocação de usuários às tarefas. Em seguida serão construídos e personalizados os formulários de cada tarefa juntamente com os scripts em Java para funções não implementadas na ferramenta. Por fim, serão definidos os conectores que permitirão o upload de arquivos a um repositório (Alfresco). 5.2.1. Variáveis Como as informações de uma tarefa devem estar imediatamente disponíveis às próximas tarefas, foram definidas variáveis no escopo do pool Diagrama ACGS, ou seja, global. Dessa forma não é necessário criar todas as variáveis em cada tarefa. O primeiro passo é criar três variáveis do tipo booleano: Selecionar Pool > Dados, na aba geral > Adicionar. Na janela que abre dar o nome booltutor > tipo booleano > Finish. A figura 9 mostra esses passos.

22 Figura 9 Adicionando variáveis As outras duas variáveis do tipo booleano, mudaacg e mudacarga seguem os mesmos passos, bem como as do tipo texto (nomealuno, cargahoraria, numeromatricula, respostatutor, parecerrelator, respostarelator, parecertutor, tipoacg, local, subtipoacg, nometutor, link), do tipo data (datainicio, datafim) e do tipo anexo (file) diferenciando apenas a opção selecionada no dropbox Tipo de dado. Ainda é necessário criar variáveis com tipos de dados personalizados através de lista de opções. Para isso, em Dados > Adicionar, na janela aberta definir como nome tacgs > no dropbox Tipo de dado selecionar lista de opções > Adicionar cada categoria de ACG conforme a tabela 1 da seção de requisitos. A figura 10 ilustra o procedimento realizado. Outra variável que segue essas mesmas etapas é Decisoes, a qual terá como componentes da lista: Sim/Não.

23 Figura 10 - Variáveis com tipos personalizados 5.2.2. Fluxos Os fluxos compõem a direção do trabalho, ou seja, o que acontece para quem. Os fluxos condicionais são identificados por um pequeno losango abaixo da tarefa e acontecem caso uma condição (com base em uma variável) seja satisfeita. Já os fluxos contínuos são representados simplesmente por uma seta e sempre ocorrem, desde que não exista um fluxo condicional atrelado a mesma tarefa. A tarefa Solicita ACG tem duas possibilidades, então: Selecionar um dos caminhos > definir a condição. No caso de possuir professor tutor booltutor == true, caso contrário booltutor == false. A situação é mostrada na figura 11.

24 Figura 11 - Fluxos Solicita ACG Figura 12 - Fluxos Tutor avalia ACG

25 A figura 12 mostra a definição da condição caso o professor tutor não aceite a solicitação de ACG do aluno. Os passos sãos os mesmos para a criação dos dois outros fluxos variando apenas a condição: mudaacg == true && respostatutor == "Sim" mudacarga == true && respostatutor == "Sim" (tutor sugere alterações); respostatutor == "Sim" && mudaacg == false && mudacarga == false (tutor aceita pedido sem sugestões de alteração). Na figura 13, caso a variável mudaacg esteja com o valor verdadeiro, será necessário o reaupload de arquivos já que implica no uso de outra categoria de ACG pelo aluno indicada pelo professor tutor. Além disso, tem-se a situação final dos fluxos contínuos, por exemplo, independente da decisão do relator, o fluxo seguirá para o colegiado. Por questões de dificuldades na integração com a base LDAP, o requisito de votação do colegiado não foi cumprido sendo que o aluno só é avisado quando o pedido for aceito por, pelo menos, um membro do colegiado. Essa questão será discutida na seção de integração a base LDAP. Figura 13 Reaupload de arquivos e situação final do diagrama

26 5.2.3. Atores Atores tornar-se-ão usuários durante a execução da aplicação. Os usuários utilizados foram os da própria ferramenta e não da base de dados LDAP, isso, novamente, em função de adversidades encontradas na integração. Esses usuários e grupos são criados na User Experience e armazenados em um banco de dados interno, porém é necessário definir a forma como são tratados em algumas tarefas. O primeiro passo é criar alguns seletores de ator que são responsáveis por selecionar o usuário da próxima tarefa em relação a ações tomadas por um usuário da tarefa anterior. São eles: Inicializador, SeletorTutor e membroscolegiado. Para criar o inicializador: selecionar Pool > Seletor de ator > criar > Bonita > Process Initiator > nomear inicializador. Esses passos podem ser observados na figura 14. Figura 14 - Criação usuário inicializador O SeletorTutor é responsável por enviar a solicitação para o professor tutor (usuário) selecionado pelo aluno. Assim, fazem-se os mesmos passos anteriores, porém escolhendo a opção Actor List nos tipos de seletores do Bonita, o mesmo acontece para membroscolegiado, porém como User Group.

27 SeletorTutor deve ser atrelado a tarefa Tutor avalia ACG : selecionar tarefa > Atores > Selecionar atores dinamicamente > Escolher > selecionar SeletorTutor (criado no pool anteriormente). A figura 15 mostra isso. Figura 15 - Atribuindo um seletor a uma tarefa O seletor membroscolegiado deve ser atrelado às tarefas Relator avalia ACG e Colegiado avalia ACG, pois ambas possuem usuários do colegiado. Ainda é preciso adicionar um filtro que sorteie (randomização) em ambas as tarefas, cumprindo o requisito de sorteio de um relator aleatório e também membro do colegiado. O filtro é de implementado pela própria ferramenta, bastando adicioná-lo: Tarefa selecionada > Filtros > Adicionar > escolher UniqueRandom na lista > nomear o filtro > Finish. A figura 16 mostra a adição da funcionalidade.

28 Figura 16 - Inserção de filtro para randomização de usuários 5.2.4. Conectores Foi utilizada uma conexão com um sistema de gerenciamento de arquivos digitais (Alfresco), para o envio, armazenamento e melhor coordenação dos anexos enviados pelos alunos. O conector do Alfresco deve ser criado nas tarefas de solicitação e revisão de solicitação, pois em ambas o aluno poderá realizar upload. Selecionar Solicita ACG > Geral > Conectores > Adicionar > Na lista que surge expandir Alfresco > selecionar Upload a file > Next > nomear como upload > definir a conexão com o servidor: - Host: localhost; - Port: 8080 - User name: admin - Password: senha Na próxima tela definir os seguintes parâmetros: - File to upload: file (variável que guarda o arquivo) - File name: file.getfilename()

29 - Mime Type: import javax.activation.mimetypesfiletypemap; new MimetypesFileTypeMap().getContentType(file.getFileName()); - Destination Folder: pasta de destino Na etapa de saídas do conector é preciso configurar um método que traga a identificação do arquivo após o upload para o servidor e salvar em uma variável do processo (link). Isso fará com que seja possível montar os links e visualizar os anexos dentro do processo. O método deve ser adicionado conforme o trecho de código abaixo e no local indicado pela seta vermelha na figura 17, a qual traz a última etapa de configuração do conector. Figura 17 - Definição de conector para upload de arquivos

30 import org.apache.abdera.model.entry; import org.apache.abdera.model.document; import org.apache.abdera.model.element; Document<Element> doc = (Document<Element>)responseDocument; Entry entry = (Entry)doc.getRoot(); return entry.getid().tostring(); É importante ressaltar que esse procedimento é exatamente o mesmo para a etapa Reaupload de Arquivos, pois nela o aluno também poderá realizar upload como já mencionado anteriormente. 5.2.5. Formulários de solicitação de ACG A partir de agora é possível implementar a aplicação para uso final. O procedimento de criação dos formulários é o mesmo para todos, portanto será detalhado uma única vez nessa seção e, nas demais seções de formulários, serão detalhadas as customizações e peculiaridades de cada um. Como as variáveis já estão definidas, um formulário pode ser facilmente gerado como segue: Selecionar a tarefa Solicita ACG > aba aplicação > Adicionar > Na janela que abre escolher as variáveis que guardarão os dados entrados no formulário > Finish. Os passos são elucidados pela figura 18. Na sequência é gerado um formulário com sugestões de campos para as variáveis selecionadas anteriormente. Ainda, são criados os botões de submissão que obedecem a ordem de criação dos formulários As customizações e peculiaridades referem-se à esses componentes. O formulário gerado pode ser visto na figura 19, juntamente com a barra de widgets a esquerda.

31 Figura 18 - Criação de formulários Figura 19 Formulário criado com sugestões de campos

32 Para a tarefa Solicita ACG foram criados dois formulários, um mostrado na figura 18 e outro correspondente a segunda parte da solicitação, onde o aluno seleciona o subtipo de ACG e anexa um arquivo para upload. O formulário da figura 18 foi customizado segundo a tabela 2: campo Data atual Nome Matrícula Local da atividade Carga Horária Data Início Data Fim Possui Tutor Categoria de ACG Widget utilizado Texto somente leitura Texto (Edit) Texto (Edit) Texto (Edit) Texto (Edit) Data Data Caixa de marcar (checkbox) Seleção (DropBox) Armazenamento nomealuno numeromatricula local cargahoraria datainicio datafim booltutor tipoacg Tabela 2 - Campos e dados do formulário 1 de solicitação de ACG Ao ser criado, o segundo formulário de solicitação também possui sugestões de campos e foi customizado segundo a tabela 3 campo Subcategoria de ACG Tutor (caso exista) Mensagem documentação Anexo Widget utilizado Seleção (DropBox) Seleção (DropBox) Mensagem Arquivo Armazenamento subtipoacg nometutor file Tabela 3 - Campos e dados do formulário 2 de solicitação de ACG Para atrelar cada variável aos campos segue-se os seguintes passos, por exemplo: Selecionar campo Tipo ACG > Dados > em valores disponíveis colocar a variável lista de categorias tacgs > marcar caixa Salvar em > selecionar tipoacg, a figura 20 mostra esses passos. Essa situação se repete para todas demais variáveis, exceto algumas que precisam de customização extra como será visto. As customizações extras referem-se ao preenchimento da data atual automaticamente, o dinamismo entre a categoria e subcategoria de ACG, bem como a mensagem indicando quais arquivos devem ser anexados, ao preenchimento automático do campo nomealuno com o nome do usuário logado, e o preenchimento do dropbox tutor com os nomes de usuários (professores tutores) do sistema. Assim, foi necessário a construção de alguns métodos Java e que serão atrelados de forma análoga a variáveis em formulários.

33 Figura 20 - Variáveis em formulários O script de usuário foi criado da seguinte forma: Menu principal > Extensões > Manage Groovy Scripts > Create > nome GroupsUtil > Abrir. Na janela que abre foram desenvolvidos alguns métodos, mostrados em sequência nas figuras abaixo, identificados funcionalmente por suas legendas (pertencem a classe GroupsUtil). Os imports utilizados pertencem a própria ferramenta, o que facilitou muito o reuso de código. Figura 21 - retorna a data atual

34 Figura 22 - retorna nome do usuário logado Figura 23 - retorna subcategoria de ACG com base na categoria Figura 24 - retorna a concatenação de duas Strings

35 Figura 25 - retorna a data formatada Figura 26 - retorna mensagem com quais arquivos devem ser anexados Figura 27 - retorna os usuários do grupo passado como parâmetro Figura 28 - retorna o link todas para visualização de arquivo

36 O arquivo de script é exportado junto com o processo, porém deve ser incluso nas dependências do projeto, conforme a figura 29. Assim será possível utilizar todos os métodos implementados. Figura 29 - Inclusão do script Java no projeto Agora é possível colocar a data atual automaticamente nos formulários, como em: Selecionar campo data da solicitação > Dados > em valor inicial chamar o método GroupsUtil.getCurrentDate(). Esses passos são os mesmos para preencher o nome do Aluno. A figura 30 elucida o que foi dito. Figura 30 - Utilizando os métodos implementados

37 Ainda é necessário validar o campo Carga Horária para que não sejam aceitos valores negativos e caracteres. Selecionar o campo > Validadores > Adicionar > dar um nome > em tipo escolher Groovy validator > parâmetro: return (Integer.parseInt(field_Campo_de_texto6)>0). A figura 31 traz essas etapas. Figura 31 Validação de campos No segundo formulário de solicitação o dropbox sub-tipos mostrará as subcategorias de ACG. Para isso: Selecionar campo > Dados > Valores disponíveis > utiliza-se o método GroupsUtil.listaSubtipos(TipoACG)> marcar salvar em > subtipoacg. Isso pode ser conferido na figura 32. Esses passos também servem para os campos tutor e mensagem, bastando chamar o método correto GroupsUtil.usuariosDoGrupo(["professores","tutores"]) GroupsUtil.mensagem(TipoACG), respectivamente. e O campo tutor não aparecerá caso o aluno não tenha marcado o checkbox se possui tutor. Isso é feito da seguinte maneira e mostrado na figura 33. Selecionar dropdown tutor > Opções > Inserir campo se > Selecionar o checkbox se possui tutor.

38 Figura 32 - Subcategorias de ACG dinâmicas Figura 33 - Condição de existência do checkbox tutor

39 Para completar a construção do segundo formulário, é necessário configurar o campo de anexo para armazenar na variável file o arquivo. Selecionar campo anexo > Dados > marcar Salvar em > file. Ao clicar no botão enviar, esse arquivo será enviado através do conector upload para o Alfresco. As figuras 34 e 35 trazem a versão final do formulário 1 e formulário 2 de solicitação respectivamente. Figura 34 - Situação final formulário 1 de solicitação Figura 35 - Situação final formulário 2 de solicitação

40 5.2.6. Formulários de parecer do professor tutor Essa tarefa de avaliação é composta, também, por dois formulários, o primeiro contém todos os dados da solicitação, um link para visualização dos documentos anexos e dois checkbox para alteração ou não da carga horária e do tipo de ACG. Mais detalhes são encontrados na tabela 4. campo Data avaliação Todos da solicitação Alterar carga Horária Alterar tipo de ACG Link para documentação Widget utilizado Texto somente leitura Texto somente leitura Caixa de marcar (checkbox) Caixa de marcar (checkbox) Texto somente leitura Armazenamento mudacarga mudaacg - Tabela 4 - Campos e dados do formulário 1 de avaliação pelo tutor O segundo formulário possui um parecer e uma decisão (sim/não). Ainda dois campos podem existir, a carga horária sugerida e o tipo de ACG sugerido conforme dados preenchidos no formulário 1. A tabela 5 traz essas informações. campo Carga Horária sugerida Tipo ACG sugerido Parecer decisão Widget utilizado Texto (Edit) Texto (Edit) Área de texto (TextArea) Seleção (dropdown) Armazenamento cargahoraria tipoacg parecertutor respostatutor Tabela 5 - Campos e dados do formulário 2 de avaliação pelo tutor No formulário 1, a data de avaliação é preenchida automaticamente e os passos são os mesmos executados na figura 30. As informações coletadas na solicitação, são vinculadas aos campos Texto somente leitura dessa forma: Selecionar campo > Dados > Valor Inicial > colocar variável. A figura 36 mostra esses passos para o campo Nome do Aluno.. Figura 36 - Recuperando informações da solicitação

41 As checkbox são customizadas da seguinte maneira: Adicionar duas checkbox > Selecionar uma delas > Dados > marcar Salvar em > selecionar mudacarga. Essas etapas são as mesmas para a outra checkbox, porém atribuindo a variável de salvamento mudaacg. A figura 37 mostra os passos descritos para o primeiro caso. A informação do campo Tipo de ACG é montada através do método GroupsUtil.concat(tipoACG,subtipoACG). Figura 37 - customização de checkbox formulário 1 de avaliação pelo tutor O link para a documentação deve ser montado através do método GroupsUtil.createLink(file.getfilename(),link), conforme a figura 38. Figura 38 - construção do link para documentação

42 Ainda no formulário 1, é preciso alterar o formato das datas de início e de fim para o formato DD/MM/AAAA. Nessa questão foi utilizado o método GroupsUtil.formataData(Data), dentro do respectivo campo de texto. O retorno desse método é uma string, por isso o campo deve ser de texto e não mais Data como no formulário de solicitação. No formulário 2, os campos Carga horária sugerida e Tipo de ACG sugerida existirão caso mudacarga e mudaacg estejam com o valor true. Essa customização é feita da mesma maneira elucidada na figura 33. Além disso, o campo parecer fornecerá a informação à variável parecertutor: Selecionar campo > Dados > marcar caixa Salvar em > parecertutor. Decisão conterá a lista decisoes (Sim/Não) conforme a figura 39, assim: Selecionar campo Decisão > Dados > em valores disponíveis colocar a variável lista de decisões > marcar Salvar em > respostatutor. Figura 39 adicionando a lista de decisões As figuras 40 e 41 trazem a versão final dos formulários aqui criados, formulário 1 e formulário 2 de avaliação do professor tutor respectivamente.

43 Figura 40 - Situação final formulário 1 de avaliação do tutor Figura 41 - Situação final formulário 2 de avaliação do tutor 5.2.7. Formulário de alteração de atividade Esse formulário está atribuído a tarefa Altera Solicitação, do aluno, e é usado quando o professor sugere alterações, seja no tipo de ACG e/ou na carga

44 horária, caso contrário não é utilizado no fluxo do processo. A tabela 6 traz as informações de campos e variáveis atribuídas. campo Mensagem Data Solicitação Local Carga horária alterada Data início Data Fim Tipo da ACG Subtipos da ACG Mensagem de documentação Anexo Widget utilizado mensagem Texto somente leitura Texto somente leitura Texto somente leitura Data Data Seleção (dropdown) Seleção (dropdown) mensagem Arquivo Armazenamento datainicio datafim subtipoacg file Tabela 6 - Campos e dados do formulário de alteração pelo aluno A customização dos primeiros 5 campos da tabela 6 seguem os passos realizados nos formulários anteriores. O Subtipo da ACG é configurado da mesma maneira mostrada na figura 32. Já a mensagem de documentação também segue as etapas descritas nas seções anteriores. Na figura 42 tem-se a situação final do formulário. Figura 42 - Situação final formulário de alteração de atividade

45 5.2.8. Formulário de parecer do relator Para esse formulário estarão presentes todas as informações da solicitação. As adições de variáveis aos campos não serão relatadas, pois seguem as mesmas etapas já relatadas nos outros formulários. A tabela 7 mostra os campos e o tipo de entrada de dados. campo Data avaliação Todos da solicitação Link documentação Parecer tutor Parecer relator Decisão Widget utilizado Texto somente leitura Texto somente leitura Texto somente leitura Texto somente leitura Área de texto (TextArea) Seleção (dropdown) Armazenamento parecerrelator respostarelator Tabela 7 - Campos e dados do formulário de avaliação pelo relator O campo parecer tutor não deve aparecer se não houver um tutor, para isso: Selecionar o campo > Opções > marcar caixa inserir campo se > condição: booltutor == true. Etapas mostradas na figura 43. Figura 43 - condição de existência do parecer do tutor O parecer do relator deve ser atrelado à variável indicada na tabela 7, assim os passos são os mesmos utilizados no parecer do tutor, porém, agora substituindo pela variável parecerrelator.

46 A mesma situação ocorre para a decisão, ou seja, os passos são exatamente os mesmos indicados pela figura 39. Já na figura 44 é possível conferir o formulário pronto. Figura 44 - Situação final formulário de avaliação pelo relator 5.2.9. Formulário de parecer do colegiado Os membros do colegiado emitirão opinião sobre o parecer do relator a favor ou contra. Assim, nesse formulário devem ser adicionados os campos Parecer relator e Decisão. Os demais campos são criados e configurados segundo os passos já realizados até aqui. A tabela 8 traz um resumo das variáveis e campos. campo Data avaliação Todos da solicitação Link documentação Parecer tutor Parecer relator Decisão Widget utilizado Texto somente leitura Texto somente leitura Texto somente leitura Texto somente leitura Área de texto (TextArea) Seleção (dropdown) Armazenamento parecerrelator respostarelator Tabela 8- Campos e dados do formulário de avaliação pelo colegiado

47 A figura 45 mostra a situação final do formulário de avaliação pelos membros do colegiado. Figura 45 - Situação final formulário de avaliação pelo colegiado 5.2.10. Exportação do processo Depois de concluída a aplicação é preciso exportar o processo criado. Para isso, o procedimento é o seguinte: Processo > Exportação avançada > na janela que abre selecionar a opção não para a exportação do motor de execução. O que será exportado será somente o processo (arquivo com extensão.bar), o qual contém todas as informações desenvolvidas nas seções anteriores, incluindo os formulários. O motor de execução não é necessário, pois esse já está presente no ambiente de execução, que será detalhado na próxima seção. Os passos para exportação são mostrados pela figura 46.

48 Figura 46 - Exportação da aplicação

49 6. INFRAESTRUTURA DO SERVIDOR O servidor utilizado possui o sistema operacional Linux Ubuntu server versão 11.10 rodando em uma máquina virtual sem acesso externo, chamada bpm. A instalação do sistema bem como da máquina virtual Java e Alfresco não foram feitos pelos estagiários e sim pelos supervisores responsáveis. O acesso a máquina se deu através de um cliente SSH para Windows chamado SSH Secure Shell versão 3.2.9. 6.1. INSTALAÇÃO Como mencionado na seção 4.2, é necessário um servidor de páginas web Java. No site do Bonita existem duas opções de servidores, inclusive já integradas com o ambiente de execução e a User Experience, são eles: TomCat e Jboss. A escolhida foi TomCat pela facilidade de configuração e instalação. 6.1.1. Instalação do Ambiente de Execução TomCat O pacote pode ser baixado através do mesmo endereço referido na seção 4.1.1. Deve-se atentar ao fato de que a versão do TomCat deve ser compatível com a versão do ambiente de desenvolvimento utilizado na construção do processo. Nesse texto foi utilizada a versão 5.6.1 de desenvolvimento, logo a versão TomCat utilizada foi a 6.0.33. Ainda existe outra opção, baixar TomCat diretamente do site http://tomcat.apache.org/download-60.cgi, porém seria necessária a exportação da User Experience e do ambiente de execução juntamente com o processo, como descrito na seção 5.2.10, e integrar manualmente com TomCat. A instalação é bastante simples, basta extrair o arquivo baixado com o comando $ gunzip BOS-5.6.1-Tomcat-6.0.33.zip em qualquer diretório. A figura 47 mostra a estrutura de diretórios do servidor web após a extração dos arquivos.

50 Figura 47 - Estrutura de diretórios do servidor web Em seguida é preciso dar permissão de execução para todos os arquivos.sh contidos no diretório bin, isso é feito com o comando: $ chmod +x *.sh. O processo é iniciado com: $./startup.sh. Assim é disparado um processo que escuta na porta 8080. O acesso pode ser feito através do seguinte endereço: http://bpm:8080/bonita. Ao acessar é exibida a tela de login da User Experience, a qual possui, por padrão, um usuário com login admin e senha bpm. A seguir será detalhada a configuração dos usuários e integração à base LDAP. A figura 48 traz a visão do módulo de login da própria ferramenta. Figura 48 - Login implementado por Bonita

51 6.2. CONFIGURAÇÃO As configurações são realizadas dentro do ambiente da User Experience com o usuário admin mencionado anteriormente. 6.2.1. Importação do processo ACGs A importação refere-se em trazer o processo (arquivo.bar) para o ambiente final de execução, para assim estar disponível aos usuários. Assim, faz-se: login como admin > Administration > Processes > Install > escolher o arquivo.bar > Install. A figura 49 mostra esses passos. Figura 49 - Importação do processo para o ambiente de execução final 6.2.2. Usuários e Grupos Esse gerenciamento ficou a cargo da própria User Experience e não da integração a base de dados LDAP. Foram criados três grupos de usuários (/professores; /colegiado; /professores/tutores) da seguinte forma: Users > Groups > Add > Save, como mostra a figura 50. Essas informações são armazenadas em um banco de dados interno do ambiente de execução Bonita.

52 Figura 50 - Grupos de usuários Ao fazer login, essas informações são recuperadas desse banco de dados por uma classe Java chamada org.ow2.bonita.identity.auth.bonitaidentityloginmodule e são integradas ao processo possibilitando a execução da aplicação. 6.2.3. Integração com a base de dados LDAP Esse requisito não foi atendido completamente. O que alcançou-se foi somente a autenticação dos usuários no sistema substituindo a classe BonitaIdentityLoginModule, por outra que busca as informações na base LDAP e realiza a autenticação. Porém, após a autenticação os usuários não podem participar dos processos como deveriam, pois essa nova classe não os atribui às tarefas ( Solicita ACG, Tutor Avalia, etc). Nesse sentido, o procedimento aqui descrito compreende a substituição da classe que realiza a autenticação padrão, bem como outros parâmetros de configuração do servidor web TomCat. Foram utilizados códigos extraídos dos fóruns de discussão do Bonita e editados utilizando o Eclipse, após isso foram compactados em um arquivo chamado MyLdapLoginModule.jar. A figura 51 mostra a visão geral do projeto juntamente com o nome de cada classe e do pacote.

53 Figura 51 - desenvolvimento do novo módulo de login O próximo passo foi adicionar o arquivo MyLdapLoginModule.jar nos locais /lib e /lib/bonita, onde encontram-se todas as dependências utilizadas na execução da User Experience e dos processos a ela atrelados. Ainda foi preciso trocar a referência a classe org.ow2.bonita.identity.auth.bonitaidentityloginmodule em um arquivo de configuração chamado jaas-standard.cfg do TomCat presente em: /external/security. A alteração corresponde na troca do seguinte trecho pelo mostrado na figura 52. BonitaAuth { org.ow2.bonita.identity.auth.bonitaidentityloginmodule required; }; Por fim, bastou reinicializar o servidor web e os usuários da informática já podiam acessar o sistema, porém não participar dos processos.