Archive for the ‘ Análisis y Diseño ’ Category

Patrones de Casos de Uso 4/9 – Known Object

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

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. Leer mas

Patrones de Casos de Uso 3/9 – Property List

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Ya hemos visto dos artículos sobre Patrones de Contenido de Casos de Uso 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 que 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.

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. Leer mas

Patrones de Casos de Uso 2/9 – Object Manager

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

En el artículo anterior hemos visto una introducción a los patrones de contenido de casos de uso presentados por Martin Langlands. Ya vimos brevemente explicados los patrones, por lo tanto a partir de este artículo, comenzaremos a verlos uno por uno, haciendo también algunas traducciones del paper original  para mantener la idea de Langlands y dando mi opinión al respecto. Los patrones no serán explicados en el mismo orden que Langlands los presenta en su paper, sino que iré escribiendo los artículos desde otra perspectiva.

El primer patrón que me gustaría tratar es el OBJECT MANAGER. Este patrón, de alguna manera, agrupa a los demás patrones presentados por Langlands, y hay que recordar que estos patrones tratan sobre el contenido de los casos de uso y no así a cómo estructurarlos (lo que sería el concepto descrito en el paper como “Inside the Oval”). Sin embargo, este es el único patrón que trata más bien sobre como organizar los patrones de contenido presentados.

Por lo general, cuando hablamos de sistemas, hablamos de trabajar con una base de datos o alguna forma de almacenamiento de datos. Durante la etapa de análisis, cada objeto que tiene la capacidad de persistir sus propiedades en una base de datos es conocido como una entidad, y este tipo de objetos son con los que más lidiamos a la hora de la descripción de casos de uso.

De esta manera, hablamos de los CRUDs o ABMs que nos permiten “administrar” o “gestionar” las entidades. Estos dos términos son muy utilizados a la hora de modelar casos de uso, es más, personalmente creo que son los que más retrasan el modelado, no por ser complicados, sino porque no se tiene un criterio uniforme para modelarlos y describirlos. Con este patrón, Langlands comenta que “cada uno de estos tipo de objetos (entidades), necesitan generalmente un conjunto de casos de uso para que los usuarios puedan administrar las instancias a través de su ciclo de vida.”, y hace referencia en que encuentra las siguientes funciones:

  1. Crear nuevas instancias. Patrón: BASIC CREATOR
  2. Buscar instancias, pudiendo utilizar varios criterios para encontrarlas. Patrón: CRITERIA SEARCH
  3. Visualizar los detalles o datos de una instancia específica y opcionalmente modificarla. Patrón: VIEWER/UPDATER
  4. Seleccionar instancias de objetos para utilizarlos en otro contexto, como por ejemplo, seleccionar la ciudad de una persona a la hora de querer crear la persona. Patrón: SELECTOR
  5. Eliminar instancias que ya no son útiles para el sistema. Patrón: DESTRUCTOR

Leer mas

Patrones de Casos de Uso 1/9 – Introducción

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Es sabido que el mayor porcentaje de esfuerzo para el desarrollo de software se encuentra en las etapas más tempranas del ciclo de vida del mismo. Desde la etapa de relevamiento de requerimientos hasta la etapa de inicio del desarrollo, existe un momento crucial que puede garantizar el éxito o fracaso de un proyecto de software.

Durante las etapas de Análisis y Diseño de los sistemas, se proveen entregables que en la actualidad son tomados muy a la ligera. La documentación deja marcada la idea del software, sus necesidades y sus funcionalidades. Entre estas documentaciones se tienen muchas preguntas sin contestar especialmente con los Casos de Uso.

Aunque existen estándares de codificación para la etapa de desarrollo e inclusive patrones de diseño que ayudan enormemente a marcar la forma de comportamiento y estructura en el código, uno de los principales problemas viene dado por las preguntas ¿cómo realizar correctamente la documentación de los Casos de Uso? y si ¿Existe una manera estandarizada para este tipo de documentación?

Para este tema, escribí un ensayo para la maestría que estoy cursando sobre “La importancia de la estandarización de los Casos de Uso por medio de Patrones”. Esta investigación, después de buscar muchísimo y leer bastante, me llevó a encontrar uno de los mejores artículos que pude leer sobre este tema. El artículo fue escrito por Martin Langlands , y tomando en cuenta el arduo trabajo de investigación, este ensayo será entonces la punta pie inicial para una serie de artículos que quiero escribir sobre estos patrones. Recomiendo ampliamente la lectura del artículo original que se puede encontrar al final de este artículo. A continuación el texto del ensayo. Leer mas

Parametrizando nuestro sistema con symfony 2/2

VN:F [1.9.22_1171]
Rating: 4.0/5 (4 votes cast)

Continúo con lo prometido de seguir con el artículo Parametrizando nuestro sistema con symfony con este segundo artículo sobre esta serie. Aquí veremos como implementar con Symfony unos métodos que nos hagan un poco más sencillo el desarrollo de una aplicación parametrizada.

Habíamos visto en el artículo anterior que podríamos trabajar creando una tabla en la que centralicemos los parámetros de nuestra aplicación según dos puntos importantes.

  1. Cantidad de registros : Si la cantidad de registros es relativamente fija y no crecen tan variablemente como son las tablas transaccionales.
  2. Cantidad de columnas: Si estas tablas tienen exactamente 2 columnas como generalmente serían id y nombre.

De esta manera lograríamos no tener tantas tablas que simplemente las usamos como parámetro y hacer nuestra aplicación mucho mas fácil de mantener.

En éste artículo veremos como manipular los datos de la tabla parámetro de una forma en la que no necesitemos mucha conversación con la base de datos.

Leer mas

Parametrizando nuestro sistema con symfony 1/2

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Mucho se habla hoy en día de que un sistema parametrizado es mucho mejor que los famosos “códigos en duro” que los programadores solemos escribir dentro del fuente de los programas. Es muy normal ver gente que usa combos de selección múltiple que en realidad van cargados dentro del mismo HTML de la página. El problema ocurre realmente cuando hacemos esto con varias páginas y luego resulta muy engorroso el mantenimiento del sitio ya que hay que buscar todos los lugares en donde lo hicimos a la hora de agregar, quitar o modificar alguna de las opciones de nuestro combo.

Mucha gente acostumbra crear tablas paramétricas para por ejemplo “estados”, “paises”, “tipos”, etc. Considero, y es una opinión muy personal, que cuando estas tablas son creadas habría que analizar 2 puntos a fin de determinar si las mismas podrían ir dentro de la estructura que voy a proponer con este artículo.

  1. Cantidad de registros : Si la cantidad de registros es relativamente fija y no crecen tan variablemente como son las tablas transaccionales.
  2. Cantidad de columnas: Si éstas tablas tienen exactamente 2 columnas como generalmente serían id y nombre.

Cabe mencionar que creando tablas como las descriptas arriba vemos un crecimiento muy grande en el número de tablas de la base de datos y por supuesto un Diagrama Entidad Relación (DER – ER) muy complejo para graficar ya que la mayoría de las tablas suelen ser de este tipo.

Tomando en cuenta esto, propongo que trabajemos con una tabla a la cual denominaremos “parametro” y con la ayuda de Symfony y los artículos de la serie Personalizando el objeto sfUser de Symfony veremos como centralizar los datos paramétricos dentro de un solo lugar y los almacenaremos dentro de la sesión del usuario activo del sistema.

Leer mas