4. REFACTORINGS SOBRE EL MODELO DE PROCESO
4.2. C ATÁLOGO
4.2.8. Agregar posibilidad de Cancelar un proceso
Motivación
Una vez iniciado un proceso en una aplicación web, el usuario tiene que seguir el itinerario de pasos previstos hasta llegar al final y concluirlo. Muchas veces los sitios web no incluyen la alternativa de cancelar o interrumpir una aplicación, el caso de que el usuario lo desee. Esa falta de practicidad del sistema se trasunta como rigidez en el proceso de negocio, al acotar al cliente, negándole la flexibilidad de sus decisiones frente al proceso iniciado.
En el caso de no tener mecanismos para cancelar un proceso antes de completarlo, el usuario que desee interrumpirlo tiene que cerrar la página en que está abierto el proceso, o usar los botones de navegación disponibles en el browser, o bien digitar una nueva URL para dirigirse a una página distinta. Todas estas opciones no son deseables pues pueden generar un estado de inconsistencia en el proceso, aparte de ser frustrantes para el usuario.
Si la lógica de la aplicación no ofrece un método que posibilite cancelar el proceso, el usuario se beneficia de los elementos que son inherentes a la aplicación como las operaciones disponibles en el browser, como los botones de Volver y Avanzar. Como afirmó Baresi et al. en [6], hacer uso de esos mecanismos generan problemas de inconsistencia en la aplicación y pueden resultar confuso para el usuario ya que el estado de la aplicación muchas veces no coincide con la realidad.
Agregar la posibilidad de cancelar un proceso antes de su conclusión muestra que la aplicación web es flexible y que considera al usuario, al incorporar la posibilidad de este no querer (o no poder) concluir el proceso en el momento o de poder volver atrás sobre una decisión (como por ejemplo, clicar sin querer en link que dispara el proceso). Al agregar la posibilidad de cancelar el proceso, el usuario sería removido de los
84
nodos del proceso y re direccionado a la Homepage de la página en cuestión volviendo a los nodos de navegación, donde puede elegir que hacer o como seguir.
El bad smell tratado por este refactoring es la falta de flexibilidad de los procesos de negocio y el estado de inconsistencia generado por el hecho de que el usuario navegue por nodos afuera del proceso.
Mecanismo
Los siguientes pasos deben ser ejecutados para aplicar ese refactoring: 1. Identificar los pasos que componen el proceso de negocio;
2. Agregar un punto de decisión (representado en UML por el elemento ) entre cada paso del proceso agregando la opción de cancelar.
Ejemplo
El ejemplo usado para este refactoring describe el proceso de checkout del sitio de Amazon (www.amazon.com). Cuando el usuario inicia el proceso de compra en la página, solo están disponibles botones para proseguir y avanzar con el proceso, no existiendo ninguna opción disponible para que el mismo pueda ser cancelado. Si el usuario desea salir del proceso que inició tiene que salir de la página (cerrando la ventana o digitando una nueva URL en el browser) o utilizar los botones de volver en el browser para retornar la navegación hacia las páginas anteriores al inicio del proceso. Estos mecanismos son paliativos encontradas por los usuarios debido a falta de opción ofrecidas por la aplicación.
Ofrecer posibilidad de corregir errores o de volver atrás en una acción realizada aumenta la confiabilidad y la satisfacción que el usuario tendrá respecto a la aplicación web pues significa que la página asume que el usuario puede equivocarse, puede querer cambiar de idea y por consiguiente desistir de ejecutar el proceso, no dejándole "preso" en este.
La Figura 30 muestra el proceso de checkout del sitio de Amazon, donde se puede ver que la única manera de salir del proceso es con su conclusión, en la etapa final de confirmación. En caso de que el usuario no pueda completar el proceso, tiene que recurrir a las alternativas mencionadas anteriormente pues la página no incluye otra posibilidad de salida.
85
Figura 30: Proceso de checkout del sitio de Amazon antes del refactoring
Con la implementación de este refactoring se agrega en cada paso del proceso un punto de decisión, la posibilidad de cancelar o de proseguir con el mismo. Si el usuario decide proseguir, el flujo de actividades se ejecutará linealmente hasta su conclusión. Por el contrario, si desea abandonarlo o interrumpirlo antes del final, tiene la posibilidad de cancelar y salir del proceso, sin tener que salir de la página o cambiar la URL del browser.
La Figura 31 muestra el proceso de checkout con la opción de "Cancelar" implementada entre cada uno de los pasos del proceso; si esta es la opción elegida, el proceso se interrumpirá automáticamente y el usuario será re direccionado a los nodos de navegación de la aplicación.
86
Figura 31: Proceso de checkout del sitio Amazon con la opción de Cancelar el proceso, después del refactoring "Agregar posibilidad de cancelar un proceso"
Este refactoring también afecta el diagrama de navegación pues al incluir la posibilidad de cancelar un proceso durante su ejecución, necesariamente altera la navegación en el mismo.
87
Mejoras Intencionadas
- Ampliar la experiencia del usuario al flexibilizar la ejecución del proceso ofrecido;
- Aumentar la confianza del usuario respecto de la página, quien podrá decidir libremente si continúa o no con el proceso iniciado;
- Evitar las inconsistencias devenidas por el uso de paliativos con el fin de salir del proceso antes que el mismo se concluya;
Refactorings Relacionados
Este refactoring está relacionado con el refactoring del modelo de navegación descripto en el capitulo 5.2.2: "Agregar posibilidad de retroceder en el proceso".
88