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

Android – Styles & Themes

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

AndroidHace ya un tiempo que comencé a investigar sobre programación para Android y de toda la información que leí encontré realmente muy poco sobre creación de themes propios para una aplicación. En la documentación oficial se llega a entender bien la parte correspondiente a estilos pero cuando comienza la parte de themes se queda muy corta y al parecer la única manera de aprender es meterse por todos los archivos fuentes de las distintas plataformas de Android y comenzar a ver como lo utilizan para los themes estándares (Theme.Holo, Theme.Holo.Light, Theme.Holo.Light.DarkActionBar).

Después de horas y horas intentando entender los archivos XML haciendo pruebas y cometiendo errores puedo concluir en que realmente sería mucho más sencillo si la documentación oficial explicara al menos lo que voy a intentar explicar en este artículo ya que una vez que se entiende resulta relativamente sencillo. De todas maneras como fanático de Google, entiendo que Android crece días tras día un poco más y confío en que dentro de poco tiempo vayan actualizando la documentación haciéndonos la vida un poco más fácil.

Antes de seguir leyendo te recomiendo que le des una leída a la documentación oficial de Android. Leer mas

Concurso de la WSA Paraguay – Aplicación Android

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

Premio WSAEn las últimas semanas estuve trabajando con una aplicación Android para la Dirección Nacional de Contrataciones Públicas (DNCP) de Paraguay (mi país para los que no lo sepan).

La DNCP se encarga de realizar las verificaciones, controles y publicaciones de los llamados a licitación del país lo cual se maneja por medio del Sistema de Información de las Contrataciones Públicas (SICP: www.contrataciones.gov.py). Para dar una herramienta útil para personas que se mantienen siempre conectadas con la tecnología y en especial personas que trabajan con el Estado, desarrollé esta aplicación que fue presentada en el concurso de la World Summit Award organizado en el país por la empresa Personal de telefonía celular.

La aplicación participó dentro de la categoría m-Government & Participation y ha salido ganadora con un premio en efectivo, pero lo más importante como una muestra de que en el Estado también se pueden tener ideas y la tecnología para lograrlas.

 

Descripción de la aplicación

Sicp.py es la aplicación oficial android del portal de Contrataciones Públicas del Paraguay.

Objetivo principal: Facilitar a los proveedores o potenciales oferentes del estado de una herramienta para poder acceder diariamente a los llamados, de las diferentes modalidades de compra, publicados en el Sistema de Información de las Contrataciones Públicas de la República del Paraguay. Además de eso, los usuarios tendrán la posibilidad de recibir alertas de las modificaciones en los llamados en los cuales se encuentren interesados.

Objetivo secundario: Servir de ayuda a los encargados de las instituciones o cualquier persona que quiera hacer seguimiento de llamados a licitación

Leer mas

Servicios REST usando Silex micro-framework 3/3 – Cliente

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

Ya hace un tiempo que escribí el primer y segundo artículo de esta serie sobre Servicios REST y Silex. En esa época había creado un repositorio en mi cuenta de GitHub para almacenar un ejemplo de como crear un servidor REST utilizando Silex el micro-framework PHP que sería como el hermano menor de Symfony.

Utilizo Silex porque es realmente fácil crear rápidamente un proyecto de ejemplo pero en realidad de expone la idea para utilizarlo con PHP, pudiéndose adaptar rápidamente el ejemplo a algún otro framework como Symfony2 o incluso hacerlo desde cero con PHP.

Con ayuda de algunas personas, a quienes agradezco por los comentarios que dejaron en los artículos, he realizado algunas modificaciones y creo que nos ha quedado un proyecto base interesante para tenerlo como estructura base.

Hay que tener en cuenta que hoy en día la nueva versión de Silex ha cambiado un poco en cuento a su instalación con relación al último artículo. Utilizaremos para este artículo la nueva versión y con el tiempo haremos las modificaciones en el ejemplo del servidor.

Hoy quiero hablar sobre como podemos consumir ese servicio creado, es decir, crear un cliente para REST utilizando Silex. Hay que recordar que nuestro servicio REST nos devuelve siempre respuestas por medio de los códigos de estados del protocolo HTTP (puedes verlo en la wiki) y en los casos que tiene que devolvernos datos como sería la ruta /ver-comentarios.json, lo hará utilizando el formato JSON. Esto es importante saber ya que para que nuestro cliente obtenga los comentarios del ejemplo tenemos que saber que obtendremos una respuesta JSON la cual tendremos que procesar para mostrarlo en nuestro cliente.

Leer mas