Enfoque transformacional

3. Ingeniería de Software.
UNIDAD 01

4. Enfoque Transformacional
01Ingeniería de Software | Enfoque Transformacional

5. Complexity
¿Qué profesión es la más antigua?
Doctor, Ingeniero Civil, Informática
Doctor: Eva extraída de una costilla de Adán
Ingeniero Civil: Ordene todo el caos para crear el cielo y la tierra
Ciencias de la Computación: ¿Quién creó el caos?
02Ingeniería de Software | Enfoque Transformacional

6. Complejidad
Explicamos la
naturaleza por
medio de
simplificaciones
03Ingeniería de Software | Enfoque Transformacional

7. Complejidaddeldominio
delproblema
04Ingeniería de Software | Enfoque Transformacional

8. 10 propiedades a preservar en las IU
International Federation for Information Processing (IFIP)
• Categoría 1: presentación de la información
• Multiplicidad de dispositivos: teclado, mouse, tablet,…
• Multiplicidad de representaciones: representaciones alternativas de Entrada y Salida,
• Reusabilidad de Entrada/Salida (usar la Salida producida por una acción de Entrada por otra)
• Categoría 2: ordenamiento de la planeación de tareas
• Multiplicidad de roles de usuario
• Multiplicidad de rutas de ejecución: los usuarios deben tener la posibilidad de participar en la ejecución
de tareas diferentes de forma simultanea
• No-anticipación: grado de libertad al usuario para decidir lo que sigue
• Alcance: posibilidad de moverse en el sistema (undo, redo)
• Observabilidad vs Navegabilidad
• Categoría 3: adaptación del dialogo
• Reconfigurabilidad: habilidad del sistema para soportar la personalización del usuario
• Adaptativo: la habilidad del sistema de soportar la adaptación automática
• Migrabilidad: habilidad del sistema de transferir la responsabilidad de un usuario a otro, entre usuarios,
entre el usuario y el sistema
• Plasticidad: habilidad del sistema para adaptarse al contexto de uso preservando propiedades de
usabilidad
[Gram & Cockton,1986]
05Ingeniería de Software | Enfoque Transformacional

9. Mayor reto hoy en día
• Proliferación de desarrollos
UI #12UI #11UI #10UI #9Application 3
UI #8UI #7UI #6UI #5Application 2
UI #4UI #3UI #2UI #1Application 1
Platform #4Platform #3Platform #2Platform #1
Application 1
Application 2
Application 3
UI model #1
UI model #2
UI model #3
Platform #1
Platform #2
Platform #3
Platform #4
Platform model #1
Platform model #2
Platform model #3
Platform model #4
[Abrams et al.,2001]
06Ingeniería de Software | Enfoque Transformacional

10. Enfoque clásico de desarrollo de IUs con un ambiente
gráfico (IDE)
• Ciclo
Descríbelo has prototipo codifícalo a prueba y error
[Vanderdonckt,2010]
07Ingeniería de Software | Enfoque Transformacional

11. Los entornos de desarrollo ofrecen una solución parcial
Interfaz deseada Solución alcanzable
 Ventana
 Barra de menú
 Paleta (iconos)
 Scrollbars
 Otros widgets: drop-down list, etc.
 Tabla con datos dinámicos
 Diagrama de Gantt
 Manipulación directa de losDirect
manipulation of widgets
[Vanderdonckt,2010]
08Ingeniería de Software | Enfoque Transformacional

12. Enfoque clásico
• Ventajas
• La IU es gráfica por naturaleza
• Una IU puede ser
• Rápidamente prototípica
• Fácilmente modificable
• Visualmente mostrada
• Restricciones
• No hay un método estructurado para el manejo de la distribución
• La selección de widgets podría ser inapropiada
• Distribuir los widgets puede ser tedioso, repetitivo
• Problema de espagueti
• Cada cambio en la IU puede orillar a un diseño no estructurado
[Vanderdonckt,2010]
09Ingeniería de Software | Enfoque Transformacional

13. DISEÑO BASADO EN
MODELOS COMO
SOLUCIÓN
10Ingeniería de Software | Enfoque Transformacional

14. Qué es el diseño basado en modelos?
• El diseño basado en modelos consiste en
• Describir la IU en un modelo de IU
• Basarse en este modelo para guiar el ciclo de vida de
desarrollo de IU
• Mientras se siguen las siguientes metas:
• Generar ambientes de desarrollo de IU compresibles
• Soporte robusto al ciclo de vida de desarrollo de IU
• Mejorar la portabilidad
• Integrar la usabilidad en el desarrollo
• de IU
• Una estructura de 3 dimensiones
Modelos
Lenguaje UsiXML
Metodo en pasos
HerramientasSoftware
suporte
involucra
Descritos en
Metodologia de desarrollo
[Vanderdonckt,2010]
11Ingeniería de Software | Enfoque Transformacional

15. Qué es el diseño basado en modelos?
• Qué es un modelo?
• Definiciones del diccionario Webster:
• « Aquel que se usa para mostrar ropa y otras mercancias (lenceria por citar un ejemplo)»
• « Un conjunto de planos de un edificio » (buena analogía)
• « Un sistema de postulados, datos, e inferencias presentadas como una descripción matemática de una entidad »
• Nuestra definición
• Un conjunto de planos estructurado de planos para desarrollar una IU
• Un sistema de postulados, datos, e inferencias presentadas como una descripción de IU (o especificación) que
guía el ciclo de vida de desarrollo de IU
[Vanderdonckt,2010]
12Ingeniería de Software | Enfoque Transformacional

16. Qué es el diseño
basado en modelos?
• Qué es un modelo?
• Un ejemplo simple para propósito de
comprensión. Sistema de login
• Encontrar la abstracción correcta para el
modelo no es
• Replicar el código de otra forma
• Capturar todas las propiedades físicas
[Vanderdonckt,2010]
13Ingeniería de Software | Enfoque Transformacional

17. Qué es un modelo?
• Encontrar el modelo correcto para el SI
• Convertir los aspectos importantes de la IU en
opciones de diseño
• E.g. alineación de la etiqueta en vez de
coordenadas
• Derivar propiedades finales de estas opciones
• E.g., computar las coordenadas de la
alineación = {left, right, aligned, centred,
justified}
LabelAlignement = left
ButtonPlacement = TotalEquil
[Vanderdonckt,2010]
14Ingeniería de Software | Enfoque Transformacional

18. Qué es un modelo?
• Encontrar la abstracción del modelo SI
• Describir los widgets de IU
independientemente de la tecnología
• ¿Por qué?
Identification label
Input text
Push button
[Vanderdonckt,2010]
15Ingeniería de Software | Enfoque Transformacional

19. Por qué describir los widgets independientes de la tecnología ?
• Porqué hay muchos lenguajes o representaciones para ejecutar una tarea
• Por que el mismo widget aparece en diferentes tecnologías
• Por que hay muchas formas de alcanzar un objetivo (e.g., selector)
Check Box
(Windows)
BoxArray
(Garnet)
XmToggleButton
(OSF-Motif)
[Vanderdonckt,2010]
16Ingeniería de Software | Enfoque Transformacional

20. Permiten crear IU
sistemáticamente
GrafiXML
17Ingeniería de Software | Enfoque Transformacional

21. Qué se necesita para tener un modelo de IU de calidad?
•No introducir en
exceso,
ya que se vuelve
muy complejo
(<> simple)
•No introducir
muy pocas,
ya que se vuelve
simplista (<>
simple)
Las
abstracciones
son limitadas
pero
extensibles
•Completo
•Consistencia
•Corregible
•Expresivo
•…
C1: Necesita
asegurar la
calidad en las
propiedades
del modelo
[Vanderdonckt,2010]
18Ingeniería de Software | Enfoque Transformacional

22. De Código a Modelos
• En un primer de abstracción,
se pasa de la interfaz final (FUI)
a la interfaz concreta (CUI)
• Consecuentemente, una CUI
es independiente de
• Cualquier lenguaje:
(X)HTML, Java, Visual
Basic, C++
• Cualquier plataforma de
computo: Windows, Linux,
MacOS
[Vanderdonckt,2010]
19Ingeniería de Software | Enfoque Transformacional

23. De Modelos Concretos a Abstractos
• IUs no sólo son gráficas, si no que pueden ser vocales, táctiles, 3D, hápticas,
multimodales
• Entonces, hay necesidad de hacer mayores abstracciones, no solo hay GUIs
Abstract Container
Abstract Individual Component with Output
Abs. Ind. Comp. with Input
Abs. Ind. Comp. with Control [Vanderdonckt,2010]
20Ingeniería de Software | Enfoque Transformacional

24. De Modelos Concretos
a Abstractos
• Con este segundo nivel de
abstracción, se va de CUI a IU
Abstracta (AUI)
• Consecuentemente, una AUI es
independiente de
• Cualquier modalidad de
interacción
[Vanderdonckt,2010]
21Ingeniería de Software | Enfoque Transformacional

25. De Modelos
Abstractos a
Modelos de
Tareas &
Conceptos
Entonces, hay necesidad de modelar los problemas
independientemente de la plataforma de computo
Modelos de Tarea y datos (UML
Class Diagram)
IUs, incluso si son abstractas, estan estructuradas
acorde al sistema objetivo lo que va en contra del
paradigma centrado en el usuario
[Vanderdonckt,2010]
22Ingeniería de Software | Enfoque Transformacional

26. De Modelos Abstractos a
Modelos de Tareas &
Conceptos
[Vanderdonckt,2010]
23Ingeniería de Software | Enfoque Transformacional

27. ¿Qué tenemos hasta ahora?
CON ESTE TERCER CONJUNTO DE
ABSTRACCIONES, PASAMOS DEL MODELO
AUI AL DE TAREAS Y DATOS (T+D)
CONSECUENTEMENTE, EL T+D ES
INDEPENDIENTE DE CUALQUIER
IMPLEMENTACIÓN DE COMPUTO
[Vanderdonckt,2010]
24Ingeniería de Software | Enfoque Transformacional

28. ¿Necesitamos más modelos?
[Vanderdonckt,2010]
25Ingeniería de Software | Enfoque Transformacional

29. Soportar el Diseño
de Propiedades de
Plasticidad
• Adaptación al contexto de uso
mientras satisface propiedades
de usabilidad
[Grolaux et al.,2002]
26Ingeniería de Software | Enfoque Transformacional

30. Demo FlexClock
[Grolaux et al.,2002]
27Ingeniería de Software | Enfoque Transformacional

31. EJEMPLO PRACTICO
Sala de emergencias
28Ingeniería de Software | Enfoque Transformacional

32. Escenario-Multi-plataforma para Emergencias
• Tres plataformas
• Pocket PC
• Desktop PC
• Wall Screens
[Vanderdonckt,2010]
29Ingeniería de Software | Enfoque Transformacional

33. ¿Como resolver este
problema ?
• Múltiples usuarios
• Paciente
• Doctor
• Recepcionista
• Enfermero
• Radiólogo
• …..
• Múltiples ambientes
• Sala de espera
• Quirófano
• Consultorio
[Vanderdonckt,2010]
30Ingeniería de Software | Enfoque Transformacional

34. Solución
Propuesta
[Vanderdonckt,2010]
Énfasis también fue puesto sobre
los iconos usados
Modelo y método
Diseñar primero la pantalla de
referencia
Refinar las otras pantallas después
• Aplicando degradación gradual (se vera a
detalle mas adelante)
• Aplicando técnicas de transformación
31Ingeniería de Software | Enfoque Transformacional

35. Usando técnicas de degradación gradual de la IU se lograron las diferentes
versiones de pantallas, menús grandes fueron modificados por menús más
pequeños, con herramientas y reglas de degradación agradable
[Florins & Vanderdonckt,2004]
32Ingeniería de Software | Enfoque Transformacional

36. Algunas reglas de transformación para degradar un control de listas para agregar o quitar contenido de
una lista a otra
Add all >>
Add >
<< Remove all
< Remove
>>
>
<<
<
>
<
Group box
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
Item 8
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
Item 1
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
33Ingeniería de Software | Enfoque Transformacional

37. Poly Medis
• Sala de Urgencias Digitalizada
• Automatización recepción
• Workflow del proceso de atención
• ToDo list
[Vanderdonckt,2010]
34Ingeniería de Software | Enfoque Transformacional

38. Marco de Referencia Camaleon
[Calvary et al.,2003]
35Ingeniería de Software | Enfoque Transformacional

39. 1-39
Aplicación de reglas de Transformación
Sistema de calculo de profesores por curso
36Ingeniería de Software | Enfoque Transformacional

40. Paso 1.
Consolidación
de Modelo de
Tareas
37Ingeniería de Software | Enfoque Transformacional

41. 1-41
38Ingeniería de Software | Enfoque Transformacional

42. 1-42
Mapeos del modelo de
tareas con el de
Dominio
Rule: A task manipulates a domain class
Regla: Una tarea manipula una clase del
Dominio
39Ingeniería de Software | Enfoque Transformacional

43. 1-43
Consolidación de Modelo
de Tareas
NAC LHS RHS
::=
NAC LHS RHS
::=
Regla: Para cada tarea que manipula una clase de Dominio, una nueva subtarea
es creada por cada atributo
Cada una de las nuevas sub-tareas será mapeada al atributo de la clase
correspondiente
Rule: For each task that manipulates a domain class, a new subtask is created for
each attribute.
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
40Ingeniería de Software | Enfoque Transformacional

44. 1-44
Modelo de Tareas Expandido 41Ingeniería de Software | Enfoque Transformacional

45. 1-45
Paso 1. Consolidación de Modelo de TareasTask &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
Task Task Type Task Item User category
Select NoTrainers Select Element Interactive
Select Trainer
Salary
Select Element Interactive
Select TrainerWD Select Element Interactive
Select NoStudents Select Element Interactive
Select Student
Salary
Select Element Interactive
Select annualWD Select Element Interactive
Calculate Salary Start Element System
Communicate
Result
Convey Element System
Exit Terminate Collection Interactive
42Ingeniería de Software | Enfoque Transformacional

46. 1-46
• Paso 2. De modelado de Tareas a Interfaz
Abstracta
43Ingeniería de Software | Enfoque Transformacional

47. 1-47
Paso 2. De modelado de Tareas a Interfaz
Abstracta
NAC LHS RHS
::=
NAC LHS RHS
::=
Cada tarea es ejecutada en un contenedor Abstracto si la
tarea es descompuesta en subtareas
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
44Ingeniería de Software | Enfoque Transformacional

48. 1-48
Paso 2. De modelado de Tareas a Interfaz Abstracta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
45Ingeniería de Software | Enfoque Transformacional

49. 1-49
Paso 2. De modelado de Tareas a Interfaz Abstracta
NAC LHS RHS
::=
NAC LHS RHS
::=
Cada hoja en el árbol de tareas es ejecutada
por un componente individual asbtracto
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
46Ingeniería de Software | Enfoque Transformacional

50. 1-50
Paso 2. De modelado de Tareas a Interfaz Abstracta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
47Ingeniería de Software | Enfoque Transformacional

51. 1-51
Paso 2. De modelado de Tareas a Interfaz Abstracta - Resultado
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
48Ingeniería de Software | Enfoque Transformacional

52. 1-52
Paso 2. De modelado de Tareas a Interfaz Abstracta
Task Task Type Task Item User category Facet
Select NoTrainers Select Element Interactive Input
Select Trainer Salary Select Element Interactive Input
Select TrainerWD Select Element Interactive Input
Select NoStudents Select Element Interactive Input
Select Student
Salary
Select Element Interactive Input
Select annualWD Select Element Interactive Input
Calculate Salary Start Element System Control
Communicate Result Convey Element System Output
Exit Terminate Collection Interactive Control
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
49Ingeniería de Software | Enfoque Transformacional

53. 1-53
• Paso 3. De modelado de Interfaz Abstracta a
Interfaz Concreta
50Ingeniería de Software | Enfoque Transformacional

54. 1-54
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
51Ingeniería de Software | Enfoque Transformacional

55. 1-55
Concrete
User
Interface
Para cada
Abstract
Container
Paso 2. De modelado de Tareas a Interfaz Abstracta
Que
contenga un
abstract
individual
component
(AIC)
Y este AIC
tenga una
faceta de
input
Y tenga de
tarea select
Task &
Concepts
Abstract
User
Interface
Final User
Interface
52Ingeniería de Software | Enfoque Transformacional

56. 1-56
Paso 2. De modelado de Tareas a Interfaz Abstracta
Y tenga como
dominio de
datos
unrango
continuo
El AIC se
concretiza en
un Slider
contino en
una caja
(Box)
Se aplica la
regla
Concrete
User
Interface
Task &
Concepts
Abstract
User
Interface
Final User
Interface
53Ingeniería de Software | Enfoque Transformacional

57. 1-57
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
54Ingeniería de Software | Enfoque Transformacional

58. 1-58
Paso 3. De modelado de Interfaz Abstracta a
Interfaz Concreta
– Selección de Widgets pensando que
estamos en la modalidad 3D.
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
55Ingeniería de Software | Enfoque Transformacional

59. 1-59
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
– Questions and answers method [MacLean
1991]
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
56Ingeniería de Software | Enfoque Transformacional

60. 1-60
Paso 3. De modelado de Interfaz Abstracta a Interfaz Concreta
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
57Ingeniería de Software | Enfoque Transformacional

61. 1-61
Paso 4. Interfaz Final
57Ingeniería de Software | Enfoque Transformacional

62. 1-62
Video del Resultado Final
Task &
Concepts
Abstract User
Interface
Concrete
User Interface
Final User
Interface
58Ingeniería de Software | Enfoque Transformacional

63. Pie de foto.
Bibliografía
•Muñoz Artega, J., GONZALEZ CALLEROS, J. M., & Huitrón, A. S. (2015). La interacción
humano-computadora en México. Pearson Educación.
•Vanderdonckt, J. Usabilité (2010). Notas del curso de Interacción Humano
Computadora, reproducidas con autorización del autor bajo la licencia creative
commons (CC).
59Título de la sección 1 | Título de la presentación

64. gracias.
©2020
Es responsabilidad exclusiva de los autores el respeto de los derechos de autor sobre los contenidos e imágenes en el presente documento,
en consecuencia, la BUAP no se hace responsable por el uso no autorizado, errores, omisiones o manipulaciones de los derechos de autor y
estos serán atribuidos directamente al Responsable de Contenidos, así como los efectos legales y éticos correspondientes.