Arquitectura y Diseño de la Solución
Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de Casos de Uso Clasificación de CU por Grupos Funcionales AU, AG, DT, GT, OT Presentación de los casos de uso más relevantes para las decisiones de arquitectura Vista Lógica Descripción de las Principales Operaciones Vista Interna por Capas Servicios e Infraestructura Vista de Datos Modelo Entidad/Relación Vista de Procesos Detalle sobre la Gestión de Tramite/Servicio Detalle sobre la Gestión de Usuarios.
Modelamiento de Trámties
Ejecución de trámites
Ejecución de Trámites
Ejecución de trámites compuestos Datos comunes se solicitan una sola vez
Ejecución de trámites compuestos
Ejecución de Trámites Compuestos
Versionamiento de trámites Tipo de Cambio Formato de Numeración (Versión Inicial: 1.0) Impacto a Instancias de Trámites en Ejecución Cambios en Características del Trámite que Indican el Tipo de Versión Mínima 1.0 Si Nombre y/o Descripción URL Web Service(s) Menor 1.1 No Soporte a Personal e Intransferible Esquema de Entrada Llaves de Consulta Prerrequisitos Información Propia del Trámite/servicio Formulario Entrada Formulario Salida Mayor 2.0 No Esquema de Salida Modelo Suscripción Periodo de disponibilidad del trámite/servicio Comentarios Adicionales No impacta a Trámites dependientes. No impacta a Trámites dependientes. Las relaciones con estos son actualizadas automáticamente a la nueva versión. Afecta trámites dependientes, requiere que estos a su vez sean modificados explícitamente por sus Administradores (Cambio Menor en estos)
Versionamiento de trámites MENOR MAYOR
La arquitectura lógica y física de la PDI fue diseñada teniendo en mente los siguientes objetivos: Incluir elementos de una Arquitectura Orientada a Servicios (SOA). Esto le añade características importantes de integración, flexibilidad. Estar orientada al rendimiento y escalabilidad. La arquitectura propuesta pretende manejar los problemas de rendimiento que una interfaz Web pueda traer al sistema, y así lograr los mejores tiempos de respuesta según la infraestructura dispuesta. La arquitectura propuesta le permiten al sistema aprovechar de mejor manera los recursos de hardware disponibles. Lograr la mayor disponibilidad del sistema, eliminando la mayor cantidad de puntos de fallo. Evitar al máximo el cruce de fronteras entre procesos y máquinas durante los llamados entre capas de la arquitectura. Estar alineada a futuras tecnologías de Microsoft basadas en estándares de la industria, que le permitirá una fácil evolución.
La estructura general del sistema se definió con base en los requerimientos, consiste de 6 subsistemas funcionales principales con las siguientes responsabilidades: Editor de Trámites: este subsistema se encarga de controlar el proceso de registro y edición de un trámite, para esto interactúa con otros subsistemas como el Administrador de Formas y el Directorio de Operaciones. El nuevo trámite modelado, junto con su configuración y características es almacenado en un Repositorio de Definición de Tramites. Directorio de Operaciones: Administra un repositorio con la definición de las diferentes operaciones (métodos) expuestas por los Web Services de Entidades o Empresas que implementan los respectivos trámites. De esta manera se puede independizar (o desacoplar) la PDI de los Web Services de las Entidades, y se logra un mecanismo de enlace dinámico a estas operaciones desde el proceso o flujo de ejecución de un tramite. Adicionalmente, expone métodos de consulta, actualización y administración del repositorio. Administrador de Formas: este subsistema administra un repositorio que contiene la definición de formas de captura y muestra de resultados para un trámite. Adicionalmente, contiene la lógica necesaria para modelar o editar una forma con base en un esquema GEL-XML determinado, y generarla en tiempo de ejecución (instanciarla).
Despachador de Trámites: este sistema reencarga de controlar y orquestar el proceso de ejecución de un tramite. Para esto hace uso de los servicios provistos por otros subsistemas como el Administrador de Formas y el Administrador de Trámites en Ejecución. En el caso de trámites compuestos, este subsistema también es responsable de obtener los tramites prerrequisito y decidir cuales ( resolución del árbol ) de estos harán parte de su ejecución y en que momento ( programación de ejecución ). Administrador de Trámites en Ejecución: este subsistema funciona como un servicio que siempre esta en ejecución, y tiene como principales responsabilidades: realizar los llamados a Web Services no-inmediatos (asincrónicos) que sean necesarios, como parte de la ejecución de un trámite. Los llamados inmediatos (sincrónicos), no utilizan este subsistema y son controlados directamente por el Despachador de Trámites. Adicionalmente, este subsistema esta pendiente de la llegada de resultados de los llamados hechos, y su correlación correspondiente. Por ultimo, implementa los mecanismos y tecnologías necesarias para garantizar la confiabilidad, seguridad y eficiencia de la comunicación con las entidades. Visor de Resultados: este subsistema brinda la información que le permite al usuario conocer el estado de un determinado trámite en ejecución, o visualizar su resultado.
Repositorio de Esquemas GEL-XML: además de servir como repositorio a los esquemas de entrada y salida definidos para cada trámite, brinda una interfaz de consulta que independiza a la PDI de la ubicación y el medio de almacenamiento utilizado. Repositorio de Definición de Trámites: almacena el modelamiento de los trámites definidos en la PDI Repositorio de Formas: sirve de almacén a la definición de formas (formularios) de entrada y salida de información asociados a trámites. Repositorio de Operaciones: mantiene un directorio de las operaciones (métodos) expuestos por los Web Services de entidades y Empresas. Repositorio de Trámites en Ejecución: guarda la información de entrada y salida de aquellos trámites que están siendo o fueron ejecutados (instanciados) por los usuarios.
División de CU por grupos funcionales Gestión de Trámites (GT) Administración de Usuarios (AU) Definición de Trámites (DT) Administración de Gestión (AG) Operación Técnica (OT) Matriz de trazabilidad
pd Interfaz de Usuario CU-AU-01 Registro (Solicitud Credenciales) CU-AU-15 Cambiar Contraseña CU-AU-11 Buscar Usuario Plataforma «include» CU-AU-02 Iniciar de Sesión CU-AU-14 Consultar Datos Usuario Plataforma «include» «include» CU-AU-03 Actualizar Datos Interfaz de Usuario CU-AU-10 Modificar Usuario Plataforma CU-AU-04 Reestablecer Contraseña CU-AU-09 Procesar Solicitud Asignación Credenciales CU-AU-05 Crear Usuario Delegado CU-AU-07 Buscar Usuario Delegado «include» «include» CU-AU-08 Modificar Usuario Delegado CU-AU-13 Consultar datos Usuario Delegado CU-AU-19 Crear Administrador de Pruebas CU-AU-16 Crear usuario sistema Información CU-AU-17 Modificar usuario sistema Información CU-AU-20 Eliminar Administrador de Pruebas CU-AU-18 Eliminar usuario sistema Información CU-AU-21 Listar Trámites con Acceso desde Sistema de Información
pd Operación Técnica OT CU-OT-03 Consultar Log de Errores Técnicos CU-OT-01 Configurar parámetros Técnicos Operacion Tecnica CU-OT-02 Ejecutar Movimiento de Información histórica CU-OT-04 Consultar Log de Auditoría
pd Tramitador CU-GT-01 Ej ecutar Trámite CU-GT-02 Consultar Estado de Ej ecución de Trámite Tramitador CU-GT-04 Consultar Histórico Trámites CU-GT-06 Ejecutar Trámite WS «include» CU-GT-05 Consultar Estado Trámite CU-GT-03 Consultar Documento
pd Directorio Tramites Electronicos «include» CU-DT-12 Seleccionar Modelo de Suscripción de Trámite CU-DT-15 Modelar Formulario Trámite «include» CU-DT-14 Seleccionar Características de Campos CU-DT-06 Descargar Instructivo de Registro de Trámite CU-DT-01 Solicitar Registro de Trámite «include» «include» CU-DT-16 Seleccionar Llaves para Consulta CU-DT-05 Consultar Arbol de Trámite «include» CU-DT-07 Consultar Lista de Tramites Publicados en General CU-DT-21 Solicitar Modificación de Trámite «include» CU-DT-18 Consultar Detalle de Tramite «include» «include» CU-DT-11 Gestionar Trámites Prerrequisito «include» «include» «include» «include» «include» «include» CU-DT-09 Seleccionar Modelo de Ej ecución Interna del Trámite Directorio de Tramites Electronicos CU-DT-17 Solicitar Aprobacion de Adicion CU-DT-04 Responder Solicitud Trámite CU-DT-02 Solicitar Modificación del Trámite CU-DT-10 Cargar Operaciones Entidad CU-DT-20 Seleccionar Caracteristicas de Campo de Salida «include» CU-DT-19 Modelar Formulario de Salida de Tramite CU-DT-29 Consultar Directorio de Trámites/Servicios CU-DT-31 Administrar Noticias CU-DT-23 Generar Reporte de Impacto CU-DT-22 Solicitar Aprobación de Modificación de Trámite CU-DT-26 Buscar Tramite para Sistema Informacion CU-DT-25 Solicitar Aprobación de Eliminación de Trámite CU-DT-30 Realizar modificación mínima sobre trámite publicado CU-DT-27 Configurar Ambiente de Pre- Producción CU-DT-28 Consultar Solicitudes y Notificaciones CU-DT-24 Enviar Notificaciones CU-DT-32 Editar Acceso a Trámites/Servicios desde Sistemas de Información CU-DT-33 Listar Trámites con Acceso desde Sistema de Información
Actor Cardinalidad Creado en el Sistema por Persona Natural o Ciudadano n N/A (Abstracto) Empresa (Abstracto) n N/A Entidad (Abstracto) n N/A Administrador de Plataforma de 1 La instalación del Sistema Interoperabilidad Administrador Delegado n Administrador de la PDI Administrador de Pruebas n Administrador de la PDI Administrador Delegado n Administrador de la PDI Administrador de Entidad n por Entidad Solicitado por él mismo, Autorizado por el Administrador de la PDI Administrador Empresa 1 por Empresa Solicitado por él mismo, Autorizado por el Administrador de la PDI Usuario Delegado n por Entidad o Empresa Administrador de Entidad o Empresa Ciudadano n Solicitado por él mismo, Autorizado por el Administrador de la PDI Usuario Anónimo 1 N/A Sistema de Información n por Entidad o Empresa Administrador de Entidad o Empresa
Esta basada en un modelo arquitectónico de N-Niveles o capas, con una interfaz de usuario 100% Web.
La arquitectura de la PDI utiliza como base una Arquitectura estándar por capas definida por Microsoft.
Directorio de Operaciones (WSDL) Cargar Operaciones (CU-DT-10) Obtener, validar y guardar lista de las operaciones expuestas. Ejecución de Operaciones Hacer llamados a las operaciones cargadas Administrador de Formas (imagen documento) Edición de formas Manipular la información de los esquema GEL-XML (xsd- >html) Generación dinámica de formas (html -> xml)
Administrador de Trámites en Ejecución Llamados inmediatos
Administrador de Trámites en Ejecución Llamados No-inmediatos
Llamados No Inmediatos
Visor de Resultados Visualización de Resultados de los trámites Revisar el estado de ejecución del tramite. Esta operación tiene en cuenta que no toda la información que retorna el Web Service que implementa el trámite en la entidad es de interés para el Actor. Por este motivo existe un formulario de salida de información que debió ser definido durante el modelamiento del trámite. Este formulario define que campos serán mostrados así como su ubicación (presentación) en la forma. Funciona similar al formulario de entrada de datos, y es generado por el Administrador de Formas, según la definición almacenada en el Repositorio de Formas.
La arquitectura del sistema estará basada en el patrón de arquitectura por capas [POSA1]* Utilizada para dividir sistemas de software complicados. Existe una organización lógica del sistema en 4 capas: Capa de Presentación (que provee las interfaces de usuario) Capa de Dominio (el cual agrupa la funcionalidad de las capas de Lógica de Negocios y Acceso a Datos, según la Arquitectura de Microsoft), Capa de Servicios Técnicos (componentes no-funcionales y librerías de uso común en el sistema) Capa de Infraestructura (servicios comunes de bajo nivel que soportan el sistema y generalmente son brindados por la plataforma). *[POSA1] Buschmann, Frank. Pattern-Oriented Software Architecture, Wiley
Manejo de eventos en la capa de presentación
Capa de Dominio
Manejo de información en la capa de Dominio
DataSets de ADO.NET DataReaders de ADO.NET XML Objetos o estructuras de objetos ( business entities )
Una vez el usuario ha sido autenticado se le genera un Contexto de Seguridad. Cada una de las paginas que el usuario intente acceder de la capa de presentación, validan que tenga acceso utilizando para esto la información contenida en el Contexto de Seguridad y el modelo de autorización basado en Roles almacenado en la base de datos. Este modelo utiliza las características de Role Management incluidas con ASP.NET 2.0. La siguiente grafica muestra el típico modelo que soporta esto: Según lo anterior, la tabla Privilegios mantiene una matriz que relaciona las acciones o accesos a paginas con los Perfiles/Roles. En la capa de servicios técnicos de la arquitectura existen componentes que facilitan la implementación de los mecanismos de Autorización.
Se utiliza el contexto de seguridad del usuario que generó el llamado. Se audita funcionalidad identificada por casos de uso.
Único punto de manejo de excepciones En InterfaseServicio es el punto donde se deben atrapar y registran cualquier excepción que ocurra durante el procesamiento de una llamada a la capa de Dominio. Por defecto el registro de errores se debe hacer al EventLog de Windows.
Todos los parámetros de configuración de Web Services, Sitios Web, y demás componentes de la solución, deberán quedar en los archivos de configuración XML que provee el Framework de.net (.config). Existe funcionalidad por el portal de administración de PDI para modificar algunos parámetros.
Utilización del patrón Table Data GateWay Ver diagramas ER