Celso Gomes Barreto
Agregando Frameworks de Infra-Estrutura
em uma Arquitetura Baseada em Componentes:
Um Estudo de Caso no Ambiente AulaNet
Dissertação de Mestrado
Dissertação apresentada ao Programa de Pós-Graduação em Informática da PUC-Rio como requisito parcial para obtenção do título de Mestre em Informática.
Orientador: Hugo Fuks
Celso Gomes Barreto Junior
Agregando Frameworks de Infra-Estrutura
em uma Arquitetura Baseada em Componentes:
Um Estudo de Caso no Ambiente AulaNet
Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre pelo Programa de Pós-graduação em Informática do Departamento de Informática do Centro Técnico e Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada.
Prof. Hugo Fuks
Orientador Departamento de Informática – PUC-Rio
Prof. Carlos José Pereira de Lucena
Departamento de Informática – PUC-Rio
Prof. Alberto Raposo
Departamento de Informática – PUC-Rio
Profa. Flávia Maria Santoro
UNI-Rio
Prof. José Eugenio Leal
Coordenador Setorial do Centro Técnico Científico – PUC-Rio
Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.
Celso Gomes Barreto
Graduou-se em Ciência da Computação na Universidade Federal do Rio de Janeiro em 2002. Durante a graduação atuou no projeto Enibam (Ensino Informatizado em Tópicos Básicos de Matemática). Durante o mestrado atuou no projeto AulaNet responsabilizando-se pela arquitetura e infra-estrutura técnica.
Ficha Catalográfica
Barreto, Celso Gomes
Agregando frameworks de infra-estrutura em uma arquitetura baseada em componentes : um estudo de caso no ambiente AulaNet / Celso Gomes Barreto ; orientador: Hugo Fuks. – Rio de Janeiro : PUC, Departamento de Informática, 2006.
210 f. : il. ; 30 cm
Dissertação (mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática
Inclui referências bibliográficas.
1. Informática – Teses. 2. Desenvolvimento de groupware. 3. Componentes de software. 4. Arquiteturas multicamadas de software. 5. Frameworks. I. Fuks, Hugo. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título.
Ao professor Hugo Fuks por acreditar no meu potencial e pela inestimável orientação ao longo destes dois anos.
Aos companheiros de consórcio, Marco Aurélio Gerosa e Mariano Gomes Pimentel, que me acompanharam nesta difícil jornada.
Aos meus pais, Celso Gomes Barreto e Isaura Maria Moreira Barreto pelo apoio, incentivo e afeto.
Aos meus colegas do LES e do projeto AulaNet pelo companheirismo. Em especial à Denise Del Re Filippo por me auxiliar na preparação para a defesa.
A todos com quem já trabalhei. Em especial a Juliana Lucas de Rezende, pelo incentivo e aconselhamento.
Aos professores da Universidade Federal do Rio de Janeiro por minha formação na graduação, sem a qual não teria chegado até aqui.
A CAPES e à Fundação Padre Leonel Franca pelo apoio financeiro.
E a todos aqueles que direta ou indiretamente contribuíram para a realização deste trabalho.
Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet. Rio de Janeiro, 2006. 210p. Dissertação de
Mestrado – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.
Groupware é difícil de construir e de manter, pois envolve aspectos multidisciplinares. Além das dificuldades associadas ao desenvolvimento de aplicações colaborativas, usualmente o desenvolvedor de groupware deve se preocupar com outros aspectos de infra-estrutura. Nesta dissertação é proposta uma arquitetura multicamadas baseada em componentes para groupware, utilizando frameworks de infra-estrutura. Na camada de negócio são utilizados os frameworks Hibernate, responsável pela persistência dos dados da aplicação, e o framework Spring, que dentre outras coisas é responsável pelo controle de transações e pela exposição de serviços remotamente. Na camada de apresentação o framework JaveServer Faces provê meios para criar e reusar componentes de interface. Nesta dissertação também é apresentada uma forma de comparar frameworks de infra-estrutura, levando em consideração tanto aspectos técnicos, que definem se o framework atende aos requisitos da aplicação, quanto não-técnicos, relacionados a aspectos como documentação disponível e aceitação no mercado. A arquitetura definida nesta dissertação é aplicada no AulaNet, groupware voltado para a aprendizagem desenvolvido no Laboratório de Engenharia de Software da PUC-Rio.
Palavras-chave
Desenvolvimento de groupware; componentes de software; arquiteturas multicamadas de software; frameworks.
Intrastructure Frameworks in an Component Based Architecture: A Case Study within the AulaNet Environment Rio de Janeiro, 2006. 210p.
M.Sc. Dissertation – Computer Science Department, Pontifical Catholic University of Rio de Janeiro.
Groupware is difficult to develop and maintain because it involves multidisciplinary aspects in its construction. Besides the difficulties related to the development of collaborative applications, usually the developer must handle with other infrastructure aspects. In this dissertation, it is proposed a multilayer component based architecture with system infrastructure frameworks to deal with them. In the business layer, the Hibernate framework is responsible for the persistence of application data, and the Spring framework is responsible for, amongst others, transactions control and remote exposition of services. In the presentation layer the JaveServer Faces framework provides ways to create and to reuse user-interface components. This dissertation also presents a way to compare system infrastructure frameworks, considering both technical aspects, related to the application requirements fulfillment, and non-technical, related to aspects such as documentation availability and market acceptance. The architecture defined in this dissertation is applied to the AulaNet, which is a groupware for learning developed in the Software Engineering Laboratory of PUC-Rio.
Keywords
Groupware development; software components. multilayer software architecture; frameworks.
1 Introdução 16 1.1. Groupware e o Modelo 3C 16 1.1.1. Comunicação 17 1.1.2. Coordenação 18 1.1.3. Cooperação 19 1.2. O AulaNet 19 1.2.1. A Arquitetura do AulaNet 2.1 22 1.3. Consórcio de Pesquisa 23
1.3.1. Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet 24 1.3.2. Desenvolvimento de Groupware Componentizado com base no
Modelo 3C de Colaboração 26
1.3.3. RUP-3C-Groupware: um Processo de Desenvolvimento de
Groupware baseado no Modelo 3C de Colaboração 29
1.4. Organização da Escrita 30
2 Frameworks: Conceitos Gerais 33
2.1. Definições de Frameworks 33
2.2. Classificação dos Frameworks 34
2.2.1. Frameworks de Aplicações Orientado a Objetos 34
2.2.2. Frameworks de Componentes 36
2.3. Papéis Envolvidos no Uso e Desenvolvimento de um Framework 37
2.4. Conseqüências da Adoção de Frameworks 37
2.4.1. Benefícios Decorrentes da Utilização de Frameworks 38 2.4.2. Desafios Decorrentes da Utilização de Frameworks 39
2.5. Frameworks e Outras Abordagens 41
2.5.1. Frameworks e Aplicações Orientado a Objetos 41
2.5.2. Frameworks e Biblioteca de Classes 41
2.5.4. Frameworks e Componentes de Software 42
2.6. Conclusão 43
3 A Camada de Negócios 47
3.1. O Modelo de Componentes Enterprise JavaBeans 47 3.1.1. Vantagens Decorrentes do Uso de Enterprise JavaBeans 49 3.1.2. Desvantagens Decorrentes do Uso de Enterprise JavaBeans 50
3.1.3. O Futuro do Enterprise JavaBeans 52
3.2. Uma Arquitetura Usando POJOs 53
3.3. Questões Decorrentes do Mapeamento Objetos em Tabelas 54 3.3.1. Conflito de Paradigmas: Orientação a Objetos x Relacional 54
3.4. Frameworks ORM 57
3.4.1. O Framework Hibernate 58
3.4.1.1. Hibernate - Um Exemplo Prático 58
3.4.1.2. Hibernate e a Questão dos Subtipos 68
3.4.1.3. Hibernate e a Questão da Igualdade 70
3.4.1.4. Hibernate e as Questões dos Relacionamentos 71 3.4.1.5. Hibernate e a Questão do Grafo de Navegação 71 3.4.1.6. Considerações Finais Sobre o Hibernate 72
3.4.2. Outros Frameworks ORM 73
3.4.2.1. Quantidade de Documentação Disponível 73
3.4.2.2. Disponibilidade de Suporte 75
3.4.2.3. Disponibilidade de Ferramentas Compatíveis 76
3.4.2.4. Grau de Aceitação no Mercado 77
3.4.2.5. Disponibilidade de Profissionais 78
3.4.2.6. Resultado da Comparação entre Frameworks ORM 80
3.5. O Framework de Infra-Estrutura Spring 80
3.5.1. Dependency Injection 81
3.5.2. Dependency Injection com Spring 83
3.5.3. Integração do Hibernate com o Spring 88
3.5.4. Transações Declarativas com Spring 91
3.5.5. Gerenciamento de Segurança com Spring 94 3.5.6. Exposição de Serviços Remotos com Spring 97
3.5.7. Considerações Finais Sobre o Spring 99 3.5.8. Outros Frameworks Para Dependency Injection 100 3.5.8.1. Quantidade de Documentação Disponível 100
3.5.8.2. Disponibilidade de Suporte 102
3.5.8.3. Disponibilidade de Ferramentas Compatíveis 103
3.5.8.4. Grau de Aceitação no Mercado 104
3.5.8.5. Disponibilidade de Profissionais 106
3.5.8.6. Resultado da Comparação 107
3.6. Conclusão 107
4 A Camada de Apresentação 110
4.1. Vantagens e Desafios no Desenvolvimento de Interfaces HTML 110
4.2. Model View Controller 112
4.3. Características Comuns a Web Frameworks 114 4.4. Comparação Técnica entre Web Frameworks 115
4.4.1. Struts 116
4.4.2. Spring MVC 123
4.4.3. JavaServer Faces 130
4.4.4. Resultado da Análise Técnica 136
4.5. Comparação Não-Técnica entre Web Frameworks 137 4.5.1. Quantidade de Documentação Disponível 138
4.5.2. Disponibilidade de Suporte 139
4.5.3. Disponibilidade de Ferramentas Compatíveis 140
4.5.4. Grau de Aceitação no Mercado 141
4.5.5. Disponibilidade de Profissionais 143
4.5.6. Resultado da Análise 144
4.6. Conclusão 145
5 Arquitetura do AulaNet 3.0 149
5.1. Elementos Principais da Arquitetura do AulaNet 3.0 149 5.2. A Arquitetura do AulaNet 3.0 e os Frameworks de Infra-Estrutura 152
5.3. Arquitetura Técnica e Mobilidade 155
5.4. Arquitetura Técnica e Outros Frameworks: Jade 161
5.4.2. Aplicações de Sistemas Multi-Agentes 162
5.4.3. O Framework de Agentes Jade 163
5.4.4. Jade e a Arquitetura do AulaNet 3.0 167
5.4.5. Prova de Conceito com Agente Móvel 170
5.4.2.1. MAS 1: O Que Há de Novo na Conferência? 171 5.4.2.2. MAS 2: Alerta de Condições Indesejáveis 180
5.5. Conclusão 183
6 Conclusão 188
7 Referências Bibliográficas 194
Apêndice A Comunicações Pessoais 202
A.1. Comunicação com Christian Bauer 202
A.2. Comunicação com Rod Johnson 203
A.3. Comunicação com Matt Raible 205
Apêndice B Método Utilizado na Análise Não-Técnica 207
B.1. Quantidade de Documentação Disponível 207
B.2. Disponibilidade de Suporte 208
B.3. Disponibilidade de Ferramentas Compatíveis 209
B.4. Grau de Aceitação no Mercado 210
Figura 1.1 – O Modelo 3C (Pimentel et al., 2005) 17 Figura 1.2 – Classificação dos Serviços do AulaNet segundo o Modelo 3C 20
Figura 1.3 – AulaNet no Desktop. 21
Figura 1.4– AulaNetM em um PDA. 21
Figura 1.5 – Arquitetura do AulaNet 2.0 (Barreto et al., 2005). 22 Figura 1.6 – Arquitetura Técnica do AulaNet 3.0. 25 Figura 1.7. A arquitetura de aplicação proposta 28 Figura 1.8. Foco para o desenvolvimento de uma versão da aplicação groupware
com base no Modelo 3C de Colaboração 29
Figura 1.9 – Exemplo de uma Listagem de Código. 31 Figura 3.1 – Diagrama de Classes que Exemplifica a Questão do Grafo de
Navegação 56 Figura 3.2 – Diagrama UML de Classes Persistidas no Exemplo 59
Figura 3.3 – Diagrama de Classes com Herança. 69 Figura 3.4 – Livros Publicados Para Cada Framework ORM Fonte: Amazon.com,
Novembro de 2005 74
Figura 3.5 – Artigos e Tutoriais Para Cada Framework ORM Fonte: Google.com,
Novembro de 2005 74
Figura 3.6 - Mensagens Trocadas em Listas de Discussão (11/2005) 75 Figura 3.7 – Ferramentas Compatíveis com os Frameworks ORM em 11/2005 76 Figura 3.8 – Ofertas de Emprego Abertas para cada Framework ORM Fonte:
Dice.com, Dezembro de 2005 77
Figura 3.9 – Ofertas de Emprego Abertas para cada Framework ORM Fonte:
Manager Online, Dezembro de 2005 78
Figura 3.10 – Disponibilidade de Profissionais Fonte: Jobs.net, Dezembro de 2005
79 Figura 3.11 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de
2005 79 Figura 3.12 – Dependências Configuradas sem Dependency Injection 82
Figura 3.14 – Modelo de Classes do Exemplo do Spring 84 Figura 3.15 - Livros Publicados Para Cada Framework de Dependency Injection
Fonte: Amazon.com, Dezembro de 2005 101
Figura 3.16 - Artigos e Tutoriais Para Cada Framework de Dependency Injection
Fonte: Google.com, Dezembro de 2005 101
Figura 3.17 - Mensagens Trocadas em Listas de Discussão (11/2005) 103 Figura 3.18 – Ferramentas Compatíveis com os Frameworks para Dependency
Injecton em 12/2005 104
Figura 3.19 – Ofertas de Emprego Abertas para cada Framework para
Dependency Injection. Fonte: Dice.com, Dezembro de 2005 105
Figura 3.20 - Vagas Abertas para cada Framework de Dependency Injection
Fonte: Manager Online, Dezembro de 2005. 105
Figura 3.21 - Disponibilidade de Profissionais em 12/2005 Fonte: Jobs.net. 106 Figura 3.22 - Disponibilidade de Profissionais Fonte: APInfo.com, Dezembro de
2005. 107 Figura 4.1 – MVC clássico (Ramachandran, 2002) 113
Figura 4.2 – MVC pull (Johnson, 2002, 2004) 114
Figura 4.3 - Calendário 135
Figura 4.4 - Editor HTML 135
Figura 4.5 - Número de Livros Publicados 138
Figura 4.6 - Número de Tutoriais escritos 139
Figura 4.7 – Mensagens Trocadas em Listas de Discussão (Julho/2005) 140
Figura 4.8 – Ferramentas Compatíveis 141
Figura 4.9 - Oferta de Empregos nos Meses 10/2004, 7/2005 e 11/2005 Fonte: Dice.com, 10/2004, 07/2005 (Raible, 2005) e 11/2005 142 Figura 4.10 – Ofertas de Emprego Fonte: Manager Online, Outubro de 2005 142 Figura 4.11 - Disponibilidade de Profissionais com Habilidades nos Frameworks Fonte: Monster.com, Junho de 2005 (Raible, 2005) 143 Figura 4.12 - Disponibilidade de Profissionais com Habilidades nos Frameworks
Fonte: APInfo.com, Novembro de 2005 144
Figura 5.1 - Arquitetura de Aplicação do AulaNet 3.0 (Gerosa, 2006)
Apresentada na Seção 1.3. 150
Figura 5.3 - Arquitetura de Aplicação do AulaNet 3.0 (Gerosa, 2006) 153 Figura 5.4 - Arquitetura Técnica do AulaNet 3.0 com Frameworks. 154 Figura 5.5 – Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por
Reposição da Camada de Apresentação 157
Figura 5.6 - Arquitetura Técnica da Integração AulaNet 3.0 com AulaNetM por
Exposição de Serviços Remotos 159
Figura 5.7 – Plataformas de Agentes Jade (Caire, 2003). 165 Figura 5.8 – Diagrama de Classes do Adaptador Jade-Leap para o Spring 168 Figura 5.9 – Plataforma de Execução do MAS 1 172 Figura 5.10 – PDA Após a Inicialização do Jade-Leap 179
Figura 5.11 – PDA Após a Primeira Consulta 179
Figura 5.12 - PDA Após a Segunda Consulta 180
Figura 5.13 – Informações Visuais no AulaNetM 182 Figura 5.14 – Informações Estatísticas no AulaNetM 182 Figura 5.15 – Informações Visuais no AulaNetM 183 Figura 5.16 – Informações Estatísticas no AulaNetM 183 Figura 5.17 – Arquitetura Técnica do AulaNet 3.0 com Frameworks 185
Listagem 3.1 – Classe Message 59
Listagem 3.2 – Classe User 60
Listagem 3.3 – Arquivo hibernate.cfg.xml de Configuração do Hibernate 61 Listagem 3.4 – Arquivo User.hbm.xml de Mapeamento Objeto – Relacional 62 Listagem 3.5 - Arquivo Message.hbm.xml de Mapeamento Objeto – Relacional 63 Listagem 3.6 – Operação de Criação com o Hibernate 64 Listagem 3.7 – Operação de Atualização com o Hibernate 66 Listagem 3.8 – Operação de Consulta com o Hibernate Usando HQL 67 Listagem 3.9 – Operação de Remoção com o Hibernate 68
Listagem 3.10 – Classe Message. 85
Listagem 3.11 – Interface MessageDAO. 85
Listagem 3.12 – Classe ConferenceFacade. 86
Listagem 3.13 – Arquivo de Configuração do Spring 87 Listagem 3.14 – Descritor web.xml da Aplicação: Iniciando o Contexto Spring 88 Listagem 3.15 – Arquivo de Configuração do Spring: Integração com Hibernate.
89
Listagem 3.16 – Classe MessageDAOImpl. 90
Listagem 3.17 - Arquivo de Configuração do Spring: Transações Declarativas. 93 Listagem 3.18 - Arquivo de Configuração do Spring: Segurança Declarativa. 96 Listagem 3.19 - Arquivo de Configuração do Spring: Exposição de Serviços
Remotos. 99 Listagem 4.1 – Declaração do Controlador do Struts na Instancia (web.xml) 117
Listagem 4.2 – Descritor struts-config.xml 118
Listagem 4.3 – Ação postMessage 119
Listagem 4.4 – Action Form da ação postMessage 120 Listagem 4.5 – Regras de Validação (validation.xml) 121 Listagem 4.6 – Página de Envio de Mensagens 122 Listagem 4.7 - Declaração do Controlador do Spring MVC na Instancia (web.xml)
124 Listagem 4.8 - Descritor SpringDispatcher-servlet.xml 125
Listagem 4.9 – Controlador Associado à Requisição postMessage 126 Listagem 4.10 – Bean de Formulário Associado ao Controlador postMessage 127 Listagem 4.11 – Classe de Validação para o Controlador postMessage 128 Listagem 4.12 - Página de Envio de Mensagem 129 Listagem 4.13 - Declaração do Controlador do JSF na Instancia (web.xml) 131 Listagem 4.14 – Arquivo de Configuração faces-config.xml 132 Listagem 4.15 – Backing Bean do Comando postMessage 133 Listagem 4.16 – Página de Envio De Mensagens (JSF) 134
Listagem 5.1 – Agente Conferência 173
Listagem 5.2 – Comportamento WhatIsNewInConferenceBehaviour 174 Listagem 5.3 – Configuração no Spring do Adaptador Jade-Leap 175
Listagem 5.4 – Agente Móvel 176
Ao desenvolver groupware, o desenvolvedor depara-se com inúmeros desafios. Além de entender de seu domínio de aplicação, ou seja, colaboração, este deve lidar com aspectos de infra-estrutura de baixo nível, como o gerenciamento de transações, a persistência dos dados da aplicação e a validação dos dados de entrada do usuário. O desenvolvimento de groupware já é difícil por si só devido a seu caráter multidisciplinar e a heterogeneidade dos diversos grupos de trabalho (Gerosa et al., 2004) e não deve ser complicado por questões de baixo nível. A introdução frameworks de infra-estrutura como o Hibernate (2005), o Spring (2005) e o JSF (2005) possibilita que o desenvolvedor de groupware concentre-se em seu domínio e lide com estas questões a partir de uma perspectiva mais alto nível.
O AulaNet (Lucena & Fuks, 2000) é um groupware (Fuks et al., 2005) usado no ensino/aprendizagem colaborativo. Este é desenvolvido no Laboratório de Engenharia de Software (LES) da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio). O objetivo da pesquisa que resultou nesta dissertação de mestrado é elaborar uma arquitetura técnica para groupware que ofereça uma base de serviços independentes de domínio, tomando como estudo de caso o ambiente AulaNet.
Esta introdução apresenta conceitos fundamentais sobre groupware. Também são apresentadas as arquiteturas do AulaNet 2.1 e 3.0. Por fim, são descritas as teses consorciadas a este trabalho e a organização do texto.
1.1.
Groupware e o Modelo 3C
Groupware é software que apóia a interação entre indivíduos que trabalham para a realização de um objetivo comum (Rezende, 2003). Trabalhando colaborativamente, pelo menos potencialmente, pode-se produzir melhores resultados do que individualmente (Fuks et al., 2002).
O modelo 3C é usado para analisar a colaboração. Segundo este modelo, para colaborar, indivíduos devem se comunicar, coordenar e cooperar de forma adequada. A Figura 1.1esquematiza o modelo 3C.
COMUNICAÇÃO
COORDENAÇÃO COOPERAÇÃO
gera compromissos gerenciados pela
organiza as tarefas para demanda Percepção
Contexto
comum + ação Ação de tornar comum
co + ordem + ação Ação de organizar em conjunto co + operar + ação Ação de operar em conjunto
Figura 1.1 – O Modelo 3C (Pimentel et al., 2005)
Para que os objetivos sejam atingidos, um grupo precisa se comunicar, o que gera compromissos. Para garantir que estes sejam cumpridos e lidar com eventuais conflitos que possam surgir, é preciso que os compromissos gerados pela comunicação sejam coordenados. Coordenados, os integrantes do grupo podem cooperar, operando em conjunto e realizando o trabalho colaborativo. A cooperação demanda comunicação e o ciclo recomeça.
Para desenvolver groupware de qualidade, é necessário entender de colaboração (Pimentel et al., 2005). Utilizando o modelo 3C pode-se mapear características de um serviço em cada um dos “Cs” e, desta forma, melhorar a ferramenta através da modificação de um dos “Cs”. Pode-se também identificar deficiências de um groupware a partir da análise da colaboração baseada no modelo 3C, acrescentando ou removendo serviços de comunicação, coordenação e cooperação (Pimentel, 2006) de acordo com a necessidade do grupo de trabalho.
1.1.1.
Comunicação
Participantes de uma equipe de trabalho devem se comunicar para conseguir realizar tarefas relacionadas, que necessitem de negociação ou que se encontram parcialmente descritas (Rezende, 2003). A comunicação em groupware pode ser efetuada de diversas formas. Alguns exemplos de ferramentas de comunicação disponíveis no AulaNet são o Debate e a Mensagem Instantânea, ferramentas de
comunicação síncrona, e a Conferência e o Correio para Turma, ferramentas de comunicação assíncrona. As ferramentas de comunicação síncrona privilegiam a interação entre os participantes, já que o tempo entre o envio de uma mensagem e a resposta do receptor é curto. Já as ferramentas de comunicação assíncronas valorizam a reflexão, pois os participantes têm mais tempo para formular suas mensagens.
Segundo o modelo 3C de colaboração, a comunicação é dita bem sucedida quando a mensagem tem o seu significado entendido pelo receptor (Fuks et al., 2005). A comunicação é realizada com o objetivo de gerar compromissos, porém uma mensagem mal interpretada pode gerar conflitos.
A leitura da mensagem altera o conhecimento do receptor e gera compromissos, que resultam em ações. Para ter indicações de que a mensagem foi compreendida o emissor deve observar as ações e o discurso do receptor (Fuks et al., 2005). Uma vez gerados os compromissos, é necessário coordenar o grupo para garantir o cumprimento dos compromissos.
1.1.2.
Coordenação
Para que um grupo cumpra uma tarefa de forma eficiente, para que o trabalho em grupo produza um resultado melhor que a soma dos trabalhos individuais, os membros do grupo precisam ser coordenados (Fussell et al., 1998). A coordenação organiza o grupo para evitar que esforços de comunicação e cooperação sejam perdidos e que as tarefas sejam realizadas na ordem correta, no tempo correto e cumprindo as restrições e objetivos (Raposo et al., 2001). Alguns exemplos de ferramentas de coordenação disponíveis no AulaNet são o serviço de Avisos e o Acompanhamento de Participação.
A coordenação de tarefas envolve a pré-articulação, o gerenciamento das atividades e a pós-articulação. Durante a pré-articulação são realizadas todas as ações necessárias de preparação para a colaboração. Dentre estas tarefas incluem-se a definição dos objetivos, o mapeamento dos objetivos em tarefas, a incluem-seleção dos participantes e a distribuição das tarefas entre os participantes. Normalmente a fase da pré-articulação termina antes do início da cooperação. O gerenciamento das atividades consiste no controle das interdependências das tarefas executadas
para alcançar o objetivo. A pós-articulação ocorre após a conclusão das tarefas e envolve uma análise dos resultados e a documentação do processo colaborativo (Fuks et al., 2005).
Trabalhar colaborativamente demanda esforço para a coordenação dos membros de um grupo. Sem coordenação, parte dos esforços de comunicação não são aproveitados na cooperação. Para que o grupo possa operar em conjunto (cooperar) de forma satisfatória é necessário que os compromissos assumidos na comunicação entre os participantes sejam coordenados (Rezende, 2003).
1.1.3.
Cooperação
Cooperação é o ato de operar em conjunto. Membros de um grupo cooperam, manipulando e organizando informação, construindo e refinando objetos de cooperação como documentos de texto, planinhas, gráficos entre outros. Mecanismos de cooperação provêem meios para gerenciar estes artefatos no espaço compartilhado, através do gerenciamento de versões, controle de acesso, busca, etc (Fuks et al., 2005). Alguns exemplos de ferramentas de cooperação disponíveis no AulaNet são o serviço de Aulas e o serviço de Co-Autoria.
O registro da informação na forma de objetos de cooperação visam aumentar o entendimento entre pessoas reduzindo a incerteza, relacionada à ausência de informação, e à equivocalidade, relacionada à ambigüidade e a existência de informações conflitantes (Fuks et al., 2002).
Ao salvar as informações trocadas, o grupo pode armazenar a história de uma discussão que resultou em uma decisão. Contando com a memória coletiva, em um tempo futuro esta história pode ser consultada, retomando os motivos que levaram decisão.
1.2.
O AulaNet
Dá-se o nome de learningware a um groupware que dá suporte a aprendizagem colaborativa (Santoro et al., 1999). O AulaNet é um learningware baseado na web desenvolvido pelo Laboratório de Engenharia de Software (LES)
da Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) desde junho de 1997. Participam de seu desenvolvimento alunos de graduação, mestrado e doutorado que também o usam para aplicar suas pesquisas e escrever artigos, monografias, dissertações e teses.
Atualmente o AulaNet está disponível em português, inglês e espanhol. Seu código fonte é fechado, mas sua distribuição é feita gratuitamente pela empresa EduWeb (2005). Esta empresa também realiza customizações no AulaNet para uso nos seus diversos clientes.
Os serviços do AulaNet são categorizados segundo sua classificação de acordo com o modelo 3C em serviços de comunicação, coordenação e cooperação. Debate Conferência Correio p/ Turma Correio para Participante Bate-papo COMUNICAÇÃO Assíncrona Síncrona Informações Acompanham. da Participação Tarefas COORDENAÇÃO Co-autoria COOPERAÇÃO Mensagem Instantânea Aulas Documentação Bibliografia Webliografia Download Avisos Exame Pesq. Opinião Acompanham. da Navegação Certificado
Figura 1.2 – Classificação dos Serviços do AulaNet segundo o Modelo 3C (Pimentel et al., 2005)
Os serviços de comunicação oferecem ferramentas com as quais os aprendizes dos cursos do AulaNet podem se comunicar de forma síncrona ou assíncrona. Os serviços de coordenação provêem serviços usados na gerência e controle das atividades de grupo. Os serviços de cooperação incluem serviços que
oferecem suporte ao conteúdo bibliográfico dos cursos, co-autoria entre aprendizes e outros.
Recentemente iniciou-se o desenvolvimento do AulaNetM, uma extensão dos serviços do AulaNet para dispositivos móveis. Esta iniciativa tem como objetivo explorar o uso do m-learning no AulaNet (Filippo et al., 2005a, b). A Figura 1.3 mostra a tela principal do AulaNet 3.0 e a Figura 1.4 a lista de mensagens da conferência do AulaNetM.
Figura 1.3 – AulaNet no Desktop. Figura 1.4– AulaNetM em um PDA.
Ao longo dos 8 anos que o AulaNet vem sendo desenvolvido, foram escritos 4 livros ou capítulos de livros, 15 artigos em revistas, 57 artigos em conferências e workshops, 2 teses de doutorado, 9 dissertações de mestrado e 5 monografias de fim de curso relacionadas de alguma forma ao AulaNet. Além disso, o AulaNet está presente em várias universidades no Brasil, como a PUC-Rio, a Federal do Rio de Janeiro, a Federal da Bahia entre outras, e em várias universidades do resto do mundo, dentre elas Universidade Tecnológica do Panamá e Universidade da Madeira (Portugal). O AulaNet também é usado em empresas, entre elas a Rede Globo, NEXTEL e SENAC.
Os mesmos desenvolvedores do AulaNet mantêm os cursos Engenharia de Groupware, onde ele é usado como repositório de informações e o curso Tecnologias de Informação Aplicada A Educação (TIAE), onde ele é usado integralmente em um curso totalmente à distância. Estes cursos são ministrados semestralmente e estão disponíveis para alunos da graduação e pós-graduação da PUC-Rio. A experiência com estes cursos fornece subsídios usados na melhoria constante do AulaNet.
O AulaNet é um learningware desenvolvido pelo LES desde 1997 e é usado em diversas empresas e universidades. O AulaNet também é usado para testar
hipóteses de pesquisas em diversos trabalhos de alunos da graduação, mestrado e doutorado da PUC-Rio. Atualmente, a versão distribuída do AulaNet é a 2.1. Sua arquitetura é descrita na seção a seguir.
1.2.1.
A Arquitetura do AulaNet 2.1
O AulaNet é desenvolvido desde junho de 1997. Inicialmente seu código era escrito em LUA (Ierusalimschy et al., 1996). O código evoluiu rapidamente e então decidiu-se utilizar a linguagem de programação Java, de modo a melhorar a integração com o mercado de desenvolvedores e aproveitar a robustez, portabilidade e recursos desta plataforma. O AulaNet foi então totalmente reformulado e sua versão 2.0 escrita em Java foi lançada.
Desde então, a sua arquitetura não sofreu alterações significativas. Atualmente, a versão de produção do AulaNet é a 2.1 que possui a mesma arquitetura da 2.0. Esta é baseada no paradigma cliente-servidor e é fortemente dependente da tecnologia Scriba (Fuks et al., 2003). A Figura 1.5 exibe o esquema da arquitetura do AulaNet 2.1. Conteúdo Web Java Aplicações Servlets Scriba Se rvle ts e C lasses Java Páginas HTML Servidor de
De bate Servidor dePrese nça
BD
Figura 1.5 – Arquitetura do AulaNet 2.0 (Barreto et al., 2005).
A tecnologia Scriba é constituída por uma linguagem de script que é embutida em arquivos HTML e um Servlet que interpreta os arquivos HTML. O Scriba possibilita, dentre outras coisas, chamadas a classes Java, acesso a banco de dados e definições de variáveis.
A maior parte das páginas HTML/Scriba está relacionada a classes Java, que acessam o banco de dados, realizam algum processamento e constroem a representação gráfica do resultado. O código que representa a lógica da aplicação
não é separado do código que representa a interface com o usuário e encontra-se espalhado tanto nas páginas HTML/Scriba quanto nas classes Java.
Os principais problemas desta arquitetura são a baixa modularidade, o uso de um paradigma procedural, a não aderência a tecnologias e boas práticas atuais e a não separação da lógica da aplicação da interface com o usuário.
O código do AulaNet 2.1 vem sendo desenvolvido ao longo destes anos através de prototipação. Isto, aliado a rotativade dos desenvolvedores do projeto, com o passar do tempo resultou em um código pouco modular e não padronizado. Como conseqüência, o código do AulaNet hoje apresenta um baixo grau de reuso.
Apesar de usar a linguagem Java, que é orientada a objetos, o código presente no AulaNet 2.1 assemelha-se à abordagem funcional, sem que seja utilizado uma modelagem de classes. Desta forma, muitas das vantagens inerentes ao paradigma OO não são aplicáveis ao AulaNet 2.1.
Muitas das tecnologias e das boas práticas presentes hoje não estavam presentes quando o AulaNet 2.1 foi desenvolvido. Um exemplo disto é a tecnologia JSP, que surge em meados de 1999 e oferece recursos semelhantes à tecnologia Scriba. O uso de tecnologias proprietárias como o Scriba dificulta a integração com outras equipes de desenvolvimento, como a EduWeb, que precisa treinar cada novo funcionário nesta tecnologia.
Por fim, a falta de uma separação clara entre a lógica da aplicação e a interface com o usuário dificulta o reuso, pois a lógica de negócios não pode ser reutilizada separadamente.
A soma destes problemas resultou em um AulaNet cuja atividade de manutenção é muito cara e cuja entrada de novos desenvolvedores ou integração com outros grupos de desenvolvedores é difícil. Para solucionar estes problemas, o consórcio de teses Groupware@LES propôs uma nova arquitetura para o AulaNet.
1.3.
Consórcio de Pesquisa
Para investigar o desenvolvimento de groupware e sua aplicação no desenvolvimento do AulaNet 3.0, nosso grupo de pesquisa Groupware@LES consorciou três trabalhos: esta dissertação de mestrado propõe a integração de
frameworks na constituição da arquitetura técnica do AulaNet; Gerosa (2006), em
sua tese de doutorado, propõe a montagem de groupware a partir da agregação de serviços e componentes baseados no Modelo 3C de Colaboração; e Pimentel (2006), em sua tese de doutorado, propõe um processo de desenvolvimento de groupware usando o Modelo 3C de Colaboração em diferentes etapas do processo. Estes trabalhos consorciados reduzem a distância semântica entre a implementação e os conceitos do domínio referentes à colaboração, o que favorece a manutenção e a evolução do groupware. Com o objetivo de contextualizar os três trabalhos, esta seção é replicada na introdução da dissertação e das teses resultantes. As subseções seguintes resumem cada trabalho.
1.3.1.
Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet
No desenvolvimento de um groupware, o projetista se depara com desafios em diferentes níveis: entender do domínio e lidar com questões de infra-estrutura. O desenvolvimento de groupware é difícil devido ao seu caráter multidisciplinar e à heterogeneidade dos diversos grupos de trabalho. O desenvolvedor deveria se concentrar mais nos aspectos funcionais utilizando uma infra-estrutura que trate as questões técnicas.
Nesta dissertação, foi elaborada uma arquitetura técnica multicamadas que faz uso do padrão MVC (Fowler, 2002) e que integra frameworks de infra-estrutura (Fayad & Schmidt, 1997; Fayad et al. 1999a, b; Fayad & Johnson, 2000). A abordagem multicamadas com o padrão MVC proporciona a separação entre a lógica da aplicação e a interface com o usuário, considerada uma boa prática de design de software (Fowler, 2002). Frameworks de infra-estrutura proporcionam uma maneira de lidar com as questões de baixo nível como persistências de dados, controle de transações, segurança, etc.
O diagrama esquematizado na Figura 1.6 mostra a arquitetura técnica proposta para o AulaNet 3.0. As setas indicam o fluxo de controle da aplicação, os retângulos representam classes, os círculos representam as interfaces, e as linhas pontilhadas representam a divisão entre as camadas. Esta arquitetura, baseada na
Arquitetura de POJOs descrita por Johnson (2002, 2004), é organizada nas seguintes camadas: apresentação, negócios e recursos.
Façade
Data Access Object V M (DTO) Camada de Negócios Camada de Apresentação Camada de Recursos C SGBD Mail Sender Servidor de E-Mails
Figura 1.6 – Arquitetura Técnica do AulaNet 3.0.
A camada de recursos relaciona os recursos externos necessários para que a aplicação seja executada. Na arquitetura do AulaNet 3.0 estão previstos o uso de banco de dados relacional (SGBD) e um servidor de e-mails.
A camada de negócios implementa a lógica da aplicação utilizando POJOs (POJO, 2005) (Plain Old Java Objects).
“O termo [POJO] foi cunhado enquanto eu [Martin Fowler], Rebbecca Parsons e Josh MacKenzie estávamos nos preparando para uma conferência em Setembro de 2000. Na palestra estávamos levantando os vários benefícios de codificar a lógica de negócios usando objetos Java comuns em vez de usar Beans de Entidade [EJB]. Questionávamos por que as pessoas eram tão contra usar objetos comuns em seus sistemas, e concluímos que era pela falta de um nome pomposo para os objetos simples. Então inventamos um, e o termo pegou muito bem.” (POJO, 2005)
Na camada de negócios, o modelo (representado no diagrama da Figura 1.6 pela letra M do MVC) é implementado por classes que realizam o padrão de projetos Data Transfer Object (Fowler, 2002), usadas para transportar os dados das entidades de negócio entre camadas. O acesso à base de dados é encapsulado através de classes que implementam o padrão de projetos Data Access Objects (DAO) (Alur et al., 2001), o que possibilita variar a maneira de persistir as classes
do modelo sem que seja preciso reescrever o código cliente. Mail Sender é a classe para enviar e-mails que, de forma similar ao DAO, encapsula o acesso ao servidor de e-mails. A lógica de negócios é exposta para a camada de apresentação através de um Façade (Gamma et al., 1995), que é o padrão de projeto para prover uma interface para acesso às funcionalidades de um serviço.
A camada de apresentação expõe a lógica de negócios ao usuário-final. Na arquitetura do AulaNet 3.0, esta camada é composta pelo controlador (representado no diagrama da Figura 1.6 pela letra C do MVC) e por páginas JSP que implementam a camada de Visão (representado no diagrama da Figura 1.6 pela letra V do MVC). O controlador chama os métodos do Façade, acessando a camada de negócios. Os DTOs resultantes de operações são passados à visão que exibe as informações ao usuário.
Frameworks de infra-estrutura foram selecionados e acrescentados a esta arquitetura para prover persistência de dados, gerenciamento de transações entre outros aspectos. Estes frameworks possibilitam ao desenvolvedor tratar estes aspectos com uma visão em alto nível, concentrando-se em seu domínio de aplicação, no caso, colaboração.
1.3.2.
Desenvolvimento de Groupware Componentizado com base no Modelo 3C de Colaboração
Um groupware é composto de ferramentas colaborativas como Fórum, Agenda, Documentação, etc. Estas ferramentas, disponíveis em diversas aplicações groupware, compartilham funcionalidades relativas ao suporte computacional à colaboração, tais como canal de comunicação, gerenciamento de participantes, registro de informações, etc.
Na tese de Gerosa (2006), para dar suporte ao desenvolvimento de groupware, foram estabelecidos dois níveis de componentização. O primeiro nível é constituído de serviços colaborativos que, por sua vez, são montados com componentes 3C (segundo nível) que implementam funcionalidades relacionadas à colaboração. Estes componentes são distribuídos em component kits organizados em função do modelo 3C de colaboração para que desenvolvedores montem aplicações colaborativas. Nesta abordagem, cada serviço usa componentes de comunicação, coordenação e de cooperação independentemente da classificação
3C do serviço. Foi aplicado um método de Engenharia do Domínio para elaborar o conjunto de componentes. Os componentes são iterativamente refinados em função da realimentação obtida com o desenvolvimento dos serviços do AulaNet 3.0 e em função de estudos de caso variando as configurações do suporte à colaboração.
Component frameworks (Syzperski, 1997) são usados para oferecer suporte
ao gerenciamento e à execução dos componentes. Conforme apresentado na Figura 1.7, na tese de Gerosa (2006) foi elaborado um component framework para cada nível de componentização (serviço e componente 3C). Os serviços são acoplados no Service Component Framework, e os componentes 3C são acoplados no Collaboration Component Framework. Estes component frameworks são responsáveis por tratar a instalação, remoção, atualização, ativação, desativação, localização, configuração e monitoramento de componentes. O Service Component Framework gerencia as instâncias dos serviços e a ligação com os componentes de colaboração correspondentes. O Collaboration Component Framework gerencia as instâncias dos componentes de colaboração, que são provenientes do Collaboration Component Kit. Algumas funcionalidades dos component frameworks são recorrentes, sendo então elaborado um framework para instanciar os component frameworks. Este tipo de framework é chamado de
component framework framework (CFF) (Szyperski, 1997, p.277). Um component framework framework é visto como um component framework de segunda ordem,
onde seus componentes são component frameworks (Szyperski, 1997, p.276). Na arquitetura da aplicação, o component framework de segunda ordem foi denominado Groupware Component Framework Framework.
Infrastructure Frameworks . Component Framework Service Component Framework Collaboration Component Framework Service X 3C Component A 3C Component B Service Y Framework . . Groupware Application Database Groupware
Figura 1.7. A arquitetura de aplicação proposta
Os component frameworks, serviços e componentes 3C oferecem suporte computacional aos conceitos do modelo 3C de colaboração, instrumentando o desenvolvimento da camada de negócio. A arquitetura de aplicação proposta estrutura os componentes do domínio, representando um projeto lógico de alto nível independente da tecnologia de suporte (D’Souza & Wills, 1998). Já os aspectos de infra-estrutura, tratados nesta dissertação, são independentes do domínio de aplicação.
Os componentes da arquitetura de aplicação são implementados segundo a arquitetura técnica. Os serviços do AulaNet são criados com um único Façade que expõe as operações deste serviço para a camada de apresentação. Os componentes de colaboração por sua vez, podem utilizar vários DTOs e DAOs, dependendo da complexidade do componente. Estes componentes podem ainda usar “código cola” (Szyperski, 1997) e adaptadores (D’Souza & Wills, 1998) para possibilitar a integração com componentes e outros sistemas que não são compatíveis por construção.
1.3.3.
RUP-3C-Groupware: um Processo de Desenvolvimento de Groupware baseado no Modelo 3C de Colaboração
Os frameworks de infra-estrutura selecionados nesta dissertação se encarregam de soluções para aspectos de infra-estrutura de baixo nível, visando possibilitar o desenvolvedor se concentrar nos aspectos funcionais. Os kits de serviços e componentes 3C elaborados por Gerosa (2006) fornecem os elementos para compor um groupware. O processo elaborado na tese de Pimentel (2006) estabelece os passos a serem seguidos na montagem do groupware, pois ainda que se construa uma aplicação groupware para um grupo com uma determinada dinâmica, com o tempo surgem novas situações onde são identificados novos problemas. A aplicação necessitará ser modificada para não se manter inadequada. Um processo organiza, em linhas gerais, uma seqüência de passos onde são incorporadas diretrizes e boas práticas que, quando seguidas, levam à produção de um software razoável (Sommerville, 2003; Beck, 2004; Philippe, 2003). Coexistem abordagens diferentes para o desenvolvimento de software, dentre elas, o desenvolvimento baseado em componentes, que é uma estratégia recente que tem se tornado cada vez mais usada (Sommerville, 2003; Gimenes & Huzita, 2005). Seguindo esta abordagem, tornaram-se conhecidos processos como Catalysis (D’Souza e Wills, 1998), UML Components (Cheesman & Daniels, 2001) e RUP – Rational Unified Process (Philippe, 2003). O processo formalizado na tese de Pimentel (2006), denominado RUP-3C-Groupware, também faz uso da abordagem baseada em componentes, estendendo o RUP para o desenvolvimento específico de aplicações groupware.
Comunicação
Coordenação Cooperação
Processo de Desenvolvimento de Groupware
Figura 1.8. Foco para o desenvolvimento de uma versão da aplicação groupware com base no Modelo 3C de Colaboração
No processo proposto, o Modelo 3C de Colaboração é usado nas diferentes etapas do processo: na análise de domínio para classificação das aplicações groupware e de seus elementos; na construção de componentes (Gerosa, 2006); e no foco dado para o desenvolvimento de cada versão. De acordo com essa prática, a aplicação groupware é desenvolvida resolvendo um problema de comunicação, de coordenação ou de cooperação, um a cada versão ao longo do ciclo de desenvolvimento, esquematizado na Figura 1.8.
1.4.
Organização da Escrita
O texto desta dissertação está estruturado em 7 capítulos e 1 apêndice. No capítulo 2 são apresentados conceitos importantes sobre frameworks. Este capítulo apresenta definições, classificações e outras características de frameworks pesquisadas na literatura.
No capítulo 3 a camada de negócios da arquitetura do AulaNet 3.0 é detalhada. É feita uma breve descrição do modelo de componentes EJB, levantando suas vantagens, desvantagens e a perspectiva para seu futuro. Neste capítulo, após uma análise e comparação criteriosa, são escolhidos o framework Hibernate (2005) e o Spring (2005) para serem acrescentados à camada de negócios do AulaNet 3.0.
No capítulo 4 o foco é a camada de apresentação. O grande número de web frameworks disponíveis no mercado demanda uma análise mais detalhada entre os concorrentes desta categoria de framework. Ao término da comparação, o web framework JavaServer Faces (JSF, 2005) é incorporado a camada de apresentação do AulaNet 3.0.
O capítulo 5 retoma a descrição da arquitetura do AulaNet 3.0 apresentada neste capítulo, complementando-a com os frameworks analisados tanto no capítulo 3 quanto no capítulo 4. Também é apresentado neste capítulo como a arquitetura do AulaNet 3.0 provê suporte a dispositivos móveis e que novos frameworks podem ser incorporados a arquitetura, tomando como estudo de caso o framework de agentes Jade (2005). Este capítulo mostra ainda os benefícios que o paradigma de agentes de software pode trazer ao AulaNet.
O capítulo 6 apresenta as conclusões finais e as contribuições desta pesquisa enquanto que o capítulo 7 apresenta as referencias bibliográficas. O apêndice A é adicionado com a transcrição dos e-mails trocados com outros pesquisadores, que gentilmente cederam dados tornando esta pesquisa mais precisa. O apêndice B fornece detalhes sobre o método utilizado para comparação de frameworks utilizando critérios não-técnicos.
Ao longo desta dissertação são apresentadas várias listagens de código. Para destacar as listagens do texto da dissertação são usadas caixas especiais. A Figura 1.9 mostra um exemplo destas caixas.
30: public class HelloReaders {
31: public static void main(String args[]) { 32: System.out.println("Olá, leitores!") ; 33: }
14: }
Figura 1.9 – Exemplo de uma Listagem de Código.
O início de cada linha é precedido de uma numeração, para facilitar a referência no texto. Linhas em branco não são numeradas. Dentro de uma seção a numeração sempre começa do fim da numeração da listagem anterior. Por exemplo, a listagem acima começa na linha 30, então se supõem que haveria uma listagem anterior cuja última linha seria 29. Numerando as linhas desta forma o texto torna-se mais claro, pois citações de linhas não se confundem quando há mais de uma listagem muito próxima. As listagens de código seguem as convenções de código definidas no Sun Java Code Conventions (SJCC, 2006) sempre que possível, mas eventualmente podem fugir do padrão para tornar a listagem mais clara. Alguns detalhes, como declarações e importações de pacotes são omitidos pelo bem da clareza.
Toda a pesquisa que resultou nesta dissertação foi baseada em pesquisas teóricas e aplicações práticas. Um protótipo do serviço da Conferência do AulaNet foi implementado utilizando os principais frameworks apresentados nesta dissertação. As listagens de código presentes nesta dissertação são baseadas em código extraído destes protótipos, simplificadas para fins didáticos.
Nesta dissertação, os frameworks também são analisados sob um ponto de vista não-técnico. São comparados os seguintes critérios: disponibilidade de documentação, de suporte e de ferramentas compatíveis, grau de aceitação no mercado e disponibilidade de profissionais aptos a trabalhar com cada framework.
Apesar de ser muito difícil obter resultados absolutos para estes critérios, Raible (2005) apresenta um método para colher indícios. A quantidade de documentação pode ser checada através de uma busca por livros sobre o framework na página da livraria Amazon e por artigos disponíveis na web sobre o framework através da ferramenta de busca Google. A disponibilidade de suporte é verificada contabilizando o volume de mensagens trocadas nas listas de discussões oficiais de cada framework. Dessa forma, obtém-se um indício do grau de atividade da comunidade que oferece suporte ao framework. A compatibilidade com ferramentas é verificada analisando um conjunto de ferramentas, verificando a documentação destas uma a uma e checando se são compatíveis com o framework. O grau de aceitação no mercado é verificado através de buscas em sites de empregos, procurando por vagas que solicitem habilidades em cada framework. Por fim, a disponibilidade de profissionais é verificada através de buscas realizadas em sites que hospedam currículos. São contabilizados os currículos de profissionais que se declaram aptos a trabalhar com cada framework.
Um dos principais objetivos da Engenharia de Software é o reuso. Através da reutilização de software obtém-se o aumento da qualidade e redução do esforço de desenvolvimento (Gimenes & Huzita, 2005). A orientação a objetos fornece funcionalidades para que classes possam ser reutilizadas, bem como métodos por meio de seus mecanismos de herança e polimorfismo (Lundberg & Mattsson 1996). Componentes de software definem unidades reutilizáveis que oferecem serviços através de interfaces bem definidas (Gimenes & Huzita, 2005). Padrões de Projeto (Design Patterns) (Gamma et al., 1995) é outra abordagem mais abstrata que objetiva a reutilização de projetos de soluções para problemas recorrentes.
Além destas formas de reutilização, a tecnologia de frameworks possibilita que uma família de produtos seja gerada a partir de uma única estrutura que captura os conceitos mais gerais da família de aplicações (Pinto, 2000).
Este capítulo apresenta os principais conceitos sobre frameworks encontrados na literatura. Primeiramente, são revistas algumas definições sobre frameworks. Logo após, os frameworks são classificados em duas categorias: frameworks de aplicação orientado a objetos e frameworks de componentes. São apresentados os papéis envolvidos no desenvolvimento e uso de frameworks e os benefícios e desafios decorrentes da adoção de frameworks. O capítulo é encerrado com uma comparação entre frameworks e outras abordagens que visam o reuso.
2.1.
Definições de Frameworks
A literatura é repleta de definições de frameworks. As principais são descritas a seguir.
Para Fayad et al (1999b) e Johnson & Foote (1988), um framework é um conjunto de classes que constitui um projeto abstrato para a solução de uma família de problemas.
Segundo Mattsson (1996, 2000), um framework é uma arquitetura desenvolvida com o objetivo de atingir a máxima reutilização, representada como um conjunto de classes abstratas e concretas, com grande potencial de especialização.
Para Johnson (1991) e Gamma et al (1995), um framework é um conjunto de objetos que colaboram com o objetivo de atender a um conjunto de responsabilidades para uma aplicação específica ou um domínio de aplicação.
Já segundo Buschmann et al. (1996), Pree (1995) e Pinto (2000) um framework é definido como um software parcialmente completo projetado para ser instanciado. O framework define uma arquitetura para uma família de subsistemas e oferece os construtores básicos para criá-los. Também são explicitados os lugares ou pontos de extensão (hot-spots) nos quais adaptações do código para um funcionamento específico de certos módulos devem ser feitas.
Apesar de diferentes, as definições encontradas na literatura não são contraditórias. A definição adotada nesta dissertação é a de Buschmann et al. (1996), Pree (1995) e Pinto (2000).
2.2.
Classificação dos Frameworks
Frameworks podem ser classificados de diversas formas. Inicialmente, são classificados em dois grupos principais: frameworks de aplicação orientado a objetos (Fayad et al., 1999a, b; Fayad & Johnson, 2000) e framework de componentes (Szyperski, 1997).
2.2.1.
Frameworks de Aplicações Orientado a Objetos
Frameworks de aplicação orientado a objetos, também chamados de frameworks de aplicação, geram famílias de aplicações orientadas a objetos. Seus pontos de extensão são definidos como classes abstratas ou interfaces, que são estendidas ou implementadas por cada instância da família de aplicações. Segundo
Fayad et al (1999b), frameworks de aplicação são classificados quanto ao seu escopo em frameworks de infra-estrutura de sistemas, frameworks de integração de middleware e frameworks de aplicações corporativas.
Frameworks de infra-estrutura de sistemas simplificam o desenvolvimento de sistemas de infra-estrutura portáveis e eficientes, como sistemas operacionais, frameworks de comunicação, de interfaces gráficas e ferramentas de processamento de linguagens.
Frameworks de integração de middleware são usados para integrar aplicações e componentes distribuídos. Estes frameworks escondem o baixo nível da comunicação entre componentes distribuídos, possibilitando que os desenvolvedores trabalhem em um ambiente distribuído de forma semelhante a que trabalham em um ambiente não distribuído. São exemplos de frameworks de integração de middleware Java RMI (RMI-IIOP, 2005) e frameworks ORB (Object Request Broker).
Frameworks de aplicações corporativas, ao contrário dos frameworks de infra-estrutura e de integração de middleware, são voltados para um domínio de aplicação específico, como por exemplo, os domínios da aviação, telecomunicações e financeiro. Frameworks de aplicações corporativas são mais caros de serem desenvolvidos ou comprados quando comparados com os de integração de middleware e de infra-estrutura, pois são necessários especialistas do domínio de aplicação para construí-lo. Entretanto, eles podem prover um retorno substancial já que eles encapsulam o conhecimento sobre o domínio onde a instituição atua (Fayad et al., 1999b).
Frameworks de infra-estrutura e de integração de middleware fornecerem mecanismos para integrar componentes distribuídos e tratar aspectos de infra-estrutura, o desenvolvedor da aplicação abstrai os detalhes em baixo nível e concentra-se no objetivo principal da aplicação. Estes frameworks tratam aspectos comuns a diversos domínios de aplicação de forma que quase sempre são encontradas soluções disponíveis no mercado e na maior parte das vezes é mais vantajoso buscar uma solução existente do que desenvolvê-la internamente.
Além da classificação por escopo, segundo Fayad et al (1999b) frameworks podem ainda ser classificados quanto à forma usada para estendê-los. Frameworks caixa branca, ou white box, são instanciados usando herança, através da implementação de Template Methods (Gamma et al., 1995), métodos abstratos
que são implementados na subclasse, ou da redefinição de métodos ganchos (hook
methods) (Pree, 1995), métodos com uma implementação padrão que pode ser
redefinida na subclasse. Frameworks caixa preta, ou black box, são instanciados através de configurações e composições, através da definição de classes que implementam uma determinada interface ou contrato. Os pontos de extensão dos frameworks caixa preta freqüentemente são definidos seguindo o padrão de projetos Strategy (Gamma et al., 1995).
Frameworks caixa branca exigem que o desenvolvedor responsável pela instanciação do framework possua um bom conhecimento sobre sua estrutura interna e normalmente são mais difíceis de usar. Por outro lado, frameworks caixa preta não exigem tanto conhecimento sobre a estrutura interna do framework, mas são menos flexíveis. Frameworks caixa cinza, ou gray box, possuem as características conjuntas dos frameworks caixa branca e preta, de forma a tentar evitar as desvantagens dos dois.
2.2.2.
Frameworks de Componentes
Segundo Szyperski (1997), um framework de componentes é uma entidade de software que provê suporte a componentes que seguem um determinando modelo e possibilita que instâncias destes componentes sejam plugadas no framework de componentes. Ele estabelece as condições necessárias para um componente ser executado e regula a interação entre as instâncias destes componentes. Um framework de componente pode ser único na aplicação, criando uma ilha de componentes ao seu redor, ou pode cooperar com outros componentes ou frameworks de componentes. Alguns exemplos de frameworks de componentes são o OpenDoc (2005) e o BlackBox (Oberon, 2005).
A principal diferença entre frameworks de aplicação orientado a objetos e framework de componentes é que, enquanto frameworks de aplicações definem uma solução inacabada que gera uma família de aplicações, um framework de componentes estabelece um contrato para plugar componentes. Usando uma analogia, um framework de aplicação equivale ao quadro de uma bicicleta. Há lugares específicos (os pontos de extensão) onde o guidão, as rodas, o banco e os pedais (implementações dos pontos de extensão) podem ser encaixados. Bicicletas
diferentes (instâncias do framework) podem ser compostas variando estes itens: bicicletas com marchas, com amortecedores, etc., mas apenas os pontos previstos podem variar e o produto final será sempre uma bicicleta. Por outro lado, frameworks de componentes podem ser vistos como uma placa de circuito integrado com slots onde os chips (componentes) podem ser encaixados para criar uma instância. Como os frameworks de componentes, as placas são utilizadas para compor soluções para diversos domínios como por exemplo, uma placa de vídeo ou um modem.
2.3.
Papéis Envolvidos no Uso e Desenvolvimento de um Framework
Há vários profissionais envolvidos na criação, manutenção e uso (instanciação) de um framework. Estes papéis, que não precisam necessariamente ser exercidos por pessoas diferentes, são segundo Froehlich et al. (1997a), Froehlich et al (1997b) e Pinto (2000): projetista do framework, mantenedor do framework e o desenvolvedor de aplicações (usuário do framework).
O projetista do framework é responsável pelo desenvolvimento da estrutura básica do framework. O projetista determina os pontos de extensão do frameworks (hot spots) e realiza o levantamento de requisitos.
O mantenedor do framework é responsável por redefinir e acrescentar novas funcionalidades ao projeto do framework, possibilitando que novas características sejam incorporadas ao framework no momento da instanciação pelos desenvolvedores de aplicação.
O desenvolvedor de aplicações usa o framework. Ele satisfaz os pontos de extensão para gerar a aplicação, instância do framework.
2.4.
Conseqüências da Adoção de Frameworks
A utilização de frameworks no desenvolvimento de aplicações traz benefícios, originados de suas características principais: são modulares, reusáveis, extensíveis e eventualmente assumem o controle da execução invocando métodos da aplicação quando necessário (inversão de controle). Por outro lado, há certos
desafios na criação e uso de frameworks que não podem ser ignorados. Esta seção lista as principais vantagens e desafios decorrente da adoção de frameworks.
2.4.1.
Benefícios Decorrentes da Utilização de Frameworks
Os principais benefícios decorrentes da utilização de frameworks, segundo Fayad et al. (1999b) e Pinto (2000) advêm da modularidade, reusabilidade, extensibilidade e inversão de controle que os frameworks proporcionam.
Frameworks encapsulam detalhes de implementação voláteis através de seus pontos de extensão, interfaces estáveis e bem definidas, aumentando a modularidade da aplicação. Os locais de mudanças de projeto e implementação da aplicação construída usando o framework são localizados, diminuindo o esforço para entender e manter a aplicação.
Além disso, frameworks incentivam o reuso, pois capturam o conhecimento de desenvolvedores em determinado domínio ou aspecto de infra-estrutura ou de integração de middleware. As interfaces do framework promovem pontos de extensão que as aplicações estendem gerando instâncias que compartilham as funcionalidades definidas no framework. Desta forma, aumentam a produtividade dos desenvolvedores, pois o processo não começa do zero, a qualidade e a confiabilidade do produto final, pois idealmente as funcionalidades do framework já foram testadas em várias instâncias, e a interoperabilidade de software, pois as instâncias de uma mesma família compartilham características em comum.
Frameworks oferecem pontos de extensão explícitos que possibilitam aos desenvolvedores estenderem suas funcionalidades para gerar uma aplicação. Os pontos de extensão desacoplam as interfaces estáveis do framework e o comportamento de um determinado domínio de aplicação das variações requeridas por uma determinada aplicação em um dado contexto.
Por fim, alguns frameworks apresentam inversão de controle (Inversion of
Controll – IoC). Inversão de controle, também é conhecida como princípio de
Hollywood : “Don’t call us, we will call you” (Larman, 2004). Trata-se de transferir o controle da execução da aplicação para o framework, que chama a aplicação em determinados momentos como na ocorrência de um evento. Através da IoC o framework controla quais métodos da aplicação e em que contexto eles
serão chamados em decorrência de eventos, como eventos de janela, um pacote enviado para determinada porta, entre outros.
2.4.2.
Desafios Decorrentes da Utilização de Frameworks
Quando usado em conjunto com padrões de projetos, bibliotecas de classes, componentes, entre outros, frameworks de aplicação têm o potencial para aumentar a qualidade de software e reduzir o esforço de desenvolvimento. Contudo, instituições que tentam construir ou usar frameworks freqüentemente falham a menos que resolvam os seguintes desafios: esforço de desenvolvimento, curva de aprendizagem, integração, eficiência, manutenção, validação e remoção de defeitos e falta de padrões (Fayad et al., 1999b).
Destes desafios, o esforço de desenvolvimento afeta principalmente os projetistas de frameworks. A curva de aprendizagem, a integração e a eficiência afetam principalmente os desenvolvedores de aplicação. A manutenção e validação e remoção de defeitos afetam tanto desenvolvedores de aplicação quanto mantenedores de frameworks e a falta de padrões afetam a todos envolvidos no desenvolvimento e uso dos frameworks.
O desafio do esforço de desenvolvimento ocorre devido à alta complexidade envolvida no projeto de um framework. Se desenvolver aplicações complexas é difícil, desenvolver frameworks que sejam de alta qualidade, extensíveis e reusáveis para domínios de aplicações complexos ou para tratar aspectos de infra-estrutura ou de integração de middleware é ainda mais difícil. Projetistas de frameworks devem estar cientes dos custos decorrentes do desenvolvimento de frameworks de aplicação.
Quanto à curva de aprendizagem, aprender a usar um framework de aplicação leva tempo e incorre em custos. A menos que o esforço de aprendizado possa ser amortizado através do uso do framework em muitos projetos, ou em projetos duradouros, o investimento pode não compensar. Deve ser analisado se os benefícios trazidos pelo framework compensam os custos com o treinamento da equipe de desenvolvimento.
O desafio da integração ocorre quando diversos frameworks são usados com outras tecnologias e com sistemas legados não previstos pela arquitetura do
framework. Antes de usar um framework o desenvolvedor de aplicações deve analisar possíveis problemas que possam surgir ao incorporar novos frameworks à aplicação.
Além disso, aplicações usando frameworks podem apresentar desempenho inferior a aplicações específicas. Para tornarem-se extensíveis, frameworks de aplicações adicionam níveis de indireção. Aplicações genéricas tendem a obter desempenho inferior a aplicações específicas (Fayad et al., 1999b). Desta forma o desenvolvedor de aplicações deve considerar se os ganhos advindos do reuso compensam uma potencial perda de desempenho.
Frameworks inevitavelmente precisam ser mantidos. A manutenção em frameworks toma diversas formas como, correção de erros de programação, acréscimo ou remoção de funcionalidades, acréscimos ou remoção de pontos de extensão, etc. A manutenção é realizada pelos mantenedores do framework, que precisam ter um conhecimento profundo sobre os componentes internos e suas interdependências. Em alguns casos, a própria instância do framework sofre manutenção para acompanhar a evolução do framework. Cabe ao desenvolvedor da aplicação considerar o esforço de manutenção gasto para obter os benefícios de uma nova versão do framework.
Além disso, a validação e remoção de erros de um framework ou de uma aplicação que usa um framework é um desafio, pois o framework é uma aplicação inacabada, o que torna difícil tanto para os mantenedores de frameworks quando para os desenvolvedores de aplicação testar, respectivamente, o framework e a instância do framework isoladamente. Aplicações que usam framework costumam ser mais difíceis de depurar, pois devido a IoC, o controle da execução oscila entre a aplicação e o framework.
Por fim, ainda não há um padrão amplamente aceito para desenvolver, documentar, implementar e adaptar frameworks. Todos os papéis envolvidos no desenvolvimento e uso do framework são afetados por este desafio, sendo que os mais afetados são os mantenedores do framework e o desenvolvedor de aplicações. O primeiro, pois precisa ter um conhecimento profundo sobre os componentes internos e suas interdependências. O segundo, pois a falta de um padrão de documentação de frameworks dificulta o seu uso.
2.5.
Frameworks e Outras Abordagens
Esta seção realiza uma breve comparação entre frameworks e outras técnicas de desenvolvimento de software que objetivam o reuso. Dentre elas, são analisadas o projeto de aplicações orientado a objetos, biblioteca de classes, padrões de projeto e componentes de software (Pinto, 2000).
2.5.1.
Frameworks e Aplicações Orientado a Objetos
Uma aplicação orientada a objetos descreve um programa executável completo, atendendo aos requisitos definidos nos documentos de especificação. Já os frameworks são incompletos e não são executáveis. Eles capturam funcionalidades comuns a diversas aplicações, mas declaram pontos de extensão que devem ser preenchidos pela aplicação que instancia o framework.
Frameworks geram famílias de aplicações orientadas a objetos através do preenchimento dos pontos de extensão, mas aplicações orientadas a objetos não geram famílias de frameworks.
2.5.2.
Frameworks e Biblioteca de Classes
Bibliotecas de classes são conjuntos de classes relacionadas com um propósito geral. Por outro lado, as classes de um framework estão relacionadas a um determinado domínio ou a algum determinado aspecto de infra-estrutura ou de integração de middleware. Além disso, as classes da biblioteca são reutilizadas individualmente enquanto que as classes de um framework são reutilizadas em conjunto.
Frameworks tendem a ter um impacto maior do que bibliotecas de classes na arquitetura da aplicação. Frameworks ativos (calling frameworks) (Matsson, 2000), que utilizam inversão de controle, podem assumir o controle de execução da aplicação ao contrário de bibliotecas de classes que são sempre passivas.
