Generación de código en la programación Web avanzada (página 2)

Desventajas de los generadores existentes:

En el mundo existen una serie de Generadores de códigos innumerables, pero a pesar de sus facilidades, también tienen sus desventajas, como:

• Generan código solo referente a los métodos básicos en las conexiones a la Base de datos, es decir, insertar, modificar, eliminar y en casos muy específicos consultas.
• No están orientados a una arquitectura, y para especificarle una se debe realizar todos los modelos correspondientes a la misma, siendo esto un trabajo muy engorroso y difícil de modelar.
• A veces deben ser demasiado detallados los diagramas para generar un simple código y otras veces no es posible a través de diagramas especificar lo que se quiere hacer.
• La mayoría de los generadores de código son aplicaciones de escritorio.

Arquitectura ideal para la generación de código:

Una aplicación se compone de varios componentes, así como el modo en que cada uno de los cuales realiza una tarea diferente. Todas las soluciones de software contienen tipos de componentes similares, independientemente de las necesidades que deban cubrir. Por ejemplo, la mayoría de las aplicaciones contienen componentes que tienen acceso a datos, encapsulan reglas empresariales y controlan la interacción con el usuario, entre otros. La identificación de los tipos de componentes que se encuentran normalmente en las soluciones de software facilitará la elaboración de un plano técnico para el diseño de las aplicaciones, así como para una rápida creación o utilización de herramientas de generación de código.

Tipos de componentes:

El análisis de la mayoría de las soluciones basadas en modelos de componentes por capas muestra que existen varios tipos de componentes habituales. En la figura 1.1 se muestra una ilustración completa en la que se indican estos tipos de componentes. Aunque la lista que se muestra en la figura no es completa, representa los tipos de componentes de software más comunes encontrados en la mayoría de las soluciones con una arquitectura en capas, orientada a objetos y servicios.

Figura 1.1. Arquitectura en capas. Tipos de componentes utilizados.

Componentes de interfaz de usuario (IU). La mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicación. Las interfaces de usuario se implementan utilizando formularios, controles u otro tipo de tecnología que permita procesar y dar formato a los datos de los usuarios, así como adquirir y validar los datos entrantes procedentes de éstos. En un gran número de casos, la interacción del usuario con el sistema se realiza de acuerdo a un proceso predecible.

Componentes de lógica de negocio o empresariales. Independientemente de si el proceso consta de un único paso o de un flujo de trabajo organizado, la aplicación requerirá probablemente el uso de componentes que implementen reglas empresariales y realicen tareas empresariales. Por ejemplo, en la aplicación comercial, deberá implementar una funcionalidad que calcule el precio total del pedido y agregue el costo adicional correspondiente por el envío del mismo. Los componentes empresariales implementan la lógica empresarial de la aplicación.

Componentes de acceso a datos. La mayoría de las aplicaciones y servicios necesitan obtener acceso a un almacén de datos en un momento determinado del proceso empresarial. Por ejemplo, la aplicación empresarial necesita recuperar los datos de los productos de una base de datos para mostrar al usuario los detalles de los mismos, así como insertar dicha información en la base de datos cuando un usuario realiza un pedido. Por tanto, es razonable abstraer la lógica necesaria para obtener acceso a los datos en una capa independiente de componentes lógicos de acceso a datos, ya que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuración y el mantenimiento de la misma.

4. Servicios. Cuando un componente empresarial requiere el uso de la funcionalidad proporcionada por un servicio externo, tal vez sea necesario hacer uso de código para administrar la semántica de la comunicación con dicho servicio. Los agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicación y pueden proporcionar servicios adicionales, como la asignación básica del formato de los datos que expone el servicio al formato que requiere la aplicación.

5. Componentes de seguridad: La directiva de seguridad se ocupa de la autenticación, autorización, comunicación segura, auditoria y administración de perfiles.

Cada componente tiene sus especificidades las cuales cumple funcionalidades de acuerdo al rol que tienen en la aplicación. A continuación se muestra una descripción un poco mas detallada por cada componente, para una mucha mejor comprensión de la arquitectura.

Funcionalidades de los componentes de interfaz de usuario

Los componentes de la interfaz de usuario deben mostrar datos al usuario, obtener y validar los datos procedentes del mismo e interpretar las acciones de éste que indican que desea realizar una operación con los datos. Asimismo, la interfaz debe filtrar las acciones disponibles con el fin de permitir al usuario realizar sólo aquellas operaciones que le sean necesarias en un momento determinado. Los componentes de interfaz de usuario:

• No inicializan, participan ni votan en transacciones.
• Presentan una referencia al componente de proceso de usuario actual si necesitan mostrar sus datos o actuar en su estado.
• Pueden encapsular tanto la funcionalidad de visualización como un controlador.

Al aceptar la entrada del usuario, los componentes de la interfaz:

• Adquieren los datos del usuario y atienden su entrada utilizando guías visuales (como informaciones sobre herramientas) y sistemas de validación, así como los controles necesarios para realizar la tarea en cuestión.
• Capturan los eventos del usuario y llaman a las funciones de control para indicar a los elementos de la interfaz de usuario que cambien el modo de visualización de los datos, bien inicializando una acción en el proceso de usuario actual, o bien, modificando los datos del mismo.
• Restringen los tipos de entrada del usuario. Por ejemplo, un campo puede limitar las entradas del usuario a valores numéricos.
• Realizan la validación de entrada de datos, por ejemplo, restringiendo el intervalo de valores que se pueden escribir en un campo determinado, o garantizando que se escriben los datos obligatorios.
• Llevan a cabo la asignación y transformación simple de la información proporcionada por los controles del usuario en los valores necesarios para que los componentes subyacentes realicen su trabajo (por ejemplo, un componente de interfaz de usuario puede mostrar el nombre de un producto pero pasar el Id. del mismo a los componentes subyacentes).
• Interpretar las acciones del usuario (como las operaciones de arrastrar y colocar o los clics de botones) y llamar a una función de control.
• Pueden utilizar un componente de utilidad para el almacenamiento de datos en caché.
• Pueden utilizar un componente de utilidad para realizar la paginación. Es frecuente, especialmente en las aplicaciones Web, mostrar largas listas de datos como conjuntos paginados. Asimismo, se suele disponer de un componente de ayuda para realizar el seguimiento de la página actual en la que se encuentra el usuario y, por tanto, invocar a las funciones de consulta paginada de los componentes lógicos de acceso a datos con los valores adecuados relativos al tamaño de página y página actual. La paginación se puede realizar sin la interacción del componente de proceso de usuario.

Componentes de lógica de negocio o empresariales

Los componentes empresariales pueden ser la raíz de las transacciones atómicas. Éstos implementan las reglas empresariales en diversos patrones y aceptan y devuelven estructuras de datos simples o complejas. Los componentes empresariales deben exponer funcionalidad de modo que sea independiente de los almacenes de datos y los servicios necesarios para realizar la tarea, y se deben componer de forma coherente desde el punto de vista del significado y transaccional. Si el proceso empresarial invocará a otros procesos empresariales en el contexto de una transacción atómica, todos los procesos invocados deben garantizar que sus operaciones participan en la transacción existente de modo que las operaciones se deshagan en caso de que la lógica empresarial que realiza las llamadas se interrumpa. Una técnica muy segura es volver a intentar una operación atómica si ésta da error, sin miedo a que los datos pierdan su coherencia. Considere el límite de una transacción determinada como un límite de reintento. En la siguiente lista se resumen las recomendaciones relativas al diseño de componentes empresariales:

• Básese lo más que pueda en la comunicación basada en mensajes.
• Asegúrese de que los procesos expuestos en las interfaces de servicios no se pueden alterar y que, por tanto, el estado de la aplicación o el servicio no perderá su coherencia si se recibe el mensaje dos veces.
• Elija con cuidado los límites de la transacción de modo que se puedan realizar reintentos y composiciones. Esto se aplica tanto a las transacciones atómicas como a las de ejecución larga. Asimismo, debe considerar el uso de reintentos para sistemas basados en mensajes, sobre todo al exponer la funcionalidad de la aplicación como un servicio.
• Los componentes empresariales se deben poder ejecutar en el contexto de cualquier usuario de servicio; no necesariamente suplantando a un usuario de una aplicación específica. Esto permite su invocación con mecanismos que ni transmiten ni delegan la identidad del usuario.
• Elija y mantenga un formato de datos coherente (como XML, conjunto de datos, etc.) para los parámetros de entrada y los valores de devolución.

Los componentes empresariales son llamados por los siguientes clientes:

• Interfaces de servicios.
• Componentes de proceso de usuario.
• Flujos de trabajo empresariales.
• Otros componentes empresariales.

En la figura1.2 se muestra un componente empresarial típico que interactúa con los componentes lógicos de acceso a datos, las interfaces y los agentes de servicios y otros componentes empresariales.

Figura 1.2. Componentes empresariales

Obsérvese los siguientes puntos:

2. Los componentes empresariales pueden ser invocados por los componentes de las capas de presentación.
3. Los componentes empresariales pueden ser invocados por interfaces de servicios (por ejemplo, un servicio Web XML).
4. Los componentes empresariales pueden llamar a componentes lógicos de acceso a datos para recuperar y actualizar datos, y pueden invocar a otros componentes empresariales.
5. Los componentes empresariales también pueden invocar a agentes de servicios. Tenga especial cuidado al diseñar la lógica de compensación en caso de que el servicio al que desea tener acceso no esté disponible o lleve demasiado tiempo devolver una respuesta.

Nota:   Las flechas que aparecen en la figura representan el flujo de control, no el flujo de datos.

Diseño de capas de acceso a datos y almacén de datos

Casi todas las aplicaciones y servicios necesitan almacenar y obtener acceso a un determinado tipo de datos.

Al trabajar con datos debe determinar:

1. El almacén de datos que utiliza.
3. El diseño de los componentes utilizados para obtener acceso al almacén de datos.
4. El formato de los datos pasados entre componentes y el modelo de programación necesario para ello.

La aplicación o servicio puede disponer de uno o varios orígenes de datos, los cuales pueden ser de tipos diferentes. La lógica utilizada para obtener acceso a los datos de un origen de datos se encapsulará en componentes lógicos de acceso a datos que proporcionan los métodos necesarios para la consulta y actualización de datos. Los datos con los que la lógica de la aplicación debe trabajar están relacionados con entidades del mundo empresarial que forman parte de la empresa. En determinados escenarios, puede disponer de componentes personalizados que representan estas entidades, mientras que en otros puede decidir trabajar con datos utilizando directamente conjuntos de datos o documentos XML. La mayoría de las aplicaciones utilizan una base de datos relacional como almacén principal de los datos de la aplicación.

Diseño de la directiva de seguridad

La directiva de seguridad se ocupa de la autenticación, autorización, comunicación segura, auditoría y administración de perfiles, tal como muestra la figura 1.3.

Figura 1.3. Aspectos de la directiva de seguridad

Principios generales sobre seguridad

Existen ciertos principios generales sobre seguridad que se deben tener en cuenta a la hora de desarrollar una directiva de seguridad. Hay que tener en cuenta las siguientes directrices:

• Siempre que sea posible, se debe recurrir a sistemas de seguridad que se hayan comprobado y demostrado su eficacia en lugar de generar su propia solución personalizada.
• Nunca confiar en las aportaciones externas. Deberá validar todos los datos que introduzcan los usuarios o envíen otros servicios.
• Considerar por principio que los sistemas externos no son seguros. Si su aplicación recibe datos confidenciales sin cifrar desde un sistema externo, asuma que dicha información no es segura.
• Aplicar el principio del menor privilegio. No habilitar más atributos en las cuentas de servicios que los que resulten estrictamente necesarios para la aplicación. Obtener acceso a los recursos con cuentas que tengan los mínimos permisos necesarios.
• Reducir el área de superficie. El riesgo se incrementa según aumenta el número de componentes y datos que haya expuesto a través de la aplicación y, por lo tanto, se deberá exponer únicamente la funcionalidad que se crea que otros van a utilizar.
• Establecer como predeterminado un modo seguro. No habilitar servicios, tecnologías y derechos de cuenta que no sean absolutamente necesarios. Cuando se implemente la aplicación en equipos cliente o servidor, la configuración predeterminada de esta deberá ser segura.
• No confiar en la seguridad a través del ocultamiento. El cifrado de los datos implica disponer de claves y de un algoritmo de cifrado demostrado. El almacenamiento de los datos seguros evitará el acceso a ésta en cualquier circunstancia. No se puede considerar seguridad la mezcla de diversas cadenas, el almacenamiento de la información en rutas de archivo inesperadas y demás técnicas similares.
• Seguir los principios de STRIDE. (STRIDE responde a las siglas inglesas de Simulación, Alteración, Repudio, Revelación de información, Denegación de servicio y Elevación de privilegios). Todas estas son clases de vulnerabilidades de la seguridad contra los que un sistema se debe proteger.
• Realizar la comprobación desde la misma puerta. No permitir que los procesos vayan más allá del lugar para el que los usuarios están autorizados.
• Bloquear su sistema interna y externamente: los usuarios y operadores internos pueden representar un riesgo igual que los intrusos externos.

Conclusiones:

Valorados los impactos causados por los generadores de código, se puede afirmar que su uso es de gran ayuda en la confección de softwares, mejorándose grandemente la calidad de la producción, el establecimiento de estándares de código y el tiempo de desarrollo de las aplicaciones.

Además, con un buen uso una arquitectura en componentes se puede llegar a obtener un máximo rendimiento del generador de código que se utilice, así como una buena practica de lo métodos de construcción de software utilizando capas o componentes.

Referencias Bibliográficas:

• COMPILADORES Y GENERADORES DE CÓDIGO. .
• CODECHARGE STUDIO. http://www.yessoftware.com/products/product_detail.php?product_id=1.
• Clarion. http://www.gopac.com.mx/herramientas/clarion/descripcion.htm.
• Pressman, R. Software Engineering. A Practitioner’s Approach. Fourth Edition. McGraw – Hill. USA, 1999.

Referente al Autor:

Leevan Abon Cepeda

Año de nacimiento: 1983.

Titulo: Ingeniero en Ciencias Informáticas.

Datos Adicionales: Trabajador de la Universidad de Ciencias Informáticas. Graduado con Titulo de Oro de Ingeniero en Ciencias Informáticas en dicha universidad.

Referente al Trabajo:

Ciudad: Ciudad de la Habana.

País: Cuba.

Fecha de Realización: febrero del 2008.