Patrones de Casos de Uso – Property List

Ya hemos visto dos artículos sobre Patrones de Casos de Uso orientados al diseño, tomando como referencia el paper publicado por Martin Langlands. En este artículo vamos a hablar sobre el patrón PROPERTY LIST, que se trata de como detallar las propiedades de un objeto dentro de los casos de uso que lo necesiten. Es decir que este patrón en realidad no tiene que ver directamente con las acciones de un CRUD, sino que más bien formará parte de varios casos de uso en donde se necesite listar las propiedades de un objeto o los datos que necesitemos.

En resumen, este patrón será utilizado dentro de otros casos de uso que utilicen a su vez los patrones BASIC CREATOR, VIEWER/UPDATER y CRITERIA SEARCH. En estos casos de uso, tenemos la necesidad de decir qué propiedades queremos que el usuario cargue o modifique para un objeto, como así también cuales son los datos que nos sirven para los filtros de una búsqueda y los datos que necesitaremos mostrar en los resultados de la búsqueda o en la visualización de un objeto.

Dando un ejemplo claro sobre esto, podríamos imaginar un caso de uso que permita crear una Persona. Cuando llega el momento de definir cuales serán las propiedades de la persona que el actor deberá cargar, necesitamos listar por ejemplo nombre, apellido, documento de identidad, fecha de nacimiento, etc; este es el objetivo del patrón PROPERTY LIST, estandarizar esta forma de listar o detallar cuales serán las propiedades. Esto mismo ocurre cuando existen filtros de búsqueda en un caso de uso Buscar Persona; o incluso cuando tenemos que mostrar información de la persona para que el actor las pueda ver.

Este listado de propiedades y sus características no solo servirán para discusiones entre el analista y el usuario, sino también para diseñadores, desarrolladores y encargados de test, por lo tanto, Langlands comenta que al describir estas propiedades debemos incluir las siguientes características:

1. El tipo de dato de cada propiedad
   1. Un dato de tipo scalar como string, number, boolean, etc
   2. Un dato estructurado como por ejemplo número de teléfono o email
   3. Una valor seleccionado de una lista
   4. Una referencia a una instancia de otro objeto
2. Si la carga del datos es o no obligatoria
3. Cuales reglas de validación deberían ser aplicadas o que reglas de negocio son aplicadas a esa propiedad como por ejemplo un campo calculado pero no persistido.

Como estas propiedades y sus características pueden ser utilizadas en varios pasos del caso de uso, como por ejemplo cuando indicamos la necesidad de que el usuario cargue ciertos datos o cuando indicamos que el sistema realiza la validación de los datos, tendremos que ponerlos en un lugar común dentro del caso de uso y no dentro de cada paso, ya que si tenemos que detallar esto en los pasos necesarios, por un lado duplicaríamos información que luego sería difícil de mantener y, por otro lado, hacemos más difícil la lectura de la historia que necesita ser contada dentro de los flujos en los casos de uso.

Para lograr el patrón, Langlands propone definir las propiedades dentro de una tabla que se encuentre como una sección dentro de los casos de uso, identificando la tabla con un nombre entendible e identificativo, y definiendo las propiedades dentro de la tabla. Ya en los pasos correspondientes de los flujos del caso de uso que hagan mención a las propiedades, directamente hacer referencia a la tabla.

De esta manera se permite que el caso de uso cuente una historia al lector en cada flujo, sin desenfocarlo con detalles. Por ejemplo, en un paso de actualización de datos podríamos decir que el actor actualiza los datos de acuerdo a la lista de propiedades “Datos de la Persona”; o cuando queremos cargar los filtros de búsqueda podríamos decir que el actor carga opcionalmente uno o más filtros que figuran en la lista de propiedades “Criterios de Búsqueda”.

Un ejemplo de lista de propiedades podría ser como sigue para la carga de datos de una persona

Lista de Propiedades: Datos de la Persona

Propiedad	Tipo de Datos	Validaciones y Otras Reglas
Nombre	Alfanumérico	Obligatorio, Actualizable, Maximo 255 caracteres
Apellido	Alfanumérico	Obligatorio, Actualizable, Maximo 255 caracteres
Documento de Identidad	Alfanumérico	Obligatorio, Actualizable, Maximo 40 caracteres
Fecha de Nacimiento	Fecha	Obligatorio, Actualizable, Menor a la fecha actual
Sexo	Selección	Obligatorio, Actualizable, Obligatorio

Por supuesto, el patrón PROPERTY LIST, indica que las propiedades deberían ser centralizadas por cada caso de uso de forma tabular, proponiendo las columnas de la tabla anterior, no así, determina las columnas a usarse de forma rigurosa. La forma de presentar una lista de propiedades podrá ser de acuerdo a la necesidad, ya que estos patrones son herramientas y no reglas. Por ejemplo, supongamos un caso de uso “Buscar Persona” (Patrón CRITERIA SEARCH), en donde queremos definir los criterios de búsqueda por medio de una lista de propiedades, pero sin embargo, tenemos una búsqueda simple y una avanzada. Podríamos reutilizar la misma lista de la siguiente manera:

Lista de Propiedades: Datos de la Persona

Propiedad	Tipo de Datos	Búsqueda Simple	Búsqueda Avanzada	Validaciones y Otras Reglas
Nombre	Alfanumérico	Si	Si	Se busca en nombre y apellido
Documento de Identidad	Alfanumérico	Si	Si
Fecha de Nacimiento	Fecha		Si
Sexo	Selección		Si	Se selecciona entre Masculino y Femenino

Con este tipo de tablas, que detallan de propiedades de un objeto y se cumplen las siguientes funcionalidades:

1. Facilitar y enfocar la lectura de los flujos en el caso de uso: ya que todo este nivel de detalle no se encuentra dentro de cada paso en los flujos, sino que simplemente se hace una referencia.
2. Centralización del detalle: por ejemplo el paso que explica que el sistema visualiza los datos de una persona para ser cargados, tomaría la primera columna de las tablas de arriba; el paso que indica la validación de los datos tomaría las columnas “Tipo de Dato” y “Validaciones y Otras Reglas”; pero a la hora de que el lector necesite validar si todo esto es correcto, enfoca su atención a la tabla y lo tiene todo en un mismo lugar.
3. Reutilización de la información: Se puede hacer referencia a la misma tabla en el paso de visualizar datos por el sistema, actualizar datos por el actor y validar los datos del sistema teniendo en cuenta el punto anterior

Martin Langlands también hace referencia a dos temas muy importantes a la hora de usar un PROPERTY LIST:

1. El uso del patrón UBIQUITOUS LANGUAGE de Eric Evans, que habla de utilizar un lenguaje que no sea técnico, sino más bien conocido por los usuarios y,
2. Que a parte de estas tablas, que estarían fuera de los flujos pero dentro del caso de uso, deberá existir otro documento, por ejemplo un diccionario de datos, en donde se escriba la información común de todas las propiedades de los objetos del sistema. Esto es porque finalmente habrá información propia de las propiedades de los objetos que no varíen entre distintos casos de uso. Por ejemplo, la explicación sobre el significado de un campo específico, como por ejemplo el nombre de una persona. Este nombre de persona, será siempre el nombre de la persona, no valdría la pena poner esta descripción en esta lista de propiedades que se encuentran dentro de los casos de uso, sino más bien en un documento central.

Opinión Personal

La experiencia en análisis y desarrollo de software me ha mostrado que la documentación que permita visualizar los requerimientos y funciones a más alto nivel, ayuda más que la documentación detallada escrita con una gran cantidad de texto. Siempre me han resultado más útiles los diagramas de estados, diagramas de actividades, prototipos de pantallas, Flujogramas, etc; Esto ya que a la hora de discutir detalles con el usuario, es más difícil hacer que se ponga a leer párrafos y párrafos de textos.

La posibilidad de abstraer al usuario del detalle de las propiedades de los objetos que estamos tratando en los casos de uso por medio del patrón PROPERTY LIST, y la centralización de estos datos en forma tabular, ayudan en gran manera a mantener casos de uso cortos y fáciles de entender, logrando con esto, hacer que a los usuarios les sea más fácil mantenerse enfocados a la hora de las discusiones con los analistas y, al mismo tiempo, lograr que el analista mantenga el nivel de detalle apropiado en la documentación para las etapas posteriores.

Finalmente cierro este artículo, abriendo los comentarios para que puedan opinar y comentar ejemplos de listas de propiedades que salgan del estándar utilizado en este articulo.

Referencias

Langlands, M. (2013). Inside The Oval : Use-Case Content Patterns (versión 2.0), páginas 21 al 25. Link alternativo: descargar

[sc name=»posts_use_cases_patterns» ][/sc]