Está en la página 1de 18

Grupo @USB @USB Documento de Arquitectura de Software

Versin <1.0>

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

Historia de Revisin
Fecha 14-05-2008 Versin 1.0 Descripcin Primera versin del Documento de Arquitectura para la aplicacin Cuaderno del sistema @USB Autor Maribel Acosta Beatriz Avila Alexander Bustamante Cristiam Da Silva Zinahia Querales Luis Serrano Alberto Quirs

Confidencial

Grupo @USB, 2013

Pgina 2 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

Tabla de Contenidos
1. Introduccin 2. Representacin Arquitectural 3. Metas de Arquitectura y Restricciones 4. Vista de Casos de Uso 5. Vista Lgica 6. Vista de Implementacin 7. Vista de Despliegue 8. Vista de Procesos 9. Vista de Datos 10. Tamao y Rendimiento 11. Calidad 12. Manejo de Errores 4 5 5 6 7 12 16 17 17 17 17 17

Confidencial

Grupo @USB, 2013

Pgina 3 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

Documento de Arquitectura de Softwaren Cuaderno


1.
1.1

Introduccin
Propsito El presente documento provee una visin inicial para la arquitectura de la aplicacin Cuaderno en el sistema @USB, a travs de la utilizacin de las 4+1 vistas de RUP. De esta manera, se busca capturar y asentar las decisiones importantes que sern tomadas en el desarrollo de la aplicacin. Alcance Se muestra a alto nivel el diseo de la arquitectura por vistas de la aplicacin. En cada una, se presentan los diagramas correspondientes, a saber: modelo conceptual, diagrama de clases, casos de uso, diagramas de interaccin, entre otros. Definiciones, Acrnimos y Abreviaturas 1. Cuaderno Espacio del sistema @USB que posee cada estudiante registrado en el sistema. Todos los estudiantes registrados pueden escribir en cualquier cuaderno. 2. Estudiante No Registrado Estudiante de la USB que an no est registrado en el sistema. 3. Estudiante Registrado Trmino utilizado para referirse a aquellos estudiantes que tienen acceso al sistema y que pueden utilizar su plataforma y aplicaciones. 4. Grupo Conjunto de usuarios registrados que se renen para compartir informacin sobre algn tema comn de inters. Posee un cuaderno. 5. Perfil Seccin de la cuenta de cada usuario donde aparecen sus datos personales, foto y el cuaderno.

1.2

1.3

1.4

Referencias Se hace referencia a los documento de Visin, de Casos de Uso y de Arquitectura del sistema @USB.

1.5

Visin General El presente documento se estructura de la siguiente manera: representacin arquitectural, metas y restricciones de la arquitectura, presentacin de las 4+1vistas, tamao y desempeo del software y finalmente la calidad del sistema.

Confidencial

Grupo @USB, 2013

Pgina 4 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

2.

Representacin Arquitectural
Para esta entrega del documento, se representarn las vistas utilizando los siguientes recursos: Vista de Casos de Uso. A cada uno se le har una descripcin en formato breve para enunciar su Escenario Principal de xito. Se utilizar el Diagrama de Casos de Uso en notacin UML. Vista Lgica. Se realizar el Modelo Conceptual de la aplicacin Cuaderno, que permita comprender el dominio del problema, utilizando la notacin UML. Adems, se desarrollar la primera versin del Diagrama de Clases de la aplicacin para representar el dominio de la solucin, utilizando tambin la notacin UML y patrones. Vista de Implementacin. Se explicar la estructura que describe el modelo de implementacin de la aplicacin, su composicin en capas y cada uno de sus componentes. Vista de Despliegue Se muestra la relacin de la aplicacin a desarrollar con el hardware requerido para el despliegue del sistema. Vista de Procesos. Se habla de los procesos (si existen). Vista de Datos. Se mostrar el Diagrama Entidad-Relacin, la traduccin al Relacional y el Diccionario de Datos del Relacional.

3.

Metas de Arquitectura y Restricciones

El desarrollo de la aplicacin se enfoca en que llegue a tener caractersticas que sean sostenibles, eficientes y fciles de usar para cualquier usuario del sistema @USB Nuestras principales metas a nivel de arquitectura son las siguientes: Performance: El desempeo de la aplicacin debe ser muy eficiente de tal manera el usuario inmediato y todos los dems observen lo ms rpidamente posible los cambios realizados en un momento determinado. Usabilidad: El diseo debe ser orientado por y para la comodidad del usuario, de manera que la interfaz sea intuitiva y fcil de manejar, al mismo tiempo que se fomente altamente la interaccin 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.

En la planificacin de este proceso hemos encontrado las siguientes restricciones:

Confidencial

Grupo @USB, 2013

Pgina 5 de 18

@USB Documento de Arquitectura de Software Arquitectura a)

Versin: <1.0> Fecha: <14/04/2008>

Restricciones de contenido: debido a que nuestro sistema est basado y propuesto para aquellos que pertenecen a la institucin educativa de la Universidad Simn Bolvar, el mismo debe estar de acuerdo con el reglamento de la institucin, por lo que ciertos contenidos deben ser excluidos en el uso de la aplicacin. Por ejemplo, no se pueden discutir temas de carcter ilcito o de ndole sexual, ya que stos van en contra de los principios de la institucin que est siendo representada.

b) Restricciones de tecnologa y uso de herramientas de desarrollo: estn predefinidos los instrumentos a utilizar as como tambin la plataforma tecnolgica sobre la que se va a desarrollar el sistema. La aplicacin ser implementada usando JSP, es por ello que las herramientas utilizadas estarn determinadas por las funcionalidades ofrecidas por dicho lenguaje.

4.

Vista de Casos de Uso


En esta vista se mostrarn la lista de los Casos de Usos crticos de la aplicacin Cuaderno.

4.1

Agregar comentario a Cuaderno.

El usuario debe estar en el perfil del estudiante o el grupo donde desea dejar su comentario. A continuacin, se posiciona en el rea predefinida para que pueda escribir su mensaje. Lo escribe y, al finalizar, presiona el botn Publicar. El sistema agregar dicho mensaje a la lista de comentarios perteneciente al dueo del perfil o al grupo, y luego aparecer en el tope del Cuaderno.

4.2

Eliminar comentario de Cuaderno.

El usuario debe encontrarse en el Cuaderno de donde quiere borrar su comentario. All, selecciona la opcin Borrar que se encuentra arriba de mensaje a eliminar (en caso de no estar este botn, el mensaje no le pertenece, as que no puede borrarlo). El sistema se encarga de suprimirlo de los registros y luego lo desaparece de la posicin en la que se encontraba en el Cuaderno, ajustando los mensajes que quedaron, si existe alguno. Es posible que un estudiante pueda borrar cualquier comentario hecho en su propio perfil. Confidencial Grupo @USB, 2013 Pgina 6 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

4.3

Eliminar comentario de Cuaderno.

5.

Vista Lgica

Como propuesta, se tiene el siguiente Modelo Conceptual para cules son las asociaciones pertinentes entre los conceptos ms relevantes para la aplicacin Cuaderno.

Confidencial

Grupo @USB, 2013

Pgina 7 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

A continuacin se muestra el Diagrama de Componentes.

Confidencial

Grupo @USB, 2013

Pgina 8 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

A continuacin, se muestra el Diagrama de Paquetes.

Confidencial

Grupo @USB, 2013

Pgina 9 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

A continuacin se presenta el diagrama de clases.

Confidencial

Grupo @USB, 2013

Pgina 10 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

Confidencial

Grupo @USB, 2013

Pgina 11 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

6.

Vista de Implementacin

Para el desarrollo de la aplicacin Cuaderno se defini una estructuracin en capas para su implementacin pues se logra independencia entre los distintos componentes. Su definicin en capas ofrece numerosas ventajas, entre ellas: 6.1 Se logra el desarrollo de un programa robusto en que cada componente trabaja correctamente. Reutilizacin de la arquitectura con lo cual se obtiene un sistema flexible a cambios e innovaciones. Permite localizar rpidamente los defectos para su efectiva solucin. Visin General En particular, la aplicacin Cuaderno estar estructurada en tres capas: Capa de Interfaz. Capa de Negocio.

6.2

Capa de Datos y Utilidades. Capas A continuacin se explican cada una de las capas que conforman la aplicacin.

Confidencial

Grupo @USB, 2013

Pgina 12 de 18

@USB Documento de Arquitectura de Software Arquitectura 6.2.1 Capa de Interfaz

Versin: <1.0> Fecha: <14/04/2008>

La capa de interfaz del usuario cubre muchas bases. Ms que un conjunto de estndares para la ubicacin de las unidades grficas en la pantalla, se envuelven tambin aspectos de la seleccin de la tecnologa.

rea Estilo de Layout y Usabilidad

Productos / Servicios / Componentes 1. El layout que se presentar para la aplicacin presentar un estilo consistente y ser amigable al usuario, de manera que se facilite la interaccin. La aplicacin se utilizar a travs del sistema @USB mediante un navegador Web o Browser.

2. Herramientas de Construccin: Lenguajes Ambiente de Desarrollo Integrado Despliegue de Informacin Componentes: Presentacin de errores a la interfaz del usuario 1. 1. 1. 1.

PHP. Es imprescindible para la generacin de la interfaz en las pginas de contenido dinmico. Adobe Dreamweaver. Extensible Hypertext Markup Language (XHTML) se emplear para transmitir la informacin al usuario.

Se mostrarn los errores en la pgina comunicndole al usuario la falla ocurrida de una manera entendible para que pueda ser comunicada fcilmente a un administrador.

Confidencial

Grupo @USB, 2013

Pgina 13 de 18

@USB Documento de Arquitectura de Software Arquitectura 6.2.2 Capa de Negocio

Versin: <1.0> Fecha: <14/04/2008>

En la capa de negocio se deben especificar el lenguaje y las herramientas para la implementacin del sistema. Adems, puntualizar patrones y componentes pre-construidos si estn disponibles.

rea Componentes: Lenguajes Ambiente de Desarrollo Integrado Uso de Patrones: A tiempo de corrida la aplicacin no sabe exactamente qu tipo de instancia debe crear. Cada Caso de Uso representa varios caminos de trabajo y el sistema debe ser altamente cohesivo en su implementacin para facilitar la reutilizacin. La presentacin externa de la informacin vara, as que la dependencia entre las formas de mostrar la informacin y de almacenarla debe ser poca. Componentes de Servicio: Enrutamiento de solicitudes desde la interfaz del usuario hasta la capa de negocios Componentes de Acceso a Datos Procedimientos almacenados Transporte de datos

Productos / Servicios / Componentes

1. 1.

Java 1.6. Eclipse Classic 3.3.2 con conexin a SVN.

1.

Patrn de Construccin Este patrn debe ser utilizado por aquellos recursos creados dinmicamente por la aplicacin. Patrn de Fachada Ms especficamente, el patrn de diseo de casos de uso debe ser utilizado. Cada caso de uso debe tener su correspondiente clase fachada para comunicarse con la capa de interfaz. Todos los casos de uso deben utilizar una arquitectura para separar el formato de la informacin de la forma en la cual est almacenada y en la forma en que se relaciona con los dems objetos.

1.

1.

1.

Cada fachada de los casos de uso se encarga de llamar a los mtodos adecuados de una clase para procesar la solicitud proveniente de la interfaz y devolver la informacin requerida.

1. 1.

Se debe priorizar la ejecucin de procedimientos almacenados. 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.

Confidencial

Grupo @USB, 2013

Pgina 14 de 18

@USB Documento de Arquitectura de Software Arquitectura 6.2.3 Capa de Datos y Utilidades

Versin: <1.0> Fecha: <14/04/2008>

La capa de datos y utilidades es la ltima capa, en la que residen todos los datos que deben ser almacenados de manera persistente.

rea Componentes: Lenguajes

Productos / Servicios / Componentes

1. Java 1.6 2. MySQL.

Conexin Ambiente de Desarrollo Integrado Uso de Patrones: Cada Caso de Uso representa varios caminos de trabajo y el sistema debe ser altamente cohesivo en su implementacin para facilitar la reutilizacin.

1. Conector JDBC. 1. Eclipse Classic 3.3.2 con conexin a servidor Tomcat.

1. Patrn de Fachada Ms especficamente, el patrn de diseo de Fachada de Base de Datos debe ser utilizado. Cada acceso a la Base de Datos debe tener un mtodo que funcione como enlace entre la capa de Negocios y la Base de Datos.

Confidencial

Grupo @USB, 2013

Pgina 15 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

7.

Vista de Despliegue

A continuacin se muestra un diagrama de despliegue que modela, a alto nivel, la distribucin de las piezas de software de la aplicacin Cuaderno sobre los elementos de hardware que se usarn para ejecutarla, indicando las asociaciones entre nodos con caminos de comunicacin, que indican la tecnologa requerida para que sta se lleve a cabo exitosamente.

En el diagrama se observa que un cliente visualiza el sitio @USB a travs de un navegador en su mquina y una conexin a Internet. Por consiguiente, la visualizacin de la aplicacin Cuaderno se realiza por la misma va. El cliente se conecta con el WebServer, que contiene Cuaderno.jar, un compilado de todos los elementos necesarios para el despliegue de la aplicacin. El servidor se conecta a travs de una LAN y usando JDBC al DBServer, que contiene la base de datos del sistema, manejada con MySQL.

Confidencial

Grupo @USB, 2013

Pgina 16 de 18

@USB Documento de Arquitectura de Software Arquitectura

Versin: <1.0> Fecha: <14/04/2008>

8.

Vista de Procesos

Debido a que la aplicacin Cuaderno es utilizada por el sistema Web @USB y se cuenta con un servidor Apache Tomcat. La implementacin no requiere de la creacin de procesos ni hilo. La comunicacin entre los hilos y procesos para el manejo de concurrencias y sincrona es transparente para el sistema y ser realizada por el servidor Web.

9.

Vista de Datos
A continuacin se muestra el Diagrama Entidad-Relacin para manejar los datos del sistema.

10.

Tamao y Rendimiento

La aplicacin no demanda una gran cantidad de espacio, sin embargo, se tiene que tomar en cuenta la cantidad de usuarios que van a hacer uso de ella. Por defecto, cada usuario dispone de un cuaderno automticamente una vez registrado en el sistema. Podra requerirse un mximo de entradas en el Cuaderno de tal manera que se tenga un lmite de almacenamiento. En cuanto al rendimiento del sistema, los tiempos de carga y descarga de documentos deben mantenerse lo ms bajo posible para incentivar el uso de la pgina. No debe ocurrir que el tiempo para cargar la pgina expire.

11.

Calidad

La arquitectura del software se ha diseado para ser independiente de la plataforma en la que el sistema se utilice. Ya que esto ofrece al sistema la capacidad de ser portable, la aplicacin Cuaderno se beneficia por igual de esta portabilidad. La aplicacin estar desarrollada por capas, de manera tal que las capas ms superficiales como la de interfaz no afectarn a la capa lgica. Cada capa se comunicar con las capas que estn directamente por debajo de ellas. No existirn saltos de acceso entre capas de manera tal que se mantenga una eficiente comunicacin entre ellas.

12.

Manejo de Errores

En el desarrollo de un sistema es importante crear una buena poltica de manejo de errores de tal manera que se cubran la mayora de los posibles casos de mal funcionamiento durante el uso de todas las funciones que ofrece el sistema. Adems, la informacin que puede ofrecer una buena poltica 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.

Confidencial

Grupo @USB, 2013

Pgina 17 de 18

@USB Documento de Arquitectura de Software Arquitectura 12.1 Buenas Prcticas Para el manejo de errores se seguirn las siguientes prcticas: -

Versin: <1.0> Fecha: <14/04/2008>

Encapsulamiento: en el caso de que una excepcin viaje a travs de las capas del sistema y se cree alguna otra a partir de la primera generada, se guarda toda la informacin del primer error a travs del encapsulamiento en el momento de la creacin de la nueva excepcin. De esta forma, no se pierde informacin debido a la propagacin de la excepcin o de la sustitucin a travs 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 atraparn cuando se tenga la mayor cantidad de informacin 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 informacin : a la hora de generar un error, la mayor cantidad de informacin debe ser desplegada de tal manera que se pueda ubicar fcilmente el origen y por lo tanto, se depure rpidamente el sistema Poltica del Manejo de Excepciones La poltica de manejo de errores en el sistema @USB se definir por capas. Para cada capa aplica una poltica distinta que permitir que las excepciones que permitan manejar la mayor cantidad de errores del sistema en general. Capa de Datos y Utilidades En esta capa se utilizar una poltica de Propagacin y de encapsulado de excepcin. Esto tendr como consecuencia que la informacin del error ocurrido no se pierda y se transmita lo ms posible a travs de su viaje por las capas del sistema. Capa Lgica Para la capa lgica se aplicar una poltica de sustitucin y encapsulamiento. Se sustituye la excepcin proveniente de la capa inferior de tal manera que se cree alguna otra ms especfica a la causa del error y que, por consiguiente, brinde informacin ms especfica a la capa superior. Capa de Presentacin e Interfaz En la capa de interfaz se aplicar la poltica 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 informacin necesaria al error ocurrido.

12.2

Confidencial

Grupo @USB, 2013

Pgina 18 de 18

También podría gustarte