La Vista del Usuario o “No me importa cómo funciona, siempre y cuando funcione”

Si hoy a alguien utiliza un equipo moderno, como una cámara de video, un cajero automático o un teléfono celular, rara vez le interesa como es el equipo adentro. Al usuario promedio no me interesa de que partes electrónicas está compuesta su máquina, o que tipo de software incluye. Por otro lado, si le interesa a un usuario para qué puede ser utilizada una máquina, o qué tipo de funcionalidades tiene o proporciona. Por ejemplo, el comprador de un teléfono celular quieres saber si su dispositivo tiene capacidad WAP o cuantas direcciones puede almacenar. Por lo general, el comprador potencial de un teléfono celular esté interesado en cómo se puede usar el dispositivo, aunque no esté interesado en cómo se construye el dispositivo, siempre y cuando tenga la funcionalidad que desea.

Este tipo de vista de un sistema se denomina caja negra, lo que significa que el sistema o el dispositivo se representa como una caja negra; no se puede mirar adentro.

No sabe cómo funciona; sólo sabes que funciona. Idealmente, ésta es la vista que un usuario debería tener de un sistema IT. El o ella utiliza el sistema IT para completar y terminar su trabajo, como una cafetera o una fotocopiadora. Sabe lo que se puede hacer con el sistema, y generalmente también saben cómo hacerlo.

La vista externa es una parte esencial del modelo del sistema IT. Aquí, se determina qué esperan los futuros usuarios del sistema IT. La funcionalidad que se define en esta vista debe usarse en última instancia, para verificar si el sistema IT cumple con los requisitos que el usuario desea.

La vista externa consiste de los siguientes elementos:

• Diagramas de caso de usos
• Diagramas de secuencias
• Prototipo de interfaces

A primera vista, estos elementos parecen extraños. Algunos analistas pueden tener la tentación de alegar que es suficiente registrar los requisitos del usuario en forma de prosa. Pero la experiencia en la práctica muestra una y otra vez que esto no es verdad. La prosa puede ser inconsistente, imprecisa incompleta, sin que se vuelva obvia para el futuro usuario cuando la lea. El sistema IT se desarrolla en consecuencia y el programador interpreta la prosa como tercero, desde su propio punto de vista, e implementa el sistema inconsecuencia. Los diagramas definidos por UML que describimos y explicamos en este capítulo están destinados a ayudar a evitar malos entendidos y malas interpretaciones. Los diagramas son herramientas para describir los requisitos para sistema de IT.

Un elemento esencial de un sistema es la interfaz del usuario. La interfaz del usuario de un cajero automático, por ejemplo, consiste en un monitor pequeño, con teclas y aberturas para las tarjetas, facturas y recibos, así como diferentes sonidos.

La interfaz del usuario es el único punto de acceso que un usuario tiene a un sistema. Si, por ejemplo, falta el botón de grabación de una grabadora de vídeo, es imposible grabar nada, inclusive si la grabadora estuviese equipada para esta función internamente.

La interfaz del usuario representa un tipo de vista de la funcionalidad del dispositivo. Lo que falta en esta vista será inaccesible para el usuario.

Sin embargo, la interfaz del usuario ofrece una vista estática del sistema. Esta vista no muestra cómo se supone que se debe ser usado el sistema, y cuales elementos operativos o de operación deben ser utilizados para completar una determinada tarea.

Debido a esto, las interfaces de usuario requieren manuales de instrucción. Solo lo que se define en el manual de instrucciones es un curso de acción significativa.

El siguiente ejemplo es un curso de acción (flujo) significativo para el uso un teléfono: levantar el receptor, esperar el tono de marcado, escribir uno de teléfono válido, esperar que alguien conteste el teléfono, hablar y colgar. Lo flujos que no están definidos en el manual de instrucciones no se consideran significativos y no son compatible con sistema. En sistemas pobremente desarrollados, puede suceder que los flujos que no están definidos tengan consecuencias inesperadas o incluso bloqueen el sistema. A veces, los sistemas de IT modernos pueden resolver problemas ad-hoc o problemas específicos, especialmente las consultas. Debido a su naturaleza, los casos de uso ad-hoc no se incluyen en las descripciones normales. Se deben encontrar otras soluciones para ellos, por ejemplo, la especificación de un entorno o de otro sistema específico que permita consultas ad-hoc. En lugar de una descripción, los casos de uso ad-hoc reciben una referencia a una herramienta de informes o un lenguaje de consulta.

Para los usuarios, un sistema consiste esencialmente en una interfaz de usuario y casos de uso, aunque generalmente sólo representan la punta del iceberg. Todos lo que va más allá no le interesa a los usuarios. ¿O alguna vez has reflexionado sobre qué tipo de sistema hay detrás de las teclas del teléfono celular?.

Escriba los casos de uso de un sistema con el que trate de manera general. Tal sistema podría hacer, por ejemplo, un cajero automático, una cafetera o un portal web.

La Figura 4.4 muestra al actor que está llevando a cabo un caso de uso. El mejor enfoque para modelar los casos de uso de un sistema IT es precisamente imaginar a un usuario que se siente frente al teclado y trabaja con el sistema IT (ver Figura 4.4). El usuario se convierte en el actor, y no es caso de uso no es más que una descripción abstracta de la actividad del usuario.

Un actor:

• Interactúa directamente con el sistema
• Siempre se encuentra fuera del sistema con el que interactúa.

Para el sistema IT, esto significa que el actor es siempre el que opera directamente el sistema IT.

Incluso en los sistemas empresariales de mayor jerarquía (consulte el sistema de modelado empresarial), los actores se ubican en el exterior. Puede ser, como por ejemplo, clientes o socios.

El trabajador que opera el sistema IT, por otro lado, es parte del sistema del negocio. Debido a esto, el o ella no puede ser un actor del sistema de negocios: Figura 4.5.

Esto lleva a la situación mostrada en la Figura 4.5:

• Un pasajero es actor del sistema comercial o sistema de negocios, y generalmente trata con un empleado del check-in. Sin embargo, él o ella también pueden ser actores del sistema, por ejemplo durante el check-in automático, que es realizado en una máquina.

• Un empleado del check-in es parte del sistema comercial o sistema de negocios. Debido a esto, él o ella no son actores del sistema IT.

• Un representante para realizar el check-in, este representante realiza el check-in en lugar de otra persona, es sólo un actor del sistema IT, esto es porque él o ella no pueden realizar el check-in automático, y por lo tanto, nunca tiene contacto directo con el sistema de IT.

En resumen, podemos decir que los actores y los casos de uso son muy adecuado para comunicarse con los usuarios o los expertos del dominio sobre la funcionalidad de los sistemas de IT que son visibles desde el afuera o desde el exterior.

En nuestra oficina de intercambio Hanseatic merchant’s, la separación entre el sistema de negocios y el sistema IT es algo difícil. Sin embargo, puede considerar que la oficina del secretario con los empleados y que la secretaria Hildebrand son los que constituyen la funcionalidad del sistema de información (sin IT o sin computadora). Un caso de uso, entonces, correspondería con un proceso de trabajo de la secretaria Hildebrand, como la actualización de los recibos de pago, un resumen de los costos e ingresos del mes pasado. Aquí, el actor es el propietario, el Sr. Hafenstein (vea Figura 4.6):