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:
- Los componentes empresariales pueden ser invocados
por los componentes de las capas de
presentación. - Los componentes empresariales pueden ser invocados
por interfaces de servicios (por ejemplo, un servicio Web
XML). - 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. - 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:
- El almacén de datos que utiliza.
- El diseño de los componentes utilizados para
obtener acceso al almacén de datos. - 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.
 Página anterior | Volver al principio del trabajo | Página siguiente  |