documento de arquitectura de software...

asaaaaa

V_1.0D i r e c t o r : M i g u e l

T o r r e s M . S c .

C l i e n t e y C o n s u l t o r : O s c a r M a u r i c i o A g u i l a r

N e u r o p s i c ó l o g o

P o n t i f i c i a U n i v e r s i d a d J a v e r i a n a

F a c u l t a d D e I n g e n i e r í a

0 7 / 0 7 / 2 0 0 9

Nicolás Aristizábal MejíaRicardo López QuiñonesGustavo 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.

Documento de Arquitectura de Software SAD

Documento SAD – V_1.0 – Trabajo de grado para Ingeniería de Sistemas

2

Historial de Cambios Autor Fecha Sección

Modificada Descripción del Cambio

Gustavo Salazar Garzón

07/07/2009 Todas Creación de la Plantilla con sus respectivas secciones y descripciones

Ricardo López Quiñones

28/07/2009 Propósito y Alcance Creación y redacción de las secciones descritas anteriormente

Nicolás Aristizábal Mejía

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 0.3.


19/10/2009 Sección 2.2.4 Creación


28/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,8,9 , 10 y 11

Actualización y Revisión Final

Ricardo López Quiñones

06/12/2009 Todo el documento Revisión de calidad


3

Tabla de Contenido 1. Introducción .......................................................................................................................... 5

1.1. Propósito ........................................................................................................................... 5

1.2. Alcance .............................................................................................................................. 5

1.3. Definiciones, acrónimos y abreviaturas ............................................................................ 6

1.4. Referencias ........................................................................................................................ 6

1.4.1. Descripción de la Metodología usada ........................................................................... 6

1.4.2. Referencias .................................................................................................................... 6

1.5. Visión general del documento .......................................................................................... 7

2. Representación Arquitectónica ............................................................................................. 7

2.1. Selección de Arquitecturas según los Atributos de Calidad .............................................. 8

2.2. Representación arquitectónica ......................................................................................... 9

2.2.1. Clientes pesados ............................................................................................................ 9

2.2.1.1. Presentación ............................................................................................................ 10

2.2.1.1.1. Modelo – Vista – Controlador [2] ............................................................................ 10

2.2.1.2. Seguridad ................................................................................................................. 11

2.2.1.3. Lógica del Negocio (Core) ........................................................................................ 11

2.2.2. Servidor ....................................................................................................................... 11

2.2.3. Capas ........................................................................................................................... 11

2.3. Representación arquitectónica ....................................................................................... 12

3. Objetivos y Restricciones Arquitectónicas .......................................................................... 14

3.1. Priorización de requerimientos ....................................................................................... 14

3.1.1. Resumen de ponderación por Stakeholder ................................................................. 14

3.1.2. Resumen de requerimientos ....................................................................................... 15

3.1.3. Requerimientos de prioridad mayor o igual a 8 .......................................................... 17

3.2. Metas y restricciones arquitectónicas según requerimientos ........................................ 18

4. Vista de Casos de Uso.......................................................................................................... 19

5. Vista Lógica .......................................................................................................................... 22

5.1. Visión General ................................................................................................................. 22

5.2. Diseño Arquitectónico de Paquetes Importantes ........................................................... 23

5.2.1. Paquete Presentación ................................................................................................. 23

5.2.2. Lógica del Negocio ....................................................................................................... 23

5.2.3. Conexión ...................................................................................................................... 23

5.2.4. Datos ........................................................................................................................... 23


4

6. Vista de Procesos ................................................................................................................ 23

7. Vista de Despliegue ............................................................................................................. 24

8. Vista de Implementación .................................................................................................... 25

8.1. Visión General ................................................................................................................. 25

8.2. Capas ............................................................................................................................... 25

8.2.1. Presentación ................................................................................................................ 25

8.2.2. Seguridad ..................................................................................................................... 26

8.2.3. Lógica de Negocio (Core) ............................................................................................. 27

8.2.4. Datos ........................................................................................................................... 27

9. Vista de Datos ..................................................................................................................... 28

10. Tamaño y Desempeño ..................................................................................................... 29

10.1. Concurrencia de usuarios ............................................................................................ 29

11. Calidad ............................................................................................................................. 29

11.1. Seguridad ..................................................................................................................... 30

11.1.1. Despliegue de la información ...................................................................................... 30

11.1.2. Validación de la información del usuario .................................................................... 30

11.2. Usabilidad .................................................................................................................... 30

11.2.1. Presentación de estímulos visuales y auditivos .......................................................... 30

11.2.2. Ayudas tipo ToolTipText .............................................................................................. 30


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.

1.2. 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 2009.

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.


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.

1.3. 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.1.0”

1.4. Referencias

1.4.1. 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.

1.4.2. Referencias [1] G. Reese, Database Programming with JDBC and Java, Second Edition, O’Reilly, Noviembre

de 2000, 128‐133 [2] C. Reynoso, N. Kiccillof, Estilos y Patrones en la Estrategia de Arquitectura de Microsoft,

Universidad de Buenos Aires, Marzo de 2004, 17‐19 [3] S. Burbeck. “Application programming in Smalltalk‐80: How to use Model‐View‐Controller

(MVC)”.University of Illinois in Urbana‐Champaign, Smalltalk Archive, http://st‐www.cs.uiuc.edu/users/smarch/st‐docs/mvc.html.

[4] Enterprise Solution Patterns: Model‐View‐Controller. Microsoft Patterns & Practices, http://msdn.microsoft.com/practices/type/Patterns/Enterprise/DesMVC/, 2003.

[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, 31‐52

[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, 1994.

[7] Object Management Group, Inc. UML® Resource Page [página de Internet]. 2009 [14/09/09]. Disponible en: http://www.uml.org/

[8] KRUCHTEN, P, Architectural Blueprints—The “4+1” View Model of Software Architecture, IEEE Software 12 (6), November 1995, p. 42‐50.

[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 9126‐1:2001, Software engineering ‐ Product Quality, Part 1: Quality model", 2001.


7

[11] Frank Buschmann – Regine Meunier – Hans Rohnert – Peter Sommerland – Michael Stal, Pattern Oriented Software Architecture, Volumen 1, AG Germany, WILEY, 1996, p. 457.

[12] JClic [Homepage en Internet] Cataluña ‐ España: XTEC [01/12/2009]. Disponible en: http://clic.xtec.cat/es/index.htm

[13] Designing a Three‐Tier Architecure Pattern Language Design Fest, EuroPLoP 2001 Kloster Irsee/Germany, July 4‐8 Proceedings: http://posa3.org/workshops/ThreeTierPatterns/;http://www.hillside.net/patterns/EuroPLoP2001/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 2008‐3.

[16] IEEE Recommended Practice for Software Requirements Specifications, 830‐1998. [17] IEEE Recommended Practice for Software Design Descriptions, 1016‐1998. [18] Bustacara Medina, Cesar Julio – [homepage de Internet] Plantilla Documento SAD

[01/05/2009]. Disponible en: http://sophia.javeriana.edu.co/~cbustaca/ [19] Camargo, E; Cardeso, F; Nuñez M. Guia de Estudio[Articulo en internet]Venezuela;

[4/12/2009]. Disponible en: http://prof.usb.ve/lmendoza/Documentos/PS‐6116/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 8. 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.


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 9126.

Actividad DescripciónAná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

Candidatas Utilizando las métricas de calidad definidas se realiza una 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 9126.

Categoría Sub Categoría

Funcionalidad

IdoneidadPrecisión Seguridad

Interoperabilidad

Fiabilidad Madurez

RecuperabilidadTolerancia a Fallos

Eficiencia Comportamiento en el tiempo Comportamiento de los recursos

Mantenibilidad

Capacidad de AnálisisFacilidad de Cambio

Estabilidad Facilidad de Pruebas

Portabilidad

AdaptabilidadCapacidad de Instalación

Co‐existencia Capacidad de Cambio

Usabilidad 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].

2.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.

2.2.1. 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


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 cliente‐servidor. 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)

2.2.1.1. Presentación La capa de presentación está representada por medio del patrón de diseño Modelo – Vista – Controlador (ver sección 2.2.1.1.1 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.

2.2.1.1.1. 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.


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.

2.2.1.2. 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.

2.2.1.3. 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.

2.2.2. Servidor El servidor del sistema estará definido por la arquitectura por capas que se especifica en la

sección 2.2.3 Capas de este documento.

El servidor tendrá la lógica del negocio y se encargará del almacenamiento de los datos.

2.2.3. 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].


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.

2.3. 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[8]. 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.

La prirequerLos diael diages la desemProcessubsistcuentagestiónlenguaImplemrequerdesemespecifLos esceste dose espe

Docume

mera de ellrimientos funagramas de serama de clasede Procesospeño y dispos. La tercertemas, que pa principalmen del softwaje de programentación. Larimientos nopeño y la escfica en la seccenarios son ocumento se ecifican en la

ento SAD – V_

as, la vista cionales del secuencia no ses. La vista lós. En esta seonibilidad. Lra es la vistueden ser deente requerimare, reutilizacamación. La a cuarta vistao funcionalescalabilidad. Scción 7. Vistaen cierto senespecifican csección 4. Vi

_1.0 – Trabajo

Figura 1. Vista "

lógica, se esistema. Se eson por si misógica se espece toman ena vista de pa de desarroesarrollados pmientos internción, y las rvista de des es la física es del sistemSe realiza el ma de Despliegntido abstracccomo Diagramista de Casos

o de grado pa

"4+1" adaptado

encarga fundespecifica consmos parte decifica en la se cuenta los procesos se eollo. En estapor un desarrnos relacionaestricciones sarrollo se een la cual se ma como la mapeo del sogue. La últimaciones de los mas de Casosde Uso

ara Ingeniería

de [8]

damentalmenn diagramas de la vista lógicción 5. Vistarequerimien

especifica ena se realiza urollador o un ados con la faimpuestas pespecifica entoma en cuedisponibilida

oftware al hara vista corresrequerimien de Uso. La v

a de Sistemas

nte de reprde clases y deca pero ayuda Lógica La sentos no funcn la sección una descompgrupo de elloacilidad de depor la herram la sección nta primordiad, la confiardware. La visponde a los tos más impoista “+1”, los

s

esentar los e secuencia. dan a refinar egunda vista cionales de 6. Vista de posición en os. Toma en esarrollo, la mienta o el 8. Vista de almente los abilidad, el sta física se escenarios. ortantes. En escenarios,


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.

3.1.1. 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 8,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


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.

3.1.2. Resumen de requerimientos La Tabla 4. Resumen de requerimientos muestra un resumen de los requerimientos del sistema.

ID Descripción Prioridad

RF‐01‐01 El usuario puede acceder a las funcionalidades que están

asociadas al tipo de usuario 5

RF‐01‐02 El usuario ingresa al sistema por medio de su Nickname y

Password. 6

RF‐02‐01 Cada función ejecutiva cuenta con actividades cuyos

estímulos son visuales y auditivos. 10

RF‐02‐02 Cada subtipo de atención cuenta con actividades cuyos


RF‐02‐03 Cada actividad cuenta con una instrucción 8 RF‐02‐04 Cada actividad cuenta con un ejemplo 4

RF‐02‐05 El sistema muestra al niño únicamente las actividades

que el neuropsicólogo le ha asignado. 8

RF‐02‐06 El sistema permite que la actividad aumente de nivel al

presentarse 8

RF‐02‐07 Las instrucciones dadas son visuales y auditivas 7

RF‐02‐08 Las instrucciones son mostradas al inicio de cada

actividad 6

RF‐02‐09 El niño puede presentar las actividades que el

neuropsicólogo le haya asignado 8

RF‐02‐11 Las actividades cuentan con instrucción ejemplo,

presentación y retroalimentación. 8

RF‐02‐17 El sistema detecta cuando el niño responde a un estímulo por medio de los dispositivos de entrada

9

RF‐02‐20 El sistema le permite al niño continuar al ejemplo

después de ver las instrucciones. 7

RF‐02‐21 El sistema le permite al niño continuar a la presentación

después de ver el ejemplo. 7

RF‐02‐22 El sistema muestra la lista de actividades asignadas luego

de estar inactivo en las instrucciones. 7

RF‐02‐23 El sistema vuelve a mostrar el ejemplo luego de estar

inactivo en el ejemplo. 7

RF‐02‐24 El sistema permite que el niño repita las instrucciones de

la actividad 8

RF‐02‐25 El sistema permite que el niño repita el ejemplo de la

actividad 8


16

RF‐02‐26 El sistema vuelve a mostrar el listado de actividades

asignadas luego de estar inactivo 4 veces consecutivas. 7

RF‐02‐27 El sistema tiene un conjunto de ejercicios de práctica para algunas actividades que el neuropsicólogo haya

escogido previamente 5

RF‐03‐01

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.

9

RF‐03‐05 Una actividad contiene de 8 a 10 niveles de dificultad 8

RF‐04‐01 El sistema permite que el neuropsicólogo seleccione el

tipo de actividad que asignará al niño 4

RF‐05‐01 El sistema permite al neuropsicólogo consultar los resultados de la presentación de las actividades por

parte de los niños. 8

RF‐05‐02 El sistema permite al neuropsicólogo hacer consultas sobre los resultados de cada niño en las actividades

realizadas. 9

RF‐05‐03 El sistema permite al neuropsicólogo hacer consultas sobre los resultados históricos de cada uno de los tipos

de actividades 9

RF‐05‐04

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‐06‐02 El sistema permite que el neuropsicólogo consulte la fecha y hora en que el niño presentó una actividad

9

RF‐07‐01 El sistema almacena los datos resultantes de la

realización de cada actividad desarrollada por el niño 6

RF‐07‐02 El sistema almacena los datos básicos de cada niño en

tratamiento. 7

RF‐07‐06 El sistema permite la creación de usuarios

neuropsicólogos 6

RF‐07‐07 El sistema permite la creación de usuarios

administradores 3

RF‐09‐01 El sistema permite la eliminación de usuarios niños 7

RF‐09‐02 El sistema permite la eliminación de usuarios

neuropsicólogos 7

RF‐09‐03 El sistema permite la eliminación de usuarios

administradores 5

RNF‐11‐01 La interfaz gráfica de usuario permite que el usuario niño

se concentre durante 15 minutos. 9

RNF‐11‐04 Los estímulos utilizados en las actividades se presentan

de forma visual y auditiva 9

RNF‐11‐05 El sistema cuenta con ayudas tipo ToolTipText. 5


17

RNF‐11‐06 El sistema muestra la información altamente relevante un formato de texto diferente al resto de información.

4

RNF‐11‐07 El sistema cuenta con tutoriales para facilitar el uso del

sistema. 6

RNF‐11‐08 El sistema integra aplicaciones en formato flash

embebidas dentro del sistema. 4

RNF‐12‐01

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.

7

RNF‐14‐01 El sistema reproduce simultáneamente más de una

estímulo auditivo 6

RNF‐17‐01 El sistema cuenta con FAQs 5

RNF‐17‐02 El sistema cuenta con ayudas para sus funciones básicas 5

RNF‐19‐01 Los dispositivos de entrada del sistema serán

únicamente ratón y teclado. 8

RNF‐19‐02 Los dispositivos de salida del sistema serán monitor y

parlantes 8

RNF‐20‐01 Se pueden efectuar pruebas para verificar el

cumplimiento de los requerimientos contenidos en este documento

4

Tabla 4. Resumen de requerimientos

3.1.3. Requerimientos de prioridad mayor o igual a 8 La Tabla 5. Requerimientos de prioridad mayor o igual a 8 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 2.2.13 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‐02‐01 Cada función ejecutiva cuenta con actividades cuyos


RF‐02‐02 Cada subtipo de atención cuenta con actividades cuyos


RF‐02‐17 El sistema detecta cuando el niño responde a un estímulo por medio de los dispositivos de entrada

9

RNF‐11‐01 La interfaz gráfica de usuario permite que el usuario niño

se concentre durante 15 minutos. 9

RNF‐11‐04 Los estímulos utilizados en las actividades se presentan

de forma visual y auditiva 9


18

RF‐03‐01

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.

9

RF‐05‐02 El sistema permite al neuropsicólogo hacer consultas sobre los resultados de cada niño en las actividades

realizadas. 9

RF‐05‐03 El sistema permite al neuropsicólogo hacer consultas sobre los resultados históricos de cada uno de los tipos

de actividades 9

RF‐06‐02 El sistema permite que el neuropsicólogo consulte la fecha y hora en que el niño presentó una actividad

9

RF‐02‐24 El sistema permite que el niño repita las instrucciones de

la actividad 8

RF‐02‐25 El sistema permite que el niño repita el ejemplo de la

actividad 8

RF‐02‐03 Cada actividad cuenta con una instrucción 8

RF‐02‐05 El sistema muestra al niño únicamente las actividades

que el neuropsicólogo le ha asignado. 8

RF‐02‐09 El niño puede presentar las actividades que el

neuropsicólogo le haya asignado 8

RF‐02‐06 El sistema permite que la actividad aumente de nivel al

presentarse 8

RF‐02‐11 Las actividades cuentan con instrucción ejemplo,

presentación y retroalimentación. 8

RF‐03‐05 Una actividad contiene de 8 a 10 niveles de dificultad 8

RF‐05‐01 El sistema permite al neuropsicólogo consultar los resultados de la presentación de las actividades por

parte de los niños. 8

RNF‐19‐01 Los dispositivos de entrada del sistema serán

únicamente ratón y teclado. 8

RNF‐19‐02 Los dispositivos de salida del sistema serán monitor y

parlantes 8

Tabla 5. Requerimientos de prioridad mayor o igual a 8

3.2. 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.


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”


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


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

CU ‐ 1.2 Consultar

información de Usuarios

Consultar información de los usuarios que están creados en el sistema SANTi

CU ‐ 1.3 Actualizar

información de Usuarios

Cambiar datos de la información de los usuarios que están creados en el sistema SANTi

CU ‐ 1.4 Eliminar usuarios Desactivar una cuenta de usuario para que este

no pueda ingresar al sistema

CU ‐ 2 Gestionar Actividades

Gestionar la información de actividades existentes en el sistema

CU ‐ 2.1 Consultar

información de actividades

Consultar información de las actividades que están creados en el sistema SANTi

CU ‐ 2.2 Actualizar

información de actividades

Cambiar datos de la información de las actividades que están creadas en el sistema

SANTi

CU ‐ 3 Entrar al sistema Ingresar al sistema y ver las funcionalidades

disponibles según el tipo de usuario

CU ‐ 3.1 Reintentar Ingreso al

sistema Ingresar al sistema y ver las funcionalidades

disponibles según el tipo de usuario

CU ‐ 4 Salir del Sistema Permite que el usuario salga del sistema

guardando los cambios que realizo mientras lo utilizo

CU ‐ 5 Crear Actividad 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 Crear

Retroalimentación Se crea la retroalimentación de la actividad

CU ‐ 6 Asignar Actividad Asignar una actividad creada a un niño con

TDAH para que éste la pueda realizar

CU ‐ 7 Consultar Reportes Acceder a toda la información almacenada

luego de que un niño con TDAH presenta una actividad

CU ‐ 10 Presentar Actividad Realizar el proceso completo de presentación de una actividad. Esto incluye ver instrucciones,

ejemplo, presentación y retroalimentación

CU ‐ 10.1 Cambiar nivel de

dificultad Aumentar la dificultad de la actividad que se

está presentando

CU ‐ 10.2 Repetir las

instrucciones Ver nuevamente las instrucciones presentadas

al iniciar una actividad


22

CU ‐ 10.3 Repetir ejemplo Ver nuevamente el ejemplo presentado luego

de ver las instrucciones de una actividad

CU ‐ 10.4 Ver

Retroalimentación Observar cómo le fue en la presentación de la

actividad

CU ‐ 10.5 Almacenar Resultados

Se almacenan los resultados de la actividad presentada por el niño en la Base de Datos

CU ‐ 11 Consultar Actividades Asignadas

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 Consultar FAQ Consultar las preguntas más frecuentes y sus

respectivas respuestas

CU ‐ 14 Consultar datos de

los niños Consultar los datos de los niños que están

siendo tratados con el sistema

CU ‐ 15 Consultar Ayuda Consultar la ayuda en caso de tener algún

inconveniente

CU ‐ 16 Consultar Tutorial Consultar los tutoriales asociados a cada tipo de

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 2.2.1. Clientes pesados y contiene las capas de presentación, seguridad y lógica del negocio (core).


23

El servidor es descrito en la sección 2.2.2. 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.

5.2. Diseño Arquitectónico de Paquetes Importantes

5.2.1. Paquete Presentación Este paquete está modelado bajo el patrón MVC, el cual se explica en la sección 2.2.1.1.1.

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.

5.2.2. 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.

5.2.3. 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.

5.2.4. 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.


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.


25

8. 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

8.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.

8.2. Capas El sistema SANTi fue implementado en cuatro capas. Cada una de estas se describe a continuación en las siguientes sub secciones.

8.2.1. 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.


26

Ilustración 7 Capa de Presentación

8.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 8 Capa de Seguridad se puede observar la capa de Seguridad.

Ilustración 8 Capa de Seguridad


27

8.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)

8.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.


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.


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.

10.1. 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.


30

11.1. Seguridad

11.1.1. 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.

11.1.2. 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.

11.2. Usabilidad

11.2.1. 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.

11.2.2. Ayudas tipo ToolTipText El sistema SANTi contiene ayudas tipo ToolTipText en cada uno de sus botones, mejorando la usabilidad del sistema.

documento de arquitectura de software...

Documents