INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE LUIZ FELIPE DE SOUSA MIRANDA

Transcrição

1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE LUIZ FELIPE DE SOUSA MIRANDA DESENVOLVIMENTO DE APLICAÇÃO CORPORATIVA PARA INTEGRAÇÃO INFORMACIONAL DO CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO NATAL/RN 2011

2 LUIZ FELIPE DE SOUSA MIRANDA DESENVOLVIMENTO DE APLICAÇÃO CORPORATIVA PARA INTEGRAÇÃO INFORMACIONAL DO CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO Trabalho de Conclusão de Curso apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte, em cumprimento às exigências legais como requisito parcial à obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas. Orientador: Fabiano Papaiz NATAL/RN 2011

3 LUIZ FELIPE DE SOUSA MIRANDA DESENVOLVIMENTO DE APLICAÇÃO CORPORATIVA PARA INTEGRAÇÃO INFORMACIONAL DO CENTRO DE IDIOMAS FUNCERN: UM ESTUDO DE CASO Trabalho de Conclusão de Curso apresentado ao Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte, em cumprimento às exigências legais como requisito parcial à obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas. Aprovado em <<data>> de <<mês> de BANCA EXAMINADORA Fabiano Papaiz Orientador Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte <<Nome de primeiro componente da banca examinadora>> Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte <<Nome de segundo componente da banca examinadora>> Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte

4 Dedico este trabalho a todos que, por falta de condições, tiveram seus sonhos restritos ou não tiveram oportunidades de alcançar seus sonhos

5 AGRADECIMENTOS Agradeço, de todo coração, ao meu Deus, que é justo, misericordioso e fiel, digno de todo louvor e adoração, fonte de toda força que me move para alcançar meus objetivos e sonhos, sempre atento ao meu clamor e às minhas dificuldades. A minha família, instrumento usado por Deus para ajudar a cuidar de mim, fonte de carinho, compreensão e superação. Em especial, quero demonstrar minha gratidão ao meu pai, Luiz Antonio, minha mãe, Edenilza, ao meu irmão, Luiz Fernando, e às minhas tias Edilzene e Elenilza, sempre solícitos nos momentos difíceis. Aos educadores que contribuíram para minha formação, em especial ao meu orientador, Fabiano Papaiz, e aos demais professores que me transmitiram um parcela de seus conhecimentos ao longo do curso de TADS. Aos amigos que fiz no curso, em especial a Henrique Pinto e a Raul Terra, companheiros ao longo de todo desenvolvimento do projeto Soft Educ GCI, e aos demais amigos e colegas que acreditam no meu potencial. A equipe da coordenação do Centro de Idiomas FUNCERN, em especial a Fernando Carneiro, por ter acreditado no trabalho de nossa equipe e nos confiado o desenvolvimento do sistema da organização que coordena. Por fim, agradeço a todos que contribuíram com minhas experiências de vida, que me fizeram chorar ou que me ajudaram a vencer, me deixando alguma lição.

6 Sem sonhos, a vida não tem brilho. Sem metas, os sonhos não têm alicerces. Sem prioridades, os sonhos não se tornam reais. Sonhe, trace metas, estabeleça prioridades e corra riscos para executar seus sonhos. Melhor é errar por tentar do que errar por omitir! Augusto Cury

7 SUMÁRIO RESUMO viii ABSTRACT ix 1. INTRODUÇÃO CONTEXTO E MOTIVAÇÃO DO TRABALHO OBJETIVOS METODOLOGIA ESTRUTURA 3 2. FUNDAMENTAÇÃO TEÓRICA METODOLOGIAS ÁGEIS EM PROCESSOS DE SOFTWARE PROCESSO DE SOFTWARE METODOLOGIAS ÁGEIS CARACTERÍSTICAS DAS PRINCIPAIS METODOLOGIAS ÁGEIS: SCRUM E XP TECNOLOGIAS JAVA ENTERPRISE EDITION (JEE) JAVA SERVER FACES (JSF) ENTERPRISE JAVABEANS (EJB) JAVA PERSISTENCE API (JPA) ESTUDO DE CASO CONTEXTUALIZAÇÃO DO PROJETO APLICAÇÃO DE PROCESSO BASEADO EM METODOLOGIAS ÁGEIS ESCOPO E REQUISITOS DO SISTEMA MÓDULO COORDENAÇÃO MÓDULO PÚBLICO MÓDULO ACADÊMICO FERRAMENTAS E TECNOLOGIAS APLICADAS ARQUITETURA E MODELAGEM DO SISTEMA RESULTADOS OBTIDOS CONCLUSÃO 67 REFERÊNCIAS BIBLIOGRÁFICAS 70 vii

8 RESUMO Miranda, Luiz. Desenvolvimento de Aplicação Corporativa para Integração Informacional do Centro de Idiomas FUNCERN: Um Estudo de Caso. Natal, f. Trabalho de Conclusão de Curso (Tecnologia em Análise e Desenvolvimento de Software) Diretoria Acadêmica de Gestão e Tecnologia da Informação, Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande Do Norte, Natal-RN, Mediante ao contexto da sociedade da informação, na qual é cada vez mais importante gerir e manipular eficaz e eficientemente dados organizacionais, as instituições necessitam de soluções adequadas para coletar (ou recuperar), processar, armazenar e distribuir informações, em conformidade com seus processos de negócio. Também no ramo das instituições de ensino, sistemas computacionais tornaram-se ferramentas diferenciais, muito úteis para simplificar a execução de atividades do fluxo de trabalho, facilitar o acesso e a manipulação de dados organizacionais, proporcionar melhores condições de gerência; melhorar o atendimento a clientes, entre outros. Com base nisso, em meados do ano de 2010, o Centro de Idiomas FUNCERN percebia a necessidade de avançar no que diz respeito ao aparato informacional utilizado para apoiar o trabalho na organização, haja vista que a estrutura de softwares então disponível apresentava vários problemas e gerava múltiplos inconvenientes. Com a pretensão de evoluir, a coordenação do Centro de Idiomas firmou uma parceria com um grupo de estudantes de desenvolvimento de sistemas a fim de que analisassem a situação, projetassem, produzissem e implantassem uma solução em tecnologia da informação que suprisse as demandas do estabelecimento. Esta solução vem sendo desenvolvida desde o mês de setembro de 2010 e tem previsão para ser concluída no mês de dezembro de O presente trabalho refere-se ao desenvolvimento desta solução, enfatizando a adoção de processo de software baseado em metodologias ágeis, o escopo e os requisitos do sistema, as tecnologias e ferramentas utilizadas na construção, a estrutura arquitetural proposta, e os resultados obtidos até o momento. Palavras-chave: Aplicações Coorporativas, Desenvolvimento Ágil. Plataforma JEE. viii

9 ABSTRACT Through the context of the information society, which is increasingly important to manage and manipulate data efficiently and effectively organizational institutions need solutions appropriate to collect (or retrieve), process, store and distribute information in accordance with their processes business. Also in the field of educational, computer systems have become common differential, very useful to simplify the execution of workflow activities, facilitate access to and manipulation of organizational data, providing better-run, improve customer service, among others. Based on this, in mid- 2010, the Language Center FUNCERN realized the need to move with respect to the informational apparatus used to support the work in the organization, given that the structure of software available then had several problems and generated many inconveniences. Claiming to evolve, the coordination of the Language Center has partnered with a group of students to develop systems that analyze the situation, design, produce and deploy an information technology solution that met the demands of the establishment. This solution has been developed since the month of September 2010 and is expected to be completed in December This paper refers to the development of this solution, emphasizing the adoption of software process based on agile methodologies, scope and system requirements, technologies and tools used in construction, architectural structure proposal, and the results obtained so time. Keywords: Applications Enterprise, Agile Development. JEE platform. ix

10 1. INTRODUÇÃO O presente trabalho consiste, essencialmente, em apresentar o desenvolvimento de uma solução em sistemas de informação, denominada Soft Educ GCI, que se propõe a resolver problemas e inconvenientes identificados na execução do fluxo de atividades do Centro de Idiomas FUNCERN. Este capítulo introdutório pretende expor uma visão geral do trabalho, indicando o contexto que o circunda, os fatores que estimularam seu desenvolvimento, os objetivos pretendidos, a metodologia utilizada, e a estrutura de organização do conteúdo do trabalho Contexto e Motivação do Trabalho O Centro de Idiomas FUNCERN é um programa da Fundação de Apoio à Educação e ao Desenvolvimento Tecnológico do RN (FUNCERN) sediado nas dependências do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte (IFRN) com o intuito de oferecer, ao público em geral, cursos de idiomas de qualidade a um custo mais acessível. Essa organização oferece cerca de 65 turmas de cursos de idiomas a cada semestre e atua com mais de 1000 alunos ativos, sendo que a demanda de alunos para ingressar nos cursos é maior que o número de vagas disponíveis. Entre professores dos cursos, e funcionários e bolsistas que trabalham exercendo funções ligadas a coordenação, o Centro de idiomas tem mais de 30 colaboradores. A instituição tem um processo de negócio um tanto quanto peculiar, incluindo a realização, a cada semestre, de um sorteio de vagas para as turmas do 1º nível dos cursos, e a reserva de um determinado número de vagas em cada turma para bolsistas alunos ou servidores do IFRN. Para apoiar na gerência e no desempenho operacional das atividades próprias de seu funcionamento, o estabelecimento utilizava alguns softwares. No entanto, ficava nítido o juízo de que a estrutura de software utilizada estava ficando obsoleta, era problemática, apresentava diversas incompatibilidades com as características do processo de negócio da instituição e gerava alguns inconvenientes, não tendo acompanhado a evolução da organização. Os problemas na referida estrutura de software serão analisados e detalhados na sessão 3.1 deste trabalho. Tomando este contexto, a realização do projeto Soft Educ GCI, que é o foco do estudo deste trabalho fundou-se em uma parceria estabelecida entre a instituição 1

11 mencionada e um grupo de alunos do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas (TADS) do IFRN, no intuito de construir uma estrutura de software mais evoluída e apropriada para apoiar o funcionamento do Centro de Idiomas FUNCERN. Tal parceria foi firmada em setembro de 2010, e prevê a instalação final do sistema, de acordo com o escopo previsto atualmente, no mês de dezembro de O processo de desenvolvimento do projeto mencionado iniciou-se dentro da disciplina de Projeto de Desenvolvimento de Software Corporativo (PDSC), do sexto período do curso de TADS, cujo objetivo é proporcionar aos alunos uma espécie de prática profissional, através da aplicação dos conteúdos ministrados durante o semestre letivo ao desenvolvimento de sistemas. Dessa forma, o projeto seria uma boa oportunidade para promover a extensão do trabalho acadêmico ao contexto de um problema real em um ambiente de negócios, e para aplicar as tecnologias Java para desenvolvimento corporativo estudadas, bem como um método de desenvolvimento de software flexível e adaptável as características da equipe de desenvolvimento e do cliente, dedicado fundamentalmente a agregar valor ao produto e a melhorar continuamente o processo Objetivos O principal objetivo deste trabalho é o desenvolvimento de uma solução computacional que apóie o desempenho das atividades próprias do fluxo de trabalho no Centro de Idiomas FUNCERN, resolva os problemas e inconvenientes identificados na estrutura informacional utilizada quando este trabalho foi idealizado, proporcione mais comodidade, eficiência e eficácia para o gerenciamento das informações e para a execução do trabalho necessário na organização, e satisfaça seus usuários e cliente. Os demais objetivos são: Desenvolver e apresentar um estudo sobre metodologias ágeis para o desenvolvimento de software; Desenvolver e apresentar um estudo sobre as tecnologias da plataforma JEE para o desenvolvimento de aplicações coorporativas; Elucidar e descrever os requisitos esperados para sistema pretendido; Descrever a aplicação de um processo de software que une o ciclo do Scrum com práticas do XP e se utiliza de alguns artefatos oriundos de processos tradicionais; Descrever sobre a utilização de ferramentas e tecnologias no desenvolvimento; Apresentar a arquitetura adotada no sistema em desenvolvimento. 2

12 1.3. Metodologia Inicialmente, foi realizado um estudo do contexto do projeto, das características relativas ao funcionamento do Centro de Idiomas FUNCERN, e um levantamento de requisitos para o sistema pretendido de um modo amplo e sem profundidade de detalhes. Em paralelo a isso foram estudados os temas enfatizados neste trabalho, processos de software ágeis e tecnologias da plataforma JEE, e também alguns temas complementares ou suplementares a eles, para que pudessem ser aplicados ao desenvolvimento do projeto Soft Educ GCI. Após isto, iniciou-se a fase do desenvolvimento do projeto, baseado no ciclo do Scrum e em algumas práticas XP (essas metodologias de desenvolvimento de software estão descritas na sub-sessão deste trabalho, e a forma como são aplicadas ao projeto é explicada na sessão 3.2). Então, para concluir o trabalho, foi produzido o presente documento, constituído pelos principais aspectos referentes aos estudos realizados e à aplicação do conhecimento obtido no desenvolvimento do trabalho Estrutura Além deste capitulo introdutório, este TCC contém mais três capítulos, que estruturam o conteúdo conforme explicado a seguir. O capitulo 2 descreve os resultados dos estudos sobre processos de software, com foco em metodologias ágeis; e sobre as tecnologias da plataforma JEE ou complementares. O capítulo 3 apresenta o estudo de caso que constitui o foco deste trabalho, dissertando sobre a aplicação de um processo de software, de técnicas, tecnologias e ferramentas no desenvolvimento do sistema Soft Educ GCI. Por fim, O capítulo 4 expõe as conclusões em relação ao trabalho, indicando a medida em que os resultados apresentados foram positivos ou não e estabelecendo uma previsão para os possíveis rumos quanto a continuidade do trabalho. 3

13 2. FUNDAMENTAÇÃO TEÓRICA Para melhor compreensão do estudo de caso que compreende o foco deste trabalho, faz-se necessário o conhecimento de alguns conceitos e idéias as quais fundamentam os aspectos abordados no capítulo 3, sobre o desenvolvimento do projeto em questão. Sendo assim, este segundo capítulo objetiva explicar, de forma sucinta, alguns fundamentos centrais envolvidos na construção do Soft Educ GCI. Para tanto, subdividir-se-á em duas seções, os quais relatarão, consecutivamente, a respeito de: 1) Processos de desenvolvimento de software, com foco em metodologias ágeis; e 2) Tecnologias da plataforma Java para desenvolvimento de aplicações coorporativas (JEE) Metodologias Ágeis em Processos de Software. Desenvolver um software consiste fundamentalmente em transformar requisitos dos clientes ou usuários em uma solução computacional adequada para os requisitantes. Em geral, a demanda de software surge: da busca por resolver problemas do dia a dia, seja no âmbito pessoal ou organizacional; da intenção de tornar mais prática e eficiente a execução de alguma(s) atividade(s) em um dado contexto. Entretanto, dependendo da dimensão do problema a resolver e dos níveis dos requisitos estabelecidos, o desenvolvimento de sistemas pode tornar-se uma atividade bem complexa, envolvendo uma vasta gama de profissionais, e inúmeras possibilidades de decisões, as quais podem implicar no sucesso ou fracasso em um projeto. Mediante a esta complexidade, são necessários meios para se organizar a criação de produtos de software. A desorganização na produção destes desencadeia problemas como: discrepância em relação aos requisitos do usuário; ocorrência demasiada de erros; excesso de gastos em relação orçamento estimado; atraso quantos aos prazos estabelecidos; criação de produtos de difícil manutenção; entre outros. Tais problemas ficaram bem evidentes na indústria de software na década de 1960, quando foi evidenciada a crise do software. Para tentar solucioná-los, houve, e ainda há um esforço no intuito de gerar processos e metodologias apropriadas para promoção do desenvolvimento de software de qualidade, apropriados para solucionar os problemas do usuário, respeitando prazos e custos estabelecidos. 4

14 Processo de Software Define-se processo de software como o conjunto de tarefas de Engenharia de Software necessárias para transformar os requisitos dos usuários em software [Humphrey apud Oliveira 2007 apud Portela 2009]. Trata-se da aplicação de uma metodologia de trabalho para coordenar as ações de uma equipe de desenvolvimento, de forma que cada membro entenda seu papel dentro do grupo, bem como as atividades que deve executar. Isso, no intuito de manter a harmonia, a sincronia e a estabilidade entre os trabalhos realizados por cada um, a fim de que a equipe alcance os resultados esperados de forma eficiente e eficaz. Todavia, nenhum processo de software é apropriado para ser aplicado em todo e qualquer projeto. Cada projeto tem seu contexto, suas peculiaridades, características próprias. Isso significa que um mesmo processo aplicado a dois projetos diferentes pode ser determinante para o grande sucesso em um e para o extremo fracasso em outro. Não existe um processo de software que possa ser genericamente aplicado a todos os projetos, visto que nenhum projeto é idêntico ao outro. Variações nas políticas e procedimentos organizacionais, métodos e estratégias de aquisição, tamanho e complexidade do projeto, requisitos e métodos de desenvolvimento do sistema, equipe (pessoas), entre outros fatores, influenciam na forma como um produto de software é adquirido, desenvolvido, operado e mantido. [ISO/IEC apud Oliveira 2007 apud Portela 2009] Conceitos Fundamentais Inerentes a Processos de Software Para ajudar a esclarecer as idéias a respeito da composição de um processo de software é conveniente observar-se também alguns conceitos intimamente associados, tais como: atividades previstas, artefatos consumidos e produzidos, procedimentos adotados, recursos empregados, paradigma e tecnologia aplicados, e modelo de ciclo de vida utilizado. Abaixo, a explicação sobre alguns dos itens mencionados, segundo [Oliveira 2007 apud Portela 2009]: Atividades: São as tarefas ou trabalhos a serem realizados. A realização de uma atividade pode adotar um procedimento, requer recursos e geralmente utiliza ou gera artefatos. Pode-se, ainda, decompô-la em sub-atividades. Além disso, atividades podem depender da finalização de outras atividades, denominadas pré-atividades. As atividades podem ser classificadas em: atividades de gerência, atividades de construção, atividades de suporte e manutenção e atividades de avaliação da 19 qualidade. Como exemplo de atividade realizada no projeto de software pode-se citar Especificar os Requisitos ; 5

15 Artefatos: São produtos de software gerados ou consumidos durante a execução das atividades. Os artefatos podem ser classificados em: artefatos de código, componentes de software, documentos, diagramas, modelos, etc. Para a atividade citada no exemplo anterior, pode-se ter como artefato consumido o Relatório de Entrevista com o Usuário e como artefato gerado o documento Especificação dos Requisitos ; Procedimentos: São condutas bem estabelecidas e ordenadas para a realização de atividades do processo. Quanto à sua natureza, procedimentos podem ser classificados em: métodos, técnicas e diretrizes. Seguindo o exemplo anterior, para executar a atividade definida pode-se definir um procedimento que faça uso da UML Unified Modelling Language para a definição de cenários das necessidades do usuário; Recursos: Qualquer fator necessário à execução de uma atividade, mas que não seja um insumo para a atividade. Os recursos podem ser classificados em: recursos de hardware, recursos de software e recursos humanos. Finalizando a caracterização do exemplo anterior, pode-se usar como recursos humanos o Analista de Sistemas, o qual poderá ter um equipamento de PC para desempenhar suas tarefas, que tenha instalado uma ferramenta para modelagem de projetos de software que automatize o procedimento UML Também é importante ressaltar que existem algumas atividades comuns a qualquer processo, conforme indicado em [Sommerville 2003 apud Soares 2004]: Especificação de Software: definição das funcionalidades (requisitos) e das restrições do software. Geralmente é uma fase em que o desenvolvedor conversa com o cliente para definir as características do novo software. Projeto e Implementação de Software: o software é produzido de acordo com as especificações. Nesta fase são propostos modelos através de diagramas, e estes modelos são implementados em alguma linguagem de programação. Validação de Software: o software é validado para garantir que todas as funcionalidades especificadas foram implementadas. Evolução de Software: o software precisa evoluir para continuar sendo útil ao cliente Tipos de Processos de Software Existem vários processos de softwares definidos na literatura da Engenharia de Software, os quais podem ser classificados essencialmente em dois grupos: os processos tradicionais e os processos ágeis. Processos tradicionais, também conhecidos como processos pesados, valorizam a idéia de que, na fase inicial do projeto, a equipe de desenvolvimento deve elucidar e documentar todos os requisitos do sistema, para que, ao longo do processo, estes requisitos sejam administrados a partir de um planejamento rigoroso, estabelecido antes do início das atividades de projeto e implementação do software. A 6

16 documentação é considerada um fator de grande importância durante a execução de processos nessa linha. A especificação de requisitos é considerada uma etapa fundamental onde todas as necessidades do cliente devem ser definidas e documentadas. Para cada um destes requisitos, devem ser gerados outros documentos, o que torna o processo de análise e projeto bastante demorado e de difícil manutenção caso surja um novo requisito ou alguma especificação seja alterada. Pode-se, ainda, caracterizar que estes tipos de processo possuem uma abordagem voltada para o planejamento detalhado e uso artefatos como insumos de uma fase para a seguinte. [Portela 2009] O exemplo que representa bem a essência das metodologias tradicionais é o modelo de desenvolvimento de software em cascata, no qual uma sequência rígida de etapas deve ser seguida durante o processo: especificação de requisitos, projeto, implementação, teste, implantação e manutenção. Ao final de cada etapa os artefatos produzidos precisam ser aprovados para que a etapa seguinte possa ter início. Figura 1. Esquema de representação do modelo de desenvolvimento de software em cascata. Fonte: em 12/06/2011 Por outro lado, têm-se os processos baseados em metodologias ágeis, também chamados de processos leves, os quais valorizam principalmente a capacidade de adaptar-se a mudanças de requisitos no software e a eficiência na produção. O tópico seguinte deste trabalho abordará com mais profundidade as características deste tipo de processos. 7

17 Metodologias Ágeis Os modelos tradicionais de desenvolvimento de software foram adotados em grande escala pela indústria de software a partir da década de Porém, em meados da década de 1990, mediante ao contexto de um ambiente organizacional cada vez mais dinâmico e instável, e de problemas cada vez maiores, quanto à extrapolação de orçamentos, atrasos nas entregas, bugs e insatisfação de clientes, apresentados em projetos aplicadores de processos tradicionais, integrantes da comunidade de software começaram a questionar tais processos, julgando-os impraticáveis em algumas situações. Dessa forma, especialistas passaram a buscar alternativas para tornar a produção de software mais eficiente e eficaz, criando métodos próprios para isso. O agrupamento desses novos métodos e dos ideais que os embasavam começaram a construir o conceito de metodologias ágeis. Esse conceito lançava a idéia de não permitir que a rigorosidade dos processos de software bloqueasse o avanço significativo na produção e as possibilidades de adaptação a mudanças. A idéia de agilidade não se fazia contrária à documentação, mas sim à documentação em excesso, aos documentos que pouco ou nada agregavam ao processo de produção e só deixavam o processo mais pesado. Diante disso, o novo enfoque para o desenvolvimento de software seria baseado em flexibilidade, habilidades de comunicação, capacidade de resposta a mudanças e de adaptação a situações adversas, buscando oferecer produtos e serviços de valor ao mercado em um curto período de tempo, no contexto de um turbulento ambiente de negócios [Highsmith 2004 apud Portela 2009]. Para complementar, vale enfatizar que as propostas indicavam a necessidade de balancear flexibilidade, estrutura e estabilidade, pois a ausência de um destes dois últimos fatores pode levar ao caos, mas, por outro lado, a estrutura em excesso gera rigidez [Highsmith 2004 apud Portela 2009], o que pode se tornar um gargalo em um projeto Manifesto Ágil Para discutir as novas idéias e abordagens que surgiram em resposta as limitações dos processos tradicionais para desenvolvimento de software, criadores e representantes de vários métodos ágeis se reunirão nos Estados Unidos, no ano de Como resultado deste encontro, surgiu a Aliança Ágil e foi publicado um 8

18 documento que oficializava e sintetizava os novos ideais estabelecidos pelo grupo, o Manifesto para Desenvolvimento Ágil de Software, mais conhecido simplesmente como Manifesto Ágil. Nesse documento, alguns valores foram colocados em detrimento de outros: Indivíduos e interação entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano [Manifesto Ágil 2001]. Expôs-se também que os itens mais a esquerda tinham valor significativo, porém que eram menos essenciais que os itens mais a direita. No encontro, os participantes demonstraram-se preocupados em deixar clara a importância da metodologia, do planejamento e da documentação. Entretanto, defenderam-se os seguintes pontos de vista em relação a estes fatores: a metodologia teria que contribuir para a eficiência e eficácia, e nunca ao contrário; o planejamento deveria ser refeito ciclicamente, tendo em vista que, em um ambiente de negócios turbulento, o planejamento e a previsibilidade em longo prazo são bastante limitados; a documentação não é um fator primordial e indispensável por si só, mas só é necessária na medida em que agregar valor ao processo de desenvolvimento ou ao produto. Princípios base do manifesto ágil Nós seguimos os seguintes princípios: Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Contínua atenção à excelência técnica e bom design, aumenta a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitos e designs emergem de times autoorganizáveis. 9

19 Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo. [Manifesto Ágil 2001] Características das Principais Metodologias Ágeis: Scrum e XP Os métodos ágeis Scrum e Extreme Programming (XP) são, atualmente, os mais conhecidos e utilizados na comunidade de desenvolvimento de software. Ambos estão calcados nos princípios estabelecidos no Manifesto Ágil, valorizando fatores como aproximação entre clientes e desenvolvedores, entregas frequentes de pequenos incrementos no software, e melhoria continua do processo de desenvolvimento da equipe. A seguir cada um destes processos é analisado de forma resumida Scrum O Scrum é uma metodologia de desenvolvimento de software bastante aberta e flexível, tornando possível e indicado adaptar seu uso de acordo com o contexto do projeto que deseja utilizá-lo. Ele procura fornecer meios de tornar a produção eficiente mesmo mediante à imprevisibilidade e às mudanças nos requisitos. O Scrum não determina tudo o que se deve fazer nem as técnicas a serem adotadas nos diversos momentos do desenvolvimento, mas oferece um conjunto práticas as quais permitem que a equipe: se situe em relação ao estado das atividades do projeto; tenha consciência dos seus objetivos, metas e nível de produtividade; possa fazer estimativas próximas da realidade; e tome as decisões adequadas e coerentes com os objetivos e metas estabelecidas. Assim, esta metodologia caracteriza-se como um framework. Por ser um framework, irá servir como um guia de boas práticas para atingir o sucesso. Entretanto, as decisões de quando e como usá-lo, quais táticas e estratégias seguir para obter produtividade e realizar as entregas ficam por conta de quem estiver o aplicando. O conhecimento das suas práticas permite a aplicação destas de forma variada e este é um dos aspectos positivos do Scrum, a adaptabilidade. [Portela 2009] Neste framework, há a definição clara de três papéis dentro da equipe ou time de desenvolvimento. O Product Owner é o responsável por representar os interesses do cliente junto ao time de desenvolvedores, em relação a requisitos, prazos, orçamento, avaliação do produto, etc. O Scrum Master é o responsável pelas funções de gerência e de resolução de conflitos internos ao time. E os Desenvolvedores são os 10

20 responsáveis pelas decisões técnicas, por estimar tempo necessário para atividades, por projetar e implementar funcionalidades do sistema. Em síntese, e de um modo genérico, o Scrum funciona da seguinte forma: inicialmente é elaborado o Backlog do Produto (Product Backlog), que consiste em um plano com as funcionalidades (User Stories ou Estórias do Usuário) e características requeridas pelo cliente no começo do projeto. Este artefato será administrado durante o todo o projeto, sendo frequentemente atualizado. Depois de listadas as estórias do usuário, o esforço para realizá-las é estimado pelos desenvolvedores, que, junto com o product owner, agrupam as estórias em vários Sprints. Um Sprint consiste em uma iteração que deve durar entre 2 e 4 semanas, de modo que, ao final deste intervalo de tempo, tenha-se uma versão usável do produto para entregar ao Product Owner. Antes de iniciar cada sprint, há uma reunião de planejamento (Scrum Planning Meeting), a qual envolve todo o time, com a finalidade de definir, de acordo com as prioridades do cliente e do contexto atual da equipe, quais das funcionalidades e características do Backlog do Produto devem ser implementadas durante a iteração, construindo assim o Sprint Backlog. Após o product owner expressar ao restante da equipe suas prioridades, scrum master e desenvolvedores dividem as estórias em atividades necessárias e estimam o esforço para cumpri-las, adequando a composição do Sprint Backlog de acordo com o esforço previsto para o sprint. Durante o sprint, o scrum master e desenvolvedores assumem espontaneamente e executam as atividades previstas no plano. Há a realização de reuniões diárias (Scrum Daily Meeting), nas quais cada desenvolvedor e o scrum master devem se pronunciar rapidamente para o restante da equipe, procurando, essencialmente, informar o que fez no último dia, o que pretende fazer no dia vindouro e quais o impedimentos encontrados na tarefa que está executando. As reuniões devem ser rápidas, entre 10 e 20 minutos, e recomenda-se que sejam realizadas com os participantes de pé. Para medir a produtividade do time no decorrer do sprint é usado um gráfico chamado Sprint Burndown, que indica o progresso da equipe, de acordo com o esforço estimado para as tarefas cumpridas a cada dia. Ao final de cada sprint deve ser realizada uma reunião de revisão de sprint (Sprint Review), na qual a equipe demonstra ao product owner o que foi produzido e todos avaliam o trabalho, comparando o resultado obtido ao esperado. Após isso, deve-se realizar uma reunião de retrospectiva de sprint (Sprint Retrospective), visando identificar os pontos positivos e negativos, o que deve ser mantido e o que não deve se 11

21 repetir, além de absolver lições e aprendizado, com o objetivo de melhorar o processo e o produto nos sprints seguintes. Figura 2. Representação do ciclo do Scrum. Fonte: em 12/06/ Extreme Programming (XP) O XP, que foi criado no final da década de 1990, trata-se de uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente [Beck 1999 apud Soares 2004]. Este método tem o objetivo de promover a produção de software de forma rápida e em ciclos de desenvolvimento cada vez mais curtos. Dentre os ideais, estão: produzir primeiro o que agrega mais valor ao produto, adaptar-se ao inesperado, priorizar as atividades de codificação (programming). Para tanto, baseia-se em 4 valores fundamentais e propõe a aplicação 12 práticas bem estabelecidas na condução do processo. Os valores são: feedback, comunicação, simplicidade e coragem [Beck 1999 apud Soares 2004]. O feedback consiste na busca constante por respostas do cliente em relação ao que foi produzido, de modo que ele observe e utilize, o quanto antes, um número 12

22 mínimo de funcionalidades desenvolvidas da forma mais simples possível, para, então, indicar o que, segundo sua óptica, necessita ser feito a mais em relação às referidas funcionalidades. Dessa forma, o cliente guiará o desenvolvimento de acordo com a evolução da formação de sua visão sobre o produto, evitando implementações desnecessárias e maiores custos para ajustes. A comunicação mais eficiente possível é um objetivo prioritário para equipes XP, para que a equipe possa compartilhar conhecimento, se ajudar mutuamente dentro do processo, etc. A intenção é usar, ao máximo, os melhores canais comunicativos disponíveis, de maneira que a comunicação pessoal é preferível em relação à comunicação por telefone, a qual é preferível em relação à comunicação por . A comunicação é estimulada tanto interiormente a equipe, quanto entre membros da equipe de desenvolvimento e clientes. A simplicidade faz-se no sentido de tentar descomplicar as coisas, para que, inicialmente seja desenvolvido algo simples e funcional, a ser melhorado posteriormente, a partir do feedback, e durante as refatorações (Refectoring). Busca-se implementar somente requisitos atuais, sem tentar prever requisitos importantes no futuro. A aposta da XP é que é melhor fazer algo simples hoje e pagar um pouco mais amanhã para fazer modificações necessárias do que implementar algo complicado hoje que talvez não venha a ser usado, sempre considerando que requisitos são mutáveis. [Soares 2004] A coragem é fator determinante para membros de times XP, uma vez que a metodologia propõe, através de seus valores e práticas, uma quebra de paradigmas relacionados às abordagens tradicionais para desenvolver sistemas. Abaixo, estão listadas as 12 práticas XP, conforme apresentado em [Dias 2005 apud Portela 2009]: 1. Jogo do Planejamento: no início de cada interação, clientes, gerentes e programadores se encontram para definir, estimar e priorizar os requerimentos. A idéia é que se elabore um plano aproximado no início do projeto e se faça um refinamento à medida que as necessidades e requisitos se tornem mais conhecidos; 2. Programação em Pares: dois programadores utilizando o mesmo computador escrevem o código; 3. Pequenas Versões: as versões devem ser tão pequenas quanto possível e trazerem valor para o negócio. Uma versão inicial do software deve ser colocada em produção após um pequeno número de interações e, em seguida, outras versões devem ser disponibilizadas tão logo faça sentido; 13

23 4. Metáforas: clientes, gerentes e programadores criam metáforas ou conjunto de metáforas para modelagem do sistema; 5. Projeto Simples: os programadores são estimulados a desenvolver o código do software o mais simples possível; 6. Testes: os programadores devem criar os testes de unidade antes ou mesmo durante o desenvolvimento do código do sistema. Os clientes, por sua vez, escrevem os testes de aceitação. Ao final de cada iteração a bateria de testes deve ser conduzida; 7. Reegenharia de Software: o código deve ser constantemente melhorado, sem que a funcionalidade do seja alterada, pela equipe do projeto, o tempo todo; 8. Integração Contínua: os programadores devem integrar os novos códigos ao software tão rapidamente e com a maior freqüência possível; 9. Propriedade Coletiva do Código: o código do programa deve ser propriedade de toda a equipe e qualquer integrante pode fazer alterações sempre que for necessário; 10. Cliente no Local: o cliente deve trabalhar com a equipe de projeto a todo momento, respondendo perguntas, realizando testes de aceitação e assegurando que o desenvolvimento do software esteja sendo feito a contento; 11. Semana de 40 horas: como trabalhar por longos períodos reduz o desempenho, o conteúdo de cada iteração deve ser planejado de forma a não haver necessidade de realização de horas extras; 12. Padrão de Codificação: no início do projeto deve ser criado um padrão de codificação, simples e aceito por toda a equipe, que deverá ser seguido de forma a padronizar e a auxiliar a condução do trabalho 2.2. Tecnologias Java Enterprise Edition (JEE). É cada vez mais vigente a necessidade de se construir aplicações distribuídas transacionais e portáveis com menos tempo e recursos, utilizando-se de vantagens, como confiabilidade, segurança e velocidade, oferecidas por tecnologias para programação do lado servidor. É sob esta perspectiva que a plataforma Java Enterprise Edition coloca-se com o objetivo de fornecer aos desenvolvedores um conjunto avançado de APIs (Application Programming Interfaces ou Interfaces para Programação de Aplicações) para reduzir a complexidade, melhorar o desempenho e reduzir o tempo de desenvolvimento de aplicações. Esta plataforma define uma arquitetura baseada em um modelo distribuído multicamadas para implementação de serviços em aplicações corporativas, de modo a proporcionar vantagens, como escalabilidade, acessibilidade e gerenciamento 14

24 necessário. A aplicação é estruturada por meio de componentes que podem se situar em camadas distintas, de acordo com a função que exercem. Estas camadas representam ambientes de execução diferentes, quais sejam a máquina cliente, o container Web o container EJB, estes dois último localizados no servidor JEE. Figura 3. Arquitetura de Componentes JEE. fonte: The Java EE 6 Tutorial As próximas subseções deste trabalho abordaram mais detalhadamente algumas das tecnologias usadas no projeto Soft Educ GCI que compõem esta plataforma de desenvolvimento Java Server Faces (JSF) Várias tecnologias surgiram com a finalidade de evoluir o modelo de programação para aplicações web, tentando abstrair, simplificar e potencializar a implementação destas. Na plataforma Java, a especificação Java Servlet foi a tecnologia precursora. Em seguida, vieram as páginas JSP, as quais passaram a ser utilizada junto aos Servlets. No entanto, os seguintes problemas, decorrentes do uso destas tecnologias, 15

25 tornaram-se cada vez mais evidentes: mistura entre códigos de apresentação (Interface Gráfica do Usuário) e de lógica de negócio, dificuldades na manutenção das aplicações, baixa produtividade no desenvolvimento, entre outros. Mediante esse contexto, o JSF foi apresentado como um framework de componentes do lado servidor para a construção de aplicações web baseadas em tecnologias Java [The Java EE 6 Tutorial]. Constituído sobre o padrão arquitetural MVC (Model-View-Controller ou Modelo-Visão-Controlador), e caracterizando-se por uma proposta de programação baseada em eventos, de forma similar ao que acontece com o uso da API Java Swing para desenvolvimento de interfaces gráficas em aplicações desktop, o JSF busca abstrair fatores relacionados ao modelo de desenvolvimento proveniente do uso das tecnologias anteriores (JSP e Servlets), elevando o nível da programação, tornando mais fácil e prático a produção de aplicações web. Essencialmente, este framework fornece uma API para: representação de componentes e gerência do estado deles, manipulação de eventos, conversão de dados, validação no lado servidor, definição de navegação entre páginas, internacionalização da aplicação e extensibilidade dos componentes [The Java EE 6 Tutorial]. Para a camada de apresentação, o JSF oferece um conjunto de tags XML para representação de componentes em páginas web. Estas tags possibilitam a associação de componentes das páginas com objetos do lado servidor através do uso da linguagem de expressão (Expression Language ou, simplesmente, EL), e estão disponíveis por meio das tag libraries, que são bibliotecas de tags a serem declaradas nas páginas. Com a finalidade de possibilitar uma compreensão mais prática do framework, na sua versão 1.2, que foi a versão usada no desenvolvimento do projeto sobre o qual se refere este trabalho, as explicações serão feitas com base em trechos de código de uma aplicação JSF simples. A Figura a seguir apresenta um trecho de código de uma página XHTML que usa alguns componentes JSF: 16

26 01 <f:view xmlns=" 02 xmlns:f=" 03 xmlns:h=" 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> Figura 4. Uso de componentes JSF A figura 4 exibe a codificação de uma página simples, com alguns componentes JSF. Nas linhas 2 e 3, ocorre a declaração das duas tag libraries padrão do JSF, com seus respectivos prefixos, pelos quais serão referenciadas ao longo do código, e URIs. A partir disso, os componentes integrantes desses pacotes de tags poderão ser usados. Da linha 10 a linha 15, exemplifica-se o uso de alguns componentes da tag library HTML do JSF. Na linha 12, demonstra-se o uso de um componente que associa uma entrada de texto do usuário a um objeto do modelo que está no lado servidor (backing bean), através de EL. Com a expressão #{exemplomb.nome}, o valor inserido no campo de texto deve ser atribuído a propriedade nome do managed bean declarado com o nome de exemplomb durante a fase de atualização dos valores do modelo do ciclo de vida do JSF. Os managed beans são classes Java que exercem a função de controladores em uma aplicação JSF. Eles contêm os objetos do domínio que serão ligados aos componentes JSF, e também os manipuladores de ações (Action Handlers), que são métodos invocados a partir de um evento, como o clique do usuário em um botão. Voltando ao exemplo, na linha 13, observa-se um componente que representa um botão em uma página HTML. Este botão, quando clicado, invocará o método manipularevento() do managed bean exemplomb, conforme indicado na expressão 17

27 #{exemplomb.manipularevento}, declarada como valor no atributo action do componente. O managed bean exemplomb pode ser implementado como demonstrado na classe conforme a figura 5: 01 public class ExemploMB { private String nome; 04 private String frase; public String getnome() { 07 return nome; 08 } 09 public void setnome(string nome) { 10 this.nome = nome; 11 } 12 public String getfrase() { 13 return frase; 14 } public String manipularevento() { 17 frase = "Oi, meu nome é " + nome + "."; 18 return "pagina2"; 19 } 20 } Figura 5. Exemplo da implementação de um managed bean A classe apresentada contém as propriedades nome e frase, as quais podem ser acessadas pelos componentes JSF presentes em uma página web por meio dos métodos get, para recuperar o valor da propriedade, e set, para atribuir um novo valor a ela. Com isso, percebe-se que, no exemplo discutido, um componente de uma página JSF pode recuperar o valor da propriedade nome e também alterar valor dela, pois o atributo nome da classe ExemploMB tem os métodos get e set correspondente. Já a propriedade frase pode ter seu valor recuperado, mas não alterado, pois o atributo frase só tem o método get, mas não o set. O método public String manipularevento() é um action handler, o qual pode ser invocado após lançamento de um evento por um componente de uma página JSF. Ele faz um processamento com os valores dos atributos do managed bean e retorna uma String, que servirá para indicar a página que deve ser apresentada após o processamento do método, conforme as regras de navegação configuradas no arquivo faces-config.xml. 18

28 Este arquivo, o faces-config.xml, é o principal arquivo de configuração de uma aplicação JSF. É lá onde são declarados os managed beans e as regras de navegação, conforme demonstrado na figura abaixo: 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 " 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> <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> Figura 6. Declaração de managed bean e definição de regra de navegação no faces-config.xml Entre as linha 06 e 10, na figura 03, é declarado um managed bean, com a indicação do nome pelo qual será referenciado na aplicação, do nome completo da classe que onde está sua implementação e do seu escopo, que pode ser de sessão (session), requisição (request) ou aplicação (application). Da linha 12 até a 18 tem-se a declaração de uma regra de navegação, indicando que quando uma requisição partir da view com o endereço /pagina1.xhtml e o action handler responsável por tratar a requisição retornar a String pagina2, deve-se exibir a view com identificada pelo endereço /pagina2.xhtml. Além de servir para declaração de managed beans e de regras de navegação, o faces-confi.xml também é usado para configurar componentes customizados, tais como conversores e validadores. Outro elemento importante em uma aplicação JSF é o arquivo descritor de implantação web.xml. É lá que é declarado o Servlet responsável por receber e processar todas as requisições recebidas do cliente, a partir de componentes JSF, o Faces Servlet. 19

29 1 <servlet> 2 <servlet-name>faces Servlet</servlet-name> 3 <servlet-class>javax.faces.webapp.facesservlet</servlet-class> 4 <load-on-startup>1</load-on-startup> 5 </servlet> 6 <servlet-mapping> 7 <servlet-name>faces Servlet</servlet-name> 8 <url-pattern>/faces/*</url-pattern> 9 </servlet-mapping> Figura 7. Delclaração do Faces Servlet no descritor de implantação web.xml RichFaces O RichFaces é um projeto de código aberto desenvolvido pela JBoss para auxiliar na construção de aplicações de internet ricas com o JSF. Consiste em um conjunto de componentes avançados de interface de usuário com o intuito de possibilitar uma fácil integração do potencial da tecnologia AJAX a aplicações JSF, sem a necessidade de recorrer a JavaScript para essa finalidade. Além disso, também propõe facilitar o trabalho de padronizar as interfaces de uma aplicação JSF, através do suporte a Skins. Este framework disponibiliza aos desenvolvedores duas tag libraries, a Core Ajax, geralmente referenciada pelo prefixo a4j, que contém componentes para configurar requisições AJAX nas páginas; e a UI, comumente referenciada pelo prefixo rich, que dispõe de recursos para adicionar características de interfaces ricas a aplicações JSF. Pode-se utilizar o RichFaces em aplicações JSF sem maiores dificuldades a partir da importação de algumas bibliotecas para o projeto e da realização de algumas configurações no arquivo descritor de implantação da aplicação, o web.xml Facelets Nas primeiras versões do JSF, 1.1 e 1.2, a tecnologia padrão para definição da camada de view era o JSP. Porém o Facelets surgiu como uma forte alternativa ao padrão estabelecido, de modo a proporcionar bastantes vantagens quando usado junto ao JSF. A prova do reconhecimento dessas vantagens foi a adoção desta tecnologia como padrão para definição da camada de visão do JSF na versão

30 O Facelets é uma linguagem de declarativa desenvolvida e apropriada para a construção da camada de visão do JSF. Entre as principais características relacionadas a esta tecnologia estão as seguintes: uso do XHTML como formato dos arquivos referentes às páginas web criadas; possibilidade de elaborar, de forma prática, templates para componentes e páginas; possibilidade de criar e reusar componentes compostos por outros; disponibilização de uma tag library própria para uso complementar aos componentes JSF; amplo suporte à linguagem de expressão e ao uso de componentes AJAX, adaptação; ampla adaptabilidade ao ciclo de vida JSF; entre outros. Dentre as vantagens do uso dessa tecnologia, pode-se citar a capacidade de promover o reuso de código através de templates e da composição de componentes; o menor tempo necessário para a compilação e melhor performance na renderização de componentes em relação ao JSP; a independência em relação ao container web; a validação de EL em tempo de compilação; a grande precisão no apontamento de erros, de modo a facilitar a depuração. Em suma, o uso do Facelets reduz o tempo e o esforço que precisa ser gasto no desenvolvimento e implantação [The Java EE 6 Tutorial] Enterprise JavaBeans (EJB) A tecnologia EJB propõe um ambiente diferenciado para a execução de componentes de negócio de aplicações corporativas Java. Este ambiente é chamado de container EJB, que é uma das partes dos servidores de aplicações corporativas em conformidade com as especificações JEE, tais como o Jboss Application Server e o GlassFish Server. Ele tem o papel de assumir a responsabilidade por prover importantes serviços para os Enterprise beans como são denominados os componentes implementados com a tecnologia, tais como: gerenciamento de transações, controle de instâncias e segurança. Isso faz com que a implementação desses serviços seja abstraída para os desenvolvedores das aplicações, de modo que estes possam se concentrar mais em resolver problemas decorrentes da lógica de negócio. Um Enterprise Bean pode ser classificado em dois tipos principais, Session Bean (Bean de Sessão) ou Message-drive Bean (Bean Orientado a Mensagem). 21

31 Bean de Sessão Os beans de sessão são objetos de classes implantadas no servidor que realizam tarefas a partir de solicitações de clientes. Eles encapsulam a lógica de negócio de uma aplicação, se responsabilizando pela execução de processos complexos. Podem ser invocados programaticamente através de chamadas aos métodos de suas interfaces, que podem ser locais, remotas ou web service, e podem ser do tipo Stateful, Stateless, ou Singleton. Um bean de sessão stateful atende às requisições de apenas um cliente, mantendo o estado conversacional com ele, de forma que os valores de seus atributos são mantidos entre as requisições realizadas entre a sua instanciação, provocada pela primeira requisição, até a desconexão do cliente. Um stateless, por sua vez, é compartilhado entre vários clientes e não mantém estado conversacional com nenhum, de modo que, ao final da execução de cada método, os estado de seus atributos não são mantidos. Exceto durante a invocação de método, todas as instâncias de um bean stateless são equivalentes, permitindo que o container EJB atribua uma instância para qualquer cliente. Devido ao fato de eles poderem suportar vários clientes, beans de sessão pode oferecer uma melhor escalabilidade para aplicações que requerem um grande número de clientes [The Java EE 6 Tutorial] Um bean de sessão do tipo singleton só tem uma instância para toda a aplicação, a qual é a responsável por atender as requisições de todos os clientes. Este tipo de bean mantém os estado de suas variáveis entre as requisições feitas para ele. Beans de sessão singleton são projetados para circunstâncias em que uma instância de bean única é acessada por clientes em condições de concorrência. [The Java EE 6 Tutorial] Vale também ressaltar que um bean stateless, bem como um singleton podem implementar um web service, mas um stateful não Bean Orientado a Mensagem Os beans orientados a mensagem são componentes que possibilitam o processamento de mensagens de forma assíncrona por aplicações JEE. Eles geralmente atuam como listeners de mensagens de um JMS (Java Messages Service ou Serviço de Mensagens Java), que são enviadas por clientes. Além de mensagens 22

32 JMS, este tipo de bean pode também processar mensagens de outros tipos de MOM (Message-Oriented Middleware). Diferentemente do que ocorre com os beans de sessão, os componentes clientes não acessam os métodos de beans de mensagem diretamente, através de interfaces. Ao invés disso, enviam mensagens por meio de um middleware, cada uma destinada ao bean que deve processá-la. Quando a mensagem chega, o container invoca o método onmessage do bean destinatário, que deve processá-la de acordo com as regras de negócio da aplicação, podendo, para isso, chamar métodos auxiliares, invocar um bean de sessão ou armazená-la no banco de dados Java Persistence API (JPA) É fato que o uso de bancos de dados relacionais é amplamente difundido em grande parte das aplicações de software desenvolvidas, assim como o paradigma da programação orientada a objetos (POO) é uma tendência largamente utilizada no desenvolvimento de sistemas. No entanto, o paradigma relacional e o orientado a objetos possuem características e operam sobre conceitos bastante distintos, de forma a tornar complexa as operações da POO realizadas sobre dados armazenados em estruturas relacionais. Considerando esse contexto, a JPA constitui-se em uma alternativa para abstrair essa complexidade e facilitar a maneira de trabalhar com bancos de dados relacionais dentro da programação orientada a objetos. Segundo a própria documentação oficial da tecnologia [The Java EE 6 Tutorial], a JPA fornece um mecanismo para desenvolvedores realizarem um mapeamento objeto-relacional e facilita o gerenciamento de dados relacionais em aplicações Java. O modelo da JPA é simples, elegante, poderoso e flexível, constituindo-se com base no mapeamento objeto-relacional realizado para as entidades, que são classes Java simples, representantes dos objetos persistentes do modelo de domínio da aplicação. Este mapeamento é feito por meio da utilização de metadados, que podem ser representados através de marcações feitas em arquivos de configuração XML ou de anotações inseridas no código das entidades JPA. A atividade de mapear entidades JPA baseia-se na idéia de configuração por exceção, de modo que o mecanismo de persistência assume valores default para a maioria das situações. Dessa forma, considerando o uso de valores padrão estabelecidos pela API, são necessárias apenas declarações mínimas de metadados, 23

33 sendo preciso declarar configurações adicionais apenas se houver a necessidade de alterar os valores default. A seguir serão indicadas algumas anotações, as quais se encontram definidas no pacote javax.persistence, utilizadas para realizar configurações de mapeamento básicas em entidades JPA. Duas anotações são essenciais e obrigatórias em uma entidade A primeira indica que a classe deve ser entendida como uma entidade a ser persistida, enquanto a segunda informa qual propriedade da classe deve ser a chave primária da tabela que representará a entidade no banco de dados. A é usada para indicar que a chave primária deve ser gerada automaticamente. As especificam, respectivamente, as propriedades de uma tabela e de uma coluna no banco de dados, tal como o nome, por exemplo. A informa que os valores de determinada coluna não podem ser nulos, define um padrão para o valores de uma coluna e define que o valor de determinada propriedade não será persistido. As anotações que indicam a multiplicidade em um relacionamento entre entidades (relacionamento um-para-um (relacionamento umpara-muitos (relacionamento muitos-para-um ) (relacionamento muitos-para-muitos ). A seguir, uma figura que exibe um trecho de código exemplificando o mapeamento de uma entidade do projeto que é objeto de estudo desse trabalho. 24

34 02 public class Aluno implements Serializable { private int id; 08 private String nummatricula; 09 private String nomedopai; 11 private String nomedamae; 13 private TipoDeAluno tipodealuno; 15 private boolean matriculado; private Pessoa pessoa; private List<Matricula> matriculas; // Métodos gets e sets omitidos nesta imagem Figura 8. Exemplo de mapeamento objeto-relacional de uma entidade com anotações A gerência do estado de persistência das entidades é feita por meio da utilização da interface EntityManager. Ela fornece métodos para persistir novas instâncias de entidades; buscar, mesclar ou remover instâncias de entidades persistidas, verificar se uma instância está sendo gerenciada pelo contexto de persistência, obter objeto para realizar transação de banco de dados, etc. Há também um mecanismo de consultas baseado em objetos, o qual abstrai o conhecimento a respeito de estruturas relacionais de armazenamento de dados, de modo que, para colocar na memória entidades persistidas e seus relacionamentos, não seja necessário conhecer colunas nem chaves estrangeiras de tabelas, por exemplo. As consultas são expressas em JPQL, uma linguagem de consulta que é derivada de EJB QL e possui sintaxe parecida com a do SQL, mas que não está vinculada com o esquema de banco de dados. Essas consultas retornam resultados que são entidades, proporcionando valiosas abstrações e permitem a consulta através de objetos do modelo de domínio Java em vez de em tabelas do banco de dados. A figura a seguir demonstra uma situação de uso de uma consulta JPQL que, quando executada, retorna uma lista de objetos do domínio. A consulta seleciona somente os objetos 25

35 persistidos da classe Matrícula que tiverem como valor do seu atributo aluno um objeto correspondente ao que é passado como parâmetro para a consulta Query query = em.createquery("select m from Matricula m where " + 03 "m.aluno=:aluno order by m.data desc"); query.setparameter("aluno", aluno); 06 List<Matricula> matriculas = query.getresultlist(); 07 Figura 9. Exemplo de uma consulta com JPQL O modelo de entidades móveis, que provê a possibilidade de uma entidade se desacoplar do módulo de persistência, ser transportada via rede e manipulada em outras aplicações ou máquinas virtuais, para depois retornar e ser re-acoplada ao contexto de persistência, também é uma importante característica da JPA, levando em consideração as arquiteturas cliente/servidor aplicações web e distribuídas, de um modo geral. Em síntese, conforme posto em [Keith e Schincariol 2006], A Java Persistence API realmente introduziu uma nova era na persistência integrada padronizada. Ao ser executado dentro de um container JEE, todos os benefícios de suporte do container e facilidade de uso superior aplicam-se, mas também pode ser configurado para ser executado fora do contêiner, em ambientes JSE. 26

36 3. ESTUDO DE CASO Neste capítulo serão abordadas questões a respeito do ciclo de desenvolvimento do projeto Soft Educ GCI, considerando-se os seguintes fatores: 1) o contexto que motivou a realização do projeto; 2) a organização dos stakeholders em torno de valores, princípios e práticas próprios de processos de desenvolvimento ágeis; 3) o escopo definido e os requisitos estabelecidos; 4) as tecnologias e as ferramentas utilizadas no processo; 5) os mecanismos utilizados para gerir o projeto; 6) a arquitetura proposta para o sistema, o projeto e implementação de suas funcionalidades; e 7) os resultados obtidos no trabalho Contextualização do Projeto Como mencionado na introdução deste trabalho, o projeto Soft Educ GCI consiste na construção de uma estrutura de software apropriada para auxiliar na execução de atividades próprias do fluxo de trabalho do Centro de Idiomas FUNCERN. No início do projeto, entre os meses de setembro e dezembro de 2010, quando o projeto estava associado a disciplina de PDSC, mencionada na sessão 1.1, a equipe de desenvolvedores era formada por cinco desenvolvedores. A partir da segunda fase do desenvolvimento, iniciada em março de 2011, quanto o projeto já não se situava mais no contexto da disciplina de PDSC, a equipe teve o número de integrantes reduzido para três. Nos primeiros contatos entre a coordenação do Centro de Idiomas FUNCERN, representada pela pessoa do senhor Fernando Ferreira Carneiro Filho, e o grupo de estudantes, houve, por parte da instituição, demonstração de insatisfação com o aparato informacional utilizado para auxiliar na execução das atividades próprias de seu processo organizacional, bem como a expressão de um desejo nítido de evoluir em relação a esse contexto. Com isso, a representação do grupo de desenvolvedores, o qual estava envolvido na conjuntura da disciplina mencionada anteriormente, propôs trabalhar, durante os três meses seguintes, no intuito de criar soluções computacionais para tentar resolver os gargalos existentes na estrutura informacional da organização. Durante a fase imediatamente anterior ao início do projeto, quando ocorreram os diálogos pré-eliminares, a equipe de desenvolvimento colheu e documentou várias e importantes informações referentes ao processo de negócio da organização e aos 27

37 softwares utilizados para administrar e manter esse processo. Buscou-se observar, com uma óptica abrangente, as características dos sistemas, o que era positivo e negativo em relação ao uso deles, as inconveniências que geravam para a manutenção do fluxo de trabalho organizacional. Foi notado que, essencialmente, eram utilizados dois sistemas na instituição. Um deles, uma aplicação web para sorteio de vagas nas turmas de 1º nível dos cursos oferecidos. Tal sistema permitia a realização de inscrições via web dos candidatos interessados pela vagas, e, após período de inscrições, promovia o sorteio das vagas entre os inscritos. O outro, um sistema cliente/servidor que, no cliente, executava em ambiente desktop, era utilizado para controle interno da coordenação, dos cursos, das turmas e dos alunos da organização. Logo se percebeu que esses sistemas não ofereciam condições de uso satisfatórias, e que não atendiam devidamente as demandas geradas pelas necessidades do processo de trabalho na coordenação dos cursos de idiomas. Foram constatadas nítidas dificuldades para operar e manter os dois sistemas, de modo a justificar a insatisfação dos usuários. A seguir, é feita a listagem e a descrição dos problemas encontrados pelo grupo de desenvolvedores do Soft Educ GCI quanto ao aparato informacional então utilizado para apoiar as atividades do Centro de Idiomas FUNCERN. Na sequência do conteúdo desta seção, o sistema que realiza sorteio das vagas para as turmas de 1º nível será chamado de sistema I e o sistema usado para controle interno de cursos, turmas e alunos será referenciado como sistema II. Falta de integração entre os sistemas utilizados. O sistema I e o sistema II não estabeleciam nenhuma forma de comunicação entre eles. Os dados inseridos no sistema I, na inscrição de um candidato para o sorteio, por exemplo, não eram reaproveitados pelo sistema II durante a realização da matrícula de um candidato sorteado. Isso gerava uma demanda de trabalho desnecessária para efetivar matrículas dos candidatos sorteados, pois os dados deles, que deveriam ser recuperados, eram redigitados pelos funcionários. Tal situação provocava também maiores tempos de espera das pessoas por atendimento, deixando insatisfeitos os clientes que procuravam se matricular no 1º nível dos cursos. 28

38 Dificuldades e falta de autonomia para operar o sistema I. O coordenador da organização não possuía autonomia para operar diretamente na coordenação das funções do sistema I. A cada novo semestre, ele tinha que recorrer à pessoa responsável pelo desenvolvimento do sistema, para que esta pudesse executar suas funcionalidades: abrir período de inscrições, gerar relatórios de inscrições, realizar sorteio de vagas, gerar documento com listagem de sorteados. Essa situação era pouco cômoda e confortável para a organização. O sistema II não atendia a várias demandas importantes para os usuários. Foi constatado que o sistema II não oferecia suporte apropriado a vários procedimentos do fluxo de trabalho na organização. Como exemplos disso, podem ser enumeradas as seguintes situações: 1) Não possibilitava um controle específico para as provas de nivelamento realizadas, e os resultados dos alunos nessas provas não eram registrados; 2) Não possibilitava listar os alunos de uma turma com seus respectivos contatos (telefones e ), o que dificultava o trabalho quando havia necessidade de comunicar algo a estes alunos rapidamente, como no caso do adiamento de uma aula; 3) Não promovia um tratamento adequado quanto ao número de vagas remanescentes, nas turmas, para alunos bolsistas e para alunos pagantes, uma vez que o sistema tratava de modo indiferente estes dois tipos de alunos; 4) O procedimento de matrícula não permitia o registro da opção de pagamento do cliente de acordo com todas as formas de pagamento previsíveis na instituição, de modo que, inúmeras vezes, os dados do pagamento eram registrados de maneira incompatível com a realidade e recibos de pagamento eram emitidos com dados incorretos, o que dificultava o controle de pagamentos; 5) Não era disponibilizada, para o usuário, informações indicando se o aluno havia sido aprovado ou reprovado, ou havia cancelado a matrícula nas turmas pelas quais passou. Sistema II apresentava grande número de bugs. Eram vários os erros observados no funcionamento do sistema II, entre eles: 1) Inconsistências na contagem das vagas disponíveis nas turmas quando alunos eram transferidos de uma turma para outra; 2) Algumas telas e botões não funcionavam; 3) Durante a execução de alguns fluxos de atividades, o sistema travava e tinha que ser fechado. 29

39 Interface gráfica do sistema II pouco clara e intuitiva aos usuários. Os conceitos se confundiam na apresentação das telas do sistema, o que tornava difícil o entendimento e a execução de várias funcionalidades, dificultando o trabalho dos usuários, principalmente dos que eram pouco experientes. Além disso, havia diversas funcionalidades que os usuários nunca entenderam ou utilizaram. Figura10. Exemplo da falta de clareza e de intuitividade na interface gráfica do sistema II Figura 11. Exemplo de componente de interface gráfica do sistema II que apresenta um funcionalidade nunca compreendida pelos usuários 30

40 Sistema II apresentava graves falhas de segurança. As credenciais de acesso eram compartilhadas por todos os usuários, e todos tinham possibilidades de acessar qualquer funcionalidade disponível no sistema. Isso permitia que qualquer pessoa, ao acessar o sistema, pudesse violar informações importantes, deixando os dados do sistema inconsistentes. Para reforçar o ambiente de insegurança, existia uma tela que aparentemente permitia a manipulação do banco de dados através de comandos SQL, o que poderia representar um potencial risco a segurança dos dados. Somando-se a esses problemas, não havia nenhum mecanismo de auditoria para registrar as ações realizadas, vinculando-as aos usuários que as efetivaram e às datas em que ocorreram. Figura 12. Tela do sistema II que aparenta permitir manipulação de dados através de comandos SQL O sistema II era pouco flexível/configurável. Para realizar configurações simples, que deveriam estar disponíveis para os usuários, era necessário 31

41 recorrer a serviços de manutenção realizada pelo responsável pelo desenvolvimento do sistema. Dificuldades para obtenção de serviços de manutenção no sistema II. O serviço de manutenção do software não respondia de forma rápida, eficaz e eficiente às requisições feitas pela coordenação dos cursos de idiomas. Não havia solução informacional dedicada a facilitar a comunicação entre coordenação, professores e alunos. Não havia, por exemplo, a possibilidade de os professores das turmas lançarem notas e freqüências dos alunos diretamente em um sistema, nem a de os alunos consultarem suas notas e freqüência via internet Aplicação de Processo Baseado em Metodologias Ágeis Decidiu-se que o processo de desenvolvimento do projeto Soft Educ GCI tomaria como base valores, princípios e práticas propostos por metodologias ágeis de desenvolvimento de software. Essa decisão tinha o principal objetivo de fazer com que às mudanças ou acréscimos de requisitos sugeridos pelo cliente pudessem ser processados e incorporados ao software com rapidez e eficiência. Também se pretendia maximizar a produtividade do trabalho da equipe, de modo a não permitir que a documentação exigida por processos mais tradicionais e menos flexíveis fossem uma barreira à entrega de software funcional ao cliente. Portanto buscou-se estabelecer um processo compatível com as características do grupo de desenvolvedores, baseandose no ciclo de vida do Scrum, e incorporando outras características fundamentadas no manifesto ágil e no XP. Inicialmente foi prevista para o processo uma fase pré-eliminar ao sprints de desenvolvimento, uma espécie de concepção, na qual seriam tomadas decisões arquiteturais e tecnológicas básicas, e realizadas algumas reuniões entre o time de desenvolvedores e o product owner, a fim de elucidar requisitos do sistema e documentar as funcionalidades pretendidas. Durante esta fase foi construído um plano, o product backlog, que continha as funcionalidades e características pretendidas e uma previsão do calendário de sprints. Também se definiu o conjunto de tecnologias e ferramentas que seriam utilizados no início do desenvolvimento, e a 1ª versão do modelo de domínio do sistema. 32

42 Quanto aos papéis dentro do time do projeto, decidiu-se que o coordenador do centro de idiomas, Fernando Carneiro, seria o product owner, ou seja, o principal representante do cliente e dos usuários do sistema. Em relação aos desenvolvedores, foi proposto um mecanismo de auto-organização, no qual todos deveriam contribuir no planejamento e no monitoramento e controle das atividades, emitindo suas opiniões para serem discutidas entre o grupo. A cada novo sprint, o papel de scrum master seria alternado entre os integrantes da equipe. O fragmento textual a seguir, extraído do plano de desenvolvimento de software do projeto, relata sobre a proposta inicial de estrutura organizacional e responsabilidades. Toda a equipe de desenvolvimento estará em ordem hierárquica equivalente e deverá trabalhar de forma cooperativa, tentando contribuir, sempre que necessário, para resolver as dificuldades dos companheiros, visando sempre o melhor para o coletivo. Os valores comunicação, proatividade, criatividade, respeito, coragem e companheirismo deverão basear as relações dentro da equipe de desenvolvedores e entre a equipe e os demais stakeholders. A cada sprint a equipe deverá alternar o scrum master, o qual terá, além das atividades de desenvolvedor, a responsabilidade adicional de conduzir as reuniões do grupo durante o sprint, orientar e monitorar o trabalho, cobrar resultados do grupo e resolver conflitos internos. Todos os desenvolvedores deverão ter suas opiniões consideradas para as decisões tomadas durante o processo. Tais decisões de planejamento, estratégia e controle devem ser estabelecidas a partir do diálogo da equipe em reuniões de planejamento, de revisão ou de retrospectiva de sprint. [Plano de Desenvolvimento Software Soft Educ GCI] Em geral, o planejamento do projeto prevê sprints com duração de 4 semanas, de modo que o objetivo principal, ao final de cada sprint, é entregar um incremento no software, através da instalação e disponibilização de uma nova versão funcional do sistema para que os usuários possam experimentar e produzir feedback. O início de cada sprint é marcado por uma reunião de planejamento entre desenvolvedores e o product owner, na qual as prioridades são reavaliadas dentro do contexto do projeto e são decididas quais funcionalidades e características devem ser incorporadas ao software durante a iteração. Após isto, há uma nova reunião envolvendo somente os desenvolvedores, quando são formuladas e estimadas as atividades necessárias para se atingir o objetivo do sprint. Os dados das atividades são registrados na ferramenta utilizada para gerenciar o projeto, o Assembla. Os desenvolvedores trabalham em um mesmo ambiente e, a cada dia de trabalho, durante o sprint, ocorre uma reunião curta (cerca de 15 minutos) entre eles, 33

43 na qual cada um expõe sobre o andamento de sua atividade. Algumas atividades, as de maior prioridade, são atribuídas aos desenvolvedores no planejamento do sprint, outras são atribuídas ao longo da iteração. Caso a equipe observe que é necessária uma nova atividade que não foi prevista no planejamento inicial, ela deverá ser integrada ao sprint backlog durante a execução do sprint. Ao final de cada expediente de trabalho, os desenvolvedores devem reportar, no Assembla, os avanços obtidos ou dificuldades encontradas na realização de suas atividades e atualizar o tempo estimado para a conclusão delas. A partir desta atualização do tempo estimado, o Assembla constrói o gráfico de sprint burndown, um importante instrumento de observação da curva de desempenho da equipe ao longo a iteração. Figura 13. Exemplo de gráfico de sprint burndown do projeto Soft Educ GCI A equipe trabalha integrando diariamente o código que produz, através do sistema de controle de versões SVN. O código produzido é de propriedade coletiva e o uso de alguns padrões de codificação pré-estabelecidos é estimulado e recomendado dentro do time. Também é recomendado que o código produzido seja simples, claro e expressivo tanto quanto o possível, e, frequentemente, são realizadas atividades de refatoração. 34

44 Semanalmente, ao menos uma vez, representantes da equipe reúnem-se com o product owner ou com usuários do sistema para demonstrar os resultados parciais do trabalho de um sprint, tirar dúvidas relacionadas a regras de negócio, ou questionar sobre preferências quanto a aspectos da interface gráfica e da interação usuáriosistema. Dessa forma é possível colher feedback de forma rápida e promover a evolução do software baseado na evolução dos conceitos dos usuários em relação ao sistema, que ocorre na medida em que o software passa de algo abstrato, contido somente no plano das idéias, para algo mais concreto e utilizável. Este modelo de relacionamento entre desenvolvedores e usuários tende a deixar os usuários mais satisfeitos. Ao final de cada sprint é realizada uma reunião que marca a entrega da versão ao product owner. Nela, representantes da equipe de desenvolvimento apresentam os resultados finais do sprint, e entregam o relatório de atividades, que é exigência do cliente. O product owner, por sua vez, avalia o que foi cumprido e o que não foi em relação aos objetivos esperados para o marco, tendo a liberdade para emitir suas opiniões em relação ao trabalho dos desenvolvedores. Após isso, a instalação da versão, no servidor de testes, é providenciada. Após a reunião com o product owner, para apresentar os resultados da iteração, é realizada uma reunião de retrospectiva de sprint somente entre os membros do time de desenvolvimento. Nela devem ser relembrados os pontos positivos e negativos que se destacaram durante o sprint. Propõe-se uma reflexão sobre que ajustes no comportamento do time poderiam produzir aumento da efetividade e da eficiência. Discuti-se o que deve ser acrescentado ao processo ou removido dele. Essa retrospectiva faz-se no intuito de promover a melhoria continua do processo, do ambiente de trabalho e do relacionamento entre os integrantes da equipe. Conforme descrito ao longo dessa seção, a estrutura do processo de desenvolvimento do projeto Soft Educ GCI e o conjunto de práticas relacionadas demonstram uma organização profundamente relacionada às idéias propostas pelas metodologias ágeis. No entanto, algumas práticas essencialmente defendidas por esse tipo de metodologia não foram incorporadas ao desenvolvimento do projeto. Como exemplo de uma prática ágil não aplicada, pode-se citar a automatização de testes. Essa prática é extremamente importante e útil, mas não foi integrada ao projeto por falta de qualificação técnica da equipe. Nenhum integrante do time tinha domínio de ferramentas e técnicas que possibilitassem aplicá-la e ainda não foi 35

45 possível dedicar tempo o suficiente para que alguém do time se capacitasse para isso. A não utilização de testes automatizados no processo representa uma falta que é bastante sentida por todos os desenvolvedores, pois torna mais difícil validar a correção das funcionalidades implementadas e deixa o sistema mais vulnerável a introdução de bugs. Assim sendo, almeja-se integrar essa prática ao processo o quanto antes, já tendo sido, inclusive, realizadas atividades com o objetivo de estudar e experimentar ferramentas de testes automatizados Escopo e Requisitos do Sistema Com fins de resolver os problemas mencionados na seção 3.1 deste trabalho, o escopo do projeto Soft Educ GCI consiste na elaboração de um sistema informacional integrado, apresentando-se em três módulos distintos para os seus usuários: o módulo coordenação, acessível para o coordenador dos cursos de idiomas, funcionários e bolsistas que desempenham atividades na secretaria da coordenação; o módulo público, acessível para qualquer usuário da web; e o módulo acadêmico, acessível para professores e alunos da organização. A descrição dos escopos de cada módulo, bem como dos seus requisitos funcionais e não funcionais serão apontados nas subseções a seguir Módulo Coordenação O módulo coordenação é o mais completo e complexo do sistema e propõe atender as demandas das atividades fundamentais para a organização, manutenção e controle da estrutura dos cursos de idiomas oferecidos. A seguir, estão descritos os requisitos funcionais referentes a este módulo. RF 01- Gerência de usuários. Possibilidade de cadastrar novos usuários do módulo coordenação, atribuindo a eles um papel de usuário, e permitindo que utilizem as funcionalidades do sistema disponíveis de acordo com papel que exercem. Deve ser possível também listar os usuários cadastrados e pesquisá-los a partir de seus nomes ou CPF, bem como visualizar e editar os dados deles ou desativá-los, removendo o direito de acesso deles ao sistema. RF 02- Gerência de professores. Possibilidade de cadastrar novos professores para os cursos de idiomas, de listar os professores cadastrados, de pesquisá-los a partir de seus nomes ou CPF, de visualizar e de editar os dados deles, e de 36

46 desativá-los, não permitindo que sejam associados a uma nova turma configurada. RF 03- Gerência de cursos. Possibilidade de cadastrar novos cursos, de listar os cursos cadastrados, de editar os nomes ou número de níveis deles e de desativálos. O cadastro e a edição de um curso só dever ser possível quando não houver um semestre em andamento. RF 04- Abertura e configuração de semestre letivo. Possibilidade de configurar dados relativos a um novo semestre de aulas, registrando as datas importantes, a quantidades de vagas disponíveis nas turmas para os diferentes tipos de alunos, e os custos dos cursos. Após registrados, os dados do semestre devem poder ser alterados no sistema. Na abertura de semestre também devem ser criadas as turmas disponíveis para o semestre. RF 05- Configuração de turmas. Possibilidade de atribuir um professor a uma turma, indicar o local, os dias e os horários de aulas. Só devem poder ser associados a uma turma professores do curso correspondente a turma. RF 06- Listagem dos alunos de uma turma. Possibilidade de listar todos os alunos de uma Tuma com seus respectivos telefones para contato e . RF 07- Gerência de inscrições para sorteio. Possibilidade de consultar inscrições realizadas para sorteio das vagas das turmas de 1º nível do semestre corrente. Deve permitir listar inscritos de cada turma separadamente e fazer pesquisas de inscrições com dados iguais ou semelhantes. Também deve possibilitar o cancelamento de inscrições. RF 08- Gerência de sorteios. Possibilidade de visualizar relatório de demanda para as vagas remanescentes nas turmas de 1º nível, de realizar 1 ou mais sorteios destas vagas, de visualizar listagem de sorteados e de gerar arquivo PDF com tal listagem. RF 09- Gerência de provas de nivelamento. Possibilidade de cadastrar sessões de provas de nivelamento, de listar as sessões de provas de nivelamento cadastradas no semestre corrente, de editar os dados delas e de excluí-las. Só devem poder ser excluídas sessões de provas de nivelamento que ainda não tiverem nenhum candidato inscrito. O sistema também deve possibilitar a listagem dos inscritos em uma sessão. 37

47 RF 10- Inscrição de candidatos a nivelamento. Possibilidade de inscrever candidatos a nivelamento, associando-os a uma sessão de nivelamento cadastrada e gerando um recibo de inscrição. RF 11- Registro e consulta a resultados em provas de nivelamento. Possibilidade de registrar o nível de certificação atingido para cada candidato inscrito em uma sessão de nivelamento, bem como de consultar esses registros a partir da pesquisa pelo nome ou CPF da pessoa que realizou a prova. RF 12- Gerência de alunos. Possibilidade de cadastrar novos alunos, de pesquisar os alunos cadastrados através de seus nomes ou CPF, de visualizar e de editar os dados deles. RF 13- Matrícula de aluno. Possibilidade de vincular um aluno a uma turma, registrando os dados de pagamento e gerando um recibo de matrícula ao final do processo. Para uma pessoa ser matriculada em uma turma, ela deve estar em conformidade com pelo menos um dos seguintes requisitos: ter sido previamente cadastrada no sistema, ter sido sorteada para uma vaga de uma turma de 1º nível de um dos cursos, ou ter obtido uma certificação em uma prova de nivelamento. O sistema deve possibilitar também o cancelamento de uma matrícula. RF 14- Transferência de alunos entre turmas. Possibilidade de transferir alunos matriculados em uma turma para outra turma do mesmo curso e de mesmo nível. Após realização de transferências devem ser gerados comunicados de transferência. RF 15- Histórico do aluno. Possibilidade de observar as turmas pelas quais um aluno passou e visualizar se o aluno foi aprovado, reprovado ou cancelou a matrícula em cada turma. Também deve ser disponibilizado o histórico de transferências do aluno. RF 16- Controle de notas e freqüência. Possibilidade de registrar a presença ou o número de faltas dos alunos de uma turma a cada aula, e de inserir as notas dos alunos em cada avaliação. Deve-se permitir indicar que as atividades de uma turma foram concluídas, para, quando isso acontecer, o sistema informar se os alunos daquela turma foram aprovados ou reprovados, de acordo com as notas e a freqüência deles. RF 17- Certificados de aprovação. Possibilidade de gerar arquivo PDF com certificados para os alunos aprovados nas turmas de um semestre letivo. 38

48 RF 18- Folhas de registro. Emissão de documentos contendo uma lista enumerada com todos os alunos aprovados durante um semestre letivo. Dos dezoito requisitos funcionais previstos para este módulo, quinze já foram implementados, representando mais de 80% do total. Já em relação aos requisitos nãofuncionais, foram previstos dois, os quais estão descritos a seguir. Deles, apenas o primeiro já está implementado. RNF 01- Autenticação e autorização de acesso a funcionalidades. Necessidade de o usuário estar autenticado no sistema para poder acessar qualquer funcionalidade. Cada usuário deve ter suas próprias credenciais de acesso, login e senha, sendo que não pode haver dois usuários como o mesmo login. Quando o usuário autentica-se, o sistema deve identificar o papel que o usuário exerce no sistema e autorizar o acesso dele somente às funcionalidades disponíveis para o papel associado. RNF 02- Auditoria de ações importantes. Registro da data e do horário de em que determinadas ações foram executadas no sistema, bem como do usuário responsável pela realização da ação Módulo Público O módulo público dedica-se exclusivamente a proporcionar, ao público em geral, a possibilidade de se inscrever para o sorteio às vagas das turmas de 1º nível dos cursos oferecidos. O único requisito para este módulo é o seguinte: RF 19- Inscrição para Sorteio. Possibilidade de realização de inscrições de candidatos para concorrer a sorteio das vagas nas turmas de 1º nível disponibilizadas no semestre corrente. O sistema só deve permitir que o candidato possa escolher uma turma. Após a realização de uma inscrição, o sistema deve permitir a geração de um comprovante de inscrição, indicando a turma para qual se inscreveu, a data de divulgação da 1ª chamada e a de matrícula. As inscrições só devem ser permitidas em um dado período, que deve ser pré-configurado durante a abertura do semestre letivo, no módulo público. 39

49 Este requisito RF 19 já está implementado, e este módulo não apresenta requisitos não funcionais Módulo Acadêmico O módulo acadêmico constitui-se em uma ferramenta para os professores registrarem informações quanto ao andamento das aulas nas turmas, à freqüência e às notas dos alunos, a fim de que estes possam acessar essas informações via internet. Dentre os requisitos funcionais para este módulo, está o requisito RF 16, descrito na seção Os demais, que ainda não foram descritos, são: RF 20- Boletim. Possibilidade de os alunos acessarem seus boletins através do sistema. RF 21- Relatório de Aulas. Possibilidade de os alunos observarem a lista de aulas já lecionadas com suas respectivas datas, conteúdos ministrados, e a informação do número de faltas do aluno em cada dia de aula. A implementação do módulo acadêmico ainda não foi iniciada e está prevista para começar no mês de agosto de 2011, conforme o planejamento do projeto entregue ao cliente. Sendo assim, os professores e alunos da organização ainda não estão utilizando o sistema. Os requisitos não funcionais previstos para este módulo são os mesmos previstos para o módulo coordenação (RNF 01 e RNF 02) Ferramentas e Tecnologias Aplicadas No intuito de gerenciar as atividades e as informações do projeto, a principal ferramenta escolhida para esta finalidade foi o Assembla ( conforme já havia sido mencionado na seção 3.2 deste trabalho. No entanto, a equipe também se utilizou de outras ferramentas auxiliares para apoiar a comunicação e o compartilhamento de informações, quais sejam o Google Groups, o Google Docs e o Gmail. Em síntese, no Assembla era registrado o planejamento das iterações, a descrição e os prazos das atividades e as informações referentes aos resultados delas. Enquanto isso, os serviços do Google eram utilizados principalmente para enviar rapidamente mensagens a todos os membros do grupo e para compartilhar documentos relacionados a controle de bugs, controle de acesso a funcionalidades e cronograma do projeto, por exemplo. 40

50 Como sistema de controle de versionamento dos arquivos do projeto, adotou-se o SVN, por meio de serviço disponibilizado pelo Assembla, que fornece uma interface gráfica amigável para observar a evolução das versões dos arquivos inseridos no repositório e para acompanhar os commits, suas descrições e mudanças que realizaram. Foi decidido que o sistema seria implementado utilizando-se a linguagem Java versão 6 e as tecnologias da plataforma JEE que foram explicadas na seção 2.2 deste trabalho. A JPA foi utilizada para promover o mapeamento objeto-relacional e simplificar o mecanismo de comunicação entre a aplicação e a camada de persistência; O EJB 3.0 foi usado com a finalidade de encapsular a lógica de negócios e a interação com o banco de dados, obtendo as vantagens fornecidas pelo container EJB; E o JSF 1.2 foi empregado de forma integrada ao RichFaces 3.3 e ao Facelets, para construir as interfaces web do sistema e programar a interação cliente-servidor via web. O servidor de aplicações coorporativas escolhido para executar o sistema foi o JBoss Application Server versão 5.1. Quanto ao Sistema de Gerenciamento de Banco de Dados para hospedar o banco de dados da aplicação, optou-se pelo PostgreSQL versão 8.4. Procurou-se padronizar a instalação dos softwares nas estações de trabalho dos desenvolvedores e configurar ambientes de desenvolvimento homogêneos para os membros da equipe, a fim de evitar problemas de incompatibilidade de recursos consumidos ou produzidos. Nesse sentido, o time decidiu usar o sistema operacional Ubuntu, na versão bits, e a IDE Eclipse Helios com os plugins Subversive, para integração com o SVN, e JBoss Tools, para facilitar o trabalho com as tecnologias associadas a plataforma JEE. Para a produção e edição de imagens foram utilizadas principalmente as ferramentas GIMP, Inkscape e Pixlr Editor. Para a produção de artefatos de modelagem do sistema, utilizou-se o Astah Community e o OpenOffice Draw. O Windows 7 foi empregado como sistema operacional alternativo. Os programas do pacote Microsoft Office foram utilizados na produção de documentos de texto formatado e de apresentações de slides Arquitetura e Modelagem do Sistema Conforme explicado na seção 3.3, os requisitos funcionais do projeto Soft Educ GCI estão subdivididos em três módulos distintos, e é desta forma que o software deve 41

51 se apresentar para seus usuários. Com o intuito de atender as demandas desses requisitos modulares, e considerando às tecnologias da plataforma JEE utilizadas e os conceitos relacionados às mesmas, abordados na seção 2.2 deste trabalho, propôs-se, para a implementação do sistema, uma solução arquitetural baseada em componentes que será detalhada ao longo desta seção. Observe-se que, como foi dito anteriormente, o módulo acadêmico ainda não começou a ser desenvolvido, e por isso esta seção não abordará aspectos arquiteturais relacionados a este módulo em específico. Antes de se analisar a arquitetura com base na visão de componentes, a qual retrata a relação entre os principais componentes lógicos, será brevemente explicada a visão de casos de uso do sistema, que relaciona os atores (usuários) às funcionalidades que eles poderão acessar. Para os diagramas apresentados nas figuras 14-a, 14-b e 15, os casos de uso representados com fundo colorido são os que já estão implementados no sistema, enquanto os que não possuem cor de fundo são os que ainda não foram implementados. As figuras 14-a e 14-b constituem o diagrama de casos de uso do Módulo Coordenação. Neste módulo percebem-se trinta e seis casos de uso, dos quais trinta e três já foram implementados. Quanto aos atores, pode-se notar que o Coordenador herda do Secretário, e este herda do Bolsista, de modo que o primeiro deve ter acesso a todos os casos de uso do módulo; o segundo, a vinte e três; e o terceiro a apenas dezesseis deles. 42

52 Figura 14-a. Primeira parte do diagrama de casos de uso do Módulo Coordenação 43

53 Figura 14-b. Segunda parte do diagrama de casos de uso do Módulo Coordenação Quanto ao Módulo Público, foram propostos apenas dois casos de uso, que devem poder ser acessíveis, por meio da utilização de um browser, para qualquer pessoa conectada a internet. Figura 15. Diagrama de casos de uso do Módulo Público 44

54 Em relação à visão lógica do sistema, o diagrama representado pela figura a seguir expõe os principais componentes relativo à implementação do sistema, e a forma como eles se relacionam. Figura 16. Organização arquitetural dos componentes do sistema Soft Educ GCI A princípio, o diagrama da figura 16 apresenta dois componentes que não foram desenvolvidos pela equipe do projeto, mas que constituem o ambiente de instalação e execução do sistema. Estes componentes são: o servidor de aplicações coorporativas Jboss Application Server, necessário para a instalação e execução do arquivo Enterprise (EAR) que empacota os módulos implementados do sistema; e o Sistema de Gerenciamento de Banco de Dados PostegreSQL na versão 8.4, necessário para executar o banco de dados da aplicação. Tal banco de dados é representado no diagrama pelo componente denominado softeduc_gci_bd. Quanto aos componentes representados dentro do container de aplicações coorporativas, eles representam os módulos do sistema da forma como são apresentados na IDE utilizada. O softeduc_gci_modelo é a unidade que encapsula as classes referentes ao modelo de domínio da aplicação, as entidades JPA. Nele está compreendida a implementação das dezesseis entidades do modelo de domínio do sistema e de seus 45

55 respectivos mapeamentos objeto-relacional. Estas classes e seus atributos persistentes estão documentados no diagrama a seguir: Figura 17. Diagrama de modelo de domínio do sistema Soft Educ GCI Ainda referindo-se à figura 16, pode-se notar que todos os demais componentes representados dentro do Jboss A. S. têm dependência em relação ao componente softeduc_gci_modelo, indicando que eles devem conhecer as classes do modelo, 46

56 pois devem ter a possibilidade realizar operações envolvendo atributos e métodos delas. O componente softeduc_gci_core representa a unidade que contém os Enterprise beans da aplicação. Como foi explicado outrora, Enterprise beans são classes que encapsulam a lógica de negócio da aplicação e se utilizam de diversos serviços oferecidos pelo container EJB. Essa unidade está dividida em dois pacotes principais: fachada e negocio. O pacote negocio comporta os treze beans de sessão responsáveis por implementar o núcleo da lógica de negócio da aplicação. Comporta também suas respectivas interfaces locais, as quais têm a função de declarar os métodos dos beans que devem estar disponíveis para serem invocados por outros componentes executados dentro do mesmo servidor de aplicações. É também nos Enterprise beans do pacote negocio que o contexto de persistência das entidades JPA do sistema é gerenciado. Nos métodos destes beans são realizados os comandos de manipulação do banco de dados através dos métodos disponibilizados pela interface EntityManager da JPA. Enquanto isso, o pacote fachada, como próprio nome sugere, implementa o padrão de projeto fachada ou facade. Ele contém dois beans de sessão, que representam duas fachadas, e suas respectivas interfaces. Essas fachadas têm a função de abstrair, para os componentes web do sistema, o conhecimento dos Enterprise beans do pacote negocio, no sentido de fazer com que os componentes web necessitem conhecer somente as fachadas para utilizarem os serviços implementados nos demais beans. Vale enfatizar que, quanto a tecnologia EJB, foram utilizados na implementação do sistema apenas beans de sessão do tipo stateless. Os componentes softeduc_gci_administrativo e softeduc_gci_publico representam os módulos web do sistema. O primeiro disponibiliza, para os usuários, as interfaces web com as funcionalidades do Módulo Coordenação, enquanto o segundo disponibiliza as do Módulo Público. Estas duas unidades estão implementadas com componentes do framework JSF, do Facelets, e do RichFaces. As estruturas dessas unidades são similares e, de forma resumida, contêm: um conjunto de páginas no formato XHTML com os componentes a serem processados na exibição delas; alguns componentes responsáveis pela conversão e validação de dados oriundos de requisições dos clientes web; um conjunto de managed beans os quais processam e respondem às requisições recebidas; e alguns arquivos XML de configuração. Os 47

57 managed beans funcionam como controladores das páginas web. Eles podem manipular instâncias das classes do modelo de domínio e também podem acessar os serviços oferecidos pelo componente softeduc_gci_core. Esses serviços são utilizados através da invocação dos métodos declarados nas interfaces FachadaAdministrativoLocal e FachadaPublicaLocal. Ao longo do processo não foi produzido nenhum documento de especificação de caso de uso nem qualquer diagrama de sequência, haja vista que a equipe avaliou que a produção destes artefatos seria muito custosa e a manutenção seria praticamente inviável, considerando-se a abertura do processo para as mudanças desejadas pelo cliente. Portanto fez-se prevalecer os princípios ágeis que priorizam colaboração com o cliente, software em funcionamento e respostas a mudanças mais que negociação de contratos e documentação abrangente. A responsabilidade de analisar cada caso de uso e de projetar sua solução era responsabilidade de cada desenvolvedor, desde que, na implementação da solução, seguisse os padrões arquiteturais e de codificação estabelecidos. Foi acordado que o planejamento das tarefas e seus resultados seriam documentados no Assembla, no espaço da descrição ou de comentários da tarefa. Dessa forma, detalhes importantes de um casos de uso deveriam ser documentados junto ao registro das tarefas relacionadas ao mesmo no Assembla. No entanto, em alguns momentos, quando se observou uma maior necessidade de organização para desenvolver um conjunto complexo de casos de uso interrelacionados, a serem implementados por vários desenvolvedores, foi produzido uma espécie de artefato sem precedentes bibliográficos conhecidos pelos membros da equipe. Trata-se de um documento exemplificado na figura 18, o qual expressa a navegação em relação a um conjunto de páginas web do sistema, e indica o modo como o conteúdo dessas páginas devem se apresentar para o usuário. 48

58 Figura 18. Exemplo de artefato que representa esquema de navegação e caracterização de interfaces do sistema 49

59 3.6. Resultados Obtidos Partindo-se dos problemas mencionados na 1ª sessão deste capítulo, aplicandose o processo de software descrito, as ferramentas e tecnologias propostas, e a estrutura arquitetural definida, a equipe está, até o momento, obtendo êxito na transformação dos requisitos do sistema em software funcional e conseguindo satisfazer o cliente. Cerca de 70% da totalidade do escopo e dos requisitos previstos para o sistema já foram implementados e o andamento do projeto está dentro do cronograma previsto no planejamento entregue ao cliente. A parcela do sistema implementada até o momento já está funcionando em ambiente de produção, sendo utilizada no processo de inscrições para sorteio, sorteio de vagas das turmas de 1º nível, e matrículas. Na sequência desta sessão serão apresentados os resultados da implementação dos dois casos de uso do Módulo Público e de oito casos de uso do Módulo Coordenação, na seguinte ordem: Inscrição para sorteio de vagas para turma de 1º nível do semestre atual (Módulo Público); Geração de comprovante de inscrição em sorteio (Módulo Público); Cadastro, edição ou desativação de professores e Listagem e visualização de dados de professores; Abertura e configuração de semestre letivo e Ativação e configuração de turmas do semestre atual; Relatório de demanda de inscrições para as vagas do sorteio, Realização de sorteio e Visualização dos resultados do sorteio; e Matrícula de Sorteado. Para apresentar esses resultados serão utilizadas as imagens das telas que compõem o fluxo básico de execução dos casos de uso mencionados. Em relação a todos os casos de uso do Módulo Coordenação, devese considerar que para acessá-los é necessário que o usuário esteja autenticado no sistema. Inscrição para sorteio de vagas para turma de 1º nível do semestre atual (Módulo Público) Qualquer internauta poderá acessar esse caso de uso, através do endereço da url do Módulo Público. Caso o acesso seja realizado fora de um período de inscrições previamente configurado, o sistema exibirá uma mensagem informando que o formulário de inscrições está indisponível; caso contrário o sistema apresentará a página exibida na figura

60 Para iniciar a inscrição, o usuário deve marcar a caixa de seleção e, em seguida, clicar no botão Iniciar Inscrição, os quais estão situados na parte inferior da página. Então o sistema deverá apresentar a página exibida na figura 20. Nesta página o usuário deve preencher os dados do formulário, selecionar a turma na qual deseja concorrer a uma vaga e clicar no botão enviar. Caso o dados informados no formulário sejam validados pelo sistema, apresentar-se-á a página exibida na figura 21, na qual o usuário poderá verificar os dados que inseriu e confirmar sua inscrição, ou então voltar para alterar algum dado. Caso o usuário confirme sua inscrição, será exibida uma página conforme a figura 22, mostrando uma mensagem indicando o sucesso na realização da inscrição do candidato e disponibilizando um link com a possibilidade de impressão de comprovante da inscrição. Figura 19. Tela inicial do sistema de inscrições para sorteio das vagas das turmas de 1º nível 51

61 Figura 20. Formulário de dados necessários para realizar inscrição para concorrer a sorteio 52

62 Figura 21. Tela de confirmação de dados da inscrição para concorrer a sorteio de vagas Figura 22. Tela indicando sucesso na realização da inscrição para concorrer a sorteio 53

63 Geração de comprovante de inscrição em sorteio (Módulo Público) Este caso de uso é um complemento do CDU descrito anteriormente, de modo que o usuário só poderá acessá-lo após completar o processo de inscrição para concorrer ao sorteio das vagas de uma turma do 1º nível, clicando no link Imprimir comprovante de inscrição, exposto na página indicada na figura 22. Fazendo isso, será aberta uma página com o comprovante de inscrição que poderá ser impresso ou salvo pelo usuário. Figura 23. Tela para impressão de comprovante de inscrição Figura 24. Comprovante de inscrição para concorrer a sorteio de vagas 54

64 Cadastro, edição ou desativação de professores e Listagem e visualização de dados de professores Após autenticar-se no Módulo Coordenação, usuários do tipo Coordenador ou Secretário poderão cadastrar um professor acessando o menu Professores e o submenu Novo Professor. Com isso, será apresentada uma página como a indicada na figura 25, na qual o usuário deverá inserir os dados solicitados no formulário e clicar no botão Cadastrar. Caso os dados inseridos no formulário sejam validados, será apresentada uma página conforme a figura 26, indicando que o cadastro foi realizado com sucesso. Para listar os professores, editar dados deles, desativá-los ou reativá-los, o usuário deve acessar o sub-menu Gerenciar Professores, do menu Professores, e será levado até a página representada na figura 27. Figura 25. Formulário de cadastro de professor 55

65 Figura 26. Tela indicando sucesso no cadastro de um professor Na tela Gerência de Professores, os usuários podem desativar um professor clicando no ícone em formato de X, ou reativá-lo clicando no ícone em formato de V. Para editar os dados de um professor, clica-se no ícone em formato de lápis, provocando a abertura de uma janela sobre a página, onde a edição poderá ser realizada. A janela de edição de dados de um professor é mostrada na figura 28. Figura 27. Tela de gerência de professores cadastrados 56

66 Figura 28. Janela de edição de dados de um professor Abertura e configuração de semestre letivo e Ativação e configuração de turmas do semestre atual Para abrir um semestre é necessário que se tenha cursos cadastrados no sistema, e para ativar e configurar turmas é necessário que os cursos associados a estas turmas tenham professores cadastrados. Essas ações só podem ser executadas por um usuário do tipo Coordenador. Para abrir um semestre o usuário deve clicar no sub-menu Abrir Semestre, da opção Semestre no menu principal. Isso levará ao usuário para uma página a exemplo da que é indicada na figura 29. Então o usuário preenche os campos do formulário e clica no botão Próximo Passo. Caso os dados inseridos no formulário sejam validados, o sistema apresentará uma página como a exemplificada na figura 30, onde o usuário deve inserir as informações quanto ao 57

67 número de turmas e o material didático para cada nível dos cursos oferecidos. Após isso o usuário deve clicar no botão Concluir para completar a abertura do semestre. Figura 29. Primeiro passo para abertura de um semestre letivo Figura 30. Segundo passo para abertura de um semestre letivo 58

68 na figura 31. Ao completar a abertura de um semestre, o sistema exibe a tela exemplificada Figura 31. Tela de ativação e configuração de turmas Figura 32. Janela de ativação e configuração de uma turma 59

69 A página Ativação de Turmas do Semestre Atual, além de ser apresentada após a conclusão da abertura de um semestre, também pode ser acessada através do sub-menu Ativar Turmas do Semestre Atual, do item do menu principal Semestre. Nela as turmas criadas pelo sistema a partir das informações declaradas na abertura do semestre podem ser ativadas e configuradas. Para tanto, deve-se clicar no ícone em formato de V, provocando a abertura de uma janela sobre a página, onde a turma poderá ser configurada e ativada. Após serem ativadas, as turmas poderão ser vistas, re-configuradas ou desativadas na página Visualização de Turmas, que é exibida nas figuras 33 e 34. Figura 33. Tela para pesquisa e listagem de turmas Figura 34. Janela para editar dados de uma turma 60

70 Relatório de demanda de inscrições para as vagas do sorteio, Realização de sorteio, Visualização dos resultados do sorteio Para visualizar relatório que aponta o número de vagas remanescentes em cada turma de 1º nível e o número de concorrentes a estas vagas, um usuário do tipo Coordenador deve acessar o sub-menu Gerenciar Sorteios, do menu Sorteio e clicar no link Clique Aqui disponível no painel inferior da página Gerência de Sorteios (figura 35). Fazendo isso, ele visualizará uma janela sobreposta a página exibindo tal relatório, conforme exemplificado na figura 36. Para realizar um novo sorteio, deve-se clicar no botão Realizar Novo Sorteio, também disposto no painel inferior da página Gerência de Sorteios. Com isso, será exibido para o usuário uma caixa de confirmação, conforme apresentado na figura 37. Caso o usuário confirme a realização de um novo sorteio, o sistema realizará o sorteio das vagas remanescentes entre os candidatos que estão concorrendo a elas e, após isto, exibirá uma mensagem indicando sucesso na realização do sorteio e uma nova linha na tabela que lista os sorteios do semestre atual, como mostrado na figura 38. Os resultados dos sorteios realizados são acessíveis através dos links disponibilizados nas colunas da tabela que lista os sorteios, tendo-se a possibilidade de visualizar os resultados de cada turma individualmente (figura 39), ou o resultado de todas as turmas no browser (figura 40) ou em um arquivo PDF. Figura 35. Tela para gerenciar sorteios 61

71 Figura 36. Janela com relatório de vagas disponíveis nas turmas e número de candidatos ao sorteio delas Figura 37. Caixa de confirmação para realização de um novo sorteio 62

72 Figura 38. Tela com mensagem indicando sucesso na realização do sorteio e exibindo lista de sorteios realizados no semestre Figura 39. Telas de visualização dos sorteados para as vagas de uma turma 63

73 Figura 40. Tela com resultado geral de um sorteio Matrícula de Sorteado Para matricular um candidato sorteado, o usuário deve acessar o sub-menu Buscar Sorteados, do item do menu principal Sorteio. Com isso, o sistema deve apresentar a página Busca de sorteados, onde o usuário deverá pesquisar o sorteado que deseja se matricular, e, ao encontrá-lo, clicar no link Matricular. Então o sistema apresentará um formulário de matrícula com os dados da inscrição do sorteado e os campos referentes às formas de pagamento. Após concluir a matrícula, o sistema exibe 64

74 uma página (figura 43) com uma mensagem indicando que a matrícula foi realizada com sucesso e um link para impressão de recibo de matrícula (figura 44). Figura 41. Tela de pesquisa de um sorteado Figura 42. Tela com formulário para matrícula de sorteados 65

75 Figura 43. Tela com mensagem indicando sucesso na matrícula de um sorteado Figura 44. Tela para impressão de recibo de matrícula em duas vias 66