Aplicaci on pr actica de la Metodolog a WebML de Desarrollo de … Juan Carlos .pdf · 2016-05-10 · \Aplicaci on pr actica de la Metodolog a WebML de Desarrollo de Software a la

$Page 1: Aplicaci on pr actica de la Metodolog a WebML de Desarrollo de … Juan Carlos .pdf · 2016-05-10 · \Aplicaci on pr actica de la Metodolog a WebML de Desarrollo de Software a la$
“Aplicacion practica de la Metodologıa WebML de

Desarrollo de Software a la gestion integral de un

gabinete psicopedagogico”

Universidad Nacional de Salta

Facultad de Cs. Exactas

Lic. en Analisis de Sistemas

Seminario de Sistemas

Informe Final

2.016

Director: Lic. Jorge Silvera

Alumno: Juan Carlos Salva

L.U.: 216.024

No de Actuacion: 1.009/15

Subcomision:

Lic. Patricia Aballay

Lic. Loraine Gimson Saravia

Lic. Carina Reyes

“Un dıa depertaras y descubriras que no tienes mas tiempo para hacer lo quesonabas. El momento es ahora. Actua...”

Paulo Coelho

Agradecimientos

Agradezco a mis padres, familia y amigos por todo el apoyo incondicional queme dieron durante estos anos.

En especial a mi madre Mercedes Paola Gomes, por ensenanarme la impor-tancia de la perseverancia y el valor del trabajo.

A mi padre Juan Carlos Salva, por apoyarme incondicionalmente en todas misdecisiones y por ensenarme que la humildad es el valor mas importante detodos.

A mis hermanos Paola, Gabriel y Francisco por que gracias a ustedes aprendıel valor del respeto y la tolerancia.

A mi abuela Salustiana, mi viejita... Gracias por todo su carino y apoyo durantetoda la carrera.

A mi companera de vida Maria Laura, por inspirar este seminario, por pres-tarme un hombro cuando lo necesite y por toda su comprension.

Por ultimo pero no menos importante a mi director de seminario el Lic. JorgeSilvera, por todo el apoyo a mi y a mis companeros durante la carrera. Graciaspor todo su esfuerzo y vountad para ayudarnos a todos en nuestro caminouniversitario.

A todos muchas gracias, no me alcanzan las palabras para decirles lo importanteque son para mi.

iii

Indice general

Agradecimientos III

Indice general IV

Indice de figuras VII

I Investigacion y planificacion 1

1. Introduccion 21.1. Objetivos Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Sistema objeto 42.1. Concepto de gabinete psicopedagogico . . . . . . . . . . . . . . . . . 42.2. Descripcion del sistema objeto . . . . . . . . . . . . . . . . . . . . . . 42.3. Descripcion del proyecto de informatizacion a realizar . . . . . . . . . 5

2.3.1. Subsistema de gestion de profesionales . . . . . . . . . . . . . 52.3.2. Subsistema de gestion de pacientes . . . . . . . . . . . . . . . 52.3.3. Subsistema de gestion de historial escolar . . . . . . . . . . . . 62.3.4. Subsistema de gestion de historial clınico . . . . . . . . . . . . 62.3.5. Subsistema de administracion de tratamientos . . . . . . . . . 62.3.6. Subsistema de administracion de sesiones . . . . . . . . . . . . 7

3. Alcance del proyecto 83.1. Eleccion de la metodologıa y las herramientas . . . . . . . . . . . . . 8

4. Marco teorico 124.1. La metodologıa WebML . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1.1. Analisis de requerimientos . . . . . . . . . . . . . . . . . . . . 134.1.2. Modelado conceptual . . . . . . . . . . . . . . . . . . . . . . . 144.1.3. Implementacion . . . . . . . . . . . . . . . . . . . . . . . . . . 144.1.4. Pruebas y evaluacion . . . . . . . . . . . . . . . . . . . . . . . 144.1.5. Mantenimiento y evolucion . . . . . . . . . . . . . . . . . . . . 15

4.2. Modelos WebML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2.1. Modelo de estructura . . . . . . . . . . . . . . . . . . . . . . . 164.2.2. Modelo de hipertexto . . . . . . . . . . . . . . . . . . . . . . . 18

iv

INDICE GENERAL v

4.2.3. Modelo de composicion . . . . . . . . . . . . . . . . . . . . . . 184.2.4. Modelo de navegacion . . . . . . . . . . . . . . . . . . . . . . 234.2.5. Modelo de presentacion . . . . . . . . . . . . . . . . . . . . . . 244.2.6. Modelo de personalizacion . . . . . . . . . . . . . . . . . . . . 25

4.3. Webratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.1. Notacion para enlaces . . . . . . . . . . . . . . . . . . . . . . 27

5. Estudio de factibilidad 295.1. Factibilidad tecnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2. Factibilidad economica-financiera . . . . . . . . . . . . . . . . . . . . 305.3. Factibilidad operativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.4. Factibilidad Legal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6. Planificacion del proyecto 35

II Aplicacion de la metodologıa: 1o Iteracion 38

7. Analisis de requerimientos 397.1. Ambito del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2. Definicion de grupos de usuarios . . . . . . . . . . . . . . . . . . . . . 42

8. Modelo de estructura 438.0.1. Identificacion de las entidades basicas de informacion . . . . . 438.0.2. Modelo inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9. Modelo de hipertexto 499.1. Modelo inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

10.Modelo de presentacion 52

11.Modelo de personalizacion 55

III Aplicacion de la metodologıa: 2o Iteracion 58

12.Refinamiento del analisis de requerimientos 5912.1. Definicion de requerimientos . . . . . . . . . . . . . . . . . . . . . . . 60

12.1.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . 6012.1.2. Requerimientos no funcionales . . . . . . . . . . . . . . . . . . 69

13.Refinamiento del modelo de estructura 7113.0.1. Asociacion del modelo a una Base de Datos . . . . . . . . . . 74

14.Refinamiento del modelo de hipertexto 8114.1. Refinamiento del modelo inicial . . . . . . . . . . . . . . . . . . . . . 82

14.1.1. Vista Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8214.1.2. Vista de Secretaria . . . . . . . . . . . . . . . . . . . . . . . . 84

INDICE GENERAL vi

14.1.3. Vista de Profesional . . . . . . . . . . . . . . . . . . . . . . . 8714.1.4. Vista de Administrador . . . . . . . . . . . . . . . . . . . . . . 98

15.Implementacion 106

16.Reportes 10916.1. El disenador de reportes . . . . . . . . . . . . . . . . . . . . . . . . . 10916.2. El procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10916.3. Listado de reportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Glosario 117

Bibliografıa 120

Indice de figuras

3.1. Ventana principal de MySQL Workbench . . . . . . . . . . . . . . . . 103.2. Monitor de Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . 11

4.1. Fases en el proceso de desarrollo WebML . . . . . . . . . . . . . . . . 134.2. Modelos WebML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3. Ejemplo del modelo de estructura . . . . . . . . . . . . . . . . . . . . 164.4. Ejemplos de entidades . . . . . . . . . . . . . . . . . . . . . . . . . . 174.5. Ejemplos de entidades relacionadas . . . . . . . . . . . . . . . . . . . 174.6. Notacion grafica para un Data Unit . . . . . . . . . . . . . . . . . . . 194.7. Notacion grafica para un Multi Data Unit . . . . . . . . . . . . . . . 194.8. Notacion grafica para un Index Unit . . . . . . . . . . . . . . . . . . 194.9. Notacion grafica para un Scroller Unit . . . . . . . . . . . . . . . . . 194.10. Notacion grafica para una Entry Unit . . . . . . . . . . . . . . . . . . 204.11. Notacion grafica para un Multi Message Unit . . . . . . . . . . . . . 204.12. Notacion grafica para una Unidad de creacion . . . . . . . . . . . . . 214.13. Notacion grafica para una Unidad de eliminacion . . . . . . . . . . . 214.14. Notacion grafica para una Unidad de modificacion . . . . . . . . . . . 214.15. Notacion grafica para las Vistas . . . . . . . . . . . . . . . . . . . . . 224.16. Notacion grafica para un Area . . . . . . . . . . . . . . . . . . . . . . 224.17. Notacion grafica para una Pagina . . . . . . . . . . . . . . . . . . . . 234.18. Notacion grafica para un Enlace contextual . . . . . . . . . . . . . . . 244.19. Notacion grafica para un Enlace no contextual . . . . . . . . . . . . . 244.20. Notacion grafica para el modelado de Usuarios, Vistas y Grupos . . . 254.21. Notacion grafica para un Login Unit . . . . . . . . . . . . . . . . . . 264.22. Notacion grafica para un Logout Unit . . . . . . . . . . . . . . . . . . 264.23. Notacion grafica para un Change Group Unit . . . . . . . . . . . . . 264.24. Arquitectura de la herramienta WebRatio . . . . . . . . . . . . . . . 274.25. Notacion grafica de Webratio para los enlaces . . . . . . . . . . . . . 28

5.1. Tabla de recursos y costos necesarios para el desarrollo . . . . . . . . 315.2. Tabla de estimacion de beneficios tangibles . . . . . . . . . . . . . . . 325.3. Grafico de costos-beneficio . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1. Planificacion del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 366.2. Diagrama de Gantt de la planificacion del proyecto . . . . . . . . . . 37

8.1. Diagrama de entidad-relacion inicial . . . . . . . . . . . . . . . . . . . 45

vii

INDICE DE FIGURAS viii

8.2. Modelo de estructura inicial . . . . . . . . . . . . . . . . . . . . . . . 47

9.1. Vinculacion entre el Modelo de datos y el Modelo de hipertexto . . . 499.2. Propiedades de una unidad de contenido . . . . . . . . . . . . . . . . 509.3. Ejemplo de un modelo de hipertexto . . . . . . . . . . . . . . . . . . 51

10.1. Estilo web ofrecido por la herramienta Webratio . . . . . . . . . . . . 5310.2. Solapa Layout en las propiedades de un objeto . . . . . . . . . . . . . 54

11.1. Campos que se deben registrar en la tabla module . . . . . . . . . . . 5611.2. Tablas module y group de la base de datos . . . . . . . . . . . . . . . 57

13.1. Diagrama de estructura refinado . . . . . . . . . . . . . . . . . . . . . 7213.2. Propiedades de la fuente de datos . . . . . . . . . . . . . . . . . . . . 7513.3. DER asociado al Subsistema de Gestion de Pacientes . . . . . . . . . 7613.4. DER asociado al Subsistema de Gestion de Profesionales . . . . . . . 7713.5. DER asociado al Subsistema de Administracion de Sesiones . . . . . . 7713.6. DER asociado al Subsistema de Administracion de Tratamientos . . . 7813.7. DER asociado al Subsistema de Gestion de Historial de Escolar . . . 7913.8. DER asociado al Subsistema de Gestion de Historial Clınico . . . . . 80

14.1. Diagrama de hipertexto para la vista de Login . . . . . . . . . . . . . 8214.2. Tabla usser group de la base de datos . . . . . . . . . . . . . . . . . 8314.3. Diagrama de hipertexto para el area Paciente (Secretaria) . . . . . . 8414.4. Diagrama de hipertexto para el area Sesiones (Secretaria) . . . . . . 8514.5. Diagrama de hipertexto para el area Cuenta (Secretaria) . . . . . . . 8614.6. Diagrama de hipertexto para el area Paciente (Profesional) . . . . . . 8714.7. Diagrama de hipertexto para el area Historia Escolar (Profesional) . 9014.8. Diagrama de hipertexto para el area Historia Clınica (Profesional) . . 9114.9. Diagrama de hipertexto para el area Sesiones (Profesional) . . . . . . 9414.10.Diagrama de hipertexto para el area Tratamientos (Profesional) . . . 9514.11.Diagrama de hipertexto para el area Cuenta (Profesional) . . . . . . 9714.12.Diagrama de hipertexto para el area Paciente (Administrador) . . . . 9814.13.Diagrama de hipertexto para el area Historia Escolar (Administrador) 9914.14.Diagrama de hipertexto para el area Historia Clınica (Administrador) 10014.15.Diagrama de hipertexto para el area Sesiones (Administrador) . . . . 10114.16.Diagrama de hipertexto para el area Tratamientos (Administrador) . 10214.17.Diagrama de hipertexto para el area Cuenta (Administrador) . . . . . 10314.18.Diagrama de hipertexto para el area Profesionales (Administrador) . 104

15.1. Version de Webratio utilizada en la implementacion . . . . . . . . . . 10615.2. Icono para inicializar el servidor Apache Tomcat . . . . . . . . . . . . 10615.3. Pantalla de Login generada con la aplicacion . . . . . . . . . . . . . . 10715.4. Vista de Administrador generada con la herramienta . . . . . . . . . 10715.5. Vista de Profesional generada con la herramienta . . . . . . . . . . . 10815.6. Vista de Secretaria generada con la herramienta . . . . . . . . . . . . 108

16.1. Entorno de diseno JasperSoft Studio . . . . . . . . . . . . . . . . . . 110

Dedicado a mi familia

por su carino, comprension y apoyo.

Todo lo que sere, es gracias a ustedes.

Parte I

Investigacion y planificacion

1

Capıtulo 1

Introduccion

A lo largo de este trabajo se explicara detalladamente la metodologıa que seutilizara, el alcance que tendra el sistema y se mostrara el desarrollo y evolucion delsistema etapa por etapa. En un primera instancia se explicaran los objetivos que seintentaran alcanzar al finalizar el seminario tanto a nivel personal del autor comodel proyecto en general. Luego se describira el sistema objeto, como ası tambien lossubsistemas que lo componen y que se incluiran dentro del alcance del proyecto. Sepasara luego a dar una explicacion de la tecnologıa con la cual se trabajara, estoincluye tanto a la metodologıa WebML y los diferentes modelos que propone, comola herramienta CASE WebRatio que permitira realizar los modelos y facilitara eluso de la notacion particular de la metodologıa

Sera importante tambien efectuar un estudio de factibilidad, lo cual incluye es-tudiar la viabilidad tecnica, economica, operativa y legal. Ademas se propondra unaplanificacion tentativa con la cual trabajar el proyecto, definiendo etapas y fechaspara el cumplimiento de las mismas y por ultimo se mostrara la aplicacion practicade la metodologıa al sistema objeto.

1.1. Objetivos Generales

El objetivo general del proyecto de seminario es el de analizar y disenar un sistemapara la gestion integral de un gabinete psicopedagogico, para permitir un mejorseguimiento y control de la evolucion de los pacientes mediante la informatizacionde sus datos personales, escolares y familiares, como ası tambien de los tratamientos,test y tecnicas que se le vayan aplicando a lo largo del abordaje psicopedagogico ygestionar la agenda de sesiones programadas de cada profesional con sus pacientes.

Ası se va a intentar brindar un sistema modular y eficiente que facilite las tareasdiarias de los profesionales que trabajan en el gabinete.

1.2. Objetivos Especıficos

Aplicar la metodologıa WebML de desarrollo de software al sistema objeto deestudio, mediante el uso de la herramienta CASE WebRatio en su version de prueba

2

INTRODUCCION 3

para crear los modelos de datos, hipertexto1, presentacion y personalizacion.

1Esto incluye los modelos de composicion y de navegacion

Capıtulo 2

Sistema objeto

2.1. Concepto de gabinete psicopedagogico

La psicopedagogıa se ocupa de las caracterısticas del aprendizaje humano, ademasintenta abarcar la problematica educativa en la medida en que se hace conocer lasdemandas humanas para que se produzca el aprendizaje senalando sus obstaculos ysus condiciones facilitadoras.[1]

Entonces, a la psicopedagogıa le interesa estudiar al ser humano en toda situacionde aprendizaje, tanto en sus dificultades, como tambien en la promocion de procesosde aprendizajes significativos y creativos.[2]

Ası se define a un gabinete psicopedagogico como aquella institucion compuestapor un grupo de profesionales de diferentes disciplinas1 que trabajan juntos para ase-gurar o favorecer el ejercicio de funciones especializadas de orientacion, evaluacion,intervencion educativa, resolucion de problemas y en general, de apoyo al sistemaescolar en sus distintos niveles educativos.[3]

2.2. Descripcion del sistema objeto

El sistema objeto de estudio es un gabinete psicopedagogico, en adelante llamadoC.E.A.P. - Centro de Especializacion en Atencion Psicopedagogica - que tiene entresus objetivos:

Prevenir las dificultades en los aprendizajes.

Detectar las dificultades de los alumnos en el aprendizaje.

Potenciar las habilidades y estrategias que emplean los alumnos en la adquisi-cion de los aprendizajes academicos, independientemente del nivel alcanzadopor cada uno de ellos.

Colaborar con los equipos docentes en el desarrollo de las capacidades de losalumnos, tanto individuales como sociales.

Orientar a los padres en las posibles estrategias a seguir con sus hijos para unamejora en su rendimiento.

1Psicologıa del aprendizaje, pedagogıa, sociologıa, didactica, psicolinguıstica, fonoaudiologıa,psicomotricidad entre otras.

4

SISTEMA OBJETO 5

Derivar a otras entidades, centros o personal especializado, aquellos casos enlos que las dificultades planteadas por los alumnos no son competencia delcentro.

Contribuir a la adecuada interaccion entre los miembros de la comunidad edu-cativa: profesores, padres y alumnos.

2.3. Descripcion del proyecto de informatizacion

a realizar

El objetivo es realizar el analisis y diseno de un sistema que gestione los procesosde la organizacion, haciendo hincapie en las necesidades referidas a las tareas querealizan habitualmente los profesionales del C.E.A.P. Los subsistemas a modelarseran los siguientes:

2.3.1. Subsistema de gestion de profesionales

El cual administrara los datos personales de los profesionales que realizan susactividades dentro del C.E.A.P., entre los cuales se puede mencionar:

Datos de contacto: como telefonos, celular, email, direccion, etc.; para podercontactar a los profesionales en caso de alguna emergencia.

Datos de la matricula(Nro. y estado): puesto que ningun profesional puederealizar su trabajo sin una matricula o con una que se encuentre en estado desuspension.

Estudios de posgrado: que los profesionales puedan adquirir con el tiempo parapoder dirigirse a ellos con el debido titulo y respeto.

Tipos de roles: donde se definiran dos tipos de usuarios, los profesionales quesolo tendran acceso a sus propios datos como los de sus pacientes y una direc-tora (administradora) que podra acceder a la informacion de todos los profe-sionales y pacientes de centro.

2.3.2. Subsistema de gestion de pacientes

El cual ofrecera la posibilidad de gestionar datos del paciente, tales como:

Informacion personal: donde se podra gestionar informacion identificatoria delpaciente tal como nombres, apellido, documento, telefono, direccion, etc.

Motivo de consulta: se debera ingresar, la primera vez que el paciente se pre-sente en la organizacion, el motivo por el cual el realiza su consulta (o sututor).

Informacion de su grupo familiar: donde se podra administrar informacionrelacionada al grupo familiar con el que convive actualmente y de aquellaspersonas que tienen o tuvieron un vinculo importante con el paciente. Estaspersonas pueden ser padres, abuelos, hermanos, tıos, profesores, tutores, etc.

SISTEMA OBJETO 6

2.3.3. Subsistema de gestion de historial escolar

Donde se guardara informacion relevante sobre la escolaridad y el desempenoacademico del paciente, tal como:

Anos cursados: donde se podra administrar informacion respecto a cursos querepitio, materias en las que se destaco y en cuales tuvo dificultades.

Conducta escolar: informacion que resumira la capacidad de relacionarse consus pares y como se desenvuelve en el ambito escolar el paciente.

2.3.4. Subsistema de gestion de historial clınico

El cual registrara toda aquella informacion relacionada con el progreso de laproblematica, la salud mental y el entorno clınico del paciente. Entre los cualespodemos nombrar:

Tratamientos previos: donde se podra gestionar informacion historial sobre losdiagnosticos realizados por profesionales que trataron anteriormente al pacien-te; estos pueden haber sido del tipo psicopedagogico, psicologico, psicomotri-cista, fonoaudiologico, etc.

Avance del caso: lo cual definira el estado en el cual se encuentra el abordajedel caso. Un paciente podra estar en los siguientes estados: en presentacion,en evaluacion, en diagnostico o en tratamiento. Se registrara ademas las fechasen las que se cambio de estado (se avanzo o retrocedio en el caso).

Derivaciones: que serviran para delegar a otro profesional el caso del pacientepara que trabaje an algun area que no corresponda al campo del profesionaltratante y luego pueda retornar a su tratamiento habitual.

2.3.5. Subsistema de administracion de tratamientos

En el cual se registraran los resultados de las tecnicas aplicadas en cada sesional paciente, para lo cual se necesitara de la siguiente informacion:

Sesiones: que tendran una duracion preestablecida y serviran de contexto paraque se desarrollen los siguientes elementos:

• Test y tecnicas: las cuales son herramientas que serviran para detectardonde se encuentran los problemas, debilidades y fortalezas del pacientea tratar; podran ser de diferente tipos y se efectuaran durante todo elproceso de abordaje.

• Entrevistas: durante las cuales se recopilaran datos importantes del pa-ciente y de su entorno, entrevistando a los familiares y allegados del pa-ciente.

• Reuniones: se dara un proceso de retroalimentacion con el/los encargadosdel paciente.

Informes: los cuales seran documentos que detallaran informacion sobre losresultados obtenidos y los pasos a seguir en el futuro proximo. Podran ser dedos tipos : parciales y finales.

SISTEMA OBJETO 7

2.3.6. Subsistema de administracion de sesiones

El cual permitira llevar la agenda diaria de sesiones programadas para cadaprofesional con sus pacientes, permitiendole al profesional cargar, editar o eliminaruna sesion, con una fecha establecida (pasada o futura) y una duracion no mayor alos 45 minutos. Ası el profesional podra planificar sus sesiones y jornadas de trabajo,administrar mejor el tiempo y evitar consignar dos sesiones para el mismo dıa a lamisma hora.

Este subsistema sirve de base para el anterior, puesto que no se puede cargaruna entrevista o test aplicado sobre una sesion que no existe o que no ha ocurridoaun.

Capıtulo 3

Alcance del proyecto

El presente seminario abarcara:

El analisis y especificacion de los requisitos del cliente: en el cual se capturarany describiran detalladamente los requerimientos de funcionalidad y de calidadde servicio del sistema que se desarrollara, tratando de identificar deseos ynecesidades del cliente. [4]

El diseno del modelo de datos: mediante el cual se especificaran cuales son losdatos que estaran contenidos en el sitio web, ası como los objetos o entidadesque interactuaran en el sistema, sus propiedades o atributos y como estaranrelacionados.

El diseno del modelo de hipertexto: donde se describiran los hipertextos queseran publicados en el sitio web. Se compone de dos sub-modelos:

• Modelo de composicion: en el cual se especificaran las paginas que com-ponen cada hipertexto y las unidades de contenido de cada pagina.

• Modelo de navegacion: el cual mostrara las relaciones entre las paginasy las unidades de contenidos que formaran la estructura del hipertexto.Estas relaciones se especificaran por medio de enlaces (links).

El diseno del modelo de presentacion: una pagina es la unidad basica de lapresentacion, ası cada pagina estara asociada con una o mas hojas de estilo(style sheets). Las hojas de estilo se expresaran formalmente en XML.

El diseno del modelo de personalizacion: en donde usuarios y grupos de usua-rios son explıcitamente modelados en forma de entidades predefinidas.[5]

3.1. Eleccion de la metodologıa y las herramientas

El presente proyecto se desarrollara con la metodologıa WebML1 explotando losbeneficios que ofrece la misma. Las herramientas necesarias para la concrecion delproyecto son:

1En el siguiente capıtulo se explicara mas detalladamente la metodologıa

8

ALCANCE DEL PROYECTO 9

WebRatio: herramienta CASE compatible con WebML2.

MySQL: se usara MySQL como motor de bases de datos relacional, puestoque cuenta con licencia de software libre y es desarrollada por una subsidiariade Oracle Corporation. Entre las ventajas de utilizar este motor de base dedatos se encuentran:

• Cuenta con el respaldo de Sun Microsystems y una gran comunidad enlınea.

• Maneja el lenguaje estandar SQL.

• Se compara muy bien contra los principales manejadores comerciales.

• Se puede manejar desde una consola de comandos, de forma muy eficiente.

• Permite multiples usuarios con contrasena y distintos niveles de manipu-lacion.

• Los requerimientos son mınimos, por lo que se ejecuta bien en casi cual-quier maquina.

• Es un manejador multiplataforma (Windows, Mac OS, Linux, Solaris,etc.).

• El lımite de los registros por tabla es casi infinito, ası como las tablas.

• Existen varios IDE’s para MySQL.

• Los tiempos para mostrar los resultados de las consultas son muy bajos.[6]

Por otro lado, para gestionar la B.D. se utilizara el IDE MySQL Workbenchel cual es una herramienta visual de diseno de bases de datos que integradesarrollo de software, administracion de bases de datos, diseno de bases dedatos, creacion y mantenimiento para el sistema de base de datos MySQL. Esel sucesor de DBDesigner 4 de fabFORCE.net, y reemplaza el anterior conjuntode software, MySQL GUI Tools Bundle.

Las caracterısticas mas destacadas de la herramienta son:

• Brinda un entorno visual de desarrollo amigable y facil de entender.

• Libre, distribuida bajo la licencia GPL.

• Multiplataforma. disponible para Windows, GNU/Linux. Mac.

• Permite crear diagramas E-R.

• Importar archivos SQL.

• Permite generar los scripts SQL a partir del modelo creado.[7]

2En el siguiente capıtulo se explicara mas detalladamente esta herramienta


Figura 3.1: Ventana principal de MySQL Workbench

Apache Tomcat: Se utilizara Apache Tomcat, el cual es un servidor web consoporte de servlets y JSPs, que ademas incluye el compilador Jasper, el cualcompila las JSPs convirtiendolas en servlets.

Por otro lado hoy en dıa Tomcat es usado como servidor web autonomo enentornos con alto nivel de trafico y alta disponibilidad. Ademas dado que fueescrito en Java, funciona en cualquier sistema operativo que disponga de lamaquina virtual Java.[8]

Cuenta con licencia Apache, la cual es de software libre creada por la ApacheSoftware Foundation y da al usuario del software la libertad de usarlo paracualquier proposito, distribuirlo y modificarlo sin ningun pago por su uso.

La Licencia Apache no exige que las obras derivadas (versiones modificadas)del software se distribuyan usando la misma licencia, ni siquiera que se tenganque distribuir como software libre.


Figura 3.2: Monitor de Apache Tomcat

En la Figura 3.2 se puede observar el monitor desde el cual podemos arrancaro detener servidor web, ademas de configurar las rutas de instalacion de Javay otras opciones de seguridad. Adicionalmente, una vez iniciado el servicio sepuede acceder a un administrador de las aplicaciones que se encuentran insta-ladas en el servidor desde la direccion http://127.0.0.1:8080/manager3.

3La direccion 127.0.01 es equivalente a la direccion “localhost”

Capıtulo 4

Marco teorico

El lenguaje de modelado web (WebML) es una metodologıa de diseno web de ter-cera generacion, concebida en 1998, tras los primeros modelos hipermedia y disenosweb. La meta original de WebML era soportar el diseno y la implementacion de lasdenominadas aplicaciones web de datos intensivos, definidas como sitios web para elacceso y mantenimiento de una gran cantidad de datos estructurados, usualmentealmacenados como registros en una base de datos.

Para alcanzar este objetivo, la metodologıa reutilizo el modelo conceptual dedatos existente y propuso una notacion original para expresar la navegacion y lascaracterısticas de composicion de interfaces de hipertexto. El modelo de hipertextotomo un enfoque bastante diferente de sus propositos iniciales: en lugar de ofrecer unalto numero de primitivas que representen todos los caminos posibles al organizaruna interfaz de hipertexto que pueden ocurrir en aplicaciones web que usan datosintensivamente, se enfoco en inventar un numero mınimo de conceptos, los cualespueden ser usados en caminos bien definidos para obtener un numero arbitrario deconfiguraciones de aplicaciones.

4.1. La metodologıa WebML

WebML es un lenguaje visual para especificar la estructura de contenidos de unaaplicacion web y la organizacion y presentacion de tal contenido en un hipertexto.

12

MARCO TEORICO 13

Figura 4.1: Fases en el proceso de desarrollo WebML[5]

Como se observa en la figura, el enfoque de la metodologıa al desarrollar apli-caciones web consiste en diferentes fases. Inspirado en el modelo espiral de Boehmy acorde con los metodos modernos para la web y el desarrollo de aplicaciones, elproceso WebML es aplicado de una manera iterativa e incremental en la cual lasdiferentes fases son repetidas y refinadas hasta que los resultados cumplen con losrequerimientos. El ciclo de vida del producto, por lo tanto se somete a varios ciclos,cada uno produciendo un prototipo o una version parcial de la aplicacion. En cadaiteracion, la version actual de la aplicacion es probada, evaluada y luego extendidao modificada para hacer frente a los requerimientos previamente recolectados, asıcomo los que surgieron en el camino. Ası un ciclo de vida iterativo e incrementales particularmente apropiado para el contexto web, donde las aplicaciones deberser rapidamente desarrolladas y los requerimientos tienden a cambiar durante eldesarrollo.[5]

4.1.1. Analisis de requerimientos

El analisis de requerimientos se enfoca en colectar informacion sobre el domi-nio de la aplicacion y las funciones esperadas para luego especificarlas mediantedescripciones faciles de entender. La entrada a esta actividad es el conjunto de re-querimientos del negocio que motivan al desarrollo de una aplicacion. Los principalesresultados de esta fase son:

La identificacion de los grupos de usuarios usados por la aplicacion. Cada gruporepresenta usuarios que tienen la misma caracterıstica o juegan el mismo roldentro de un proceso del negocio. Un mismo usuario puede jugar diferentesroles perteneciendo ası a diferentes grupos.

La especificacion de requerimientos funcionales que configuran las funcionesa ser provistas a los usuarios. Para cada grupo de usuarios, las actividadesrelevantes a ser ejecutada son identificadas y especificadas.

La identificacion de objetos de informacion basica.

MARCO TEORICO 14

La descomposicion de la aplicacion web en vistas. A cada grupo de usuariosse le proporcionara al menos una vista del sitio que soporte las funcionesidentificadas por el grupo.

Los analistas podran usar su formato favorito para la especificacion de requeri-mientos, por ejemplo formatos tabulares que cuales pueden ser usados para capturarlos requerimientos informales ası como los grupos o las descripciones de las vistas desitio o UML que usa diagramas de casos y diagramas de actividad, que pueden tam-bien ser usados como representaciones estandar de escenarios de uso y actividades desincronizacion. En particular, los requerimientos funcionales pueden ser capturadospor flujos de actividad, mostrando secuencia, paralelismo y sincronizacion entre lasactividades a ser ejecutadas por los diferentes grupos de usuarios.[4][5]

4.1.2. Modelado conceptual

El modelado conceptual consiste en la definicion conceptual de esquemas, loscuales expresan la organizacion de la aplicacion a un alto nivel de abstraccion, in-dependientemente de los detalles de implementacion. Se compone por el diseno dedatos y el diseno de hipertexto:

El diseno de datos corresponde a la organizacion de los objetos centrales deinformacion previamente identificados durante el analisis de requerimientos enun esquema de datos comprensivo y coherente, posiblemente enriquecido atraves de objetos derivados.

El diseno de hipertexto produce entonces esquemas de vistas de sistema enla parte superior del esquema de datos anteriormente definido. Las vistas desitio expresan la composicion de los contenidos y servicios dentro de paginasde hipertexto, ası como la navegacion y la interconexion de componentes.

4.1.3. Implementacion

El desarrollo de aplicaciones con WebML es asistido por WebRatio, una herra-mienta comercial para el diseno e implementacion de aplicaciones web. La arquitec-tura de WebRatio consiste en dos capas : una capa de diseno, la cual provee funcionespara la edicion visual de especificaciones y una capa a nivel de ejecucion, que imple-menta los servicios basicos para ejecutar unidades WebML en la parte superior deun framework de aplicaciones web estandar.[5]

4.1.4. Pruebas y evaluacion

El enfoque basado en modelos beneficia a la prueba sistematica de aplicaciones,gracias a la disponibilidad del modelo conceptual y el enfoque de transformacionde los modelos para la generacion de codigo. Con respecto al tradicional testeo deaplicaciones, el foco cambia de verificar aplicaciones web individuales a la evalua-cion de la exactitud del codigo generado. Intuitivamente uno podrıa asegurar que

MARCO TEORICO 15

el generador de codigo produce una implementacion correcta para todos los esque-mas conceptuales legales y significativos, entonces el testeo de las aplicaciones sereducirıa al problema, mas sencillo, de validar el esquema conceptual.

Trabajos de investigacion llevados a cabo en esta area, han demostrado que esposible evaluar cuantitativamente la confianza en la exactitud de un generador decodigo basado en modelos, midiendo formalmente la cobertura de un conjunto deprueba dado con respecto al universo entero de esquemas sintacticamente admisibles.Diferentes nociones de cobertura fueron propuestas y varias heurısticas han sidoderivadas para minimizar el numero de casos de prueba necesarios para llegar alnivel de cobertura deseado en el proceso de prueba.

El desarrollo basado en modelos tambien fomenta la creacion de tecnicas inno-vadoras para la evaluacion de la calidad. Las investigaciones en esta area han dadolugar a un framework y evaluaciones automaticas de la calidad de aplicaciones web.

El framework soporta el analisis estatico de esquemas conceptuales y la colecciondinamica de los datos que usa la web para ser analizadas automaticamente y com-paradas con la navegacion dictada por el esquema conceptual. El analisis estaticose basa en el descubrimiento, en el esquema conceptual, de patrones de diseno y suevaluacion automatica contra atributos de calidad codificados como reglas. Inver-samente, el analisis de uso consiste en la examinacion automatica y la minerıa deregistros web enriquecidos, llamados registros conceptuales, que relacionan registrosHTTP comunes con informacion adicional sobre las unidades y los caminos de enlaceaccedidos por los usuarios y los objetos de la base de datos publicados dentro de laspaginas visitadas. [5]

4.1.5. Mantenimiento y evolucion

En el proceso basado en modelos, el mantenimiento y la evolucion tambien sebenefician de la existencia de una modelo conceptual de la aplicacion. Las solicitudesde cambios pueden convertirse en cambios a nivel conceptual, ya sean sobre el modelode datos o de hipertexto. Entonces, los cambios a nivel conceptual son propagadosa la implementacion. Este enfoque, levemente incorpora gestion de cambio dentrode la corriente principal del ciclo de vida de la produccion y reduce enormementeel riesgo de romper el proceso de ingenierıa del software debido a la aplicacion decambios unicamente en el nivel de implementacion. [9]

4.2. Modelos WebML

La especificacion de un sitio con WebML se basa en la construccion de modelos,estos son cuatro: el modelo estructural, el de hipertexto, el de presentacion y el depersonalizacion.

MARCO TEORICO 16

Figura 4.2: Modelos WebML[16]

4.2.1. Modelo de estructura

Las entidades poseen atributos con nombre y un tipo asociado; propiedades conmultiples ocurrencias pueden ser organizadas por medio de componentes multiva-luadas, las cuales corresponden a la relacion clasica “part-of”1.

Por otro las entidades puede ser organizadas en jerarquıas de generalizacion ylas relaciones pueden ser dadas por restricciones y nombres de rol.

WebML no propone otro idioma para el modelado de datos , pero es compatiblecon notaciones clasicos como el modelo E/R , el modelo orientado a objetos ODMG,y diagramas de clases UML. Para hacer frente a la exigencia de expresar informacionredundante y calculada, el modelo estructural tambien ofrece un lenguaje de consultaOQL, mediante el cual es posible especificar la informacion derivada.[5][9]

Figura 4.3: Ejemplo del modelo de estructura

Entidades

Las entidades representan objetos basicos de informacion, es decir son una des-cripcion de un conjunto de objetos de caracterısticas similares. Ejemplos de entidades

1Relacion por la cual se construyen objetos a partir de la combinacion de otros

MARCO TEORICO 17

son Pacientes, Sesiones, Areas de estudio, Pruebas, etc.El conjunto de objetos representados en una entidad se llaman instancias de la

entidad. La notacion grafica para una entidad es un rectangulo que lleva el nombrede la misma en la parte superior. La siguiente imagen muestra dos entidades y susatributos.

Figura 4.4: Ejemplos de entidades

Relaciones

Las relaciones representan conexiones semanticas entre entidades, aquellas queconectan dos entidades se llaman binarias y las que conectan dos o mas entidadesse llaman relaciones N-arias.

Cada relacion binaria esta caracterizada por dos roles, cada rol expresa la funcionque cada una de la entidades participantes juega en la relacion. Tienen asignadoslımites de cardinalidad mınima y maxima, denotados por el numero mınimo y maxi-mo, respectivamente, de objetos de la entidad destino a la cual algun objeto dela entidad fuente puede estar relacionado. Es decir, la cardinalidad de una enti-dad informa el grado de participacion de dicha entidad en la relacion. Se expresanindicando el valor mınimo y maximo: 1:1, 1:N y N:N.

La siguiente figura ilustra el caso en el que un Informe tiene un solo Tipo deinforme, y un Tipo de informe puede estar presente en muchos Informes.

Figura 4.5: Ejemplos de entidades relacionadas

Identificacion de Clave Primaria

Todas las instancias de una entidad tienen un identificador unico que permitedistinguirlas unıvocamente. Para expresar el identificador unico de las instancias dela entidad, uno o mas atributos pueden ser definidos como la clave primaria de la

MARCO TEORICO 18

entidad. La clave primaria debe satisfacer ciertas restricciones no solicitadas para losotros atributos. Sus valores deben estar definidos (esto es, no deben ser nulos) parainstancias de la entidad, y deber ser unicos, esto quiere decir que no deben existirdos instancias de la entidad con el mismo valor para el atributo clave.

Es buena practica definir la clave primaria de la entidad usando un atributosimple llamado Objeto Identificador (abreviado OID). Posteriormente, cuando efec-tuemos el Modelo de estructura para el caso de estudio, se notara la presencia deeste atributo en todas la entidades ya que la herramienta CASE WebRatio que asisteal modelado en WebML lo crea automaticamente dentro de cada entidad.

Tipos de atributos

Los atributos pueden asumir valores definidos en un dominio de datos. El modelono prescribe un conjunto especıfico de tipos para atributos, pero es buena practicaexpresar tipos de atributos en el modelo de datos, para hacer mas expresiva laespecificacion y mejorar la implementacion.

A continuacion, se asume que los atributos de las entidades se asocian con lostipos de datos soportados por la mayorıa de los lenguajes de programacion y basesde datos: string, text, integer, float, date, time, bolean, enumeration, blob, etc.

4.2.2. Modelo de hipertexto

Describe uno o mas hipertextos que pueden ser publicados en el sitio. Cadahipertexto diferente define lo que se denomina una vista del sitio. Estas ultimas asu vez se describen mediante dos submodelos: el modelo de composicion y el denavegacion.

4.2.3. Modelo de composicion

El proposito de este modelo es definir que nodos conforman el hipertexto quefigura en el sitio Web . Mas precisamente, el modelado de la composicion espe-cifica unidades de contenido (unidades para abreviar), es decir, los elementos deinformacion atomicos que pueden aparecer en el sitio web y paginas, es decir, loscontenedores por medio de los cuales la informacion es agrupada para su entrega alusuario. En un entorno concreto , por ejemplo, una aplicacion HTML o WML deun sitio WebML, paginas y unidades se asignan a las construcciones adecuadas enel lenguaje de entrega, por ej. las unidades se pueden asignar a archivos HTML ylas paginas a HTML a frames que organizaran los archivos en la pantalla.

Unidades de datos

WebML soporta los siguientes tipos de unidades para componer un hipertexto:

Data Units: muestran informacion sobre un unico objeto, por ejemplo, unainstancia de una entidad o de un componente.

MARCO TEORICO 19

Figura 4.6: Notacion grafica para un Data Unit

Multidata Units: muestran informacion sobre un conjunto de objetos, por ejem-plo, todas las instancias de una entidad o todos los sub-componentes de unobjeto compuesto.

Figura 4.7: Notacion grafica para un Multi Data Unit

Index Units: muestran una lista de objetos (instancias de entidad o compo-nentes), sin presentar la informacion detallada de cada objeto.

Figura 4.8: Notacion grafica para un Index Unit

Scroller Units: muestran comandos para acceder a los elementos de un conjuntoordenado de objetos (el primero, ultimo, anterior, siguiente, i-esimo).

Figura 4.9: Notacion grafica para un Scroller Unit

Entry Units : se utilizan para mostrar un formulario. Por ejemplo, con el usode esta unidad, podemos disenar un patron de busqueda o un formulario deentrada de datos.

MARCO TEORICO 20

Figura 4.10: Notacion grafica para una Entry Unit

Multi Message Units : permiten al usuario imprimir mensajes dentro de lapagina.

Figura 4.11: Notacion grafica para un Multi Message Unit

Data Units y Multidata Units presentan el contenido real de los objetos a loscuales refieren, en tanto que los restantes tipos de unidades permiten localizar ob-jetos. Por otro lado los Data units se refieren a un solo objeto, mientras que losMultidata, Index y Scroller Units se refieren a un conjunto de objetos, por lo cualson denominados en conjunto unidades de contenedores.[5][9]

Administracion de contenidos

WebML soporta la especificacion de operaciones para la administracion de con-tenido. Estas operaciones permiten crear, borrar o modificar una instancia de unaentidad, o bien agregar o eliminar una relacion entre dos instancias.

Las unidades de operacion son un nuevo tipo de unidades que se colocan fuera delas paginas y pueden ir unidas a otras operaciones o unidades de contenido definidasdentro de la pagina. A diferencia de las unidades de contenido, las operaciones nodespliegan contenido, por eso el hecho de colocarlas fuera de las paginas ya querepresentan una accion. Estan descriptas por un objeto fuente (como puede ser unaentidad o relacion) y selectores, que pueden recibir parametros de los links de entraday enviar valores por medio de los links de salida que seran usados como parametros.

WebML provee operaciones preconstruidas o predefinidas dentro del lenguaje.Debido a que esta es una metodologıa para el diseno de aplicaciones Web con usointensivo de datos las operaciones predefinidas ofrecen tareas para la administracion[5]. A continuacion se listara cada operacion predefinida:

Unidad de creacion: Permite la creacion de una nueva instancia de la enti-dad. Esta caracterizada por:

• Un nombre definido por el usuario.

• Una entidad fuente sobre la cual aplica la operacion.

• Un conjunto de asignaciones vinculando los atributos del objeto a sercreado con los valores de los parametros de los links de entrada o algunasconstantes.

MARCO TEORICO 21

Figura 4.12: Notacion grafica para una Unidad de creacion

Unidad de eliminacion: Esta unidad se usa para borrar uno o mas objetosde las entidades. Cada unidad esta caracterizada por:


• Una entidad fuente y el selector que define la condicion que deben cum-plir aquellos objetos o conjunto de objetos sobre los cuales aplicar laoperacion.

Figura 4.13: Notacion grafica para una Unidad de eliminacion

Unidad de modificacion: Se usa para actualizar uno o mas objetos de unaentidad dada. Se caracteriza por:


• Una entidad fuente junto a un selector que define la condicion que debencumplir aquellos objetos o conjunto de objetos sobre los cuales aplicaresta operacion.

• Un conjunto de asignaciones vinculando los nuevos valores a los atributosde los objetos a modificar.

Figura 4.14: Notacion grafica para una Unidad de modificacion

Contenedores de vista

La especificacion de un complejo hipertexto puede organizarse jerarquicamentepor medio del uso de construcciones modularizadas como vistas de sitio, areas ypaginas anidadas.

MARCO TEORICO 22

Vistas del sitio: una vista de sitio WebML consta de un conjunto de paginasy links, con un estilo de presentacion asociado. En un mismo proyecto puedendisenarse diferentes vistas de sitio para distintos accesos de dispositivos o paradistintos grupos de usuarios. Esto es debido a la separacion entre el modeloestructural y el modelo de hipertexto y da lugar a la definicion de muchasvistas o modos de presentar un mismo modelo de datos.

Figura 4.15: Notacion grafica para las Vistas

Areas: un area es un contenedor de vista compuesto por paginas y areasanidadas para la publicacion o la gestion de contenido homogeneo . Es posiblecrear diferentes areas en la misma vista sitio y un area puede contener anidadasotra areas y paginas.

Figura 4.16: Notacion grafica para un Area

Paginas: una pagina es un contenedor que tiene una o mas porciones de in-formacion que se muestra al usuario en un momento determinado. Una paginapuede contener a otras, formando paginas anidadas. Los usuarios navegan unsitio formado por paginas.

Se podrıa decir que son la abstraccion de su propia region de contenido enla pantalla, que es tratado como un bloque de interfase independiente. Ejem-plos de implementaciones concretas de un concepto abstracto de pagina en unlenguaje especıfico puede ser un frame en HTML o una carta en WML.

Las paginas pueden organizarse internamente en sus unidades y/o recursiva-mente en otras paginas. En el ultimo caso, las subpaginas de un contenedor depaginas se tratan como bloques de presentacion diferentes (similar a la nocionde frames dentro de un conjunto de frames en HTML). Las paginas se puedenanidar en forma conjunta (Ej.: desplegar juntas) o en forma disjunta (Ej.: eldespliegue de una pagina es alternativo al despliegue de otra subpagina).

MARCO TEORICO 23

Las sub-paginas AND/OR permiten representar paginas de estructura com-pleja que ocurren en la practica. El caso simple ocurre cuando una porcion deuna pagina esta fijo (Ej.: el frame izquierdo en una pagina HTML), y otra por-cion puede desplegar informacion variable basada en los comandos del usuario(Ej.: la informacion en la parte derecha de un frame puede ser reemplazadapor diferentes datos luego de un clic del usuario en el frame izquierdo) [18].

Figura 4.17: Notacion grafica para una Pagina

Un contenedor de vista puede estar marcado como:

Home: El contenedor de inicio es el principal de un sitio. Es lo primero queel usuario deberıa ver. Cada vista del sitio debe contener una pagina marcadacomo pagina de inicio (Home), identificada con una letra “H” o “D” (Default).

Punto de referencia: Si un contenedor esta marcado con una letra “L” seentiende que es un contenedor referenciable. Estos son globalmente visibles porlas demas paginas y el usuario puede acceder a esa contenedor desde cualquierotro contenido en la misma vista del sitio.

4.2.4. Modelo de navegacion

Las unidades y las paginas que no existen de manera aislada, sino que deben estarconectadas para formar una estructura de hipertexto. El proposito del modelado denavegacion es especificar la forma en que las unidades y las paginas se unen paraformar un hipertexto. Para este proposito, WebML ofrece la nocion de enlace. Haydos variantes de enlaces:

Enlaces contextuales: conectan unidades de una manera coherente con lassemantica expresadas por la estructura de esquema de la aplicacion. Un enlacecontextual lleva algo de informacion (llamado contexto) de la unidad fuentea la unidad de destino. Este contexto se utiliza para determinar el objeto oconjunto de objetos que seran mostrados en la unidad de destino.

MARCO TEORICO 24

Figura 4.18: Notacion grafica para un Enlace contextual

Enlaces no contextuales: conectan paginas de una manera totalmente libre, esdecir, independientemente de las unidades que contienen y de las relacionessemanticas entre los conceptos estructurales incluidas en esas unidades.

Figura 4.19: Notacion grafica para un Enlace no contextual

Sintacticamente, enlaces contextuales y no contextuales se denotan como HY-PERLINK e INFOLINK, respectivamente anidadas dentro de las unidades y pagi-nas.

4.2.5. Modelo de presentacion

Expresa la disposicion y aspecto grafico de las paginas, independientemente deldispositivo de salida y del lenguaje por medio de una sintaxis XML abstracta.Laespecificaciones de la presentacion puede ser de paginas especıficas o genericas. Enel primer caso dictan la presentacion de una pagina especıfica e incluyen explıci-tamente referencias al contenido de la pagina; en el segundo caso, son basadas enmodelos predefinidos, independientes del contenido especıfico de la pagina e incluyenreferencias a elementos de contenido generico.

El modelado de presentacion se refiere a la apariencia de las paginas identificadaspor el modelo de composicion. Las paginas WebML se renderizan de acuerdo conuna hoja de estilo,la cual dicta el diseno de las paginas y en que disposicion loselementos de la misma seran insertados, independientemente del lenguaje utilizadopara la ejecucion de la pagina. Para una mejor reutilizacion, se proporcionan doscategorıas de hojas de estilo:

Hojas de estilo no tipificadas: tambien llamados modelos,los cuales describenel diseno de la pagina de forma independiente a su contenido, y por lo tantopueden ser aplicadas independientemente de la asignacion de la pagina paraun concepto dado.

Hojas de estilo tipificadas: que especifican en una granularidad mas fina y porlo tanto se aplican solo a las paginas que describen conceptos especıficos.[5]

MARCO TEORICO 25

4.2.6. Modelo de personalizacion

Los usuarios y grupos de usuarios se modelan explıcitamente en el esquema deestructura en forma de entidades predefinidas llamadas Usuario y de Grupo. Lascaracterısticas de estas entidades se pueden utilizar para almacenar informacion demanera especıfica o grupal. Entonces, expresiones declarativas pueden ser anadidas alesquema de estructura, que define el contenido derivado basado en los datos de perfilalmacenados en el usuario y las entidades del Grupo. Este contenido personalizadopuede ser utilizado tanto en la composicion de las unidades o en la definicion de lasespecificaciones de presentacion.[5]

Por otro lado WebML distingue dos clases de usuarios, registrados y no registra-dos. El primero tiene una identidad conocida por la aplicacion que dura el tiempode una sesion (tal identidad puede haber sido provista en un proceso de login). Elsegundo carece de identidad conocida para la aplicacion.

De la misma manera, WebML distingue dos clases de vistas de sitio: publicas oprivadas. La primera puede ser accedida por cualquier tipo de usuario. La segundarequiere una credencial por parte del usuario para permitirle el acceso.

WebML considera usuarios, grupos, vistas de sitio y sus relaciones semanticasparte del modelo conceptual de una aplicacion. El esquema de estructura de unaaplicacion usando vistas de sitio protegidas debe incluir un fragmento como el de laFigura 4.20 , el cual puede ser enriquecido con atributos adicionales y relacionesnecesarias para modelar aun mas las propiedades de usuarios y grupos [17].

Figura 4.20: Notacion grafica para el modelado de Usuarios, Vistas y Grupos

La estructura se interpreta de la siguiente manera:

Cada usuario puede pertenecer a uno o mas grupos.

Cada usuario puede estar asociado con un grupo distinguido, que actua comoel grupo por defecto del usuario.

Cada grupo definido tiene una vista de sitio (modulo) que se presenta a losusuarios incluidos en el.

MARCO TEORICO 26

Unidades de sesion

Son unidades que permiten manejar el acceso al sistema mediante usuarios, asıcomo salir del mismo y terminar la sesion actual. Existen tres tipos de unidades desesion:

Login Unit : la verificacion para el acceso a las vistas protegidas esta mode-lado por WebML con la operacion llamada login. Esta es usada para establecerla identidad del usuario que esta ingresando al sitio, y lo direcciona a la paginaprincipal de la vista de sitio asociada a su grupo por defecto. La operacion tienedos parametros fijos, uno para el nombre de usuario y otro para la contrasena.

Figura 4.21: Notacion grafica para un Login Unit

Logout Unit : la operacion logout se usa para abandonar la sesion de unusuario logueado, y llevarlo a una pagina por defecto que no tenga control deacceso es decir que sea publica. La operacion logout no tiene valores de entraday de salida, por lo cual puede invocarse por medio de un link no contextual.

Figura 4.22: Notacion grafica para un Logout Unit

Change Group Unit : las solicitudes de paginas en una aplicacion en WebMLestan sujetas a control de acceso si es que la vista de sitio es privada: si elusuario X solicita la pagina Y, la pagina Y debe pertenecer a la vista de sitioasociada con uno de los grupos donde el usuario pertenece. Es por eso queWebML contempla la posibilidad de que un usuario logueado pueda cambiarentre los grupos que el pertenece, mientras navega una vista de sitio, y accedera las paginas de la vista de sitio del grupo al que emigro sin la necesidad deabandonar la sesion y realizar de nuevo una validacion de usuario. Estas tareasestan desempenadas por la operacion Cambio de Grupo. La operacion tomaun parametro de entrada, el OID del grupo, chequea la relacion UsuarioGrupoy lleva al usuario a la pagina principal de la vista de sitio del grupo.

Figura 4.23: Notacion grafica para un Change Group Unit

MARCO TEORICO 27

4.3. Webratio

WebRatio es una plataforma de desarrollo de aplicaciones basadas en modelos.Permite desarrollar visualmente programas web y aplicaciones moviles con resultadosprofesionales, en lugar de escribir todo el codigo.

Expertos del negocio y en tecnologıas de la informacion pueden trabajar jun-tos para desarrollar rapidamente una aplicacion robusta, segura y escalable de laempresa en una fraccion del tiempo, en comparacion con otras metodologıas y he-rramientas. La tecnologıa de generacion de codigo inteligente de WebRatio construyeautomaticamente aplicaciones listas para su funcionamiento a traves de una interfazamigable y facil de utilizar.

La arquitectura de esta herramienta se divide en dos capas: la capa de diseno,que proporciona funciones par la edicion visual de las especificaciones y la capa deejecucion, que implementan los servicios necesarios para la ejecucion de distintasunidades WebML en una aplicacion [16].

Figura 4.24: Arquitectura de la herramienta WebRatio[16]

A partir de requerimientos de analisis aun incompletos que luego se van modifi-cando y transformando dentro del modelo, se produce un prototipo que se comparacon las expectativas previstas, de esta forma se tiene un nuevo modelo actualizadoen base a nuevos requerimientos y se convierte en un prototipo que evoluciona hastala version final.[10][11]

4.3.1. Notacion para enlaces

La herramienta Webratio adopta la siguiente notacion para los enlaces:

MARCO TEORICO 28

Figura 4.25: Notacion grafica de Webratio para los enlaces

Ası un enlace podra ser del tipo:

Normal link: un enlace normal es un punto de anclaje o un boton que el usuariotiene que activar con el fin de cambiar el contenido de la pagina o pasar a otrapagina.

Transport link: este tipo de enlace se utiliza solo para pasar la informacion decontexto de una unidad a otra. Se denomina enlace de transporte , para ponerenfasis en el hecho de que el enlace solo permite pasar parametros, y no lanavegacion del usuario.

OK y KO link: son enlaces utilizados por las unidades de operacion de WebRa-tio para especificar que unidad es el objetivo de la operacion en funcion de losresultados de la operacion . Si la operacion ejecutada por la unidad terminacon exito , el enlace sera del tipo OK ; de lo contrario se utiliza el enlace KO.

Capıtulo 5

Estudio de factibilidad

El estudio de factibilidad permitira tomar una decision en cuanto a si debe conti-nuar o no con el desarrollo del sistema. Ahora la factibilidad significa que el proyectopropuesto:

Ayudara a la organizacion a lograr sus objetivos

Sera posible de lograr con los recursos actuales de la organizacion (o aquellosque se puedan conseguir).

Se realizara entonces un analisis teniendo en cuenta la factibilidad a nivel tecnica,economica, operativa y legal.

5.1. Factibilidad tecnica

Se investigara si es posible desarrollar el nuevo sistema teniendo en cuenta losrecursos tecnicos y tecnologicos actuales en la organizacion o en el medio.

Se procedera entonces, a adquirir el hardware necesario para poner en marchael sistema, mientras que el software no supondra costo alguno al utilizarse herra-mientas gratuitas o que tienen version de prueba. Los recursos y herramientas quese utilizaran son los siguientes:

Hardware

Se adquirira una PC de escritorio que servira como servidor para el sistema.

Se adquirira un router wireless para la instalacion de la red interna.

Se adquirira una impresora, que servira para la impresion de documentos yreportes.

Se utilizaran las PC’s portatiles de cada profesional como terminales1.

Software

WebRatio en su version de prueba.

MySQL Woorkbench como DBMS del motor MySQL.

1Se necesitara que las maquinas puedan correr Windows 7 como mınimo.

29

ESTUDIO DE FACTIBILIDAD 30

Servidor Web Apache Tomcat para alojar el proyecto.

Es necesario que las PC (tanto servidor como terminales) se encuentren conec-tadas a la misma red interna.

Se concluye entonces que los recursos tecnicos y tecnologicos necesarios podranser adquiridos, con lo cual es factible la realizacion del proyecto desde el punto devista tecnico.

5.2. Factibilidad economica-financiera

En este apartado se debe evaluar que el costo en los cuales la empresa incurra seanmenores a aquellos beneficios que la misma obtendra de la realizacion y posterioruso del sistema. Se debe tambien considerar si actualmente existe dinero suficientepara afrontar dichos gastos o si en su defecto se pueden conseguir financiacion deterceros2.

En la siguiente tabla se describen los recursos que seran necesarios para desarro-llar el proyecto y una estimacion3 de los costos asociados a los mismos.[12]:

2Estos pueden ser prestamos bancarios, de entidades financieras o prestamistas3Los honorarios de los profesionales fueron obtenidos de la Res. No 139/09 del COPAIPA,

actualizando los montos con una tasa de inflacion del 25 % y el precio del servidor se obtuvo de latienda virtual de Musimundo, luego de comparar precios de Garbarino, Fravega y Compumundo.


Figura 5.1: Tabla de recursos y costos necesarios para el desarrollo

Se procedera a enunciar ahora los beneficios que se esperan alcanzar con la im-plementacion del sistema y a su vez se los clasificara en:


Tangibles:

Figura 5.2: Tabla de estimacion de beneficios tangibles

En la Figura 5.2 se observa la tabla de estimacion de beneficios tangibles, te-niendo en cuenta que en el C.E.A.P. existen 4 profesionales que trabajan haciendo4 hs a la manana con los pacientes y 4 horas por la tarde haciendo analisis e inter-pretacion de datos. Cada profesional atiende 4 pacientes al dıa y el precio por sesiondiaria es de $120.[14]

Intangibles:

Calidad y uniformidad en la elaboracion de documentos.

Organizacion de las fichas y antecedentes de los pacientes.

Mayor orden y control en la organizacion.

Calidad y mayor control de los casos clınicos.

La organizacion financiara la mitad del costo del proyecto con capital propio yla otra mitad lo hara con un prestamo bancario. Por otro lado se puede estimar larecuperacion de la inversion, observando la cuantificacion de beneficios tangibles yla Figura 5.3, en aproximadamente 6 meses. Se concluye ası que el proyecto seraviable economica y financieramente.


Figura 5.3: Grafico de costos-beneficio

5.3. Factibilidad operativa

La viabilidad operacional depende de los recursos humanos disponibles para elproyecto e implica la accion de pronosticar si el sistema se utilizara una vez instalado.En este punto se puede decir que:

Puesto que la directora de esta institucion es la interesada en el desarrollo delsistema y fue quien impulso el proyecto, se provee que habra un alto nivel decompromiso por parte de la misma.

Puesto que el objetivo principal del proyecto es agilizar y facilitar las tareasdiarias de los profesionales se prevee que los mismos contribuiran a la operacionexitosa del sistema, como ası tambien que ayudaran brindando retroalimenta-cion para la correccion de errores y adaptaciones.

Puesto que no existe ningun otro sistema en funcionamiento actualmente, elsistema resultante no sera comparado ni debera competir con otro para lograrla aceptacion de los profesionales.

Se brindara un manual del usuario como ası tambien jornadas de capacitacion alos usuarios finales para resolver cualquier duda que pudiesen tener los mismos.

Se concluye entonces que el proyecto sera viable operativamente.

5.4. Factibilidad Legal

En esta seccion se analizara cualquier infraccion, violacion a la ley o ilegalidadque pudiere resultar del desarrollo del sistema.

Los recursos de software que se utilizaran cuentan con las licencias respectivas,y en el caso de WebRatio se utilizara la version de prueba. Ademas el personalinformatico que trabajara, se contratara segun las normas y salarios establecidos


por el COPAIPA - Consejo Profesional de Agrimensores, Ingenieros y ProfesionesAfines de Salta - que es el consejo que nuclea a los profesionales informaticos.

Por otro lado el sistema debera garantizar confidencialidad y seguridad a losdatos contenidos en las historias clınicas de los pacientes, acorde a lo establecido enla ley No 26.529.

Esta ultima garantiza el derecho a la intimidad y a la confidencialidad de toda in-formacion medica concerniente a los pacientes, ademas del respeto por la autonomıadel paciente y el derecho a recibir la informacion necesaria para su salud.

Citando el inciso ‘d’ del articulo 2:“El paciente tiene derecho a que toda persona que participe en la elaboracion o

manipulacion de la documentacion clınica, o bien tenga acceso al contenido de lamisma, guarde la debida reserva, salvo expresa disposicion en contrario emanada deautoridad judicial competente o autorizacion del propio paciente”[13]

Por estas consideraciones el proyecto sera viable desde el punto de vista legal yen conclusion sera factible en general.

Capıtulo 6

Planificacion del proyecto

El desarrollo del presente seminario constara de varias etapas en las que se llevaraadelante el analisis y diseno del sistema mediante la utilizacion de la metodologıaWebML (Lenguaje de Modelado Web) y siguiendo un desarrollo iterativo e incre-mental. A continuacion se detallan las etapas involucradas en el proyecto.

Etapa 1: Recopilacion de informacion e investigacion sobre las herramientasy la metodologıa necesarias para desarrollar el proyecto: WebML y WebRatio.

Etapa 2: Estudio y familiarizacion con las herramientas.

Etapa 3: Instalacion y configuracion del entorno de desarrollo.

Inicio de la primera iteracion

Etapa 4: Recopilacion y especificacion de requerimientos. Al principio de estaetapa se producira una reunion con el cliente donde se fijaran las funcionali-dades que el mismo desea esten presentes en el sistema.

Etapa 5: Primer diseno del modelo de datos y todos los soportes necesariospara el almacenamiento de informacion de nuestro sistema. Aquı se modelarala BD y se hara una primera aproximacion al modelo de estructura.

Etapa 6: Primer diseno del modelo de hipertexto, como asi tambien de losmodelos que lo componen .

Etapa 7: Primer diseno del modelo de presentacion, es decir la definicion dela apariencia de las paginas.

Etapa 8: Primer diseno del modelo de personalizacion.

Etapa 9: Construccion del prototipo usando el generador de WebRatio.

Etapa 10: Presentacion del prototipo al cliente, donde se tomara nota de lascorrecciones que haga el mismo para poder refinar los diferentes modelos.

Inicio de la segunda iteracion

Etapa 11: Refinamiento y correccion del modelo de estructura.

35

PLANIFICACION DEL PROYECTO 36

Etapa 12: Refinamiento y correccion del modelo de hipertexto, como asıtambien de los modelos que lo componen .

Etapa 13: Refinamiento y correccion del modelo de presentacion.

Etapa 14: Refinamiento y correccion del modelo de personalizacion.

Etapa 15: Construccion de un segundo prototipo usando el generador deWebRatio.

Etapa 16: Presentacion y entrega del nuevo prototipo al cliente con las co-rrecciones propuestas por el mismo.

Etapa 17: Documentacion del avance y confeccion del informe.

La Figura 6.2 muestra el diagrama de Gantt con la planificacion tentativa. Laduracion de las etapas esta expresada en dıas con una carga horaria de 2 hs. por dıaaproximadamente (10 hs. semanales).

Figura 6.1: Planificacion del proyecto

PLANIFICACION DEL PROYECTO 37

Figura 6.2: Diagrama de Gantt de la planificacion del proyecto

Parte II

Aplicacion de la metodologıa: 1o

Iteracion

38

Capıtulo 7

Analisis de requerimientos

Este sera el primer paso en el proceso de desarrollo del sistema, luego de habertenido una reunion inicial con la direccion de la organizacion, se procedera a realizarla:

Descripcion del ambito del sistema (narrativa).

Definicion de los grupos de usuarios.

Determinacion de los requerimientos funcionales para cada grupo de usuarios.

Es importante decir que en este capitulo no se listara la totalidad de los requeri-mientos funcionales, esto se hara en un capıtulo posterior , luego de la presentaciondel 1o prototipo con el cliente para poder tabular correctamente el conjunto defuncionalidades que abarcara el sistema.

7.1. Ambito del sistema

Dentro de la organizacion, cada vez que ingresa un nuevo paciente la seccionde secretarıa procede a registrar sus datos personales. Entre estos datos se carga elmotivo por el cual se realiza la consulta y la fecha en que se hace la misma. Dichosdatos seran unicamente necesarios para la primera vez que el paciente ingrese.

Luego se asigna dicho paciente a un profesional de la organizacion, ya sea pordisposicion o preferencia del paciente (o su encargado), y se fija la fecha y hora dela primera sesion.

Cada sesion no podra durar mas de 40 minutos y un profesional no podra tenerasignado mas de un paciente el mismo dıa en la misma franja horaria, ademas deque debera consignar con anterioridad que tipo de tratamiento se planea efectuar.Por otro lado dentro de una sesion se puede desarrollar cualquiera de los siguienteselementos:

Prueba: las cuales son los tipos de test y tecnicas que el profesional puedeaplicarle al paciente, donde cada uno tiene un area especifica de aplicacion.Estas son:

• Madurativa

• Proyectiva

39

ANALISIS DE REQUERIMIENTOS 40

• Psicopedagogica

• Cognitiva

Ademas, regularmente se desarrollan y publican nuevos tipos de pruebas porparte de la comunidad cientıfica e investigadora del area psicopedagogica ypsicologica. Actualmente el C.E.A.P. aplica los siguientes tipos:

• Dibujo Libre (Area madurativa)

• D.F.H. (Area madurativa)

• Gestaltico Viso-Motor (Area madurativa)

• Dibujo de la Familia (Area proyectiva)

• Dibujo de la Familia Kinetica (Area proyectiva)

• H.T.P. (Area proyectiva)

• Dip(Le) (Area psicopedagogica)

• WISC IV (Area cognitiva)

• Hora de Juego (Area psicopedagogica)

• Analisis del cuaderno (Area proyectiva)

• Observacion de la clase (Area proyectiva)

Cada prueba que se aplica tiene asociada un documento en donde se vuelca lainformacion obtenida y ademas se puede contar (opcionalmente) con archivoscomplementarios tales como grabaciones de audio o video y fotos de la pruebatomada1.

Entrevista: en donde el profesional cita y le efectua una entrevista preparadaa algun (solo un) familiar o allegado del paciente para recolectar informacionrelevante. Ademas se puede contar con otros archivos complementarios talescomo grabaciones de audio, transcripciones o escaneos de la entrevista2.

Reunion: en donde el profesional cita al encargado del paciente para informarlesobre algun problema que esta teniendo el mismo o bien sobre los avances yprogresos en su problematica.

A lo largo de las sesiones, el profesional recopilara mucha informacion, entre ellainformacion personal y de contacto sobre los familiares y allegados al paciente.

Por otro lado redactara periodicamente informes que podran ser parciales o fi-nales (de cada etapa del caso), en los cuales se describe detalladamente las tecnicasabordadas y los resultados que se obtuvieron (progresos en el caso).

Por otro lado se recopila la informacion historial y actual de la escolaridad delpaciente, detallando el establecimiento, el curso y el ano en el que asistio el paciente,ademas de si repitio dicho ano y bajo que circunstancias lo hizo. Resulta importantetambien guardar por cada curso la conducta general que el paciente tuvo durante elano para poder detectar indicios de su problematica y resulta muy util contar conel boletın de calificaciones de dicho ano.

1Siempre contando con la autorizacion debida para realizar dichas grabaciones o tomar dichasfotos.

2Siempre contando con la autorizacion debida para realizar dichas grabaciones.


Otro eje de informacion importante para el tratamiento del caso es la historiaclınica del paciente, dentro de la cual se registran :

Tratamientos previos: donde se detallan cuales fueron las problematicas quese le trataron al paciente, entre que periodo se realizaron dichos tratamientoy a que area clınica pertenecen. Estas ultimas pueden ser:

• Psicomotriz

• Neurologica

• Fisiologica

• Psicologica

• Psiquiatrica

• Fonoaudiologica

• Nutricional

• Estimulacion temprana

• Psicopedagogica

Derivaciones: surgen cuando un profesional del detecta que uno de sus pa-cientes debe iniciar un tratamiento en otra area clınica distinta a la psicope-dagogica. Puede resultar que no se pueda continuar con el caso hasta que seresuelva dicha problematica o bien que se traten ambas (la derivada y por laque acudio el paciente al centro) simultaneamente.

Se registra la fecha de derivacion, la fecha de culminacion del tratamientoderivado, el area clınica3 a la cual pertenece y se elabora un reporte detallandola situacion y las razones por las cuales cree el profesional que el paciente debeiniciar otro tratamiento.

Avances en el caso: cada vez que el paciente avanza (o retrocede) en las etapasde su tratamiento se registra dicho evento y la fecha en que sucede. Los estadosde un caso pueden ser:

• Presentacion del caso

• Administracion de pruebas y test

• Analisis y evaluacion

• Diagnostico

• Tratamiento

• Derivado

• Finalizado

• Interrumpido

La direccion del centro registra ademas, informacion relevante a sus profesionalestales como datos personales, telefonos y direcciones de contacto (utiles ante algunaurgencia), nivel de estudios e informacion sobre su matricula profesional4.

3Las cuales son las mismas que los tratamientos previos4Puesto que por ley, ningun profesional puede trabajar sin una matricula activa y autorizada


La directora del C.E.A.P. tiene acceso a toda la informacion de los profesionalesy de sus pacientes, esto es para poder controlar el trabajo de los mismos, balancear lacarga horaria y si fuera necesario ayudar en algun caso puntual a algun profesional.Sin embargo estos ultimos solo tienen acceso a la informacion de sus pacientes, poretica profesional y un acuerdo de confidencialidad entre el paciente, sus familiares,el profesional tratante y la directora del centro.

7.2. Definicion de grupos de usuarios

Se estableceran tres grupos (o tipos) de usuarios, estos seran:

Secretaria: La cual tendra acceso al sistema con ciertas limitaciones. Un usua-rio de este tipo podra:

• Listar y administrar informacion personal unicamente, sobre todos lospacientes que asisten a la organizacion.

• Listar y administrar las sesiones de todos los profesionales que trabajanen la organizacion. Se debe aclarar que no podra acceder al detalle de lassesiones, puesto que esto es informacion clasificada.

Profesional: El cual tendra acceso al sistema con ciertas limitaciones. Unusuario de este tipo podra:

• Obtener acceso a una cierta cantidad de reportes.

• Listar y gestionar informacion propia unicamente.

• Listar y administrar informacion sobre todos sus pacientes que asisten ala organizacion (no ası la de pacientes de otros profesionales).

Administrador: El cual tendra acceso a toda la informacion y sitios del sis-tema, sin ningun tipo de restriccion. Particularmente se asignara este usuarioa la directora del centro, con lo cual podra:

• Obtener acceso a una mayor cantidad de reportes.

• Listar y editar informacion sobre todos los profesionales de la organiza-cion.

• Listar y editar informacion sobre todos los pacientes que asisten a laorganizacion.

Es importante destacar que este ultimo tipo de usuario sera asignado a la directoradel centro, puesto que sera ella la unica autorizada a acceder a la totalidad de lainformacion y datos de la organizacion.

Por otro lado, el sistema funcionara en una red interna de la organizacion, conlo cual para poder ingresar al mismo se requerira estar registrado. El unico grupoque puede crear usuarios es el Administrador, con lo cual este sera el encargado dedar de alta a los profesionales que existen y que vayan ingresando al centro. Cabedestacar que no se proveera el acceso de manera anonima al sistema o desde unservidor online.

Capıtulo 8

Modelo de estructura

Para la elaboracion de este modelo y del de hipertexto1 se realizaran dos iteracio-nes de produccion. La primera, o tambien llamada desarrollo incremental, la cual apartir del analisis de requerimientos buscara aproximar el producto lo mas posible alsistema objeto que se intenta modelar, luego sigue una reunion con el cliente, el cualdara su opinion sobre lo que se desarrollo y validara los modelos ademas de corregiraquellos que el crea necesarios. Posteriormente (con las correcciones del cliente), seprocedera a efectuar una segunda iteracion o tambien llamada etapa de refinamientode los modelos.

Ası, en la metodologıa WebML el proceso de diseno comenzara con la definiciondel esquema de la estructura de datos, dentro del cual se especificara la organizacionde los datos. Esta estructura se iniciara definiendo los objetos basicos de informaciony sus relaciones.

8.0.1. Identificacion de las entidades basicas de informacion

Para esta tarea se desarrollara el Diagrama de Entidad–Relacion, lo cual no soloayudara para identificar y entender mejor las relaciones y dependencias entre lasdistintas unidades de datos que deberıa tener en cuenta la aplicacion, sino tam-bien ayudara a descubrir nuevas entidades necesarias debido a que poseen atributospropios e importantes para la organizacion.

Algunas de las entidades mas importantes que se identificaron, luego del analisis:

Pacientes

Familiares

Sesiones

Test

Profesionales

Historia Escolar

Antecedente clınico

1Si bien la metodologıa propone hacer iteraciones para todos los modelos, en nuestro caso nosupusieron un foco de atencion y mas adelante se hablara de dichos modelos.

43

MODELO DE ESTRUCTURA 44

Y otras que se iran viendo mas en detalle a medida que se avance en el desarrollo yrefinamiento de los modelos. A continuacion se muestra un borrador, creado usandola notacion grafica de los DER, de la estructura de datos:


Figura 8.1: Diagrama de entidad-relacion inicial


8.0.2. Modelo inicial

En la Figura 8.2 se presenta una aproximacion inicial del modelo de estructu-ra, generado con la herramienta Webratio, a partir del analisis de requerimientosfuncionales y de la descripcion de la realidad elaborada en los puntos anteriores.


Figura 8.2: Modelo de estructura inicial

Es importante explicar un poco la notacion grafica que usa WebML para indicarla cardinalidad de las relaciones entre las entidades. La misma es mas cercana a lautilizada en los diagramas de clases UML en POO, que a la que se conoce comonotacion DER, es por esto que parecerıa ser que estan invertidas.


Por ejemplo en la relacion entre User y Paciente vemos una flecha que une dichasentidades con un 1 del lado del Paciente y una N del lado del User. Esto debe serinterpretado como 1 Paciente solo puede ser atendido por un User y un User puedeatender muchos pacientes.

Capıtulo 9

Modelo de hipertexto

Ahora se apreciara el aporte que realiza el modelo anterior (modelo de datos), enla Figura 9.1 se refleja como las unidades de contenido y de operacion del modelo dehipertexto se asientan sobre el modelo de datos, para poder exhibir la informacion.

Figura 9.1: Vinculacion entre el Modelo de datos y el Modelo de hipertexto

La herramienta WebRatio ayudara en esta asociacion de la siguiente manera:

Primero se debera crear la unidad de contenido y asignarle un nombre, en esteejemplo son las entidades Sesion, Entrevista, Reunion y Prueba.

En las propiedades de la unidad (parte izquierda de la Figura 9.1) en elcampo Entity se debera elegir la entidad con la que se va asociar la unidad decontenido.

49

MODELO DE HIPERTEXTO 50

Figura 9.2: Propiedades de una unidad de contenido

Tambien se tendra el campo Display Attributes que permitira seleccionar losatributos a mostrar.

9.1. Modelo inicial

Aquı partiendo de los requerimientos obtenidos en la reunion inicial con el clientese construira un modelo inicial de las paginas y los vınculos que interactuaran enel sistema. Puesto que este modelo es extenso de explicar y documentar, en esteseminario solo se adjuntara la documentacion de la version refinada, es decir luegode que se haya realizado la validacion y verificacion de la version inicial con el cliente.

Se mostrara como ejemplo el diseno de hipertexto del modulo de pruebas, estemismo modelo mas adelante sera refinado y se le agregaran funcionalidades depen-diendo de las correcciones que surjan de la presentacion del primer prototipo.

MODELO DE HIPERTEXTO 51

Figura 9.3: Ejemplo de un modelo de hipertexto

Capıtulo 10

Modelo de presentacion

Definir la presentacion es la tarea de determinar el aspecto visual de las paginasen una vista del sitio.

Como las especificaciones WebML pueden ser representadas usando XML, la pre-sentacion es considerada como una transformacion documental, marcando el trazadode las especificaciones WebML de una pagina escrita a un lenguaje concreto de im-plementacion como JSP o ASP . Las paginas en WEBML se presentan de acuerdocon una hoja de estilo de XLS. Una hoja de estilo dicta el diseno de paginas y delos elementos de contenido que se incluira en dicha disposicion.

El modelo toma las hojas de estilo codificadas en documentos XML como en-trada y genera plantillas incluyendo las marcas requeridas para el diseno grafico ylas consultas de acceso a datos. En la Figura 10.1 se muestra la hojas de estiloprovista por WebRatio que se utilizo para generar la prototipacion en el modelo depresentacion.

52

MODELO DE PRESENTACION 53

Figura 10.1: Estilo web ofrecido por la herramienta Webratio

MODELO DE PRESENTACION 54

Si bien es cierto que la version de Webratio que se utilizo para este seminarioes una de prueba, es importante destacar la sencillez y lo completo que trabaja laaplicacion en este sentido, casi desligando al desarrollador de esta tarea.

Existe una tienda de add-on oficial de Webratio, en la cual se pueden comprar unamultitud de estilos, haciendo que las aplicaciones queden mucho mas profesionales.

Una de las desventajas que se encuentran en esta version de pruebas es la impo-sibilidad de modificar los estilos por defecto, haciendo imposible modificar el layoutdel mismo y personalizarlo, pero para la tarea de prototipacion (que es nuestro caso)es mas que suficiente.

Para aplicar una hoja de estilo en la aplicacion que se generara mas adelantees necesario elegir dicho estilo en la solapa Layout, dentro de las propiedades de unarea.

No es necesario ir aplicando area por area el estilo, basta con hacerlo en la vistao area superior y el estilo seleccionado en el objeto mas grande se aplica a todos losque se encuentren dentro. Esto es muy comodo puesto que por lo general se trabajancon varias areas en una aplicacion mediana y estar seleccionando el estilo en todomomento serıa algo engorroso.

Para la aplicacion se decidio utilizar un estilo que viene incluido, llamado We-bRatio.

Figura 10.2: Solapa Layout en las propiedades de un objeto

Capıtulo 11

Modelo de personalizacion

El modelo de personalizacion trabaja muy de cerca con el de hipertexto, en el sen-tido de que todo aquello que se modelo en el segundo debe expresarse explicitamenteen el primero.

Esto se logra (en la herramienta Webratio) trabajando con la base de datosgenerada por la aplicacion y la solapa General de las propiedades de las areas y vistasque se modelaron anteriormente. Los pasos para crear el modelo de personalizacionson los siguientes:

1. Una vez se han modelado todas las vistas de la aplicacion, se deben registrarestas ultimas en la base de datos. Especıficamente en la tabla module.

2. Para ello nos dirigiremos a las propiedades de las vistas y luego entraremos ala pestana General, allı copiamos los campos Id y Name y los insertamos comoun nuevo registro en la tabla module en los campos moduleid y modulenamerespectivamente

55

MODELO DE PERSONALIZACION 56

Figura 11.1: Campos que se deben registrar en la tabla module

MODELO DE PERSONALIZACION 57

3. De manera analoga se debe proceder con todos aquellos modulos que se tenganprotegidos en la aplicacion (tildados en la opcion Protected).

4. Ahora en la tabla group se deben registrar todos los tipos de usuarios que co-existiran en la aplicacion. En nuestro caso son tres: Administrador, Profesionaly Secretaria.

5. Se debe observar que en esta ultima tabla hay un campo llamado module-id,allı se debe poner el id de la vista (registrada en la tabla module) por defectode ese usuario, es decir aquella que se cargara al iniciar sesion en el sistema.Como se muestra a continuacion:

Figura 11.2: Tablas module y group de la base de datos

6. En la tabla user se deben registrar los usuarios (la primera vez, se debe registrarsolo un administrador, luego se podra agregar al resto de usuarios desde laaplicacion en el modulo de profesionales) y en la tabla user-group se debenasociar los usuarios creados a los grupos que perteneceran.

7. Ahora se deben asociar los grupos a los modulos que tendran acceso en la tablagroup-module, para ello necesitaremos los id de cada tabla (la de modulos y lade grupos).

8. Con esto el sistema quedarıa configurado en cuanto a la seguridad y permisosde accesos a las distintas areas del mismo.

Parte III

Aplicacion de la metodologıa: 2o

Iteracion

58

Capıtulo 12

Refinamiento del analisis derequerimientos

Continuando con lo planteado en el Capitulo 7, se procedera a listar formal-mente los requerimientos que se habıan obtenido de la primera reunion junto con losobtenidos luego de la validacion del prototipo inicial y que impactaran directamenteen el analisis de requerimientos. Dichos cambios obtenidos de la 1o iteracion son lossiguientes:

Agregar modulo de administracion de Estado del caso.

Agregar modulo de gestion de Informes.

Agregar modulo de gestion de Derivaciones.

A partir de lo anterior se tuvo que replantear la division de subsistemas que sehabıa descripto inicialmente en el Capitulo 2, la cual era la siguiente:

Subsistema de Gestion Pacientes: que contenıa informacion personal, el histo-rial cınico, escolar e informacion del entorno familiar del paciente.

Subsistema de Gestion Profesionales: que englobaba la informacion personal,de formacion y de contacto de los profesionales.

Subsistema de Administracion de Test y tecnicas: en el cual se hallaban lostest y tecnicas aplicados al paciente, ademas de las reuniones y entrevistas asus familiares.

Subsistema de Administracion de Sesiones: en el cual se encontraba informa-cion sobre las sesiones que cada profesional tenıa con sus pacientes.

Pero con las nuevas entidades e informacion que se debıa incorporar al sistema,se decidio plantear la siguiente division de subsistemas:

Subsistema de Gestion de Pacientes: que pasara a contener solo la informacionpersonal del paciente y de los familiares del paciente.

Subsistema de gestion de Profesionales: que se mantendra sin cambios.

59

REFINAMIENTO DEL ANALISIS DE REQUERIMIENTOS 60

Subsistema de gestion de Historial escolar: donde se registrara la informacionde los anos escolares cursados por el paciente y la conducta escolar manifestadaen dicho ano. De ser posible se registrara tambien un archivo digital del boletınescolar.

Subsistema de gestion de Historial clınico: a donde se agruparan los tratamien-tos previos del paciente, el historial del avance en su caso y las derivacionesque le realice su profesional asignado.

Subsistema de administracion de tratamientos: anteriormente llamado subsis-tema de administracion de test y tecnicas, el cual se mantendra sin cambios aexcepcion del incorporamiento de los informes.

Subsistema de administracion de sesiones: el cual se mantendra sin cambios.

12.1. Definicion de requerimientos

12.1.1. Requerimientos funcionales

Los requerimientos funcionales son declaraciones de los servicios que proveera elsistema, de la manera en que este reaccionara a entradas particulares y estımulospor parte de los usuarios. Esta especificacion debera ser completa (que los serviciossolicitados por el usuario esten definidos) y consistente (que los requerimientos notengan definiciones contradictorias).

Aunque en la practica, para sistema grandes y complejos, resultara imposiblecumplir los requerimientos de consistencia y complecion. La razon de esto se debeparcialmente a la complejidad inherente del sistema y a que los diferentes puntos devista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando losrequerimientos se especifican por primera vez. Los problemas emergen despues de unanalisis profundo y una vez que estos se hayan descubierto en las diferentes revisioneso en las fases posteriores del ciclo de vida, se deben corregir en el documento derequerimientos. [15]

Para el sistema que se desarrollara, se definiran entonces los siguientes reque-rimientos funcionales, identificando el grupo de usuario que tendra acceso a dichafuncionalidad :










12.1.2. Requerimientos no funcionales

Rendimiento: Garantizar que el diseno de las consultas u otro proceso no afecteel desempeno de la base de datos, ni considerablemente el trafico de la red.

Seguridad: Garantizar la confiabilidad, la seguridad y el desempeno del sistemainformatico a los diferentes usuario. En este sentido la informacion almacenadao registro realizados podran ser consultados y actualizados permanentementey simultaneamente, sin que se afecte el tiempo de respuesta. Por otro lado sedebe garantizar la seguridad del sistema con respecto a la informacion y datosque se manejan tales sean documentos, archivos y contrasenas.

Finalmente se deben brindar facilidades y controles para permitir el acceso ala informacion al personal autorizado, con la intencion de consultar y subirinformacion pertinente para cada una de ella.

Fiabilidad: El sistema debe tener una interfaz de uso intuitiva y sencilla.


Disponibilidad: La disponibilidad del sistema debe ser continua con un nivelde servicio para los usuarios de 7 dıas por 24 horas, garantizando un esquemasadecuado que permita la posible falla en cualquiera de sus componentes ycontar con un plan de contingencia.

Portabilidad: El sistema podra ser instalado en cualquier servidor con ApacheTomcat y luego ser ejecutado desde cualquier terminal conectada a la mismared que el servidor.[19]

Todo el analisis efectuado en este capıtulo y el Capıtulo 7 se realizo siguiendolas practicas recomendadas en el documento ANSI/IEEE 830 [20]. Es importantedecir que al ser un documento que trata el analisis de requerimientos en general, sedebieron realizar algunas modificaciones y eliminar ciertas secciones como por ejem-plo la seccion de acronimos (innecesaria puesto que el informe contiene una seccionde glosario), restricciones al sistema (que se tuvieron en cuenta en el analisis deviabilidad) y la de mejoras futuras (que se expondran mas adelante) para adaptarlode la mejor manera a la metodologıa WebML.

Capıtulo 13

Refinamiento del modelo deestructura

Luego de la presentacion del prototipo inicial de la aplicacion con el cliente, sepudo validar y corregir el mismo a partir de la retroalimentacion obtenida por partede los interesados en el sistema. A continuacion se listan dichas correcciones:

Cambiar nombre de entidad Test y tecnicas a Pruebas.

Agregar historial de cambios de Estado del caso: con lo cual se pretende regis-trar el avance o retroceso del paciente en las diferentes etapas del caso.

Agregar entidad Informes : los cuales son documentos que profesional redactaraperiodicamente sobre el progreso de un caso en particular.

Agregar Tipos de informes : estos tipos serviran para tipificar los informes delinciso anterior, los cuales podran ser parciales o finales.

Agregar conducta escolar como campo de Historia escolar : se agregara la con-ducta escolar a la entidad Historia escolar.

Agregar escala de Conducta: la cual servira para tipificar la conducta y podraser insatisfactoria, regular, buena, muy Buena o sobresaliente).

Agregar boletın de calificaciones como campo de historia escolar: consistiraen un campo en la entidad Historia escolar el cual almacenara un archivodigitalizado del boletın de calificaciones de ese ano.

Agregar entidad Derivaciones : las cuales podra aplicar un profesional a supaciente y ademas perteneceran a un area clınica, que seran las mismas que lade la entidad Antecedente clınico.

71

REFINAMIENTO DEL MODELO DE ESTRUCTURA 72

Figura 13.1: Diagrama de estructura refinado


A continuacion se describiran en forma general cada una de las entidades queintervienen en el modelo de estructura de toda la aplicacion:

1. User: en esta entidad se registran los datos personales de los profesionales quetrabajan en el centro ademas de su usuario y contrasena con los cuales ingresaal sistema. Es importante aclarar que esta entidad reune a todas aquellaspersonas que puedan acceder de alguna manera al sistema.

2. Group: aquı se definen los tipos de usuarios que habran en la aplicacion y quetendran diferentes niveles de acceso y de permisos. En particular habran tres :Administrador, Profesional y Secretaria. Esta entidad servira para agrupar alos diferentes usuarios en los grupos antes mencionados, con la particularidadque un usuario que tenga permisos de adeministrador podra ejercer dos roles:el de admnistrador propiamente dicho y el de profesional.

3. Module: sirve para registrar la informacion de los diferentes modulos que secrearan en el modelo de hipertexto. Es de manejo interno exclusivo de la he-rramienta Webratio y ayuda al control de permisos y acceso en la aplicacion.

4. Paciente: agrupa toda la informacion personal del paciente y es la entidadcentral del sistema, es decir por la cual casi todos los susbsistemas se conectan.

5. Familiar: en esta entidad se guarda toda la informacion personal de los fami-liares del paciente y su vinculo con el mismo.

6. Vinculo: sirve para tabular todas los posibles vınculos y relaciones que unfamiliar pueda tener con el paciente.

7. Sesion: reune la informacion basica de las sesiones tal como fecha, hora deinicio, paciente al que pertenece, etc.

8. Reunion: es un tipo de actividad que se puede desarrollar dentro de una sesiony sirve para informar sobre algun tema en particular al familiar encargado delpaciente.

9. Entrevista: es un tipo de actividad que se puede desarrollar dentro de unasesion y se la utiliza para recabar informacion sobre el entorno del pacienteentrevistando a algun paciente en particular.

10. Prueba: es un tipo de actividad que se puede desarrollar dentro de una sesion ysirve para evaluar las capacidades mentales, motoras, psicologicas y cognitivasdel pacientes. Puede ser de diferentes tipos.

11. Tipo de prueba: sirve para tipificar las pruebas del inciso anterior y regular-mente se incorporan nuevas y se dan de baja otras, con lo cual se debe preveresta situacion en el sistema. Pueden evaluar diferentes areas del paciente.

12. Area de prueba: sirven para clasificar los tipos de prueba del inciso anterior ypermiten visualizar que area se puede evaluar con determinado tipo de prueba.


13. Informe: son documentos que el profesional redactara periodicamente, ya seapara uso propio (interno de la organizacion) o para hacer una devolucion a losfamiliares del paciente.

14. Tipo de informe: sirve para tipificar los informes del punto anterior. En parti-cular podran ser parciales o finales.

15. Historia Escolar: reune toda la informacion sobre la escolaridad del pacienteano por ano, incluyendo cambios de escuela y si el mismo repitio algun curso.

16. Conducta: indica la conducta general del paciente durante un ano escolar.

17. Curso: tabula los diferentes cursos a los que un paciente puede asistir o pu-do haber asisitido. Abarca desde las salitas de jardın hasta el ultimo ano desecundaria.

18. Avance en el caso: sirve para indicar en que fecha se produjo un avance oretroceso en el caso de un paciente.

19. Estado del caso: clasifica las diferentes etapas por las cuales un caso puedetransitar.

20. Antecedente clınico: en esta entidad se registran antecedentes clınicos anterio-res que se le aplicaron al paciente, ası como el periodo en el que ocurrieron.

21. Derivacion: si durante la aplicacion del tratamiento a un paciente, el profe-sional detecta que el mismo debe ser tratado en otra area, debera derivar alpaciente oportunamente al profesional que corresponda. Puede ocurrir que sutratamiento en el C.E.A.P. se interrumpa o continue con ambos tratamien-tos al vez. Se puede dar otro tipo de derivacion, la cual ocurre dentro de laorganizacion. Como el profesional tratante es el unico autorizado a accedera los datos de un paciente, en caso de que este deba ausentarse durante unperiodo prolongado se debera registrar una derivacion del paciente indicandoel nuevo profesional tratante. Al ser esto una situacion muy poco frecuente enla organizacion, puesto que se trata de que el paciente sea tratado siempre porel mismo profesional, no sera necesario crear otra entidad para registrar estas“derivaciones internas”.

22. Area clınica: clasifica las diferentes areas clınicas a las que pueden pertenecerlas derivaciones y los antecedente.

23. Sexo: indica la sexualidad biologica del paciente.

13.0.1. Asociacion del modelo a una Base de Datos

Una vez definido el diagrama Entidad - Relacion, la herramienta WebRatio proveela opcion de asociar esta estructura a una base de datos. Esta accion corresponde alo que se llama “mapeo” y se lo puede hacer de la siguiente manera:

El “mapeo” consiste en asociar una BD a la estructura de datos formada enWebRatio. Para ello se debe crear una base de datos vacıa en el directorio donde


se guardara el proyecto, para ello se creara la Base de Datos llamada sapsi enMySQL. En este trabajo se utilizo un driver para poder conectarse a MySQL (mysql-connector-java-5.1.5-bin.jar). La Figura 8.4 muestra las propiedades de la fuentede datos para realizar el mapeo.

Figura 13.2: Propiedades de la fuente de datos

WebRatio tiene la capacidad de crear tablas automaticamente para el almace-namiento del contenido de las entidades y relaciones modeladas en la estructura delproyecto.

Para proceder al mapeo se selecciona en WebRatio la base de datos del Modelode Datos y con el boton derecho del mouse hacemos clic en la opcion Sinchronize.Luego marcamos todas las Entidades y Relaciones, hacemos clic con el boton derechodel mouse y luego elegimos la opcion Export to DataBase.

Luego del mapeo la aplicacion entrega un archivo .txt con las instrucciones SQLutilizadas para crear todas las tablas y los tipos de datos definidos en la creacion decada atributo.

Si se modifica algo en la estructura de datos, se debe hacer un Refresh a labase de datos para que esta se actualice. Esta caracterıstica se debe destacar ya quees una tarea recurrente modificar el diseno de datos constantemente a lo largo deldesarrollo del proyecto ante nuevas apariciones o redefiniciones de requerimientos.


Figura 13.3: DER asociado al Subsistema de Gestion de Pacientes


Figura 13.4: DER asociado al Subsistema de Gestion de Profesionales

Figura 13.5: DER asociado al Subsistema de Administracion de Sesiones


Figura 13.6: DER asociado al Subsistema de Administracion de Tratamientos


Figura 13.7: DER asociado al Subsistema de Gestion de Historial de Escolar


Figura 13.8: DER asociado al Subsistema de Gestion de Historial Clınico

Capıtulo 14

Refinamiento del modelo dehipertexto

A partir del modelo de datos y del analisis de requerimientos se construira unmodelo de hipertexto inicial. En el se podıan observar las tres vistas del sistema,estas son:

Login: es la vista por defecto del sistema y no se requiere de ningun permi-so para acceder a ella. Consiste en un formulario que recibe el usuario y lacontrasena y la compara contra la base de datos de usuarios registrados. Encaso de un correcto acceso (que el usuario y la contrasena existan y coincidancon el registrado) se redirigira la navegacion a la vista por defecto del usuario(Administrador o profesional) y en caso de un acceso erroneo se recargara lapagina sin acceder a ninguna vista.

Administrador: permite acceder a los datos de todos los profesionales y suspacientes ademas de acceder a otras funcionalidades y administrar entidadesque un usuario normal no puede1.

Profesional: es la vista por defecto de los usuarios normales o profesionalesque trabajan en el centro, permite unicamente acceso a su informacion y la desus pacientes.

Luego de la presentacion del primer prototipo con el cliente, se obtuvieron lassiguiente correcciones y modificaciones aplicables al modelo de hipertexto:

Mostrar cartel de confirmacion al intentar dar de baja una entidad.

Agregar columna Estado del caso en la lista de pacientes.

Agregar columna Curso en la lista de pacientes.

Agregar atributo Area de prueba en el detalle de una prueba.

Cambiar vista por defecto de los usuarios administradores a la vista Adminis-trador.

Corregir funcion Editar contrasena. Al ingresar una nueva contrasena y darleAceptar, la aplicacion devuelve un error.

1Estas funcionalidades se explicaran en secciones posteriores

81

REFINAMIENTO DEL MODELO DE HIPERTEXTO 82

Reestructurar y reasignar las opciones disponibles en el menu superior.

Construir el modulo de gestion (listar los existentes, agregar, editar y dar debaja) de la entidad Estado del caso.

Construir el modulo de gestion (listar los existentes, agregar, editar y dar debaja) de la entidad Informe.

Construir el modulo de gestion (listar los existentes, agregar, editar y dar debaja) de la entidad Derivaciones.

Definir un nuevo tipo de usuario Secretaria.

Construir la vista Secretaria.

Agregar y adaptar a la vista Secretaria los modulos de pacientes y sesiones.

14.1. Refinamiento del modelo inicial

Luego de aplicar las correcciones propuestas por el cliente y construir un nuevoprototipo se obtendra una version refinada del modelo. A continuacion se listaranlas cuatro vistas principales que compondran al sistema:

Vista de Login.

Vista de Secretaria

Vista de Profesional.

Vista de Admnistrador.

A continuacion se enumeraran las vistas y todas las areas que las componen, mostran-do el diagrama de hipertexto asociado a cada una y explicando su funcionamiento.

14.1.1. Vista Login

Figura 14.1: Diagrama de hipertexto para la vista de Login


Esta sera la unica vista publica del sistema, es decir cualquier terminal conectadoa la red interna del centro podra acceder a ella. Su funcion principal es la de recibircomo parametros el usuario y la contrasena de la persona que se quiere identificardentro del sistema, compararlos contra la base de datos de usuarios registrados y sise encuentra activo dicho usuario redirigirlo a su vista por defecto.

Puede darse el caso que el usuario no este registrado o bien se encuentre enestado inactivo por algun motivo, entonces se redirigira la navegacion a una paginainformando el error con un link para regresar a la pagina inicial.

Un usuario de tipo Profesional solo tendra acceso a la vista de profesional y asus funcionalidades, sin embargo un usuario de tipo Administrador podra alternarentre las vistas de administrador y usuario.

Dicho comportamiento debe especificarse en la base de datos generada por laherramienta, mas especıficamente en la tabla usser group

Figura 14.2: Tabla usser group de la base de datos


14.1.2. Vista de Secretaria

Area de Pacientes

Figura 14.3: Diagrama de hipertexto para el area Paciente (Secretaria)

El objetivo principal de esta area sera el de permitir al area de secretarıa el accesoal sistema, pero con ciertas limitaciones.

Podra agregar a un paciente, pero debera asignarselo a algun profesional activo.Por otro lado podra listar a todos los pacientes activos del centro, editar informacionpersonal y de contacto unicamente, no ası la informacion que el profesional recopilede cada paciente a lo largo del tratamiento (informacion escolar, clınica, etc.)

Esto permitira facilitar el trabajo de la organizacion sobre todo en el area de re-cepcion de nuevos pacientes y ayudara tambien a balancear la cantidad de pacientesentre los diferentes profesionales que trabajan en el centro.

Al ser esta la primer area que involucra una operacion de baja, se debe de explicarque el C.E.A.P. decidio que las mismas no sean fısicas, es decir que cada vez quese produce una baja en cualquier parte del sistema, dicho registro no desaparecefısicamente del sistema, sino que se pone en estado inactivo. Ası el sistema estaradisenado para mostrar unicamente aquellos registros que se encuentren activos.


Area de Sesiones

Figura 14.4: Diagrama de hipertexto para el area Sesiones (Secretaria)

El sistema tambien le permitira acceder al area de secretarıa a la lista de sesionesactivas de todos los profesionales, esto permitira asociar por primera vez una sesionde un profesional a un paciente.

Por otro lado tambien dejara dar de baja una sesion y editarla. Algo importantepara destacar de esta vista, es que si bien permitira acceder a los detalles de unasesion, no dejara que un personal de secretarıa acceda a los elementos que la com-ponen (pruebas, entrevistas y sesiones), solo mostrara detalles de la fecha y hora dela misma.

Esta es una vista limitada y fue agregada en el refinamiento del modelo a pedidodel cliente, puesto que hasta el momento la encargada de la recepcion de nuevospacientes era la directora, sin embargo junto con el desarrollo del sistema se decidioreestructurar la organizacion y se contratara a una secretaria que coordinara a losnuevos pacientes (siempre consultando a la direccion) y avisara a los profesionales amedida que los pacientes vayan llegando a sus sesiones programadas.


Area Cuenta

Figura 14.5: Diagrama de hipertexto para el area Cuenta (Secretaria)

Permite al usuario visualizar y administrar sus datos de cuenta, ademas de salirde la sesion actual.


14.1.3. Vista de Profesional

Area de Pacientes

Figura 14.6: Diagrama de hipertexto para el area Paciente (Profesional)


Esta es el area encargada de la gestion de pacientes, su informacion personal y lade sus familiares. Dentro de esta area se podran encontrar dos modulos principalesque son los asociados a las areas de Fichas de pacientes y Grupo Familiar.

Fichas de pacientes

Dentro de esta area se agrupan las funcionalidades necesarias para mantener ygestionar a los pacientes que asisten al centro. Estas son:

Listar pacientes: recibira como parametro el usuario actual que se encuentraconectado al sistema y mostrara una lista con informacion asociada a todoslos pacientes que son atendidos unicamente por dicho usuario (profesional).Mostrara un link que permite agregar un nuevo paciente que sera atendidopor dicho profesional.

Agregar paciente: recibira como parametro el usuario actual que se encuentraidentificado en el sistema y la fecha actual, ademas de toda la informacionpersonal del paciente necesaria y luego lo registra en la base de datos. En casode ocurrir algun error, redirigira la navegacion a una pagina que informa dichasituacion.

Baja de paciente: recibira como parametro el codigo del paciente y como sedijo anteriormente solo se cambiara su estado a inactivo, es decir no borraradicho paciente definitivamente del sistema. Esto es por razones de seguridad ya pedido del cliente.

Editar paciente: cargara un formulario similar al del modulo de Agregar pa-ciente con los datos que ya tiene registrados en la base de datos de un pacientey permitira modificarlos. Una vez hecho los cambios registrara los mismos en labase de datos, sin embargo permitira tambien cancelar la edicion sin registrarningun cambio.

Perfil del paciente: a traves de una unidad de contenido se mostrara informa-cion personal sobre el paciente del cual se recibio el codigo.

Todos los modulos anteriores estaran relacionados entre si mediante enlaces, loscuales se nombraron y clasificaron en el marco teorico.

Grupo familiar

Sera el modulo encargado de la administracion de los datos personales del grupofamiliar y allegados al paciente. La informacion necesaria para que funcione serarecopilada por el profesional a medida que avance en la investigacion del caso.

Permitira listar los familiares de un paciente en particular, agregar un familiar,editarlo y darlo de baja. Todas estas funcionalidades operan de manera analoga almodulo anterior.

Para especificar bien los tipos de vınculos que puedan tener un paciente con susfamiliares se decidio cargarlos directamente a la base de datos en la tabla asociadaa la entidad Vinculo. Esto se hizo ası puesto que son datos que no van a cambiarnunca, aunque si requirio relevar junto al cliente todos los vınculos posibles, que selistan a continuacion:


Madre

Padre

Hermana

Hermano

Abuela Materna

Abuela Paterna

Abuelo Materno

Abuelo Paterno

Tio

Tia

Primo

Prima

Maestra

Profesor

Padrastro

Madrastra

Hermanastro

Hermanastra

Sobrina

Sobrino


Area de Historia Escolar

Figura 14.7: Diagrama de hipertexto para el area Historia Escolar (Profesional)


Area de Historia Clınica

Figura 14.8: Diagrama de hipertexto para el area Historia Clınica (Profesional)


Componen el eje de la investigacion, puesto que un abordaje psicopedagogicoconsta del analisis del entorno clınico (es decir la salud mental y clınica del pacien-te) y del analisis del rendimiento escolar principalmente (existen otros factores quetambien se abordan, pero estos son los dos mas importantes).

Historia escolar

Permite gestionar la informacion relacionada al historial academico del paciente,permitiendo indicar que curso, en que institucion y en que ano asistio el mismo,ademas de poder registrar cual fue su conducta general y comportamiento en eseano. A pedido del cliente se incluyo un campo el cual permite guardar un archivodigitalizado del boletın de calificaciones de dicho curso, el cual se ira actualizando2

a medida que avance el ciclo lectivo y quedara cargado con la ultima entrega.Analogo a todas las areas mostradas anteriormente, permite agregar un historial

escolar, editarlo, darlo de baja y listar toda la historia escolar de un paciente enparticular.

Para permitir una mejor tabulacion de los cursos y la conducta, se decidio cargardirectamente en la base de datos todos los cursos y tipos de conducta posibles. Estose hizo ası puesto que son datos que no van a cambiar (al menos no tan seguido), yserıa mas costoso crear modulos para la administracion de dichas entidades. En casode haber algun cambio (por ejemplo en la ley de educacion) bastarıa con modificardirectamente la base de datos. Sin embargo para no correr el riesgo de dejar afueraalgun tipo de conducta o curso, se hizo un relevamiento exhaustivo junto al clientede los mismos y se los listara a continuacion:

Guarderıa

Sala de 2

Sala de 3

Sala de 4

Pre-Jardın

Jardın de Infantes

1o Grado

2o Grado

3o Grado

4o Grado

5o Grado

6o Grado

7o Grado

1er Ano

2do Ano

2Un archivo nuevo sobreescribe al anterior, puesto que actualiza su informacion pero no pierdela anterior.


3er Ano

4to Ano

5to Ano

Historia clınica

Es el modulo encargado de gestionar la informacion asociada a la salud y lascapacidades mentales del paciente. Se compone a su vez de otras tres areas.

Historia clınica: Encargado de administrar todos los tratamientos clınicos an-teriores al tratamiento actual de un paciente. Registra en que periodo ocurriodicho tratamiento y a que area clınica pertenece dicho antecedente.

Avance del caso: Encargado de registrar el avance o el retroceso en las distintasetapas del abordaje del caso. Indica ademas en que fecha se produce dichocambio.

Derivaciones: Encargado de registrar todas las derivaciones que pueda tener unpaciente por parte de un profesional que trabaja en la organizacion. Esto sucedecuando un profesional detecta mediante diferentes pruebas y entrevistas, queel paciente sufre alguna condicion o problematica que debe ser tratado porotro profesional de otra area de conocimiento. Se debe indicar al momento deefectuar la derivacion cual es el area a la que se hace la misma y la fecha.

Ofrece las operaciones de listar por paciente, alta (agregar), baja y modificacionpara cada area, ademas se decidio tabular las areas clınicas directamente en la basede datos , puesto que muy difıcilmente surja alguna nueva area de investigacion oconocimiento ligada a la psicologıa o la ciencia de la educacion.

Las diferentes areas deberan indicarse en una historia clınica y cuando se derivea algun paciente, ademas esto ultimo puede interrumpir totalmente un tratamiento,o bien el paciente podra realizar ambos tratamientos de manera simultanea (en elcentro y con el profesional al que fue derivado).

Las dos siguientes areas (tratamientos y sesiones) estan muy ligadas debido a unpedido especial por parte del cliente, el cual deseaba poder acceder a los tratamientosde una sesion particular desde el subsistema de sesiones, pero ademas deseaba listardichos tratamientos y filtrarlos por paciente, ası como acceder a los detalles de lasesion que los contiene desde el subsistema de tratamientos. Por esta razon los dosdiagramas de hipertexto asociados a cada subsistema estan llenos de vınculos quese cortan (por problemas de espacio no se pudieron poner ambos diagramas juntosen un mismo grafico), esto representa la fuerte relacion que subyace entre ambossubsistemas.


Area de Sesiones

Figura 14.9: Diagrama de hipertexto para el area Sesiones (Profesional)


Area de Tratamientos

Figura 14.10: Diagrama de hipertexto para el area Tratamientos (Profesional)


Area de sesiones

Se encuentra encargada de administrar todas las sesiones que un profesional tengacon su paciente. Registra dıa, hora y no puede durar mas de 40 minutos. Dentro deuna sesion se pueden desarrollar uno dos o hasta los tres tipos de tratamientos.

El modulo cuando es invocado por primera vez permite visualizar todas las sesio-nes prefijadas que tenga el usuario identificado en el sistema. Sin embargo se disenoal modulo (mas especıficamente al area listar sesiones) para que permita filtrar lassesiones por un rango de fechas y por paciente, pudiendo ası el profesional navegaren su historial de sesiones y hacer un seguimiento por paciente.

Al igual que el resto de subsistemas, permite listar, dar de alta, modificar y darde baja a una sesion que sea de un paciente propio. Esto es importante destacarlo,puesto que por polıticas de confidencialidad (y por ley) de la organizacion ningunprofesional ademas del tratante y la directora pueden tener acceso a ningun tipo deinformacion de un paciente.

Area de tratamientos

Es el area encargada de administrar toda la informacion referida al tratamientodel paciente. Dentro de ella se agrupan:

Pruebas: las cuales se le aplicaran a los pacientes a medida que avance elcaso. Pueden ser de diferentes tipos y evaluar diferentes areas de abordaje,ademas de que el modulo permite guardar archivos relacionados a la prueba(grabaciones, fotos, etc.).

Entrevistas: las cuales realizara un profesional a algun familiar de sus pacientes,con el objetivo de recabar informacion del entorno familiar del mismo. Elmismo permite guardar una transcripcion de la entrevista u otros archivosrelacionados a la entrevista.

Reuniones: las cuales se daran entre el profesional y algun familiar (por logeneral el encargado del mismo) y tendran el objetivo de informar a la familiadel paciente sobre los avances o problemas que esta teniendo en el tratamientoel mismo.

Informes: que el profesional redactara periodicamente y podran ser del tipoparcial o final. Permitira guardar el informe digitalizado.

Los tipos de informes fueron cargados directamente a la base de datos, puestoque resultarıa muy difıcil que se agregue un nuevo tipo, estos pueden ser:

Parciales

Finales

Por otro lado los tipos de pruebas estan cambiando constantemente, es decir laorganizacion incorpora o deja de usar ciertas pruebas a medida que transcurre eltiempo, esto se debe en gran medida a que el campo de investigacion psicopedagogicay psicologica publica periodicamente nuevos test y tecnicas para ser aplicadas. Estocauso que fuera necesaria un area que gestionara los tipos de pruebas, sin embargoesta se describira en la vista de Administrador, puesto que es el unico grupo conpermiso para acceder a dicho modulo.


Area de Cuenta

Figura 14.11: Diagrama de hipertexto para el area Cuenta (Profesional)

Surgio en respuesta a la necesidad de agrupar todas las funcionalidades relacio-nadas a la identificacion en el sistema y con las cuentas de cada usuario registrado.

Cuenta con las siguiente areas:

Perfil: el cual muestra en pantalla la informacion personal asociada al usuarioidentificado en el sistema.

Cambiar usuario: el cual consiste en un formulario que permite modificar elusuario y la contrasena del usuario identificado.

Vistas disponibles: surgio en respuesta a gestionar las dos vistas que puedetener un usuario administrador (como profesional y como administrador pro-piamente dicho), en el se muestra una tabla con las vistas disponibles y unlink para acceder a dicha vista. Es importante decir que esta opcion solo estadisponible para los usuarios que pertenezcan al grupo Administrador.

Salir: modulo cuya unica funcionalidad es salir del sistema y eliminar3 la sesionactual de usuario.

3Puesto que la herramienta generara el codigo en Java, internamente crea una variable de sesionpara cada usuario identificado actualmente en el sistema. Ası al momento de salir, se destruye dichavariable.


14.1.4. Vista de Administrador

Area de Pacientes

Figura 14.12: Diagrama de hipertexto para el area Paciente (Administrador)


Area de Historia Escolar

Figura 14.13: Diagrama de hipertexto para el area Historia Escolar (Administrador)


Area de Historia Clınica

Figura 14.14: Diagrama de hipertexto para el area Historia Clınica (Administrador)


Area de Sesiones

Figura 14.15: Diagrama de hipertexto para el area Sesiones (Administrador)


Area de Tratamientos

Figura 14.16: Diagrama de hipertexto para el area Tratamientos (Administrador)


Area de Cuenta

Figura 14.17: Diagrama de hipertexto para el area Cuenta (Administrador)

Todas las areas anteriores tienen las mismas funcionalidades que su contrapartidaen la vista de profesional, salvo que no estan limitadas a ver informacion unicamentedel usuario identificado en el sistema, sino que puede filtrar la informacion porprofesionales y a su vez elegir cualquier paciente que sea atendido por este.

En otras palabras un usuario del tipo Administrador 4 tiene permiso para acce-der a todos los pacientes de todos lo profesionales, como ası tambien a todos losantecedentes clınicos, escolares y todas las sesiones asociadas a los profesionales.

Otra diferencia es que en el area de tratamientos se puede acceder al modulo deadministracion de tipos de pruebas, con lo cual un Administrador puede agregar unnuevo tipo de prueba, listar las activas actualmente, dar de baja alguna y editar unaexistente, pudiendo modificar el nombre de la misma o el area de evaluacion queaborda.

Estas ultimas se tabularon directamente en la base de datos, puesto que sondatos que difıcilmente cambien en el corto y mediano plazo. Por supuesto, al igualque en los casos anteriores, esto requirio de un relevamiento exhaustivo con el clientepara no dejar fuera del sistema a ningun area de evaluacion, estas son las areas:

Madurativa

Proyectiva

Psicopedagogica

4Rol ejercido unicamente por la directora del centro.


Cognitiva

En el caso de la ultima area (area de cuenta) el area de Vistas disponibles sevisualiza para todos los usuarios Administradores, permitiendo ası que un profesionalpueda cumplir dos roles, el de administrar y controlar al resto de profesionales, comoası tambien gestionar sus propias sesiones y pacientes.

Esto ultimo funciona ası por pedido del cliente, ya que refleja su forma realde trabajar dentro de la organizacion, en donde la directora ademas atiende a suspacientes como cualquier otro profesional.

Es importante tambien aclarar que un usuario tendra la posibilidad de modificarsus datos de acceso a sistema, pero no asi sus datos personales, ademas de que en casose que el mismo olvidase su usuario o contrasena, debera solicitar personalmente a ladirectora de la institucion nuevos datos de acceso, pusto que es la unica autorizadaa realizar dicha tarea.

Ademas, el administrador es el unico que puede crear nuevos usuarios de cualquiertipo: secretaria, profesional o incluso otro administrador, como ası tambien modificarlos datos de acceso y el rol de cualquier usuario registrado en el sistema.

Area de Profesionales

Figura 14.18: Diagrama de hipertexto para el area Profesionales (Administrador)


Permite administrar todos los profesionales que trabajan en el centro, esto con-siste en:

Listar profesionales: lo cual lista todos los profesionales que se encuentranactualmente trabajando en la organizacion y estan activos.

Agregar profesional: que consiste en un formulario que recoge todos los datospersonales, de formacion y de contacto del nuevo profesional, luego se debeseleccionar a que grupo de usuarios pertenecera dicho profesional y por ultimoregistra esto en la base de datos.

Editar profesional: el cual es un formulario que se carga con la informacionactual del profesional y permite editar la misma. Ası se podran guardar loscambios realizados o bien salir sin guardar.

Dar de baja profesional: lo cual inhabilita el usuario seleccionado ocasionandoque no pueda iniciar sesion nunca mas en el sistema.

Capıtulo 15

Implementacion

La implementacion es asistida por Webratio, particularmente se utilizo WebRa-tio Personal, version 6.1.1 la cual permite generar de manera local la aplicacion,haciendo que el desarrollo sea mucho mas rapido1 y controlable.

Figura 15.1: Version de Webratio utilizada en la implementacion

Para generar en Webratio basta con hacer click con el boton derecho sobre elproyecto, luego ir a Generate y luego a Generate Selection. Esto hara que se genereautomaticamente la aplicacion de manera local, es decir en nuestra terminal.

Ahora para poder abrir el proyecto sera necesario inicializar el servidor (que vieneincuido en Webratio) Apache Tomcat haciendo click en el siguiente icono:

Figura 15.2: Icono para inicializar el servidor Apache Tomcat

1Las nuevas versiones generan en la nube, pero esta casi siempre se encuentra saturada, haciendoque la implementacion se torne lenta.

106

IMPLEMENTACION 107

Ahora se abrira un navegador web y en la barra de direcciones se debera ingresarla direccionhttp://localhost:8080/nombredelproyecto, esto nos llevara a la Home de nues-tra aplicacion.

A continuacion se mostrara la pantalla de Login generada con la herramienta ylas vistas de todos los tipos de usuarios que existen.

Figura 15.3: Pantalla de Login generada con la aplicacion

Figura 15.4: Vista de Administrador generada con la herramienta

IMPLEMENTACION 108

Figura 15.5: Vista de Profesional generada con la herramienta

Figura 15.6: Vista de Secretaria generada con la herramienta

Capıtulo 16

Reportes

Para la finalizacion del proyecto se dejaron los reportes, de los cuales la me-todologıa no ofrece un soporte nativo, ni forma alguna de especificacion. Por otrolado la herramienta WebRatio si que ofrece una alternativa para disenar reportes:“WebRatio Reports”, sin embargo esta ultima es paga y va en contra del espıritudel proyecto, el cual es utilizar herramientas gratuitas.

Desde la pagina de WebRatio se puede seguir un tutorial[21] para lograr disenarlos reportes usando el plugin antes mencionado, en donde se aclara que se debeinstalar el software (tambien gratuito) iReports para modificar la interfaz graficade los mismos. Es decir desde Webratio se modelaran los datos y con iReports sedisenara estaticamente el reporte.

Por todo lo anterior descrito se decidio disenar los reportes con una herramientaexterna que utilice las estructuras de datos generadas por WebRatio, dicha herra-mienta sera JasperSoft Studio, la cual es la version mas reciente del software iReportsque utiliza Webratio Reports1.

16.1. El disenador de reportes

Jaspersoft Studio [22] es una biblioteca de creacion de informes que tiene lahabilidad de entregar contenido enriquecido al monitor, a la impresora o a ficherosPDF, HTML, XLS, CSV y XML.

Esta escrito completamente en Java y puede ser usado en gran variedad de aplica-ciones de Java, incluyendo J2EE o aplicaciones web, para generar contenido dinami-co.

Su proposito principal es ayudar a crear documentos de tipo paginas, preparadospara imprimir en una forma simple y flexible. Ademas se encuentra bajo licencialibre GNU, por lo que es software libre.

16.2. El procedimiento

Se procedera entonces a realizar el reporte dentro de JasperSoft, lo cual es muyintuitivo y no tiene mayores complicaciones al tratarse de una herramienta mas

1Ambas versiones utilizan la biblioteca JasperReports, escrita en Java

109

REPORTES 110

bien grafica. Es importante mencionar que antes de empezar a trabajar, se debeconfigurar el JDBC con los datos de la base de datos a la que debera conectarse elreporte2.

Una vez realizado lo anterior se puede proceder a disenar el reporte.

Figura 16.1: Entorno de diseno JasperSoft Studio

Utilizando la conexion a la base de datos se pueden utilizar todos los atributosde la misma, incorporar parametros externos e incluso se permite realizar consultasen SQL permitiendo obtener practicamente cualquier tipo de informacion a partirde la B.D.

Adicionalmente la herramienta nos permite incorporar una gran multitud deadicionales a nuestros reportes, por ejemplo, a pedido del cliente se necesitabancrear tarjetas de identificacion para los profesionales. Esto se pudo hacer facilmentegracias a un plugin QR que se encuentra incluido, facilitando mucho el desarrollo yahorrando tiempo de produccion.

Una vez disenados y compilados los reportes podemos exportarlos a diferentesformatos, en nuestro caso se opto por el formato .jrxml 3. Ademas se pueden obtenerdirectamente desde la herramienta archivos .pdf para previsualizar como se vera elreporte una vez incluido en el proyecto.

Esto ultimo es precisamente lo que nos interesa a fin de obtener una aprobacionpor parte del cliente sobre los reportes generados.

16.3. Listado de reportes

Si bien por parte del cliente no existe actualmente mucho interes en obtenerreportes, debido a que el sistema se encuentra en su fase de puesta en producciony no cuenta con demasiada informacion como para producir reportes que sean muyrelevantes, se relevaron y disenaron los siguientes reportes:

2Esto se denomina configurar el ’Data Source’ dentro de la herramientas3Esto debido a que la aplicacion final se desarrollara en Java.

REPORTES 111

Ranking de Test aplicados entre dos fechas : el cual enumera los tipos de testque fueron aplicados con mayor frecuencia.

Listado de Sesiones entre dos fechas : el cual reporta todas las sesiones que seefectuaron en un rango de fechas.

Listado de Pacientes : el cual lista todos los pacientes que actualmente seencuentran asistiendo a la organizacion.

Identificacion de profesionales : el cual es un reporte especial que sirve deidentificacion para los profesionales.

Reporte completo de sesion : el cual aglomera todos los eventos que puedesuceder dentro de una sesion especifica.

CENTRO DE ESPECIALIZACIÓN EN ATENCIÓN PSICOPEDAGÓGICA

Laprida Nº 849 - 4400 - Salta Capital

Tel. : 423-3628 / 434-0702

Republica Argentina

Ranking de Test aplicados entre el 5/3/2015 y el 24/3/2016

Test aplicado Área clínica Cantidad

Dibujo Libre 1Madurativa

Gestáltico Viso-Motor 0Madurativa

Análisis del cuaderno 0Proyectiva

D.F.H. 0Madurativa

WISC IV 0Cognitiva

H.T.P. 0Proyectiva

Hora de Juego 0Psicopedagogica

Dibujo de la Familia Kinetica 0Proyectiva

Dip(Le) 0Psicopedagogica

Dibujo de la Familia 0Proyectiva

Observación de la clase 0Proyectiva

14/03/2016 1



Tel. : 423-3628 / 434-0702

Republica Argentina

Listado de Sesiones entre el 20/03/15 y el 10/03/16

Profesional tratante Apellido/s Nombre/s Fecha Horario

Valdivieso Portales, Maria Laura Facundo Alejandro 2015-11-04 22:00:00Farfán






Valdivieso Portales, Maria Laura Francisco Ezequiel 2015-11-04 22:20:23Salva

14/03/2016 1



Tel. : 423-3628 / 434-0702

Republica Argentina

Listado de Pacientes

Profesional Apellido/s Nombre/s Edad Estado del caso

Valdivieso Portales, Maria Laura Facundo Alejandro 8 años y 4 meses Presentación del casoFarfán

Valdivieso Portales, Maria Laura Francisco Ezequiel 10 años y 5 meses Presentación del casoSalva

Valdivieso Portales, Maria Laura Pichon 20 años y 7 meses Presentación del casoDe la Vida

Valdivieso Portales, Maria Laura Juan Carlos 20 años y 7 meses Presentación del casoSalva

20/01/2016 1



Tel. : 423-3628 / 434-0702

Republica Argentina

Identificación de profesionales

Apellido/s :

Nombre/s :

Título :

Nacimiento :

Lic.

Valdivieso Portales

Maria Laura

10/10/1990

Documento :

Nº de Matricula :

37419278

4578

Laprida Nº 849 - 4400 - Salta CapitalTel. : 423-3628 / 434-0702

Republica Argentina

14/03/2016 1



Tel. : 423-3628 / 434-0702

Republica Argentina

Reporte completo de sesión

Paciente :Farfán, Facundo Alejandro

4-11-2015

Detalle de la sesión

Fecha :

Hora :22:00

Tratamiento :Aplicación de bateria de Test Wisc IV

Observaciones :Se observó una buena predisposicion del paciente en la resolucion de los problemas

Detalle del test o técnica aplicado

Tipo de test :Dibujo Libre

Observaciones :Sin observaciones

Detalle de la reunión

Familiar :Farfán, Fernando

Sin observacionesObservaciones :

Detalle de la entrevista

Familiar :Farfán, Fernando

Observaciones :Sin observaciones

14/03/2016 1

Glosario

A

ABM: Siglas utilizadas en la jerga informatica y de desarrollo de aplicaciones, sig-nifica alta, baja y modificacion. Se utilizan para denotar las tres operacionesbasicas que se pueden efectuar sobre una entidad en un sistema. Estas son:efectuar el alta, es decir agregar un nuevo registro a esa entidad, modificar unregistro existente y dar de baja un registro.

Abordaje psicopedagogico: Actividad que realiza el profesional con el pacientepara lograr conocer cuales son sus fortalezas y debilidades dentro del apren-dizaje, a traves de la utilizacion de test y tecnicas para lograr un optimodesempeno academico del mismo.

C

C.E.A.P.: Centro de Especializacion en Atencion Psicopedagogica, constituye elsistema objeto de estudio.

D

D.B.M.S.: DataBase Management System, que traducido significa sistema de ges-tion de bases de datos, el cual es un conjunto de programas que permiten elalmacenamiento, modificacion y extraccion de la informacion en una base dedatos, ademas de proporcionar herramientas para anadir, borrar, modificar yanalizar los datos.

Derivacion: Es el acto de remitir a un paciente, mediante un parte interconsulta,a otro profesional, para ofrecerle una atencion complementaria tanto para sudiagnostico, su tratamiento como su rehabilitacion.

Diagrama E-R: Un diagrama o modelo entidad-relacion (a veces denominado porsus siglas en ingles, E-R ”Entity relationship”, o del espanol DER ”Diagramade Entidad Relacion”) es una herramienta para el modelado de datos quepermite representar las entidades relevantes de un sistema de informacion asıcomo sus interrelaciones y propiedades.

E

117

GLOSARIO 118

Enlace: Elemento de un documento electronico que hace referencia a otro recur-so, por ejemplo, otro documento o un punto especıfico del mismo o de otrodocumento.

H

Hipertexto: Herramienta de software con estructura secuencial que permite crear,agregar, enlazar y compartir informacion de diversas fuentes por medio deenlaces asociativos.

Historia Clınica: Documento medico-legal que surge del contacto entre el profe-sional de la salud y el paciente, donde se recoge informacion necesaria para lacorrecta atencion de los pacientes.

J

JSP: Java Servlet Pages ’ (JSP) es una tecnologıa que ayuda a los desarrolladoresde software a crear paginas web dinamicas basadas en HTML, XML, entreotros tipos de documentos. JSP es similar a PHP, pero usa el lenguaje deprogramacion Java.

O

O.Q.L.: Object Query Language (OQL) es un lenguaje de consulta estandar parabases de datos orientadas a objetos modelado a partir de SQL.

P

Problematica: Conjunto de problemas que atanen a una persona o cosa. En parti-cular nos referimos a los problemas escolares, familiares y mentales que puedatener un paciente.

Paginas: Contenedores de unidades de contenido que agrupan informacion.

S

Servlet: Clase en el lenguaje de programacion Java, utilizada para ampliar las ca-pacidades de un servidor. Aunque los servlets pueden responder a cualquiertipo de solicitudes, estos son utilizados comunmente para extender las aplica-ciones alojadas por servidores web, de tal manera que pueden ser vistos comoapplets de Java que se ejecutan en servidores en vez de navegadores web.

Sistema modular: Sistema que se encuentra dividido en modulos o subsistemascon el fin de hacerlo mas manejable y entendible.

SQL: El lenguaje de consulta estructurado o SQL (por sus siglas en ingles Struc-tured Query Language) es un lenguaje declarativo de acceso a bases de datosrelacionales que permite especificar diversos tipos de operaciones en ellas.

GLOSARIO 119

T

Test: Instrumento experimental que tiene por objeto medir o evaluar una carac-terıstica psicologica-cognitiva especıfica, o los rasgos generales en cuanto a sudesempeno en el proceso de ensenanza y aprendizaje.

U

Unidad de Contenido: Elementos atomicos para publicacion de informacion.

Bibliografıa

[1] Definicion de psicopedagogıa. URL: http://definicion.de/psicopedagogia.Accedido el 05/06/2015.

[2] Introduccion a la psicologıa del aprendizaje escolar. BAQUERO, R. y LUQUE,M.L. Ano 2001. Universidad Nacional de Quilmes. ISBN 9789879173589.

[3] Aprender para ser. MARINA Muller. Editorial Bonum. Ano 2001. ISBN9505073569.

[4] Ingenierıa del software: un enfoque practico. PRESSMAN Roger S.. EditorialMac Graw-Hill. Ano 1997. ISBN 9780073375977.

[5] Web Modeling Language (WebML): a modeling language for designing Web sites.STEFANO Ceri, PIERO Fraternali, ALDO Bongio. Dipartimento di Elettronicae Informazione, Politecnico di Milano, Piazza Leonardo da Vinci. Ano 2000.

[6] MySQL - Pagina oficial. URL: http://www.mysql.com/why-mysql. Accedidoel 05/06/2015.

[7] MySQL - MySQL Workbench. URL: http://dev.mysql.com/doc/index-gui.html. Accedido el 05/06/2015.

[8] Apache Tomcat - Wiki oficial. URL: http://wiki.apache.org/tomcat/FrontPage. Accedido el 05/06/2015.

[9] Web Engineering: Modelling and Implementing Web Applications. ROSSI Gus-tavo, PASTOR Oscar, SCHWABE Daniel,OLSINA Luis. Editorial Springer. Ano2008. ISBN 9781846289224.

[10] Designing Data-Intensive Web Applications - The Morgan Kaufmann Series inData Management Systems. CERI Stefano, PIERO Fraternali, BONGIO Aldo,BRAMBILLA Marco, COMAI Sara, MATERA Maristella. Editorial MorganKaufmann. Ano 2003. ISBN 9780080503936.

[11] WebRatio - Pagina oficial. URL: http://www.webml.org/webml. Accedido el10/06/2015.

[12] Honorarios Indicativos – Profesionales Informaticos. Resolucion Nro. 139/09del Co.P.A.I.P.A.. Ano 2009.

[13] Ley Nro. 26.529 - Normativa sobre el manejo de Historia Clınica. Ano 2009.

120

BIBLIOGRAFIA 121

[14] Nomenclador de practicas psicopedagogicas 2015. Colegio de Profesionales Psi-copedagogos de Salta. Ano 2015.

[15] Ingenierıa del software. SOMMERVILLE, I. and GALIPIENSO, M.I.A. Edito-rial Pearson Educacion. Ano 2015. ISBN 9788478290741.

[16] Modelos y tecnicas para la especificacion y el analisis de la navegacion ensistemas software. ESCALONA CUARESMA Marıa Jose. Tesis Doctoral. Ano2004. URL: http://www.lsi.us.es/docs/doctorado/tesis/tesis.pdf. Ac-cedido el 01/10/2015.

[17] Una Aplicacion basada en Eclipse para la Personalizacion de Aplicaciones WebDirigida por Modelos. GARRIGOS Irene, GLORIO Octavio y HERNANDEZPaul. Universidad de Alicante, Espana. Ano 2009.

[18] Integracion de Calidad y Experiencia en el Desarrollo de Interfaces de Usuariodirigido por Modelos. MONTERO Simarro Francisco. Tesis Doctoral. Univer-sidad de Castilla - Departamento de Sistemas Informaticos. Ano 2005. URL:http://www.usixml.org/servlet/Repository/montero-phd2005.pdf. Acce-dido el 01/10/2015.

[19] Requerimientos No funcionales para aplicaciones Web. ROJO, Silvana del Valley OLIVEROS, Alejandro. 13th Argentine Symposium on Software Engineering.Ano 2012.

[20] Especificacion de Requisitos segun el estandar de IEEE 830. IEEE STD 830.Ano 1998.

[21] WebRatio - Modeling Reports. URL: http://my.webratio.com/learn/learningobject/modeling-reports. Accedido el 25/04/2016.

[22] JasperSoft Studio -Pagina Oficial. URL: http://community.jaspersoft.com/project/jaspersoft-studio. Accedido el 25/04/2016.

Documents

Aplicaci on pr actica de la Metodolog a WebML de Desarrollo de … Juan Carlos .pdf · 2016-05-10 · \Aplicaci on pr actica de la Metodolog a WebML de Desarrollo de Software a la