Cumplimiento normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.

1 Modelo lógico

Para conseguir la independencia, robustez y escalabilidad de los sistemas, y en base a las pautas generales del modelado y diseño de los sistemas de información, las aplicaciones desarrolladas por la STIC deberán ser diseñadas como aplicaciones Web siguiendo un modelo arquitectónico basado en el principio de Separación de Problemas (SoC, Separation of Concerns). Este principio permite el estudio de cada uno de los componentes de un sistema de forma aislada. Es un principio fundamental en el diseño de sistemas complejos empresariales y de la programación Orientada a Objetos.

Este principio aplicado al desarrollo de aplicaciones para el SAS resulta en la siguiente separación lógica:

• Presentación y Control.
• Negocio.
• Integracion. 

En la imagen lateral puede verse la arquitectura propuesta por SAS para el desarrollo de aplicaciones web.

Esta separacion nos permite dividir el aplicativo en modulos mas mantenibles y sencillos de evolucionar.

En general la arquitectura de referencia del SAS está basada en el patrón Boundary Control Entity (BCE), esta se aplicara si no se especifica lo contrario.

Como puede observarse, la arquitectura propuesta es independiente de la tecnología a usar, siendo válida tanto para los desarrollos realizados en Java como .NET. Además, es importante destacar que la propuesta que aquí se presenta es un modelo a seguir de forma obligatoria por todos los proveedores de software, si bien es posible la modificación de la misma si fuera necesario, para lo cual será necesario presentar y justificar una propuesta de cambio a la STIC para su valoración y aceptación.

2 Pautas de diseño

Existen unas pautas básicas a considerar de forma general durante el diseño de los diferentes modulos. Las principales se muestran a continuación.

Presentación y Control

La Presentación muestra el sistema al usuario, presentándole la información y capturando aquella proporcionada por el usuario en un mínimo proceso de filtrado. Esta modulo se debe comunicar únicamente con el modulo de negocio.Se ara uso principalmente del patrón MVC.

Las pautas de diseño generales a adoptar en este modulo son:

• Separación de la lógica de negocio y presentación. La vista debe limitarse únicamente a la presentación de la información al usuario o a solicitársela, nunca a procesarla ni tomar decisiones sobre ella. Tales tareas serán competencia del negocio.
• Desacoplamiento entre modulos. La vista sólo debe contener lógica de visualización, nunca de tratamiento de la información, evitando de esta forma el acoplamiento entre modulos.
• Aspecto gráfico externo. Todos los sistemas deben tener el mismo aspecto gráfico externo a nivel de proyecto, corporativo y/o de función de negocio.
• Modularidad. Las vistas deben diseñarse de forma modular, evitando que cada módulo haga referencia a otros de la misma o de otras vistas. Es el caso, por ejemplo, de los módulos correspondientes a la cabecera, el cuerpo, el menú o pie de las vistas, que deberán integrarse dinámicamente. El grado de reusabilidad de los módulos así como el encapsulamiento de la funcionalidad en cada caso debe de ser muy elevado.
• Internacionalización. Las vistas y por extensión las aplicaciones deben permitir su adaptación a diferentes idiomas y convenciones (formatos de fecha, moneda, etc.) sin necesidad de realizar cambios en su código.
• Validaciones. Deben de realizarse las validaciones formales de los datos introducidos en las vistas, así como las correspondientes a campos obligatorios.
• Elaborar un catálogo de controles. Es recomendable elaborar un catálogo con la lista de controles oficiales en la que se especifique la función de cada control, los posibles validadores/conversores que se le puedan asociar, los eventos que pueda lanzar y los atributos que puedan cambiarse para manipular su aspecto externo. Este catálogo de controles facilitará la creación de las vistas de forma estándar e independiente de los componentes del modulo de negocio. De forma generalizada, no se recomienda la inclusión en este catálogo de controles desarrollados por terceros.
• Gestión de los mensajes de interfaz de usuario. Los mensajes que las aplicaciones devuelvan deben proceder de los controles, del procesado de los datos de la vista (el resultado) o del negocio.

Negocio

El Negocio ocupa un lugar angular en la definición de una infraestructura de software base que permita el crecimiento y la extensibilidad de servicios para todas las aplicaciones existentes y futuras.

La definición de los límites de cada modulo permite definir correctamente la colaboración que proveerá cada una de ellas.

Las principales pautas para el diseño de esta modulo son:

• Elementos constitutivos. El negocio engloba toda la lógica de negocio: reglas, workflow y operaciones no persistentes. Aunque no son parte del negocio como tal las operaciones persistentes deben ser ubicadas junto al negocio.
• Reglas de negocio. El negocio debe ser visto como el punto de acceso único y centralizado al conjunto de servicios expuestos a los modulos que lo usen
• Validaciones de datos. Los servicios de negocio deben realizar las comprobaciones necesarias sobre los datos proporcionados para garantizar su validación previa al inicio de los procesos de negocio requeridos.
• Comunicación entre modulos. La definición de la estrategia de negocio, basada en la creación de las entidades del negocio o los objetos del modelo, se presenta como una fase fundamental en el desarrollo. La comunicación entre modulos se establece mediante estos objetos.
• Transacciones. El manejo de transacciones debe realizarse desde el negocio.
• Tratamiento de excepciones. Debe establecerse una gestión de excepciones según la cuál las mismas se propaguen hacia los modulos que usen el negocioLas excepciones generadas desde la capa de integración o persistencia deben ser encapsuladas en esta capa para ser trasladadas de forma correcta a la capa superior. Debe evitarse, además, el uso de métodos genéricos para la captura de las excepciones, empleando métodos específicos relativos al objeto en cuestión.
• Encapsular los servicios de negocio. Los servicios de negocio son el "puente" entre el usuario y los servicios de datos. Responden ante peticiones del usuario (u otros servicios de negocios) para ejecutar una tarea de este tipo aplicando procedimientos formales y reglas de negocio a los datos relevantes. Cuando los datos necesarios residen en un servidor de bases de datos, garantizan los servicios de datos indispensables para cumplir con la tarea de negocios o aplicar su regla. Esto aísla al usuario de la interacción directa con la base de datos.
• Control sobre el uso de servicios. El control del acceso a los servicios de negocio debe hacerse en el negocio, bien a nivel de servicio vertical (cada Fachada) o a nivel de método dentro de cada servicio.
• Persistencia. Aunque no suele incluirse en el negocio, la persistencia para la mayoria de desarrollos estara modularizada junto con el negocio, aplicando junto con el, el patron BCE.
  • Mapeo Objeto-Relacional (ORM). La implementación debe realizarse en base a un mapeo Objeto-Relacional, empleando un motor de persistencia que asegure el correcto funcionamiento.
  • Cada objeto debe ser creado en la base de datos para que sea persistente. El patrón CRUD indica que cualquier objeto debe de ser creado como un elemento persistente en la base de datos. Es necesario asegurar que existen operaciones que permitan leer, actualizar o simplemente borrar. Para ello, debe implementarse un DAO distinto por cada objeto de negocio en el sistema.
  • Manejo de la Cache. El uso de cachés en el acceso a datos debe realizarse siempre teniendo en cuenta las características del sistema y las necesidades de sincronización. No hay que olvidar el coste de rendimiento derivado de su uso, por lo que el manejo de cachés deberá estar siempre justificado.
  • Permitir la concurrencia de usuarios. Debe permitir que múltiples usuarios trabajen en la misma base de datos protegiendo los datos de ser escritos equivocadamente, minimizando las restricciones en su capacidad concurrente para lectura y escritura.
  • Evitar las referencias circulares entre objetos. En la medida de lo posible, se deben evitar las referencias circulares, facilitando la localización de los objetos, proporcionando un acceso más efectivo a la información.
  • Buen uso de la información oculta. Existen numerosas columnas de tablas que no necesitan ser mapeadas a una propiedad del objeto, conteniendo información oculta para el modelo de objetos pero necesaria para el modelo relacional. En esta categoría entran los mecanismos de auditoría. Al leer el objeto, se lee esta información, que es ocultada al objeto pero mantenida por el framework de persistencia.
  • Actualización en cascada. Debe utilizarse la posibilidad que ofrecen los frameworks para la actualización en cascada de objetos. Esta característica permite que las modificaciones hechas a un objeto se repliquen en los objetos relacionados, mejorándose su mantenimiento, la replicación eficiente de los cambios y la integridad de los datos.
  • Operaciones en masa. Se deben de permitir las operaciones en masa sobre los datos almacenados, lo que mejora de forma sensible el rendimiento de las operaciones.

Integracion

El modulo de integracion permite tener separado del negocio todas las necesidades de datos de servicios externos a la aplicacion.

Las pautas de diseño generales a adoptar en este modulo son:

• Integraciones con terceros. En este modulo se deben de englobar todos las integraciones con los sistemas externos, exponiendo al negocio una fachada adaptada a las necesidades del propio negocio.
• Adaptadores o mapeadores.  Se debe evitar el uso de clases de librerias de integracion de terceros, para ello se propone el uso de adaptadores o mapeadores que faciliten la conversion de los dto externos a internos.
• Librerias de terceros. Las dependencias con librerias de terceros deben estar contenidas en este modulo. Evitando que el negocio dependa directamente con estas librerias.

Infraestructura o Transversales

Adicionalmente a las modulos ya comentadas, puede existir la necesidad de contar con una base que de soporte de herramientas funciones comunes que son usadas a lo largo de la aplicación. En estos modulos cubririán entre otros, los siguientes aspectos:

• La seguridad
• La trazabilidad
• La instrumentación
• El uso de caché
• La gestión de excepciones
• La validación de datos

Estos modulos no seran necesarios a menos que por el tamaño del desarrollo asi lo requiera.

4 Entorno Tecnológico

Estas recomendaciones también serán de aplicación para los desarrollos evolutivos y/o correctivos de sistemas ya desarrollados, si bien se debe tener en cuenta que para tecnologías anteriores (como PHP, Visual Basic, etc.) la inclusión o migración a las nuevas tecnologías no será siempre viable, pudiendo ser recomendable en muchos casos continuar con las tecnologías actuales del proyecto, como la elección de alguna tecnología diferente a las aquí descritas.

Tecnologías de Base y Requerimientos de Entorno

La arquitectura de referencia plasmada en este documento se basa en unas herramientas y tecnologías tomadas como base, y en las que se apoyarán muchas de las decisiones tecnológicas adoptadas.  Será necesario por ello tener en cuenta las Normas de Referencia elaboradas por la STI para:

• La Base de Datos Oracle.
• La Explotación de Datos.(BI)
• Integración y Comunicación. (OTI)
• Normativa de Clientes Web

Asimismo, existen otros requerimientos de entorno propios para que puede consultar cada tecnología JAVA ó .NET .

Documentación relacionada