Desenvolvimento de um Sistema de Acompanhamento Acadêmico

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIOGRANDE DO NORTE

CAMPUS NATAL CENTRALDIRETORIA ACADÊMICA DE GESTÃO E TECNOLOGIA DA INFORMAÇÃO

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DESISTEMAS

DANIEL LOBÃO DOS SANTOS FIGUEIREDO

DESENVOLVIMENTO DE UM SISTEMA DE ACOMPANHAMENTO ACADÊMICO

Natal–RN2014



Trabalho de Conclusão de Cursoapresentado ao Curso Superior deTecnologia em Análise e Desenvolvimentode Sistemas do Instituto Federal deEducação, Ciência e Tecnologia do RioGrande do Norte, em cumprimento àsexigências legais como requisito parcial àobtenção do título de Tecnólogo emAnálise e Desenvolvimento de Sistemas.

Orientador: Prof. Dr. Fellipe Araújo Aleixo.

Natal–RN2014



Trabalho de Conclusão de Cursoapresentado ao Curso Superior deTecnologia em Análise e Desenvolvimentode Sistemas do Instituto Federal deEducação, Ciência e Tecnologia do RioGrande do Norte, em cumprimento àsexigências legais como requisito parcial àobtenção do título de Tecnólogo emAnálise e Desenvolvimento de Sistemas.

Trabalho de Conclusão de Curso apresentado e aprovado em ___ /____/_______ , pela seguinte Banca Examinadora:

BANCA EXAMINADORA

________________________________________________Prof. Dr. Fellipe Araújo Aleixo – Presidente

Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte

________________________________________________Prof. Me. Leonardo Ataíde Minora – Examinador


________________________________________________Prof. Me. Alexandre Gomes de Lima – Examinador


Dedico esse trabalho a minha família, cujo

apoio e compreensão inabaláveis foram a

pedra fundamental de todas as nossas

conquistas. Aos amigos, aquelas pessoas

que se tornam família ao longo da vida. E

a Vanessa, cuja existência me ensinou

sobre o amor e suas diversas formas.

AGRADECIMENTOS

A minha mãe Vicência e minha irmã Morgana, que muito me ensinaram sobre

docência, responsabilidade social e pensamento crítico, fundamentos que me

tornaram o que sou hoje. A minha tia Francisca, cujo carinho e altruísmo sempre

estiveram presentes. A minha tia Neide pelo exemplo de responsabilidade e vida. Ao

meu primo Marcelo, cujo sorriso e brilho no olhar são suficientes para aliviar

qualquer dificuldade em que eu esteja. A meu pai Arthur e meu irmão Gabriel, que

independente da distância sempre estarão em meu coração e pensamento.

A todos professores, técnicos, pedagogos, servidores e comunidade do IFRN,

que me acolheram calorosamente desde o Ensino Médio. A todos os professores da

DIATINF pelas experiências compartilhadas, brincadeiras, conselhos e repreensões,

pois cada uma a sua medida ajudou a me preparar para os passos da graduação, e

o que vier a seguir. Em especial ao prof. Jailton, cujo exemplo de docência e

profissionalismo lembrarei sempre. A equipe da secretaria pela presteza em todos os

momentos, além de toda descontração e eficiência que caracterizam a DIATINF. A

Fátima por seu trabalho e apoio aos discentes. Aos prof. Arnóbio e Luís Antônio, e

também a Tânia, cuja confiança e apoio se tornaram grandes motivadores.

Aos amigos, antigos e novos, que apenas por existirem tornam a vida melhor.

Em especial a Dante e Matheus, cuja amizade e presença constantes têm sido um

fator importante desde que nos conhecemos tantos anos atrás. Aos demais amigos

de longa data, em especial os da Casa Escola, com quem partilhei boa parte da

infância. Aos grandes amigos descobertos durante o curso: Arthur, Marcelo, Pablo,

Sedir, Victor, Segundo e João, pois sem vocês a experiência da graduação jamais

seria a mesma. Aos demais amigos e amigas que a vida me trouxe, e que apesar de

não estarem listados ajudaram a construir essa história.

A Vanessa, que, por mais que eu repita o quanto sou grato por tudo que fez

por mim e fizemos juntos, nunca será o suficiente. Obrigado por tudo, more.

Eu acredito firmemente que a melhor hora

para qualquer homem, a maior realização

de tudo aquilo que ele ama, é o momento

quando ele deu tudo de si por uma boa

causa e deita exausto no campo de

batalha – vitorioso.

Vince Lombardi

RESUMO

Na sociedade atual a tecnologia se torna cada vez mais presente em

diferentes áreas do conhecimento. Sendo assim, ela também ocorre em vários e

diversos contextos educacionais. A partir das oportunidades, e desafios inerentes a

expansão da tecnologia, surge a necessidade de ferramentas adequadas, que

auxiliem os estudantes em seu planejamento e acompanhamento de desempenho

acadêmico, fornecendo-lhes autonomia. Este trabalho apresenta uma situação-

problema específica, encontrada no contexto educacional de um curso superior de

tecnologia, que motivou o desenvolvimento do Sistema de Acompanhamento

Acadêmico (SAA). A partir dessa situação-problema, são relatados os passos

necessários para a sua solução enquanto sistema a ser disponibilizado como

software livre para uso gratuito e universal. Para tanto, são abordados conceitos

teóricos e práticos, como a determinação do SAA enquanto sistema corporativo,

desenvolvimento de sistemas corporativos em Java, além das etapas mais comuns

de desenvolvimentos de sistemas que envolvem: levantamento de requisitos,

representação do sistema por meio de diagramas e implementação dos códigos.

Palavras-chave: Sistema acadêmico. Sistemas corporativos. Software livre.

ABSTRACT

In today's society, technology becomes increasingly present in different areas

of knowledge. Thus, it also occurs in various and diverse educational contexts.

Based on the opportunities and challenges inherent in the expansion of technology

comes the need for appropriate tools to assist students in planning and monitoring of

academic performance by providing them autonomy. This work presents a specific

problem situation, found in the educational context of a superior technology course,

which has motivated the development of Academic Support System (SAA). From the

problem situation are reported the steps between the discovery of the problem and

its solution as a system to be available as free software, to free and universal use.

Both theoretical and practical concepts are discussed, such as determining the SAA

as enterprise system, development of Java enterprise systems, plus the most

common stages of systems development, involving: requirements gathering, system

representation through diagrams and code implementation.

Keywords: Academic systems. Enterprise systems. Free software.

LISTA DE ILUSTRAÇÕES

Figura 1 – Diagrama de casos de uso do sistema 25

Figura 2 – Diagrama de classes do domínio 26

Figura 3 – Diagrama de classe dos atores cadastrados (tipos de usuários) 27

Figura 4 – Diagrama de arquitetura: visão externa 28

Figura 5 – Diagrama de arquitetura: visão interna 28

LISTA DE QUADROS

Quadro 1 – Comparação dos servidores de aplicação 17

Quadro 2 – Requisitos funcionais para ator Público 20

Quadro 3 – Requisitos funcionais para ator Usuário 21

Quadro 4 – Requisitos funcionais para ator Aluno 21

Quadro 5 – Requisitos funcionais para ator Moderador 22

Quadro 6 – Requisitos funcionais para ator Coordenador 23

Quadro 7 – Requisitos funcionais para ator Administrador 23

Quadro 8 – Requisitos não funcionais 24

SUMÁRIO

1 INTRODUÇÃO 11

1.1 OBJETIVO GERAL 12

1.2 OBJETIVOS ESPECÍFICOS 12

1.3 METODOLOGIA 13

1.4 ESTRUTURA DO TRABALHO 13

2 FUNDAMENTAÇÃO TEÓRICA 14

2.1 SISTEMAS CORPORATIVOS 14

2.2 JAVA PLATFORM, ENTERPRISE EDITION (Java EE) 14

2.2.1 Principais tecnologias Java EE 15

2.2.2 Servidores de aplicação 16

2.3 APACHE TOMEE 17

2.3.1 Implementações das especificações Java EE 18

2.3.2 Modularidade 19

3 ETAPAS DO DESENVOLVIMENTO DO PROJETO 20

3.1 LEVANTAMENTO DE REQUISITOS 20

3.1.1 Requisitos funcionais 20

3.1.2 Requisitos não funcionais 23

3.2 DIAGRAMAS DE CASOS DE USO 24

3.3 DIAGRAMAS DE CLASSE 25

3.4 ARQUITETURA DO SISTEMA 27

4 RESULTADOS 29

5 CONCLUSÃO 30

5.1 LIÇÕES APRENDIDAS 30

5.2 TRABALHOS FUTUROS 31

REFERÊNCIAS 32

11

1 INTRODUÇÃO

O acompanhamento de notas e presenças durante um curso nunca foi tarefa

simples. Deveria ser, pois com o avanço tecnológico e a existência de sistemas cujo

único propósito é gerenciar esse tipo de informação, isso deveria ser possível, e

fácil. Mas no Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do

Norte (IFRN), e especificamente no curso superior de Tecnologia em Análise e

Desenvolvimento de Sistemas (TADS), não ocorre dessa forma. Por muitos anos no

final do período letivo os alunos se reúnem para trocar informações sobre as regras

de aprovação e reprovação acadêmica institucional, e reclamar da dificuldade em

calcular tais informações.

A partir da recorrência dessa situação, no dia 11 de maio de 2010 foi fundado

o Centro Acadêmico de Tecnologia em Análise e Desenvolvimento de Sistemas

(CAADS), para servir de meio interlocutor entre as necessidades discentes do curso

de TADS e a estrutura institucional do IFRN. Desde essa data foram registradas pelo

CAADS, a partir de relatos em reuniões de colegiado, envio de e-mails ou por meio

de redes sociais, inúmeras ocorrências de problemas com o sistema acadêmico do

instituto. Problemas esses que relatam mal funcionamento e indisponibilidade do

sistema, até a quantidade excessiva (e confusa) de funcionalidades não utilizadas,

subutilizadas e mal utilizadas.

Entretanto o que foi percebido após reflexão das demandas dos alunos, e

outras ocorrências, foi que as questões mais recorrentes não envolviam problemas

com as funcionalidades disponíveis no sistema, mas sim a ausência de

determinadas funcionalidades. Se mostravam ausentes funcionalidades que

respondessem às perguntas, dúvidas e necessidades mais frequentes: “Quantas

presenças eu preciso ter para não ser reprovado na disciplina ou semestre?”, “Que

nota eu preciso tirar nessa prova pra passar na média?”, “Como que eu faço o

cálculo das notas?”. Tais questões foram registradas em diversas épocas, tendo sido

a partir de alunos diversos. Mas sempre foram os alunos dos primeiros períodos os

com dificuldades mais frequentes, como relatado pelo CAADS.

O que se percebeu foi que os alunos mais experientes, a partir de

determinado período do curso, por experiência já haviam aprendido o suficiente para

12

fazer os cálculos sozinhos. Já os recém-chegados não sabiam lidar com a relação

de presenças e notas mínimas necessárias para cumprir com as disciplinas, ou com

os diferentes pesos dos bimestres. Por vezes até mesmo entre alunos experientes

surgiam dúvidas, em geral são mais complexas, por exemplo: “Eu tirei nota '‘x’' em

uma avaliação de peso '‘a’' na média, e ainda tenho mais duas avaliações pela

frente, uma com peso '‘b’' e outra com peso '‘c’'. Quanto eu preciso tirar, no mínimo,

em cada das avaliações seguintes para conseguir atingir a nota '‘z’' esse bimestre?”

Com essa situação-problema em mente o CAADS buscou uma solução na

forma de sistema, para que não fosse necessário aos alunos uma curva de

aprendizagem sobre os critérios de aprovação institucional para se planejar e

acompanhar desempenhos. Essa solução se tornou o projeto de Sistema de

Acompanhamento Acadêmico (SAA) aqui relatado.

1.1 OBJETIVO GERAL

a) Este trabalho tem como objetivo geral relatar as etapas do desenvolvimento

(concepção, análise e implementação) do SAA, abordando em especial as

decisões tecnológicas, demonstrando os resultados obtidos.

1.2 OBJETIVOS ESPECÍFICOS

a) Descrever o problema;

b) Apresentar tecnologias e conceitos necessários para o desenvolvimento de

sistemas corporativos em Java;

c) Relatar as etapas necessárias para a elaboração do SAA;

d) Apresentar os resultados do projeto;

e) Fazer sugestões e recomendações quanto as tecnologias envolvidas e definir

pontos relevantes para trabalhos futuros.

13

1.3 METODOLOGIA

A metodologia consistiu em analisar casos já registados pelo CAADS,

conversar com alunos para revisar as necessidades, pesquisar tecnologias

suficientes para a solução do problema, registrar as etapas do processo de

desenvolvimento de software e os artefatos produzidos, registrar os problemas

encontrados, e então estruturar todas as informações de maneira lógica para facilitar

a compreensão deste trabalho.

1.4 ESTRUTURA DO TRABALHO

Esse trabalho está estruturado em cinco capítulos, de forma a apresentar

todas as decisões tomadas durante a fase de concepção, projeto e implementação

inicial do SAA, explicando desde as escolhas de tecnologia às prioridades do

sistema.

No primeiro capítulo, é feita a introdução ao tema deste projeto, sua

motivação e seus objetivos.

No segundo capítulo, são descritos os principais conceitos e tecnologias

relacionadas ao desenvolvimento do sistema, desde sua determinação enquanto

sistema corporativo à escolha das tecnologias e ferramentas que tornaram possível

sua confecção.

No terceiro capítulo, são descritas as etapas específicas do desenvolvimento

do SAA, desde o levantamento de requisitos, definição de casos de uso, concepção

e representação dos dados (classes de entidades) necessários à implementação do

sistema e definição arquitetural do sistema

No quarto capítulo, são apresentados os resultados obtidos ao final das

etapas de desenvolvimento do SAA.

No quinto capítulo, conclui-se o trabalho com as lições aprendidas e trabalhos

futuros.

14

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo, são apresentados os aspectos teóricos e escolhas

tecnológicas deste trabalho, tais como: Sistemas Corporativos, “Java Platform,

Enterprise Edition” (Java EE) e Apache TomEE.

2.1 SISTEMAS CORPORATIVOS

Para a classificação de sistemas, existem muitas terminologias diferentes,

cada uma tentando representar uma determinada categoria. Algumas das

denominações e categorias mais usuais são: sistemas web, sistemas legados

(antigos, obsoletos), sistemas embarcados, sistemas de tempo real e sistemas

corporativos.

Considerando o problema a ser solucionado pelo SAA, pode-se classificá-lo

enquanto sistema corporativo, pois: “As aplicações corporativas muitas vezes têm

dados complexos – e uma quantidade grande deles – para trabalhar, aliados a

regras de negócio que não passam em nenhum teste de raciocínio lógico”

(FOWLER, 2006, p.24). O SAA tem como objetivo primário lidar com o contexto

educacional, oferecendo formas para atender às demandas dos alunos. Tal contexto

é muito grande, e diverso, abrangendo diferentes níveis de ensino, públicos e idade

de usuários, o que inclui complexas regras de negócio.

Além disso, também existe uma obrigatoriedade quanto à disponibilidade e

confiabilidade dos dados ao longo de muitos semestres e anos, o que reforça a

classificação do SAA como sistema corporativo, pois “As aplicações corporativas

normalmente envolvem dados persistentes. Os dados são persistentes porque

precisam estar disponíveis entre múltiplas execuções do programa – de fato, eles

normalmente precisam persistir por vários anos.” (FOWLER, 2006, p. 25).

2.2 JAVA PLATFORM, ENTERPRISE EDITION (Java EE)

Conhecido anteriormente por “Java 2 Platform, Enterprise Edition” (J2EE), se

trata de um conjunto de especificações, sendo criado como uma opção para

15

desenvolvimento de sistemas corporativos em Java. Teve sua primeira versão,

número 1.2 (mesma versão do Java na época), anunciada em 12 de dezembro de

1999.

A plataforma só veio a se chamar Java EE a partir da versão 5 (11 de maio de

2006), abandonando o prefixo “1.x”.

Apesar de possuir bibliotecas que oferecem diversas funcionalidades, Java

EE é apenas, em essência, o conjunto de especificações de tecnologias para

desenvolvimento de sistemas corporativos em Java. Essas especificações

determinam o conjunto de Application Programming Interface (API), ou seja, de

interfaces que devem ser oferecidas. Cada conjunto de necessidades gera sua

própria especificação, que recebe um nome e posteriormente uma solução real, ou

seja, implementação de código. A especificação que melhor caracteriza a plataforma

Java EE é a dos Enterprise Java Beans (EJBs), que é uma arquitetura de

componentes para construção modular de sistemas corporativos.

Dentro das tecnologias para desenvolvimento de sistemas corporativos, Java

é amplamente utilizada, tanto para ensino dos conceitos durante cursos de

graduação como TADS, quanto para aplicações comerciais de larga escala. Por

exemplo, o Internet banking da Caixa Econômica Federal é feita em Java EE (CAIXA

ECONÔMICA FEDERAL, [200-?]). Além dos já citados EJBs, com o conjunto de

especificações Java EE, também são fornecidas APIs para mapeamento objeto

relacional, criação de Web Services, organização de arquiteturas multicamada,

chamadas remotas, dentre outras necessidades recorrentes para o desenvolvimento

de sistemas corporativos.

2.2.1 Principais tecnologias Java EE

Abaixo se encontram descritas as principais especificações Java EE, e que

também foram utilizadas no SAA.

a) Java Database Connectivity (JDBC), conjunto de APIs utilizadas no acesso a

bancos de dados;

16

b) Java Transaction API (JTA), conjunto de APIs utilizadas para interagir com as

transações ocorridas nos EJBs e na camada de persistência de dados.

c) Enterprise Java Beans (EJBs), conjunto de APIs utilizadas para oferecer um

contêiner de objetos que ofereça transação, chamadas remotas, injeção de

dependência, controle de acesso e outras funcionalidades. Os EJBs são a

parte principal da especificação Java EE, e utilizam várias outras

especificações como níveis mais baixos de abstração para oferecer suas

funcionalidades.

d) Java Persistence API (JPA), conjunto de APIs que padronizam a persistência

dos dados de forma transparente através de mapeamento objeto relacional.

e) Context and Dependency Injection (CDI), conjunto de APIs que controlam a

injeção de dependência e contextos. São muito importantes para aumentar o

desacoplamento e melhorar a abstração, entregando o gerenciamento de

componentes para o servidor.

f) Anotações, tendo sido adicionadas apenas no Java EE 5 (11 de maio de

2006), anotações já existiam em frameworks Java, e foram absorvidos para

unificar e melhorar a forma de se declarar componentes.

2.2.2 Servidores de aplicação

No ecossistema Java EE, servidores de aplicação são o conjunto de

ferramentas que oferecem as funcionalidades previstas nas especificações, dentro

de um contexto de execução. A partir do Java EE 6 foi introduzido o conceito de

perfis, que representa um conjunto de configurações da plataforma que são

adequadas para uma determinada classe de aplicações. Essa também foi uma

forma de permitir aos desenvolvedores de servidores de aplicação abandonarem

tecnologias ultrapassadas, utilizadas apenas por sistemas legados.

O perfil Java EE 6 Web Profile é o suficiente para muitas aplicações

corporativas baseadas na web, também sendo válido para o SAA. O Java EE Web

Profile representa aproximadamente metade do conjunto completo da especificação

Java EE 6.

17

Para a escolha do servidor de aplicação a ser utilizado no projeto, foram

avaliados alguns dos servidores livres mais conhecidos. Primeiramente foram

considerados os servidores Glassfish Server Open Source Edition e Wildfly (antigo

JBoss AS), que foram utilizados durante a graduação em diferentes semestres na

disciplina de Programação de Sistemas Corporativos. Entretanto ambos os

servidores ofereciam recursos muito além das necessidades do projeto, e também

por conta disso sendo mais custosos em espaço e performance, além de apenas o

Glassfish oferecer uma versão Web Profile.

Outros servidores foram analisados, sendo eles o Apache Geronimo e o

Apache TomEE (os dois são da Apache Foundation), ambos referências enquanto

servidores de aplicações corporativas em Java. Para os requisitos do SAA, o

Apache TomEE se mostrou uma melhor opção, tanto por seu tamanho mínimo

quanto pela sua modularidade. A comparação feita entre os servidores pode ser

vista abaixo (Quadro 1):

Quadro 1 – Comparação dos servidores de aplicação.

ServidorCumpre osrequisitos

Tamanho descompactado (Web Profile ou Full Profile)

Wildfly 8.1.0 Sim 138 MB (Full Profile)

Geronimo 3.0.1 Sim 103 MB (Web Profile)

Glassfish 4.0 Sim 76 MB (Web Profile)

TomEE 1.6.0.2 Sim 37 MB (Web Profile)

Fonte: Figueiredo (2014).

2.3 APACHE TOMEE

O Apache TomEE, chamado de “Tommy” pelos seus desenvolvedores e

comunidade Java, ganhou espaço a partir de 2011, quando, no mês de outubro,

obteve a certificação de compatibilidade para a especificação Java EE 6 Web Profile.

Apesar de apenas em 2011 obter a certificação, o conjunto de bibliotecas que

compõem o Apache TomEE já eram antigas, estáveis e populares individualmente. O

que o Apache TomEE fez de diferente foi unir as implementações de cada recurso

18

previsto na especificação Java EE Web Profile, garantindo a interoperabilidade de

forma transparente.

No centro do Apache TomEE, encontra-se o Apache Tomcat, um projeto feito

para servir a aplicações web, sem necessidades de sistemas corporativos. Sem

perder nada do que o Apache Tomcat naturalmente já oferece, são adicionados os

demais componentes, oferecendo as funcionalidades previstas na especificação

Java EE, e essa integração é garantida formalmente por meio da certificação de

compatibilidade do Apache TomEE.

2.3.1 Implementações das especificações Java EE

O Apache TomEE utiliza o seguinte conjunto de bibliotecas para satisfazer as

especificações Java EE:

a) Apache OpenWebBeans, conjunto de bibliotecas responsável pela

injeção de dependência (CDI);

b) Apache OpenEJB, conjunto de bibliotecas responsável pelos

containêrs de execução da camada de negócio (EJB);

c) Apache OpenJPA, conjunto de bibliotecas responsável pelo

mapeamento objeto relacional (JPA) ;

d) Apache MyFaces, conjunto de bibliotecas responsável pelos

componentes de interface web e ajax (JSF);

e) Apache Geronimo Transaction, conjunto de bibliotecas responsável

pelo gerenciamento de transações (JTA).

19

2.3.2 Modularidade

Atualmente existem três versões do Apache TomEE, a versão Web Profile, a

versão Web Profile + Java API for RESTful Web Services (JAX-RS), e a versão

Apache TomEE+, que além do JAX-RS também adiciona Java API for XML Web

Services (JAX-WS), Java Message Service (JMS) e Conector Java EE. Como não foi

necessário utilizar uma versão mais completa, optou-se pela versão Web Profile

mais recente (1.6.0.2), lançada em maio de 2014, cujo tamanho descompactado é

de apenas 37 MB.

20

3 ETAPAS DO DESENVOLVIMENTO DO PROJETO

O SAA foi iniciado enquanto projeto integrador do quinto período da

graduação, abrangendo as etapas iniciais de levantamento de requisitos e primeiras

concepções dos diagramas. Entretanto para fins desse trabalho os requisitos foram

revisados, assim como todos os diagramas e código existente, sendo adicionados

diagramas de arquitetura, sequência e implementação dos códigos necessários ao

funcionamento do sistema Abaixo são descritas as diferentes etapas do projeto,

divididas em levantamento de requisitos, diagramas de caso de uso, diagramas de

classe e diagrama de arquitetura, apresentando uma visão externa e a visão interna

do funcionamento do sistema.

3.1 LEVANTAMENTO DE REQUISITOS

Os requisitos do sistema foram enumerados a partir de reuniões com alunos

do curso de TADS, incluindo membros do CAADS.

3.1.1 Requisitos funcionais

Os requisitos funcionais representam as principais funcionalidades que o

sistema deve realizar. Eles são listados com relação aos atores identificados para o

sistema, dessa forma serão apresentados os atores, seguidos de suas listas de

requisitos funcionais (Quadros 2, 3, 4, 5, 6, 7).

O primeiro ator identificado foi o que representa os indivíduos que ainda não

possuem cadastro no sistema. Para esse ator, foi dado o nome “Público”.

Quadro 2 – Requisitos funcionais para ator Público.

Código Nome Descrição Categoria

F01 Efetuar cadastroUsuários não cadastrados poderãorealizar seu cadastro e ter acesso aosistema

Obrigatória


21

O segundo ator identificado foi o que representa o conjunto de indivíduos que

possuem cadastro no sistema. Para esse ator, foi dado o nome “Usuário”, e os

demais atores, que possuem cadastro no sistema, são derivados a partir de Usuário.

Quadro 3 – Requisitos funcionais para ator Usuário.


F02 Efetuar login

Usuários devem ser capazes de seautenticar no sistema utilizando acombinação de login e senha, queforam fornecidos durante o cadastro

Obrigatória

F03Solicitar nova

senha

Usuários cadastrados que não lembremsua senha poderão solicitar o envio deuma nova senha para o e-mailcadastrado

Obrigatória


O terceiro ator identificado foi o que representa os alunos, para esse ator foi

dado o nome “Aluno”. Alunos são usuários que possuem uma relação com um

determinado curso, podendo registrar o cumprimento de disciplinas dentro do

mesmo, incluindo suas metas acadêmicas e desempenhos obtidos em avaliações,

além do registro de presenças. Um usuário pode ter vários cadastros enquanto

aluno.

Quadro 4 – Requisitos funcionais para ator Aluno.


F04Gerenciar

associação acurso

Um usuário cadastrado deve poder seassociar a um dos cursos disponíveisno sistema, e ao fazê-lo cria um perfilde aluno associado aquele curso. Nãohá um limite para associações

Obrigatória

F05Gerenciar

situação deperíodos

Um aluno de um curso precisa sercapaz de especificar quais disciplinasele está cursando, ou já cursou, emdeterminado período do curso

Obrigatória

22


F06Gerenciar metas

acadêmicas

Um aluno pode definir suas metasacadêmicas em seu perfil de aluno,como também pode especificar metaspor semestre ou por período. O valormínimo permitido é o valor especificadono curso

Obrigatória

F07Acompanhar

metas

Um aluno deve ser capaz de facilmenteacompanhar o cumprimento de suasmetas

Obrigatória

F08Visualizar

sugestões dedisciplinas

Um aluno deve poder recebersugestões sobre quais disciplinascursar, baseado nas disciplinas jácursadas em seus perfis

Desejável

F09Visualizar

situação geralno curso

Um aluno deve ser capaz de visualizarsua situação de forma geral no curso,tendo previsão de quais e quantasdisciplinas faltam cursar, além daprevisão de conclusão

Desejável

F10 Importar dados

Um aluno deve ser capaz de importardados acadêmicos a partir de outrasfontes, desde outros sistemas aarquivos serializados

Desejável


O quarto ator identificado foi o que representa os “líderes de turma”, para

esse ator foi dado o nome “Moderador”. Moderadores são Alunos com permissões

especiais, tais quais registrar avaliações em uma disciplina, com informações como

data e peso.

Quadro 5 – Requisitos funcionais para ator Moderador.


F11Gerenciaravaliações

Ao ser concedida permissão demoderador, um aluno poderá adicionaravaliações dentro das unidades dasdisciplinas que estiver cursando ouhouver cursado

Desejável


23

O quinto ator identificado foi o que representa um “membro de centro

acadêmico”, ou outro indivíduo com alto grau de confiabilidade e conhecimento da

matriz de um curso, para esse ator foi dado o nome “Coordenador”. Coordenadores

são usuários que possuem permissões especiais com relação aos cursos, podendo

alterar sua matriz curricular e ofertar disciplinas.

Quadro 6 – Requisitos funcionais para ator Coordenador.


F12Gerenciar matriz

de curso

Um Coordenador deve ser capaz deadicionar, alterar e remover disciplinasrelacionadas ao curso que coordena

Desejável

F13Gerenciar oferta

de disciplinas

Usuários cadastrados que não lembremsuas senhas poderão solicitar o enviode uma nova senha para o e-mailcadastrado

Desejável


O sexto e último ator identificado foi o que representa o “responsável pelo

sistema”, que deve ser alguém com conhecimento de vários cursos, sendo capaz de

designar Coordenadores e Moderadores para o bom funcionamento do sistema.

Administradores são usuários que possuem as permissões mais importantes dentro

do SAA.

Quadro 7 – Requisitos funcionais para ator Administrador.


F14Gerenciarusuários

Administradores devem ser capazes dealterar a permissão de qualquer usuário

Desejável


3.1.2 Requisitos não funcionais

Os requisitos não funcionais (Quadro 8) estão relacionados às restrições do

sistema quanto a sua disponibilidade, desempenho e segurança.

24

Quadro 8 – Requisitos não funcionais.


NF01 AutenticaçãoSomente usuários habilitados acessamo sistema

Obrigatória

NF02Controle depermissão

Aos usuários habilitados, serãodisponibilizadas apenas funcionalidadescompatíveis ao seu perfil

Obrigatória

NF03 Login únicoO sistema não pode permitir que existamais de um usuário com o mesmo login

Obrigatória


3.2 DIAGRAMAS DE CASOS DE USO

Os diagramas de caso de uso foram gerados baseando-se nos requisitos

funcionais já enumerados, e estão representados nas Figuras 1 e 2. A Figura 1

apresenta o conjunto de casos de uso de todo o sistema a partir de uma visão geral,

enquanto a Figura 2 apresenta o diagrama de casos de uso do ator Aluno, que

compõe as funcionalidades mais importantes e atividade-fim deste projeto.

25

Figura 1 – Diagrama de casos de uso do sistema.


3.3 DIAGRAMAS DE CLASSE

Durante o processo de análise foram identificadas inúmeras entidades

necessárias para a persistência dos dados, e uma complexa relação entre elas. Para

compreender o SAA, é preciso compreender os dados nos quais suas

funcionalidades se baseiam, e, para demonstrar isso, abaixo está representado o

conjunto de entidades do projeto por meio do diagrama de classes (Figura 8).

26

Figura 2 – Diagrama de classes do domínio.


Podemos observar o conjunto de atores representados nos dados ao

analisarmos o respectivo diagrama de classe (Figura 3).

27

Figura 3 – Diagrama de classe dos atores cadastrados

(tipos de usuários).

Fonte: Figueiredo (2014)

3.4 ARQUITETURA DO SISTEMA

Como pode ser visto abaixo (Figuras 4 e 5), além de um padrão arquitetural

multicamada, também foi utilizado o padrão Fachada na camada de negócio. Tal

decisão é importante para fornecer um determinado conjunto de APIs, podendo

estender as funcionalidades para Web Services, sem expor o funcionamento e

divisão interna do projeto. De acordo com Gamma (2000), a intenção de uma

fachada é fornecer uma interface unificada para um conjunto de interfaces em um

subsistema.

As implementações Java EE (e algumas especificações) disponíveis pelo

Apache TomEE também fazem uso de diversos padrões de projeto, mas sua

listagem foge ao escopo deste trabalho.

28

Figura 4 – Diagrama de arquitetura: visão externa.


Figura 5 – Diagrama de arquitetura: visão interna.


29

4 RESULTADOS

O sistema encontra-se disponível em um repositório do Google Code

(SISTEMA DE ACOMPANHAMENTO ACADÊMICO, 2014), podendo ser obtido a

partir dele, e configuradas as variáveis de ambiente seguindo a descrição da

documentação do projeto (também disponível no repositório) ele pode ser

implantado e utilizado. A versão atualmente disponível oferece as funcionalidades de

registro, autenticação e solicitação de senha, além da funcionalidade de registro e

acompanhamento de metas acadêmicas a partir dos cursos e disciplinas registradas.

30

5 CONCLUSÃO

O objetivo original deste trabalho foi apenas parcialmente atingido, pois

apesar de ter relatado todo o processo de desenvolvimento do SAA, nem todas as

funcionalidades previstas para o mesmo já se encontram disponíveis, apesar dos

artefatos de análise e códigos-fonte necessários à validação da arquitetura escolhida

já estarem disponíveis e funcionais.

5.1 LIÇÕES APRENDIDAS

Com o projeto algumas lições importantes foram aprendidas. As principais

delas são:

a) Existe um enorme ecossistema de diferentes tecnologias para

solucionar cada necessidade de domínio e, dentro de cada tecnologia,

diferentes implementações. Escolher qual utilizar pode ser quase tão

difícil quanto aprender a usá-las, e existe uma relação direta entre

ambas, pois, se uma solução é muito difícil de ser aprendida, então

provavelmente ela não é a solução adequada ao projeto.

b) Ao escolher uma ferramenta livre, deve-se levar em consideração a

longevidade, estabilidade e confiabilidade do projeto, além de

conformação a especificações, quando existentes. Muitas tecnologias

surgem de forma promissora para logo serem descartadas.

c) Sempre que possível, limitar as dependências funcionais do projeto ao

que as especificações da tecnologia definem. Isso garante a

interoperabilidade entre diferentes servidores de aplicação, e diminui o

tempo necessário para se aprender ou desenvolver uma forma de

substituir alguma funcionalidade específica de alguma ferramenta.

d) Tomar especial cuidado com o escopo ao se definir um projeto, para

que novas ideias se atenham ao objetivo do que se pretende fazer,

além de avaliar devidamente sua viabilidade. Pois se for de outra forma

as ideias podem fazer o escopo de um projeto fugir ao controle, e

quando isso ocorre é difícil de definir o que fazer e por onde começar.

31

5.2 TRABALHOS FUTUROS

O SAA traz consigo um conceito fundamental: oferecer aos alunos uma

solução livre, simples e gratuita para melhorar a experiência acadêmica por meio do

controle de metas. E considerando o conceito, é necessário tornar o projeto

extensível de forma a atingir seu objetivo.

Inicialmente, propõe-se expor as funcionalidades do sistema enquanto Web

Services, a partir das fachadas oferecidas para as aplicações clientes. Para tanto,

faz-se necessário apenas o uso correto das devidas anotações, e utilizar a versão

do Apache TomEE que ofereça as funcionalidades desejadas. Esta é uma medida

importante, pois permitirá uma integração mais fácil com outras ferramentas, além

de manter e garantir o SAA como camada de negócio e dados, excluindo a

necessidade de uma camada de apresentação própria. Pois o que o define enquanto

sistema corporativo, são justamente as camadas do lado servidor, podendo deixar a

interface de usuário (desktop, web, mobile…) a ser desenvolvida em qualquer

tecnologia que exista ou se considere interessante.

Um claro exemplo da afirmação acima é que, no IFRN, apesar de Java ter

sido e continuar sendo uma das tecnologias mais ensinadas no curso de TADS, ela

não é utilizada nos sistemas da instituição, sendo Python a escolha mais comum. A

exposição das funcionalidades do SAA enquanto Web Service permitirá uma

integração fácil entre elas, visto que ambas as linguagens possuem ferramentas

para consumo e oferta de Web Services REST.

32

REFERÊNCIAS

FOWLER, Martin. Padrões de arquitetura de aplicações corporativas. PortoAlegre: Bookman, 2006.

PANDA, Debu; RAHMAN, Reza; LANE, Derek. EJB 3 em ação. 2. ed. rev. Rio deJaneiro: Alta Books, 2009.

GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado aobjetos. Porto Alegre: Bookman, 2000.

LARMAN, Craig. Utilizando UML e padrões. Porto Alegre: Bookman, 2004.

FOWLER, Martin. UML essencial: um breve guia para a linguagem-padrão demodelagem de objetos. 3. ed. Porto Alegre: Bookman, 2005.

ROMAN, Ed; AMBLER, Scott W.; JEWELL, Tyler. Dominando enterprisejavabeans. 2. ed. São Paulo: Bookman, 2004.

JAVA PLATFORM, ENTERPRISE EDITION. Oracle. [200-?]. Disponível em:<http://www.oracle.com/technetwork/java/javaee/documentation/index.html>. Acessoem: 1 jun. 2014.

TUTORIAL JAVA EE 6. Oracle. [200-]. Disponível em: <http://docs.oracle.com/JavaEE/6/tutorial/doc/>. Acesso em: 1 jun. 2014.

SISTEMA DE ACOMPANHAMENTO ACADÊMICO. 2014. Disponível em:<https://code.google.com/p/tcc-lobao/>. Acesso em: 1 jun. 2014.

APACHE TOMEE. Apache Foundation. [201-]. Disponível em:<http://tomee.apache.org/index.html>. Acesso em: 1 jun. 2014.

WILDFLY. Red Hat. Disponível em: <http://www.wildfly.org/>. 2014. Acesso em: 1jun. 2014.

APACHE GERONIMO. Apache Foundation. [201-?]. Disponível em:<http://geronimo.apache.org/>. Acesso em: 1 jun. 2014.

GLASSFISH SERVER OPEN SOURCE EDITION. Oracle. [201-?]. Disponível em:<https://glassfish.java.net/>. Acesso em: 1 jun. 2014.

CAIXA ECONÔMICA FEDERAL – Suportando milhões de transações por dia com obanco de dados PostgreSQL. 4Linux. [200-?]. Disponível em:<http://www.4linux.com.br/clientes/cases/projetos/caixa-economica-federal-suportando-milhoes-de-transacoes-por-dia-com-banco-de-dados-postgresql>.Acesso em: 1 jun. 2014.

http://www.oracle.com/technetwork/java/javaee/documentation/index.html

http://www.4linux.com.br/clientes/cases/projetos/caixa-economica-federal-suportando-milhoes-de-transacoes-por-dia-com-banco-de-dados-postgresql

http://www.4linux.com.br/clientes/cases/projetos/caixa-economica-federal-suportando-milhoes-de-transacoes-por-dia-com-banco-de-dados-postgresql

http://geronimo.apache.org/

http://www.wildfly.org/

http://tomee.apache.org/index.html

https://code.google.com/p/tcc-lobao/

http://docs.oracle.com/javaee/6/tutorial/doc/

http://docs.oracle.com/javaee/6/tutorial/doc/

Education

Desenvolvimento de um Sistema de Acompanhamento Acadêmico