< BLOG.H >:

Error: Clase No Registrada.

2011-07-08T12:37:00.000-07:00

Tenía un proyecto en .NET que en una máquina compilaba y corría sin problemas. Pero al querer pasar el proyecto a otra máquina, luego de compilar, me aparecía la siguiente excepción:

Clase no registrada (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

La solución es simple: además de agregar las referencias al proyecto, debemos hacer click derecho (desde un adminsitrador de archivos) en los archivos DLLs que hemos referenciado, y luego click en "Registrar".

Con eso se soluciona el problema.

S2

Programación Orientada a Aspectos. Implementando un Aspecto. (Parte 3)

2011-04-22T17:22:00.000-07:00

En la parte 2 planteamos una situación utópica: que una clase realizara algo sin indicarle que lo hiciera. Bueno, sí, eso es utópico. Pero, podemos pensar en otra "entidad" que se encargue de realizar esa tarea (en nuestro caso es registrar un movimiento) detectando el momento preciso en el que debe realizarla. Es decir, tener "algo" que sepa cuando registrar un movimiento, pero que ese "algo" no tenga nada que ver con la clase Cuenta. Ese algo, es lo que llamamos aspecto. Un aspecto, entonces, es algo que entrecruza una o más clases. Dicho de otra forma, un aspecto es un concepto que ofrece funcionalidad transversal a los objetos del negocio.

Imaginémoslo como algo que vigila un programa a medida que este se ejecuta; y a partir de ciertas acciones que se producen en el programa, este algo realiza acciones propias de él. Llamemos a este algo "aspecto". Podemos decirle a un aspecto, que cuando se termine de ejecutar cualquier método que comience con la palabra "hacer" realice un registro de movimiento. La clase Cuenta de nuestro ejemplo, no se enteraría jamás de la existencia de este aspecto, pero este aspecto está atento a las ejecuciones hacerAlgo...() de esa clase.

Vamos a definir rápidamente este aspecto para poder visualizar mejor lo que estamos tratando de decir. Para poder escribir un aspecto y compilar el programa con este aspecto, es necesario tener instalado el plugin de AspectJ en el editor de Java que estemos usando, o poder compilar configurando el editor. Bueno, pasemos a definir el aspecto de una vez. Agregamos un nuevo archivo con extensión .aj (por "AspectJ") al proyecto:

public aspect RegistroDeMovimientos {

   after():execution (public * hacer*(..)) {
       Date hora = new Date();           
       SimpleDateFormat formatoDeFecha = new SimpleDateFormat("yyyy.MM.dd G 'at' HH:mm:ss");
       System.out.println("Movimiento realizado a las " + formatoDeFecha.format(hora)) ;
   }
}

Observemos este código. Lo primero que vemos, es la declaración del aspecto bajo el nombre de RegistroDeMovimientos. Por ende, al igual que las clases de Java, el archivo del aspecto debe llamarse RegistroDeMovimientos.aj. Si seguimos vemos la linea que dice:

after():execution (public * hacer*(..)) {

Esta línea es clave para definir unos conceptos que explicaré más adelante. Pero por el momento, analizaremos de manera simple qué significa. Si tuviera que decirlo en lenguaje informal, la describiría asi: "Después de la ejecución de cualquier método público, sin importar el tipo que retorne, que comience con hacer, y sin importar la cantidad y tipo de parámetros que requiera, hacer lo siguiente:". Eso significaría mas o menos. Ahora examinemos lo que significa cada parte:

after(): Esto indica que el cuerpo se ejecutará después de algo. Ahora veamos ese algo.
execution ( ): esto significa que se toma como referencia una ejecución de lo que sigue:
public * hacer*(..): public nos indica que se buscará un método público cualquiera. El asterisco que sigue, indica que ademas no importa el tipo que retorna el método. hacer* significa que el nombre del método debe comenzar con la palabra "hacer" y no importa cómo termine (para eso está el asterisco luego de "hacer"). Y finalmente, los dos puntos entre paréntesis significa que no importa ni el tipo ni la cantidad de parámetros del método.

Entonces, revisemos la descripción informal del método: "Después dela ejecución de cualquier método que sea público, que retorne cualquier tipo de dato, que comience con "hacer" y sin importar el tipo y cantidad de parámetros", se debe ejecutar lo que se indica en el cuerpo. El cuerpo es muy simple: no es mas que aquello que hacía el método RegistrarMovimiento() que hicimos antes. Esto es un aspecto. Simple, ¿no? El aspecto, se encargará de ejecutar ese cuerpo de código cada vez que ocurra esa descripción informal.

Con esto, hemos solucionado el problema del apartado anterior. ¿Por qué? Porque hemos logrado aislar el comportamiento de registrar un movimiento, de forma tal que la clase Cuenta no conoce de su existencia. Por lo tanto, no hemos tenido que repetir ningún código dentro de la clase, y además, al aislar ese comportamiento en un sólo aspecto, este se hace más fácilmente mantenible, ya que si queremos modificar la forma en que se registran los movimientos sólo debemos modificar el cuerpo de ejecución del aspecto, y no preocuparnos por las clases del negocio.

Por supuesto, para compilar aspectos, no podemos usar el compilador de java, para eso usamos el compilador AspectJ que lo que hace es armar un código complementando el código base con el código de aspectos. Una vez que esta herramienta genera el código final, ahí si se puede correr sobre la máquina virtual de java.

Programación Orientada a Aspectos. ¿Por qué usar POA? (Parte 2)

2011-04-20T06:28:00.000-07:00

En la parte 1, di una introducción a lo que es la programación orientada a aspectos de una forma bastante teórica. En esta segunda parte, voy a mostrar un ejemplo práctico muy simplificado para poder asentar un poco más el concepto. Para el ejemplo utilicé el lenguaje Java, y la extensión del lenguaje Java que implementa aspectos AspectJ. Ya he contado como compilar con AspectJ en NetBeans.

Bueno, ¿en qué consiste la POA? Voy a poner un ejemplo muy fácil que ilustra el potencial que nos ofrece la POA Supongamos una aplicación de transacciones bancarias. (Este es el típico ejemplo que se menciona en todos lados, y lo voy a poner en mi versión porque es muy ilustrativo).

Vamos a tener una clase cuyo nombre es Cuenta y es una versión muy simplificada de una cuenta de un banco. Esta clase, tiene un atributo llamado saldo de tipo Double que indica el saldo en la cuenta. Y vamos a tener tres métodos: Uno que llamado hacerDeposito() con un único parámetro de tipo Double que indica la cantidad a depositar en la cuenta. Otro llamado hacerExtraccion() que cuenta con un solo parámetro que indica la cantidad de dinero que se quiere extraer de la cuenta. El método restante se llama hacerTransferencia() y tiene dos parámetros: uno indica la cantidad de dinero y el otro es la cuenta a la que se quiere hacer la transferencia. Además tendremos una típica -y muy simplificada- clase que representa un cliente del supuesto "banco" llamada Cliente. Para seguir simplificando (cosa que se me está haciendo mala costumbre ya) un cliente sólo puede tener una cuenta. Ilustremos con UML:

A continuación, les muestro un ejemplo en java bien simple. Lo que haré en el método Main() será crear dos clientes (Pepe y Juan) y crear una cuenta para cada uno. Después, le asignaré a Pepe una cuenta y a Juan la otra. Finalmente, haré una extracción de la cuenta de Pepe; y -felizmente para Juan- terminaré con una transferencia de dinero de la cuenta de Pepe a la de Juan. Aunque lo que realiza el método Main(), por el momento no nos interesa. Veamos el código de ambas clases (sin los getter y los setters porque son muy triviales).

Veamos la definición de los métodos hacer...() de la clase Cuenta:

public void hacerDeposito(Double cantidad) {
 if(cantidad <= 0) {
     System.out.println("No hay dinero suficiente para hacer el depósito");
 }
 else {         
     Date hora = new Date();         
     SimpleDateFormat formatoDeFecha = new SimpleDateFormat("yyyy.MM.dd G 'at' HH:mm:ss");         
     //Realizamos el depósito
     this.saldo += cantidad;         
     //Registramos el movmiento
     System.out.println("Movimiento realizado a las " + formatoDeFecha.format(hora)) ;         
 }
}

public void hacerTransferencia(Double cantidad, Cuenta cuentaDestino)
{
 if(this.saldo < cantidad) {
     System.out.println("No hay fondos suficientes para la transferencia.");         
 }
 else {
     Date hora = new Date();         
     SimpleDateFormat formatoDeFecha = new SimpleDateFormat("yyyy.MM.dd G 'at' HH:mm:ss");        
     cuentaDestino.hacerDeposito(cantidad);
     this.saldo -= cantidad;
     //Registramos el movmiento
     System.out.println("Movimiento realizado a las " + formatoDeFecha.format(hora)) ;
 }
}

public void hacerExtraccion(Double cantidad) {

 if(this.saldo < cantidad) {
     System.out.println("No hay fondos suficientes para la extracción.");         
 }
 else {         
     Date hora = new Date();         
     SimpleDateFormat formatoDeFecha = new SimpleDateFormat("yyyy.MM.dd G 'at' HH:mm:ss");         
     //Extraemos la cantidad del saldode la cuenta.
     this.saldo -= cantidad;         
     //Registramos el movmiento
     System.out.println("Movimiento realizado a las " + formatoDeFecha.format(hora)) ;
 }
}

Examinemos un poco el código: en todos métodos comenzamos con una verificación de la cantidad que se quiere extraer, depositar o transferir. Esta verificación es necesaria, ya que ciertamente sería un error, por ejemplo, depositar una cantidad negativa de dinero de una cuenta; también sería un error permitir una extracción de más cantidad de dinero de la que se dispone. Estas situaciones deben evitarse si o si.

Por otra parte, vemos que una vez que se comprueban las cantidades y que esta todo bien, se procede a realizar el deposito o la extracción o la transferencia (según sea el caso). Pero para esto, he supuesto (a modo de regla de negocio) que el banco necesita tener un registro (logging) de cada movimiento realizado en cada cuenta. Por eso es que creé una variable llamada hora y la mostré en pantalla. Lo más común no es mostrarlo en pantalla sino almacenarlo en un archivo de logs, pero lo hice así por practicidad.

Lo interesante, curioso, y que tenemos que tener en cuenta de estos métodos, es que los tres repiten el proceso de registrar un movimiento. Y no solo eso, sino que además se hace en los tres métodos de la misma forma! Lo cual es una muy mala práctica. Nunca debería repetirse código, eso lo sabemos bien. Entonces, he aquí un problema. ¿Cómo lo solucionamos?...

Algún iluminado podría indicar hacer lo siguiente: Creamos un cuarto método dentro de la clase al que podríamos llamar registrarMovimiento(). Este método se encargaría sólo de la parte del registro del movimiento; y cada uno de los anteriores tres métodos lo llama cuando ha concluido un movimiento. Genial. Veamos cómo quedaría registrarMovimiento():

private void registrarMovimiento()
{
 Date hora = new Date();         
 SimpleDateFormat formatoDeFecha = new SimpleDateFormat("yyyy.MM.dd G 'at' HH:mm:ss");         
 System.out.println("Movimiento realizado a las " + formatoDeFecha.format(hora)) ;
}

Y ahora, el código de los otros tres métodos se modifica para llamar a registrarMovimiento() quedando así (sólo mostramos dos, pero el tercero seguiría la misma lógica que éstos):

public void hacerTransferencia(Double cantidad, Cuenta cuentaDestino)
{
 if(this.saldo < cantidad) {
     System.out.println("No hay fondos suficientes para la transferencia.");         
 }
 else {
     cuentaDestino.hacerDeposito(cantidad);
     this.saldo -= cantidad;
     //Registramos el movmiento
     registrarMovimiento();
 }
}

public void hacerExtraccion(Double cantidad) {

 if(this.saldo < cantidad) {
     System.out.println("No hay fondos suficientes para la extracción.");         
 }
 else {
     //Extraemos la cantidad del saldode la cuenta.
     this.saldo -= cantidad;         
     //Registramos el movmiento
     registrarMovimiento();         
 }
}

Pero lo malo de esta solución, es que si se efectuara otro movimiento que no fuera "dentro" de la clase Cuenta sino "dentro" de otra clase, esta clase tendría que tener su propio método registrarMovimiento(), y nuevamente estaríamos repitiendo código, pero entre clases. Ante este nuevo problema, podemos proponer otra solución: creamos una clase que se encargue específicamente de registrar movimientos; y cualquier método de cualquier clase puede instanciarla y llamar al método que registra movimientos. Podríamos, por ejemplo, crear una clase llamada RegistroDeMovimientos con un método público llamado registrarMovimiento(). Parece que esta es la mejor solución. Sin embargo no es así. Sigue habiendo "algo malo". ¿Qué es?...

Está claro: aunque tengamos una clase aparte que registre los movimientos, cada clase debe instanciar y llamar al método de esa clase. Es decir, seguimos repitiendo código. Cada método que deba registrar un movimiento, debe repetir el mismo código que los otros métodos que también deban registrar un movimiento. ¡Que feo! ¡Y no solo eso! Además, el hecho de registrar un movimiento -ya sea dentro del mismo método o llamando a RegistroDeMovimientos.registrarMovimiento()- significa introducir código que no pertenece exclusivamente al movimiento. El movimiento sólo debería realizar el movimiento y nada más. El registro debería hacerse aparte, no debería ser responsabilidad de un depósito, o una extracción o una transferencia. Esta forma de registrar un movimiento, ensucia el código que se refiere a los métodos de la clase Cuenta. Es decir, lo ideal sería que estos métodos se vieran así:

public void hacerDeposito(Double cantidad) {
 if(cantidad <= 0) {
     System.out.println("No hay dinero suficiente para hacer el depósito");
 }
 else { 
     this.saldo += cantidad;
 }
}

public void hacerTransferencia(Double cantidad, Cuenta cuentaDestino)
{
 if(this.saldo < cantidad) {
     System.out.println("No hay fondos suficientes para la transferencia.");         
 }
 else {
     cuentaDestino.hacerDeposito(cantidad);
     this.saldo -= cantidad;
 }
}

public void hacerExtraccion(Double cantidad) {

 if(this.saldo < cantidad) {
     System.out.println("No hay fondos suficientes para la extracción.");         
 }
 else {
     this.saldo -= cantidad;
 }
}

Como dije, sería ideal que a pesar de no llamar a registrarMevimiento(), el movimiento se registrara igual. Eso sería ideal, ¿no? No ensuciaríamos código y tampoco lo repetiríamos. La clase sería tremendamente cohesiva. Parece utópico ¿verdad? Bueno, para nuestra felicidad, esto es realizable y es acá donde entran en juego los "aspectos".

En la tercer parte, voy a mostrar cómo implementar un aspecto que solucione el problema planteado.

Programación Orientada a Aspectos. ¿Qué es? (Parte 1)

2011-04-15T06:58:00.000-07:00

Para explicar la programación orientada a aspectos, quizás lo ideal sería comenzar con una breve descripción de la historia de la ingeniería de software, como lo hacen la mayoría de los artículos o PDFs que podemos encontrar en la web, pero como justamente la mayoría lo hace así, yo no. Quien quiera verlo así, busque en la web el tema y ahí van a tener mucho para leer (y no está demás). Pero yo prefiero comenzar yendo al grano.

La programación orientada a objetos trata la manera de modularizar "conceptos comunes" de software. Sin embargo, existen otros conceptos o asuntos que se extienden a lo largo de estos "conceptos comunes" y que no pueden ser modularizados con el diseño orientado a objetos. En un intento más de subsanar lo que la orientación a objetos no puede, aparece una nueva solución: la Programación Orientada a Aspectos (y su consecuente Diseño Orientado a Aspectos).

La programación orientada a aspectos se ha planteado como un nuevo paradigma de programación (con lo que no estoy de acuerdo), el cual consiste en separar los conceptos que entrecruzan varias clases y se extienden a lo largo de éstas, pero que no pertenecen a esas clase en sí mismas. Incluso, los conceptos pueden aparecer no sólo en varias clases, sino de una sola. Ahora la pregunta: ¿de qué tipo de conceptos hablamos? Pensemos como ejemplo, en una aplicación que requiere del registro (logging) de las acciones que realiza. Bien, estos registros "alguien" tiene que llevarlos a cabo, y es normal cargar a muchas clases con la responsabilidad de hacerlo cuando, seguramente, no sea la función principal de esas clases hacer dicha tarea. Como vemos, se trata de una misma funcionalidad (registrar acciones) que se encuentra entrecruzada en varias clases, pero que a la vez no es parte de ninguna.

Otro ejemplo, simple de entender, es el manejo de errores. Los errores hay que tratarlos sí o si en una aplicación. Pero, desde un punto de vista "purista" de objetos, no tenemos clases que traten los errores por sí solos. Siempre las clases que definen la funcionalidad de la aplicación van a tener que lidiar con los errores, y esa no es su función principal. En cierta forma, esto hace a dichas clases menos cohesivas. Un tercer ejemplo puede ser el manejo de la sincronización. Nuevamente, los objetos del negocio deben tratar la sincronización además de su función principal.

En todo los ejemplos estamos viendo que hay ciertos asuntos que no pertenecen al negocio pero que sin embargo, deben ser tratados. Y lo negativo de esto, es que según el paradigma de objetos, son los objetos del negocio quienes deben tratar estos asuntos y, como si fura poco que hagan tareas que no les corresponden, estas tareas se esparcen a lo largo de toda la aplicación, llevando a dispersar código y enredarlo por la misma (a esto último se llama Code Tangling y Code Scattering).

Entonces, para darle más sentido a la POA, veamos en qué se afecta el desarrollo de aplicaciones cuando surgen estos asuntos:

Baja cohesión: las clases realizan tareas que no le corresponden específicamente a ellas.
Baja reusabilidad: Cuando una clase trata un asunto que no le corresponde, esta clase probablemente sea difícil de re usar en otro sistema.
Peor calidad de código: El código se complica, y cuesta más entenderlo y mantenerlo.
Evolución dificultosa: Se vuelve más costoso que el sistema evoluciones al tener código disperso y enredado por toda la aplicación.

Estos asuntos son denominados "conceptos transversales". La POA viene para tratar de separar y encapsularlos en una aplicación y aislarlos para independizar a los objetos del negocio de éstos conceptos. Este aislamiento se encapsula en "aspectos".

Por lo tanto, la POA permite la separación de conceptos transversales a través de mecanismos que permiten abstraer y encapsular estos conceptos en un sistema. Un aspecto es la unidad que encapsula uno o más conceptos transversales, y que con la programación orientada a objetos no es posible diferenciarlo de forma clara.

La definición actual de aspecto dice: "Un aspecto es una unidad modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de programa o de código es una unidad modular del programa que aparece en otras unidades modulares del programa.”

La principal ventaja de la POA es que permite tratar la funcionalidad pura por un lado, y los aspectos por otro, de forma separada. Luego ambos se combinan con un tipo de programa llamado 'Weaver') para dar por resultado el sistema final.

Hay mucho más por hablar de POA aún. En la próxima parte (parte 2), voy a mostrar un ejemplo muy claro, para asentar toda esta teoría en algo más palpable, así que a no abandonar si esta pequeña introducción a resultado medio difícil de entender, en el ejemplo de la Parte 2 quedará muy claro de que se trata.

Instalar AspectJ en NetBeans 6.9.1

2011-04-12T14:13:00.000-07:00

English version

Hola. Finalmene, después de horas de intentos, logré copilar AspectJ en NetBeans 6.9.1.
Ahora les muestro la forma de hacerlo. Pero quiero aclarar que no voy a instalar un plug-in de netbeans, sino que voy a mostrar la forma de compilar aspectos en netbeans con AspectJ. Veamos los pasos:

1) Descargar la última versión estable de AspectJ en este sitio.
2) Descomprimir el archivo ".jar" en algún directorio donde pongan librerías. No debería ser en el directorio de librerías del proyecto, ya que quizás quieras usar esta librería en otros proyectos.
3) Crear un proyecto en netbeans, basta con un simple "Java Project".

Ahora, los próximos pasos deben seguirlos en cada nuevo proyecto que hagan:

4) Ir a las propiedades del proyecto, y en el panel de "librerias", seleccionar "Add Jar/Folder". Ahora, seleccionar los siguientes archivos del archivo descomprimido:

aspectjrt.jar
aspectjtools.jar
org.aspectj.matcher.jar

5)Una vez que se agregaron estos archivos, hay que editar el archivo build.xml creado en el directorio del proyecto.
6) Entre los tags <project> y </project> pegar el siguiente código:


<taskdef classpath="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjtools.jar"
     resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties"/>

<target name="aspectj">
  <echo level="info">--- aspectj (start) ---</echo>  
  <iajc destDir="${build.classes.dir}">
      <inpath>
        <pathelement location="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjrt.jar"/>
        <pathelement location="${build.classes.dir}" />
      </inpath>
 <sourceroots>
  <pathelement location="${src.dir}"/>
 </sourceroots>
 <classpath>
  <pathelement location="${javac.classpath}"/>
  <pathelement location="${j2ee.platform.classpath}"/>
 </classpath>
  </iajc> 
  <echo level="info">--- build.xml by Ignacio Rigoni email: {name}.{lastname}@gmail.com ---</echo>
</target>

<target name="-post-compile" depends="aspectj"></target>

De forma tal que el archivo build.xml les quede así:


<?xml version="1.0" encoding="UTF-8"?>

<project name="pruebaAspectJ_nb6.9.1" default="default" basedir=".">
    <description>Builds, tests, and runs the project pruebaAspectJ_nb6.9.1.</description>
    <import file="nbproject/build-impl.xml"/>

<taskdef classpath="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjtools.jar"
     resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties"/>

<target name="aspectj">
  <echo level="info">--- aspectj (start) ---</echo>  
  <iajc destDir="${build.classes.dir}">
      <inpath>
        <pathelement location="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjrt.jar"/>
        <pathelement location="${build.classes.dir}" />
      </inpath>
 <sourceroots>
  <pathelement location="${src.dir}"/>
 </sourceroots>
 <classpath>
  <pathelement location="${javac.classpath}"/>
  <pathelement location="${j2ee.platform.classpath}"/>
 </classpath>
  </iajc> 
  <echo level="info">--- build.xml by Ignacio Rigoni email: {name}.{lastname}@gmail.com ---</echo>
</target>

<target name="-post-compile" depends="aspectj"></target>
 
</project>

7) Ahora, modificar las lineas 7 y 14. En la línea 7 hay que especificar la ruta completa del archivo "aspectjtools.jar". Esto se hace donde descomprimiste aspectj. En la línea 14 hay que hacer lo mismo, pero apuntando al archivo "aspectjrt.jar".

8) Eso es todo!

Consideraciones

1) Bajar el archivo aspect{version}.jar, no el archivo aspectj{version}-src.jar.
2) Tener cuidado con las rutas de los archivos, siempre causan problemas!
3) No estoy seguro, pero es posible que las otras lineas que agregaron en build.xml tengan errores. A mi me funcionaron bien, pero puede que esto dependa del proyecto creado, así que si esto les causa problemas, hay que chequear los directorios a los que apunta el resto del archivo, y otras causas posibles de errores.

Espero que esto te ayude. Vuelvan a comentar si anduvo y/o si tienen sugerencias que crean que puede mejorar esto.

Install AspectJ in NetBeans 6.9.1

2011-04-11T23:15:00.000-07:00

Versión en español

Hi. First, sorry my English, it's not my native languaje.
Second, after hours trying, I managed to compile with AspectJ in NetBeans 6.9.1
Now I'll show the way to make it possible. But I want to clarify that I wont install a NetBeans's plugin, but it is the way to make it possible to compile aspects in netbeans with AspectJ. Now, let's go on the steps:

1) Download the AspectJ Latest Stable Release, on this page.
2) Unzip de ".jar" file in the directory you like to put your libraries. It should not be in the proyect's lib directory, because you may want to use it in other projects too. You will unzip about 4 ".jar" files.
3) Create a project in netbeans, just a simple "Java Project".

Now listen, you have to follow the next steps in every new project you make:

4) Go to the project's propierties and in the libraries panel, select the "Add Jar/Folder". Now, select this files from the unzipped file:

aspectjrt.jar
aspectjtools.jar
org.aspectj.matcher.jar

5) Once this files were added, you must edit the build.xml file created inside you project directory.
6) Between the tags <project> and </project> paste this code:


<taskdef classpath="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjtools.jar"
     resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties"/>

<target name="aspectj">
  <echo level="info">--- aspectj (start) ---</echo>  
  <iajc destDir="${build.classes.dir}">
      <inpath>
        <pathelement location="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjrt.jar"/>
        <pathelement location="${build.classes.dir}" />
      </inpath>
 <sourceroots>
  <pathelement location="${src.dir}"/>
 </sourceroots>
 <classpath>
  <pathelement location="${javac.classpath}"/>
  <pathelement location="${j2ee.platform.classpath}"/>
 </classpath>
  </iajc> 
  <echo level="info">--- build.xml by Ignacio Rigoni email: {name}.{lastname}@gmail.com ---</echo>
</target>

<target name="-post-compile" depends="aspectj"></target>

So the complete build.xml file can be like this:


<?xml version="1.0" encoding="UTF-8"?>

<project name="pruebaAspectJ_nb6.9.1" default="default" basedir=".">
    <description>Builds, tests, and runs the project pruebaAspectJ_nb6.9.1.</description>
    <import file="nbproject/build-impl.xml"/>

<taskdef classpath="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjtools.jar"
     resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties"/>

<target name="aspectj">
  <echo level="info">--- aspectj (start) ---</echo>  
  <iajc destDir="${build.classes.dir}">
      <inpath>
        <pathelement location="/home/ignacio/NetBeansProjects/lib/aspectj/aspectjrt.jar"/>
        <pathelement location="${build.classes.dir}" />
      </inpath>
 <sourceroots>
  <pathelement location="${src.dir}"/>
 </sourceroots>
 <classpath>
  <pathelement location="${javac.classpath}"/>
  <pathelement location="${j2ee.platform.classpath}"/>
 </classpath>
  </iajc> 
  <echo level="info">--- build.xml by Ignacio Rigoni email: {name}.{lastname}@gmail.com ---</echo>
</target>

<target name="-post-compile" depends="aspectj"></target>
 
</project>

7) Now, modify the lines 7 and 14. In line 7 you must specify the "aspectjtools.jar" with the full path. This is where you unzipped aspectj. In line 14 you must do the same, but pointing to the "aspectjrt.jar" file.

8) That's all.

Considerations

1) Use the aspect{version}.jar file, no the aspectj{version}-src.jar file.
2) Be careful with the paths, it always cause problems!
3) I'm not shure, but may be possible that the other lines you added in build.xml could have errors. It worked fine for me, but may be it depends on the project, so if that causes a problem, you should check the dirs, and other possible error sources.

I wish this helps you! Please, come back and comment or suggest if you think this could be improved in any way.

Colorear código fuente en Bolgger con "Syntax HighLighter"

2011-04-09T11:23:00.000-07:00

Esto si que me costo encontrarlo, y mas aun hacerlo funcionar. ¿Por que? Porque en la mayoria de las web esta mal explicado, como en esta.

Luego encontré cómo se configura blogger para que realmente funcione esto: es muy facil. Lo pasos son los siguientes:

1º) Modificamos la plantilla de Blogger.
Para esto vamos a Diseño -> Edición de HTML. Ahi buscamos la etiqueta </head>. Y justo una linea encima de esta agregamos el siguiente código:


<!--SYNTAX HIGHLIGHTER BEGINS-->
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shCore.css' rel='stylesheet' type='text/css'/>
<link href='http://alexgorbatchev.com/pub/sh/current/styles/shThemeDefault.css' rel='stylesheet' type='text/css'/>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shCore.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCpp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCSharp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushCss.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJava.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushJScript.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPhp.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPython.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushRuby.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushSql.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushVb.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushXml.js' type='text/javascript'></script>
<script src='http://alexgorbatchev.com/pub/sh/current/scripts/shBrushPerl.js' type='text/javascript'></script>
<script language='javascript'>
SyntaxHighlighter.config.bloggerMode = true;
SyntaxHighlighter.config.clipboardSwf = 'http://alexgorbatchev.com/pub/sh/current/scripts/clipboard.swf';
SyntaxHighlighter.all();
</script>
<!--SYNTAX HIGHLIGHTER ENDS-->

2º) Verificar si todo anduvo bien haciendo click en "Ver Blog".

3º) Agregar el código fuente que quieras.
Para esto, cuando estamos editando una entrada, tenemos que hacer click en la pestaña que dice "Edicion de HTML" y ahi agregar las siguientes líneas:


<pre class="brush:java">
Aca va tu codigo en java
</pre>

Donde dice java, ponen el lenguaje que esten usando. Para ver una lista de lenguajes disponibles y como se nombran, vean este link.

Por ultimo, me gustaria recalcar algo. Conviene formatear el codigo fuente, al final de la edición del post, ya que si se hace cambiando el tipo de edición (de "Edicion de HTML" a "Redactar") se pierde el formato de saltos de lineas y espaciados del codigo fuente. Por lo tanto, recomiendo escribir el post completo, y al final poner todo el código fuente que se quiera.

Saludos!

Instalar AspectJ en NetBeans

2011-04-07T21:27:00.000-07:00

UPDATE 1: Para compilar AspectJ en NB 6.9.1, leer esta entrada.

Bueno, este es un punto que me tenía un poco molesto porque no encontraba una buena página que describiera cómo hacerlo. Resultó mucho más fácil de lo que imaginé. La instalación no es precisamente difícil, pero creo que nunca está demás mostrar como hace, sobre todo porque lamentablemente el plugin de AspectJ para NetBeans dejó de desarrollarse oficialmente. Ramón Ramos hizo una nueva versión compatible con está versión del IDE, y es ésta versión del plugin la que instalaremos. Bien, vamos:

1º) Instalar el IDE NetBeans 6.1. Probé de instalarlo en Netbeans 6.9.1 pero no me reconocía algunas partes del plugin, y no las instalaba por un problema de versiones. Como no soy muy ducho con esos temas, opté por directamente instalarlo en la versión 6.1. Ahora, si alguien puede instalarlo en una versión más reciente, que comente y lo agregamos a este pequeño tutorial.

2º) Descargar los plugins de AspectJ. Desde la misma página de NetBeans, vamos a la sección de plugins y buscamos en el catálogo todos los plugins que coincidan con "aspectj". Descargamos el más nuevo.

3º) Agregar los plugins a NetBeans. Descomprimimos el archivo descargado del paso anterior en una carpeta temporal. Luego vamos a NetBeans, y al menú "Herramientas | Complementos". Allí seleccionamos la pestaña "Descargados" y agregamos todos los archivos que salieron de la extracción del archivo comprimido. Luego los instalamos y listo.

En este punto ya tenemos instalado el plugin de AspectJ, es decir, ya podemos agregar aspectos a nuestros proyectos. Ahora queda un últimp paso, que es configurar el proyecto que al que queremos añadir aspectos. Esto es muy simple:

1º) Añadir la librería "AspectJ-Runtime". Para esto vamos a las propiedades del proyecto, y en Librerías seleccionamos la pestaña "Compilación". Le damos click a "Añadir librería" y seleccionamos la que se llama AspectJ-Runtime.

Listo, con esto ya podemos empezar a hacer uso de los aspectos en Java bajo NetBeans. Simple, ¿no? A mi me costó al no encontrar una buena página que describiera los pasos. Al final recién di con la que mencioné al principio.

S2!

¿Convolución? ¡Pero si es muy fácil! (Parte 3/3)

2011-01-07T10:31:00.001-08:00

Buenas. Hoy voy a terminar con la última parte que había comentado sobre el tema de convolución. Básicamente voy a presentar un pequeño código que hice en C, y que muestra dos formas de realizar la convolución. En la primera de ellas, llamada (Input Side Algorithm) y denominada como input_side_conv() en el código, se puede observar que se obtiene la convolución de una forma muy simple: se recorren todos los puntos de la señal x[n] y h[n], y en base a esto se calcula el y[n] correspondiente.

La segunda función, llamada output_side_conv(), obtiene la convolución con el Output Side Algorithm, la cual varía de la anterior en un punto muy importante. Antes de ver cual es la diferencia importante, veamos el código, ya que es muy simple de entender:


#include <stdio.h>
#include <stdlib.h>

#define PUNTOS_X (6)
#define PUNTOS_H (4)
#define PUNTOS_Y ((PUNTOS_X) + (PUNTOS_H) - 1)

/* Los metodos tienen la misma interfaz:
    x, h ---> son las señales de entrada
       y ---> es la señal de salida        */
void input_side_conv(int *x, int *h, int *y)
{
    int i,j;
    for(i=0;i<PUNTOS_X; i++)
        for(j=0;j<PUNTOS_H;j++)
            y[i+j]=y[i+j]+x[i]*h[j];
}

void output_side_conv(int *x, int *h, int *y)
{
    int i,j;

    for(i=0;i<PUNTOS_Y; i++) {
        y[i]=0;
        for(j=0;j<PUNTOS_H;j++) {
            if(i-j<0 || i-j>=PUNTOS_X) continue;
            y[i] = y[i]+h[j]*x[i-j];
        }
    }
}

int main()
{
    int x[PUNTOS_X] = {0,-1,-1,2,1,1};
    int h[PUNTOS_H] = {1,0,-1,1};
    int y1[PUNTOS_Y] = {0,0,0,0,0,0,0,0,0};
    int y2[PUNTOS_Y] = {0,0,0,0,0,0,0,0,0};

    int i;

    //calculamos la convolucion por el primer metodo
    input_side_conv(x, h, y1);
    //calculamos la convolucion por el otro metodo
    output_side_conv(x, h, y2);

    //mostramos las dos respuestas
    printf("Input Side        Output Side\n");
    for(i=0;i<PUNTOS_Y;i++)
        printf("[%2d]              [%d]\n", y1[i], y2[i]);

    return 0;
}

Vemos que he definido 3 constantes simbólicas con #define. Las mismas son PUNTOS_X, PUNTOS_H y PUNTOS_Y. Cada uno denota la cantidad de puntos que tiene cada señal involucrada. En el caso de PUNTOS_Y se puede obtener con la operación que puse, según la fórmula que expliqué en la primera parte de esta serie de artículos.

Luego siguen las definiciones de las funciones que calculan la convolución. Ambas dan el mismo resultado, pero cada una lo calcula de forma distinta.

Finalmente, tenemos un main() que lo unico que hace es fijar valores para x[n] y h[n] y luego realiza la convolución de las mismas en dos señales de salida, y1[n] e y2[n] y muestra en forma "de tabla" el resultado de ambas para simplificar la comparación y ver que dan el mismo resultado.

La diferencia importante de la que hablé recién, es la siguiente: si observamos con detalle cómo se calcula cada convolución, podemos notar que la segunda forma, output_side_conv() tiene una ventaja importante, y ésta es que permite calcular un valor específico de y[n] sin que sea necesario conocer todos los puntos de x[n], sino solo los necesarios. En cambio, en la otra función necestiamos conocer todos los puntos de x[n] de antemano, ya que los recorremos uno a uno, y en base a esto vamos calculando cada valor de y[n]. ¿Por qué esto es tan importante? Porque generalmente, no contamos con todos los puntos de x[n] ya que muchas veces se necesita obtener la convolución a medida que se va obteniendo la señal x[n], es decir, obtener y[n] en tiempo real.

Acá les dejo el código en C para que no tengan que copiarlo a mano: bajar código en C .

Bueno, con esto doy por finalizados los artículos de convolución, espero que les haya resultado interesante, divertido.. o al menos práctico!

¿Convolución? ¡Pero si es muy fácil! (Parte 2/3)

2010-12-25T08:01:00.000-08:00

Método "Semi-Gráfico" Simple de convolución.

Buenas! En mi post anterior, hablé un poco de lo que era la convolución, y medio que me obligué a mostrar en esta entrega un método para resolver convoluciones a mano. Le he llamado "semi-gráfico" porque no es gráfico, pero se me ocurrió a partir de las gráficas de las señalesa convolucionar, aquellas que llamábamos x[n] y h[n] . Mediante este método, obtendremos el y[n]. Pero demás está decir que las señales pueden ser cualquiera, asique de forma genérica las llamaremos a[n] y b[n].

Bueno, aqui dejo el video con la explicación del método. Espero que sea últil! ;)

Saludos!

¿Convolución? ¡Pero si es muy fácil! (Parte 1/3)

2010-12-08T14:41:00.000-08:00

Bueno, les comento que para el título del post, saqué la idea de un libro muy viejo que tenía mi abuelo, el cual se titulaba: "¿La Radio? ¡Pero si es muy fácil!", y como me pareció muy simpático para un libro, me quedó grabado muchos años.. ahora lo adapté para usarlo en mi blog :)

Pasando al tema que me toca. La convolución es un tema al que cuesta agarrarle la mano en un principio, tanto en el concepto como el cálculo de la misma. Mientras aprendía este tema, se me ocurrió una forma muy simple de calcular convoluciones a mano, y por eso me decidí a realizar el post. Advierto que no soy un experto en el tema, pero comprendo muy bien el concepto, y voy a tratar de explicarlo de la forma más sencilla posible; además del método de resolución que mencioné y un programa en algún lenguaje que la resuelva, como para terminar esto bien bonito. En la imagen que no se ve, pueden hacer click para agrandarla.

¿Qué es la convolución?

Para comenzar, la convolución se trata de una operación matemática que combina dos señales para producir una tecer señal. En el campo de las señales digitales es muy importante, ya que permite obtener la señal de salida de un sistema a partir de la señal de entrada y la respuesta al impulso. Es decir, podemos predecir la salida, conociendo la entrada y la respuesta al impulso.

Conceptos previos.

Bien, primero que nada, es necesario tener algunas cosas claras antes de explicar la convolución. Comencemos por describir qué es el impulso unitario o función delta (es lo mismo). No es nada más que una simple función matemática que vale 1 en n = 0 y vale 0 en cualquier otro punto. Es decir:

Podemos desplazar y escalar esta función delta, ¿cierto? Por ejemplo, si tenemos una señal s[n] que vale -3 en n = 5 y vale cero en cualquier otro punto, entonces expresarla como una función delta desplazada 5 muestras hacia la derecha, y escalada por un factor de -3. Es decir que s[n] = -3*delta[n-5]. Es decir, lo que tenemos es un impulso (es decir, es una señal que es el impulso unitario pero desplazado y escalado).

Una vez que comprendemos el efecto de desplazar y escalar la función delta, podemos descomponer cualquier señal en una sumatoria de impulsos (funciones delta desplazadas y escaladas). A la descoposición de una señal en una otras señales se le llama análisis de la señal. La idea de esto, es que si tomamos cada impulso y los sumamos, volveremos a obtener la señal original. A la composición de una señal a partir de la sumatoria de otras señales (en nuestro caso impulsos) se le llama síntesis.

Veamos un ejemplo simple de descomposición de una señal en una sumatoria de impulsos

Ahora, imaginemos que tenemos un sistema lineal cualquiera. Si en la entrada de dicho sistema ponemos una señal cuañquiera, el sistema, como es de esperarse, nos devovlerá una señal salida, la cual dependerá exclusivamente de qué haga el sistema internamente. O sea que distintos sistemas nos pueden dar distintas respuestas ante la misma entrada. En el caso particular de que la entrada sea el impulso unitario la salida del sistema se llamará respuesta al impulso o respuesta impulsiva y se denota como h[n].

Lo interesante de esto, es que si la entrada al sistema es un impulso unitario desplazado y escalado, entonces la salida será la respuesta al impulso, pero igualmente desplazada y escalada que que la entrada. Si además, recordamos que cualquier señal puede expesarse como una sumatoria de impulsos, podemos conocer la respuesta del sistema a cada uno de esos impulsos. Y si además, sumamos todas estas respuestas a cada impulso, entonces obtendremos la respuesta del sistema a la señal original.

Ahora si, ¿qué es la convolución?

¿Cuál es el beneficio de todo esto? Que podemos predecir la salida de cualquier sistema linear con solo conocer su respuesta al impulso unitario, es decir, el h[n].y no hay necesidad de introducir realmente una señal de entrada al sistema; sino que descomponemos esa señal en impulsos, evaluamos la respuesta del sistema para cada impulso (escalamos y desplazamos h[n] según cada impulso) y luego sumamos esas respuestas. ¡Todo este proceso, no es más que la convolución de h[n] y la señal de entrada! La convolucion se representa con una estrella. Es decir:

Matemáticamente, se escribe como:

donde M es la cantidad de muestras que tiene la respuesta al impulso h[n] y van desde 0 hasta M-1. La señal x[n] tiene N muestras (0 a N-1). La convolución de ambas señales, y[n], tendrá N+M-1 muestras (de 0 a N+M-2).

Bueno, espero que haya sido claro, sino pregunten o sugieran, y nunca está demás complementar con otras lecturas. Personalmente, recomiendo leer el capítulo 6 de un libro disponible en formato digital llamado "The Scientist and Engineer's Guide to Digital Signal Processing" escrito por Steven W. Smith, Ph.D. Enlace al libro. Está en inglés, ¡pero es excelente!

La proxima entrega describo el método de cálculo manual de la convolución. ¡Nos vemos!

Funciones estáticas de C

2010-12-07T23:17:00.001-08:00

Esta tarde estaba mirando/modificando un código en lenguaje C. Me llamó la atención el uso de un puntero a función que referenciaba a una función estática. Me llamó a la atención porque si bien en el paradigma orientado a objetos los métodos estáticos tienen una importancia relevante, no pude hacer una relación inmediata sobre qué podía significar una función estática en la programación estructurada. Por esto es que me puse a buscar un poco, hasta dí con el significado.

Cuando definimos una función como estática en C, lo que realmente estamos haciendo es limitar a que solo las funciones que están definidas en el mismo archivo que la función estática puedan llamarla a ésta. Para verlo más claro, veamos los siguientes archivos:


//////////////////////////
// Archivo: funciones.h //
//////////////////////////

int sumar (int a, int b);
static int rest(int a, int b);
int restar(int a, int b);


//////////////////////////
// Archivo: funciones.c //
//////////////////////////

#include "funciones.h"

int sumar(int a, int b)
{
    return a+b;
}
static int rest (int a, int b)
{
    return a-b;
}
int restar (int a, int b)
{
    return rest(a,b);
}


/////////////////////
// Archivo: main.c //
/////////////////////

#include <stdio.h>
#include <stdlib.h>

int main()
{
    int a, b, c, d, e;

    a = 5;
    b = 7;

    c = sumar(a,b);
    d = restar(a,b); //CORECTO! :)
    e = rest(a,b);   //  ERROR! :(

    return 0;
}

La función rest() está definida como estática, esto quiere decir que solo las funciones sumar() y restar() pueden llamarla; pero main() -que está definida en otro archivo- no puede hacerlo, ya que no la "vé" directamente. (En esta página hay una forma interesante de saltear esta restricción para casos particulares, como por ejemplo, pruebas unitarias).

Puedo decir, sin intención de herir la susceptibilidad de los paradigmáticos, que las funciones estáticas de C vienen a ser las abuelas de los actuales modificadores private tan utilizados en la programación orientada a objetos, ya que ambos permiten el encapsulamiento de funcionalidad .

Luego sigo ahondando un poco más en el tema, ¡nos vemos!

EDIT: Artículo corregido.

Comunidad Libre UTN

2010-11-01T14:23:00.000-07:00

Buenas! Hoy les tiro la data de una comunidad que estamos armando junto con algunos compañeros de la facutlad. Les "copy-pasteo" la descripción de la misma:

Sobre la comunidad

Porque creemos que la utilización de software libre en el ámbito educativo es un recurso invaluable y debe ser aprovechado al máximo.

Unite a una comunidad en donde el fín último será el aprendizaje colectivo y la utilización de nuevas tecnologías.
Mediante el intercambio de información, conocimiento e ideas potenciaremos las capacidades individuales de cada uno de los miembros.
Fomentaremos el espíritu proactivo y creativo de los integrantes mediante el aprendizaje autodidacta, el desarrollo de nuevas herramientas y el trabajo en equipo.
Organizaremos diferentes tipos de actividades para promover la utilización de herramientas libres y su filosofía, dentro y fuera de la comunidad.

¿Cómo funcionamos?

La comunidad persigue fuertemente la filosofía de “aprender haciendo”. Esto significa que la comunidad induce a los miembros a participar en diferentes proyectos y aprender del estudio, de la experiencia y de compartir conocimiento.

No tenemos un foro de ayuda, no somos soporte técnico y si buscás ayuda para un problema puntual probablemente te sea dificil encontrarla porque nuestra estructura no facilita ese tipo de búsqueda. Estamos para aprender haciendo cosas y nosotros también buscamos conocimientos desde otras fuentes. Si en algún futuro nace un grupo dentro de la comunidad que esté dedicado a ayudar en la resolución de problemas, pues esas serán políticas puramente de dicho grupo.

Te invitamos a que te unas a la comunidad registrándote en este sitio y que busques grupos de tu interés, o que crees el tuyo propio si es que no encuentras alguno que te guste.

Link: http://comunidadlibre-utn.co.cc/

Funciones 'inline' de C++: "Expansión en Línea"

2010-09-14T18:09:00.000-07:00

Es realmente interesante todo lo que se puede aprender a partir de pequeñas dudas. La mía surgió por un motivo que no viene al caso, pero terminé interesándome por las funciones definidas en el estándar de C++ llamadas inline.

Las funciones inline han venido de alguna manera, a reemplazar las macros de preprocesador. No es que esta fuera la finalidad al crearlas (realmente no lo sé), pero la utilidad es básicamente la misma, aunque las funciones inline tienen ventajas sobre las macros.

Bueno, empecemos: ¿qué hace un función inline? Cuando declaramos una función con el calificador inline, el compilador intentará -llegado el momento- de colocar una copia del código de la función en el lugar de la llamada a dicha función en línea). Esto reduce la sobrecarga que se genera cuando llamamos a funciones, pero a costa de incrementar el tamaño del programa por el hecho de tener una copia de la función en cada lugar en que la llamamos.

Es lo mismo que logramos cuando utilizamos las macros de preprocesamiento para expandir código en línea. Acá se puede ver:


#include <iostream>

using namespace std;

#define macroCubo(x) (x)*(x)*(x)

inline int funcCubo(int x)
{
    return x*x*x;
}

int main(void)
{
    cout << endl << "Con macro: " << macroCubo(2+1);
    cout << endl << "Con inline: " << funcCubo(2+1);

    /*
        La linea 10 queda finalmente como:
            cout << endl << "Con macro: " << (2+1)*(2+1)*(2+1);
        La linea 11 queda finalmente como:
            cout << endl << "Con inline: " << 3*3*3;
    */
}

Aunque el resultado funcional es el mismo, existen diferencias entre los dos métodos:

Las funciones inline, al ser como cualquier otra función, conlleva una verificación de tipo, cosa que no sucede con las macros, ya que se reemplazan "sin más".
Las funciones inline no pueden utilizarse de forma sintácticamente incorrecta, ya que esto produciría un error de compilación. Con las macros, es posible sufrir ciertos efectos colaterales por mal uso.
Las macros no puede ser depuradas, ya que para el precompilador son solo porciones de texto que deben reemplazarse donde se indique. El compilador puede informar un error, pero no podrá decir que se debe a una macro, ni a cual. Por el contrario, las funciones inline se puede depurar como cualquier otra función.
Las macros reemplazan los argumentos con los parámetros sin evaluar (ver imagen de arriba). En cambio, las funciones evalúan los parámetros (si se tratá de una expresión matemática, por ejemplo, esta se resuelve y se pasa).

Cabe aclarar que no me gusta hablar de ventajas y desventajas, y remarco que son diferencias. Muchas veces lo que en ciertos contextos es ua ventaja, en otros puede no serlo o ser una desventaja.

Sobre el uso de las funciones en línea, vale aclarar algunas cositas:

Cada vez que se modifica una función inline, es necesario recompilar todos los archivos que la utilizan (recordemos que se trata de copiar y pegar el cuerpo de la función; y si ésta se moficia, hay que volver a copiar y pegar).
Se recomienda utilizar el calificador sólo en las funciones pequeñas (aunque tengo entendido que el compilador lo ignora si la función es relativamente grande).
Existe una sobrecarga cuando se llama a una función cualquiera, la cual se evita utilizando funciones inline, mejorando el tiempo de ejecución.

Ahora quiero mencionar algunos aspectos importantes de las funciones en línea que es conveniente tener presentes al momento de diseñar un programa. Para el "programa típico" quizás no sean relevantes, pero para casos más extremos como sistemas embebidos o sistemas distribuídos, puede significar un costo importante de recursos.

Los aspectos a tener en cuenta son:

Se reduce tiempo de ejecución, probablemente a costa de aumentar el tamaño del programa. Es necesario evaluar este punto si queremos, por ejemplo, programar sistemas embebidos ya que usualmente el espacio suele ser un factor crítico en estos.
Las variables que se agregan por las funciones en línea pueden necesitar registros adicionales, y si no se dispone de suficientes, entonces se requerirá más accesos a memoria RAM, incrementando así el tiempo de ejecución.
Si el código del programa crece demasiado, pueden superarse las limitaciones de recursos (como memoria RAM) y fallar el programa. Esto es importante sobre todo en sistemas de recursos más limitados, como embebidos, móviles, etc.

Bueno, supongo que aún pueden tenerse en cuenta algunos aspectos que no he mencionado acá, pero esto da algunas pautas de las consecuencias que puede haber con el uso de las funciones en línea, que pueden ayudar o perjudicar en las aplicaciones que hagamos.

Salutes!

Ejemplo de uso del patron Observer

2010-09-04T14:42:00.000-07:00

Ahora que hice el último patrón que se nos había encomendado implementar, el patrón Observador, voy a poner el ejemplo como hice con el patrón Command.

La idea es la siguiente: tenemos un caso de uso "Marcar Gol" que se dispara -imaginemos- cuando un sensor ubicado en un arco de fútbol detecta que pasa la pelota. Al dispararse este caso de uso, se llama al método de su experto anotarGol(), quien -entre otras cosas- llama al método actualizar() de SuscriptorGoles.

La interfaz del caso de uso "Ver Resultados" llama al método inciar() del controlador, con el cual éste se suscribe a SuscriptorGoles para que SuscriptorGoles llame al método actualizar() del controlador. Este método, lo implementa de la interfaz IObservadorGoles.

Notemos que SuscriptorGoles tiene un arreglo (o lista) de IObservadorGoles para actualizar a cada observador suscrtipto a el.

En el diagrama de clases olvidé especificarlo, pero conviene que SuscriptorGoles sea un singleton, ya que no vamos a usar más que una sola instancia de él.

Implementación en C#: Descargar

Salutes!

La estrategia del Cartógrafo

2010-09-03T08:52:00.000-07:00

Todos los que hayan leido el conocido libro de Craig Larman "UML y Patrones", ya saben a que me refiero. Para quienes no, y para tenerlo en mi colección bloggera de temas interesantes, lo pongo.

La estrategia del cartógrafo está explicada en la parte del libro que habra sobre la construcción de modelos conceptuales. La idea que propone es tener en cuenta tres sugerencias que seguir al momento de trazar un mapa o, en nuestro caso, modelar un dominio.

Un modelo conceptual es una especie de mapa de las cosas del dominio que estamos analizando. Las tres sugerencias para tener en cuenta son:

1) Utilizar los nombres existentes en el territorio. Los cartógrafos utilizan los nombres que se usan en ese territorio, no les inventan nuevos nombres a las cosas. Es decir, que el vocabulario que usemos cuando asignamos el nombre a los conceptos y atributos sea el mismo que se usa en el dominio. Por ej: si en un modelo de supermercado, el personal llama "Comprador" a los clientes, nosotros le llamaremos como tal y no "Cliente" o "PersonaQueCompra" o cualquier otro nombre que nos guste más.

2) Excluir las características irrelevantes. Los cartógrafos deben omitir en su mapa las cosas que no les parecen importantes, es decir, aquellas que no contribuyen con el propósito que persiguen, como por ejemplo, la población en determinados lugares, o la salinidad de la tierra, etc. En nuestro ámbito, y siguiendo con el ejemplo del supermercado, nos puede convenir excluir conceptos como "Proveedor" si es que los proveedores no son relevantes para los requerimientos actuales. Hay que tener cuidado en esto, porque algunos conceptos pueden no ser tan obvios respecto de su relevancia, y podemos omitir algo que en el futuro será necesario.

3) No agregar cosas que no existan. El ejemplo que se menciona en el libro no puede ser más claro: ¡un cartógrafo no va a poner una montaña si ésta no existe! Con esto se refiere a que es conveniente excluir todo aquello que no forma parte del dominio del sistema que se analiza.

Claro no hay que cumplirlas al pie de la letra (por algo son sugerencias) pero a mi parecer son muy simples y muy prácticas. A veces hasta pueden sonar obvias e innecesarias, pero lo que me agrada es que son muy útiles para esos momentos en que el sistema "nos puede", esos momentos en que nos perdemos en el mar de conceptos, requerimientos y descripciones que tienen los sistemas grandes...

Hasta la próxima.

Ejemplo de uso del patron Command

2010-08-28T08:33:00.000-07:00

Buenas, gente. Decidi subir este ejemplo al blog porque tuve que hacerlo para la facultad y por ahi viene bien ver algunos ejemplos, aunque que abunden en internet.
Como dije, se trata de un ejemplo aplicado del patrón Command a un negocio que tiene que ver con una escuela.

La idea es que cuando en dicha escuela se programan las fechas de exámenes, se debe notificar a los profesores, a los padres de los alumnos, a la Dirección General de Escuelas, y debe además, mostrarse en la cartelera. Es un caso ficticio, inventado para el ejemplo. La idea es que a los profesores se les debe enviar una notificación impresa a la casa, a los padres se les avisa por e-mail, a la DGE se le puede avisr por e-mail o por notificacion escrita (da igual). Digo que da igual, porque no me he centrado en el proceso particular de cada notificación en sí, sino solo en la aplicación del patrón Command.

Cuando el experto del caso de uso "Programar Fechas de Examenes" confirma dichas fechas, se debe proceder a hacer las notificaciones para cada caso. Eso es lo que está en el ejemplo.

El lenguaje utilizado es C#, con el IDE Visual C# 2008 Express Edition. Pueden descargar el código fuente y ver el diagrama de clases.

Código Fuente : Descargar
Diagrama de Clases: Descargar o la imagen.

Saludos!

CNEISI '10: Impresiones personales.

2010-08-21T11:45:00.000-07:00

Acabo de volver del CNEISI 2010, realizado en la provincia de Santa Fé, y esta es mi impresión en rasgos generales.

La prvincia. No pude conocer mucho debido al poco tiempo que dura el congreso, pero lo poco que ví me encantó. El tiempo nos acompañó de muy buena manera, no hacía ni frío, ni calor. El río formaba un paisaje realmente hermoso y digno de ver, junto al puente "colgante" y desde la orilla odíamos ver el edificio del CONICET y la UNL al otro lado de la misma. También cruzamos a Entre Ríos para concoer Paraná, una ciudad que verdaderamente me encantó, no se, su estilo.. La verdad, quisiera haber tenido más tiempo para conocer ambos lugares un poco más.

El congreso en general. Bueno, este no me encantó desde ningún punto de vista. De hecho su organización me pareció muy pobre. Mi único punto de comparación es el CNEISI 2009 realizado en San Franciso (pvca de Córdoba), el cual me resultó mucho mejor armado.

Las charlas. Son los detalles los que hacen que un congreso sea bueno o malo. Los temas de las charlas me parecieron muy malos (con excpeciones), me arriesgo a decir que fueron casi "improvisados". Dar una charla sobbre "crackeo de contraseñas" es muy pobre... esta es información disponible en cualquier lugar de internet, no hay nada innovador en ello, es más, ¿quién no ha investigado y googleado sobre el crackeo de contraseñas alguna vez?. Otra cosa que noté, es que la empresas -en sus charlas- están ansiosas por presentar("vender") sus productos, sus sistemas... esto no llama, no sirve, esto no es de interés para un estudiante típico.
Como conclusión en las charlas tuve la impresión de que nos llenaron de información inútil, pero no nos muestran la importancia de meditarla. Y por esto mismo, quiero recalcar la charla "¿Me va a servir dentro de 20 años lo que estoy aprendiendo hoy?" que dio Santiago Ceria porque significó algo así como una "pausa en el tiempo", un "wait" para procesar un poco lo que había en el búffer, porque eso es más difícil de encontrar en internet, porque te hace dejar de reaccionar mecánicamente a la información y te hace pensar.. o eso fue lo que me produjo a mi. Esa charla, realmente me encantó.

La comida. Los pebetes con botella del almuerzo no estuvieron mal, teniendo en cuenta que son solo un brake para seuir en el congreso. Por ahi te quedabas como con ganas de comer un poco más, pero de última pasaba. Las cenas me parecieron muy malas, pésimas. La primera: ir a comer a un boliche y comer 6 porciones de pizza por 23 pesos es una gastada... y todavía peor si están frías y con la música a todo volúmen. La segunda cena fue más rica (pancitos con un poco de carne entre medio) pero realmente fue escasa. Nos quedamos con muchísimas hambre. Nuevamente la música a todo volúmen... no da para cenar, no podés conversar. Una cena no debería hacerse en un boliche. En esto, la facultad de San Francisco estuvo muchísimo mejor organizadas. Comidas realmente ricas, y en un ambiente agradable.

El hotel. No estuvo mal para ser que solo pasabamos allí las noches. El servicio no era el mejor, pero para los fines era adecuado. No pongo quejas en ello. Tampoco me siento del todo satisfecho.

A favor... Ló único que si puedo rescatar a favor, y en lo cual este congresó fue superior al anterior, fue la puntualidad. No fue 100% puntual, pero la demora fue de menos horas que el anterior. ¿Qué pasa con esto? Es fácil: cuando una delegación llega a destino luego de un largo viaje, quiere sí o sí ir al hotel y bañarse. No me parece que el hotel este acreditado desde ese mismo día. No me parece que haya que esperar 3 horas en la facultad hasta que nos acrediten en el congreso para recién podes ir al hotel. El problema, es que ni siquiera después se puede ir al hotel. Este es un aspecto que imagino tienen todos los congresos, pero realmente habría que mejorar.

Bueno, esa fue mi impresión general del congreso. De todas formas, la pasé muy bien y esperaremos al año que viene para volver a participar del mismo :)

Info del congreso: http://www.frsf.utn.edu.ar/cneisi2010/

Saludos!

Algoritmos Genéticos Paralelos (I)

2010-08-02T07:15:00.000-07:00

Después de casi un año de letargo, me decidí a volver y escribir uno de los tantos posts que tengo en la cabeza hace un tiempo.

Voy a tirar algunos conceptos básicos sobre lo que son los algoritmos genéticos paralelos.

Había escrito el primer post sobre el tema, pero lo eliminé porque me pareció molesto tenerlo en dos blogs. Directamente dejo el otro lugar donde tengo las dos partes del informe ya terminadas y además porque es más elegante y te parsea codigo fuente.
Bien, estos son los temas que trato:

1. Una introducción a los Algoritmos Genéticos.
2. Explicación del Algoritmo Genético Simple.
3. Los algoritmos genéticos paralelos.

Los temas 1 y 2 se ven acá: Algoritmos Genéticos Paralelos (Parte 1)
El tema 3, se puede ver acá: Algoritmos Genéticos Paralelos (Parte 2)

Esta serie de artículos se trata de un informe que escribí para la cátedra de Computación Paralela de la facultad a la que asisto. Acepto sugerencias y críticas. Salute!

Puliendo el vocabulario: Parámetros y Argumentos

2009-08-29T16:07:00.000-07:00

Tener un vocabulario preciso es una cuestión esencial al momento de querer recibir o transmitir conocimiento. Sin ir más lejos, cuando he leído libros o artículos sobre temas un tanto áridos de entender, me me he encontrado con que algunos autores no son precisos al momento de utilizar el vocabulario. En algunas ocasiones, esto me ha significado caer en los mismo errores que ellos, y lo que es peor, no comprender realmente lo que ellos han querido transmitir.

En charlas en la facultad, discutiendo sobre problemas, me he encontrado que muchas personas no saben la diferencia -o la han olvidado- entre los parámetros y los argumentos de una función. Incluso buscando en internet he visto que muchas personas las confunden, o que para intentar simplificar su explicación de las mismas, las mezclan (que ridículo). En fin, en la página de MSDN encontré ambas definiciones muy sencillas.

Diferencias entre parámetros y argumentos

En la mayoría de los casos, un procedimiento necesita cierta información sobre las circunstancias en las que se le ha llamado. Un procedimiento que ejecuta tareas repetidas o compartidas utiliza datos distintos en cada llamada. Estos datos se componen de variables, constantes y expresiones que se transfieren al procedimiento cada vez que se le llama.

Para comunicar esta información al procedimiento, el procedimiento define un parámetro, y el código de llamada transfiere un argumento a dicho parámetro. Puede imaginar el parámetro como una plaza de aparcamiento y el argumento como un automóvil. Del mismo modo que diferentes automóviles puede aparcan en la misma plaza de aparcamiento en momentos distintos, el código de llamada puede transferir un argumento distinto al mismo parámetro cada vez que llama al procedimiento.

Parámetros

Un parámetro representa un valor que el procedimiento espera que se transfiera cuando es llamado. La declaración del procedimiento define sus parámetros.

El nombre de cada parámetro actúa como una variable local dentro del procedimiento. El nombre del parámetro se utiliza del mismo modo que cualquier otra variable.

Argumentos

Un argumento representa el valor que se transfiere a un parámetro del procedimiento cuando se llama al procedimiento. El código de llamada proporciona los argumentos cuando llama al procedimiento.

A diferencia de la definición de parámetros, los argumentos no tienen nombres. Cada argumento es una expresión que puede contener cero o más variables, constantes y literales. El tipo de datos de la expresión evaluada normalmente debe coincidir con el tipo de datos definido para el parámetro correspondiente, y en algún caso, debe poder convertirse al tipo del parámetro.

Fuente: http://msdn.microsoft.com/es-es/library/9kewt1b3%28VS.80%29.aspx

¿Validar las precondiciones?

2009-05-29T09:16:00.000-07:00

La idea de escribir este postsurgió de una charla que esuché ayer entre un compañero de la meteria "Diseño de Sistemas" y la profesora. Él decía que las precondiciones no se debían evaluar dentro del caso de uso -o sea que no debería ser parte del flujo de ese caso de uso el validar que dichas precondiciones se cumplirian- y por el contrario, son condiciones que ya deben haberse cumplido antes de disparar ese caso de uso. La profesora, en el otro extremo le decía que sí debían validarse dentro del caso de uso.

En principio estuve de acuerdo con mi compañero, porque pensé que esa es justamente la definción de "precondición" (de hecho, la misma palabra lo dice).

Además, la definición formal de precondición es: "una operación que debe ser cierta cuando se invoca una operación". En el Manual de Referencia de UML se agrega, despues de esta definición, que el receptor no debe tener que verificar la condición.

Aunque con estos argumentos parece tener la última palabra mi compañero, la profesora tenía algo más que razón. Quizás su punto de vista no encaja exactamente con el del paradigma de orientación a objetos, o mejor dicho, con las definiciones que se proponen en UML. ¿Entonces está mal su punto de vista?

No. Si recordamos los principios básicos de la orientación a objetos, uno de ellos se refería a la capacidad de reutlizar componentes. Componentes que son de un sistema, pero sirven para otro, pueden ser reutilizados para evitar volver a construirlos. Un caso de uso, por ejemplo, puede ser reutilizado si dos sistemas tienen algun requisito en común. Este caso de uso tendrá sus propias precondiciones que el peimer sistema (llamémosle sistema A) se encarga de "poner a punto" antes de llamarlo. Con "poner a punto" me refiero a que el sistema sabe que caso de uso se llamará -previo al caso de uso que vamos compartir- de forma que el sistema queda en un estado tal que el caso de uso que vamos a compartir tiene "verificadas" esas precondiciones.
¿Pero quien me asegura que esto sea realmente asi? o peor aún, ¿quien me asegura que el nuevo sistema (sistema B) también se encargue de llamar al caso de uso compartido con las precondiciones validadas? Nadie.

Entonces, quizás sea esto lo que la profesora quería decir. Si el mismo caso de uso verificara sus precondiciones, entonces no hay problema de reutilizarlo, ya que el mismo se asegura -donde quiera que lo pongan- que las condiciones se validen. De no validarse, sencillamente no se ejecutará. Esto evita que el sistema llegue a estados no válidos, o de resultados incorrectos.

Entonces, ¿para qué están las precondiciones? Bueno, es un dato más sobre la interfaz del caso de uso. Si conozco las precondiciones, no necesito saber que hace un caso de uso -qué valida y que no- sino simplemente usarlo. Es decir, la precondición como tal es un aspecto más bien ligado al análisis y al diseño, mientras que la verificacion de ésta está más ligada a la implementación.
También ayudan a percibir los flujos posibles entre casos de uso: un caso de uso solo podrá ejecutarse si anteriormente, otros casos de uso han dejado el sistema en un estado tal que éste pueda ejecutarse.

Sincronizar carpetas para trabajar en RED

2009-05-04T08:13:00.000-07:00

En este post quiero comentar un esquema -y un programa que permite implementarlo- para la sincronización de recursos que nos facilite el trabajo en red.

Hace tiempo que estaba buscando un buen programa para sincronizar carpetas con un servidor en internet. La finalidad era mantener mis archivos actualizados en cualquier equipo que yo quisiera, sin tener que copiarlos y mantener esa actualización "a mano".

Este problema se vio incrementado aún más, cuando comenzamos a hacer trabajos de campo en quipo en la facultad. Por ahi se necesita tener demasiados archivos al alcance de todo el equipo (de unas 10 personas en mi caso) y donde no resulta cómodo pasarse los archivos por mail, pendrives, o de alguna otra manera. Es decir, lo que se busca es que todo este al alcance de todos sin hacer esfuerzo.

Generalmente, cada intgrante del equipo tendra su propio equipo para trabajar (pc, portatil, etc) y dentro de su equipo tendrá un directorio para cada proyecto. ¡Que bueno si ese directorio puediera compartirse con el resto del equipo!

Bueno... de hecho, se puede: Windows XP lo permite. Pero hay una gran contra: sólo un equipo puede compartir su recurso (una carpeta por ejemplo), y todos los miembros tendrán que acceder a esa carpeta para leer o modificar archivos. Pero lo peor, es que ese equipo tendrá que estar encendido y conectado a la red cada vez que un integrante "remoto" quiera acceder a él para trabajar. Con esto desechamos el "compartir carpetas" de windows y lo enviamos a la papelera de reciclaje ;)

Después de probar bastante (y buscar muchisimo), di con un programa que hasta ahora no me da motivos de queja: Allways Sync. Es licencia freeware, muy fácil e intuitivo. Solo hay que tener claro qué es lo que se quiere hacer (como pasa siempre, ¿no? xD).

Ahora explico con un esquema cual era mi objetivo para trabajar:

El funcionamiento de este esquema es adecuado porque que cualquier equipo puede realizar modificaciones sobre sus carpetas. Estas carpetas se sincronizacn con el servidor -probablemente un servicio de FTP- y cada uno de los otros equipos, cuando se encienda -o si ya está encendido- sincronizará con el servidor y actualizará los archivos. Algo así:

Con este programa que mencioné esto es posible, e incluso el mismo software da muchas más posibilidades que no voy a describir pero están en la página del mismo.

Su configuración para este esquema es muy sencilla, básicamente:

Instalamos All Sync en cada equipo, y por cada equipo realizamos los siguientes pasos.

Seleccionamos el "origen" y el "destino". El origen será la carpeta de nuestro equipo que queremos mantener sincronizada con el "destino", que en este caso será el sitio FTP.
Configuramos el acceso al servidor FTP (servidor, usuario, password, etc).
Opcionalmente, podemos ir a las opciones de esta tarea y marcar la opción de que se realice una sincronización cada vez que se modifique algún archivo e incluso que se haga una sincronización cada cierto tiempo.
Listo!

Increiblemente, es asi de sencillo. Hay muchas más opciones, pero esas son las principales para este esquema.

Las ventajas principales son:

No es necesario que un equipo en particular esté prendido para trabajar, ya que los datos están en el mismo equipo que los necesite.
Si un equipo o el servidor falla y pierde sus archivos, existen copias en los otros equipos.
Es posible trabajar remotamente sin necesidad de preocuparse por nada, excepto porder acceder a la red de comunicaciones (en este caso se supone que es internet).
Aún sin una conexión, se puede realizar todos los cambios que se desee, y éstos se actualizaran en el resto de los nodos de trabajo (equipos, servidor, etc) cuando haya una conexión disponible.

La desventajas principales son:

Se requiere una buena política de versionado y posiblemente backups para evitar que un equipo realice modifiaciones indeseables (borrado de archivos, actualizaciones erroneas, etc)
Si no se cuenta con una conexión a la red de comunicaciones, no se pueden actualizar los archivos de forma indemdiata.

Espero que ésto les sea de utilidad.

Avances de UML: Modelado en Colores (Parte 1)

2009-04-29T11:54:00.000-07:00

UML tal y como se lo usa en la mayoría de lo casos, nos permite mantener un nivel de abstracción que elegimos nosotros mismos. Y lo elegimos según cual sea el nivel de detalle que nos interese percibir en un determinado modelo. Por ejemplo, en una clase de análisis, no nos importa conocer el tipo de dato que un atributo puede tener; con saber con el atributo existe nos basta; e incluso, si nos abstraemos más aún, podemos lograr que ese mismo atributo sea totalmente irrelevante, a tal punto que desaparezca por completo de la clase (aunque cuidado, para niveles menores de abstracción, éste seguirá existiendo).

Técnicas de abstracción hay muchas, y más de una vez nosotros mismos tenemos nuestras propias formas “simplificar un modelo” aún sin pretenderlo conscientemente.

Como ejemplo, en UML, podemos agrupar los elementos que se pueden manipular como un todo en los llamados paquetes. Y esto, nos permite concentrarnos en el paquete como una sola cosa, y no como los muchos componentes que puede contener. Esto es realmente útil cuando tenemos demasiados elementos para analizarlos todos en detalles, y más aún, cuando algunos de esos elementos no los queremos analizar en detalle.

Utilizar paquetes, es sólo una forma de abstraernos de algunos aspectos del dominio. Seguramente existen muchas otras, pero sin duda una de las más interesantes, tiene que ver con el uso de colores en los diagramas de UML.

Peter Coad, Eric Lefevre y Jeff De Luca realizaron investigaciones sobre este último punto: el uso de colores para el modelado de sistemas. El lenguaje que utilizaron para “colorear” fue el Lenguaje Unificado de Modelado (UML). El resultado de estas investigaciones, es una notable técnica, que nos permite identificar a simple vista, los distintos tipos de elementos que existan en un dominio de negocio dado, y además nos permite saber qué tipos de elementos son. A este “tipo de elementos” ellos les llamaron: arquetipos. (“archetypes”, en inglés). En su libro “JAVA Modeling COLOR with UML” ([Coad99]) explican con detalle ésta técnica.

Esta técnica de coloreado nos permite analizar un modelo y entenderlo rápidamente por encima. El hecho de usar color en un modelo –por ejemplo, en un diagrama de clases- no da una perspectiva general de cómo está conformado el modelo, aún antes de mirarlo con detalle, porque como veremos más adelantes, estos modelos siguen un patrón genérico llamado “Componente de Dominio Neutral” (Domain-Neutral Component).

Esta técnica, además de ayudar a quién examina un modelo, también ayuda a diseñar modelos. Esto es así porque si tenemos en cuenta que los procesos de negocio siguen ciertos patrones (algo que Coad y los otros notaron), entonces se puede armar un modelo con sólo identificar las partes del dominio donde se pueden ajustar esos patrones.

(continuará..)

¿Generalizacion o Inclusion? Esa es la cuestion.

2009-03-26T23:58:00.000-07:00

Esta pregunta surgió en un curso de Diseño de Sistemas, en tanto la profesora pretendia poner a prueba los conocimientos conceptuales supuestamente adquiridos por los alumnos en el curso anterior de Analisis de Sistemas. Todos tiraban ideas, pero costo un buen tiempo entre los cincuenta alumnos llegar a una conclusion importante.

Podemos imaginarnos el siguiente diagrama de Casos de Uso. Si la descripcion del sistema dice que “los pacientes pueden internarse por obra social o de forma particular”, es casi evidente –intuitivo incluso- pensar en una especialización de un caso mas general denominado “Internar”. Algo así:

Esto a simple vista nos resulta correcto, aceptable y hasta tipico y seguimos adelante. Pero la pregunta que podria surgirnos es. ¿Por que especializamos? ¿Por que no incluimos? Es decir, ¿estaria mal el siguiente diagrama?

Que diferencia presenta con el anterior, si ambos pueden hacer exactamente lo mismo. Para asegurarnos de esto, recordemos que es una generalizacion y que es una inclusion.

Inclusion: Es una forma de interaccion, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es util para extraer comportamientos comunes desde multiples casos de uso a una descripcion individual, desde el caso de uso que lo incluye hasta el caso de uso incluido. El comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parametros o valores de retorno.

Generalizacion: Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. Esto se asemeja al concepto orientado a objetos de sub-clases. En la practica puede ser util generalizar comportamientos comunes, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados. Entonces la Generalizacion es la actividad de identificar elementos en común entre conceptos y definir las relaciones de un concepto general y un concepto especializado. Es una manera de construir clasificaciones taxonomicas entre conceptos.

Ya tenemos definidos ambos tipos de relaciones. Las definiciones parecen indicar que estos conceptos son bastante diferentes el uno del otro, y, de hecho los son, pero ¿donde radica la diferencia en el ejemplo dado? Es posible implementar un sistema usando el modelo con generalizacion, y funcionaria de la misma manera que si se implementara el modelo de inclusion.

En el primero, el paciente va a internarse activando el CU “Internar”. Supongamos que el paciente tiene una obra social: entonces el C.U. que se activa es “Internar con Obra Social” aplicando los pasos generales de “Internar” y en el punto indicado se siguen los pasos que pertenecen a la especializacion que, en este caso, se es “Internar con Obra Social”.

En el segundo modelo, el paciente activa directamente el caso de uso “Internar con Obra Social”, el cual realizara los pasos referidos a una internación con obra social llamara al caso de uso “Internar” en el momento que deba realizar los pasos generales.
Como vemos, ambos funcionan sin problemas. La pregunta –insisto- es: ¿porque el segundo no se utiliza?

Dejo abierta la pregunta para quien quiera pensarlo un poco.
Saludos.

Restar fechas en C#

2008-10-02T16:33:00.000-07:00

Para comprobar el vencimiento de una fecha, es una buena idea usar la clase TimeSpan que provee la plataforma .NET. En mi caso, estoy usando la fecha de vencimiento del tipo DateTime, con lo cual en un princpio tuve problemas para hacer una resta de esa fecha con la fecha actual.

Foreando encontré varias propuestas que al menos a mi, no me funcionaron, ya que intentaban usar el metodo Substract de la clase DateTime, con un parametro DateTime; y esto no es posible porque -según mi compilador- no podia convertir DateTime en TimeSpan. Lo extraño, es que este metodo esta sobrecargado para aceptar ambos tipos de datos...

Pero en fin, una manera sencilla -y a mi gusto muy prolija- de hacerlo, es implementando un metodo al que podemos llamar, por ej, ObtenerDias y que le pasemos como argumento dos fechas (de tipo DateTime). Lo que nos devuleve es la diferencia en días entre dichas fechas. ( Obviamente, bien podría ser la diferencia en meses, años, segundos etc..)


public double ObtenerDias( DateTime Fecha1, DateTime Fecha2)
{
        TimeSpan T1, T2;
        double diff;

        T1 = new TimeSpan( Fecha1.Ticks );
        T2 = new TimeSpan( Fecha2.Ticks );

        diff = ( T1.Substract(T2) ).TotalDays;

        return diff;
}

La clase TimeSpan tiene la propiedad 'Ticks' como unidad de medida. Solo obtenemos los ticks de cada fecha, los restamos y mediante la propiedad TotalDays obtenemos la cantidad total de días entre ambas fechas. Logicamente se puede obtener TotalYears, TotalMinutes, etc.. Pero hay que tener cuidado con la propiedad 'Days' que no es lo mismo que 'TotalDays', ya que Days solo mide la cantidad de dias que corresponden al mes del año de la diferencia entre ambas fechas.. Por ejemplo:

si TotalDays = 35, entonces Days = 4 debido a que los 31 dias anteriores, corresponden al mes anterior y no se cuentan en el mes del ultimo de los 35 dias.

Me agradaría saber si esto les ha resultado de interés y si les ha servido. Saludos!