MAC 449 - Trabalho de Formatura Supervisionado

As atividades abaixo estão ordenadas cronologicamente e foram realizadas entre abril/2002 e dez/2003:

Treinamento:
No início do estágio não havia uma estratégia de treinamento bem definida, mas tive muitas palestras sobre o funcionamento do sistema, os frameworks externos e desenvolvidos internamente e também sobre a tecnologia J2EE. Essa fase foi importante para integração com a equipe e familiarização com as tecnologias envolvidas no projeto.

Entidades do sistema:
Logo após o treinamento, participei do desenvolvimento de algumas entidades do sistema utilizando a tecnologia EJB em conjunto com os frameworks desenvolvidos pela empresa. As entidades EJB representam a camada de persistência do sistema, e nessa camada utilizamos alguns padrões normalmente utilizados em aplicações J2ee, como por exemplo, os padrões Data Transfer Object, Proxy Factory e alguns desenvolvidos pela Touch entre eles os frameworks de ativamento e versionamento de entidades.

Há muitas entidades no sistema que não devem poder ser alteradas, e sim versionadas. Por exemplo, um laudo já registrado não pode ser posteriormente alterado sem que seja registrado um histórico das alterações, para resolver esse problema foi desenvolvido um método para versionamento de entidades onde é guardada a versão de cada alteração da entidade. Isso é realmente um exemplo muito simplificado dos problemas que tentamos resolver no sistema, e após algum tempo esse mecanismo foi generalizado para poder ser utilizado em qualquer entidade do sistema que precise de versionamento.

Telas de cadastramento de entidades do sistema:
A próxima fase foi criar as telas de cadastro e utilização das entidades. Nessa fase desenvolvi as sessions EJB relacionadas às regras de negócio em questão e suas respectivas telas. No início eram telas de cadastro, mas logo depois comecei a criar as telas relacionadas à entrada de amostras no NTO. Essas telas foram desenvolvidas utilizando o framework Struts e JSP e foram desenvolvidas aproximadamente 7 telas de cadastro.

No início do estágio foi realmente difícil assimilar toda a tecnologia utilizada na camada web, o padrão mvc, internacionalização, padrões J2ee para camada web eram coisas muito diferentes dos sistemas web que estava acostumado. Era realmente um outro m,undo para que estava acostumado com ASP e PHP.

As telas mais importantes que desenvolvi em relação às regras de negócio do sistema estão descritas nos próximos itens.

Módulo de entrada de amostras no NTO:
Uma das telas relacionadas à entrada de amostras no NTO que eu desenvolvi era a tela principal desse módulo, que para o usuário é muito simples, só recebe um código de amostra ou container e com esse código faz a liberação das amostras para a execução ou coloca-as em aguardo para algum preparo caso o teste relacionada a essa amostra necessite de preparo e essa amostra não tenha realizado todos ainda, ou coloca em aguardo para alguma outra amostra caso o exame relacionado for um exame do tipo múltipla amostra e todas ainda não tenham chegado ao NTO.

Para a utilização dessa tela a máquina cliente também deveria ser previamente registrada como um ponto de controle de execução através de outra tela do sistema. No Motion, pontos de controle server para fazer o rastreamento do fluxo da amostra durante todo o seu ciclo de vida.

Telas de entrada em Container:
Faz o registro de entrada de um container ou uma amostra em um outro container. Essa tela é necessária porque o NTO precisa saber exatamente em que posição do processo da empresa e exatamente em que localização está uma determinada amostra. Quando fiz essa tela já havia sido criada as telas de criação de container.

No Motion um container representa qualquer coisa que possa armazenar uma amostra, desde uma grade que vai para uma centrífuga até uma geladeira que faz a estocagem. Esse container possuir endereços que são criados automaticamente ou manualmente onde ficam as amostras ou outros containers.

Essa tela fui um tanto complicada de ser feita pois, existe 4 tipos de container's diferentes, cada um com a sua forma de endereçamento sendo criada de forma específica. Temos container's com endereços de criação automáticos, com posições identificadas por letras ou números, container's circulares, e grades. Tudo isso foi desenvolvido tendo em mente a maior agilidade no manuseio de amostras no NTO.

As imagens abaixo mostram essa tela e a tela de criação de um novo container:

Tela 1 - Entrada em container
Tela 2 - Criação de container

Módulo de alteração de Requisição existente:

Normalmente no Motion, a requisição de um paciente vem pronta da unidade, com os exames e testes de cada exame que devem ser feitos, associados com suas amostras. Mas era preciso fazer uma tela para alterar uma requisição quando fosse necessário fazer isso no NTO.

Uma requisição é alterada no NTO nos seguintes casos:

Quando é necessário incluir, cancelar ou definir como urgente algum exame (no sistema definido como produto) em uma requisição.
Quando é necessário incluir algum teste em um exame existente. Isso é muito comum em alguns testes, que dependendo do resultado, devem ser repetidos ou que devem ser realizados.
Quando é necessário cancelar ou excluir algum teste que não deve mais ser realizado devido a um resultado de outro teste que já tenha garantido o resultado do exame.

Nesse módulo é possível incluir novos testes, inclusive dentro de testes que são definidos no sistema como testes compostos. É possível associar a esse teste a uma amostra existente do paciente em questão ou fazer um pedido de reconvocação do paciente. Uma reconvocação significa que o paciente vai ter que comparecer novamente à alguma unidade para fazer a coleta de amostra novamente. Isso raramente deve acontecer. Também é possível indicar que um novo teste complementa algum teste já existente dessa requisição.

Esse módulo ainda está em desenvolvimento, devido a algumas mudanças que ocorreram recentemente no sistema.

Logo abaixo estão as telas de manutenção de requisição e outra de manutenção de exame relacionado a uma requisição.

Tela 1 - Manutenção de requisição
Tela 2 - Manutenção de exame relacionada à requisição

Implantação de frameworks de teste:
Após o fim de algumas telas da entrada e concorrentemente com o tópico acima, vi a falta que um mecanismo para testes fazia no desenvolvimento e tive a oportunidade de configurar no ambiente de desenvolvimento os frameworks JUnit / Cactus / StrutsTestCase para os testes de entitys,sessions e telas feitas com o Struts. Da forma que foi configurado facilmente um desenvolvedor poder criar um teste para algum componente EJB e rodá-lo à partir de uma tarefa do ANT. Após o teste criado estar pronto ele pode ir para o ambiente de teste onde será executado várias vezes ao dia, e, caso em alguma execução ocorra uma falha ele será notificado por email.

Ambiente de desenvolvimento:
No final de dezembro de 2002, fiquei também responsável por grande parte da infra-estrutura do ambiente de desenvolvimento, incluindo todas as configurações dos servidores Tomcat e Weblogic, a manutenção dos scripts de build (ANT) utilizado por todos os desenvolvedores, em testes de novas versões dos servidores e em todas as tarefas relacionadas ao deploy da aplicação.

No início do projeto, muito antes de eu entrar na empresa, foi definido que seria utilizada uma arquitetura centralizada no ambiente de desenvolvimento, isto é, todo o código fonte da aplicação ficaria centralizado em um único servidor e existiria dois servidores de aplicação e dois servidores web para o desenvolvimento independentes dos desenvolvedores. Essa escolha teve suas vantagens e desvantagens. Uma grande vantagem foi a agilidade no desenvolvimento, já que o build era centralizado , não havia o CVS implantado no ambiente e raramente alguém mexia num código que alguém já estava mexendo. Outra vantagem foi que cada desenvolvedor não precisa fazer nenhuma configuração ou instalação na própria máquina para poder começar a desenvolver.

Aqui está um diagrama simplificado do ambiente de desenvolvimento.

A aplicação Motion é composta de duas aplicações com scripts de montagem independentes, a aplicação Model e a aplicação Web. Os dois builds em conjunto possuem quase 3000 linhas de código, mas à algum tempo atrás possuía muito mais. Esses scripts foram refatorados algumas vezes para diminuir a complexidade da montagem da aplicação.
Devido ao tamanho da aplicação, à quantidade de ferramentas e tecnologias utilizadas, os cerca de 400 componentes EJB a tarefa de manter o ambiente de desenvolvimento sem problemas gera muito trabalho.

O ambiente de controle de qualidade:
Esse ambiente, também chamado de ambiente de teste, foi implantado por mim na mesma época em que era implantado o CVS no ambiente de desenvolvimento, em fevereiro de 2003 aproximadamente. O objetivo do ambiente de teste é poder fazer a integração do sistema de forma contínua, isto é, compilar toda a aplicação, gerar os pacotes, o deploy e os testes unitários e funcionais de forma automatizada e frequënte.

Para ajudar nessa tarefa instalei uma ferramenta chamada CruiseControl, inspirado pelo artigo Continuous Integration de Martin Fowler and Matthew Foemmel. Essa ferramenta faz a seguintes tarefas: