Reemplazar <userAction> por <systemAction>

Motivación

Un proceso de negocio está compuesto de <systemActions> y <userActions>. Los <systemActions> corresponden a todas las actividades procesadas internamente por el sistema y que son transparentes para el usuario, como: validaciones de datos o búsqueda de datos en el sistema. Por otra parte, un proceso depende del usuario, que es quien lo alimenta, proveyendo los datos necesarios para que el proceso de negocio continúe. Esas acciones son llamadas de <userActions>, y son ejemplo de ellas, la entrada de datos o el accionar de los botones.

En los procesos de negocio embebidos en las aplicaciones web, cuanto menos el usuario tenga que interactuar con el sistema (cuanto menos <userActions>) mejor, porque cuanto menos se solicite al usuario entrar datos, ejecutar acciones o responder a preguntas, más intuitivo y rápido será el proceso y menos laboriosa su ejecución. Por estas razones, este refactoring propone hacer una análisis de todos los <userActions> del proceso con el objetivo reemplazarlos por <systemActions>, siempre que sea posible. En otras palabras, este refactoring busca hacer que, si es posible, el sistema ejecute algunas acciones que hasta entonces eran realizadas por el usuario, haciendo que estas se resuelvan internamente y sin la intervención del mismo.

El bad smell que vulnera este refactoring es la cantidad excesiva de datos que los usuarios tienen que completar cuando hay posibilidad de obtener esos datos automáticamente.

65

Mecanismo

Este refactoring puede ser realizado en cuatro pasos:

1. Identificar dentro del diagrama de proceso las actividades ejecutadas por los usuarios, los <userActions>.

2. Identificar el o los <userActions> identificados en el paso 1 que puedan ser reemplazados por un <systemAction>.

3. Crear un nuevo <systemAction> para cada <userAction> identificado en el paso 2 asociándolos a los datos que se necesite acceder.

4. Eliminar los <userActions> que fueron identificados en el paso 2 e insertar en su lugar el/los nuevo(s) <systemAction(s)>, conectándolo(s) a través de nuevos processLinks según corresponda.

Ejemplo

El ejemplo de este refactoring describe un proceso de registración de grandes sitios de comercio electrónico de Brasil, Submarino (www.submarino.com.br) y Saraiva (www.livrariasaraiva.com.br). Estos sitios, así como la mayoría de las páginas de E-Commerce, requieren que un usuario nuevo se registre proveyendo información personal, como nombre, e-mail, dirección, datos de tarjeta de crédito, etc. El proceso de registración es generalmente largo y requiere mucho del usuario haciendo que este ingrese gran cantidad de datos en los formularios mostrados en las páginas.

En el proceso de registración de una de las páginas seleccionadas, se identificó una sección que demanda del usuario llenar muchos campos, la sección "Dirección"; en ella se pide al usuario que ingrese uno por uno los siguientes datos: Código Postal, País, Calle, Número, Barrio, Provincia y Ciudad como se observa en la Figura 19.

66

Figura 19: Vista parcial del proceso de registración de la página web de Saraiva antes del refactoring

Como se observa en el diagrama, el usuario tiene que informar siete campos distintos relacionados con su dirección. Sin embargo, los códigos postales de Brasil identifican detalles de la dirección del usuario y por esa razón bastaría con que se ingrese el código postal para que el sistema identifique automáticamente la dirección del usuario, evitando que el mismo tenga que ingresar manualmente todos esos datos. Con este refactoring se cambia la acción del usuario de entrar múltiples datos a ingresar únicamente el código postal de su domicilio, a partir del cual, automáticamente el sistema hace la verificación internamente de la dirección postal del cliente.

67

Figura 20: Vista parcial del proceso de registración de la página web de Saraiva después del refactoring "Reemplazar <userAction> por <systemAction>

En la Figura 20 se advierte que parte de las acciones que antes necesitaban del usuario ahora son realizadas internamente por el sistema. El sistema, a través del código postal informado al principio, procesa la mayoría de las informaciones de la dirección del usuario, completándolas automáticamente en el formulario. Con eso

68

el usuario solo necesita ingresar dos campos (código postal y número) en lugar de los siete que tenía que ingresar antes de la aplicación del refactoring.

En el sitio de comercio electrónico Submarino ya existe esta opción y el usuario solamente necesita ingresar su código postal para que la mayoría de las informaciones de su dirección sean cargadas automáticamente por la aplicación. El usuario tiene apenas que cargar informaciones personales como el número y teléfono, como se observa en la Figura 21. Este mismo mecanismo se utiliza en otras páginas de E-Commerce como el del supermercado Tesco (www.tesco.com).

Figura 21: Ejemplo de la página de Submarino donde la dirección es cargada automáticamente por la aplicación después del usuario ingresar su código postal

Mejoras Intencionadas

- Reducción del número de acciones ejecutadas por el usuario haciendo que sea menos costoso para este ejecutar el proceso;

- Reducción del tiempo necesario para finalizar con el proceso;

- Aumento de la eficiencia de la aplicación web donde el sistema procesa las informaciones internamente sin depender del usuario;

Refactorings Relacionados

Este refactoring está relacionado con el refactoring descripto a seguir en el capitulo 4.2.4: "Remover pasos duplicados" y también con el refactoring detallado en el capitulo 4.2.7: "Agregar funcionalidad de Autocompletar en formularios" que serán analizados en más detalle en las próximas secciones.

69