DESENVOLVIMENTO DE SOFTWARE PARA INTERVENÇÃO PSICOLOGICA JUNTO A CRIANÇAS HOSPITALIZADAS

Transcrição

1 CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO EDMILSON DE ARAUJO AMANCIO DESENVOLVIMENTO DE SOFTWARE PARA INTERVENÇÃO PSICOLOGICA JUNTO A CRIANÇAS HOSPITALIZADAS VILA VELHA 2011

2

3 EDMILSON DE ARAUJO AMANCIO DESENVOLVIMENTO DE SOFTWARE PARA INTERVENÇÃO PSICOLOGICA JUNTO A CRIANÇAS HOSPITALIZADAS Trabalho de Conclusão de Curso apresentado ao Centro Univertário Vila Velha como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação. Orientador: Vinicius Rosalen VILA VELHA 2011

4 EDMILSON DE ARAUJO AMANCIO DESENVOLVIMENTO DE SOFTWARE PARA INTERVENÇÃO PSICOLOGICA JUNTO A CRIANÇAS HOSPITALIZADAS BANCA EXAMINADORA Prof. Msc. Vinicius Rosalen Centro Universitário Vila Velha Orientador Prof. Msc. Susiléa Abreu dos Santos Lima Centro Universitário Vila Velha Prof. Msc. Marcello Novaes de Amorim Centro Universitário Vila Velha Trabalho de Conclusão de Curso aprovado em 09/12/2011.

5 "Eu, Edmilson de Araujo Amancio, autorizo que a UVV, sem ônus, promova a publicação de minha monografia em página própria na Internet ou outro meio de divulgação de trabalho científico." Data: / /

6 Aos meus pais, esposa e irmãos...

7 AGRADECIMENTOS Primeiramente agradeço a Deus, por me dar força, coragem para prosseguir e guiar meus caminhos. Ao meu pai Ademir Ribeiro Amancio e minha mãe Denise de Araujo Amancio, pelo total apoio e incentivo para realizar esta graduação, sem eles teria sido muito mais difícil. A minha esposa Wanneska Nascimento Amancio, que por tantas vezes teve que se privar da minha companhia durante o período de graduação e sempre tem uma palavra de amor e carinho nos momentos difíceis. Aos meus irmãos Edney de Araujo Amancio e Grazielle de Araujo Amancio por fazerem parte da minha vida. Ao meu cunhado Washington Francisco Nascimento e sua esposa Rosangela Lopes Nascimento, que sempre me receberam em sua casa com muito carinho e me deram muito ajuda e apoio. Ao amigo Austecliano de Sá Anacleto pela ajuda neste trabalho e vários outros que realizamos juntos. Ao professor Vinicius Rosalen pela oportunidade de participar deste projeto tão importante e a todos os professores da UVV que contribuíram para a minha formação. E a professora Alessandra Brunoro Motta pela simpatia durante o período de realização deste projeto.

8 O perigo real não é de computadores começarem a pensar como homens, mas de homens começarem a pensar como computadores. Sydney J. Harris

9 LISTA DE TABELAS 1 Descrição do problema Sentença de posição do produto Resumo dos envolvidos Resumo dos Usuários

10 LISTA DE FIGURAS 1 Prancha cantar e dançar Diagrama de análise de estratégias Ciclo de vida incremental[1] Diagrama de casos de uso Diagrama de casos de uso do pacote Controle Administrativo Diagrama de casos de uso do pacote Avaliação Diagrama de Pacotes Diagrama de classes pacote controle administrativo Diagrama de classes pacote avaliação Diagrama transição de estados da avaliação Diagrama de sequência cadastrar criança Diagrama de sequência alterar criança Diagrama de sequência remover criança Diagrama de sequência consultar criança Diagrama de sequência cadastrar familiar Diagrama de sequência alterar familiar Diagrama de sequência remover familiar Diagrama de Sequência Cadastra Avaliação Diagrama de Sequência Remover Avaliação Diagrama de sequência escolher opção Diagrama de sequência aplicar avaliação Diagrama de sequência registrar inquérito

11 23 Diagrama de sequência visualizar Pós-Avaliação Diagrama de sequência cadastrar avaliador Diagrama de sequência alterar avaliador Diagrama de sequência remover avaliador Diagrama de sequência consultar avaliador Arquitetura Lógica Divisão em camadas do subsistema de Controle Administrativo Divisão em camadas do subsistema Avaliação Diagrama de Classes Modelo Controle Administrativo Diagrama de Classes Modelo Avaliação Diagrama de Classes Controle Administrativo Diagrama de Classes Controle Avaliação Diagrama de Classes Dao Administrativo Diagrama de Classes Dao Avaliação Diagrama de sequência cadastrar criança Diagrama de sequência alterar criança Diagrama de sequência consultar criança Diagrama de sequência remover criança Diagrama de sequência cadastrar familiar Diagrama de sequência alterar familiar Diagrama de sequência remover familiar Diagrama de sequência cadastrar avaliação Diagrama de sequência aplicar avaliação Diagrama de sequência escolher opção Diagrama de sequência registrar inquérito Diagrama de sequência visualizar Pós-Avaliação

12 49 Diagrama de sequência cadastrar avaliador Diagrama de sequência alterar avaliador Diagrama de sequência consultar avaliador Diagrama de sequência remover avaliador Modelo do banco de dados Modelo do banco de dados Diagrama de Navegabilidade Componente JDateChooser Padrão dos Botões Apresentação dos menus Barra de Ferramentas Tela de cadastro de criança Tela de cadastro de avaliação Tela de aplicação Tela registro do inquérito Tela de seleção dos modos de enfrentamento Tela play de áudio Tela Pós-avaliação Tela relatório contagem por prancha

13 SUMÁRIO RESUMO 1 INTRODUÇÃO Objetivo Justificativa e motivação APRESENTAÇÃO DO PROCESSO DE AVALIAÇÃO AEH Avaliação do enfrentamento da hospitalização ABH Avaliação do brincar no hospital LEVAMTAMENTO E ESPECIFICAÇÃO DE REQUISITOS Documento de Visão Posicionamento Descrições dos Envolvidos e dos Usuários Ambiente do Usuário Principais Necessidades dos Usuários ou dos Envolvidos Visão Geral do Produto Especificação de requisitos funcionais e não funcionais Diagrama de casos de uso Descrição de casos de uso Acessar sistema (CSU01) Alterar Senha (CSU02) Manter Criança (CSU03)

14 3.4.4 Manter composição familiar (CSU04) Manter avaliação (CSU05) Aplicar Avaliação (CSU06) Escolher Opção (CSU07) Registar Inquérito (CSU08) Visualizar Pós-Avaliação (CSU09) Manter Grupos (CSU10) Manter Escolaridade (CSU11) Manter tipo de parentesco (CSU12) Manter Local de Aplicação (CSU13) Manter Avaliador (CSU14) Manter Especialidade (CSU15) Manter Religião (CSU16) Manter Instituições (CSU17) ESPECIFICAÇÃO DE ANÁLISE DE REQUISITOS Diagramas de classes Diagrama de transição de estados Diagramas de sequência Diagramas de Sequência Manter Criança Diagramas de Sequência Manter Composição Familiar Diagramas de Sequência Manter Avaliação Diagramas de Sequência do processo de avaliação Diagramas de sequência Manter Avaliador ESPECIFICAÇÃO DE PROJETO Tecnologias utilizadas

15 5.1.1 Plataforma de desenvolvimento Java NetBeans IDE JasperReport e ireport MySQL Arquitetura do sistema Arquitetura em camadas Diagramas de classes revisados Pacote modelo Pacote controle Pacote Dao Diagrama de sequência revisado Diagramas de Sequência Manter Criança Diagramas de Sequência Manter Composição Familiar Diagramas de Sequência do processo de avaliação Diagramas de sequência Manter Avaliador Diagrama de implantação Modelagem do banco de dados Diagrama de navegabilidade Interface com o usuário CONCLUSÃO Trabalhos futuros REFERÊNCIAS 116 Requisitos funcionais e não funcionais 118

16 RESUMO Este trabalho propõe o desenvolvimento de um sistema de software em plataforma Desktop para intervenção psicológica junto a crianças hospitalizadas. Aqui são apresentados os instrumentos de avaliação do enfrentamento da hospitalização (AEH), que permite identificar as estrategias de enfrentamento utilizadas pela criança ao lidar com a situação de hospitalização, além daquele de avaliação do brincar no hospital (ABH), elaborado para avaliar as preferências lúdicas da criança podendo contribuir para as necessidades institucionais voltadas a promoção de uma qualidade de vida adequada no ambiente hospitalar. Sendo que os métodos de avaliação consistem em apresentar à criança imagens que retratam comportamentos que a mesma pode apresentar durante o período em que se encontra hospitalizada ou atividades lúdicas de preferência da criança, e com base nos relatos emitidos pela mesma em entrevista realizada durante o processo torna-se possível a identificação das estrategias de enfrentamento ou as preferencias lúdicas fornecendo subsídios para intervenção neste contexto. Este sistema terá por objetivo permitir ao profissional responsável em aplicar a avaliação maior disponibilidade em observar os comportamentos da criança ao realizar a entrevista, dado que não terá mais a preocupação com as anotações referentes a mesma, pois esta passará a ser gravada pelo sistema; facilitar os processo cadastrais e tornar mais agradável e intuitivo a avaliação para a criança. Será apresentado também as etapas que nortearam o desenvolvimento do referido sistema que são: a etapa de levantamento e especificação de requisitos; especificação de analise de requisitos; especificação de projeto. Fases estas realizadas na Fabrica de Software do Centro Universitário Vila Velha, local este que permite aos alunos aplicarem os conhecimentos adquiridos ao longo do curso ou mesmo desenvolver novas habilidades no que diz respeito à Ciência da Computação. Palavras-chave: Avaliação, Hospitalização, Enfrentamento.

17 15 1 INTRODUÇÃO O modelo biopsicossocial de concepção de saúde, adotado pela Organização Mundial de Saúde, ao qual enfatiza que a saúde é um estado de completo bem- estar físico, mental e social, e não simplesmente a ausência de doença ou enfermidade [2], bem como os avanços tecnológicos da medicina, contribuíram para a inserção de diversos profissionais não médicos nas instituições de saúde. Entre esses profissionais, encontra-se o psicólogo, cuja atuação se tornou ampliada para além da atenção à saúde mental, passando a abranger a área da saúde como um todo. Coerente com esse posicionamento, a medicina tem direcionado a atenção para os determinantes e consequências psicológicas da doença para o indivíduo, com vistas a melhorar sua qualidade de vida [3]. Essas consequências podem ter efeitos mais agravantes em crianças e adolescentes pelo fato de estes se encontrarem em uma fase de desenvolvimento, tanto físico quanto mental. Portanto, uma área com a qual o modelo de assistência psicológica em saúde pode contribuir é a pediatria, em que os aspectos dos desenvolvimentos físico e mental da criança e do adolescente, relacionados ao processo de saúde e doença, são algumas das preocupações da área [4] e [5]. A psicologia pediátrica abrange questões relacionadas ao desenvolvimento físico e mental, saúde e doença; que afetam crianças, adolescentes e suas famílias. Entre os fatores que afetam o desenvolvimento infantil está a hospitalização. Sabe-se que muitas das reações de stress e sofrimento estão relacionadas à exposição frequente a procedimentos médicos invasivos, à restrição de atividades cotidianas, ao afastamento familiar, à necessidade de se adaptar a uma nova rotina, entre outros [6]. Levando em consideração que a hospitalização infantil pode acarretar danos psicológicos que a criança sentirá pelo resto de sua vida, é muito importante que sejam agregados ao tratamento médico medidas de intervenção psicológica e psicossocial, para amenizar os riscos ao desenvolvimento global da criança, permitindo que esta e sua família mobilizem recursos adequados a um enfrentamento que contribua tam-

18 16 bém com o tratamento médico. A partir do exposto, algumas propostas de avaliação de como a criança enfrenta a hospitalização vem surgindo, entre estas, uma proposta de avaliação do enfrentamento que vem sendo utilizada por pesquisadores do grupo de Psicologia Pediátrica da Associação Nacional de Pesquisadores de Pós-graduação (ANPEPP) e por pesquisadores interessados na temática do enfrentamento é o AEH - Instrumento de Avaliação do Enfrentamento da Hospitalização e o ABH Instrumento de Avaliação do Brincar no Hospital, ambos desenvolvidos por [7] e [8]. 1.1 Objetivo Uma vez levantada a importância da psicologia pediátrica no desenvolvimento físico e mental da criança e do adolescente; e expostos os instrumentos de avaliação AEH e ABH, os quais serão explanados em mais detalhes no capítulo seguinte, é apresentado o objetivo deste projeto de pesquisa, que consiste em um trabalho integrado entre os cursos de Psicologia e Ciência da Computação do Centro Universitário de Vila Velha, com o intuito do desenvolvimento de um software para a avaliação de estratégias de enfrentamento da hospitalização infantil, criando dessa maneira uma versão informatizada do Instrumento de Avaliação do Enfrentamento da Hospitalização (AEH) e do Instrumento de Avaliação do Brincar no Hospital (ABH). Espera-se com este software proporcionar aos pesquisadores que possuem interesse em tal instrumento maior agilidade e controle ao aplicarem os processos de avaliação, maior disponibilidade do pesquisador para observação dos comportamentos da criança e interação com a mesma, além de facilitar as análises referentes às avaliações, pois uma série de cálculos realizados manualmente passaram a ser feitos de forma automática. Além disso, o referido sistema facilitará o processo de higienização do instrumento, essencial para o ambiente hospitalar, pois agora passara a ser higienizado apenas o computador em que o software encontra-se instalado, além de proporcionar auxilio na tomada de decisão do profissional. O que pode ser considerada a principal das vantagens oferecidas pelo sistema será o fato deste ser um atrativo para a criança, que já viria sofrendo com uma serie de procedimentos médicos, por se tratar em uma atividade lúdica e prazerosa e muitas vezes nova para a criança: o uso do computador.

19 Justificativa e motivação Segundo [8], é crescente o número de estudos que discutem a eficácia da intervenção psicológica com crianças. Porém, alerta para a necessidade de se preencher a lacuna entre os tratamentos empiricamente comprovados em psicologia pediátrica e sua aplicação na prática. Esta situação se repete quando estes estudos possuem suas investigações iniciais baseando-se em modelos de enfrentamento descritos para adultos, muitas vezes não surtindo os efeitos desejados, o que deixa uma lacuna no que se refere à questão do desenvolvimento infantil. E mesmo sendo crescente os estudos a cerca da psicologia pediátrica ainda assim é considerado pequeno o número de pesquisadores que se dedicam a essa área. Desta forma indica-se a necessidade de elaboração e adequação de instrumentos dirigidos a crianças e o desenvolvimento de ferramentas auxiliares para os profissionais que possuem interesse no assunto colocarem em prática suas experiências, além do que, o instrumento ao qual se deseja informatizar é diretamente voltado ao contexto infantil. Pode-se considerar como motivação maior o vinculo social existente neste projeto, que visa amenizar os efeitos e riscos psicológicos que a hospitalização acarreta para a criança e para a sua família.

20 18 2 APRESENTAÇÃO DO PROCESSO DE AVALIAÇÃO Neste capitulo é apresentado em mais detalhes os instrumentos a partir dos quais se propõe o desenvolvimento da versão informatizada. Será exposta a utilização do processo de avaliação em sua forma manual, como é realizado atualmente, visando a esclarecer detalhes dos termos técnicos utilizados no método de avaliação. O conjunto de avaliação é composto pelos dois instrumentos AEH - Avaliação do enfrentamento da hospitalização e o ABH - Avaliação do brincar no hospital, ambos independentes entre si. No entanto, em uma mesma avaliação podem ser aplicados os dois instrumentos sem se perder o objetivo geral de cada um. O processo de avaliação consiste em apresentar para a criança um conjunto de pranchas, sendo prancha um termo utilizado para referenciar uma das figuras que retratam possíveis comportamentos que a criança mais frequentemente apresenta para enfrentar a hospitalização, ou as preferências lúdicas da criança no ambiente hospitalar. Cada instrumento possui seus próprios conjuntos de pranchas; e as mesmas consistem em uma versão para o sexo feminino e outra para o masculino, sendo as pranchas do ABH ainda dispostas em subgrupos, a saber: jogos de exercício, jogos simbólicos, jogos de acoplagem e jogos de regras e atividades recreativas diversas. Na figura 1 é apresentado um exemplo de prancha, sendo esta a prancha cantar e dançar do AEH em sua versão masculina.

21 19 Figura 1: Prancha cantar e dançar As pranchas são apresentadas às crianças, uma por vez, e elas são estimuladas a descrever o que está acontecendo no desenho. Após a descrição da cena, a criança é solicitada a responder o quanto a cena representa o que ela tem feito/pensado/sentido durante a hospitalização. As respostas possíveis são: não, um pouco, às vezes, quase sempre e sempre, as quais possuem atreladas a elas as seguintes pontuações: 0, 1, 2, 3 e 4, respectivamente. Uma vez respondida a solicitação, o avaliador deve proceder ao inquérito, que representa um conjunto de questões padronizadas aplicadas a todas as pranchas com o intuito de se investigar a justificativa da criança, a resposta. O procedimento apresentado até o momento se aplica tanto ao AEH quanto ao ABH. Nas subseções seguintes é apresentado o processo de análise dos dados obtidos na aplicação da avaliação, o que difere de um instrumento ao outro, apresentando suas particularidades e objetivos.

22 2.1 AEH Avaliação do enfrentamento da hospitalização 20 O AEH é um instrumento que permite identificar os comportamentos apresentados pela criança ao lidar com a situação de hospitalização, de modo a fornecer subsídios para a intervenção nesse contexto, o mesmo trata de apresentar vinte cenas que retratam possíveis comportamentos durante a hospitalização. Seu processo de análise consiste no seguinte procedimento: deve-se primeiramente transcrever os relatos obtidos da criança durante o processo de inquérito para o formulário de registro de inquérito, após isso somam-se os valores atribuídos a cada resposta da criança, obtendo-se assim um valor total. Os relatos emitidos pela criança durante o processo de inquérito, para justificar sua escolha de resposta, são analisados e classificados em modos de enfrentamento que retratam os comportamentos apresentados pela criança. A partir destes modos se chega à estratégia utilizada pela criança. No diagrama da figura 2, referente à prancha cantar e dançar, vê-se com mais clareza como é realizado o processo para se chegar à estratégia de enfrentamento, sendo este diagrama atribuído a todas as pranchas. No centro do diagrama consta a prancha a que o mesmo se refere, intermediariamente estão os modos de enfrentamento, que podem ser identificados no relato da criança. De acordo com o modo identificado chegase à estratégia utilizada, e nas bordas do diagrama às estratégias de enfrentamento. Como exemplo, suponhamos que para a prancha cantar e dançar seja identificada a atividade como prazerosa. Logo o avaliador selecionará este modo de enfrentamento e desta forma será identificada a estratégia Distração(DIS).

23 21 Figura 2: Diagrama de análise de estratégias É importante ressaltar que o AEH pode suscitar reações psicológicas de manejo delicado, além de exigir conhecimento técnico na área de psicologia para avaliação dos dados, sendo assim o uso deste torna-se restrito somente a psicólogos no contexto da saúde [9]. 2.2 ABH Avaliação do brincar no hospital O ABH trata-se de um instrumento elaborado exclusivamente para avaliar as preferências lúdicas da criança, e pode contribuir para o direcionamento das necessidades institucionais voltadas à promoção de uma qualidade de vida adequada no ambiente hospitalar. O conjunto de pranchas contempla os seguintes tipos de brincadeiras em seus seguintes subgrupos: jogos de exercício (jogar bola, tocar instrumentos, boliche e jogo das pedrinhas); jogos simbólicos (fantoches, palhaço, desenhar e médico); jogos de acoplagem (montagem, modelagem, recorte/colagem e quebra-cabeça); jogos de regras (baralho, minigame, dominó e bingo) e uma categoria denominada atividades recreativas diversas (assistir TV, ler gibi, ouvir histórias e ouvir música). No processo de análise dos dados obtidos durante a avaliação, transcrevem-se os relatos da criança obtidos no inquérito no formulário de registro de respostas, e somam-se os

24 22 valores referentes a cada resposta da criança, obtendo-se assim um valor total para cada subgrupo do instrumento. No processo de intervenção psicológica existe um programa compostos por varias atividades lúdicas denominadas técnicas de intervenção psicológica, que são utilizadas na intervenção psicológica da criança. Uma técnica é selecionada para ser utilizada quando a criança responde as opções às vezes, quase sempre e sempre. Pelo fato de se tratar de brincadeiras, podem ser selecionadas todas as atividades, neste caso prevalece a escolha do profissional avaliador que usará a que melhor lhe convier, de acordo com os relatos da criança no processo de inquérito. Por se tratar, essencialmente, de um levantamento das preferências lúdicas de crianças hospitalizadas, o ABH pode direcionar ações multiprofissionais que utilizem o brinquedo. Desse modo, seu uso está aberto a outros profissionais além do psicólogo, podendo ser administrado por pedagogos que atuam em classes hospitalares, fisioterapeutas, terapeutas ocupacionais, enfermeiros, recreadores capacitados, entre outros [9].

25 23 3 LEVAMTAMENTO E ESPECIFICAÇÃO DE REQUISITOS Uma vez explicitado do que se tratam os instrumentos AEH e ABH, abordaremos neste capítulo como se procedeu a etapa de levantamento e especificação de requisitos. Desde então é importante salientar que ficou definido que a metodologia de desenvolvimento de software utilizada é uma variação da mesma utilizada nos projetos da Fábrica de Software do curso de Ciência da Computação do Centro Universitário de Vila Velha [1]. A fábrica segue o modelo de ciclo de vida incremental, em que inicialmente é feita uma abordagem do modelo em cascata que se categoriza por possuir uma tendência na progressão sequencial entre uma fase e a seguinte [10]. A partir disso é realizado um planejamento do sistema. Concluído o planejamento é dado início à etapa de levantamento de requisitos, seguindo-se para a fase de análise e, por fim, é feito o projeto arquitetural do sistema. De posse dos artefatos gerados ao fim do projeto arquitetural, o desenvolvimento do software é dividido em ciclos e passa a ocorrer gradualmente e, ao final de cada estágio, uma versão operável é produzida e incrementada nos demais estágios até a sua conclusão final. A figura 3 ilustra um exemplo de como ocorre este modelo de desenvolvimento.

26 24 Figura 3: Ciclo de vida incremental[1] A etapa de levantamento de requisitos corresponde a buscar junto ao usuário, seus sistemas e documentos, todas as informações possíveis sobre as funções que o sistema deve executar e as restrições sob as quais o sistema deve operar [11]. Para tanto foram utilizadas várias técnicas de levantamento de requisitos, objetivando-se compreender o domínio do problema. Dentre as diversas técnicas propostas por [12] são apresentadas as que foram utilizadas: Entrevista, onde semanalmente eram realizadas reuniões com a participação de professores do curso de psicologia do Centro Universitário de Vila Velha, que possuem o entendimento do domínio do problema; Investigação em documentos, onde foi feita uma revisão da literatura sobre os temas do projeto, a saber: estratégias de enfrentamento, hospitalização infantil e brincar no hospital; Observação, onde foi realizada a observação da aplicação do método em sua forma manual como é realizada hoje, além de outros sistemas da área psicológica, que apesar de não serem sistemas voltados para avaliação de enfrentamento, proporcionou a ideia de como realizar algumas funções da forma como os usuários de sistemas voltados para psicologia estão habituados.

27 25 Por fim foi criado um protótipo das interfaces gráficas do sistema a ser construído, ao qual serão apresentadas algumas desta interface no capítulo 5, com o intuito de validar os dados levantados com as técnicas anteriores, buscando seu aproveitamento para etapa de implementação. 3.1 Documento de Visão O documento de visão representa um relato resumido com os principais tópicos do negócio a ser automatizado [13]. Tem por objetivo coletar, analisar e definir necessidades e recursos de nível superior do sistema a ser desenvolvido. Ele se concentra nos recursos necessários aos envolvidos e aos usuários-alvo sendo estes apresentados nas tabelas 3 e 4 e nas razões que levam a essas necessidades que pode ser vista na tabela 1 e 2. Os detalhes de como o sistema satisfaz essas necessidades são descritos no caso de uso que consiste de uma descrição do uso do sistema Posicionamento Descrição do problema O problema 1. Falta de um sistema para automatizar o processo de aplicação de avaliação psicológica AEH e ABH, que gerencie todo o processo de aplicação da avaliação, desde o cadastro das crianças e seus dados clínicos bem como dos avaliadores, e que permita um maior controle e facilidade de acesso às avaliações e seus resultados. Afeta O avaliador e a criança.

28 26 Cujo impacto é 1. Avaliador Perca de tempo no preenchimento do Formulário de Registro de Resposta, onde são registradas as respostas do avaliado bem como a sua pontuação (não - pontuação 0; um pouco- 1 ponto; às vezes 2 pontos; quase sempre - 3 pontos e sempre - 4 pontos). E com a soma dos pontos, onde é obtida a pontuação total no caso do AEH, e uma pontuação das brincadeiras preferidas da criança no caso do ABH. Perca de tempo para transcrever as resposta das crianças referentes ao inquérito. 2. Criança Poderá demonstrar maior interesse em realizar o processo de avaliação, pelo fato de o uso do computador ser uma experiência nova e atrativa. Uma boa solução seria O desenvolvimento de um sistema que permita um maior controle do cadastro das crianças e dos avaliadores, e permita maior controle gerencial das aplicações e facilite o trabalho dos avaliadores quanto a todo o processo de avaliação e analise dos dados obtidos nos mesmos. Tabela 1: Descrição do problema Sentença de Posição do Produto Para Pesquisadores que possuem interesse em realizar pesquisas na área de psicologia pediátrica, utilizando o instrumento de avaliação do enfrentamento hospitalar (AEH) e o instrumento de avaliação do brincar no hospital (ABH).

29 27 Os quais O AEHcomp Que Ao contrário de O produto Passaram a ter uma maior agilidade e controle ao aplicarem os processos de avaliação, bem como maior facilidade para realizarem as análises referentes às avaliações, pois uma série de cálculos realizados manualmente passarão a ser feitos de forma automática, além de o sistema sugerir algumas técnicas de intervenção auxiliando na tomada de decisão e facilitar o acesso aos dados das avaliações, e permitir maior disponibilidade do avaliador para observação da criança. É um sistema desktop. Ficará instalado no computador pessoal do profissional responsável por aplicar a avaliação. Como é realizado atualmente, onde todo o processo é feito de forma manual, desde o cadastro da criança, a aplicação da avaliação e a análise das informações obtidas durante a realização da aplicação, dificultando a gerência e a análise dos dados. Dará mais autonomia, flexibilidade e rapidez na geração dos relatórios necessários e na análise dos dados. Dará acesso necessário aos avaliadores especificados, pois existem restrições sobre quais profissionais podem aplicar o AEH. Dará também qualidade na recuperação de qualquer informação referente ao processo de avaliação. Tabela 2: Sentença de posição do produto Descrições dos Envolvidos e dos Usuários Resumo dos Envolvidos Nome Descrição Responsabilidades

30 28 Professor do curso de Pessoa que orienta Ciência da Computação. e monitora o desenvolvimento de todo o sistema. Aluno do curso de Ciência Pessoa que irá desenvolver da Computação. o sistema. Professora do curso de Pessoa que desenvolveu Psicologia. o processo de avaliação, e deseja uma versão informatizada do mesmo. Tabela 3: Resumo dos envolvidos Monitorar o andamento do projeto e realizar a orientação do mesmo, sugerindo melhorias no desenvolvimento. Coletar informações necessárias ao desenvolvimento do sistema, realizar a análise, projeto e desenvolvimento do sistema. Informa como é realizado o processo de avaliação, suas necessidades e o que ela deseja que o sistema contenha. Resumo dos Usuários Nome Descrição Responsabilidades Envolvido Avaliador Pessoa que é responsável por aplicar o processo de avaliação, e realizar o cadastro das crianças. Administrador Pessoa responsável por realizar a manutenção dos avaliadores e manter a base de dados com cadastro de especialidades e instituições. Aplicar avaliação, manter o registro de crianças, preparar nova aplicação, manter inquérito. Manter avaliador, manter especialidades, manter instituição, manter escolaridade, manter religião.

31 29 Avaliado Pessoa que receberá a avaliação. Não possui Tabela 4: Resumo dos Usuários Ambiente do Usuário Atualmente o processo é realizado de forma manual, em que são preenchidas fichas cadastrais impressas para o registro da criança bem como das avaliações. O processo de avaliação é aplicado em um caderno, contendo as pranchas da avaliação, que são apresentadas às crianças à medida em que a aplicação avança. Para registrar os relatos e as escolhas da criança, utiliza-se um gravador ou anotação em papel. Após isso, o avaliador realiza os cálculos necessários e preenche o inquérito com as respostas que foram obtidas no momento da aplicação. Caso necessite gerar os relatórios, recupera todas as aplicações e as analisa Principais Necessidades dos Usuários ou dos Envolvidos Manter crianças É necessário oferecer ao usuário responsável pela aplicação da avaliação, meios onde ele possa realizar cadastro, remoção, consulta ou alteração de uma criança, sendo que uma aplicação não pode deixar de ser realizada por falta de dados da criança, portanto, ao se realizar um cadastro, poderá ser registrado somente o nome, o sexo e a idade, sendo os demais dados lançados posteriormente. Ainda, no que tange ao controle da criança, existe a necessidade de manter a sua composição familiar, pois uma avaliação poderá ser aplicada não somente à criança mais também a um de seus familiares com o objetivo de contrapor o que a criança diz estar fazendo/pensando/sentindo com o que o familiar em questão diz ter observado sobre o seu comportamento. Logo, no cadastro da criança, deve existir um meio de inserir a composição familiar da mesma. Manter avaliador É necessário manter um controle dos avaliadores, onde poderá ser cadastrado, alterado, consultado ou removido um avaliador cabendo ao administrador realizar este

32 30 controle. Como o AEH poderá ser aplicado somente por avaliadores cuja especialidade seja psicólogo, cada avaliador terá um login que o dará acesso somente às funcionalidades que lhe são cabíveis. Manter avaliação Deve ser dado ao avaliador mecanismos onde ele possa cadastrar ou remover uma avaliação, lembrando que, referente ao AEH, estas funcionalidades poderão ser realizadas somente por usuários cuja especialidade seja psicólogo. Quando se aplicar uma avaliação a mesma poderá ser pausada a qualquer momento, pois podem ocorrer eventos que não permitam a continuação da aplicação. Por exemplo, a criança pode não estar se sentindo bem ou estar na hora em que ela deva tomar algum medicamento, no entanto esta avaliação poderá ser retomada em outro momento oportuno. É importante ressaltar que na prancha inicial, onde é apresentado o personagem convidando a criança a saber o que ele tem a dizer, deverá ter uma gravação do personagem convidando a criança, com o objetivo de chamar a sua atenção para o processo de avaliação. Registrar inquérito O inquérito é formado por um conjunto de questões padronizadas que são aplicadas a todas as pranchas do processo com o intuito de se investigar a justificativa da criança para a resposta. O sistema deverá permitir ao avaliador registrar as respostas obtidas durante o processo de avaliação, considerando que somente a primeira pergunta seja obrigatória. Deverá ser exibido no topo do inquérito o nome da prancha a qual o mesmo é referente, e a resposta do avaliado para prancha. Os relatos emitidos pela criança durante o processo de inquérito do AEH para justificar sua escolha de resposta são analisados e classificados em modos de enfrentamento. O sistema deverá apresentar os modos de enfrentamento para que o avaliador possa selecionar os que foram identificados, e, com base nas escolhas feitas pelo avaliador, o sistema deverá identificar as estratégias de enfrentamento.

33 31 Manter instituição Como o sistema será distribuído a outros avaliadores que possuem interesse no instrumento, é necessário manter um controle da instituição dos avaliadores, portanto, devem existir meios onde possam ser cadastradas, removidas ou alteradas as instituições. É importante ressaltar que tais operações devem ser desempenhadas pelo administrador. Manter Religião Pelo fato de existirem vários tipos de religião, o sistema deve permitir cadastro ou remoção das religiões na base de dados, sendo esta função desempenhada pelo administrador. Manter local de aplicação A aplicação de teste poderá ser realizada em locais diferentes, por exemplo, enfermaria e ambulatório. Sendo assim, deve ser mantido um registro dos locais onde uma aplicação poderá ser realizada. Gerar relatórios Deverá ser permitido ao avaliador gerar relatórios; dois tipos de relatórios poderão ser gerados. Um será a contagem por pranchas, em que será exibido o quantitativo em que determinada estratégia foi identificada para uma determinada prancha, bem como seu total a todas as pranchas. O outro será uma contagem das estratégias por criança, bem como a média para a criança e o total de determinada estratégia a todas as crianças, e a média para a estratégia. Exportar dados Todas as informações coletadas no processo serão mantidas na máquina em que o sistema encontra-se instalado. Torna-se necessário neste momento a possibilidade de exportar as informações referentes às avaliações, pois pode ser que seja necessário o envio para uma análise estatística mais aprofundada. Então será gerado algum relatório que não seja contemplado pelo sistema.

34 32 Manter grupos O sistema será utilizado, tanto para pesquisa quanto para controle de intervenção psicológica. Sendo assim deve ser permitida a criação de grupos para associar as avaliações. No momento do cadastro do grupo, será decidido se o mesmo será um grupo experimental ou controle e deverá ser feita uma descrição do mesmo Visão Geral do Produto Perspectivas do Produto O sistema automatizará todo o processo referente a aplicação das avaliações (AEH e ABH), com um cadastro dos usuários do sistema, oferecendo um maior controle e permitindo que tenham acesso somente a áreas que o interessam. Oferece ainda um cadastro das crianças facilitando sua identificação durante o período em que se encontra internada, além de aumentar a satisfação das crianças em realizar o processo, por se tratar de uma experiência nova e atrativa para muitas delas. Além do mais, facilitará o processamento e a análise das informações coletadas, apoiando o profissional na tomada de decisões e possibilitando maior disponibilidade para observação da criança. 3.2 Especificação de requisitos funcionais e não funcionais Segundo [11] requisitos funcionais descrevem o comportamento do sistema, ou seja, consiste de uma listagem de tudo que o sistema deve fazer. Enquanto que os requisitos não funcionais expressam como deve ser feito; são as restrições impostas sobre como deve ser realizado os requisitos funcionais. Os requisitos funcionais são apresentados no anexo Diagrama de casos de uso O diagrama de casos de uso é um diagrama da UML(Unified Modeling Language) e corresponde a uma visão externa de alto nível do sistema. Esse diagrama rep-

35 33 resenta graficamente o ator que consiste de papéis que os usuários desempenham quando interagem com esses casos de uso [14], e relacionamentos entre esses elementos. Um caso de uso consiste em um relato do uso de certa funcionalidade do sistema, porém sem revelar a estrutura e o comportamento interno do mesmo [10]. Em seguida serão apresentados os diagramas referentes aos casos de uso identificados com as técnicas que foram aplicadas na elicitação de requisitos. Desde então é importante lembrar que, segundo [10], o termo pacotes se refere a um mecanismo utilizado para agrupar elementos semanticamente relacionados e este se trata de um mecanismo genérico. Logo, podem ser utilizados para agrupar quaisquer outros elementos conforme será visto nos capítulos seguintes. Os diagramas de casos de uso do sistema foram divididos em dois pacotes, conforme é visto na figura 4, sendo um referente à parte administrativa do sistema ao qual é apresentado com maior detalhe na figura 5. Neste diagrama, destaca-se como principal caso de uso o manter avaliador, em que é definido os acessos que o avaliador terá perante o sistema, já que o AEH deve ser aplicado somente por psicólogos, os casos de uso restantes existem apenas para permitir ao ator administrador alimentar uma base de dados. Figura 4: Diagrama de casos de uso

36 34 Figura 5: Diagrama de casos de uso do pacote Controle Administrativo A figura 6 é referente ao pacote de avaliação. Nela se destacam como principais casos de uso do sistema, manter criança, manter avaliação, aplicar avaliação e registrar inquérito, todos, casos de uso do processo de avaliação, além do caso de uso escolher opção, momento no qual a criança que está sendo avaliada interage com o sistema.

37 35 Figura 6: Diagrama de casos de uso do pacote Avaliação 3.4 Descrição de casos de uso A UML não define uma estrutura especifica a ser utilizada na descrição de um caso de uso. Por conta disso, há diversas propostas de descrição. Para este trabalho foi seguida a estrutura proposta por [10] Acessar sistema (CSU01) Sumário: este caso de uso descreve como o ator obtém acesso ao sistema. Ator Primário: avaliador, administrador. Pré-condições: o ator deverá ter um login e uma senha para acessar ao sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator solicita acesso ao sistema. 2. O sistema apresenta um formulário para que o ator insira seu login e sua senha.

38 36 3. O ator informa seu login e senha; confirma ou decide cancelar a operação e o caso de uso se encerra. 4. O sistema verifica o login e a senha. Se estiver correto, o sistema permite o acesso e o caso de uso se encerra. Fluxo Alternativo (3): primeiro acesso. a. O sistema identifica que é o primeiro acesso do ator e solicita que informe se deseja alterar sua senha. b. O ator informa que deseja alterar sua senha e o caso de uso alterar senha (CSU02) é executado ou cancela a operação e o caso de uso se encerra. Fluxo de exceção (3): campo não preenchido. a. Um dos campos não foi preenchido. O sistema reporta o fato e o caso de uso retorna ao passo 3. Fluxo de exceção (3): usuário ou senha inválido. a. O usuário não está cadastrado; a senha informada ou login estão incorretos, o sistema reporta o fato e o caso de uso retorna ao passo 3. Pós-condições: depois de realizado o caso de uso o ator terá acesso ao sistema de acordo com o seu perfil de usuário Alterar Senha (CSU02) Sumário: este caso de uso descreve como o ator altera a sua senha. Ator Primário: avaliador, administrador. Pré-condições: o ator está identificado pelo sistema ou o sistema verifica que é seu primeiro acesso. Fluxo Principal 1. Este caso de uso se inicia quando o ator decide alterar sua senha.

39 37 2. O sistema exibe um formulário para que o ator informe sua senha atual, a nova senha e a confirmação da nova senha. 3. O ator informa sua senha atual, a nova senha e a confirmação da nova senha e confirma a operação ou decide cancelar a operação e o caso de uso se encerra. 4. O sistema realiza a alteração da senha e o caso de uso se encerra Fluxo de exceção (3): campo não preenchido. a. Um dos campos não foi preenchido; o sistema reporta o fato e o caso de uso retorna ao passo 3. Fluxo de exceção (3): erro na senha. a. A senha atual está incorreta ou a nova senha não confere com a confirmação da nova senha; o sistema reporta o fato e o caso de uso retorna ao passo 3. Pós-condições: éfeita à alteração da senha do ator Manter Criança (CSU03) Sumário: ator realiza a manutenção (cadastro, remoção, alteração e consulta) dos dados referentes à criança. Ator Primário: avaliador. Pré-condições: o avaliador está identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o avaliador solicita a realização de manutenção de uma criança. 2. O sistema apresenta as operações que podem ser realizadas: o cadastro de uma nova criança, a alteração dos dados de uma criança, a exclusão de uma criança ou a consulta de uma criança. 3. O avaliador indica a operação desejada: cadastro, remoção, alteração, consulta ou opta por encerrar o caso de uso.

40 38 4. O sistema retorna uma mensagem de sucesso. 5. O avaliador confirma a mensagem e o caso de uso se encerra. Fluxo Alternativo (3): cadastrar criança a. O sistema apresenta um formulário em branco para que os dados da criança sejam inseridos. b. O avaliador fornece os dados cadastrais da criança e confirma a operação ou cancela a operação e o caso de uso se encerra. c. O sistema verifica se os campos que são obrigatórios foram preenchidos (nome, sexo e a idade). Se os campos obrigatórios tiverem sido inseridos, a nova criança é cadastrada; caso contrário, o sistema reporta o fato, solicita a correção dos dados e repete a verificação. Fluxo de Alternativo (3): remover criança a. O sistema apresenta uma lista com todas as crianças. b. O avaliador informa a criança a ser removida ou decide cancelar a operação e o caso de uso se encerra. c. O sistema apresenta as informações da criança para que o avaliador confirme a remoção. d. O avaliador confirma que deseja remover a criança apresentada ou decide cancelar a operação e o caso de uso se encerra. e. O sistema remove a criança, exibe mensagem de sucesso e o caso de uso retorna ao passo b. Fluxo de Alternativo (3): alterar criança a. O sistema apresenta uma lista com todas as crianças. b. O avaliador informa criança a qual se deseja realizar a alteração ou decide cancelar a operação e o caso de uso se encerra. c. O sistema exibe os dados da criança informada para alteração.

41 39 d. O avaliador realiza a alteração dos dados e confirma a operação ou cancela a operação e o caso de uso se encerra. d. O sistema verifica se algum campo obrigatório não foi preenchido (nome, sexo e a idade). Se os dados obrigatórios tiverem sido inseridos, a criança é alterada, é exibida mensagem de sucesso e o caso de uso retorna ao passo b, caso contrário, o sistema reporta o fato, solicita a correção dos dados e repete a verificação. Fluxo de Alternativo (3): consultar criança a. O sistema solicita ao avaliador que informe o nome da criança a ser consultada. b. O avaliador informa o nome da criança a ser consultada, ou decide cancelar a operação e o caso de uso se encerra. c. O sistema pesquisa pelo nome informado e exibe uma lista com todas as crianças que o possui; ou não encontra o nome, reporta o fato e o caso de uso se encerra. d. O avaliador seleciona a criança na lista exibida e seleciona a opção de remoção ou alteração; ou cancela a operação e o caso de uso se encerra. Pós-condições: uma criança foi cadastrada ou removida, ou seus dados foram alterados Manter composição familiar (CSU04) Sumário: o ator realiza a manutenção da composição familiar de uma criança (cadastro, remoção, alteração). Ator Primário: avaliador. Pré-condições: o avaliador deverá estar identificado pelo sistema, e deverá estar sendo realizado o cadastro ou a alteração de uma criança. Fluxo Principal 1. O avaliador solicita o cadastro ou a alteração de uma criança. 2. O sistema exibe junto aos campos referentes à criança, o formulário de composição familiar para que os dados do familiar possam ser inseridos.

42 40 3. O avaliador fornece os dados do familiar, e solicita a inserção. 4. O sistema insere o familiar da criança na lista de familiares e o caso de uso se encerra. Fluxo Alternativo (1): remover familiar a. O sistema exibe junto aos campos referentes à criança a lista de sua composição familiar. Caso não exista nenhum registro em sua composição, nada será apresentado. b. O avaliador seleciona o familiar a ser removido. c. O sistema exibe os dados do familiar selecionado d. O avaliador confirma a operação de remoção. e. O sistema remove o familiar e o caso de uso se encerra. Fluxo Alternativo (2): alterar familiar a. O sistema exibe junto aos campos referentes à criança a lista de sua composição familiar, caso não exista nenhum registro em sua composição, nada será apresentado. b. O ator seleciona o familiar a ser alterado. c. O sistema exibe os dados do familiar selecionado para alteração. d. O ator altera os dados; confirma a operação. e. O sistema altera o familiar e o caso de uso se encerra. Fluxo de exceção: dado inválido ou familiar cadastrado. a. O ator informa dados inválidos ou o familiar informado já consta cadastrado no sistema, o sistema reporta o fato e o caso de uso retorna ao passo 2. Pós-condições: um novo familiar foi cadastrado ou removido da composição familiar da criança ou os dados do familiar foram alterados.

43 Manter avaliação (CSU05) Sumário: ator realiza a manutenção (cadastro, remoção) de uma avaliação. Ator Primário: avaliador. Pré-condições: o avaliador deverá estar identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o avaliador solicita a realização de manutenção de uma avaliação. 2. O sistema apresenta as operações que podem ser realizadas: cadastro de uma nova avaliação, remoção de uma avaliação. 3. O avaliador indica a operação que deseja realizar: cadastro, remoção. Fluxo Alternativo (3): cadastro a. O sistema apresenta um formulário para que o avaliador informe os dados da avaliação. b. O avaliador informa todos os dados solicitados e confirma a operação ou opta por cancelar a operação e o caso de uso se encerra. c. O sistema verifica se todas as informações foram preenchidas, se não, reporta o fato e solicita a correção dos dados, e o caso de uso retorna ao passo b. d. O sistema retorna mensagem de sucesso. e. O avaliador confirma a mensagem e o caso de uso se encerra. Fluxo Alternativo (3): remoção a. O sistema apresenta uma lista com todas as avaliações. b. O avaliador indica a avaliação que deseja remover e confirma a operação. c. O sistema remove a avaliação e exibe mensagem de sucesso. d. O avaliador confirma a mensagem e o caso de uso retorna ao passo 3. Pós-condições: uma avaliação foi cadastrada ou removida.

44 Aplicar Avaliação (CSU06) Sumário: o avaliador realiza a aplicação de uma das avaliações vigentes. Ator Primário: avaliador. Ator Secundário: avaliado. Pré-condições: o avaliador deve estar identificado pelo sistema, e a avaliação ter sido previamente cadastrada. Fluxo Principal 1. Este caso de uso se inicia quando o avaliador solicita a aplicação de uma avaliação. 2. O sistema apresenta uma lista com todas as aplicações vigentes. 3. O avaliador seleciona a avaliação que deseja aplicar e solicita ao sistema a sua aplicação. 4. O sistema apresenta as pranchas de acordo com o sexo definido no cadastro da criança. 5. O avaliador decide que o processo de avaliação deve ser gravado. 6. O avaliador inicia a avaliação com uma questão aberta: Durante o tempo em que você fica no hospital, o que você tem feito, pensado ou sentido para ajudar a enfrentar a hospitalização?. 7. Após a resposta do avaliado, o avaliador apresenta o personagem principal do teste referindo que ele já sentiu, fez e pensou várias coisas durante a hospitalização. O avaliador inicia uma gravação do personagem, convidando o avaliado a saber o que ele tem a dizer/oferecer. 8. O sistema executa o áudio do personagem. 9. O avaliador apresenta a tela inicial para o avaliado e explica como deve ser feito o teste. Obs.: a tela inicial é a prancha que traz o personagem principal, convidando o avaliado para a brincadeira. 10. Ao apresentar a tela para o avaliado, o avaliador realiza a seguinte solicitação: 11. Descreva/Conte para mim o que está acontecendo no desenho?

45 Caso o avaliado não consiga descrever o que o personagem está fazendo/ pensando/ sentindo, o avaliador apresenta a questão: 13. Conta para mim o que o Pedro/Ana está fazendo/pensando/sentindo. 14. Após a descrição da cena, o avaliado é solicitado a responder o quanto a cena representa o que ele tem feito/pensado/sentido durante a hospitalização e o caso de uso escolher opção (CSU07) se inicia. 15. Diante da resposta do avaliado, o avaliador deverá investigar a justificativa da resposta, procedendo ao inquérito. 16. O avaliado seleciona a opção avançar para apresentar a próxima prancha. 17. O sistema apresenta a próxima prancha; os passos 10, 11, 12, 13, 14, 15, 16 serão repetidos para cada prancha existente dentro do tipo de avaliação escolhida. 18. Após o processo de avaliação o sistema exibir mensagem de avaliação concluída. 19. O avaliador confirma a mensagem e o caso de uso se encerra. Fluxo de exceção (3): aplicação já iniciada a. O sistema verifica que a avaliação já foi iniciada em outro momento e por algum motivo não foi concluída, apresenta a avaliação na prancha em que a avaliação foi parada e o caso de uso segue para o passo 10. Fluxo de exceção: pausa de avaliação a. A qualquer momento durante o processo de avaliação o avaliador decide para a avaliação (avaliado pode não estar se sentindo bem, ter que tomar algum medicamento ou qualquer outro motivo). b. O sistema solicita que o avaliador informe se realmente deseja parar a avaliação. c. O avaliador informa a opção desejada. d. Se sim, o sistema salva a aplicação e o áudio; e o caso de uso se encerra, se não, o caso de uso prossegue.

46 44 Fluxo de exceção: pausa e execução do áudio a. A qualquer momento o avaliador decide parar ou executar o áudio. b. Se o áudio estiver em execução, o sistema pausa o áudio, se não, o sistema executa o áudio. Fluxo de exceção: retornar Prancha a. A qualquer momento o avaliador solicita retorna uma prancha. b. O sistema retorna a prancha anterior e o caso de uso segue para o passo 10. Pós-condições: é concluída a aplicação de uma das avaliações vigentes Escolher Opção (CSU07) Sumário: o avaliado seleciona a opção desejada quando solicitado. Ator Primário: avaliado. Pré-condições: o caso de uso aplicar avaliação (CSU06) deve estar em execução. Fluxo Principal 1. Este caso de uso se inicia quando, após a descrição da cena do caso de uso aplicar avaliação (CSU06), o avaliado é solicitado a responder o quanto a cena representa o que ele tem feito/pensado/sentido durante a hospitalização; o avaliado seleciona a opção desejada. 2. O sistema registra a opção escolhida pelo avaliado, bem como seu peso, e o caso de uso se encerra. Pós-condições: é registrada a opção escolhida pelo avaliado para a prancha em questão e o peso da opção Registar Inquérito (CSU08) Sumário: o avaliador realiza o registro do inquérito obtido no momento da justificativa do avaliado: a resposta selecionada na avaliação.

47 45 Ator Primário: avaliador Pré-condições: o avaliador deverá estar identificado pelo sistema, e a aplicação da avaliação deverá ter sido concluída. Fluxo Principal 1. Este caso de uso se inicia quando a avaliador solicita o registro do inquérito obtido no processo de avaliação. 2. O sistema apresenta as avaliações que constam pendentes o registro do inquérito. 3. O avaliador seleciona a avaliação desejada e solicita a funcionalidade registrar ou cancela a operação e o caso de uso se encerra. 4. O sistema apresenta uma mensagem de sucesso. 5. O avaliador confirma a mensagem e o caso de uso se encerra. Fluxo Alternativo (3): inquérito do AEH a. O sistema apresenta um formulário para que o avaliador insira a resposta e apresenta os modos de enfrentamento para seleção. b. O avaliador insere a resposta e seleciona os modos de enfrentamento e solicita ao sistema que salve os dados. c. O sistema salva a resposta e os modos de enfrentamento e o caso de uso segue para o passo a, até que o inquérito de todas as pranchas seja respondido. Fluxo Alternativo (3): inquérito do ABH a. O sistema apresenta um formulário para que o avaliador insira a resposta. b. O avaliador insere a resposta e solicita que o sistema a salve c. O sistema salva a resposta e o caso de uso retorna para o passo a até que o inquérito de todas as pranchas seja respondido. Fluxo Alternativo (3): somente as resposta do AEH

48 46 a. O sistema apresenta um formulário para que o avaliador insira a resposta e apresenta os modos de enfrentamento para seleção. b. O avaliador insere somente a resposta do inquérito e solicita que o sistema a salve. c. O sistema salva a resposta e o caso de uso retorna para o passo a até que o inquérito de todas as pranchas seja respondido. d. O sistema apresenta mensagem de inquérito respondido, porém informa que os modos de enfrentamento constam pendentes de seleção. e. O avaliador confirma a mensagem e o caso de uso se encerra. Fluxo Alternativo (3): modos de enfrentamento pendentes do AEH a. O sistema apresenta um formulário com a resposta do inquérito e apresenta os modos de enfrentamento para seleção. b. O avaliador seleciona os modos de enfrentamento e se desejar realiza alteração na resposta e solicita ao sistema que salve. c. O sistema salva os modos de enfrentamento e a resposta em caso de alteração e o caso de uso segue para o passo a até que o inquérito de todas as pranchas seja respondido. Fluxo de exceção: resposta não informada a. Resposta obrigatória não foi informada, o sistema reporta o fato e solicita que seja informada a resposta. Fluxo de exceção: cancelamento do registro a. O avaliador decide cancelar a operação sem concluir o registro da resposta de todas as pranchas do processo de avaliação. b. O sistema exibe mensagem informando ao avaliador o cancelamento e solicita que informe se realmente deseja cancelar a operação. c. O avaliador confirma o cancelamento ou decide continuar com o registro do inquérito.

49 47 d. O sistema encerra o registro do inquérito e o caso de uso se encerra. Pós-condições: o registro de inquérito referente a uma aplicação é concluído ou o registro do AEH é concluído, porém com pendências Visualizar Pós-Avaliação (CSU09) Sumário: o ator visualiza o resultado final da aplicação de uma avaliação. Ator Primário: avaliador Pré-condições: o avaliador está identificado pelo sistema, e a avaliação deve ter sido concluído o registro do inquérito. Fluxo Principal 1. Este caso de uso se inicia quando o avaliador decide visualizar os resultados de uma avaliação. 2. O sistema apresenta todas as avaliações que tenha sido concluído o registro do inquérito. 3. O avaliador informa a avaliação desejada ou cancela a operação e o caso de uso se encerra. 4. O sistema apresenta os dados da avaliação informada. 5. O avaliador visualiza os dados, cancela a operação e o caso de uso se encerra. Fluxo Alternativo (5): análise quantitativa a. O avaliador decide realizar análise quantitativa da avaliação, informa os dados e solicita que o sistema a salve. b. O sistema salva a análise e o caso de uso retorna ao passo 5. Fluxo Alternativo (5): seleção das técnicas de intervenção do ABH a. O avaliador decide alterar as técnicas sugeridas pelo sistema, informa a alteração e solicita que o sistema a salve. b. O sistema salva as alterações e o caso de uso retorna ao passo 5.

50 48 Fluxo Alternativo (5): salvar em arquivo a. O avaliador decide salvar o resultado em arquivo. b. O sistema solicita que o avaliador informe onde deseja salvar o arquivo. c. O avaliador informa o local e confirma a operação. d. O sistema salva o arquivo e o caso de uso retorna ao passo 5. Pós-condições: o avaliador visualiza o resultado de uma avaliação, realiza a análise quantitativa, são feitas alterações nas técnicas sugeridas ou é salvo um arquivo com os dados da avaliação Manter Grupos (CSU10) Sumário: o ator realiza a manutenção dos grupos (cadastro, remoção, alteração). Ator Primário: avaliador. Pré-condições: o avaliador deve estar identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator solicita a manutenção dos grupos. 2. O sistema apresenta um formulário em branco, uma lista com os grupos cadastrados e as operações que podem ser realizadas: o cadastro de novo grupo, alteração de um grupo, a exclusão de um grupo. 3. O sistema retorna uma mensagem de sucesso. 4. O ator confirma a mensagem. Caso queira continuar com a manutenção, o caso de uso retorna ao passo 2, caso contrário, cancela a operação e o caso de uso se encerra. Fluxo Alternativo (2): cadastro a. O ator informa os dados referentes ao grupo e requisita ao sistema o cadastro ou cancela a operação, e o caso de uso se encerra.

51 49 b. O sistema verifica a validade dos dados e se o grupo já está cadastrado. Se os dados forem válidos e o grupo não tiver sido cadastrado, inclui o novo grupo; caso contrário, o sistema reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): alteração a. O ator seleciona um grupo da lista apresentada. b. O sistema habilita a opção de alteração e de remoção. c. O ator requisita a sua alteração ou cancela a operação e o caso de uso se encerra. d. O sistema exibe os dados referentes ao grupo selecionado. e. O ator altera os dados do grupo e confirma a operação ou cancela, e o caso de uso retorna ao passo 2. f. O sistema verifica a validade dos dados e se o nome do grupo já está cadastrado. Se forem válidos e não houver cadastro, altera os dados na lista de grupos, em caso contrário, o sistema reporta o fato e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): remoção a. O ator seleciona um grupo da lista apresentada. b. O sistema habilita a opção de remoção e alteração. c. O ator requisita ao sistema que a remova o grupo ou cancela a operação e o caso de uso se encerra. d. O sistema requisita a confirmação de remoção. e. O ator confirma a remoção ou cancela a operação, e o caso de uso volta ao passo 2. f. O sistema remove o grupo selecionado. Pós-condições: um grupo foi cadastrado ou removido, ou seus dados foram alterados.

52 Manter Escolaridade (CSU11) Sumário: o ator realiza a manutenção (inclusão, remoção, alteração) dos dados sobre escolaridade. Ator Primário: administrador. Pré-condições: o administrador está identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator requisita a manutenção de uma escolaridade. 2. O sistema apresenta um formulário em branco, uma lista com as escolaridades cadastradas e as operações que podem ser realizadas: cadastro, alteração, remoção. 3. O sistema retorna uma mensagem de sucesso. 4. O ator confirma a mensagem, caso queira continuar com a manutenção, o caso de uso retorna ao passo 2, ou cancela a operação e o caso de uso se encerra. Fluxo Alternativo (2): cadastro a. O ator informa os dados referentes à escolaridade e requisita ao sistema o cadastro ou cancela a operação e o caso de uso termina. b. O sistema verifica a validação dos dados e se a escolaridade já não está cadastrada. Se os dados forem válidos e a escolaridade não estiver cadastrada, inclui a nova escolaridade; caso contrário, o sistema reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): remoção a. O ator seleciona uma escolaridade da lista. b. O sistema habilita a opção de remoção. c. O ator requisita ao sistema que a remova a escolaridade ou cancela a operação, e o caso de uso se encerra.

53 51 d. O sistema requisita a confirmação de remoção. e. O ator confirma a remoção ou cancela a operação, e o caso de uso volta ao passo 2. f. O sistema remove a escolaridade selecionada. Fluxo Alternativo (2): alteração a. O ator seleciona uma escolaridade da lista. b. O sistema habilita a opção de alteração. c. O ator requisita a sua alteração ou cancela a operação, e o caso de uso se encerra. d. O sistema exibe os dados referentes à escolaridade selecionada. e. O ator altera a escolaridade e confirma a operação ou cancela a operação, e o caso de uso retorna ao passo 2. f. O sistema verifica a validade dos dados e se os novos dados já foram cadastrados, se forem válidos e não houver cadastro, altera os dados na lista de escolaridades, em caso contrario o sistema reporta o fato, e o caso de uso retorna ao passo 2. Pós-condições: uma escolaridade foi inserida ou removida, ou seus detalhes foram modificados Manter tipo de parentesco (CSU12) Sumário: o ator realiza a manutenção do tipo de parentesco (cadastro, remoção, alteração). Ator Primário: avaliador. Pré-condições: o avaliador deve estar identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator solicita a manutenção do tipo de parentesco.

54 52 2. O sistema apresenta um formulário em branco, uma lista com os tipos de parentesco cadastrados e as operações que podem ser realizadas: o cadastro de um novo tipo de parentesco, a alteração de um tipo de parentesco, a exclusão de um tipo de parentesco. 3. O sistema retorna uma mensagem de sucesso. 4. O avaliador confirma a mensagem caso queira continuar com a manutenção o caso de uso retorna ao passo 2, caso contrário, cancela a operação e o caso de uso se encerra. Fluxo Alternativo (2): cadastro a. O avaliador informa os dados referentes ao tipo de parentesco e requisita ao sistema o cadastro ou cancela a operação, e o caso de uso se encerra. b. O sistema verifica a validade dos dados e se o nome do tipo de parentesco já não está cadastrado. Se os dados forem válidos e o tipo de parentesco não estiver sido cadastrado, inclui o novo tipo de parentesco; caso contrário, o sistema reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): alteração a. O ator seleciona o tipo de parentesco na lista apresentada. b. O sistema habilita as opções de alteração e remoção. c. O ator requisita a alteração ou cancela a operação, e o caso de uso se encerra. d. O sistema exibe os dados referentes ao tipo de parentesco selecionado. e. O ator realiza as alterações desejáveis e confirma a operação, ou cancela a operação, e o caso de uso retorna ao passo 2. f. O sistema verifica a validade dos dados e se os mesmos já não foram cadastrados; se forem válidos e não houver cadastro, altera os dados na lista de tipo de parentesco, caso contrário, reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): remoção a. O ator seleciona o tipo de parentesco na lista apresentada

55 53 b. O sistema habilita as opções de remoção e alteração. c. O ator requisita ao sistema que remova o tipo de parentesco ou cancela a operação e o caso de uso se encerra. d. O sistema requisita a confirmação de remoção. e. O ator confirma a remoção ou cancela a operação e o caso de uso volta ao passo 2. f. O sistema remove o tipo de parentesco selecionado. Pós-condições: um tipo de parentesco foi cadastrado ou removido, ou seus dados foram alterados Manter Local de Aplicação (CSU13) Sumário: o ator realiza a manutenção do local de aplicação (cadastro, remoção, alteração). Ator Primário: avaliador. Pré-condições: o avaliador deve estar identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator solicita a manutenção do local de aplicação. 2. O sistema apresenta um formulário em branco, uma lista com os locais de aplicação cadastrados e as operações que podem ser realizadas: o cadastro de um novo local de aplicação, a alteração de um local de aplicação, a exclusão de um local de aplicação. 3. O sistema retorna uma mensagem de sucesso. 4. O ator confirma a mensagem caso queira continuar com a manutenção o caso de uso retorna ao passo 2, caso contrario cancela a operação, e o caso de uso se encerra. Fluxo Alternativo (2): cadastro

56 54 a. O ator informa os dados referentes ao local de aplicação e requisita ao sistema o cadastro ou cancela a operação, e o caso de uso se encerra. b. O sistema verifica a validade dos dados e se o nome do local de aplicação já não está cadastrado. Se os dados forem válidos e o local de aplicação não estiver sido cadastrado, inclui o novo local de aplicação; caso contrário, o sistema reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): alteração a. O ator seleciona o local de aplicação na lista apresentada. b. O sistema habilita as opções de alteração e remoção. c. O ator requisita a alteração ou cancela a operação, e o caso de uso se encerra. d. O sistema exibe os dados referentes ao local de aplicação selecionado. e. O ator realiza as alterações desejáveis e confirma a operação, ou cancela a operação, e o caso de uso retorna ao passo 2. f. O sistema verifica a validade dos dados e se os mesmos já não foram cadastrados. Se forem válidos e não houver cadastro, altera os dados na lista de local de aplicação, caso contrário reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): remoção a. O ator seleciona o local de aplicação na lista apresentada b. O sistema habilita as opções de remoção e alteração. c. O ator requisita ao sistema que a remova o local de aplicação ou cancela a operação, e o caso de uso se encerra. d. O sistema requisita a confirmação de remoção. e. O ator confirma a remoção ou cancela a operação, e o caso de uso volta ao passo 2. f. O sistema remove o tipo de parentesco selecionado. Pós-condições: um local de aplicação foi cadastrado ou removido, ou seus dados foram alterados.

57 Manter Avaliador (CSU14) Sumário: o ator realiza a manutenção (inclusão, remoção, alteração e consulta) dos dados de um avaliador. Ator Primário: administrador. Pré-condições: o administrador está identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator requisita a manutenção de um avaliador. 2. O sistema apresenta as operações que podem ser realizadas: cadastro, alteração, exclusão ou consulta de um avaliador. 3. O ator indica a opção a desejada: cadastro, remoção, alteração, consulta ou opta por encerrar o caso de uso. 4. O sistema retorna uma mensagem de sucesso. 5. O administrador confirma a mensagem e o caso de uso se encerra. Fluxo Alternativo (3): cadastro a. O ator requisita o cadastro de um avaliador. b. O sistema apresenta um formulário em branco para que os dados do avaliador sejam inseridos. c. O ator fornece os dados cadastrais do avaliador e confirma a operação, ou cancela a operação, e o caso de uso se encerra. d. O sistema verifica se os campos que são obrigatórios foram preenchidos. Se os obrigatórios tiverem sido inseridos o novo avaliador é cadastrado; caso contrário, o sistema reporta o fato, solicita a correção dos dados e repete a verificação. Fluxo Alternativo (3): remoção a. O ator requisita a remoção de um avaliador. b. O sistema apresenta uma lista com todos avaliadores, permitindo ao administrador selecionar o avaliador desejado.

58 56 c. O ator informa um avaliador e confirma a operação, ou decide cancelar a operação, e o caso de uso se encerra. d. O sistema exibe os dados do avaliador e solicita que o administrador confirme a remoção. e. O ator confirma que deseja remover o avaliador apresentado ou cancelar a operação, o caso de uso retorna ao passo c. Fluxo Alternativo (3): alteração a. O ator requisita a alteração de um dos avaliadores. b. O sistema apresenta uma lista com todos avaliadores, permitindo que o ator selecione o avaliador desejado. c. O ator informa um avaliador e confirma a alteração, ou cancela a operação, e o caso de uso se encerra. d. O sistema apresenta um formulário com os dados do avaliador para que o ator possa realizar as alterações que deseja. e. O ator altera um ou mais dados sobre um avaliador e requisita a sua alteração. f. O sistema verifica a validade dos dados e, se forem válidos, altera os dados do avaliador. Fluxo Alternativo (3): consulta a. O ator solicita a realização de consulta de um avaliador. b. O sistema solicita que o ator informe o nome do avaliador. c. O ator informa o nome e confirma a operação, ou cancela e o caso de uso se encerra. d. O sistema apresenta uma lista com os avaliadores que possuem o nome selecionado e. O solicita a alteração ou remoção do avaliador ou cancela, e o caso de uso se encerra.

59 57 Fluxo de exceção: nome não encontrado a. O ator informa um nome não cadastrado para consulta. b. O sistema reporta o fato e o caso de uso se encerra. Pós-condições: um avaliador foi inserido ou removido, ou seus detalhes foram modificados Manter Especialidade (CSU15) Sumário: o ator realiza a manutenção do local de aplicação (cadastro, remoção, alteração). Ator Primário: administrador. Pré-condições: o administrador deve estar identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator solicita a manutenção de uma especialidade. 2. O sistema apresenta um formulário em branco, uma lista com as especialidades cadastradas e as operações que podem ser realizadas: o cadastro de uma nova especialidade, a alteração de uma especialidade, a exclusão de uma especialidade. 3. O sistema retorna uma mensagem de sucesso. 4. O ator confirma a mensagem, caso queira continuar com a manutenção, o caso de uso retorna ao passo 2, caso contrário, cancela a operação e o caso de uso se encerra. Fluxo Alternativo (2): cadastro a. O ator informa os dados referentes à especialidade e requisita ao sistema o cadastro ou cancela a operação, e o caso de uso se encerra. b. O sistema verifica a validade dos dados e se o nome da especialidade já não está cadastrado. Se os dados forem válidos e a especialidade não estiver sido

60 58 cadastrada, inclui a nova especialidade; caso contrário, o sistema reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): alteração a. O ator seleciona a especialidade na lista apresentada. b. O sistema habilita as opções de alteração e remoção. c. O ator requisita a alteração ou cancela a operação e o caso de uso se encerra. d. O sistema exibe os dados referentes à especialidade selecionada. e. O ator realiza as alterações desejáveis e confirma a operação, ou cancela a operação, e o caso de uso retorna ao passo 2. f. O sistema verifica a validade dos dados e se os mesmos já não foram cadastrados; se forem válidos e não houver cadastro altera os dados na lista de especialidade, caso contrário reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): remoção a. O ator seleciona a especialidade na lista apresentada b. O sistema habilita as opções de remoção e alteração. c. O ator requisita ao sistema que a remova a especialidade ou cancela a operação e o caso de uso se encerra. d. O sistema requisita a confirmação de remoção. e. O ator confirma a remoção ou cancela a operação e o caso de uso volta ao passo 2. f. O sistema remove a especialidade selecionada. Pós-condições: Uma especialidade foi cadastrada ou removida, ou seus dados foram alterados.

61 Manter Religião (CSU16) Sumário: o ator realiza a manutenção do local de aplicação (cadastro, remoção, alteração). Ator Primário: administrador. Pré-condições: o administrador deve estar identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator solicita a manutenção de uma religião. 2. O sistema apresenta um formulário em branco, uma lista com as religiões cadastradas e as operações que podem ser realizadas: o cadastro de uma nova religião, a alteração de uma religião, a exclusão de uma religião. 3. O sistema retorna uma mensagem de sucesso. 4. O ator confirma a mensagem caso queira continuar com a manutenção o caso de uso retorna ao passo 2, caso contrário, cancela a operação, e o caso de uso se encerra. Fluxo Alternativo (2): cadastro a. O ator informa os dados referentes à religião e requisita ao sistema o cadastro ou cancela a operação e o caso de uso se encerra. b. O sistema verifica a validade dos dados e se o nome da religião já não está cadastrado. Se os dados forem válidos e a religião não estiver sido cadastrada, inclui a nova religião; caso contrário, o sistema reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): alteração a. O ator seleciona a religião na lista apresentada. b. O sistema habilita as opções de alteração e remoção. c. O ator requisita a alteração ou cancela a operação, e o caso de uso se encerra. d. O sistema exibe os dados referentes à religião selecionada.

62 60 e. O ator realiza as alterações desejáveis e confirma a operação, ou cancela a operação, e o caso de uso retorna ao passo 2. f. O sistema verifica a validade dos dados, e se os mesmos já não foram cadastrados, se forem válidos e não houver cadastro, altera os dados na lista de religião, caso contrário, reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): remoção a. O ator seleciona a religião na lista apresentada b. O sistema habilita as opções de remoção e alteração. c. O ator requisita ao sistema que a remova a religião ou cancela a operação, e o caso de uso se encerra. d. O sistema requisita a confirmação de remoção. e. O ator confirma a remoção ou cancela a operação e o caso de uso volta ao passo 2. f. O sistema remove a religião selecionada. Pós-condições: uma religião foi cadastrada ou removida, ou seus dados foram alterados Manter Instituições (CSU17) Sumário: o ator realiza a manutenção de uma instituição (cadastro, remoção, alteração). Ator Primário: administrador. Pré-condições: o administrador deve estar identificado pelo sistema. Fluxo Principal 1. Este caso de uso se inicia quando o ator solicita a manutenção de uma instituição. 2. O sistema apresenta um formulário em branco, uma lista com as instituições cadastradas e as operações que podem ser realizadas: o cadastro de uma nova instituição, a alteração de uma instituição, a exclusão de uma instituição.

63 61 3. O sistema retorna uma mensagem de sucesso. 4. O ator confirma a mensagem, caso queira continuar com a manutenção, o caso de uso retorna ao passo 2, caso contrário cancela a operação, e o caso de uso se encerra. Fluxo Alternativo (2): cadastro 5. a. O ator informa os dados referentes à instituição e requisita ao sistema o cadastro ou cancela a operação, e o caso de uso se encerra. 6. b. O sistema verifica a validade dos dados e se o nome da instituição já não está cadastrado. Se os dados forem válidos e a instituição não estiver sido cadastrada, inclui a nova religião; caso contrário, o sistema reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): alteração a. O ator seleciona a instituição na lista apresentada. b. O sistema habilita as opções de alteração e remoção. c. O ator requisita a alteração ou cancela a operação, e o caso de uso se encerra. d. O sistema exibe os dados referentes à instituição selecionada. e. O ator realiza as alterações desejáveis e confirma a operação, ou cancela a operação, e o caso de uso retorna ao passo 2. f. O sistema verifica a validade dos dados, e se os mesmos já não foram cadastrados, se forem validos e não houver cadastro, altera os dados da instituição, caso contrário, reporta o fato, e o caso de uso retorna ao passo 2. Fluxo Alternativo (2): remoção a. O ator seleciona a instituição na lista apresentada b. O sistema habilita as opções de remoção e alteração. c. O ator requisita ao sistema que a remova a instituição ou cancela a operação, e o caso de uso se encerra. d. O sistema requisita a confirmação de remoção.

64 62 e. O ator confirma a remoção ou cancela a operação, e o caso de uso volta ao passo 2. f. O sistema remove a instituição selecionada. Pós-condições: uma instituição foi cadastrada ou removida, ou seus dados foram alterados.

65 63 4 ESPECIFICAÇÃO DE ANÁLISE DE REQUISITOS No contexto de sistemas de software, esta é a fase em que é realizado um estudo detalhado dos requisitos levantados. Segundo [10], o termo análise corresponde a quebrar um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona. E assim, obter mais detalhes de como o sistema deve realizar suas tarefas. Alguns artefatos são gerados nesta fase, visando a esclarecer estes detalhes, a seguir são apresentados nas subseções alguns artefatos importantes ao desenvolvimento de software, aplicados ao contexto do sistema a ser desenvolvido. Sendo primeiramente apresentado na figura 7 o diagrama de como ficaram expostos os pacotes do sistema. Figura 7: Diagrama de Pacotes

66 Diagramas de classes Este diagrama fornece uma visão estrutural estática do sistema, permitindo compreender como o sistema está estruturado internamente para que as funcionalidades externamente visíveis sejam produzidas. Segundo [14] estes diagramas são importantes não só para a visualização, a especificação e a documentação de modelos estruturais, mas também para a construção de sistemas executáveis por intermédio de engenharia de produção, logo, estes são muito utilizados na modelagem orientada a objetos. A figura 8 apresenta o diagrama de classes do pacote de controle administrativo. Em seguida é apresentado na figura 9 o diagrama de classes de análise do pacote Avaliação, onde constam as classes referentes ao processo de avaliação como um todo. Figura 8: Diagrama de classes pacote controle administrativo

67 65 Figura 9: Diagrama de classes pacote avaliação 4.2 Diagrama de transição de estados Uma máquina de estados é um comportamento que especifica as sequências de estados pelos quais um objeto passa durante seu tempo de vida [14]. Um objeto muda seu estado em decorrer de algum evento interno ou externo ao sistema. Quando muda de estado, diz-se que realizou uma transição de estado. Um estado e transições de estados de um objeto constituem o seu ciclo de vida [10]. A figura 10 apresenta os estados pelos quais passa uma avaliação, seguida dos eventos que podem ocorrer resultando em sua transição de estados.

68 66 Figura 10: Diagrama transição de estados da avaliação 4.3 Diagramas de sequência Este é um diagrama que pode ser usado para mostrar a evolução de uma dada situação em determinado momento do software, mostrar uma dada colaboração entre duas ou mais classes e pode, também, ser usado para mostrar a tradução de um caso de uso desde a interação com o usuário até a finalização daquele processo [13]. Portanto, o objetivo deste diagrama é proporcionar uma visão estrutural dinâmica do sistema, ele apresenta as interações entre os objetos na ordem temporal em que as trocas de mensagem acontecem [10] para se realizar determinado caso de uso. A seguir são apresentados os diagramas de sequência dos casos de uso deste sistema, como alguns casos de uso serão apenas para permitir a manutenção da base de dados, estes não serão contemplados aqui, sendo apresentados somente os diagramas de sequência referentes à manutenção dos avaliadores e das crianças e os do processo de avaliação.

69 Diagramas de Sequência Manter Criança São apresentados nas figuras 11 a 14 os diagramas de sequência referentes ao caso de uso manter criança. Figura 11: Diagrama de sequência cadastrar criança Figura 12: Diagrama de sequência alterar criança

70 68 Figura 13: Diagrama de sequência remover criança Figura 14: Diagrama de sequência consultar criança Diagramas de Sequência Manter Composição Familiar São apresentados nas figuras 15, 16 e 17 os diagramas de sequência referentes ao caso de uso manter composição familiar.

71 69 Figura 15: Diagrama de sequência cadastrar familiar Figura 16: Diagrama de sequência alterar familiar

72 70 Figura 17: Diagrama de sequência remover familiar Diagramas de Sequência Manter Avaliação Nas figuras 18 e 19 são apresentados os diagramas de sequência referentes ao caso de uso manter avaliação Figura 18: Diagrama de Sequência Cadastra Avaliação

73 71 Figura 19: Diagrama de Sequência Remover Avaliação Diagramas de Sequência do processo de avaliação São apresentados os diagramas de sequência referentes ao processo de avaliação. A figura 20 consiste o digrama do caso de uso escolher opção em seguida na figura 21 o diagrama do caso de uso aplicar avaliação e nas figuras 22 e 23 os diagramas dos casos de uso registrar inquérito e pós-avaliação Figura 20: Diagrama de sequência escolher opção

74 72 Figura 21: Diagrama de sequência aplicar avaliação Figura 22: Diagrama de sequência registrar inquérito

75 73 Figura 23: Diagrama de sequência visualizar Pós-Avaliação Diagramas de sequência Manter Avaliador São apresentados nas figuras 24 a 27 os diagramas de sequência referentes ao caso de uso manter avaliador.

76 74 Figura 24: Diagrama de sequência cadastrar avaliador Figura 25: Diagrama de sequência alterar avaliador

77 75 Figura 26: Diagrama de sequência remover avaliador Figura 27: Diagrama de sequência consultar avaliador

78 76 5 ESPECIFICAÇÃO DE PROJETO Na fase de projeto, determina-se como o sistema irá funcionar para atender aos requisitos, de acordo com os recursos tecnológicos existentes, ou seja, o foco é pensar em uma solução computacional que atenda a necessidade dos requisitos levantados na fase de análise. Nesta etapa vários aspectos devem ser considerados pelo fato de, neste momento, ter-se uma visão ampla do sistema. Alguns exemplos de aspectos a serem levados em conta nesta fase são: a arquitetura do sistema, o padrão de interface gráfica, a linguagem de programação, o gerenciador de banco de dados entre outros. Nesta seção serão definidos os quesitos necessários ao desenvolvimento do sistema. 5.1 Tecnologias utilizadas Neste momento, apresenta-se as tecnologias que foram definidas para o desenvolvimento, ressaltando que, como se pretende fornecer o sistema gratuitamente para os profissionais que possuem interesse no assunto, assim como é realizado com o método em sua forma manual, buscou-se utilizar somente tecnologias gratuitas, possibilitando desta forma não gerar ônus para os mesmos e nem ao desenvolvimento do sistema, com a aquisição de licenças Plataforma de desenvolvimento Java Java é uma plataforma de desenvolvimento que possibilita a criação de programas da mais alta qualidade, como utilitários, jogos e aplicativos corporativos, entre muitos outros. Os programadores Java tiram proveito das ricas coleções de classes existentes nas bibliotecas de classe Java, que também são conhecidas como Java API (Interface de Programação de Aplicativos)[15]. A plataforma é constituída de um grande

79 77 número de tecnologias, cada uma provê uma porção distinta de todo o ambiente de desenvolvimento e execução de software. Das diversas tecnologias disponíveis no Java para desenvolvimento de aplicações, foi utilizada a Java SE 6, uma ferramenta que contém todo o ambiente necessário para a criação e execução de aplicações, incluindo a máquina virtual Java (JVM), o compilador Java, e várias APIs. Outro motivo que estimulou o uso desta plataforma foi o fato desta ser portável e independente, o que torna possível sua execução em qualquer ambiente que possua suporte ao Java, exigindo poucas alterações, como durante a fase de levantamento e especificação de requisitos se percebeu que poderia ocorrer a migração do sistema para outros ambientes, esta percepção foi crucial na escolha da plataforma, além do mais, Java é livre. API Java Sound Muitos programas de computador atraem a atenção do usuário com recursos de áudio. Neste sistema, busca-se atrair a atenção da criança com a execução de áudio do personagem contido na prancha, convidando-a a saber o que ele tem feito para enfrentar a hospitalização. O outro recurso necessário à aplicação é à necessidade de se gravar o processo de avaliação e escutá-lo posteriormente no momento do registro do inquérito. Para execução e captura de som foi utilizado a API Java Sound [16], sendo que esta acompanha o Java SE e por isso é considerada por alguns como a fonte do sucesso do Java para a programação musical. Esta API provê suporte para operações de áudio e MIDI com alta qualidade, tais como: captura, mixagem, gravação, sequenciamento e síntese MIDI. Em constante evolução e melhoria, pode-se destacar como características nativas da API: Suporte aos formatos de arquivos de áudio: AIFF, AU e WAV; Suporte aos formatos de arquivos de música: MIDI; Formatos de som em 8/16 bits, mono e estéreo, com taxa de amostragem de 8 a 48 hertz; Dados de áudio codificados em linear, a-law e mu-law para qualquer um dos formatos de áudio suportados;

80 78 Mixer com capacidade para mixar e renderizar mais de 64 canais de áudio digital e sons MIDI sintetizados. Foi utilizado o formato WAV, com baixa qualidade: formato de 8 bits, mono e taxa de amostragem de 8 hertz, uma vez que estes atende a necessidade de gravação do processo de avaliação. Gerando assim arquivos de áudio de menor tamanho e permitindo a persistência no banco sem muita perda de desempenho, além de economia de espaço em disco. A API Java Sound é o suporte a áudio de mais baixo nível na plataforma Java, permitindo aos programas um bom controle nas operações de som. Ela não inclui editores de som sofisticados ou ferramentas gráficas, mas é extensível o suficiente para que isso seja construído a partir dela, como uma API de baixo nível deve ser [17]. Apesar de algumas restrições, o Java Sound permite que as aplicações escritas com suas classes funcionem da mesma forma nas diversas plataformas suportadas pelo Java. API Java Help No desenvolvimento de aplicações é muito importante um sistema de ajuda que permita aos usuários tirar suas dúvidas em relação ao uso de alguma funcionalidade. No caso deste projeto, esta necessidade foi além, pelo fato de ter sido solicitado que se inserisse também uma descrição referente às técnicas de intervenção, com a sua forma de aplicação e os objetos necessários. Esta necessidade foi sanada como o uso da API Java Help[18], que consiste de um sistema de ajuda on-line que os desenvolvedores podem usar para adicionar material de apoio explicativo às suas aplicações em plataforma Java. O sistema Java Help é projeto de código aberto que inclui a fonte para a implementação de referência NetBeans IDE O NetBeans IDE é um ambiente de desenvolvimento que permite programadores escrever, compilar, depurar e implantar seus programas. É escrito em Java, mas provê suporte a qualquer linguagem de programação [19]. É um ambiente rico em recursos para aplicações Web e aplicações visuais com Swing, que é uma API Java para inter-

81 79 faces gráficas; foi utilizada para o desenvolvimento das interfaces do sistema. Alguns de seus recursos são apresentados na subseção 9. O NetBeans possui ainda o recurso auto completar avançado e permite a geração automática de arquivos javadoc em HTML, que consiste na documentação gerada para o código fonte a partir dos comentários inseridos, além de recursos que facilitam a inclusão de comentários no código JasperReport e ireport Em muitas aplicações, às vezes é necessário gerar relatórios. No processo de avaliação, dois tipos de relatórios são necessários ser gerados pelos avaliadores: o relatório de contagem por prancha, que apresenta a frequência com que as estratégias de enfrentamento foram identificadas para a prancha e o relatório de contagem por estratégia, que apresenta a frequência de estratégias para a criança. A seguir são apresentadas as ferramentas utilizadas para definir os relatórios: JasperReports - é um poderoso framework, de código fonte aberto, escrito em Java para geração de relatórios. Ele permite gerar dinamicamente relatórios em diversos formatos como: PDF, HTML, XLS, CSV e XML. O design do relatório é definido em um arquivo XML chamado jrxml, que pode ser codificado manualmente, ou projetados usando uma ferramenta auxiliar. Usando o XML, o designer pode definir textos estáticos, imagens, linhas e formas geométricas, como retângulos e elipses, e suas localizações dentro do relatório. Além de definir os campos que serão preenchidos dinamicamente a partir da base de dados. O arquivo XML é compilado, gerando um arquivo.jasper, onde as expressões Java existentes dentro do XML serão verificadas em tempo de compilação. Depois de compilado, torna-se simples a chamada do relatório pela aplicação, permitindo inclusive a passagem de parâmetro[20]. ireport é um programa que permite o desenvolvedor criar os mais complexos relatórios no formato do JasperReport através de uma interface gráfica intuitiva. Mesmo sabendo que o ireport desenvolve no formato XML usado pelo JasperReport, que é simples de ser manipulado. A vantagem da ferramenta é que para usuários iniciantes ela supre as necessidades, tornando possível que seja evitado realizar modificações no código. E para usuários experientes, diminui o tempo na criação de relatórios mais complexos. Outra vantagem é,

82 80 já que foi definido o netbeans como IDE de desenvolvimento, o ireport é possível de ser integrado à ferramenta tornando possível ter as duas ferramentas no mesmo ambiente, o que facilita o desenvolvimento como um todo [21] MySQL MySQL é um sistema de gerenciamento de bancos de dados relacional que utiliza a linguagem SQL (Structured Query Language) como interface [22]. Entre as várias vantagens oferecidas por este, pode-se citar: Excelente desempenho e estabilidade; Pouco exigente quanto a recursos de hardware; Compatibilidade (existem drivers ODBC, JDBC e.net e módulos de interface para diversas linguagens de programação, como Delphi, Java, C/C++, C#, Visual Basic, Python, Perl, PHP, ASP e Ruby); 5.2 Arquitetura do sistema Uma questão a ser levada em consideração na fase de projeto é a forma como o sistema pode ser decomposto em seus diversos subsistemas. Dá-se o nome de arquitetura à forma como o sistema está disposto física e logicamente [10]. A figura 28 ilustra como ficou definida a arquitetura lógica do sistema, em que, a partir do diagrama de pacotes, pode-se observar como sistema está agrupado logicamente, mostrando as dependências entre esses grupos. Sendo que se seguiu a mesma disposição exposta na especificação de análise, onde o pacote de controle administrativo contém as entidades relacionadas às questões de cadastro no sistema como cadastro de avaliadores e crianças, enquanto no pacote avaliação, constam as entidades voltadas ao processo de avaliação como um todo. Sendo inserido um pacote extra, denominado utilitários, que contém classes utilizadas pelos dois subsistemas.

83 81 Figura 28: Arquitetura Lógica 5.3 Arquitetura em camadas Os subsistemas apresentados na figura 28 foram ainda decompostos em novos pacotes seguindo o padrão de projeto Modelo-Visão-Controle-Estendido (MVCE), que tem como objetivo criar uma independência e divisão de responsabilidades entre as partes que envolvem o sistema, dada a definição de que a linguagem de programação a ser utilizada é Java, torna-se fácil a migração para outras plataformas que possuem suporte à mesma. O sistema é disposto em camadas. Na camada de Modelo, encontram-se as classes referentes ao domínio do problema a ser resolvido; na camada de Visão, encontram-se as classes referentes à interface gráfica do sistema; na camada de Controle, encontram-se classes que fazem o controle do sistema e suas regras de negócio, e, por fim a camada Estendida, responsável pela persistência dos dados no mecanismo de armazenamento. A figura 29 ilustra a disposição dos pacotes definidos para o subsistema de controle administrativo, a figura 30, o subsistema avaliação, sendo que nesta foi adicionado um pacote extra contendo os relatórios da aplicação.

84 82 Figura 29: Divisão em camadas do subsistema de Controle Administrativo Figura 30: Divisão em camadas do subsistema Avaliação 5.4 Diagramas de classes revisados Na fase de análise, quando criados os diagramas de classes, considera-se uma classe de visão e uma classe de controle para todo o sistema, logo, nesta etapa foi necessário definir também as classes referentes às demais camadas, e o modelo de classes de analise passou por uma revisão mais apurada, sendo agora considerado modelo de classes de projeto. A seguir são apresentados os diagramas de classes de

85 83 acordo com o pacote a que pertence e seu respectivo subsistema Pacote modelo A figura 31 mostra o diagrama de classes do subsistema controle administrativo e a na figura 32 encontra-se o diagrama do subsistema avaliação. Figura 31: Diagrama de Classes Modelo Controle Administrativo

86 Figura 32: Diagrama de Classes Modelo Avaliação 84

87 Pacote controle Até o presente momento, não se havia pensado nas classes de controle do sistema. As figuras 33 e 34 ilustram os diagramas definidos para este pacote para o subsistema controle administrativo e avaliação. Figura 33: Diagrama de Classes Controle Administrativo

88 86 Figura 34: Diagrama de Classes Controle Avaliação Pacote Dao Os diagramas aqui apresentados são referentes à camada de persistência dos subsistemas, sendo o diagrama da figura 35 referente ao subsistema controle administrativo e a figura 36 o subsistema avaliação.

89 Figura 35: Diagrama de Classes Dao Administrativo 87

90 88 Figura 36: Diagrama de Classes Dao Avaliação 5.5 Diagrama de sequência revisado Assim como na fase de análise, o diagrama de sequência da fase de projeto tem por objetivo proporcionar uma visão estrutural dinâmica do sistema, apresentando as interações entre os objetos na ordem temporal em que as trocas de mensagem acontecem. No entanto, agora devem ser levados em consideração vários novos aspectos, como a divisão em camadas do sistema, o papel que cada classe desempenha e os tipos de mensagem que são trocadas. Sendo assim, uma vez defino o padrão de projeto a ser seguido e apresentado os diagramas das demais camadas do sistema, são apresentados os diagramas de sequência provenientes da fase de análise, porém agora revisados levando em consideração os aspectos expostos.

91 Diagramas de Sequência Manter Criança São apresentados nas figuras 37 a 40 os diagramas de sequência revisados referentes ao caso de uso manter criança. Figura 37: Diagrama de sequência cadastrar criança

92 Figura 38: Diagrama de sequência alterar criança 90

93 Figura 39: Diagrama de sequência consultar criança 91

94 92 Figura 40: Diagrama de sequência remover criança Diagramas de Sequência Manter Composição Familiar São apresentados nas figuras 41, 42 e 43 os diagramas de sequência revisado referentes ao caso de uso manter composição familiar.

95 93 Figura 41: Diagrama de sequência cadastrar familiar Figura 42: Diagrama de sequência alterar familiar

96 94 Figura 43: Diagrama de sequência remover familiar Diagramas de Sequência do processo de avaliação São apresentados os diagramas de sequência revisado referentes ao processo de avaliação. A figura 44 consiste o digrama do caso de uso cadastrar avaliação em seguida na figura 45 o diagrama do caso de uso aplicar avaliação e nas figuras 46, 47 e 48 os diagramas dos casos de uso escolher opção, registrar inquérito e pós-avaliação respectivamente.

97 Figura 44: Diagrama de sequência cadastrar avaliação 95

98 Figura 45: Diagrama de sequência aplicar avaliação 96

99 Figura 46: Diagrama de sequência escolher opção 97

100 Figura 47: Diagrama de sequência registrar inquérito 98

101 99 Figura 48: Diagrama de sequência visualizar Pós-Avaliação Diagramas de sequência Manter Avaliador São apresentados nas figuras 49 a 52 os diagramas de sequência revisado referentes ao caso de uso manter avaliador.

102 100 Figura 49: Diagrama de sequência cadastrar avaliador Figura 50: Diagrama de sequência alterar avaliador

103 101 Figura 51: Diagrama de sequência consultar avaliador Figura 52: Diagrama de sequência remover avaliador

104 Diagrama de implantação O diagrama de implantação é um tipo de diagrama empregado para a modelagem dos aspectos físicos de um sistema orientado a objetos e são empregados para a modelagem estática da implantação de um sistema [13]. A figura 53 mostra o diagrama de implantação do sistema. Figura 53: Modelo do banco de dados 5.7 Modelagem do banco de dados Quando se opta por utilizar como mecanismo de armazenamento persistente um sistema gerenciador de banco de dados relacional em um sistema que segue uma abordagem orientada a objetos, há a necessidade de se realizar o mapeamento dos objetos para as tabelas do banco de dados. Para a modelagem do banco de dados, seguiu-se uma abordagem conhecida como mapeamento objeto-relacional (ORM), uma técnica de desenvolvimento em que as tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes[10]. Na figura 54 é apresentado o modelo do banco de dados desenvolvido.

105 103 Figura 54: Modelo do banco de dados 5.8 Diagrama de navegabilidade No diagrama de navegabilidade, é definida a estrutura de navegação propriamente dita. A figura 55 apresenta o diagrama de navegabilidade do sistema.