INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO...
79
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE LUIZ FELIPE DE SOUSA MIRANDA DESENVOLVIMENTO DE APLICAÇÃO CORPORATIVA PARA INTEGRAÇÃO INFORMACIONAL DO CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO NATAL/RN 2011
Transcript of INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO...
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
DO RIO GRANDE DO NORTE
LUIZ FELIPE DE SOUSA MIRANDA
DESENVOLVIMENTO DE APLICAÇÃO CORPORATIVA PARA INTEGRAÇÃO
INFORMACIONAL DO CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO
NATAL/RN
2011
LUIZ FELIPE DE SOUSA MIRANDA
DESENVOLVIMENTO DE APLICAÇÃO CORPORATIVA PARA INTEGRAÇÃO
INFORMACIONAL DO CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO
Trabalho de Conclusão de Curso apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte, em cumprimento às exigências legais como requisito parcial à obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas. Orientador: Fabiano Papaiz
NATAL/RN
2011
LUIZ FELIPE DE SOUSA MIRANDA
DESENVOLVIMENTO DE APLICAÇÃO CORPORATIVA PARA INTEGRAÇÃO
INFORMACIONAL DO CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO
Trabalho de Conclusão de Curso apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte, em cumprimento às exigências legais como requisito parcial à obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas.
Aprovado em <<data>> de <<mês> de 2011.
BANCA EXAMINADORA
Fabiano Papaiz – Orientador
Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte
<<Nome de primeiro componente da banca examinadora>> Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte
<<Nome de segundo componente da banca examinadora>>
Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte
Dedico este trabalho a todos que, por falta de condições, tiveram
seus sonhos restritos ou não tiveram oportunidades de alcançar
seus sonhos
AGRADECIMENTOS
Agradeço, de todo coração, ao meu Deus, que é justo, misericordioso e fiel,
digno de todo louvor e adoração, fonte de toda força que me move para alcançar meus
objetivos e sonhos, sempre atento ao meu clamor e às minhas dificuldades.
A minha família, instrumento usado por Deus para ajudar a cuidar de mim, fonte
de carinho, compreensão e superação. Em especial, quero demonstrar minha gratidão
ao meu pai, Luiz Antonio, minha mãe, Edenilza, ao meu irmão, Luiz Fernando, e às
minhas tias Edilzene e Elenilza, sempre solícitos nos momentos difíceis.
Aos educadores que contribuíram para minha formação, em especial ao meu
orientador, Fabiano Papaiz, e aos demais professores que me transmitiram um parcela
de seus conhecimentos ao longo do curso de TADS.
Aos amigos que fiz no curso, em especial a Henrique Pinto e a Raul Terra,
companheiros ao longo de todo desenvolvimento do projeto Soft Educ GCI, e aos
demais amigos e colegas que acreditam no meu potencial.
A equipe da coordenação do Centro de Idiomas FUNCERN, em especial a
Fernando Carneiro, por ter acreditado no trabalho de nossa equipe e nos confiado o
desenvolvimento do sistema da organização que coordena.
Por fim, agradeço a todos que contribuíram com minhas experiências de vida,
que me fizeram chorar ou que me ajudaram a vencer, me deixando alguma lição.
“Sem sonhos, a vida não tem brilho. Sem metas, os sonhos não têm
alicerces. Sem prioridades, os sonhos não se tornam reais. Sonhe,
trace metas, estabeleça prioridades e corra riscos para executar seus
sonhos. Melhor é errar por tentar do que errar por omitir!”
Augusto Cury
vii
SUMÁRIO
RESUMO viii
ABSTRACT ix
1. INTRODUÇÃO 1
1.1. CONTEXTO E MOTIVAÇÃO DO TRABALHO 1
1.2. OBJETIVOS 2
1.3. METODOLOGIA 3
1.4. ESTRUTURA 3
2. FUNDAMENTAÇÃO TEÓRICA 4
2.1. METODOLOGIAS ÁGEIS EM PROCESSOS DE SOFTWARE. 4
2.1.1. PROCESSO DE SOFTWARE 5
2.1.2. METODOLOGIAS ÁGEIS 8
2.1.3. CARACTERÍSTICAS DAS PRINCIPAIS METODOLOGIAS ÁGEIS: SCRUM E XP 10
2.2. TECNOLOGIAS JAVA ENTERPRISE EDITION (JEE). 14
2.2.1. JAVA SERVER FACES (JSF) 15
2.2.2. ENTERPRISE JAVABEANS (EJB) 21
2.2.3. JAVA PERSISTENCE API (JPA) 23
3. ESTUDO DE CASO 27
3.1. CONTEXTUALIZAÇÃO DO PROJETO 27
3.2. APLICAÇÃO DE PROCESSO BASEADO EM METODOLOGIAS ÁGEIS 32
3.3. ESCOPO E REQUISITOS DO SISTEMA 36
3.3.1. MÓDULO COORDENAÇÃO 36
3.3.2. MÓDULO PÚBLICO 39
3.3.3. MÓDULO ACADÊMICO 40
3.4. FERRAMENTAS E TECNOLOGIAS APLICADAS 40
3.5. ARQUITETURA E MODELAGEM DO SISTEMA 41
3.6. RESULTADOS OBTIDOS 50
4. CONCLUSÃO 67
REFERÊNCIAS BIBLIOGRÁFICAS 70
viii
RESUMO
Miranda, Luiz. Desenvolvimento de Aplicação Corporativa para Integração
Informacional do Centro de Idiomas FUNCERN: Um Estudo de Caso. Natal, 2011. 79 f.
Trabalho de Conclusão de Curso (Tecnologia em Análise e Desenvolvimento de
Software) – Diretoria Acadêmica de Gestão e Tecnologia da Informação, Instituto
Federal de Educação, Ciência e Tecnologia do Rio Grande Do Norte, Natal-RN, 2011.
Mediante ao contexto da sociedade da informação, na qual é cada vez mais importante
gerir e manipular eficaz e eficientemente dados organizacionais, as instituições
necessitam de soluções adequadas para coletar (ou recuperar), processar, armazenar
e distribuir informações, em conformidade com seus processos de negócio. Também
no ramo das instituições de ensino, sistemas computacionais tornaram-se ferramentas
diferenciais, muito úteis para simplificar a execução de atividades do fluxo de trabalho,
facilitar o acesso e a manipulação de dados organizacionais, proporcionar melhores
condições de gerência; melhorar o atendimento a clientes, entre outros. Com base
nisso, em meados do ano de 2010, o Centro de Idiomas FUNCERN percebia a
necessidade de avançar no que diz respeito ao aparato informacional utilizado para
apoiar o trabalho na organização, haja vista que a estrutura de softwares então
disponível apresentava vários problemas e gerava múltiplos inconvenientes. Com a
pretensão de evoluir, a coordenação do Centro de Idiomas firmou uma parceria com
um grupo de estudantes de desenvolvimento de sistemas a fim de que analisassem a
situação, projetassem, produzissem e implantassem uma solução em tecnologia da
informação que suprisse as demandas do estabelecimento. Esta solução vem sendo
desenvolvida desde o mês de setembro de 2010 e tem previsão para ser concluída no
mês de dezembro de 2011. O presente trabalho refere-se ao desenvolvimento desta
solução, enfatizando a adoção de processo de software baseado em metodologias
ágeis, o escopo e os requisitos do sistema, as tecnologias e ferramentas utilizadas na
construção, a estrutura arquitetural proposta, e os resultados obtidos até o momento.
Palavras-chave: Aplicações Coorporativas, Desenvolvimento Ágil. Plataforma JEE.
ix
ABSTRACT
Through the context of the information society, which is increasingly important to
manage and manipulate data efficiently and effectively organizational institutions need
solutions appropriate to collect (or retrieve), process, store and distribute information in
accordance with their processes business. Also in the field of educational, computer
systems have become common differential, very useful to simplify the execution of
workflow activities, facilitate access to and manipulation of organizational data,
providing better-run, improve customer service, among others. Based on this, in mid-
2010, the Language Center FUNCERN realized the need to move with respect to the
informational apparatus used to support the work in the organization, given that the
structure of software available then had several problems and generated many
inconveniences. Claiming to evolve, the coordination of the Language Center has
partnered with a group of students to develop systems that analyze the situation,
design, produce and deploy an information technology solution that met the demands of
the establishment. This solution has been developed since the month of September
2010 and is expected to be completed in December 2011. This paper refers to the
development of this solution, emphasizing the adoption of software process based on
agile methodologies, scope and system requirements, technologies and tools used in
construction, architectural structure proposal, and the results obtained so time.
Keywords: Applications Enterprise, Agile Development. JEE platform.
1
1. INTRODUÇÃO
O presente trabalho consiste, essencialmente, em apresentar o desenvolvimento
de uma solução em sistemas de informação, denominada Soft Educ GCI, que se
propõe a resolver problemas e inconvenientes identificados na execução do fluxo de
atividades do Centro de Idiomas FUNCERN. Este capítulo introdutório pretende expor
uma visão geral do trabalho, indicando o contexto que o circunda, os fatores que
estimularam seu desenvolvimento, os objetivos pretendidos, a metodologia utilizada, e
a estrutura de organização do conteúdo do trabalho.
1.1. Contexto e Motivação do Trabalho
O Centro de Idiomas FUNCERN é um programa da Fundação de Apoio à
Educação e ao Desenvolvimento Tecnológico do RN (FUNCERN) sediado nas
dependências do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande
do Norte (IFRN) com o intuito de oferecer, ao público em geral, cursos de idiomas de
qualidade a um custo mais acessível. Essa organização oferece cerca de 65 turmas de
cursos de idiomas a cada semestre e atua com mais de 1000 alunos ativos, sendo que
a demanda de alunos para ingressar nos cursos é maior que o número de vagas
disponíveis. Entre professores dos cursos, e funcionários e bolsistas que trabalham
exercendo funções ligadas a coordenação, o Centro de idiomas tem mais de 30
colaboradores. A instituição tem um processo de negócio um tanto quanto peculiar,
incluindo a realização, a cada semestre, de um sorteio de vagas para as turmas do 1º
nível dos cursos, e a reserva de um determinado número de vagas em cada turma para
bolsistas alunos ou servidores do IFRN.
Para apoiar na gerência e no desempenho operacional das atividades próprias de
seu funcionamento, o estabelecimento utilizava alguns softwares. No entanto, ficava
nítido o juízo de que a estrutura de software utilizada estava ficando obsoleta, era
problemática, apresentava diversas incompatibilidades com as características do
processo de negócio da instituição e gerava alguns inconvenientes, não tendo
acompanhado a evolução da organização. Os problemas na referida estrutura de
software serão analisados e detalhados na sessão 3.1 deste trabalho.
Tomando este contexto, a realização do projeto Soft Educ GCI, que é o foco do
estudo deste trabalho fundou-se em uma parceria estabelecida entre a instituição
2
mencionada e um grupo de alunos do Curso Superior de Tecnologia em Análise e
Desenvolvimento de Sistemas (TADS) do IFRN, no intuito de construir uma estrutura
de software mais evoluída e apropriada para apoiar o funcionamento do Centro de
Idiomas FUNCERN. Tal parceria foi firmada em setembro de 2010, e prevê a instalação
final do sistema, de acordo com o escopo previsto atualmente, no mês de dezembro de
2011.
O processo de desenvolvimento do projeto mencionado iniciou-se dentro da
disciplina de Projeto de Desenvolvimento de Software Corporativo (PDSC), do sexto
período do curso de TADS, cujo objetivo é proporcionar aos alunos uma espécie de
prática profissional, através da aplicação dos conteúdos ministrados durante o
semestre letivo ao desenvolvimento de sistemas. Dessa forma, o projeto seria uma boa
oportunidade para promover a extensão do trabalho acadêmico ao contexto de um
problema real em um ambiente de negócios, e para aplicar as tecnologias Java para
desenvolvimento corporativo estudadas, bem como um método de desenvolvimento de
software flexível e adaptável as características da equipe de desenvolvimento e do
cliente, dedicado fundamentalmente a agregar valor ao produto e a melhorar
continuamente o processo.
1.2. Objetivos
O principal objetivo deste trabalho é o desenvolvimento de uma solução
computacional que apóie o desempenho das atividades próprias do fluxo de trabalho
no Centro de Idiomas FUNCERN, resolva os problemas e inconvenientes identificados
na estrutura informacional utilizada quando este trabalho foi idealizado, proporcione
mais comodidade, eficiência e eficácia para o gerenciamento das informações e para a
execução do trabalho necessário na organização, e satisfaça seus usuários e cliente.
Os demais objetivos são: Desenvolver e apresentar um estudo sobre
metodologias ágeis para o desenvolvimento de software; Desenvolver e apresentar um
estudo sobre as tecnologias da plataforma JEE para o desenvolvimento de aplicações
coorporativas; Elucidar e descrever os requisitos esperados para sistema pretendido;
Descrever a aplicação de um processo de software que une o ciclo do Scrum com
práticas do XP e se utiliza de alguns artefatos oriundos de processos tradicionais;
Descrever sobre a utilização de ferramentas e tecnologias no desenvolvimento;
Apresentar a arquitetura adotada no sistema em desenvolvimento.
3
1.3. Metodologia
Inicialmente, foi realizado um estudo do contexto do projeto, das características
relativas ao funcionamento do Centro de Idiomas FUNCERN, e um levantamento de
requisitos para o sistema pretendido de um modo amplo e sem profundidade de
detalhes. Em paralelo a isso foram estudados os temas enfatizados neste trabalho,
processos de software ágeis e tecnologias da plataforma JEE, e também alguns temas
complementares ou suplementares a eles, para que pudessem ser aplicados ao
desenvolvimento do projeto Soft Educ GCI.
Após isto, iniciou-se a fase do desenvolvimento do projeto, baseado no ciclo do
Scrum e em algumas práticas XP (essas metodologias de desenvolvimento de software
estão descritas na sub-sessão 2.1.3 deste trabalho, e a forma como são aplicadas ao
projeto é explicada na sessão 3.2).
Então, para concluir o trabalho, foi produzido o presente documento, constituído
pelos principais aspectos referentes aos estudos realizados e à aplicação do
conhecimento obtido no desenvolvimento do trabalho.
1.4. Estrutura
Além deste capitulo introdutório, este TCC contém mais três capítulos, que
estruturam o conteúdo conforme explicado a seguir. O capitulo 2 descreve os
resultados dos estudos sobre processos de software, com foco em metodologias ágeis;
e sobre as tecnologias da plataforma JEE ou complementares. O capítulo 3 apresenta
o estudo de caso que constitui o foco deste trabalho, dissertando sobre a aplicação de
um processo de software, de técnicas, tecnologias e ferramentas no desenvolvimento
do sistema Soft Educ GCI. Por fim, O capítulo 4 expõe as conclusões em relação ao
trabalho, indicando a medida em que os resultados apresentados foram positivos ou
não e estabelecendo uma previsão para os possíveis rumos quanto a continuidade do
trabalho.
4
2. FUNDAMENTAÇÃO TEÓRICA
Para melhor compreensão do estudo de caso que compreende o foco deste
trabalho, faz-se necessário o conhecimento de alguns conceitos e idéias as quais
fundamentam os aspectos abordados no capítulo 3, sobre o desenvolvimento do
projeto em questão. Sendo assim, este segundo capítulo objetiva explicar, de forma
sucinta, alguns fundamentos centrais envolvidos na construção do Soft Educ GCI. Para
tanto, subdividir-se-á em duas seções, os quais relatarão, consecutivamente, a respeito
de: 1) Processos de desenvolvimento de software, com foco em metodologias ágeis; e
2) Tecnologias da plataforma Java para desenvolvimento de aplicações coorporativas
(JEE).
2.1. Metodologias Ágeis em Processos de Software.
Desenvolver um software consiste fundamentalmente em transformar requisitos
dos clientes ou usuários em uma solução computacional adequada para os
requisitantes. Em geral, a demanda de software surge: da busca por resolver
problemas do dia a dia, seja no âmbito pessoal ou organizacional; da intenção de
tornar mais prática e eficiente a execução de alguma(s) atividade(s) em um dado
contexto. Entretanto, dependendo da dimensão do problema a resolver e dos níveis
dos requisitos estabelecidos, o desenvolvimento de sistemas pode tornar-se uma
atividade bem complexa, envolvendo uma vasta gama de profissionais, e inúmeras
possibilidades de decisões, as quais podem implicar no sucesso ou fracasso em um
projeto.
Mediante a esta complexidade, são necessários meios para se organizar a
criação de produtos de software. A desorganização na produção destes desencadeia
problemas como: discrepância em relação aos requisitos do usuário; ocorrência
demasiada de erros; excesso de gastos em relação orçamento estimado; atraso
quantos aos prazos estabelecidos; criação de produtos de difícil manutenção; entre
outros. Tais problemas ficaram bem evidentes na indústria de software na década de
1960, quando foi evidenciada a crise do software. Para tentar solucioná-los, houve, e
ainda há um esforço no intuito de gerar processos e metodologias apropriadas para
promoção do desenvolvimento de software de qualidade, apropriados para solucionar
os problemas do usuário, respeitando prazos e custos estabelecidos.
5
2.1.1. Processo de Software
“Define-se processo de software como o conjunto de tarefas de Engenharia de
Software necessárias para transformar os requisitos dos usuários em software”
[Humphrey apud Oliveira 2007 apud Portela 2009]. Trata-se da aplicação de uma
metodologia de trabalho para coordenar as ações de uma equipe de desenvolvimento,
de forma que cada membro entenda seu papel dentro do grupo, bem como as
atividades que deve executar. Isso, no intuito de manter a harmonia, a sincronia e a
estabilidade entre os trabalhos realizados por cada um, a fim de que a equipe alcance
os resultados esperados de forma eficiente e eficaz.
Todavia, nenhum processo de software é apropriado para ser aplicado em todo e
qualquer projeto. Cada projeto tem seu contexto, suas peculiaridades, características
próprias. Isso significa que um mesmo processo aplicado a dois projetos diferentes
pode ser determinante para o grande sucesso em um e para o extremo fracasso em
outro.
Não existe um processo de software que possa ser genericamente aplicado a todos os projetos, visto que nenhum projeto é idêntico ao outro. Variações nas políticas e procedimentos organizacionais, métodos e estratégias de aquisição, tamanho e complexidade do projeto, requisitos e métodos de desenvolvimento do sistema, equipe (pessoas), entre outros fatores, influenciam na forma como um produto de software é adquirido, desenvolvido, operado e mantido. [ISO/IEC apud Oliveira 2007 apud Portela 2009]
2.1.1.1. Conceitos Fundamentais Inerentes a Processos de Software
Para ajudar a esclarecer as idéias a respeito da composição de um processo de
software é conveniente observar-se também alguns conceitos intimamente associados,
tais como: atividades previstas, artefatos consumidos e produzidos, procedimentos
adotados, recursos empregados, paradigma e tecnologia aplicados, e modelo de ciclo
de vida utilizado. Abaixo, a explicação sobre alguns dos itens mencionados, segundo
[Oliveira 2007 apud Portela 2009]:
Atividades: São as tarefas ou trabalhos a serem realizados. A realização de uma atividade pode adotar um procedimento, requer recursos e geralmente utiliza ou gera artefatos. Pode-se, ainda, decompô-la em sub-atividades. Além disso, atividades podem depender da finalização de outras atividades, denominadas pré-atividades. As atividades podem ser classificadas em: atividades de gerência, atividades de construção, atividades de suporte e manutenção e atividades de avaliação da 19 qualidade. Como exemplo de atividade realizada no projeto de software pode-se citar “Especificar os Requisitos”;
6
Artefatos: São produtos de software gerados ou consumidos durante a execução das atividades. Os artefatos podem ser classificados em: artefatos de código, componentes de software, documentos, diagramas, modelos, etc. Para a atividade citada no exemplo anterior, pode-se ter como artefato consumido o “Relatório de Entrevista com o Usuário” e como artefato gerado o documento “Especificação dos Requisitos”; Procedimentos: São condutas bem estabelecidas e ordenadas para a realização de atividades do processo. Quanto à sua natureza, procedimentos podem ser classificados em: métodos, técnicas e diretrizes. Seguindo o exemplo anterior, para executar a atividade definida pode-se definir um procedimento que faça uso da UML – Unified Modelling Language para a definição de cenários das necessidades do usuário; Recursos: Qualquer fator necessário à execução de uma atividade, mas que não seja um insumo para a atividade. Os recursos podem ser classificados em: recursos de hardware, recursos de software e recursos humanos. Finalizando a caracterização do exemplo anterior, pode-se usar como recursos humanos o “Analista de Sistemas”, o qual poderá ter um equipamento de “PC” para desempenhar suas tarefas, que tenha instalado uma ferramenta para modelagem de projetos de software que automatize o procedimento UML
Também é importante ressaltar que existem algumas atividades comuns a qualquer
processo, conforme indicado em [Sommerville 2003 apud Soares 2004]:
Especificação de Software: definição das funcionalidades (requisitos) e das restrições do software. Geralmente é uma fase em que o desenvolvedor conversa com o cliente para definir as características do novo software. Projeto e Implementação de Software: o software é produzido de acordo com as especificações. Nesta fase são propostos modelos através de diagramas, e estes modelos são implementados em alguma linguagem de programação. Validação de Software: o software é validado para garantir que todas as funcionalidades especificadas foram implementadas. Evolução de Software: o software precisa evoluir para continuar sendo útil ao cliente.
2.1.1.2. Tipos de Processos de Software
Existem vários processos de softwares definidos na literatura da Engenharia de
Software, os quais podem ser classificados essencialmente em dois grupos: os
processos tradicionais e os processos ágeis.
Processos tradicionais, também conhecidos como processos pesados, valorizam
a idéia de que, na fase inicial do projeto, a equipe de desenvolvimento deve elucidar e
documentar todos os requisitos do sistema, para que, ao longo do processo, estes
requisitos sejam administrados a partir de um planejamento rigoroso, estabelecido
antes do início das atividades de projeto e implementação do software. A
7
documentação é considerada um fator de grande importância durante a execução de
processos nessa linha.
A especificação de requisitos é considerada uma etapa fundamental onde todas as necessidades do cliente devem ser definidas e documentadas. Para cada um destes requisitos, devem ser gerados outros documentos, o que torna o processo de análise e projeto bastante demorado e de difícil manutenção caso surja um novo requisito ou alguma especificação seja alterada. Pode-se, ainda, caracterizar que estes tipos de processo possuem uma abordagem voltada para o planejamento detalhado e uso artefatos como insumos de uma fase para a seguinte. [Portela 2009]
O exemplo que representa bem a essência das metodologias tradicionais é o
modelo de desenvolvimento de software em cascata, no qual uma sequência rígida de
etapas deve ser seguida durante o processo: especificação de requisitos, projeto,
implementação, teste, implantação e manutenção. Ao final de cada etapa os artefatos
produzidos precisam ser aprovados para que a etapa seguinte possa ter início.
Figura 1. Esquema de representação do modelo de desenvolvimento de software em cascata. Fonte: http://diegoduarte88.wordpress.com/modelo-de-desenvolvimento-de-software-cascata/ em 12/06/2011
Por outro lado, têm-se os processos baseados em metodologias ágeis, também
chamados de processos leves, os quais valorizam principalmente a capacidade de
adaptar-se a mudanças de requisitos no software e a eficiência na produção. O tópico
seguinte deste trabalho abordará com mais profundidade as características deste tipo
de processos.
8
2.1.2. Metodologias Ágeis
Os modelos tradicionais de desenvolvimento de software foram adotados em
grande escala pela indústria de software a partir da década de 1970. Porém, em
meados da década de 1990, mediante ao contexto de um ambiente organizacional
cada vez mais dinâmico e instável, e de problemas cada vez maiores, quanto à
extrapolação de orçamentos, atrasos nas entregas, bugs e insatisfação de clientes,
apresentados em projetos aplicadores de processos tradicionais, integrantes da
comunidade de software começaram a questionar tais processos, julgando-os
impraticáveis em algumas situações. Dessa forma, especialistas passaram a buscar
alternativas para tornar a produção de software mais eficiente e eficaz, criando
métodos próprios para isso.
O agrupamento desses novos métodos e dos ideais que os embasavam
começaram a construir o conceito de metodologias ágeis. Esse conceito lançava a
idéia de não permitir que a rigorosidade dos processos de software bloqueasse o
avanço significativo na produção e as possibilidades de adaptação a mudanças. A idéia
de agilidade não se fazia contrária à documentação, mas sim à documentação em
excesso, aos documentos que pouco ou nada agregavam ao processo de produção e
só deixavam o processo mais pesado.
Diante disso, o novo enfoque para o desenvolvimento de software seria baseado
em flexibilidade, habilidades de comunicação, capacidade de resposta a mudanças e
de adaptação a situações adversas, buscando oferecer produtos e serviços de valor ao
mercado em um curto período de tempo, no contexto de um turbulento ambiente de
negócios [Highsmith 2004 apud Portela 2009].
Para complementar, vale enfatizar que as propostas indicavam a necessidade
de balancear flexibilidade, estrutura e estabilidade, pois a ausência de um destes dois
últimos fatores pode levar ao caos, mas, por outro lado, a estrutura em excesso gera
rigidez [Highsmith 2004 apud Portela 2009], o que pode se tornar um gargalo em um
projeto.
2.1.2.1. Manifesto Ágil
Para discutir as novas idéias e abordagens que surgiram em resposta as
limitações dos processos tradicionais para desenvolvimento de software, criadores e
representantes de vários métodos ágeis se reunirão nos Estados Unidos, no ano de
2001. Como resultado deste encontro, surgiu a Aliança Ágil e foi publicado um
9
documento que oficializava e sintetizava os novos ideais estabelecidos pelo grupo, o
Manifesto para Desenvolvimento Ágil de Software, mais conhecido simplesmente como
Manifesto Ágil.
Nesse documento, alguns valores foram colocados em detrimento de outros:
Indivíduos e interação entre eles mais que processos e ferramentas; Software em
funcionamento mais que documentação abrangente; Colaboração com o cliente
mais que negociação de contratos; Responder a mudanças mais que seguir um plano
[Manifesto Ágil 2001].
Expôs-se também que os itens mais a esquerda tinham valor significativo, porém
que eram menos essenciais que os itens mais a direita.
No encontro, os participantes demonstraram-se preocupados em deixar clara a
importância da metodologia, do planejamento e da documentação. Entretanto,
defenderam-se os seguintes pontos de vista em relação a estes fatores: a metodologia
teria que contribuir para a eficiência e eficácia, e nunca ao contrário; o planejamento
deveria ser refeito ciclicamente, tendo em vista que, em um ambiente de negócios
turbulento, o planejamento e a previsibilidade em longo prazo são bastante limitados; a
documentação não é um fator primordial e indispensável por si só, mas só é necessária
na medida em que agregar valor ao processo de desenvolvimento ou ao produto.
Princípios base do manifesto ágil Nós seguimos os seguintes princípios:
Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas.
Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
Software funcional é a medida primária de progresso.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
10
Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
[Manifesto Ágil 2001]
2.1.3. Características das Principais Metodologias Ágeis: Scrum e XP
Os métodos ágeis Scrum e Extreme Programming (XP) são, atualmente, os mais
conhecidos e utilizados na comunidade de desenvolvimento de software. Ambos estão
calcados nos princípios estabelecidos no Manifesto Ágil, valorizando fatores como
aproximação entre clientes e desenvolvedores, entregas frequentes de pequenos
incrementos no software, e melhoria continua do processo de desenvolvimento da
equipe. A seguir cada um destes processos é analisado de forma resumida.
2.1.3.1. Scrum
O Scrum é uma metodologia de desenvolvimento de software bastante aberta e
flexível, tornando possível e indicado adaptar seu uso de acordo com o contexto do
projeto que deseja utilizá-lo. Ele procura fornecer meios de tornar a produção eficiente
mesmo mediante à imprevisibilidade e às mudanças nos requisitos. O Scrum não
determina tudo o que se deve fazer nem as técnicas a serem adotadas nos diversos
momentos do desenvolvimento, mas oferece um conjunto práticas as quais permitem
que a equipe: se situe em relação ao estado das atividades do projeto; tenha
consciência dos seus objetivos, metas e nível de produtividade; possa fazer estimativas
próximas da realidade; e tome as decisões adequadas e coerentes com os objetivos e
metas estabelecidas. Assim, esta metodologia caracteriza-se como um framework.
Por ser um framework, irá servir como um guia de boas práticas para atingir o sucesso. Entretanto, as decisões de quando e como usá-lo, quais táticas e estratégias seguir para obter produtividade e realizar as entregas ficam por conta de quem estiver o aplicando. O conhecimento das suas práticas permite a aplicação destas de forma variada e este é um dos aspectos positivos do Scrum, a adaptabilidade. [Portela 2009]
Neste framework, há a definição clara de três papéis dentro da equipe ou time
de desenvolvimento. O Product Owner é o responsável por representar os interesses
do cliente junto ao time de desenvolvedores, em relação a requisitos, prazos,
orçamento, avaliação do produto, etc. O Scrum Master é o responsável pelas funções
de gerência e de resolução de conflitos internos ao time. E os Desenvolvedores são os
11
responsáveis pelas decisões técnicas, por estimar tempo necessário para atividades,
por projetar e implementar funcionalidades do sistema.
Em síntese, e de um modo genérico, o Scrum funciona da seguinte forma:
inicialmente é elaborado o Backlog do Produto (Product Backlog), que consiste em um
plano com as funcionalidades (User Stories ou Estórias do Usuário) e características
requeridas pelo cliente no começo do projeto. Este artefato será administrado durante o
todo o projeto, sendo frequentemente atualizado. Depois de listadas as estórias do
usuário, o esforço para realizá-las é estimado pelos desenvolvedores, que, junto com o
product owner, agrupam as estórias em vários Sprints. Um Sprint consiste em uma
iteração que deve durar entre 2 e 4 semanas, de modo que, ao final deste intervalo de
tempo, tenha-se uma versão usável do produto para entregar ao Product Owner.
Antes de iniciar cada sprint, há uma reunião de planejamento (Scrum Planning
Meeting), a qual envolve todo o time, com a finalidade de definir, de acordo com as
prioridades do cliente e do contexto atual da equipe, quais das funcionalidades e
características do Backlog do Produto devem ser implementadas durante a iteração,
construindo assim o Sprint Backlog. Após o product owner expressar ao restante da
equipe suas prioridades, scrum master e desenvolvedores dividem as estórias em
atividades necessárias e estimam o esforço para cumpri-las, adequando a composição
do Sprint Backlog de acordo com o esforço previsto para o sprint.
Durante o sprint, o scrum master e desenvolvedores assumem
espontaneamente e executam as atividades previstas no plano. Há a realização de
reuniões diárias (Scrum Daily Meeting), nas quais cada desenvolvedor e o scrum
master devem se pronunciar rapidamente para o restante da equipe, procurando,
essencialmente, informar o que fez no último dia, o que pretende fazer no dia vindouro
e quais o impedimentos encontrados na tarefa que está executando. As reuniões
devem ser rápidas, entre 10 e 20 minutos, e recomenda-se que sejam realizadas com
os participantes de pé. Para medir a produtividade do time no decorrer do sprint é
usado um gráfico chamado Sprint Burndown, que indica o progresso da equipe, de
acordo com o esforço estimado para as tarefas cumpridas a cada dia.
Ao final de cada sprint deve ser realizada uma reunião de revisão de sprint
(Sprint Review), na qual a equipe demonstra ao product owner o que foi produzido e
todos avaliam o trabalho, comparando o resultado obtido ao esperado. Após isso,
deve-se realizar uma reunião de retrospectiva de sprint (Sprint Retrospective), visando
identificar os pontos positivos e negativos, o que deve ser mantido e o que não deve se
12
repetir, além de absolver lições e aprendizado, com o objetivo de melhorar o processo
e o produto nos sprints seguintes.
Figura 2. Representação do ciclo do Scrum. Fonte: http://tasafo.wordpress.com/tag/scrum/ em 12/06/2011
2.1.3.2. Extreme Programming (XP)
O XP, que foi criado no final da década de 1990, trata-se de “uma metodologia
ágil para equipes pequenas e médias que desenvolvem software baseado em
requisitos vagos e que se modificam rapidamente” [Beck 1999 apud Soares 2004]. Este
método tem o objetivo de promover a produção de software de forma rápida e em
ciclos de desenvolvimento cada vez mais curtos. Dentre os ideais, estão: produzir
primeiro o que agrega mais valor ao produto, adaptar-se ao inesperado, priorizar as
atividades de codificação (programming). Para tanto, baseia-se em 4 valores
fundamentais e propõe a aplicação 12 práticas bem estabelecidas na condução do
processo.
Os valores são: feedback, comunicação, simplicidade e coragem [Beck 1999
apud Soares 2004].
O feedback consiste na busca constante por respostas do cliente em relação ao
que foi produzido, de modo que ele observe e utilize, o quanto antes, um número
13
mínimo de funcionalidades desenvolvidas da forma mais simples possível, para, então,
indicar o que, segundo sua óptica, necessita ser feito a mais em relação às referidas
funcionalidades. Dessa forma, o cliente guiará o desenvolvimento de acordo com a
evolução da formação de sua visão sobre o produto, evitando implementações
desnecessárias e maiores custos para ajustes.
A comunicação mais eficiente possível é um objetivo prioritário para equipes XP,
para que a equipe possa compartilhar conhecimento, se ajudar mutuamente dentro do
processo, etc. A intenção é usar, ao máximo, os melhores canais comunicativos
disponíveis, de maneira que a comunicação pessoal é preferível em relação à
comunicação por telefone, a qual é preferível em relação à comunicação por e-mail. A
comunicação é estimulada tanto interiormente a equipe, quanto entre membros da
equipe de desenvolvimento e clientes.
A simplicidade faz-se no sentido de tentar descomplicar as coisas, para que,
inicialmente seja desenvolvido algo simples e funcional, a ser melhorado
posteriormente, a partir do feedback, e durante as refatorações (Refectoring). Busca-se
implementar somente requisitos atuais, sem tentar prever requisitos importantes no
futuro.
A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis. [Soares 2004]
A coragem é fator determinante para membros de times XP, uma vez que a
metodologia propõe, através de seus valores e práticas, uma quebra de paradigmas
relacionados às abordagens tradicionais para desenvolver sistemas.
Abaixo, estão listadas as 12 práticas XP, conforme apresentado em [Dias 2005
apud Portela 2009]:
1. Jogo do Planejamento: no início de cada interação, clientes, gerentes e
programadores se encontram para definir, estimar e priorizar os requerimentos. A idéia é que se elabore um plano aproximado no início do projeto e se faça um refinamento à medida que as necessidades e requisitos se tornem mais conhecidos;
2. Programação em Pares: dois programadores utilizando o mesmo computador escrevem o código;
3. Pequenas Versões: as versões devem ser tão pequenas quanto possível e
trazerem valor para o negócio. Uma versão inicial do software deve ser colocada em produção após um pequeno número de interações e, em seguida, outras versões devem ser disponibilizadas tão logo faça sentido;
14
4. Metáforas: clientes, gerentes e programadores criam metáforas ou
conjunto de metáforas para modelagem do sistema;
5. Projeto Simples: os programadores são estimulados a desenvolver o código do software o mais simples possível;
6. Testes: os programadores devem criar os testes de unidade antes ou
mesmo durante o desenvolvimento do código do sistema. Os clientes, por sua vez, escrevem os testes de aceitação. Ao final de cada iteração a bateria de testes deve ser conduzida;
7. Reegenharia de Software: o código deve ser constantemente melhorado,
sem que a funcionalidade do seja alterada, pela equipe do projeto, o tempo todo;
8. Integração Contínua: os programadores devem integrar os novos códigos
ao software tão rapidamente e com a maior freqüência possível;
9. Propriedade Coletiva do Código: o código do programa deve ser propriedade de toda a equipe e qualquer integrante pode fazer alterações sempre que for necessário;
10. Cliente no Local: o cliente deve trabalhar com a equipe de projeto a todo
momento, respondendo perguntas, realizando testes de aceitação e assegurando que o desenvolvimento do software esteja sendo feito a contento;
11. Semana de 40 horas: como trabalhar por longos períodos reduz o
desempenho, o conteúdo de cada iteração deve ser planejado de forma a não haver necessidade de realização de horas extras;
12. Padrão de Codificação: no início do projeto deve ser criado um padrão de
codificação, simples e aceito por toda a equipe, que deverá ser seguido de forma a padronizar e a auxiliar a condução do trabalho
2.2. Tecnologias Java Enterprise Edition (JEE).
É cada vez mais vigente a necessidade de se construir aplicações distribuídas
transacionais e portáveis com menos tempo e recursos, utilizando-se de vantagens,
como confiabilidade, segurança e velocidade, oferecidas por tecnologias para
programação do lado servidor. É sob esta perspectiva que a plataforma Java Enterprise
Edition coloca-se com o objetivo de fornecer aos desenvolvedores um conjunto
avançado de APIs (Application Programming Interfaces ou Interfaces para
Programação de Aplicações) para reduzir a complexidade, melhorar o desempenho e
reduzir o tempo de desenvolvimento de aplicações.
Esta plataforma define uma arquitetura baseada em um modelo distribuído
multicamadas para implementação de serviços em aplicações corporativas, de modo a
proporcionar vantagens, como escalabilidade, acessibilidade e gerenciamento
15
necessário. A aplicação é estruturada por meio de componentes que podem se situar
em camadas distintas, de acordo com a função que exercem. Estas camadas
representam ambientes de execução diferentes, quais sejam a máquina cliente, o
container Web o container EJB, estes dois último localizados no servidor JEE.
Figura 3. Arquitetura de Componentes JEE. fonte: The Java EE 6 Tutorial
As próximas subseções deste trabalho abordaram mais detalhadamente algumas
das tecnologias usadas no projeto Soft Educ GCI que compõem esta plataforma de
desenvolvimento.
2.2.1. Java Server Faces (JSF)
Várias tecnologias surgiram com a finalidade de evoluir o modelo de programação
para aplicações web, tentando abstrair, simplificar e potencializar a implementação
destas. Na plataforma Java, a especificação Java Servlet foi a tecnologia precursora.
Em seguida, vieram as páginas JSP, as quais passaram a ser utilizada junto aos
Servlets. No entanto, os seguintes problemas, decorrentes do uso destas tecnologias,
16
tornaram-se cada vez mais evidentes: mistura entre códigos de apresentação (Interface
Gráfica do Usuário) e de lógica de negócio, dificuldades na manutenção das
aplicações, baixa produtividade no desenvolvimento, entre outros.
Mediante esse contexto, o JSF foi apresentado como “um framework de
componentes do lado servidor para a construção de aplicações web baseadas em
tecnologias Java” [The Java EE 6 Tutorial]. Constituído sobre o padrão arquitetural
MVC (Model-View-Controller ou Modelo-Visão-Controlador), e caracterizando-se por
uma proposta de programação baseada em eventos, de forma similar ao que acontece
com o uso da API Java Swing para desenvolvimento de interfaces gráficas em
aplicações desktop, o JSF busca abstrair fatores relacionados ao modelo de
desenvolvimento proveniente do uso das tecnologias anteriores (JSP e Servlets),
elevando o nível da programação, tornando mais fácil e prático a produção de
aplicações web.
Essencialmente, este framework fornece uma API para: representação de
componentes e gerência do estado deles, manipulação de eventos, conversão de
dados, validação no lado servidor, definição de navegação entre páginas,
internacionalização da aplicação e extensibilidade dos componentes [The Java EE 6
Tutorial].
Para a camada de apresentação, o JSF oferece um conjunto de tags XML para
representação de componentes em páginas web. Estas tags possibilitam a associação
de componentes das páginas com objetos do lado servidor através do uso da
linguagem de expressão (Expression Language ou, simplesmente, EL), e estão
disponíveis por meio das tag libraries, que são bibliotecas de tags a serem declaradas
nas páginas.
Com a finalidade de possibilitar uma compreensão mais prática do framework, na
sua versão 1.2, que foi a versão usada no desenvolvimento do projeto sobre o qual se
refere este trabalho, as explicações serão feitas com base em trechos de código de
uma aplicação JSF simples. A Figura a seguir apresenta um trecho de código de uma
página XHTML que usa alguns componentes JSF:
17
Figura 4. Uso de componentes JSF
A figura 4 exibe a codificação de uma página simples, com alguns componentes
JSF. Nas linhas 2 e 3, ocorre a declaração das duas tag libraries padrão do JSF, com
seus respectivos prefixos, pelos quais serão referenciadas ao longo do código, e URIs.
A partir disso, os componentes integrantes desses pacotes de tags poderão ser
usados.
Da linha 10 a linha 15, exemplifica-se o uso de alguns componentes da tag
library HTML do JSF. Na linha 12, demonstra-se o uso de um componente que associa
uma entrada de texto do usuário a um objeto do modelo que está no lado servidor
(backing bean), através de EL. Com a expressão “#{exemploMB.nome}”, o valor
inserido no campo de texto deve ser atribuído a propriedade “nome” do managed bean
declarado com o nome de “exemploMB” durante a fase de atualização dos valores do
modelo do ciclo de vida do JSF.
Os managed beans são classes Java que exercem a função de controladores
em uma aplicação JSF. Eles contêm os objetos do domínio que serão ligados aos
componentes JSF, e também os manipuladores de ações (Action Handlers), que são
métodos invocados a partir de um evento, como o clique do usuário em um botão.
Voltando ao exemplo, na linha 13, observa-se um componente que representa
um botão em uma página HTML. Este botão, quando clicado, invocará o método
“manipularEvento()” do managed bean “exemploMB”, conforme indicado na expressão
01 <f:view xmlns="http://www.w3.org/1999/xhtml"
02 xmlns:f="http://java.sun.com/jsf/core"
03 xmlns:h="http://java.sun.com/jsf/html"
04 contentType="text/html">
05 <html>
06 <head>
07 <title>Exemplo</title>
08 </head>
09 <body>
10 <h:form>
11 <h:outputLabel value="seu nome: " />
12 <h:inputText value="#{exemploMB.nome}" />
13 <h:commandButton value="Enviar"
14 action="#{exemploMB.manipularEvento}" />
15 </h:form>
16 </body>
17 </html>
16 </f:view>
18
“#{exemploMB.manipularEvento}”, declarada como valor no atributo “action” do
componente.
O managed bean “exemploMB” pode ser implementado como demonstrado na
classe conforme a figura 5:
Figura 5. Exemplo da implementação de um managed bean
A classe apresentada contém as propriedades “nome” e “frase”, as quais podem
ser acessadas pelos componentes JSF presentes em uma página web por meio dos
métodos get, para recuperar o valor da propriedade, e set, para atribuir um novo valor a
ela. Com isso, percebe-se que, no exemplo discutido, um componente de uma página
JSF pode recuperar o valor da propriedade “nome” e também alterar valor dela, pois o
atributo “nome” da classe “ExemploMB” tem os métodos get e set correspondente. Já a
propriedade “frase” pode ter seu valor recuperado, mas não alterado, pois o atributo
“frase” só tem o método get, mas não o set.
O método “public String manipularEvento()” é um action handler, o qual pode ser
invocado após lançamento de um evento por um componente de uma página JSF. Ele
faz um processamento com os valores dos atributos do managed bean e retorna uma
String, que servirá para indicar a página que deve ser apresentada após o
processamento do método, conforme as regras de navegação configuradas no arquivo
“faces-config.xml”.
01 public class ExemploMB {
02
03 private String nome;
04 private String frase;
05
06 public String getNome() {
07 return nome;
08 }
09 public void setNome(String nome) {
10 this.nome = nome;
11 }
12 public String getFrase() {
13 return frase;
14 }
15
16 public String manipularEvento() {
17 frase = "Oi, meu nome é " + nome + ".";
18 return "pagina2";
19 }
20 }
19
Este arquivo, o “faces-config.xml”, é o principal arquivo de configuração de uma
aplicação JSF. É lá onde são declarados os managed beans e as regras de
navegação, conforme demonstrado na figura abaixo:
Figura 6. Declaração de managed bean e definição de regra de navegação no faces-config.xml
Entre as linha 06 e 10, na figura 03, é declarado um managed bean, com a
indicação do nome pelo qual será referenciado na aplicação, do nome completo da
classe que onde está sua implementação e do seu escopo, que pode ser de sessão
(session), requisição (request) ou aplicação (application). Da linha 12 até a 18 tem-se a
declaração de uma regra de navegação, indicando que quando uma requisição partir
da view com o endereço “/pagina1.xhtml” e o action handler responsável por tratar a
requisição retornar a String “pagina2”, deve-se exibir a view com identificada pelo
endereço “/pagina2.xhtml”. Além de servir para declaração de managed beans e de
regras de navegação, o “faces-confi.xml” também é usado para configurar
componentes customizados, tais como conversores e validadores.
Outro elemento importante em uma aplicação JSF é o arquivo descritor de
implantação “web.xml”. É lá que é declarado o Servlet responsável por receber e
processar todas as requisições recebidas do cliente, a partir de componentes JSF, o
Faces Servlet.
01 <?xml version="1.0" encoding="UTF-8"?>
02 <!DOCTYPE faces-config PUBLIC
03 "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
04 "http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
05 <faces-config>
06 <managed-bean>
07 <managed-bean-name>exemploMB</managed-bean-name>
08 <managed-bean-class>pacote.exemplo.ExemploMB</managed-bean-class>
09 <managed-bean-scope>session</managed-bean-scope>
10 </managed-bean>
11
12 <navigation-rule>
13 <from-view-id>/pagina1.xhtml</from-view-id>
14 <navigation-case>
15 <from-outcome>pagina2</from-outcome>
16 <to-view-id>/pagina2.xhtml</to-view-id>
17 </navigation-case>
18 </navigation-rule>
19 </faces-config>
20
Figura 7. Delclaração do Faces Servlet no descritor de implantação “web.xml”
2.2.1.1. RichFaces
O RichFaces é um projeto de código aberto desenvolvido pela JBoss para
auxiliar na construção de aplicações de internet ricas com o JSF. Consiste em um
conjunto de componentes avançados de interface de usuário com o intuito de
possibilitar uma fácil integração do potencial da tecnologia AJAX a aplicações JSF, sem
a necessidade de recorrer a JavaScript para essa finalidade. Além disso, também
propõe facilitar o trabalho de padronizar as interfaces de uma aplicação JSF, através
do suporte a Skins.
Este framework disponibiliza aos desenvolvedores duas tag libraries, a Core
Ajax, geralmente referenciada pelo prefixo “a4j”, que contém componentes para
configurar requisições AJAX nas páginas; e a UI, comumente referenciada pelo prefixo
“rich”, que dispõe de recursos para adicionar características de interfaces ricas a
aplicações JSF. Pode-se utilizar o RichFaces em aplicações JSF sem maiores
dificuldades a partir da importação de algumas bibliotecas para o projeto e da
realização de algumas configurações no arquivo descritor de implantação da aplicação,
o “web.xml”.
2.2.1.2. Facelets
Nas primeiras versões do JSF, 1.1 e 1.2, a tecnologia padrão para definição da
camada de view era o JSP. Porém o Facelets surgiu como uma forte alternativa ao
padrão estabelecido, de modo a proporcionar bastantes vantagens quando usado junto
ao JSF. A prova do reconhecimento dessas vantagens foi a adoção desta tecnologia
como padrão para definição da camada de visão do JSF na versão 2.0.
1 <servlet>
2 <servlet-name>Faces Servlet</servlet-name>
3 <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
4 <load-on-startup>1</load-on-startup>
5 </servlet>
6 <servlet-mapping>
7 <servlet-name>Faces Servlet</servlet-name>
8 <url-pattern>/faces/*</url-pattern>
9 </servlet-mapping>
21
O Facelets é uma linguagem de declarativa desenvolvida e apropriada para a
construção da camada de visão do JSF. Entre as principais características
relacionadas a esta tecnologia estão as seguintes: uso do XHTML como formato dos
arquivos referentes às páginas web criadas; possibilidade de elaborar, de forma
prática, templates para componentes e páginas; possibilidade de criar e reusar
componentes compostos por outros; disponibilização de uma tag library própria para
uso complementar aos componentes JSF; amplo suporte à linguagem de expressão e
ao uso de componentes AJAX, adaptação; ampla adaptabilidade ao ciclo de vida JSF;
entre outros.
Dentre as vantagens do uso dessa tecnologia, pode-se citar a capacidade de
promover o reuso de código através de templates e da composição de componentes; o
menor tempo necessário para a compilação e melhor performance na renderização de
componentes em relação ao JSP; a independência em relação ao container web; a
validação de EL em tempo de compilação; a grande precisão no apontamento de erros,
de modo a facilitar a depuração. Em suma, o uso do Facelets reduz o tempo e o
esforço que precisa ser gasto no desenvolvimento e implantação [The Java EE 6
Tutorial].
2.2.2. Enterprise JavaBeans (EJB)
A tecnologia EJB propõe um ambiente diferenciado para a execução de
componentes de negócio de aplicações corporativas Java. Este ambiente é chamado
de container EJB, que é uma das partes dos servidores de aplicações corporativas em
conformidade com as especificações JEE, tais como o Jboss Application Server e o
GlassFish Server. Ele tem o papel de assumir a responsabilidade por prover
importantes serviços para os Enterprise beans – como são denominados os
componentes implementados com a tecnologia –, tais como: gerenciamento de
transações, controle de instâncias e segurança. Isso faz com que a implementação
desses serviços seja abstraída para os desenvolvedores das aplicações, de modo que
estes possam se concentrar mais em resolver problemas decorrentes da lógica de
negócio.
Um Enterprise Bean pode ser classificado em dois tipos principais, Session Bean
(Bean de Sessão) ou Message-drive Bean (Bean Orientado a Mensagem).
22
2.2.2.1. Bean de Sessão
Os beans de sessão são objetos de classes implantadas no servidor que
realizam tarefas a partir de solicitações de clientes. Eles encapsulam a lógica de
negócio de uma aplicação, se responsabilizando pela execução de processos
complexos. Podem ser invocados programaticamente através de chamadas aos
métodos de suas interfaces, que podem ser locais, remotas ou web service, e podem
ser do tipo Stateful, Stateless, ou Singleton.
Um bean de sessão stateful atende às requisições de apenas um cliente,
mantendo o estado conversacional com ele, de forma que os valores de seus atributos
são mantidos entre as requisições realizadas entre a sua instanciação, provocada pela
primeira requisição, até a desconexão do cliente. Um stateless, por sua vez, é
compartilhado entre vários clientes e não mantém estado conversacional com nenhum,
de modo que, ao final da execução de cada método, os estado de seus atributos não
são mantidos.
Exceto durante a invocação de método, todas as instâncias de um bean stateless são equivalentes, permitindo que o container EJB atribua uma instância para qualquer cliente. Devido ao fato de eles poderem suportar vários clientes, beans de sessão pode oferecer uma melhor escalabilidade para aplicações que requerem um grande número de clientes [The Java EE 6 Tutorial]
Um bean de sessão do tipo singleton só tem uma instância para toda a
aplicação, a qual é a responsável por atender as requisições de todos os clientes. Este
tipo de bean mantém os estado de suas variáveis entre as requisições feitas para ele.
Beans de sessão singleton são projetados para circunstâncias em que uma instância de bean única é acessada por clientes em condições de concorrência. [The Java EE 6 Tutorial]
Vale também ressaltar que um bean stateless, bem como um singleton podem
implementar um web service, mas um stateful não.
2.2.2.2. Bean Orientado a Mensagem
Os beans orientados a mensagem são componentes que possibilitam o
processamento de mensagens de forma assíncrona por aplicações JEE. Eles
geralmente atuam como listeners de mensagens de um JMS (Java Messages Service
ou Serviço de Mensagens Java), que são enviadas por clientes. Além de mensagens
23
JMS, este tipo de bean pode também processar mensagens de outros tipos de MOM
(Message-Oriented Middleware).
Diferentemente do que ocorre com os beans de sessão, os componentes
clientes não acessam os métodos de beans de mensagem diretamente, através de
interfaces. Ao invés disso, enviam mensagens por meio de um middleware, cada uma
destinada ao bean que deve processá-la. Quando a mensagem chega, o container
invoca o método onMessage do bean destinatário, que deve processá-la de acordo
com as regras de negócio da aplicação, podendo, para isso, chamar métodos
auxiliares, invocar um bean de sessão ou armazená-la no banco de dados.
2.2.3. Java Persistence API (JPA)
É fato que o uso de bancos de dados relacionais é amplamente difundido em
grande parte das aplicações de software desenvolvidas, assim como o paradigma da
programação orientada a objetos (POO) é uma tendência largamente utilizada no
desenvolvimento de sistemas. No entanto, o paradigma relacional e o orientado a
objetos possuem características e operam sobre conceitos bastante distintos, de forma
a tornar complexa as operações da POO realizadas sobre dados armazenados em
estruturas relacionais.
Considerando esse contexto, a JPA constitui-se em uma alternativa para abstrair
essa complexidade e facilitar a maneira de trabalhar com bancos de dados relacionais
dentro da programação orientada a objetos. Segundo a própria documentação oficial
da tecnologia [The Java EE 6 Tutorial], a JPA fornece um mecanismo para
desenvolvedores realizarem um mapeamento objeto-relacional e facilita o
gerenciamento de dados relacionais em aplicações Java.
O modelo da JPA é simples, elegante, poderoso e flexível, constituindo-se com
base no mapeamento objeto-relacional realizado para as entidades, que são classes
Java simples, representantes dos objetos persistentes do modelo de domínio da
aplicação. Este mapeamento é feito por meio da utilização de metadados, que podem
ser representados através de marcações feitas em arquivos de configuração XML ou
de anotações inseridas no código das entidades JPA.
A atividade de mapear entidades JPA baseia-se na idéia de configuração por
exceção, de modo que o mecanismo de persistência assume valores default para a
maioria das situações. Dessa forma, considerando o uso de valores padrão
estabelecidos pela API, são necessárias apenas declarações mínimas de metadados,
24
sendo preciso declarar configurações adicionais apenas se houver a necessidade de
alterar os valores default. A seguir serão indicadas algumas anotações, as quais se
encontram definidas no pacote javax.persistence, utilizadas para realizar configurações
de mapeamento básicas em entidades JPA.
Duas anotações são essenciais e obrigatórias em uma entidade JPA: @Entity e
@Id. A primeira indica que a classe deve ser entendida como uma entidade a ser
persistida, enquanto a segunda informa qual propriedade da classe deve ser a chave
primária da tabela que representará a entidade no banco de dados. A anotação
@GeneratedValue é usada para indicar que a chave primária deve ser gerada
automaticamente. As anotações @Table e @Column especificam, respectivamente, as
propriedades de uma tabela e de uma coluna no banco de dados, tal como o nome, por
exemplo. A anotação @NotNull informa que os valores de determinada coluna não
podem ser nulos, a @Pattern define um padrão para o valores de uma coluna e a
@Transient define que o valor de determinada propriedade não será persistido. As
anotações que indicam a multiplicidade em um relacionamento entre entidades são:
@OneToOne (relacionamento “um-para-um”), @OneToMany (relacionamento “um-
para-muitos”), @ManyToOne (relacionamento “muitos-para-um”) e @ManyToMany
(relacionamento “muitos-para-muitos”). A seguir, uma figura que exibe um trecho de
código exemplificando o mapeamento de uma entidade do projeto que é objeto de
estudo desse trabalho.
25
Figura 8. Exemplo de mapeamento objeto-relacional de uma entidade com anotações
A gerência do estado de persistência das entidades é feita por meio da utilização
da interface EntityManager. Ela fornece métodos para persistir novas instâncias de
entidades; buscar, mesclar ou remover instâncias de entidades persistidas, verificar se
uma instância está sendo gerenciada pelo contexto de persistência, obter objeto para
realizar transação de banco de dados, etc.
Há também um mecanismo de consultas baseado em objetos, o qual abstrai o
conhecimento a respeito de estruturas relacionais de armazenamento de dados, de
modo que, para colocar na memória entidades persistidas e seus relacionamentos, não
seja necessário conhecer colunas nem chaves estrangeiras de tabelas, por exemplo.
As consultas são expressas em JPQL, uma linguagem de consulta que é derivada de
EJB QL e possui sintaxe parecida com a do SQL, mas que não está vinculada com o
esquema de banco de dados. Essas consultas retornam resultados que são entidades,
proporcionando valiosas abstrações e permitem a consulta através de objetos do
modelo de domínio Java em vez de em tabelas do banco de dados. A figura a seguir
demonstra uma situação de uso de uma consulta JPQL que, quando executada,
retorna uma lista de objetos do domínio. A consulta seleciona somente os objetos
01 @Entity
02 public class Aluno implements Serializable {
03
04 @Id
05 @GeneratedValue(strategy=GenerationType.IDENTITY)
06 private int id;
07 @Column(unique=true)
08 private String numMatricula;
09 private String nomeDoPai;
10 @Column(nullable=false)
11 private String nomeDaMae;
12 @Column(nullable=false)
13 private TipoDeAluno tipoDeAluno;
14 @Transient
15 private boolean matriculado;
16
17 @OneToOne(optional=false)
18 private Pessoa pessoa;
19
20 @OneToMany(mappedBy="aluno")
21 private List<Matricula> matriculas;
22
23 // Métodos gets e sets omitidos nesta imagem
26
persistidos da classe “Matrícula” que tiverem como valor do seu atributo “aluno” um
objeto correspondente ao que é passado como parâmetro para a consulta.
Figura 9. Exemplo de uma consulta com JPQL
O modelo de entidades móveis, que provê a possibilidade de uma entidade se
desacoplar do módulo de persistência, ser transportada via rede e manipulada em
outras aplicações ou máquinas virtuais, para depois retornar e ser re-acoplada ao
contexto de persistência, também é uma importante característica da JPA, levando em
consideração as arquiteturas cliente/servidor aplicações web e distribuídas, de um
modo geral.
Em síntese, conforme posto em [Keith e Schincariol 2006], A Java Persistence API
realmente introduziu uma nova era na persistência integrada padronizada. Ao ser
executado dentro de um container JEE, todos os benefícios de suporte do container e
facilidade de uso superior aplicam-se, mas também pode ser configurado para ser
executado fora do contêiner, em ambientes JSE.
01
02 Query query = em.createQuery("select m from Matricula m where " +
03 "m.aluno=:aluno order by m.data desc");
04
05 query.setParameter("aluno", aluno);
06 List<Matricula> matriculas = query.getResultList();
07
27
3. ESTUDO DE CASO
Neste capítulo serão abordadas questões a respeito do ciclo de desenvolvimento
do projeto Soft Educ GCI, considerando-se os seguintes fatores: 1) o contexto que
motivou a realização do projeto; 2) a organização dos stakeholders em torno de
valores, princípios e práticas próprios de processos de desenvolvimento ágeis; 3) o
escopo definido e os requisitos estabelecidos; 4) as tecnologias e as ferramentas
utilizadas no processo; 5) os mecanismos utilizados para gerir o projeto; 6) a
arquitetura proposta para o sistema, o projeto e implementação de suas
funcionalidades; e 7) os resultados obtidos no trabalho.
3.1. Contextualização do Projeto
Como mencionado na introdução deste trabalho, o projeto Soft Educ GCI consiste
na construção de uma estrutura de software apropriada para auxiliar na execução de
atividades próprias do fluxo de trabalho do Centro de Idiomas FUNCERN. No início do
projeto, entre os meses de setembro e dezembro de 2010, quando o projeto estava
associado a disciplina de PDSC, mencionada na sessão 1.1, a equipe de
desenvolvedores era formada por cinco desenvolvedores. A partir da segunda fase do
desenvolvimento, iniciada em março de 2011, quanto o projeto já não se situava mais
no contexto da disciplina de PDSC, a equipe teve o número de integrantes reduzido
para três.
Nos primeiros contatos entre a coordenação do Centro de Idiomas FUNCERN,
representada pela pessoa do senhor Fernando Ferreira Carneiro Filho, e o grupo de
estudantes, houve, por parte da instituição, demonstração de insatisfação com o
aparato informacional utilizado para auxiliar na execução das atividades próprias de
seu processo organizacional, bem como a expressão de um desejo nítido de evoluir em
relação a esse contexto. Com isso, a representação do grupo de desenvolvedores, o
qual estava envolvido na conjuntura da disciplina mencionada anteriormente, propôs
trabalhar, durante os três meses seguintes, no intuito de criar soluções computacionais
para tentar resolver os gargalos existentes na estrutura informacional da organização.
Durante a fase imediatamente anterior ao início do projeto, quando ocorreram os
diálogos pré-eliminares, a equipe de desenvolvimento colheu e documentou várias e
importantes informações referentes ao processo de negócio da organização e aos
28
softwares utilizados para administrar e manter esse processo. Buscou-se observar,
com uma óptica abrangente, as características dos sistemas, o que era positivo e
negativo em relação ao uso deles, as inconveniências que geravam para a manutenção
do fluxo de trabalho organizacional.
Foi notado que, essencialmente, eram utilizados dois sistemas na instituição. Um
deles, uma aplicação web para sorteio de vagas nas turmas de 1º nível dos cursos
oferecidos. Tal sistema permitia a realização de inscrições via web dos candidatos
interessados pela vagas, e, após período de inscrições, promovia o sorteio das vagas
entre os inscritos. O outro, um sistema cliente/servidor que, no cliente, executava em
ambiente desktop, era utilizado para controle interno da coordenação, dos cursos, das
turmas e dos alunos da organização.
Logo se percebeu que esses sistemas não ofereciam condições de uso
satisfatórias, e que não atendiam devidamente as demandas geradas pelas
necessidades do processo de trabalho na coordenação dos cursos de idiomas. Foram
constatadas nítidas dificuldades para operar e manter os dois sistemas, de modo a
justificar a insatisfação dos usuários.
A seguir, é feita a listagem e a descrição dos problemas encontrados pelo grupo
de desenvolvedores do Soft Educ GCI quanto ao aparato informacional então utilizado
para apoiar as atividades do Centro de Idiomas FUNCERN. Na sequência do conteúdo
desta seção, o sistema que realiza sorteio das vagas para as turmas de 1º nível será
chamado de “sistema I” e o sistema usado para controle interno de cursos, turmas e
alunos será referenciado como “sistema II”.
Falta de integração entre os sistemas utilizados. O sistema I e o sistema II
não estabeleciam nenhuma forma de comunicação entre eles. Os dados
inseridos no sistema I, na inscrição de um candidato para o sorteio, por
exemplo, não eram reaproveitados pelo sistema II durante a realização da
matrícula de um candidato sorteado. Isso gerava uma demanda de trabalho
desnecessária para efetivar matrículas dos candidatos sorteados, pois os dados
deles, que deveriam ser recuperados, eram redigitados pelos funcionários. Tal
situação provocava também maiores tempos de espera das pessoas por
atendimento, deixando insatisfeitos os clientes que procuravam se matricular no
1º nível dos cursos.
29
Dificuldades e falta de autonomia para operar o sistema I. O coordenador da
organização não possuía autonomia para operar diretamente na coordenação
das funções do sistema I. A cada novo semestre, ele tinha que recorrer à
pessoa responsável pelo desenvolvimento do sistema, para que esta pudesse
executar suas funcionalidades: abrir período de inscrições, gerar relatórios de
inscrições, realizar sorteio de vagas, gerar documento com listagem de
sorteados. Essa situação era pouco cômoda e confortável para a organização.
O sistema II não atendia a várias demandas importantes para os usuários.
Foi constatado que o sistema II não oferecia suporte apropriado a vários
procedimentos do fluxo de trabalho na organização. Como exemplos disso,
podem ser enumeradas as seguintes situações: 1) Não possibilitava um controle
específico para as provas de nivelamento realizadas, e os resultados dos alunos
nessas provas não eram registrados; 2) Não possibilitava listar os alunos de
uma turma com seus respectivos contatos (telefones e e-mail), o que dificultava
o trabalho quando havia necessidade de comunicar algo a estes alunos
rapidamente, como no caso do adiamento de uma aula; 3) Não promovia um
tratamento adequado quanto ao número de vagas remanescentes, nas turmas,
para alunos bolsistas e para alunos pagantes, uma vez que o sistema tratava de
modo indiferente estes dois tipos de alunos; 4) O procedimento de matrícula não
permitia o registro da opção de pagamento do cliente de acordo com todas as
formas de pagamento previsíveis na instituição, de modo que, inúmeras vezes,
os dados do pagamento eram registrados de maneira incompatível com a
realidade e recibos de pagamento eram emitidos com dados incorretos, o que
dificultava o controle de pagamentos; 5) Não era disponibilizada, para o usuário,
informações indicando se o aluno havia sido aprovado ou reprovado, ou havia
cancelado a matrícula nas turmas pelas quais passou.
Sistema II apresentava grande número de bugs. Eram vários os erros
observados no funcionamento do sistema II, entre eles: 1) Inconsistências na
contagem das vagas disponíveis nas turmas quando alunos eram transferidos
de uma turma para outra; 2) Algumas telas e botões não funcionavam; 3)
Durante a execução de alguns fluxos de atividades, o sistema “travava” e tinha
que ser fechado.
30
Interface gráfica do sistema II pouco clara e intuitiva aos usuários. Os
conceitos se confundiam na apresentação das telas do sistema, o que tornava
difícil o entendimento e a execução de várias funcionalidades, dificultando o
trabalho dos usuários, principalmente dos que eram pouco experientes. Além
disso, havia diversas funcionalidades que os usuários nunca entenderam ou
utilizaram.
Figura10. Exemplo da falta de clareza e de intuitividade na interface gráfica do sistema II
Figura 11. Exemplo de componente de interface gráfica do sistema II que apresenta um funcionalidade nunca compreendida pelos usuários
31
Sistema II apresentava graves falhas de segurança. As credenciais de
acesso eram compartilhadas por todos os usuários, e todos tinham
possibilidades de acessar qualquer funcionalidade disponível no sistema. Isso
permitia que qualquer pessoa, ao acessar o sistema, pudesse violar informações
importantes, deixando os dados do sistema inconsistentes. Para reforçar o
ambiente de insegurança, existia uma tela que aparentemente permitia a
manipulação do banco de dados através de comandos SQL, o que poderia
representar um potencial risco a segurança dos dados. Somando-se a esses
problemas, não havia nenhum mecanismo de auditoria para registrar as ações
realizadas, vinculando-as aos usuários que as efetivaram e às datas em que
ocorreram.
Figura 12. Tela do sistema II que aparenta permitir manipulação de dados através de comandos SQL
O sistema II era pouco flexível/configurável. Para realizar configurações
simples, que deveriam estar disponíveis para os usuários, era necessário
32
recorrer a serviços de manutenção realizada pelo responsável pelo
desenvolvimento do sistema.
Dificuldades para obtenção de serviços de manutenção no sistema II. O
serviço de manutenção do software não respondia de forma rápida, eficaz e
eficiente às requisições feitas pela coordenação dos cursos de idiomas.
Não havia solução informacional dedicada a facilitar a comunicação entre
coordenação, professores e alunos. Não havia, por exemplo, a possibilidade
de os professores das turmas lançarem notas e freqüências dos alunos
diretamente em um sistema, nem a de os alunos consultarem suas notas e
freqüência via internet.
3.2. Aplicação de Processo Baseado em Metodologias Ágeis
Decidiu-se que o processo de desenvolvimento do projeto Soft Educ GCI tomaria
como base valores, princípios e práticas propostos por metodologias ágeis de
desenvolvimento de software. Essa decisão tinha o principal objetivo de fazer com que
às mudanças ou acréscimos de requisitos sugeridos pelo cliente pudessem ser
processados e incorporados ao software com rapidez e eficiência. Também se
pretendia maximizar a produtividade do trabalho da equipe, de modo a não permitir que
a documentação exigida por processos mais tradicionais e menos flexíveis fossem uma
barreira à entrega de software funcional ao cliente. Portanto buscou-se estabelecer um
processo compatível com as características do grupo de desenvolvedores, baseando-
se no ciclo de vida do Scrum, e incorporando outras características fundamentadas no
manifesto ágil e no XP.
Inicialmente foi prevista para o processo uma fase pré-eliminar ao sprints de
desenvolvimento, uma espécie de concepção, na qual seriam tomadas decisões
arquiteturais e tecnológicas básicas, e realizadas algumas reuniões entre o time de
desenvolvedores e o product owner, a fim de elucidar requisitos do sistema e
documentar as funcionalidades pretendidas. Durante esta fase foi construído um plano,
o product backlog, que continha as funcionalidades e características pretendidas e uma
previsão do calendário de sprints. Também se definiu o conjunto de tecnologias e
ferramentas que seriam utilizados no início do desenvolvimento, e a 1ª versão do
modelo de domínio do sistema.
33
Quanto aos papéis dentro do time do projeto, decidiu-se que o coordenador do
centro de idiomas, Fernando Carneiro, seria o product owner, ou seja, o principal
representante do cliente e dos usuários do sistema. Em relação aos desenvolvedores,
foi proposto um mecanismo de auto-organização, no qual todos deveriam contribuir no
planejamento e no monitoramento e controle das atividades, emitindo suas opiniões
para serem discutidas entre o grupo. A cada novo sprint, o papel de scrum master seria
alternado entre os integrantes da equipe. O fragmento textual a seguir, extraído do
plano de desenvolvimento de software do projeto, relata sobre a proposta inicial de
estrutura organizacional e responsabilidades.
Toda a equipe de desenvolvimento estará em ordem hierárquica equivalente e deverá trabalhar de forma cooperativa, tentando contribuir, sempre que necessário, para resolver as dificuldades dos companheiros, visando sempre o melhor para o coletivo. Os valores comunicação, proatividade, criatividade, respeito, coragem e companheirismo deverão basear as relações dentro da equipe de desenvolvedores e entre a equipe e os demais stakeholders. A cada sprint a equipe deverá alternar o scrum master, o qual terá, além das atividades de desenvolvedor, a responsabilidade adicional de conduzir as reuniões do grupo durante o sprint, orientar e monitorar o trabalho, cobrar resultados do grupo e resolver conflitos internos. Todos os desenvolvedores deverão ter suas opiniões consideradas para as decisões tomadas durante o processo. Tais decisões de planejamento, estratégia e controle devem ser estabelecidas a partir do diálogo da equipe em reuniões de planejamento, de revisão ou de retrospectiva de sprint.
[Plano de Desenvolvimento Software Soft Educ GCI]
Em geral, o planejamento do projeto prevê sprints com duração de 4 semanas, de
modo que o objetivo principal, ao final de cada sprint, é entregar um incremento no
software, através da instalação e disponibilização de uma nova versão funcional do
sistema para que os usuários possam experimentar e produzir feedback.
O início de cada sprint é marcado por uma reunião de planejamento entre
desenvolvedores e o product owner, na qual as prioridades são reavaliadas dentro do
contexto do projeto e são decididas quais funcionalidades e características devem ser
incorporadas ao software durante a iteração. Após isto, há uma nova reunião
envolvendo somente os desenvolvedores, quando são formuladas e estimadas as
atividades necessárias para se atingir o objetivo do sprint. Os dados das atividades são
registrados na ferramenta utilizada para gerenciar o projeto, o Assembla.
Os desenvolvedores trabalham em um mesmo ambiente e, a cada dia de
trabalho, durante o sprint, ocorre uma reunião curta (cerca de 15 minutos) entre eles,
34
na qual cada um expõe sobre o andamento de sua atividade. Algumas atividades, as
de maior prioridade, são atribuídas aos desenvolvedores no planejamento do sprint,
outras são atribuídas ao longo da iteração. Caso a equipe observe que é necessária
uma nova atividade que não foi prevista no planejamento inicial, ela deverá ser
integrada ao sprint backlog durante a execução do sprint. Ao final de cada expediente
de trabalho, os desenvolvedores devem reportar, no Assembla, os avanços obtidos ou
dificuldades encontradas na realização de suas atividades e atualizar o tempo estimado
para a conclusão delas. A partir desta atualização do tempo estimado, o Assembla
constrói o gráfico de sprint burndown, um importante instrumento de observação da
curva de desempenho da equipe ao longo a iteração.
Figura 13. Exemplo de gráfico de sprint burndown do projeto Soft Educ GCI
A equipe trabalha integrando diariamente o código que produz, através do
sistema de controle de versões SVN. O código produzido é de propriedade coletiva e o
uso de alguns padrões de codificação pré-estabelecidos é estimulado e recomendado
dentro do time. Também é recomendado que o código produzido seja simples, claro e
expressivo tanto quanto o possível, e, frequentemente, são realizadas atividades de
refatoração.
35
Semanalmente, ao menos uma vez, representantes da equipe reúnem-se com o
product owner ou com usuários do sistema para demonstrar os resultados parciais do
trabalho de um sprint, tirar dúvidas relacionadas a regras de negócio, ou questionar
sobre preferências quanto a aspectos da interface gráfica e da interação usuário-
sistema. Dessa forma é possível colher feedback de forma rápida e promover a
evolução do software baseado na evolução dos conceitos dos usuários em relação ao
sistema, que ocorre na medida em que o software passa de algo abstrato, contido
somente no plano das idéias, para algo mais concreto e utilizável. Este modelo de
relacionamento entre desenvolvedores e usuários tende a deixar os usuários mais
satisfeitos.
Ao final de cada sprint é realizada uma reunião que marca a entrega da versão ao
product owner. Nela, representantes da equipe de desenvolvimento apresentam os
resultados finais do sprint, e entregam o relatório de atividades, que é exigência do
cliente. O product owner, por sua vez, avalia o que foi cumprido e o que não foi em
relação aos objetivos esperados para o marco, tendo a liberdade para emitir suas
opiniões em relação ao trabalho dos desenvolvedores. Após isso, a instalação da
versão, no servidor de testes, é providenciada.
Após a reunião com o product owner, para apresentar os resultados da iteração, é
realizada uma reunião de retrospectiva de sprint somente entre os membros do time de
desenvolvimento. Nela devem ser relembrados os pontos positivos e negativos que se
destacaram durante o sprint. Propõe-se uma reflexão sobre que ajustes no
comportamento do time poderiam produzir aumento da efetividade e da eficiência.
Discuti-se o que deve ser acrescentado ao processo ou removido dele. Essa
retrospectiva faz-se no intuito de promover a melhoria continua do processo, do
ambiente de trabalho e do relacionamento entre os integrantes da equipe.
Conforme descrito ao longo dessa seção, a estrutura do processo de
desenvolvimento do projeto Soft Educ GCI e o conjunto de práticas relacionadas
demonstram uma organização profundamente relacionada às idéias propostas pelas
metodologias ágeis. No entanto, algumas práticas essencialmente defendidas por esse
tipo de metodologia não foram incorporadas ao desenvolvimento do projeto.
Como exemplo de uma prática ágil não aplicada, pode-se citar a automatização
de testes. Essa prática é extremamente importante e útil, mas não foi integrada ao
projeto por falta de qualificação técnica da equipe. Nenhum integrante do time tinha
domínio de ferramentas e técnicas que possibilitassem aplicá-la e ainda não foi
36
possível dedicar tempo o suficiente para que alguém do time se capacitasse para isso.
A não utilização de testes automatizados no processo representa uma falta que é
bastante sentida por todos os desenvolvedores, pois torna mais difícil validar a
correção das funcionalidades implementadas e deixa o sistema mais vulnerável a
introdução de bugs. Assim sendo, almeja-se integrar essa prática ao processo o quanto
antes, já tendo sido, inclusive, realizadas atividades com o objetivo de estudar e
experimentar ferramentas de testes automatizados.
3.3. Escopo e Requisitos do Sistema
Com fins de resolver os problemas mencionados na seção 3.1 deste trabalho, o
escopo do projeto Soft Educ GCI consiste na elaboração de um sistema informacional
integrado, apresentando-se em três módulos distintos para os seus usuários: o módulo
coordenação, acessível para o coordenador dos cursos de idiomas, funcionários e
bolsistas que desempenham atividades na secretaria da coordenação; o módulo
público, acessível para qualquer usuário da web; e o módulo acadêmico, acessível
para professores e alunos da organização. A descrição dos escopos de cada módulo,
bem como dos seus requisitos funcionais e não funcionais serão apontados nas sub-
seções a seguir.
3.3.1. Módulo Coordenação
O módulo coordenação é o mais completo e complexo do sistema e propõe
atender as demandas das atividades fundamentais para a organização, manutenção e
controle da estrutura dos cursos de idiomas oferecidos. A seguir, estão descritos os
requisitos funcionais referentes a este módulo.
RF 01- Gerência de usuários. Possibilidade de cadastrar novos usuários do
módulo coordenação, atribuindo a eles um papel de usuário, e permitindo que
utilizem as funcionalidades do sistema disponíveis de acordo com papel que
exercem. Deve ser possível também listar os usuários cadastrados e pesquisá-los
a partir de seus nomes ou CPF, bem como visualizar e editar os dados deles ou
desativá-los, removendo o direito de acesso deles ao sistema.
RF 02- Gerência de professores. Possibilidade de cadastrar novos professores
para os cursos de idiomas, de listar os professores cadastrados, de pesquisá-los
a partir de seus nomes ou CPF, de visualizar e de editar os dados deles, e de
37
desativá-los, não permitindo que sejam associados a uma nova turma
configurada.
RF 03- Gerência de cursos. Possibilidade de cadastrar novos cursos, de listar os
cursos cadastrados, de editar os nomes ou número de níveis deles e de desativá-
los. O cadastro e a edição de um curso só dever ser possível quando não houver
um semestre em andamento.
RF 04- Abertura e configuração de semestre letivo. Possibilidade de configurar
dados relativos a um novo semestre de aulas, registrando as datas importantes, a
quantidades de vagas disponíveis nas turmas para os diferentes tipos de alunos,
e os custos dos cursos. Após registrados, os dados do semestre devem poder ser
alterados no sistema. Na abertura de semestre também devem ser criadas as
turmas disponíveis para o semestre.
RF 05- Configuração de turmas. Possibilidade de atribuir um professor a uma
turma, indicar o local, os dias e os horários de aulas. Só devem poder ser
associados a uma turma professores do curso correspondente a turma.
RF 06- Listagem dos alunos de uma turma. Possibilidade de listar todos os
alunos de uma Tuma com seus respectivos telefones para contato e e-mail.
RF 07- Gerência de inscrições para sorteio. Possibilidade de consultar
inscrições realizadas para sorteio das vagas das turmas de 1º nível do semestre
corrente. Deve permitir listar inscritos de cada turma separadamente e fazer
pesquisas de inscrições com dados iguais ou semelhantes. Também deve
possibilitar o cancelamento de inscrições.
RF 08- Gerência de sorteios. Possibilidade de visualizar relatório de demanda
para as vagas remanescentes nas turmas de 1º nível, de realizar 1 ou mais
sorteios destas vagas, de visualizar listagem de sorteados e de gerar arquivo PDF
com tal listagem.
RF 09- Gerência de provas de nivelamento. Possibilidade de cadastrar sessões
de provas de nivelamento, de listar as sessões de provas de nivelamento
cadastradas no semestre corrente, de editar os dados delas e de excluí-las. Só
devem poder ser excluídas sessões de provas de nivelamento que ainda não
tiverem nenhum candidato inscrito. O sistema também deve possibilitar a listagem
dos inscritos em uma sessão.
38
RF 10- Inscrição de candidatos a nivelamento. Possibilidade de inscrever
candidatos a nivelamento, associando-os a uma sessão de nivelamento
cadastrada e gerando um recibo de inscrição.
RF 11- Registro e consulta a resultados em provas de nivelamento.
Possibilidade de registrar o nível de certificação atingido para cada candidato
inscrito em uma sessão de nivelamento, bem como de consultar esses registros a
partir da pesquisa pelo nome ou CPF da pessoa que realizou a prova.
RF 12- Gerência de alunos. Possibilidade de cadastrar novos alunos, de
pesquisar os alunos cadastrados através de seus nomes ou CPF, de visualizar e
de editar os dados deles.
RF 13- Matrícula de aluno. Possibilidade de vincular um aluno a uma turma,
registrando os dados de pagamento e gerando um recibo de matrícula ao final do
processo. Para uma pessoa ser matriculada em uma turma, ela deve estar em
conformidade com pelo menos um dos seguintes requisitos: ter sido previamente
cadastrada no sistema, ter sido sorteada para uma vaga de uma turma de 1º nível
de um dos cursos, ou ter obtido uma certificação em uma prova de nivelamento.
O sistema deve possibilitar também o cancelamento de uma matrícula.
RF 14- Transferência de alunos entre turmas. Possibilidade de transferir alunos
matriculados em uma turma para outra turma do mesmo curso e de mesmo nível.
Após realização de transferências devem ser gerados comunicados de
transferência.
RF 15- Histórico do aluno. Possibilidade de observar as turmas pelas quais um
aluno passou e visualizar se o aluno foi aprovado, reprovado ou cancelou a
matrícula em cada turma. Também deve ser disponibilizado o histórico de
transferências do aluno.
RF 16- Controle de notas e freqüência. Possibilidade de registrar a presença ou
o número de faltas dos alunos de uma turma a cada aula, e de inserir as notas
dos alunos em cada avaliação. Deve-se permitir indicar que as atividades de uma
turma foram concluídas, para, quando isso acontecer, o sistema informar se os
alunos daquela turma foram aprovados ou reprovados, de acordo com as notas e
a freqüência deles.
RF 17- Certificados de aprovação. Possibilidade de gerar arquivo PDF com
certificados para os alunos aprovados nas turmas de um semestre letivo.
39
RF 18- Folhas de registro. Emissão de documentos contendo uma lista
enumerada com todos os alunos aprovados durante um semestre letivo.
Dos dezoito requisitos funcionais previstos para este módulo, quinze já foram
implementados, representando mais de 80% do total. Já em relação aos requisitos não-
funcionais, foram previstos dois, os quais estão descritos a seguir. Deles, apenas o
primeiro já está implementado.
RNF 01- Autenticação e autorização de acesso a funcionalidades.
Necessidade de o usuário estar autenticado no sistema para poder acessar
qualquer funcionalidade. Cada usuário deve ter suas próprias credenciais de
acesso, login e senha, sendo que não pode haver dois usuários como o mesmo
login. Quando o usuário autentica-se, o sistema deve identificar o papel que o
usuário exerce no sistema e autorizar o acesso dele somente às funcionalidades
disponíveis para o papel associado.
RNF 02- Auditoria de ações importantes. Registro da data e do horário de em
que determinadas ações foram executadas no sistema, bem como do usuário
responsável pela realização da ação.
3.3.2. Módulo Público
O módulo público dedica-se exclusivamente a proporcionar, ao público em geral,
a possibilidade de se inscrever para o sorteio às vagas das turmas de 1º nível dos
cursos oferecidos. O único requisito para este módulo é o seguinte:
RF 19- Inscrição para Sorteio. Possibilidade de realização de inscrições de
candidatos para concorrer a sorteio das vagas nas turmas de 1º nível
disponibilizadas no semestre corrente. O sistema só deve permitir que o
candidato possa escolher uma turma. Após a realização de uma inscrição, o
sistema deve permitir a geração de um comprovante de inscrição, indicando a
turma para qual se inscreveu, a data de divulgação da 1ª chamada e a de
matrícula. As inscrições só devem ser permitidas em um dado período, que deve
ser pré-configurado durante a abertura do semestre letivo, no módulo público.
40
Este requisito RF 19 já está implementado, e este módulo não apresenta
requisitos não funcionais.
3.3.3. Módulo Acadêmico
O módulo acadêmico constitui-se em uma ferramenta para os professores
registrarem informações quanto ao andamento das aulas nas turmas, à freqüência e às
notas dos alunos, a fim de que estes possam acessar essas informações via internet.
Dentre os requisitos funcionais para este módulo, está o requisito RF 16, descrito na
seção 3.3.1. Os demais, que ainda não foram descritos, são:
RF 20- Boletim. Possibilidade de os alunos acessarem seus boletins através do
sistema.
RF 21- Relatório de Aulas. Possibilidade de os alunos observarem a lista de
aulas já lecionadas com suas respectivas datas, conteúdos ministrados, e a
informação do número de faltas do aluno em cada dia de aula.
A implementação do módulo acadêmico ainda não foi iniciada e está prevista para
começar no mês de agosto de 2011, conforme o planejamento do projeto entregue ao
cliente. Sendo assim, os professores e alunos da organização ainda não estão
utilizando o sistema. Os requisitos não funcionais previstos para este módulo são os
mesmos previstos para o módulo coordenação (RNF 01 e RNF 02).
3.4. Ferramentas e Tecnologias Aplicadas
No intuito de gerenciar as atividades e as informações do projeto, a principal
ferramenta escolhida para esta finalidade foi o Assembla (http://www.assembla.com),
conforme já havia sido mencionado na seção 3.2 deste trabalho. No entanto, a equipe
também se utilizou de outras ferramentas auxiliares para apoiar a comunicação e o
compartilhamento de informações, quais sejam o Google Groups, o Google Docs e o
Gmail. Em síntese, no Assembla era registrado o planejamento das iterações, a
descrição e os prazos das atividades e as informações referentes aos resultados delas.
Enquanto isso, os serviços do Google eram utilizados principalmente para enviar
rapidamente mensagens a todos os membros do grupo e para compartilhar
documentos relacionados a controle de bugs, controle de acesso a funcionalidades e
cronograma do projeto, por exemplo.
41
Como sistema de controle de versionamento dos arquivos do projeto, adotou-se o
SVN, por meio de serviço disponibilizado pelo Assembla, que fornece uma interface
gráfica amigável para observar a evolução das versões dos arquivos inseridos no
repositório e para acompanhar os commits, suas descrições e mudanças que
realizaram.
Foi decidido que o sistema seria implementado utilizando-se a linguagem Java
versão 6 e as tecnologias da plataforma JEE que foram explicadas na seção 2.2 deste
trabalho. A JPA foi utilizada para promover o mapeamento objeto-relacional e
simplificar o mecanismo de comunicação entre a aplicação e a camada de persistência;
O EJB 3.0 foi usado com a finalidade de encapsular a lógica de negócios e a interação
com o banco de dados, obtendo as vantagens fornecidas pelo container EJB; E o JSF
1.2 foi empregado de forma integrada ao RichFaces 3.3 e ao Facelets, para construir
as interfaces web do sistema e programar a interação cliente-servidor via web. O
servidor de aplicações coorporativas escolhido para executar o sistema foi o JBoss
Application Server versão 5.1. Quanto ao Sistema de Gerenciamento de Banco de
Dados para hospedar o banco de dados da aplicação, optou-se pelo PostgreSQL
versão 8.4.
Procurou-se padronizar a instalação dos softwares nas estações de trabalho dos
desenvolvedores e configurar ambientes de desenvolvimento homogêneos para os
membros da equipe, a fim de evitar problemas de incompatibilidade de recursos
consumidos ou produzidos. Nesse sentido, o time decidiu usar o sistema operacional
Ubuntu, na versão 10.04 - 32 bits, e a IDE Eclipse Helios com os plugins Subversive,
para integração com o SVN, e JBoss Tools, para facilitar o trabalho com as tecnologias
associadas a plataforma JEE.
Para a produção e edição de imagens foram utilizadas principalmente as
ferramentas GIMP, Inkscape e Pixlr Editor. Para a produção de artefatos de
modelagem do sistema, utilizou-se o Astah Community e o OpenOffice Draw. O
Windows 7 foi empregado como sistema operacional alternativo. Os programas do
pacote Microsoft Office foram utilizados na produção de documentos de texto
formatado e de apresentações de slides.
3.5. Arquitetura e Modelagem do Sistema
Conforme explicado na seção 3.3, os requisitos funcionais do projeto Soft Educ
GCI estão subdivididos em três módulos distintos, e é desta forma que o software deve
42
se apresentar para seus usuários. Com o intuito de atender as demandas desses
requisitos modulares, e considerando às tecnologias da plataforma JEE utilizadas e os
conceitos relacionados às mesmas, abordados na seção 2.2 deste trabalho, propôs-se,
para a implementação do sistema, uma solução arquitetural baseada em componentes
que será detalhada ao longo desta seção. Observe-se que, como foi dito anteriormente,
o módulo acadêmico ainda não começou a ser desenvolvido, e por isso esta seção não
abordará aspectos arquiteturais relacionados a este módulo em específico.
Antes de se analisar a arquitetura com base na visão de componentes, a qual
retrata a relação entre os principais componentes lógicos, será brevemente explicada a
visão de casos de uso do sistema, que relaciona os atores (usuários) às
funcionalidades que eles poderão acessar. Para os diagramas apresentados nas
figuras 14-a, 14-b e 15, os casos de uso representados com fundo colorido são os que
já estão implementados no sistema, enquanto os que não possuem cor de fundo são
os que ainda não foram implementados.
As figuras 14-a e 14-b constituem o diagrama de casos de uso do Módulo
Coordenação. Neste módulo percebem-se trinta e seis casos de uso, dos quais trinta e
três já foram implementados. Quanto aos atores, pode-se notar que o Coordenador
herda do Secretário, e este herda do Bolsista, de modo que o primeiro deve ter acesso
a todos os casos de uso do módulo; o segundo, a vinte e três; e o terceiro a apenas
dezesseis deles.
43
Figura 14-a. Primeira parte do diagrama de casos de uso do Módulo Coordenação
44
Figura 14-b. Segunda parte do diagrama de casos de uso do Módulo Coordenação
Quanto ao Módulo Público, foram propostos apenas dois casos de uso, que
devem poder ser acessíveis, por meio da utilização de um browser, para qualquer
pessoa conectada a internet.
Figura 15. Diagrama de casos de uso do Módulo Público
45
Em relação à visão lógica do sistema, o diagrama representado pela figura a
seguir expõe os principais componentes relativo à implementação do sistema, e a
forma como eles se relacionam.
Figura 16. Organização arquitetural dos componentes do sistema Soft Educ GCI
A princípio, o diagrama da figura 16 apresenta dois componentes que não foram
desenvolvidos pela equipe do projeto, mas que constituem o ambiente de instalação e
execução do sistema. Estes componentes são: o servidor de aplicações coorporativas
Jboss Application Server, necessário para a instalação e execução do arquivo
Enterprise (EAR) que empacota os módulos implementados do sistema; e o Sistema de
Gerenciamento de Banco de Dados PostegreSQL na versão 8.4, necessário para
executar o banco de dados da aplicação. Tal banco de dados é representado no
diagrama pelo componente denominado “softEduc_GCI_BD”.
Quanto aos componentes representados dentro do container de aplicações
coorporativas, eles representam os módulos do sistema da forma como são
apresentados na IDE utilizada.
O “softEduc_GCI_modelo” é a unidade que encapsula as classes referentes ao
modelo de domínio da aplicação, as entidades JPA. Nele está compreendida a
implementação das dezesseis entidades do modelo de domínio do sistema e de seus
46
respectivos mapeamentos objeto-relacional. Estas classes e seus atributos persistentes
estão documentados no diagrama a seguir:
Figura 17. Diagrama de modelo de domínio do sistema Soft Educ GCI
Ainda referindo-se à figura 16, pode-se notar que todos os demais componentes
representados dentro do “Jboss A. S.” têm dependência em relação ao componente
“softEduc_GCI_modelo”, indicando que eles devem conhecer as classes do modelo,
47
pois devem ter a possibilidade realizar operações envolvendo atributos e métodos
delas.
O componente “softEduc_GCI_core” representa a unidade que contém os
Enterprise beans da aplicação. Como foi explicado outrora, Enterprise beans são
classes que encapsulam a lógica de negócio da aplicação e se utilizam de diversos
serviços oferecidos pelo container EJB. Essa unidade está dividida em dois pacotes
principais: “fachada” e “negocio”.
O pacote “negocio” comporta os treze beans de sessão responsáveis por
implementar o núcleo da lógica de negócio da aplicação. Comporta também suas
respectivas interfaces locais, as quais têm a função de declarar os métodos dos beans
que devem estar disponíveis para serem invocados por outros componentes
executados dentro do mesmo servidor de aplicações. É também nos Enterprise beans
do pacote “negocio” que o contexto de persistência das entidades JPA do sistema é
gerenciado. Nos métodos destes beans são realizados os comandos de manipulação
do banco de dados através dos métodos disponibilizados pela interface
“EntityManager” da JPA.
Enquanto isso, o pacote “fachada”, como próprio nome sugere, implementa o
padrão de projeto fachada ou facade. Ele contém dois beans de sessão, que
representam duas fachadas, e suas respectivas interfaces. Essas fachadas têm a
função de abstrair, para os componentes web do sistema, o conhecimento dos
Enterprise beans do pacote “negocio”, no sentido de fazer com que os componentes
web necessitem conhecer somente as fachadas para utilizarem os serviços
implementados nos demais beans. Vale enfatizar que, quanto a tecnologia EJB, foram
utilizados na implementação do sistema apenas beans de sessão do tipo stateless.
Os componentes “softEduc_GCI_administrativo” e “softEduc_GCI_publico”
representam os módulos web do sistema. O primeiro disponibiliza, para os usuários, as
interfaces web com as funcionalidades do Módulo Coordenação, enquanto o segundo
disponibiliza as do Módulo Público. Estas duas unidades estão implementadas com
componentes do framework JSF, do Facelets, e do RichFaces. As estruturas dessas
unidades são similares e, de forma resumida, contêm: um conjunto de páginas no
formato XHTML com os componentes a serem processados na exibição delas; alguns
componentes responsáveis pela conversão e validação de dados oriundos de
requisições dos clientes web; um conjunto de managed beans os quais processam e
respondem às requisições recebidas; e alguns arquivos XML de configuração. Os
48
managed beans funcionam como controladores das páginas web. Eles podem
manipular instâncias das classes do modelo de domínio e também podem acessar os
serviços oferecidos pelo componente “softEduc_GCI_core”. Esses serviços são
utilizados através da invocação dos métodos declarados nas interfaces
“FachadaAdministrativoLocal” e “FachadaPublicaLocal”.
Ao longo do processo não foi produzido nenhum documento de especificação de
caso de uso nem qualquer diagrama de sequência, haja vista que a equipe avaliou que
a produção destes artefatos seria muito custosa e a manutenção seria praticamente
inviável, considerando-se a abertura do processo para as mudanças desejadas pelo
cliente. Portanto fez-se prevalecer os princípios ágeis que priorizam colaboração com o
cliente, software em funcionamento e respostas a mudanças mais que negociação de
contratos e documentação abrangente.
A responsabilidade de analisar cada caso de uso e de projetar sua solução era
responsabilidade de cada desenvolvedor, desde que, na implementação da solução,
seguisse os padrões arquiteturais e de codificação estabelecidos. Foi acordado que o
planejamento das tarefas e seus resultados seriam documentados no Assembla, no
espaço da descrição ou de comentários da tarefa. Dessa forma, detalhes importantes
de um casos de uso deveriam ser documentados junto ao registro das tarefas
relacionadas ao mesmo no Assembla.
No entanto, em alguns momentos, quando se observou uma maior necessidade
de organização para desenvolver um conjunto complexo de casos de uso inter-
relacionados, a serem implementados por vários desenvolvedores, foi produzido uma
espécie de artefato sem precedentes bibliográficos conhecidos pelos membros da
equipe. Trata-se de um documento exemplificado na figura 18, o qual expressa a
navegação em relação a um conjunto de páginas web do sistema, e indica o modo
como o conteúdo dessas páginas devem se apresentar para o usuário.
49
Figura 18. Exemplo de artefato que representa esquema de navegação e caracterização de interfaces do sistema
50
3.6. Resultados Obtidos
Partindo-se dos problemas mencionados na 1ª sessão deste capítulo, aplicando-
se o processo de software descrito, as ferramentas e tecnologias propostas, e a
estrutura arquitetural definida, a equipe está, até o momento, obtendo êxito na
transformação dos requisitos do sistema em software funcional e conseguindo
satisfazer o cliente. Cerca de 70% da totalidade do escopo e dos requisitos previstos
para o sistema já foram implementados e o andamento do projeto está dentro do
cronograma previsto no planejamento entregue ao cliente. A parcela do sistema
implementada até o momento já está funcionando em ambiente de produção, sendo
utilizada no processo de inscrições para sorteio, sorteio de vagas das turmas de 1º
nível, e matrículas.
Na sequência desta sessão serão apresentados os resultados da implementação
dos dois casos de uso do Módulo Público e de oito casos de uso do Módulo
Coordenação, na seguinte ordem: Inscrição para sorteio de vagas para turma de 1º
nível do semestre atual (Módulo Público); Geração de comprovante de inscrição em
sorteio (Módulo Público); Cadastro, edição ou desativação de professores e Listagem
e visualização de dados de professores; Abertura e configuração de semestre letivo e
Ativação e configuração de turmas do semestre atual; Relatório de demanda de
inscrições para as vagas do sorteio, Realização de sorteio e Visualização dos
resultados do sorteio; e Matrícula de Sorteado. Para apresentar esses resultados serão
utilizadas as imagens das telas que compõem o fluxo básico de execução dos casos de
uso mencionados. Em relação a todos os casos de uso do Módulo Coordenação, deve-
se considerar que para acessá-los é necessário que o usuário esteja autenticado no
sistema.
Inscrição para sorteio de vagas para turma de 1º nível do semestre atual
(Módulo Público)
Qualquer internauta poderá acessar esse caso de uso, através do endereço da url
do Módulo Público. Caso o acesso seja realizado fora de um período de inscrições
previamente configurado, o sistema exibirá uma mensagem informando que o
formulário de inscrições está indisponível; caso contrário o sistema apresentará a
página exibida na figura 19.
51
Para iniciar a inscrição, o usuário deve marcar a caixa de seleção e, em seguida,
clicar no botão “Iniciar Inscrição”, os quais estão situados na parte inferior da página.
Então o sistema deverá apresentar a página exibida na figura 20. Nesta página o
usuário deve preencher os dados do formulário, selecionar a turma na qual deseja
concorrer a uma vaga e clicar no botão enviar. Caso o dados informados no formulário
sejam validados pelo sistema, apresentar-se-á a página exibida na figura 21, na qual o
usuário poderá verificar os dados que inseriu e confirmar sua inscrição, ou então voltar
para alterar algum dado. Caso o usuário confirme sua inscrição, será exibida uma
página conforme a figura 22, mostrando uma mensagem indicando o sucesso na
realização da inscrição do candidato e disponibilizando um link com a possibilidade de
impressão de comprovante da inscrição.
Figura 19. Tela inicial do sistema de inscrições para sorteio das vagas das turmas de 1º nível
52
Figura 20. Formulário de dados necessários para realizar inscrição para concorrer a sorteio
53
Figura 21. Tela de confirmação de dados da inscrição para concorrer a sorteio de vagas
Figura 22. Tela indicando sucesso na realização da inscrição para concorrer a sorteio
54
Geração de comprovante de inscrição em sorteio (Módulo Público)
Este caso de uso é um complemento do CDU descrito anteriormente, de modo
que o usuário só poderá acessá-lo após completar o processo de inscrição para
concorrer ao sorteio das vagas de uma turma do 1º nível, clicando no link “Imprimir
comprovante de inscrição”, exposto na página indicada na figura 22. Fazendo isso,
será aberta uma página com o comprovante de inscrição que poderá ser impresso ou
salvo pelo usuário.
Figura 23. Tela para impressão de comprovante de inscrição
Figura 24. Comprovante de inscrição para concorrer a sorteio de vagas
55
Cadastro, edição ou desativação de professores e Listagem e visualização
de dados de professores
Após autenticar-se no Módulo Coordenação, usuários do tipo Coordenador ou
Secretário poderão cadastrar um professor acessando o menu “Professores” e o sub-
menu “Novo Professor”. Com isso, será apresentada uma página como a indicada na
figura 25, na qual o usuário deverá inserir os dados solicitados no formulário e clicar no
botão “Cadastrar”. Caso os dados inseridos no formulário sejam validados, será
apresentada uma página conforme a figura 26, indicando que o cadastro foi realizado
com sucesso. Para listar os professores, editar dados deles, desativá-los ou reativá-los,
o usuário deve acessar o sub-menu “Gerenciar Professores”, do menu “Professores”, e
será levado até a página representada na figura 27.
Figura 25. Formulário de cadastro de professor
56
Figura 26. Tela indicando sucesso no cadastro de um professor
Na tela “Gerência de Professores”, os usuários podem desativar um professor
clicando no ícone em formato de “X”, ou reativá-lo clicando no ícone em formato de “V”.
Para editar os dados de um professor, clica-se no ícone em formato de lápis,
provocando a abertura de uma janela sobre a página, onde a edição poderá ser
realizada. A janela de edição de dados de um professor é mostrada na figura 28.
Figura 27. Tela de gerência de professores cadastrados
57
Figura 28. Janela de edição de dados de um professor
Abertura e configuração de semestre letivo e Ativação e configuração de
turmas do semestre atual
Para abrir um semestre é necessário que se tenha cursos cadastrados no
sistema, e para ativar e configurar turmas é necessário que os cursos associados a
estas turmas tenham professores cadastrados. Essas ações só podem ser executadas
por um usuário do tipo Coordenador. Para abrir um semestre o usuário deve clicar no
sub-menu “Abrir Semestre”, da opção “Semestre” no menu principal. Isso levará ao
usuário para uma página a exemplo da que é indicada na figura 29. Então o usuário
preenche os campos do formulário e clica no botão “Próximo Passo”. Caso os dados
inseridos no formulário sejam validados, o sistema apresentará uma página como a
exemplificada na figura 30, onde o usuário deve inserir as informações quanto ao
58
número de turmas e o material didático para cada nível dos cursos oferecidos. Após
isso o usuário deve clicar no botão “Concluir” para completar a abertura do semestre.
Figura 29. Primeiro passo para abertura de um semestre letivo
Figura 30. Segundo passo para abertura de um semestre letivo
59
Ao completar a abertura de um semestre, o sistema exibe a tela exemplificada
na figura 31.
Figura 31. Tela de ativação e configuração de turmas
Figura 32. Janela de ativação e configuração de uma turma
60
A página “Ativação de Turmas do Semestre Atual”, além de ser apresentada
após a conclusão da abertura de um semestre, também pode ser acessada através do
sub-menu “Ativar Turmas do Semestre Atual”, do item do menu principal “Semestre”.
Nela as turmas criadas pelo sistema a partir das informações declaradas na abertura
do semestre podem ser ativadas e configuradas. Para tanto, deve-se clicar no ícone
em formato de “V”, provocando a abertura de uma janela sobre a página, onde a turma
poderá ser configurada e ativada. Após serem ativadas, as turmas poderão ser vistas,
re-configuradas ou desativadas na página “Visualização de Turmas”, que é exibida nas
figuras 33 e 34.
Figura 33. Tela para pesquisa e listagem de turmas
Figura 34. Janela para editar dados de uma turma
61
Relatório de demanda de inscrições para as vagas do sorteio, Realização de
sorteio, Visualização dos resultados do sorteio
Para visualizar relatório que aponta o número de vagas remanescentes em cada
turma de 1º nível e o número de concorrentes a estas vagas, um usuário do tipo
Coordenador deve acessar o sub-menu “Gerenciar Sorteios”, do menu “Sorteio” e clicar
no link “Clique Aqui” disponível no painel inferior da página “Gerência de Sorteios”
(figura 35). Fazendo isso, ele visualizará uma janela sobreposta a página exibindo tal
relatório, conforme exemplificado na figura 36.
Para realizar um novo sorteio, deve-se clicar no botão “Realizar Novo Sorteio”,
também disposto no painel inferior da página “Gerência de Sorteios”. Com isso, será
exibido para o usuário uma caixa de confirmação, conforme apresentado na figura 37.
Caso o usuário confirme a realização de um novo sorteio, o sistema realizará o sorteio
das vagas remanescentes entre os candidatos que estão concorrendo a elas e, após
isto, exibirá uma mensagem indicando sucesso na realização do sorteio e uma nova
linha na tabela que lista os sorteios do semestre atual, como mostrado na figura 38.
Os resultados dos sorteios realizados são acessíveis através dos links
disponibilizados nas colunas da tabela que lista os sorteios, tendo-se a possibilidade de
visualizar os resultados de cada turma individualmente (figura 39), ou o resultado de
todas as turmas no browser (figura 40) ou em um arquivo PDF.
Figura 35. Tela para gerenciar sorteios
62
Figura 36. Janela com relatório de vagas disponíveis nas turmas e número de candidatos ao sorteio delas
Figura 37. Caixa de confirmação para realização de um novo sorteio
63
Figura 38. Tela com mensagem indicando sucesso na realização do sorteio e exibindo lista de sorteios realizados no semestre
Figura 39. Telas de visualização dos sorteados para as vagas de uma turma
64
Figura 40. Tela com resultado geral de um sorteio
Matrícula de Sorteado
Para matricular um candidato sorteado, o usuário deve acessar o sub-menu
“Buscar Sorteados”, do item do menu principal “Sorteio”. Com isso, o sistema deve
apresentar a página “Busca de sorteados”, onde o usuário deverá pesquisar o sorteado
que deseja se matricular, e, ao encontrá-lo, clicar no link “Matricular”. Então o sistema
apresentará um formulário de matrícula com os dados da inscrição do sorteado e os
campos referentes às formas de pagamento. Após concluir a matrícula, o sistema exibe
65
uma página (figura 43) com uma mensagem indicando que a matrícula foi realizada
com sucesso e um link para impressão de recibo de matrícula (figura 44).
Figura 41. Tela de pesquisa de um sorteado
Figura 42. Tela com formulário para matrícula de sorteados
66
Figura 43. Tela com mensagem indicando sucesso na matrícula de um sorteado
Figura 44. Tela para impressão de recibo de matrícula em duas vias
67
4. CONCLUSÃO
Pode-se afirmar que o desenvolvimento do sistema para integrar as informações
referentes ao processo de negócio do Centro de Idiomas FUNCERN está bem
avançado, dentro das expectativas estimadas no planejamento do projeto. As
funcionalidades implementadas e implantadas até o momento estão validadas pelo
product owner e pelos usuários, através das várias experiências que eles tiveram
utilizando o sistema ao longo das sessões de testes e de treinamento realizadas com a
participação deles. O product owner demonstra bastante satisfação com o trabalho
realizado pela equipe de desenvolvedores, reportando, com freqüência, que o software
que está sendo desenvolvido simplifica bastante a realização de atividades que antes
exigiam um esforço muito maior para serem executadas.
A equipe conseguiu estabelecer a organização do processo de desenvolvimento
por meio da adoção de uma adaptação do Scrum integrada a algumas práticas XP.
Além disso, também foi inserido no processo o uso de alguns artefatos oriundos de
metodologias tradicionais, haja vista que o grupo de desenvolvedores estava adaptado
a eles e avaliou a relação custo-benefício para produzi-los e mantê-los como sendo
positiva. Esses fatores representaram a adaptação do processo às características do
time de desenvolvimento e às expectativas do cliente. A busca pela melhoria contínua
do processo também foi algo bastante positivo, notado a cada reunião que acontecia
no intuito de se estabelecer melhores práticas.
Ficou bastante nítida a idéia de que as práticas ágeis atuam no sentido de
repassar para as pessoas a responsabilidade que, na abordagem das metodologias
tradicionais, são depositadas sobre documentos e ferramentas. Isso leva a conclusão
de que o nível de aplicação dessas práticas deve estar diretamente relacionado ao
nível de maturidade, responsabilidade e comprometimento dos membros da equipe do
projeto. Em uma equipe com alto nível em relação a esses critérios o uso dessas
práticas pode ser bastante positivo e conduzir o time a uma organização baseada em
um mecanismo de auto-gerência. Quando o nível de maturidade e responsabilidade
das pessoas envolvidas no projeto não for tão confiável, é indicado mesclar agilidade
com rigidez, sempre procurando motivar o grupo. Também foi inferido que quanto
maior o número de pessoas envolvidas no processo, maior é a dificuldade para
implantação dessas práticas.
68
O fator comunicação também demonstrou sua importância decisiva no processo.
A comunicação e a aproximação entre desenvolvedores e product owner foi bastante
significativa no sentido de promover, no decorrer do processo, para ambas as partes,
esclarecimentos quanto à melhor forma de implementar os requisitos. Em alguns
momentos, quando os desenvolvedores falharam em relação à comunicação interna,
deixando de reportar sobre o andamento de suas atividades, o processo ficou
prejudicado, de modo que algumas atividades atrasaram o projeto ou produziram
resultados insatisfatórios, o que se conseguiu reverter na com esforços adicionais.
Outros aspectos positivos observados foram: o bom nível de envolvimento e
participação dos desenvolvedores no projeto, o que deve ter sido motivado pela maior
possibilidade deles influenciarem nas decisões tomadas; e o amplo aprendizado em
relação às tecnologias da plataforma JEE utilizadas, tendo em vista que, no início do
projeto, nenhum dos desenvolvedores possuía domínio sobre elas.
Em relação às tecnologias e ferramentas de desenvolvimento utilizadas, notou-se
que as tecnologias da plataforma JEE realmente proporcionam bastantes vantagens e
abstrações. Porém, o tempo necessário para iniciar servidor de aplicações JBoss e
para fazer a implantação da aplicação mostrou-se um fator amplamente negativo, já
que dificultava bastante na hora de observar os resultados da programação. Também o
alto consumo de memória RAM do JBoss Aplication Server, algumas dificuldades e
problemas encontrados no uso da IDE Eclipse, e o grande número de configurações
necessárias para utilizar essas tecnologias e ferramentas em conjunto apresentaram-
se como empecilhos ao desenvolvimento sistema que estão sendo superados até o
momento com o esforço e a paciência dos desenvolvedores.
A não adoção de testes automatizados no processo e a falta de disciplina dos
desenvolvedores em documentar as classes produzidas com comentário Javadoc
foram duas grandes falhas mais perceptíveis no processo. A primeira é bastante
sentida nos momentos de lançamento de builds, quando muito tempo é perdido na
execução de testes manuais para tentar assegurar a correção e a estabilidade do
sistema. Sem testes automatizados, fica muito mais difícil detectar possíveis bugs
introduzidos no sistema por novas implementações. A segunda falha poderá ocasionar
problemas quando for necessário alterar trechos de códigos não entendidos pelo
desenvolvedor responsável. Portanto, é sabido que estas duas práticas devem ser
integradas ao processo tão logo quanto possível.
69
Quanto aos aspectos relacionados à gerência das atividades e ao
compartilhamento de informações, a experiência foi positiva em relação ao uso do
Assembla e das ferramentas do Google mencionadas na sessão 3.4. Contudo, para
melhor aplicação de características ágeis relacionadas a esses aspectos, faltou o uso
de recurso mais palpáveis e visíveis dentro do ambiente de trabalho, tais como quadro
branco e post its, o que serve de sugestão para ser aplicado na sequência do
desenvolvimento do projeto.
Em síntese, observando-se todos os aspectos mencionados neste capítulo, pode-
se avaliar que os objetivos propostos para este trabalho foram amplamente alcançados
e que a experiência do desenvolvimento do Soft Educ GCI está sendo bastante
positiva, tanto na avaliação do cliente, quanto em relação à capacidade de organização
da equipe de desenvolvimento. Foram notados alguns problemas referentes ao
processo e às tecnologias utilizadas, os quais constituem as lições aprendidas, que
devem servir como base para a melhoria do processo em etapas futuras do
desenvolvimento deste ou de outros projetos.
Quanto à continuidade das ações relacionadas a este trabalho, pretende-se
concluir a implementação dos requisitos levantados e implantação das funcionalidades
correspondentes a eles dentro do prazo estipulado (dezembro de 2011). Além disso, a
equipe vislumbra também a possibilidade de criar uma empresa, de ampliar o número
de desenvolvedores, de estudar novas tecnologias, de adaptar o produto para uso em
outras instituições, de planejar a produção de outros produtos e de se associar a novos
parceiros.
70
REFERÊNCIAS BIBLIOGRÁFICAS
Portela, C. S. Uma Proposta de Gerenciamento Ágil dos Projetos de Desenvolvimento de Software do CTIC/UFPA. Trabalho de Conclusão de Curso. CTIC/UFPA, Belém-PA, Brasil. 2009.
Soares, M. S. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. INFOCOMP (UFLA. Impresso), v. 3, p. 8-13, 2004.
Soares, M. S. Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software. RESI. Revista Eletrônica de Sistemas de Informação, v. 3, p. 1-8, 2004.
Manifesto para o Desenvolvimento Ágil de Software. Disponível em: http://www.manifestoagil.com.br/. Acesso em 25 de maio de 2011.
Jendrock, E.; Evans, I.; Gollapudi D.; Haase, K.; SrivathsaThe, C. The Java EE 6 Tutorial. Disponível em: http://download.oracle.com/javaee/6/tutorial/doc/. Acesso em 04 de junho de 2011.
Keith, M.; Schincariol, M. Pro EJB 3: Java Persistence API. Berkely, CA, USA: Apress, 2006. 480p.
RichFaces Developer Guide. Disponível em: http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html_single/. Acesso em 05 de junho de 2011
Documentation Facelets tools. Disponível em: http://www.jsftoolbox.com/documentation/facelets/. Acesso em 05 de junho de 2011
![Spring Framework - start [DIATINF/CNAT/IFRN]diatinf.ifrn.edu.br/prof/lib/exe/fetch.php?media=user:... · 2015-12-23 · Spring MVC •Módulo do Spring Framework que permite o desenvolvimento](https://static.fdocumentos.tips/doc/165x107/5f0a68967e708231d42b7d4c/spring-framework-start-diatinfcnatifrn-2015-12-23-spring-mvc-amdulo.jpg)
![RATIONAL UNIFIED PROCESS - start [DIATINF/CNAT/IFRN]diatinf.ifrn.edu.br/prof/lib/exe/fetch.php?media=user:... · 2016. 6. 28. · O RUP define iterações como uma sequência distinta](https://static.fdocumentos.tips/doc/165x107/60a1668304bc3c0140130114/rational-unified-process-start-diatinfcnatifrn-2016-6-28-o-rup-define.jpg)
