protÓtipo de sistema para apoio À avaliaÇÃo...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
PROTÓTIPO DE SISTEMA PARA APOIO À AVALIAÇÃO
PSICOPEDAGÓGICA CLÍNICA
SABRINA ROSENI CABRAL DA SILVA
BLUMENAU
2015
2015/2-19
SABRINA ROSENI CABRAL DA SILVA
PROTÓTIPO DE SISTEMA PARA APOIO À AVALIAÇÃO
PSICOPEDAGÓGICA CLÍNICA
Trabalho de Conclusão de Curso apresentado
ao curso de graduação em Sistemas de
Informação do Centro de Ciências Exatas e
Naturais da Universidade Regional de
Blumenau como requisito parcial para a
obtenção do grau de Bacharel em Sistemas de
Informação.
Prof. Roberto Heinzle, Doutor - Orientador
BLUMENAU
2015
2015/2-19
PROTÓTIPO DE SISTEMA PARA APOIO À AVALIAÇÃO
PSICOPEDAGÓGICA CLÍNICA
Por
SABRINA ROSENI CABRAL DA SILVA
Trabalho de Conclusão de Curso aprovado
para obtenção dos créditos na disciplina de
Trabalho de Conclusão de Curso II pela banca
examinadora formada por:
______________________________________________________
Presidente: Prof. Roberto Heinzle, Doutor – Orientador, FURB
______________________________________________________
Membro: Prof. Dalton Solano dos Reis, Mestre – FURB
______________________________________________________
Membro: Profª. Joyce Martins, Mestre - FURB
Blumenau, 07 de dezembro de 2015
Dedico este trabalho a minha mãe, por todo o
amor, atenção e por minha criação, e aos que,
apesar de não terem alcançado seu objetivo,
estão mais perto que ontem.
AGRADECIMENTOS
A Deus, por ter me privilegiado com tantas bênçãos durante toda a minha trajetória.
A Jurema Roseni Cabral, como mãe e psicopedagoga, que inspirou este trabalho e é
responsável por quem sou e por tudo que conquistei.
Às psicopedagogas Marli Bernardo da Costa, da Clínica Somater, e Jocimara Kostetze,
do Espaço Estruturar, pelas sugestões nas etapas de desenvolvimento e avaliação do sistema.
A meu orientador, Roberto Heinzle, pela confiança e pelo despertar da ideia deste
trabalho em uma disciplina do curso.
Aos amigos que enviaram energias positivas para a conclusão deste.
Aos que não acreditaram que esta etapa chegaria, como inspiração.
Acho que a grande coisa neste mundo não é
tanto onde estamos, mas para qual direção nos
movemos: Para alcançar a porta do céu,
precisamos às vezes navegar com o vento e às
vezes contra ele, mas precisamos navegar, e
não ficar à deriva, nem ancorar.
Oliver Wendell Holmes Sr.
RESUMO
A psicopedagogia é uma área de estudo que vem crescendo e despertando o interesse de
muitos profissionais nos últimos anos. A maioria destes profissionais realiza o controle dos
pacientes e atendimentos de forma manual, dispendendo tempo e espaço desnecessários para
o armazenamento e organização de documentos que, isolados, não oferecem informações para
uma avaliação psicopedagógica precisa. O objetivo do presente trabalho é apresentar um
protótipo de sistema que auxilie o psicopedagogo clínico na avaliação de pacientes com
dificuldades de aprendizagem e em fase de alfabetização. O protótipo possibilita o registro de
pacientes, contratos e planejamentos, além de informatizar a entrevista de anamnese com os
pais e calcular a modalidade de aprendizagem identificada na Entrevista Operativa Centrada
na Aprendizagem (EOCA). Também foram informatizados os testes de lateralidade e de
compreensão da palavra escrita. O protótipo foi implementado na linguagem Java voltada
para web com a biblioteca Primefaces, utilizando Hibernate para persistência de dados. O
resultado da EOCA e do teste de lateralidade são obtidos através de regras de produção,
implementadas com o uso da ferramenta Drools. Por meio da avaliação de três
psicopedagogas foi identificado que o protótipo atendeu os objetivos propostos e informatizou
76,6% de todos os processos de atendimento psicopedagógico realizados atualmente de forma
manual. Diante disto, neste trabalho são apresentadas sugestões de ampliação das
funcionalidades voltadas à avaliação psicopedagógica visando total abrangência dos processos
manuais.
Palavras-chave: Psicopedagogia. Avaliação. Dificuldade de aprendizagem.
ABSTRACT
The psychopedagogy is an area of study that is growing and awakening the interest of many
professionals in the last years. The majority of these professionals perform the control of the
patients and attendances manually, spending needless time and space for the storage and
organization of documents that, isolated, don’t offer informations for an accurate
psychopedagogyc evaluation. The objective of the present study is to show a prototype of a
system that helps the clinic psychopedagogist in the evaluation of patients with learning
difficulties and in literacy phase. The prototype allows the register of patients, contracts and
plannings, besides of computerize the anamnesis interview with the parents and calculate the
learning modality identified in the Operative Interview Focused on Learning (OIFL). Also
were computerized the tests of laterality and of understanding of the written word. The
prototype was implemented in Java language web based with the Primefaces library, using
Hibernate for data persistence. The result of the OIFL and the laterality test are obtained
through production rules, implemented with the use of the Drools tool. By means of the
evaluation of three psychopedagogists was identified that the prototype attended the proposed
objectives and computerized 76,6% of all the processes of psychopedagogyc attendance
realized manually. In light of this, in this study are presented suggestions of extensions of the
functionalities focused to the psychopedagogyc evaluation aiming total comprehensiveness of
the manual processes.
Key-words: Psychopedagogy. Evaluation. Learning difficulty.
LISTA DE FIGURAS
Figura 1 – Interação entre os contextos no processo de avaliação psicopedagógica ............... 22
Figura 2 – Agentes envolvidos em um projeto de SE .............................................................. 26
Figura 3 – Relação entre os componentes de um sistema especialista ..................................... 27
Figura 4 – Exemplo de encadeamento de regras de produção ................................................. 29
Figura 5 – Tela inicial do aplicativo Hippocrates .................................................................... 32
Figura 6 – Tela fase Ajudando os animais do Pré-d1scalc ....................................................... 33
Figura 7 – Tela da fase Maior ou Menor do Pré-d1scalc ......................................................... 34
Figura 8 – Exemplo de jogo implementado no ambiente Roseta ............................................. 35
Figura 9 – Tela inicial do aplicativo X-Dyslex ........................................................................ 36
Figura 10 - Casos de uso de manutenção de registros .............................................................. 43
Figura 11 – Casos de uso referentes à avaliação do paciente ................................................... 44
Figura 12 – Casos de uso referentes a controle de acesso ........................................................ 45
Figura 13 – Diagrama de pacotes do protótipo ........................................................................ 46
Figura 14 – Diagrama de classes do protótipo ......................................................................... 47
Figura 15 – Especificação da classe GenericDAO ................................................................... 49
Figura 16 – Especificação da classe PlanejamentoDAO .......................................................... 49
Figura 17 – Especificação da classe PlanejamentoFacade ............................................. 50
Figura 18 – Especificação da classe LoginBean ................................................................... 51
Figura 19 – Diagrama de classes do pacote util ................................................................... 52
Figura 20 – Fluxo de utilização do protótipo ........................................................................... 53
Figura 21 – Diagrama de atividades do protótipo .................................................................... 54
Figura 22 - Tela inicial do protótipo ......................................................................................... 64
Figura 23 – Link para edição do cadastro de psicopedagogo ................................................... 65
Figura 24 – Formulário de edição de cadastro de psicopedagogo ............................................ 66
Figura 25 - Tela de consulta de pacientes................................................................................. 66
Figura 26 - Tela de consulta de contratos ................................................................................. 66
Figura 27 – Tela de edição de contrato..................................................................................... 67
Figura 28 – Documento exportado pelo protótipo na funcionalidade Baixar docx .................. 68
Figura 29 – Tela de edição de cadastro de paciente e registro de avaliação ............................ 69
Figura 30 – Tela de seleção de planejamento para registro de atendimento ............................ 70
Figura 31 – Tela de registro de anamnese – Aba Concepção ................................................... 71
Figura 32 – Tela de registro de EOCA ..................................................................................... 72
Figura 33 – Tela de realização de teste de lateralidade ............................................................ 73
Figura 34 – Quadro do teste de compreensão da palavra escrita.............................................. 74
Figura 35 – Relatório de avaliação de paciente – Histórico de atendimentos .......................... 74
Figura 36 – Relatório de avaliação de paciente ........................................................................ 75
Figura 37 – Tela de registro de anamnese – Aba Sono .......................................................... 102
Figura 38 – Tela de registro de anamnese – Aba Alimentação .............................................. 102
Figura 39 – Tela de registro de anamnese – Aba Desenvolvimento/Evolução ...................... 103
Figura 40 – Tela de registro de anamnese – Aba Escolaridade .............................................. 103
Figura 41 – Tela de registro de anamnese – Aba Rotina ........................................................ 104
Figura 42 – Tela de registro de anamnese – Aba Histórico clínico ........................................ 104
Figura 43 – Tela de registro de anamnese – Aba Família ...................................................... 104
LISTA DE QUADROS
Quadro 1 – Exemplo de regra de produção para diagnóstico de gripe ..................................... 31
Quadro 2 – Relação entre sintomas e doenças do Hippocrates ................................................ 31
Quadro 3 - Indicadores de pontuação final do X-Dyslex ......................................................... 37
Quadro 4- Características dos trabalhos relacionados .............................................................. 38
Quadro 5 - Lista de requisitos funcionais do protótipo ............................................................ 41
Quadro 6 - Lista de requisitos não funcionais do protótipo ..................................................... 42
Quadro 7 – Trecho de implementação da classe Lateralidade ........................................ 56
Quadro 8 – Trecho de implementação da classe Lateralidade ........................................ 57
Quadro 9 – Implementação da classe LateralidadeEnum ................................................ 57
Quadro 10 – Implementação do arquivo commonLayout.xhtml ...................................... 58
Quadro 11 – Implementação da página recurso.xhtml .................................................... 58
Quadro 12 - Implementação da ordem de apresentação das figuras no teste de compreensão da
palavra escrita ........................................................................................................ 59
Quadro 13 – Implementação da apresentação das figuras no teste de compreensão da palavra
escrita ..................................................................................................................... 60
Quadro 14 – Implementação dos métodos findAll e findById da classe RecursoDAO
............................................................................................................................... 60
Quadro 15 – Implementação dos métodos findAll e findById da classe
RecursoFacade ................................................................................................ 61
Quadro 16 – Implementação do método calcularHiperacomodativo da classe
DroolsUtils ..................................................................................................... 61
Quadro 17 – Implementação do método de cálculo de lateralidade dominante ....................... 62
Quadro 18 – Acionamento das regras de produção do teste de lateralidade ............................ 63
Quadro 19 – Trecho das regras de produção do teste de lateralidade ...................................... 63
Quadro 20 – Trecho das regras de produção do cálculo de resultado da EOCA ..................... 63
Quadro 21 – Comparativo entre o protótipo desenvolvido e seus trabalhos correlatos ........... 80
Quadro 22 - Detalhamento do caso de uso UC01 - Efetuar login .............................. 88
Quadro 23 - Detalhamento do caso de uso UC02 – Manter usuários ......................... 88
Quadro 24 - Detalhamento do caso de uso UC03 - Manter pacientes ....................... 89
Quadro 25 - Detalhamento do caso de uso UC04 - Manter planejamentos ............. 90
Quadro 26 - Detalhamento do caso de uso UC05 - Manter Atendimentos ................. 91
Quadro 27 - Detalhamento do caso de uso UC06 - Manter Atividades .................... 92
Quadro 28 - Detalhamento do caso de uso UC07 - Manter Recursos ......................... 93
Quadro 29 - Detalhamento do caso de uso UC08 - Realizar teste de
lateralidade .................................................................................................. 94
Quadro 30 - Detalhamento do caso de uso UC09 – Visualizar relatório de
avaliação .......................................................................................................... 95
Quadro 31 – Detalhamento do caso de uso UC10 - Realizar anamnese .................... 95
Quadro 32 - Detalhamento do caso de uso UC11 - Realizar EOCA .............................. 96
Quadro 33 - Detalhamento do caso de uso UC12 – Manter familiares .................... 97
Quadro 34 - Detalhamento do caso de uso UC13 – Manter contratos ....................... 98
Quadro 35 - Detalhamento do caso de uso UC14 – Exportar contrato para docx
............................................................................................................................... 98
Quadro 36 - Detalhamento do caso de uso UC15 – Editar cadastro de
psicopedagogo ................................................................................................ 99
Quadro 37 - Detalhamento do caso de uso UC16 – Realizar teste de
compreensão da palavra escrita ..................................................... 100
Quadro 38 – Questionário de avaliação do protótipo ............................................................. 101
LISTA DE TABELAS
Tabela 1 - Porcentagem de atividades realizadas hoje manualmente compreendidas pelo
protótipo ................................................................................................................. 77
LISTA DE ABREVIATURAS E SIGLAS
ABPp - Associação Brasileira de Psicopedagogia
API – Application Programming Interface
CSS - Cascading Style Sheets
EOCA - Entrevista Operativa Centrada na Aprendizagem
XHTML - eXtensible Hypertext Markup Language
JEOPS - Java Embedded Object Production System
JPA - Java Persistence API
JSF - Java Server Faces
HTML - HyperText Markup Language
MVC - Model View Controller
REST - Representational State Transfer
RF - Requisito Funcional
RNF - Requisito Não Funcional
SE - Sistema Especialista
SGBD – Sistema Gerenciador de Banco de Dados
TDE – Teste de Desempenho Escolar
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 17
1.1 OBJETIVOS ...................................................................................................................... 18
1.2 ESTRUTURA.................................................................................................................... 18
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 19
2.1 PSICOPEDAGOGIA ........................................................................................................ 19
2.1.1 Áreas de atuação ............................................................................................................. 19
2.1.2 Psicopedagogia clínica .................................................................................................... 20
2.2 DIFICULDADES DE APRENDIZAGEM ....................................................................... 21
2.2.1 Processo de diagnóstico .................................................................................................. 22
2.2.2 Instrumentos de avaliação psicopedagógica ................................................................... 23
2.3 SISTEMAS ESPECIALISTAS ......................................................................................... 25
2.3.1 Arquitetura ...................................................................................................................... 27
2.3.2 Representação do conhecimento ..................................................................................... 28
2.3.2.1 Regras de produção ....................................................................................................... 28
2.3.3 JBoss Drools ................................................................................................................... 30
2.4 TRABALHOS CORRELATOS ........................................................................................ 31
2.4.1 Hippocrates ..................................................................................................................... 31
2.4.2 Pré-d1scalc ...................................................................................................................... 32
2.4.3 Roseta .............................................................................................................................. 34
2.4.4 X-Dyslex ......................................................................................................................... 36
2.4.5 Comparação entre os trabalhos correlatos....................................................................... 37
3 DESENVOLVIMENTO DO PROTÓTIPO .................................................................... 40
3.1 PRINCIPAIS REQUISITOS DO PROBLEMA A SER TRABALHADO ....................... 40
3.2 ESPECIFICAÇÃO ............................................................................................................ 42
3.2.1 Diagrama de casos de uso ............................................................................................... 42
3.2.2 Diagrama de classes ........................................................................................................ 45
3.2.2.1 Pacote entity ............................................................................................................ 46
3.2.2.2 Pacotes dao .................................................................................................................. 48
3.2.2.3 Pacote facade ............................................................................................................ 50
3.2.2.4 Pacote bean ................................................................................................................. 50
3.2.2.5 Pacote util ................................................................................................................. 51
3.2.2.6 Pacote rules ............................................................................................................... 53
3.2.3 Diagrama de atividades ................................................................................................... 53
3.3 IMPLEMENTAÇÃO ........................................................................................................ 54
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 55
3.3.2 Etapas do desenvolvimento ............................................................................................. 55
3.3.2.1 Implementação do objeto Model ................................................................................. 56
3.3.2.2 Implementação do objeto View ................................................................................... 57
3.3.2.3 Implementação do objeto Controller ..................................................................... 60
3.3.2.4 Implementação do pacote util ................................................................................... 61
3.3.2.5 Implementação das regras de produção ........................................................................ 62
3.3.3 Operacionalidade da implementação .............................................................................. 64
3.3.3.1 Tela inicial do protótipo ................................................................................................ 64
3.3.3.2 Edição de cadastro de psicopedagogo .......................................................................... 65
3.3.3.3 Cadastro de contratos .................................................................................................... 66
3.3.3.4 Registro de planejamentos ............................................................................................ 68
3.3.3.5 Registro de atendimentos .............................................................................................. 69
3.3.3.6 Entrevistas e testes ........................................................................................................ 70
3.3.3.6.1 Entrevista de anamnese ............................................................................................ 70
3.3.3.6.2 EOCA ....................................................................................................................... 71
3.3.3.6.3 Teste de lateralidade ................................................................................................. 72
3.3.3.6.4 Teste de compreensão da palavra escrita ................................................................. 73
3.3.3.7 Relatório de avaliação de paciente................................................................................ 74
3.4 RESULTADOS E DISCUSSÕES ..................................................................................... 75
3.4.1 Avaliação do protótipo .................................................................................................... 76
3.4.2 Sugestões obtidas ............................................................................................................ 78
3.4.3 Dificuldades encontradas ................................................................................................ 79
3.4.4 Comparativo entre o protótipo e os trabalhos correlatos ................................................ 79
4 CONCLUSÕES .................................................................................................................. 82
4.1 EXTENSÕES .................................................................................................................... 82
17
1 INTRODUÇÃO
Nos dias atuais, percebe-se que durante o processo de aprendizagem humana podem
surgir dificuldades que paralisam os alunos, gerando uma rotulação por parte da família,
professores e colegas (BARROS, 2009). Segundo Maluf (2013), “esses problemas devem-se a
diferentes fatores isolados ou associados entre si, e somente a avaliação e a intervenção
precoce das dificuldades podem levar ao sucesso na aprendizagem escolar.” De acordo com
Santos (2013):
Todo [...] ser humano apresenta algum tipo de limitação em sua vida e possuem
habilidades diferentes que são aperfeiçoadas de acordo com desenvolvimento e a
prática da mesma. Porém, algumas pessoas não conseguem desenvolver algumas
habilidades cognitivas, na qual surgem as dificuldades de aprendizagem.
Atualmente é possível encontrar muitos alunos em sala de aula com estas dificuldades
que impedem a absorção do conhecimento. Desta forma, é papel dos profissionais do âmbito
escolar e da própria família identificar estes pontos, considerando a necessidade de
encaminhamento a um profissional especializado. À vista disso, Barros (2009) afirma que “é
importante que todos os envolvidos no processo educativo estejam atentos a essas
dificuldades, observando se são momentâneas ou se persistem há algum tempo”.
A psicopedagogia é o campo de conhecimento que trata os problemas de aprendizagem
utilizando diversos recursos que possibilitam estudar o processo de aprendizagem humana e
suas variações, para que os efeitos produzidos por esta dificuldade no contexto escolar e
familiar sejam reduzidos (MORAES, 2010, p.2). Esta área de estudo contempla
conhecimentos oriundos da pedagogia e da psicologia e, através da “escuta” precisa dos
sintomas do paciente, busca o motivo do não aprendizado de forma lúdica, desenvolvendo
suas estruturas de pensamento através dos estímulos do ambiente (CHAMAT, 2004, p. 17).
Hoje um psicopedagogo utiliza, pelo menos, 4 horas e cerca de 10 páginas de texto
apenas para a realização da entrevista de anamnese com os responsáveis do paciente, além de
2 horas para organização de relatórios e cerca de 6 horas para elaboração de atividades
(SANTOS, 2012). Diante deste cenário e da oportunidade de aprofundamento neste tema de
forma colaborativa, foi desenvolvido um protótipo que auxilia o psicopedagogo na avaliação
dos pacientes, automatizando alguns procedimentos como cadastros e questionários utilizados
no atendimento de pacientes com dificuldades de aprendizagem.
O objetivo do trabalho é facilitar o planejamento da atuação do profissional para com o
paciente, permitindo ao mesmo maior dedicação à etapa principal do processo: a investigação
do problema.
18
1.1 OBJETIVOS
O objetivo geral deste trabalho é o desenvolvimento de um protótipo de um sistema
especialista para auxílio a psicopedagogos clínicos na avaliação de pacientes em fase de
alfabetização e com dificuldades de aprendizagem.
Os objetivos específicos do trabalho são:
a) coletar as informações pertinentes ao domínio psicopedagógico junto a um
especialista, com base nos instrumentos de avaliação utilizados, tais como
Entrevista Operativa Centrada na Aprendizagem (EOCA), anamnese, teste de
lateralidade e teste de compreensão da palavra escrita;
b) auxiliar o psicopedagogo a reduzir a preocupação com registros manuais e utilizar
melhor seu tempo de atendimento;
c) disponibilizar informações que auxiliem o psicopedagogo na avaliação de
pacientes.
1.2 ESTRUTURA
O presente trabalho está dividido em quatro capítulos. O primeiro contém a introdução
e os objetivos propostos. No segundo capítulo consta a fundamentação teórica, introduzindo o
conceito de psicopedagogia, suas áreas de atuação e os instrumentos de avaliação utilizados
pelos profissionais, além de discorrer sobre os trabalhos correlatos encontrados.
O terceiro capítulo refere-se ao desenvolvimento do protótipo, contendo a descrição
das ferramentas utilizadas, classes, requisitos e casos de uso. Neste capítulo também são
descritos os detalhes da implementação e os resultados alcançados.
O último capítulo aponta as conclusões obtidas com o trabalho e expõe as sugestões de
trabalhos futuros na visão da autora.
19
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo está organizado em três seções: a seção 2.1 visa apresentar o conceito de
psicopedagogia, detalhando a área clínica, bem como os principais instrumentos de avaliação
utilizados pelos profissionais; a seção 2.2 destina-se à definição de sistemas especialistas e
sua arquitetura, além da conceituação da representação do conhecimento e de regras de
produção; ao final, a seção 2.3 apresenta os trabalhos correlatos ao protótipo desenvolvido.
2.1 PSICOPEDAGOGIA
Segundo Acampora (2013, p. 17), “a psicopedagogia estuda o processo de
aprendizagem e suas dificuldades, tendo, portanto, um caráter preventivo e terapêutico.”
Verifica-se que a psicopedagogia é responsável por atuar juntamente à família e à escola,
observando comportamentos e identificando dificuldades, de forma a trabalhar a autoestima e
possibilitar ao sujeito que se desenvolva e sinta-se seguro. Ao compreender e aceitar suas
próprias limitações, este aprende a conviver com elas mostrando sua capacidade de superá-
las. Igea (2005, p.29) explica que:
A tarefa do psicopedagogo, portanto, deverá desenvolver ao máximo as capacidades
e habilidades em que cada uma dessas crianças e desses jovens podem se sentir mais
competentes. Deverá igualmente procurar que se sintam fortes do ponto de vista
psicológico.
Percebe-se que a psicopedagogia apresenta um papel importante no âmbito escolar, de
forma que os profissionais deste meio devem estar atentos ao comportamento dos alunos,
identificando previamente possíveis variações de aprendizagem. Vitorino (2000) ressalta que
“o profissional da psicopedagogia detém um conhecimento científico específico oriundo da
articulação de várias áreas envolvidas nos processos e caminhos do aprender”.
É possível perceber a importância do papel do psicopedagogo nos mais diversos
contextos, de modo que Gonçalves (2007, p.40) confirma que “atualmente, os psicopedagogos
estão expandindo seu olhar e seu campo de atuação. Eles estão presentes onde se faz
necessário aprender a aprender, nas mais diferentes instituições, como, por exemplo, empresas
ou hospitais”. Neste sentido, Acampora (2013, p. 19) esclarece que “o psicopedagogo é o
profissional preparado para atender crianças, adolescentes ou adultos com problemas de
aprendizagem, atuando na sua prevenção, diagnóstico e tratamento clínico ou institucional”.
2.1.1 Áreas de atuação
A Associação Brasileira de Psicopedagogia (ABPp) (2011) transcorre no artigo 1º,
parágrafo 2º do Código de Ética do Psicopedagogo: “A intervenção psicopedagógica na
20
Educação e na Saúde se dá em diferentes âmbitos da aprendizagem, considerando o caráter
indissociável entre o institucional e o clínico”. O psicopedagogo institucional trabalha em
escolas, atuando com as condições de ensino e aprendizagem. Nas instituições o profissional
atua em conjunto com o corpo docente para auxiliar os alunos com dificuldades de
aprendizagem, promovendo um período lúdico com os indivíduos para que estes se reinsiram
no âmbito escolar e social considerando e aceitando suas possibilidades (MARICATO, 2013).
Quando a dificuldade é causada por fatores socioeducativos, os profissionais de
educação e saúde presentes no ambiente escolar podem intervir, porém, em hipóteses de
histórico pessoal e/ou familiar, é necessário um diagnóstico com olhares clínicos
(AZEVEDO, 2014). Em relação à prática clínica, Gonçalves (2007, p.34) afirma que:
tem-se transformado em campo de estudos para investigadores interessados no
processo de construção do conhecimento e nas dificuldades que se apresentam nessa
construção. Como prática preventiva, busca construir uma relação saudável com o
conhecimento, de modo a facilitar a sua construção.
A psicopedagogia clínica disponibiliza de instrumentos e técnicas específicas que
podem ser selecionadas pelo profissional para cada atendimento, conforme a necessidade do
paciente. Diante deste contexto, o presente trabalho aborda mais profundamente a área clínica
da psicopedagogia.
2.1.2 Psicopedagogia clínica
O psicopedagogo clínico trabalha em consultório e atua em parceria com outros
profissionais, como pediatra, neuropediatra, fonoaudiólogo, psicólogo, psicomotricista, dentre
outros, visando tratar dificuldades de aprendizagem apresentadas pelo paciente. Nesta área, o
profissional atua em uma linha terapêutica, de forma a diagnosticar, desenvolver técnicas
remediativas e orientar familiares e professores, tornando seu trabalho integrado e não
individual (MARICATO, 2013).
O encaminhamento a um psicopedagogo clínico pode ser realizado pela escola ou por
iniciativa dos próprios pais, ao perceberem alterações na aprendizagem do indivíduo. O
paciente também pode ser encaminhado por outro profissional e apresentar ao profissional um
laudo que define algum transtorno. Neste caso, o paciente já foi levado a outro profissional
que determinou o laudo e sugeriu a consulta a um psicopedagogo para efetuar a intervenção.
Diante disso, o atendimento psicopedagógico visa diminuir os impactos destas dificuldades no
âmbito social e escolar do paciente.
21
No processo de alfabetização, a intervenção do psicopedagogo clínico é realizada
através do emprego de jogos e atividades voltadas para as dificuldades que o indivíduo
apresenta. No trabalho psicopedagógico clínico, Cipriano (2011) afirma que:
o psicopedagogo busca não só compreender o porquê de o sujeito não aprender
algumas coisas, mas o que ele pode aprender e como. A busca desse conhecimento
inicia-se no processo diagnóstico, momento em que a ênfase é a leitura da realidade
daquele sujeito, para então proceder à intervenção, que é o próprio tratamento ou o
encaminhamento.
Este profissional, de acordo com Vilana (2008, p. 70), “estabelecerá, mediante o
contrato terapêutico, as condições econômicas, a duração, a periodicidade das sessões e as
responsabilidades que cada um deve assumir”. Após o diagnóstico, o tratamento é planejado
de acordo com as possibilidades do paciente em superar suas dificuldades e o conhecimento
manifestado é mediado pelo profissional (CHAMAT, 2004, p. 28).
2.2 DIFICULDADES DE APRENDIZAGEM
Dificuldades de aprendizagem, conforme explica Azevedo (2014), “são sinais
indicativos de que algo não vai bem no aprender ou no ensinar”. Para Carvalho (2007, p.
230), “a aprendizagem pode ser entendida como um processo de aquisição individual,
evolutiva e constante, que reúne características tanto orgânicas como do ambiente”. Os
comportamentos ou atitudes, desenvolvidos neste processo, que não favorecem a alegria de
aprender, a autoria de pensamento ou o sucesso acadêmico são entendidos como dificuldades
de aprendizagem (AZEVEDO, 2014).
Segundo Kauark (2008, p. 267), “de modo geral, as crianças com dificuldades de
aprendizagem e de comportamento são descritas como menos envolvidas com as tarefas
escolares do que os seus colegas sem dificuldades”. Maluf (2013) afirma que “as dificuldades
e os transtornos de aprendizagem que se apresentam na infância têm forte impacto sobre a
vida da criança, de sua família e sobre o seu entorno, pelos prejuízos que acarretam em todas
as áreas do desenvolvimento pessoal”.
Desta forma, suas causas devem ser precocemente identificadas e investigadas para
que os problemas não se agravem com o passar do tempo. Kauark (2008, p. 268) cita alguns
fatores que podem prejudicar o quadro de aprendizagem de um aluno:
Falhas no sistema educacional: o método da escola não condiz com o tipo de
raciocínio utilizado pelo aluno, ou os professores são inábeis; quadros neurológicos
ou psiquiátricos: neste caso, além da terapia comportamental, é aconselhável
acompanhamento psiquiátrico; condições emocionais: a criança pode não se sentir
bem na escola por causa de algum professor, ou algum problema familiar está
atrapalhando sua atenção à educação.
22
As dificuldades de aprendizagem são geralmente transitórias, percebidas quando há
desempenho incompatível com a capacidade cognitiva do indivíduo. Estas dificuldades
podem ser evitadas respeitando o nível cognitivo da criança e permitindo sua interação com o
conhecimento através dos atos de observar, compreender e analisar (SAMPAIO, 2011, p. 28).
2.2.1 Processo de diagnóstico
O diagnóstico de um problema de aprendizagem é um processo de investigação
realizado pelo psicopedagogo para identificar problemas de aprendizagem em um paciente.
Cipriano (2011) explica que o diagnóstico “permite ao profissional investigar, levantar
hipóteses provisórias que serão ou não confirmadas ao longo do processo recorrendo, para
isso, a conhecimentos práticos e teóricos”.
Cipriano (2011) define o diagnóstico como “um processo no qual analisa-se a situação
do aluno com dificuldade dentro do contexto da escola, da sala de aula, da família; ou seja, é
uma exploração problemática do aluno frente à produção acadêmica.” Portanto, neste
processo o psicopedagogo deve analisar a queixa trazida pelos responsáveis ou até pelo
próprio sujeito com um olhar interdisciplinar, construído, pesquisando informações nos
comportamentos, no silêncio, na intenção (RODRIGUES, 2009). A Figura 1 demonstra a
interação entre os contextos existentes no processo de avaliação.
Figura 1 – Interação entre os contextos no processo de avaliação psicopedagógica
Fonte: Adaptado de Coloner, Masot e Navarro (2008, p.16).
Na Figura 1 são demonstrados os diferentes âmbitos envolvidos no processo de
avaliação do indivíduo: os alunos, suas famílias, as escolas e os professores. Cada
23
personagem tem sua responsabilidade com este indivíduo e pode auxiliar na identificação de
comportamentos que possam vir a se tornar uma dificuldade de aprendizagem.
Os contextos devem interagir influenciando-se mutuamente. A escola faz parte de um
contexto social mais amplo e dentro desse contexto há uma referência particular à família que
o aluno pertence, interagindo com os outros contextos. Qualquer mudança produzida em
algum dos contextos leva a adaptações de outros. A avaliação psicopedagógica deverá
considerar a individualidade e a interação de todos esses contextos (COLONER, MASOT e
NAVARRO, 2008, p.17)
Diante disto, o psicopedagogo procede buscando a compreensão do motivo dos
desvios no processo de aprendizagem, avaliando as possibilidades e capacidades de
aprendizagem futura do paciente. Alguns princípios a serem seguidos durante o processo de
diagnóstico são a análise do contexto e leitura do sintoma e das causas históricas, avaliação do
nível da dificuldade apresentada e encaminhamento a outros profissionais se necessário
(MORAES, 2010, p.7). Para Chamat (2004, p. 38), na etapa de diagnóstico “o levantamento
de hipóteses tem a finalidade de direcionar o trabalho de avaliação, tornando-o mais objetivo,
evitando-se especulações que possam desviar o examinador do campo focal de estudo”.
2.2.2 Instrumentos de avaliação psicopedagógica
A avaliação é a base para a intervenção psicopedagógica, pois ela oferece
possibilidades de decisão voltadas à prevenção e tratamento das possíveis dificuldades dos
pacientes, de forma a promover melhores condições para o seu desenvolvimento (MORAES,
2010, p.2). Moraes (2010, p. 4) afirma que:
A avaliação psicopedagógica é a investigação do processo de aprendizagem do
indivíduo visando entender a origem da dificuldade e/ou distúrbio apresentado.
Inclui entrevista inicial com os pais ou responsáveis pela criança, análise do material
escolar, aplicação de diferentes modalidades de atividades e uso de testes para
avaliação do desenvolvimento, áreas de competência e dificuldades apresentadas.
Para que o psicopedagogo possa avaliar da situação do paciente, ele precisa investigar
o problema fazendo uso de entrevistas, aplicando a Entrevista Familiar Exploratória
Situacional (EFES), Entrevista Operatória Centrada na Aprendizagem (EOCA), testes
específicos, visita à escola, anamnese, entre outros (ACAMPORA, 2013, p. 15). Coma (2008,
p.45) relata que “as técnicas e os instrumentos psicopedagógicos devem nos ajudar a fazer
uma reflexão organizada sobre o que ocorre e, ao mesmo tempo, sobre o que é preciso fazer,
entendido como o possível em um contexto determinado”.
Alguns critérios para seleção de instrumentos de avaliação psicopedagógica, citados
pelo Ministério da Educação (2006, p. 24), são:
24
1. O primeiro critério é o de atenção ao propósito do instrumento. Alguns
instrumentos são descritivos e muito simples, formando uma ideia apenas geral do
desenvolvimento da criança, não fornecendo informações detalhadas que poderão
subsidiar um planejamento curricular amplo e profundo.
2. O segundo critério é a necessidade de definir claramente os objetivos da
avaliação, especificando quais aspectos do desenvolvimento o instrumento é capaz
de medir.
3. Terceiro, a seleção de indicadores comportamentais deve ser apropriada para os
objetivos do instrumento e para a população na qual o instrumento será usado. Um
exemplo de uso indevido é a utilização de instrumento que valoriza a resposta verbal
da criança sendo aplicado em crianças com dificuldades de articulação da fala.
Ao iniciar uma avaliação, os primeiros instrumentos utilizados pelo profissional são as
entrevistas com o paciente e sua família. Posteriormente, o psicopedagogo pode fazer uso de
testes e jogos para conhecer melhor seu paciente. Fiorenzano (2012) completa que:
por meio dos jogos, o sujeito pode se manifestar, sem mecanismos de defesa, os
desejos contidos em seu inconsciente. Levando-se em conta que o sujeito possui
poucos recursos (de vocabulário, por exemplo) para se comunicar expressar o que
sente e o que deseja, ele pode fazer o uso de jogos, desenhos e brincadeiras para
manifestar suas emoções.
No âmbito das entrevistas psicopedagógicas destaca-se a anamnese, que captura
informações da história de vida do paciente e disponibiliza fatos que facilitam o trabalho do
psicopedagogo durante o processo de investigação do problema. Kwiecinski (2012) afirma
que “através da anamnese é possível levantar hipóteses que poderão justificar a defasagem do
indivíduo, bem como nos auxiliar na seleção de outros instrumentos do diagnóstico, com base
nas hipóteses levantadas”. A anamnese, de acordo com Chamat (2004, p. 81):
constitui-se em um instrumento muito útil para o processo diagnóstico, pois auxilia a
investigação do objeto focal (...) a confirmar e/ou refutar hipóteses levantadas
anteriormente, como também a formular novas hipósteses sobre as possíveis causas
das dificuldades de aprendizagem do sujeito.
A EOCA, proposta por Visca (1987), é um importante instrumento que auxilia o
profissional a conhecer melhor seu paciente e organizar suas observações através do registro
dos comportamentos percebidos durante atividades executadas pelo indivíduo na entrevista,
como desenhos e jogos. Chamat (2004, p. 72) aponta três objetivos principais na realização da
EOCA:
a) Detectar sintomas e formular hipóteses sobre as prováveis causas das dificuldades
de aprendizagem, sem julgamento prévio ou contaminação do agente corretor;
b) Levantar os possíveis obstáculos que emergem na relação do sujeito com o
conhecimento;
c) Obter dados a respeito do paciente nos aspectos afetivos e cognitivos, a fim de
formular um sistema de hipóteses e delinear linhas de investigação.
Outro instrumento utilizado na avaliação do paciente é o teste de lateralidade. Este
teste visa identificar a lateralização ocular, manual e pedal por meio da aplicação de três testes
25
para cada membro. Maricato (2010) cita formas de execução do teste de modo a investigar a
dominância de lateralidade para olho, mão e pé do paciente:
Olho dominante: oferecer um papel retangular (papel cartão) com um orifício e
solicitar que a criança olhe por ele, fechando um dos olhos, na direção de uma figura
(pode ser o desenho de uma paisagem). O olho dominante será o que ficou aberto
para a visualização da figura.
Mão dominante: solicitar que a criança faça um desenho, para observar qual mão
utiliza ou fazer uma brincadeira jogando objetos para que ela agarre com uma mão
só. A mão dominante será a que ela utilizar para agarrar ou desenhar.
Pé dominante: solicitar que chute a bola ou que fique apoiada em um pé só. O pé
dominante será o que utilizar para apoiar-se ou para chutar a bola.
O teste de compreensão da palavra escrita avalia a compreensão de leitura de sentenças
de complexidades variadas por meio da exibição de uma palavra seguida de figuras
alternativas, sendo uma o alvo e as demais apenas distraidoras. A tarefa do paciente neste
teste é escolher a figura que melhor corresponde à sentença (NIKAEDO et al., 2006, p. 109).
Sampaio (2009, p. 128) descreve uma versão deste teste contendo dez quadros contendo um
nome de animal e três figuras alternativas.
Percebe-se que o psicopedagogo tem à sua disposição, na atualidade, uma grande
diversidade de instrumentos para a avaliação e diagnóstico de pacientes, porém Coma (2008,
p.46) afirma que “cada psicopedagogo terá de saber estabelecer qual é a melhor estratégia de
intervenção a propósito de um caso concreto, escolhendo os instrumentos e as técnicas que
possam se ajustar melhor a cada momento para obter funcionalidade e adequação”.
Após a realização das atividades de intervenção com o paciente, é realizada a
entrevista de devolução com os responsáveis do paciente. Segundo Acampora (2013, p.117),
esta entrevista é “a comunicação verbal feita ao final de toda a avaliação em que o terapeuta
relata aos pais e ao paciente os resultados obtidos ao longo do diagnóstico”. A devolutiva é
apresentada aos pais fracionada em três áreas: pedagógica, cognitiva e afetivo-social, e visa
verificar aspectos psicopedagógicos, como leitura, escrita e raciocínio (ACAMPORA, p.117).
2.3 SISTEMAS ESPECIALISTAS
Heinzle (1995, p. 7) descreve os sistemas especialistas como sistemas computacionais
projetados e desenvolvidos para prover soluções de problemas geralmente conhecidos apenas
por especialistas de determinado domínio. Os Sistemas Especialistas (SEs) são uma subárea
da inteligência artificial que auxiliam na resolução de problemas através de regras que
reproduzem o conhecimento de um profissional especialista, a fim de fornecer respostas de
determinado domínio (BARRETO; PREZOTO, 2010, p.4).
26
Segundo Bittencourt (2006, p. 260), “os SEs são concebidos para reproduzir o
comportamento de especialistas humanos na resolução de problemas do mundo real”. Já
Heinzle (1995, p. 7) registra que os sistemas especialistas armazenam um vasto conhecimento
a respeito de uma área específica, de modo que tais conhecimentos devem ser armazenados de
forma organizada, simplificando a busca a respostas requeridas. A Figura 2 ilustra os agentes
envolvidos no projeto de um sistema especialista.
Figura 2 – Agentes envolvidos em um projeto de SE
Fonte: Zuben (2011, p.9).
Percebe-se que um sistema especialista é o resultado da transformação do
conhecimento de um especialista em regras digitalizadas na busca de um resultado. Desta
forma, Bittencourt (2006, p. 262) afirma que:
A chave para o desempenho de um SE está no conhecimento armazenado em suas
regras e em sua memória de trabalho. Este conhecimento deve ser obtido junto a um
especialista humano do domínio e representado de acordo com regras formais
definidas para a codificação de regras no SE em questão.
A principal vantagem da utilização de um sistema especialista é sua funcionalidade de
auxílio a resolução de problemas através da simulação do conhecimento de peritos em
determinado domínio, o que o torna facilmente expansível e adaptável (FÁVERO; SANTOS,
2000b). Diante disso, a etapa mais crítica do desenvolvimento de um SE é a aquisição do
conhecimento, pois nela é preciso integrar conhecimentos novos aos já existentes e atentar aos
possíveis erros de aquisição (BITTENCOURT, 2006, p. 264).
27
2.3.1 Arquitetura
Um sistema especialista geralmente é composto por três elementos: base de
conhecimentos, memória de trabalho ou quadro negro e mecanismo ou motor de inferências.
Na Figura 3 é apresentada a relação entre estes componentes.
Figura 3 – Relação entre os componentes de um sistema especialista
Fonte: Ribeiro (1987 apud FÁVERO e SANTOS, 2000b).
A base de conhecimento, conforme afirma Heinzle (1995, p. 12), “é o local onde se
armazenam fatos, heurísticas, crenças, etc., ou seja, é um depósito de conhecimentos acerca
de um determinado assunto”. Fávero e Santos (2000a) completam que a base de
conhecimentos “é onde estão armazenadas as informações de um sistema especialista, ou seja,
os fatos e as regras”.
A memória de trabalho, para Fávero e Santos (2000a), “é uma área de memória usada
para fazer avaliações das regras que são recuperadas da base de conhecimento para se chegar
a uma solução”. Heinzle (1995, p. 16) destaca que a memória de trabalho é utilizada pelo
sistema especialista durante o processo de inferência. Ainda segundo o autor, é nesta área que
são armazenadas informações de suporte ao sistema enquanto este raciocina.
O motor de inferências é descrito por Heinzle (1995, p. 14) como “o elemento (...) que
é capaz de buscar na base o conhecimento necessário a ser avaliado em cada situação,
direcionar o processo de raciocínio, gerenciar situações de incerteza e levar ao resultado
final”. Desta forma, este componente realiza o raciocínio responsável pela resolução de um
problema, vinculando regras da base de conhecimento aos fatos já conhecidos (ZUBEN,
2011, p.12).
28
Assim, após a aquisição do conhecimento com um especialista, representa-se o mesmo
na base de conhecimento através de fatos, que são utilizados nas regras de produção para
gerar uma resposta a algo anteriormente desconhecido, ou seja, as regras são utilizadas para
retornar fatos a partir de outros fatos e regras já conhecidos através do mecanismo de
inferência.
2.3.2 Representação do conhecimento
O conhecimento existente em uma máquina, para ser utilizado, necessita de uma forma
de representação. Segundo Câmara (2001, p. 2), “todo programa de computador contém o
conhecimento sobre um determinado problema a ser resolvido. O conhecimento está [...] nos
procedimentos de decisão que determinam qual destes algoritmos empregar em determinada
circunstância”.
Para que seja possível resolver problemas através de um sistema especialista, é
necessário associar a ele um volume de conhecimentos relativos ao domínio do problema.
Este conhecimento deve ser transformado em estruturas de dados organizadas que permitam a
sua administração pelo computador e também pelo especialista e pelo usuário (HEINZLE,
1995, p. 17).
A escolha da forma de representação de conhecimento é uma tarefa importante no
projeto de um sistema especialista. Segundo Bittencourt (2006, p. 265), “a linguagem
associada ao método escolhido deve ser suficientemente expressiva (...) para permitir a
representação do conhecimento a respeito do domínio escolhido de maneira completa e
eficiente”. Os principais formalismos de representação do conhecimento, citadas por Prati
(2011, p.8), são: a lógica de primeira ordem, as redes semânticas, os quadros ou frames, os
scripts e as regras de produção, sendo este último o formalismo adotado no presente trabalho.
2.3.2.1 Regras de produção
Regra de produção é uma forma de representação do conhecimento através de pares
formados por uma condição e uma ação, onde: Se uma condição ocorre, determinada ação é
disparada. As regras de produção usufruem de fatos e regras existentes em uma base de
conhecimento para produzir novos fatos, que passam também a fazer parte desta base de
conhecimento (NUNES, 2011, p. 8).
De acordo com Nunes (2011, p. 3), o esquema de regras de produção “representa um
dos melhores meios disponíveis para codificação da experiência de especialistas na resolução
de problemas”. Segundo Heinzle (1995, p. 25), a representação do conhecimento através de
29
regras de produção é a forma mais comum nos sistemas especialistas devido à sua
naturalidade. Para o autor, isto ocorre porque o par “condição-ação” também é utilizado pela
mente humana no processo de raciocínio e decisão. As regras de produção são descritas por
Zuben (2011, p. 3) como:
uma estrutura na forma “SE <antecedente> ENTÃO <consequente>” que relaciona
informações ou fatos (no antecedente, também denominado de premissa ou
condição) a alguma ação ou resultado (no consequente, também denominado de
conclusão).
As regras de produção formam a base de conhecimento dos sistemas especialistas
através da representação do conhecimento do domínio do especialista humano. Miranda Jr.
(2012, p. 1) complementa a explicação sobre a estrutura das regras nos sistemas especialistas:
A parte SE da regra é constituída de CLÁUSULAS. Estas cláusulas são condições
que, compostas formarão uma decisão a ser tomada, sendo conectadas via
conectores lógicos do tipo E OU. Por exemplo: SE A= 1 E B = 2 possui duas
cláusulas: A=1 e B=2. A parte ENTÃO das regras constitui a conclusão a que se
chega se a combinação das cláusulas for verdadeira.
Portanto, uma condição representa uma premissa ou antecedente, ou seja, é necessária
para determinada ação. Caso esta seja verdadeira, ocorre um resultado ou consequência. Esta
conclusão é obtida através no processo de inferência, pois os fatos são armazenados na lista
de verdades, estando disponíveis durante o processo de raciocínio.
Se os fatos armazenados atenderem as premissas da regra e a regra contiver na sua
parte conclusiva uma solução para o problema, o processo de inferência estará concluído com
sucesso (HEINZLE, 1995, p. 28). A Figura 4 ilustra um exemplo de encadeamento de regras
de produção onde uma combinação de condições gera uma conclusão.
Figura 4 – Exemplo de encadeamento de regras de produção
Fonte: Zuben (2011, p. 14).
Desta forma, percebe-se que é possível simular parte do comportamento de um
profissional especialista através do mapeamento de seu conhecimento em sistemas
especialistas, onde são definidas regras de produção que oferecem soluções de problemas com
base no conhecimento obtido com o profissional.
30
Atualmente existem diversas ferramentas que auxiliam na criação de sistemas
baseados em regras de produção. Liu (2011) afirma que nestas ferramentas “os motores de
inferência avaliam informações de acordo com regras de negócio previamente definidas”, e
acrescenta que “a JBoss oferece uma plataforma de lógica de negócio chamada JBoss Drools,
que possui uma implementação de motor de regras.”
2.3.3 JBoss Drools
JBoss Drools é uma plataforma integrada de gerenciamento de regras de produção
voltada para a implementação de sistemas especialistas. Introduzida pela empresa JBoss em
2001, é escrita em linguagem Java e possui código aberto (ZAMBIAZI, 2013, p.44). O motor
de inferências da plataforma, chamado Drools Experts, é um de seus componentes. A
ferramenta conta também com componentes pertinentes a resolução de problemas da
inteligência artificial e gerência de processo de negócio, sendo eles: Drools Guvnor, jBPM,
Drools Fusion e Drools Planner (JBOSS, 2011).
Tizzei (2007, p. 28) explica que “o Drools é baseado em linguagens declarativas, suas
regras são descritas em blocos if/then e pode não haver dependências entre elas. É possível
também estabelecer uma sequência na qual as regras serão executadas”. As regras a serem
executadas pelo motor de inferências e suas condições são armazenadas em um arquivo com
extensão DRL através da comparação entre os fatos e condições das regras (TIZZEI, 2007, p.
28). Paiva (2010, p.17) descreve quatro componentes principais da plataforma Drools:
Working Memory - Memória de Trabalho: É onde residem os fatos.
Production Memory - Base de Conhecimento: É onde reside todo o conhecimento de
negócio (regras).
Pattern Matcher - Reconhecedor de padrões: Responsável por casar os fatos na
memória de trabalho com as condições das regras e criar ativações a partir dos
casamentos.
Agenda: Responsável pela ordenação das ativações para execução.
Uma regra escrita em linguagem DRL exige basicamente quatro componentes: o nome
do pacote, o nome da regra, condições para execução, chamadas Left Hand Side (LHS), e as
ações a serem disparadas, nomeadas Right Hand Side (RHS) (ZAMBIAZI, 2013, p. 46).
Bittencourt (2006, p. 258) complementa que “para cada regra (LHS, RHS), se a sequência de
caracteres LHS está contida na memória de trabalho, então substituir os caracteres LHS na
memória de trabalho pelos caracteres de RHS; se não continuar na próxima regra.” O Quadro
1 apresenta um exemplo de regra que verifica se um paciente possui diagnóstico de gripe.
31
Quadro 1 – Exemplo de regra de produção para diagnóstico de gripe
2.4 TRABALHOS CORRELATOS
Nas pesquisas realizadas foram encontrados trabalhos com finalidade semelhante ao
protótipo proposto: sistemas especialistas que auxiliam na avaliação e diagnóstico na área de
saúde. Esta seção tem por finalidade apresentar quatro trabalhos relacionados, com suas
respectivas abrangências, técnicas abordadas e níveis de precisão medidos pelos autores.
Dentre os trabalhos, os selecionados foram: Hippocrates (SANTOS, 2010); Pré-
d1scalc (ANDRADE et al., 2014); Roseta (MORAES, 2012); e X-Dyslex (RIVEROS, 2001).
2.4.1 Hippocrates
O trabalho de Santos (2010) visa auxiliar estudantes de medicina através do sistema
especialista Hippocrates, que testa o diagnóstico de diversas doenças possibilitando a
identificação de sintomas suficientes para uma sugestão de diagnóstico. Inicialmente é
realizado o levantamento dos requisitos, mapeando quais são os sintomas de cada doença que
será diagnosticada no sistema. Em seguida, o usuário pode criar um paciente virtual e realizar
as perguntas dos sintomas ao paciente. Posteriormente, é feita a validação probabilística,
relacionando o sintoma informado com as possíveis doenças associadas e calculando a
probabilidade através de pesos para cada uma das doenças, conforme Quadro 2.
Quadro 2 – Relação entre sintomas e doenças do Hippocrates
Fonte: Santos (2010, p.46).
O sistema possui três casos de uso: Manutenção de usuários, Criação de paciente
virtual e Interação com paciente virtual, de modo que na tela de interação com o usuário são
informados os sintomas apresentados pelo paciente disponíveis para seleção pelo profissional.
32
O diagnóstico é sugerido pelo sistema através das regras de produção e da base de
conhecimento, populada anteriormente com os dados dos sintomas disponíveis. A Figura 5
apresenta a tela inicial do protótipo Hippocrates.
Figura 5 – Tela inicial do aplicativo Hippocrates
Fonte: Santos (2010, p.66).
As ferramentas utilizadas neste protótipo foram a linguagem de programação Java,
Application Programming Interface (API) Swing, Eclipse e a API Drools para as regras de
negócio. A autora não apresentou resultados do sistema desenvolvido aplicados à realidade,
não informando o atendimento ou não dos objetivos propostos quanto à assertividade dos
diagnósticos, porém afirma que houve sucesso na aplicação das ferramentas em conjunto e
que é extremamente válido o desenvolvimento de um sistema especialista que possibilite a
integração de diferentes módulos programacionais.
2.4.2 Pré-d1scalc1
O Pré-d1scalc é um projeto de jogo computacional que tem como objetivo auxiliar
professores, pedagogos e psicólogos fornecendo um pré-diagnóstico de discalculia¹ em
crianças. Segundo Andrade et al. (2014, p. 5), “para este pré-diagnóstico foram desenvolvidas
fases baseadas nas dificuldades que pessoas com discalculia apresentam. Cada fase testa a
proficiência do jogador em cada dificuldade específica”.
Foram desenvolvidas, ao todo, 6 fases no jogo. A primeira fase é intitulada “Ajudando
os animais” e nesta o jogador deve separar imagens de animais, frutas e lixo apresentadas na
1 Dificuldade de aprendizagem que afeta a compreensão de números e símbolos matemáticos.
33
tela, arrastando os objetos para o local correspondente (para junto dos outros animais, à cesta
de frutas e à lixeira), conforme Figura 6.
Figura 6 – Tela fase Ajudando os animais do Pré-d1scalc
Fonte: Andrade et al. (2014, p.5).
A segunda fase é a “Balança Matemática”, onde deve ser feito o equilíbrio de um
conjunto de números em uma balança. A fase três chama-se “Labirinto” e permite avaliar a
percepção do jogador quanto às direções esquerda e direita, utilizadas para sair do labirinto.
Na fase “Aritmética”, o jogador deve responder os resultados de contas de adição, subtração,
multiplicação e divisão. Na fase 5, “Jogo das garrafas coloridas”, o jogador deve ordenar, de
forma crescente e decrescente, sete figuras de garrafas de tamanhos variados. A última fase,
chamada “Maior ou Menor”, permite a avaliação da capacidade do jogador em identificar
sequências de números (antecessor e sucessor). Nesta fase, segundo Andrade et al. (2014, p.
6), “é apresentado ao jogador um número e uma soma, o jogador deve informar se a soma é
maior ou menor que o número.” A Figura 7 ilustra a tela apresentada ao jogador nesta fase.
34
Figura 7 – Tela da fase Maior ou Menor do Pré-d1scalc
Fonte: Andrade et al. (2014, p. 6).
Desta forma, o jogo é voltado para crianças de 10 a 12 anos e provê um pré-
diagnóstico de discalculia através da base de conhecimentos e do mecanismo de regras de
produção. Andrade et al. (2014, p. 6) explica o funcionamento do sistema:
Após o jogador completar todas as fases, através de uma base de conhecimento
podemos simular as regras que um especialista utilizaria para diagnosticar a criança
e inferir de acordo com o desempenho do jogador, dando um pré-diagnóstico para
que o usuário seja encaminhado para um pedagogo ou psicólogo a fim de obter um
diagnóstico mais detalhado.
A aplicação utiliza como ferramentas de desenvolvimento a linguagem Java, a
biblioteca para interface gráfica Swing e, para o desenvolvimento de regras, o motor de
inferência Java Embedded Object Production System (JEOPS).
Os autores do Pré-d1scalc afirmam que seu uso nas escolas auxiliará os profissionais
da educação, e Andrade et al. (2014, p. 6) complementa afirmando que este “poderá ser de
grande ajuda na identificação da discalculia nos estudantes, pois, se esse problema for
diagnosticado cedo, é possível acompanhar o aluno e auxiliá-lo nas suas dificuldades de
maneira mais eficaz.”
2.4.3 Roseta
Na Universidade Federal do Rio de Janeiro foi desenvolvida, em 2012, Roseta, uma
solução que provê ferramentas que têm como objetivo facilitar as tarefas dos profissionais
envolvidos nas etapas de construção de um ambiente de avaliação cognitiva para um jogo
psicopedagógico (MORAES, 2012, p. 21). De acordo com Moraes (2012, p. 67), este
35
ambiente “fornece uma infraestrutura de ferramentas computacionais que facilitam a
construção de ambientes de avaliação cognitiva para os jogos psicopedagógicos, atendendo os
diferentes profissionais envolvidos em cada uma das etapas previstas nesse trabalho.” A
plataforma auxilia as tarefas de construção de um jogo psicopedagógico e de seus
mecanismos de avaliação através dos módulos de Coleta de Informações, Construção de
Critérios de Avaliação Cognitiva e Apresentação de Resultados.
No módulo de Coleta de Informações, as ferramentas utilizadas são a linguagem de
programação Java, ambiente de desenvolvimento Eclipse e Serviços Web, Representational
State Transfer (REST), Restful e Rest Easy para a camada de comunicação através de Web
Services. No módulo de Construção de Critérios de Avaliação Cognitiva, é usada a API
Drools para computar as variáveis de desempenho (percentual de erros, acertos e precisão,
tempo médio de resposta, rapidez). Finalmente, no módulo de Apresentação de Resultados é
utilizado Java Server Faces (JSF), juntamente com RichFaces para a interface gráfica e
JFreeChart para gráficos.
Um dos objetivos dos experimentos realizados por Moraes (2012, p. 134) foi “validar
a capacidade técnica do ambiente computacional Roseta em fornecer as ferramentas
adequadas para construir ambientes de avaliação cognitiva através de 135 jogos
psicopedagógicos”. A Figura 8 – Exemplo de jogo implementado no ambiente apresenta o
“Monta Boneco”, um exemplo de jogo implementado no ambiente Roseta.
Figura 8 – Exemplo de jogo implementado no ambiente Roseta
Através de um experimento de validação técnica e simulação de uso com quatro
profissionais foi evidenciado que a ferramenta é intuitiva e eficaz, porém foram sugeridas
melhorias na interface. Uma das contribuições citadas pelo autor sobre a camada de
Apresentação de Resultados é que esta “fornece um maior controle das ações tomadas pela
36
criança durante o jogo, permitindo o avaliador rastrear suas evoluções e assim mediá-lo com o
objetivo de estimular seu aprendizado”, conforme afirma Moraes (2012, p. 165).
2.4.4 X-Dyslex
X-Dyslex, um sistema apresentado por Riveros (2001), é voltado para auxiliar
psicólogos, psicopedagogos e professores dos anos iniciais no diagnóstico da dislexia. O
desenvolvimento do sistema foi dividido entre as etapas de: (a) aquisição do conhecimento,
realizado através de entrevistas com especialistas; (b) desenvolvimento gráfico dos quadros
do aplicativo, que totalizam 45 e envolvem categorias de habilidades; (c) uma terceira etapa,
que, segundo Riveros (2001, p. 41), “consistiu na escolha de um software que apresente
recursos gráficos, inclusão de som e programação de pontuação”.
O aplicativo X-Dyslex é composto por nove testes: recepção visual, orientação
espacial, associação visual, recepção auditiva, associação auditiva, rima, integração,
associação visual e closura gramatical. A Figura 9 ilustra a tela inicial do aplicativo, que
disponibiliza acesso aos testes disponíveis.
Figura 9 – Tela inicial do aplicativo X-Dyslex
Fonte: Riveros (2001, p. 46).
Todos os testes apresentam recursos visuais interativos e são realizados diretamente
pelas crianças com sintomas de dislexia. A criança responde aos testes e ao final é
apresentada a pontuação, disponibilizando o pré-diagnóstico conforme Quadro 3, apresentado
abaixo.
37
Quadro 3 - Indicadores de pontuação final do X-Dyslex
Pontuação Pré-diagnóstico
30 a 43 pontos Não apresenta risco de ter dislexia.
15 a 29 pontos Cuidado, é necessário um acompanhamento pelo
psicólogo, para verificar qual é o problema desta
criança.
0 a 14 pontos Sério risco de que a criança seja disléxica. Deve
ser feito um diagnóstico pelo especialista. Fonte: Riveros (2001, p. 65).
Quanto à tecnologia, Riveros (2001, p. 41) afirma que “em primeira instância foi
escolhido o Flash-4, tendo um grande poder de processamento multimídia e versatibilidade,
ficando limitado somente à criatividade do design”. Porém, devido à falta de alguns recursos,
identificada durante a etapa de programação, e à falta de tempo para pesquisa de uma
correção na versão 4, foi decidida a alteração para o Flash 5 (RIVEROS, 2001, p. 42). Além
da ferramenta Flash, no desenvolvimento foi utilizada a linguagem Action Script. Como
conclusão, Riveros (2001, p. 66) afirma:
Embora não seja fácil, quase impossível, conseguir testes aplicados na área de
psicologia para diagnosticar a dislexia, as aceitações do protótipo foram motivadoras
e as contínuas sugestões permitiram o aprimoramento do aplicativo durante o
processo de desenvolvimento.
2.4.5 Comparação entre os trabalhos correlatos
O Quadro 4 apresenta a comparação entre os trabalhos pesquisados com relação aos
seguintes critérios:
a) plataforma: indica a plataforma de desenvolvimento do sistema (desktop, web,
mobile) e se foi desenvolvida interface gráfica para o sistema especialista,
possibilitando a interação do usuário e apresentação de resultados de forma
prática;
b) tecnologias: neste critério foram observadas as tecnologias e frameworks utilizados
no desenvolvimento do sistema;
c) implementação de regras: indica o mecanismo de implementação de regras de
produção que computam as informações adquiridas do paciente para gerar o
diagnóstico;
d) banco de dados: aponta a integração com algum banco de dados para serializar os
dados manipulados no sistema;
e) área de diagnóstico: apresenta a informação de qual é o público a ser avaliado ou
diagnosticado;
f) público alvo: indica o usuário alvo do sistema, o profissional que utilizará os
recursos desenvolvidos;
38
g) domínio: apesar de todos os trabalhos relacionados estarem relacionados a saúde,
este item indica o domínio do sistema especialista, a área de abrangência do
projeto.
Quadro 4- Características dos trabalhos relacionados
Critério Hippocrates
(2010)
Pré-d1scalc
(2014)
Roseta
(2012)
X-Dyslex
(2001)
Plataforma Desktop Desktop Web Desktop
Tecnologias Swing Swing JSF, RichFaces,
REST Flash, ActionScript
Implementação
de regras Drools JEOPS Drools Não se aplica
Banco de dados Não Não Não Não
Área de
diagnóstico
Pacientes com
sintomas
variados
Crianças de 10 a
12 anos em
processo de
alfabetização
Crianças com
déficit cognitivo
Crianças com
dificuldade de
aprendizagem na
etapa de alfabetização
Público alvo Estudantes de
Medicina
Profissionais de
educação e
psicólogos
Psicólogos e
Psicopedagogos
Psicólogos,
psicopedagogos e
professores de séries
iniciais
Domínio
Medicina –
Doenças em
geral
Discalculia Jogos
psicopedagógicos Dislexia
A partir do Quadro 4 pode-se observar que apenas o trabalho Roseta (2012) oferece
plataforma web, sendo que os demais, apesar de apresentarem interface gráfica, não oferecem
portabilidade ao usuário. As tecnologias para implementação de regras variam, sendo que os
trabalhos Hippocrates (2010) e Roseta (2012) utilizam o mecanismo de inferência Drools,
enquanto o trabalho Pré-d1scalc utiliza a ferramenta JEOPS (FIGUEIRA FILHO, 2007),
motor de inferências para aplicações Java, e o trabalho X-Dyslex é implementado com o uso
da ferramenta Flash 5.
Nenhuma das aplicações utilizou banco de dados para armazenamento dos registros,
porém, no aplicativo Roseta (2012) uma sugestão de trabalho futuro é a implementação de
banco de dados para persistência dos dados coletados no Módulo de Coleta. Nos trabalhos X-
Dyslex e Hippocrates, os autores afirmam que a utilização de banco de dados estava fora do
escopo da aplicação. Com exceção do sistema Hippocrates, voltado a pacientes sem limitação
de idade e com sintomas de doenças variadas, os trabalhos apresentados oferecem uma
ferramenta para auxílio no diagnóstico de algum transtorno de aprendizagem em crianças para
uso de professores, psicopedagogos e psicólogos. As tecnologias utilizadas no
desenvolvimento dos trabalhos também são diversas, variando conforme a plataforma
oferecida. Enquanto Hippocrates e Pré-d1scalc implementam a interface através de Swing, o
39
X-Dyslex, também desenvolvido para desktop, é implementado com a tecnologia Flash para a
interface gráfica. O trabalho Roseta tem como diferencial os Web Services na camada de
comunicação, onde é utilizado o protocolo REST.
40
3 DESENVOLVIMENTO DO PROTÓTIPO
Neste capítulo são abordadas as etapas de desenvolvimento do protótipo. A seção 3.1
apresenta os principais Requisitos Funcionais (RF) e Requisitos Não Funcionais (RNF) do
trabalho. A seção 3.2 apresenta a especificação do protótipo, casos de uso e diagramas. Na
seção 3.3 consta a implementação, detalhando as ferramentas e técnicas utilizadas durante o
desenvolvimento. Os resultados obtidos e discussões são relatados na seção 3.4.
3.1 PRINCIPAIS REQUISITOS DO PROBLEMA A SER TRABALHADO
Nesta seção são apresentados os requisitos funcionais e não funcionais do protótipo
desenvolvido. O Quadro 5 detalha os requisitos funcionais e sua rastreabilidade com os
respectivos casos de uso.
41
Quadro 5 - Lista de requisitos funcionais do protótipo
Requisito Caso de uso
RF01: O protótipo deverá permitir que o usuário efetue login. UC01
RF02: O protótipo deverá permitir o cadastro, consulta, edição e exclusão de usuários. UC02
RF03: O protótipo deverá permitir o cadastro, consulta e edição de pacientes. UC03
RF04: O protótipo deverá permitir o cadastro, consulta, edição e inativação de
planejamentos de atendimento.
UC04
RF05: O protótipo deverá permitir o cadastro, consulta, edição e inativação de
atendimentos.
UC05
RF06: O protótipo deverá permitir o cadastro, consulta, edição e exclusão de
atividades.
UC06
RF07: O protótipo deverá permitir o cadastro, consulta, edição e exclusão de recursos. UC07
RF08: O protótipo deverá permitir o cadastro, consulta, edição e exclusão de
familiares.
UC12
RF09: O protótipo deverá permitir o vínculo de uma atividade a um planejamento. UC04
RF10: O protótipo deverá permitir o vínculo de um ou mais recursos a um
planejamento.
UC04
RF11: O protótipo deverá permitir o vínculo de um planejamento a um paciente. UC04
RF12: O protótipo deverá permitir o vínculo de uma atividade a um atendimento. UC05
RF13: O protótipo deverá permitir o vínculo de um ou mais recursos a um
atendimento.
UC05
RF14: O protótipo deverá permitir o vínculo de um atendimento a um paciente. UC05
RF15: Será permitida a visualização de relatório de avaliação de paciente, detalhando
as sessões realizadas, seu objetivo, recursos e atividades utilizadas, além de
informações gerais dos testes e entrevistas realizados.
UC15
RF16: O sistema deverá permitir a realização de teste de lateralidade do paciente. UC07
RF17: O psicopedagogo poderá selecionar direita ou esquerda para três testes com
mão, olho e pé do paciente.
UC07
RF18: O sistema deverá apresentar o resultado para o teste de lateralidade para cada
membro (mão, olho e pé).
UC07
RF19: O sistema deverá apresentar o resultado final da lateralidade dominante com
base nos três resultados de membros (resultados possíveis: esquerda, direita, cruzada
ou indefinida).
UC07
RF20: O sistema deverá permitir a realização de entrevista de anamnese. UC09
RF21: O sistema deverá permitir a realização de entrevista EOCA. UC10
RF22: O sistema deverá apresentar a modalidade de aprendizagem resultante doa
entrevista EOCA.
UC10
RF23: O sistema deverá permitir a inclusão, edição e inativação de contratos de
pacientes.
UC13
RF24: O sistema deverá permitir a exportação dos contratos de pacientes em formato
docx.
UC13
RF25: O sistema não deverá permitir a exclusão de atividades vinculadas a algum
atendimento ou planejamento.
UC06
RF26: O sistema não deverá permitir a exclusão de recursos vinculados a algum
atendimento ou planejamento.
UC07
RF27: O sistema não deverá permitir o cadastro de contratos para pacientes sem
familiar responsável cadastrado.
UC13
RF28: O sistema não deverá permitir a exclusão de familiares cadastrados como
responsáveis e vinculados a um contrato.
UC12
RF29: A opção de cadastro de usuários estará visível apenas para usuários com perfil
de administrador.
UC02
42
O Quadro 6 demonstra os requisitos não funcionais atendidos no protótipo.
Quadro 6 - Lista de requisitos não funcionais do protótipo
REQUISITOS NÃO FUNCIONAIS
RNF01: Será utilizado o banco de dados MySQL.
RNF02: O sistema deve ser acessado através de um web browser.
RNF03: O ambiente de desenvolvimento deve ser o Eclipse Luna.
RNF04: A versão do Java utilizada deverá ser 7 ou posterior.
RNF05: O mecanismo de inferências de regras de produção deverá ser o JBoss Drools.
RNF06: A biblioteca para implementação da interface gráfica deverá ser a Primefaces 5 ou superior.
RNF07: A biblioteca para implementação da persistência de dados deverá ser a Hibernate 4 ou
superior.
RNF08: O sistema deverá ser compatível com sistemas operacionais Windows.
RNF09: O sistema deve possuir um mecanismo de segurança, evitando acesso indevido a
informações e armazenamento dos dados.
RNF10: O sistema deverá possuir um mecanismo de criptografia na autenticação do usuário.
3.2 ESPECIFICAÇÃO
Nesta seção é apresentada a especificação do protótipo desenvolvido. A especificação
foi elaborada utilizando os padrões da Unified Modeling Language (UML) através da
ferramenta Enterprise Architect (EA). Nas próximas seções são apresentados os diagramas de
casos de uso, diagrama de classes, detalhando os pacotes contidos no protótipo, e diagrama de
atividades.
3.2.1 Diagrama de casos de uso
As figuras a seguir ilustram os casos de uso executados pelo ator Psicopedagogo. A
Figura 10 apresenta os casos de uso referentes à manutenção do sistema, ou seja, cadastros
que permitem inclusão, edição e exclusão ou inativação.
43
Figura 10 - Casos de uso de manutenção de registros
Os casos de uso apresentados na Figura 10 referem-se aos cadastros voltados ao dia a
dia do psicopedagogo. O UC03 – Manter pacientes refere-se ao cadastro de um paciente
quando o mesmo chega à clínica. O UC12 – Manter familiares é utilizado no vínculo dos
familiares ao paciente, de forma a registrar os dados do responsável para fins de contrato de
prestação de serviços do psicopedagogo ao responsável do paciente, cuja funcionalidade está
contida no UC13 – Manter contratos. No UC04 – Manter planejamentos o usuário
registra o planejamento para um atendimento ao paciente, e no UC05 – Manter
atendimentos, são efetuados os registros do atendimento já realizado pelo psicopedagogo,
detalhando, assim como no UC05, o objetivo do atendimento, os recursos e atividades
utilizadas. Desta forma, nos casos de uso UC06 – Manter atividades e UC07 – Manter
recursos, o usuário efetua o cadastro, respectivamente, das atividades executadas e recursos
utilizados em um atendimento ou planejamento.
Na Figura 11 podem-se observar os demais casos de uso, também executados pelo
psicopedagogo. Estes são relacionados aos instrumentos de apoio ao atendimento e avaliação
do paciente.
44
Figura 11 – Casos de uso referentes à avaliação do paciente
O caso de uso de UC10 – Realizar anamnese descreve a interação entre o usuário e a
funcionalidade que permite a realização da entrevista de anamnese com o paciente. O UC11 –
Realizar EOCA é utilizado na realização da EOCA com o paciente, sendo apresentado o
resultado da modalidade de aprendizagem identificada através dos comportamentos
observados. No UC14 – Exportar contrato para docx, é permitido que o usuário efetue a
exportação do texto do contrato de prestação de serviços, mantido pelo UC13, em formato
docx.
O UC08 – Realizar teste de lateralidade descreve a funcionalidade do teste de
lateralidade executado pelo psicopedagogo, que identifica a lateralidade dominante do
paciente. No UC16 – Realizar teste de compreensão da palavra escrita, o
psicopedagogo responderá, em conjunto com o paciente, o teste de compreensão da palavra
escrita, relacionando nomes de animais às respectivas imagens. O UC09 – Visualizar
relatório de avaliação descreve a funcionalidade que apresenta o histórico de
atendimentos realizados, as principais observações registradas na anamnese e o resultado da
EOCA e dos testes realizados nos casos de uso UC08 e UC16.
Na Figura 12 pode-se visualizar o caso de uso UC02 – Manter usuários, executado
pelo ator Administrador, que refere-se ao registro dos usuários com acesso ao sistema, e o
UC01 – Efetuar login, vinculado aos dois atores identificados no protótipo, Psicopedagogo
45
e Administrador, e que é utilizado para efetuar o acesso ao sistema através de credenciais
informadas pelo usuário.
Figura 12 – Casos de uso referentes a controle de acesso
O detalhamento dos casos de uso da aplicação encontra-se no Apêndice A. Nele
constam os objetivos, cenários e fluxos alternativos.
3.2.2 Diagrama de classes
Nesta seção são apresentados os diagramas de classes do protótipo. A aplicação foi
dividida em seis pacotes, seguindo o modelo Model View Controller (MVC), detalhados a
seguir: entities, dao, facade, bean, utils e rules. Nas próximas subseções são
apresentadas as classes, relacionamentos e estruturas desenvolvidas em cada pacote. A Figura
13 ilustra os pacotes da aplicação e suas respectivas classes.
46
Figura 13 – Diagrama de pacotes do protótipo
Na Figura 13 pode-se observar que os pacotes estão integrados na forma de camadas
no modelo MVC. As classes do pacote bean estão vinculadas à interface do usuário, ou seja,
às páginas web da aplicação. Os beans fazem chamadas às classes do pacote facade para
inserir objetos no banco de dados. O pacote facade, por sua vez, comunica-se com o pacote
dao enviando as entidades para persistência, além de ser responsável por validações de
negócio pertinentes a serialização. O pacote entity é encarregado da comunicação direta
com o banco de dados, contendo as classes serializáveis. No pacote utils encontram-se as
classes utilitárias da aplicação, desde métodos de ordenação de listas a formatação gráfica de
um documento com extensão docx. O pacote rules contém as classes de regras de produção
referentes às funcionalidades de EOCA e anamnese. Os pacotes apresentados na figura 4 são
detalhados a seguir.
3.2.2.1 Pacote entity
O pacote entity contém as classes de domínio, serializáveis, da aplicação, ou seja,
basicamente o mapeamento das tabelas do banco de dados, classes com perfil de persistência
de objetos. A Figura 14 representa o diagrama de classes deste pacote.
47
Figura 14 – Diagrama de classes do protótipo
A classe Pessoa é a base para as classes Psicopedagogo, Familiar e Paciente.
Estas classes possuem um atributo que referencia a classe Pessoa, que possui as informações
em comum entre as três. A classe Psicopedagogo armazena informações do psicopedagogo
que utiliza o sistema e que serão utilizadas para a geração do contrato com o responsável do
paciente. Na classe Familiar são armazenados os familiares do paciente atendido, contendo
dados de contato e informações também utilizadas no contrato com o psicopedagogo.
A classe Paciente é responsável por armazenar os pacientes atendidos pelo
psicopedagogo e possui vínculos com as demais classes do sistema, pois a maioria das
funcionalidades está vinculada ao paciente. A classe Contrato é utilizada no registro de
contrato de prestação de serviços assim que o psicopedagogo recebe um novo paciente. A
classe Planejamento armazena as informações de um planejamento efetuado pelo
psicopedagogo antes de uma sessão psicopedagógica, que é representada pela classe
Atendimento. As classes Planejamento e Atendimento contêm os atributos objetivo,
recurso e atividade, sendo que a classe Recurso tem a função de armazenar os recursos
utilizados pelo psicopedagogo durante uma sessão e a classe Atividade armazena a atividade
realizada.
48
A classe TesteCompreensaoPalavra é acionada no teste de compreensão da palavra
escrita realizado com o paciente. Esta classe contém a pontuação do teste, o vínculo com o
paciente, a data de realização e o atributo testeCompreensaoPalavraRespostas, uma lista
das respostas registradas durante o teste na classe TesteCompreensaoPalavraResposta,
contendo a indicação do acerto ou erro da pergunta. Já a classe
TesteCompreensaoPalavraPergunta armazena a descrição da pergunta e as imagens das
opções de resposta.
As classes Eoca e EocaQuestionario são responsáveis pelo armazenamento dos
dados referentes à EOCA realizada com o paciente. A EOCA possui os atributos
dataRealizacao, resultado, probabilidade e um relacionamento com as classes
Paciente e EocaQuestionario. EocaQuestionario, por sua vez, é a classe que armazena os
atributos que indicam características possivelmente apresentadas pelo paciente durante a
interação com o psicopedagogo.
Semelhante à classe Eoca, a classe Anamnese armazena a data de realização e o
relacionamento com as classes Paciente e as demais que contém as questões da entrevista
divididas em categorias: AnamneseConcepcao, AnamneseAlimentacao,
AnamneseEscolaridade, AnamneseEvolucao, AnamneseFamiliar,
AnamneseHistoricoClinico, AnamneseRotina e AnamneseSono.
Ao realizar o teste de lateralidade, as informações são armazenadas na classe
Lateralidade, que contém o atributo indicador da data de realização e o resultado, que
representa a lateralidade dominante do paciente (direita, esquerda, cruzada ou indefinida),
além do relacionamento com a classe LateralidadeAvaliacao. A classe
LateralidadeAvaliacao contém os resultados individuais do teste de lateralidade, isto é, a
lateralidade apresentada para pés, mãos e olhos nos três testes de cada um. A classe do tipo
enumeration LateralidadeEnum está vinculada à classe Lateralidade e corresponde às
lateralidades dominantes possíveis e suas letras iniciais.
3.2.2.2 Pacotes dao
O pacote dao contém as classes responsáveis pela serialização das entidades no banco
de dados. Este pacote comunica-se com os pacotes facade e entity, de modo que o facade
invoca as classes do pacote dao nas interações com o banco de dados através da classe
EntityManager, nativa do Java Persistence API (JPA). Quando as classes do pacote facade
chamam os métodos do pacote dao, a entidade a ser manipulada é enviada como parâmetro.
49
Nos casos de operações como gravação, edição, consulta e exclusão de registros são
utilizados os métodos da classe abstrata GenericDAO, porém é possível criar queries
personalizadas no banco de dados diretamente no pacote dao. A Figura 15 ilustra a
especificação da classe GenericDAO, com seus atributos e métodos.
Figura 15 – Especificação da classe GenericDAO
A classe GenericDAO implementa os métodos responsáveis pelo gerenciamento de
transações no banco de dados. O método beginTransaction inicia uma transação no banco
de dados instanciando o serviço central para ações de persistência, representado pela classe
EntityManager. O método closeTransaction se encarrega de fechar uma transação após a
sincronização do estado das entidades com o banco de dados. Os métodos commit e
rollback, respectivamente, efetuam a confirmação ou cancelamento de envio de uma
alteração ao banco de dados. Para melhor entendimento, a Figura 16 apresenta os atributos e
métodos implementados na classe PlanejamentoDAO.
Figura 16 – Especificação da classe PlanejamentoDAO
O método findAllByPaciente efetua a consulta de todos os planejamentos existentes
no banco de dados vinculados a determinado paciente, enviado como parâmetro pelo método
do pacote facade. A consulta de um planejamento para uma data e paciente específicos,
através dos parâmetros paciente e data, fica a cargo do método findAllByPacienteEData.
A inclusão de novos planejamentos no banco de dados é realizada através do método insert,
que recebe como parâmetro o planejamento a ser cadastrado. O método update é responsável
pela atualização de um planejamento no banco de dados através do envio do parâmetro
planejamento.
50
3.2.2.3 Pacote facade
No pacote facade estão as classes referentes a regras de negócio pertinentes ao banco
de dados. Por exemplo, ao receber a solicitação de exclusão de um recurso ou atividade, é
necessário validar se existe atendimento ou planejamento vinculado a estes objetos. Desta
forma, a classe RecursoFacade realiza uma consulta no banco de dados pelo identificador do
recurso ou atividade e, se existirem relacionamentos, é retornada ao pacote bean uma
mensagem com o retorno da validação, impedindo a exclusão.
Este pacote realiza mediação entre o pacote bean (chamadas a métodos vindos da
interface com o usuário, como inserções e consultas) e o pacote dao (comunicação com o
pacote entity para manipulação de registros no banco de dados). As classes deste pacote
estão vinculadas aos beans dos formulários da aplicação e cada uma possui chamada a uma
classe do pacote facade para consultas, inserções, edições ou exclusões de registros.
Tomando como exemplo a classe PlanejamentoFacade, a Figura 17 apresenta alguns dos
métodos existentes nas classes deste pacote.
Figura 17 – Especificação da classe PlanejamentoFacade
Os métodos da classe PlanejamentoFacade apenas efetuam chamadas aos métodos da
classe PlanejamentoDAO, do pacote dao, detalhado na seção 3.2.2.2. As operações da classe
PlanejamentoFacade efetivam as operações de comunicação com o banco de dados,
servindo as classes do pacote facade apenas como interface entre os beans e a camada de
persistência.
3.2.2.4 Pacote bean
O pacote bean contém as classes responsáveis pela interação entre a interface com o
usuário e a parte funcional do sistema. As classes deste pacote contêm direcionamentos a
outras páginas, chamadas ao pacote facade e validações a nível de tela. Existe um bean
relativo a cada página da aplicação. Na Figura 18 pode-se visualizar a classe LoginBean, do
pacote bean.
51
Figura 18 – Especificação da classe LoginBean
Conforme ilustrado na figura acima, um dos métodos da classe LoginBean é o
doLogin, que invoca a classe UserBOImpl para validar a existência do usuário no banco de
dados, enviando como parâmetro os atributos login e senha. Caso as credenciais estejam
inválidas, é apresentada mensagem de aviso ao usuário e a ação de login é abortada. Se a
validação das credenciais for positiva, o atributo usuario é populado com o objeto retornado
na validação realizada na classe UserBOImpl.
O método doLogout encerra a sessão do usuário no sistema, redirecionando-o para a
página de login. Por fim, o método getDataAtualPorExtenso é acionado na exibição da data
atual na página inicial da aplicação e retorna o texto de data formatada com o nome da cidade
após a chamada à classe Utils. As implementações de outros métodos do pacote bean são
apresentadas na seção 3.3.2.2.
3.2.2.5 Pacote util
No pacote util estão contidas as classes utilitárias da aplicação que auxiliam as
demais classes através de métodos de conversão, ordenação e formatação de arquivos. A
Figura 19 ilustra as classes do pacote util e seus métodos.
52
Figura 19 – Diagrama de classes do pacote util
Todos os métodos da classe Utils são estáticos e podem ser acessados a partir de
qualquer classe do projeto sem a necessidade de instanciar a classe. A classe DroolsUtils
contém os métodos auxiliares às classes de regras de produção da EOCA e do teste de
lateralidade, sendo responsáveis pelo cálculo destes resultados. A classe
MapValueComparator é utilizada para ordenar os resultados da EOCA na regra de cálculo. A
classe MultiPageMessagesSupport representa o filtro para mensagens de aviso ao usuário.
Esta classe é declarada no arquivo faces-config.xml para que as mensagens não sejam
perdidas no redirecionamento de páginas web.
O método doFilter da classe LoginFilter é encarregado da segurança do sistema,
apenas autorizando o acesso às páginas da aplicação a usuários logados. Desta forma, quando
um usuário tenta acessar uma página não autorizada, é apresentada a tela de login para
autenticação no sistema. A classe SessionContext é utilizada na autenticação via contexto,
uma forma simples de controlar as sessões dos usuários. O SessionContext é um recurso
nativo do componente Enterprise Java Beans (EJB) e armazena as informações de sessão do
usuário logado. Ainda referente ao controle de acesso, a classe UserBOImpl efetua a validação
das credenciais informadas quando o login ao sistema é solicitado, checando as mesmas no
banco de dados para autenticação.
A classe StyleSheetFormatter é utilizada na formatação gráfica do arquivo em
formato docx gerado no caso de uso referente à exportação de contratos de pacientes. Os
métodos desta classe utilizam os recursos da biblioteca docx4j, apresentada na seção 3.3.1, e
são responsáveis pelos estilos de fonte e parágrafo utilizados no documento. Na classe Utils
são declarados métodos auxiliares como formatação de data por extenso, comparação de
53
string vazia e conversor de string para criptografia MD5 (utilizado para o campo de senha do
usuário ao logar).
3.2.2.6 Pacote rules
No pacote rules encontram-se as classes relacionadas às regras de produção
executadas na realização da EOCA (RulesEoca) e do teste de lateralidade
(RulesLateralidade). Estas classes utilizam a biblioteca Drools e são acionadas pela classe
correspondente no pacote bean (EocaBean e LateralidadeBean). Detalhes das classes
RulesEoca e RulesLateralidade são apresentados na sessão 3.3.2.5.
3.2.3 Diagrama de atividades
Esta seção tem como objetivo elucidar o processo de utilização da aplicação através
das figuras a seguir. A Figura 20 apresenta o fluxo de utilização da aplicação com base nas
funcionalidades desenvolvidas.
Figura 20 – Fluxo de utilização do protótipo
Na primeira etapa, o usuário efetuará os cadastros dos pacientes, familiares de
pacientes, contratos, recursos e atividades, que serão vinculados aos planejamentos e
atendimentos posteriormente. Nesta fase o usuário criará a base de informações que o sistema
utilizará nas fases seguintes referentes à avaliação psicopedagógica. A fase 2 refere-se às
atividades realizadas com o paciente durante a etapa de avaliação: questionário de anamnese,
EOCA, teste de compreensão da palavra escrita e teste de lateralidade.
A última etapa é representada pela funcionalidade de visualização do relatório de
avaliação do paciente, que apresenta o histórico do paciente e dados da fase 2 que facilitam o
processo de avaliação do psicopedagogo. Na Figura 21 é ilustrado o diagrama de atividades
do protótipo de forma mais detalhada.
54
Figura 21 – Diagrama de atividades do protótipo
Pode-se observar na Figura 21 que, após o acesso do usuário ao sistema, é realizado o
cadastro das atividades e recursos que estão disponíveis ao psicopedagogo na clínica para a
realização dos atendimentos aos pacientes. Posteriormente, são cadastrados os pacientes e
vinculados os seus familiares. A próxima atividade é o cadastro de contrato de prestação de
serviços entre o psicopedagogo e o familiar responsável do paciente.
Em seguida, o usuário pode efetuar o registro do planejamento antes de determinado
atendimento ou seguir para o cadastro do atendimento, que pode ser realizado em conjunto
com as atividades de teste de lateralidade, teste de compreensão da palavra escrita, EOCA e
anamnese. As entrevistas e testes poderão ser cadastradas como atividades e assim vinculadas
ao planejamento e atendimento, ou seja, durante a execução de um atendimento, o
psicopedagogo pode simultaneamente realizar um teste ou entrevista. Por fim, o usuário gera
o relatório de avaliação do paciente, que reúne informações do histórico de atendimentos,
observações e resultados dos testes, informações estas que serão citadas na entrevista
devolutiva aos pais.
3.3 IMPLEMENTAÇÃO
A seguir são detalhadas as ferramentas utilizadas no desenvolvimento do protótipo, o
processo de desenvolvimento e a operacionalidade da implementação.
55
3.3.1 Técnicas e ferramentas utilizadas
No desenvolvimento do protótipo foi utilizada a linguagem Java versão 8 na Integrated
Development Environmnet (IDE) Eclipse Luna. A arquitetura seguida na implementação foi a
MVC. Nesta arquitetura, conforme descrito por Caelum (2009), o objeto View é responsável
por apresentar os resultados na página web; o objeto Controller, ou Controlador, efetua o
direcionamento das operações para quem deve executar determinada tarefa; e as classes que
representam as entidades e as que auxiliam no armazenamento e busca dos dados são
chamadas de Modelo (Model).
Para a camada web, foi adotada a biblioteca Primefaces, versão 5.1, suportada pelo
framework Java Server Faces (JSF), versão 2.2, em conjunto com as linguagens HyperText
Markup Language (HTML) e eXtensible Hypertext Markup Language (XHTML), e a folha de
estilos Cascading Style Sheets (CSS). Na persistência de dados, foi utilizada a especificação
Java Persistence API (JPA) versão 2.1 em conjunto com o framework Hibernate versão 4.3.8,
e o Sistema Gerenciador de Banco de Dados (SGBD) utilizado foi o MySQL Server 5.1.
Para a exportação de arquivos com extensão docx, foi escolhida a biblioteca docx4j.
Quanto à tecnologia para a implementação das regras de produção, inicialmente foi proposto
utilizar a ferramenta JEOPS (FIGUEIRA FILHO, 2007) por ter sido desenvolvida no Brasil,
porém devido à vasta documentação, apesar de estar em língua estrangeira, e à simplicidade
em sua configuração, foi feito uso da plataforma Drools, suportada pela empresa JBoss. O
servidor de aplicações escolhido foi o Apache Tomcat versão 7, por sua facilidade de
configuração e uso em pequenas aplicações.
3.3.2 Etapas do desenvolvimento
Esta seção apresenta as funcionalidades da aplicação a nível de código, demonstrando
trechos de código-fonte relativos às operações disponíveis ao usuário. A seção é dividida em 4
subseções, levando em consideração a arquitetura MVC e o mecanismo de regras utilizado no
desenvolvimento. No item 3.3.2.1 é detalhada a implementação do pacote entities,
referente ao objeto Model, onde se encontram as entidades serializáveis e são utilizadas as
anotações do framework Hibernate. A implementação do pacote bean, referente ao objeto
View, é demonstrada no item 3.3.2.2. No subcapítulo 3.3.2.3 é detalhada a implementação dos
pacotes facade e dao, relativos ao objeto Controller do modelo MVC. Na subseção 3.3.2.4
são apresentadas as implementações do pacote utils. Por fim, no item 3.3.2.5 é apresentada
a implementação das regras de produção do pacote rules.
56
3.3.2.1 Implementação do objeto Model
No objeto Model são implementadas as classes existentes no pacote entity e
apresentadas no digrama de classes na seção 3.2.2.1. As classes deste pacote possuem a
anotação @Table do Hibernate para indicar que representam uma tabela do banco de dados, e
cada atributo da classe é anotado com @Column, indicando o nome da coluna referente a ele no
banco de dados. A classe Lateralidade, do pacote entity, possui outras algumas anotações
do Hibernate em seus atributos, necessárias para o relacionamento entre classes e
mapeamento do tipo de dados. O Quadro 7 ilustra o código-fonte da classe Lateralidade.
Quadro 7 – Trecho de implementação da classe Lateralidade
No Quadro 7 (acima), pode-se observar na linha 21 a anotação @Temporal. Ela indica
ao JPA que o atributo anotado armazena conteúdo de data. Nas linhas 25 e 26 são utilizadas
duas anotações no atributo paciente: @OneToOne e @JoinColumn. Estas anotações apontam o
relacionamento entre as tabelas Lateralidade e Paciente, sendo que a primeira indica que
um paciente pode possuir apenas um registro de lateralidade, enquanto uma lateralidade está
vinculada a apenas um paciente por vez. Já a anotação @JoinColumn é utilizada para
estabelecer o relacionamento entre as tabelas Lateralidade e Paciente através da coluna
identificada no parâmetro name da anotação (id_paciente).
No Quadro 8 é possível observar, ainda na classe Lateralidade, outras anotações
indicativas de relacionamentos entre classes.
57
Quadro 8 – Trecho de implementação da classe Lateralidade
Na linha 42, o relacionamento entre as tabelas LateralidadeAvaliacao e
Lateralidade é indicado pela anotação @OneToOne. Esta anotação aponta que um objeto
Lateralidade possui vínculo com apenas um objeto do tipo LateralidadeAvaliacao e
vice-versa. Já a anotação @PrimaryKeyJoinColumn, existente na linha 43, significa que a
chave primária da tabela LateralidadeAvaliacao é a coluna de junção com a tabela
Lateralidade.
A anotação @Enumerated, utilizada na linha 39, aponta ao JPA que o atributo
lateralidadeDominante é uma classe do tipo enum, uma estrutura de dados organizados
que, no caso da classe LateralidadeEnum, possui as constantes relativas à lateralidade,
conforme indicado no Quadro 9.
Quadro 9 – Implementação da classe LateralidadeEnum
3.3.2.2 Implementação do objeto View
No objeto View são encontradas as classes relativas à camada web da aplicação. No
corrente trabalho, este objeto é representado pelo pacote WebContent na estrutura de arquivos
da aplicação e contém páginas XHTML, recursos como imagens e folhas de estilos e arquivos
de configuração da camada de visualização. Nas páginas do sistema foi implementado um
template padrão que inclui os conteúdos da página de modo formatado conforme os estilos
aplicados. O arquivo commonLayout.xhtml é ilustrado no Quadro 10.
58
Quadro 10 – Implementação do arquivo commonLayout.xhtml
No arquivo commonLayout são incluídos os arquivos commonContent, cujo conteúdo
principal de cada página é adicionado ao template padrão, e commonHeader, que contém as
divisões (divs) do cabeçalho da aplicação. Devido ao cabeçalho ser comum para todas as
páginas, exceto à tela de login, através do uso dos templates não é necessário duplicar o
código. Um exemplo de utilização do template é apresentado no Quadro 11, que contém o
código da página recurso.xhtml.
Quadro 11 – Implementação da página recurso.xhtml
Pode-se visualizar na linha 10 o componente ui:composition recebendo como
parâmetro do atributo template o caminho para o arquivo commonLayout.xhtml. Desta
forma, o conteúdo existente dentro do ui:composition estará formatado com os padrões de
estilos do sistema, e o cabeçalho já estará incluso. Na linha 15 é utilizado o componente
panelGrid para inserir os campos descricao e quantidade, informados pelo usuário no
cadastro de recurso, em duas colunas de mesma largura. O botão Salvar, implementado na
linha 24, efetua a chamada ao método salvarRecurso da classe RecursoBean para gravar o
59
registro. Neste momento o componente messages (linha 14) é responsável por apresentar ao
usuário a mensagem de retorno do método.
A funcionalidade de teste de compreensão da palavra escrita é implementada através
de abas que contêm uma tabela com três figuras. A ordem de exibição das alternativas do teste
é dinâmica, isto é, apesar das figuras dos animais serem estáticas, a cada novo quadro
apresentado as alternativas têm sua posição alterada. É apresentado ao usuário um quadro
para cada pergunta, totalizando 10 quadros. O Quadro 12 ilustra o trecho de código da classe
TesteCompreensaoPalavraBean, responsável pela geração randômica da ordem das imagens
apresentadas ao usuário ao avançar um quadro.
Quadro 12 - Implementação da ordem de apresentação das figuras no teste de compreensão da palavra
escrita
Na linha 64 é obtido um número de um a três, e em seguida é verificado seu valor para
atribuir o conteúdo correspondente às variáveis que armazenam as figuras. Na linha 81 é
possível observar que é gerado outro número randômico, devendo este ser diferente do
anterior, para então posicionar a segunda figura.
O Quadro 13 ilustra o trecho de código da página de teste de compreensão da palavra
escrita. Este código é implementado dentro de um componente repetidor, ou seja, para cada
uma das dez perguntas realizadas no teste são apresentados em tela três componentes do tipo
p:commandLink contendo as respostas (figuras) disponíveis.
60
Quadro 13 – Implementação da apresentação das figuras no teste de compreensão da palavra escrita
Nas linhas 46, 52 e 58, são implementados os métodos que escutam o clique sobre a
imagem. Ao clicar em uma das figuras, o método selecionouResp é chamado, recebendo
como parâmetro o identificador da imagem selecionada.
3.3.2.3 Implementação do objeto Controller
O objeto Controller é formado pelos pacotes dao e facade, sendo responsável pelas
transações com o banco de dados. No Quadro 14 são demonstrados os métodos findAll e
findById da classe RecursoDAO.
Quadro 14 – Implementação dos métodos findAll e findById da classe RecursoDAO
Na linha 19, o método findAll realiza a execução da query que retorna todos os
registros do tipo Recurso existentes na base de dados. O método findById efetua a pesquisa
de um recurso pelo identificador do registro, retornando o objeto resultante na linha 28. O
Quadro 15 ilustra as funções contidas na classe RecursoFacade, responsáveis pela chamada
aos métodos descritos anteriormente.
61
Quadro 15 – Implementação dos métodos findAll e findById da classe RecursoFacade
Os métodos da classe RecursoFacade são acionados pelas classes do pacote bean e
retornam resultados que serão apresentados ao usuário, sejam todos os recursos existentes ou
um específico para o caso de edição de registro.
3.3.2.4 Implementação do pacote util
O pacote util contém as classes auxiliares de diversas funcionalidades do sistema,
como exportação de contrato, autenticação no sistema e funções chamadas na execução das
regras de produção. Estas classes, em sua maioria, possuem métodos estáticos, não
necessitando da instância da classe para a chamada dos métodos, e podem ser acionadas a
partir de qualquer pacote da aplicação.
Os métodos auxiliares às regras de produção acionadas no teste de compreensão da
palavra escrita e na EOCA estão definidos na classe DroolsUtils. Um dos métodos desta
classe é o calcularHiperacomodativo, apresentado no Quadro 16.
Quadro 16 – Implementação do método calcularHiperacomodativo da classe DroolsUtils
Na linha 8 é instanciado o atributo somaHiperacom, que armazenará a quantidade de
características atendidas pelo paciente existentes no parâmetro quest. Nas linhas 10, 13, 16 e
19 é feita a validação das questões respondidas na EOCA de modo a incrementar o atributo
somaHiperacom a cada retorno positivo da validação. O mesmo procedimento é realizado nos
métodos calcularNormalidade, calcularHiperacomodativo,
calcularHiperassimilativo e calcularHipoassimilativo, cada um verificando os
62
atributos da classe EocaQuestionario que atendem os requisitos para a definição de uma
modalidade de aprendizagem.
O método calcularLateralidade é chamado na execução da regra de identificação
da lateralidade dominante do paciente. Este método é ilustrado no Quadro 17.
Quadro 17 – Implementação do método de cálculo de lateralidade dominante
Os três parâmetros recebidos pelo método calcularLateralidade contêm os
resultados dos testes individuais realizados pelo psicopedagogo, visto que são realizados três
testes para cada membro (pé, mão e olhos). Nas linhas 122, 127 e 132 é verificado se o
resultado de cada teste é igual a D, que representa a lateralidade “Direita”, incrementando,
então, o atributo contD, que armazena a quantidade de resultados “Direita” informados, ou o
atributo contE, que contém o total de resultados informados como “Esquerda”. Ao final do
método é retornada a letra indicativa da lateralidade, baseada no resultado da comparação
entre os atributos contD e contE. Na linha 144 é retornada a letra I, indicativa da lateralidade
“Indefinida”, quando em um dos testes o resultado diferir dos demais, por exemplo: D, D e E.
3.3.2.5 Implementação das regras de produção
As regras de produção utilizadas no cálculo dos resultados do teste de compreensão da
palavra escrita e da EOCA são acionadas pelas classes correspondentes no pacote bean. O
método salvarLateralidade, implementado na classe LateralidadeBean, efetua a
chamada às regras do arquivo Lateralidade.drl inserindo na base de conhecimentos o
objeto lateralidade com os resultados informados no teste, conforme demonstrado no
Quadro 18.
63
Quadro 18 – Acionamento das regras de produção do teste de lateralidade
Na classe Lateralidade.drl é calculado o resultado da lateralidade dominante
conforme o valor informado pelo usuário para cada membro avaliado do paciente. O Quadro
19 ilustra a regras que identificam a lateralidade esquerda e direita.
Quadro 19 – Trecho das regras de produção do teste de lateralidade
A classe Eoca.drl é responsável pela implementação das regras de cálculo do
resultado da Eoca. Nesta classe é definida uma regra para a verificação de cada modalidade de
aprendizagem resultante possível. No Quadro 20 são ilustrados os métodos Calcular
Hipoassimilativo e Calcular Hiperassimilativo.
Quadro 20 – Trecho das regras de produção do cálculo de resultado da EOCA
64
Nas linhas 15 a 18 e 26 a 29 são verificados os atributos referentes às características
identificadas no paciente pelo psicopedagogo durante a entrevista. Caso alguma seja
verdadeira, é efetuada a chamada ao método de cálculo da quantidade de características
atendidas para a modalidade de aprendizagem, apresentado no Quadro 17. Posteriormente é
identificada a modalidade com mais características atendidas e efetuado o cálculo da
probabilidade desta afirmação. Esta porcentagem é obtida também conforme a quantidade de
características marcadas pelo usuário, considerando a proporção das quatro características de
cada modalidade igual a 100%.
3.3.3 Operacionalidade da implementação
Nesta seção é demonstrado o funcionamento do protótipo a nível de usuário seguindo
um estudo de caso que simula o fluxo de utilização da aplicação. São apresentadas a seguir as
funcionalidades implementadas conforme casos de uso citados no capítulo 3.2.1.
Diante disto, as próximas subseções são divididas da seguinte forma: na seção 3.3.3.1 é
apresentada a página inicial do protótipo com as opções disponíveis ao usuário; na seção
3.3.3.2 é detalhada a operacionalidade do registro de contratos; as funcionalidades de registro
de planejamento e atendimento são apresentadas, respectivamente, nas seções 3.3.3.3 e
3.3.3.4; na seção 3.3.3.5 é demonstrada a operacionalidade das entrevistas anamnese e EOCA
e dos testes de lateralidade e de compreensão da palavra escrita; por fim, a funcionalidade
pertinente ao relatório de avaliação de paciente, contendo o histórico dos atendimentos e
observações registradas durante as sessões, é detalhada na seção 3.3.3.6.
3.3.3.1 Tela inicial do protótipo
Após informar o usuário e senha e clicar no botão Entrar, se o usuário estiver válido,
é apresentada a tela inicial do sistema, conforme ilustrado na Figura 22.
Figura 22 - Tela inicial do protótipo
65
Conforme pode-se observar na Figura 22, na página inicial são disponibilizadas ao
usuário as opções de registro de pacientes, recursos, atividades, edição de cadastro e, caso o
usuário seja administrador do sistema, registro de usuários. Na barra superior é exibido um
link para a tela inicial, identificado pela palavra Início, que está disponível em qualquer
página do protótipo. Também é exibida a data atual e uma mensagem de boas vindas ao
usuário. O link identificado pela palavra Sair efetua o logout do sistema, retornando à página
de login.
3.3.3.2 Edição de cadastro de psicopedagogo
O psicopedagogo pode editar seu cadastro através do acionamento do botão Meu
cadastro na página inicial, destacado na figura 21.
Figura 23 – Link para edição do cadastro de psicopedagogo
Na página de edição do cadastro, o psicopedagogo pode atualizar os dados de
endereço e contato da clínica, sua inscrição na Associação Brasileira de Psicopedagogia
(ABPp), seus documentos, utilizados na geração do contrato de prestação de serviços e
também sua senha de acesso ao sistema. Estes campos podem ser visualizados na Figura 24,
que ilustra a tela Meu cadastro.
66
Figura 24 – Formulário de edição de cadastro de psicopedagogo
3.3.3.3 Cadastro de contratos
A funcionalidade de registro de contratos é acionada pelo botão Contratos exibido na
lista de pacientes. A Figura 25 ilustra a lista de pacientes, onde na coluna Ação está disponível
o acesso à tela de contratos.
Figura 25 - Tela de consulta de pacientes
O acionamento do botão Contratos direciona o usuário à tela de consulta de contratos
de prestação de serviços a pacientes, firmados com os responsáveis das crianças atendidas.
Esta tela possibilita ao usuário a edição ou inativação do registro, além do cadastro de novos
contratos. A tela de consulta de contratos é ilustrada na Figura 26.
Figura 26 - Tela de consulta de contratos
67
Na lista de contratos são exibidas as colunas Título, Data atualização e Ação. O
botão identificado pelo símbolo + permite o vínculo de novos contratos de prestação de
serviços a um usuário. O botão identificado por um lápis, exibido na coluna Ação, permite a
edição de um contrato, e o segundo botão desta coluna, quando acionado, efetua a inativação
do contrato, removendo-o da lista de contratos. A Figura 27 ilustra a tela de edição de
contratos, onde são requisitados os campos Título e Descrição.
Figura 27 – Tela de edição de contrato
Ao acessar esta tela, são apresentadas ao usuário as informações da parte contratante,
no caso, o familiar marcado como responsável do paciente no cadastro de familiar. O campo
Descrição é expansível e não possui limite de caracteres para gravação. O botão Baixar
docx realiza o download de um documento para visualização com o programa Microsoft
Word, com extensão docx, contendo, além das informações de título e descrição, a descrição
das partes contratadas através da associação do familiar indicado como responsável e das
informações do psicopedagogo registradas no cadastro do mesmo através do botão Meu
cadastro, implementado na tela apresentada na Figura 22. A Figura 28 apresenta o arquivo
exportado pelo sistema e gravado automaticamente na pasta de downloads do usuário.
68
Figura 28 – Documento exportado pelo protótipo na funcionalidade Baixar docx
O arquivo exportado é gravado automaticamente na pasta de downloads do usuário.
Além das partes citadas no contrato (contratante e contratada), é exibida a data de gravação do
registro e são montados dinamicamente os campos para assinatura das partes associadas ao
contrato.
3.3.3.4 Registro de planejamentos
O registro de planejamentos para sessões de atendimento a um paciente pode ser
realizado através da funcionalidade acionada pelo botão Avaliação da tela de consulta de
pacientes (Figura 25). Este botão direciona o usuário à página de edição do registro do
paciente, que além do formulário com as informações do paciente, também apresenta as
opções relativas às atividades do psicopedagogo para com o paciente, conforme demonstrado
na Figura 29.
69
Figura 29 – Tela de edição de cadastro de paciente e registro de avaliação
O acionamento do botão Planejamentos, visualizado na Figura 29, direciona o
usuário à tela de consulta de planejamentos do paciente selecionado. Nesta tela, o usuário
deve informar a data do atendimento para o qual está registrando o planejamento, o objetivo e
a descrição das ações planejadas para a sessão. Também deve ser selecionada a atividade a ser
realizada dentre as opções existentes no campo Atividade. Os registros existentes neste
componente são obtidos pela consulta às atividades cadastradas anteriormente na tela de
recursos, acessada pelo botão Recursos disponível na tela inicial do protótipo, conforme
Figura 22.
O mesmo procedimento deve ser realizado para o campo Recursos, que dispõe para
seleção os recursos já cadastrados pelo usuário, porém neste campo pode ser selecionado mais
de um recurso a ser utilizado no atendimento. Durante a edição de um planejamento, é
possível inativá-lo, através do botão Inativar, removendo-o da lista de planejamentos de
determinado paciente.
3.3.3.5 Registro de atendimentos
Para acessar a funcionalidade de consulta de atendimentos realizados com pacientes, é
necessário acionar o botão Atendimentos na tela de edição de pacientes ilustrada na Figura
29. O registro de atendimentos oferece as mesmas operações do registro de planejamentos
(inclusão, edição e inativação), porém difere pelo campo Observações e pelo mecanismo de
consulta aos planejamentos já cadastrados através de uma data, de forma a sugerir ao usuário
um ou mais planejamentos para preenchimento do formulário de registro de atendimento.
Após informar a data de atendimento, o usuário deve clicar no botão Ok, e em seguida, se
houver planejamentos cadastrados para o paciente na data informada, é apresentada uma
janela com a lista dos registros para seleção, conforme Figura 30.
70
Figura 30 – Tela de seleção de planejamento para registro de atendimento
A janela com título Carregar planejamentos apresenta as informações do(s)
planejamento(s) encontrados e oferece ao usuário a possibilidade de seleção do registro
através do acionamento do botão Ok, exibido na coluna Ação. Ao selecionar um registro desta
lista, o formulário de registro de atendimento é atualizado com as informações do
planejamento escolhido, permitindo a alteração dos campos pelo usuário. As alterações
realizadas a partir deste momento não refletirão no planejamento original, apenas no
atendimento a ser gravado.
3.3.3.6 Entrevistas e testes
Nesta seção estão detalhadas as funcionalidades referentes às entrevistas e testes
disponíveis no protótipo. Na seção 3.3.3.5.1 é apresentada a utilização da tela de registro de
anamnese com o paciente. Na sessão seguinte é demonstrada a utilização da página de registro
da Entrevista Operativa Centrada na Aprendizagem (EOCA). A funcionalidade relativa ao
teste de lateralidade do paciente é apresentada na seção 3.3.3.5.3. Na última subseção é
demonstrado o funcionamento do teste de compreensão da palavra escrita.
Estas funcionalidades, assim como as operações de registro de planejamento e
atendimento, podem ser acessadas pela tela de consulta de pacientes, através dos botões
identificados pelos nomes das operações, conforme ilustrado na Figura 29.
3.3.3.6.1 Entrevista de anamnese
O protótipo disponibiliza um formulário para realização da anamnese, onde são
apresentadas as questões de histórico do paciente comumente utilizadas na entrevista. A
entrevista se divide em 8 subáreas com suas respectivas perguntas, representadas por abas no
formulário. São elas: concepção, sono, alimentação, desenvolvimento/evolução, escolaridade,
rotina, histórico clínico e família. As questões da entrevista foi adaptado a partir dos
71
formulários das psicopedagogas e outros modelos encontrados em pesquisas. A Figura 31
ilustra o formulário de realização da anamnese, cuja aba em evidência é a subárea de
concepção.
Figura 31 – Tela de registro de anamnese – Aba Concepção
As questões estão numeradas para facilitar a leitura durante a realização da entrevista.
É disponibilizado um campo, sem limites de caracteres para gravação, para registro das
observações em cada subárea da anamnese. As demais abas do formulário de anamnese estão
ilustradas no Apêndice C.
3.3.3.6.2 EOCA
A tela responsável pelo registro da EOCA é acionada no formulário de pacientes,
apresentado na Figura 29, através do botão EOCA. Nesta tela o psicopedagogo registrará suas
observações durante a interação com o paciente, quando solicita a realização de atividades
como desenhos e jogos. Enquanto o paciente executa as atividades, o psicopedagogo
perceberá os comportamentos apresentados e selecionará na tela as características
correspondentes a cada modalidade de aprendizagem, além de registrar as observações destas
atividades no campo Observações.
A ordem dos grupos ou modalidades apresentados é: Normalidade, Hipoassimilativa,
Hiperassimilativa, Hipoacomodativa e Hiperacomodativa. No formulário de registro da
EOCA são apresentados cinco grupos com quatro características. Os grupos representam as
72
modalidades de aprendizagem existentes para um paciente. A Figura 32 demonstra a tela de
registro da EOCA.
Figura 32 – Tela de registro de EOCA
Não houve necessidade de apresentar as modalidades em tela devido ao psicopedagogo
possuir conhecimento das características de cada modalidade, porém, ao salvar o registro, é
apresentada a modalidade resultante com base nas características selecionadas. Na Figura 32
percebe-se que estão selecionadas duas características do grupo “Normalidade”, uma
característica do segundo grupo e outra do terceiro grupo, de forma que a modalidade de
aprendizagem resultante é Normalidade. Para o cálculo do resultado o protótipo considera
apenas a modalidade com mais características atendidas, neste caso a modalidade
“Normalidade”. A probabilidade é igual a 50% devido ao atendimento de duas das quatro
características existentes no grupo.
3.3.3.6.3 Teste de lateralidade
O teste de lateralidade disponibilizado no protótipo permite a identificação da
lateralidade dominante de um paciente através do registro das observações durante os testes
motores. No formulário do teste é apresentada uma tabela com três linhas e três colunas, além
da linha e coluna de identificação, onde as linhas representam os membros avaliados, e as
73
colunas, a ordem dos testes, realizados três vezes para cada membro. A Figura 33 ilustra o
formulário referente ao teste de lateralidade.
Figura 33 – Tela de realização de teste de lateralidade
Na situação apresentada na Figura 33 foi identificada lateralidade esquerda nos três
testes para o pé do paciente, lateralidade esquerda no primeiro teste de mão e direita nos dois
seguintes, e lateralidade direita em todos os testes de olho. Desta forma, a lateralidade para o
pé resultou em Esquerda, pois não houve manifestação do pé direito em todos os testes.
Resultado semelhante ocorreu para o olho, onde não foi manifestada utilização do olho
esquerdo nos testes. Já a lateralidade para a mão resultou em Indefinida, pois houve indecisão
por parte do paciente no uso das mãos nos testes realizados.
A lateralidade dominante é calculada com base nos resultados individuais dos
membros. Conforme Figura 33, foram apresentados resultados diferentes para cada membro,
ocasionando a lateralidade dominante cruzada. Caso todos os resultados individuais sejam
indefinidos, a lateralidade dominante será também Indefinida. O mesmo ocorre para a
predominância dos resultados individuais de lateralidade esquerda e direita.
3.3.3.6.4 Teste de compreensão da palavra escrita
O teste de compreensão da palavra escrita baseia-se em quadros contendo um nome de
animal e três imagens de animais, sendo uma a correspondente à palavra. São apresentados
dez quadros com diferentes nomes de animais e as figuras são ordenadas aleatoriamente a
cada questão, evitando possíveis acertos por respostas por impulso ou “chutes”. A Figura 34
ilustra um dos quadros do teste.
74
Figura 34 – Quadro do teste de compreensão da palavra escrita
Neste teste o usuário deve selecionar a figura correspondente à palavra apresentada na
parte superior da tela. Conforme visualizado na Figura 34, caso o usuário selecione a imagem
correta, é apresentada uma mensagem informando o resultado e deve-se clicar no botão
indicado pela seta », que direciona ao próximo quadro.
Ao finalizar o teste, é calculada a pontuação conforme a quantidade de acertos do
usuário, sendo 100 a pontuação máxima. Na página de resultado do teste de compreensão da
palavra escrita são detalhadas as questões e a indicação do resultado da resposta. Também é
apresentada a pontuação final do teste contabilizando as respostas corretas dos dez quadros.
3.3.3.7 Relatório de avaliação de paciente
O botão Relatório/Histórico, disponível na tela de consulta de pacientes (Figura
25), direciona o usuário à tela de Relatório de avaliação de paciente. Nesta página são
apresentadas informações dos atendimentos, entrevistas e testes realizados com o paciente. A
Figura 35 demonstra o conteúdo do relatório.
Figura 35 – Relatório de avaliação de paciente – Histórico de atendimentos
75
Na parte superior da tela são informados o nome do paciente, seu nascimento e a data
do primeiro atendimento. Logo abaixo é apresentada uma lista com o histórico de
atendimentos do paciente. Esta lista é semelhante à disponibilizada na tela de consulta de
atendimentos. No relatório de avaliação ainda são apresentadas as abas Anamnese, EOCA e
Demais informações, cujo conteúdo é apresentado na Figura 36.
Figura 36 – Relatório de avaliação de paciente
Na aba Anamnese são detalhadas, caso preenchidas, as observações informadas nos
campos de texto livre disponíveis para cada subárea no registro da entrevista de anamnese. Na
Figura 36 é ilustrado um caso em que estão preenchidas as observações das áreas de
escolaridade, família e sono. O resultado da EOCA, bem como a data de realização e as
observações registradas pelo psicopedagogo durante a entrevista com o paciente, é
demonstrado na aba EOCA. Na aba Demais Informações é apresentado o resultado do teste de
lateralidade e a pontuação do teste de compreensão da palavra escrita.
3.4 RESULTADOS E DISCUSSÕES
O objetivo deste trabalho foi desenvolver uma solução que facilite a realização da
avaliação psicopedagógica clínica de crianças em fase de alfabetização e com dificuldades de
aprendizagem. Com este trabalho, pretendia-se propiciar ao psicopedagogo que trabalha em
consultório a organização de suas ferramentas de trabalho, a redução do tempo e espaço
dispendidos com registros manuais e possibilitar ao profissional maior dedicação às tarefas
cruciais de diagnóstico e intervenção psicopedagógicos.
76
O protótipo desenvolvido atendeu o objetivo de auxiliar o profissional na avaliação do
paciente e também disponibilizou funcionalidades pertinentes aos atendimentos em geral, não
restringindo a utilização apenas para um grupo seleto de pacientes. Inicialmente o objetivo
principal era automatizar diversos testes utilizados na avaliação psicopedagógica, porém
durante o desenvolvimento do trabalho foram identificadas necessidades prioritárias destes
profissionais. Levando em consideração que cada psicopedagogo possui uma forma de
trabalhar e que aplicam diferentes materiais na fase de avaliação, foi percebida a oportunidade
de oferecer uma solução com ferramentas úteis a toda a classe de psicopedagogos.
Desta forma, apesar do objetivo inicial estar focado na etapa de avaliação, os requisitos
implementados na aplicação abrangeram também as fases de planejamento e atendimento
psicopedagógico, proporcionando maior autonomia para o profissional durante seu trabalho.
Os objetivos específicos propostos, citados na seção 1.1, também foram atendidos. As
informações pertinentes ao domínio psicopedagógico foram coletadas com especialistas da
área de psicopedagogia desde a fase de concepção do protótipo, direcionando o
desenvolvimento para a real necessidade destes profissionais.
Por meio das informações obtidas, foi percebida a gama de instrumentos necessários
para um atendimento psicopedagógico, considerando a individualidade de cada paciente.
Também foi identificada a dependência de documentos manuais, como roteiros e arquivos,
que conservam os registros dos pacientes, planejamentos e relatórios de avaliação. Assim,
acredita-se que foi possível contribuir com a redução da preocupação do psicopedagogo com
estes registros, de forma a otimizar o tempo de atendimento e avaliação do paciente.
Conforme proposto inicialmente, o protótipo disponibiliza informações para apoio ao
profissional na avaliação de pacientes atendidos na clínica.
3.4.1 Avaliação do protótipo
O protótipo foi disponibilizado para a avaliação de três psicopedagogas da área clínica
da cidade de Blumenau em dois momentos do trabalho. A primeira avaliação foi parcial e teve
como objetivo captar sugestões de novas funcionalidades e melhorias nas já desenvolvidas.
Na avaliação final foi apresentada a versão atualizada do protótipo, a fim de confrontar a
versão final e sua aplicabilidade e obter considerações para trabalhos futuros.
Na primeira avaliação, foram disponibilizadas imagens das telas desenvolvidas e
solicitadas sugestões de testes na área da avaliação psicopedagógica que pudessem ser
automatizados. Na segunda avaliação, a versão resultante do protótipo foi apresentada em um
notebook com o banco de dados MySQL e com a aplicação inicializada no servidor Tomcat 7.
77
As psicopedagogas executaram todos os casos de uso do protótipo com uma breve orientação
sobre seu funcionamento e posteriormente responderam a um questionário qualitativo com
perguntas sobre a usabilidade e praticidade. O questionário utilizado é apresentado no
Apêndice B.
Com relação às funcionalidades, as psicopedagogas avaliaram como práticas e úteis
para a otimização do tempo de atendimento. O protótipo também foi avaliado como intuitivo,
produtivo e concentrado, de forma a focar a atenção do profissional nas atividades específicas.
Foi comentado que as opções estão bem visíveis, organizadas e objetivas, porém pode ser
melhorada a separação entre as funcionalidades de avaliação e de atendimento através do
reposicionamento dos botões de acesso na tela de pacientes. Uma das avaliadoras também
apresentou desorientação no cadastro de planejamentos e atendimentos, que inspiram
duplicidade devido à semelhança dos campos.
Quanto ao leiaute, as avaliadoras classificaram como limpo e claro, ideal para o
objetivo da aplicação. O desempenho foi avaliado como rápido. A ideia proposta foi
considerada inovadora, visto que a área de psicopedagogia é recente e não há intenso interesse
no desenvolvimento de aplicações voltadas a este campo.
Foi mencionado que o sistema está atendendo boa parte do dia a dia do profissional da
área clínica, possibilitando seu uso com todos os pacientes, o que favorece todos os
envolvidos no processo psicopedagógico. Quando questionadas sobre a porcentagem das
atividades realizadas pelo psicopedagogo, hoje manualmente, nos consultórios, desde o
processo de atendimento até a intervenção, compreendidas pelo sistema, as entrevistadas
responderam os valores apresentados na Tabela 1.
Tabela 1 - Porcentagem de atividades realizadas hoje manualmente compreendidas pelo protótipo
Avaliadora Atendimento Avaliação
Entrevistada 1 80% 25%
Entrevistada 2 60% 50%
Entrevistada 3 90% 30%
Média 76,6% 35%
Os percentuais foram informados considerando as funcionalidades de duas áreas:
a) o atendimento psicopedagógico, compreendido no protótipo pelos registros de
pacientes, planejamentos (considerado a base para todo o processo), atendimento e
contratos. Trata-se das atividades rotineiras do profissional, realizadas em todas as
fases do trabalho psicopedagógico e voltadas à organização e gerenciamento do
consultório;
b) a avaliação psicopedagógica, abrangida pelas entrevistas de anamnese e EOCA e
78
pelos testes de lateralidade e de compreensão da palavra escrita. A avaliação
requer diversos instrumentos, manuais ou não, que para seu uso é considerada a
individualidade de cada paciente.
Considerando o valor médio informado pelas entrevistadas, 76,6% de todos os
procedimentos psicopedagógicos realizados manualmente no atendimento clínico foram
automatizados no protótipo desenvolvido. A média de abrangência do protótipo na área de
avaliação psicopedagógica, segundo as entrevistadas, é de 35%. Os valores obtidos são
considerados expressivos para um protótipo.
Considerando as opções muito bom, bom, mediano e ruim, o sistema foi avaliado
como muito bom por duas profissionais e bom por uma profissional, que percebe a
necessidade de mais funcionalidades de forma que a aplicação compreenda cerca de 90% do
trabalho realizado na clínica. As psicopedagogas relataram que, com o uso do sistema, seria
obtida grande economia de tempo na transcrição das informações de entrevistas e registro e
organização de planejamentos, redução da utilização de papel com impressões de roteiros e
modelos de questionários e entrevistas e melhor aproveitamento do espaço físico do
consultório devido ao registro digital dos documentos, que hoje são armazenados em arquivos
por cerca de cinco anos.
3.4.2 Sugestões obtidas
A principal sugestão obtida com as psicopedagogas que avaliaram o sistema foi de
ampliação do sistema, incluindo novos testes na fase de avaliação. Um dos testes sugeridos
foi o Teste de Desempenho Escolar (TDE), de forma que o sistema disponibilizasse o registro
dos resultados dos testes de escrita, aritmética e leitura existentes no TDE e efetuasse o
cálculo do nível de aprendizagem do paciente. Foi apontada a possibilidade de implementação
de algum teste de coordenação motora, que indicasse a firmeza da mão e o nível motor do
paciente.
Outra funcionalidade indicada foi a de assinalar os resultados dos testes piagetianos,
realizados impreterivelmente com material concreto, informando em quadros, para cada um
dos testes, a idade mental ou fase de pensamento atual do paciente. Também foi sugerida a
exibição do resultado de cada questão do teste de compreensão de palavra escrita através de
símbolos visuais, como desenhos intuitivos, ou som de palmas, de forma a facilitar a
identificação do erro ou acerto pela própria criança que realiza o teste.
As psicopedagogas citaram a necessidade de um sistema em que as informações sejam
registradas e disponibilizadas ao profissional em forma de relatório, com os resultados já
79
prontos para a devolutiva aos pais do paciente. Também foi sugerida a criação de uma agenda
ou calendário onde fosse possível visualizar e registrar os agendamentos diretamente pela
secretária da clínica, possibilitando o alinhamento entre os funcionários e a organização do
próprio psicopedagogo. Além disso, foi ressaltado o interesse em um módulo financeiro para
controle de pagamentos, vinculado a cada atendimento, que hoje é realizado pela secretaria da
clínica.
3.4.3 Dificuldades encontradas
As ferramentas utilizadas, em sua maioria, geraram bons resultados. O
desenvolvimento foi facilitado pela linguagem Java e sua estrutura web com a biblioteca
Primefaces, que dispõe de diversos componentes e temas úteis na interface gráfica. Também
não houve problemas com o MySQL e o framework Hibernate, de forma que os códigos de
persistência de dados e comunicação com o SGBD foram desenvolvidos sem problemas
acentuados.
As principais dificuldades encontradas foram na implementação do motor de
inferências, cuja ferramenta escolhida inicialmente foi o JEOPS. Foi considerado que, por
tratar-se de uma ferramenta brasileira, haveria vasta documentação, no idioma português, na
internet, porém, ao iniciar as pesquisas, não foram encontradas referências claras suficientes
para o início do desenvolvimento com esta ferramenta. Diante disto, foi decidida a alteração
do motor de inferências para a ferramenta JBoss Drools, que, apesar de mantida por uma
empresa internacional, oferece diversos documentos e tutoriais de aplicação da mesma em
sistemas com características semelhantes às existentes neste trabalho.
Também foi considerada a possibilidade de migração do servidor Tomcat 7 para o
JBoss 7 para futura ampliação do protótipo, porém alguns fatores impossibilitaram esta
migração. Inicialmente ocorreram problemas ao adequar os arquivos de configuração do
JBoss aos já existentes no Tomcat, porém, após a resolução destes, foi identificada, e
posteriormente confirmada, uma incompatibilidade da versão 7 do servidor JBoss com a
versão 8 do Java Development Kit (JDK). Desta forma, seria necessário utilizar a nova versão
do JBoss, o WildFly, porém a esta altura não houve tempo hábil para a migração.
3.4.4 Comparativo entre o protótipo e os trabalhos correlatos
Conforme critérios definidos na seção 2.3.5, onde foram apresentados os trabalhos
correlatos ao protótipo desenvolvido, o Quadro 21 descreve o comparativo entre estes
trabalhos e o atual.
80
Quadro 21 – Comparativo entre o protótipo desenvolvido e seus trabalhos correlatos
Critério Hippocrates
(2010)
Pré-d1scalc
(2014)
Roseta
(2012)
X-Dyslex
(2001)
Protótipo
desenvolvido
(2015)
Plataforma Desktop Desktop Web Desktop Web
Tecnologias Swing Swing
JSF,
RichFaces,
REST
Flash,
ActionScript
JSF,
PrimeFaces,
Hibernate, CSS
Implementa-
ção de regras Drools JEOPS Drools Não se aplica Drools
Banco de
dados Não Não Não Não Sim
Área de
diagnóstico
Pacientes com
sintomas
variados
Crianças de
10 a 12 anos
em processo
de
alfabetização
Crianças
com déficit
cognitivo
Crianças com
dificuldade de
aprendizagem
na fase de
alfabetização
Crianças com
dificuldade de
aprendizagem
na fase de
alfabetização
Público alvo Estudantes de
Medicina
Profissionais
de educação
e psicólogos
Psicólogos
e
Psicopeda-
gogos
Psicólogos,
psicopedagogos
e professores de
séries iniciais
Psicopedagogos
clínicos
Domínio
Medicina –
Doenças em
geral
Discalculia
Jogos
psicopeda-
gógicos
Dislexia
Atendimento e
avaliação
psicopedagógica
Com relação à plataforma, apenas o trabalho Roseta (2012) foi implementado para
web, assim como o protótipo desenvolvido. Os demais trabalhos foram desenvolvidos para
desktop. Apesar de ambos, Roseta e o trabalho atual, aplicarem JSF na camada web, o
diferencial do trabalho atual é a utilização da biblioteca Primefaces para a interface gráfica.
Quanto às tecnologias utilizadas, há grande variação entre os demais trabalhos e o protótipo
desenvolvido devido ao objetivo de cada trabalho.
Dois dos trabalhos correlatos implementaram as regras de produção com a ferramenta
Drools, sendo que o Pré-d1scalc (2014) utilizou o recurso JEOPS e o X-Dyslex (2001) não
utilizou ferramenta específica como motor de inferências. Pode-se perceber que nenhum dos
trabalhos correlatos utilizou banco de dados para persistência dos dados transmitidos.
Entretanto, o protótipo atual oferece o mecanismo de gravação e consulta dos registros
manipulados pelo sistema e armazenados em uma base de dados.
Os trabalhos Pré-d1scalc (2014), Roseta (2012) e X-Dyslex (2001) se assemelham ao
atual no critério área de diagnóstico, pois são voltados a crianças com algum déficit de
aprendizagem ou em processo de alfabetização. Contudo, o trabalho X-Dyslex (2001), assim
como o protótipo atual, foi desenvolvido para uso de crianças em fase de alfabetização e com
81
dificuldades de aprendizagem, divergindo do atual no público-alvo, que é mais amplo e inclui
psicólogos, e no domínio, que é limitado ao distúrbio de dislexia. O público-alvo do trabalho
atual é concentrado na área clínica da psicopedagogia, porém Roseta (2012) e X-Dyslex
(2001) não fazem distinção da área de estudo da psicopedagogia por oferecerem atividades
realizadas pelas próprias crianças, estando seu uso voltado aos pacientes e não aos
profissionais.
82
4 CONCLUSÕES
O campo da psicopedagogia, apesar de recente, vem crescendo e sendo cada vez mais
útil no tratamento de dificuldades de aprendizagem em crianças. A cada ano, novos
profissionais são formados em psicopedagogia clínica e boa parte é inserida em clínicas que
oferecem atendimento multidisciplinar, trabalhando em conjunto com psicólogos,
fisioterapeutas, fonoaudiólogos, etc.
O presente trabalho visava implementar, através dos conhecimentos obtidos com
profissionais da área, um sistema que oferecesse ao psicopedagogo informações organizadas
referentes à avaliação de pacientes, centralizando estas em uma aplicação intuitiva e
inteligente. Desta forma, o objetivo geral e os específicos foram atendidos, visto que o
protótipo foi implementado conforme as sugestões obtidas pelos profissionais através de
funcionalidades informatizadas que reduzem o tempo gasto pelo psicopedagogo com registros
manuais. A solução desenvolvida também disponibiliza um relatório com todas as atividades
realizadas com cada paciente desde o primeiro atendimento.
Diante disto, percebe-se que o trabalho voltou-se não apenas à avaliação
psicopedagógica, mas também, e em maior parte, ao atendimento em si, ao dia a dia do
profissional, facilitando as operações diárias do mesmo, realizadas com pacientes com
diversas características devido à abrangência das funcionalidades.
Apesar da escassez de trabalhos semelhantes a este no mercado, através das avaliações
das psicopedagogas identificou-se uma necessidade de ampliação do sistema para que este
atenda quase integralmente a fase de avaliação psicopedagógica por meio da inclusão de
novos testes, citados na seção 3.4.2. Contudo, os resultados finais foram satisfatórios e
entende-se que atingiram as maiores necessidades dos profissionais da área.
4.1 EXTENSÕES
Durante o desenvolvimento deste trabalho foram identificadas oportunidades de
melhorias futuras. De acordo com as sugestões citadas na seção 3.4.2, indica-se a criação de
um calendário para agendamento de horários para pacientes visível para a secretaria e
psicopedagogo, com indicador de comparecimento. Também se sugere a criação de um
módulo financeiro que efetue o controle de pagamentos dos atendimentos.
Além disso, as extensões possíveis para o presente trabalho são voltadas à área de
avaliação psicopedagógica, podendo ser implementados novos testes e provas dirigidas às
crianças em fase de alfabetização, também usufruindo de regras de produção. Nesta linha,
83
sugere-se a migração e validação do protótipo para a utilização de design responsivo,
permitindo a realização destes testes pelos próprios pacientes através de tablets ou
equipamentos semelhantes, disponibilizados pelos profissionais na clínica psicopedagógica
visando mediação lúdica. Como alternativa indica-se a implementação de importação de
resultados de testes e jogos de outra aplicação, melhor integrando as ferramentas de
atendimento e avaliação.
Por fim, é percebida a possibilidade de impressão da entrevista de anamnese em
formato de formulário e exportação dos dados de um paciente para um arquivo semelhante a
um prontuário, com conteúdo semelhante ao relatório de avaliação. Outra extensão sugerida é
a associação de arquivos digitalizados de pacientes, em formato de anexos, contendo
informações de laudos ou documentos de interesse do profissional. Propõe-se também a
implementação de exportação do relatório de avaliação em um documento de texto que possa
ser complementado pelo psicopedagogo para a realização da devolutiva aos pais.
84
REFERÊNCIAS
ACAMPORA, Bianca. Psicopedagogia Clínica: O Despertar das Potencialidades. 2. ed. Rio
de Janeiro: Wak, 2013.
ANDRADE, Danyllo G. F. de et al. Pré-d1scalc: Sistema Especialista para o Pré-diagnóstico
da Discalculia em Crianças. In: Simpósio de Excelência em Gestão e Tecnologia, 11., 2014,
Resende. Anais eletrônicos... Resende: AEDB, [2014]. p. 1-9. Disponível em:
<http://www.aedb.br/seget/arquivos/artigos14/12620210.pdf>. Acesso em: 17 nov. 2015.
ASSOCIAÇÃO BRASILEIRA DE PSICOPEDAGOGIA. Código de ética do
psicopedagogo. [São Paulo], 2011. Disponível em: <http://www.abpp.com.br/codigo-de-
etica-do-psicopedagogo>. Acesso em: 17 nov. 2015.
AZEVEDO, Simone M. de. É preciso diferenciar problemas de aprendizagem de
dificuldades de aprendizagem. Portal do Professor: [S.I], 11 jul. 2014. Disponível em:
<http://portaldoprofessor.mec.gov.br/conteudoJornal.html?idConteudo=3390>. Acesso em:
23 nov. 2015. Entrevista concedida ao Jornal do Professor.
BARRETO, Luiz R.; PREZOTO, Marcelo G. Introdução a sistemas especialistas. Limeira,
2010. Disponível em:
<http://www.ft.unicamp.br/liag/wp/monografias/monografias/2010_IA_FT_UNICAMP_siste
masEspecialistas.pdf>. Acesso em: 18 nov. 2015.
BARROS, Jussara de. Dificuldades de aprendizagem. [S.I.], [2009?]. Disponível em:
<http://www.brasilescola.com/educacao/dificuldades-aprendizagem.htm>. Acesso em: 18
nov. 2015.
BITTENCOURT, Guilherme. Inteligência artificial: ferramentas e teorias. 3. ed.
Florianópolis: Editora da UFSC, 2006.
BRASIL. Ministério da Educação. Secretaria de Educação Especial. Educação infantil:
saberes e práticas da inclusão: dificuldades acentuadas de aprendizagem ou limitações no
processo de desenvolvimento. Brasília: MEC, Secretaria de Educação Especial, 2006. 65 p.
Disponível em:
<http://portal.mec.gov.br/seesp/arquivos/pdf/dificuldadesdeaprendizagem.pdf>. Acesso em:
17 nov. 2015.
CAELUM. MVC – Model View Controller. [S.I.], [2009?]. Disponível em:
<http://www.caelum.com.br/apostila-java-web/mvc-model-view-controller/#9-12-model-
view-controller>. Acesso em: 18 nov. 2015.
CÂMARA, Marco S. A. L. Inteligência artificial: representação do conhecimento. Coimbra,
2001. Disponível em: <https://student.dei.uc.pt/~mcamara/artigos/inteligencia_artificial.pdf>.
Acesso em: 18 nov. 2015.
CARVALHO, Fabrícia B. de; CRENITTE, Patrícia A. P.; CIASCA, Sylvia M. Distúrbios de
aprendizagem na visão do professor. Revista da Associação Brasileira de Psicopedagogia.
São Paulo, v. 24, n. 75, p. 229-239, nov. 2007. Disponível em:
<http://www.revistapsicopedagogia.com.br/download/75.pdf>. Acesso em: 17 nov. 2015.
CHAMAT, Leila S. J. Diagnóstico psicopedagógico. São Paulo: Vetor, 2004.
CIPRIANO, Thais B. de S. Diagnóstico psicopedagógico. Campo Grande, 2011. Disponível
em: <https://www.portaleducacao.com.br/pedagogia/artigos/10325/diagnostico-
psicopedagogico>. Acesso em: 18 nov. 2015.
85
COLONER, Teresa; MASOT, M. Teresa; NAVARRO, Isabel. A avaliação psicopedagógica.
In: SÁNCHEZ-CANO, Manuel; BONALS, Joan (Org.). Avaliação psicopedagógica.
Tradução Fátima Murad. São Paulo: Artmed, 2008. p. 15-23.
COMA, Ramon; Álvarez, Lluís. Técnicas e instrumentos de avaliação psicopedagógica. In:
SÁNCHEZ-CANO, Manuel; BONALS, Joan (Org.). Avaliação psicopedagógica. Tradução
Fátima Murad. São Paulo: Artmed, 2008. p. 44-63.
FÁVERO, Alexandre J.; SANTOS, Nilson M. dos. O estado da arte. [S.I], [2000a].
Disponível em: < http://www.din.uem.br/ia/especialistas/arte.html>. Acesso em: 18 nov.
2015.
_____. Sistemas Especialistas. [S.I], [2000b]. Disponível em:
<http://www.din.uem.br/ia/especialistas/elementos.html>. Acesso em: 17 nov. 2015.
FIGUEIRA FILHO, Carlos S. da. JEOPS – The Java Embededd Object Production System.
Recife, 2007. Disponível em: <http://www.cin.ufpe.br/~jeops>. Acesso em: 19 nov. 2015.
FIORENZANO, Giane. Diagnóstico psicopedagógico. [S.I], 2012. Disponível em:
<http://espacoaprendente.blogspot.com.br/2012/09/diagnostico-psicopedagogico.html>.
Acesso em: 17 nov. 2015.
GONÇALVES, Luciana dos S. Psicopedagogia: formação, identidade e atuação profissional.
2007. 71 f. Monografia (Especialização em Educação e Psicopegagogia) – Faculdade de
Educação, Pontifícia Universidade Católica de Campinas, Campinas. Disponível em:
<http://bibliotecadigital.puc-
campinas.edu.br/services/monografias/Luciana%20dos%20Santos%20Goncalves.pdf. Acesso
em: 17 nov. 2015.
HEINZLE, Roberto. Protótipo de uma ferramenta para criação de sistemas especialistas
baseados em regras de produção. 1995. 145 f. Dissertação (Mestrado em Engenharia) –
Curso de Pós-graduação em Engenharia de Produção, Universidade Federal de Santa
Catarina, Florianópolis.
IGEA, Bento del R. (Org.). Presente e futuro do trabalho psicopedagógico. Tradução
Antonio Feltrin. Porto Alegre: Artmed, 2005.
JBOSS. Drools Expert User Guide. [S.I], [2011]. Disponível em:
<https://docs.jboss.org/drools/release/5.2.0.CR1/drools-expert-docs/html_single>. Acesso em:
18 nov. 2015.
KAUARK, Fabiana da S.; SILVA, Valéria A. dos S. Dificuldades de aprendizagem nas séries
iniciais do ensino fundamental e ações psico & pedagógicas. Revista da Associação
Brasileira de Psicopedagogia. São Paulo, v. 25, n. 78, p. 264-270, out. 2008. Disponível em:
<http://www.revistapsicopedagogia.com.br/download/78.pdf>. Acesso em: 17 nov. 2015.
KWIECINSKI, Inês M. História de vida ou anamnese psicopedagógica. Alvorada, 2012.
Disponível em: <http://psico09.blogspot.com.br/2012/03/historia-de-vida-ou-
anamnese.html>. Acesso em: 17 nov. 2015.
LIU, Rafael. JBoss Drools 5 – Java Magazine 88. [S.I], [2011]. Disponível em:
<http://www.devmedia.com.br/jboss-drools-5-java-magazine-88/19270>. Acesso em: 18 nov.
2015.
MALUF, Maria I. Crianças com dificuldade de aprendizagem. [São Paulo], 2013.
Disponível em: <http://direcionalescolas.com.br/2013/12/10/criancas-com-dificuldade-de-
aprendizagem>. Acesso em: 17 nov. 2015.
86
MARICATO, Cristiane C. Psicopedagogia Clínica X Institucional: Do que se trata?
[Campo Grande], 2013. Disponível em:
<http://www.portaleducacao.com.br/pedagogia/artigos/30071/psicopedagogia-clinica-x-
institucional-do-que-se-trata>. Acesso em: 17 nov. 2015.
_____. Transtornos psicomotores. [S.I], 2010. Disponível em:
<http://carminatimaricato.blogspot.com.br/2010/04/voce-tem-boa-percepcao-visual-
entao_10.html>. Acesso em: 08 dez. 2015.
MIRANDA JR., Pasteur O de. Sistemas especialistas. [Belo Horizonte], [2012?]. Disponível
em: <http://www.tesestec.com.br/pasteurjr/sistesp.pdf>. Acesso em: 17 nov. 2015.
MORAES, André L. A. de. Roseta: Infraestrutura computacional para construção de
ambientes de avaliação cognitiva através de jogos psicopedagógicos. 2012. 172 f. Dissertação
(Mestrado em Informática) - Programa de Pós-graduação em Informática (PPGI),
Universidade Federal do Rio de Janeiro, Rio de Janeiro. Disponível em:
<http://www.nce.ufrj.br/ginape/publicacoes/dissertacoes/d_2012/d_2012_andre_luiz_antunes
_de_moraes.pdf>. Acesso em: 17 nov. 2015.
MORAES, Deisy N. M. de. Diagnóstico e avaliação psicopedagógica. Revista de Educação
do Ideau, Getúlio Vargas, v. 5, n. 10, p. 1-15, jan./jun. 2010. Disponível em:
<http://www.ideau.com.br/getulio/restrito/upload/revistasartigos/203_1.pdf>. Acesso em: 17
nov. 2015.
NIKAEDO, Carolina C. et al. Nível de leitura e compreensão de sentenças faladas no ensino
fundamental: diagnóstico diferencial dos problemas de leitura. Revista da Associação
Brasileira de Psicopedagogia, São Paulo, v. 23, n. 71, p. 107-115, jun. 2006. Disponível em:
<http://www.ip.usp.br/lance/artigos/Nikaedo_Macedo_Diana_Lukasova_Kuriyama_Orsati_C
apovilla_Natalle_2006.pdf>. Acesso em: 08 dez. 2015.
NUNES, Maria A. S. N. Inteligência Artificial. [São Cristóvão], [2011]. Disponível em:
<http://200.17.141.213/~gutanunes/hp/IA-2011-
2/representa%C3%A7ao%20de%20conhecimento/aula6.ppt>. Acesso em: 17 nov. 2015.
PAIVA, Raphael D. Drools: desacoplando as regras de negócio do código da aplicação. [S.I],
2010. Disponível em: <https://macoli.files.wordpress.com/2010/11/drools.pdf>. Acesso em:
18 nov. 2015.
PRATI, Ronaldo C. Representação do conhecimento: Considerações gerais. [Santo André],
[2011]. Disponível em:
<http://professor.ufabc.edu.br/~ronaldo.prati/InteligenciaArtificial/RC.pdf>. Acesso em: 18
nov. 2015.
RIVEROS, Lilian J. M. Sistema especialista: Uma base para o pré-diagnóstico da dislexia.
2001. 81 f. Dissertação (Mestrado em Ciência da Computação) - Programa de Pós-graduação
em Ciências da Computação. Universidade Federal de Santa Catarina, Florianópolis.
Disponível em:
<http://repositorio.ufsc.br/bitstream/handle/123456789/79503/188940.pdf?sequence=1&isAll
owed=y>. Acesso em: 17 nov. 2015.
RODRIGUES, Judite F. Diagnóstico psicopedagógico na escola. [S.I], 2009. Disponível em:
<http://www.pedagobrasil.com.br/pedagogia/diagnosticopsicopedagogico.htm>. Acesso em:
18 nov. 2015.
SAMPAIO, Simaia. Manual prático do diagnóstico psicopedagógico clínico. Rio de
Janeiro: Wak, 2009.
87
SAMPAIO, Simaia; FREITAS, Ivana B. de (Org.). Transtornos e dificuldades de
aprendizagem: entendendo melhor os alunos com necessidades educativas especiais. Rio de
Janeiro: Wak, 2011.
SANTOS, Antonion. Relatório de estágio psicopedagogia clínica. [São Paulo], 2012.
Disponível em: <http://dialogoeducao.blogspot.com.br/2012/06/relatorio-de-estagio-
supervisionado_02.html>. Acesso em: 23 nov. 2015.
SANTOS, Luana R. dos. Protótipo de um sistema especialista educativo para diagnóstico
Médico. 2010. 85 f. Trabalho de Conclusão de Curso (Bacharelado em Ciência da
Computação) – Curso de Ciência da Computação, Centro Universitário Vila Velha, Vila
Velha. Disponível em: <http://www.uvv.br/edital_doc/2010-02-Monografia-Final-
06_10cf8924-7adb-4407-bb51-0b305043cec2.pdf>. Acesso em: 17 nov. 2015.
SANTOS, Valdinéia M. dos. Dificuldade de aprendizagem da matemática: Discalculia.
[S.I.], [2013?]. Disponível em: < http://monografias.brasilescola.com/psicologia/dificuldade-
aprendizagem-matematica-discalculia.htm>. Acesso em: 17 nov. 2015.
TIZZEI, Leonardo P. Uma infra-estrutura de suporte à evolução para repositórios de
componentes. 2007. 88 f. Dissertação (Mestrado em Ciência da Computação) – Instituto de
Computação, Universidade Estadual de Campinas, Campinas. Disponível em
<http://www.bibliotecadigital.unicamp.br/document/?code=vtls000414573&fd=y>. Acesso
em: 18 nov. 2015.
VILANA, Ramon. Avaliação psicopedagógica. A entrevista com os pais, os professores e os
alunos. In: SÁNCHEZ-CANO, Manuel; BONALS, Joan (Org.). Avaliação psicopedagógica.
Tradução Fátima Murad. São Paulo: Artmed, 2008. p. 64-80.
VISCA, Jorge. Clínica psicopedagógica: epistemologia convergente. Porto alegre: Artes
Médicas, 1987.
VITORINO, Janete L. O trabalho psicopedagógico e a aprendizagem segundo a
abordagem Vygotskyana: A teoria vygostskyana e a prática psicopedagógica. [São Paulo],
[2000?]. Disponível em: <http://www.pedagobrasil.com.br/normasparapublicacao.htm>.
Acesso em: 17 nov. 2015.
ZAMBIAZI, Bruno D. Análise de ferramentas para gestão de regras de negócio em
sistemas de informação. 2013. 80 f. Monografia (Bacharelado em Sistemas de Informação) –
Centro de Ciências Exatas e Naturais, Centro Universitário UNIVATES, Lajeado. Disponível
em: <https://www.univates.br/bdu/bitstream/10737/363/1/BrunoZambiazi.pdf>. Acesso em:
18 nov. 2015.
ZUBEN, Fernando J. V. Sistemas baseados em regras e árvores de decisão. Campinas,
2011. Disponível em:
<ftp://ftp.dca.fee.unicamp.br/pub/docs/vonzuben/ea072_2s11/topico6_EA072_2s11.pdf>.
Acesso em: 17 nov. 2015.
88
APÊNDICE A – Descrição dos Casos de Uso
Nos quadros abaixo é apresentada a descrição dos casos de uso conforme previstos no
diagrama apresentado na seção 3.3.1. Também são detalhadas as pré e pós-condições, bem
como o fluxo principal e cenários.
O UC01 refere-se ao processo de login do usuário na aplicação. Detalhes sobre o caso
de uso estão descritos no Quadro 22.
Quadro 22 - Detalhamento do caso de uso UC01 - Efetuar login
UC01 O protótipo deverá permitir ao usuário efetuar login no sistema
Descrição Permite ao usuário que, através da identificação por usuário e senha,
conecte-se ao sistema.
Ator Psicopedagogo
Pré-condição Estar cadastrado no banco de dados da aplicação
Fluxo principal 1. Usuário acessa o endereço do sistema;
2. O sistema apresenta a página inicial onde será solicitado login e
senha do usuário;
3. O usuário informa os dados solicitados (login/senha) e confirma no
botão Login;
4. O sistema valida o login e senha inseridas;
5. O sistema apresenta a página principal.
Cenário – Exceção 4.1 Se, no passo 4, o login ou a senha informados pelo usuário estiverem em
branco ou estiverem inválidos, o sistema apresenta a mensagem: "Login
e/ou senha inválidos!".
Pós-condição Usuário está conectado ao sistema.
O UC02 – Manter usuários descreve a funcionalidade de manutenção de usuários.
Detalhes do caso de uso são apresentados no Quadro 23.
Quadro 23 - Detalhamento do caso de uso UC02 – Manter usuários
UC02 O protótipo deverá permitir a manutenção de usuários
Descrição Permite ao usuário o cadastro, consulta, edição e exclusão de usuários.
Ator Psicopedagogo
Pré-condição Estar cadastrado no banco de dados da aplicação. Usuário deve possuir
perfil de administrador.
Fluxo principal 1. O usuário aciona o botão Usuários na página inicial.
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona a opção de incluir paciente;
4. Usuário informa todos os campos obrigatórios;
5. Usuário seleciona a opção Salvar;
6. Protótipo inclui o registro e apresenta mensagem “Paciente cadastrado
com sucesso!”.
Pós-condição Registro de usuário consultado, cadastrado, editado ou excluído com
sucesso.
O UC03 – Manter pacientes descreve a funcionalidade de manutenção de pacientes.
Detalhes do caso de uso são apresentados no Quadro 24.
89
Quadro 24 - Detalhamento do caso de uso UC03 - Manter pacientes
UC03 O protótipo deverá permitir a manutenção de pacientes
Descrição Permite ao usuário o cadastro de pacientes, com opção de consultar,
cadastrar ou editar os registros. Serão solicitadas as informações pessoais do
paciente: nome, data de nascimento, endereço, escola e dados de contato.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema
Fluxo principal O protótipo apresenta os pacientes cadastrados;
Usuário opta pela edição ou cadastro de paciente.
Cenário – Inclusão 1. O protótipo apresenta os pacientes cadastrados;
2. Usuário seleciona a opção de incluir paciente;
3. Usuário informa todos os campos obrigatórios;
4. Usuário seleciona a opção Salvar;
5. Protótipo inclui o registro e apresenta mensagem “Paciente cadastrado
com sucesso!”.
Cenário - Edição 1. O protótipo apresenta os pacientes cadastrados;
2. Usuário seleciona um paciente para edição;
3. O protótipo mostra os dados do paciente para edição;
4. Usuário realiza as alterações necessárias;
5. Usuário seleciona a opção Alterar;
6. O protótipo altera o registro e apresenta a mensagem “Paciente alterado
com sucesso!”.
Cenário - Inativação 1. O protótipo apresenta os pacientes cadastrados;
2. Usuário seleciona um paciente para inativação;
3. Usuário seleciona a opção Inativar;
4. O protótipo inativa o registro e apresenta a mensagem “Paciente inativado
com sucesso”.
Pós-condição O paciente foi cadastrado, visualizado ou editado pelo usuário.
No Quadro 25 apresenta-se o caso de uso UC04 - Manter planejamentos, que
descreve a funcionalidade de manutenção de planejamentos de atendimentos
psicopedagógicos.
90
Quadro 25 - Detalhamento do caso de uso UC04 - Manter planejamentos
UC04 O protótipo deverá permitir a manutenção de planejamentos de
atendimentos
Descrição Permite ao usuário o cadastro de planejamentos de atendimentos, com opção
de consultar, editar ou inativar os registros. Nesta tela, serão informados os
seguintes dados: data, objetivo, recursos, atividades e descrição do
planejamento.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema. Usuário deve ter cadastrado
recurso e atividade para vincular ao atendimento.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona um paciente para visualizar os planejamentos
vinculados a ele;
4. O protótipo apresenta os planejamentos já cadastrados para o
paciente.
Cenário – Inclusão 1. O protótipo apresenta os planejamentos já cadastrados para o paciente;
2. Usuário seleciona a opção de incluir planejamento;
3. Usuário informa todos os campos obrigatórios;
4. Usuário seleciona a opção Salvar;
5. Protótipo inclui o registro e apresenta mensagem “Planejamento
cadastrado com sucesso!”.
Cenário - Edição 1. O protótipo apresenta os planejamentos já cadastrados para o paciente;
2. Usuário seleciona um planejamento para edição;
3. O protótipo mostra os dados do planejamento para edição;
4. Usuário realiza as alterações necessárias;
5. Usuário seleciona a opção Alterar;
6. O protótipo altera o registro e apresenta a mensagem “Planejamento
alterado com sucesso!”.
Cenário - Inativação 1. O protótipo apresenta os planejamentos já cadastrados para o paciente;
2. Usuário seleciona um planejamento para edição;
3. O protótipo mostra os dados do planejamento para edição;
4. Usuário seleciona a opção Inativar;
5. O protótipo altera o registro e apresenta a mensagem “Planejamento
inativado com sucesso!”.
Pós-condição O planejamento de atendimento a um paciente foi cadastrado, visualizado,
editado ou inativado pelo usuário.
No Quadro 26 apresenta-se o caso de uso UC05 - Manter atendimentos, que
descreve a funcionalidade de manutenção de atendimentos.
91
Quadro 26 - Detalhamento do caso de uso UC05 - Manter Atendimentos
UC05 O protótipo deverá permitir a manutenção de atendimentos.
Descrição Permite ao usuário o cadastro de atendimentos, com opção de consultar ou
editar os registros. Nesta tela, o usuário deverá informar a data, o objetivo,
recursos e atividades utilizadas e a descrição das observações do
atendimento.
Ator Psicopedagogo
Pré-condições Usuário deve ter efetuado login no sistema. Usuário deve ter cadastrado
recurso e atividade para vincular ao atendimento.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona um paciente para visualizar os atendimentos
vinculados a ele;
4. O protótipo apresenta os atendimentos já cadastrados para o
paciente.
Cenário – Inclusão 1. O protótipo apresenta os atendimentos já cadastrados para o paciente;
2. Usuário seleciona a opção de incluir atendimento;
3. Usuário informa os dados obrigatórios;
4. Usuário seleciona a opção Salvar;
5. Protótipo inclui o registro e apresenta mensagem “Atendimento
cadastrado com sucesso!”.
Cenário alternativo –
Inclusão baseada em
planejamento
1. Se houver planejamento cadastrado para o paciente e a data atual, o
protótipo questiona o usuário se este deseja utilizar um dos planejamentos
cadastrados;
2. Se usuário informou que utilizará um planejamento, o protótipo apresenta
os planejamentos cadastrados para o paciente na data escolhida;
3. O protótipo carrega os dados do planejamento selecionado nos campos do
cadastro de atendimento;
4. Usuário confere os dados do atendimento e seleciona o registro desejado;
5. O protótipo preenche o formulário de registro de atendimento com os
dados do planejamento selecionado.
5. Usuário edita as informações se necessário e seleciona a opção Salvar;
6. Protótipo inclui o registro e apresenta mensagem “Atendimento
cadastrado com sucesso!”.
Cenário - Edição 1. O protótipo apresenta os atendimentos já cadastrados para o paciente;
2. Usuário seleciona um atendimento para edição;
3. O protótipo mostra os dados do atendimento para edição;
4. Usuário realiza as alterações necessárias;
5. Usuário seleciona a opção Salvar;
6. O protótipo altera o registro e apresenta a mensagem “Atendimento
alterado com sucesso!”.
Cenário - Inativação 1. O protótipo apresenta os atendimentos já cadastrados para o paciente;
2. Usuário seleciona um atendimento para edição;
3. O protótipo mostra os dados do atendimento para edição;
4. Usuário seleciona a opção Inativar;
5. O protótipo altera o registro e apresenta a mensagem “Atendimento
inativado com sucesso!”.
Pós-condição O atendimento de um usuário foi cadastrado, visualizado, editado ou
inativado pelo usuário.
No Quadro 27 apresenta-se o caso de uso UC06 - Manter Atividades.
92
Quadro 27 - Detalhamento do caso de uso UC06 - Manter Atividades
UC06 O protótipo deverá permitir a manutenção de atividades.
Descrição Permite ao usuário o cadastro de atividades, com opção de consultar, editar
ou excluir os registros. O usuário deverá informar a descrição da atividade.
Exemplos: Entrevista de anamnese, testes, jogos.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema
Fluxo principal 1. O protótipo apresenta as atividades cadastradas;
2. Usuário opta pela edição, exclusão ou cadastro de atividade.
Cenário – Inclusão 1. Usuário seleciona a opção de incluir atividade;
2. Usuário informa o campo de descrição;
3. Usuário seleciona a opção Salvar;
4. Protótipo inclui o registro e apresenta mensagem “Atividade cadastrada
com sucesso!”.
Cenário - Edição 1. Usuário seleciona uma atividade para edição;
2. O protótipo mostra os dados da atividade para edição;
3. Usuário realiza as alterações necessárias;
4. Usuário seleciona a opção Salvar;
5. O protótipo altera o registro e apresenta a mensagem “Atividade alterada
com sucesso!”.
Cenário - Exclusão 1. Usuário seleciona uma atividade para exclusão;
2. Usuário seleciona a opção Excluir;
3. O protótipo solicita confirmação ao usuário;
4. Usuário confirma a exclusão;
3. O protótipo inativa o registro e apresenta a mensagem “Atividade
excluída com sucesso”.
Cenário alternativo 1 -
Exclusão
No passo 3, se o usuário informar “não”, nenhuma ação é realizada pelo
protótipo.
Cenário alternativo 2 -
Exclusão
No passo 4, se houver atendimento ou planejamento com vínculo ao
recurso, o sistema apresenta a mensagem “Existe atendimento/planejamento
vinculado ao recurso. Não é permitida exclusão” e aborta a ação.
Pós-condição Atividade cadastrada, visualizada, editada ou excluída pelo usuário.
No Quadro 28 apresenta-se o caso de uso UC07 - Manter Recursos.
93
Quadro 28 - Detalhamento do caso de uso UC07 - Manter Recursos
UC07 O protótipo deverá permitir a manutenção de recursos.
Descrição Permite ao usuário o cadastro de recursos, com opção de consultar, editar ou
excluir os registros. Nesta tela, o usuário deverá informar o nome do recurso
e a quantidade disponível. Exemplos: jogo de quebra-cabeça, questionário
EOCA, lápis de cor, brinquedos.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema
Fluxo principal 1. O protótipo apresenta os recursos cadastrados;
2. Usuário opta pela edição, exclusão ou cadastro de recurso.
Cenário – Inclusão 1. Usuário seleciona a opção de incluir recurso;
2. Usuário informa todos os campos obrigatórios;
3. Usuário seleciona a opção Salvar;
4. Protótipo inclui o registro e apresenta mensagem “Recurso cadastrado
com sucesso!”.
Cenário - Edição 1. Usuário seleciona um recurso para edição;
2. O protótipo mostra os dados do recurso para edição;
3. Usuário realiza as alterações necessárias;
4. Usuário seleciona a opção Salvar;
5. O protótipo altera o registro e apresenta a mensagem “Recurso alterado
com sucesso!”.
Cenário - Exclusão 1. Usuário seleciona um recurso para exclusão;
2. Usuário seleciona a opção Excluir;
3. Protótipo solicita confirmação ao usuário;
4. Usuário confirma a exclusão;
5. O protótipo inativa o registro e apresenta a mensagem “Recurso excluído
com sucesso”.
Cenário alternativo 1 -
Exclusão
No passo 3, se o usuário informar “não”, nenhuma ação é realizada pelo
protótipo.
Cenário alternativo 2 -
Exclusão
No passo 4, se houver atendimento ou planejamento com vínculo ao
recurso, o sistema apresenta a mensagem “Existe atendimento/planejamento
vinculado ao recurso. Não é permitida exclusão” e aborta a ação.
Pós-condição Recurso cadastrado, visualizado, editado ou excluído pelo usuário.
No Quadro 29 é apresentado o caso de uso UC08 - Realizar teste de
lateralidade.
94
Quadro 29 - Detalhamento do caso de uso UC08 - Realizar teste de lateralidade
UC08 O protótipo deverá permitir a realização de teste de lateralidade com o
paciente
Descrição Permite ao usuário a realização de teste de lateralidade com o paciente,
informando a lateralidade dominante identificada durante os testes
psicomotores para olhos, mãos e pés.
Ator Psicopedagogo
Pré-condições Usuário deve ter efetuado login no sistema. A funcionalidade estará
disponível para pacientes já cadastrados.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona um paciente para realização do teste de
lateralidade;
4. O protótipo apresenta a tela de teste de lateralidade;
5. Usuário preenche a lateralidade (direita ou esquerda) identificada
para pés, mãos e olhos;
6. Usuário seleciona a opção Salvar;
7. O protótipo salva o registro e apresenta a mensagem “Teste de
lateralidade salvo com sucesso”;
8. A tela do protótipo é atualizada e é apresentada a lateralidade
dominante calculada com base nos resultados informados.
Cenário - Edição No passo 4, se o teste de lateralidade já estiver preenchido e o usuário
desejar alterar o registro:
4.1 Usuário realiza novo teste e altera a lateralidade identificada para
pés, mãos e/ou olhos;
4.2 Usuário seleciona a opção Salvar;
4.3 O protótipo salva o registro e apresenta a mensagem “Teste de
lateralidade salvo com sucesso”;
4.4 A tela do protótipo é atualizada e é apresentada a lateralidade
dominante calculada com base nos novos resultados individuais
informados.
Pós-condição Teste de lateralidade salvo com sucesso.
No Quadro 30 apresenta-se o caso de uso UC09 – Visualizar relatório de
avaliação.
95
Quadro 30 - Detalhamento do caso de uso UC09 – Visualizar relatório de avaliação
UC09 O protótipo deverá permitir a visualização de relatório de avaliação
Descrição Permite ao usuário a geração de relatório de avaliação de paciente, utilizado
para auxílio na entrevista de devolutiva aos responsáveis do paciente. O
relatório apresenta os detalhes das sessões realizadas, juntamente com seus
objetivos, recursos e atividades realizadas. O relatório também apresenta as
observações da anamnese, o resultado da EOCA e dos testes de lateralidade
e de compreensão da palavra escrita.
Ator Psicopedagogo
Pré-condições Usuário deve ter efetuado login no sistema.
A funcionalidade estará disponível para pacientes já cadastrados.
Para todas as informações serem exibidas, o paciente deve ter pelo menos
um atendimento realizado e possuir as informações coletadas na anamnese e
testes cadastrados.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona um paciente e seleciona a opção Histórico;
4. O protótipo apresenta o relatório.
Pós-condição Relatório de avaliação de paciente apresentado ao usuário.
No Quadro 31 apresenta-se o caso de uso UC10 - Realizar anamnese.
Quadro 31 – Detalhamento do caso de uso UC10 - Realizar anamnese
UC10 O protótipo deverá permitir a realização de entrevista de anamnese com o
paciente.
Descrição Permite ao usuário a realização da entrevista de anamnese, onde são
coletados os dados referentes ao histórico do paciente, desenvolvimento,
alimentação e rotina.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema. A funcionalidade estará
disponível para pacientes já cadastrados.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona o paciente desejado e clica na opção Realizar
anamnese;
4. O protótipo apresenta a tela de anamnese;
5. Usuário informa os campos obrigatórios das abas do formulário e
seleciona a opção Salvar;
6. O protótipo grava o registro e apresenta a mensagem: “Anamnese
salva com sucesso”.
Cenário - Edição No passo 4, a anamnese já está gravada e o usuário deseja alterar.
4.1 O protótipo apresenta a tela de anamnese com os dados já
cadastrados;
4.2 Usuário altera os campos necessários e seleciona a opção Salvar;
4.3 O protótipo grava o registro e apresenta a mensagem: “Anamnese
salva com sucesso”.
Pós-condição Anamnese cadastrada ou editada com sucesso.
No Quadro 32 apresenta-se o caso de uso UC11 - Realizar EOCA.
96
Quadro 32 - Detalhamento do caso de uso UC11 - Realizar EOCA
UC11 O protótipo deverá permitir a realização de EOCA com o paciente
Descrição Permite ao usuário a realização de Entrevista Operativa Centrada na
Aprendizagem (EOCA) com o paciente, registrando no protótipo as
características observadas pelo paciente de forma a identificar a modalidade
de aprendizagem apresentada pelo paciente (hipoassimilativa,
hiperacomodativa, hiperassimilativa, hiperacomodativa ou normal).
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema. A funcionalidade estará
disponível para pacientes já cadastrados.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona um paciente e clica na opção Realizar EOCA;
4. O protótipo apresenta a tela de EOCA;
5. Usuário seleciona no formulário as características apresentadas,
digita as observações e seleciona a opção Salvar;
6. O protótipo salva o registro e apresenta a mensagem “EOCA salva
com sucesso”.
7. O protótipo apresenta a modalidade de aprendizagem do paciente
com base nas informações registradas.
Cenário - Edição No passo 4, a EOCA já está gravada e o usuário deseja alterar.
1. O protótipo apresenta a tela de EOCA com os dados já cadastrados;
2. Usuário realiza as alterações e seleciona a opção Salvar;
3. O protótipo salva o registro e apresenta a mensagem “EOCA salva
com sucesso”.
4. O protótipo apresenta a modalidade de aprendizagem do paciente
atualizada com base nas informações registradas.
Pós-condição EOCA com o paciente realizada.
No Quadro 33 apresenta-se o caso de uso UC12 - Manter familiares.
97
Quadro 33 - Detalhamento do caso de uso UC12 – Manter familiares
UC12 O protótipo deverá permitir a consulta, cadastro, edição e exclusão de
familiares de pacientes.
Descrição Permite ao usuário o cadastro de familiares de pacientes, com opção de
consultar, editar ou inativar os registros. Nesta tela, o usuário informará
dados básicos do familiar indicando se o mesmo é o responsável pelo
paciente.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema. O cadastro estará disponível
para pacientes já cadastrados.
Fluxo principal 1. O usuário efetua a consulta de pacientes;
3. O protótipo os pacientes cadastrados;
4. Usuário seleciona um paciente e clica na opção Familiar.
Cenário – Inclusão 1. Usuário seleciona a opção de incluir familiar;
2. Usuário informa todos os campos obrigatórios;
3. Usuário seleciona a opção Salvar;
4. Protótipo inclui o registro e apresenta mensagem “Familiar cadastrado
com sucesso!”.
Cenário - Edição 1. Usuário seleciona um recurso para edição;
2. O protótipo mostra os dados do familiar para edição;
3. Usuário realiza as alterações necessárias;
4. Usuário seleciona a opção Salvar;
5. O protótipo altera o registro e apresenta a mensagem “Familiar alterado
com sucesso!”.
Cenário - Exclusão 1. Usuário seleciona um familiar para exclusão;
2. Usuário seleciona a opção Excluir;
3. O protótipo solicita confirmação ao usuário;
4. Usuário confirma a exclusão;
5. O protótipo exclui o registro do banco de dados e apresenta a mensagem
“Familiar excluído com sucesso”.
Cenário alternativo 1
– Exclusão
No passo 3, se o usuário informar “não”, nenhuma ação é realizada pelo
protótipo.
Cenário alternativo 2 -
Exclusão
No passo 4, se o familiar estiver marcado como responsável do paciente e
possuir contrato vinculado, é apresentada a mensagem “Não é permitido
excluir familiar responsável com contrato vinculado” e a ação é abortada.
Pós-condição Familiar consultado, cadastrado, editado ou excluído com sucesso.
No Quadro 34 apresenta-se o caso de uso UC13 - Manter contratos.
98
Quadro 34 - Detalhamento do caso de uso UC13 – Manter contratos
UC13 O protótipo deverá permitir a consulta, inclusão, edição e exclusão de
contratos.
Descrição Permite ao usuário a manutenção de contratos de prestação de serviços do
psicopedagogo para com o familiar responsável do paciente.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema;
Paciente deve possuir um familiar cadastrado.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona um paciente e clica na opção Contrato;
4. O protótipo apresenta a tela de contratos;
5. Usuário realiza o cadastro do contrato informando o título e a
descrição.
6. O protótipo salva o registro e apresenta a mensagem “Contrato
salvo com sucesso”.
Cenário - Edição No passo 4, o contrato já está gravado e o usuário deseja alterar.
4.1 O protótipo apresenta a tela de contrato com os dados já
cadastrados;
4.2 Usuário realiza as alterações e seleciona a opção Salvar;
4.3 O protótipo salva o registro e apresenta a mensagem “Contrato salvo
com sucesso”.
Pós-condição Contrato consultado, cadastrado, editado ou excluído com sucesso.
No Quadro 35 apresenta-se o caso de uso UC14 - Exportar contrato para docx.
Quadro 35 - Detalhamento do caso de uso UC14 – Exportar contrato para docx
UC14 O protótipo deverá permitir a exportação e download de contrato em
extensão docx.
Descrição Permite ao usuário a exportação e download do contrato de prestação de
serviços em formato docx com a cláusula de partes envolvidas e assinaturas
preenchidas dinamicamente conforme o familiar do paciente e os dados do
psicopedagogo.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema. Deve haver um familiar
responsável cadastrado para o paciente. Deve haver contrato cadastrado.
Fluxo principal 1. O protótipo apresenta os pacientes cadastrados;
2. Usuário seleciona um paciente e clica na opção Contrato;
3. O protótipo apresenta a lista de contratos do paciente;
4. Usuário seleciona o contrato para visualizar;
5. O protótipo apresenta os dados do contrato selecionado;
6. Usuário seleciona a opção Exportar docx.
7. O protótipo gera o arquivo em formato docx com o conteúdo do
contrato e salva na pasta de downloads do usuário.
Pós-condição Contrato exportado em formato docx.
No Quadro 36 apresenta-se o caso de uso UC15 - Editar cadastro de
psicopedagogo.
99
Quadro 36 - Detalhamento do caso de uso UC15 – Editar cadastro de psicopedagogo
UC15 O protótipo deverá permitir a edição de cadastro de psicopedagogo.
Descrição Permite ao usuário editar seu cadastro de psicopedagogo, que contém
informações da clínica utilizadas no contrato de prestação de serviços e
senha de acesso ao sistema.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema;
Fluxo principal 1. Na página inicial da aplicação, usuário seleciona a opção “Meu
cadastro”;
2. O protótipo apresenta a tela de edição do cadastro do psicopedagogo
com as informações já existentes.
3. Usuário altera as informações necessárias e seleciona a opção
Salvar;
4. Usuário apresenta a mensagem “Cadastro de psicopedagogo salvo
com sucesso!”.
Pós-condição Cadastro de psicopedagogo salvo com sucesso.
No Quadro 37Quadro 37 apresenta-se o caso de uso UC16 - Realizar teste de
compreensão da palavra escrita.
100
Quadro 37 - Detalhamento do caso de uso UC16 – Realizar teste de compreensão da palavra escrita
UC16 O protótipo deverá permitir a realização de teste de compreensão da palavra
escrita com o paciente.
Descrição Permite ao usuário a geração de relatório de diagnóstico de paciente,
utilizado para auxílio na entrevista de devolutiva aos responsáveis do
paciente. O relatório apresenta os detalhes das sessões realizadas,
juntamente com seus objetivos, recursos e atividades realizadas. O relatório
também apresenta, se existir necessidade, indicação a outro profissional
(psicólogo, neurologista, fonoaudiólogo) com base nas informações,
coletadas nas entrevistas com o paciente e família, e critérios definidos nas
regras de produção.
Ator Psicopedagogo
Pré-condição Usuário deve ter efetuado login no sistema;
Paciente deve ter realizado pelo menos dois atendimentos e possuir as
informações coletadas na anamnese cadastradas.
Fluxo principal 1. Usuário efetua a consulta de pacientes;
2. O protótipo apresenta os pacientes cadastrados;
3. Usuário seleciona um paciente para realização do teste de
compreensão da palavra escrita;
4. O protótipo apresenta a tela de teste de compreensão da palavra
escrita;
5. Usuário preenche as respostas obtidas com o paciente para as
perguntas;
6. Usuário seleciona a opção Salvar;
7. O protótipo salva o registro e apresenta a mensagem “Teste de
compreensão da palavra escrita salvo com sucesso”;
A tela do protótipo é atualizada e é apresentada a lista de testes realizados
contendo o resultado calculado conforme a quantidade de acertos.
Cenário - Edição No passo 4, se o teste de compreensão da palavra escrita já foi realizado,
será apresentado um formulário com a pontuação obtida pelo paciente e a
indicação das respostas informadas para cada questão.
Pós-condição Teste de compreensão da palavra escrita realizado ou consultado com
sucesso.
101
APÊNDICE B – Questionário de avaliação do protótipo
Neste apêndice é demonstrado o questionário realizado com as psicopedagogas após a
execução dos casos de uso para a avaliação do sistema. O Quadro 38 compreende as
perguntas respondidas pelos profissionais, cujas respostas foram descritas qualitativamente na
seção 3.4.
Quadro 38 – Questionário de avaliação do protótipo
QUESTIONÁRIO DE AVALIAÇÃO
1. Você achou o protótipo intuitivo e fácil de usar?
2. Qual a sua avaliação sobre o layout do sistema?
3. Qual a sua avaliação sobre a usabilidade do sistema?
4. Qual é a sua avaliação do protótipo? Muito Bom ( ) Bom ( ) Mediano ( ) Ruim ( )
5. Na sua visão, qual a porcentagem de atividades realizadas pelo psicopedagogo
manualmente está sendo atendida/automatizada no sistema?
6. O sistema seria útil para psicopedagogos?
7. Você acha que o sistema reduziria o tempo gasto pelo psicopedagogo com registros
manuais?
8. Você usaria este sistema no seu dia a dia?
9. Você indicaria a outra pessoa?
10. Pontos positivos
11. Pontos negativos
12. Sugestões/melhorias:
102
APÊNDICE C – Detalhamento das abas do formulário de anamnese
Neste apêndice estão apresentadas as demais abas do formulário de anamnese,
correspondentes às subáreas da entrevista não apresentadas na seção 3.3.3.6.1. A Figura 37
ilustra a aba Sono do formulário.
Figura 37 – Tela de registro de anamnese – Aba Sono
A Figura 38 apresenta a aba Alimentação da tela de registro de anamnese.
Figura 38 – Tela de registro de anamnese – Aba Alimentação
Na Figura 39 é ilustrada a aba Desenvolvimento/Evolução do formulário de anamnese.
103
Figura 39 – Tela de registro de anamnese – Aba Desenvolvimento/Evolução
Na Figura 40 é demonstrado o conteúdo da aba Escolaridade da entrevista de
anamnese.
Figura 40 – Tela de registro de anamnese – Aba Escolaridade
A Figura 41 ilustra o conteúdo da aba Rotina da entrevista de anamnese.
104
Figura 41 – Tela de registro de anamnese – Aba Rotina
A Figura 42 apresenta a aba Histórico clínico da entrevista de anamnese.
Figura 42 – Tela de registro de anamnese – Aba Histórico clínico
Na Figura 43 é demonstrado o conteúdo da aba Família da entrevista de anamnese.
Figura 43 – Tela de registro de anamnese – Aba Família