Documento de Arquitectura de Software SAD

Transcripción

1 asaaaaa Documento de Arquitectura de Software SAD V_1.0 Director: Miguel Torres M.Sc. Cliente y Consultor: Oscar Mauricio Aguilar Neuropsicólogo Pontificia Universidad Javeriana Facultad De Ingeniería 07/07/2009 Nicolás Aristizábal Mejía Ricardo López Quiñones Gustavo Salazar Garzón Este documento es el resultado de la definición de arquitectura de software y diseño para el Sistema SANTi que es desarrollado como parte del Trabajo de Grado de Ingeniería de Sistemas de los estudiantes autores del mismo, en conjunto con el área de Neuropsicología de la misma universidad. Aquí están contenidos los modelos y diagramas que sirven como base para el desarrollo del sistema y que están basados en los requerimientos previamente definidos y especificados.

2 Historial de Cambios Autor Fecha Sección Modificada Gustavo Salazar Garzón Ricardo López Quiñones Nicolás Aristizábal Mejía Nicolás Aristizábal Mejía Nicolás Aristizábal Mejía Nicolás Aristizábal Mejía Gustavo Salazar Garzón Gustavo Salazar Garzón Nicolás Aristizábal Mejía Nicolás Aristizábal Mejía Gustavo Salazar Garzón Gustavo Salazar Garzón Gustavo Salazar Garzón Ricardo López Quiñones Descripción del Cambio 07/07/2009 Todas Creación de la Plantilla con sus respectivas secciones y descripciones 2/07/2009 Propósito y Alcance Creación y redacción de las secciones descritas anteriormente 06/09/2009 Sección 1 Corrección de toda la sección 07/09/2009 Sección 2 y 3 Se desarrollaron las secciones. 11/09/2009 Sección 10 y 11 Creación y adición 11/09/2009 Sección 1.2 y 1.3 Corrección 29/09/2009 Sección 3 Se actualizo y se arreglo la sección. 01/10/2009 Todo el Documento Se Actualizo el documento a la versión /10/2009 Sección Creación 2/10/2009 Sección 3.1.1/2/3 Actualización de los requerimientos con respecto al archivo RequerimientosVSStakeholders.xls 01/12/2009 Sección 2 Actualización y Validación 01/12/2009 Sección 4 Actualización 02/12/2009 Secciones 5,6,7,,9, Actualización y Revisión Final 10 y 11 06/12/2009 Todo el documento Revisión de calidad 2

3 Tabla de Contenido 1. Introducción Propósito Alcance Definiciones, acrónimos y abreviaturas Referencias Descripción de la Metodología usada Referencias Visión general del documento Representación Arquitectónica Selección de Arquitecturas según los Atributos de Calidad Representación arquitectónica Clientes pesados Presentación Modelo Vista Controlador [2] Seguridad Lógica del Negocio (Core) Servidor Capas Representación arquitectónica Objetivos y Restricciones Arquitectónicas Priorización de requerimientos Resumen de ponderación por Stakeholder Resumen de requerimientos Requerimientos de prioridad mayor o igual a Metas y restricciones arquitectónicas según requerimientos Vista de Casos de Uso Vista Lógica Visión General Diseño Arquitectónico de Paquetes Importantes Paquete Presentación Lógica del Negocio Conexión Datos

4 6. Vista de Procesos Vista de Despliegue Vista de Implementación Visión General Capas Presentación Seguridad Lógica de Negocio (Core) Datos Vista de Datos Tamaño y Desempeño Concurrencia de usuarios Calidad Seguridad Despliegue de la información Validación de la información del usuario Usabilidad Presentación de estímulos visuales y auditivos Ayudas tipo ToolTipText

5 1. Introducción Esta sección pretende dar una visión general de todo Documento de Arquitectura de Software, llamado de aquí en adelante SAD. En esta sección se explica el propósito, alcance, definiciones, referencias y visión general del documento 1.1. Propósito El propósito de este documento es especificar claramente la arquitectura de software a ser usada para el desarrollo del sistema SANTi que es el producto del Trabajo de Grado de los estudiantes autores de este documento. Con este documento se pretenden plasmar en términos arquitectónicos y de diseño todos los requerimientos definidos en el Documento de Especificación de Requerimientos de Software (SRS). Este documento va dirigido a los stakeholders implicados en el proceso de desarrollo del software. Estos son gerente de proyecto, analista de requerimientos, arquitecto de software, director de desarrollo, desarrolladores y testers. Este documento es la principal fuente de información para empezar con el desarrollo del sistema y la integración de los componentes adquiridos. Este documento es parte de los entregables del Trabajo de Grado en Ingeniería de Sistemas realizado en el 2009 II por los estudiantes autores del mismo, bajo la dirección del ingeniero Miguel Eduardo Torres Moreno Alcance Este proyecto se inscribe dentro del marco del Trabajo de Grado de los estudiantes de Ingeniería de Sistemas autores de este documento en la Pontificia Universidad Javeriana bajo la dirección del ingeniero Miguel Eduardo Torres Moreno. Dicho proyecto es la fase de continuación del proceso iniciado en el Proyecto Especial en el primer semestre del De igual manera, este trabajo es realizado en conjunto con la Facultad de Psicología de la Pontificia Universidad Javeriana, específicamente con el área de Neuropsicología, bajo la asesoría del neuropsicólogo Oscar Mauricio Aguilar. Con este documento se pretende definir la arquitectura de software que será utilizada para el desarrollo del sistema SANTi. Como se verá posteriormente en este documento (ver sección 2 Representación Arquitectónica) esta representación arquitectónica es especificada por las diferentes vistas del sistema (Casos de Uso, Lógica, Procesos, Despliegue, Implementación y Datos). También son detallados y direccionados otros aspectos importantes con respecto a los requerimientos no funcionales como lo son el tamaño, desempeño y la calidad de la arquitectura del sistema. 5

6 En este documento se definen los módulos a desarrollar y la manera en que éstos se relacionan con los componentes adquiridos. El sistema contará con las funcionalidades definidas en el SRS y mapeadas al software en este documento Definiciones, acrónimos y abreviaturas Las palabras desconocidas o ambiguas que son utilizadas por primera vez en este documento, serán definidas en el pie de página de la página correspondiente. Sin embargo, para no hacer este proceso repetitivo, existe un documento al cual usted se puede remitir y encontrar allí términos importantes de este proyecto transversalmente. Remítase al documento Definiciones, Acrónimos y Abreviaturas_V Referencias Descripción de la Metodología usada El uso de referencias se realiza de manera transversal a todo el Proyecto Especial y al Trabajo de Grado, utilizando los formatos encontrados en el documento Plantilla Referencias.dot que se basa en el formato IEEE Referencias [1] G. Reese, Database Programming with JDBC and Java, Second Edition, O Reilly, Noviembre de 2000, [2] C. Reynoso, N. Kiccillof, Estilos y Patrones en la Estrategia de Arquitectura de Microsoft, Universidad de Buenos Aires, Marzo de 2004, [3] S. Burbeck. Application programming in Smalltalk 0: How to use Model View Controller (MVC).University of Illinois in Urbana Champaign, Smalltalk Archive, docs/mvc.html. [4] Enterprise Solution Patterns: Model View Controller. Microsoft Patterns & Practices, [5] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern Oriented Software Architecture. A System Of Patterns, JOHN WILEY & SONS. Inglaterra, Octubre de 1996, [6] D. Garlan, M. Shaw. An introduction to software architecture. CMU Software Engineering Institute Technical Report, CMU/SEI 94 TR 21, ESC TR 94 21, [7] Object Management Group, Inc. UML Resource Page [página de Internet] [14/09/09]. Disponible en: [] KRUCHTEN, P, Architectural Blueprints The 4+1 View Model of Software Architecture, IEEE Software 12 (6), November 1995, p [9] B. Bruegge, A.H. Dutoit. Object Oriented Software Engineering, Conquering Complex and Changing Systems, Prentice Hall, 1999, p. 14 [10] ISO, International Organization for Standardization, "ISO :2001, Software engineering Product Quality, Part 1: Quality model",

7 [11] Frank Buschmann Regine Meunier Hans Rohnert Peter Sommerland Michael Stal, Pattern Oriented Software Architecture, Volumen 1, AG Germany, WILEY, 1996, p [12] JClic [Homepage en Internet] Cataluña España: XTEC [01/12/2009]. Disponible en: [13] Designing a Three Tier Architecure Pattern Language Design Fest, EuroPLoP 2001 Kloster Irsee/Germany, July 4 Proceedings: op2001/focusgroups_designfests/three tier design fest.htm [14] Pattern Oriented Software Architecture On Patterns and Pattern Languages Frank Buschmann, Siemens, Munich, Germany Kevlin Henney, Curbralan, Bristol, UK Douglas C. Schmidt, Vanderbilt University, Tennessee, USA Volume 5 [15] Documento de Descripción Arquitectónica de Estudiantes de Arquitectura de Software de la Pontificia Universidad Javeriana del semestre [16] IEEE Recommended Practice for Software Requirements Specifications, [17] IEEE Recommended Practice for Software Design Descriptions, [1] Bustacara Medina, Cesar Julio [homepage de Internet] Plantilla Documento SAD [01/05/2009]. Disponible en: [19] Camargo, E; Cardeso, F; Nuñez M. Guia de Estudio[Articulo en internet]venezuela; [4/12/2009]. Disponible en: /Guia%20Arquitectura%20v.2.pdf 1.5. Visión general del documento Este documento está organizado de forma en la cual el lector conforme lo va leyendo, puede encontrar la descripción de la arquitectura del sistema con ayuda de diferentes aspectos importantes, estos están distribuidos de la siguiente manera. La sección 2. Representación Arquitectónica, describe que arquitectura de software será utilizada para el desarrollo del sistema y como será representada. La sección 3. Objetivos y Restricciones Arquitectónicas, muestra como los requerimientos no funcionales impactan en la arquitectura de software seleccionada. La sección 4. Vista de Casos de Uso, contiene los casos de uso del sistema. La sección 5. Vista Lógica, tiene una descripción de las partes más importantes de la arquitectura. La sección 6. Vista de Procesos, muestra la descripción del sistema en los procesos que ejecuta. La sección 7. Vista de Despliegue, describe la manera como se va a ejecutar el sistema. La sección. Vista de Implementación, describe el modelo de implementación del sistema. La sección 9. Vista de Datos, muestra la manera cómo van a ser almacenados los datos del sistema. La sección 10. Tamaño y Desempeño, describe las principales características del tamaño y del desempeño del sistema. La sección 11. Calidad, muestra los atributos de calidad que son tenidos en cuenta. 2. Representación Arquitectónica En esta sección se describe el patrón arquitectónico principal escogido para el diseño de la arquitectura para el Sistema SANTi. 7

8 2.1. Selección de Arquitecturas según los Atributos de Calidad El método de comparación de arquitecturas que se utilizo fue el Método de comparación de arquitecturas basada en el modelo ISO/IEC 9126 adaptado para arquitecturas de software [19], el cual proporciona seis actividades para poder seleccionar la mejor arquitectura según los atributos de calidad. Estas seis actividades se muestran en la Tabla 1 Actividades del modelo ISO/IEC Actividad Descripción Análisis Se realiza un análisis de los requerimientos funcionales y no funcionales, para poder establecer metas de calidad. Definición de Métricas Utilizando el modelo de calidad ISO/IEC 9126 se definen las métricas de calidad utilizando los atributos de calidad. Selección de Arquitecturas Utilizando las métricas de calidad definidas se realiza una Candidatas selección de arquitecturas candidatas. Tabla Comparativa Se construye una tabla comparativa con las arquitecturas seleccionadas en la actividad anterior. Establecer Prioridades Se establecen prioridades para las sub características de calidad tomando en cuenta los requerimientos de calidad del sistema. Selección de la Arquitectura Se analizan los resultados que se obtuvieron en la tabla comparativa y se selecciona la mejor arquitectura. Tabla 1 Actividades del modelo ISO/IEC 9126 Los criterios utilizados para realizar la comparación entre las arquitecturas de software, fueron los atributos de calidad, basándonos en la norma ISO 9126, en donde se definen 6 categorías principales, y cada una de estas tiene sus principales sub categorías, estas categorías son descritas a continuación en la Tabla 2 Atributos de Calidad ISO Categoría Funcionalidad Fiabilidad Eficiencia Mantenibilidad Portabilidad Usabilidad Sub Categoría Idoneidad Precisión Seguridad Interoperabilidad Madurez Recuperabilidad Tolerancia a Fallos Comportamiento en el tiempo Comportamiento de los recursos Capacidad de Análisis Facilidad de Cambio Estabilidad Facilidad de Pruebas Adaptabilidad Capacidad de Instalación Co existencia Capacidad de Cambio Comprensibilidad Capacidad de Aprendizaje

9 Operabilidad Atractivo Tabla 2 Atributos de Calidad ISO 9126 [10] Los criterios de calidad seleccionados para escoger la arquitectura de software fueron usabilidad, mantenibilidad y funcionalidad, según su el orden de importancia para el sistema. En la tabla de comparación de arquitecturas (ver documentos anexo ComparacionArquitecturas_V_1.0.xlsx ), este proceso se realizo tomando los criterios de calidad seleccionados anteriormente frente a las arquitecturas candidata, se establecieron prioridades en los atributos de calidad (importancia del atributo de calidad) para luego seleccionar la arquitectura del sistema SANTi. La primera parte de la priorización fue conocer la prioridad de los atributos de calidad, esto se realizo mirando que arquitecturas cumplían cada atributo de calidad, se contabiliza este número y luego se realiza el promedio según la cantidad de arquitecturas candidatas. Cuando ya se tienen priorizados los atributos de calidad, se utiliza el peso de cada uno para determinar la mejor arquitectura. Luego de realizar el proceso de comparación de arquitecturas dos arquitecturas quedaron empatadas con la puntuación más alta. Estas arquitecturas son la de cliente servidor y capas. Por este motivo se decidió unir las capacidades de cada una de estas arquitecturas en una sola. Por consiguiente la arquitectura seleccionada es la de Cliente Servidor en Capas, en donde se aprovechan las ventajas que ofrece la arquitectura cliente servidor para el manejo de datos concurrentes para varios usuarios, y las ventajas que ofrece la arquitectura en capas para ser optimizada, refinada y reutilización[2] Representación arquitectónica La arquitectura escogida para el sistema SANTi es la de Cliente Servidor en Capas, la cual se describe a continuación[1][2]. La arquitectura Cliente Servidor en Capas es comúnmente una arquitectura que se basa en el concepto de procesamiento en dos o más máquinas. Una aplicación es Cliente Servidor si el almacenamiento de los datos se encuentra apartado de la presentación. En este caso, el servidor es un motor de base de datos que almacena datos y el cliente es el proceso que recupera o crea dichos datos. La idea detrás de esta arquitectura es que el servidor pueda permitir el acceso de múltiples usuarios a la misma fuente de datos. La arquitectura Cliente Servidor en Capas del sistema SANTi, está compuesta por cuatro capas. En donde cada cliente tiene tres de estas cuatro capas y el servidor una capa. Por esta razón los clientes son clientes pesados Clientes pesados La filosofía detrás de la arquitectura cliente servidor supone que cada máquina realiza el procesamiento relevante para sus tareas. Los clientes son diseñados para proveer a los 9

10 usuarios una interfaz gráfica lo que supone una presentación de los datos. Los servidores son diseñados para manejar la complejidad de los datos y las comunicaciones por lo cual sirven como almacenes de datos. Conforme los sistemas van creciendo, se van encontrando diferentes necesidades de procesamiento que no tiene un lugar claro en el modelo clienteservidor. Por esto, los clientes ahora son más potentes, siendo capaces de soportar interfaces gráficas más robustas y procesamiento de información y los servidores cuentan con más capacidad de almacenamiento y procesamiento a la vez. Para el caso específico del sistema SANTi, los clientes serán clientes pesados que realizarán parte de las tareas de procesamiento y, naturalmente, se encargarán de la presentación de datos. Los clientes estarán definidos por tres capas: Presentación Seguridad Lógica del Negocio (Core) Presentación La capa de presentación está representada por medio del patrón de diseño Modelo Vista Controlador (ver sección Modelo Vista Controlador [2]). El uso de este patrón de diseño suma dos ventajas principales al sistema. La posibilidad de varias vistas usando el mismo modelo, esto facilita el diseño de diferentes interfaces de usuario dependiendo del usuario que utilice el sistema. Extensibilidad por medio de look and feel, esta ventaja permite aplicar diferentes tipos de look and feel a cada vista sin necesidad de afectar o modificar la funcionalidad del modelo. El modelo es el encargado de comunicarse con las otras capas del sistema Modelo Vista Controlador [2] El patrón de diseño conocido como MVC por sus siglas en ingles (Model View Controller), el cual divide el sistema en tres áreas: procesamiento, salida y entrada. Estas áreas se representan en tres clases respectivamente [3]: Modelo. El modelo se encarga de administrar el comportamiento y los datos del sistema, respondiendo a requerimientos de información sobre su estado y respondiendo a instrucciones de cambio de estado (habitualmente desde el controlador). Vista. Se encarga de manejar la visualización de la información. Controlador. Interpreta las acciones de los dispositivos de entrada, informando al modelo y/o a la vista para que se actualicen. 10

11 Ilustración 1 Modelo Vista Controlador tomado de [2] Tanto la vista como el controlador dependen del modelo, el cual no depende de las otras clases. Esta separación permite construir y probar el modelo independientemente de la representación visual, permitiendo cambios en el controlador y la vista sin afectar la funcionalidad del sistema [11]. Entre las ventajas del estilo señaladas en la documentación de Patterns & Practices de Microsoft están las siguientes: Soporte de vistas múltiples. Dado que la vista se halla separada del modelo y no hay dependencia directa del modelo con respecto a la vista, la interfaz de usuario puede mostrar múltiples vistas de los mismos datos simultáneamente. Por ejemplo, múltiples páginas de una aplicación de Web pueden utilizar el mismo modelo de objetos, mostrado de maneras diferentes. Adaptación al cambio. Los requerimientos de interfaz de usuario tienden a cambiar con mayor rapidez que las reglas de negocios. Los usuarios pueden preferir distintas opciones de representación, o requerir soporte para nuevos dispositivos como teléfonos celulares o PDAs. Dado que el modelo no depende de las vistas, agregar nuevas opciones de presentación generalmente no afecta al modelo Seguridad La capa de seguridad se encarga de validar y autenticar a cada usuario que desee utilizar el sistema, garantizando que solamente los usuarios registrados puedan ingresar al sistema y hacer uso del mismo Lógica del Negocio (Core) La capa de Lógica de Negocio, es la encargada de realizar el procesamiento, administrando el comportamiento y los datos del sistema. Esta capa se encarga del funcionamiento del sistema Servidor El servidor del sistema estará definido por la arquitectura por capas que se especifica en la sección Capas de este documento. El servidor tendrá la lógica del negocio y se encargará del almacenamiento de los datos Capas El patrón arquitectónico por capas ayuda a estructurar las aplicaciones que pueden ser descompuestas en grupos de tareas en la cual cada grupo de tareas es un nivel particular de abstracción[5]. 11

12 En [6] Garlan y Shaw definen el estilo en capas como una organización jerárquica tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior. Este patrón cuenta con diferentes capan que envuelven funcionalidades específicas del sistema y tienen unas interfaces de comunicación definidas mediante protocolos de comunicación. Originalmente este patrón supone que las comunicaciones se realizan únicamente entre capas adyacentes y que las comunicaciones entre elementos de una capa solo pueden ser entre elementos de la misma. Si esto no se cumple, el estilo deja de ser puro y se pierden algunas de sus características[2] Los sistemas de información usados en los sistemas de dominio de negocio, usualmente utilizan arquitecturas de dos capas. La capa inferior es la base de datos que contiene los datos de la compañía. En esta arquitectura muchas aplicaciones trabajan de manera concurrente encima de esta capa de datos, para cumplir diferentes tareas. Por el acoplamiento tan alto que esto genera entre la interface de usuario y los datos, se introduce una tercera capa en medio de estas, llamada la capa de dominio, que modela la estructura conceptual del domino del problema. De igual manera es necesario subdividir esta capa, para final mente tener una arquitectura de cuatro capas[5]: Presentación Lógica de la aplicación Dominio Datos Entre los beneficios de esta arquitectura se encuentran los siguientes[5]: Reutilización de capas: Se puede dar en la medida en que cada capa tenga un nivel de abstracción bien definido y unas interfaces documentadas y bien definidas igualmente. Si esta caja negra está desarrollada correctamente, puede reducir dramáticamente el esfuerzo en desarrollo y la cantidad de defectos Soporte de estandarización: Unos niveles de abstracción claramente definidos y comúnmente aceptados, permiten el desarrollo de tareas e interfaces estandarizadas Posibilidad de intercambio: Se pueden intercambiar diferentes implementaciones de la misma capa que sean semánticamente equivalentes, sin realizar gran esfuerzo Representación arquitectónica Este documento presenta la arquitectura de tres niveles como una serie de vistas: vista de casos de uso, vista lógica, vista de procesos, vista de despliegue, vista de implementación y vista de datos. Estas vistas se basan en el Lenguaje Unificado de Modelado (UML)[7]. Para este fin se utiliza el modelado de vistas 4+1 de Kruchten[]. En este enfoque se definen 5 vistas diferentes de un mismo sistema cada una de las cuales se enfoca en un aspecto específico del mismo. 12

13 Documento SAD V 1.0 Trabajo de grado para Ingeniería de Sistemass Figura 1. Vista "4+1" adaptado de [] La primera de ellas, la vista lógica, se encarga fundamentalmente de representar los requerimientos funcionales del sistema. Se especifica con diagramas de clases y de secuencia. Los diagramas de secuencia no son por si mismos parte de la vista lógica pero ayudan a refinar el diagrama de clases. La vista lógica se especifica en la sección 5. Vista Lógica La segunda vista es la de Procesos. En esta se toman en cuenta los requerimientos no funcionales de desempeño y disponibilidad. La vista de procesos se especifica en la sección 6. Vista de Procesos. La tercera es la vista de desarrollo. En esta se realiza una descomposición en subsistemas, que pueden ser desarrollados por un desarrollador o un grupo de ellos. Toma en cuenta principalmente requerimientos internos relacionados con la facilidad de desarrollo, la gestión del software, reutilización, y las restricciones impuestas por la herramienta o el lenguaje de programación. La vista de desarrollo se especifica en la sección. Vista de Implementación. La cuarta vista es la física en la cual se toma en cuenta primordialmente los requerimientos no funcionales del sistema como la disponibilidad, la confiabilidad, el desempeño y la escalabilidad. Se realiza el mapeo del software al hardware. La vista física se especifica en la sección 7. Vista de Despliegue. La última vista corresponde a los escenarios. Los escenarios son en cierto sentido abstracciones de los requerimientos más importantes. En este documento se especifican como Diagramas de Casos de Uso. La vista +1, los escenarios, se especifican en la sección 4. Vista de Casos de Uso

14 3. Objetivos y Restricciones Arquitectónicas 3.1. Priorización de requerimientos El proceso de priorización de requerimientos se realizó tomando los Stakeholders involucrados en el proyecto (ver Sección 3.2. Resumen de Stakeholders del Documento Visión_1.0.docx), y mirando la importancia que cada uno de estos Stakeholders tiene sobre cada requerimiento. La primera parte de la priorización es saber el peso que tiene cada Stakeholder del proyecto, porque no podemos tomar a los Stakeholders por igual, porque cada uno tiene una importancia diferente dentro del proyecto. Esto lo hacemos tomando los requerimientos contra los Stakeholders y miramos por cada requerimiento que Stakeholder está interesado en el requerimiento. Luego se contabiliza el número de requerimientos que le interesan a cada Stakeholder, para obtener el porcentaje de los requerimientos que le interesan. Cuando se tiene el peso de cada Stakeholder, se utiliza este peso para obtener la prioridad de cada uno de los requerimientos, sumando los pesos de los Stakeholders interesados en cada requerimiento. Los resultados de los procesos se encuentran en el documento RequerimientosVsStakeholders.xlsx. En las siguientes sub secciones se muestra el resumen de los pesos de los Stakeholders, un resumen de todos los requerimientos y aquellos con prioridad superior a 7, con el fin de justificar las decisiones arquitectónicas tomadas Resumen de ponderación por Stakeholder La Tabla 3. Resumen de ponderación por Stakeholder muestra un resumen de la ponderación asignada a cada Stakeholder del proyecto. Stakeholder Peso del Stakeholder Neuropsicólogo,7 Niño 2,4 Cliente 9,6 Analista de Requerimientos 6,7 Arquitecto de Software 5,4 Director de Desarrollo 4,6 Director del Proyecto 3,0 Administrador del Sistema 2,4 Desarrollador 5,7 Tester 6,6 Tabla 3. Resumen de ponderación por Stakeholder 14

15 Dicha ponderación se realizó con base al documento RequerimientosVSStakeholders.xls, tomando en cuenta la cantidad de requerimientos con los que cada uno de los Stakeholders tenía interés Resumen de requerimientos La Tabla 4. Resumen de requerimientos muestra un resumen de los requerimientos del sistema. ID Descripción Prioridad RF RF RF RF El usuario puede acceder a las funcionalidades que están asociadas al tipo de usuario El usuario ingresa al sistema por medio de su Nickname y Password. Cada función ejecutiva cuenta con actividades cuyos estímulos son visuales y auditivos. Cada subtipo de atención cuenta con actividades cuyos estímulos son visuales y auditivos. RF Cada actividad cuenta con una instrucción RF Cada actividad cuenta con un ejemplo 4 RF RF El sistema muestra al niño únicamente las actividades que el neuropsicólogo le ha asignado. El sistema permite que la actividad aumente de nivel al presentarse RF Las instrucciones dadas son visuales y auditivas 7 RF 02 0 RF RF RF RF RF RF RF RF RF Las instrucciones son mostradas al inicio de cada actividad El niño puede presentar las actividades que el neuropsicólogo le haya asignado Las actividades cuentan con instrucción ejemplo, presentación y retroalimentación. El sistema detecta cuando el niño responde a un estímulo por medio de los dispositivos de entrada El sistema le permite al niño continuar al ejemplo después de ver las instrucciones. El sistema le permite al niño continuar a la presentación después de ver el ejemplo. El sistema muestra la lista de actividades asignadas luego de estar inactivo en las instrucciones. El sistema vuelve a mostrar el ejemplo luego de estar inactivo en el ejemplo. El sistema permite que el niño repita las instrucciones de la actividad El sistema permite que el niño repita el ejemplo de la actividad

16 RF RF El sistema vuelve a mostrar el listado de actividades asignadas luego de estar inactivo 4 veces consecutivas. El sistema tiene un conjunto de ejercicios de práctica para algunas actividades que el neuropsicólogo haya escogido previamente 7 5 RF El sistema permite que el neuropsicólogo modifique las variables de entrada de las actividades. Estas variables de entrada se definen posteriormente según el tipo de cada una de las actividades. RF Una actividad contiene de a 10 niveles de dificultad RF RF RF RF El sistema permite que el neuropsicólogo seleccione el tipo de actividad que asignará al niño El sistema permite al neuropsicólogo consultar los resultados de la presentación de las actividades por parte de los niños. El sistema permite al neuropsicólogo hacer consultas sobre los resultados de cada niño en las actividades realizadas. El sistema permite al neuropsicólogo hacer consultas sobre los resultados históricos de cada uno de los tipos de actividades RF Los resultados que entrega el sistema al neuropsicólogo después de que el niño realiza una actividad de función ejecutiva, contienen información tal como: número de respuestas correctas e incorrectas y la latencia de la respuesta. 7 RF RF RF RF RF El sistema permite que el neuropsicólogo consulte la fecha y hora en que el niño presentó una actividad El sistema almacena los datos resultantes de la realización de cada actividad desarrollada por el niño El sistema almacena los datos básicos de cada niño en tratamiento. El sistema permite la creación de usuarios neuropsicólogos El sistema permite la creación de usuarios administradores RF El sistema permite la eliminación de usuarios niños 7 RF RF RNF RNF El sistema permite la eliminación de usuarios neuropsicólogos El sistema permite la eliminación de usuarios administradores La interfaz gráfica de usuario permite que el usuario niño se concentre durante 15 minutos. Los estímulos utilizados en las actividades se presentan de forma visual y auditiva RNF El sistema cuenta con ayudas tipo ToolTipText

17 RNF RNF RNF 11 0 RNF RNF El sistema muestra la información altamente relevante un formato de texto diferente al resto de información. El sistema cuenta con tutoriales para facilitar el uso del sistema. El sistema integra aplicaciones en formato flash embebidas dentro del sistema. El sistema es parte del proceso de tratamiento del niño con TDAH y por esto debe facilitar la labor del neuropsicólogo en términos de facilidad de uso y optimización de su tiempo. El sistema reproduce simultáneamente más de una estímulo auditivo RNF El sistema cuenta con FAQs 5 RNF El sistema cuenta con ayudas para sus funciones básicas RNF RNF RNF Los dispositivos de entrada del sistema serán únicamente ratón y teclado. Los dispositivos de salida del sistema serán monitor y parlantes Se pueden efectuar pruebas para verificar el cumplimiento de los requerimientos contenidos en este documento Tabla 4. Resumen de requerimientos Requerimientos de prioridad mayor o igual a La Tabla 5. Requerimientos de prioridad mayor o igual a muestra ordenados de mayor a menor los requerimientos según su prioridad en el sistema. Los niveles de prioridad están definidos en la sección del documento SRS, la priorización se encuentra en el documento RequerimientosVSStakeholders.xls y el método para realizar la priorización se describe en la sección 3.1 Priorización de requerimientos en este documento. ID Descripción Prioridad RF RF RF RNF RNF Cada función ejecutiva cuenta con actividades cuyos estímulos son visuales y auditivos. Cada subtipo de atención cuenta con actividades cuyos estímulos son visuales y auditivos. El sistema detecta cuando el niño responde a un estímulo por medio de los dispositivos de entrada La interfaz gráfica de usuario permite que el usuario niño se concentre durante 15 minutos. Los estímulos utilizados en las actividades se presentan de forma visual y auditiva

18 RF RF RF RF RF RF El sistema permite que el neuropsicólogo modifique las variables de entrada de las actividades. Estas variables de entrada se definen posteriormente según el tipo de cada una de las actividades. El sistema permite al neuropsicólogo hacer consultas sobre los resultados de cada niño en las actividades realizadas. El sistema permite al neuropsicólogo hacer consultas sobre los resultados históricos de cada uno de los tipos de actividades El sistema permite que el neuropsicólogo consulte la fecha y hora en que el niño presentó una actividad El sistema permite que el niño repita las instrucciones de la actividad El sistema permite que el niño repita el ejemplo de la actividad RF Cada actividad cuenta con una instrucción RF RF RF RF El sistema muestra al niño únicamente las actividades que el neuropsicólogo le ha asignado. El niño puede presentar las actividades que el neuropsicólogo le haya asignado El sistema permite que la actividad aumente de nivel al presentarse Las actividades cuentan con instrucción ejemplo, presentación y retroalimentación. RF Una actividad contiene de a 10 niveles de dificultad RF RNF RNF El sistema permite al neuropsicólogo consultar los resultados de la presentación de las actividades por parte de los niños. Los dispositivos de entrada del sistema serán únicamente ratón y teclado. Los dispositivos de salida del sistema serán monitor y parlantes Tabla 5. Requerimientos de prioridad mayor o igual a Metas y restricciones arquitectónicas según requerimientos Basados en la priorización expuesta en la sección anterior, se plantean las siguientes metas a cumplir con la arquitectura propuesta: Ya que para el tratamiento neuropsicológico del TDAH es necesario estimular a los niños por medio de las vías visual y auditiva, el sistema debe permitir presentar estímulos de dicha manera. El neuropsicólogo debe poder asignar actividades a sus niños según las funcionalidades que pretenda tratar. 1

19 Para el neuropsicólogo es fundamental poder ver los resultados que el niño obtuvo al presentar cada actividad asignada pues esto le permite continuar con su diagnóstico y tratamiento. Como el sistema será utilizado por una población muy específica, es necesario que el lenguaje sea el español pero que esté adaptado al lenguaje que se usa en Colombia. El cliente estará presente en el proceso de determinación de las palabras usadas para que esto quede satisfecho. Con respecto al proceso de presentación de cada actividad, es importante resaltar que todas las actividades deben contar con su respectivo ejemplo e instrucción. En términos de seguridad, es necesario que se cuenten con gestores de autenticación y autorización para asegurar que están accediendo al sistema las personas autorizadas con sus respectivos datos. Esto permite asegurar que los datos manejados en el sistema sean confidenciales y solo puedan ser recuperados por las personas autorizadas. 4. Vista de Casos de Uso Un caso de uso es una secuencia general de eventos, que describe todas las posibles acciones entre los posibles actores y el sistema, para una determinada funcionalidad[9]. En esta sección se describen los Casos de Uso del sistema SANTi, en donde se abarcan todas las funcionalidades del sistema, se muestran los actores que interactúan en el sistema y las funcionalidades asociadas. El diagrama de Casos de Uso actualizado se puede observar en la Ilustración 2 Vista de Casos de Uso, además está se encuentra anexa en el archivo CU.jpg 19

20 Ilustración 2 Vista de Casos de Uso La documentación de los Casos de Uso actualizada se encuentra en anexa en el archivo CU.xls, en donde se puede encontrar toda la información asociada a cada caso de uso. La Tabla 6. Casos de Uso del sistema SANTi muestra un resumen de los Casos de Uso del sistema SANTi Id Nombre Descripción 20

21 CU 1 Gestionar Usuarios Gestionar la información de usuarios existentes en el sistema CU 1.1 Crear Usuarios Crear usuarios con sus datos necesarios Consultar Consultar información de los usuarios que están CU 1.2 información de creados en el sistema SANTi Usuarios CU 1.3 CU 1.4 CU 2 CU 2.1 CU 2.2 CU 3 CU 3.1 CU 4 CU 5 Actualizar información de Usuarios Eliminar usuarios Gestionar Actividades Consultar información de actividades Actualizar información de actividades Entrar al sistema Reintentar Ingreso al sistema Salir del Sistema Crear Actividad Cambiar datos de la información de los usuarios que están creados en el sistema SANTi Desactivar una cuenta de usuario para que este no pueda ingresar al sistema Gestionar la información de actividades existentes en el sistema Consultar información de las actividades que están creados en el sistema SANTi Cambiar datos de la información de las actividades que están creadas en el sistema SANTi Ingresar al sistema y ver las funcionalidades disponibles según el tipo de usuario Ingresar al sistema y ver las funcionalidades disponibles según el tipo de usuario Permite que el usuario salga del sistema guardando los cambios que realizo mientras lo utilizo Asignar los valores deseados a una actividad para posteriormente asignarla a un niño CU 5.1 Crear Instrucción Se crea la instrucción de la actividad CU 5.2 Crear Ejemplo Se crea el ejemplo de la actividad CU 5.3 Crear Presentación Se crea la presentación de la actividad CU 5.4 CU 6 CU 7 Crear Retroalimentación Asignar Actividad Consultar Reportes Se crea la retroalimentación de la actividad Asignar una actividad creada a un niño con TDAH para que éste la pueda realizar Acceder a toda la información almacenada luego de que un niño con TDAH presenta una actividad CU 10 CU 10.1 CU 10.2 Presentar Actividad Cambiar nivel de dificultad Repetir las instrucciones Realizar el proceso completo de presentación de una actividad. Esto incluye ver instrucciones, ejemplo, presentación y retroalimentación Aumentar la dificultad de la actividad que se está presentando Ver nuevamente las instrucciones presentadas al iniciar una actividad 21

22 CU 10.3 CU 10.4 CU 10.5 CU 11 Repetir ejemplo Ver Retroalimentación Almacenar Resultados Consultar Actividades Asignadas Ver nuevamente el ejemplo presentado luego de ver las instrucciones de una actividad Observar cómo le fue en la presentación de la actividad Se almacenan los resultados de la actividad presentada por el niño en la Base de Datos Consultar las actividades que el neuropsicólogo le ha asignado para posteriormente presentarlas CU 12 Crear Usuarios Niño Crear usuarios niño con sus datos necesarios CU 13 CU 14 CU 15 CU 16 Consultar FAQ Consultar datos de los niños Consultar Ayuda Consultar las preguntas más frecuentes y sus respectivas respuestas Consultar los datos de los niños que están siendo tratados con el sistema Consultar la ayuda en caso de tener algún inconveniente Consultar los tutoriales asociados a cada tipo de Consultar Tutorial usuario (Neuropsicólogo y Niño) Tabla 6. Casos de Uso del sistema SANTi 5. Vista Lógica La vista lógica se encarga de representar los requerimientos funcionales del sistema. Esta sección describe las partes del diseño del modelo significativas para la arquitectura, tales como subsistemas y paquetes. El diagrama de Vista Lógica actualizado se puede observar en la Ilustración 3 Vista Lógica y en el archivo anexo Vista Logica.jpg. Ilustración 3 Vista Lógica 5.1. Visión General Como se explica en la sección 2.2 Representación arquitectónica de este documento, la arquitectura de general escogida para el sistema SANTi es Cliente Servidor en Capas. En esta vista se observan los dos módulos: Cliente y Servidor. El cliente hace parte de un cliente pesado como es descrito en la sección Clientes pesados y contiene las capas de presentación, seguridad y lógica del negocio (core). 22

23 El servidor es descrito en la sección Servidor de este documento, encargándose fundamentalmente del manejo de los datos del sistema y de la comunicación entre los distintos clientes cuando es necesario el paso de información desde y hacia la Base de Datos del sistema Diseño Arquitectónico de Paquetes Importantes Paquete Presentación Este paquete está modelado bajo el patrón MVC, el cual se explica en la sección Modelo Vista Controlador [2]. El paquete de presentación es el encargado de desplegar la información que es mostrada a los usuarios niño, neuropsicólogo y administrador Lógica del Negocio La lógica de negocio está basada en el sistema JClic[5] y contiene toda la lógica necesaria para modelar las actividades de tratamiento del TDAH definidas en el documento Especificación de las Actividades, la presentación de las actividades, la gestión de usuario, el manejo de los reportes y la asignación de actividades a cada uno de los niños Conexión El paquete conexión es el encargado de manejar las conexiones entre el Cliente y el Servidor. Este paquete permite la concurrencia entre varios clientes y el servidor, permitiendo el uso del sistema por varios usuarios al mismo tiempo Datos Este paquete es el encargado de controlar la información que ingresa y sale de la Base de Datos de SANTi, sustentando el funcionamiento del sistema. 6. Vista de Procesos En esta vista se realiza una descomposición en subsistemas, que pueden ser desarrollados por un desarrollador o un grupo de ellos. Toma en cuenta principalmente requerimientos internos relacionados con la facilidad de desarrollo, la gestión del software, reutilización, y las restricciones impuestas por la herramienta o el lenguaje de programación. En esta sección se ilustra el mapeo de los requerimientos no funcionales de desempeño y disponibilidad al diagrama de procesos. 23

24 El diagrama de Procesos actualizado se puede observar en la Ilustración 4 Vista de Procesos, además encuentra anexa en el documento Modelo de procesos.jpg. Ilustración 4 Vista de Procesos En el servidor de SANTi estarán ejecutándose constantemente 2 procesos correspondientes a la máquina virtual de java y a la base de datos. Cada cliente del sistema SANTi correrá un proceso adicional. La cantidad final de procesos en ejecución será 2 + n, donde n es igual a la cantidad de clientes en ejecución. 7. Vista de Despliegue La configuración física de la red es muy simple ya que la arquitectura Cliente Servidor permite que sea de esta manera. Como se puede ver en la Ilustración 5 Vista de Despliegue y en el archivo adjunto Modelo de despliegue.jpg. Ilustración 5 Vista de Despliegue Todos los clientes se conectarán directamente al servidor para intercambiar información con este, y poder funcionar de manera adecuada. 24

25 . Vista de Implementación En esta vista se detalla la manera como fue implementado el sistema SANTi, se describe visualmente las capas que tiene el sistema, como están distribuidas y sus principales funciones. El diagrama de Implementación se puede observar en la Ilustración 6 Vista de Implementación y también se encuentra anexa en el archivo Implementacion.jpg. Ilustración 6 Vista de Implementación.1. Visión General La implementación del sistema SANTi fue desarrollada bajo la arquitectura Cliente Servidor en Capas (ver sección 2.2 Representación arquitectónica), en donde se une la arquitectura de cliente servidor con la de capas..2. Capas El sistema SANTi fue implementado en cuatro capas. Cada una de estas se describe a continuación en las siguientes sub secciones Presentación Esta capa es la encargada de mostrar la información asociada a cada tipo de usuario, recibir las acciones de los usuarios y enviar las peticiones correspondientes a la siguiente capa, encargada de procesar la información. En la Ilustración 7 Capa de Presentación se puede observar la capa de presentación. 25

26 Ilustración 7 Capa de Presentación.2.2. Seguridad Esta capa es la encargada de validar que el nickname y el password solicitado por el usuario sean correctos y se encarga de enviar la información asociada a cada usuario según su tipo de usuario (ver la sección 3.6 Perfil de Usuarios en el documento de Visión). En la Ilustración Capa de Seguridad se puede observar la capa de Seguridad. Ilustración Capa de Seguridad 26

27 .2.3. Lógica de Negocio (Core) Esta capa es la encargada de administrar el comportamiento y los datos del sistema SANTi, respondiendo a las peticiones realizadas por los usuarios desde la capa de presentación. En la Ilustración 9 Capa de Lógica del Negocio (Core) se puede observar la capa de lógica del negocio. Ilustración 9 Capa de Lógica del Negocio (Core).2.4. Datos En esta capa se realiza el procesamiento de datos desde y hacia la bases de datos para que la capa de lógica de negocio pueda funcionar correctamente, también es la encargada de acceder a la base de datos de SANTi. 27

28 En la Ilustración 10 Capa de Datos se puede observar la capa de Datos del sistema SANTi. Ilustración 10 Capa de Datos 9. Vista de Datos En esta vista se explica la manera como fueron almacenados los datos en la base de datos de SANTi. Esta vista es vital porque el sistema se encarga de gestionar usuario, actividades y reportes. En el diagrama de entidad relación que se puede observar en la Ilustración 11 Vista de Datos, se pueden ver las tablas que se utilizaron para la persistencia de los datos. 2

29 Ilustración 11 Vista de Datos 10. Tamaño y Desempeño En esta sección se describen de manera general las características del software que impactan la arquitectura y las restricciones de desempeño Concurrencia de usuarios El sistema SANTi está diseñado para permitir el acceso concurrente de máximo 10 (tomando el caso extremo que todos los usuarios estén consultando la capa de datos al mismo tiempo). El sistema cuenta con un manejador de concurrencia de usuarios que permite que este no baje su desempeño cuando varios usuarios lo estén accediendo a la capa de datos. 11. Calidad En esta sección se describe cómo la arquitectura contribuye a las características no funcionales del sistema. 29

30 11.1. Seguridad Despliegue de la información El sistema SANTi controla el despliegue de la información de acuerdo al tipo de usuario (ver la sección 3.6 Perfil de Usuarios en el documento de Visión), mostrando la información apropiada para cada usuario que ingresa en la aplicación. La capa de seguridad es la encargada de validar los privilegios que tiene cada tipo de usuario en el sistema Validación de la información del usuario El sistema SANTi asegura la privacidad de la información por cada usuario que se encuentre dentro del sistema, ya que pueden existen personas malintencionadas que tratarán de modificar o borrar la información que esta almacenada en el sistema. Esto se realiza mediante la capa de seguridad, la cual se encarga de validar que el nickname y password que son ingresados por el usuario sean correctos Usabilidad Presentación de estímulos visuales y auditivos El sistema SANTi permite la creación de actividades con estímulos visuales y auditivos, esto con el fin de aumentar el interés del niño hacia el sistema Ayudas tipo ToolTipText El sistema SANTi contiene ayudas tipo ToolTipText en cada uno de sus botones, mejorando la usabilidad del sistema. 30