Preparación adecuada de los datos o elementos básicos de información y tratamiento de los mismos mediante reglas y procedimientos que ejecutan distintas operaciones (cálculos).
CONTROL: Comprobación, inspección, intervención, dirección mando y regulación de algún fenómeno (proceso, actividad).
¿Por que es necesario controlar un proceso?
• Incremento de la productividad
• Alto costo de mano de obra
• Seguridad
• Alto costo de materiales
• Mejorar la calidad
• Reducción de tiempo de manufactura
• Reducción de inventario en proceso
• Certificación (mercados internacionales)
• Protección del medio ambiente (desarrollo sustentable)
El proceso de diseño del sistema de control
Para poder diseñar un sistema de control automático, se requiere conocer el proceso que se desea controlar, es decir, conocer la ecuación diferencial que describe su comportamiento, utilizando las leyes físicas, químicas y/o eléctricas, computacionales etc. A esta ecuación diferencial se le llama modelo del proceso. Una vez que se tiene el modelo, se puede diseñar el controlador.
Definición de Diseño de Sistemas
El diseño de sistemas es la evaluación de las distintas soluciones alternativas y la especificación de una solución detallada a un problema de información
1. Investigar las opciones y los criterios técnicos
– Calidad de documentación
– Facilidad de aprendizaje
– Facilidad de uso
– Tiempo de respuesta
– Productividad
El diseño de sistemas se encarga de:
1. Analizar y distribuir datos
2. Analizar y distribuir los procesos
3. Dividir en unidades de diseño
4. Diseñar bases de datos y o archivos
5. Diseñar entradas y salidas informáticas
6. Diseñar interfaces interactivas de usuario
7. Presentar y revisar el diseño
Actividades que se desarrollan en el diseño de control y proceso
• Actividad de Definición de la Arquitectura del Sistema.
• Definición de la arquitectura del sistema.
• Definición de Niveles de Arquitectura.
• Identificación de Requisitos de Diseño y Construcción.
• Generación del Código de los Procedimientos de Operación y Seguridad
Actividad de Definición de la Arquitectura del Sistema
En esta actividad se establece:
• El particionamiento físico del sistema de información.
• La organización en subsistemas de diseño.
• La especificación del entorno tecnológico.
• Los requisitos de operación, administración, seguridad y control de acceso.
Definición de la Arquitectura del Sistema
En esta actividad se define la:
• Arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo.
• La descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición.
• Se especifica detalladamente la infraestructura tecnológica necesaria para dar soporte al sistema de información.
• El entorno Tecnológico del Sistema, comprende la especificación del entorno tecnológico, las restricciones técnicas y la planificación de capacidades.
Definición de Niveles de Arquitectura
En esta tarea se describen los niveles de la arquitectura software, mediante la definición de las principales particiones físicas del sistema de información, representadas como nodos y comunicaciones entre nodos. Los elementos que se deben de especificar son:
• Gestores de datos.
• Tipos de puesto cliente.
• Tipos de dispositivos de impresión.
• Monitores de teleproceso.
• Servidores.
• Comunicaciones.
Identificación de Requisitos de Diseño y Construcción
En esta tarea se realiza la especificación de los requisitos que están directamente relacionados con el diseño o la construcción del sistema de información.
Estos requisitos son:
• Lenguajes.
• Rendimiento de los distintos elementos de la arquitectura.
• Criterios de ubicación de módulos y datos en los distintos nodos.
Especificación de Requisitos de Operación y Seguridad.
El objetivo de esta tarea es definir los procedimientos de seguridad y operación necesarios para el adecuado funcionamiento del sistema y garantizar el cumplimiento de los niveles de servicios que exigirá el sistema en cuanto a la gestión de operaciones (procesos por lotes, seguridad, comunicaciones, etc.).
Se establecen los requisitos de seguridad y control de acceso necesarios para garantizar la protección del sistema y minimizar el riesgo de pérdida, alteración o consulta indebida de la información.
Para ello, se diseñan los procedimientos relacionados con:
• Acceso al sistema y a sus recursos (datos, transacciones, librerías, etc.).
• Mantenimiento de la integridad y confidencialidad de los datos.
• Control y registro de accesos al sistema (logs, certificación, etc.).
• Copias de seguridad y recuperación de datos y su periodicidad.
• Recuperación ante catástrofes.
• Se definen los requisitos de operación para los distintos elementos del sistema (módulos, clases, estructuras físicas de datos, sistemas de ficheros)
• Control y seguimiento del correcto funcionamiento de los procedimientos de backup y recuperación utilizados habitualmente.
Generación Del Código De Los Componentes y Procedimientos
El objetivo de esta actividad es la codificación de los componentes del sistema de información, a partir de las especificaciones de construcción obtenidas en el proceso Diseño del Sistema de Información (DSI), así como la construcción de los procedimientos de operación y seguridad establecidos para el mismo.
Generación del Código de Componentes
En esta tarea se genera el código correspondiente a cada uno de los componentes del sistema de información, identificados en la tarea Definición de Componentes y Subsistemas de Construcción.
Generación del Código de los Procedimientos de Operación y Seguridad
• El objetivo de esta tarea es generar los procedimientos de operación y administración del sistema de información, así como los procedimientos de seguridad y control de acceso, necesarios para ejecutar el sistema una vez que se haya implantado y esté en producción.
• Para la generación de dichos procedimientos se tienen en cuenta, también, los estándares y normas de la instalación recogidos en el catálogo de normas.
jueves, 14 de octubre de 2010
DISEÑO DE BASE DE DATOS
Son muchas las consideraciones a tomar en cuenta al momento de hacer el diseño de la base de datos, quizá las más fuertes sean:
• La velocidad de acceso,
• El tamaño de la información,
• El tipo de la información,
• Facilidad de acceso a la información,
• Facilidad para extraer la información requerida,
• El comportamiento del manejador de bases de datos con cada tipo de información.
No obstante que pueden desarrollarse sistemas de procesamiento de archivoe incluso manejadores de bases de datos basándose en la experiencia del equipo de desarrollo de software logrando resultados altamente aceptables, siempre es recomendable la utilización de determinados estándares de diseño que garantizan el nivel de eficiencia mas alto en lo que se refiere a almacenamiento y recuperación de la información.
De igual manera se obtiene modelos que optimizan el aprovechamiento secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse al usuario.
OBJETIVOS DEL DISEÑO DE BASES DE DATOS
Almacenar Solo La Información Necesaria.
A menudo pensamos en todo lo que quisiéramos que estuviera almacenado en una base de datos y diseñamos la base de datos para guardar dichos datos. Debemos de ser realistas acerca de nuestras necesidades y decidir qué información es realmente necesaria.
Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicación.
Normalizar la Estructura de las Tablas.
Si nunca antes hemos oídohablar de la " normalizaciónde datos", no debemos temer. Mientras que la normalización puede parecer un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización.
Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir la pista de nuestra colección de CD’s en una hoja de cálculo, podríamos diseñar algo parecido a lo que se muestra en la siguiente tabla.
+------------+-------------+--------------+ .. +--------------+
| Álbum | track1 | track2 | | track10 |
+------------+-------------+--------------+ .. +--------------+
Esto parece razonable. Sin embargo el problema es que el número de pistas que tiene un CD varía bastante. Esto significa que con este método tendríamos que tener una hoja de cálculorealmente grande para albergar todos los datos, que en los peores casos podrían ser de hasta 20 pistas. Esto en definitiva no es nada bueno.
Uno de los objetivosde una estructura de tabla normalizada es minimizar el número de "celdas vacías". El darnos cuenta de que cada lista de CD’s tiene un conjunto fijo de campos (título, artista, año, género) y un conjunto variable de atributos (el número de pistas) nos da una idea de cómo dividir los datos en múltiples tablas que luego podamos relacionar entre sí.
Mucha gente no esta familiarizada con el concepto "relacional", de manera sencilla esto significa, que grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común.
Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está en el hecho que podemos agregar datos al sistemaposteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiéramos agregar la información de los artistas de cada álbum, lo único que tenemos que hacer es crear una tabla artista que esté relacionada a la tabla álbum de la misma manera que la tabla pista. Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta.
La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y tampoco tenemos grandes cantidades de "celdas vacías".
El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información.
Es importante que esta información se almacene sin redundancia para que se pueda tener una recuperación rápida y eficiente de los datos.
A través de la normalización tratamos de evitar ciertos defectos que nos conduzcan a un mal diseño y que lleven a un procesamiento menos eficaz de los datos.
Podríamos decir que estos son los principales objetivos de la normalización:
• Controlar la redundancia de la información.
• Evitar pérdidas de información.
• Capacidad para representar toda la información.
• Mantener la consistencia de los datos.
Seleccionar el Tipo de Dato Adecuado.
Una vez identificadas todas las tablas y columnas que necesita la base de datos, debemos determinar el tipo de dato de cada campo. Existen tres categorías principales que pueden aplicarse prácticamente a cualquier aplicación de bases de datos:
• Texto
• Números
• Fecha y hora
Cada uno de éstos presenta sus propias variantes, por lo que la elección del tipo de dato correcto no sólo influye en el tipo de información que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos.
A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de dato adecuado para nuestras tablas:
• Identificar si una columna debe ser de tipo texto, numérico o de fecha.
• Elegir el subtipo más apropiado para cada columna.
• Configurar la longitud máxima para las columnas de texto y numéricas, así como otros atributos.
Utilizar Índices Apropiadamente
Los índices son un sistema especial que utilizan las bases de datos para mejorar su rendimiento global. Dado que los índices hacen que las consultas se ejecuten más rápido, podemos estar incitados a indexar todas las columnas de nuestras tablas.
Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, MySQLtiene que actualizar cualquier índice en la tabla para reflejar los cambios en los datos.
¿Así que, cómo decidimos usar índices o no? La respuesta es "depende". De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas.
Así que antes de indexar una columna, debemos considerar que porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es demasiado alto, seguramente no veremos alguna mejora con el uso de un índice. Ante la duda, no tenemos otra alternativa que probar.
Usar Consultas REPLACE
Existen ocasiones en las que deseamos insertar un registro a menos de que éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos hacer es una actualización de los datos.
Usar Una Versión Reciente de MySQL
La recomendación es simple y concreta, siempre que esté en nuestras manos, debemos usar la versión más reciente de MySQL que se encuentre disponible. Además de que las nuevas versiones frecuentemente incluyen muchas mejoras, cada vez son más estables y más rápidas. De esta manera, a la vez que sacamos provecho de las nuevas características incorporadas en MySQL, veremos significativos incrementos en la eficiencia de nuestro servidor de bases de datos.
Usar Tablas Temporales.
Cuando estamos trabajando con tablas muy grandes, suele suceder que ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas sobre la tabla completa y hacer que MySQL encuentre cada vez los pocos registros que necesitamos, puede ser mucho más rápido seleccionar dichos registros en una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla.
Una tabla temporal existe mientras dure la conexión a MySQL. Cuando se interrumpe la conexión MySQL remueve automáticamente la tabla y libera el espacio que ésta usaba.
Recomendaciones.
El último paso del diseño de la base de datos es adoptar determinadas convenciones de nombres. Aunque MySQL es muy flexible en cuanto a la forma de asignar nombre a las bases de datos, tablas y columnas, he aquí algunas reglas que es conveniente observar:
• Utilizar caracteres alfanuméricos.
• Limitar los nombres a menos de 64 caracteres (es una restricción de MySQL).
• Utilizar el guión bajo (_) para separar palabras.
• Utilizar palabras en minúsculas (esto es más una preferencia personal que una regla).
• Los nombres de las tablas deberían ir en plural y los nombres de las columnas en singular (es igual una preferencia personal).
• Utilizar las letras ID en las columnas de clave primaria y foránea.
• En una tabla, colocar primero la clave primaria seguida de las claves foráneas.
• Los nombres de los campos deben ser descriptivos de su contenido.
• Los nombres de los campos deben ser unívocos entre tablas, excepción hecha de las claves.
• La velocidad de acceso,
• El tamaño de la información,
• El tipo de la información,
• Facilidad de acceso a la información,
• Facilidad para extraer la información requerida,
• El comportamiento del manejador de bases de datos con cada tipo de información.
No obstante que pueden desarrollarse sistemas de procesamiento de archivoe incluso manejadores de bases de datos basándose en la experiencia del equipo de desarrollo de software logrando resultados altamente aceptables, siempre es recomendable la utilización de determinados estándares de diseño que garantizan el nivel de eficiencia mas alto en lo que se refiere a almacenamiento y recuperación de la información.
De igual manera se obtiene modelos que optimizan el aprovechamiento secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse al usuario.
OBJETIVOS DEL DISEÑO DE BASES DE DATOS
Almacenar Solo La Información Necesaria.
A menudo pensamos en todo lo que quisiéramos que estuviera almacenado en una base de datos y diseñamos la base de datos para guardar dichos datos. Debemos de ser realistas acerca de nuestras necesidades y decidir qué información es realmente necesaria.
Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos también tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicación.
Normalizar la Estructura de las Tablas.
Si nunca antes hemos oídohablar de la " normalizaciónde datos", no debemos temer. Mientras que la normalización puede parecer un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización.
Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir la pista de nuestra colección de CD’s en una hoja de cálculo, podríamos diseñar algo parecido a lo que se muestra en la siguiente tabla.
+------------+-------------+--------------+ .. +--------------+
| Álbum | track1 | track2 | | track10 |
+------------+-------------+--------------+ .. +--------------+
Esto parece razonable. Sin embargo el problema es que el número de pistas que tiene un CD varía bastante. Esto significa que con este método tendríamos que tener una hoja de cálculorealmente grande para albergar todos los datos, que en los peores casos podrían ser de hasta 20 pistas. Esto en definitiva no es nada bueno.
Uno de los objetivosde una estructura de tabla normalizada es minimizar el número de "celdas vacías". El darnos cuenta de que cada lista de CD’s tiene un conjunto fijo de campos (título, artista, año, género) y un conjunto variable de atributos (el número de pistas) nos da una idea de cómo dividir los datos en múltiples tablas que luego podamos relacionar entre sí.
Mucha gente no esta familiarizada con el concepto "relacional", de manera sencilla esto significa, que grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común.
Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está en el hecho que podemos agregar datos al sistemaposteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiéramos agregar la información de los artistas de cada álbum, lo único que tenemos que hacer es crear una tabla artista que esté relacionada a la tabla álbum de la misma manera que la tabla pista. Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta.
La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y tampoco tenemos grandes cantidades de "celdas vacías".
El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información.
Es importante que esta información se almacene sin redundancia para que se pueda tener una recuperación rápida y eficiente de los datos.
A través de la normalización tratamos de evitar ciertos defectos que nos conduzcan a un mal diseño y que lleven a un procesamiento menos eficaz de los datos.
Podríamos decir que estos son los principales objetivos de la normalización:
• Controlar la redundancia de la información.
• Evitar pérdidas de información.
• Capacidad para representar toda la información.
• Mantener la consistencia de los datos.
Seleccionar el Tipo de Dato Adecuado.
Una vez identificadas todas las tablas y columnas que necesita la base de datos, debemos determinar el tipo de dato de cada campo. Existen tres categorías principales que pueden aplicarse prácticamente a cualquier aplicación de bases de datos:
• Texto
• Números
• Fecha y hora
Cada uno de éstos presenta sus propias variantes, por lo que la elección del tipo de dato correcto no sólo influye en el tipo de información que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos.
A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de dato adecuado para nuestras tablas:
• Identificar si una columna debe ser de tipo texto, numérico o de fecha.
• Elegir el subtipo más apropiado para cada columna.
• Configurar la longitud máxima para las columnas de texto y numéricas, así como otros atributos.
Utilizar Índices Apropiadamente
Los índices son un sistema especial que utilizan las bases de datos para mejorar su rendimiento global. Dado que los índices hacen que las consultas se ejecuten más rápido, podemos estar incitados a indexar todas las columnas de nuestras tablas.
Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, MySQLtiene que actualizar cualquier índice en la tabla para reflejar los cambios en los datos.
¿Así que, cómo decidimos usar índices o no? La respuesta es "depende". De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas.
Así que antes de indexar una columna, debemos considerar que porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es demasiado alto, seguramente no veremos alguna mejora con el uso de un índice. Ante la duda, no tenemos otra alternativa que probar.
Usar Consultas REPLACE
Existen ocasiones en las que deseamos insertar un registro a menos de que éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos hacer es una actualización de los datos.
Usar Una Versión Reciente de MySQL
La recomendación es simple y concreta, siempre que esté en nuestras manos, debemos usar la versión más reciente de MySQL que se encuentre disponible. Además de que las nuevas versiones frecuentemente incluyen muchas mejoras, cada vez son más estables y más rápidas. De esta manera, a la vez que sacamos provecho de las nuevas características incorporadas en MySQL, veremos significativos incrementos en la eficiencia de nuestro servidor de bases de datos.
Usar Tablas Temporales.
Cuando estamos trabajando con tablas muy grandes, suele suceder que ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas sobre la tabla completa y hacer que MySQL encuentre cada vez los pocos registros que necesitamos, puede ser mucho más rápido seleccionar dichos registros en una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla.
Una tabla temporal existe mientras dure la conexión a MySQL. Cuando se interrumpe la conexión MySQL remueve automáticamente la tabla y libera el espacio que ésta usaba.
Recomendaciones.
El último paso del diseño de la base de datos es adoptar determinadas convenciones de nombres. Aunque MySQL es muy flexible en cuanto a la forma de asignar nombre a las bases de datos, tablas y columnas, he aquí algunas reglas que es conveniente observar:
• Utilizar caracteres alfanuméricos.
• Limitar los nombres a menos de 64 caracteres (es una restricción de MySQL).
• Utilizar el guión bajo (_) para separar palabras.
• Utilizar palabras en minúsculas (esto es más una preferencia personal que una regla).
• Los nombres de las tablas deberían ir en plural y los nombres de las columnas en singular (es igual una preferencia personal).
• Utilizar las letras ID en las columnas de clave primaria y foránea.
• En una tabla, colocar primero la clave primaria seguida de las claves foráneas.
• Los nombres de los campos deben ser descriptivos de su contenido.
• Los nombres de los campos deben ser unívocos entre tablas, excepción hecha de las claves.
DISEÑO DE LA INTERFAZ DE USUARIO
El diseño de interfaces de usuario es una tarea que ha adquirido relevancia en el desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los motivos que conduzca a un sistema al éxito o al fracaso. Los principios que se presentan son de utilidadpara creación de interfaces funcionales y de fácil operación. A pesar de no ser capaces de resolver todos los aspectos propios del contexto con el que se esté trabajando, pueden ser combinados con la prototipación y la aplicación de heurísticas de evaluación para facilitar el proceso de diseño. El presente artículo se centra en los componentes de software de las interfaces de usuario, quedando fuera del alcance de mismo otros aspectos, como hardware y documentación. Lo anteriormente expuesto se complementa con un caso práctico de diseño de interfaces de usuario, producto de realizar la actividad de "Definición de Interfaces de Usuario" (EFS 4) de la metodología Métrica Versión 2.
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.
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.
Autonomía
La computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambienteflexible 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.
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
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 valorespor 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
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.
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.
Autonomía
La computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se debe dar al usuario el ambienteflexible 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.
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
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 valorespor 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
MODELO ORIENTADO A OBJETOS
Las aplicaciones de las bases de datos en áreas como el diseño asistido por computadora, la ingeniería de software y el procesamiento de documentos no se ajustan al conjunto de suposiciones que se hacen para aplicaciones del estilo de procesamiento de datos. El modelo de datos orientado a objetos se ha propuesto para tratar algunos de estos nuevos tipos de aplicaciones.
El modelo de bases de datos orientado a objetos es una adaptación a los sistemas de bases de datos. Se basa en el concepto de encapsulamiento de datos y código que opera sobre estos en un objeto. Los objetos estructurados se agrupan en clases. El conjunto de clases esta estructurado en sub y superclases basado en una extensión del concepto ISA del modelo Entidad - Relación. Puesto que el valor de un dato en un objeto también es un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto.
El propósito de los sistemas de bases de datos es la gestión de grandes cantidades de información. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestión de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerárquicas y, más tarde, en bases de datos relacionales.
Estructura de objetos.
El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes.
Un objeto tiene asociado:
• un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto.
• Un conjunto de mensajes a los que el objeto responde.
• Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un valor como respuesta al mensaje.
El término mensaje en un contexto orientado a objetos, no implica el uso de un mensaje físico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación.
La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de las mayores ventajas del modelo de programación orientado a objetos.
El modelo de bases de datos orientado a objetos es una adaptación a los sistemas de bases de datos. Se basa en el concepto de encapsulamiento de datos y código que opera sobre estos en un objeto. Los objetos estructurados se agrupan en clases. El conjunto de clases esta estructurado en sub y superclases basado en una extensión del concepto ISA del modelo Entidad - Relación. Puesto que el valor de un dato en un objeto también es un objeto, es posible representar el contenido del objeto dando como resultado un objeto compuesto.
El propósito de los sistemas de bases de datos es la gestión de grandes cantidades de información. Las primeras bases de datos surgieron del desarrollo de los sistemas de gestión de archivos. Estos sistemas primero evolucionaron en bases de datos de red o en bases de datos jerárquicas y, más tarde, en bases de datos relacionales.
Estructura de objetos.
El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes.
Un objeto tiene asociado:
• un conjunto de variables que contienen los datos del objeto. El valor de cada variable es un objeto.
• Un conjunto de mensajes a los que el objeto responde.
• Un método, que es un trozo de código para implementar cada mensaje. Un método devuelve un valor como respuesta al mensaje.
El término mensaje en un contexto orientado a objetos, no implica el uso de un mensaje físico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación.
La capacidad de modificar la definición de un objeto sin afectar al resto del sistema está considerada como una de las mayores ventajas del modelo de programación orientado a objetos.
Suscribirse a:
Comentarios (Atom)