UNIDAD 3 DISEÑO DE APLICACIONES DISTRIBUIDAS 3.

1 DISEÑO E IMPLEMENTACIÓN DE MANEJO DE DATOS
COMPONENTES SOFTWARE ¿Alguna vez ha pensado que un programa pudiera ser como... una bicicleta?. Si es necesario cambiar la cadena de la bicicleta, usted solo se centra en la cadena, no tiene que lidiar con otros componentes ajenos, como por ejemplo, las gomas o tan sencillo como el timbre, sino solo la cadena. Sabe con exactitud dónde está el componente y puede modificarlo (engrasar) o actualizarlo (una nueva). Si ahora le dijera que pudiera hacer lo mismo con los software que usted desarrolla, ¿qué diría al respecto?. El objetivo de la tecnología de componentes software es construir aplicaciones complejas mediante ensamblado de módulos (componentes) que han sido previamente diseñados por otras personas a fin de ser rehusados en múltiples aplicaciones. La ingeniería de programación que sigue esta estrategia de diseño se le conoce por el acrónimo CBSE1 y es actualmente una de las más prometedoras para incrementar la calidad del software, abreviar los tiempos de acceso al mercado y gestionar el continuo incremento de su complejidad. La arquitectura software de una aplicación basada en componentes consiste en uno o un número pequeño de componentes específicos de la aplicación (que se diseñan específicamente para ella), que hacen uso de otros muchos componentes prefabricados que se ensamblan entre sí para proporcionar los servicios que se necesitan en la aplicación.

En la tecnología de componentes la interfaz constituye el elemento básico de interconectividad. Cada componente debe describir de forma completa las interfaces que ofrece, así como las interfaces que requiere para su operación. Y debe operar correctamente

con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz. Características muy relevantes de la tecnología de programación basada en componentes son la modularidad, la reusabilidad y compatibilidad y en todos ellos coincide con la tecnología orientada a objetos de la que se puede considerar una evolución. Sin embargo, en la tecnología basada en componentes también se requiere robustez ya que los componentes han de operar en entornos mucho más heterogéneos y diversos. El desarrollo de software basado componentes es la evolución natural de la ingeniería software para mejorar la calidad, disminuir los tiempos de desarrollo y gestionar la creciente complejidad de los sistemas.

ENTORNOS NORMALIZADOS DE DESARROLLO DE COMPONENTES SOFTWARE.
Para que una arquitectura de componentes pueda operar es necesario disponer de un entorno normalizado que proporcione soporte a los mecanismos con que se comunican las interfaces. COM (Component Object Model). Los lenguajes de programación clásicos fueron diseñados para desarrollar aplicaciones secuenciales compuestas de módulos, todos ellos codificados con un solo lenguaje. Sin embargo, hay situaciones en las que no es práctico restringirse al uso de un único lenguaje. La tecnología COM aborda la solución a este problema proporcionando un sencillo, pero a la vez potente modelo para construir sistemas software a partir de la interacción de objetos (componentes). COM define un estándar binario (esto implica que es independiente del lenguaje de programación) para objetos y la intercomunicación entre ellos. Toda comunicación se realiza a través de operaciones que son proporcionadas dentro de interfaces. El diseñador invoca las operaciones que necesita directamente, incluso si el objeto destinatario está localizado en otro proceso o en otra máquina. El modelo de programación COM está basado en la distribución de código de clases en componentes binarios. Esto significa que el software (componentes) que se adhiere a COM, puede ser rehusado sin ninguna dependencia de código fuente. Los desarrolladores pueden exponer sus trabajos como ficheros binarios sin dar a conocer sus algoritmos. El desarrollo basado en componentes resuelve muchos de los problemas asociados con las aplicaciones monolíticas. Permite al grupo de desarrollo exponer ficheros binarios en vez de código fuente. Los componentes binarios pueden ser actualizados independientemente y reemplazados, lo que se hace mucho más fácil mantener y extender una aplicación después de que esta ha sido puesta en explotación.

MTS (Microsoft Transaction Server). MTS es una pieza de software que fue creada para Windows NT Server. Como su nombre implica, MTS permite a los objetos de la capa media (más adelante se expone una arquitectura de diseño) correr sobre Windows NT Server y controlar las transacciones distribuidas, es decir, permite a los componentes ser esparcidos por la red y que se ejecuten en otras computadoras con sistema operativo Windows NT Server. MTS provee un entorno de ejecución para objetos COM, adicionando soporte para la seguridad, soporte para administración y configuración. Es posible administrar varios servidores desde una simple computadora. COM+ COM+1, no es más que la integración de la arquitectura COM y MTS (Microsoft Transation Server). A diferencia de MTS, esta nueva capa de ejecución no es opcional2, COM+ es parte por defecto de la instalación del sistema operativo Windows 2000. Como COM, COM+, es basado sobre componentes binarios y programación basada en interfaces. Los Componentes COM+ pueden ser actualizados y extendidos una vez que estén en explotación sin afectar a las aplicaciones clientes que los usan en la producción. De este modo, la combinación de la tecnología COM+ junto con las técnicas de programación orientada a objeto, nos ofrece una importante simplificación en el proceso de desarrollo de aplicaciones informáticas. Diseñando Aplicaciones Distribuidas. El diseño de aplicaciones modernas involucra la división de una aplicación en múltiples capas; la interfase de usuario, la capa media de objetos de negocios, y la capa de acceso a datos. Puede ser útil identificar los tipos de procesamiento que podemos esperar que una aplicación realice. Muchas aplicaciones pueden, al menos, hacer lo siguiente:
• • • • • • •

Cálculos u otros procesos de negocios. Ejecución de reglas de negocios. Validación de datos relacionados al negocio. Manipulación de datos. Ejecución de las reglas de datos relacional. Interactuar con aplicaciones externas o servicios. Interactuar con otros usuarios.

Nosotros podemos tomar estos tipos de servicios y generalizarlos dentro de los tres grupos o capas que a continuación se resumen:

Interfase de usuario (Capa de Presentación)
• o

Interactuar con otros usuarios.

Interactuar con aplicaciones externas o servicios. Procesos de negocios (Capa de Negocios)
o •

Cálculos u otros procesos de negocios. Ejecución de reglas de negocios. Validación de datos relacionados al negocio. Procesos de datos (Capa de Servicios de Datos).
o o o • o o

Manipulación de datos. Ejecución de las reglas de datos relacional.

La división de estos procesos de aplicaciones y su distribución entre diferentes procesos cliente/servidor es conocido como Procesamiento Distribuido. Generalizando estos procesos dentro de estas tres categorías o capas es una distribución lógica y no refleja necesariamente alguna opción de diseño físico sobre computadoras, terminales u otros equipos. Usted puede desarrollar una aplicación cliente/servidor distribuida basada sobre estas tres capas de Presentación, Lógica de Negocios y Servicios de Datos y tener la aplicación entera corriendo sobre una simple computadora. Alternativamente, usted puede esparcir estas tres capas a través de un gran número de diferentes computadoras sobre una red. De cualquier forma usted ha desarrollado una aplicación cliente/servidor de tres capas. Capa de Presentación. La capa de Presentación provee su aplicación con una interfase de usuario (IU). Aquí es donde su aplicación presenta información a los usuarios y acepta entradas o respuestas del usuario para usar por su programa. Idealmente, la IU no desarrolla ningún procesamiento de negocios o reglas de validación de negocios. Por el contrario, la IU debería relegar sobre la capa de negocios para manipular estos asuntos. Esto es importante, especialmente hoy en día, debido a que es muy común para una aplicación tener múltiples IU, o para sus clientes o usuarios, que le solicitan que elimine una IU y la remplace con otra. Por ejemplo, usted puede desarrollar una aplicación Win32 (un programa en Visual Basic) y entonces solicitársele remplazarla con una página HTML., quizás usando tecnología ASP. Una de las mayores dificultades y factores importantes cuando desarrollamos aplicaciones cliente/servidor es mantener una separación completa entre la presentación, la lógica de negocios y los servicios de datos. Es muy tentador para los desarrolladores mezclar una o más capas; poniendo alguna validación u otro proceso de negocios dentro de la capa de presentación en vez de en la capa de negocios. Capa de Negocios. Toda aplicación tiene código para implementar reglas de negocios, procesos relacionados a los datos o cálculos y otras actividades relativas a los negocios. Colectivamente este código es considerado para formar la capa de negocios. Otra vez, uno de los principios del diseño lógico cliente/servidor, la lógica de negocios debe mantenerse separada de la capa de

presentación y de los servicios de datos. Esto no significa necesariamente que la lógica de negocios está en cualquier parte, por el contrario, esta separación es en un sentido lógico. Hay muchas formas de separar la lógica de negocios. En términos orientados a objetos, usted debería encapsular la lógica de negocios en un conjunto de objetos o componentes que no contienen presentación o código de servicios de datos. Teniendo separada lógicamente su lógica de negocios de ambas, la capa de presentación y servicios de datos, usted ganará en flexibilidad en término de donde usted puede almacenar físicamente la lógica de negocios. Por ejemplo, usted puede seleccionar almacenar la lógica de negocios sobre cada estación de cliente, u optar por ejecutar la lógica de negocios sobre un servidor de aplicaciones, permitiendo a todos los clientes acceder a un recurso centralizado. Los objetos de negocios son diseñados para reflejar o representar sus negocios. Ellos se convierten en un modelo de sus entidades de negocios e interrelaciones. Esto incluye tanto objetos físicos como conceptos abstractos. Estos son algunos ejemplos de objetos del mundo real: un empleado, un cliente, un producto, una orden de compra. Todos estos son objetos en el mundo físico, y la idea en su totalidad detrás de usar objetos de negocios de software, es crear una representación de los mismos objetos dentro de su aplicación. Sus aplicaciones pueden hacer que estos objetos interactúen unos con otros como ellos lo hacen en el mundo real. Por ejemplo, un empleado puede crear una orden de compra a un cliente que contiene una lista de productos. Siguiendo esta lógica usted puede crear objetos de negocios de una orden conteniendo el código necesario para administrarse a si mismo, así usted nunca necesitará replicar código para crear ordenes, usted solo usará el objeto. Similarmente, un objeto cliente contiene y administra sus propios datos. Un buen diseño de un objeto cliente contiene todos los datos y rutinas necesitadas para representarlo a través del negocio completo, y puede ser usado a través de toda la aplicación de ese negocio. No toda la lógica de negocio es la misma. Alguna lógica de negocio es un proceso intensivo de datos, requiriendo un eficiente y rápido acceso a la base de datos. Otras no requieren un frecuente acceso a los datos, pero es de uso frecuente por una interfase de usuario robusta para la validación en la entrada de campos u otras interacciones de usuarios. Si nosotros necesitamos una validación al nivel de pantallas y quizás cálculos en tiempo real u otra lógica de negocios, pudiéramos considerar este tipo de lógica de negocios para ser parte de la IU, ya que en su mayor parte es usada por la interfase de usuario. Una alternativa de solución es dividir la capa de lógica de negocios en dos:
• •

Objetos de negocios de la IU. Objetos de negocios de datos.

Un ejemplo del objeto Empleado de la capa objetos de negocios de la IU proveerá propiedades y métodos para usar por el diseñador de la interfase de usuario. Ejemplo de propiedades y métodos pudieran ser: IDEmpleado, Nombre, Dirección, etc., y como métodos crear una de compra, etc. El objeto Empleado de la capa de objetos de negocios de

datos será responsable de los mecanismos de persistencias, interactuar con la base de datos. Los objetos de esta capa son considerados sin estado, solo poseen métodos.

Capa de Servicios de Datos. Muchas aplicaciones interactúan con datos, los almacenan en alguna forma de bases de datos. Hay algunas funciones básicas que son comunes a todos los procesos. Estas incluyen:
• • • •

Crear datos, leer datos, actualizar datos y eliminar datos.

Adicionalmente, nosotros tenemos servicios más avanzados disponibles, tales como: búsquedas, ordenamientos, filtrados, etc. Ejemplo de Aplicación Cliente/Servidor. Especificaciones Técnicas. Nuestro ejemplo fue desarrollado con Microsoft Visual Basic 6.0 y la base de datos fue elaborada en Microsoft Access 2000. El mismo carece de complejidad, la única intención ha sido la de mostrar cómo se desarrolla una aplicación cliente/servidor empleando un diseño distribuido. Es suficiente con una sola estación de trabajo que tenga instalado el sistema operativo Microsoft Windows 2000 para su ejecución, aunque pudiera esparcirse por varias computadoras en una red. Descripción. La aplicación cuenta con una simple interfase como se muestra en la siguiente figura:

Permitiendo dos funciones básicas la de crear nuevos empleados y borrar, tal como se muestran en las figuras siguientes:

Figure 1 Borrar un empleado

Figure 2 Adicionar un empleado La aplicación cuenta con una simple interfase permitiendo dos funciones básicas la de crear nuevos empleados y borrar. Para un mayor control de la aplicación se le ha incorporado a la capa de negocios la seguridad a través de un objeto Session. Esto permite aislar al desarrollador de la interfase de usuario de esta responsabilidad. De esta forma logramos una mayor autonomía de la capa de negocios. Cuando se pretende acceder al objeto de negocio Employee, este chequeara si el objeto Session ya ha sido creado, de no estarlo automáticamente lanzara una ventana de autenticación para la creación del objeto, por lo que al destruirse el objeto Employee se destruirá automáticamente el objeto Session. Por lo que hemos creado este objeto Session justamente al inicio de la aplicación, limitando el acceso a usuarios no deseados. El objeto Session puede crearse a través del siguiente segmento de código al comenzar la aplicación en un módulo de código: Set Session = New SecurityObject.Session Una vez ejecutada la sentencia anterior se mostraría la siguiente ventana:

Figure 1 Ventana de autenticación Diagrama de clases

Diagrama de Componentes

3.2 DISEÑO DE PROCESAMIENTO DE DATOS
En el diseño de bases de se debe considerar el problema de cómo distribuir la información entre diferentes sitios. Existen razones organizacionales las cuales determinan en gran medida lo anterior. Sin embargo, cuando se busca eficiencia en el acceso a la información, se deben abordar dos problemas relacionados. Primero, como fragmentar la información. Segundo, como asignar cada fragmento entre los diferentes sitios de la red. En el diseño de la BDD también es importante considerar si la información está replicada, es decir, si existen copias múltiples del mismo dato y, en este caso, como mantener la consistencia de la información. Finalmente, una parte importante en el diseño de una BDD se refiere al manejo del directorio. Si existen únicamente usuarios globales, se debe manejar un solo directorio global. Sin embargo, si existen también usuarios locales, el directorio combina información local con información global. Una base de datos correctamente diseñada permite obtener acceso a información exacta y actualizada. Puesto que un diseño correcto es esencial para lograr los objetivos fijados para la base de datos, parece lógico emplear el tiempo que sea necesario en aprender los

principios de un buen diseño ya que, en ese caso, es mucho más probable que la base de datos termine adaptándose a sus necesidades y pueda modificarse fácilmente. Una base de datos correctamente diseñada permite obtener acceso a información exacta y actualizada. Puesto que un diseño correcto es esencial para lograr los objetivos fijados para la base de datos, parece lógico emplear el tiempo que sea necesario en aprender los principios de un buen diseño ya que, en ese caso, es mucho más probable que la base de datos termine adaptándose a sus necesidades y pueda modificarse fácilmente. En este artículo se proporcionan instrucciones para preparar una base de datos. Aprenderá a decidir qué información necesita, a dividir la información en las tablas y columnas adecuadas y a relacionar las tablas entre sí. Debe leer este artículo antes de crear la primera base de datos. Algunos términos sobre bases de datos que debe conocer Microsoft Office Access 2007 organiza la información en tablas, que son listas y columnas similares a las de los libros contables o a las de las hojas de cálculo de Microsoft Office Excel 2007. Una base de datos simple puede que sólo contenga una tabla, pero la mayoría de las bases de datos necesitan varias tablas. Por ejemplo, podría tener una tabla con información sobre productos, otra con información sobre pedidos y una tercera con información sobre clientes.

Cada fila recibe también el nombre de registro y cada columna se denomina también campo. Un registro es una forma lógica y coherente de combinar información sobre alguna cosa. Un campo es un elemento único de información: un tipo de elemento que aparece en cada registro. En la tabla Products (Productos), por ejemplo, cada fila o registro contendría información sobre un producto, y cada columna contendría algún dato sobre ese producto, como su nombre o el precio.

¿Qué es un buen diseño de base de datos? El proceso de diseño de una base de datos se guía por algunos principios. El primero de ellos es que se debe evitar la información duplicada o, lo que es lo mismo, los datos redundantes, porque malgastan el espacio y aumentan la probabilidad de que se produzcan errores e incoherencias. El segundo principio es que es importante que la información sea correcta y completa. Si la base de datos contiene información incorrecta, los informes que recogen información de la base de datos contendrán también información incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarán mal fundamentadas. Un buen diseño de base de datos es, por tanto, aquél que:
• • • •

Divide la información en tablas basadas en temas para reducir los datos redundantes. Proporciona a Access la información necesaria para reunir la información de las tablas cuando así se precise. Ayuda a garantizar la exactitud e integridad de la información. Satisface las necesidades de procesamiento de los datos y de generación de informes.

El proceso de diseño El proceso de diseño consta de los pasos siguientes:

Determinar la finalidad de la base de datos

Esto le ayudará a estar preparado para los demás pasos.

Buscar y organizar la información necesaria

Reúna todos los tipos de información que desee registrar en la base de datos, como los nombres de productos o los números de pedidos.

Dividir la información en tablas

Divida los elementos de información en entidades o temas principales, como Productos o Pedidos. Cada tema pasará a ser una tabla.

Convertir los elementos de información en columnas

Decida qué información desea almacenar en cada tabla. Cada elemento se convertirá en un campo y se mostrará como una columna en la tabla. Por ejemplo, una tabla Empleados podría incluir campos como Apellido y Fecha de contratación.

Especificar claves principales

Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar inequívocamente cada fila, como Id. de producto o Id. de pedido.

Definir relaciones entre las tablas

Examine cada tabla y decida cómo se relacionan los datos de una tabla con las demás tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las relaciones según sea necesario.

Ajustar el diseño

Analice el diseño para detectar errores. Cree las tablas y agregue algunos registros con datos de ejemplo. Compruebe si puede obtener los resultados previstos de las tablas. Realice los ajustes necesarios en el diseño.

Aplicar las reglas de normalización

Aplique reglas de normalización de los datos para comprobar si las tablas están estructuradas correctamente. Realice los ajustes necesarios en las tablas. Determinar la finalidad de la base de datos Es conveniente plasmar en papel el propósito de la base de datos: cómo piensa utilizarla y quién va a utilizarla. Para una pequeña base de datos de un negocio particular, por ejemplo, podría escribir algo tan simple como "La base de datos de clientes contiene una lista de información de los clientes para el envío masivo de correo y la generación de informes". Si la base de datos es más compleja o la utilizan muchas personas, como ocurre normalmente en un entorno corporativo, la finalidad podría definirse fácilmente en uno o varios párrafos y debería incluir cuándo y cómo va a utilizar cada persona la base de datos. La idea es desarrollar una declaración de intenciones bien definida que sirva de referencia durante todo el proceso de diseño. Esta declaración de intenciones le permitirá centrarse en los objetivos a la hora de tomar decisiones. Buscar y organizar la información necesaria Para buscar y organizar la información necesaria, empiece con la información existente. Por ejemplo, si registra los pedidos de compra en un libro contable o guarda la información de los clientes en formularios en papel en un archivador, puede reunir esos documentos y enumerar cada tipo de información que contienen (por ejemplo, cada casilla de un formulario). Si no dispone de formularios, imagine que tiene que diseñar uno para registrar la información de los clientes. ¿Qué información incluiría en el formulario? ¿Qué casillas crearía? Identifique cada uno de estos elementos y cree un listado. Suponga, por ejemplo, que guarda la lista de clientes en fichas. Cada ficha podría contener un nombre de cliente, su dirección, ciudad, provincia, código postal y número de teléfono. Cada uno de estos elementos representa una columna posible de una tabla.

Cuando prepare esta lista, no se preocupe si no es perfecta al principio. Simplemente, enumere cada elemento que se le ocurra. Si alguien más va a utilizar la base de datos, pídale también su opinión. Más tarde podrá ajustar la lista. A continuación, considere los tipos de informes o la correspondencia que desea producir con la base de datos. Por ejemplo, tal vez desee crear un informe de ventas de productos que contenga las ventas por región, o un informe de resumen de inventario con los niveles de inventario de los productos. Es posible que también desee generar cartas modelo para enviárselas a los clientes con un anuncio de una actividad de ventas o una oferta. Diseñe el informe en su imaginación y piense cómo le gustaría que fuera. ¿Qué información incluiría en el informe? Cree un listado de cada elemento. Haga lo mismo para la carta modelo y para cualquier otro informe que tenga pensado crear.

Detenerse a pensar en los informes y en la correspondencia que desea crear le ayudará a identificar los elementos que necesita incluir en la base de datos. Suponga, por ejemplo, que ofrece a sus clientes la oportunidad de inscribirse o borrarse de las actualizaciones periódicas de correo electrónico y desea imprimir un listado de los que han decidido inscribirse. Para registrar esa información, agrega una columna "Enviar correo electrónico" a la tabla de clientes. Para cada cliente, puede definir el campo en Sí o No. La necesidad de enviar mensajes de correo electrónico a los clientes implica la inclusión de otro elemento. Cuando sepa que un cliente desea recibir mensajes de correo electrónico, tendrá que conocer también la dirección de correo electrónico a la que éstos deben enviarse. Por tanto, tendrá que registrar una dirección de correo electrónico para cada cliente. Parece lógico crear un prototipo de cada informe o listado de salida y considerar qué elementos necesita para crear el informe. Por ejemplo, cuando examine una carta modelo, puede que se le ocurran algunas ideas. Si desea incluir un saludo (por ejemplo, las abreviaturas "Sr." o "Sra." con las que comienza un saludo), tendrá que crear un elemento de saludo. Además, tal vez desee comenzar las cartas con el saludo "Estimado Sr. García",

en lugar de "Estimado Sr. Miguel Ángel García". Esto implicaría almacenar el apellido independientemente del nombre. Un punto clave que hay que recordar es que debe descomponer cada pieza de información en sus partes lógicas más pequeñas. En el caso de un nombre, para poder utilizar el apellido, dividirá el nombre en dos partes: el nombre y el apellido. Para ordenar un informe por nombre, por ejemplo, sería útil que el apellido de los clientes estuviera almacenado de forma independiente. En general, si desea ordenar, buscar, calcular o generar informes a partir de un elemento de información, debe incluir ese elemento en su propio campo. Piense en las preguntas que le gustaría que la base de datos contestara. Por ejemplo, ¿cuántas ventas de un determinado producto se cerraron el pasado mes? ¿Dónde viven sus mejores clientes? ¿Quién es el proveedor del producto mejor vendido? Prever esas preguntas le ayudará a determinar los elementos adicionales que necesita registrar. Dividir la información en tablas Para dividir la información en tablas, elija las entidades o los temas principales. Por ejemplo, después de buscar y organizar la información de una base de datos de ventas de productos, la lista preliminar podría ser similar a la siguiente:

Las entidades principales mostradas aquí son los productos, los proveedores, los clientes y los pedidos. Por tanto, parece lógico empezar con estas cuatro tablas: una para los datos sobre los productos, otra para los datos sobre los proveedores, otra para los datos sobre los clientes y otra para los datos sobre los pedidos. Aunque esto no complete la lista, es un buen punto de partida. Puede seguir ajustando la lista hasta obtener un diseño correcto. Cuando examine por primera vez la lista preliminar de elementos, podría estar tentado a incluirlos todos ellos en una sola tabla en lugar de en las cuatro tablas mostradas en la ilustración anterior. A continuación le explicaremos por qué eso no es una buena idea. Considere por un momento la tabla que se muestra a continuación:

En este caso, cada fila contiene información sobre el producto y su proveedor. Como hay muchos productos del mismo proveedor, la información del nombre y la dirección del proveedor debe repetirse muchas veces, con lo que se malgasta el espacio en disco. Registrar la información del proveedor una sola vez en una tabla Proveedores distinta y luego vincular esa tabla a la tabla Productos es una solución mucho mejor. Otro problema de este diseño surge cuando es necesario modificar la información del proveedor. Suponga, por ejemplo, que necesita cambiar la dirección de un proveedor. Como ésta aparece en muchos lugares, podría sin querer cambiar la dirección en un lugar y olvidarse de cambiarla en los demás lugares. Ese problema se resuelve registrando la información del proveedor en un único lugar. Cuando diseñe la base de datos, intente registrar siempre cada dato una sola vez. Si descubre que está repitiendo la misma información en varios lugares, como la dirección de un determinado proveedor, coloque esa información en una tabla distinta. Por último, suponga que el proveedor Bodega Sol sólo suministra un producto y desea eliminar ese producto pero conservar el nombre del proveedor y la información de dirección. ¿Cómo eliminaría el producto sin perder la información del proveedor? No puede. Como cada registro contiene datos sobre un producto, además de datos sobre un proveedor, no puede eliminar unos sin eliminar los otros. Para mantener estos datos separados, debe dividir la tabla en dos: una tabla para la información sobre los productos y otra tabla para la información sobre los proveedores. Al eliminar un registro de producto sólo se eliminarían los datos del producto y no los datos del proveedor. Una vez seleccionado el tema representado por una tabla, las columnas de esa tabla deben almacenar datos únicamente sobre ese tema. Por ejemplo, la tabla de productos sólo debe contener datos de productos. Como la dirección del proveedor es un dato del proveedor, pertenece a la tabla de proveedores. Convertir los elementos de información en columnas Para determinar las columnas de una tabla, decida qué información necesita registrar sobre el tema representado por la tabla. Por ejemplo, para la tabla Clientes, una buena lista de columnas iniciales sería Nombre, Dirección, Ciudad-Provincia-Código postal, Enviar correo electrónico, Saludo y Correo electrónico. Cada registro de la tabla contiene el mismo número de columnas, por lo que puede almacenar información sobre el nombre, dirección, ciudad-provincia-código postal, envío de correo electrónico, saludo y dirección de correo electrónico para cada registro. Por ejemplo, la columna de dirección podría contener las

direcciones de los clientes. Cada registro contendrá datos sobre un cliente y el campo de dirección, la dirección de ese cliente. Cuando haya determinado el conjunto inicial de columnas para cada tabla, puede ajustar con mayor precisión las columnas. Por ejemplo, tiene sentido almacenar los nombres de los clientes en dos columnas distintas (el nombre y el apellido) para poder ordenar, buscar e indizar por esas columnas. De igual forma, la dirección consta en realidad de cinco componentes distintos: dirección, ciudad, provincia, código postal y país o región, y parece lógico también almacenarlos en columnas distintas. Si desea realizar, por ejemplo, una búsqueda o una operación de ordenación o filtrado por provincia, necesita que la información de provincia esté almacenada en una columna distinta. Debe considerar también si la base de datos va a contener información sólo de procedencia nacional o internacional. Por ejemplo, si piensa almacenar direcciones internacionales, es preferible tener una columna Región en lugar de Provincia, ya que esa columna puede incluir provincias del propio país y regiones de otros países o regiones. De igual forma, es más lógico incluir una columna Región en lugar de Comunidad Autónoma si va a almacenar direcciones internacionales. En la lista siguiente se incluyen algunas sugerencias para determinar las columnas de la base de datos.

No incluya datos calculados

En la mayoría de los casos, no debe almacenar el resultado de los cálculos en las tablas. En lugar de ello, puede dejar que Access realice los cálculos cuando desee ver el resultado. Suponga, por ejemplo, que tiene un informe Productos bajo pedido que contiene el subtotal de unidades de un pedido para cada categoría de producto de la base de datos. Sin embargo, no hay ninguna tabla que contenga una columna de subtotal Unidades en pedido. La tabla Productos contiene una columna Unidades en pedido que almacena las unidades incluidas en un pedido de cada producto. Con esos datos, Access calcula el subtotal cada vez que se imprime el informe, pero el subtotal propiamente dicho no debe almacenarse en una tabla.

Almacene la información en sus partes lógicas más pequeñas

Puede ceder a la tentación de habilitar un único campo para los nombres completos o para los nombres de productos junto con sus descripciones. Si combina varios tipos de información en un campo, será difícil recuperar datos individuales más adelante. Intente dividir la información en partes lógicas. Por ejemplo, cree campos distintos para el nombre y el apellido, o para el nombre del producto, la categoría y la descripción.

Una vez ajustadas las columnas de datos de cada tabla, ya puede seleccionar la clave principal de cada tabla. Especificar claves principales Cada tabla debe incluir una columna o conjunto de columnas que identifiquen inequívocamente cada fila almacenada en la tabla. Ésta suele ser un número de identificación exclusivo, como un número de identificador de empleado o un número de serie. En la terminología de bases de datos, esta información recibe el nombre de clave principal de la tabla. Access utiliza los campos de clave principal para asociar rápidamente datos de varias tablas y reunir automáticamente esos datos. Si ya tiene un identificador exclusivo para una tabla, como un número de producto que identifica inequívocamente cada producto del catálogo, puede utilizar ese identificador como clave principal de la tabla, pero sólo si los valores de esa columna son siempre diferentes para cada registro. No puede tener valores duplicados en una clave principal. Por ejemplo, no utilice los nombres de las personas como clave principal, ya que los nombres no son exclusivos. Es muy fácil que dos personas tengan el mismo nombre en la misma tabla. Una clave principal siempre debe tener un valor. Si el valor de una columna puede quedar sin asignar o vacío (porque no se conoce) en algún momento, no puede utilizarlo como componente de una clave principal. Debe elegir siempre una clave principal cuyo valor no cambie. En una base de datos con varias tablas, la clave principal de una tabla se puede utilizar como referencia en las demás tablas. Si la clave principal cambia, el cambio debe aplicarse también a todos los lugares donde se haga referencia a la clave. Usar una clave principal que no cambie reduce la

posibilidad de que se pierda su sincronización con las otras tablas en las que se hace referencia a ella. A menudo, se utiliza como clave principal un número único arbitrario. Por ejemplo, puede asignar a cada pedido un número de pedido distinto. La única finalidad de este número de pedido es identificar el pedido. Una vez asignado, nunca cambia. Si piensa que no hay ninguna columna o conjunto de columnas que pueda constituir una buena clave principal, considere la posibilidad de utilizar una columna que tenga el tipo de datos Autonumérico. Cuando se utiliza el tipo de datos Autonumérico, Access asigna automáticamente un valor. Este tipo de identificador no es "fáctico", es decir, no contiene información objetiva sobre la fila que representa. Los identificadores de este tipo son perfectos para usarlos como claves principales, ya que no cambian. Una clave principal que contiene datos sobre una fila, como un número de teléfono o el nombre de un cliente, es más probable que cambie, ya que la propia información "fáctica" podría cambiar.

Una columna establecida en el tipo de datos Autonumérico suele constituir una buena clave principal. No hay dos identificadores de producto iguales.

En algunos casos, tal vez considere conveniente utilizar dos o más campos juntos como clave principal de una tabla. Por ejemplo, una tabla Detalles de pedidos que contenga artículos de línea de pedidos tendría dos columnas en su clave principal: Id. de pedido e Id. de producto. Cuando una clave principal está formada por más de una columna se denomina clave compuesta. Para la base de datos de ventas de productos, puede crear una columna autonumérica para cada una de las tablas que funcione como clave principal: IdProducto para la tabla Productos, IdPedido para la tabla Pedidos, IdCliente para la tabla Clientes e IdProveedores para la tabla Proveedores.

Crear una relación de uno a uno Otro tipo de relación es la relación de uno a uno. Suponga, por ejemplo, que necesita registrar información complementaria sobre productos que apenas va a necesitar o que sólo se aplica a unos pocos productos. Como no necesita la información con frecuencia, y como almacenar la información en la tabla Productos crearía un espacio vacío para todos los productos que no necesitan esa información, la coloca en una tabla distinta. Al igual que en la tabla Productos, utiliza el identificador de producto como clave principal. La relación entre esta tabla complementaria y la tabla Productos es una relación de uno a uno. Para cada registro de la tabla Productos hay un único registro coincidente en la tabla complementaria. Cuando identifique esta relación, ambas tablas deben compartir un campo común. Cuando necesite crear una relación de uno a uno en la base de datos, considere si puede incluir la información de las dos tablas en una tabla. Si no desea hacer eso por algún motivo (quizás porque se crearía una gran cantidad de espacio vacío), puede representar esa relación en su diseño guiándose por las pautas siguientes:
• •

Si las dos tablas tienen el mismo tema, probablemente podrá definir la relación utilizando la misma clave principal en ambas tablas. Si las dos tablas tienen temas diferentes con claves principales distintas, elija una de las tablas (cualquiera de ellas) e inserte su clave principal en la otra tabla como clave externa.

Determinar las relaciones entre las tablas le ayudará a asegurarse de que tiene las tablas y columnas correctas. Cuando existe una relación de uno a uno o de uno a varios, las tablas implicadas deben compartir una o varias columnas comunes. Cuando la relación es de varios a varios, se necesita una tercera tabla para representar la relación.

Ajustar el diseño Cuando tenga las tablas, los campos y las relaciones necesarias, debe crear y rellenar las tablas con datos de ejemplo y probar que funcionan con la información: creando consultas, agregando nuevos registros, etc. Esto le permitirá encontrar posibles problemas, como la necesidad de agregar una columna que olvidó insertar durante la fase de diseño, o dividir una tabla en dos tablas para eliminar datos duplicados. Compruebe si puede usar la base de datos para obtener las respuestas que desea. Cree formularios e informes provisionales y compruebe si muestran los datos según lo previsto. Compruebe si existen datos duplicados innecesarios y, si encuentra alguno, modifique el diseño para eliminar la duplicación. Cuando pruebe la base de datos inicial, probablemente se dará cuenta de que se puede mejorar. Éstas son algunas comprobaciones que puede hacer:

• •

¿Olvidó incluir alguna columna? Y, en ese caso, ¿pertenece la información a alguna de las tablas existentes? Si se trata de información sobre otro tema, tal vez necesite crear otra tabla. Cree una columna para cada elemento de información que desee registrar. Si la información no se puede calcular a partir de otras columnas, es probable que necesite una nueva columna para esa información. ¿Hay alguna columna innecesaria porque se puede calcular con los campos existentes? Si un elemento de información se puede calcular a partir de otras columnas existentes (como un descuento calculado a partir del precio de venta al público), normalmente es preferible que se calcule en lugar de crear una nueva columna. ¿Ha proporcionada información duplicada en alguna de las tablas? Si es así, probablemente tendrá que dividir la tabla en dos tablas que tengan una relación de uno a varios. ¿Tiene tablas con muchos campos, un número limitado de registros y muchos campos vacíos en cada registro? En ese caso, considere la posibilidad de volver a diseñar la tabla de forma que tenga menos campos y más registros. ¿Ha dividido cada elemento de información en sus partes lógicas más pequeñas? Si necesita generar informes, ordenar, buscar o calcular a partir de un elemento de información, incluya ese elemento en su propia columna. ¿Contiene cada columna datos sobre el tema de la tabla? Si una columna no contiene información sobre el tema de la tabla, pertenece a una tabla distinta. ¿Están representadas todas las relaciones entres las tablas mediante campos comunes o mediante una tercera tabla? Las relaciones de uno a uno y de uno a

varios requieren columnas comunes. Las relaciones de varios a varios requieren una tercera tabla. Ajustar la tabla Productos Suponga que cada producto de la base de datos de ventas de productos pertenece a una categoría general, como bebidas, condimentos o marisco. La tabla Productos podría incluir un campo que mostrara la categoría de cada producto. Suponga que después de examinar y ajustar el diseño de la base de datos, decide almacenar una descripción de la categoría junto con su nombre. Si agrega un campo Descripción de categoría a la tabla Productos, tendría que repetir la descripción de cada categoría para cada producto perteneciente a dicha categoría, lo cual no es una buena solución. Una solución mejor es convertir las categorías en un nuevo tema de la base de datos, con su propia tabla y su propia clave principal. A continuación, puede agregar la clave principal de la tabla Categorías a la tabla Productos como clave externa. Las tablas Categorías y Productos tienen una relación de uno a varios: una categoría puede incluir varios productos, pero un producto pertenece únicamente a una categoría. Cuando examine las estructuras de las tablas, compruebe si existen grupos extensibles. Por ejemplo, considere una tabla con las siguientes columnas:
• • • • • • • •

Id. de producto Nombre Id1 de producto Nombre1 Id2 de producto Nombre2 Id3 de producto Nombre3

Aquí, cada producto es un grupo extensible de columnas que se diferencia de los demás solamente por el número agregado al final del nombre de columna. Si tiene columnas numeradas de esta forma, debe revisar el diseño. Un diseño como éste tiene varios defectos. Para empezar, obliga a crear un límite máximo de número de productos. En cuanto supere ese límite, deberá agregar un nuevo grupo de columnas a la estructura de la tabla, lo que supone una tarea administrativa importante. Otro problema es que se malgastará el espacio en aquellos proveedores que tengan menos que el número máximo de productos, ya que las columnas adicionales quedarán en blanco. El defecto más grave de este diseño es que muchas tareas son difíciles de realizar, como ordenar o indizar la tabla por identificador de producto o nombre.

Siempre que aparezcan grupos extensibles, revise atentamente el diseño con vistas a dividir la tabla en dos. En el ejemplo anterior, sería conveniente usar dos tablas, una para proveedores y otra para productos, vinculadas por el identificador de proveedor. Aplicar las reglas de normalización En el siguiente paso del diseño, puede aplicar las reglas de normalización de datos (denominadas a veces simplemente reglas de normalización). Estas reglas sirven para comprobar si las tablas están estructuradas correctamente. El proceso de aplicar las reglas al diseño de la base de datos se denomina normalizar la base de datos o, simplemente, normalización. La normalización es más útil una vez representados todos los elementos de información y después de haber definido un diseño preliminar. La idea es asegurarse de que se han dividido los elementos de información en las tablas adecuadas. Lo que la normalización no puede hacer es garantizar que se dispone de los elementos de datos correctos para empezar a trabajar. Las reglas se aplican consecutivamente en cada paso para garantizar que el diseño adopta lo que se conoce como "forma normal". Hay cinco formas normales ampliamente aceptadas: de la primera forma normal a la quinta forma normal. En este artículo se abordan las tres primeras, porque todas ellas son necesarias para la mayoría de los diseños de base de datos. Primera forma normal La primera forma normal establece que en cada intersección de fila y columna de la tabla existe un valor y nunca una lista de valores. Por ejemplo, no puede haber un campo denominado Precio en el que se incluya más de un precio. Si considera cada intersección de filas y columnas como una celda, cada celda sólo puede contener un valor. Segunda forma normal La segunda forma normal exige que cada columna que no sea clave dependa por completo de toda la clave principal y no sólo de parte de la clave. Esta regla se aplica cuando existe una clave principal formada por varias columnas. Suponga, por ejemplo, que existe una tabla con las siguientes columnas, de las cuales Id. de pedido e Id. de producto forman la clave principal:
• • •

Id. de pedido (clave principal) Id. de producto (clave principal) Nombre de producto

Este diseño infringe los requisitos de la segunda forma normal, porque Nombre de producto depende de Id. de producto, pero no de Id. de pedido, por lo que no depende de toda la clave principal. Debe quitar Nombre de producto de la tabla, ya que pertenece a una tabla diferente (a la tabla Productos).

Tercera forma normal La tercera forma normal exige no sólo que cada columna que no sea clave dependa de toda la clave principal, sino también que las columnas que no sean clave sean independientes unas de otras. O dicho de otra forma: cada columna que no sea clave debe depender de la clave principal y nada más que de la clave principal. Por ejemplo, considere una tabla con las siguientes columnas:
• • • •

IdProducto (clave principal) Nombre PVP Descuento

Suponga que la columna Descuento depende del precio de venta al público (PVP) sugerido. Esta tabla infringe los requisitos de la tercera forma normal porque una columna que no es clave, la columna Descuento, depende de otra columna que no es clave, la columna PVP. La independencia de las columnas implica que debe poder cambiar cualquier columna que no sea clave sin que ninguna otra columna resulte afectada. Si cambia un valor en el campo PVP, la columna Descuento cambiaría en consecuencia e infringiría esa regla. En este caso, la columna Descuento debe moverse a otra tabla cuya clave sea PVP.

3.3 DISEÑO DE INTERFAZ DE USUARIO
Conceptos Generales La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos hardware y software de una computadora que presentan información al usuario y le permiten interactuar con la información y con el computadora. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software. Si la IU está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, ya que el usuario habitualmente tiende a culparse a sí mismo por no saber usar el objeto. Los programas son usados por usuarios con distintos niveles de conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario.

Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseñador (analogía de la construcción de una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a través de su experiencia. El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones adecuadas para modificar el mismo. Los modelos subyacen en la interacción con las computadoras, de ahí su importancia.

Modelo del usuario: El usuario tiene su visión personal del sistema, y espera que éste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudiándolo, ya sea realizando tests de usabilidad, entrevistas, o a través de una realimentación. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo. Para ello son de gran utilidad las metáforas, que asocian un dominio nuevo a uno ya conocido por el usuario. Un ejemplo típico es la metáfora del escritorio, común a la mayoría de las interfaces gráficas actuales. Modelo del diseñador: El diseñador mezcla las necesidades, ideas, deseos del usuario y los materiales de que dispone el programador para diseñar un producto de software. Es un intermediario entre ambos. El modelo del diseñador describe los objetos que utiliza el usuario, su presentación al mismo y las técnicas de interacción para su manipulación. Consta de tres partes: presentación, interacción y relaciones entre los objetos (Figura 1). La presentación es lo que primero capta la atención del usuario, pero más tarde pasa a un segundo plano, y adquiere más importancia la interacción con el producto para poder satisfacer sus expectativas. La presentación no es lo más relevante y un abuso en la misma (por ejemplo, en el color) puede ser contraproducente, distrayendo al usuario. La segunda parte del modelo define las técnicas de interacción del usuario, a través de diversos dispositivos. La tercera es la más importante, y es donde el diseñador determina la metáfora adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia arriba. Una vez definida la metáfora y los objetos del interfaz, los aspectos visuales saldrán de una manera lógica y fácil.

Figura 1. Representación del modelo del diseñador: el look-and-feel iceberg, de IBM (1992)

Estos modelos deben estar claros para los participantes en el desarrollo de un producto, de forma que se consiga una interfaz atractiva y a la vez efectiva para el trabajo con el programa. Una interfaz no es simplemente una cara bonita; esto puede impresionar a primera vista pero decepcionar a la larga. Lo importante es que el programa se adapte bien al modelo del usuario, cosa que se puede comprobar utilizando el programa más allá de la primera impresión. Modelo del programador: Es el más fácil de visualizar, al poderse especificar formalmente. Está constituido por los objetos que manipula el programador, distintos de los que trata el usuario (ejemplo: el programador llama base de datos a lo que el usuario podría llamar agenda). Estos objetos deben esconderse del usuario. Los conocimientos del programador incluyen la plataforma de desarrollo, el sistema operativo, las herramientas de desarrollo y especificaciones. Sin embargo, esto no significa necesariamente que tenga la habilidad de proporcionar al usuario los modelos y metáforas más adecuadas. Muchos no consideran el modelo del usuario del programa, y sí sus propias expectativas acerca de cómo trabajar con la computadora.

Principios para el Diseño de Interfaces de Usuario Existen principios relevantes para el diseño e implementación de IU, ya sea para las IU gráficas, como para la Web. Anticipación Las aplicaciones deberían intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la información, recopilarla o invocar las herramientas que va a utilizar.

En la Figura 2 se ilustra como el procesador de texto se anticipa a las necesidades del usuario, proporcionando las características del texto seleccionado -fuente, tamaño, alineación, etc.- permitiendo que el usuario pueda modificarlas ágilmente. Autonomía La computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender rápidamente a usar la aplicación. Sin embargo, está comprobado que el entorno de trabajo debe tener ciertas cotas, es decir, ser explorable pero no azaroso.

En la Figura 3 se visualiza un diseño incorrecto de interfaz de usuario. La cantidad de opciones propuestas propone un grado de complejidad que no permite que el usuario pueda aprender a utilizar el sistema en forma progresiva. Es importante utilizar mecanismos indicadores de estado del sistema que mantengan a los usuarios alertas e informados. No puede existir autonomía en ausencia de control, y el control no puede ser ejercido sin información suficiente. Además, se debe mantener información del estado del sistema en ubicaciones fáciles de visualizar.

En la Figura 4 se ejemplifica una incorrecta disposición de componentes en la IU. El reloj no debe ser incorporado en el menú del sistema ya que aporta confusión al usuario. Para mantenerlo informado sería más adecuado colocarlo en la barra de estado del sistema. Percepción del Color Aunque se utilicen convenciones de color en la IU, se deberían usar otros mecanismos secundarios para proveer la información a aquellos usuarios con problemas en la visualización de colores

En la Figura 5 se representa un mecanismo secundario muy utilizado para ejecución de comandos: los comandos abreviados (shortcut-keys). Sin embargo la aplicación presenta un problema de inconsistencia ya que define combinaciones de teclas que difieren a lo esperado por el usuario, por ejemplo Alt+< en lugar de Alt+B. Valores por Defecto No se debe utilizar la palabra "Defecto" en una aplicación o servicio. Puede ser reemplazada por "Estándar" o "Definida por el Usuario", "Restaurar Valores Iniciales" o algún otro término especifico que describa lo que está sucediendo. Los valores por defecto deberían ser opciones inteligentes y sensatas. Además, los mismos tienen que ser fáciles de modificar. Consistencia Para lograr una mayor consistencia en la IU se requiere profundizar en diferentes aspectos que están catalogados en niveles. Se realiza un ordenamiento de mayor a menor consistencia:
1. Interpretación del comportamiento del usuario: la IU debe comprender el

2.

3.

4.

5.

6.

significado que le atribuye un usuario a cada requerimiento. Ejemplo: mantener el significado de las los comandos abreviados (shortcut-keys) definidos por el usuario. Estructuras invisibles: se requiere una definición clara de las mismas, ya que sino el usuario nunca podría llegar a descubrir su uso. Ejemplo: la ampliación de ventanas mediante la extensión de sus bordes. Pequeñas estructuras visibles: se puede establecer un conjunto de objetos visibles capaces de ser controlados por el usuario, que permitan ahorrar tiempo en la ejecución de tareas específicas. Ejemplo: ícono y/o botón para impresión. Una sola aplicación o servicio: la IU permite visualizar a la aplicación o servicio utilizado como un componente único. Ejemplo: La IU despliega un único menú, pudiendo además acceder al mismo mediante comandos abreviados. Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicación o servicio utilizado como un conjunto de componentes. Ejemplo: La IU se presenta como un conjunto de barras de comandos desplegadas en diferentes lugares de la pantalla, pudiendo ser desactivadas en forma independiente. Consistencia del ambiente: la IU se mantiene en concordancia con el ambiente de trabajo. Ejemplo: La IU utiliza objetos de control como menú es, botones de comandos de manera análoga a otras IU que se usen en el ambiente de trabajo.

7. Consistencia de la plataforma: La IU es concordante con la plataforma. Ejemplo:

La IU tiene un esquema basado en ventanas, el cual es acorde al manejo del sistema operativo Windows.

En la Figura 6 puede observarse la mejora en la consistencia de las pequeñas estructuras visibles (3.) para los sistemas gráficos basados en ventanas. La inclusión de la opción X para cerrar la ventana –operación comúnmente utilizada en estas aplicaciones- simplifica la operatividad del mismo. La inconsistencia en el comportamiento de componentes de la IU debe ser fácil de visualizar. Se debe evitar la uniformidad en los componentes de la IU. Los objetos deben ser consistentes con su comportamiento. Si dos objetos actúan en forma diferente, deben lucir diferentes. La única forma de verificar si la IU satisface las expectativas del usuario es mediante testeo.

Eficiencia del Usuario Se debe considerar la productividad del usuario antes que la productividad de la máquina. Si el usuario debe esperar la respuesta del sistema por un período prolongado, estas pérdidas de tiempo se pueden convertir en pérdidas económicas para la organización. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los problemas. Lo menú es y etiquetas de botones deberían tener las palabras claves del proceso.

En la Figura 7 se demuestra como una incorrecta definición de las palabras clave de las etiquetas de los botones de comando puede confundir al usuario. Los botones OK y Apply aparentan realizar el mismo proceso. Esto puede solucionarse suprimiendo uno de ellos si realizan la misma tarea o etiquetándolos con los nombres de los procesos específicos que ejecutan. Ley de Fitt

El tiempo para alcanzar un objetivo es una función de la distancia y tamaño del objetivo. Es por ello, que es conveniente usar objetos grandes para las funciones importantes.

En la Figura 8 se puede apreciar la relación entre los elementos de diseño de pantalla y su percepción visual. El número de elementos visuales que perciben son: en el caso a) 1 (el fondo); en b) 3 (la línea, lo que está encima y lo que está debajo); en c) son 5 (el espacio fuera del recuadro, el recuadro, la línea y el espacio encima y debajo de ésta); finalmente, en d) el número se eleva a 35, siguiendo el mismo criterio. Conclusión: cada elemento nuevo que se añade influye más de lo que se piensa en el usuario. Interfaces Explorables Siempre que sea posible se debe permitir que el usuario pueda salir ágilmente de la IU, dejando una marca del estado de avance de su trabajo, para que pueda continuarlo en otra oportunidad. Para aquellos usuarios que sean noveles en el uso de la aplicación, se deberá proveer de guías para realizar tareas que no sean habituales. Es conveniente que el usuario pueda incorporar elementos visuales estables que permitan, no solamente un desplazamiento rápido a ciertos puntos del trabajo que esté realizando, sino también un sentido de "casa" o punto de partida. La IU debe poder realizar la inversa de cualquier acción que pueda llegar a ser de riesgo, de esta forma se apoya al usuario a explorar el sistema sin temores.

Siempre se debe contar con un comando "Deshacer". Este suprimirá la necesidad de tener que contar con diálogos de confirmación para cada acción que realice en sistema. El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por ello que la IU debe tener un objeto fácil de accionar con el cual poder finalizar la aplicación. Objetos de Interfaz Humana Los objetos de interfaz humana no son necesariamente los objetos que se encuentran en los sistemas orientados a objetos. Estos pueden ser vistos, escuchados, tocados o percibidos de alguna forma. Además, estos objetos deberían ser entendibles, consistentes y estables.

En la Figura 9 se presentan barras de controles que simplifican la operación de un sistema. A través de las ilustraciones que poseen los mismos, el usuario puede aprender fácilmente su uso. Si se mantienen para estos botones las mismas asignaciones de procesos en diferentes sistemas, la comprensión del funcionamiento de los mismos se hace más sencilla. Uso de Metáforas Las buenas metáforas crean figuras mentales fáciles de recordar. La IU puede contener objetos asociados al modelo conceptual en forma visual, con sonido u otra característica perceptible por el usuario que ayude a simplificar el uso del sistema.

En la Figura 10 se compara la aplicación de metáforas en el desarrollo de una IU. En el primer caso, se utiliza incorrectamente la metáfora de una cámara de video para representar el procesamiento de un documento por una impresora. Se puede observar que el botón << carece de sentido, ya que no se puede volver atrás un trabajo que ya ha sido impreso. En el segundo caso, la metáfora de la agenda es utilizada correctamente para la implementación de una agenda electrónica. Curva de Aprendizaje El aprendizaje de un producto y su usabilidad no son mutuamente excluyentes. El ideal es que la curva de aprendizaje sea nula, y que el usuario principiante pueda alcanzar el dominio total de la aplicación sin esfuerzo. Reducción de Latencia Siempre que sea posible, el uso de tramas (multi-threading) permite colocar la latencia en segundo plano (background). Las técnicas de trabajo multitarea posibilitan el trabajo ininterrumpido del usuario, realizando las tareas de transmisión y computación de datos en segundo plano. Protección del Trabajo Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por error de su parte, problemas de transmisión de datos, de energía, o alguna otra razón inevitable. Auditoría del Sistema La mayoría de los navegadores de Internet (browsers), no mantienen información acerca de la situación del usuario en el entorno, pero para cualquier aplicación es conveniente conocer un conjunto de características tales como: hora de acceso al sistema, ubicación del

usuario en el sistema y lugares a los que ha accedido, entre otros. Además, el usuario debería poder salir del sistema y al volver a ingresar continuar trabajando en lugar dónde había dejado. Legibilidad Para que la IU favorezca la usabilidad del sistema de software, la información que se exhiba en ella debe ser fácil de ubicar y leer. Para lograr obtener este resultado se deben tener en cuenta alguna como: el texto que aparezca en la IU debería tener un alto contraste, se debe utilizar combinaciones de colores como el texto en negro sobre fondo blanco o amarillo suave. El tamaño de las fuentes tiene que ser lo suficientemente grande como para poder ser leído en monitores estándar. Es importante hacer clara la presentación visual (colocación/agrupación de objetos, evitar la presentación de excesiva información.

En la Figura 11 se describe una comparación de disposición de los objetos en pantalla. La figura de la izquierda, combina una disposición asimétrica de la información con un conjunto de colores que no facilita la lectura. La figura de la derecha realiza la presentación de la información utilizando una gama de colores homogénea y una alineación del texto que favorece a la legibilidad del mismo. Interfaces Visibles El uso de Internet, ha favorecido la implementación de interfaces invisibles. Esto significa que el usuario siempre ve una página específica, pero nunca puede conocer la totalidad del espacio de páginas de Internet. La navegación en las aplicaciones debe ser reducida a la mínima expresión. El usuario debe sentir que se mantiene en un único lugar y que el que va variando es su trabajo. Esto no solamente elimina la necesidad de mantener mapas u otras ayudas de navegación, sino que además brindan al usuario una sensación de autonomía.

Utilización de Prototipos en la Implementación de IU Niveles de Prototipado Se puede hacer una clasificación de los principales tipos de prototipos, variando su grado de complejidad, de acuerdo a las características que consideren y a su operabilidad para realizar simulaciones.

Prototipos Estáticos: son aquellos que no permiten la alteración de sus componentes, pero sirven para identificar y resolver problemas de diseño. En esta categoría se incluyen las presentaciones sobres reproductores, papel u otro medio de visualización. Prototipos Dinámicos: permiten la evaluación de un modelo del sistema sobre una estación de trabajo o una terminal. Estos prototipos involucran aspectos de diseño más detallados que los prototipos estáticos, incluyendo la validación del diseño del sistema en términos de requerimientos no funcionales, por ejemplo de performance. Prototipos Robustos: deben ser relativamente completos en la simulación de las características dinámicas de la interfaz (presentación de mensajes de error, entrada y edición de datos, etc.). Esta categoría puede ser utilizada para validar los objetivos de diseño.

• •

• •

El nivel de sofisticación del prototipo debería incrementarse a lo largo del proceso de diseño de interfaces de usuario. La información recolectada durante las tareas de análisis del sistema y la especificación de los requisitos del usuario constituyen los datos clave para el proceso de prototipación. Heurísticas para la Evaluación de IU Las heurísticas ayudan a poder analizar las IU y localizar problemas que afecten la utilización de las mismas. Algunas pautas para evaluar una IU son:
• • • • • • • • • •

Visibilidad del estado del sistema Semejanza del sistema al mundo real Control y libertad por parte del usuario Consistencia y estandarización Prevención de Errores Reconocimiento de acciones y opciones Flexibilidad y eficiencia en el uso Estética y diseño minimalista Reconocimiento de errores, diagnóstico y recuperación Ayuda y documentación

Para establecer medidas que indiquen la severidad de los problemas en el uso de las interfaces, se deben conocer los factores que determinan el grado de un problema:
• • • •

La frecuencia de ocurrencia. El impacto que causa la ocurrencia del problema. La persistencia del problema. El impacto en el mercado.

Medidas de severidad de un problema en la IU: 0: No puede llegar a considerarse un problema. 1: Es un problema "cosmético" que no necesita ser corregido a menos que se disponga tiempo extra en el proyecto. 2: Es un problema menor y su corrección puede tener baja prioridad. 3: Es un problema mayor y su corrección debería tener alta prioridad. 4: Es una catástrofe para la utilización de la aplicación y es imperativo corregir el error. Para la evaluación de los problemas en las IU es conveniente que contar con más de un evaluador; de esta forma los resultados son más confiables. Caso Práctico Para complementar los aspectos teóricos, se realiza una ejemplificación de una de las actividades propuestas por la metodología Métrica Versión 2 para el diseño de interfaces de usuario. La metodología Métrica Versión 2 contempla la simulación de diálogos de pantalla para la actividad EFS 4 "Definir Interfaces de Usuario", a partir de las principales funciones interactivas, eventos y consultas identificados en la fase de análisis. Siguiendo la metodología:
• • • •

Definir los formatos individuales de las pantallas utilizadas. Describir de modo detallado los diálogos entre pantallas y el encadenamiento entre las mismas. Determinar los diálogos que se consideran críticos. Realizar una maqueta dinámica.

Asimismo indica:
• •

Obtener una definición de los formatos de los informes generados. Definir los formularios utilizados (si fuera necesario).

Verificar si los diseños realizados están de acuerdo con los estándares de la unidad y obtener la validación y conformidad de los usuarios.

Para acotar el presente trabajo, se realiza un desarrollo del primer punto de la propuesta en la metodología, exponiendo algunos de los productos resultantes.

Definir los formatos individuales de las pantallas utilizadas.

Caso Práctico: Construcción de un sistema de Gestión de Alquiler de Automóviles (AGA 2000). Requisitos de interfaces de usuario:

La interfaz con el usuario se hará mediante pantallas con menús desplegables.

Se describe a modo de ejemplo, el formato de la pantalla principal del sistema AGA 2000 y sus componentes (Figura 12). Descripción de componentes Barra de Título: se utiliza para desplegar el título de la pantalla desplegada. Si la ventana está activa, la barra de título tendrá un color diferente al resto de las ventanas desplegadas. Menú Principal: contiene un conjunto de botones que permiten desplegar la totalidad de las pantallas del sistema. Usuario del Sistema: indica el nombre del usuario que está utilizando el sistema, el cual ha sido previamente ingresado con una contraseña como requisito para acceder al sistema. Reloj del Sistema: indica la hora actual del sistema. Área de Trabajo: es el lugar donde se despliegan las pantallas que son activadas a través del Menú Principal. Maximizar/Restaurar Ventana: botón que se utiliza para ampliar o reducir el tamaño de la pantalla. Minimizar Ventana: control que se utiliza para quitar de primer plano de trabajo una ventana, sin cerrarla. Cerrar Ventana: control que se usa para cerrar una ventana.

Puede utilizarse para la descripción de las pantallas, las operaciones que se especifican en los diagramas de la Historia de Vida de las Entidades del sistema anteriormente presentado (AGA 2000). Cada operación representa una pantalla diferente, por lo que se expondrán algunas de ellas (Figuras 13 y 14) con el objeto de ilustrar el diseño de las mismas. Opciones de Menú Avería Cliente Operaciones Alta avería, Actualización período Avería, Borrado de avería. Alta cliente, Modificar dirección, Emisión tarjeta, Cancelación tarjeta, Renovación tarjeta. Alta entrega, Borrar Entrega Alta entrega / vehículo, Borrar entrega / vehículo Alta fabricante, Actualizar datos Alta factura fabricante fabricante, Borrar factura

Entrega Entrega/Vehículo Fabricante Factura Fabricante Modelo Modelo/Pedido Oficina Pago Cliente Pago Fabricante Pedido

Alta modelo, Borrar modelo Alta modelo/pedido, Borrar modelo/pedido Alta oficina, Borrar oficina Alta pago cliente, Borrar pago cliente Alta pago fabricante, Borrar pago fabricante Alta pedido, Borrar pedido

Reserva vehículo Seguro

Alta reserva vehículo, Borrar reserva vehículo Alta seguro, Modificar porcentaje seguro, Borrar seguro

Ejemplos de pantalla para la operación de Alta de Fabricante y Alta de Pedidos

El encadenamiento de las pantallas está determinado a partir de la pantalla principal del sistema, permitiendo desplegar cualquiera de las pantallas utilizadas para las operaciones anteriormente descriptas. Dichas pantallas pueden ser activadas o cerradas en forma independiente.

BIBLIOGRAFÍA
• • • • • • • • •

MSDN Library – January 2001. o COM+ Overview for Microsoft Visual Basic Programmers. Rebecca M. Riordan. Designing Relational Database Systems. ISBN 0-7356-0634X. Rockford Lhotka. Visual Basic 6 Business Objects, Enterprise Design e Implementation. ISBN 1-861001-4-01. Ted Pattison. Programming Distributed Applications with COM+ and Visual Basic 6.0, Second Edition. ISBN 0-7356-1010-X. David A. Solomon, Mark Russinovich. Inside Microsoft Windows 2000. ISBN 07356-1021-5 Guy Eddon, Henry Eddon. Inside COM+ Base Services ISBN 0-7356-0728-1 Hernandez, Michael J. Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, Second Edition. Addison-Wesley Professional. 2003. Fleming, Candace C. von Halle, Barbara. Handbook of Relational Database Design. Addison-Wesley Professional. 1989. Riordan, Rebecca M. Designing Effective Database Systems. Addison-Wesley Professional. 2005. Guía de Estudio del Módulo III "Metodología de Construcción de Sistemas de Software" de la Maestría en Ingeniería del Software, Escuela de Posgrado, Instituto Tecnológico de Buenos Aires. Molich, R., y Nielsen, J.,"Improving a human computer dialogue", Communications of the ACM 33, 3 (March), pp 338-348, 1990. Molich, R., y Nielsen, J., "Heuristic evaluation of user interfaces", Proceedings of the ACM CHI´90 Conference, pp. 249-256, 1990. Molich, R., y Nielsen, J., "Enhancing the explanatory power of usability heuristics", Proceedings of the ACM CHI´94 Conference, pp. 152-158, 1994. Durrett, H.J., "General Approach to Rapid Prototyping",

• • • •

http://swt.edu/~hd01/4326/PROTOTYP.htm, 1997.

INTEGRATES: JAVIER ANTONIO ARTIGAS GÓMEZ JUAN PABLO GÓMEZ TOMAS BARUCH AGUIRRE HÉCTOR JASIEL MIRAVETE MORTERA GERZON SÁNCHEZ OSORIO