3.1 Diseo e implementacin de manejo de datos.

En nuestros das el vertiginoso avance de la informtica y las comunicaciones, con sus mayores exponentes Internet e Intranet, y la cada vez ms creciente demanda de la empresa de aplicaciones de calidad que den solucin a sus necesidades, ha hecho que las tcnicas tradicionales de diseo e implementacin de aplicaciones comiencen hacer insuficiente, por lo que un nuevo enfoque dedesarrollo se hace necesario. El presente trabajo tiene como objetivo principal lograr introducir al desarrollador en las nuevas tcnicas de diseo de aplicaciones distribuidas, para ello hemos divido el estudio en dos partes. Una primera est orientada al estudio de los componentes software, y al entorno normalizado de desarrollo COM+. En la segunda describimos un diseo de aplicaciones distribuidas cliente/servidorconcluyendo con la muestra de un ejemplo. Palabras Claves: Componentes, distribuidas y aplicaciones. Articulo de tipo : Acadmico 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 donde 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 dira al respecto?. El objetivo de la tecnologa de componentes software es construir aplicaciones complejas mediante ensamblado de mdulos (componentes) que han sido previamente

diseados por otras personas a fin de ser rehusados en mltiples aplicaciones. La ingeniera de programacin que sigue esta estrategiade diseo se le conoce por el acrnimo CBSE1 y es actualmente una de las ms 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 aplicacin basada en componentes consiste en uno o un nmero pequeo de componentes especficos de la aplicacin (que se disean especficamente para ella), que hacen uso de otros muchos componentes prefabricados que se ensamblan entre s para proporcionar los servicios que se necesitan en la aplicacin.

En la tecnologa de componentes la interfaz constituye el elemento bsico de interconectividad. Cada componente debe describir de forma completa las interfaces que ofrece, as como las interfaces que requiere para su operacin. Y debe operar correctamente con independencia de los mecanismos internos que utilice para soportar la funcionalidad de la interfaz. Caractersticas muy relevantes de la tecnologa de programacin basada en componentes son la modularidad, la rehusabilidad y componibilidad y en todos ellos coincide

con la tecnologa orientada a objetos de la que se puede considerar una evolucin. Sin embargo, en la tecnologa basada en componentes tambin se requiere robustez ya que los componentes han de operar en entornos mucho ms heterogneos y diversos. El desarrollo de software basado componentes es la evolucin natural de la ingeniera software para mejorar la calidad, disminuir los tiempos de desarrollo y gestionar la creciente complejidad de lossistemas. 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 programacin clsicos fueron diseados para desarrollar aplicaciones secuenciales compuestas de mdulos, todos ellos codificados con un solo lenguaje. Sin embargo, hay situaciones en las que no es prctico restringirse al uso de un nico lenguaje. La tecnologa COM aborda la solucin a este problema proporcionando un sencillo, pero a la vez potente modelo para construir sistemas software a partir de la interaccin de objetos (componentes). COM define un estndar binario (esto implica que es independiente del lenguaje de programacin) para objetos y la intercomunicacin entre ellos. Toda comunicacin se realiza a travs de operaciones que son proporcionadas dentro de interfaces. El diseador invoca las operaciones que necesita directamente, incluso si el objeto destinatario est localizado en otro proceso o en otra mquina. El modelo de programacin COM esta basado en la distribucin de cdigo de clases en componentes binarios. Esto significa que el software (componentes) que se adhiere a COM, puede ser rehusado sin ninguna

dependencia de cdigo 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 monolticas. Permite al grupo de desarrollo exponer ficheros binarios en vez de cdigo fuente. Los componentes binarios pueden ser actualizados independientemente y reemplazados, lo que se hace mucho ms fcil mantener y extender una aplicacin despus de que esta ha sido puesta en explotacin. 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 (ms adelante se expone una arquitectura de diseo) 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 ejecucin para objetos COM, adicionando soporte para la seguridad, soporte para administracin y configuracin. Es posible administrar variosservidores desde una simple computadora. COM+ COM+1, no es ms que la integracin de la arquitectura COM y MTS (Microsoft Transation Server). A diferencia de MTS, esta nueva capa de ejecucin no es opcional2 , COM+ es parte por defecto de la instalacin del sistema operativo Windows 2000. Como COM, COM+, es basado sobre componentes binarios y programacin basada en interfaces. Los Componentes COM+ pueden ser actualizados y extendidos una vez que estn en explotacin sin afectar a las aplicaciones clientes que los usan en la produccin.

De este modo, la combinacin de la tecnologa COM+ junto con las tcnicas de programacin orientada a objeto, nos ofrece una importante simplificacin en el proceso de desarrollo de aplicaciones informticas. Diseando Aplicaciones Distribuidas. El diseo de aplicaciones modernas involucra la divisin de una aplicacin en mltiples 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 aplicacin realice. Muchas aplicaciones pueden, al menos, hacer lo siguiente:

Clculos u otros procesos de negocios. Ejecucin de reglas de negocios. Validacin de datos relacionados al negocio. Manipulacin de datos. Ejecucin 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 continuacin se resumen:
o o o o o o o

Interfase de usuario (Capa de Presentacin) Interactuar con otros usuarios. Interactuar con aplicaciones externas o servicios. Procesos de negocios (Capa de Negocios) Clculos u otros procesos de negocios. Ejecucin de reglas de negocios. Validacin de datos relacionados al negocio. Procesos de datos (Capa de Servicios de Datos). Manipulacin de datos. Ejecucin de las reglas de datos relacional.

La divisin de estos procesos de aplicaciones y su distribucin entre diferentes procesos cliente/servidor es conocido como Procesamiento Distribuido. Generalizando estos procesos dentro de estas tres categoras o capas es una distribucin lgica y no refleja necesariamente alguna opcin de diseo fsico sobre computadoras, terminales u otros equipos. Usted puede desarrollar una aplicacin

cliente/servidor distribuida basada sobre estas tres capas de Presentacin, Lgica de Negocios y Servicios de Datos y tener la aplicacin entera corriendo sobre una simple computadora. Alternativamente, usted puede esparcir estas tres capas a travs de un gran nmero de diferentes computadoras sobre una red. De cualquier forma usted ha desarrollado una aplicacin cliente/servidor de tres capas. Capa de Presentacin. La capa de Presentacin provee su aplicacin con una interfase de usuario(IU). Aqu es donde su aplicacin presenta informacin a los usuarios y acepta entradas o respuestas del usuario para usar por su programa. Idealmente, la IU no desarrolla ningn procesamiento de negocios o reglas de validacin de negocios. Por el contrario, la IU debera relegar sobre la capa de negocios para manipular estos asuntos. Esto es importante, especialmente hoy en da, debido a que es muy comn para una aplicacin tener mltiples 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 aplicacin Win32 (un programa en Visual Basic) y entonces solicitrsele remplazarla con una pgina HTLM., quizs usando tecnologa ASP. Una de las mayores dificultades y factores importantes cuando desarrollamos aplicaciones cliente/servidor es mantener una separacin completa entre la presentacin, la lgica de negocios y los servicios de datos. Es muy tentador para los desarrolladores mezclar una o ms capas; poniendo alguna validacin u otro proceso de negocios dentro de la capa de presentacin en vez de en la capa de negocios. Capa de Negocios. Toda aplicacin tiene cdigo para implementar reglas de negocios, procesos relacionados a los datos o clculos y otras actividades relativas a los negocios. Colectivamente este cdigo es considerado para formar la capa de

negocios. Otra vez, uno de los principios del diseo lgico cliente/servidor, la lgica de negocios debe mantenerse separada de la capa de presentacin y de los servicios de datos. Esto no significa necesariamente que la lgica de negocios est en cualquier parte, por el contrario, esta separacin es en un sentido lgico. Hay muchas formas de separar la lgica de negocios. En trminos orientados a objetos, usted debera encapsular la lgica de negocios en un conjunto de objetos o componentes que no contienen presentacin o cdigo de servicios de datos. Teniendo separada lgicamente su lgica de negocios de ambas, la capa de presentacin y servicios de datos, usted ganar en flexibilidad en trmino de donde usted puede almacenar fsicamente la lgica de negocios. Por ejemplo, usted puede seleccionar almacenar la lgica de negocios sobre cada estacin de cliente, u optar por ejecutar la lgica de negocios sobre un servidor de aplicaciones, permitiendo a todos los clientes acceder a un recurso centralizado. Los objetos de negocios son diseados para reflejar o representar sus negocios. Ellos se convierten en un modelo de sus entidades de negocios e interrelaciones. Esto incluye tanto objetos fsicos 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 fsico, y la idea en su totalidad detrs de usar objetos de negocios de software, es crear una representacin de los mismos objetos dentro de su aplicacin. Sus aplicaciones pueden hacer que estos objetos interacten 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 lgica usted puede crear objetos de negocios de una orden conteniendo el cdigo necesario para administrarse a si mismo, as usted nunca

necesitar replicar cdigo para crear ordenes, usted solo usar el objeto. Similarmente, un objeto cliente contiene y administra sus propios datos. Un buen diseo de un objeto cliente contiene todos los datos y rutinas necesitadas para representarlo a travs del negocio completo, y puede ser usado a travs de toda la aplicacin de ese negocio. No toda la lgica de negocio es la misma. Alguna lgica de negocio es un proceso intensivo de datos, requiriendo un eficiente y rpido 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 validacin en la entrada de campos u otras interacciones de usuarios. Si nosotros necesitamos una validacin al nivel de pantallas y quizs clculos en tiempos real u otra lgica de negocios, pudiramos considerar este tipo de lgica de negocios para ser parte de la IU, ya que en su mayor parte es usada por la interfase de usuario. Una alternativa de solucin es dividir la capa de lgica 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 ymtodos para usar por el diseador de la interfase de usuario. Ejemplo de propiedades y mtodos pudieran ser: IDEmpleado, Nombre, Direccin, etc., y como mtodos 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 mtodos. Capa de Servicios de Datos. Muchas aplicaciones interactan con datos, los almacenan en alguna forma de bases de datos. Hay algunas funciones bsicas que son comunes a todos los procesos. Estas incluyen:

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

Adicionalmente, nosotros tenemos servicios ms avanzados disponibles, tales como: bsquedas, ordenamientos, filtrados, etc. Ejemplo de Aplicacin Cliente/Servidor. Especificaciones Tcnicas. Nuestro ejemplo fue desarrollado con Microsoft Visual Basic 6.0 y la base de datos fue elaborada enMicrosoft Access 2000. El mismo carece de complejidad, la nica intencin ha sido la de mostrar como se desarrolla una aplicacin cliente/servidor empleando un diseo distribuido. Es suficiente con una sola estacin de trabajo que tenga instalado el sistema operativo Microsoft Windows 2000 para su ejecucin, aunque pudiera esparcirse por varias computadoras en una red. Descripcin. La aplicacin cuenta con una simple interfase como se muestra en la siguiente figura:

Permitiendo dos funciones bsicas 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 aplicacin cuenta con una simple interfase permitiendo dos funciones bsicas la de crear nuevos empleados y borrar. Para un mayor control de la aplicacin se le ha incorporado a la capa de negocios la seguridad a travs de un objeto Session. Esto permite aislar al desarrollador de la interfase de usuario de estaresponsabilidad. De esta forma logramos una mayor autonoma 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 automticamente lanzara una ventana de autenticacin para la creacin del objeto, por lo que al destruirse el objeto Employee se destruir automticamente el objeto Session. Por lo que hemos creado este objeto Session justamente al inicio de la aplicacin, limitando el acceso a usuarios no deseados. El objeto Session puede crearse a travs del siguiente segmento de cdigo al comenzar la aplicacin en un mdulo de cdigo:

Set Session = New SecurityObject.Session Una vez ejecutada la sentencia anterior se mostrara la siguiente ventana:

Figure 1 Ventana de autenticacin Diagrama de clases

Diagrama de Componentes

3.2 Diseo de procesamiento de datos.

Qu es un buen diseo de base de datos? El proceso de diseo de una base de datos se gua por algunos principios. El primero de ellos es que se debe evitar la informacin 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 informacin sea correcta y completa. Si la base de datos contiene informacin incorrecta, los informes que recogen informacin de la base de datos contendrn tambin informacin incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarn mal fundamentadas. Un buen diseo de base de datos es, por tanto, aqul que:

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

El proceso de diseo El proceso de diseo consta de los pasos siguientes:

Determinar la finalidad de la base de datos

Esto le ayudar a estar preparado para los dems pasos.

Buscar y organizar la informacin necesaria

Rena todos los tipos de informacin que desee registrar en la base de datos, como los nombres de productos o los nmeros de pedidos.

Dividir la informacin en tablas

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

Convertir los elementos de informacin en columnas

Decida qu informacin 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 podra incluir campos como Apellido y Fecha de contratacin.

Especificar claves principales

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

Definir relaciones entre las tablas

Examine cada tabla y decida cmo se relacionan los datos de una tabla con las dems tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las relaciones segn sea necesario.

Ajustar el diseo

Analice el diseo 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 diseo.

Aplicar las reglas de normalizacin

Aplique reglas de normalizacin de los datos para comprobar si las tablas estn estructuradas correctamente. Realice los ajustes necesarios en las tablas. Determinar la finalidad de la base de datos Es conveniente plasmar en papel el propsito de la base de datos: cmo piensa utilizarla y quin va a utilizarla. Para una pequea base de datos de un negocio particular, por ejemplo, podra escribir algo tan simple como "La base de datos de clientes contiene una lista de informacin de los clientes para el envo masivo de correo y la generacin de informes". Si la base de datos es ms compleja o la utilizan muchas personas, como ocurre normalmente en un entorno corporativo, la finalidad podra definirse fcilmente en uno o varios prrafos y debera incluir cundo y cmo va a utilizar cada persona la base de datos. La idea es

desarrollar una declaracin de intenciones bien definida que sirva de referencia durante todo el proceso de diseo. Esta declaracin de intenciones le permitir centrarse en los objetivos a la hora de tomar decisiones. Buscar y organizar la informacin necesaria Para buscar y organizar la informacin necesaria, empiece con la informacin existente. Por ejemplo, si registra los pedidos de compra en un libro contable o guarda la informacin de los clientes en formularios en papel en un archivador, puede reunir esos documentos y enumerar cada tipo de informacin que contienen (por ejemplo, cada casilla de un formulario). Si no dispone de formularios, imagine que tiene que disear uno para registrar la informacin de los clientes. Qu informacin incluira en el formulario? Qu casillas creara? Identifique cada uno de estos elementos y cree un listado. Suponga, por ejemplo, que guarda la lista de clientes en fichas. Cada ficha podra contener un nombre de cliente, su direccin, ciudad, provincia, cdigo postal y nmero de telfono. 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 ms va a utilizar la base de datos, pdale tambin su opinin. Ms tarde podr ajustar la lista. A continuacin, 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 regin, o un informe de resumen de inventario con los niveles de inventario de los productos. Es posible que tambin desee generar cartas modelo para envirselas a los clientes con un anuncio de una actividad de ventas o una oferta. Disee el informe en su imaginacin y piense cmo le gustara que fuera. Qu informacin incluira 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.

Una persona imaginndose un informe de inventario de productos

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 peridicas de correo electrnico y desea imprimir un listado de los que han decidido inscribirse. Para registrar esa informacin, agrega una columna "Enviar correo electrnico" a la tabla de clientes. Para cada cliente, puede definir el campo en S o No. La necesidad de enviar mensajes de correo electrnico a los clientes implica la inclusin de otro elemento. Cuando sepa que un cliente desea recibir mensajes de correo electrnico, tendr que conocer tambin la direccin de correo electrnico a la que stos deben enviarse. Por tanto, tendr que registrar una direccin de correo electrnico para cada cliente. Parece lgico 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. Adems, tal vez desee comenzar las cartas con el saludo "Estimado Sr. Garca", en lugar de "Estimado Sr. Miguel ngel Garca". Esto implicara almacenar el apellido independientemente del nombre. Un punto clave que hay que recordar es que debe descomponer cada pieza de informacin en sus partes lgicas ms pequeas. 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, sera 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 informacin, debe incluir ese elemento en su propio campo. Piense en las preguntas que le gustara que la base de datos contestara. Por ejemplo, cuntas ventas de un determinado producto se cerraron el pasado mes? Dnde viven sus mejores clientes? Quin es el proveedor del producto mejor vendido? Prever esas preguntas le ayudar a determinar los elementos adicionales que necesita registrar. Una vez reunida esta informacin, ya puede continuar con el paso siguiente. Dividir la informacin en tablas Para dividir la informacin en tablas, elija las entidades o los temas principales. Por ejemplo, despus de buscar y organizar la informacin de una base de datos de ventas de productos, la lista preliminar podra ser similar a la siguiente:

Elementos de informacin escritos a mano y agrupados en temas

Las entidades principales mostradas aqu son los productos, los proveedores, los clientes y los pedidos. Por tanto, parece lgico 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 diseo correcto. Cuando examine por primera vez la lista preliminar de elementos, podra estar tentado a incluirlos todos ellos en una sola tabla en lugar de en las cuatro tablas mostradas en la ilustracin anterior. A continuacin le explicaremos por qu eso no es una buena idea. Considere por un momento la tabla que se muestra a continuacin:

Imagen que muestra una tabla que contiene productos y proveedores

En este caso, cada fila contiene informacin sobre el producto y su proveedor. Como hay muchos productos del mismo proveedor, la informacin del nombre y la direccin del proveedor debe repetirse muchas veces, con lo que se malgasta el espacio en disco. Registrar la informacin del proveedor una sola vez en una tabla Proveedores distinta y luego vincular esa tabla a la tabla Productos es una solucin mucho mejor. Otro problema de este diseo surge cuando es necesario modificar la informacin del proveedor. Suponga, por ejemplo, que necesita cambiar la direccin de un proveedor. Como sta aparece en muchos lugares, podra sin querer cambiar la direccin en un lugar y olvidarse de cambiarla en los dems lugares. Ese problema se resuelve registrando la informacin del proveedor en un nico lugar. Cuando disee la base de datos, intente registrar siempre cada dato una sola vez. Si descubre que est repitiendo la misma informacin en varios lugares, como la direccin de un determinado proveedor, coloque esa informacin en una tabla distinta. Por ltimo, suponga que el proveedor Bodega Sol slo suministra un producto y desea eliminar ese producto pero conservar el nombre del proveedor y la informacin de direccin. Cmo eliminara el producto sin perder la informacin del proveedor? No puede. Como cada registro contiene datos sobre un producto, adems 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 informacin sobre los productos y otra tabla para la informacin sobre los proveedores. Al eliminar un registro de producto slo se eliminaran 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 slo debe contener datos de productos. Como la direccin del proveedor es un dato del proveedor, pertenece a la tabla de proveedores. Convertir los elementos de informacin en columnas Para determinar las columnas de una tabla, decida qu informacin necesita registrar sobre el tema representado por la tabla. Por ejemplo, para la tabla Clientes, una buena lista de columnas iniciales sera Nombre, Direccin, Ciudad-Provincia-Cdigo postal, Enviar correo electrnico, Saludo y Correo electrnico. Cada registro de la tabla contiene el mismo nmero de columnas, por lo que puede almacenar informacin sobre el nombre, direccin, ciudadprovincia-cdigo postal, envo de correo electrnico, saludo y direccin de correo electrnico para cada registro. Por ejemplo, la columna de direccin podra contener las direcciones de los clientes. Cada registro contendr datos sobre un cliente y el campo de direccin, la direccin de ese cliente. Cuando haya determinado el conjunto inicial de columnas para cada tabla, puede ajustar con mayor precisin 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 direccin consta en realidad de cinco componentes distintos: direccin, ciudad, provincia, cdigo postal y pas o regin, y parece lgico tambin almacenarlos en columnas distintas. Si desea realizar, por ejemplo, una bsqueda o una operacin de ordenacin o filtrado por provincia, necesita que la informacin de provincia est almacenada en una columna distinta. Debe considerar tambin si la base de datos va a contener informacin slo de procedencia nacional o internacional. Por ejemplo, si piensa almacenar direcciones internacionales, es preferible tener una columna Regin en lugar de Provincia, ya que esa columna puede incluir

provincias del propio pas y regiones de otros pases o regiones. De igual forma, es ms lgico incluir una columna Regin en lugar de Comunidad Autnoma 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 mayora de los casos, no debe almacenar el resultado de los clculos en las tablas. En lugar de ello, puede dejar que Access realice los clculos 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 categora 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 informacin en sus partes lgicas ms pequeas

Puede ceder a la tentacin de habilitar un nico campo para los nombres completos o para los nombres de productos junto con sus descripciones. Si combina varios tipos de informacin en un campo, ser difcil recuperar datos individuales ms adelante. Intente dividir la informacin en partes lgicas. Por ejemplo, cree campos distintos para el nombre y el apellido, o para el nombre del producto, la categora y la descripcin.

Lista de elementos de informacin durante el proceso de diseo

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 inequvocamente cada fila almacenada en la tabla. sta suele ser un nmero de identificacin exclusivo, como un nmero de identificador de empleado o un nmero de serie. En la terminologa de bases de datos, esta informacin recibe el nombre de clave principal de la tabla. Access utiliza los campos de clave principal para asociar rpidamente datos de varias tablas y reunir automticamente esos datos. Si ya tiene un identificador exclusivo para una tabla, como un nmero de producto que identifica inequvocamente cada producto del catlogo, puede utilizar ese identificador como clave principal de la tabla, pero slo 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

fcil 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 vaco (porque no se conoce) en algn 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 dems tablas. Si la clave principal cambia, el cambio debe aplicarse tambin 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 sincronizacin con las otras tablas en las que se hace referencia a ella. A menudo, se utiliza como clave principal un nmero nico arbitrario. Por ejemplo, puede asignar a cada pedido un nmero de pedido distinto. La nica finalidad de este nmero 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 Autonumrico. Cuando se utiliza el tipo de datos Autonumrico, Access asigna automticamente un valor. Este tipo de identificador no es "fctico", es decir, no contiene informacin 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 nmero de telfono o el nombre de un cliente, es ms probable que cambie, ya que la propia informacin "fctica" podra cambiar.

Imagen que muestra la tabla Productos con un campo de clave principal.

Llamada 1

Una columna establecida en el tipo de datos Autonumrico suele constituir una buena clave principal. No hay dos identificadores de producto iguales. En algunos casos, tal vez considere conveniente utilizar dos o ms campos juntos como clave principal de una tabla. Por ejemplo, una tabla Detalles de pedidos que contenga artculos de lnea de pedidos tendra dos columnas en su clave principal: Id. de pedido e Id. de producto. Cuando una clave principal est formada por ms de una columna se denomina clave compuesta. Para la base de datos de ventas de productos, puede crear una columna autonumrica 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.

Imagen que muestra elementos de informacin durante el proceso de diseo

Crear relaciones entre las tablas Ahora que ha dividido la informacin en tablas necesita un modo de reunir de nuevo la informacin de forma provechosa. Por ejemplo, el siguiente formulario incluye informacin de varias tablas.

El formulario Pedidos

Llamada 1

La informacin de este formulario procede de la tabla Clientes...

Llamada 2

...la tabla Empleados...

Llamada 3

...la tabla Pedidos...

Llamada 4

...la tabla Productos...

Llamada

...y la tabla Detalles de pedidos. Access es un sistema de administracin de bases de datos relacionales. En una base de datos relacional, la informacin se divide en tablas distintas en funcin del tema. A continuacin, se utilizan relaciones entre las tablas para reunir la informacin segn se precise. Crear una relacin de uno a varios Considere este ejemplo: las tablas Proveedores y Productos de la base de datos de pedidos de productos. Un proveedor puede suministrar cualquier nmero de productos y, por consiguiente, para cada proveedor representado en la tabla Proveedores, puede haber muchos productos representados en la tabla Productos. La relacin entre la tabla Proveedores y la tabla Productos es, por tanto, una relacin de uno a varios.

Concepto de uno a varios

Para representar una relacin de uno a varios en el diseo de la base de datos, tome la clave principal del lado "uno" de la relacin y agrguela como columna o columnas adicionales a la tabla en el lado "varios" de la relacin. En este caso, por ejemplo, agregara la columna Id. de

proveedor de la tabla Proveedores a la tabla Productos. Access utilizara entonces el nmero de identificador de proveedor de la tabla Productos para localizar el proveedor correcto de cada producto. La columna Id. de proveedor de la tabla Productos se denomina clave externa. Una clave externa es la clave principal de otra tabla. La columna Id. de proveedor de la tabla Productos en una clave externa porque tambin es la clave principal en la tabla Proveedores.

Lista de elementos de informacin durante el proceso de diseo

El punto de partida para la unin de tablas relacionadas se proporciona estableciendo parejas de claves principales y claves externas. Si no est seguro de las tablas que deben compartir una columna comn, al identificar una relacin de uno a varios se asegurar de que las dos tablas implicadas requerirn una columna compartida. Crear una relacin de varios a varios Considere la relacin entre la tabla Productos y la tabla Pedidos. Un solo pedido puede incluir varios productos. Por otro lado, un nico producto puede aparecer en muchos

pedidos. Por tanto, para cada registro de la tabla Pedidos puede haber varios registros en la tabla Productos. Y para cada registro de la tabla Productos puede haber varios registros en la tabla Pedidos. Este tipo de relacin se denomina relacin de varios a varios porque para un producto puede haber varios pedidos, y para un pedido puede haber varios productos. Tenga en cuenta que para detectar las relaciones de varios a varios entre las tablas, es importante que considere ambas partes de la relacin. Los temas de las dos tablas (pedidos y productos) tienen una relacin de varios a varios. Esto presenta un problema. Para comprender el problema, imagine qu sucedera si intenta crear la relacin entre las dos tablas agregando el campo Id. de producto a la tabla Pedidos. Para que haya ms de un producto por pedido, necesita ms de un registro en la tabla Pedidos para cada pedido y, en ese caso, tendra que repetir la informacin de pedido para cada fila relacionada con un nico pedido, lo que dara lugar a un diseo ineficaz que podra producir datos inexactos. El mismo problema aparece si coloca el campo Id. de pedido en la tabla Productos: tendra varios registros en la tabla Productos para cada producto. Cmo se soluciona este problema? La solucin a este problema consiste en crear una tercera tabla que descomponga la relacin de varios a varios en dos relaciones de uno a varios. Insertara la clave principal de cada una de las dos tablas en la tercera tabla y, por consiguiente, la tercera tabla registrara todas las apariciones o instancias de la relacin.

Una relacin de varios a varios

Cada registro de la tabla Detalles de pedidos representa un artculo de lnea de un pedido. La clave principal de la tabla Detalles de pedidos consta de dos campos: las claves externas de las tablas Pedidos y Productos. El campo Id. de pedido no se puede utilizar en solitario como clave principal, ya que un pedido puede tener varios artculos de lnea. El identificador de pedido se repite para cada artculo de lnea del pedido, por lo que el campo no contiene valores nicos. Tampoco servira utilizar solamente el campo Id. de producto, porque un producto puede aparecer en varios pedidos. Pero los dos campos juntos producen un valor exclusivo para cada registro. En la base de datos de ventas de productos, la tabla Pedidos y la tabla Productos no se relacionan directamente entre s, sino indirectamente a travs de la tabla Detalles de pedidos. La relacin de varios a varios entre los pedidos y los productos se representa en la base de datos mediante dos relaciones de uno a varios:

La tabla Pedidos y la tabla Detalles de pedidos tienen una relacin de uno a varios. Cada pedido tiene varios artculos de lnea, pero cada artculo est asociado a un nico pedido.

La tabla Productos y la tabla Detalles de pedidos tienen una relacin de uno a varios. Cada producto puede tener varios artculos asociados, pero cada artculo de lnea hace referencia nicamente a un producto.

Desde la tabla Detalles de pedidos puede determinar todos los productos de un determinado pedido, as como todos los pedidos de un determinado producto. Despus de incorporar la tabla Detalles de pedidos, la lista de tablas y campos sera similar a la siguiente:

Lista de elementos de informacin durante el proceso de diseo

Crear una relacin de uno a uno Otro tipo de relacin es la relacin de uno a uno. Suponga, por ejemplo, que necesita registrar informacin complementaria sobre productos que apenas va a necesitar o que slo se aplica a unos pocos productos. Como no necesita la informacin con frecuencia, y como almacenar la informacin en la tabla Productos creara un espacio vaco para todos los productos que no necesitan esa informacin, la coloca en una tabla distinta. Al igual que en la tabla Productos, utiliza el identificador de

producto como clave principal. La relacin entre esta tabla complementaria y la tabla Productos es una relacin de uno a uno. Para cada registro de la tabla Productos hay un nico registro coincidente en la tabla complementaria. Cuando identifique esta relacin, ambas tablas deben compartir un campo comn. Cuando necesite crear una relacin de uno a uno en la base de datos, considere si puede incluir la informacin de las dos tablas en una tabla. Si no desea hacer eso por algn motivo (quizs porque se creara una gran cantidad de espacio vaco), puede representar esa relacin en su diseo guindose por las pautas siguientes:

Si las dos tablas tienen el mismo tema, probablemente podr definir la relacin 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 relacin de uno a uno o de uno a varios, las tablas implicadas deben compartir una o varias columnas comunes. Cuando la relacin es de varios a varios, se necesita una tercera tabla para representar la relacin. Ajustar el diseo 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 informacin: 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 diseo, 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 segn lo previsto. Compruebe si existen datos duplicados

innecesarios y, si encuentra alguno, modifique el diseo para eliminar la duplicacin. 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 informacin a alguna de las tablas existentes? Si se trata de informacin sobre otro tema, tal vez necesite crear otra tabla. Cree una columna para cada elemento de informacin que desee registrar. Si la informacin no se puede calcular a partir de otras columnas, es probable que necesite una nueva columna para esa informacin. Hay alguna columna innecesaria porque se puede calcular con los campos existentes? Si un elemento de informacin se puede calcular a partir de otras columnas existentes (como un descuento calculado a partir del precio de venta al pblico), normalmente es preferible que se calcule en lugar de crear una nueva columna. Ha proporcionada informacin duplicada en alguna de las tablas? Si es as, probablemente tendr que dividir la tabla en dos tablas que tengan una relacin de uno a varios. Tiene tablas con muchos campos, un nmero limitado de registros y muchos campos vacos en cada registro? En ese caso, considere la posibilidad de volver a disear la tabla de forma que tenga menos campos y ms registros. Ha dividido cada elemento de informacin en sus partes lgicas ms pequeas? Si necesita generar informes, ordenar, buscar o calcular a partir de un elemento de informacin, incluya ese elemento en su propia columna. Contiene cada columna datos sobre el tema de la tabla? Si una columna no contiene informacin sobre el tema de la tabla, pertenece a una tabla distinta. Estn 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 categora general, como bebidas, condimentos o marisco. La tabla Productos podra incluir un campo que mostrara la categora de cada producto.

Suponga que despus de examinar y ajustar el diseo de la base de datos, decide almacenar una descripcin de la categora junto con su nombre. Si agrega un campo Descripcin de categora a la tabla Productos, tendra que repetir la descripcin de cada categora para cada producto perteneciente a dicha categora, lo cual no es una buena solucin. Una solucin mejor es convertir las categoras en un nuevo tema de la base de datos, con su propia tabla y su propia clave principal. A continuacin, puede agregar la clave principal de la tabla Categoras a la tabla Productos como clave externa. Las tablas Categoras y Productos tienen una relacin de uno a varios: una categora puede incluir varios productos, pero un producto pertenece nicamente a una categora. 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 dems solamente por el nmero agregado al final del nombre de columna. Si tiene columnas numeradas de esta forma, debe revisar el diseo. Un diseo como ste tiene varios defectos. Para empezar, obliga a crear un lmite mximo de nmero de productos. En cuanto supere ese lmite, 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 nmero mximo de

productos, ya que las columnas adicionales quedarn en blanco. El defecto ms grave de este diseo es que muchas tareas son difciles de realizar, como ordenar o indizar la tabla por identificador de producto o nombre. Siempre que aparezcan grupos extensibles, revise atentamente el diseo con vistas a dividir la tabla en dos. En el ejemplo anterior, sera conveniente usar dos tablas, una para proveedores y otra para productos, vinculadas por el identificador de proveedor. Aplicar las reglas de normalizacin En el siguiente paso del diseo, puede aplicar las reglas de normalizacin de datos (denominadas a veces simplemente reglas de normalizacin). Estas reglas sirven para comprobar si las tablas estn estructuradas correctamente. El proceso de aplicar las reglas al diseo de la base de datos se denomina normalizar la base de datos o, simplemente, normalizacin. La normalizacin es ms til una vez representados todos los elementos de informacin y despus de haber definido un diseo preliminar. La idea es asegurarse de que se han dividido los elementos de informacin en las tablas adecuadas. Lo que la normalizacin 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 diseo 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 artculo se abordan las tres primeras, porque todas ellas son necesarias para la mayora de los diseos de base de datos. Primera forma normal La primera forma normal establece que en cada interseccin 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 ms de un

precio. Si considera cada interseccin de filas y columnas como una celda, cada celda slo 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 slo 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 diseo 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 slo que cada columna que no sea clave dependa de toda la clave principal, sino tambin 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 ms 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 pblico (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 cambiara en consecuencia e infringira esa regla. En este caso, la columna Descuento debe moverse a otra tabla cuya clave sea PVP.

3.3 Diseo de interfaz de usuario.

1. 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 informacin al usuario y le permiten interactuar con la informacin y con el computadora. Tambin se puede considerar parte de la IU la documentacin (manuales, ayuda, referencia, tutoriales) que acompaa al hardware y al software. Si la IU est bien diseada, el usuario encontrar la respuesta que espera a su accin. Si no es as puede ser frustrante su operacin, 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 vlida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interaccin que ms se adece a susobjetivos en cada momento. La mayora de los programas

y sistemas operativos ofrecen varias formas de interaccin al usuario. Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseador (analoga de la construccin 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 travs 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 interaccin con las computadoras, de ah su importancia. Modelo del usuario: El usuario tiene su visin personal del sistema, y espera que ste se comporte de una cierta forma. Se puede conocer el modelo del usuario estudindolo, ya sea realizando tests de usabilidad, entrevistas, o a travs de una realimentacin. Una interfaz debe facilitar el proceso de crear un modelo mental efectivo. Para ello son de gran utilidad las metforas, que asocian un dominio nuevo a uno ya conocido por el usuario. Un ejemplo tpico es la metfora del escritorio, comn a la mayora de las interfaces grficasactuales. Modelo del diseador: El diseador mezcla las necesidades, ideas, deseos del usuario y los materialesde que dispone el programador para disear un producto de software. Es un intermediario entre ambos. El modelo del diseador describe los objetos que utiliza el usuario, su presentacin al mismo y lastcnicas de interaccin para su manipulacin. Consta de tres partes: presentacin, interaccin y relaciones entre los objetos (Figura 1). La presentacin es lo que primero capta la atencin del usuario, pero ms tarde pasa a un segundo plano, y adquiere ms importancia la interaccin con el producto para poder satisfacer sus expectativas. La presentacin no

es lo ms 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 tcnicas de interaccin del usuario, a travs de diversos dispositivos. La tercera es la ms importante, y es donde el diseador determina la metfora adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por esta parte e ir hacia arriba. Una vez definida la metfora y los objetos del interfaz, los aspectos visuales saldrn de una manera lgica y fcil.

Figura 1. Representacin del modelo del diseador: el lookand-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 ms all de la primera impresin. Modelo del programador: Es el ms fcil 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 podra llamar agenda). Estos objetos deben esconderse del usuario. Los conocimientos del programador incluyen la plataforma de desarrollo, el sistema operativo, lasherramientas de desarrollo y especificaciones. Sin embargo, esto no significa necesariamente que tenga la habilidad de proporcionar al usuario los modelos y metforas ms adecuadas. Muchos no consideran el modelo del usuario del programa, y s sus propias expectativas acerca de cmo trabajar con la computadora. 2. Principios para el Diseo de Interfaces de Usuario Existen principios relevantes para el diseo e implementacin de IU, ya sea para las IU grficas, como para la Web. Anticipacin Las aplicaciones deberan intentar anticiparse a las necesidades del usuario y no esperar a que el usuario tenga que buscar la informacin, recopilarla o invocar las herramientas que va a utilizar. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajartrabajo" ubicado en la parte superior de este documento En la Figura 2 se ilustra como el procesador de texto se anticipa a las necesidades del usuario, proporcionando las caractersticas del texto seleccionado -fuente, tamao, alineacin, etc.- permitiendo que el usuario pueda modificarlas gilmente. Autonoma

La computadora, la IU y el entorno de trabajo deben estar a disposicin del usuario. Se debe dar al usuario el ambiente flexible para que pueda aprender rpidamente a usar la aplicacin. Sin embargo, est comprobado que el entorno de trabajo debe tener ciertas cotas, es decir, ser explorable pero no azaroso. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento En la Figura 3 se visualiza un diseo 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 autonoma en ausencia de control, y el control no puede ser ejercido sin informacin suficiente. Adems, se debe mantener informacin del estado del sistema en ubicaciones fciles de visualizar. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento En la Figura 4 se ejemplifica una incorrecta disposicin de componentes en la IU. El reloj no debe ser incorporado en el men del sistema ya que aporta confusin al usuario. Para mantenerlo informado sera mas adecuado colocarlo en la barra de estado del sistema. Percepcin del Color Aunque se utilicen convenciones de color en la IU, se deberan usar otros mecanismos secundarios para proveer la informacin a aquellos usuarios con problemas en la visualizacin de colores Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento

En la Figura 5 se representa un mecanismo secundario muy utilizado para ejecucin de comandos: los comandos abreviados (shortcut-keys). Sin embargo la aplicacin 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 aplicacin o servicio. Puede ser reemplazada por "Estndar" o "Definida por el Usuario", "Restaurar Valores Iniciales" o algn otro trmino especifico que describa lo que est sucediendo. Los valores por defecto deberan ser opciones inteligentes y sensatas. Adems, los mismos tienen que ser fciles de modificar. Consistencia Para lograr una mayor consistencia en la IU se requiere profundizar en diferentes aspectos que estn catalogados en niveles. Se realiza un ordenamiento de mayor a menor consistencia:
1.

2. Interpretacin del comportamiento del usuario: la IU debe comprender el significado que le atribuye un usuario a cada requerimiento. Ejemplo: mantener el significado de las los comandos abreviados (shortcut-keys) definidos por el usuario. 3. Estructuras invisibles: se requiere una definicin clara de las mismas, ya que sino el usuario nunca podra llegar a descubrir su uso. Ejemplo: la ampliacin de ventanas mediante la extensin de sus bordes. 4. Pequeas estructuras visibles: se puede establecer un conjunto de objetos visibles capaces de ser controlados por el usuario, que permitan ahorrar tiempo en la ejecucin de tareas especficas. Ejemplo: cono y/o botn para impresin. 5. Una sola aplicacin o servicio: la IU permite visualizar a la aplicacin o servicio utilizado como un componente nico. Ejemplo: La IU despliega un nico men, pudiendo adems acceder al mismo mediante comandos abreviados. 6. Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicacin 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. 7. Consistencia del ambiente: la IU se mantiene en concordancia con el ambiente de trabajo. Ejemplo: La IU utiliza objetos de control como menes, botones de comandos de manera anloga a otras IU que se usen en el ambiente de trabajo. 8. 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.

Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento En la Figura 6 puede observarse la mejora en la consistencia de las pequeas estructuras visibles (3.) para los sistemas grficos basados en ventanas. La inclusin de la opcin X para cerrar la ventana operacin comunmente utilizada en estas aplicaciones- simplifica la operatividad del mismo. La inconsistencia en el comportamiento de componentes de la IU debe ser fcil de visualizar. Se debe evitar la uniformidad en los componentes de la IU. Los objetos deben ser consistentes con su comportamiento. Si dos objetos actan 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 mquina. Si el usuario debe esperar la respuesta del sistema por un perodo prolongado, estas prdidas de tiempo se pueden convertir en prdidas econmicas para la organizacin. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los problemas. Los menes y etiquetas de botones deberan tener las palabras claves del proceso. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento

En la Figura 7 se demuestra como una incorrecta definicin 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 etiquetndolos con los nombres de los procesos especficos que ejecutan. Ley de Fitt El tiempo para alcanzar un objetivo es una funcin de la distancia y tamao del objetivo. Es por ello, que es conveniente usar objetos grandes para las funciones importantes. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento En la Figura 8 se puede apreciar la relacin entre los elementos de diseo de pantalla y su percepcinvisual. El nmero de elementos visuales que perciben son: en el caso a) 1 (el fondo); en b) 3 (la lnea, lo que est encima y lo que est debajo); en c) son 5 (el espacio fuera del recuadro, el recuadro, la lnea y el espacio encima y debajo de sta); finalmente, en d) el nmero se eleva a 35, siguiendo el mismo criterio. Conclusin: cada elemento nuevo que se aade influye ms 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 unamarca 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 aplicacin, se deber proveer de guas para realizar tareas que no sean habituales. Es conveniente que el usuario pueda incorporar elementos visuales estables que permitan, no solamente un desplazamiento rpido a ciertos puntos del trabajo que est

realizando, sino tambin un sentido de "casa" o punto de partida. La IU debe poder realizar la inversa de cualquier accin 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 dilogos de confirmacin para cada accin 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 fcil de accionar con el cual poder finalizar la aplicacin. 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. Adems, estos objetos deberan ser entendibles, consistentes y estables. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento En la Figura 9 se presentan barras de controles que simplifican la operacin de un sistema. A travs de las ilustraciones que poseen los mismos, el usuario puede aprender fcilmente su uso. Si se mantienen para estos botones las mismas asignaciones de procesos en diferentes sistemas, la comprensin del funcionamiento de los mismos se hace mas sencilla. Uso de Metforas Las buenas metforas crean figuras mentales fciles de recordar. La IU puede contener objetos asociados al modelo conceptual en forma visual, con sonido u otra caracterstica perceptible por el usuario que ayude a simplificar el uso del sistema. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento

En la Figura 10 se compara la aplicacin de metforas en el desarrollo de una IU. En el primer caso, se utiliza incorrectamente la metfora de una cmara de video para representar el procesamiento de un documento por una impresora. Se puede observar que el botn << carece de sentido, ya que no se puede volver atrs un trabajo que ya ha sido impreso. En el segundo caso, la metfora de la agenda es utilizada correctamente para la implementacin de una agenda electrnica. 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 aplicacin sin esfuerzo. Reduccin de Latencia Siempre que sea posible, el uso de tramas (multi-threading) permite colocar la latencia en segundo plano (background). Las tcnicas de trabajo multitarea posibilitan el trabajo ininterrumpido del usuario, realizando las tareas de transmisin y computacin de datos en segundo plano. Proteccin del Trabajo Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por error de su parte, problemas de transmisin de datos, de energa, o alguna otra razn inevitable. Auditora del Sistema La mayora de los navegadores de Internet (browsers), no mantienen informacin acerca de la situacin del usuario en el entorno, pero para cualquier aplicacin es conveniente conocer un conjunto de caractersticas tales como: hora de acceso al sistema, ubicacin del usuario en el sistema y lugares a los que ha accedido, entre otros. Adems, el usuario debera poder salir del sistema y al volver a ingresar continuar trabajando en lugar dnde haba dejado. Legibilidad

Para que la IU favorezca la usabilidad del sistema de software, la informacin que se exhiba en ella debe ser fcil de ubicar y leer. Para lograr obtener este resultado se deben tener en cuenta algunas como: el texto que aparezca en la IU debera tener un alto contraste, se debe utilizar combinaciones de colorescomo el texto en negro sobre fondo blanco o amarillo suave. El tamao de las fuentes tiene que ser lo suficientemente grande como para poder ser ledo en monitores estndar. Es importante hacer clara la presentacin visual (colocacin/agrupacin de objetos, evitar la presentacin de excesiva informacin. Para ver esta imagen deber descargar el archivo de Word que se encuentra en la opcin "Bajar trabajo" ubicado en la parte superior de este documento En la Figura 11 se describe una comparacin de disposicin de los objetos en pantalla. La figura de la izquierda, combina una disposicin asimtrica de la informacin con un conjunto de colores que no facilita la lectura. La figura de la derecha realiza la presentacin de la informacin utilizando una gama de colores homognea y una alineacin del texto que favorece a la legibilidad del mismo. Interfaces Visibles El uso de Internet, ha favorecido la implementacin de interfaces invisibles. Esto significa que el usuario siempre ve una pgina especfica, pero nunca puede conocer la totalidad del espacio de pginas de Internet. La navegacin en las aplicaciones debe ser reducida a la mnima expresin. 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 navegacin, sino que adems brindan al usuario una sensacin de autonoma. 3. Utilizacin de Prototipos en la Implementacin de IU Niveles de Prototipado

Se puede hacer una clasificacin de los principales tipos de prototipos, variando su grado de complejidad, de acuerdo a las caractersticas que consideren y a su operabilidad para realizar simulaciones.

Prototipos Estticos: son aquellos que no permiten la alteracin de sus componentes, pero sirven para identificar y resolver problemas de diseo. En esta categora se incluyen las presentaciones sobre reproductores, papel u otro medio de visualizacin. Prototipos Dinmicos: permiten la evaluacin de un modelo del sistema sobre una estacin de trabajo o una terminal. Estos prototipos involucran aspectos de diseo mas detallados que los prototipos estticos, incluyendo la validacin del diseo del sistema en trminos de requerimientos no funcionales, por ejemplo de performance. Prototipos Robustos: deben ser relativamente completos en la simulacin de las caractersticas dinmicas de la interfaz (presentacin de mensajes de error, entrada y edicin de datos, etc.). Esta categora puede ser utilizada para validar los objetivos de diseo.

El nivel de sofisticacin del prototipo debera incrementarse a lo largo del proceso de diseo de interfaces de usuario. La informacin recolectada durante las tareas de anlisis del sistema y la especificacin de los requisitos del usuario constituyen los datos clave para el proceso de prototipacin. 4. Heursticas para la Evaluacin de IU Las heursticas ayudan a poder analizar las IU y localizar problemas que afecten la utilizacin 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 estandarizacin Prevencin de Errores Reconocimiento de acciones y opciones Flexibilidad y eficiencia en el uso Esttica y diseo minimalista Reconocimiento de errores, diagnstico y recuperacin Ayuda y documentacin

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 "cosmtico" que no necesita ser corregido a menos que se disponga tiempo extra en el proyecto. 2: Es un problema menor y su correccin puede tener baja prioridad. 3: Es un problema mayor y su correccin debera tener alta prioridad. 4: Es una catstrofe para la utilizacin de la aplicacin y es imperativo corregir el error. Para la evaluacin de los problemas en las IU es conveniente que contar con mas de un evaluador; de esta forma los resultados son mas confiables. 5. Caso Prctico Para complementar los aspectos tericos, se realiza una ejemplificacin de una de las actividades propuestas por la metodologa Mtrica Versin 2 para el diseo de interfaces de usuario. La metodologa Mtrica Versin 2 contempla la simulacin de dilogos 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 anlisis. Siguiendo la metodologa, la tarea 4.1 prescribe las siguientes acciones:

Definir los formatos individuales de las pantallas utilizadas. Describir de modo detallado los dilogos entre pantallas y el encadenamiento entre las mismas. Determinar los dilogos que se consideran crticos.

Realizar una maqueta dinmica.

Asimismo, la tarea 4.2 indica:

Obtener una definicin de los formatos de los informes generados. Definir los formularios utilizados (si fuera necesario). Verificar si los diseos realizados estn de acuerdo con los estndares de la unidad y obtener la validacin y conformidad de los usuarios.

Para acotar el presente trabajo, se realiza un desarrollo del primer punto de la tarea 4.1 propuesta en la metodologa, exponiendo algunos de los productos resultantes.

Tarea 4.1.1. Definir los formatos individuales de las pantallas utilizadas.

Caso Prctico: Construccin de un sistema de Gestin de Alquiler de Automviles (AGA 2000). Requisitos de interfaces de usuario:

La interfaz con el usuario se har mediante pantallas con mens desplegables.

Se describe a modo de ejemplo, el formato de la pantalla principal del sistema AGA 2000 y sus componentes (Figura 12). Descripcin de componentes Barra de Ttulo: se utiliza para desplegar el ttulo de la pantalla desplegada. Si la ventana est activa, la barra de titulo 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 contrasea como requisito para acceder al sistema. Reloj del Sistema: indica la hora actual del sistema. Area de Trabajo: es el lugar donde se despliegan las pantallas que son activadas a travs del Men Principal. Maximizar/Restaurar Ventana: botn que se utiliza para ampliar o reducir el tamao 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.