A aplicação desenvolvida nesta segunda parte tem como objetivo alertar o mediador de um curso quando uma condição indesejável estiver ocorrendo no serviço Conferências. São verificadas quatro condições que normalmente são indesejáveis. A primeira refere-se ao seu nível de atividade, o que gera uma notificação caso seja detectada a ausência de mensagens em um intervalo de tempo maior do que um período previamente estabelecido. A segunda informação verifica se uma questão está sendo pouco debatida ou se está polarizando a conferência em detrimento das outras. Neste caso, o mediador é notificado caso alguma mensagem categorizada como “Questão” possua uma quantidade de
respostas menor ou maior que um limite pré-configurado. Isto só é feito a partir de 12 horas após o início da conferência, dando tempo para os aprendizes iniciarem a discussão. A terceira informação refere-se ao nível de atividade dos aprendizes: uma notificação é gerada quando um aprendiz apresentar uma participação que possa ser considerada muito baixa segundo os critérios do curso. A quarta e última informação disponibiliza uma medida para o mediador estimar o nível de interatividade da conferência: por exemplo, uma notificação é gerada toda vez que a porcentagem de folhas da estrutura da árvore da conferência for maior que 50%, ou seja, quando mais da metade das mensagens não estiverem sendo respondidas. Devido às diferentes características das turmas e dos propósitos das conferências, os valores dos parâmetros para que as notificações sejam acionadas devem ser configurados pelos mediadores para cada conferência através de uma interface específica para este fim.
Ao receber estas notificações os mediadores podem tomar decisões que mudem o rumo da conferência, contornando as situações indesejáveis. O AulaNetM provê meios para a verificação destas situações através de informações visuais (Figura 5.13) e estatísticas (Figura 5.14), porém, o processo de detecção das condições indesejáveis não é automatizado, isto é, os Mediadores precisam acessar diretamente o AulaNetM para obter a informação. Conseqüentemente, na maior parte dos casos os mediadores tomam conhecimento da condição tardiamente. Além disso, mediadores entrevistados reclamaram da dificuldade de estabelecer conexão e de mantê-la uma vez estabelecida. Pesquisas revelaram indícios de que os mediadores passavam mais tempo tentando conectar-se ou reconectar-se do que analisando a conferência.
Figura 5.13 – Informações Visuais no AulaNetM
Figura 5.14 – Informações Estatísticas no AulaNetM
Para contornar estes problemas uma MAS foi desenvolvido. Os mediadores não precisam mais monitorar o estado da conferência, pois os agentes já fazem isto e o mecanismo de tolerância a falhas presente no Jade possibilita que mensagens não entregues devido a falhas na conexão sejam adiadas e entregues ao retomar a conexão de forma transparente ao usuário. A aplicação consiste em um sistema multi-agentes constituído por dois tipos de agentes diferentes: o Conference Agent e o Mediator Assistant.
O Conference Agent é o mesmo descrito na seção anterior, mas a ele é adicionado os comportamentos que permitem detectar as condições indesejáveis na conferência. O Conference Agent é pró-ativo e reativo, e permanece monitorando a Conferência do AulaNet na tentativa de detectar situações indesejáveis. Como cada curso no AulaNet pode ter várias conferências, cada nova conferência ganha um Conference Agent na sua ativação e, na sua desativação, este agente é destruído.
O Mediator Assistant é executado dentro de um container Jade-Leap em execução dentro de um PDA iPAQ 5555, o mesmo ambiente utilizado na aplicação da seção anterior. Este agente permanece em execução no PDA initerrupdamente, esperando por mensagens do Agente Conference Agent. Ao receber uma mensagem, o agente Mediator Assistant emite um alerta, comunicando ao seu usuário a situação indesejada ocorrida. Este agente é
autônomo, e pode optar por não mostrar um alerta em determinados casos, como a desabilitação explícita de um determinado tipo de alerta pelo mediador ou a excessiva repetição do alerta. As figuras Figura 5.15 e Figura 5.16 mostram o Mediator Assistant em execução.
Figura 5.15 – Informações Visuais no AulaNetM
Figura 5.16 – Informações Estatísticas no AulaNetM
A Figura 5.15 mostra a tela do agente Mediator Assistant e a Figura 5.16 mostra o agente após receber vários alertas. Esta aplicação é capaz de alertar os mediadores tão logo a condição seja detectada e assim, estes são capazes de tomar atitudes mais cedo para contornar a condição indesejável com mais rapidez.
5.5.
A arquitetura do AulaNet 3.0 pode ser vista através de duas perspectivas: a da arquitetura de aplicação, que apresenta uma visão mais alto nível e a da arquitetura técnica, que apresenta uma visão mais baixo nível.
Quando contemplada do ponto de vista da arquitetura de aplicação, a arquitetura do AulaNet 3.0 apresenta dois níveis de componentização: o dos serviços e o dos componentes de colaboração com os quais os serviços são construídos. A arquitetura de aplicação apresenta dois frameworks de componentes: o Service Component Framework, que provê os contratos que os serviços de groupware devem implementar e o Collaboration Component Framework, que fornece os contratos para criar componentes 3C com os quais os serviços de groupware são construídos. Tanto os serviços quanto os componentes 3C são desenvolvidos segundo a arquitetura técnica.
A arquitetura técnica segue uma abordagem em três camadas e também o padrão MVC (Fowler, 2002). A camada de recursos relaciona os recursos necessários para à execução do AulaNet, por exemplo o banco de dados relacional. A camada de negócios é onde a lógica da aplicação é implementada. Nela encontram-se Data Transfer Objects (DTOs) (Fowler, 2005), classes do modelo que representam entidades de negócio e são usadas para transportar dado entre camadas (correspondem ao M do MVC), Data Access Objects (DAOs) (Alur et al., 2001), classes que encapsulam o acesso ao banco de dados e Façades (Gamma et al., 1995), classes que servem como ponto de entrada para a camada de negócios. A camada de apresentação, que expõe a lógica de negócios ao usuário, é composta pelo controlador, o C do MVC além de páginas JSP, que correspondem ao V do MVC. Ao longo desta dissertação foram vistos como vários frameworks podem ser acrescentados proporcionando uma base de serviços de infra-estrutura. Após o acréscimo destes frameworks, a arquitetura é descrita segundo a Figura 5.17.
Façade
Spring/Hibernate Data Access Object
M (DTO) Camada de Negócios Camada de Apresentação Camada de Recursos JSF Controller Mail Sender SGBD Servidor de E-Mails JSP Componente JSF Proxy (Spring) XML DTO.hbm.xml IFaçade IFaçade Backing Bean
Figura 5.17 – Arquitetura Técnica do AulaNet 3.0 com Frameworks
Com o crescimento do uso de dispositivos móveis e com o advento das redes sem fio, espera-se que seja possível ter acesso a informações, comunicação e serviços em qualquer lugar e a qualquer instante. Com o objetivo de investigar o uso de equipamentos móveis na aprendizagem colaborativa, iniciou-se o desenvolvimento de uma extensão do ambiente AulaNet para dispositivos móveis denominada AulaNetM.
Atualmente o AulanetM integra-se ao AulaNet 2.1 no nível de dados. A arquitetura do AulaNet 3.0 foi projetada para possibilitar a integração em nível de serviços, proporcionando um maior reuso. A integração pode ser alcançada através da técnica reposição da camada de apresentação ou da exposição de serviços remotamente.
Pela técnica da reposição da camada de apresentação, a camada de negócios de negócios é totalmente reaproveitada enquanto que a camada de apresentação é
substituída por uma outra mais adequada ao dispositivo móvel, utilizando HTML ou WML. Esta técnica é adequada a clientes magros e sua principal vantagem é a maior facilidade que equipes de um projeto tendem a encontrar ao participar de outro, já que ambos usam as mesmas interfaces de negócios. A maior desvantagem é que clientes magros não têm acesso direto a informações como a localização do PDA, por exemplo, dificultando a implementação de serviços específicos de mobilidade de forma transparente.
A técnica da exposição de serviços remotos é implementada através da adição de Proxys do Spring que exportam os serviços remotamente. Clientes magros ou gordos acessam os serviços do AulaNet através destes Proxys. A principal vantagem desta técnica é que clientes gordos têm acesso às informações do dispositivo, como por exemplo, a localização. Desta forma, podem dar suporte a serviços específicos de mobilidade de forma transparente. A principal desvantagem é que as chamadas remotas são mais complexas de serem feitas e oferecem desempenho inferior. Apesar de prover suporte tanto para clientes magros quanto gordos, esta técnica é mais adequada para os gordos.
Apesar das inegáveis vantagens do uso de dispositivos móveis, o desenvolvimento de sistemas nestes ambientes oferece desafios devido à baixa capacidade de processamento do aparelho, conexão intermitente e de baixa qualidade, bateria que precisa ser recarregada, etc. Segundo Kinshuk & Lin (2004), sistemas de agentes inteligentes têm um grande potencial para solucionar estes desafios.
Além das aplicações de agentes para dispositivos móveis, há várias outras possíveis para o AulaNet 3.0. Por isto, decidiu-se que a arquitetura do AulaNet 3.0 deveria possibilitar o uso de agentes. Para evidenciar que a arquitetura do AulaNet 3.0 pode ser estendida com outros frameworks e que pode dar suporte ao uso de agentes, decidiu-se investigar a integração do AulaNet ao framework de agentes Jade.
Para que um framework seja integrado a arquitetura do AulaNet, é preciso que este seja compatível com o Spring. Como o Spring não oferece suporte nativo de integração com o Jade, foi necessário criar um adaptador. Através do adaptador, podem ser realizadas operações sobre o container Jade e sobre agentes. Como os agentes são instanciados pelo Spring, eles podem fazer uso das
funcionalidades proporcionadas por ele, incluindo Dependency Injection com outras classes.
Para testar a integração do Jade com o Spring bem como a viabilidade do uso de agentes em dispositivos móveis foi realizada uma prova de conceito em duas etapas. Ambas envolveram agentes em ambientes móveis comunicando-se com agentes no AulaNet.
O teste de conceito foi implementado com sucesso e com ele, constatou-se que a arquitetura do AulaNet 3.0 pode ter outros frameworks não previstos inicialmente incorporados, desde que eles sejam compatíveis com o Spring ou possam ser adaptados através de um adaptador para uso com o Spring. Constatou- se também que é possível desenvolver agentes em dispositivos móveis usando Jade e que eles podem se comunicar com outros agentes localizados em servidores.
Trabalhando colaborativamente, pelo menos potencialmente, pode-se produzir melhores resultados do que se os membros do grupo atuassem individualmente (Fuks et al., 2002). Groupware é um tipo de software que oferece suporte à interação entre indivíduos possibilitando o trabalho colaborativo. Learningware é um tipo de groupware usado no aprendizado colaborativo.
Um groupware envolve aspectos multidisciplinares em sua construção e é difícil de aplicar e testar, sendo especialmente vulnerável a falhas (Gerosa et al., 2004). Como cada grupo tem suas próprias necessidades que se modificam ao longo do tempo, é importante que o groupware seja desenvolvido de forma iterativa e que a experiência do seu uso seja usada para guiar seu desenvolvimento, criando novos serviços ou melhorando as funcionalidades dos serviços existentes. Através de uma arquitetura componentizada, o groupware pode ser adaptado plugando e desplugando componentes, compondo uma aplicação que melhor satisfaça um grupo de trabalho.
O AulaNet é um learningware desenvolvido pelo Laboratório de Engenharia de Software (LES) da Pontifícia Universidade Católica do Rio de Janeiro (PUC- Rio) desde 1997 e desde o lançamento da versão 2.0 a sua arquitetura nunca sofreu reengenharia. Alunos de graduação, mestrado e doutorado desenvolvem suas monografias, dissertações e teses usando o AulaNet para realizar suas pesquisas. O AulaNet é usado no curso Engenharia de Groupware, onde atua como repositório de informações, e no curso Tecnologias de Informação Aplicada A Educação (TIAE), onde é usado integralmente a distância. O AulaNet é distribuído pela EduWeb, que também realiza customizações para atender as demandas de seus clientes. Atualmente o AulaNet é usado em diversas universidades e empresas no mundo inteiro. Com o passar do tempo o AulaNet acumulou código legado que não segue as principais boas práticas e tecnologias conhecidas atualmente. Como conseqüência, as equipes do LES e da EduWeb vêm enfrentando dificuldades para desenvolver novos serviços e manter os
existentes, sendo apontadas causas como a baixa modularidade e o uso de um paradigma funcional (Pimentel et al., 2005). Para solucionar estas questões, iniciou-se o desenvolvimento de uma nova versão, o AulaNet 3.0.
Gerosa (2006) em sua pesquisa de doutorado na PUC-Rio concebeu uma arquitetura baseada em componentes para o AulaNet 3.0. Esta arquitetura possui dois níveis de componentização: o de serviços e o dos componentes 3C. Os serviços, como a Conferência e o Debate são plugados e desplugados em um framework de componentes, o Groupware Component Framework, compondo um groupware especifico que atenda às necessidades de um grupo de trabalho. Os serviços por sua vez são compostos por componentes 3C, que são reusados na construção de diversos serviços.
Ao desenvolver componentes, o desenvolvedor se depara com inúmeros desafios. Além de entender do seu domínio de conhecimento ele deve lidar com questões como persistências de dados, controle de transações, segurança e muitas outras. O desenvolvimento de groupware já é difícil por si só devido a seu caráter multidisciplinar e a heterogeneidade dos diversos grupos de trabalho e não deveria ser complicado por questões de baixo nível.
Frameworks de infra-estrutura de sistemas simplificam o desenvolvimento de sistemas de infra-estrutura portáveis e eficientes (Fayad et al., 1999b). Estes frameworks possibilitam uma visão mais alto nível destas questões. Nesta dissertação, foi visto como estes frameworks oferecem serviços que simplificam o desenvolvimento de groupwares. Tomando uma abordagem em camadas, foram vistos frameworks usados na camada de negócios e frameworks usados na camada de apresentação.
Ao buscar por frameworks para lidar com determinada questão de infra- estrutura muitas vezes o arquiteto de software se depara com diversos frameworks similares que se propõe a realizar a mesma coisa. A leitura da documentação do fabricante pode ajudar na escolha, mas muitas vezes as informações fornecidas pelo fabricante são subjetivas. Realizando uma análise técnica, possivelmente implementando uma prova de conceito, o arquiteto obtém indícios sobre qual framework atende melhor a suas necessidades. Entretanto nem sempre a implementação da prova de conceito é possível devido à limitação natural de tempo e recursos que todo projeto tem.
Além de identificar se o framework atende às necessidades técnicas do projeto, há outros fatores importantes que devem ser considerados. É importante saber se há documentação disponível, se há suporte disponível, se há ferramentas compatíveis com o framework, se o framework está sendo usado por outras instituições e se há profissionais aptos a trabalhar com o framework. Estas questões não-técnicas usualmente são tão importantes quanto as questões técnicas, principalmente no caso do AulaNet devido à rotatividade de desenvolvedores no LES e a integração com a equipe da EduWeb. Esta dissertação apresentou uma forma de comparar estes fatores.
Na camada de negócios, as principais questões de infra-estrutura resolvidas por frameworks são: persistência de dados, gerenciamento de transações, gerenciamento de segurança e exposição de serviços remotamente. Estas questões são tratadas no framework de componentes Enterprise Java Beans (EJB) e, por isso, ele foi avaliado como opção.
Após a análise técnica do EJB chegou-se a conclusão que ele apresentava inúmeras desvantagens. É preciso manter uma grande quantidade de arquivos para realizar manutenção em um componente EJB. Componentes EJB dependem de servidores de aplicação que possuam containeres EJB que geralmente são mais caros e complexos. Além disso, o modelo EJB resulta em componentes altamente intrusivos e consequentemente mais difíceis de serem testados unitariamente. As restrições de programação impostas pela especificação EJB 2.1 impossibilitam a realização de atividades corriqueiras. A especificação EJB 3.0 vem se inspirado em um modelo de POJOs e frameworks como o Hibernate para solucionar estas questões mas, como seu futuro é incerto, optou-se por seguir uma arquitetura de POJOs com frameworks.
Para tratar a persistência de dados e dos desafios decorrentes do conflito dos paradigmas Objeto/Relacional, é usado o framework Object Relational Mapping (ORM) Hibernate (2005). Antes de adotar o Hibernate foi realizada uma análise técnica onde foram analisadas as características deste framework. Após a implementação de uma prova de conceito, um protótipo do serviço Conferências do AulaNet, percebeu-se que este framework supria as necessidades de persistência do AulaNet.
Após a análise técnica foi realizada a análise não-técnica, que iniciou-se pela seleção dos concorrentes. Os frameworks ORM iBATIS (2005), Apache OJB
(OJB, 2005) e JDOMax (2005), uma implementação da especificação JDO (2005) são soluções de mapeamento completo (Fussel,1997) e gratuitos. A análise determinou o Hibernate como o framework com mais documentação disponível, com mais suporte disponível (é a comunidade mais ativa e possui suporte pago), com mais ferramentas compatíveis, com mais empresas usando e com mais profissionais aptos a trabalhar com ele disponíveis no mercado. Como os outros não apresentavam nenhuma vantagem técnica significativa, a escolha do Hibernate se manteve.
Para solucionar às questões de gerenciamento de transações, gerenciamento de segurança e exposição de serviços remotamente, foi escolhido o framework Spring (2005). A análise técnica mostrou que o Spring fornecia meios para lidar com estas questões e, além disso, fornecia um módulo de Dependency Injection que torna os componentes mais fracamente acoplados e mais fáceis de serem testados unitariamente. Spring possui também um módulo de Programação Orientada a Aspectos, possibilitando que pesquisas nesta área sejam realizadas com o AulaNet. Spring também integra-se ao Hibernate, facilitando o seu uso.
O Spring também se manteve após a na análise não-técnica. Foram encontrados 4 frameworks gratuitos com características similares ao Spring: Avalon (2005), que se transformou no projeto Excalibur (2005), o HiveMind (2005), NanoContainer (2005) e o PicoContainer (2005). A análise mostrou que o Spring é superior em todas as categorias e, novamente, a escolha se manteve.
Na camada de apresentação, há uma família de frameworks denominada web frameworks que oferecem uma implementação do padrão de projetos Model View Controller (MVC) (Fowler, 2002), além de tratar também desafios decorrentes do uso do HTML na construção de interfaces com o usuário. Estima- se que há 54 web frameworks disponíveis gratuitamente na plataforma Java (Manageability, 2005). Devido ao grande número de web frameworks disponíveis, foi preciso adotar uma outra abordagem. Foram selecionados 3 para serem analisados tecnicamente. O Struts (2005), por ser o mais popular, o Spring MVC, módulo do framework Spring (2005), por ter sido escolhido para a camada de apresentação, e o JavaServer Faces (JSF) (2005), por especificar um modelo de componentes e ser um padrão da Sun.
A análise técnica indicou cada um com suas vantagens. O Spring MVC, o menos intrusivo de todos, o Struts, com o melhor módulo de validação de entrada
de dados e o JSF sendo o único dos três a especificar um modelo de componentes. Após a análise técnica, escolheu-se o JSF, pois ele aparenta ser um modelo de componentes promissor e porque começa a se desenhar um mercado de componentes JSF com o surgimento de projetos como MyFaces (2005) e WebGalileo Faces (WebGalileo, 2005), que são gratuitos, e o WebCharts (2005), que é comercial. Alguns destes componentes, como o editor HTML encontrado no projeto MyFaces, atendem a demandas atuais de usuários do AulaNet.
Ao realizar a análise não-técnica notou-se que Struts liderou todas as categorias exceto a categoria de ferramentas compatíveis. JSF, que liderou esta categoria, ficou em segundo lugar em todas as outras exceto a categoria de disponibilidade de suporte onde foi terceiro. JSF foi também o framework cujo número de oportunidades requerendo habilidade no framework mais cresceu ao longo das pesquisas. O bom desempenho do JSF na análise técnica foi crucial para que ele se mantivesse como escolha para a camada de apresentação. Mesmo tendo a sua primeira versão estável lançada em 2004, JSF ficou atrás apenas do Struts, que parece ser o web framework mais aceito atualmente, mas que não define um modelo de componentes e por isso não será usado.
Apesar da arquitetura do AulaNet 3.0 prever apenas estes 3 frameworks, é possível incorporar outros frameworks, oferecendo infra-estrutura para tratar questões não previstas. Nesta dissertação foi visto como incorporar o framework de agentes Jade a arquitetura do AulaNet 3.0. Para integrar um novo framework na camada de negócios da arquitetura do AulaNet 3.0 é preciso integrá-lo ao Spring. Como o String não é intrusivo e é baseado em boas práticas, como a programação para interfaces (Bloch, 2005) e encapsulamento através de propriedades JavaBeans (2005), normalmente isto não é um problema. Como visto nesta dissertação, o Jade pode ser integrado à arquitetura através de um adaptador construído com poucas classes, possibilitando o uso de agentes de software no AulaNet tanto para fins de pesquisa quanto para fins de mercado.
Além disso, através dos Proxys remotos do Spring é oferecido suporte a