Agrupar Validaciones

58

Motivación

En los procesos cortos, la gran cantidad de validaciones de datos consume tiempo del usuario y complica sin necesidad el proceso, que debería ser simple. Por esa razón, reducir el número de validaciones durante la ejecución de un proceso hace que este sea más rápido, dinámico y objetivo, como debe ser un proceso pequeño.

El propósito de este refactoring es simplificar el proceso de validación evitando que se haga una por cada campo informado por el usuario, lo que se traduce en la reducción de la interacción entre el servidor y el cliente, y consecuentemente el tiempo de respuesta y tiempo de espera por parte del usuario. Otra ventaja es que al agrupar las validaciones se reduce también la cantidad de pasos necesarios para completar el proceso, ya que en este caso las validaciones no son transparentes al usuario (o sea, las validaciones no son realizadas internamente por el sistema) y exigen que el mismo interactúe en el proceso presionando los botones para completar las mismas.

El número excesivo de validaciones confunde al usuario, hace que la ejecución del proceso deje de ser fluida y prolonga el tiempo de espera mucho más allá de lo necesario. Validaciones realizadas precipitadamente en transcurso de un proceso simple generan ruido innecesario, por eso es importante que sean evitadas en un etapa temprana del mismo. El refactoring "Agrupar Validaciones" propone que estas validaciones se agrupen y se retrasen en el final de la carga de datos, validándolos todos juntos, resultando que el proceso sea más sencillo para el usuario. Este refactoring es indicado para ser aplicado a procesos pequeños, no muy extensos, donde la cantidad de campos a validar no es numerosa, como por ejemplo, el proceso de Login a un sistema.

Este refactoring representa un cambio en la estructura del proceso, donde se hace una agrupación de actividades para reducir los pasos y hacer que sea más rápido para el usuario.

El “bad smell” que motiva este refactoring sería el tiempo excesivo que se pierde en validar cada campo individualmente y navegar al siguiente campo a ser completado.

Mecanismo

Este refactoring propuesto puede ser realizado en cinco pasos:

1. Identificar todos los <userActions> del proceso que se validan individualmente.

2. Agrupar los <userActions> identificados en el paso 1 creando un nuevo <userAction>. Insertar el nuevo <userAction> en la posición del primer <userAction> del grupo. Colocar en el nuevo <userAction> todos las salidas (output pins) que estaban en cada uno de los <userActions> individuales.

3. Identificar cada una de las validaciones del sistema (<systemActions>)

4. Crear un nuevo <systemAction> que representa el conjunto de los <systemActions> identificados en el paso 3 y ubicarlo en la posición donde se encontraba el último de los <systemActions> individuales que se agruparon.

59

5. Crear un nuevo diagrama de actividad mostrando cómo se compone el nuevo <systemAction> que contiene todas las validaciones agrupadas.

Ejemplo

El ejemplo para este refactoring se refiere a un proceso de Login de la página de Home Banking del Banco Nación Argentina (www.bna.com.ar), como muestra la Figura 15. En esta página el usuario tiene que ingresar su nombre de usuario y presionar el botón “Ingresar” para que se efectúe la validación del usuario ingresado. Después de la validación, el usuario tiene que ingresar la clave y nuevamente presionar el botón “Ingresar” para que se valide la clave de seguridad correspondiente a esta persona.

Las dos validaciones son realizadas en páginas distintas, lo que hace que el usuario tenga que esperar que después de la primera validación se cargue la segunda página, para recién llenar y validar los próximos datos.

60

Se identificaron dos validaciones individuales en la página: la de usuario y la de contraseña. Luego, para evitar que el usuario tenga que ingresar datos y esperar por dos validaciones en dos momentos distintos, las dos validaciones fueron agrupadas. Con eso el usuario tiene que entrar los datos al mismo tiempo y en la misma página y presionar el botón "Ingresar" una sola vez. Una vez hecho eso, el sistema se encarga de hacer interna y centralizadamente las dos validaciones, o sea: verificar si el usuario existe y si la contraseña ingresada corresponde al usuario aludido.

La Figura 16 muestra la refactorización de este proceso, donde ambas validaciones fueron centralizadas en un solo paso.

Figura 16: Proceso de login de la página del Banco Nación Argentina después del refactoring "Agrupar Validaciones"

El mismo problema puede ser visto en otras páginas de Home Banking como el web site del banco Nation Wide (www.nationwide.co.uk) y del banco Santander del Reino Unido (www.santander.co.uk).

Mejoras Intencionadas

- Reducción del número de pasos del proceso ya que algunos fueron agrupados;

- Reducción del tiempo de espera del usuario para ejecutar el proceso ya que se eliminó el tiempo de carga de la segunda página;

- Centralización de los pasos y de las validaciones del formulario en una sola página, como se verá en más detalles en el capítulo 6.2.1;

61

Refactorings Relacionados

Este refactoring impacta no sólo en el diagrama de proceso como también en el de presentación de la página. El cambio estructural que se realiza con este refactoring se refleja también en el modelo de presentación, como está descripto en el capítulo 6.2.1: "Agrupar validaciones en la misma página".

Otro refactoring relacionado está descripto en la sección 4.2.5 de este capítulo: "Anticipar Validaciones", que sugiere el opuesto de este refactoring.