Patrones-Conceptuales_en_DIHM_UTN-FRRo_v1_01b - Alberto Medina

Vista previa del material en texto

Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
Introducción a Patrones
Conceptuales en el diseño de la
Interaccion Hombre Máquina
Diseño de Sistemas
1. Índice
1. Índice .......................................................................................................................................... 1 
2. Introducción ................................................................................................................................ 1 
2.1. Propósito del documento ..................................................................................................... 1 
2.2. Alcance del documento ........................................................................................................ 2 
2.3. Definiciones, abreviaturas y acrónimos ............................................................................... 2 
2.4. Documentos Relacionados .................................................................................................. 2 
2.5. Visión general del documento ............................................................................................. 2 
2.6. Abstract ............................................................................................................................... 3 
3. Introducción ................................................................................................................................ 3 
3.1. Motivación y Alcance ........................................................................................................... 3 
3.2. Marco Teórico ...................................................................................................................... 5 
3.2.1. Conceptos Clave ........................................................................................................... 5 
3.2.2. Concepto de Patrón ...................................................................................................... 6 
3.2.3. Decisiones de Diseño a partir de Patrones ................................................................... 8 
3.2.4. Diferencia entre Patrones de Diseño de Interacción y las Guías de Usabilidad .......... 8 
3.2.5. Beneficios del uso de patrones conceptuales de Interacción ....................................... 9 
4. Patrones de Interacción (sus dimensiones) ............................................................................... 9 
4.1. Niveles de Granularidad ...................................................................................................... 9 
4.2. Tipos de UI ......................................................................................................................... 10 
4.3. Características de Interacción ........................................................................................... 11 
4.4. Patrones de interacción de bajo nivel ................................................................................ 12 
5. Patrones Conceptuales de Interacción ................................................................................... 17 
5.1. Patrones a Nivel de Casos de Uso de Usuario ................................................................. 17 
5.2. Patrones a Nivel de Unidad de interacción ....................................................................... 17 
5.3. Patrones a Nivel de Panel ................................................................................................. 18 
5.3.1. Ejemplo de algunos patrones a Nivel de Panel .......................................................... 20 
5.4. Patrones a Nivel de Objetos .............................................................................................. 24 
5.4.1. Ejemplo de algunos patrones a Nivel de Objetos ....................................................... 25 
6. Aplicación de los patrones conceptuales en un ejemplo ......................................................... 27 
6.1. CU Consultar Libros ........................................................................................................... 27 
6.2. CU Prestar Libros .............................................................................................................. 28 
7. Conclusión ................................................................................................................................ 29 
8. Bibliografía ................................................................................................................................ 29 
9. Historia de Versiones del documento .......................................................................................30 
2. Introducción
2.1. Propósito del documento
Introducir el concepto de Patrones Conceptuales en su aplicación en el diseño de la
Interacción Hombre Máquina
 1/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
2.2. Alcance del documento
Las consignas de este documento aplican a todos los alumnos de la asignatura Diseño
de Sistemas de la carrera de Ingeniería en Sistemas de Información dictada en la Universidad
Tecnológica Nacional - Facultad Regional Rosario.
2.3. Definiciones, abreviaturas y acrónimos
Interacción Hombre Máquina (IHM) → Ver más abajo en la sección marco teórico la
definición,abreviada como IHM (o HCI en Inglés); y que corresponde a lo que hasta hace
algunos años denominábamos como interfaz de usuario 
2.4. Documentos Relacionados
Ver también sección #8.Bibliografía 
Documento Nombre / Ubicación del archivo Fuente
Conceptos y
Directrices de
Interfaz de Usuario
en RUP
Nombre: 
Conceptos_y_Directrices_de_Interfaz_de_Usuario_en_RUP_v1_01.pdf 
Ubicación: 
http://es.groups.yahoo.com/group/ds_utn_rosario/files/Apuntes_por_Te
ma/Usabilidad/
E. Porta –
L. Ripani
Modelado de
requerimientos IU
con storyboard
Nombre: 
Modelado_de_requerimientos_de_la_IU_con_storyboard_v1_01.pdf 
Ubicación: 
http://es.groups.yahoo.com/group/ds_utn_rosario/files/Apuntes_por_Te
ma/Usabilidad/
E. Porta –
L. Ripani
2.5. Visión general del documento
El presente documento realiza una introducción a los Patrones Conceptuales de IHM
que están siendo desarrollados por la cátedra de Diseño de Sistemas de la UTN – FRRo, como
parte de un proyecto de I+D (en proceso de formalización). Asimismo, en este documento se
compila una introducción al concepto de patrón y su aplicación en lo relacionado al diseño de
IHM.
En la sección 3 se realiza una introducción describiendo la motivación del presente
trabajo, el marco teórico en que está basado, el concepto de patrón y su aplicabilidad a la
usabilidad.
En la sección 4, se describe cómo la definición de patrones de interacción debe
contemplar varias dimensiones: tipos de unidades de interacción (o pantallas), niveles de
granularidad de la especificación (desde lo general a lo particular), y características de
interacción en cada nivel.
En la sección 5, se define nuestra propuesta de patrones conceptuales de interacción.
En la sección 6, se presenta la aplicación de los patrones conceptuales a un ejemplo.
Finalmente, en las secciones 7 y 8 se presentan las conclusiones, y la bibliografía
utilizada en la elaboración del presente trabajo.
 2/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
2.6. Abstract 
La Interacción Hombre Máquina (o interfaz de usuario)se torna un aspecto clave de las
aplicaciones administrativas, en cuanto a su aceptabilidad por parte de los usuarios, y que tiene
una gran incidencia en la productividad de los mismos. Si bien hay buenas y sólidas teorías
sobre usabilidad en la que se capacita los desarrolladores, aún no se ha logrado evitar un
grado de dispersión importante en la efectividad y eficiencia de la IHM de las aplicaciones
construidas. Hace falta encontrar un mecanismo que permita una aplicación homogénea de las
buenas soluciones conocidas por los desarrolladores con experiencia.
El diseño de la IHM ha sido erróneamente considerado como un terreno exclusivo del
diseñador de software, ignorando que muchas veces hay requerimientos importantes del
negocio que inciden sobre la IHM que solo pueden capturarse durante el relevamiento.
Desarrollaremos un catálogo de patrones conceptuales de IHM para que los analistas
especifiquen los requerimientos de la IHM al momento de la especificación de requerimientos, y
que luego permita a los diseñadores refinarlo en diseños detallados adecuados a la tecnología
de implementación. Para limitar el alcance de este trabajo, la aplicabilidad de estos patrones se
restringe a aplicaciones administrativas empresariales.
3. Introducción
3.1. Motivación y Alcance
El presente trabajo pretende desarrollar un catálogo de patrones conceptuales a ser
aplicados en el diseño de la Interacción Hombre Máquina (IHM) de aplicaciones administrativas
empresariales. 
La Interacción Hombre Máquina (o interfaz de usuario) se torna un aspecto clave de las
aplicaciones administrativas, en cuanto a su aceptabilidad por parte de los usuarios. Una
aplicación con un pobre diseño de IHM, tiende a generar problemas al momento de la
implementación acentuando la natural resistencia al cambio de los usuarios, y en muchas
ocasiones puede incidir en una deficiente productividad en la operación del sistema por parte
de los usuarios.
Si bien en el mercado existen numerosas aplicaciones con una IHM de calidad, efectiva
y eficiente, es muy común encontrar una gran dispersión entre los proyectos de desarrollo en
cuanto a la calidad de sus IHM, siendo evidente que en numerosas ocasiones no se respetan
las buenas prácticas provenientes de las aplicaciones exitosas. Estas deficiencias, suelen
encontrarse en grupos de desarrollo de poca experiencia, o en grupos donde no se le brinda
importancia al diseño de la IHM desde la óptica de la usabilidad, y en los cuales cada
desarrollador opta por la solución que le parece más conveniente.
Como solución a estos problemas, numerosos autores han escrito extensos libros
dedicados a los principios y prácticas necesarias para lograr una buena IHM; y como una forma
de incorporar estos principios en el desarrollo de aplicaciones suele capacitarse a los
desarrolladores en estas teorías. Sin embargo, no es fácil lograr un resultado uniforme en los
equipos de desarrollo con solo brindarles una buena capacitación en los temas mencionados.
Es por eso que recientemente ha surgido un movimiento que propone aplicar patrones de
diseño a la IHM, tal como en los últimos años ha ido avanzando la aplicación de patrones en el
diseño de los programas de software. Hasta ahora la mayoría de estos patrones se centran en
aspectos del diseño que podríamos llamar de bajo nivel, o dialogal (por ejemplo, formas
posibles de diseñar la IHM para elegir un valor dentro de una lista). Pero no ha habido hasta
ahora un gran desarrollo de patrones de más alto nivel, excepto quizás por la tesis doctoral de
Pedro J. Molina; la cual constituye un punto de partida para este trabajo.
 3/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de SistemasUTN – F.R.Ro.
Por otro lado, debemos considerar también otro aspecto preponderante en las
deficiencias normalmente encontradas en el diseño de las IHM, y es el hecho de que hay
requerimientos de la IHM que nacen en la etapa de especificación de requerimientos. Por
ejemplo, si estamos haciendo una aplicación para registrar cobranzas de créditos que nos
rinden numerosos comercios, será muy importante para la productividad de la aplicación cómo
plantear la registración de los mismos, lo cual es muy sensible al hecho de que los recibos de
cobranza que recibimos vengan agrupados o no por comercio, ordenados o no por cliente, etc.
Este tipo de información solo puede ser capturada por los integrantes del grupo de desarrollo
que se dedican a la especificación de requerimientos, e incluso muchas veces pueden haber
razones del negocio que no permitan cambiar alguna de estas condiciones, por lo que es muy
importante debatir sobre las mismas con el usuario en forma temprana.
A pesar de lo expuesto, debido a la explosión de alternativas tecnológicas en los
recientes años de la informática, la problemática del diseño de la IHM ha sido vista por la
corriente de pensamiento predominante como un problema del diseño de software, y que debía
ser solo resuelta por aquella persona con el rol de diseñador. Teorías como la de sistemas
esenciales de Stephen M. McMenamin, han contribuido probablemente de forma involuntaria a
esta noción, por la cual el analista debía especificar qué debería hacer el sistema, y el
diseñador se encargaría de adecuarlo a la tecnología elegida para el desarrollo. El problema
muchas veces aparece cuando el diseñador debe tomar decisiones sobre la IHM, sin tener
ningún tipo de información del negocio, ni de los requerimientos del mismo que puedan
impactar en un determinado estilo de IHM o no.
Sin embargo, no debe perderse de vista que también es cierto que quien está haciendo
el relevamiento y la especificación de requerimientos, muchas veces no tiene el conocimiento
necesario de la tecnología para comprender cabalmente el esfuerzo de desarrollo y
restricciones de performance, etc., que un determinado diseño de IHM puede implicar.
Por lo tanto, se propone desarrollar un catálogo de patrones conceptuales de IHM para
ser utilizados por el especificador de requerimientos, que lo ayuden a capturar el “diseño
conceptual” que debería tener la aplicación, y que luego utilizará el diseñador para refinarlo en
un diseño de más bajo nivel adecuado a la tecnología de desarrollo. Se elige un enfoque de
patrones, de manera de acotar las soluciones posibles que puede elegir el especificador de
requerimientos como manera de asegurarse de que las IHM propuestas no sean imposibles o
altamente costosas de llevar a la práctica. Este supuesto se basa en el hecho de que al
conformar el catálogo de patrones los mismos pueden ser construidos en conjunto por un grupo
conformado tanto por analistas como diseñadores con experiencia, lo que permitirá disponer de
alternativas de solución que logren un equilibrio tanto en cuanto a requerimientos de usabilidad
habituales al universo de aplicaciones, como soluciones que desde lo tecnológico impliquen un
esfuerzo de desarrollo optimizado, y que no tengan restricciones prohibitivas en cuanto a
atributos de calidad ( performance, mantenibilidad, etc.). Adicionalmente, el uso de un catálogo
de patrones también contribuye a disminuir la dispersión de las soluciones elegidas por el
grupo de desarrollo, permitiendo escoger entre soluciones probadas, y sentando las bases de
un lenguaje común entre analistas y diseñadores.
 4/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
Finalmente, es muy importante reconocer que para que el catálogo de patrones
conceptuales sea factible de aplicar conservando el equilibrio entre las visiones de los analistas
y diseñadores expuestas en el párrafo anterior, el mismo debe estar restringido a un universo
de aplicaciones en particular; ya que no es el mismo tipo de soluciones que se utilizan para por
ejemplo aplicaciones empresariales que para la IHM utilizada para controlar una máquina
industrial, o un teléfono celular. Claramente las soluciones exitosas tienen características
distintas para c/u de esto tipos de aplicaciones. 
Es por esto que debemos escoger un tipo de aplicación, y en particular para este
trabajo se eligen la aplicaciones administrativas empresariales. Las cuales podemos
caracterizar como aplicaciones que requieren almacenar un volumen importante y estructurado
de datos (por lo cual suelen implementarse con bases de datos relacionales), que son
principalmente transaccionales (es decir que se registran transacciones a medida que ocurren
en el negocio), y que suelen proveer reportes que agrupan, ordenan y resumen los datos
ingresados en las transacciones, con la restricción de que los reportes generados son pre-
planeados.
3.2. Marco Teórico
3.2.1. Conceptos Clave
A continuación mencionaremos los conceptos clave que son pertinentes a la presente
investigación:
� IHM (Interacción Hombre Máquina, o HCI en Inglés): es la interacción que existe entre un
“ente“ tecnológico y una persona . El “ente” tecnológico puede ser un sistema de
software (como el Microsoft Word, o el sistema de Inscripción en Alumnado), pero también
puede ser un dispositivo de Hardware (como una calculadora, un microondas, o un celular).
Hemos visto también que en el pasado se refería a esta problemática bajo el nombre
de diseño de interfaz de usuario, pero según la concepción de los últimos tiempos hemos
comenzado a llamarla IHM para ser más abarcativos respecto a los problemas que intentamos
resolver con esta disciplina. Es decir, que no solo se agrupa a un software, sino que también a
todo tipo de máquina que tenga algún tipo de panel para operarla. Obviamente que dentro de la
definición de “máquina” estamos comprendiendo al software en una computadora, e incluso
también al software incluido dentro de un celular; ya que en los últimos modelos de hoy en día,
ya es prácticamente inconcebible hablar del panel (“teclado”) de operación del celular sin
pensar en el software que está por detrás haciéndolo funcionar.
� El diseño de IHM es una tarea compleja, ya que existen muchas soluciones posibles, pero
no todas son válidas desde un punto de vista de usabilidad . Para determinar qué
soluciones son válidas, se debe analizar la información a ingresar, la dinámica en que se
ingresa dicha información, y el tipo de usuario que utilizará el sistema.
El objetivo perseguido en definitiva es lograr un sistema fácil de usar.
� Principios o Guías de usabilidad : son reglas básicas que nos indican qué lineamientos
debe respetar un diseño de IHM para que el mismo sea considerado una “buena solución”
Ejemplos de estas guías de usabilidad son:
♦ La IHM debe dar feedback ���� es importante que nuestras pantallas
muestren información al usuario, de lo que la máquina está haciendo en todo momento.
Por ejemplo, mostrar el reloj de arena cuando se está grabando un documento.
Esto es especialmente importante cuando la máquina estará ocupada por un tiempo
considerable (más de 2 segundos) sin dar respuesta al usuario.
 5/309/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
♦ Uso prudente de colores para destacar información importante ���� es buena
práctica el uso de colores para destacar información por excepción dentro de una pantalla.
Sin embargo debe tenerse cuidado de no abusar este principio, cargando la pantalla con
muchos colores diferentes (porque provocará desorientación en el usuario); o destacando
en casi todas las pantallas información habitual que no es importante (en ese caso el color
pierde efecto ya que el usuario se acostumbra al mismo en todas las pantallas, y pierde el
sentido de llamar la atención).
Un ejemplo de un buen uso de este principio, sería destacar en rojo un cartel que
indique (en el sistema de alumnado) que el alumno no puede inscribirse a una materia por no
haber aprobado las correlativas. Mientras que para otros errores menos significativos, como un
código de alumno no encontrado, se utiliza el color negro.
� Para profundizar en conceptos básicos de usabilidad referirse al libro “Diseño de interfaces
de usuario” (Shneiderman Ben, Pearson Educación, Marzo 2006), y a la bibliografía citada
de Nielsen y Constantine.
� Actualmente existen en el mercado numerosas aplicaciones de software con serios
defectos de usabilidad, a pesar de haber sido desarrolladas por software factories que
respetan las buenas prácticas de la Ingeniería de Software. Al mismo tiempo se observa
que los principios básicos de usabilidad han sido incorporados en la formación de los
profesionales de la ingeniería de software, lo que parece no haber logrado el efecto
deseado.
En tiempos recientes se ha comenzado a incorporar el concepto de patrón de diseño a
la usabilidad, así como viene siendo usado desde hace años en otras disciplinas de la Ing. de
software, como el diseño de software. Los autores que promocionan el uso de patrones en la
usabilidad, plantean que producirán una mejora en las aplicaciones si fuesen utilizados.
3.2.2. Concepto de Patrón
El concepto de patrón de diseño nace en el campo de la Arquitectura, propuesto por el
arquitecto Christopher Alexander en el contexto del diseño y construcción urbanística.
Partiendo de la definición original de Alexander, un patrón de diseño es una solución a un
problema que se usa repetidamente en contextos similares con algunas variantes en la
implementación. 
La forma de obtener esta solución es a partir de la abstracción de ejemplos específicos
de diseño. Para que una solución pueda ser considerada un patrón de diseño debe ser eficaz –
que se haya demostrado resuelve satisfactoriamente el problema – y reutilizable – que pueda
ser aplicada en diferentes casos .
La reflexión que proponía Alexander desde su óptica de la Arquitectura, es que en los
diseños de construcciones de viviendas, hay problemas repetitivos con soluciones ya probadas
y aceptadas por la mayoría de los arquitectos. Por ejemplo, cuando se trata de diseñar un
baño, ya hay determinadas disposiciones de los sanitarios que se repiten en varios diseños de
viviendas; y cuando un arquitecto se aboca al diseño de una nueva vivienda opta entre alguna
de esas soluciones dependiendo de determinados factores que hacen más viable una solución
u otra.
 6/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
Estos “factores” es lo que denominaremos fuerzas, que normalmente son
contrapuestas, y cada solución factible (patrón) inclina el equilibrio hacia una u otra fuerza. Por
ejemplo, si pensamos en la ubicación del baño de departamentos de un edificio con 3 deptos.
por piso, tenemos básicamente dos opciones factibles: 
� una es ubicar los baños sobre las paredes divisorias entre deptos (colocándolos así en el
centro del piso todos juntos); 
� mientras que la otra, consiste en ubicar los baños sobre la pared del frente o contrafrente
del edificio (quedando alejados entre sí).
En la primer opción se está priorizando una fuerza involucrada en este problema, que es la
ubicación de los conductos de los caños de desagüe de los baños. Al estar los tres baños en el
centro del piso, se puede construir una columna en el centro del edificio por donde pasen los
caños de los tres baños. De lo contrario, la segunda opción implica construir tres columnas
para caños de desagüe (con su consecuente aumento de costos), debido a que los baños se
encuentran alejados entre sí.
 7/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
Por otro lado, también está presente otra fuerza, que es la disponibilidad de una ventana
exterior en el baño, para tener una mejor ventilación. La primer opción va en contra de esta
fuerza, ya que al agrupar los baños en el centro del piso, los mismos no pueden tener ventanas
que den al exterior.
3.2.3. Decisiones de Diseño a partir de Patrones
Una de las reglas de oro del Diseño de Interfaces de Usuario es la de evaluar cualquier
decisión de diseño de Interfaces desde las primeras etapas del ciclo de desarrollo, con el
objetivo de reducir costos, puesto que siempre será más económico modificar un diseño que
rediseñar por completo. En base a esta regla, podemos deducir la importancia económica de
tomar decisiones de diseño previsiblemente acertadas, que en la posterior evaluación no se
demuestren como erróneas o desafortunadas. 
Una herramienta para facilitar la elección de soluciones a problemas concretos de
diseño son los denominados ‘patrones de diseño’. La primera adopción de este modelo de
diseño desde el campo de la Arquitectura para su aplicación en el diseño de productos
informáticos se produce en el área de la Ingeniería del Software y programación orientada a
objetos a principios de los 90, y se conoce como Patrones de Diseño de Software. Es
posteriormente cuando este mismo modelo empieza a ser estudiado y aplicado en el área del
Diseño de Interfaces de Usuario e Interacción Persona- Ordenador. Mientras que los Patrones
de Diseño de Software están destinados a solucionar problemas de funcionalidad
(considerando los atributos de calidad de soft); los Patrones de Interacción tienen el objetivo de
resolver problemas de usabilidad.
Los Patrones de Interacción nos guiarán para tomar decisiones tempranas acertadas
respecto a las pantallas del sistema a construir. La utilidad de los mismos consiste en evitar
que al momento de tener terminado el sistema, cuando el usuario lo comienza a usar se
descubra que hay algunas pantallas que son muy “incómodas” de usar. Usando patrones de
interacción, esta situación no debería presentarse, ya que estamos usando soluciones ya
probadas. Y si comprendemos adecuadamente elbalance de fuerzas que implica cada
solución, estaremos escogiendo aquella que mejor se ajuste a las necesidades del usuario de
nuestro sistema.
3.2.4. Diferencia entre Patrones de Diseño de Intera cción y las
Guías de Usabilidad
Una de las diferencias es referente a su enfoque o perspectiva. Mientras que las
directrices de usabilidad describen reglas a seguir, los patrones además especifican el
resultado deseado. Es decir, una directriz de usabilidad representa una regla que si se cumple
el diseño “estará bien”, y si no “estará mal”, mientras que un patrón especifica qué hacer para
conseguir un objetivo concreto en un contexto determinado.
Los patrones de interacción están destinados a la solución de problemas concretos,
frente al enfoque más generalista de las directrices. Otra diferencia es en cuanto a la
representación de la información. Si bien mucha de la información de los patrones es replicada
de la existente en guías y directrices de usabilidad, en los patrones además se describe el
contexto en el que el patrón es aplicable, y ejemplos concretos de aplicación. Es decir,
especifican cuándo, cómo y por qué la solución puede aplicarse.
 8/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
3.2.5. Beneficios del uso de patrones conceptuales d e
Interacción
El uso de patrones conceptuales nos permite que la problemática de la IHM sea tenida
en cuenta desde el momento de la concepción del sistema, asegurando que al momento de
estar relevando las necesidades del sistema el analista de sistemas vaya pre-viendo soluciones
probadas con anterioridad respecto a buenos diseños de IHM. Esto resulta beneficioso porque
al utilizar patrones se está aprovechando el conocimiento colectivo de la ingeniería de software
como disciplina; e incluso al simplificar los tiempos de análisis de requerimientos de IHM, el uso
de patrones transforma en una tarea sencilla la introducción del análisis de este tipo de
requerimientos en la fase de concepción del sistema.
La ventaja de contemplar desde un inicio los requerimientos de IHM, nos permitirá
lograr sistemas con una mejor valoración en los atributos de calidad relacionados con la
“experiencia del usuario”, como por ejemplo facilidad de uso, facilidad de aprendizaje,
performance, look and feel, etc.
4. Patrones de Interacción (sus dimensiones)
Basándonos en la tesis doctoral de Pedro J. Molina y haciéndola evolucionar (1),
utilizaremos un modelo que consta de diferentes tipos de unidades de interacción (o pantallas),
cuatro niveles de granularidad de la especificación (desde lo general a lo particular), y
características de interacción en cada nivel.
4.1. Niveles de Granularidad
� La IHM puede especificarse en cuatro niveles de granularidad diferentes:
1 Caso de Uso Usuario � contemplando la estructuración del C.U. en una o varias
pantallas, y la navegabilidad entre ellas
2 Unidad de interacción (UI) � equivale al término de pantalla, pero para ser más
abarcativos de otras soluciones tecnológicas, preferimos referirnos con el término elegido
por Molina. Para ejemplificar aún más, podemos decir que equivale también a una ventana
en Windows, o una Página Html en Web.
 
3 Panel � Es una agrupación de objetos de interfaz dentro de una unidad de interacción
que tienen una cohesión semántica, o función específica. Puede ser disjunto, no es un
marco gráfico, aunque puede coincidir con un marco.
4 Objeto � un elemento que permite realizar una interacción. Pueden ser simples
(botones, textos, números, ítems, fechas, etc), o grupos de objetos (Widgets, campo de
fecha con calendario emergente, etc.). Haciendo una simplificación podemos decir que un
objeto permite ingresar y/o mostrar un campo (el cual podría ser tanto univalor como
multivalor).
1 Molina introduce conceptos similares a los planteados en este trabajo, pero que no han sido tomados en forma
literal de su trabajo, sino que han sido los disparadores para una re-elaboración de los mismos generando
conceptos algo diferentes (él reconoce solo 3 niveles de especificación, e incorpora las características de
interacción como patrones en sí, y no como algo independiente y transversal.). Es importante destacar que en la
obra de Molina se perciben ciertas limitaciones debido a que su objetivo principal es la generación de código
automático más que el desarrollo de un catálogo de patrones. Si bien desarrolla patrones, los mismos están
restringidos a lograr al fin la generación de código, lo que a nuestro juicio impone ciertas limitaciones.
 9/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
Como manera de ejemplificar estos conceptos, presentaremos un bosquejo de una
pantalla para consultar libros disponibles en una biblioteca. Es importante notar que por ser un
bosquejo conceptual de la pantalla, y no la forma física final de la misma, el mismo es
representado con ciertos íconos elegidos por convención para patrones conceptuales, y no con
gráficos habituales usados en ventanas windows por ejemplo.
TTítulo
Editorial T ... Autor T ...
Tema T ...
Idioma 1 n<
T
Título EditorialAutor Tema Idioma
T
Ubicación Disponible
T T T T T
La pantalla completa en sí constituye un ejemplo de unidad de interacción .
En el área superior identificada como A, se ingresan los criterios del libro que se quiere
buscar, y en el área inmediatamente inferior marcada como C, se muestran los datos de los
libros que cumplen con los criterios de la consulta ingresada en el área superior.
Tanto el área A como la C, constituyen ejemplos de paneles . En particular podemos
decir que el área A, es un conjunto de objetos que constituyen el panel de filtro, ya que en
conjunto permiten especificar el filtro a utilizar en la búsqueda. Mientras que el área C,
constituye el panel de datos, ya que el conjunto de objetos del área C permite mostrar los datos
de los libros encontrados.
Como ejemplo de objeto, podemos mencionar el objeto identificado como B, el cuál es
un campo que permite ingresar el código de autor que se está buscando, permitiendo invocar
una pantalla guía de autores disponibles en caso de dudas (los ... indican la posibilidad de
invocar una guía).
Finalmente, para dar un ejemplo del nivel de caso de uso , podemos suponer que esta
consulta forma parte de un caso de uso para registrar el préstamo de un libro en la biblioteca, y
que comienza con una pantalla de búsqueda (la unidad de interacción representada arriba), y
que luego pasa a otra pantalla donde se registran los datos del préstamo (socio, período del
préstamo, etc.), y finalmente se emite el ticket a modo de comprobante del préstamo. Vemos
de esta forma que un caso de uso, puede abarcar más de una unidad de interacción, y que
deben especificarse las mismas y el modo de navegar entre ellas.
4.2. Tipos de UI
� Los tipos de unidades de interacción que podemos encontrarson (2):
� UI Controlantes ���� son UI que controlan el flujo de la interacción del resto de las
UI. Por ejemplo, una ventana de Abm desde donde se puede llamar a otra ventana de búsqueda o
guía de autores.
✓ Mono-Instancia ���� permite consultar o editar datos de una única instancia de
una entidad (por ej. ABM de un socio).
✓ Multi-Instancia (Mono-Entidad 3) ���� permite consultar o editar varias
instancias de una entidad (por ejemplo, materias en las que está inscripto un alumno).
2 Recordar que el presente trabajo restringe su alcance a las aplicaciones administrativas
empresariales
3 Entidad en este contexto se refiere tanto a una entidad del DER (o clase), como a un conjunto de
entidades del DER (o clases) que estén cohesionadas mediante un join. Esto último sería equivalente
al concepto de select de las Base de Datos Relacionales, donde por ejemplo una ventana
monoentidad es aquella cuyas acciones operan sobre un único select (aunque el mismo cohesione
varias tablas por medio de join)
 10/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
A
B
C
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
✓ Multi-Instancia (Multi-Entidad ) ���� permite consultar o editar más de una
entidad (por ejemplo el alta de una cobranza, donde pueden ingresarse tanto los datos del recibo
como de los cheques recibidos en la misma pantalla).
✓ Reportes ���� muestran datos que pueden estar resumidos o agrupados,
orientados a constituirse en un informe. Suelen incluir también atributos de cálculo, y
estadísticos. En aspectos de IHM, debe diferenciarse el reporte de la consulta, ya que está
última está más bien pensada con un mayor grado de interactividad necesaria cuando se
requiere encontrar una unidad dentro de un conjunto. Mientras que el reporte está más
orientado a información de conjuntos, y donde no es tan común encadenar interacciones
hasta encontrar lo buscado.
✓ Utilidades ���� Son UI que no están destinadas a consultar o editar entidades,
sino a ingresar otro tipo de peticiones al sistema (ej. Ventana selección impresora).
� UI Dependientes ���� llamadas por una UI controlante
✓ Búsqueda (o guías) ���� son invocadas desde otra UI permitiendo buscar el
código de un campo que debe ingresarse y que tiene asociado una entidad (por ej.,
búsqueda de autores).
✓ Ayuda ���� dan información sobre cómo funciona la aplicación
✓ Mensajes ���� mensajes de error, informes de progreso, etc.
4.3. Características de Interacción
� Al momento de diseñar la IHM hay determinadas características de la interacción que
deben ser tomadas en cuenta. Las mismas son:
1 Panel de Datos
� Estilo de presentación � puede ser de tipo grilla, free form (una instancia por
vez), gráfico, etc.
� Estructura � cómo se subdivide el panel de datos, y su ubicación
2 Navegación � indica cómo se realizan las transiciones entre unidades de interacción ,
paneles, instancias y objetos. Por ejemplo podemos tener un estilo de navegación entre
unidades de interacción basado en una UI controlante, y el resto de las UI dependientes. O
podríamos tener un estilo Wizard (o asistente) donde las UI aparecen en una secuencia
fija, permitiendo ir a la siguiente o anterior.
La navegación también debe definirse a nivel de instancias. Por ejemplo, como debe
hacerse para pasar a la instancia siguiente instancia: ¿ Usando un scrollbar ?
¿ Usando un botón “siguiente” ?, etc.
3 Filtro � indica cómo se establecen los criterios usados para filtrar. Por ejemplo, en
una consulta puede haber un panel específico para indicar los criterios de la búsqueda, o
puede usarse el mismo panel donde se muestran los datos en un estado especial donde se
indica por qué campo buscar (concepto denominado query by example)
4 Orden � indica cómo se ordenan los datos. ¿ Qué mecanismos de interacción
permitirán modificar el orden de los datos ? (un ejemplo son aquellas grillas donde
haciendo doble click sobre el título de una columna se altera el orden de la grilla)
5 Acciones � indica cómo se peticionan las acciones a realizar sobre los datos. ¿ Hay
botones específicos ? ¿ Se utilizan combinaciones de teclas ? ¿ O mensajes emergentes
con preguntas ? etc.
 11/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
Basándonos en estas características podemos ver que dependiendo del nivel de
granularidad de especificación algunos aplican y otros no:
Casos de Uso Usuario 
• Navegación (entre UI)
Unidad de interacción
• Navegación (entre paneles)
• Acciones
• Estructura y comportamiento
Panel
• Datos – Estilo Presentación
• Navegación (entre objetos del panel)
• Acciones 
• Filtro 
• Orden 
4.4. Patrones de interacción de bajo nivel
Analizando la bibliografía existente sobre patrones de interacción se puede ver que en
su mayoría se centran en diseños de bajo nivel, más bien orientado a patrones específicos de
objetos o cuestiones muy ligadas al diseño gráfico. Este tipo de patrones no es muy adecuado
para ser utilizado por el analista en el momento de la especificación de requerimientos, ya que
implica avanzar en decisiones de diseño que en alturas tempranas del desarrollo no conviene
fijar. Como ejemplificación de esta afirmación mostraremos algunos patrones de interacción
presentados por Jennifer Tidwell en su libro “Designing Interfaces - Patterns for Effective
Interaction Design” . Para presentar los patrones en forma rápida y abreviada, los
representaremos mediante una imagen gráfica, mientras que se puede recurrir a su
especificación formal recurriendo al libro mencionado. Debido a que estos patrones son muy
comúnmente usados se considera que la representación mediante imágenes resulta suficiente
para los objetivos de este trabajo.
� Extras a demanda � mediante la presión de un botón la ventana se agranda y permite el
ingreso de otros datos “avanzados”
 12/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
18. extras on demand
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Navegación Global � implica disponer de una barra superior en todas las UI que permite
navegar a otras UI:
� Navegación en pirámide � implica navegar desde una UI central, volviendo siempre a la
misma antes de pasar a otra UI
 
 13/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired:doc_basico_UTN v. 3.1 [10/8/07] 
22. global navigation
24. pyramid
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Panel Modal � implica disponer de una ventana que no permitirá activar ninguna otra
ventana de la aplicación, hasta tanto se elija alguna de las acciones planteadas en la
misma
� Barra de desplazamiento comentada � implica tener una barra de desplazamiento
(scrollbar) que al momento de moverla muestre un comentario emergente indicando en qué
parte del formulario se encuentra ubicado. Podrían ser, por ej., paginas de un documento, o
registros de una instancia.
 14/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
28. annotated scrollbar
25. modal panel
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Fichas (tabs) � usar fichas para dividir pantallas cuando hay gran cantidad de campos por
mostrar
 
� Paneles colapsables � la UI contiene varios paneles de los cuales se muestra abierto
uno solo a la vez, y de los otros solo se exhibe su barra de título. Esta patrón también
aplica cuando hay gran cantidad de campos por mostrar
 15/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
35. card stack
36. closable panels
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Habilitar en base a las respuestas � habilitar las opciones relacionadas con un campo,
solo cuando el valor ingresado en el mismo haga posible utilizar las otras opciones.
� Casilla de Verificación � permite elegir entre dos valores posibles
� Casillas de selección (radio buttons) � permite elegir entre dos o más valores
mutuamente excluyentes, estando todas las opciones visibles. 
� Lista desplegable � permite elegir entre dos o más valores mutuamente excluyentes,
mostrando las opciones posibles cuando se lo solicita.
 16/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
42. responsive enabling
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
No se puede negar que estos patrones resultan útiles al momento de diseñar el detalle
de la IHM, pero poco pueden ayudar al analista para capturar requerimientos significativos en
términos del negocio en el momento de especificar requerimientos, e incluso algunos de ellos
resultan más convenientes o no según el contexto tecnológico en que sean usados. Sin
embargo, sí podemos pensar en algunos requerimientos de negocio que puedan derivar luego,
al momento de implementarlos, en el uso de alguno de estos patrones básicos.
5. Patrones Conceptuales de Interacción 
Por lo tanto, se propone la creación de un catálogo de patrones que sean conceptuales
y que como tales permitan agrupar patrones de bajo nivel que sean equivalentes al momento
de definir los requerimientos de la IHM. Y que además, se concentren en los aspectos
relevantes al momento de definir requerimientos de la IHM para aplicaciones administrativas
empresariales (como ser navegabilidad, ordenamiento, filtro, etc.).
Estos patrones permitirán indicar requerimientos de la aplicación al diseñador quien
será luego el encargado de escoger patrones de interacción de bajo nivel que permitan
respetar los patrones conceptuales escogidos por el analista.
En función de los niveles de granularidad, de los tipos de UI, y características de
interacción anteriormente descriptas, podemos definir un catálogo inicial de patrones que
consta de lo siguiente:
5.1. Patrones a Nivel de Casos de Uso de Usuario
Patrones de navegación (entre UI)
o UI Encadenadas *
� Asistente (Wizard)
� Secuencial fija e implícita 
(ej.: ventana de Logueo previo)
o UI Principal y secundarias 
o UI Única
5.2. Patrones a Nivel de Unidad de interacción
Patrones de navegación (entre paneles)
o Carpetas (Tab), Extra on demand, etc.
* Nota: (*) Cuando se utilicen estos patrones, se deberá especificar la navegación entre unidades de interacción
con un diagrama de actividad.
 17/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
Patrones de acción (Ej. Cerrar, Guardar, Ayuda, etc)
Patrones de estructura y comportamiento de una UI 
• UI Controlantes ** (Controlan el flujo)
o Mono-Instancia
� Panel datos 
• + Patrón Datos
• + Patrón Acciones
• [+ Patrón filtro]
o (Se aplica en casos de Modificación, Consulta y
Baja)
o Multi-Instancia (Mono-Entidad **)
� Panel datos
• + Patrón Datos
• + Patrón Navegación 
• + Patrón Acciones
• [+ Patrón de ordenamiento] 
• [+Patrón filtro] 
o Multi-Instancia (Multi-Entidad **)
� Variantes 
• Cabecera – Detalle (Ej.: Factura y otros documentos)
• Maestro – Detalle (Ej.: Cliente – mascota)
� Panel Datos Princ.
• + Patrón Datos
• + Patrón Navegación 
• + Patrón Acciones
• [+ Patrón de ordenamiento]
• [+Patrón filtro]
� Panel Datos sec. 
• + Patrón Datos
• + Patrón Navegación 
• + Patrón Acciones
• [+ Patrón de ordenamiento]
• [+Patrón filtro]
� Utilidades (Ej. Ventana selección impresora)
ACLARACIÓN: No se desarrollan en el presente trabajo patrones para UI de Reporte,
Búsqueda, Ayuda o Mensajes.
5.3. Patrones a Nivel de Panel
Patrones p/ paneles Datos
� Estructura
� Una Vista
* * Nota: (**) Entidad en este contexto se refiere tanto a una entidad del DER (o clase), como a un conjunto de
entidades del DER (o clases) que estén cohesionadas mediante un join. Esto último sería equivalente al concepto
de select de las Base de Datos Relacionales, donde por ejemplo una ventana monoentidad es aquella cuyas
acciones operan sobre un único select (aunque el mismo cohesione varias tablas por medio de join)
 18/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseñode Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Dos Vistas (2 view) � un mismo grupo de datos se representa
en dos paneles de la misma UI. (por ej. hay un panel principal con los datos de
inscripción de un alumno, y el campo observación se repite en un panel aparte
con varias líneas para ingresar los comentarios pertinentes).
� Estilo presentación (Freeform – Tabular – Gráfico – Crosstab – Tree)
♦ Freeform � una instancia ocupa varios renglones, se ubican las etiquetas
en forma libre, y no hay columnas.
♦ Tabular � los datos se presentan en una grilla, donde cada instancia
ocupa una fila
♦ Gráfico � los datos se presentan mediante un gráfico
♦ Crosstab � los datos se presentan en una tabla de doble entrada
♦ Tree � se usa una estructura de árbol
Patrón Navegación (para Panel Datos, la navegación es entre instancias)
� Estructura paneles
� Navegación interna al Panel de Datos (Ej.: scrollbar y flechas cursor)
� Panel externo � hay otro panel en la UI (pantalla) que permite realizar
la navegación
� Panel adicional � es un panel emergente (que no está siempre visible,
sino que cuando se lo invoca) que permite realizar la navegación
� Panel externo común � cuando hay más de un panel de datos, se
podría tener un único panel de navegación externo que aplique al panel de
datos que tiene el foco
Patrón Acciones 
� Nombre de botones � es importante estandarizar los nombres que
se asignan a los botones de las acciones (Ej: Imprimir, Guardar (poco frecuente), Limpiar,
agregar, borrar, etc.)
� Estructura paneles
• Panel externo � (ver en navegación)
• Panel adicional � (ver en navegación)
• Panel externo común � (ver en navegación)
Patrón filtro 
• Estructura paneles
 19/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Interno al panel de datos � query by example
� Panel externo � (ver en navegación)
� Panel adicional � (ver en navegación)
Patrón de ordenamiento de paneles de Datos 
� Estructura paneles
• Interno del panel de datos (Ej. Haciendo click en título columnas)
• Panel de ordenamiento externo � (ver en navegación)
• Panel adicional � (ver en navegación)
5.3.1. Ejemplo de algunos patrones a Nivel de Panel
� Dos Vistas (2 view) 
Implica usar dos paneles de datos, relacionados entre sí (no necesariamente deben estar
adyacentes en el layout). Dos Vistas de una misma entidad [lista de clientes y detalle de
cliente] 
� Estilo presentación 
� Freeform 
� Tabular 
 20/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Gráfico
� Crosstab
� Tree 
 21/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Panel externo : cuando se tiene las acciones, navegación, filtro u ordenamiento en un
panel distinto al de datos
� Panel adicional : cuando se abre un panel que no estaba visible.
 Un ejemplo cuando para ordenar una grilla se elige la opción “Ordenar” con
botón derecho, y esto abre una ventanita popup donde se especifica el orden deseado.
 22/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
En este ejemplo,
el panel de filtro
está separado
del panel de
datos.
Ejemplo de
panel externo de
navegación. En
este caso en
vez de usar un
scrollbar, se
usan estos
botones para
navegar por la
grilla (panel de
datos).
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Panel externo común : cuando se tiene las acciones o navegación en un panel distinto al
de datos, pero que es común a todos los paneles de datos de la UI
 También se puede compartir con el panel de acción / navegación de la UI
� Query by example : el panel de datos tiene dos estados, primero sirve para especificar el
filtro, y luego al realizar la acción de recuperar es transforma en el panel de datos en sí.
 23/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
En este caso, hay
un único panel
para las acciones
de la ventana, y
de los dos
paneles de datos
de la misma. Los
botones “Guardar”
y “Cerrar”
corresponden a la
ventana; y el
botón “Buscar”
sirve tanto para el
panel de datos del
socio, como el del
ejemplar.
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
5.4. Patrones a Nivel de Objetos
• Patrones de Elección de Objetos Simples
o Elección de un Control (Ver 7.2 Elección de un Control – Libro de Tidwell)
o 7.2.1. LISTAS DE ELEMENTOS
� Seleccionar una o dos opciones 
� Seleccionar uno de N elementos cuando N es pequeño
� Seleccionar uno de N elementos, cuando N es grande
� Seleccionar varios de N elementos, en algún orden
� Construir una lista desordenada de elementos 
� Construir una lista ordenada de elementos
o 7.2.2. TEXTO
� Ingreso de una línea de texto 
� Entrada de una línea de texto o de una de N opciones
� Ingreso de líneas múltiples de texto sin formato
� Ingreso de líneas múltiples de texto con formato
o 7.2.3. NUMEROS
� Ingreso de número de cualquier tipo o formato 
� Ingresar número desde rango acotado
� Ingreso de un subrango desde un rango mas grande
o 7.2.4. FECHAS U HORAS
� Sin formato
� Con formato
� Con widget
o Objeto de acción (Ver capítulo 5 – Libro de Tidwell) 
� Ejemplos: Botones (Buttons ), Barras de menú (Menu bars), Menú emergente
(Pop-up menus), Barra de herramientas (Toolbars), Enlaces (Links), Panel de
acciones (Action panels ), Doble click (Double-clicking on items), Teclas
(Keyboard actions), Arrastrar y soltar (Drag-and-drop), Escribir comandos
(Typed commands), etc.)
• Patrones de Grupos de Objetos 
o Recuperar información para mostrar
o Recuperar información para modificar24/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
T
T
F
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
o Atributos condicionales (o Habilitar en base a las respuestas “Responsive
Enabling”)
ABM Cliente
1234Id Cliente >
Trabaja
Domicilio Rioja 2356 Localidad Rosario
Carlos Gimenez
ABM Cliente
1234Id Cliente >
Trabaja Lugar Trabajo Supermercado Sur
Domicilio Rioja 2356 Localidad Rosario
Teléfono Trabajo 4356783
Carlos Gimenez
5.4.1. Ejemplo de algunos patrones a Nivel de Objeto s
� Seleccionar una o dos opciones � este patrón conceptual puede implementarse con los
siguiente patrones de interacción de más bajo nivel (tomados de Tidwell):
� Casilla de Verificación 
 25/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Casillas de selección (radio buttons) 
� Lista desplegable 
� Seleccionar uno de N elementos cuando N es pequeño � este patrón conceptual
puede implementarse con los siguiente patrones de interacción de más bajo nivel
(tomados de Tidwell):
� Arreglo de N casillas de verificación (Array of N checkboxes)
� Arreglo de N botones intercambiables (Array of N toggle buttons)
� Menú emergente con N casillas de verificación 
� Ingresar número desde rango acotado � este patrón conceptual puede implementarse
con los siguiente patrones de interacción de más bajo nivel (tomados de Tidwell):
� Deslizador (Slider)
 26/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Spinner
6. Aplicación de los patrones conceptuales en un
ejemplo
6.1. CU Consultar Libros
� Patrones conceptuales de interacción
1 Patrón navegación entre UI : UI Principal y secundarias (como todas las UI secundarias son de
búsqueda, no se desarrollan)
2 Patrón de estructura Multi-Instancia – Mono-Entidad
3 Patrón filtro 
� Panel Externo
✓ Free-Form
♦ Patrones a nivel de Objetos
Ingreso de una línea de texto simple (Titulo)
Ingreso de una línea de texto con búsqueda (Autor, Tema y Editorial)
Seleccionar uno de N elementos cuando N es pequeño (Idioma)
4 Patrón datos 
� Tabular
5 Patrón navegación 
� Navegación interna al Panel de Datos
6 Patrón acciones 
� Panel Externo
 27/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
3
4
6
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
7 Patrón ordenamiento 
� Interno (doble click sobre los títulos de las columnas)
� Patrones de diseño de interacción (Tidwell)
1 Panel filtro
� Patrones a nivel de Objetos
Campo de texto de una línea (Titulo)
Lista desplegable de N elementos (Idioma)
Campo texto con botón mas (...) (Autor, Tema y Editorial)
2 Patrón navegación
� Navegación interna al Panel de Datos
Barra de desplazamiento
6.2. CU Prestar Libros
� Patrones conceptuales de interacción
1 Patrón navegación entre UI : UI Principal y secundarias (como todas las UI secundarias son
de búsqueda, no se desarrollan)
2 Patrón de estructura : Multi-Instancia – Multi-Entidad – Cabecera-detalle � en la
cabecera se ingresan datos del préstamo (ID Socio y cant. días). En el detalle se ingresan
datos de los ejemplares prestados.
3 Panel datos principal 
� Patrón datos
✓ Estilo Free-Form
✓ Patrones a nivel de Objetos
Recuperar para mostrar (socio)
Ingreso de número de cualquier tipo o formato (cantidad de días)
 28/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
3
4
4.3
4.1
4.2
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
� Patrón acciones
✓ Panel externo común
4 Panel datos secundario 
� Patrón datos
✓ Estilo Tabular (4.1)
✓ Patrones a nivel de Objetos
Recuperar para mostrar (Id Ejemplar) (4.2)
Construir una lista desordenada de elementos (4.3)
5 Patrón navegación 
� Navegación interna a nivel datos
6 Patrón ordenamiento 
� Interno
� Patrones de diseño de interacción (Tidwell)
1 Panel datos principal
� Patrones a nivel de Objetos
Spin box (cantidad de días)
2 Panel datos secundario
� Patrones a nivel de Objetos
Lista con botón agregar (Id ejemplar)
7. Conclusión
En este trabajo se han sentado las bases para construir un catálogo de patrones
conceptuales de interacción para IHM. Se ha desarrollado una lista inicial de los mismos,
aportando un marco teórico en el cual basarse. Incluso se ha ejemplificado la idea de que los
patrones conceptuales pueden luego implementarse con patrones de diseño de interacción de
más bajo nivel sobre los cuales hay literatura abundante.
Para completar este desarrollo es necesario trabajar con grupos de analistas y
diseñadores con el objeto de contrastar diversas soluciones de IHM de manera de comprobar si
el catálogo de patrones conceptuales resulta suficiente para cubrir la variedad de IHM que
podemos encontrar en la aplicaciones administrativas empresariales. 
Además, se desprende del trabajo de ejemplificación de los patrones realizado, que
sería deseable desarrollar un lenguaje de íconos que permitan construir bosquejos de la IHM
sin necesidad de recurrir a objetos reales usados en implementaciones de IHM. Si
dispusiéramos de un lenguaje de íconos ad hoc, para representar los bosquejos evitaríamos el
riesgo de que los diseñadores interpreten que el bosquejo de IHM construido por el analista es
la pantalla final. Es importante, que al aplicar esta técnica tanto el diseñador como el analista
sean conscientes de que los patrones conceptuales deben ser usados por el analista para
representar en bosquejos de unidades de interacción requerimientos realmente necesarios
desde el punto de vista del negocio, pero que luego podrán ser implementados por el diseñador
con algunas alternativas posibles de patrones de diseño de bajo nivel.
Este trabajo constituye el punto de partido para un trabajo de I+D quea nuestro juicio
permitiría realizar un aporte significativo en la mejora de las IHM construidas por los grupos de
desarrollo de software. Es importante reconocer que si bien el catálogo de patrones aún no
está maduro, es factible comenzar a utilizarlo en proyectos piloto como una manera de hacerlo
evolucionar en la práctica, y lograr los objetivos planteados en un mediano plazo.
8. Bibliografía
o Tesis Doctoral "Especificación de interfaz de usuario: De los requisitos a la
generación automática" - Pedro J. Molina - Universidad Politécnica de Valencia –
Valencia, España - Marzo de 2003
 29/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07] 
Introducción a Patrones Conceptuales en el diseño de la Interaccion Hombre
Máquina - Diseño de Sistemas
Autor: L. Ripani - E. Porta Versión : 1.01b [1/9/09] 
Cátedra Diseño de Sistemas UTN – F.R.Ro.
o “Ingeniería de la web y patrones de diseño” – (Capitulo 10, Molina) - Pearson
Educación - - Marzo/2006
o “Interaction patterns in user interfaces” – Martijn van Welie – Paper on-line
(http://www.cs.vu.nl/~martijn/patterns/PLoP2k-Welie.pdf)
o “Mastering the Requirements Process” – Suzanne Robertson, James Robertson –
ACM Press / Addison-Wesley – London (UK) – 1999
o “Diseño de interfaces de usuario ” - Shneiderman Ben, Pearson Educación, Marzo
2006
o “Designing Interfaces - Patterns for Effective Interaction D esign ” Jennifer Tidwell –
Editorial O’Reilly – 2005
o “Usability Engineering ” - Jakob Nielsen – publicado por Morgan Kaufmann - San
Francisco - 1994.
o “Software for Use ” - Larry L. Constantine, Lucy A. D. Lockwood - Addison-Wesley
Professional - 1999
o "A Pattern Language: Towns, Buildings, Construction " - Christopher Alexander -
Oxford University Press - 1977
o "Design Patterns: Elements of Reusable Object-Orient ed Software " - Eric Gamma,
et.al. - Addyson Wesley - 1995
9. Historia de Versiones del documento
Versión Fecha Autor Descripción
0.01 09/08/09 LRI /
ENPO
Versión inicial en base a documentos parciales
“Introduccion_a_Patrones_de_Diseño_de_Interaccion_v1_03.pdf” y
“Patrones_Conceptuales_de_Interaccion_en_AG_v1_14.pdf”
'1.01 01/09/09 LRI /
ENPO
Mejora de algunos gráficos, y se completa sección documentos
relacionados
'1.01b 01/09/09 LRI Se corrige problema de impresión en pag. 15
 30/30 9/1/2009 12:58:44 PM
V:\w_conting\UTN\DS\Patrones-Conceptuales_en_Diseño_Interaccion-HM_UTN-FRRo_v1_01b.odt 
Plantilla: campo word: hardwired: doc_basico_UTN v. 3.1 [10/8/07]