Continuando con la serie de artículos sobre Patrones de Casos de Uso, hoy quiero hablar sobre el patrón KNOWN OBJECT, creado por Martin Langlands. Este patrón forma parte de la lista de Patrones del Contenido de Casos de Uso presentados en el paper del autor antes mencionado, y es más bien un concepto muy sencillo pero muy importante a la hora de describir este tipo de documentaciones.
Existen casos de uso que son directamente invocados por un actor, como por ejemplo los que utilizan patrones como BASIC CREATOR o CRITERIA SEARCH. Estos tipos de casos de uso pueden ser invocados directamente porque no necesitan como pre-requisito una instancia de un objeto existente. Es decir, cuando vamos a crear un objeto, el objeto todavía no existe y cuando lo buscamos, la idea es encontrar una instancia. Por otro lado, existen casos de uso que necesitan de una instancia de un objeto ya existente como para iniciar los flujos, como serían los casos de uso para visualizar un registro, modificarlo o incluso cambiar de estado, lo que es muy común.
Como ejemplo, imaginemos un buscador de personas. Una vez encontrados los registros (objetos) que buscamos, nos dará la posibilidad de realizar acciones sobre ellos. Cada acción, utilizando la idea del patrón OBJECT MANAGER, podrá incluir un caso de uso que ejecute lo necesario. Estos casos de uso que son incluidos son lo que deberán conocer el objeto con el cual trabajar. Así por ejemplo, podemos tomar el caso de visualizar los datos de la persona, modificar sus datos, activar a la persona o inactivarla. Cuatro casos de uso que necesitan, como pre-requisito, saber sobre cuál persona deben realizar sus acciones.
A los casos de uso por los cuales se identifican los objetos, Langlands los denomina “Casos de Uso Identificadores” y a los que ejecutan las acciones sobre un objeto conocido “Casos de Uso Actores”.
La idea del patrón KNOWN OBJECT, es determinar que los “Casos de Uso Actores”, se describan tomando en cuenta que ya existe un objeto conocido, de ahí el nombre del patrón, y no contar con la necesidad de explicar como se obtiene este objeto, ya que puede ser obtenido desde distintos casos de uso. Por lo tanto, la simpleza de este patrón está dado por dos cosas:
- En el caso de uso que identifica el objeto, en el paso correspondiente dentro del flujo que necesita hacer el << include >> de las acciones, se debería hacer referencia a que se realiza la acción, invocando a otro caso de uso específico, utilizando como Context Object (objeto en cuestión) al objeto seleccionado.
- En el caso de uso que ejecuta las acciones, se le puede agregar una sección antes del Flujo Básico en donde indique cuál es el Context Object para ese caso de uso.
Abajo podemos ver una imagen del paper de Martin Langlands mostrando un ejemplo sobre una Biblioteca de Músicas:
Opinión Personal
Así como comenté al inicio de este artículo, el patrón KNOWN OBJECT es un concepto muy sencillo a la hora de implementarlo, pero sin embargo, marca la idea de conocer el objeto con el cual trabajamos en un caso de uso. Gracias a este concepto, ya no es necesario pensar si debemos incluir dentro de un “Caso de Uso Actor” la forma a la que llegamos a ese objeto.
Considero que en los casos de uso que invocan a los demás, la idea de especificar que se invoca a tal caso de uso utilizando el objeto seleccionado es muy útil, ahora bien, lo que no se es si es tan necesario declarar el Context Object dentro de los demás. Quizás utilizando un nombre entendible para el caso de uso esto pueda dejarse de lado.
También me queda en el tintero la mejor forma de traducir la frase “Context Object”, ya que traduciéndolo como “Objeto de Contexto” no estoy muy seguro de que sea una frase que los usuarios puedan entender con solo leerla. De todas formas, dejo esta idea para recibir sus comentarios.
Referencias
- Langlands, M. (2013). Inside The Oval : Use-Case Content Patterns (versión 2.0), páginas 46 al 47. Link alternativo: descargar
Descubre más desde Neurosimbiosis
Suscríbete y recibe las últimas entradas en tu correo electrónico.