Sign in or 
Share this
2.A.1.1.2.2.-Interfaces: Desarrollo basado en modelos
________________________________________________________________________________________________
-------------------------------------------------Alejandro Gustavo Sabatini
-------------------------------------------------
------------
-
-
- 
--------------------------------Ver 2.A.1.1.3.4.-Metodologia para la Investigacion de la Interaccion
---------------------------------------------------2.A.2.1.-Diseños de Interface
________________________________________________________________________________________________
-------------------------------------------------------Interfaz de usuario:
Definida la interface como lo que permite la comunicación entre un usuario y la máquina o computadora, podría decirse que
es como un sistema de traducción para dicha comunicación. La interface o interfaz de usuario podría ser definida como el conjunto de componentes empleados por los usuarios para comunicarse con las computadoras. Por ello hay que tener en cuenta las características humanas para el diseño de la interfaz, tales como las habilidades cognitivas y de percepción de las personas. Debido a esto último se debe tener en cuenta: la adecuación sobre las características físicas del : Ambiente, Visibilidad, Edad y Personalidad.
A.-Diseño de interfaz de usuario. Conceptos generales:
Reunir y analizar la información del usuario.
Diseñar la interfaz de usuario. Construir la interfaz de usuario.
Validar la interfaz de usuario.
B.-Reglas para el diseño de interfaces de usuario:
Dar control al usuario:
Permitir a los usuarios utilizar el teclado o el ratón.
Permitir al usuario interrumpir su tarea y continuarla más tarde.
Permitir deshacer las acciones, e informar de su resultado.
Reducir la carga de memoria del usuario:
Permitir deshacer, copiar y pegar.
Saber en que lugar esta ubicado.
Presentar al usuario sólo la información que necesita.
Consistencia:
En la realización de las tareas.
Dentro del propio producto.
En los resultados. En la apariencia estética.
C.-Técnicas avanzadas y pasos para el diseño de interfaces de usuario:
Presentación de información:
No se deben colocar demasiados objetos en la pantalla.
Los objetos deben estar bien distribuidos.
Análisis de Color:
El color comunica información.
Deben utilizarse combinaciones adecuadas.
El color debe atraer la atención. Principio básico.
Tener en cuenta que los objetos verdes o azules parecen más grandes que aquellos que son rojos o amarillos. Combinaciones de colores
Análisis Audio:
Analizar cuándo es más apropiado utilizar audio.
Determinar el sonido adecuado.
Se debe permitir la personalización.
El sonido debe usarse para informar.
Análisis Animación:
Se define como un cambio en el tiempo de la apariencia visual de un elemento gráfico.
Ejemplos de su uso: progreso de acciones, estado de procesos, etc.
Guías de Expertos.
Demasiada simetría puede hacer las pantallas difíciles de leer.
Asumir errores en la entrada del usuario.
Diseñar para el usuario, no para demostrar los propios conocimientos tecnológicos.
Unos gráficos espectaculares no salvarán a una mala interfaz.
Utilidad. El concepto “utilidad” se refiere al grado en que un producto ofrece la posibilidad al usuario de conseguir sus metas. Una interfaz que sea de fácil uso y aprendizaje pero no permite al usuario lograr sus objetivos no será utilizada.
D.-Evaluación de Interfaces Gráficas de Usuario:
Un método de evaluación es aquel procedimiento en el que se recogen datos relevantes sobre la operatibilidad y usabilidad de un sistema.
Llevar adelante la evaluación es:
Conocer el mundo real donde la interfaz va a funcionar.
Comparar ideas. Dar un objetivo claro al desarrollo de la interfaz.
Comparar la interfaz con unos estándares.
E.-Formas de Evaluar:
La evaluación automática.
La evaluación empírica.
La evaluación formal.
La evaluación informal.
Clasificación de Interfaces de usuarios -software-:
1.-Interfaces de línea de comandos (command-line user interfaces, CUIs).
1.1.- Desventajas: Memorizar las instrucciones. Ayuda difícil de leer. Nombres de Instrucciones inadecuados. 1.2.-Ventajas: Potente. Flexible. Controlado por usuarios experimentados
2.-Interfaces de menús.
Menú es una lista de opciones.
Permiten:
2.1.-Navegar dentro de un sistema.
2.2.-Seleccionar propiedades o acciones de un objeto.
2.3.-Se usan cuando la computadora se vuelve una herramienta de usuario.
2.4.-Tipos de menús
2.4.1.- Menús de pantalla completa.
2.4.2.-Menús de barra.
2.4.3.-Menús en cascada.
2.4.4.-Paletas o barras de herramientas.
2.4.4.- Menús contextuales.
3.-Interfaces gráficas (Graphical User Interfaces, GUIs).
Están basadas en iconos y elementos gráficos.
No requieren un uso de la memoria a largo plazo.
Fácil de usar.
Características
Provee de un gráfico de alta resolución.
Provee elementos de interfaz estándar como menús y diálogos.
Proporciona respuesta visual a las acciones del usuario.
Permite a los usuarios personalizar la interface
---------------------------Principios de diseño de interacción de Interfaces gráficas:
--------------------------Métodos de Evaluación de Interfaces Gráficas de usuarios:
----------------------------Previos a al distribución comercial.
----------------------------Durante la vida activa del producto.
4.-Interfaces orientadas a objetos (Object Oriented User Interfaces, OOUIs).
Trata de hacer uso de los conocimientos previos.
Metáforas.
El objetivo de la OOUI es que el usuario se concentre en sus tareas y no en la computadora.
La interfaz establece qué peticiones se pueden hacer a un objeto particular.
Sin embargo, se debe codificar en algún sitio para satisfacer esta petición. Ésta, junto con los datos ocultos, constituyen la implementación.
Desde el punto de vista de la programación procedural, no es complicado. Un tipo tiene una función asociada para cada posible petición, y cuando se hace una petición particular a un objeto, se llama a esa función. Este proceso normalmente se resume diciendo que ha “enviado un mensaje” (ha hecho una petición) a un objeto, y el objeto sabe qué hacer con este mensaje (ejecuta código).
_______________________________________________________________________________________________
¡Esa máquina puede hacer cosas sola!
Por Ariel Torres
Link corto: http://www.lanacion.com.ar/1079685
________________________________________________________________________________________________
------------
--------
---------------------------------------http://uwnews.org/article.asp?articleID=42817
Interface Informática que se adapta al usuario para un mejor manejo del ratón:
Los diseños estándares son especialmente frustrantes para los discapacitados, los ancianos y cualquiera que tenga problemas para controlar un ratón. Una nueva estrategia de diseño, desarrollada en la Universidad de Washington, permitirá que una interfaz "inteligente" someta a una pequeña prueba de habilidades a cada persona, lo cual le permitirá entonces generar mediante cálculos matemáticos una versión de sí misma optimizada para las habilidades motoras y de visión de dicha persona. Este sistema ofrece por primera vez un método personalizable al instante para las interfaces de usuario.
"Las tecnologías de interfaz están diseñadas sobre la suposición de que son las personas las que tienen que adaptarse a la tecnología. Nosotros intentamos invertir ese concepto, y hacer que el software se adapte a las personas", explica el científico principal del proyecto, Krzysztof Gajos. Dan Weld y Jacob Wobbrock son coautores de la investigación.
Las pruebas mostraron que el sistema redujo la diferencia de eficacia de manejo entre usuarios sanos y discapacitados en un 62 por ciento, y los usuarios discapacitados prefirieron mayormente esas interfaces personalizadas generadas de modo automático.
Esto demuestra que la generación automática de interfaces personalizadas realmente funciona, y que la tecnología está lista para ser usada.
Completar la información con le referido en el archivo: 2.A.2.1.-Diseños de Interfaces
_____________________________________________________________________________________
http://www.l-lab.de/EN/Projects/PRJ_human_machine.jsp
Relacione esta información con 2.A.1.1.3.4.-Metodologia para la Investigacion de la Interaccion
________________________________________________________________________________________________
Uso del diseño basado en modelos para probar y verificar el software embebido de automoción:
------------------------
El diseño basado en modelos se ha convertido en la mejor opción para el desarrollo de software embebido de automoción, ya que mejora las fases de especificación, diseño e implementación. En la actualidad, existen nuevas herramientas y funciones para el diseño basado en modelos que ayudan a afrontar el reto que supone la realización de pruebas y verificaciones, y a la vez, mejoran la calidad del software embebido y acortan el ciclo de pruebas y verificaciones.
Diseño basado en modelos para la realización de pruebas y verificación:
Los ingenieros de automoción suelen usar modelos para desarrollar funciones que se ejecutan en una unidad de control electrónica (ECU, del inglés Electronic Control Unit). En el diseño basado en modelos estos últimos se usan de múltiples formas: para proporcionar especificaciones ejecutables, para analizar el comportamiento dinámico del sistema, para simular los componentes y las condiciones del entorno reduciendo o eliminando la necesidad de costosos prototipos físicos, y para diseñar algoritmos. Además, la generación automática de código a partir de estos modelos se ha afianzado como una forma de implementación del software de producción de las ECU. Se espera que en los próximos años se convierta en la opción principal para la implementación de software de control embebido en muchas empresas de automoción.
Desde una perspectiva de calidad, la generación automática de código ya es de gran ayuda, porque optimiza el diseño mediante el análisis y la simulación y garantiza la repetibilidad de la calidad del código generado automáticamente. Además, el código se puede generar desde los modelos de componentes del sistema y del entorno para generar pruebas de hardware–in-the-loop (HIL).
En la actualidad, gracias a enfoques nuevos y mejorados, se puede sacar el máximo partido a estos mismos modelos con utilidades más potentes y variadas, entre las que se incluyen pruebas basadas en requisitos, análisis de cobertura y generación de pruebas. Todo esto sirve para acelerar y mejorar la realización de pruebas y verificaciones de los complejos sistemas embebidos actuales, incluidos el software embebido y los componentes electrónicos.
Seguimiento y comprobación de requisitos:
En la mayoría de los estándares de procesos y software, como CMM-I, es necesario que la trazabilidad entre el diseño y los requisitos sea bidireccional durante todo el desarrollo. El código de implementación también ha de ser trazable con respecto al diseño, para que pueda ser revisado y verificado. Las herramientas de diseño basado en modelos pueden vincular el texto de los requisitos, guardado en Excel, Word o en una herramienta de gestión de requisitos, con el modelo (el diseño). Cualquier requisito que no se cumpla en el diseño puede marcarse, de la misma manera que pueden marcarse los elementos del diseño que no se correspondan con un requisito. Si se cambia un requisito (o diseño), las herramientas indican los elementos del diseño correspondientes (o los requisitos) que pueden verse afectados. Además, el generador automático de código puede insertar enlaces HTML en el código C generado para que se pueda determinar el origen de la implementación en el modelo, algo muy importante sobre todo en aquellos sistemas en los que la seguridad es vital. El conjunto de estas funciones ofrece una ruta de trazabilidad completa desde el código a los requisitos (figura 1).
Además de vincular los requisitos al diseño, las herramientas del diseño basado en modelos ofrecen funciones que sirven para confirmar que el diseño cumple ciertos requisitos. Estos requisitos se introducen en el modelo del diseño como propiedades (o afirmaciones), y los algoritmos de métodos formales determinan matemáticamente si las propiedades se cumplen en todas las situaciones válidas. Si existe un escenario que pueda infringir las propiedades, la herramienta de método formal genera un contraejemplo que el ingeniero puede usar en simulaciones y añadir al plan de pruebas.
Comprobación del estilo de los modelos:
Durante la fase de diseño, un modelo de alto nivel inicial se transforma en un modelo adecuado para su implementación, ya que se le incluyen las características necesarias para la implementación, como son datos de coma fija, y se eliminan las partes que no se implementarán. De la misma manera que los ingenieros de software establecen directrices sobre el estilo del código fuente para que sea más fácil su lectura, prueba e implementación, los ingenieros que trabajan en el diseño basado en modelos, establecen directrices sobre el estilo de los modelos para garantizar que el modelo pueda ser implementado y facilitar también su comprensión y prueba.
En función del flujo de trabajo deseado y de si el diseño representa una nueva función o una modificación de una función existente, se puede proceder de dos maneras: limitar las opciones disponibles desde el principio al diseñador, o realizar comprobaciones en el diseño más adelante, a medida que se va transformando.
En el primer enfoque, usado con frecuencia en sistemas en los que la seguridad es vital o en diseños que son pequeñas modificaciones de una implementación ya existente, las restricciones se aplican al principio del proyecto. Generalmente, esta estrategia se basa en la definición de un subconjunto restringido de componentes del modelo (bloques o máquinas de estado), estructuras de modelado (la manera en que los bloques están conectados), y otros ajustes (p. ej. aspectos de coma fija) que no necesitan ser comprobados manualmente en cada diseño porque las herramientas lo hacen sistemáticamente.
En el segundo enfoque, se comprueba si el modelo cumple las directrices más adelante en el proceso de desarrollo. El hecho de que la comprobación sea posterior permite que el diseñador comience con un diseño sin restricciones y, luego, se vaya limitando y transformando gradualmente el diseño hasta conseguir una implementación sólida y lista para la realización de pruebas. El lugar ideal para la comprobación de este modelo es el propio entorno del modelado, para que el desarrollador pueda detectar rápidamente los problemas y editar el diseño de una manera eficiente e interactiva.
Se han introducido recientemente herramientas que permiten al equipo de ingeniería definir y personalizar un conjunto de normas para la comprobación de modelos, aplicarlas a los modelos y localizar inmediatamente las excepciones.
Análisis y garantía de la cobertura del modelo:
El modelo ofrece la oportunidad en las primeras etapas del proceso de diseño, antes de la implementación, de llevar a cabo los tipos de pruebas que se realizarían después con la comprobación basada en el código fuente. Los ingenieros realizan pruebas de esfuerzo con el controlador para verificar la integridad del diseño y detectar problemas tales como las secciones inalcanzables del diseño que aparecerían más tarde como código muerto.
Los ingenieros realizan a menudo simulaciones muy exhaustivas de los modelos para confirmar que un diseño es sólido y funciona correctamente. No obstante, estas simulaciones sólo son tan útiles como los escenarios que ejecutan.
La realización de pruebas de esfuerzo mediante la ejecución de simulaciones con valores numéricos máximos y mínimos ayuda a evitar que se produzcan condiciones de desbordamiento. También es importante comprobar que durante las simulaciones se prueben todas las partes del diseño, y todos los modos y ramificaciones lógicas del diseño.
En el análisis de cobertura del modelo se evalúan los resultados acumulados de una serie de pruebas para determinar los bloques o estados que fueron ejecutados durante una simulación y los que no lo fueron. Algunos análisis de cobertura están bien establecidos en los lenguajes de código fuente, como C, C++ y Ada, pero estos tipos de análisis no han estado disponibles para los modelos hasta hace poco. [2]
La Administración Federal de Aviación de Estados Unidos (FAA) considera la cobertura de decisión/condición (MD/DC) como el nivel de cobertura más riguroso que deben cumplir los sistemas en los que la seguridad es vital. Este análisis de la cobertura, entre otros, está ahora disponible en el diseño basado en modelos y se se basa en la ejecución de las simulaciones. Cuando se realiza dentro de las herramientas de simulación, MC/DC permite el registro automático y la creación de informes de los datos de cobertura del modelo (figura 2). Así, el ingeniero de pruebas puede evaluar si los escenarios de prueba están completos en lo referente a la estructura del diseño. El desafío se presenta entonces en la definición de un conjunto de pruebas que representen una cobertura total de manera eficiente.
Generación automática de pruebas:
Un nuevo conjunto de herramientas para el diseño basado en modelos puede generar automáticamente patrones de prueba que satisfagan los objetivos de cobertura especificados, como MC/DC, analizando automáticamente la estructura del modelo y usando métodos formales para generar patrones. Este análisis estructural también identifica si hay partes del modelo que nunca se ejecutan, lo que puede ser una indicación de que algo no se tuvo en cuenta durante la creación de la especificación, la implementación o las pruebas.
Se pueden combinar estos patrones de prueba con otros escenarios de prueba derivados de los requisitos, de los datos de los bancos de prueba, de escenarios de Monte Carlo y de modelos de planta o entorno para probar de manera exhaustiva el modelo a través de simulaciones, así como durante su posterior implementación real.
----------------------------
Comprobación del cumplimiento de las directrices MISRA-C en el código:
La Asociación para la fiabilidad de software en la industria del motor (Motor Industry Software Reliability Association - MISRA) ha publicado “Guidelines for the Use of the C Language in Vehicle Based Software” (Directrices sobre el uso del lenguaje C en software para vehículos). Cada vez más fabricantes y proveedores de automóviles adoptan este conjunto de directrices, conocido comúnmente como MISRA-C. [5] Gran parte de la comprobación del cumplimiento de las directrices de MISRA-C de un modelo se puede llevar a cabo mirando lo que la herramienta de generación automática de código genera de forma sistemática, en lugar de comprobar todo el código generado, algo que sí es necesario si se crea manualmente.
Pero la comprobación de la herramienta de generación de código no incluye ciertos escenarios, como el código heredado y escrito a mano importado. Se pueden usar interfaces abiertas de modelos para comprobar automáticamente estos escenarios. De esta manera, las comprobaciones se realizan después de la creación del modelo y antes de la generación de código, garantizando así la verificación del código generado e importado. Otra opción es incluir un comprobador de código MISRA-C o una herramienta de análisis estático en el proceso de generación de código.
Detección de errores en tiempo de ejecución:
Los errores en tiempo de ejecución son especialmente difíciles de detectar a nivel del modelo o durante la simulación y esto puede ocasionar problemas graves durante el desarrollo o las pruebas del software. Los errores en tiempo de ejecución son fallos latentes, que a menudo se producen con combinaciones específicas de valores de datos, por lo que resulta caro localizarlos mediante la realización de pruebas dinámicas. De hecho, normalmente se descubren por las consecuencias que tienen en comportamientos funcionales, por ejemplo, en el envío de comandos inesperados a actuadores, la parada del coprocesador matemático y fallos inexplicables del software o difíciles de reproducir. En estos casos, es necesario un largo proceso de depuración para localizar el origen del problema. [3]
El análisis estático es un enfoque válido para la detección de los errores en tiempo de ejecución. En los últimos años, se han introducido herramientas de verificación estáticas que utilizan técnicas de análisis avanzado y han reducido el número de resultados “falso-positivos” que requieren una inspección o realización manual de pruebas .[4] Estas herramientas realizan un análisis estático, y también dinámico, del código C, independientemente de si el código se generó de manera automática o manual.
La integración de estas herramientas de verificación con las herramientas del diseño basado en modelos supone una mejora importante para el flujo de trabajo. Al conectar el código analizado y el modelo a partir del cual se generó automáticamente, la herramienta de verificación estática puede presentar sus resultados tanto en el código fuente como en el modelo. El hecho de poder navegar desde el código al modelo, realizar el cambio y, después volver a generar y comprobar el código automáticamente, hace que ésta sea una manera muy eficaz para analizar, depurar y modificar algoritmos tanto desde una perspectiva de alto nivel como de detalle. De este modo, se mejora el proceso de desarrollo ya que los cambios se realizan en el modelo en lugar de directamente en el código, lo que aumenta la longevidad y reutilización de los modelos entre proyectos.
Observaciones finales:
La filosofía clave descrita en este artículo representa las tres mejores prácticas con el objetivo de sacar el máximo partido del diseño basado en modelos durante la realización de pruebas y verificaciones.
En primer lugar, se aconseja la reutilización de los modelos como banco de pruebas para la implementación. Puede recopilar conocimientos, datos de pruebas y otra información útil que podrá reutilizar más adelante en los procesos de desarrollo y realización de pruebas a partir de diferentes acciones como la simulación de modelos, la implementación de software vinculado a los modelos, la ejecución en un (ordenador) host o en el procesador destino de la implementación o la ejecución del sistema completo embebido en un banco de pruebas.
En segundo lugar, se aconseja que se realicen las siguientes pruebas lo antes posible: realización de pruebas en la etapa de simulación antes que en tiempo real, realización de pruebas en tiempo real en el banco de pruebas antes de aplicarlo al mundo real y realización de pruebas sobre el modelo anterior a la generación de código. La realización de pruebas al principio del proceso es generalmente más fácil, ya que el nivel de abstracción es más alto, y resulta mucho más barato detectar los errores en esta fase.
En tercer lugar, se aconseja aprovechar al máximo todas las técnicas disponibles. Los métodos de simulación y formales deberían compaginarse para sacarles el máximo partido a ambos; las técnicas basadas en código y las basadas en modelos para la realización de pruebas y verificaciones han de complementarse las unas a las otras, y todasestán disponibles para ser utilizadascon el diseño basado en modelos en una gama de herramientas de distintos proveedores.
Muchos fabricantes y proveedores de equipamiento original para coches utilizan el diseño basado en modelos para generar especificaciones ejecutables, simular su rendimiento y generar código automáticamente. Muchas de estas empresas comienzan a dar el siguiente paso, aprovechando los modelos existentes para realizar pruebas y verificaciones. Este artículo recoge una amplia gama de métodos actuales para ilustrar los enfoques prácticos que pueden usarse para mejorar la calidad y reducir los costes del software embebido de automoción.
Referencia http://www.convertronic.net/index.phpoption=com_content&task=view&id=1345&Itemid=22
_______________________________________________________________________________________________
_____________________________________________________________________________________
-------------------------------Autos potenciados con registros de laboratorio para Diabéticos:
---------------------------
----------------ver la URL http://www.medgadget.com/archives/2008/06/mpowered_car_for_diabetics.html
_____________________________________________________________________________________
Tendencias Nuevas tecnologías: ahora se aprende en tres dimensiones
http://www.lanacion.com.ar/nota.asp?nota_id=1029501
______________________________________________________________________________________
Algoritmo para que un ordenador clasifique datos con versatilidad humana
Los humanos tenemos una tendencia natural a buscar organización en los conjuntos de información, una
habilidad que se ha comprobado que es difícil de replicar en los ordenadores. Al enfrentarse con un conjunto
grande de datos, los ordenadores no saben por dónde comenzar, a menos que estén programados para trabajar
con una estructura específica, como por ejemplo una jerarquía o un orden lineal.
________________________________________________________________________________________
---------
______________________________________________________________________________________
Misceláneas:
INAMO
Primer Restaurante Interactivo - con tecnología informática que permite como interface realizar pedidos de cocina gourmet.-
http://www.inamo-restaurant.com/
SMALL DISHES 
LARGE DISHES
_____________________________________________________________________________________
SITEMAP http://interfacemindbraincomputer.wetpaint.com/sitemap
-------------------------------------------------Alejandro Gustavo Sabatini
-------------------------------------------------
------------
--- --------------------------------Ver 2.A.1.1.3.4.-Metodologia para la Investigacion de la Interaccion
---------------------------------------------------2.A.2.1.-Diseños de Interface
________________________________________________________________________________________________
-------------------------------------------------------Interfaz de usuario:
Definida la interface como lo que permite la comunicación entre un usuario y la máquina o computadora, podría decirse que
es como un sistema de traducción para dicha comunicación. La interface o interfaz de usuario podría ser definida como el conjunto de componentes empleados por los usuarios para comunicarse con las computadoras. Por ello hay que tener en cuenta las características humanas para el diseño de la interfaz, tales como las habilidades cognitivas y de percepción de las personas. Debido a esto último se debe tener en cuenta: la adecuación sobre las características físicas del : Ambiente, Visibilidad, Edad y Personalidad.
A.-Diseño de interfaz de usuario. Conceptos generales:
Reunir y analizar la información del usuario.
Diseñar la interfaz de usuario. Construir la interfaz de usuario.
Validar la interfaz de usuario.
B.-Reglas para el diseño de interfaces de usuario:
Dar control al usuario:
Permitir a los usuarios utilizar el teclado o el ratón.
Permitir al usuario interrumpir su tarea y continuarla más tarde.
Permitir deshacer las acciones, e informar de su resultado.
Reducir la carga de memoria del usuario:
Permitir deshacer, copiar y pegar.
Saber en que lugar esta ubicado.
Presentar al usuario sólo la información que necesita.
Consistencia:
En la realización de las tareas.
Dentro del propio producto.
En los resultados. En la apariencia estética.
C.-Técnicas avanzadas y pasos para el diseño de interfaces de usuario:
Presentación de información:
No se deben colocar demasiados objetos en la pantalla.
Los objetos deben estar bien distribuidos.
Análisis de Color:
El color comunica información.
Deben utilizarse combinaciones adecuadas.
El color debe atraer la atención. Principio básico.
Tener en cuenta que los objetos verdes o azules parecen más grandes que aquellos que son rojos o amarillos. Combinaciones de colores
Análisis Audio:
Analizar cuándo es más apropiado utilizar audio.
Determinar el sonido adecuado.
Se debe permitir la personalización.
El sonido debe usarse para informar.
Análisis Animación:
Se define como un cambio en el tiempo de la apariencia visual de un elemento gráfico.
Ejemplos de su uso: progreso de acciones, estado de procesos, etc.
Guías de Expertos.
Demasiada simetría puede hacer las pantallas difíciles de leer.
Asumir errores en la entrada del usuario.
Diseñar para el usuario, no para demostrar los propios conocimientos tecnológicos.
Unos gráficos espectaculares no salvarán a una mala interfaz.
Utilidad. El concepto “utilidad” se refiere al grado en que un producto ofrece la posibilidad al usuario de conseguir sus metas. Una interfaz que sea de fácil uso y aprendizaje pero no permite al usuario lograr sus objetivos no será utilizada.
D.-Evaluación de Interfaces Gráficas de Usuario:
Un método de evaluación es aquel procedimiento en el que se recogen datos relevantes sobre la operatibilidad y usabilidad de un sistema.
Llevar adelante la evaluación es:
Conocer el mundo real donde la interfaz va a funcionar.
Comparar ideas. Dar un objetivo claro al desarrollo de la interfaz.
Comparar la interfaz con unos estándares.
E.-Formas de Evaluar:
La evaluación automática.
La evaluación empírica.
La evaluación formal.
La evaluación informal.
Clasificación de Interfaces de usuarios -software-:
1.-Interfaces de línea de comandos (command-line user interfaces, CUIs).
1.1.- Desventajas: Memorizar las instrucciones. Ayuda difícil de leer. Nombres de Instrucciones inadecuados. 1.2.-Ventajas: Potente. Flexible. Controlado por usuarios experimentados
2.-Interfaces de menús.
Menú es una lista de opciones.
Permiten:
2.1.-Navegar dentro de un sistema.
2.2.-Seleccionar propiedades o acciones de un objeto.
2.3.-Se usan cuando la computadora se vuelve una herramienta de usuario.
2.4.-Tipos de menús
2.4.1.- Menús de pantalla completa.
2.4.2.-Menús de barra.
2.4.3.-Menús en cascada.
2.4.4.-Paletas o barras de herramientas.
2.4.4.- Menús contextuales.
3.-Interfaces gráficas (Graphical User Interfaces, GUIs).
Están basadas en iconos y elementos gráficos.
No requieren un uso de la memoria a largo plazo.
Fácil de usar.
Características
Provee de un gráfico de alta resolución.
Provee elementos de interfaz estándar como menús y diálogos.
Proporciona respuesta visual a las acciones del usuario.
Permite a los usuarios personalizar la interface
---------------------------Principios de diseño de interacción de Interfaces gráficas:
--------------------------Métodos de Evaluación de Interfaces Gráficas de usuarios:
----------------------------Previos a al distribución comercial.
----------------------------Durante la vida activa del producto.
4.-Interfaces orientadas a objetos (Object Oriented User Interfaces, OOUIs).
Trata de hacer uso de los conocimientos previos.
Metáforas.
El objetivo de la OOUI es que el usuario se concentre en sus tareas y no en la computadora.
La interfaz establece qué peticiones se pueden hacer a un objeto particular.
Sin embargo, se debe codificar en algún sitio para satisfacer esta petición. Ésta, junto con los datos ocultos, constituyen la implementación.
Desde el punto de vista de la programación procedural, no es complicado. Un tipo tiene una función asociada para cada posible petición, y cuando se hace una petición particular a un objeto, se llama a esa función. Este proceso normalmente se resume diciendo que ha “enviado un mensaje” (ha hecho una petición) a un objeto, y el objeto sabe qué hacer con este mensaje (ejecuta código).
_______________________________________________________________________________________________
¡Esa máquina puede hacer cosas sola!
Por Ariel Torres
Link corto: http://www.lanacion.com.ar/1079685
________________________________________________________________________________________________
------------
--------
---------------------------------------http://uwnews.org/article.asp?articleID=42817
Interface Informática que se adapta al usuario para un mejor manejo del ratón:
Los diseños estándares son especialmente frustrantes para los discapacitados, los ancianos y cualquiera que tenga problemas para controlar un ratón. Una nueva estrategia de diseño, desarrollada en la Universidad de Washington, permitirá que una interfaz "inteligente" someta a una pequeña prueba de habilidades a cada persona, lo cual le permitirá entonces generar mediante cálculos matemáticos una versión de sí misma optimizada para las habilidades motoras y de visión de dicha persona. Este sistema ofrece por primera vez un método personalizable al instante para las interfaces de usuario."Las tecnologías de interfaz están diseñadas sobre la suposición de que son las personas las que tienen que adaptarse a la tecnología. Nosotros intentamos invertir ese concepto, y hacer que el software se adapte a las personas", explica el científico principal del proyecto, Krzysztof Gajos. Dan Weld y Jacob Wobbrock son coautores de la investigación.
Las pruebas mostraron que el sistema redujo la diferencia de eficacia de manejo entre usuarios sanos y discapacitados en un 62 por ciento, y los usuarios discapacitados prefirieron mayormente esas interfaces personalizadas generadas de modo automático.
Esto demuestra que la generación automática de interfaces personalizadas realmente funciona, y que la tecnología está lista para ser usada.
Completar la información con le referido en el archivo: 2.A.2.1.-Diseños de Interfaces
_____________________________________________________________________________________
http://www.l-lab.de/EN/Projects/PRJ_human_machine.jsp
Relacione esta información con 2.A.1.1.3.4.-Metodologia para la Investigacion de la Interaccion
________________________________________________________________________________________________
Uso del diseño basado en modelos para probar y verificar el software embebido de automoción:
------------------------
El software embebido y la electrónica representan una parte cada vez más importante del contenido de ingeniería de un automóvil. Se prevé que en el año 2010, la electrónica suponga el 40% del coste total de los materiales de un coche, mientras que en 1970 sólo representaba el 10% [1]. El software embebido y la electrónica se utilizan en áreas funcionales del coche para sustituir o simplificar los sistemas hidráulicos o mecánicos en las funciones principales, como el sistema de frenos o de dirección. También se usan para implementar funciones avanzadas, como sistemas de seguridad activa y de información al conductor que suponen un valor añadido para el cliente en cuanto a comodidad, seguridad y facilidades.
Sin embargo, el software embebido y la electrónica son cada vez más complejos y esto, junto con la dificultad que conlleva la realización de pruebas y verificaciones de estos sistemas, se ha asociado a un aumento del número de reparaciones y de problemas relacionados con la calidad. Según IBM Corporation, los fabricantes de coches emplean entre dos y tres mil millones de dólares al año en solucionar problemas de software y el 32% de las reclamaciones de garantía de los coches en Estados Unidos se deben a problemas relacionados con la electrónica o el software. El diseño basado en modelos se ha convertido en la mejor opción para el desarrollo de software embebido de automoción, ya que mejora las fases de especificación, diseño e implementación. En la actualidad, existen nuevas herramientas y funciones para el diseño basado en modelos que ayudan a afrontar el reto que supone la realización de pruebas y verificaciones, y a la vez, mejoran la calidad del software embebido y acortan el ciclo de pruebas y verificaciones.
Diseño basado en modelos para la realización de pruebas y verificación:
Los ingenieros de automoción suelen usar modelos para desarrollar funciones que se ejecutan en una unidad de control electrónica (ECU, del inglés Electronic Control Unit). En el diseño basado en modelos estos últimos se usan de múltiples formas: para proporcionar especificaciones ejecutables, para analizar el comportamiento dinámico del sistema, para simular los componentes y las condiciones del entorno reduciendo o eliminando la necesidad de costosos prototipos físicos, y para diseñar algoritmos. Además, la generación automática de código a partir de estos modelos se ha afianzado como una forma de implementación del software de producción de las ECU. Se espera que en los próximos años se convierta en la opción principal para la implementación de software de control embebido en muchas empresas de automoción.
Desde una perspectiva de calidad, la generación automática de código ya es de gran ayuda, porque optimiza el diseño mediante el análisis y la simulación y garantiza la repetibilidad de la calidad del código generado automáticamente. Además, el código se puede generar desde los modelos de componentes del sistema y del entorno para generar pruebas de hardware–in-the-loop (HIL).
En la actualidad, gracias a enfoques nuevos y mejorados, se puede sacar el máximo partido a estos mismos modelos con utilidades más potentes y variadas, entre las que se incluyen pruebas basadas en requisitos, análisis de cobertura y generación de pruebas. Todo esto sirve para acelerar y mejorar la realización de pruebas y verificaciones de los complejos sistemas embebidos actuales, incluidos el software embebido y los componentes electrónicos.
Seguimiento y comprobación de requisitos:
En la mayoría de los estándares de procesos y software, como CMM-I, es necesario que la trazabilidad entre el diseño y los requisitos sea bidireccional durante todo el desarrollo. El código de implementación también ha de ser trazable con respecto al diseño, para que pueda ser revisado y verificado. Las herramientas de diseño basado en modelos pueden vincular el texto de los requisitos, guardado en Excel, Word o en una herramienta de gestión de requisitos, con el modelo (el diseño). Cualquier requisito que no se cumpla en el diseño puede marcarse, de la misma manera que pueden marcarse los elementos del diseño que no se correspondan con un requisito. Si se cambia un requisito (o diseño), las herramientas indican los elementos del diseño correspondientes (o los requisitos) que pueden verse afectados. Además, el generador automático de código puede insertar enlaces HTML en el código C generado para que se pueda determinar el origen de la implementación en el modelo, algo muy importante sobre todo en aquellos sistemas en los que la seguridad es vital. El conjunto de estas funciones ofrece una ruta de trazabilidad completa desde el código a los requisitos (figura 1).
Además de vincular los requisitos al diseño, las herramientas del diseño basado en modelos ofrecen funciones que sirven para confirmar que el diseño cumple ciertos requisitos. Estos requisitos se introducen en el modelo del diseño como propiedades (o afirmaciones), y los algoritmos de métodos formales determinan matemáticamente si las propiedades se cumplen en todas las situaciones válidas. Si existe un escenario que pueda infringir las propiedades, la herramienta de método formal genera un contraejemplo que el ingeniero puede usar en simulaciones y añadir al plan de pruebas.
Comprobación del estilo de los modelos:
Durante la fase de diseño, un modelo de alto nivel inicial se transforma en un modelo adecuado para su implementación, ya que se le incluyen las características necesarias para la implementación, como son datos de coma fija, y se eliminan las partes que no se implementarán. De la misma manera que los ingenieros de software establecen directrices sobre el estilo del código fuente para que sea más fácil su lectura, prueba e implementación, los ingenieros que trabajan en el diseño basado en modelos, establecen directrices sobre el estilo de los modelos para garantizar que el modelo pueda ser implementado y facilitar también su comprensión y prueba.
En función del flujo de trabajo deseado y de si el diseño representa una nueva función o una modificación de una función existente, se puede proceder de dos maneras: limitar las opciones disponibles desde el principio al diseñador, o realizar comprobaciones en el diseño más adelante, a medida que se va transformando.
En el primer enfoque, usado con frecuencia en sistemas en los que la seguridad es vital o en diseños que son pequeñas modificaciones de una implementación ya existente, las restricciones se aplican al principio del proyecto. Generalmente, esta estrategia se basa en la definición de un subconjunto restringido de componentes del modelo (bloques o máquinas de estado), estructuras de modelado (la manera en que los bloques están conectados), y otros ajustes (p. ej. aspectos de coma fija) que no necesitan ser comprobados manualmente en cada diseño porque las herramientas lo hacen sistemáticamente.
En el segundo enfoque, se comprueba si el modelo cumple las directrices más adelante en el proceso de desarrollo. El hecho de que la comprobación sea posterior permite que el diseñador comience con un diseño sin restricciones y, luego, se vaya limitando y transformando gradualmente el diseño hasta conseguir una implementación sólida y lista para la realización de pruebas. El lugar ideal para la comprobación de este modelo es el propio entorno del modelado, para que el desarrollador pueda detectar rápidamente los problemas y editar el diseño de una manera eficiente e interactiva.
Se han introducido recientemente herramientas que permiten al equipo de ingeniería definir y personalizar un conjunto de normas para la comprobación de modelos, aplicarlas a los modelos y localizar inmediatamente las excepciones.
Análisis y garantía de la cobertura del modelo:
El modelo ofrece la oportunidad en las primeras etapas del proceso de diseño, antes de la implementación, de llevar a cabo los tipos de pruebas que se realizarían después con la comprobación basada en el código fuente. Los ingenieros realizan pruebas de esfuerzo con el controlador para verificar la integridad del diseño y detectar problemas tales como las secciones inalcanzables del diseño que aparecerían más tarde como código muerto.
Los ingenieros realizan a menudo simulaciones muy exhaustivas de los modelos para confirmar que un diseño es sólido y funciona correctamente. No obstante, estas simulaciones sólo son tan útiles como los escenarios que ejecutan.
La realización de pruebas de esfuerzo mediante la ejecución de simulaciones con valores numéricos máximos y mínimos ayuda a evitar que se produzcan condiciones de desbordamiento. También es importante comprobar que durante las simulaciones se prueben todas las partes del diseño, y todos los modos y ramificaciones lógicas del diseño.
En el análisis de cobertura del modelo se evalúan los resultados acumulados de una serie de pruebas para determinar los bloques o estados que fueron ejecutados durante una simulación y los que no lo fueron. Algunos análisis de cobertura están bien establecidos en los lenguajes de código fuente, como C, C++ y Ada, pero estos tipos de análisis no han estado disponibles para los modelos hasta hace poco. [2]
La Administración Federal de Aviación de Estados Unidos (FAA) considera la cobertura de decisión/condición (MD/DC) como el nivel de cobertura más riguroso que deben cumplir los sistemas en los que la seguridad es vital. Este análisis de la cobertura, entre otros, está ahora disponible en el diseño basado en modelos y se se basa en la ejecución de las simulaciones. Cuando se realiza dentro de las herramientas de simulación, MC/DC permite el registro automático y la creación de informes de los datos de cobertura del modelo (figura 2). Así, el ingeniero de pruebas puede evaluar si los escenarios de prueba están completos en lo referente a la estructura del diseño. El desafío se presenta entonces en la definición de un conjunto de pruebas que representen una cobertura total de manera eficiente.
Generación automática de pruebas:
Un nuevo conjunto de herramientas para el diseño basado en modelos puede generar automáticamente patrones de prueba que satisfagan los objetivos de cobertura especificados, como MC/DC, analizando automáticamente la estructura del modelo y usando métodos formales para generar patrones. Este análisis estructural también identifica si hay partes del modelo que nunca se ejecutan, lo que puede ser una indicación de que algo no se tuvo en cuenta durante la creación de la especificación, la implementación o las pruebas.
Se pueden combinar estos patrones de prueba con otros escenarios de prueba derivados de los requisitos, de los datos de los bancos de prueba, de escenarios de Monte Carlo y de modelos de planta o entorno para probar de manera exhaustiva el modelo a través de simulaciones, así como durante su posterior implementación real.
----------------------------
Comprobación del cumplimiento de las directrices MISRA-C en el código:
La Asociación para la fiabilidad de software en la industria del motor (Motor Industry Software Reliability Association - MISRA) ha publicado “Guidelines for the Use of the C Language in Vehicle Based Software” (Directrices sobre el uso del lenguaje C en software para vehículos). Cada vez más fabricantes y proveedores de automóviles adoptan este conjunto de directrices, conocido comúnmente como MISRA-C. [5] Gran parte de la comprobación del cumplimiento de las directrices de MISRA-C de un modelo se puede llevar a cabo mirando lo que la herramienta de generación automática de código genera de forma sistemática, en lugar de comprobar todo el código generado, algo que sí es necesario si se crea manualmente.
Pero la comprobación de la herramienta de generación de código no incluye ciertos escenarios, como el código heredado y escrito a mano importado. Se pueden usar interfaces abiertas de modelos para comprobar automáticamente estos escenarios. De esta manera, las comprobaciones se realizan después de la creación del modelo y antes de la generación de código, garantizando así la verificación del código generado e importado. Otra opción es incluir un comprobador de código MISRA-C o una herramienta de análisis estático en el proceso de generación de código.
Detección de errores en tiempo de ejecución:
Los errores en tiempo de ejecución son especialmente difíciles de detectar a nivel del modelo o durante la simulación y esto puede ocasionar problemas graves durante el desarrollo o las pruebas del software. Los errores en tiempo de ejecución son fallos latentes, que a menudo se producen con combinaciones específicas de valores de datos, por lo que resulta caro localizarlos mediante la realización de pruebas dinámicas. De hecho, normalmente se descubren por las consecuencias que tienen en comportamientos funcionales, por ejemplo, en el envío de comandos inesperados a actuadores, la parada del coprocesador matemático y fallos inexplicables del software o difíciles de reproducir. En estos casos, es necesario un largo proceso de depuración para localizar el origen del problema. [3]
El análisis estático es un enfoque válido para la detección de los errores en tiempo de ejecución. En los últimos años, se han introducido herramientas de verificación estáticas que utilizan técnicas de análisis avanzado y han reducido el número de resultados “falso-positivos” que requieren una inspección o realización manual de pruebas .[4] Estas herramientas realizan un análisis estático, y también dinámico, del código C, independientemente de si el código se generó de manera automática o manual.
La integración de estas herramientas de verificación con las herramientas del diseño basado en modelos supone una mejora importante para el flujo de trabajo. Al conectar el código analizado y el modelo a partir del cual se generó automáticamente, la herramienta de verificación estática puede presentar sus resultados tanto en el código fuente como en el modelo. El hecho de poder navegar desde el código al modelo, realizar el cambio y, después volver a generar y comprobar el código automáticamente, hace que ésta sea una manera muy eficaz para analizar, depurar y modificar algoritmos tanto desde una perspectiva de alto nivel como de detalle. De este modo, se mejora el proceso de desarrollo ya que los cambios se realizan en el modelo en lugar de directamente en el código, lo que aumenta la longevidad y reutilización de los modelos entre proyectos.
Observaciones finales:
La filosofía clave descrita en este artículo representa las tres mejores prácticas con el objetivo de sacar el máximo partido del diseño basado en modelos durante la realización de pruebas y verificaciones.
En primer lugar, se aconseja la reutilización de los modelos como banco de pruebas para la implementación. Puede recopilar conocimientos, datos de pruebas y otra información útil que podrá reutilizar más adelante en los procesos de desarrollo y realización de pruebas a partir de diferentes acciones como la simulación de modelos, la implementación de software vinculado a los modelos, la ejecución en un (ordenador) host o en el procesador destino de la implementación o la ejecución del sistema completo embebido en un banco de pruebas.
En segundo lugar, se aconseja que se realicen las siguientes pruebas lo antes posible: realización de pruebas en la etapa de simulación antes que en tiempo real, realización de pruebas en tiempo real en el banco de pruebas antes de aplicarlo al mundo real y realización de pruebas sobre el modelo anterior a la generación de código. La realización de pruebas al principio del proceso es generalmente más fácil, ya que el nivel de abstracción es más alto, y resulta mucho más barato detectar los errores en esta fase.
En tercer lugar, se aconseja aprovechar al máximo todas las técnicas disponibles. Los métodos de simulación y formales deberían compaginarse para sacarles el máximo partido a ambos; las técnicas basadas en código y las basadas en modelos para la realización de pruebas y verificaciones han de complementarse las unas a las otras, y todasestán disponibles para ser utilizadascon el diseño basado en modelos en una gama de herramientas de distintos proveedores.
Muchos fabricantes y proveedores de equipamiento original para coches utilizan el diseño basado en modelos para generar especificaciones ejecutables, simular su rendimiento y generar código automáticamente. Muchas de estas empresas comienzan a dar el siguiente paso, aprovechando los modelos existentes para realizar pruebas y verificaciones. Este artículo recoge una amplia gama de métodos actuales para ilustrar los enfoques prácticos que pueden usarse para mejorar la calidad y reducir los costes del software embebido de automoción.
Referencia http://www.convertronic.net/index.phpoption=com_content&task=view&id=1345&Itemid=22
_______________________________________________________________________________________________
Un software permite a los móviles controlar la pantalla de un ordenador
Informáticos de la Universidad de York han desarrollado un software que permite a un móvil manejar los objetos que aparecen en la pantalla de nuestro ordenador. Para ello, lo único que tiene que hacer el usuario es mover el terminal en la dirección y el modo que necesite. Ambos dispositivos se conectan entre sí vía Bluetooth, y el ordenador traduce el movimiento y la rotación del celular en tres dimensiones a acciones concretas del cursor sobre la pantalla. Sus primeras aplicaciones podrían permitirnos interactuar con un anuncio que encontremos en la calle o descargar en nuestro celular información de interés de, por ejemplo, un panel informativo. 24/01/2008_____________________________________________________________________________________
-------------------------------Autos potenciados con registros de laboratorio para Diabéticos:
----------------ver la URL http://www.medgadget.com/archives/2008/06/mpowered_car_for_diabetics.html
_____________________________________________________________________________________
Tendencias Nuevas tecnologías: ahora se aprende en tres dimensiones
Los videojuegos comienzan a revolucionar el e-learning de los empleados
http://www.lanacion.com.ar/nota.asp?nota_id=1029501
______________________________________________________________________________________
Algoritmo para que un ordenador clasifique datos con versatilidad humana
Los humanos tenemos una tendencia natural a buscar organización en los conjuntos de información, una
habilidad que se ha comprobado que es difícil de replicar en los ordenadores. Al enfrentarse con un conjunto
grande de datos, los ordenadores no saben por dónde comenzar, a menos que estén programados para trabajar
con una estructura específica, como por ejemplo una jerarquía o un orden lineal.
________________________________________________________________________________________
---------
Ya es posible conocer al instante el estado del tráfico en el móvil
Diversas ciudades norteamericanas, como Nueva York, Los Angeles o Washington, disponen ya de la posibilidad de conocer el estado del tráfico desde el teléfono móvil, para planificar en tiempo real el mejor trayecto a seguir antes de subir al coche. Una compañía de comercialización de aplicaciones para teléfonos móviles se ha aliado con una cadena de televisión para hacer llegar la imagen de las cámaras de tráfico al celular de cualquier conductor. El servicio es gratuito, pero contiene publicidad, lo que no es un obstáculo para su aceptación por los ciudadanos. 31/07/2008______________________________________________________________________________________
Misceláneas:
INAMO
Primer Restaurante Interactivo - con tecnología informática que permite como interface realizar pedidos de cocina gourmet.-
http://www.inamo-restaurant.com/
SMALL DISHES LARGE DISHES _____________________________________________________________________________________
DESSERTS
DRINKSSITEMAP http://interfacemindbraincomputer.wetpaint.com/sitemap
agsabatini |
Latest page update: made by agsabatini
, May 18 2009, 11:18 AM EDT
(about this update
About This Update
Moved from: 2.A.1.1.-Concepto y clasificacion general de la INTERACTIVIDAD
- agsabatini
No content added or deleted. - complete history) |
|
Keyword tags:
computacion social
interface de usuario
interfaz usuario
modelo
sociedad de la informacion
More Info: links to this page
|
There are no threads for this page.
Be the first to start a new thread.
