Documento Arquitectura Calendario

myUSB
@USB
Documento de Arquitectura: Aplicación Calendario
Versión <0.1>
@USB Versión: <0.1>
Documento de Arquitectura: Aplicación Calendario Fecha: <12-06-2008>
Arquitectura
Historia de Revisión
Fecha Versión Descripción Autor
12-06-2008 0.1 Primera versión del Documento de Beatriz Avila
Arquitectura de la aplicación Calendario Luis Serrano
para el sistema myUSB. Maribel Acosta
Alexander Bustamante
Cristiam Da Silva
Zinahia Querales
07-07-2008 0.5 Versión final del Documento de @USB
Arquitectura de la aplicación Calendario
para el sistema myUSB
Confidencial myUSB, 2010 Página 2 de 27

Arquitectura
Tabla de Contenidos
1. Introducción 5
1.1 Propósito 5
1.2 Alcance 5
1.3 Definiciones, Acrónimos y Abreviaturas 5
1.4 Referencias 5
1.5 Visión General 5
2. Representación Arquitectural 6
3. Metas de Arquitectura y Restricciones 6
4. Vista de Casos de Uso 7

4.1 Actores del Sistema 8
4.2 Diagramas de Caso de Uso de la aplicación Calendario 8
4.3 Lista de casos de uso en formato breve 9
4.3.1 Crear Evento 9
4.3.2 Eliminar Evento 9
4.3.3 Editar Evento 10
4.3.4 Ver eventos en un mes dado 10
4.3.5 Ver eventos en el mes actual 11
4.3.6 Ver todos los eventos 11
5. Vista Lógica 12
5.1 Crear Evento 16
5.2 Eliminar Evento 16
5.3 Editar Evento 17
5.4 Ver eventos en un mes dado 17
5.5 Ver eventos en el mes actual 18
5.6 Ver todos los eventos 18
6. Vista de Implementación 19
6.1 Visión General 19
6.2 Capas 19
6.2.1 Capa de Interfaz 19
6.2.2 Capa de Negocio 20
6.2.3 Capa de Datos y Utilidades 21
7. Vista de Despliegue 22
7.1 Requerimientos 22
7.1.1 Del usuario 22
7.1.2 Del servidor 23
7.2 Limitaciones 23
7.2.1 Disponibilidad del sistema 23
7.2.2 Rendimiento 23
7.3 Suposiciones 23
7.3.1 Acceso a internet 23

Arquitectura
8. Vista de Procesos 23
9. Vista de Datos 23
10. Tamaño y Rendimiento 24
11. Calidad 24
12. Manejo de Errores 25

12.1 Buenas Prácticas 25
12.2 Política del Manejo de Excepciones 25
12.3 Notación y Diagramas para el manejo de excepciones. 26
12.4 Ejemplo del manejo de excepciones 26
13. Consideraciones de Seguridad 26

Arquitectura
Documento de Arquitectura: Aplicación Calendario
1. Introducción
1.1 Propósito
El presente documento provee una visión inicial para la arquitectura de la aplicación Calendario del sistema
myUSB, a través de la utilización de las 4+1 vistas de RUP. De esta manera, se busca capturar y asentar
las decisiones importantes que serán tomadas en el desarrollo de la misma.
1.2 Alcance
Se muestra a alto nivel el diseño de la arquitectura por vistas de la aplicación Calendario. En cada una, se
presentan los diagramas correspondientes, a saber: modelo conceptual, diagrama de clases, casos de uso,
diagramas de interacción, diagrama de componentes, diagrama de paquetes, entre otros.
1.3 Definiciones, Acrónimos y Abreviaturas
Ver Documento de Arquitectura de la Plataforma myUSB. El único concepto importante que cambia es el
de Calendario, que se enuncia a continuación.
1. Calendario
En un calendario se crean eventos y se observan en una tabla que lista los eventos de un mes. Esta tabla
tiene columnas: fecha, descripción, acciones (editar, eliminar). No se representará un calendario con los
días de la semana como columnas. Esta aplicación existe a nivel de estudiante solamente, no a nivel grupal.
1.4 Referencias
Se hace referencia a:
- Documento de Visión.
- Documento de Casos de Uso del sistema myUSB.
- Documento de Arquitectura de la Plataforma.
1.5 Visión General
El presente documento se estructura de la siguiente manera: representación arquitectural, metas y

restricciones de la arquitectura, presentación de las 4+1vistas, tamaño y desempeño del software y finalmente la
calidad del sistema.

Arquitectura
2. Representación Arquitectural
Para esta entrega del documento, se representarán las vistas utilizando los siguientes recursos:
• Vista de Casos de Uso.

A cada uno se le hará una descripción en formato breve para enunciar su Escenario Principal de
Éxito. Se utilizará el Diagrama de Casos de Uso en notación UML.
• Vista Lógica.
Se realizarán varios esquemas a saber: Modelo Conceptual, Diagrama de Clases, Diagrama de
Paquetes, Diagrama de Componentes y Diagramas de Secuencia. Estos permitirán entender el
problema y la solución que se plantea en este Documento de Arquitectura para el caso de la
aplicación Calendario. Se utilizará notación UML y patrones en cada uno de los diagramas.
• Vista de Implementación.
Se explicará la estructura que describe el modelo de implementación de la aplicación, su
composición en capas y cada uno de sus componentes.
• Vista de Despliegue
Se muestra la relación de la aplicación a desarrollar con el hardware requerido para el despliegue
del sistema.
• Vista de Procesos.
Se habla de los procesos, en caso de que existan.
3. Metas de Arquitectura y Restricciones
El desarrollo de @USB está orientado a la elaboración de un software de alta calidad, que sea escalable,
sostenible y que aporte facilidades y entretenimiento a los estudiantes de la Universidad Simón Bolívar.
Las principales metas a nivel de arquitectura son las siguientes:
• Portabilidad: Se desea que el sistema cuente con cualidades que lo hagan totalmente independiente
de la plataforma en la que corre ya sea amd64, IA64, x86, etc. De esta manera, el sistema se hace
accesible para una mayor cantidad de usuarios en la red social de la universidad.
• Performance: El desempeño del sistema debe ser eficiente, es nuestro objetivo que el usuario se
sienta cómodo a la hora de utilizar el sistema y que obtenga respuestas relativamente rápidas y
adecuadas a cada uno de los eventos realizados.
• Usabilidad: El sistema no sólo debe ser útil a nivel de funcionalidad sino también usable, lo que
quiere decir que el diseño debe ser orientado por y para la comodidad del usuario, de manera que
la interfaz sea intuitiva y fácil de manejar, al mismo tiempo que se fomente altamente la
interacción entre ambos. De la misma forma, el usuario debe tener la capacidad de equivocarse y
regresar a un estado seguro en el que se le permita cumplir con su objetivo original sin que se le
haga tedioso o complicado el proceso para llegar a dicho fin.
• Alta disponibilidad: Nuestro objetivo es que todas y cada una de las funcionalidades estén
disponibles las 24 horas al día, de manera tal que el usuario no se sienta limitado o presionado por
restricciones de tiempo.

Arquitectura
En la planificación de este proceso se han encontrado las siguientes restricciones:
a) Restricciones de contenido: debido a que el sistema está basado y propuesto para los estudiantes
de la Universidad Simón Bolívar, el mismo debe estar de acuerdo con el reglamento de la
institución, por lo que ciertos contenidos deben ser excluidos, por ejemplo, no se pueden discutir
temas de carácter ilícito o de índole sexual, ya que éstos van en contra de los principios de la
institución que está siendo representada.
b) Restricciones de tecnología y uso de herramientas de desarrollo: están predefinidos los

instrumentos a utilizar así como también la plataforma tecnológica sobre la que se va a desarrollar
el sistema. @USB será implementado con el uso de JSF y JSP, es por ello que las herramientas
utilizadas estarán determinadas por las funcionalidades ofrecidas por dicho lenguaje.
4. Vista de Casos de Uso
En esta vista se mostrarán los actores del sistema y sus relaciones entre sí, los diagramas de casos de uso y
la lista de los Casos de Usos de la plataforma en formato breve.

Arquitectura
4.1 Actores del Sistema
A continuación se explica el actor de la aplicación Calendario, presentado en la figura anterior:
Actor Descripción
Estudiante de la Universidad Simón Bolívar que tiene
Usuario Registrado
carnet asociado (usbid) y está registrado en el sistema.
4.2 Diagramas de Caso de Uso de la aplicación Calendario

Arquitectura
4.3 Lista de casos de uso en formato breve
4.3.1 Crear Evento
El usuario se posiciona en el recuadro titulado “Agregar Nuevo Evento”. Allí introduce la fecha y
descripción del evento en los campos respectivos, y presiona “Agregar”. Esto hará que el nuevo evento se muestre
en el tope de la lista de eventos del usuario.
4.3.2 Eliminar Evento
El usuario marca el check box de o de los eventos que desea eliminar. Luego hace click en “Eliminar”. El
sistema le pregunta si está seguro que desea eliminar los eventos, el usuario confirma y ocurre la eliminación.
Luego, el usuario podrá ver la lista de eventos, sin los que fueron eliminados.

Arquitectura
4.3.3 Editar Evento
El usuario hace click en el icono al final de la fila que tiene el evento que desea editar. Luego se permite al
usuario modificar la fecha o la descripción del mismo. A continuación, presiona “Actualizar”. Se muestra la lista de
eventos al usuario con las modificaciones hechas.
4.3.4 Ver eventos en un mes dado
El usuario despliega un drop-down list con los meses del año y escoge uno. Realiza el mismo
procedimiento con otro menú que corresponde a los años. Luego presiona “Ver eventos”. El sistema mostrará la lista
de eventos del mes y año escogidos.

Arquitectura
4.3.5 Ver eventos en el mes actual
Este es un link que representa un “shortcut” del sistema que permite llevar al usuario a ver los eventos del
mes actual, sin que tenga que solicitarlo explícitamente utilizando el caso de uso anterior (4.3.5). Con sólo
seleccionar el link, se muestra la lista de eventos del mes y año en curso.
4.3.6 Ver todos los eventos
Cuando el usuario presiona este link, se muestra la lista de todos los eventos de su calendario, sin importar
el mes o año en que hayan sido agregados.

Arquitectura
5. Vista Lógica
En esta primera aproximación a la aplicación Calendario, se propone el siguiente Modelo Conceptual para
comprender y profundizar en el dominio del problema. El mismo explica cuáles son las asociaciones pertinentes
entre los conceptos más relevantes en un nivel abstracto.

Arquitectura
A continuación se muestra el Diagrama de Componentes.

Arquitectura
A continuación, se muestra el Diagrama de Paquetes.

Arquitectura
A continuación se presenta el diagrama de clases correspondiente a la solución propuesta. Describe la

estructura del sistema indicando las sus clases, atributos y relaciones entre las mismas.

Arquitectura
A continuación, se presentan los diagramas de secuencia a alto nivel de los casos de uso:
5.1 Crear Evento
5.2 Eliminar Evento

Arquitectura
5.3 Editar Evento
5.4 Ver eventos en un mes dado

Arquitectura
5.5 Ver eventos en el mes actual
5.6 Ver todos los eventos

Arquitectura
6. Vista de Implementación
Para el desarrollo de la aplicación Calendario se definió una estructuración en capas, con el objetivo de
lograr la independencia entre los distintos componentes. Definir un sistema en capas ofrece numerosas ventajas,
entre ellas:
- Se logra el desarrollo de un programa robusto en que cada componente trabaja correctamente.

- Reutilización de la arquitectura con lo cual se obtiene un sistema flexible a cambios e innovaciones.
- Permite localizar rápidamente los defectos para su efectiva solución.
Para lograr esta serie de objetivos se utilizará JSF, un framework de desarrollo basado en el patrón MVC
(Modelo Vista-Controlador) que permite un manejo adecuado para las tres capas definidas para la aplicación.
6.1 Visión General
En particular, la aplicación Calendario será estructurada en tres capas:
- Capa de Interfaz.
- Capa de Negocio.
- Capa de Datos y Utilidades.
6.2 Capas
A continuación se explican cada una de las capas que conforman la plataforma de @USB.
6.2.1 Capa de Interfaz
La capa de interfaz del usuario cubre muchas bases. Más que un conjunto de estándares para la ubicación
de las unidades gráficas en la pantalla, se envuelven también aspectos de la selección de la tecnología.
Área Productos / Servicios / Componentes
Estilos de Layout y Usabilidad 1. Cada layout que se presenta en las distintas secciones Web presentará un
estilo consistente y será amigable al usuario, de manera que éste pueda
interactuar fácilmente con el sistema.
2. Todas las funcionalidades son utilizadas a través de un navegador web o
browser.
Herramientas de Construcción:
Lenguajes 1. Java Server Pages (JSP) será utilizado como vehículo de presentación
primaria para las soluciones basadas en Java. Es imprescindible para la
generación de la interfaz en las páginas de contenido dinámico.
2.- Java Server Faces (JSF) será utilizado para mantener correspondencia
entre lo presentado en la interfaz y los objetos de la capa de negocio.

Arquitectura
3. JavaScript para pequeñas utilidades.

4. Cascade Styling Sheet (CSS) para definir la presentación de un
documento estructurado escrito en XHTML.
Ambiente de Desarrollo Integrado 1. Adobe Dreamweaver.
2. NetBeans 6.1 con conexión a SVN.
Despliegue de Información Extensible Hypertext Markup Language (XHTML) se empleará para
transmitir la información al usuario.
Componentes:
Presentación de errores a la interfaz Se mostrarán los errores en la página comunicándole al usuario la falla
del usuario ocurrida de una manera entendible para que pueda ser comunicada
fácilmente a un administrador.
6.2.2 Capa de Negocio
En la capa de negocio se deben especificar el lenguaje y las herramientas para la implementación del
sistema. Además, puntualizar patrones y componentes pre-construidos si están disponibles.
Componentes:
Lenguajes Java 1.6.
Ambiente de Desarrollo Integrado NetBeans 6.1 con conexión a SVN.
Uso de Patrones:
A tiempo de corrida la aplicación Patrón de Construcción – Este patrón debe ser utilizado por aquellos
no sabe exactamente qué tipo de recursos creados dinámicamente por la aplicación. Un ejemplo es que el
instancia debe crear. Calendario crea Eventos cuando se agrega un nuevo evento al Calendario.
El sistema requiere comunicarse de Patrón Adaptador – Se necesita comunicación entre las aplicaciones con el
manera efectiva con aplicaciones sistema principal. Mediante este patrón se logra la independencia entre
que proveen distintos servicio para ambas partes y da flexibilidad para poder agregar nuevas aplicaciones en el
el usuario futuro.
Se necesita recorrer colecciones de Patrón Iterador – Este patrón se usa cuando se busca recorrer un conjunto de
objetos para mostrar información elementos sin exponer su representación. Ejemplo: el conjunto de Eventos
sobre ellos en la interfaz. del calendario de un usuario.
Componentes de Servicio:
Enrutamiento de solicitudes desde Cada fachada de los casos de uso se encarga de llamar a los métodos
la interfaz del usuario hasta la capa adecuados de una clase para procesar la solicitud proveniente de la interfaz y
de negocios devolver la información requerida.
Componentes de Acceso a Datos

Arquitectura
Procedimientos almacenados Se debe priorizar la ejecución de procedimientos almacenados.

Transporte de datos Tanto los objetos con valores (atributos) como los objetos de acceso a datos
(objetos que realmente ejecutan sentencias de SQL) deben ser utilizados
siempre que sean necesarios.
6.2.3 Capa de Datos y Utilidades
La capa de datos y utilidades es la última capa, en la que residen todos los datos que deben ser almacenados
de manera persistente.
Componentes:
Lenguajes 1. Java 1.6
2. MySQL.
Se utilizará Hibernate como framework de manejo de Datos.
Conexión Conector JDBC.
Ambiente de Desarrollo Integrado NetBeans 6.1 conexión a servidor GlassFish.
Uso de Patrones:
Cada Caso de Uso representa Patrón de Fachada – Más específicamente, el patrón de diseño de Fachada de
varios caminos de trabajo y el Base de Datos debe ser utilizado. Cada acceso a la Base de Datos debe tener
sistema debe ser altamente un método que funcione como enlace entre la capa de Negocios y la Base de
cohesivo en su implementación Datos.
para facilitar la reutilización.

Arquitectura
7. Vista de Despliegue
A continuación se muestra un diagrama de despliegue que modela, a alto nivel, la distribución de las piezas
de software de la aplicación Calendario sobre los elementos de hardware que se usarán para ejecutarla, indicando las
asociaciones entre nodos con caminos de comunicación, que indican la tecnología requerida para que ésta se lleve a
cabo exitosamente.
En el diagrama podemos ver que para que el cliente pueda visualizar la aplicación Calendario, debe tener
en su máquina un browser, que le permitirá conectarse con el Servidor de la Plataforma myUSB, se conecta con el
Servidor Web donde se encuentra un compilado correspondiente a la aplicación Calendario. Este servidor se conecta
a través de una LAN y usando JDBC al DBServer, que contiene la base de datos del sistema, manejada con MySQL.
También
7.1 Requerimientos
7.1.1 Del usuario
• SO Windows NT/XP/Vista, OS/2, Linux/Unix.

• Conexión a Internet
• Browser con soporte de JavaScript y Flash Player

Arquitectura
7.1.2 Del servidor
• Servidor HTTP GlassFish que soporte JSP 2.0 y JSF 1.0 o superior
• Manejador de Base de Datos relacionales MySQL instalado
7.2 Limitaciones
7.2.1 Disponibilidad del sistema

La disponibilidad dependerá de la calidad y el soporte de alto desempeño de los servidores que sean
asignados para anidar al sistema. Para garantizar una mejor disponibilidad, es posible que haga falta la asignación de
servidores de respaldo en caso de problemas de distinta índole con los servidores originales.
7.2.2 Rendimiento
El sistema está diseñado para ser lo más eficiente posible y dar respuesta relativamente rápidas y adecuadas
a cada uno de los eventos. Es evidente que el rendimiento, a la vista del usuario, está limitado de las especificaciones
de su máquina, además de la capacidad de los servidores asignados al sistema para soportar alta demanda de
usuarios.
7.3 Suposiciones
7.3.1 Acceso a internet

Todos los usuarios tienen acceso al servidor principal a través de internet.
8. Vista de Procesos
Debido a que el sistema para la comunidad estudiantil de la Universidad Simón Bolívar es Web y se cuenta
con un servidor GlassFish, la implementación no requiere de la creación de procesos ni hilos para la ejecución de la
plataforma.
La comunicación entre los hilos y procesos para el manejo de concurrencias y sincronía es transparente
para el sistema y será realizada por el servidor Web.
9. Vista de Datos
El modelo Entidad-Interrelación que del Calendario se muestra a continuación. No se muestran los

atributos para no sobrecargar el esquema.

Arquitectura
La traducción al relacional es la siguiente:
Estudiante (idPerfil, nombre, apellido, url_foto)
Estudiante
Evento (idEvento, fecha, nombre, descripción, idPerfil)
El diccionario de datos de la traducción se indica a continuación:
1. Estudiante:
Campo Tipo Nulo Default Enlaces a Comentarios

idPerfil varchar(32) No Identificador del perfil
Nombre varchar(64) Sí Nombre del estudiante
Apellido varchar(32) Sí Apellido del estudiante
url_foto varchar(128 Sí Foto del estudiante
)
2. Evento
Campo Tipo Nulo Default Enlaces a Comentarios

idEvento Int No Identificación del evento
Fecha Date No Fecha del evento
Nombre varchar(64) No Nombre del evento
Descripción varchar(128) Sí Descripcion del evento
idPerfil varchar(32) No Estudiante->idPerfil Identificador del perfil
10. Tamaño y Rendimiento
Una característica a tomar en cuenta para dimensionar el sistema es que éste se encuentra limitado a los
estudiantes de la Universidad Simón Bolívar, lo que restringe su tamaño y su curva de crecimiento, pues la entrada
de estudiantes cada año es limitada.
En cuanto al rendimiento del sistema, los tiempos de carga y descarga de páginas deben mantenerse lo más
bajo posible para incentivar el uso del programa. No debe ocurrir que el tiempo para cargar la página expire.
11. Calidad
La arquitectura del software se ha diseñado para ser independiente de la plataforma en la que el sistema se
utilice. Esto le ofrece al sistema la capacidad de ser portable.
El sistema será desarrollado por capas, de manera que las capas más superficiales como la de interfaz no
afectarán a la capa lógica del sistema. Cada capa se comunicará con las capas que estén directamente por encima o
por debajo de ellas, no existirán saltos de acceso entre capas de manera tal que se mantenga una eficiente
comunicación entre ellas.

Arquitectura
12. Manejo de Errores
En el desarrollo de un sistema es importante crear una buena política de manejo de errores de tal manera
que se cubran la mayoría de los posibles casos de mal funcionamiento durante el uso de todas las funciones que
ofrece el sistema. Además, la información que puede ofrecer una buena política de manejo de excepciones es muy
valiosa a la hora de depurar el sistema y por lo tanto, el mantenimiento puede simplificarse a gran escala.
12.1 Buenas Prácticas
Para el manejo de errores se seguirán las siguientes prácticas:
- Encapsulamiento: en el caso de que una excepción viaje a través de las capas del sistema y se cree alguna
otra a partir de la primera generada, se guarda toda la información del primer error a través del
encapsulamiento en el momento de la creación de la nueva excepción. De esta forma, no se pierde
información debido a la propagación de la excepción o de la sustitución a través de las capas del sistema.
- Lanzar temprano: las excepciones son lanzadas en el preciso instante en el que ocurre el error. Así se tiene
un mejor control a la hora de depurar y de buscar el origen de la falla.
- Atrapar tarde: las excepciones se atraparán cuando se tenga la mayor cantidad de información posible y
cuando se esté en la capa correspondiente del sistema que tenga las herramientas necesarias para manejar
correctamente el error.
- Obtener y desplegar la mayor cantidad de información : a la hora de generar un error, la mayor cantidad de
información debe ser desplegada de tal manera que se pueda ubicar fácilmente el origen y por lo tanto, se
depure rápidamente el sistema.
12.2 Política del Manejo de Excepciones
Para el manejo de errores se definirá una gran variedad de clases (excepciones) para el control de todos los
casos posibles de fallo. Para capa del sistema aplica una política distinta que permitirá que las excepciones puedan
manejar la mayor cantidad de errores.
Capa de Datos y Utilidades

En esta capa se utilizará una política de Propagación y de encapsulado de excepción. Esto tendrá
como consecuencia que la información del error ocurrido no se pierda y se transmita lo más posible a través
de su viaje por las capas del sistema.
Capa Lógica
Para la capa lógica se aplicará una política de sustitución y encapsulamiento. Se sustituye la
excepción proveniente de la capa inferior de tal manera que se cree alguna otra más específica a la causa
del error y que, por consiguiente, brinde información más específica a la capa superior.
Capa de Presentación e Interfaz

En la capa de interfaz se aplicará la política de manejo de errores. En esta capa del sistema se
realizará el manejo de todas las excepciones provenientes de las capas inferiores y se desplegará al usuario
la información necesaria acerca del error ocurrido.
En el caso de las aplicaciones, las clases encargadas de la comunicación con las mismas tendrán la

Arquitectura
responsabilidad de sustituir y encapsular las excepciones consideradas para el caso. Las políticas aplicadas en este
caso serán las mismas que las aplicadas para la capa lógica.
12.3 Notación y Diagramas para el manejo de excepciones.
Para representar el manejo de errores a medida que se desarrolle el sistema usaremos el siguiente tipo de
diagrama propuesto en UML 2:
12.4 Ejemplo del manejo de excepciones
• Descripción: Ocurre un error durante la introducción de datos al repositorio.

• Tipo: Exception.
• Lanzada desde: Capa de Persistencia
• Política por capa o componente:
o Capa de Persistencia: Se recibe una excepción de tipo SQLException y se encapsula dentro de

una excepción de tipo DataLayerException que se lanza a la capa de Negocios.
o Capa de Negocios: Se recibe una excepción de tipo DataLayerException, se propaga y se

reemplaza por una excepción de tipo IntroduccionDatosException que se transfiere a la Capa de
Interfaz.
o Capa de Interfaz: Se atrapa una excepción de tipo IntroduccionDatosException y se hace manejo

de la misma, ya sea por medio de un mensaje de error amigable, o alguna implementación de
código.
13. Consideraciones de Seguridad
Categorí Integridad – Modificación, Borrado, Validación de Data.

a Confidencialidad – Autenticación
Problem Un ataque de SQL Injection usando los campos de entrada, podría
a permitir a un atacante agregar, modificar o eliminar registros de
la base de datos. También podría permitirle acceder al sistema
con credenciales que no posee.
Acción Verificar los datos de entrada para escapar o eliminar caracteres
especiales (ej. ; ‘ ’ -- ) y usar la clase PreparedStatement de Java

Arquitectura
para realizar las consultas SQL.
Categorí Integridad – Validación de Data

a
Problem Un atacante podría colocar valores muy grandes en los campos de
a entrada con la intención de causar un overflow en el sistema y
negar los servicios.
Acción Colocar límite superior e inferior a los campos de entrada, por
ejemplo, la descripción de un evento no puede superar los 250
caracteres.
Categorí Disponibilidad – Asignación de Recursos

a
Problem Un atacante puede intentar crear muchos eventos para consumir
a todos los recursos del sistema
Acción No se permitirá crear más de 100 eventos. Cualquier otro evento
que se intente crear borrará al más antiguo del resto.
Categorí Integridad – Manejo de Excepciones

a
Problem Errores muy descriptivos que se muestren al usuario pueden darle
a información sobre el sistema que puede ser usada para atacarlo.
Acción Mantener una política de manejo de errores que dé mensajes
amigables al usuario que indiquen sólo lo que debe saber sobre el
error ocurrido.
Categorí Integridad – Manejo de Excepciones

a
Problem El sistema no puede acceder al servidor de bases de datos y
a terminar abruptamente
Acción Mantener una política de manejo de errores que capture esa
excepción e indique lo ocurrido de forma amigable
Categorí Disponibilidad – Tiempo de Respuesta

a
Problem El sistema tiene estar disponible 24/7 y los tiempos de respuesta
a tienen que ser bajos.
Acción Implementaciones eficientes con un servidor dedicado a la
aplicación. Podría pensarse en colocar servidores de backup

Documento Arquitectura Calendario

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Documento Arquitectura Calendario

Caricato da

Copyright:

Formati disponibili

myUSB

Confidencial myUSB, 2010 Página 2 de 27

3. Metas de Arquitectura y Restricciones 6

4. Vista de Casos de Uso 7

Confidencial myUSB, 2010 Página 3 de 27

10. Tamaño y Rendimiento 24

12. Manejo de Errores 25

13. Consideraciones de Seguridad 26

Confidencial myUSB, 2010 Página 4 de 27

Documento de Arquitectura: Aplicación Calendario

1.3 Definiciones, Acrónimos y Abreviaturas

1.5 Visión General

El presente documento se estructura de la siguiente manera: representación arquitectural, metas y

Confidencial myUSB, 2010 Página 5 de 27

• Vista de Casos de Uso.

3. Metas de Arquitectura y Restricciones

Las principales metas a nivel de arquitectura son las siguientes:

Confidencial myUSB, 2010 Página 6 de 27

En la planificación de este proceso se han encontrado las siguientes restricciones:

b) Restricciones de tecnología y uso de herramientas de desarrollo: están predefinidos los

4. Vista de Casos de Uso

Confidencial myUSB, 2010 Página 7 de 27

4.1 Actores del Sistema

A continuación se explica el actor de la aplicación Calendario, presentado en la figura anterior:

4.2 Diagramas de Caso de Uso de la aplicación Calendario

Confidencial myUSB, 2010 Página 8 de 27

4.3 Lista de casos de uso en formato breve

4.3.1 Crear Evento

4.3.2 Eliminar Evento

Confidencial myUSB, 2010 Página 9 de 27

4.3.3 Editar Evento

4.3.4 Ver eventos en un mes dado

Confidencial myUSB, 2010 Página 10 de 27

4.3.5 Ver eventos en el mes actual

4.3.6 Ver todos los eventos

Confidencial myUSB, 2010 Página 11 de 27

Confidencial myUSB, 2010 Página 12 de 27

A continuación se muestra el Diagrama de Componentes.

Confidencial myUSB, 2010 Página 13 de 27

A continuación, se muestra el Diagrama de Paquetes.

Confidencial myUSB, 2010 Página 14 de 27

A continuación se presenta el diagrama de clases correspondiente a la solución propuesta. Describe la

Confidencial myUSB, 2010 Página 15 de 27

5.1 Crear Evento

5.2 Eliminar Evento

Confidencial myUSB, 2010 Página 16 de 27

5.3 Editar Evento

5.4 Ver eventos en un mes dado

Confidencial myUSB, 2010 Página 17 de 27

5.5 Ver eventos en el mes actual

5.6 Ver todos los eventos

Confidencial myUSB, 2010 Página 18 de 27

- Se logra el desarrollo de un programa robusto en que cada componente trabaja correctamente.

6.1 Visión General

En particular, la aplicación Calendario será estructurada en tres capas:

6.2.1 Capa de Interfaz

Área Productos / Servicios / Componentes

Confidencial myUSB, 2010 Página 19 de 27

3. JavaScript para pequeñas utilidades.

6.2.2 Capa de Negocio

Área Productos / Servicios / Componentes

Confidencial myUSB, 2010 Página 20 de 27

Procedimientos almacenados Se debe priorizar la ejecución de procedimientos almacenados.