El siguiente patrón que vamos a tratar dentro de esta serie de artículos sobre patrones de casos de uso, será el que se denomina BASIC CREATOR. Este patrón tiene como objetivo crear un nuevo objeto, asegurando al sistema que no será duplicado en el este proceso.
Pensando en el concepto fundamental de un CRUD, correspondería a la C de create. Es decir, que describe cómo debería ser presentada la pantalla al usuario, para que este proporcione todos los datos necesarios para que el sistema realice la creación del objeto, haciendo énfasis en cuidar el detalle de que este objeto no se duplique durante este proceso, y controlando de que el objeto contenga todos los datos requeridos para su creación, así como también que contenga valores válidos.
Como ya se menciona anteriormente, este patrón está particularmente centrado en crear el objeto, siempre y cuando este no exista, por lo que hace referencia a la utilización de solo los datos requeridos u obligatorios, tomando en cuenta que estos datos son los que identificarán al objeto generalmente y tomando en cuenta también que no valdría la pena obligar al usuario a cargar datos opcionales para recibir un mensaje indicando que el objeto podría estar duplicado.
Langlands propone como ejemplo la carga de un nuevo autor dentro de un sistema de biblioteca musical, haciendo referencia a que, no siempre, la determinación de un duplicado está dada por simplemente una propiedad del objeto, como bien podría ser la cédula de identidad o el DNI de una persona. Dentro de este ejemplo, se podría hablar que exista un autor llamado «John David Smith» y cuando el usuario intente cargar un autor «J D Smith», el sistema podría ser capaz de presentar como alerta al usuario que este registro se encuentra posiblemente duplicado.
Otro ejemplo que podríamos dar, podría ser con relación a direcciones de calles. Podría ya existir una calle denominada «Mcal. López», pero también pudiera llegar a ser «Mariscal Francisco Solano López», finalmente la misma avenida, pero recorriendo la ciudad podríamos incluso encontrar carteles con todas estas opciones.
Ahora bien, hay que tomar en cuenta tres cosas:
- Estos son simplemente ejemplos, por supuesto opciones de solución podrían haber muchas, como intentar validar contra un API de Google Maps para el ejemplo de las calles, pero lo importante es entender que no siempre la duplicación podría ser detectada por medio de una propiedad de identificación del objeto.
- La inclusión o no de este control de duplicación avanzado, dependería del caso de uso en particular, lo que nos lleva a entender que no es obligatorio buscar este tipo de dificultad en casos en donde no exista la necesidad
- Existen casos en que la detención de posibles duplicaciones no podría ser automatizado, sino que dependería de mostrar al usuario que opciones son encontradas y que el mismos usuario deba validar si son efectivas duplicaciones o no
Finalmente, la detección de un duplicado, en caso que nuestro caso de uso plantee hacer este tipo de control, se debería representar por medio de un flujo de tipo excepción, diferente al flujo principal de nuestra descripción. Los pasos para ambos flujos se pueden ver a continuación
Por otro lado, este patrón hace referencia a que probablemente, se necesite un patrón BASIC CREATOR, para todo objeto principal (“major” object-type). Esto está muy relacionado al concepto definido por Eric Evans en su libro «Domain Driven Design» denominado «root entities of aggregates», lo que hace mención a las composiciones altamente mencionadas dentro de conceptos como UML, a los que comúnmente las conocemos como cabecera/detalle. Un ejemplo dado bajo este concepto, sería en el caso de una factura y su detalle, en donde si bien la entidad Factura que actúa de raíz, podría contener asociado un caso de uso BASIC CREATOR, pero esto quizás no tiene mucho sentido hacerlo con la creación de sus objetos detalles.
Opinión personal
Personalmente considero que existen varios puntos muy interesantes sobre este patrón
- Pensar en que solo sean tomados en cuenta los datos principales obligatorios para la creación en si del objeto, y llevando este análisis al concepto de la usabilidad de software, me hace evaluar que el enfoque del usuario será mejor contando con una cantidad menor de datos en pantalla, especialmente para objetos de alta complejidad, como bien podrían ser objetos que contengan muchos detalles. Permitir que el usuario cree el objeto y luego, redireccionado a un patrón VIEWER/UPDATER, tenga la posibilidad de ir eligiendo con qué datos continuar, asumiendo que estos ya serían datos opcionales que dependerán del objetivo del usuario
- Siguiendo con este tema, considero bajo mi experiencia que quizás se podría redefinir el concepto de usar los datos obligatorios a un concepto más orientado a datos principales, en donde pudieran estar, a parte de los datos obligatorios que deben ser tenidos en cuenta para la creación, pudiéramos pensar también en datos que podrían estar orientados a ciertas reglas principales que impacten en la decisión de datos opcionales a ser cargados en el siguiente caso de uso
- Otro tema fundamental es que utilizar ya el patrón conocido como PROPERTY LIST, facilita ampliamente la definición de los datos obligatorios o principales a ser cargados en este caso de uso, cumpliendo directamente el objetivo de este patrón
Referencias
Langlands, M. (2013). Inside The Oval : Use-Case Content Patterns (version 2.0), páginas 38 – 42. Link alternativo: descargar
Evans, E., & Evans, E. J. (2004). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional.
Otros artículos de esta serie
- Introducción a los patrones de casos de uso
- Patrón: Object Manager
- Patrón: Property List
- Patrón: Known Object
- Patrón: Basic Creator
- Patrón: Selector
- Patrón: Criteria Search
- Patrón: Viewer/Updater
- Patrón: Destructor