Controlador De Faltas

Integrantes:

  • Alexandre Couto Albizzati
  • José Gerardo Arruda Junior
  • Leonardo Bruno Pedrosa Pontes Lima

Ano/sem: 2008/2o.
data da apresentação: 05/12/2008

Apresentação

O presente relatório tem por objetivo apresentar o projeto final da disciplina de CES-22 (Programação orientada a objetos), ministrada no Instituto Tecnológico de Aeronáutica. A proposta do projeto foi de desenvolver a habilidade orientada a objetos por meio da aplicação dos conceitos adquiridos no curso num projeto final.

A aplicação desenvolvida tem forte valor agregado para estudantes do ITA, visto que pode ser utilizada por alunos de todos os anos da graduação no auxílio à árdua tarefa de controle do limite pessoal de faltas.

A idéia do projeto surgiu da percepção de que boa parte dos alunos que fazem tal controle, o fazem por meio de anotações ou planilhas do Excel, o que se torna por vezes ineficaz por não permitir que o registro da falta seja feito no momento em que ocorre. A necessidade de um computador ligado para registro põe em risco a eficácia do controle, visto que se torna vulnerável à memória do aluno.

O projeto, intitulado “Controlador de Faltas”, foi desenvolvido para plataformas móveis, que, por serem de uso generalizado, acabam com esta dificuldade e permitem um controle mais seguro, garantindo o aumento da vida útil do aluno no referido Instituto.

Nos próximos itens, as etapas de desenvolvimento serão detalhadas e serão descritos o planejamento, a modelagem, detalhes de codificação e testes.

Estapas do desenvolvimento

Planejamento

O primeiro passo após a concepção da idéia esteve relacionada ao planejamento do projeto. Nesta etapa, foram discutidos principalmente a viabilidade de implementação no sentido de se descobrir como criar uma interface gráfica e como persistir os dados no celular.

Para a elaboração da interface gráfica foi utilizado o framework Java Wireless Toolkit 2.2, da Sun, cuja interface de uso está ilustrada na Fig.01 abaixo:

WirelessToolkit


Fig.01 - Java Wireless Toolkit - framework utilizado para a criação da interface gráfica

Para a persistência de dados, inicialmente tentou-se utilizar a classe RecordStore. A dificuldade em seu manuseio e necessidade de vasto conhecimento sobre a classe fez com que fosse buscada outra solução para persistência. A solução encontrada foi a utilização do framework Floggy Persistence, cujo funcionamento é baseado na própria classe RecordStore e pode ser resumido pelo diagrama da Fig.02.

MecanismoDePersistencia

Fig.02 - Floggy Persistence - Mecanismo de funcionamento do framework utilizado na persistência de dados

Modelagem

Uma vez definidas as ferramentas de trabalho, a próxima etapa consistiu na modelagem da aplicação, tanto a de classes como a modelagem do fluxo de telas do programa.

Nesta etapa, pôde-se perceber o quanto uma modelagem se relaciona com outra, visto que as funcionalidades da aplicação, modeladas no fluxo de telas, são implementadas nas classes. Uma mudança no fluxo de telas por vezes nos fez, por exemplo, remanejar métodos ou atributos de uma classe pra outra.

Na modelagem de classes foram criadas 3 classes principais: Aluno, Matéria e Falta. Essas três classes implementam a interface Persistable para a persistência de dados e se relacionam conforme o diagrama de classes ilustrado na Fig.03. A classe HelloMIDlet é a responsável por chamar os métodos da aplicação e interfaceá-los com o celular.

DiagramaDeClasses


Fig.03 - Diagrama de classes da aplicação

A modelagem do fluxo de telas, como foi dito, determinou a modelagem de classes. O fluxo de telas pode ser visto na classe HelloMIDlet, que faz uso do pacote Java Mobility Pack do NetBeans. Não colocaremos o “printscreen” por haver muitas telas.

Codificação

A escrita do código foi feita “em paralelo” pelos membros do grupo. À medida que a aplicação foi se desenvolvendo, novos métodos e/ou modificações se mostraram necessários. A divisão das tarefas foi feita de modo que um membro da equipe ficou responsável pelo manuseio e implementação da interface gráfica e os outros dois pelo desenvolvimento dos códigos relacionados às três classes principais. Outras tarefas como pesquisa e estudo de frameworks, implementação de padrões de projeto, por exemplo, foram atribuídas de forma genérica, de acordo com ocupação do membro dentro do projeto.

O uso do controle de versionamento foi de ótimo proveito, pois auxiliou muito no controle de versão. No início do projeto, quando não se utilizou o controle, muitas dificuldades apareceram no sentido de ter que mandar sempre a última versão, ou compartilhar na rede, etc. O projeto foi armazenado no SourceForge.net e pode ser acessado pelo link https://sourceforge.net/projects/exameces-22/.

O número de linhas de código desenvolvido por cada membro e sua participação no desenvolvimento não deve ser tido como referência pelas estatísticas do SourceForge, visto que o projeto só foi criado no site depois de já estar relativamente adiantado. Pode-se assegurar, contudo, que os três integrantes participaram de modo ativo e homogêneo, com divisão de tarefas feita conforme descrito acima.

Padrões de projeto

O projeto se baseou no que era possível de se fazer com o o Mobile Tool Kit e com o framework de persistência Floggy. Devido às limitações destes algumas idéias de implementação tornaram-se inviáveis.

Todo o desenvolvimento do código, todavia, seguiu fielmente o encapsulamento. Toda a comunicação da estrutura de classes com o framework de persistência foi feita através de uma única classe (classe Aluno) que serviu como interface de acesso para a implementação da interface com o usuário (controle de fluxo das telas, parte gráfica, etc) e da persistência. A classe Aluno encapsulava a classe Materia e esta, por sua vez, encapsulava a classe Falta.

Um padrão de projeto muito importante no projeto foi o Singleton, pois era importante que houvesse apenas uma instância de aluno, para que a persistência não criasse outro aluno toda vez que se abrisse o programa. Uma limitação na implementação do padrão Singleton foi que não pudemos tornar o construtor de aluno como private, por limitação do Floggy.

Houve a necessidade de que Aluno fosse notificada sobre o seu status em relação às suas faltas quando estivesse perto de estourar ou, já tivesse estourado o seu limite de faltas, para que fosse apresentada uma janela de notificação. Para isso usou-se a idéia do padrão Observer. Todavia, não implementamos uma interface devido à simplicidade do código. A implementação deste "observer" simplificado foi criar um método setStatus que receberia como parâmetro o numero de faltas pra estourar. Este método foi colocado dentro do metodo inserirFalta e é chamada sempre que uma falta é inserida. Quando setStatus é chamado ele pode alterar o valor de duas variáveis: uma boolean alerta (que diz se devemos alertar ou não o aluno de que ele está perto de estourar ou já estourou) e uma String, que será a mensagem da tela de alerta.

É válido ressaltar que, idéias como o encapsulamento, e instanciação única (Singleton), foram extremamente importantes.

Instalação

A instalação é através da comunicação do celular com o computador. A forma de comunicação varia a cada fabricante, mas há uma grande semelhança semântica entre as mesmas, como intuitivamente esperamos.

Motorola:

Os programas utilizados são:

  • Motorola Phone Tools: Com o Motorola Phone Tools você pode enviar somente imagens, sons e videos, com ele não é possível enviar jogos e aplicativos *.jar ou *.jad para o celular. Download do Motorola Phone Tools 5. Esta versão é compatível com todos os celulares da Motorola, inclusive os mais novos, Windows XP e Vista
  • Motorola PST: Necessário para instalar os drivers P2K. Download do Motorola PST
  • P2K, P2KTools, RSDLite: Um destes aplicativos é necessário para os drivers P2K reconhecer o seu celular. Download do P2KTools, Download do RSDLite
  • Motomidman: Para instalar os jogos e aplicativos no celular. Existem outras opções, mas eu recomendo o Motomidman pela facilidade de usar, serve para toda série P2K. Download do Motomidman.

Nokia:

Para celulares da Nokia você pode utilizar o Nokia PC Suite. Com ele é possível fazer backup do celular, armazenar imagens e videoclipes do telefone no PC, enviar mensagens de texto, usar o celular como modem para conectar o computador à internet, criar e organizar a agenda de contatos, converter faixas de música para um formato que possa ser tocado no telefone, instalar jogos e outros programas do PC para o telefone, entre outras coisas. Normalmente os celulares Nokia são acompanhados de um CD-ROM contendo o Nokia PC Suite, ele também pode ser baixado aqui. Para instalar um aplicativo no telefone, faça o seguinte:

  • Faça o download dos arquivos *.SIS, *.SISX, ou *.JAR e *.JAD do game que deseja instalar.
  • Conecte o telefone no computador.
  • No Windows Explorer, clique duas vezes no arquivo *.JAR, *.SISou *.SISX a ser instalado no telefone. E o aplicativo será instalado no seu telefone.

Sony Ericsson:

My Phone Explorer é um programa gratuito, e com ele você pode pode incluir/excluir nomes na agenda, fazer ligações, baixar suas fotos, enviar jogos e aplicativos. Indispensável para quem tem um celular Sony Ericsson.

  • Primeiro baixe o programa neste link.
  • Depois instale e reinicie o PC
  • Conecte o cabo de dados no celular e PC, execute o My Phone Explorer e clique em conect.
  • Para enviar arquivos jar do PC para o celular clique com botão direito do mouse em cima do arquivo, depois clique na opção “enviar para o telefone” automaticamente ele encaminhará para a pasta de jogos.

Testes

Após a conclusão da aplicação o projeto foi compilado e os primeiros testes foram efetuados pelo simulador do Java Mobility Pack, que pode ser visto na Fig.04. Os resultados foram satisfatórios de modo que se pôde manipular a aplicação e persistir dados conforme desejado.

Celular.jpg

Fig.04 - Simulador utilizado nos testes

Confirmado o funcionamento da aplicação no Net Beans, a aplicação foi instalada num celular Nokia modelo 6288, compatível com a tecnologia MIDP 2.0 necessária.

A aplicação funcionou perfeitamente. Os resultados do teste no celular serão mostrados na apresentação do projeto, feita pessoalmente aos professores da disciplina.

Conclusão

No presente trabalho pôde-se, pela primeira vez no curso de graduação, desenvolver uma aplicação prática e de utilidade no dia-a-dia. Terminado o trabalho, esperamos que a aplicação possa ser utilizada de modo produtivo pelos alunos do ITA e que seu uso seja válido no controle pessoal do limite de faltas.

No decorrer do trabalho foi possível lidar com situações inesperadas, mas comuns no desenvolvimento de projetos. O uso de frameworks, por exemplo, nos ajudou por um lado, mas, por outro impôs algumas limitações em uso de bibliotecas, por exemplo.

Foi possível observar, também, o quanto a organização e elegibilidade de código se tornam importantes em um projeto maior com mais de um desenvolvedor. O encapsulamento, conceito básico de OO, pôde ser evidenciado quando classes ou métodos criados por um desenvolvedor foram utilizados por outro, em outro trecho de código.

Novamente, vale ressaltar o quanto foi proveitosa a criação do projeto no Source Forge para controle de versão. Isso permitiu com que os integrantes do grupo pudessem trabalhar simultaneamente sem qualquer tipo de conflito. A importância foi evidenciada e percebida por boa parte do projeto ter sido levada fora do Source Forge.

Por fim, pode-se julgar que a aplicação desenvolvida atingiu seus objetivos. O trabalho foi concluído com sucesso, possui valor agregado, e possibilitou a aquisição de novos conhecimentos.

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License