Desenvolvimento de Sistema de Informação Coorporativo para o Centro de Idiomas Funcern: Um Estudo de Caso

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA
DO RIO GRANDE DO NORTE
LUIZ FELIPE DE SOUSA MIRANDA
DESENVOLVIMENTO DE SISTEMA DE INFORMAO COORPORATIVO PARA

O CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO
NATAL/RN
2011

Trabalho de Concluso de Curso apresentado

ao Curso Superior de Tecnologia em Anlise e
Desenvolvimento de Sistemas do Instituto
Federal de Educao, Cincia e Tecnologia do
Rio Grande do Norte, em cumprimento s
exigncias legais como requisito parcial
obteno do ttulo de Tecnlogo em Anlise e
Desenvolvimento de Sistemas.
Orientador: Fabiano Papaiz
NATAL/RN
2011

Trabalho de Concluso de Curso apresentado ao

Curso Superior de Tecnologia em Anlise e
Desenvolvimento de Sistemas do Instituto
Federal de Educao, Cincia e Tecnologia do
Rio Grande do Norte, em cumprimento s
exigncias legais como requisito parcial
obteno do ttulo de Tecnlogo em Anlise e
Desenvolvimento de Sistemas.
Aprovado em 13 de julho de 2011.
BANCA EXAMINADORA
Fabiano Papaiz Orientador

Instituto Federal de Educao, Cincia e Tecnologia do Rio Grande do Norte
Alexandre Gomes de Lima

Plcido Antonio de Souza Neto

Dedico este trabalho a todos que, por falta de

condies, tiveram seus sonhos restringidos ou
no tiveram oportunidades para alcan-los.
AGRADECIMENTOS
Agradeo, de todo corao, ao meu Deus, que justo, misericordioso e fiel,

digno de todo louvor e adorao, fonte de toda fora que me move para alcanar
meus objetivos e sonhos, sempre atento ao meu clamor e s minhas dificuldades.
A minha famlia, instrumento usado por Deus para ajudar a cuidar de mim,
fonte de carinho, compreenso e superao. Em especial, quero demonstrar minha
gratido ao meu pai, Luiz Antonio, minha me, Edenilza, ao meu irmo, Luiz
Fernando, e s minhas tias Edilzene e Elenilza, sempre solcitos nos momentos
difceis.
Aos educadores que contriburam para minha formao, em especial ao meu
orientador, Fabiano Papaiz, e aos demais professores que me transmitiram uma
parcela de seus conhecimentos no decorrer do curso de Tecnologia em Anlise e
Desenvolvimento doe Sistemas (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 coordenao do Centro de Idiomas da Fundao de Apoio
Educao e ao Desenvolvimento Tecnolgico do Rio Grande do Norte (FUNCERN),
em especial a Fernando Carneiro, por ter acreditado no trabalho de nossa equipe e
nos confiado o desenvolvimento do sistema da organizao que coordena.
Por fim, agradeo a todos que contriburam com minhas experincias de vida,
que me fizeram chorar ou que me ajudaram a vencer, me deixando alguma lio.
RESUMO
Mediante ao contexto da sociedade da informao, na qual cada vez mais

importante gerir e manipular eficaz e eficientemente dados organizacionais, as
instituies necessitam de solues adequadas para coletar (ou recuperar),
processar, armazenar e distribuir informaes, em conformidade com seus
processos de negcio. Tambm no ramo das instituies de ensino, sistemas
computacionais tornaram-se ferramentas diferenciais, muito teis para simplificar a
execuo de atividades do fluxo de trabalho, facilitar o acesso e a manipulao de
dados organizacionais, proporcionar melhores condies de gerncia; 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 avanar no que diz
respeito ao aparato informacional utilizado para apoiar o trabalho na organizao,
haja vista que a estrutura de softwares ento disponvel apresentava vrios
problemas e gerava mltiplos inconvenientes. Com a pretenso de evoluir, a
coordenao do Centro de Idiomas firmou uma parceria com um grupo de
estudantes de desenvolvimento de sistemas a fim de que analisassem a situao,
projetassem, produzissem e implantassem uma soluo em tecnologia da
informao que suprisse as demandas do estabelecimento. Esta soluo vem sendo
desenvolvida desde o ms de setembro de 2010 e tem previso para ser concluda
no ms de dezembro de 2011. O presente trabalho refere-se ao desenvolvimento
desta soluo, enfatizando a adoo de processo de software baseado em
metodologias geis, o escopo e os requisitos do sistema, as tecnologias e
ferramentas utilizadas na construo, a estrutura arquitetural proposta, e os
resultados obtidos at o momento.
Palavras-chave: Aplicaes Coorporativas, Desenvolvimento gil. Plataforma JEE.
ABSTRACT
In the context of the current information society, where it is very important to manage
and manipulate organizational data with efficiently and effectively instruments, the
institutions need appropriate solutions to collect (or retrieve), process, store and
distribute information in accordance with their business processes. Also in
educational institutions, computer systems have become differential mechanisms,
very useful to simplify the execution of workflows, easy access and manipulation of
organizational data, providing better management, improve customer service, among
other activities.
Based on these aspects, in mid-2010, the Centro de Idiomas FUNCERN noted the
need to move in relation to their equipment used to support the work in the
organization, because the available structure of information systems had several
problems and caused many inconveniences. In order to evolve in their computational
processes, the Centro de Idiomas FUNCERN coordination formed a partnership with
a group of System Developers students to analyze the situation, design, produce and
build a technology solution that met the demands of the establishment. This solution
has been started in September 2010 and will be finished in December 2011. This
document refers to the development Processes of this solution, with emphasis on the
adoption of agile methodologies as software process, its scope, system requirements
and technologies used in this project, its proposed architectural structure, and all
results obtained until this moment.
Keywords: Enterprise Applications, Agile Development. JEE platform.
SUMRIO
1.
INTRODUO
1.1.
CONTEXTO E MOTIVAO DO TRABALHO
1.2.
OBJETIVOS
1.3.
METODOLOGIA
10
1.4.
ESTRUTURA
10
2.
FUNDAMENTAO TERICA
12
2.1.
METODOLOGIAS GEIS EM PROCESSOS DE SOFTWARE.
12
2.1.1.
PROCESSO DE SOFTWARE
13
2.1.2.
METODOLOGIAS GEIS
16
2.1.3.
CARACTERSTICAS DAS PRINCIPAIS METODOLOGIAS GEIS: SCRUM E XP
19
2.2.
TECNOLOGIAS JAVA ENTERPRISE EDITION (JEE).
24
2.2.1.
JAVA SERVER FACES (JSF)
25
2.2.2.
ENTERPRISE JAVABEANS (EJB)
31
2.2.3.
JAVA PERSISTENCE API (JPA)
33
3.
ESTUDO DE CASO
37
3.1.
CONTEXTUALIZAO DO PROJETO
37
3.2.
APLICAO DE PROCESSO BASEADO EM METODOLOGIAS GEIS
43
3.3.
ESCOPO E REQUISITOS DO SISTEMA
47
3.3.1.
MDULO COORDENAO
47
3.3.2.
MDULO PBLICO
50
3.3.3.
MDULO ACADMICO
51
3.4.
FERRAMENTAS E TECNOLOGIAS APLICADAS
52
3.5.
ARQUITETURA E MODELAGEM DO SISTEMA
53
3.6.
RESULTADOS OBTIDOS
61
4.
CONCLUSO
78
REFERNCIAS
81
1. INTRODUO
presente
trabalho
consiste,
essencialmente,
em
apresentar
desenvolvimento de uma soluo em sistemas de informao, denominada Soft

Educ GCI, que se prope a resolver problemas e inconvenientes identificados na
execuo do fluxo de atividades do Centro de Idiomas FUNCERN. Este captulo
introdutrio pretende expor uma viso 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 organizao do contedo do trabalho.
1.1. CONTEXTO E MOTIVAO DO TRABALHO
O Centro de Idiomas FUNCERN um programa da Fundao de Apoio

Educao e ao Desenvolvimento Tecnolgico do RN (FUNCERN) sediado nas
dependncias do Instituto Federal de Educao, Cincia e Tecnologia do Rio
Grande do Norte (IFRN) com o intuito de oferecer, ao pblico em geral, cursos de
idiomas de qualidade a um custo mais acessvel. Essa organizao 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
nmero de vagas disponveis. Entre professores dos cursos, funcionrios e bolsistas
que trabalham exercendo funes ligadas a coordenao, o Centro de Idiomas tem
mais de 30 colaboradores. A instituio tem um processo de negcio um tanto
quanto peculiar, incluindo a realizao, a cada semestre, de um sorteio de vagas
para as turmas do 1 nvel dos cursos, e a reserva de um determinado nmero de
vagas em cada turma para bolsistas alunos ou servidores do IFRN.
Para apoiar na gerncia e no desempenho operacional das atividades prprias
de seu funcionamento, o estabelecimento utilizava alguns softwares. No entanto,
ficava ntido o juzo de que a estrutura de software utilizada estava ficando obsoleta,
era problemtica, apresentava diversas incompatibilidades com as caractersticas do
processo de negcio da instituio e gerava alguns inconvenientes, no tendo
acompanhado a evoluo da organizao. Os problemas na referida estrutura de

software sero analisados e detalhados na sesso 3.1 deste trabalho.
Tomando este contexto, a realizao do projeto Soft Educ GCI, que o foco do
estudo deste trabalho, fundou-se em uma parceria estabelecida entre a instituio
mencionada e um grupo de alunos do Curso Superior de Tecnologia em Anlise e
Desenvolvimento de Sistemas (TADS) do IFRN, no intuito de construir uma estrutura
de software mais evoluda e apropriada para apoiar o funcionamento do Centro de
Idiomas FUNCERN. Tal parceria foi firmada em setembro de 2010, e prev a
instalao final do sistema, de acordo com o escopo previsto atualmente, no ms 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
perodo do curso de TADS, cujo objetivo proporcionar aos alunos uma espcie de
prtica profissional, atravs da aplicao dos contedos ministrados, durante o
semestre letivo, ao desenvolvimento de sistemas. Dessa forma, o projeto seria uma
boa oportunidade para promover a extenso do trabalho acadmico ao contexto de
um problema real em um ambiente de negcios, e para aplicar as tecnologias Java
para
desenvolvimento
corporativo
estudadas,
bem
como
um
mtodo
de
desenvolvimento de software flexvel e adaptvel as caractersticas 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 soluo

computacional que: Apie o desempenho das atividades prprias 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, eficincia e eficcia no gerenciamento das
informaes e na execuo do trabalho dentro da organizao; Satisfaa seus
usurios e cliente.
10
Os demais objetivos so: Desenvolver e apresentar um estudo sobre

metodologias geis para o desenvolvimento de software; Desenvolver e apresentar
um estudo sobre tecnologias da plataforma JEE para o desenvolvimento de
aplicaes coorporativas; Elucidar e descrever os requisitos esperados para sistema
pretendido; Descrever a aplicao de um processo de software que une o ciclo do
Scrum com prticas do XP e se utiliza de alguns artefatos oriundos de processos
tradicionais; Descrever sobre a utilizao de ferramentas e tecnologias adotadas no
processo; Apresentar a arquitetura do sistema em desenvolvimento.
1.3. METODOLOGIA
Inicialmente, foi realizado um estudo do contexto do projeto, das caractersticas

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 tambm alguns
temas complementares ou suplementares a eles, para que pudessem ser aplicados
ao desenvolvimento do projeto Soft Educ GCI.
Aps isto, iniciou-se a fase do desenvolvimento do projeto, baseado no ciclo do
Scrum e em algumas prticas XP (essas metodologias de desenvolvimento de
software esto descritas na sub-seo 2.1.3 deste trabalho, e a forma como so
aplicadas ao projeto explicada na seo 3.2).
Ento, para concluir o trabalho, foi produzido o presente documento,
constitudo pelos principais aspectos referentes aos estudos realizados e relativos
aplicao do conhecimento obtido no desenvolvimento do trabalho.
1.4. ESTRUTURA
Alm deste capitulo introdutrio, este TCC contm mais trs captulos, que
estruturam o contedo conforme explicado a seguir. O capitulo 2 descreve os
11
resultados dos estudos sobre processos de software, com foco em metodologias

geis, e sobre tecnologias da plataforma JEE ou complementares. O captulo 3
apresenta o estudo de caso que constitui o foco deste trabalho, dissertando sobre a
aplicao de um processo de software, de tcnicas, tecnologias e ferramentas no
desenvolvimento do sistema Soft Educ GCI. Por fim, O captulo 4 expe as
concluses em relao ao trabalho, indicando a medida em que os resultados
apresentados foram positivos ou no, e estabelecendo uma previso para os
possveis rumos quanto a continuidade do trabalho.
12
2. FUNDAMENTAO TERICA
Para melhor compreenso do estudo de caso que compreende o foco deste

trabalho, faz-se necessrio o conhecimento de alguns conceitos e idias as quais
fundamentam os aspectos abordados no captulo 3, sobre o desenvolvimento do
projeto em questo. Sendo assim, este segundo captulo objetiva explicar alguns
fundamentos centrais envolvidos na construo do Soft Educ GCI. Para tanto,
subdividir-se- em duas sees, os quais relataro, consecutivamente, a respeito de:
1) Processos de desenvolvimento de software, com foco em metodologias geis; e
2)
Tecnologias
da
plataforma
Java
para
desenvolvimento
de
aplicaes
coorporativas (JEE).
2.1. METODOLOGIAS GEIS EM PROCESSOS DE SOFTWARE.
Desenvolver
um
software
consiste
fundamentalmente
em
transformar
requisitos dos clientes ou usurios em uma soluo 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 inteno de
tornar mais prtica e eficiente a execuo de alguma(s) atividade(s) em um dado
contexto. Entretanto, dependendo da dimenso do problema a resolver e dos nveis
dos requisitos estabelecidos, o desenvolvimento de sistemas pode tornar-se uma
atividade bem complexa, envolvendo uma vasta gama de profissionais, e inmeras
possibilidades de decises, as quais podem implicar no sucesso ou fracasso em um
projeto.
Mediante a esta complexidade, so necessrios meios para se organizar a
criao de produtos de software. A desorganizao na produo destes
desencadeia problemas como: discrepncia em relao aos requisitos do usurio;
ocorrncia demasiada de erros; excesso de gastos em relao oramento estimado;
atraso quantos aos prazos estabelecidos; criao de produtos de difcil manuteno;
entre outros. Tais problemas ficaram bem evidentes na indstria de software na
dcada de 1960, quando foi evidenciada a crise do software. Para tentar solucion-
13
los, houve, e ainda h um esforo no intuito de gerar processos e metodologias

apropriadas para promoo do desenvolvimento de software de qualidade,
apropriados para solucionar os problemas do usurio, respeitando prazos e custos
estabelecidos.
2.1.1. Processo de Software
Define-se processo de software como o conjunto de tarefas de Engenharia de

Software necessrias para transformar os requisitos dos usurios em software
(Portela, 2009). Trata-se da aplicao de uma metodologia de trabalho para
coordenar as aes 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,
caractersticas prprias. 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.
No existe um processo de software que possa ser genericamente aplicado
a todos os projetos, visto que nenhum projeto idntico ao outro.
Variaes nas polticas e procedimentos organizacionais, mtodos e
estratgias de aquisio, tamanho e complexidade do projeto, requisitos e
mtodos de desenvolvimento do sistema, equipe (pessoas), entre outros
fatores, influenciam na forma como um produto de software adquirido,
desenvolvido, operado e mantido. (Portela, 2009)
2.1.1.1. Conceitos Fundamentais Inerentes a Processos de Software
Para ajudar a esclarecer as idias a respeito da composio de um processo

de software conveniente observar-se tambm alguns conceitos intimamente
associados, tais como: atividades previstas, artefatos consumidos e produzidos,
14
procedimentos adotados, recursos empregados, paradigma e tecnologia aplicados, e

modelo de ciclo de vida utilizado. Abaixo, a explicao sobre alguns dos itens
mencionados, segundo Portela (2009):
Atividades: So as tarefas ou trabalhos a serem realizados. A realizao
de uma atividade pode adotar um procedimento, requer recursos e
geralmente utiliza ou gera artefatos. Pode-se, ainda, decomp-la em subatividades. Alm disso, atividades podem depender da finalizao de
outras atividades, denominadas pr-atividades. As atividades podem ser
classificadas em: atividades de gerncia, atividades de construo,
atividades de suporte e manuteno e atividades de avaliao da 19
qualidade. Como exemplo de atividade realizada no projeto de software
pode-se citar Especificar os Requisitos;
Artefatos: So produtos de software gerados ou consumidos durante a
execuo das atividades. Os artefatos podem ser classificados em:
artefatos de cdigo, componentes de software, documentos, diagramas,
modelos, etc. Para a atividade citada no exemplo anterior, pode-se ter
como artefato consumido o Relatrio de Entrevista com o Usurio e como
artefato gerado o documento Especificao dos Requisitos;
Procedimentos: So condutas bem estabelecidas e ordenadas para a
realizao de atividades do processo. Quanto sua natureza,
procedimentos podem ser classificados em: mtodos, tcnicas e diretrizes.
Seguindo o exemplo anterior, para executar a atividade definida pode-se
definir um procedimento que faa uso da UML Unified Modelling
Language para a definio de cenrios das necessidades do usurio;
Recursos: Qualquer fator necessrio execuo de uma atividade, mas
que no seja um insumo para a atividade. Os recursos podem ser
classificados em: recursos de hardware, recursos de software e recursos
humanos. Finalizando a caracterizao 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
Tambm importante ressaltar que existem algumas atividades comuns a qualquer

processo, conforme indicado em Soares (2004):
Especificao de Software: definio das funcionalidades (requisitos) e
das restries do software. Geralmente uma fase em que o
desenvolvedor conversa com o cliente para definir as caractersticas do
novo software.
Projeto e Implementao de Software: o software produzido de acordo
com as especificaes. Nesta fase so propostos modelos atravs de
diagramas, e estes modelos so implementados em alguma linguagem de
programao.
Validao de Software: o software validado para garantir que todas as
funcionalidades especificadas foram implementadas.
Evoluo de Software: o software precisa evoluir para continuar sendo til
ao cliente.
15
2.1.1.2. Tipos de Processos de Software
Existem vrios 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, tambm conhecidos como processos pesados,
valorizam a idia 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 incio das atividades de projeto e implementao do
software. A documentao considerada um fator de grande importncia durante a
execuo de processos nessa linha.
A especificao 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 anlise e projeto bastante demorado e de difcil
manuteno caso surja um novo requisito ou alguma especificao 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 essncia das metodologias tradicionais o

modelo de desenvolvimento de software em cascata, no qual uma sequncia rgida
de etapas deve ser seguida durante o processo: especificao de requisitos, projeto,
implementao, teste, implantao e manuteno. Ao final de cada etapa os
artefatos produzidos precisam ser aprovados para que a etapa seguinte possa ter
incio.
16
Figura 1. Esquema de representao do modelo de desenvolvimento de software em cascata.
Fonte: http://diegoduarte88.wordpress.com/modelo-de-desenvolvimento-de-software-cascata/
(12/06/2011)
Por outro lado, tm-se os processos baseados em metodologias geis,

tambm chamados de processos leves, os quais valorizam principalmente: a
capacidade de adaptar-se a mudanas de requisitos do software; e a eficincia na
produo. O tpico seguinte deste trabalho abordar com mais profundidade as
caractersticas deste tipo de processos.
2.1.2. Metodologias geis
Os modelos tradicionais de desenvolvimento de software foram adotados em

grande escala pela indstria de software a partir da dcada de 1970. Porm, em
meados da dcada de 1990, observou-se o contexto de um ambiente organizacional
cada vez mais dinmico e instvel, e de problemas cada vez maiores nos projetos
aplicadores de processos tradicionais, referentes fatores como: extrapolao de
oramentos; atrasos nas entregas; ocorrncia de bugs; e insatisfao de clientes.
Mediante a essa situao, integrantes da comunidade de software comearam a
questionar esses processos clssicos, julgando-os impraticveis em algumas
17
situaes. Dessa forma, especialistas passaram a buscar alternativas para tornar a

produo de software mais eficiente e eficaz, criando mtodos prprios para isso.
O agrupamento desses novos mtodos e dos ideais que os embasavam
comearam a construir o conceito de metodologias geis. Esse conceito
disseminava as idias de aumentar a capacidade de adaptao a mudanas, e de
no permitir que a rigorosidade dos processos de software bloqueie o avano
significativo na produo. A idia de agilidade no se fazia contrria
documentao, mas contrria documentao em excesso, aos documentos que
pouco ou nada agregavam valor ao processo de produo e s o deixavam mais
pesado.
Assim, o novo enfoque para o desenvolvimento de software seria baseado
em: flexibilidade; habilidades de comunicao; capacidades de resposta a mudanas
e de adaptao a situaes adversas. Tudo isso buscando oferecer produtos e
servios de valor para o mercado em curtos perodos de tempo, no contexto de um
turbulento ambiente de negcios (Portela, 2009).
Para complementar, vale enfatizar que as propostas geis indicavam a
necessidade de balancear flexibilidade, estrutura e estabilidade, pois a ausncia de
um destes dois ltimos fatores pode levar ao caos, mas, por outro lado, a estrutura
em excesso gera rigidez (Portela, 2009), o que pode se tornar um gargalo em um
projeto de software.
2.1.2.1. Manifesto gil
Para discutir as novas idias e abordagens que surgiram em resposta as

limitaes dos processos tradicionais para desenvolvimento de software, criadores e
representantes de vrios mtodos geis se reuniram nos Estados Unidos, no ano de
2001. Como resultado deste encontro, surgiu a Aliana gil e foi publicado um
documento que oficializava e sintetizava os novos ideais estabelecidos pelo grupo, o
Manifesto para Desenvolvimento gil de Software, mais conhecido como Manifesto
gil.
Nesse documento, alguns valores foram colocados em detrimento de outros:
Indivduos e interao entre eles mais que processos e ferramentas; Software
18
em funcionamento mais que documentao abrangente; Colaborao com o

cliente mais que negociao de contratos; Responder a mudanas mais que
seguir um plano (Manifesto gil, 2001).
Exps-se tambm que os itens mais a direita tinham valor significativo, porm
que eram menos essenciais que os itens mais a esquerda (em negrito).
No encontro, os participantes demonstraram-se preocupados em deixar clara
a importncia da metodologia, do planejamento e da documentao. Entretanto,
defenderam-se os seguintes pontos de vista em relao a estes fatores: a
metodologia teria que contribuir para a eficincia e eficcia, e nunca ao contrrio; o
planejamento deveria ser refeito ciclicamente, tendo em vista que, em um ambiente
de negcios turbulento, o planejamento e a previsibilidade em longo prazo so
bastante limitados; a documentao no um fator primordial e indispensvel por si
s, mas s necessria na medida em que agregar valor ao processo de
desenvolvimento ou ao produto.
Princpios base do manifesto gil
Ns seguimos os seguintes princpios:
Nossa maior prioridade satisfazer o cliente, atravs da entrega
adiantada e contnua de software de valor.
Aceitar mudanas de requisitos, mesmo no fim do desenvolvimento.
Processos geis se adquam a mudanas, para que o cliente possa
tirar vantagens competitivas.
Entregar software funcionando com frequncia, na escala de semanas
at meses, com preferncia aos perodos mais curtos.
Pessoas relacionadas a negcios e desenvolvedores devem trabalhar
em conjunto e diariamente, durante todo o curso do projeto.
Construir projetos ao redor de indivduos motivados. Dando a eles o
ambiente e suporte necessrio, e confiar que faro seu trabalho.
O Mtodo mais eficiente e eficaz de transmitir informaes para, e por
dentro de um time de desenvolvimento, atravs de uma conversa
cara a cara.
Software funcional a medida primria de progresso.
Processos geis promovem um ambiente sustentvel. Os
patrocinadores, desenvolvedores e usurios, devem ser capazes de
manter indefinidamente, passos constantes.
Contnua ateno excelncia tcnica e bom design, aumenta a
agilidade.
Simplicidade: a arte de maximizar a quantidade de trabalho que no
precisou ser feito.
As melhores arquiteturas, requisitos e designs emergem de times autoorganizveis.
Em intervalos regulares, o time reflete em como ficar mais efetivo,
ento, se ajustam e otimizam seu comportamento de acordo.
(Manifesto gil, 2001)
19
2.1.3. Caractersticas das Principais Metodologias geis: Scrum e XP
Os mtodos geis Scrum e Extreme Programming (XP) so, atualmente, os

mais conhecidos e utilizados na comunidade de desenvolvimento de software.
Ambos esto calcados nos princpios estabelecidos no Manifesto gil, valorizando
fatores como aproximao entre clientes e desenvolvedores, entregas frequentes de
pequenos incrementos no software, e melhoria continua do processo de
desenvolvimento. 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 flexvel, tornando possvel e indicado adaptar seu uso de acordo com o contexto
do projeto no qual se deseja utiliz-lo. Ele procura fornecer meios de tornar a
produo eficiente mesmo mediante imprevisibilidade e s mudanas nos
requisitos. O Scrum no determina tudo o que se deve fazer nem as tcnicas a
serem adotadas nos diversos momentos do desenvolvimento, mas oferece um
conjunto prticas as quais permitem que a equipe: se situe em relao ao estado
das atividades do projeto; tenha conscincia dos seus objetivos, metas e nvel de
produtividade; possa fazer estimativas prximas da realidade; e tome as decises
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 prticas para
atingir o sucesso. Entretanto, as decises de quando e como us-lo, quais
tticas e estratgias seguir para obter produtividade e realizar as entregas
ficam por conta de quem estiver o aplicando. O conhecimento das suas
prticas permite a aplicao destas de forma variada e este um dos
aspectos positivos do Scrum, a adaptabilidade. (Portela, 2009)
Neste framework, h a definio clara de trs papis dentro da equipe ou time

de desenvolvimento. O Product Owner o responsvel por representar os interesses
do cliente junto ao time de desenvolvedores, em relao a requisitos, prazos,
20
oramento, avaliao do produto, etc. O Scrum Master o responsvel pelas

funes de gerncia e de resoluo de conflitos internos ao time. E os
Desenvolvedores so os responsveis pelas decises tcnicas, por estimar tempo
necessrio para atividades, por projetar e implementar funcionalidades do sistema.
Em sntese, e de um modo genrico, 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 Estrias do Usurio) e
caractersticas requeridas pelo cliente, no comeo do projeto. Este artefato ser
administrado durante o todo o projeto, sendo frequentemente atualizado. Depois de
listadas as estrias do usurio, o esforo para realiz-las estimado pelos
desenvolvedores, que, juntos com o Product Owner, agrupam as estrias em vrios
Sprints. Um Sprint consiste em uma iterao que deve durar entre 2 e 4 semanas,
de modo que, ao final deste intervalo de tempo, tenha-se uma verso usvel do
produto, para entregar ao Product Owner.
Antes de iniciar cada Sprint, h uma reunio 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 caractersticas do Backlog do Produto devem ser implementadas
durante a iterao, construindo assim o Sprint Backlog. Aps o Product Owner
expressar ao restante da equipe suas prioridades, Scrum Master e desenvolvedores
dividem as estrias em atividades necessrias e estimam o esforo para cumpri-las,
adequando a composio do Sprint Backlog de acordo com o esforo previsto para o
Sprint.
Durante
Sprint,
Scrum
Master
desenvolvedores
assumem
espontaneamente e executam as atividades previstas no plano. H a realizao de

reunies dirias (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
reunies devem ser rpidas, 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 grfico chamado Sprint Burndown, que indica o
progresso dirio da equipe em relao ao esforo estimado para as cumprir as
tarefas.
21
Ao final de cada Sprint deve ser realizada uma reunio de reviso 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. Aps isso,
deve-se realizar uma reunio de retrospectiva de Sprint (Sprint Retrospective),
visando identificar os pontos positivos e negativos, o que deve ser mantido e o que
no deve se repetir, e tambm absorver lies e aprendizado, com o objetivo de
melhorar o processo e o produto nos Sprints seguintes.
Figura 2. Representao do ciclo do Scrum.
Fonte: http://tasafo.wordpress.com/tag/scrum/ (12/06/2011)
2.1.3.2. Extreme Programming (XP)
O XP, que foi criado no final da dcada de 1990, trata-se de uma metodologia
gil para equipes pequenas e mdias que desenvolvem software baseado em
requisitos vagos e que se modificam rapidamente (Soares, 2004). Este mtodo tem
o objetivo de promover a produo de software de forma rpida e em ciclos de
desenvolvimento cada vez mais curtos. Dentre os ideais, esto: produzir primeiro o
que agrega mais valor ao produto; adaptar-se ao inesperado; priorizar as atividades
de
codificao
(programming).
Para
tanto,
baseia-se
em
quatro
valores
22
fundamentais e prope a aplicao doze prticas bem estabelecidas, na conduo

do processo.
Os valores so: feedback, comunicao, simplicidade e coragem (Soares,
2004).
O feedback consiste na busca constante por respostas do cliente em relao
ao que foi produzido, de modo que ele observe e utilize, o quanto antes, um nmero
mnimo de funcionalidades desenvolvidas da forma mais simples possvel, para,
ento, indicar o que, segundo sua ptica, necessita ser feito a mais em relao s
referidas funcionalidades. Dessa forma, o cliente guiar o desenvolvimento de
acordo com a evoluo da formao de sua viso sobre o produto, evitando
implementaes desnecessrias e maiores custos para ajustes.
A comunicao mais eficiente possvel um objetivo prioritrio de equipes XP,
a fim de que seus integrantes possam compartilhar conhecimento, se ajudarem
mutuamente dentro do processo, etc. A inteno usar, ao mximo, os melhores
canais comunicativos disponveis: a comunicao pessoal prefervel em relao
comunicao por telefone, a qual prefervel em relao comunicao por e-mail.
A comunicao 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 refatoraes (Refectoring). Buscase 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 modificaes necessrias do que implementar
algo complicado hoje que talvez no venha a ser usado, sempre
considerando que requisitos so mutveis. (Soares, 2004)
A coragem fator determinante para membros de times XP, uma vez que a
metodologia prope, atravs de seus valores e prticas, uma quebra de paradigmas
relacionados s abordagens tradicionais para desenvolver sistemas.
Abaixo, esto listadas as 12 prticas XP, conforme apresentado em Portela
(2009):
1. Jogo do Planejamento: no incio de cada interao, clientes, gerentes e
programadores se encontram para definir, estimar e priorizar os
23
requerimentos. A idia que se elabore um plano aproximado no incio

do projeto e se faa um refinamento medida que as necessidades e
requisitos se tornem mais conhecidos;
2. Programao em Pares: dois programadores utilizando o mesmo
computador escrevem o cdigo;
3. Pequenas Verses: as verses devem ser to pequenas quanto
possvel e trazerem valor para o negcio. Uma verso inicial do
software deve ser colocada em produo aps um pequeno nmero de
interaes e, em seguida, outras verses devem ser disponibilizadas
to logo faa sentido;
4. Metforas: clientes, gerentes e programadores criam metforas ou
conjunto de metforas para modelagem do sistema;
5. Projeto Simples: os programadores so estimulados a desenvolver o
cdigo do software o mais simples possvel;
6. Testes: os programadores devem criar os testes de unidade antes ou
mesmo durante o desenvolvimento do cdigo do sistema. Os clientes,
por sua vez, escrevem os testes de aceitao. Ao final de cada iterao
a bateria de testes deve ser conduzida;
7. Reegenharia de Software: o cdigo deve ser constantemente
melhorado, sem que a funcionalidade do seja alterada, pela equipe do
projeto, o tempo todo;
8. Integrao Contnua: os programadores devem integrar os novos
cdigos ao software to rapidamente e com a maior freqncia
possvel;
9. Propriedade Coletiva do Cdigo: o cdigo do programa deve ser
propriedade de toda a equipe e qualquer integrante pode fazer
alteraes sempre que for necessrio;
10. Cliente no Local: o cliente deve trabalhar com a equipe de projeto a
todo momento, respondendo perguntas, realizando testes de aceitao
e assegurando que o desenvolvimento do software esteja sendo feito a
contento;
11. Semana de 40 horas: como trabalhar por longos perodos reduz o
desempenho, o contedo de cada iterao deve ser planejado de
forma a no haver necessidade de realizao de horas extras;
12. Padro de Codificao: no incio do projeto deve ser criado um padro
de codificao, simples e aceito por toda a equipe, que dever ser
seguido de forma a padronizar e a auxiliar a conduo do trabalho
24
2.2. TECNOLOGIAS JAVA ENTERPRISE EDITION (JEE).
cada vez mais vigente a necessidade de se construir aplicaes distribudas

transacionais e portveis com menos tempo e recursos, utilizando-se de vantagens,
como confiabilidade, segurana e velocidade, oferecidas por tecnologias para
programao do lado servidor. sob esta perspectiva que a plataforma Java
Enterprise Edition coloca-se com o objetivo de fornecer aos desenvolvedores um
conjunto avanado de APIs (Application Programming Interfaces ou Interfaces para
Programao de Aplicaes) para reduzir a complexidade, melhorar o desempenho
e reduzir o tempo de desenvolvimento de aplicaes.
Esta plataforma define uma arquitetura baseada em um modelo distribudo
multicamadas para implementao de servios em aplicaes corporativas, de modo
a proporcionar vantagens, como escalabilidade, acessibilidade e gerenciamento
necessrio. A aplicao estruturada por meio de componentes que podem se
situar em camadas distintas, de acordo com a funo que exercem. Estas camadas
representam ambientes de execuo diferentes, quais sejam a mquina cliente, o
container Web e o container EJB, estes dois ltimo localizados no servidor JEE.
Figura 3. Arquitetura de Componentes JEE.
Fonte: The Java EE 6 Tutorial (2011)
25
As prximas subsees deste trabalho abordaram mais detalhadamente

algumas das tecnologias usadas no projeto Soft Educ GCI que compem esta
plataforma de desenvolvimento.
2.2.1. Java Server Faces (JSF)
Vrias tecnologias surgiram com a finalidade de evoluir o modelo de

programao para aplicaes web, tentando abstrair, simplificar e potencializar a
implementao delas. Na plataforma Java, a especificao Java Servlet foi a
tecnologia precursora. Em seguida, vieram as pginas JSP, as quais passaram a ser
utilizada junto aos Servlets. No entanto, os seguintes problemas, decorrentes do uso
destas tecnologias, tornaram-se cada vez mais evidentes: mistura entre cdigos de
apresentao (Interface Grfica do Usurio) e de lgica de negcio, dificuldades na
manuteno das aplicaes, baixa produtividade no desenvolvimento, entre outros.
Mediante esse contexto, o JSF foi apresentado como um framework de
componentes do lado servidor para a construo de aplicaes web baseadas em
tecnologias Java (The Java EE 6 Tutorial, 2011). Constitudo sobre o padro
arquitetural
MVC
(Model-View-Controller
ou
Modelo-Viso-Controlador),
caracterizando-se por uma proposta de programao baseada em eventos, de forma

similar ao que acontece com o uso da API Java Swing para desenvolvimento de
interfaces grficas em aplicaes desktop, o JSF busca abstrair fatores relacionados
ao modelo de desenvolvimento proveniente do uso das tecnologias anteriores (JSP
e Servlets), elevando o nvel da programao, tornando mais fcil e prtico a
produo de sistemas web.
Essencialmente, este framework fornece uma API para: representao de
componentes e gerncia do estado deles, manipulao de eventos, converso de
dados, validao no lado servidor, definio de navegao entre pginas,
internacionalizao da aplicao e extensibilidade dos componentes (The Java EE 6
Tutorial, 2011).
Para a camada de apresentao, o JSF oferece um conjunto de tags XML para
representao de componentes em pginas web. Estas tags possibilitam a
26
associao de componentes das pginas com objetos do lado servidor atravs do

uso de linguagem de expresso (Expression Language ou, simplesmente, EL), e
esto disponveis por meio das Tag Libraries, que so bibliotecas de tags a serem
declaradas nas pginas.
Com a finalidade de possibilitar uma compreenso mais prtica do framework,
na sua verso 1.2, verso usada no desenvolvimento do projeto Soft Educ GCI,
segue-se algumas explicaes baseadas em trechos de cdigo de uma aplicao
JSF simples. A figura a seguir apresenta um trecho de cdigo de uma pgina
XHTML que usa alguns componentes JSF:
Figura 4. Uso de componentes JSF
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>
Fonte: Autoria prpria (2011)
A figura 4 exibe a codificao de uma pgina simples, com alguns

componentes JSF. Nas linhas 2 e 3, ocorre a declarao das duas Tag Libraries
padro do JSF, com seus respectivos prefixos, pelos quais sero referenciadas ao
longo do cdigo, e URIs. A partir disso, os componentes integrantes desses pacotes
de tags podero 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 usurio a um objeto do modelo que est no lado
servidor (Backing Bean), atravs de EL. Com a expresso #{exemploMB.nome}, o
27
valor inserido no campo de texto deve ser atribudo a propriedade nome do

Managed Bean declarado como exemploMB, durante a fase de atualizao dos
valores do ciclo de vida do JSF.
Os Managed Beans so classes Java que exercem a funo de controladores
em uma aplicao JSF. Eles contm os objetos do domnio que sero ligados aos
componentes JSF, e tambm os manipuladores de aes (Action Handlers), que so
mtodos invocados a partir de um evento, como o clique do usurio em um boto.
Voltando ao exemplo, na linha 13, observa-se um componente que representa
um boto em uma pgina HTML. Este boto, quando clicado, invocar o mtodo
manipularEvento() do Managed Bean exemploMB, conforme indicado na
expresso #{exemploMB.manipularEvento}, declarada como valor do atributo
action do componente.
O Managed Bean exemploMB pode ser implementado como demonstrado
na classe conforme a figura 5:
Figura 5. Exemplo da implementao de um Managed Bean
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
public class ExemploMB {

private String nome;
private String frase;
public String getNome() {
return nome;
}
public void setNome(String nome) {
this.nome = nome;
}
public String getFrase() {
return frase;
}
public String manipularEvento() {
frase = "Oi, meu nome " + nome + ".";
return "pagina2";
}
}
A classe apresentada contm as propriedades nome e frase, as quais

podem ser acessadas pelos componentes JSF presentes em uma pgina web por
meio dos mtodos Get, para recuperar o valor da propriedade, e Set, para atribuir
28
um novo valor a ela. Com isso, percebe-se que, no exemplo discutido, um

componente de uma pgina JSF pode recuperar o valor da propriedade nome e
tambm alterar valor dela, pois o atributo nome da classe ExemploMB tem os
mtodos Get e Set correspondente. J a propriedade frase pode ter seu valor
recuperado, mas no alterado, pois o atributo frase s tem o mtodo Get, mas no
o Set.
O mtodo public String manipularEvento() um Action Handler, o
qual pode ser invocado aps lanamento de um evento por um componente de uma
pgina JSF. Ele faz um processamento com os valores dos atributos do Managed
Bean e retorna uma String, que servir para indicar a pgina que deve ser
apresentada aps o processamento do mtodo, conforme as regras de navegao
configuradas no arquivo faces-config.xml.
Este arquivo, o faces-config.xml, o principal arquivo de configurao de
uma aplicao JSF. l onde so declarados os Managed Beans e as regras de
navegao, conforme demonstrado na figura abaixo:
Figura 6. Declarao de Managed Bean e definio de regra de navegao no faces-config.xml
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>
29
Entre as linha 06 e 10, na figura 03, declarado um Managed Bean, com a

indicao do nome pelo qual ser referenciado na aplicao, do nome completo da
classe que onde est sua implementao e do seu escopo, que pode ser de sesso
(session), requisio (request) ou aplicao (application). Da linha 12 at a 18 temse a declarao de uma regra de navegao, indicando que quando uma requisio
partir da View com o endereo /pagina1.xhtml e o Action Handler responsvel por
tratar a requisio retornar a String pagina2, deve-se exibir a View identificada pelo
endereo /pagina2.xhtml. Alm de servir para declarao de Managed Beans e de
regras de navegao, o faces-confi.xml tambm usado para declarar
componentes customizados, tais como conversores e validadores.
Outro elemento importante em uma aplicao JSF o arquivo descritor de
implantao web.xml. l que declarado o Servlet responsvel por receber e
processar todas as requisies recebidas do cliente, a partir de componentes JSF, o
Faces Servlet.
Figura 7. Declarao do Faces Servlet no descritor de implantao web.xml
1
2
3
4
5
6
7
8
9
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
2.2.1.1. RichFaces
O RichFaces um projeto de cdigo aberto desenvolvido pela JBoss para

auxiliar na construo de aplicaes de internet ricas com o JSF. Consiste em um
conjunto de componentes avanados de interface de usurio com o intuito de
possibilitar uma fcil integrao do potencial da tecnologia AJAX a aplicaes JSF,
sem a necessidade de recorrer a JavaScript para essa finalidade. Alm disso,
30
tambm prope facilitar o trabalho de padronizar as interfaces de uma aplicao

JSF, atravs do suporte a Skins.
Este framework disponibiliza aos desenvolvedores duas Tag Libraries, a Core
Ajax, geralmente referenciada pelo prefixo a4j, que contm componentes para
configurar requisies AJAX nas pginas; e a UI, comumente referenciada pelo
prefixo rich, que dispe de recursos para adicionar caractersticas de interfaces
ricas a aplicaes JSF. Pode-se utilizar o RichFaces em aplicaes JSF sem
maiores dificuldades a partir da importao de algumas bibliotecas para o projeto e
da realizao de algumas configuraes no arquivo descritor de implantao da
aplicao, o web.xml.
2.2.1.2. Facelets
Nas primeiras verses do JSF, 1.1 e 1.2, a tecnologia padro para definio
da camada de View era o JSP. Porm o Facelets surgiu como uma forte alternativa
ao padro estabelecido, de modo a proporcionar bastantes vantagens quando usado
junto ao JSF. A prova do reconhecimento dessas vantagens foi a adoo desta
tecnologia como padro para definio da camada de viso do JSF na verso 2.0.
O Facelets uma linguagem de declarativa desenvolvida e apropriada para a
construo da camada de viso do JSF. Entre as principais caractersticas
relacionadas a esta tecnologia esto as seguintes: uso do XHTML como formato dos
arquivos referentes s pginas web criadas; possibilidade de elaborar, de forma
prtica, templates para componentes e pginas; possibilidade de criar e reusar
componentes compostos por outros; disponibilizao de uma Tag Library prpria
para uso complementar aos componentes JSF; amplo suporte linguagem de
expresso e ao uso de componentes AJAX; ampla adaptabilidade ao ciclo de vida
JSF; dentre outros.
Entre as vantagens do uso dessa tecnologia, pode-se citar a capacidade de
promover o reuso de cdigo atravs de templates e da composio de componentes;
o menor tempo necessrio para a compilao e melhor desempenho na
renderizao de componentes em relao ao JSP; a independncia em relao ao
container web; a validao de EL em tempo de compilao; a grande preciso no
31
apontamento de erros, de modo a facilitar a depurao. Em suma, o uso do Facelets

reduz o tempo e o esforo que precisa ser gasto no desenvolvimento e implantao
(The Java EE 6 Tutorial, 2011).
2.2.2. Enterprise JavaBeans (EJB)
A tecnologia EJB prope um ambiente diferenciado para a execuo de

componentes de negcio de aplicaes corporativas Java. Este ambiente
chamado de container EJB, que uma das partes dos servidores de aplicaes
corporativas em conformidade com as especificaes JEE, tais como o Jboss
Application
Server
GlassFish
Server.
container
EJB
assume
responsabilidade por prover importantes servios para os Enterprise Beans como

so denominados os componentes implementados com a tecnologia , tais como:
gerenciamento de transaes, controle de instncias e segurana. Isso faz com que
a implementao desses servios seja abstrada para os desenvolvedores das
aplicaes, de modo que estes possam se concentrar mais em resolver problemas
decorrentes da lgica de negcio.
Um Enterprise Bean pode ser classificado em dois tipos principais, Session
Bean (Bean de Sesso) ou Message-drive Bean (Bean Orientado a Mensagem).
2.2.2.1. Bean de Sesso
Os Beans de sesso so objetos de classes implantadas no servidor que

realizam tarefas a partir de solicitaes de clientes. Eles encapsulam a lgica de
negcio de uma aplicao, se responsabilizando pela execuo de processos
complexos. Podem ser do tipo Stateful, Stateless, ou Singleton, e seus mtodos
pblicos podem ser invocados programaticamente caso estejam declarados em suas
interfaces, as quais podem ser do tipo Local, Remota ou Web Service.
Um Bean de sesso Stateful atende s requisies de apenas um cliente,
mantendo o estado conversacional com ele, de forma que os valores de seus
32
atributos so mantidos entre as requisies realizadas desde sua instanciao,

provocada pela primeira requisio, at a desconexo do cliente. Um Stateless, por
sua vez, compartilhado entre vrios clientes e no mantm estado conversacional
com nenhum, de modo que, ao final da execuo de cada mtodo, os estado de
seus atributos no so mantidos.
Exceto durante a invocao de mtodo, todas as instncias de um Bean
Stateless so equivalentes, permitindo que o container EJB atribua uma
instncia para qualquer cliente. Devido ao fato de poderem suportar vrios
clientes, Beans Stateless podem oferecer uma melhor escalabilidade para
aplicaes que requerem um grande nmero de clientes (The Java EE 6
Tutorial, 2011)
Um Bean de sesso do tipo Singleton s tem uma instncia para toda a

aplicao, a qual a responsvel por atender as requisies de todos os clientes.
Este tipo de Bean mantm os estado de suas variveis entre as requisies feitas a
ele.
Beans de sesso Singleton so projetados para circunstncias em que
uma instncia de Bean nica acessada por clientes em condies de
concorrncia. (The Java EE 6 Tutorial, 2011)
Vale tambm ressaltar que um Bean Stateless, bem como um Singleton

podem implementar um web Service, mas um Stateful no.
2.2.2.2. Bean Orientado a Mensagem
Os Beans orientados a mensagem so componentes que possibilitam o

processamento de mensagens de forma assncrona por aplicaes JEE. Eles
geralmente atuam como listeners de mensagens de um JMS (Java Messages
Service ou Servio de Mensagens Java), que so enviadas por clientes. Alm de
mensagens JMS, este tipo de Bean pode tambm processar mensagens de outros
tipos de MOM (Message-Oriented Middleware).
Diferentemente do que ocorre com os Beans de sesso, os componentes
clientes no acessam os mtodos de Beans de mensagem diretamente atravs de
interfaces. Ao invs disso, enviam mensagens por meio de um middleware, cada
uma destinada ao Bean que deve process-la. Quando a mensagem chega, o
33
container invoca o mtodo onMessage do Bean destinatrio, que deve process-la

de acordo com as regras de negcio da aplicao, podendo, para isso, chamar
mtodos auxiliares, invocar um Bean de sesso 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 aplicaes de software desenvolvidas, assim como o paradigma da
programao orientada a objetos (POO) uma tendncia largamente utilizada. No
entanto, o paradigma relacional e o orientado a objetos possuem caractersticas e
operam sobre conceitos bastante distintos, de forma a tornar complexa as operaes
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 programao orientada a objetos. Segundo a prpria
documentao oficial da tecnologia (The Java EE 6 Tutorial, 2011), a JPA fornece
um mecanismo para desenvolvedores realizarem um mapeamento objeto-relacional
e facilita o gerenciamento de dados relacionais em aplicaes Java.
O modelo da JPA simples, elegante, poderoso e flexvel, constituindo-se com
base no mapeamento objeto-relacional realizado para as entidades, que so classes
Java simples, representantes dos objetos persistentes do modelo de domnio da
aplicao. Este mapeamento feito por meio da utilizao de metadados, que
podem ser representados atravs de marcaes feitas em arquivos de configurao
XML ou de anotaes inseridas no cdigo das entidades JPA.
A atividade de mapear entidades JPA baseia-se na idia de configurao por
exceo, de modo que o mecanismo de persistncia assume valores default para a
maioria das situaes. Dessa forma, considerando o uso de valores padro
estabelecidos pela API, so necessrias apenas declaraes mnimas de
metadados, sendo preciso declarar configuraes adicionais apenas se houver a
necessidade de alterar os valores default. A seguir sero indicadas algumas
anotaes, as quais se encontram definidas no pacote javax.persistence,
utilizadas para realizar configuraes de mapeamento bsicas em entidades JPA.
34
Duas anotaes so essenciais e obrigatrias 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
primria da tabela que representar a entidade no banco de dados. A anotao
@GeneratedValue usada para indicar que a chave primria deve ser gerada
automaticamente.
As
anotaes
@Table
@Column
permitem
especificar,
respectivamente, as propriedades de uma tabela e de uma coluna no banco de

dados, tal como o nome, por exemplo. A anotao @NotNull informa que os valores
de determinada coluna no podem ser nulos, a @Pattern define um padro para o
valores de uma coluna e a @Transient define que o valor de determinada
propriedade no ser persistido. As anotaes que indicam a multiplicidade em um
relacionamento entre entidades so: @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 cdigo exemplificando o mapeamento de uma
entidade do projeto Soft Educ GCI.
Figura 8. Exemplo de mapeamento objeto-relacional de uma entidade com uso de anotaes
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
@Entity
public class Aluno implements Serializable {
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
private int id;
@Column(unique=true)
private String numMatricula;
private String nomeDoPai;
@Column(nullable=false)
private String nomeDaMae;
@Column(nullable=false)
private TipoDeAluno tipoDeAluno;
@Transient
private boolean matriculado;
@OneToOne(optional=false)
private Pessoa pessoa;
@OneToMany(mappedBy="aluno")
private List<Matricula> matriculas;
22
23
// Mtodos gets e sets omitidos nesta imagem

35
A gerncia do estado de persistncia das entidades feita por meio da utilizao

da interface EntityManager. Ela fornece mtodos para persistir novas instncias de
entidades; buscar, mesclar ou remover instncias de entidades persistidas, verificar
se uma instncia est sendo gerenciada pelo contexto de persistncia, obter objeto
para realizar transao de banco de dados, etc.
H tambm 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 memria entidades persistidas e seus relacionamentos,
no seja necessrio conhecer colunas nem chaves estrangeiras de tabelas, por
exemplo. As consultas so expressas em JPQL, uma linguagem de consulta que
derivada de EJB QL e possui sintaxe parecida com a do SQL, mas que no est
vinculada com o esquema de banco de dados. Essas consultas retornam resultados
que so entidades, proporcionando valiosas abstraes e permitem a consulta
atravs de objetos do modelo de domnio Java em vez de em tabelas do banco de
dados. A figura a seguir demonstra uma situao de uso de uma consulta JPQL que,
quando executada, retorna uma lista de objetos do domnio. A consulta seleciona
somente os objetos persistidos da classe Matrcula que tiverem como valor do seu
atributo aluno um objeto correspondente ao que passado como parmetro para a
consulta.
Figura 9. Exemplo de uma consulta com JPQL
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
O modelo de entidades mveis, que prov a possibilidade de uma entidade se

desacoplar do mdulo de persistncia, ser transportada via rede e manipulada em
outras aplicaes ou mquinas virtuais, para depois retornar e ser re-acoplada ao
contexto de persistncia, tambm uma importante caracterstica da JPA, levando
36
em considerao as arquiteturas cliente/servidor, aplicaes web e distribudas, de

um modo geral.
Em sntese, conforme posto em (Keith e Schincariol, 2006), A Java Persistence
API realmente introduziu uma nova era na persistncia integrada padronizada. Ao
ser executada dentro de um container JEE, todos os benefcios de suporte do
container e facilidade de uso superior aplicam-se, mas tambm pode ser configurada
para ser executada fora do continer, em ambientes JSE.
37
3. ESTUDO DE CASO
Nesta
seo
sero
abordadas
questes
respeito
do
ciclo
de
desenvolvimento do projeto Soft Educ GCI, considerando-se os seguintes fatores: 1)

o contexto que motivou a realizao do projeto; 2) a organizao dos stakeholders
em torno de valores, princpios e prticas prprios de processos de desenvolvimento
geis; 3) o escopo definido e os requisitos estabelecidos; 4) as ferramentas e
tecnologias utilizadas no processo; 5) a arquitetura proposta para o sistema; e 6) os
resultados obtidos no trabalho.
3.1. CONTEXTUALIZAO DO PROJETO
Como mencionado na introduo deste trabalho, o projeto Soft Educ GCI

consiste na construo de uma estrutura de software apropriada para auxiliar na
execuo de atividades prprias do fluxo de trabalho do Centro de Idiomas
FUNCERN. No incio do projeto, entre os meses de setembro e dezembro de 2010,
quando estava associado a disciplina de PDSC, mencionada na seo 1.1, a equipe
de desenvolvedores era formada por cinco desenvolvedores. A partir da segunda
fase do desenvolvimento, iniciada em maro de 2011, quanto o projeto j no se
situava mais no contexto da disciplina de PDSC, a equipe teve o nmero de
integrantes reduzido para trs.
Nos primeiros contatos entre a coordenao do Centro de Idiomas
FUNCERN, representada pela pessoa do senhor Fernando Ferreira Carneiro Filho, e
o grupo de estudantes, houve, por parte da instituio, demonstrao de insatisfao
com o aparato informacional utilizado para auxiliar na execuo das atividades
prprias de seu processo organizacional, bem como a expresso de um desejo
ntido de evoluir em relao a esse contexto. Com isso, a representao do grupo de
desenvolvedores, o qual estava envolvido na conjuntura da disciplina mencionada
anteriormente, props trabalhar, durante os meses seguintes, no intuito de criar
solues computacionais para tentar resolver os gargalos existentes na estrutura
informacional da organizao.
38
Durante a fase imediatamente anterior ao incio do projeto, quando ocorreram

os dilogos pr-eliminares, a equipe de desenvolvimento colheu e documentou
vrias e importantes informaes referentes ao processo de negcio da organizao
e aos softwares utilizados para administrar e manter esse processo. Buscou-se
observar, com uma ptica abrangente, as caractersticas dos sistemas, o que era
positivo e negativo em relao ao uso deles, as inconvenincias que geravam para a
manuteno do fluxo de trabalho organizacional.
Foi notado que, essencialmente, eram utilizados dois sistemas na instituio.
Um deles, uma aplicao web para sorteio de vagas nas turmas de 1 nvel dos
cursos oferecidos. Tal sistema permitia a realizao de inscries via web dos
candidatos interessados pela vagas, e, aps perodo de inscries, 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
coordenao, dos cursos, das turmas e dos alunos da organizao.
Logo se percebeu que esses sistemas no ofereciam condies de uso
satisfatrias, e que no atendiam devidamente as demandas geradas pelas
necessidades do processo de trabalho na coordenao dos cursos de idiomas.
Foram constatadas ntidas dificuldades para operar e manter os dois sistemas, de
modo a justificar a insatisfao dos usurios.
A seguir, feita a listagem e a descrio dos problemas encontrados pelo
grupo de desenvolvedores do Soft Educ GCI quanto ao aparato informacional ento
utilizado para apoiar as atividades do Centro de Idiomas FUNCERN. Na sequncia
do contedo desta seo, o sistema que realiza sorteio das vagas para as turmas de
1 nvel ser chamado de sistema I e o sistema usado para controle interno de
cursos, turmas e alunos ser referenciado como sistema II.
a) falta de integrao entre os sistemas utilizados. O sistema I e o sistema

II no estabeleciam nenhuma forma de comunicao entre eles. Os dados
inseridos no sistema I, na inscrio de um candidato para o sorteio, por
exemplo, no eram reaproveitados pelo sistema II durante a realizao da
matrcula de um candidato sorteado. Isso gerava uma demanda de trabalho
desnecessria para efetivar matrculas dos candidatos sorteados, pois os
dados deles, que deveriam ser recuperados, eram redigitados pelos
funcionrios. Tal situao provocava tambm maiores tempos de espera para
39
o atendimento das pessoas, deixando insatisfeitos os clientes que

procuravam se matricular no 1 nvel dos cursos.
b) dificuldades e falta de autonomia para operar o sistema I. O coordenador

da organizao no possua autonomia para operar diretamente na
coordenao das funes do sistema I. A cada novo semestre, ele tinha que
recorrer pessoa responsvel pelo desenvolvimento do sistema, para que
esta disponibilizasse o sistema na web e executasse suas funcionalidades:
gerar relatrios de inscries, realizar sorteio de vagas, gerar documento com
listagem de sorteados, etc. Essa situao era pouco cmoda e confortvel
para a organizao.
c) o sistema II no atendia a vrias demandas importantes para os

usurios. Foi constatado que o sistema II no oferecia suporte apropriado a
vrios procedimentos do fluxo de trabalho da organizao. Como exemplos
disso, podem ser enumeradas as seguintes situaes: 1) No possibilitava um
controle especfico para as provas de nivelamento realizadas, e os resultados
dos alunos nessas provas no eram registrados; 2) No 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) No
promovia
um
tratamento
adequado
quanto
ao
nmero
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 matrcula no permitia o registro da
opo de
pagamento do cliente de acordo com todas as formas de pagamento

previsveis na instituio, de modo que, inmeras vezes, os dados do
pagamento eram registrados de maneira incompatvel com a realidade, e
recibos de pagamento eram emitidos com dados incorretos, o que dificultava
o controle de pagamentos; 5) No era disponibilizada, para o usurio,
informaes indicando se o aluno havia sido aprovado ou reprovado, ou havia
cancelado a matrcula nas turmas pelas quais passou.
40
d) sistema II apresentava grande nmero de bugs. Eram vrios os erros

observados no funcionamento do sistema II, entre eles: 1) Inconsistncias na
contagem das vagas disponveis nas turmas quando alunos eram transferidos
de uma turma para outra; 2) Algumas telas e botes no funcionavam; 3)
Durante a execuo de alguns fluxos de atividades, o sistema travava e
tinha que ser fechado.
e) interface grfica do sistema II pouco clara e intuitiva aos usurios. Os
conceitos se confundiam na apresentao das telas do sistema, o que tornava
difcil o entendimento e a execuo de vrias funcionalidades, dificultando o
trabalho dos usurios, principalmente dos que eram pouco experientes. Alm
disso, havia diversas funcionalidades que os usurios nunca entenderam ou
utilizaram.
Figura10. Exemplo da falta de clareza e de intuitividade na interface grfica do sistema II
Fonte: Sistema legado do Centro de Idiomas FUNCERN (2010)
41
Figura 11. Exemplo de componente de interface grfica do sistema II que nunca foi compreendida
pelos usurios
f) sistema II apresentava graves falhas de segurana. As credenciais de

acesso eram compartilhadas por todos os usurios, e todos tinham
possibilidades de acessar qualquer funcionalidade disponvel no sistema. Isso
permitia que qualquer pessoa, ao acessar o sistema, pudesse violar
informaes importantes, deixando os dados do sistema inconsistentes. Para
reforar o ambiente de insegurana, existia uma tela que aparentemente
permitia a manipulao do banco de dados atravs de comandos SQL, o que
poderia representar um potencial risco a segurana dos dados. Somando-se a
esses problemas, no havia nenhum mecanismo de auditoria para registrar as
aes realizadas, vinculando-as aos usurios que as efetivaram e s datas
em que ocorreram.
42
Figura 12. Tela do sistema II que aparenta permitir manipulao de dados atravs de comandos SQL
g) o sistema II era pouco flexvel/configurvel. Para realizar configuraes

simples, que deveriam estar disponveis para os usurios, era necessrio
recorrer a servios de manuteno realizada pelo responsvel pelo
desenvolvimento do sistema.
h) dificuldades para obteno de servios de manuteno no sistema II. O

servio de manuteno do software no respondia de forma rpida, eficaz e
eficiente s requisies feitas pela coordenao dos cursos de idiomas.
i) no havia soluo informacional dedicada a facilitar a comunicao

entre coordenao, professores e alunos. No havia, por exemplo, a
possibilidade de os professores das turmas lanarem notas e freqncias dos
alunos diretamente em um sistema, nem a de os alunos consultarem suas
notas e freqncia via internet.
43
3.2. APLICAO DE PROCESSO BASEADO EM METODOLOGIAS GEIS
Decidiu-se que o processo de desenvolvimento do projeto Soft Educ GCI

tomaria como base valores, princpios e prticas propostos por metodologias geis
de desenvolvimento de software. Essa deciso tinha o principal objetivo de fazer
com que s mudanas ou acrscimos de requisitos sugeridos pelo cliente pudessem
ser processados e incorporados ao software com rapidez e eficincia. Tambm se
pretendia maximizar a produtividade do trabalho da equipe, de modo a no permitir
que a documentao exigida por processos mais tradicionais e menos flexveis
fossem uma barreira entrega de software funcional ao cliente. Portanto buscou-se
estabelecer um processo compatvel com as caractersticas do grupo de
desenvolvedores, baseando-se no ciclo de vida do Scrum, e incorporando outras
caractersticas fundamentadas no manifesto gil e no XP.
Inicialmente foi prevista para o processo uma fase pr-eliminar ao Sprints de
desenvolvimento, uma espcie de concepo, na qual seriam tomadas decises
arquiteturais e tecnolgicas bsicas, e realizadas algumas reunies 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 construdo um
plano, o Product Backlog, que continha as funcionalidades e caractersticas
pretendidas e uma previso do calendrio de Sprints. Tambm se definiu o conjunto
de tecnologias e ferramentas que seriam utilizados no incio do desenvolvimento,
alm da 1 verso do modelo de domnio do sistema.
Quanto aos papis 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
dos
usurios
do
sistema.
Em
relao
aos
desenvolvedores, foi proposto um mecanismo de auto-organizao, no qual todos

deveriam contribuir no planejamento e no monitoramento e controle das atividades,
emitindo suas opinies 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, extrado 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 hierrquica
equivalente e dever trabalhar de forma cooperativa, tentando contribuir,
44
sempre que necessrio, para resolver as dificuldades dos companheiros,

visando sempre o melhor para o coletivo. Os valores comunicao,
proatividade, criatividade, respeito, coragem e companheirismo devero
basear as relaes 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, alm
das atividades de desenvolvedor, a responsabilidade adicional de conduzir
as reunies do grupo durante o Sprint, orientar e monitorar o trabalho,
cobrar resultados do grupo e resolver conflitos internos.
Todos os desenvolvedores devero ter suas opinies consideradas para as
decises tomadas durante o processo. Tais decises de planejamento,
estratgia e controle devem ser estabelecidas a partir do dilogo da equipe
em reunies de planejamento, de reviso ou de retrospectiva de Sprint.
(Plano de Desenvolvimento de Software - Projeto Soft Educ, 2010, p. 8)
Em geral, o planejamento do projeto prev Sprints com durao de quatro

semanas, de modo que o objetivo principal, ao final de cada Sprint, entregar um
incremento no software, atravs da instalao e disponibilizao de uma nova
verso funcional do sistema para que os usurios possam experimentar e produzir
feedback.
O incio de cada Sprint marcado por uma reunio de planejamento entre
desenvolvedores e o Product Owner, na qual as prioridades so reavaliadas dentro
do contexto do projeto e so decididas quais funcionalidades e caractersticas
devem ser incorporadas ao software durante a iterao. Aps isto, h uma nova
reunio envolvendo somente os desenvolvedores, quando so formuladas e
estimadas as atividades necessrias para se atingir o objetivo do Sprint. Os dados
das atividades so 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 reunio curta (cerca de 15 minutos) entre
eles, na qual cada um expe sobre o andamento de sua atividade. Algumas
atividades, as de maior prioridade, so atribudas aos desenvolvedores no
planejamento do Sprint, outras so atribudas ao longo da iterao. Caso a equipe
observe que necessria uma nova atividade que no foi prevista no planejamento
inicial, ela dever ser integrada ao Sprint Backlog durante a execuo do Sprint. Ao
final de cada expediente de trabalho, os desenvolvedores devem reportar, no
Assembla, os avanos obtidos ou dificuldades encontradas na realizao de suas
atividades e atualizar o tempo estimado para a concluso delas. A partir desta
45
atualizao do tempo estimado, o Assembla constri o grfico de Sprint Burndown,

um importante instrumento de observao da curva de desempenho da equipe ao
longo a iterao.
Figura 13. Exemplo de grfico de Sprint Burndown do projeto Soft Educ GCI
Fonte: Assembla (2011)
A equipe trabalha integrando diariamente o cdigo que produz, atravs do

sistema de controle de verses SVN. O cdigo produzido de propriedade coletiva e
o uso de alguns padres de codificao pr-estabelecidos estimulado e
recomendado dentro do time. Tambm recomendado que o cdigo produzido seja
simples, claro e expressivo tanto quanto o possvel, e, frequentemente, so
realizadas atividades de refatorao.
Semanalmente, ao menos uma vez, representantes da equipe renem-se com
o Product Owner ou com usurios do sistema para demonstrar os resultados parciais
do trabalho de um Sprint, tirar dvidas relacionadas a regras de negcio, ou
questionar sobre preferncias quanto a aspectos da interface grfica e da interao
usurio-sistema. Dessa forma possvel colher feedback de forma rpida e
promover a evoluo do software baseado na evoluo dos conceitos dos usurios
46
em relao ao sistema, que ocorre na medida em que o software passa de algo

abstrato, contido somente no plano das idias, para algo mais concreto e utilizvel.
Este modelo de relacionamento entre desenvolvedores e usurios tende a deixar os
usurios mais satisfeitos.
Ao final de cada Sprint realizada uma reunio que marca a entrega da verso
ao Product Owner. Nela, representantes da equipe de desenvolvimento apresentam
os resultados finais do Sprint, e entregam o relatrio de atividades, que exigncia
do cliente. O Product Owner, por sua vez, avalia o que foi cumprido e o que no foi
em relao aos objetivos esperados para o marco, tendo a liberdade para emitir
suas opinies em relao ao trabalho dos desenvolvedores. Aps isso, a instalao
da verso, no servidor de testes, providenciada.
Aps a reunio com o Product Owner, para apresentar os resultados da
iterao, realizada uma reunio 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. Prope-se uma reflexo
sobre que ajustes no comportamento do time poderiam produzir aumento da
efetividade e da eficincia. 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 seo, a estrutura do processo de
desenvolvimento do projeto Soft Educ GCI e o conjunto de prticas relacionadas
demonstram uma organizao profundamente relacionada s idias propostas pelas
metodologias geis. No entanto, algumas prticas essencialmente defendidas por
esse tipo de metodologia no foram incorporadas ao desenvolvimento do projeto.
Como exemplo de uma prtica gil no aplicada, pode-se citar a automatizao
de testes. Essa prtica extremamente importante e til, mas no foi integrada ao
projeto por falta de qualificao tcnica da equipe. Nenhum integrante do time tinha
domnio de ferramentas e tcnicas que possibilitassem aplic-la e ainda no foi
possvel dedicar tempo o suficiente para que algum do time se capacitasse para
isso. A no utilizao de testes automatizados no processo representa uma falta que
bastante sentida por todos os desenvolvedores, pois torna mais difcil validar a
correo das funcionalidades implementadas e deixa o sistema mais vulnervel a
introduo de bugs. Assim sendo, almeja-se integrar essa prtica ao processo o
47
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 seo 3.1 deste trabalho,

o escopo do projeto Soft Educ GCI consiste na elaborao de um sistema
informacional integrado, apresentando-se em trs mdulos distintos para os seus
usurios: o mdulo coordenao, acessvel para o coordenador dos cursos de
idiomas, funcionrios e bolsistas que desempenham atividades na secretaria da
coordenao; o mdulo pblico, acessvel para qualquer usurio da web; e o mdulo
acadmico, acessvel para professores e alunos da organizao. A descrio dos
escopos de cada mdulo, bem como dos seus requisitos funcionais e no funcionais
sero apontados nas sub-sees a seguir.
3.3.1. Mdulo Coordenao
O mdulo coordenao o mais completo e complexo do sistema, e prope

atender as demandas das atividades fundamentais para organizao, manuteno e
controle da estrutura dos cursos de idiomas oferecidos. A seguir, esto descritos os
requisitos funcionais referentes a este mdulo.
a) RF 01- Gerncia de usurios. Possibilidade de cadastrar novos usurios do

mdulo coordenao, atribuindo a eles um papel de usurio, e permitindo que
utilizem as funcionalidades do sistema disponveis de acordo com papel que
exercem. Deve ser possvel tambm listar os usurios 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.
b) RF 02- Gerncia de professores. Possibilidade de cadastrar novos
professores para os cursos de idiomas, de listar os professores cadastrados,
48
de pesquis-los a partir de seus nomes ou CPF, de visualizar e de editar os

dados deles, e de desativ-los, no permitindo que sejam associados a uma
nova turma configurada.
c) RF 03- Gerncia de cursos. Possibilidade de cadastrar novos cursos, de
listar os cursos cadastrados, de editar os nomes ou nmero de nveis deles e
de desativ-los. O cadastro ou a edio de um curso s deve ser possvel
quando no houver um semestre em andamento.
d) RF 04- Abertura e configurao de semestre letivo. Possibilidade de
configurar dados relativos a um novo semestre de aulas, registrando as datas
importantes, a quantidades de vagas disponveis nas turmas para os
diferentes tipos de alunos, e os custos dos cursos. Aps registrados, os dados
do semestre devem poder ser alterados no sistema. Na abertura de semestre
tambm devem ser criadas as turmas disponveis para o semestre.
e) RF 05- Configurao de turmas. Possibilidade de atribuir um professor a
uma turma, indicar o local, os dias e os horrios de aulas. S devem poder
ser associados a uma turma professores do curso correspondente a turma.
f)
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.
g) RF 07- Gerncia de inscries para sorteio. Possibilidade de consultar

inscries realizadas para sorteio das vagas das turmas de 1 nvel do
semestre corrente. Deve permitir listar inscritos de cada turma separadamente
e fazer pesquisas de inscries com dados iguais ou semelhantes. Tambm
deve possibilitar o cancelamento de inscries.
h) RF 08- Gerncia de sorteios. Possibilidade de visualizar relatrio de
demanda para as vagas remanescentes nas turmas de 1 nvel, de realizar 1
ou mais sorteios destas vagas, de visualizar listagem de sorteados e de gerar
arquivo PDF com tal listagem.
i)
RF 09- Gerncia de provas de nivelamento. Possibilidade de cadastrar

sesses de provas de nivelamento, de listar as sesses de provas de
nivelamento cadastradas no semestre corrente, de editar os dados delas e de
exclu-las. S devem poder ser excludas sesses de provas de nivelamento
que ainda no tiverem nenhum candidato inscrito. O sistema tambm deve
possibilitar a listagem dos inscritos em uma sesso.
49
j)
RF 10- Inscrio de candidatos a nivelamento. Possibilidade de inscrever

candidatos a nivelamento, associando-os a uma sesso de nivelamento
cadastrada e gerando um recibo de inscrio.
k) RF 11- Registro e consulta a resultados em provas de nivelamento.

Possibilidade de registrar o nvel de certificao atingido para cada candidato
inscrito em uma sesso de nivelamento, bem como de consultar esses
registros a partir da pesquisa pelo nome ou CPF da pessoa que realizou a
prova.
l)
RF 12- Gerncia de alunos. Possibilidade de cadastrar novos alunos, de

pesquisar os alunos cadastrados atravs de seus nomes ou CPF, de
visualizar e de editar os dados deles.
m) RF 13- Matrcula de aluno. Possibilidade de vincular um aluno a uma turma,

registrando os dados de pagamento e gerando um recibo de matrcula 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 nvel de um dos cursos, ou ter obtido uma certificao em uma
prova de nivelamento. O sistema deve possibilitar tambm o cancelamento de
uma matrcula.
n) RF 14- Transferncia de alunos entre turmas. Possibilidade de transferir
alunos matriculados em uma turma para outra turma do mesmo curso e de
mesmo nvel. Aps realizao de transferncias devem ser gerados
comunicados de transferncia.
o) RF 15- Histrico do aluno. Possibilidade de observar as turmas pelas quais
um aluno passou e visualizar se o aluno foi aprovado, reprovado ou cancelou
a matrcula em cada turma. Tambm deve ser disponibilizado o histrico de
transferncias do aluno.
p) RF 16- Controle de notas e freqncia. Possibilidade de registrar a
presena ou o nmero de faltas dos alunos de uma turma a cada aula, e de
inserir as notas dos alunos em cada avaliao. Deve-se permitir indicar que
as atividades de uma turma foram concludas, para, quando isso acontecer, o
sistema informar se os alunos daquela turma foram aprovados ou reprovados,
de acordo com as notas e a freqncia deles.
50
q) RF 17- Certificados de aprovao. Possibilidade de gerar arquivo PDF com

certificados para os alunos aprovados nas turmas de um semestre letivo.
r)
RF 18- Folhas de registro. Emisso de documentos contendo uma lista

enumerada com todos os alunos aprovados durante um semestre letivo.
Dos dezoito requisitos funcionais previstos para este mdulo, quinze j foram
implementados, representando mais de 80% do total. J em relao aos requisitos
no-funcionais, foram previstos dois, os quais esto descritos a seguir. Deles,
apenas o primeiro j est implementado.
a) RNF 01- Autenticao e autorizao de acesso a funcionalidades.

Necessidade de o usurio estar autenticado no sistema para poder acessar
qualquer funcionalidade. Cada usurio deve ter suas prprias credenciais de
acesso, login e senha, sendo que no pode haver dois usurios como o
mesmo login. Quando o usurio autentica-se, o sistema deve identificar o
papel que o usurio exerce no sistema e autorizar o acesso dele somente s
funcionalidades disponveis para o papel associado.
b) RNF 02- Auditoria de aes importantes. Registro da data e do horrio de
em que determinadas aes foram executadas no sistema, bem como do
usurio responsvel pela realizao da ao.
3.3.2. Mdulo Pblico
O mdulo pblico dedica-se exclusivamente a proporcionar, ao pblico em

geral, a possibilidade de se inscrever para o sorteio s vagas das turmas de 1 nvel
dos cursos oferecidos. O nico requisito para este mdulo o seguinte:
a) RF 19- Inscrio para Sorteio. Possibilidade de realizao de inscries de

candidatos para concorrer a sorteio das vagas nas turmas de 1 nvel
disponibilizadas no semestre corrente. O sistema s deve permitir que o
candidato possa escolher uma turma. Aps a realizao de uma inscrio, o
sistema deve permitir a gerao de um comprovante de inscrio, indicando a
51
turma para qual se inscreveu, a data de divulgao da 1 chamada e a de

matrcula. As inscries s devem ser permitidas em um dado perodo, que
deve ser pr-configurado durante a abertura do semestre letivo, no mdulo
coordenao.
Este requisito RF 19 j est implementado, e este mdulo no apresenta

requisitos no funcionais.
3.3.3. Mdulo Acadmico
O mdulo acadmico constitui-se em uma ferramenta para os professores

registrarem informaes quanto ao andamento das aulas nas turmas, freqncia e
s notas dos alunos, a fim de que estes possam acessar essas informaes via
internet. Dentre os requisitos funcionais para este mdulo, est o requisito RF 16,
descrito na seo 3.3.1. Os demais, que ainda no foram descritos, so:
a) RF 20- Boletim. Possibilidade de os alunos acessarem seus boletins atravs

do sistema.
b) RF 21- Relatrio de Aulas. Possibilidade de os alunos observarem a lista de
aulas j lecionadas com suas respectivas datas, contedos ministrados, e a
informao do nmero de faltas do aluno em cada dia de aula.
A implementao do mdulo acadmico ainda no foi iniciada e est prevista

para comear no ms de agosto de 2011, conforme o planejamento do projeto
entregue ao cliente. Sendo assim, os professores e alunos da organizao ainda
no esto utilizando o sistema. Os requisitos no funcionais previstos para este
mdulo so os mesmos previstos para o mdulo coordenao (RNF 01 e RNF 02).
52
3.4. FERRAMENTAS E TECNOLOGIAS APLICADAS
No intuito de gerenciar as atividades e as informaes do projeto, a principal

ferramenta escolhida para esta finalidade foi o Assembla (http://www.assembla.com),
conforme j havia sido mencionado na seo 3.2 deste trabalho. No entanto, a
equipe tambm se utilizou de outras ferramentas auxiliares para apoiar a
comunicao e o compartilhamento de informaes, quais sejam o Google Groups, o
Google Docs e o Gmail. Em sntese, no Assembla era registrado o planejamento das
iteraes, a descrio e os prazos das atividades e as informaes referentes aos
resultados delas. Enquanto isso, os servios 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.
Como sistema de controle de versionamento dos arquivos do projeto, adotouse o SVN, por meio de servio disponibilizado pelo Assembla, que fornece uma
interface grfica amigvel para observar a evoluo das verses dos arquivos
inseridos no repositrio e para acompanhar os commits, suas descries e
mudanas que realizaram.
Foi decidido que o sistema seria implementado utilizando-se a linguagem Java
verso 6 e as tecnologias da plataforma JEE que foram explicadas na seo 2.2
deste trabalho. A JPA foi utilizada para promover o mapeamento objeto-relacional e
simplificar o mecanismo de comunicao entre a aplicao e a camada de
persistncia; O EJB 3.0 foi usado com a finalidade de encapsular a lgica de
negcios e a interao 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 interao
cliente-servidor via web. O servidor de aplicaes coorporativas escolhido para
executar o sistema foi o JBoss Application Server verso 5.1. Quanto ao Sistema de
Gerenciamento de Banco de Dados para hospedar o banco de dados da aplicao,
optou-se pelo PostgreSQL verso 8.4.
Procurou-se padronizar a instalao dos softwares nas estaes de trabalho
dos desenvolvedores e configurar ambientes de desenvolvimento homogneos para
os membros da equipe, a fim de evitar problemas de incompatibilidade de recursos
53
consumidos ou produzidos. Nesse sentido, o time decidiu usar o sistema operacional

Ubuntu, na verso 10.04 - 32 bits, e a IDE Eclipse Helios com os plugins Subversive,
para integrao com o SVN, e JBoss Tools, para facilitar o trabalho com as
tecnologias associadas a plataforma JEE.
Para a produo e edio de imagens foram utilizadas principalmente as
ferramentas GIMP, Inkscape e Pixlr Editor. Para a produo 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 produo de documentos de texto
formatado e de apresentaes de slides.
3.5. ARQUITETURA E MODELAGEM DO SISTEMA
Conforme explicado na seo 3.3, os requisitos funcionais do projeto Soft Educ

GCI esto subdivididos em trs mdulos distintos, e desta forma que o software
deve se apresentar para seus usurios. Com o intuito de atender as demandas
desses requisitos modulares, considerando s tecnologias da plataforma JEE
utilizadas e os conceitos relacionados s mesmas, abordados na seo 2.2 deste
trabalho, props-se, para a implementao do sistema, uma soluo arquitetural
baseada em componentes que ser detalhada ao longo desta seo. Observe-se
que, como foi dito anteriormente, o mdulo acadmico ainda no comeou a ser
desenvolvido, e por isso esta seo no abordar aspectos arquiteturais
relacionados a este mdulo em especfico.
Antes de se analisar a arquitetura com base na viso de componentes, a qual
retrata a relao entre os principais componentes lgicos, ser brevemente
explicada a viso de casos de uso do sistema, que relaciona os atores (usurios) s
funcionalidades que eles podero acessar. Para os diagramas apresentados nas
figuras 14-a, 14-b e 15, os casos de uso representados com fundo colorido so os
que j esto implementados no sistema, enquanto os que no possuem cor de fundo
so os que ainda no foram implementados.
As figuras 14-a e 14-b constituem o diagrama de casos de uso do Mdulo
Coordenao. Neste mdulo percebem-se trinta e seis casos de uso, dos quais trinta
54
e trs j foram implementados. Quanto aos atores, pode-se notar que o

Coordenador herda do Secretrio, e este herda do Bolsista, de modo que o primeiro
deve ter acesso a todos os casos de uso do mdulo; o segundo, a vinte e trs; e o
terceiro a apenas dezesseis deles.
Figura 14-a. Primeira parte do diagrama de casos de uso do Mdulo Coordenao
55
Figura 14-b. Segunda parte do diagrama de casos de uso do Mdulo Coordenao
Quanto ao Mdulo Pblico, foram propostos apenas dois casos de uso, que
devem poder ser acessveis, por meio da utilizao de um browser, para qualquer
pessoa conectada a internet.
Figura 15. Diagrama de casos de uso do Mdulo Pblico
56
Em relao viso lgica do sistema, o diagrama representado pela figura a

seguir expe os principais componentes relativo implementao do sistema, e a
forma como eles se relacionam.
Figura 16. Organizao arquitetural dos componentes do sistema Soft Educ GCI
A princpio, o diagrama da figura 16 apresenta dois componentes que no

foram desenvolvidos pela equipe do projeto, mas que constituem o ambiente de
instalao e execuo do sistema. Estes componentes so: o servidor de aplicaes
coorporativas Jboss Application Server, necessrio para a instalao e execuo do
arquivo Enterprise (EAR) que empacota os mdulos implementados do sistema; e o
Sistema de Gerenciamento de Banco de Dados PostegreSQL na verso 8.4,
necessrio para executar o banco de dados da aplicao. Tal banco de dados
representado no diagrama pelo componente denominado softEduc_GCI_BD.
Quanto aos componentes representados dentro do container de aplicaes
coorporativas, eles representam os mdulos do sistema da forma como so
apresentados na IDE utilizada.
O softEduc_GCI_modelo a unidade que encapsula as classes referentes
ao modelo de domnio da aplicao, as entidades JPA. Nele est compreendida a
57
implementao das dezesseis entidades do modelo de domnio do sistema e de

seus respectivos mapeamentos objeto-relacional. Estas classes e seus atributos
persistentes esto documentados no diagrama a seguir:
Figura 17. Diagrama de modelo de domnio do sistema Soft Educ GCI
Ainda referindo-se figura 16, pode-se notar que todos os demais

componentes representados dentro do Jboss A. S. tm dependncia em relao ao
58
componente softEduc_GCI_modelo, indicando que eles devem conhecer as

classes do modelo, pois devem ter a possibilidade realizar operaes envolvendo
atributos e mtodos delas.
O componente softEduc_GCI_core representa a unidade que contm os
Enterprise Beans da aplicao. Como foi explicado outrora, Enterprise Beans so
classes que encapsulam a lgica de negcio da aplicao e se utilizam de diversos
servios oferecidos pelo container EJB. Essa unidade est dividida em dois pacotes
principais: fachada e negocio.
O pacote negocio comporta os treze Beans de sesso responsveis por
implementar o ncleo da lgica de negcio da aplicao. Comporta tambm suas
respectivas interfaces locais, as quais tm a funo de declarar os mtodos dos
Beans que devem estar disponveis para serem invocados por outros componentes
executados dentro do mesmo servidor de aplicaes. tambm nos Enterprise
Beans do pacote negocio que o contexto de persistncia das entidades JPA do
sistema gerenciado. Nos mtodos destes Beans so realizados os comandos de
manipulao do banco de dados atravs dos mtodos disponibilizados pela interface
EntityManager da JPA.
Enquanto isso, o pacote fachada, como prprio nome sugere, implementa o
padro de projeto fachada ou facade. Ele contm dois Beans de sesso, que
representam duas fachadas, e suas respectivas interfaces. Essas fachadas tm a
funo 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 servios
implementados nos demais Beans. Vale enfatizar que, quanto a tecnologia EJB,
foram utilizados na implementao do sistema apenas Beans de sesso do tipo
Stateless.
Os componentes softEduc_GCI_administrativo e softEduc_GCI_publico
representam os mdulos web do sistema. O primeiro disponibiliza, para os usurios,
as interfaces web com as funcionalidades do Mdulo Coordenao, enquanto o
segundo disponibiliza as do Mdulo Pblico. Estas duas unidades esto
implementadas com componentes do framework JSF, do Facelets, e do RichFaces.
As estruturas dessas unidades so similares e, de forma resumida, contm: um
conjunto de pginas no formato XHTML com os componentes a serem processados
na exibio delas; alguns componentes responsveis pela converso e validao de
59
dados oriundos de requisies dos clientes web; um conjunto de Managed Beans os

quais processam e respondem s requisies recebidas; e alguns arquivos XML de
configurao. Os Managed Beans funcionam como controladores das pginas web.
Eles podem manipular instncias das classes do modelo de domnio e tambm
podem acessar os servios oferecidos pelo componente softEduc_GCI_core.
Esses servios so utilizados atravs da invocao dos mtodos declarados nas
interfaces FachadaAdministrativoLocal e FachadaPublicaLocal.
Ao longo do processo no foi produzido nenhum documento de especificao
de caso de uso nem qualquer diagrama de sequncia, haja vista que a equipe
avaliou que a produo destes artefatos seria muito custosa e a manuteno seria
praticamente invivel, considerando-se a abertura do processo para as mudanas
desejadas pelo cliente. Portanto fez-se prevalecer os princpios geis que priorizam
colaborao com o cliente, software em funcionamento e respostas a mudanas
mais que negociao de contratos e documentao abrangente.
A responsabilidade de analisar cada caso de uso e de projetar sua soluo
era responsabilidade de cada desenvolvedor, desde que, na implementao da
soluo, seguisse os padres arquiteturais e de codificao estabelecidos. Foi
acordado que o planejamento das tarefas e seus resultados seriam documentados
no Assembla, no espao da descrio ou de comentrios da tarefa. Dessa forma,
detalhes importantes de um caso 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 organizao para desenvolver um conjunto complexo de casos de
uso inter-relacionados, a serem implementados por vrios desenvolvedores, foi
produzido uma espcie de artefato sem precedentes bibliogrficos conhecidos pelos
membros da equipe. Trata-se de um documento exemplificado na figura 18, o qual
expressa a navegao em relao a um conjunto de pginas web do sistema, e
indica o modo como o contedo dessas pginas devem se apresentar para o
usurio.
60
Figura 18. Exemplo de artefato que representa esquema de navegao e caracterizao de interfaces
do sistema
61
3.6. RESULTADOS OBTIDOS
Partindo-se dos problemas mencionados na 1 sesso deste captulo,

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 transformao 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 produo, sendo utilizada no processo de inscries para sorteio, sorteio de
vagas das turmas de 1 nvel, e matrculas.
Na
sequncia
desta
sesso
sero
apresentados
os
resultados
da
implementao dos dois casos de uso do Mdulo Pblico e de oito casos de uso do
Mdulo Coordenao, na seguinte ordem: Inscrio para sorteio de vagas para
turma de 1 nvel do semestre atual (Mdulo Pblico); Gerao de comprovante de
inscrio em sorteio (Mdulo Pblico);
Cadastro, edio ou desativao de
professores e Listagem e visualizao de dados de professores; Abertura e

configurao de semestre letivo e Ativao e configurao de turmas do semestre
atual; Relatrio de demanda de inscries para as vagas do sorteio, Realizao de
sorteio e Visualizao dos resultados do sorteio; e Matrcula de Sorteado. Para
apresentar esses resultados sero utilizadas as imagens das telas que compem o
fluxo bsico de execuo dos casos de uso mencionados. Em relao a todos os
casos de uso do Mdulo Coordenao, deve-se considerar que para acess-los
necessrio que o usurio esteja autenticado no sistema.
Observao: Todos os dados exibidos nas imagens das telas apresentadas na
sequncia desta seo so fictcios e irreais, gerados aleatoriamente com a
finalidade de testar o sistema.
a) Inscrio para sorteio de vagas para turma de 1 nvel do semestre atual

(Mdulo Pblico)
62
Qualquer internauta poder acessar esse caso de uso, atravs do endereo da

URL do Mdulo Pblico. Caso o acesso seja realizado fora de um perodo de
inscries previamente configurado, o sistema exibir uma mensagem informando
que o formulrio de inscries est indisponvel; caso contrrio o sistema
apresentar a pgina exibida na figura 19.
Para iniciar a inscrio, o usurio deve marcar a caixa de seleo e, em
seguida, clicar no boto Iniciar Inscrio, os quais esto situados na parte inferior
da pgina. Ento o sistema dever apresentar a pgina exibida na figura 20. Nesta
pgina o usurio deve preencher os dados do formulrio, selecionar a turma na qual
deseja concorrer a uma vaga e clicar no boto enviar. Caso o dados informados no
formulrio sejam validados pelo sistema, apresentar-se- a pgina exibida na figura
21, na qual o usurio poder verificar os dados que inseriu e confirmar sua inscrio,
ou ento voltar para alterar algum dado. Caso o usurio confirme sua inscrio, ser
exibida uma pgina conforme a figura 22, mostrando uma mensagem indicando o
sucesso na realizao da inscrio do candidato e disponibilizando um link com a
possibilidade de impresso de comprovante da inscrio.
Figura 19. Tela inicial do sistema de inscries para sorteio das vagas das turmas de 1 nvel
Fonte: Sistema SoftEduc (2011)
63
Figura 20. Formulrio de dados necessrios para realizar inscrio para concorrer a sorteio
64
Figura 21. Tela de confirmao de dados da inscrio para concorrer a sorteio de vagas
Figura 22. Tela indicando sucesso na realizao da inscrio para concorrer a sorteio
65
b) Gerao de comprovante de inscrio em sorteio (Mdulo Pblico)
Este caso de uso um complemento do CDU descrito anteriormente, de modo

que o usurio s poder acess-lo aps completar o processo de inscrio para
concorrer ao sorteio das vagas de uma turma do 1 nvel, clicando no link Imprimir
comprovante de inscrio, exposto na pgina indicada na figura 22. Fazendo isso,
ser aberta uma pgina com o comprovante de inscrio que poder ser impresso
ou salvo pelo usurio.
Figura 23. Tela para impresso de comprovante de inscrio
Figura 24. Comprovante de inscrio para concorrer a sorteio de vagas
66
c) Cadastro,
edio
ou
desativao
de
professores
Listagem
visualizao de dados de professores
Aps autenticar-se no Mdulo Coordenao, usurios do tipo Coordenador ou

Secretrio podero cadastrar um professor acessando o menu Professores e o
sub-menu Novo Professor. Com isso, ser apresentada uma pgina como a
indicada na figura 25, na qual o usurio dever inserir os dados solicitados no
formulrio e clicar no boto Cadastrar. Caso os dados inseridos no formulrio
sejam validados, ser apresentada uma pgina 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 usurio deve acessar o sub-menu Gerenciar
Professores, do menu Professores, e ser levado at a pgina representada na
figura 27.
Figura 25. Formulrio de cadastro de professor
67
Figura 26. Tela indicando sucesso no cadastro de um professor
Na tela Gerncia de Professores, os usurios 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 lpis,
provocando a abertura de uma janela sobre a pgina, onde a edio poder ser
realizada. A janela de edio de dados de um professor mostrada na figura 28.
Figura 27. Tela de gerncia de professores cadastrados
68
Figura 28. Janela de edio de dados de um professor
d) Abertura e configurao de semestre letivo e Ativao e configurao de

turmas do semestre atual
Para abrir um semestre necessrio que se tenha cursos cadastrados no

sistema, e para ativar e configurar turmas necessrio que os cursos associados a
estas turmas tenham professores cadastrados. Essas aes s podem ser
executadas por um usurio do tipo Coordenador. Para abrir um semestre o usurio
deve clicar no sub-menu Abrir Semestre, da opo Semestre no menu principal.
Isso levar ao usurio para uma pgina a exemplo da que indicada na figura 29.
Ento o usurio preenche os campos do formulrio e clica no boto Prximo
Passo. Caso os dados inseridos no formulrio sejam validados, o sistema
apresentar uma pgina como a exemplificada na figura 30, onde o usurio deve
inserir as informaes quanto ao nmero de turmas e o material didtico para cada
69
nvel dos cursos oferecidos. Aps isso o usurio deve clicar no boto 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
70
Ao completar a abertura de um semestre, o sistema exibe a tela exemplificada

na figura 31.
Figura 31. Tela de ativao e configurao de turmas
Figura 32. Janela de ativao e configurao de uma turma
71
A pgina Ativao de Turmas do Semestre Atual, alm de ser apresentada

aps a concluso da abertura de um semestre, tambm pode ser acessada atravs
do sub-menu Ativar Turmas do Semestre Atual, do item do menu principal
Semestre. Nela as turmas criadas pelo sistema a partir das informaes 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
pgina, onde a turma poder ser configurada e ativada. Aps serem ativadas, as
turmas podero ser vistas, re-configuradas ou desativadas na pgina Visualizao
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
72
e) Relatrio de demanda de inscries para as vagas do sorteio, Realizao

de sorteio, Visualizao dos resultados do sorteio
Para visualizar relatrio que aponta o nmero de vagas remanescentes em

cada turma de 1 nvel e o nmero de concorrentes a estas vagas, um usurio do
tipo Coordenador deve acessar o sub-menu Gerenciar Sorteios, do menu Sorteio
e clicar no link Clique Aqui disponvel no painel inferior da pgina Gerncia de
Sorteios (figura 35). Fazendo isso, ele visualizar uma janela sobreposta a pgina
exibindo tal relatrio, conforme exemplificado na figura 36.
Para realizar um novo sorteio, deve-se clicar no boto Realizar Novo Sorteio,
tambm disposto no painel inferior da pgina Gerncia de Sorteios. Com isso, ser
exibido para o usurio uma caixa de confirmao, conforme apresentado na figura
37. Caso o usurio confirme a realizao de um novo sorteio, o sistema realizar o
sorteio das vagas remanescentes entre os candidatos que esto concorrendo a elas
e, aps isto, exibir uma mensagem indicando sucesso na realizao 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 so acessveis atravs 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
73
Figura 36. Janela com relatrio de vagas disponveis nas turmas e nmero de candidatos ao sorteio
delas
Figura 37. Caixa de confirmao para realizao de um novo sorteio
74
Figura 38. Tela com mensagem indicando sucesso na realizao do sorteio e exibindo lista de
sorteios realizados no semestre
Figura 39. Telas de visualizao dos sorteados para as vagas de uma turma
75
Figura 40. Tela com resultado geral de um sorteio
f) Matrcula de Sorteado
Para matricular um candidato sorteado, o usurio deve acessar o sub-menu

Buscar Sorteados, do item do menu principal Sorteio. Com isso, o sistema deve
apresentar a pgina Busca de sorteados, onde o usurio dever pesquisar o
sorteado que deseja se matricular, e, ao encontr-lo, clicar no link Matricular. Ento
o sistema apresentar um formulrio de matrcula com os dados da inscrio do
sorteado e os campos referentes s formas de pagamento. Aps concluir a
76
matrcula, o sistema exibe uma pgina (figura 43) com uma mensagem indicando
que a matrcula foi realizada com sucesso e um link para impresso de recibo de
matrcula (figura 44).
Figura 41. Tela de pesquisa de um sorteado
Figura 42. Tela com formulrio para matrcula de sorteados
77
Figura 43. Tela com mensagem indicando sucesso na matrcula de um sorteado
Figura 44. Tela para impresso de recibo de matrcula em duas vias
78
4. CONCLUSO
Pode-se afirmar que o desenvolvimento do sistema para integrar as

informaes referentes ao processo de negcio do Centro de Idiomas FUNCERN
est bem avanado, dentro das expectativas estimadas no planejamento do projeto.
As funcionalidades implementadas e implantadas at o momento esto validadas
pelo Product Owner e pelos usurios, atravs das vrias experincias que eles
tiveram utilizando o sistema ao longo das sesses de testes e de treinamento
realizadas com a participao deles. O Product Owner demonstra bastante
satisfao com o trabalho realizado pela equipe de desenvolvedores, reportando,
com freqncia, que o software que est sendo desenvolvido simplifica bastante a
realizao de atividades que antes exigiam um esforo muito maior para serem
executadas.
A
equipe
conseguiu
estabelecer
organizao
do
processo
de
desenvolvimento por meio da adoo de uma adaptao do Scrum integrada a

algumas prticas XP. Alm disso, tambm 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 relao custo-benefcio para
produzi-los e mant-los como sendo positiva. Esses fatores representaram a
adaptao do processo s caractersticas do time de desenvolvimento e s
expectativas do cliente. A busca pela melhoria contnua do processo tambm foi algo
bastante positivo, notado a cada reunio que acontecia no intuito de se estabelecer
melhores prticas.
Ficou bastante ntida a idia de que as prticas geis atuam no sentido de
repassar para as pessoas a responsabilidade que, na abordagem das metodologias
tradicionais, so depositadas sobre documentos e ferramentas. Isso leva a
concluso de que o nvel de aplicao dessas prticas deve estar diretamente
relacionado ao nvel de maturidade, responsabilidade e comprometimento dos
membros da equipe do projeto. Em uma equipe com alto nvel em relao a esses
critrios o uso dessas prticas pode ser bastante positivo e conduzir o time a uma
organizao baseada em um mecanismo de auto-gerncia. Quando o nvel de
maturidade e responsabilidade das pessoas envolvidas no projeto no for to
confivel, indicado mesclar agilidade com rigidez, sempre procurando motivar o
79
grupo. Tambm foi inferido que quanto maior o nmero de pessoas envolvidas no
processo, maior a dificuldade para implantao dessas prticas.
O fator comunicao tambm demonstrou sua importncia decisiva no
processo. A comunicao e a aproximao 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 relao
comunicao 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 insatisfatrios, o que se conseguiu reverter na com esforos
adicionais.
Outros aspectos positivos observados foram: o bom nvel de envolvimento e
participao dos desenvolvedores no projeto, o que deve ter sido motivado pela
maior possibilidade deles influenciarem nas decises tomadas; e o amplo
aprendizado em relao s tecnologias da plataforma JEE utilizadas, tendo em vista
que, no incio do projeto, nenhum dos desenvolvedores possua domnio sobre elas.
Em relao s tecnologias e ferramentas de desenvolvimento utilizadas, notouse que as tecnologias da plataforma JEE realmente proporcionam bastantes
vantagens e abstraes. Porm, o tempo necessrio para iniciar servidor de
aplicaes JBoss e para fazer a implantao da aplicao mostrou-se um fator
amplamente negativo, j que dificultava bastante na hora de observar os resultados
da programao. Tambm o alto consumo de memria RAM do JBoss Aplication
Server, algumas dificuldades e problemas encontrados no uso da IDE Eclipse, e o
grande nmero de configuraes necessrias para utilizar essas tecnologias e
ferramentas em conjunto apresentaram-se como empecilhos ao desenvolvimento
sistema que esto sendo superados at o momento com o esforo e a pacincia dos
desenvolvedores.
A no adoo de testes automatizados no processo e a falta de disciplina dos
desenvolvedores em documentar as classes produzidas com comentrio Javadoc
foram duas grandes falhas muito perceptveis no processo. A primeira bastante
sentida nos momentos de lanamento de builds, quando muito tempo perdido na
execuo de testes manuais para tentar assegurar a correo e a estabilidade do
sistema. Sem testes automatizados, fica muito mais difcil detectar possveis bugs
introduzidos no sistema por novas implementaes. A segunda falha poder
80
ocasionar problemas quando for necessrio alterar trechos de cdigos no

entendidos pelo desenvolvedor responsvel. Portanto, sabido que estas duas
prticas devem ser integradas ao processo to logo quanto possvel.
Quanto aos aspectos relacionados gerncia das atividades e ao
compartilhamento de informaes, a experincia foi positiva em relao ao uso do
Assembla e das ferramentas do Google mencionadas na sesso 3.4. Contudo, para
melhor aplicao de caractersticas geis relacionadas a esses aspectos, faltou o
uso de recurso mais palpveis e visveis dentro do ambiente de trabalho, tais como
quadro branco e post its, o que serve de sugesto para ser aplicado na sequncia
do desenvolvimento do projeto.
Em sntese, observando-se todos os aspectos mencionados neste captulo,
pode-se avaliar que os objetivos propostos para este trabalho foram amplamente
alcanados e que a experincia do desenvolvimento do Soft Educ GCI est sendo
bastante positiva, tanto na avaliao do cliente, quanto em relao capacidade de
organizao da equipe de desenvolvimento. Foram notados alguns problemas
referentes ao processo e s tecnologias utilizadas, os quais constituem as lies
aprendidas, que devem servir como base para a melhoria do processo em etapas
futuras do desenvolvimento deste ou de outros projetos.
Quanto continuidade das aes relacionadas a este trabalho, pretende-se
concluir
implementao
dos
requisitos
levantados
implantao
das
funcionalidades correspondentes a eles dentro do prazo estipulado (dezembro de

2011). Alm disso, a equipe vislumbra tambm a possibilidade de criar uma
empresa, de ampliar o nmero de desenvolvedores, de estudar novas tecnologias,
de adaptar o produto para uso em outras instituies, de planejar a produo de
outros produtos e de se associar a novos parceiros.
81
REFERNCIAS
CAMARA, F. SCRUM: Uma metodologia gil. Disponvel em:

<http://imasters.com.br/artigo/10699/gerencia/scrum_uma_metodologia_agil/>.
Acesso em: 27 mai. 2011
Documentation Facelets tools. Disponvel em:
<http://www.jsftoolbox.com/documentation/facelets/>. Acesso em: 05 jun. 2011
JENDROCK, E.; EVANS, I.; GOLLAPUDI D.; HAASE, K.; SRIVATHSATHE, C. The
Java EE 6 Tutorial. Disponvel em:
<http://download.oracle.com/javaee/6/tutorial/doc/>. Acesso em: 04 jun. 2011.
KEITH, M.; SCHINCARIOL, M. Pro EJB 3: Java Persistence API. Berkely, CA,
USA: Apress, 2006. 480p.
Manifesto para o Desenvolvimento gil de Software. Disponvel em:
<http://www.manifestoagil.com.br/>. Acesso em: 25 mai. 2011.
PORTELA, C. S. Uma Proposta de Gerenciamento gil dos Projetos de
Desenvolvimento de Software do CTIC/UFPA. Trabalho de Concluso de Curso.
CTIC/UFPA, Belm-PA, Brasil. 2009.
RichFaces Developer Guide. Disponvel em:
<http://docs.jboss.org/richfaces/latest_3_3_X/en/devguide/html_single/>. Acesso em:
05 jun. 2011
SOARES, M. S. Comparao 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 Eletrnica de Sistemas de
Informao, v. 3, p. 1-8, 2004.

Desenvolvimento de Sistema de Informação Coorporativo para o Centro de Idiomas Funcern: Um Estudo de Caso

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Desenvolvimento de Sistema de Informação Coorporativo para o Centro de Idiomas Funcern: Um Estudo de Caso

Transféré par

Droits d'auteur :

Formats disponibles

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA

DO RIO GRANDE DO NORTE

LUIZ FELIPE DE SOUSA MIRANDA

DESENVOLVIMENTO DE SISTEMA DE INFORMAO COORPORATIVO PARA

LUIZ FELIPE DE SOUSA MIRANDA

DESENVOLVIMENTO DE SISTEMA DE INFORMAO COORPORATIVO PARA

Trabalho de Concluso de Curso apresentado

LUIZ FELIPE DE SOUSA MIRANDA

DESENVOLVIMENTO DE SISTEMA DE INFORMAO COORPORATIVO PARA

Trabalho de Concluso de Curso apresentado ao

Aprovado em 13 de julho de 2011.

Fabiano Papaiz Orientador

Alexandre Gomes de Lima

Plcido Antonio de Souza Neto

Dedico este trabalho a todos que, por falta de

Agradeo, de todo corao, ao meu Deus, que justo, misericordioso e fiel,

Mediante ao contexto da sociedade da informao, na qual cada vez mais

Palavras-chave: Aplicaes Coorporativas, Desenvolvimento gil. Plataforma JEE.

Keywords: Enterprise Applications, Agile Development. JEE platform.

CONTEXTO E MOTIVAO DO TRABALHO

METODOLOGIAS GEIS EM PROCESSOS DE SOFTWARE.

CARACTERSTICAS DAS PRINCIPAIS METODOLOGIAS GEIS: SCRUM E XP

TECNOLOGIAS JAVA ENTERPRISE EDITION (JEE).

JAVA SERVER FACES (JSF)

ENTERPRISE JAVABEANS (EJB)

JAVA PERSISTENCE API (JPA)

APLICAO DE PROCESSO BASEADO EM METODOLOGIAS GEIS

ESCOPO E REQUISITOS DO SISTEMA

FERRAMENTAS E TECNOLOGIAS APLICADAS

ARQUITETURA E MODELAGEM DO SISTEMA

desenvolvimento de uma soluo em sistemas de informao, denominada Soft

1.1. CONTEXTO E MOTIVAO DO TRABALHO

O Centro de Idiomas FUNCERN um programa da Fundao de Apoio

acompanhado a evoluo da organizao. Os problemas na referida estrutura de

desenvolvimento de software flexvel e adaptvel as caractersticas da equipe de

O principal objetivo deste trabalho o desenvolvimento de uma soluo

Os demais objetivos so: Desenvolver e apresentar um estudo sobre

Inicialmente, foi realizado um estudo do contexto do projeto, das caractersticas

resultados dos estudos sobre processos de software, com foco em metodologias

Para melhor compreenso do estudo de caso que compreende o foco deste

2.1. METODOLOGIAS GEIS EM PROCESSOS DE SOFTWARE.

requisitos dos clientes ou usurios em uma soluo computacional adequada para

los, houve, e ainda h um esforo no intuito de gerar processos e metodologias

2.1.1. Processo de Software

Define-se processo de software como o conjunto de tarefas de Engenharia de

2.1.1.1. Conceitos Fundamentais Inerentes a Processos de Software

Para ajudar a esclarecer as idias a respeito da composio de um processo

procedimentos adotados, recursos empregados, paradigma e tecnologia aplicados, e

Tambm importante ressaltar que existem algumas atividades comuns a qualquer

2.1.1.2. Tipos de Processos de Software

Existem vrios processos de softwares definidos na literatura da Engenharia

O exemplo que representa bem a essncia das metodologias tradicionais o

Figura 1. Esquema de representao do modelo de desenvolvimento de software em cascata.

Por outro lado, tm-se os processos baseados em metodologias geis,

2.1.2. Metodologias geis

Os modelos tradicionais de desenvolvimento de software foram adotados em

situaes. Dessa forma, especialistas passaram a buscar alternativas para tornar a

2.1.2.1. Manifesto gil

Para discutir as novas idias e abordagens que surgiram em resposta as

em funcionamento mais que documentao abrangente; Colaborao com o

2.1.3. Caractersticas das Principais Metodologias geis: Scrum e XP

Os mtodos geis Scrum e Extreme Programming (XP) so, atualmente, os