Arquitectura y Diseño de la...
48
Arquitectura y Diseño de la Solución
-
Upload
duongtuyen -
Category
Documents
-
view
214 -
download
0
Transcript of Arquitectura y Diseño de la...
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ámitesTipo 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
Comentarios Adicionales
Mínima 1.0 Si • Nombre y/o Descripción • URL Web Service(s)
No impacta a Trámites dependientes.
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
No impacta a Trámites dependientes. Las relaciones con estos son actualizadas automáticamente a la nueva versión.
Mayor 2.0 No • Esquema de Salida • Modelo Suscripción • Periodo de
disponibilidad del trámite/servicio
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 PDIRepositorio 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
Interfaz de Usuario
CU-AU-01 Registro (Solicitud
Credenciales)
CU-AU-02 Iniciar de Sesión
CU-AU-05 Crear Usuario Delegado
CU-AU-09 Procesar Solicitud
Asignación Credenciales
CU-AU-13 Consultar datos
Usuario Delegado
CU-AU-14 Consultar Datos
Usuario Plataforma
CU-AU-03 Actualizar Datos
CU-AU-04 Reestablecer Contraseña
CU-AU-08 Modificar Usuario
Delegado
CU-AU-10 Modificar Usuario
Plataforma
CU-AU-07 Buscar Usuario Delegado
CU-AU-11 Buscar Usuario Plataforma
CU-AU-15 Cambiar Contraseña
CU-AU-16 Crear usuario sistema
Información
CU-AU-17 Modificar usuario
sistema Información
CU-AU-18 Eliminar usuario sistema
Información
CU-AU-19 Crear Administrador de
Pruebas
CU-AU-20 Eliminar Administrador de
Pruebas
CU-AU-21 Listar Trámites con Acceso
desde Sistema de Información
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«include»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«include»
«include»
«include»
«realize»
«include»
pd Operación Técnica OT
Operacion Tecnica
CU-OT-01 Configurar parámetros
Técnicos
CU-OT-02 Ejecutar Mov imiento de
Información histórica
CU-OT-03 Consultar Log de Errores Técnicos
CU-OT-04 Consultar Log de
Auditoría
«realize»
«realize»«realize»
«realize»
pd Tramitador
Tramitador
CU-GT-01 Ejecutar Trámite
CU-GT-03 Consultar Documento
CU-GT-02 Consultar Estado de Ejecución de
Trámite
CU-GT-04 Consultar
Histórico Trámites
CU-GT-05 Consultar Estado
Trámite
CU-GT-06 Ejecutar Trámite WS
«include»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
pd Directorio Tramites Electronicos
Directorio de Tramites Electronicos
CU-DT-12 Seleccionar Modelo de
Suscripción de Trámite
CU-DT-14 Seleccionar
Características de Campos
CU-DT-01 Solicitar Registro de Trámite
CU-DT-16 Seleccionar Llav es para
Consulta
CU-DT-07 Consultar Lista de
Tramites Publicados en
General
CU-DT-10 Cargar Operaciones
Entidad
CU-DT-09 Seleccionar Modelo de
Ejecución Interna del Trámite
CU-DT-04 Responder
Solicitud Trámite
CU-DT-15 Modelar Formulario Trámite
CU-DT-11 Gestionar Trámites
Prerrequisito
CU-DT-02 Solicitar Modificación del
Trámite
CU-DT-05 Consultar Arbol de
Trámite
CU-DT-06 Descargar
Instructiv o de Registro de Trámite
CU-DT-17 Solicitar Aprobacion de
Adicion
CU-DT-18 Consultar Detalle
de Tramite
CU-DT-19 Modelar Formulario de
Salida de Tramite
CU-DT-20 Seleccionar
Caracteristicas de Campo de Salida
CU-DT-21 Solicitar Modificación de
Trámite
CU-DT-22 Solicitar Aprobación de
Modificación de Trámite
CU-DT-23 Generar Reporte de Impacto
CU-DT-24 Env iar Notificaciones
CU-DT-25 Solicitar Aprobación de Eliminación de
Trámite
CU-DT-26 Buscar Tramite para Sistema
Informacion
CU-DT-27 Configurar
Ambiente de Pre-Producción
CU-DT-28 Consultar
Solicitudes y Notificaciones
CU-DT-29 Consultar Directorio de
Trámites/Serv icios
CU-DT-30 Realizar modificación mínima sobre
trámite publicado
CU-DT-31 Administrar
Noticias
CU-DT-32 Editar Acceso a
Trámites/Serv icios desde Sistemas de
Información
CU-DT-33 Listar Trámites con Acceso
desde Sistema de Información
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«include»
«include»
«include»
«realize»
«realize»
«include»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«realize»
«include»«include»
«include»
«include»
«include»
«realize»
«realize»
«realize»
«realize»«realize»
«realize» «realize»
«include»
«include»
«include»
«include»
«include»
«include»
Actor Cardinalidad Creado en el Sistema porPersona Natural o Ciudadano (Abstracto)
n N/A
Empresa (Abstracto) n N/AEntidad (Abstracto) n N/AAdministrador de Plataforma de Interoperabilidad
1 La instalación del Sistema
Administrador Delegado n Administrador de la PDIAdministrador de Pruebas n Administrador de la PDIAdministrador Delegado n Administrador de la PDIAdministrador 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/ASistema 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 OperacionesHacer 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.NETDataReaders de ADO.NETXMLObjetos o estructuras de objetos (“businessentities”)
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
