SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA

Transcripción

1 SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA PARA INARGOS LTDA. DOCUMENTO DE ARQUITECTURA DE SOFTWARE VERSIÓN 3.0 BOGOTÁ, COLOMBIA, MARZO DE 2012

2 TABLA DE CONTENIDO 1 Introducción Propósito Alcance Representación Arquitectónica Diagrama de contexto Estilo Arquitectónico Modelo Arquitectónico Seguridad Usuarios Principales y Roles Autenticación y Autorización Patrones Cliente/Servidor Modelo Vista Controlador Facade Service Locator Vista de Escenarios Vista Lógica Descripción Vista Lógica Vistas Rangos de calidad... 13

3 1 INTRODUCCIÓN En este documento de arquitectura se definen los elementos más significativos de la arquitectura a través de las 4+1 vistas de Kruchten: Escenarios, Lógica, Procesos, Implementación y Física. La arquitectura documentada y especificada en este documento representa la solución del sistema de administración de materiales de tubería (AMT). Para definir la arquitectura y llegar a una solución que estuviera fielmente alineada con los procesos de negocio, los requerimientos funcionales y los atributos de calidad, el grupo siguió una metodología de desarrollo tipo top-down, más específicamente nos basamos en el escrito de Buschmann, Building Software with Patterns. (Buschmann, 2000), el escrito define patrones y diferentes etapas de desarrollo las cuales se siguieron lo mas alineado posible. 1.1 PROPÓSITO El objetivo es claro, describir la arquitectura de software que compone el sistema de administración de materiales de tubería (AMT). Además de las 5 vistas que propone Kruchten se agrega la vista de datos para especificar detalles de persistencia. Por otro lado, cada una de las vistas debe estar documentada en su totalidad. El documento es bastante técnico y necesita de ciertos conocimientos para comprenderlo en su totalidad. Finalmente dentro del documento se le da real importancia a la metodología usada para concebir la arquitectura, los estilos arquitectónicos que se analizaron y los patrones que finalmente componen el diseño. Cualquier diseño tipo ad-hoc también será documentado en su totalidad. 1.2 ALCANCE Dentro del alance podemos incluir todas las consideraciones de diseño, las metas y restricciones arquitectónicas. También se describen los patrones que se usaron en el diseño de la arquitectura y cómo se relacionan entre sí, y con los más elementos del sistema. Finalmente se explica cómo se pretende cumplir con los atributos de calidad y cómo se ven impactados por los diferentes elementos del diseño. En este documento no se entregan avances de implementación o diseño de bajo nivel o detallado relacionados con algún lenguaje específico.

4 2 REPRESENTACIÓN ARQUITECTÓNICA 2.1 DIAGRAMA DE CONTEXTO A continuación se presenta el diagrama de contexto donde se representan todos los elementos que interactúan de una u otra forma con el sistema. Se entiende por elemento cualquier persona, organización o sistema que hace parte del entorno del sistema AMT.

5 2.2 ESTILO ARQUITECTÓNICO El estilo principal que se va a manejar dentro de la aplicación es cliente servidor. Es un modelo de componentes independientes, en donde los datos y el procesamiento son distribuidos en un conjunto de componentes: servidores y clientes. Es un estilo probado y tiene grandes ventajas: El servidor es independiente de los clientes. Uso eficiente de los sistemas de red Este estilo arquitectónico se aplicará usando Java Empresarial 6.

6 2.3 MODELO ARQUITECTÓNICO Para representar la arquitectura del sistema AMT nos basaremos en el modelo de 4+1 vistas, el cual se encuentra comprendido en 5 vistas, que permiten poder ver las funcionalidad y características del sistemas, estas vistas son la de escenarios, la lógica, la de implementación, la de procesos y la de despliegue. Adicionalmente utilizaremos una vista de datos para representar los datos que se van a manejar en la base de datos interna de la aplicación. Vista de escenarios Vista lógica Esta vista será la primera en desarrollarse y permitirá poder ver las funcionalidades que debe cumplir el sistema. Se utilizará UML 2.0 para poder representarlos y los escenarios más representativos tendrán un diagrama de secuencia. Esta vista mostrara los servicios que deberá prestar el sistema, de igual manera mostrar la organización lógica de los paquetes dentro del sistema y la dependencia entre estos paquetes. De igual manera también se usará UML 2.0 Vista de implementación Esta vista se desarrollara con base en la vista lógica y tendrá como objetivo mostrar la descomposición por componentes del sistema y la responsabilidad que cada uno de estos tiene, se utilizará UML 2.0 para representarlo. Vista de procesos Esta vista se desarrollara con base en la vista lógica y mostrará los procesos que se encuentran en el sistema, cómo sería su interacción, su comunicación, los protocolos que van a usar y analizar la concurrencia entre los mismos.

7 Vista Física Esta vista se desarrollará con base en las vistas de proceso y de implementación para poder describir el despliegue de los diferentes procesos en las maquinas donde estarán ubicadas y mostrar la forma de comunicarse entre ellas. Vista de datos Esta vista se mostrará la disposición de los datos dentro del sistema en las bases de datos y se represento mediante un diagrama de entidad relación.

8 2.4 SEGURIDAD La seguridad es un tema que siempre se debe considerar en las aplicaciones empresariales de una u otra forma. Puede ir desde tener seguridad en las redes, cifrar información antes de transferirla, hasta otorgar permisos de los usuarios al sistema. En internet nos encontramos con temas de seguridad todo el tiempo, por lo general es necesario ingresar códigos, nombres de usuario, contraseña y verificaciones. La seguridad se ha convertido en una necesidad en los temas web, sobre todo en ambientes con gran cantidad de usuarios e información importante. La edición empresarial 6 de Java ha definido muchos mecanismos para asegurar las aplicaciones. Antes de hablar de temas de seguridad es fundamental tener los conceptos claros. Es necesario comprender cómo se mapean los usuarios son mapeados a un principal y cada uno puede tener varios roles. Cada uno de esos roles le otorgará permisos a un conjunto de recursos. Para que un usuario tenga una identidad en el sistema, el usuario debe autenticarse mediante un procedimiento específico, luego la plataforma puede controlar el acceso de ese usuario autorizándolo a una serie de recursos dependiendo de sus credenciales de autenticación USUARIOS PRINCIPALES Y ROLES Un usuario principal representa un usuario del sistema que ha sido autenticado usando un sistema de autenticación, en este caso el proceso de autenticación se llevará a cabo revisando nombre de usuario y contraseña. Cada empleado de Inargos Ltda. tendrá un usuario para acceder al sistema. El diagrama a continuación muestra los roles que tendrá cada tipo de empleado o usuario del sistema AUTENTICACIÓN Y AUTORIZACIÓN Como se ha venido mencionando la seguridad envuelve dos funciones: autenticación y autorización. Autenticación es el proceso de verificar las credenciales del usuario (usuario, contraseña, OpenId, huella digital, etc.) contra un sistema de autenticación. Autorización es el proceso que determina si un

9 usuario autenticado tiene acceso a un recurso particular. Dependiendo del rol, el usuario puede acceder, visualizar o modificar los recursos específicos. Dentro del prototipo funcional se definieron cuatro grandes módulos importantes: Módulo de Clientes Módulo de Materiales Módulo de Proyectos Módulo de Administración. El siguiente diagrama los diferentes permisos que tiene cada rol. El diagrama sólo muestra los módulos para el primer prototipo funcional. El administrador puede acceder a toda la funcionalidad y también tiene acceso a temas de administración, como nombres de usuario, cambios de contraseña, modificación de permisos y credenciales (esta parte forma parte del diseño del primero prototipo pero no hace parte del alcance de la implementación). Finalmente, los roles principales: director, ingeniero y auxiliar tienen completo acceso a los módulos más importantes de este primer prototipo funcional: clientes, materiales y proyectos.

10 2.5 PATRONES CLIENTE/SERVIDOR El estilo arquitectónico predominante en el sistema es cliente servidor, esta familia fue escogida debido a que se determino que el sistema necesita confiabilidad, debido a las grandes exigencias que debe soportar el sistema por la cantidad de usuarios y trabajo colaborativo que necesita la compañia. Este estilo arquitectónico tiene como gran ventaja que es fácilmente escalable y permite poder actualizar los servidores o agregar nuevos al sistema sin tener consecuencias traumáticas sobre el mismo y sin erosionar la arquitectura MODELO VISTA CONTROLADOR Este patrón lo usamos para darle la estructura a cada uno de los módulos de las aplicaciones usada dentro del sistema. Este patrón permite que cada una de las aplicaciones tenga su control, sepa manejar las peticiones que reciba, mandarla al modelo, donde será procesada y la respuesta será mostrada a través de la vista, para implementar este patrón es necesario usar el patrón Observer, de tal forma que cualquier cambio en el modelo es reflejado en la vista. Ayuda a separar las funcionalidades del sistema y permite ayudar a tener un sistema interactivo y agradable para el usuario lo que está actualmente en el modelo FACADE Este patrón lo usamos en el modelo de los módulos de las aplicaciones para bajar el acoplamiento entre el control y el modelo, de tal forma que solo hay un punto de entrada entre las dos capas. Este patrón nos permite tener ayudar a generar una mantenibilidad y extensibilidad en la arquitectura debido a que las interfaces quedan bien definidas y los componentes internos pueden variar sin causar cambios en cascada en la arquitectura SERVICE LOCATOR Este patrón se usa para la localización de servicios externos que necesita los diferentes módulos de aplicaciones, como lo son los posibles proveedores o contratistas. Este patrón permite la transparencia en la localización y utilización de servicios por parte de los componentes que lo requieren para su funcionamiento.

11 3 VISTA DE ESCENARIOS

12 4 VISTA LÓGICA 4.1 DESCRIPCIÓN VISTA LÓGICA Dentro de la aplicación podemos encontrar básicamente cuatro componentes fundamentales, los cuales son el cliente o navegador, el paquete de presentación, el paquete que contiene toda la lógica de negocios y se comunica con un paquete encargado de comunicación con servicios externos. A continuación se describen las características principales de cada uno de estos sistemas y sus relaciones y dependencias.

13 5 VISTAS Revisar enlace de modelos en la página web. 6 RANGOS DE CALIDAD Atributo de calidad Usabilidad: Entendibilidad, aprendizaje, operatividad, claridad y ayudabilidad. Funcionalidad: Precisión Funcionalidad: Interoperabilidad Confiabilidad: Tolerancia a fallas y recuperación Portabilidad: Adaptabilidad e Instalabilidad Descripción Esfuerzo necesario para el uso. Tal como esfuerzo de los usuarios para reconocer los conceptos lógicos y su aplicación, el esfuerzo para el aprendizaje de los servicios y funciones y, el esfuerzo para operar y controlar las operaciones. Por otro lado debe tener ayudas y debe ser claro en la presentación de los datos. Los resultados arrojados por el sistema deben ser correctos y precisos. Se puede revisar las operaciones realizadas y obtener un estudio de la precisión de los resultados. Aunque el primer prototipo no debe interactuar con ningún otro sistema, se espera que el producto este preparado para una futura integración con diversos sistemas en versiones posteriores. Se desea que el producto tenga un nivel específico de funcionamiento aún en casos de fallas de software o de algún servicio específico. También debe permitir recuperar datos y trabajos en caso de ciertos errores. Oportunidad para adaptar el producto de software a diferentes entornos sin dificultad. El sistema también debe ser sencillo de instalar o desinstalar.