O primeiro passo para começar a utilizar as facilidades da Aplicação é realizar a inserção das informações relativas a um exame ECG que se queira analisar. O sistema deve ser capaz de oferecer um formulário onde deverão ser cadastrados alguns dos atributos do novo exame a partir de um navegador através da Web. Ao adicionar tags J SF nas páginas XHT M L 2, estaremos criando as Facelets, que são partes integrantes da especificação J SF 2.0, e compõem as telas expostas pelo navegador (browser ) com as chamadas ao preenchimento dos campos de entrada de dados que ficam associados aos atributos da classe bean correspondente no contexto corrente [203].
A classe bean expõe os atributos e eventos a um framework, como o J SF , através de métodos get e set que ficarão ocultos em todos os diagramas apresentados neste trabalho, pois optou-se por remover do modelo os detalhes de baixo nível. Em vários Diagramas de Sequência apresentados, os relacionamentos entre o Usuário e as classes utilizadas em conjunto com o J SP para a entrada de dados, realizados por métodos get e set, também estarão ocultos.
Alguns desses atributos serão opcionais, porém os demais serão vitais para o processamento das informações constantes no ECG e sua ausência deve ser impe- ditiva para a continuidade da própria atividade de cadastro do novo exame. Uma condicionante é então imposta no Diagrama de Atividade, ilustrado na figura 27, que impede que um cadastro seja concluído até que todos os atributos obrigatórios sejam devidamente preenchidos.
Na conclusão do cadastro do novo exame, o sistema deve retornar a lista de exames cadastrados e estabelecer um ponto de parada, para aguardar nova ação do
Figura 27 – Diagrama de Atividade para o cadastramento de um novo exame.
usuário. Através desta lista, estarão disponíveis as ações que poderão ser tomadas pelo usuário para a continuidade da análise do exame. Também é providencial incluir nesse momento um aviso de que a ação de cadastramento foi concluída com êxito.
O cadastramento será realizado através da persistência dos atributos pre- enchidos em um formulário fornecido em uma página HT M L enxertada com tags do J SF , que proporcionará a inserção em um Banco de Dados utilizando uma coleção de classes beans, algumas delas mapeadas pelo Hibernate, que deverão ser implementadas para que se possa realizar tal persistência.
O acesso a tais classes dar-se-á através de suas instâncias criadas e repassadas ao Model no escopo da requisição (request), e cada um dos campos do formulário deverá estar associado a uma propriedade alcançável por um método get do objeto do Model, que por sua vez está associado a métodos get e set das classes que endereçam os atributos e são mapeadas pelo Hibernate para a composição das tabelas geradas automaticamente no Banco de Dados [201]. Para a orientação objeto, o relacionamento entre as classes deve ser representado em um Diagrama de Definição de Bloco, como ilustrado na figura 28.
Para cumprir sua função, as classes AdminExamBean, AdminListExamBean e LeadsList deverão receber a anotação @Model do J SF para que seus objetos sejam repassados ao Model durante a requisição, enquanto as classes Exam e Lead recebem a anotação @Entity para que o Hibernate realize o mapeamento do objeto criado com a respectiva tabela no Banco de Dados.
Figura 28 – Diagrama de Definição de Bloco para o cadastramento de um novo exame.
para evitar que uma requisição seja feita com atributos insuficientes para completar a regra de negócio proposta, evitando assim a formação de objetos imprestáveis com a respectiva persistência de seus dados. As classes DAO chamarão uma AP I do J P A para manipular o acesso ao Banco de Dados; são elas: ExamDAO e LeadDAO, utilizadas unicamente para esse fim.
Várias das atividades necessárias para cadastrar um novo exame são atômicas, porém sua sequência interna com a respectiva atuação de cada classe envolvida é controlada pelos objetos que fomam o Model. Diagramas de sequência refletam características comportamentais e conseguem especificar as interação temporais entre os subsistemas e componentes [35], e o Diagrama de Sequência da figura 29 ilustra o sequenciamento da parte do código responsável pelo cadastro de um novo exame no sistema, onde fica explícito o controle das classes que formam o Model sobre as classes DAO, que, por sua vez, são responsáveis pelo acesso aos atributos mapeados através das classes que serão inseridas no Banco de Dados.
Quando um novo cadastro é realizado através do formulário ilustrado na figura 30, o Banco de Dados será alimentado com as informações fornecidas pelo usuário, porém o arquivo do exame ECG propriamente dito ainda não foi transferido
Figura 29 – Diagrama de Sequência para o cadastramento de um novo exame.
para o servidor. Isso se dará após nova ação a ser iniciada pelo usuário através da ferramenta correspondente disponível na Aplicação. A figura 31 indica a situação em que o cadastramento foi realizado com êxito, ao mesmo tempo que mostra uma lacuna na posição que deveria constar o arquivo contendo o ECG para o cadastramento recém realizado.
Esta estrutura desvincula o cadastro do exame da transferência do arquivo que contém o sinal do ECG e fornece maior flexibilidade na operação da Aplicação uma vez que o cadastro independe da existência do arquivo de ECG no servidor. O ECG poderá ser transferido a qualquer tempo, sempre que necessário, evitando a necessidade de manter e gerenciar um servidor de arquivos, algo indesejado nesta versão da Aplicação.