La luna ilumina por igual a culpables e inocentes

Cómo utilizar el API de Paypal en Java (III)

2011-09-09T22:43:00.004Z

4. Poniendo el código en el proyecto

He creado un sencillo proyecto con un único paquete y he puesto en él los dos ficheros de código generados por el wizard de Paypal. Como se puede ver tienen algunos fallitos, pero nada que sea difícil de corregir.

Vamos a empezar añadiendo al código el botón de pago por Paypal (creado por el wizard). Cuando el cliente pulsa este botón, significa que quiere pagar mediante Paypal, así que tendremos que hacer la operación SetExpressCheckout.

Por no complicar el ejemplo, utilizaré el formulario vacío creado por el wizard. He añadido el formulario al servlet EjemploPaypalServlet y he modificado la URL de la etiqueta action del formulario. El código completo se muestra a continuación.

package ejemplopaypal;

import java.io.IOException;
import javax.servlet.http.*;

@SuppressWarnings("serial")
public class EjemploPaypalServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
HttpSession session = req.getSession(true);
session.setAttribute("Payment_Amount", "30.00");

resp.setContentType("text/html");
resp.getWriter().println("-- Código del formulario aquí --");
}
}

Al pulsar el botón, se ejecutarà el código que invoca la operación de la API que ya generó el wizard (archivo expresscheckout.java), pero hay que modificar este archivo un poco para que funcione.

Además, se ha añadido al servlet una variable de sesión que guarda el total del pedido que facturará Paypal.

5. Operación SetExpressCheckout

El archivo expresschecout.java es un Servet que realiza una operación utilizando los métodos del paypalfunctions.java, en concreto, el método: CallShortcutExpressCheckout (paymentAmount, returnURL, cancelURL);

Lo primero que tenemos que hacer es añadirle la declaración del paquete. En mi caso es esta: package ejemplopaypal;
Una vez añadida esta línea, el código ya no da más errores sintácticos.
Para poder invocar a CallShortcutExpressCheckout necesitamos tres parámetros: la cuantía total de la factura, la URL a la que paypal nos enviará si el cliente confirma el pago y la URL la que nos enviará si surge un error. Los dos últimos parámetros ya los tenemos bien configurados gracias a las URLs que pusimos en el wizard.
La cantidad, se toma de una variable de sesión de tipo String con clave Payment_Amount. Ya vimos en el código de EjemploPaypalServlet como ponerlo.

Para aprender un poco como funciona Paypal, os aconsejo que hagáis una modificación al código para que os muestre todo lo que Paypal responde al invocar al método CallShortcutExpressCheckout . Para eso, podemos modificar el código del archivo expresscheckout.java) añadiendo las siguientes líneas:

// Buscar esta línea
HashMap nvp = ppf.CallShortcutExpressCheckout (paymentAmount, returnURL, cancelURL);

//* -- Añadir
for (Object o: nvp.entrySet()) {
Map.Entry e = (Map.Entry)o;
System.out.println(e.getKey() + ": " + e.getValue());
}

String strAck = nvp.get("ACK").toString();

Nota: Google Application Engine soporta las sesiones de Servlets, pero este soporte no está activdo por defecto. Para que funcione es necesario añadir la etiqueta sessions-enabled con un valor a true

Aún no podemos ejecutar el sistema, ya que paypalfunctions tiene errores que hay que corregir. Eso es justo lo que haremos a continuación.

Cómo utilizar el API de Paypal en Java (II)

2011-08-30T08:54:00.004Z

2.5. Creando una tienda de prueba

Antes de continuar, vamos a crear una cuenta vendedora para usarla en nuestro ejemplo. Lo primero es ir al sandbox (https://developer.paypal.com/) y hacer login con el usuario y clave que registrado en el paso anterior (ver la primera entrada de este tutorial).

Allí, vamos a l opción API Credentials y creamos una nueva cuenta asegurándonos que es una cuenta de tipo vendedor (Seller). Cuando tengamos el código hecho, comprobaremos que nuestra cuenta compradora ha pagado y nuestra cuenta vendedora ha recibido el dinero. Pero eso será al final del tutorial.

Una vez hecho esto, veremos los datos que necesitamos para acceder a la API. Vamos a copiarlos que los necesitaremos más adelante. Un detalle, comprobad que las cuentas están enabled, si alguna os aparece como disable, pulsad en esa misma palabra (“disabled”) para activarla.

3. Creando el código con el wizard de Paypal

Por suerte, Paypal puede generar el código que necesitamos gracias a su wizard. La URL es: https://www.paypal-labs.com/integrationwizard/

En el wizard, elegimos la opción 1, así crearemos el código necesario para el flujo de Express Checkout (consulta la documentación de desarrolladores de Paypal, ahí viene bien explicado).

En cuanto a lenguaje, elegimos “Java SDK”, como URLs yo usaré: http://localshost:8888/sucess y http://localshost:8888/cancel. Si tu contenedor de Servlets (Tomcat, Jetty, etc.) está configurado para usar una URL distinta, usa dicha URL.
Ahora, copia el código HTML generado y guárdalo.

Copia los dos archivos .java y guárdalos también. Veamos lo que son. El archivo expresscheckout.java es el servlet que ejecuta la primera operación del API SetExpressCheckout y redirige al servidor de Paypal. El archivo paypalfunctions.java es un objeto que contiene métodos para invocar operacons del API de Paypal que vamos a necesitar.

S quieres puedes continuar generando el código para elr estod e los psos. Pero, con lo que ya tenemos, podemos montar la primera operación (SetExpresscheckout) e, incluso, las otras dos operaciones escirbiéndo algo de código por nosotros mismos.

Si quieres puedes continuar generando el código para el resto de los pasos. Pero, con lo que ya tenemos, podemos montar la primera operación e, incluso, las otras dos operaciones escribiendo algo de código por nosotros mismos.

Manos a la obra (en la siguiente entrega).

Cómo utilizar el API de Paypal en Java

2011-08-27T09:29:00.003Z

El objetivo de este tutorial es crear un sistema Java muy básico que sea capaz de realizar un pago utilizando Paypal. Nuestro sistema se conectará con Paypal, le dirá lo que tiene que cobrar, nos enviará a la página de Paypal y recibirá el resultado de la operación.

Lo que necesitas para seguir este tutorial es el J2EE de Java (cualquier versión vale), ya que en este tutorial usaremos Servlets. Además, necesitarás un servidor capaz de ejecutar los Servlets. Cualquier Tomcat o Jetty debería servir. En mi caso concreto he utilizado Google Application Engine, no por nada en especial sino porque es lo que tengo más a amno ahora.

Empezamos.

1. Un poco de teoría

Lo que vamos a implementar es un pago express, o express checkout, el cuál es uno de los servicios que Paypal ofrece. Para hacer este pago sólo tenemos que hacer tres operaciones con (y una de ella no es obligatoria). Veámoslas:

SetExpressCheckout: Prepara un nuevo pago. La llamaremos justo antes de enviar a un cliente a Paypal. El servidor nos devolverá el token que identifica el pago.

GetExpressCheckout (opcional): Nos permite obtener información sobre el cliente.

DoExpressCheckoutPayment: Concluye y confirma el pago.

Para comunicarnos con Paypal (y hacer las tres operaciones anteriores) tenemos dos opciones, utilizar la API NVP y la API SOAP. NVP son la siglas de Name-Value Pair (par clave-valor) y eso es exactamente en lo que consiste, en construir conjuntos de pares clave valor, con la información que Paypal necesita y mandárselo. En este ejemplo usaremos la API NVP.

2. Creando un usuario de sandbox

Para hacer pruebas necesitamos usuarios de prueba: un usuario que represente la tienda a la que pagamos y usuarios que representen los clientes que hacen el pago. Algunos de ejemplos ya vienen configurados para hacer pagos a una tienda imaginaria, así que vamos a empezar creando un cliente imaginario. Este cliente será el que usemos en Paypal para pagar. Para crear los clientes de pruebas podemos usar esta URL https://developer.paypal.com/

La manera de trabajar es registrarnos en el sandbox para, mediante nuestra cuenta, generar los usuarios de prueba que necesitemos. El proceso no es complejo. La cuenta de correo debe ser auténtica ya que nos mandarán un mensaje para activarla.

Una vez activa, entramos con nuestro correo y contraseña y ya podemos crear nuestra primera test account. En mi caso he creado una cuenta de comprador (buyer) preconfigurada

Ojo que las cuentas se crean con el mismo dominio que la dirección e correo original y variantes aleatorias. Con este método se pueden crear todas las que se quieran.

Ahora sí vámonos de cabeza al código.

Continuará en un par de días.

Nueva página sobre Test-Driven Development y testing: www.portaltdd.org

2011-08-09T10:22:00.002Z

Actualizo este blog para comentar que estoy participando en la página Portal TDD (www.portaltdd.org)

El objetivo de este portal es publicar referencias a toda la información que aparece en Internet sobre Test-Driven Development y pruebas del softwareen general.
También queremos publicar artículos prácticos y, más adelante, intentar organizar encuentros y promover reuniones para intercambiar experiencias.

Espero veros por allí.

Un saludo.

Seguridad en aplicaciones web y modelos de navegación

2008-07-31T22:01:00.001Z

Saludos.

Recientemente, por motivos de trabajo, ha caído en mis manos un manual de buenas prácticas de seguridad para el desarrollo de aplicaciones. Después de ojearlo me han pedido unas ideas de cómo poder evaluar que, en el proceso de desarrollo de una aplicación, se está poniendo en práctica todo lo que viene en dicho manual.

Pensando en ello me ha vuelto a quedar patente la importancia, sobre todo en aplicaciones web, de contar con buenos modelos de referencia y, sobre todo, con un buen modelo navegacional. Un modelo navegacional representa (como no puede ser de otra manera) la navegación del sistema. Cuando hablo de navegación no hablo de en qué pantalla estoy y a qué otra pantalla puedo ir. Eso vendrá más adelante y es solo una parte de la navegación.

Los modelos de navegación con los que trabajo (más información en www.iwt2.org), y muchos otros propuestos por empresas e investigadores, son el pegamento de modelos de información, funcionales y de actores / roles, junto con algunos añadidos más.

Un buen modelo navegacional nos dice con precisión cuáles son los actores / roles que interactúan con la aplicación y qué funcionalidad (por ejemplo definida mediante casos de uso) tiene disponible cada uno, qué información y qué campos de dicha información es accesible para cada actor y qué información no lo es (por ejemplo definida mediante prototipos de visualización o diagramas de clases conceptuales), y, por supuesto, a qué otras secciones de la aplicación pueden acceder o no. Todo esto combinado con información sobre validaciones, permisos, etc. incluida en los requisitos funcionales (por ejemplo mediante los mecanismos de precondiciones y postcondicione sutilizados por muchos autores) nos proporcionan abundante información de seguridad
Por supuesto, luego habrá muchas más reglas a tener en cuenta en diseño y en codificación (verificación de parámetros y controles de seguridad en todas las capas, almacenamiento de información encriptada, etc.), pero ya contamos con una buena base de seguridad en nuestros modelos sin necesidad de realizar ninguna inversión en herramientas o técnicas específicas de seguridad.

A divertirse.

Extendiendo PMD con nuevos renderers

2008-07-16T07:46:00.001Z

PMD es una herramienta de verificación que código Java que permite aplicar un conjunto de reglas (actualmente tiene aproximadamente 240 reglas) y generar un informe con los resultados. En una entrada anterior (http://rincew.blogspot.com/2008/02/escribiendo-reglas-en-pmd.html) conté como escribir una nueva regla. En esta entrada voy a dar unas ideas de cómo desarrollar un nuevo informe de resultados.

Los encargados de procesar los resultados de la verificación se llaman renderers. PMD trae un conjunto de renderers ya construidos para mostrar los resultados como texto, o como HTML, o CSV, o XML. Es útil crear un renderer propio cuando se quiere hacer un procesado adicional, cuando queremos generar un nuevo tipo de resultado, por ejemplo un informa en RTF o añadir el resultado a una BBDD, o cuando queremos ampliar alguno de los renderers ya existentes para incluya información adicional. Hay que recalcar que todas las acciones anteriores pueden hacerse e otra manera, por ejemplo utilizando transformaciones XSLT o las opciones de importación de CSV de la mayoría de sistemas de BBDD.

En PMD, un renderer es una clase que implementa la interfaz Renderer del paquete net.sourceforge.pmd.renderers. Esta interfaz permite que un rederer se comporte como una máquina de estados. Al inicializar el renderer se invoca el método start(), cada vez que se ha aplicado un nuevo conjunto de reglas se invoca al método renderFileReport(Report report) y una vez que se ha acabado el proceso se invoca al método end(). Existen más métodos en esta interfaz, sin embargo no será necesario utilizarlos en este ejemplo.

Como es habitual en muchas librerías y herramientas, PMD ya ofrece una implementación base de esta interfaz en la clase AbstractRenderer (que se mantiene por motivos de compatibilidad con versiones antiguas). A pesar de su nombre, esta clase no es abstracta ni ninguno de sus métodos son abstractos. Tampoco usaremos esta clase como base para los renderers, en su lugar utilizaremos su hija OnTheFlyRenderer, la cuál sí tiene tres métodos abstractos: start, renderFileViolations y end. El funcionamiento de start y end es el mismo que el definido anteriormente, sin embargo, para cada conjunto de reglas, el método invocado será el método renderFileViolations(Iterator violations)

Este método, recibe un iterador con todas las violaciones detectadas para un conjunto de reglas concreto. Una violación es un objetivo de una clase que implementa la interfaz IRuleViolation. A partir de los métodos get de esta interfaz podemos conocer toda la información que PMD maneja del error como el nombre del archivo (método getFilename), la clase y el método de la violación (getClassName y getMethodName), etc.
Además, también podemos obtener toda la información referente a la regla que se ha incumplido con el método getRule. Este método devuelve un objeto que implementa la interfaz Rule y que tiene varios métodos get para conocer el nombre de la regla (getName), su prioridad (getPriority), etc.
A modo de ejemplo, a continuación se muestra un nuevo renderer que también genera una salida de texto plano pero con una información distinta y un orden distinto al renderer de texto que viene de serie en PMD.


import net.sourceforge.pmd.IRuleViolation;
import net.sourceforge.pmd.PMD;
import net.sourceforge.pmd.renderers.OnTheFlyRenderer;
import java.io.IOException;
import java.io.Writer;
import java.util.Iterator;

public class RendererTexto extends OnTheFlyRenderer {

 
    public void start() throws IOException {
       
    }

    public void renderFileViolations(Iterator violations) 
            throws IOException 
    {
        Writer writer = getWriter();
        StringBuffer buf = new StringBuffer();
        
        while (violations.hasNext()) {
            IRuleViolation rv = violations.next();
            buf.append(PMD.EOL);
            buf.append(rv.getFilename());
            buf.append(':');
            buf.append(Integer.toString(rv.getBeginLine()));
            buf.append('\t');
            buf.append(rv.getRule().getName());
            buf.append(": ");
            buf.append(rv.getDescription());
            
            writer.write(buf.toString());
        }
    }

    public void end() throws IOException {
        getWriter().write("Ok.");
    }

}

Como heredamos de OnTheFlyRenderer solo nos tenemos que preocupar de los tres métodos antes mencionados. En concreto, en el método start no hemos nada. En el método renderFileViolations recorremos cada una de las violaciones mostrando el nombre del fichero y la línea donde ocurre, el nombre de la regla y su descripción. En el método end escribimos la cadena de texto Ok para indicar que el proceso terminó con éxito.
Por último, será necesario indicar a PMD que utilice el nuevo renderer. Para ello es necesario que la clase esté disponible en el classpath del PMD (por ejemplo poniendo el nuevo renderer en una archivo jar y modificando el archivo pmd.bat para que añada dicho jar al classpath en cada ejecución).
Una vez hecho, solo es necesario indicar el nombre de la clase (indicando su paquete) como segundo parámetro. Por ejemplo, si la clase mostrada más arriba está guardada en el paquete pmdext, para utilizar habría que escribir:


PMD c:\src pmdext. RendererTexto basic

Con la línea anterior se verificarían todas las reglas de conjunto de regla basic en todo el código Java dentro de la carpeta src.
En verdad, el mundo de los renderes en PMD es un poco más complejo, ya que no hemos hablado de los writers (aunque se usan en el ejemplo de más arriba). Además, el report no solo nos informa de las violaciones de las reglas sino de los errores que han podido seguir a la hora de procesar un archivo o de las supresiones, es decir, bloques de código marcados para ser ignorados por PMD.
Sin embargo, con estas nociones básicas no es difícil estudiar el código de la clase OnTheFlyRenderer y ver los detalles que no hemos mencionado.
Como comentario final, quiero mencionar que el diseño del mecanismo de renders de PMD no es todo lo bueno y homogéneo que pudiera ser, por suerte es bastante sencillo de usar. Ya se ha anunciado que para la versión 5 se van a hacer cambios de código importantes y se va a romper la compatibilidad hacia atrás, por lo que tengo esperanzas de que mejoren este mecanismo.

Como aplicar inclusiones y extensiones a las plantillas de casos de uso

2008-03-21T14:38:00.003Z

Saludos.

Muchos de nosotros utilizamos diagramas UML de casos de uso (ver más abajo) y, además, definimos cada caso de uso con plantillas de texto (ver más abajo). Sin embargo, en más de una ocasión ambas representaciones no son consistentes, es decir, hay una información en una de las representaciones que no está en la otra. Esto pasa, por ejemplo, a la hora de definir relaciones de inclusión y extensión. Ambas se definen en los diagramas de casos de uso pero casi nunca se incluyen en las plantillas.
A continuación expongo cómo incluyo yo dichas relaciones en mis plantillas para que sean consistentes con lo que se cuenta en el diagrama de casos de uso.
Como una inclusión debe realizarse siempre, la coloco en la secuencia principal, esto es, en los pasos que se ejecutan salvo algún error o circunstancia anómala. Con esto, además, estoy indicando en qué momento debe realizarse otro caso de uso.
Una excepción, por el contrario, puede realizarse o no dependiendo de una condición (llamada punto de extensión). Si bien los puntos de extensión pueden añadirse a los diagramas de casos de uso en la mayoría de herramientas, yo no suelo hacerlo porque, en cuanto hay más de uno, ya no se sabe qué punto de extensión corresponde a cada extensión. En cambio, añadirlo a la plantilla es muy sencillo. Sólo hay que colocar el punto de extensión y el caso de uso a realizar como un paso de la secuencia alternativa. Si los pasos de la secuencia alternativa están asociados a pasos de la secuencia principal entonces, además, estamos indicando en qué momento concreto debe evaluarse el punto de extensión para decidir si se realiza la extensión o no.
Veamos un ejemplo imaginario. Teneos el caso de uso dar de alta nuevo proyecto, en el cuál, además de introducir la información de cada proyecto, debemos indicar el supervisor del proyecto y el grupo de trabajo encargado. Un proyecto debe tener siempre un encargado, y el comportamiento para seleccionar uno lo definiremos en otro caso de uso. Además, si no encontramos un grupo de trabajo adecuado, podremos crear un nuevo grupo sobre la marcha (mediante otro caso de uso). Con todo esto tenemos tres casos de uso, una inclusión y una extensión. El diagrama correspondiente se muestra a continuación.

Veamos ahora la plantilla del caso de uso dar de alta un nuevo proyecto. Esta plantilla ha sido simplificada al máximo para este ejemplo.

Como se puede observar, las inclusiones y extensiones indicadas en el diagrama de casos de uso también están en la plantilla. Además, se ha indicado información adicional (cuando aparecen las relaciones, cuál es el punto de extensión de la extensión) de manera clara y sencilla sin necesidad de complicar el diagrama de casos de uso.

Feliz semana.

Uso de ant y CPD

2008-02-22T12:43:00.002Z

La herramienta de detección de copy&paste de PMD (http://pmd.sourceforge.net/) permite detectar fragmentos de código copiados. Esta herramienta, al igual que PMD, también incorpora una tarea ant para poder ser invocada desde dicha herramienta. Sin embargo, no está tan documentada como la tarea ant para CPD. Un ejemplo de su uso se muestra a continuación.

Como cuenta de tokens se ha elegido 50 para que detecte bloques de código repetido de entre 5 o 6 líneas ( si tienen muchos caracteres) hasta 10 u 11 líneas (si tienen pocos caracteres).

(La captura de pantalla está tomada de Microsoft Word, por eso aparecen algunas palabras subralladas).

Escribiendo reglas en PMD

2008-02-14T18:19:00.005Z

Saludos.

PMD (http://pmd.sourceforge.net/) es un programa para la verificación estática de código Java. PMD contiene bastantes reglas de programación (como no utilizar variables ni muy cortas ni muy largas o no anidar una sentencia if dentro de otra) y su función es buscar qué fragmentos de código incumplen dichas reglas.

A continuación veremos cómo añadir una nueva regla a PMD. Esta herramienta ofrece dos alternativas para las nuevas reglas: implementarlas como código Java o mediante XPath. En este ejemplo usaremos la segunda alternativa. La regla a implementar será: no se permiten genéricos de tipo Object, es decir, no se permiten declaraciones como List[Object] o Set[Object] (uso corchetes en vez de los símbolos de mayor y menor). Puede que esta regla no sea muy útil ya que el declarar genéricos que contienen Objects es tan poco práctico que difícilmente alguien lo va a usar, pero es un buen ejemplo.

Lo primero que tenemos que hacer es ejecutar la herramienta de diseño de reglas que viene con PMD (la propia herramienta viene con un script para ejecutarla). Después, escribimos un fragmento de código que incumpla la regla (como el de la figura 1) y generamos su árbol de sintaxis abstracta (muy similar a un documento XML).

Figura 1.

Ahora, tenemos que escribir una expresión XPath que encuentre sólo aquellos nodos del árbol que incumplen la regla. Para ello, tenemos que buscar aquellas declaraciones de tipo clase o interfaz con un argumento que es un tipo clase object (se puede ver un ejemplo en la figura 1)

Una posible expresión en XPath se muestra a continuación: //ReferenceType/ClassOrInterfaceType/TypeArguments/TypeArgument/ReferenceType/ClassOrInterfaceType[@Image='Object']

Para probarla, la escribimos en el cuadro de la parte superior derecha y la ejecutamos. En el cuadro que está justo debajo vemos las líneas del código Java que incumplen la regla. En la figura 1 se puede observar como la expresión detecta toda las líneas que declaran un genérico de tipo Object.

Para poder utilizar esta regla debemos incluirla en un ruleset, el cuál es un archivo XML que define un conjunto de reglas a verificar. Para no modificar ninguno de los archivos de PMD vamos a crear un nuevo ruleset. La cabecera se muestra a continuación.

[ruleset name="My custom rules" xmlns="http://pmd.sf.net/ruleset/1.0.0" nonamespaceschemalocation="http://pmd.sf.net/ruleset_xml_schema.xsd" schemalocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd" xsi="http://www.w3.org/2001/XMLSchema-instance"]

….

[/ruleset]

(De nuevo uso corchetes en vez de los símbolos de mayor y menor).

La propia herramienta de diseño de reglas es capaz de generar el código XML de la regla. Dicho código (figura 2) debe incluirse entre las etiquetas ruleset.

Figura 2.

Ahora, ya es posible utilizar nuestro ruleset como parámetro de PMD para que aplique la regla que hemos definido.

Combinando el modo grabar/reproducir con el modo API de código de Selenium

2006-10-30T15:01:00.000Z

Saludos.

Selenium (http://www.openqa.org/) es una herramienta open-source estupenda para realizar pruebas de sistema / aceptación de aplicaciones web. Selenium incluye una herramienta que se integra con Firefox y que permite grabar todo lo que hagamos con Firefox, guardarlo en un archivo, y reproducirlo después. Además, Selenium también incluye la posibilidad de escribir nuestras pruebas directamente en Java, C#, Python y Ruby.

Para un proyecto real, estábamos muy interesados en utilizar Selenium y su herramienta para grabar / reproducir pruebas. Sin embargo, queríamos hacer dos cosas que no se pueden hacer con la filosofía de grabar / reproducir: la primera es añadir código adicional que compruebe el estado de la aplicación y el estado de la base de datos y la segunda ejecutar todas las pruebas grabadas automáticamente cada cierto tiempo.

Por suerte el código de una prueba cuando se graba es muy similar al código que habría que escribir en un lenguaje, por ejemplo en Java o CSharp. A continuación incluyo el código de una sencilla prueba

Código 1. Prueba grabada con Firefox.


class NewTest
  def test_foo
    open "/links_jsp/Default.jsp"
    assertTitle "Links"
    clickAndWait "//a[contains(@href, 'LinkNew.jsp')]"
    assertTitle "Links"
    type "name", "Prueba"
    type "link_url", "Prueba"
    type "description", "URL de prueba"
    clickAndWait "//input[@value='Insert']"
    assertTitle "Links"
  end
end

Código 2. Prueba escrita en Java


import com.thoughtworks.selenium.*;
import junit.framework.*;


public class Selenium_InsertarEnlace extends TestCase {

    private Selenium sel;

    public void setUp() {
        sel = new DefaultSelenium("localhost",
            4444, "*firefox", "http:/localhost:8080");
        sel.start();
    }
    
    public void testInsertarEnlace() {
        sel.open("/links_jsp/Default.jsp");
        assertEquals("Links", sel.getTitle());
        sel.click("//a[contains(@href, 'LinkNew.jsp')]");
        sel.waitForPageToLoad("5000");
        sel.type("name", "Prueba");
        sel.type("link_url", "Prueba");
        sel.type("description", "URL de prueba");
        sel.click("//input[@value='Insert']");
        sel.waitForPageToLoad("5000");
        assertEquals("Links", sel.getTitle());
    }
    
    public void tearDown() {
        sel.stop();
    }
    
    public static void main(String[] args) {
      junit.textui.TestRunner.run(new TestSuite(Selenium_InsertarEnlace.class));
    }
}

Código 3. Prueba escrita en CSharp


using Selenium;
using NUnit.Framework;
namespace MyTests {
    [TestFixture]
    public class Selenium_InsertarEnlace {
        private ISelenium sel;
        
        [SetUp]
        public void SetUp() {
            sel = new DefaultSelenium("localhost",
                4444, "*firefox", "http:/localhost:8080");
            sel.Start();
        }
        
        [Test]
        public void testGoogle() {
            sel.Open("/links_jsp/Default.jsp");
            Assert.AreEqual("Links", sel.getTitle());
            sel.Click("//a[contains(@href, 'LinkNew.jsp')]");
            sel.WaitForPageToLoad("5000");
            sel.Type("name", "Prueba");
            sel.Type("link_url", "Prueba");
     sel.Type("description", "URL de prueba");
                 sel.Click("//input[@value='Insert']");
            sel.WaitForPageToLoad("5000");
            Assert.AreEqual("Links", sel.getTitle());
        }
        
        [TearDown]
        public void TearDown() {
            sel.stop();
        }
    }
}

Para ejecutar la prueba en Java, es necesario tener en ejecución el servidor de Selenium ("java -jar selenium-server.jar") y tener en el PATH la ruta a Firefox. Al ejecutar la prueba en Java (necesitamos "selenium-java-client-driver.jar") se abrirá una nueva instancia del Firefox y, en la salida estándar veremos el resultado de la prueba. La prueba en CSharp no la hemos ejecutado, pero debería ser igual de sencillo.

Ahora es posible añadir a la prueba todas las comprobaciones adicionales que queramos como, por ejemplo, conectar con la BBDD para asegurarnos que el enlace está ahí.

Estamos escribiendo un sencillo script para traducir automáticamente el código de una prueba capturada a código Java. Si alguien está interesado no tiene más que escribirme.

Aplicaciones autoadministradas y autoreparadas

2006-10-25T15:07:00.000Z

Después de asistir a la conferencia de un gurú (o eso dijeron) de la arquitectura de software en un congreso, me llevo la idea de que el desarrollo de aplicaciones que sean capaces de administrase ellas solitas (y de paso repararse) es un buen nicho de mercado.

Esto no es, ni mucho menos, ciencia-ficción. Si no me equivoco la plataforma Java ya incorpora desde hace tiempo interfaces de monitorización de componentes bajo el nombre de JMX.

Para poder hacer esto, dado que la tecnología existe, lo que hay que hacer es plantearlo desde el comienzo del desarrollo de la aplicación e incluir en nuestra aplicación, módulos que monitoricen el funcionamiento de la misma y que tengan la capacidad de tomar las medidas correctivas necesarias. Esto puede venderse muy bien, ya que, como nos comentó el gurú, por cada dólar gastado en adquirir una aplicación (esto incluye el desarrollo a medida), se gastan nueve dólares en su administración y mantenimiento (en euros será menos, seguro). Si podemos desarrollar aplicaciones autoadministradas, podemos reducir el gasto durante toda la vida útil de la aplicación de nuestros clientes 9 veces, lo cuál es bastante interesante.

Además una aplicación que sea capaz de arreglarse a sí misma, es una aplicación que no tiene por qué detenerse nunca, lo cuál es muy beneficioso en ciertos nichos de mercado.

Presentaciones "De casos de uso a casos de prueba" en mi web

2006-10-19T14:12:00.000Z

Saludos.

He puesto en mi web el 95% de las presentaciones que voy a usar en el seminario "De casos de uso a casos de prueba" que impartiré el martes 24 en el evento SoloRequisitos. La dirección es:

http://www.lsi.us.es/~javierj/cursos.htm

Después del evento publicaré el 100% de las transparencias, aunque el 5% que falta son las menos importantes.

Feliz otoño

Eclipse. Caballo ganador en la investigación

2006-10-18T16:46:00.000Z

Saludos.

A menudo nos encontramos comparativas entre Eclipse y NetBeans y muchas veces nos da la impresión (al menos a mí) de que ambas plataformas tienen una lucha feroz por imponerse en el mundo de la empresa.
sin embargo en el mundo de la investigación y las universidades no es así. Por lo que he podido ver en un reciente congreso, todo el mundo usa Eclipse y desarrolla sus ideas a partir de Eclipse. En ese sentido, el EMF es una herramienta de uso casi inevitable. Netbeans no aparece por ningún sitio ni se le espera.

¡Dios mío, yo uso Netbeans!. ¿De dónde me puedo descargar Eclipse?.

Evitando el lado oscuro de las pruebas (y II)

2006-10-16T16:58:00.000Z

Como ya comentamos hace tiempo en este blog, las pruebas de código tipo JUnit tienen un lado oscuro. Si el código cambia, las pruebas pueden quedar inservibles, lo cuál supone un desperdicio de tiempo y recursos.

La solución que propuse fue la de intentar automatizar lo máximo posible la generación de pruebas. Así, si el código cambiaba, simpleente se volvía a ejecutar el programa que generaba un nuevo conjunto de pruebas.

Otra posible solución que se ha comentado en el taller de pruebas es la verificacón estática del código. Es decir, revisar el código para buscar errores antes de ejecutarlo. Según comentaron, las revisiones estáticas de código pueden resolver cerca de un 80% de los errores básicos. Un artículo muy bueno al respecto puede encontrase en (http://in2test.lsi.uniovi.es/pris2006/).

Feliz otoño.

Reglas para escribir buenos casos de uso

2006-09-15T07:13:00.000Z

Saludos a todos.

Desde principios de verano estoy colaborando con la empresa Icinetic (www.icinetic.com) aplicando algunas de mis ideas sobre pruebas para mejorar su proceso de fabricación de software y también desarrollando nuevos servicios.

Uno de los primeros pasos para poner en marcha un proceso de prueba es tener buenos casos de uso. Cuanto mejor sean los casos de uso, más fácil será fabricar el software y elaborar buenas pruebas. En Icinetic tienen su propio conjunto de reglas para desarrollar buenos casos de uso y, además, me han dado permiso para difundirlas. Estas reglas son:

1. El caso de uso se inicia con la acción de un actor.

2. El caso de uso tiene una precondición y una postcondición

3. Mostrar todas las excepciones posibles, así como los flujos alternativos. Al menos “datos incorrectos” y “error al guardar los datos”

4. Mantener el mismo nivel de abstracción.

5. Rastreabilidad hacia el requisito/s de información y el objetivo/s por el que se ha incluido el caso de uso.

6. Comprobar que las relaciones entre casos de uso (include y extends) sean consecuentes con diagramas de casos de uso.

7. Comprobar que los actores que inician los casos de uso sean consecuentes con los diagramas de caso de uso

8. En las eliminaciones comprobar revisando los requisitos de información si se debería eliminar más elementos en cascada. En tal caso detallarlo en la postcondición.

En general, este conjunto de reglas me parece muy bueno. A continuación incluyo los comentarios que les hice a ellos para que el conjunto de reglas fueran aún mejor.

Completamente de acuerdo con las reglas 1, 4, 6 y 8.
No estoy muy convencido de que un caso de uso deba tener siempre una precondición y una postcondición. Si no identificamos claramente una pre o postcondición vale más la pena no ponerla que forzar la situación.
Por regla general, una precondición expresa el estado que debe tener el sistema para poder ejecutar un caso de uso y una postcondición el estado en el que queda el sistema después de ejecutar un caso de uso. Por ejemplo, no se me ocurre ninguna postcondición para un caso de uso de realizar una búsqueda ya que no cambia nada en el sistema. Poner por poner es para nada.
La regla 5 puede hacerse más genérica. Es buena idea que cualquier requisito sea rastreable, y no solo los requisitos de almacenamiento de información.
La regla 7 me parece un poco ambigua. Cuando, en un diagrama de casos de uso hay más de un actor que participa en un caso de uso, no hay, que yo conozca, ninguna notación para saber cuál es el actor que comienza el caso de uso. Yo les propuse escribir esta regla de una forma más genérica: “comprobar que los actores participantes en un caso de uso son consecuentes con los diagramas de casos de uso”.

Además, les propuse añadir las siguientes reglas, la mayoría sacadas sobre todo del libro “Writting Effective Use Cases” de Cockburn.

9. Si el caso de uso se inicia por la acción de un actor, al final de dicho caso de uso el actor debe obtener un resultado (salvo que el caso de uso sea una inclusión o extensión de otro caso de uso. Entonces, probablemente, no se inicie con a acción de un actor.)
10. Comprobar que el caso de uso sea como un partido de tenis (El actor hace… El sistema hace…) y como un partido de fútbol (se sabe en todo momento qué pasa y quién lo hace)

11. Un caso de uso de 3 pasos o menos o de más de 10 pasos probablemente no sea un buen caso de uso (salvo que el caso de uso sea una inclusión o extensión de otro caso de uso).

12. Todas las acciones similares deben describirse con las mismas frases. Por ejemplo, enunciar todas las inserciones de datos con la frase “El actor X introduce los datos….”. No permitir variantes como “inserta datos”, “añade datos”, “incluye datos”, ni siquiera “introducir datos”, etc. Siempre igual, por muy aburrido que resulte.

Por cierto, la regla 12 es muy útil cuando varias personas distintas escriben casos de uso y también a la hora de utilizar herramientas software de análisis de casos de uso y de generación de pruebas.

Como resumen de todo lo visto: un buen requisito y caso de uso debe tener estas características: completo, correcto, no ambiguo, validado, verificable y rastreable.

a. Un requisito completo es aquel que lo cuenta todo, si hay un limite dice cuál es, si hay algo que hacer dice el qué, etc.

b. Un requisito correcto es aquel que está bien escrito, si faltas de ortografía, ni errores sintácticos y que, además, sigue correctamente las reglas para definir requisitos que se estén usando.

c. Un requisito validado es un requisito que ha sido visto y comprendido por el cliente (y ha dado su visto bueno).

d. Un requisito no ambiguo es aquel requisito que tiene el mismo significado para todo el que lo lea.

e. Un requisito verificable es un requisito que expresa cosas que se pueden probar. Un ejemplo de requisitos no verificables son los que dependen de que una persona haga algo determinado (llevar un paquete, comprobar que los códigos estén correctos, etc.).

f. Un requisito rastreable es un requisito que se sabe de dónde viene y se sabe a dónde va.

P.D.
Autonota. Ahora que retomo la actividad, sería buena idea terminar el curso de Cacuts, a ser posible, utilizando la herramienta Cactus.

Publicaciones en mi web.

2006-09-06T09:01:00.000Z

Saludos.

He publicado en mi web una página con referencias a todas las propuestas para probar casos de uso que conozco. El enlace es http://www.lsi.us.es/~javierj/approaches.htm

También he publicado un texto dónde se describe brevemente propuestas para especificar pruebas y para implementarlas, tanto para aplicaciones de escritorio como para aplicaciones web. El enlace es http://www.lsi.us.es/~javierj/investigacion_ficheros/EICP.pdf.

Feliz septiembre.
PD: aún está pendiente terminar la serie de pruebas con Cactus.

La desidia del verano

2006-08-18T09:16:00.000Z

Saludos a todos.

Se supone que el verano, con las vacaciones, sería una época estupendapara escribir un montón de entradas interesantes.

Pues no. La verdad es que, aunque tengo tiempo libre, en verano se apetece escribir nada. Espero volver en septiembre.

Feiz vacaciones a todos.

Un ejemplo de diseño de pruebas con Cactus (II).

2006-07-10T11:58:00.000Z

Un millón de disculpas por la tardanza, continuamos:

Necesitaremos definir los siguientes elementos para cada caso de prueba: acciones a realizar, valores de prueba, resultado esperado. Por comodidad, vuelvo a poner el comportamiento que el servlet debe tener:


1. El servlet recibe una petición de login con un nombre de usuario y una clave.
  1.1. Si el usuario ya se ha registrado, el servlet informa de ello y termina.
  1.2. Si el usuario ya lo intentó 3 veces, el servlet informa de ello y termina.
2. En caso contrario, el servlet comprueba el nombre y la clave recibida.
  2.1. Si el nombre es válido y la clave coincide, el servlet registra al usuario, informa de ello y termina.
  2.2. Si el nombre no es válido o la clave no coincide, el servlet incrementa el número de intentos e informa de ello.

Comencemos.

Las acciones a realizar serán todas las combinaciones posibles, tal y como se muestra a continuación.


c.a) 1 -> 1.1
c.b) 1 -> 1.2
c.c) 1 -> 2 -> 2.1
c.d) 1 -> 2 -> 2.2

La combinación c.a) representa el escenario en el que un usuario solicita el acceso pero ya se había validado. La combinación c.c) representa el escenario en que un usuario solicita el acceso e introduce un nombre y clave correctos, etc.

Además, estás combinaciones pueden repetirse varias veces, tal y como se muestra a continuación:


a) 1 -> 1.1 -> 1 -> 1.1 -> ... (hasta que la sesión expire)
b) 1 -> 1.2 -> 1 -> 1.2 -> ... (hasta que la sesión expire)
c) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.1
d) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.1
e) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 1.2 -> 1 -> 1.2 -> ... (hasta que la sesión expire)
f) 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.2 -> 1 -> 2 -> 2.1 -> 1 -> 1.1 -> 1 -> 1.1 -> ... (hasta que la sesión expire)

Las repeticiones de combinaciones, en principio, no las tendremos en cuenta, aunque sería interesante probar algunas, por ejemplo la c, la d, la e y la f.

Pasemos ahora a los valores de prueba. En primer lugar identificamos los valores o variables y su dominio:


Nombre de usuario (Cadena de texto)
Clave (Cadena de texto)
Número de intentos (Entero)
Está validado (Booleano)

A continuación dividimos el dominio en distintas categorías. Podemos definir, de manera informal, una categoría como un subconjunto de los valores del dominio para los cuales el sistema siempre presenta el mismo comportamiento. Algunos ejemplos de categorías se muestran a continuación:


Nombre de usuario  Correcto / Incorrecto
Clave    Correcto / Incorrecto
Número de intentos  Menor de 3 / igual a 3 *
Registrado   Cierto / Falso

*- Debemos investigar si es posible que el número de intentos sea mayor que 3 o menor que 0.

No todas las categorías pueden tomarse siempre. En general, las categorías posibles estarán restringidas por el camino que estemos probando. Por ejemplo para la secuencia c) (la secuencia de acceso correcto), el número de intentos debe ser menos que tres, el usuario no debe estar registrado y el nombre y la clave deben ser correctos. A continuación se expresan las restricciones de cada una de las combinaciones.


c.a) Registrado = Cierto.
c.b) Registrado = Falso && Numero de intentos = 3
c.c) Registrado = Falso && Numero de intentos < 3 && Nombre = Correcto && Clave = Correcto
c.d) Registrado = Falso && Numero de intentos < 3 && ( Nombre = Incorrecto || Clave = Incorrecto )

A partir de estas restricciones vamos a construir los escenarios de prueba. Un escenario de prueba es una combinación concreta, con un conjunto de valores de prueba concretos que cumplen las restricciones. Cada escenario de prueba es una prueba candidata, es decir, puede convertirse en un caso de prueba. En total, para las cuatro combinaciones del principio hemos identificado 10 escenarios de prueba:


Escenario 1:
Camino a)
Registrado = Cierto.

Escenario 2:
Camino b)
Registrado = Falso 
Numero de intentos = 3

Escenario 3:
Camino c)
Registrado = Falso 
Numero de intentos = 0

Escenario 4:
Camino c)
Registrado = Falso 
Numero de intentos = 2
Nombre = correcto
Clave = correcto

Escenario 5:
Camino d)
Registrado = Falso 
Numero de intentos = 0
Nombre = correcto
Clave = incorrecto

Escenario 6:
Camino d)
Registrado = Falso 
Numero de intentos = 0
Nombre = incorrecto 
Clave = correcto

Escenario 7:
Camino d)
Registrado = Falso 
Numero de intentos = 0
Nombre = incorrecto 
Clave = incorrecto 

Escenario 8:
Camino d)
Registrado = Falso 
Numero de intentos = 2
Nombre = correcto
Clave = incorrecto

Escenario 9:
Camino d)
Registrado = Falso 
Numero de intentos = 2
Nombre = incorrecto 
Clave = correcto

Escenario 10:
Camino d)
Registrado = Falso 
Numero de intentos = 2
Nombre = incorrecto 
Clave = incorrecto

Aún nos falta decidir cuáles de estos escenarios se implementarán como pruebas con Cactus y definir el resultado esperado de cada escenario. Eso lo veremos en la siguiente entrada, que espero que no tarde tanto como esta.

Feliz verano.

Un ejemplo de diseño de pruebas con Cactus (I).

2006-06-12T16:30:00.000Z

Saludos y disculpas por la tardanza.

Vamos a ver un sencillo ejemplo donde vamos a diseñar un conjunto de pruebas para un servlet que controla el acceso mediante nombre y clave (el login de toda la vida) y las vamos a implementar con la herramienta Cactus de Apache. Por supuesto, las ideas que veamos pueden aplicarse a otras plataformas de desarrollo web y otras herramientas.
Cactus es una herramienta que nos permite escribir pruebas para código que se ejecute en un servidor, como servlets, JSP, filtros, EJB, etc. Básicamente, una prueba escrita en Cactus se divide en dos partes: la parte cliente y la parte servidor. La parte cliente se ejecuta en nuestra máquina mientras que la parte servidor se ejcuta en el servidor. Más adelante veremos como usarla, ahora vamos a describir el problema y diseñar un conjunto de pruebas.

Vamos a probar el servlet de acceso. Lo primero que necesitamos es el funcionamiento esperado del servlet. Dicho funcionamiento se describe a continuación:

1. El servlet recibe una petición de login con un nombre de usuario y una clave.
1.1. Si el usuario ya se ha registrado, el servlet informa de ello y termina.
1.2. Si el usuario ya lo intentó 3 veces, el servlet informa de ello y termina.
2. En caso contrario, el servlet comprueba el nombre y la clave recibida.
2.1. Si el nombre es válido y la clave coincide, el servlet registra al usuario, informa de ello y termina.
2.2. Si el nombre no es válido o la clave no coincide, el servlet incrementa el número de intentos e informa de ello.

El código del servlet que vamos a probar no lo necesitamos ni para diseñar las pruebas ni para codificarlas. De todas amneras dicho código se muestra a continuación:


import javax.servlet.*;
import javax.servlet.http.*;

public class AccessServlet extends HttpServlet {
  
  private String user ="test";
  private String passwd = "test";
  
  protected void doPost(HttpServletRequest req, HttpServletResponse resp) 
    throws ServletException, java.io.IOException  
  {
    HttpSession session;
    ServletOutputStream  out;
    Boolean validUser;
    Integer numTries;
    String pUser, pPass;
    
    out = resp.getOutputStream();
    
    // 1. Obtengo la sesion.
    session = req.getSession();
    
    // 2. Miro si el usuario ya está validado
    validUser = (Boolean) session.getAttribute("validUser");
    if (validUser != null) {
     out.println(""+"Ya eres un usuario válid");
      out.flush();
      return;
    }
    
    // 3. Comprobamos el número máximo de intentos
    numTries = (Integer) session.getAttribute("numTries");
    if (numTries == null) {
      numTries = new Integer(0);
    }
    
    if (numTries.intValue() >= 3) {
     out.println("
"+"Demasiados intentos");
     out.flush();
      return;
    }
     
    // 4. Recuperamos los parámetros.
    pUser = req.getParameter("f_user");
    pPass = req.getParameter("f_password");
     
    // 5. Comprobamos si el nombre y la clave son válidos
    if ( pUser.equals(user) && pPass.equals(passwd) ) {
     session.setAttribute("validUser", new Boolean(true) );
     out.println("
"+"Eres un usuario válido");
     out.flush();
      return;
    }
     
    // 6. Si no, incrementamos en 1 el número de intentos y lo guardamos en la sesión
    numTries = new Integer(numTries.intValue()+1);  
    session.setAttribute("numTries", numTries );    
    out.println("
"+"Los datos de acceso no son válidos.");
    out.flush();
     
  }
}

Por simplicidad, se ha incluido el nombre y la clave válidos en el propio servlet. Si consultáramos con una base de datos, las pruebas que vamos a diseñar a continuación serán exactamente iguales. Sin embargo la arquitectura de pruebas (por ejemplo el setUp() de un caso de prueba) será un poco más complejo.

En la próxima entrada diseñaremos pruebas para probar este servlet y las codificaremos con Cactus.

PD: en el código de ejemplo faltan los println para las etiquetas HTML y BODI.

Extrayendo fragmentos de frases con expresiones regulares

2006-05-18T12:42:00.000Z

Saludos.

Recientemente, desarrollando unas herramientas de prueba, me he encontrado la necesidad de extraer fragmentos de frases compuestas. Lo que buscaba era poder hacer algo así. Si tengo, por ejemplo, estas dos frases.

1: El niño cogió la pelota con las manos.
2: El niño de azul cogió la pelota grande y morada con las dos manos.

Y quiero aplicar el siguiente patrón.

El $1 cogió $2 con $3

El resultado que quiero es:

1: $1 = "niño", $2 = "la pelota", $3 = "las manos"
2: $1 = "niño de azul", $2 = "la pelota grande y morada", $3 = "las dos manos"

Por suerte encontré una manera rápida y fácil de hacer esto en Java con expresiones regulares y Jakarta RegExp (http://jakarta.apache.org/regexp/index.html). Con esta herramienta escribo el patrón utilizando una expresión regular y encerrando entre paréntesis las expresiones que luego quiero recuperar. Así, el patrón anterior se expresaría de la siguiente forma:

El (.+) cogió (.+) con (.+)

El código para aplicar las frases anteriores al patrón se muestra a continuación.



import org.apache.regexp.*;

public class DemoBlog {
  
  public static void main(String[] args) {
    
    String f1 = "El niño cogió la pelota con las manos.";
    String f2 = "El niño de azul cogió la pelota grande y morada con las dos manos.";
    String re00 = "El (.+) cogió (.+) con (.+)";

    RE re = new RE(re00);
    System.out.println("Match: " + re.match(f1) );
    System.out.println("Match: " + re.match(f2) );
  }
}

El código anterior nos muestra por consola que ambas frases casan con la expresión regular.

Ahora, para extraer la parte de la frase que casa con cada una de las expresiones entre paréntesis del patrón, solo tenemos que llamar a getParen(índice), con índice = 1 para obtener el primer paréntesis e índice = 3 para el último. Por ejemplo:


    System.out.println("$1 = " + re.getParen(1) );
    System.out.println("$2 = " + re.getParen(2) );
    System.out.println("$3 = " + re.getParen(3) );

Además, índice = 0 nos devuelve todo el texto (en este caso la frase completa). Si no queremos saber a priori cuanto paréntesis tenemos, podemos ir llamando a getParen(índice) hasta que este nos devuelva null.

Las clases de expresiones regulares (java.util.regexp) que viene a partir del SE 1.4 (y que comentamos en el post de pruebas con JUnit y expresiones regulares) no permiten hacer lo mismo. O, al menos, yo no he encontrado ninguna manera de hacerlo.

También estuve mirando el proyecto ORO de Jakarta (http://jakarta.apache.org/oro/index.html), por si tuviera algo que me permitiera hacer esto mismo de una manera más potente. Pero en un primer vistazo no he visto nada interesante.

Rompiendo una lanza a favor de las empresas de informática

2006-05-08T16:25:00.000Z

Saludos.

Algunas veces escuchamos, o leemos, comentarios de que en tal o cual empresa se escriben aplicaciones deficientes y código malo. La causa principal, dicen, es la falta de tiempo. n las empresas hay que hacerlo ya, y por eso no hay tiempo para hacer una buena planificación y un buen diseño.

No creo que eso sea una buena justificación para hacer mal código. A continuación juego de abogado del diablo y expongo el por qué.

Dudo mucho que a un arquitecto le pidan el diseño de una torre o unos chalets y le digan que el tiempo no importa, que tarde lo que le apetezca. Lo mismo les pasa a los albañiles, seguro que ellos no tienen tiempo para planificar cómo van a poner los ladrillos. Sin embargo, los edificios no se caen, ni la gente deja de usarlos porque son inhabitables, ni hay que llamar constantemente a arquitectos y albañiles para que pongan parches.

A nadie se le ocurre que, por mucha prisa que haya en levantar un edificio, los albañiles comiencen a poner ladrillos por su cuenta. ¿por qué?. Pues porque los arquitectos, los albañiles, y tantos otros profesionales, saben hacerlo rápido y hacerlo bien.

Esto es algo que, según mi opinión, los informáticos aún no sabemos hacer. Si no hay tiempo para hacer un buen diseño, hay que hacer un buen diseño sobre la marcha.

Cuando escribamos el código debemos Ser capaces de identificar rápidamente las necesidades y decidir qué clases construir. Debemos tener muy en cuenta algunos conceptos de diseño fundamentes como las clases tímidas o la encapsulación (pedir a los objetos que hagan operaciones, en vez de pedirles información para hacerlo nosotros). Tampoco debemos olvidar los patrones, por ejemplo, utilizar siempre el patrón iterador (IEnumerator en .NET) para recorrer colecciones de objetos, o implementarlo para nuestras propias colecciones. Si Java y .NET o hacen, ¿por qué no nosotros?. Tampoco hay que escribir tanto código.

Desde mi opinión, la mayoría de las personas que empiezan en las empresas de informática, vengan de la universidad, de FP, de cursos de formación o autodidactas, no saben hacer estas cosas (incluso algunas que llevan muchos años si no se esfuerzan en mejorar). Aunque también tengo mi opinión de por qué pasa esto, no voy a entrar en ese debate.

Si nos formamos adecuadamente y ponemos en práctica lo aprendido nuestro código no va a ser bueno a la primera y cometeremos errores. Pero seguro que esos errores serán más pequeños y fáciles de arreglar (encapsular / desacoplar, encapsular / desacoplar, encapsular / desacoplar,....). Seguro que nuestro código es muchísimo mejor y seguro que

podremos ir convenciendo a nuestros jefes de que, si le dedicamos algo de tiempo al principio, nuestro código será aún mejor, seremos más productivos y más rápidos.

En resumen, si sabemos hacerlo bien, hacerlo rápido sólo implica pensar más rápido. Hacerlo mal nunca es hacerlo rápido.

Termino con otra opinión que, en principio, puede parecer que no tenga mucha relación pero creo que la tiene. Un sueldo bajo no debe ser excusa para hacer mal nuestro trabajo.

PD:

Por supuesto, esto es una opinión personal algo "extrema" y provocadora. Ni esto es la causa de todos los males ni su solución. Por descontado cualquier otra opinión a favor o en contra es bienvenida.

Un plan de pruebas para una aplicación gráfica.

2006-04-27T15:55:00.000Z

Saludos a todos.

Recientemente me he visto involucrado en un interesante proyecto para desarrollar una aplicación de escritorio con una interfaz gráfica en Java. Esta aplicación permitirá diseñar formularios de una manera gráfica. Estos formularios se almacenan archivos XML, son específicos de una empresa y utilizan un juego de controles predeterminados y bien documentados.

La aplicación no es vital. De hecho, sus futuros usuarios llevan ya tiempo creando y trabajando con estos formularios. Sin embargo, ahora estos formularios se construyen a mano con editores de texto. Esto presenta varios problemas: no se puede ver el resultado o los cambios a medida que se hacen y hay que conocer un número muy alto de etiquetas y atributos.

A continuación expongo un resumen preliminar de cómo creo que debe ser un plan de pruebas y, en concreto, la parte que aborda las pruebas del sistema.

Pruebas del sistema.
Las pruebas del sistema (según Métrica v3) ejercitan a fondo el sistema completo para verificar que todo funciona bien. Dentro de las pruebas del sistema se encuentran varios tipos de prueba como pruebas funcionales, de carga, de seguridad, de usabilidad, de stress, etc. En este caso, yo me voy a centrar solo en las pruebas funcionales, esto es, las pruebas que verifican que el sistema hace lo que debe hacer a través de su interfaz externa, en este sistema, una interfaz de usuario gráfica.

Lo primero que vamos a definir es qué se puede hacer con la aplicación:

1. Crear un nuevo formulario.
2. Modificar un formulario existente.
2.1. Añadir nuevos controles.
2.2. Eliminar controles
2.3. Modificar las propiedades de los controles
2.4. Modificar la posición de los controles.

Una vez definida la funcionalidad a probar, hay que determinar los valores de prueba. Estos valores de prueba son, sin duda, los formularios. Dividimos los formularios en distintas categorías.

- Formularios básicos: Un único componente.
- Formulario simples: Entre dos y cuatro componentes.
- Formularios medios: entre cinco y ocho componentes.
- Formularios grandes: entre 9 y 14 componentes.
- Formularios enormes: quince o más componentes.

También será necesario, cuando haya más información sobre el proyecto, estudiar las características de cada componente que puede haber en un formulario y decidir si es necesario diseñar pruebas específicas para probar características particulares de componentes.

Diseño de pruebas.

Ahora, se trata de combinar las operaciones y los tipos de formularios para construir pruebas. Combinando las 5 operaciones a realizar sobre un formulario con los 5 tipos de formularios posibles tenemos un total de 25 tipos de pruebas iniciales. Algunos ejemplos son:

1. Crear un formulario básico.
2. Añadir un nuevo control a un formulario medio.
3. Eliminar un control de un formulario enorme.

Estas pruebas se repetirán varias veces con distintos tipos de controles. Además, estas pruebas se combinarán entre ellas para construir pruebas mayores. Por ejemplo, si combinamos las pruebas 2 y 3 para un formulario enorme obtenemos una prueba que añade nuevos controles y después elimina otros controles ya existentes.

Estimamos que, en las primeras iteraciones, la herramienta tendrá pocas opciones y pocos controles. Así, en las primeras iteraciones deben primar las pruebas de creación de formularios básicos y simples. Por la misma razón, en las últimas iteraciones deben primar las pruebas de modificaciones de formularios grandes y enormes.

Herramientas.

Queremos usar dos herramientas para realizar estas pruebas.

La primera herramienta nos permitirá definir una secuencia de interacciones con la interfaz gráfica (mover el ratón, hacer click, etc.) y ejecutarlas sobre nuestra aplicación. Además, esa herramienta debe permitir comprobar que los resultados de las interacciones son los esperados (un cambio en la pantalla, la aparición de una nueva ventana, etc.).
En un post anterior ya hemos comentado algunas de las herramientas que podemos utilizar para implementar este tipo de pruebas en sistemas Java, tales como Marathon (http://marathonman.sourceforge.net/) o Abbot (http://abbot.sourceforge.net/).

Hemos visto que queremos construir nuevas pruebas a partir de pruebas básicas (por ejemplo una prueba que sea crear un formulario nuevo, insertar tres controles, guardarlo, cargarlo, insertar dos controles más, borrar un control, modificar otro, etc). Esto presenta algunos problemas:
1) Estas pruebas son largas de codificar (perdemos recursos) y, cuanto más largas sean, más tendremos que escribir más errores podemos tener.
2) El número de posibles combinaciones de añadidos y modificaciones es muy alto.
3) Si hay algún cambio en la interfaz o bien damos por perdidas las pruebas que nos ha constado mucho tiempo implementar, o bien las modificamos con lo que perdemos más tiempo aún.

La solución es una herramienta que coja unas pocas pruebas simples, las combine y genere tantas pruebas complejas como queramos. Existen trabajos que hablan de como combinar pruebas pero no conozco ninguna herramienta que pueda hacerlo.

Como opino que las ventajas superan a los inconvenientes, nos planteamos construir una herramienta ad-hoc para construir pruebas a partir de otras. Una vez que tengamos decida una herramienta concreta y sepamos qué formato tienen las pruebas (por ejemplo archivos de código Python o archivos XML) podremos desarrollarla.

Siguientes pasos.

Como hemos comentado al principio, esto es una aproximación preliminar. A medida que el desarrollo del sistema avance, se definan con más precisión la funcionalidad del sistema, se obtengan formularios de ejemplo por parte de los clientes, etc. Este plan de pruebas y las pruebas diseñadas se irán completando. Así, durante cada iteración se dispondrá de un conjunto de pruebas del sistema listas para verificar que todo va bien.

La información necesaria para seguir completando este plan es:
- Una descripción detallada de los componentes.
- Los casos de uso.
- Formularios, a ser posible, reales.

Ojo, las pruebas contempladas aquí no son suficientes para desarrollar una buena fase de pruebas del sistema. Además se deben probar la correcta implementación de los casos de uso (http://es.wikipedia.org/wiki/UML#Ejemplo_de_diagrama_de_caso_de_uso) del sistema. Por ejemplo, probablemente exista un caso de uso que sea cargar formulario de archivo y otro que sea guardar formulario en archivo dónde se explicará como tiene que comportarse la aplicación al realizar esas operaciones. Por tanto, debemos desarrollar también algunas pruebas que comprueben no solo que los formularios se cargar y guardan correctamente y dichas operaciones se comportan como dicen los casos de uso.

Si este proyecto sigue adelante y, además, hay la oportunidad de poner estas ideas en prácticas, os lo comentaré.

Andalucía, tierra de OpenCMS

2006-04-12T09:48:00.000Z

Saludos a todos.

En una entrada anterior comentada que, en Andalucía (al sur de España), las tencologías dominantes en la industria, sin duda, son Java y Oracle (http://rincew.blogspot.com/2005_10_01_rincew_archive.html). De un tiempo a esta parte, me he dado cuenta que varias empresas (de las más importantes, al menos en mi opninión) están utilizando OpenCMS como plataforma de desarrollo de portales (http://www.opencms.org/).

No conozco la herramienta, así que ignoro si es la mejor, pero si varias empresas importantes y la administración pública la usan, desde luego hay que tenerla en cuenta.

Referencias sobre generación de pruebas a partir de casos de uso.

2006-04-04T14:36:00.000Z

Saludos.

Para quién le interese. A continuación pongo algunos enlaces sobre documentación para generar pruebas a partir de casos de uso.

En mi página web ha puesto los reusltados de un enlace comparativo con casos prácticos:
http://www.lsi.us.es/~javierj/publications.html
(descargar "Generación de casos de prueba a partir de la especificación funcional")

En STORM es posible encontrar varias listas de herramientas de prueba. Aunque no conozco ninguna herramienta de acceso público para generar pruebas, sí
se pueden encontrar algunas herramientas muy interesante para implementar las pruebas. Se puede encontrar alguna herramienta de libre descarga para
TSL, pero está a añados luz de distancia de WinRunner.
http://www.mtsu.edu/~storm/

Algunos artículos que pueden ser interesantes. Son fáciles de encontrar en Google. Si alguien no los localiza que no dude en pedírmelos:

Axel Ruder et-al. 2004. A Model-based Approach to Improve System Testing of Interactive Applications. ISSTA’04. Boston, USA.
L. Briand, Y. Labiche. 2002. A UML-Based Approach to System Testing. Carleton University Inner Report.
Heumann , Jim, 2002. Generating Test Cases from Use Cases. Journal of Software Testing Professionals.
Nebut, C. Fleurey, et-al. 2003. Requirements by contract allow automated system testing. Procedings of the 14th International symposium of Software Reliability Engineering (ISSRE'03). Denver, Colorado. EEUU.

UCTSystem. http://www.irisa.fr/triskell/results/ISSRE03/UCTSystem/UCTSystem.html

Espero que los disfruteis.

Si alguien tiene interés en el tema y quiere más información que no dude en comunicármelo.

Materiales de cursos

2006-03-22T12:17:00.000Z

Saludos.

Estoy poniendo en mi página web materiales relacionados sobre algunos y seminarios que he tenido la suerte de poder impartir. Por si a alguien le interesa la dirección es:
http://www.lsi.us.es/~javierj/cursos.htm

Aún hay poco material. Espero ir subiendo más cosas a lo largo de estas semanas.

Nos leemos.

Trabajando con HipersonicDB

2006-03-03T10:37:00.000Z

Saludos.

Existen varias bases de datos libres implementadas en Java. Una de ellas, la que uso habitualmente, es HipersonicSQL DB (http://hsqldb.org/).

¿Por qué utilizar una base de datos pequeña escrita en Java cuando existen sistemas como MySQL, PostgreSQL o Firebird?. En mi caso, la respuesta es comodidad. Puedo distribuir junto con mis programas todo el servidor de bases de datos (sólo son 200-300 KB de más) evitando que los usuarios tengan que instalar ni configurar nada. En las primeras etapas de desarrollo es una opción muy interesante, ya que podemos tener nuestra base de datos funcionando de manera autónoma sin depender de la instalación y configuración de ningún servidor.
Además, HSQLDB es bastante completa soportando vistas, integridad referencial, transacciones, consultas batch, etc. (verificar esto).

HipersonicSQL tiene varios modos de funcionamiento. Los dos principales son local y servidor. En el primer modo, el servidor se inicia y termina a la misma vez que el programa. En el segundo, hemos de iniciar y terminar el servidor a mano (como en cualquier otro sistema). La principal diferencia entre ambos es su cadena de conexión, como se muestra a continuación

Modo servidor: jdbc:hsqldb:hsql://localhost/base_de_datos
Modo local: jdbc:hsqldb:ruta_a_la_base_de_datos

A continuación pongo el código de un sencillo ejemplo que se conecta a una base de datos en modo local, realiza una consulta y muestra el resultado. Lo único necesario para que este ejemplo funcione (además de la base de datos), es tener hsqldb.jar en el CLASSPATH.


import java.sql.*;
public class SQLStatement  {
 public static void main(String args[]) {
  try {
   Class.forName("org.hsqldb.jdbcDriver");

  } catch(java.lang.ClassNotFoundException e) {
   System.err.println(e.getMessage());
  }
  try {
      Connection con = DriverManager.getConnection("jdbc:hsqldb:./testdb/testdb", 
          "sa", "");

      String query = "select COF_NAME from COFFEES";
      Statement stmt = con.createStatement();       
   ResultSet rs = stmt.executeQuery(query);
   ResultSetMetaData rsmd = rs.getMetaData();
   int numberOfColumns = rsmd.getColumnCount();
      System.out.println("Columns: "+numberOfColumns);
   while (rs.next()) {
    System.out.println("Fila " + rowCount + ":  ");
    for (int i = 1; i <= numberOfColumns; i++) {
     System.out.print("   Columna " + i + ":  ");
     System.out.println(rs.getString(i));
    }
    System.out.println("");
   }
      stmt.execute("Shutdown");
   stmt.close();
   con.close();

  } catch(SQLException ex) {
   System.err.println(ex.getMessage());
  } 
 }
}

No todos son ventajas trabajando con HSQLDB. Por ejemplo, las bases de datos de la versión 1.7 no son compatibles con la versión 1.8, lo cuál es malo. Sin embargo, tampoco he encontrado la necesidad de actualizar, por lo que he seguido trabajando con el 1.7 sin problemas.

Mutaciones y Java.

2006-02-06T17:41:00.000Z

Saludos.

Una técnica de prueba de código bastante antigua (de los 70) y famosa son las mutaciones. Sin embargo, esta técnica no suele ser muy conocida. Voy a hacer un breve resumen de ella y después comentaré una herramienta para Java.

A grandes rasgos, la técnica de las mutaciones surge de la idea de que todos los fallos de un programa vienen motivados por pequeños cambios en el código, como un error al escribir un número, un operador matemático o una comprobación. Obviamente, un fallo grande es un conjunto de fallos pequeños.

La técnica de las mutaciones propone un conjunto de operadores para obtener código mutado: por ejemplo cambiar un '>' por un '<' o un '+' por un '-'. Con esto, el código mutado que se genera es erróneo (aunque no siempre, puede dar la casualidad de que siga estando bien).

¿Pero para qué sirve el código mutado?. Principalmente tiene dos usos: 1) guiar la construcción de pruebas, 2) validar un conjunto de pruebas. Comentémoslos brevemente.

En primer lugar, el código mutado nos dice qué prueba hemos de construir. Por ejemplo, si hemos cambiado un '+' por un '-', debemos construir una prueba que sea capaz de detectar ese error. A más mutaciones, más pruebas y más fiable será nuestro código.

Además, las mutaciones pueden indicarnos lo bueno que es un conjunto de pruebas ya existente. Así, generamos un conjunto de mutaciones, ejecutamos las pruebas sobre el conjunto y, según el número de mutaciones detectadas podemos tener una idea de la eficacia de las pruebas.

Como ya he comentado, esta es una técnica antigua, por lo que ya existen muchos trabajos que describen operadores "mutacionales" para obtener mutaciones de código en muchos lenguajes como Fortran, C, o Java. También existen varias herramientas, aunque, personalmente, no conozco ninguna muy famosa, ni libre, ni fácil de usar.

La última que he visto (MuJava http://www.isse.gmu.edu/faculty/ofut/mujava/) es gratuita pero no libre. El trabajo con esta herramienta se divide en dos partes: en primer lugar la herramienta es capaz de generar ella sola un conjunto de mutantes a partir de las clases y métodos originales. Después, la herramienta permite ejecutar un conjunto de pruebas sobre los mutantes y detectar los mutantes eliminados (aquellos detectados con alguna prueba). Por desgracia, las pruebas hemos de escribirlas a mano. A la hora de la verdad, la herramienta se comía la primera letra de mis clases y solo era capaz de generar un montón de NullPointerException. Lástima que no sea libre y pueda corregir el código.

Aunque las herramientas que conozco no permitan sacar todo el jugo de la técnica de mutaciones, creo que los fundamentos son muy importantes para cualquier que escriba pruebas para código. Conocer los operadores para crear mutaciones nos va a dar muchas buenas ideas sobre qué pruebas escribir para verificar que nuestro código funciona y siga funcionando en el futuro.

Herramientas libres para pruebas de sistema/aceptación en Java.

2006-01-17T16:09:00.000Z

Saludos.

Una de las cosas que he estado haciendo aprovechando la tranquilidad de las navidades es ojear herramienta que me permitan hacer
pruebas del sistema/aceptación sobre aplicaciones Java. A continuación os cuento un resumen superficial de mis opiniones.

El problema:

Quiero escribir una prueba que verifique que una aplicación tipo bloc de notas carga correctamente un archivo del sistema. La
aplicación elegida fue, al principio, el Notepad que se incluye como ejemplo en el paquete J2SE. Como me dio problemas con
algunas herramientas, al final hice las pruebas con Stylepad, que también se incluye como ejemplo en J2SE.

Las herramientas:

Lo que buscaba es una herramienta que me permitiera indicar las mismas secuencias que haría una persona que cargara un archivo. Es decir: pulsar en el menú file > open, navegar hasta una carpeta predeterminada, seleccionar en un archivo concreto y pulsar el botón open. Para evitar tener que pelearme con lenguajes o archivos XML, busqué herramientas que me permitan grabar y reproducir todas esas acciones.

Las elegidas fueron 3: Abbot (link) , JFCUnit (link)y Marathon (link).

Abbot:

Abbot sirve tanto para probar componentes de manera aislada como para grabar y reproducir una secuencia de acciones. La herramienta viene con un editor (llamado Costello) muy completo que facilita la tarea de grabar secuencias, construir casos de prueba, y reproducirlas. No fue nada difícil echarla a andar.

Con el editor ejecuté la aplicación y capturé todas las pulsaciones de ratón perfectamente. El editor, además, registró todos los componentes (JMenuBar, JPane, JTextPane, etc. ) implicados en la secuencia. A la hora de añadir asertos, no tuve más que elegir el componente, elegir la propiedad que quería comprobar y el valor al que iba a comparara. Realmente sencillo.

Ahora vienen las cosas malas. Abbot almacena los casos de prueba en un XML bastante complejo, lo que hace difícil hacer pruebas sin grabar/reproducir. Además, el editor siempre se colgaba con bastante rapidez. La descripción de errores es muy poco clara, ya que se limita simplemente a mostrar el texto de la excepción, lo cual no tiene ninguna utilidad para mí que no conocía como estaba hecha la herramienta por dentro.

JFCUnit:

JFCUnit permite realizar pruebas unitarias de interfaces gráficas de usuario y pruebas del sistema. A diferencia de Abbot y Marathon, esta herramienta no trae ningún editor que permita capturar/reproducir. Para grabar y reproducir hay que escribir un par de programas en programa Java, fácil de hacer una vez que se investiga a fondo en la documentación y ejemplos. Además, es necesario modificar el código de la prueba a mano para añadir los asertos. Además, la prueba no fue capaz de grabar mi interacción con el FileDialog para seleccionar el archivo a abrir.

Las pruebas también se almacenan en XML. Aunque la documentación de JFCUnit es muy completa, falta una buena referencia de las etiquetas y sus atributos. algo indispensable ya que no dispone de un editor.

Marathon:

Esta herramienta sólo sirve para pruebas de sistema/aceptación, no permitirnedo escribir pruebas para componentes de manera individual. En esta herramienta las pruebas nos e guardan en XML sino en Python (y se procesan con JPython). Esto hace que el código sea muy compacto, muy legible y que tengamos toda la potencia de Python a nuestra disposición.

Aunque el editor no es tan completo como el editor de Abbot, incluye un menú contextual sobre la aplicación a prueba que permite añadir comprobaciones al mismo tiempo que se graba. Sin embargo también presenta problemas. El más importante es que, al igual que en la herramienta anterior, no se ha capturado la interacción con el diálogo para abrir un archivo. La documentación, aunque muy buena para empezar, se queda muy corta cuando quieres profundizar.

Conclusiones:

En una primera aproximación, no creo que ninguna de estas tres sea la herramienta definitiva. La herramienta que más me ha gustado es Marathon, sin duda por trabajar en Python. He encontrado mucho más cómodo entender código en Python que lenguajes propios de etiquetas. Marathon, además, es capaz de ocultar los detalles de la interfaz gráfica mejor que las demás. Esto es muy útil cuando queremos escribir las pruebas antes de tener la interfaz gráfica, o para evitar tener que volver a grabar todas las pruebas por algún cambio en la interfaz.

Estas navidades también estuve investigando algunas herramientas para probar aplicaciones web. En un futuro post, dentro de un mes más o menos, hablaré de ellas. Por supuesto escribiré más mensajes mientras.

Probando excepciones con JUnit.

2006-01-04T16:13:00.000Z

Saludos.

Escribir una prueba con JUnit que compruebe si salta o no una excepción es muy sencillo. Por ejemplo, supongamos que queremos probar un método con la
siguiente cabecera:


public Empleado obtenerEmpleado(String DNI)
  throws DNIErroneo

Vamos a escribir, en primer lugar, una prueba que compruebe que cuando le indicamos un DNI correcto, no lanza la excepción:


public void testDNICorrectoNoExcepcion() {
 try {
  // Nota: es un DNI inventado. Supongamos que es correcto
  obtenerEmpleado("18665230F");
 } catch (DNIErroneo e) {
  fail();
 }
}

Como se puede ver, si surge una excepción se ejecuta fail(), lo cuál termina el caso de prueba con error. Si no, termina normalmente.

Ahora vamos a escribir una prueba que verifique lo contrario. Le indicaremos al método un DNI erróneo y verificaremos que nos devuelve una excepción.


public void testDNIErroneoExcepcion() {
 try {
  // Nota: es un DNI inventado. Supongamos que es correcto
  obtenerEmpleado("18665230F");
 } catch (DNIErroneo e) {
  return;
 }
 fail();
}

Ahora, fail() se ejecutará si no ha aparecido la la excepción de DNI erróneo. Si aparee cualquier otra excepción, la prueba también fallará.

Utilizando Drools II. Caso práctico 2/2

2005-12-27T15:37:00.000Z

Como ya hemos visto, Drools es un motor de reglas de negocio. ¿Cuándo podemos utilizar Drools?. Pues,por ejemplo:

Cuando la lógica de negocio sea compleja pero se pueda expresar mediante cláusulas IF-THEN.

Cuando vaya a haber muhcos cambios.

Cuando el cliente no tiene clara su lógica de negocio.

Cuando el cliente se exprese de manera natural mediante IF-THEN.

Básicamente, al utilizar Drools tendremos que escribir dos elementos: las reglas de negocio y el sistema que utilizará dichas reglas (a a través de Drools). Drools permite escribir reglas en lenguaje Java, Python o Groovy. En este ejemplo vamos a escribir las reglas utilizando Java. Las reglas se almacenan en un archivo DRL, que no es más que un archivo XML con la definición de las reglas. La estructura (simplificada) de un archivo DRL se muestra a continuación

Imports de elementos de paquetes.

Declaración de funciones auxiliares.

Nombre del conjunto de reglas.

Reglas

Para cada regla podemos indicar:

Nombre de la regla.

Parámetros (los nombres son importantes).

Conciones para que la regla se dispare.

Consecuencias.

A continuación se muestra un ejemplo de un archivo DRL completo para el ejemplo que expusimos en el post aterior. Concretamente este archivo DRL incluye una regla por la que, si el precido de un pedido es superior a 100, le descuenta el 5%.

<?xml version="1.0"?>
<rule-set name="BusinessRulesSample"
   xmlns="http://drools.org/rules"
   xmlns:java="http://drools.org/semantics/java"
   xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
   xs:schemaLocation="http://drools.org/rules rules.xsd
   http://drools.org/semantics/java java.xsd">
 
 <java:import> java.lang.Object </java:import>
 <java:import> java.lang.String </java:import>
 <java:import> ebr.beans.Pedido </java:import>

 <rule name="Calculo del total del pedido">
 <parameter identifier="pedido">
 <class>ebr.beans.Pedido</class>
 <java:condition>
   pedido.getCalculoTotalOriginal() >= 100.0
 </java:condition>
 <java:consequence>
   pedido.setTotalFinal(pedido.getCalculoTotalOriginal() * 0.95);
 </java:consequence>
 </rule>

Para disparar esta regla vamos a escribir, en prime lugar, los beans que van a guardar la información
del workspace y un sencillo programa que utilice el motor. Uno de los beans guardará información sobre cada producto (nombre cantidad y precio) y el otro guardará la lista de productos. El sgeundo bean se muestra a continuación.

import java.util.*;

public class Pedido {

 private List entradas;
 private double totalFinal;

 public Pedido() {
   entradas = new ArrayList();
   this.totalFinal = -1.0;
 }

 public void addEntrada (Entrada e) {
   this.entradas.add(e);
 }
   
 public List getEntradas() {
   return this.entradas;
 }
   
 public void getEntradas(List entradas) {
   this.entradas = entradas;
 }
   
 public double getCalculoTotalOriginal() {
   Entrada e;
   double total = .0;
   Iterator it = this.entradas.iterator();
   
   while(it.hasNext()) {
     e = (Entrada) it.next();
     total += e.getCantidad();
   }
   
   return total;
 }
   
 public void setTotalFinal(double total) {
   this.totalFinal = total;
 }

Para trabajar con Drools necesitamos importar los sigientes elementos:

  import java.io.IOException;
   import org.drools.DroolsException;
   import org.drools.RuleBase;
   import org.drools.WorkingMemory;
   import org.drools.event.DebugWorkingMemoryEventListener;
   import org.drools.io.RuleBaseLoader;
   import org.xml.sax.SAXException;

Lo primero que tenemos que hacer es crear un nuevo pedido:

  Entrada e1 = new Entrada("A", 10, 5);
   Entrada e2 = new Entrada("B", 6, 6);
   Pedido pedido = new Pedido();
   pedido.addEntrada (e1);

En este pedido tenemos 10 unidades del producto A cada una a un precio de 5 y 6 unidades del B a un
precio de 6. A continuación creamos nuestro motor de reglas para que procese el archivo de reglas visto más arriba:

  BREngine br = new BREngine();
   RuleBase businessRules = RuleBaseLoader.loadFromUrl(
     BREngine.class.getResource( "rules01.drl" ) );

Limpiamos el espacio de trabajo e instalamos un listener que será avisado cada vez que Drools ejecute una regla. Este listener mostrará un mnesaje por la salida estándar.

  WorkingMemory workingMemory = businessRules.newWorkingMemory();
   workingMemory.addEventListener(new DebugWorkingMemoryEventListener());

A continuación añadimos el pedido:

 workingMemory.assertObject(fact);

Y a trabajar:

 workingMemory.fireAllRules();

Nota, los try / catch de todas las pisbles excepciones han sido omitios.

Cumplimos un año. Gracias !!!!!!

2005-12-19T18:05:00.000Z

Saludos a todos.

Recientemente este blog ha cumplido un año. Sinceramente, cuando empecé no esperaba que fuera capaz de mantenerlo todo este tiempo, no por falta d einetrés sino de tiempo.

Os agradezco de todo corazón vuestro tiempo a todos los que de vez en cuando venís por aquí. Lamento no poder actualizar esto con tanta frecuencia como me gustaría pero espero que, lo que ponga, os sea de utilidad.

Felices fiesta a todos.

(PD: sí, sí, está pendiente la continuación del post de Drools, a ver si llegan ya las vacaciones y tengo tiempo de ponerme con ello).

Drools I. Introducción a los motores de reglas de negocios.

2005-11-30T14:43:00.000Z

Saludos.

Drools (http://drools.org) es una implementación libre de un motor de reglas de negocio compatible con la especificación JSR-94 Rules Engine API (http://www.jcp.org/en/jsr/detail?id=94). ¿Y qué es un motor de reglas de negocio?. Es un componente que, a partir de una información inicial y un conjunto de
reglas, detectas qué reglas deben aplicarse en un instante determinado y cuáles son los resultados de esas reglas.

Uno de los puntos fuertes de los motores de reglas de negocios es que hablan el mismo lenguaje que el dominio del problema. Un ejemplo típico: supongamos que estamos hablando con un cliente para el desarrollo de una tienda virtual.
Algunas de las cosas que nuestro cliente nos pediría pudieran ser:

Si la cuantía del pedido supera cierta cantidad o si es un cliente de confianza, entonces se le aplica un descuento. Si se compra más de N productos del mismo tipo se le aplica un descuento. Entre las fechas X e Y, un producto está en oferta y, si se lleva 2, se le añade un 3º gratis

En una aplicación normal, todo lo anterior deberíamos codificarlo en métodos de clases que se ejecutaran al procesar un pedido, lo cual no siempre es sencillo. Con un motor, solo tenemos que indicarle las reglas de negocio, e ir indicándole los hechos. En este ejemplo, tendríamos que suministrarle al motor la información sobre los pedidos, clientes y productos mediante clases JavaBean.

Otra ventaja es a la hora de realizar cambios o mantenimiento. Si nuestro cliente desea cambiar el descuento por pedido, o el descuento por número de productos, o las fechas o tipos de productos (o quitar todos los descuentos), con un motor de reglas de negocio sólo es necesario cambiar las reglas, sin necesidad de modificar código, recompilar, ni siquiera de parar la aplicación.

Básicamente un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, el espacio de trabajo (o el conocimiento que tiene), y el procesador de reglas. Las reglas son sentencias de la forma IF-THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El espacio de trabajo es donde se guarda el conocimiento (objetos Java) que el motro utilizará para decidir que reglas deben activarse.

Dentro de las reglas pueden existir conflictos. Un conflicto es cuando varias reglas distintas pueden activarse para el mismo conjunto de hechos y, la aplicación de dichas reglas, pueden tener resultados contradictorios. Algunas de las estrategias para resolver conflictos son: asignarle una prioridad a cada regla, estrategias FIFO o LIFO, aplicarlas en el orden en que se declararon o aplicarlas en orden aleatorio.

Existen otros motores de reglas de negocio para java, por ejemplo JESS (http://herzberg.ca.sandia.gov/jess/), Mandarax (http://mandarax.sourceforge.net/) o OpenRules (http://java-source.net/open-source/rule-engines/openrules). También hay
motores de reglas de negocio para plataforma .NET como Quick Rules, JRules o Blaze.

Los motores de reglas de negocio pueden utilizarse, por ejemplo, para desarrollar prototipos rápidos o, incluso, para implementar la lógica de la aplicación. También pueden utilizarse como parte de un sistema de workflow.

En el próximo mensaje pondré un ejemplo de como implementar el caso práctico que hemos visto.

Extendiendo JUnit para que verifique expresiones regulares

2005-11-16T18:46:00.000Z

Saludos.

A veces, escribiendo pruebas unitarias con JUnit, hemos de comprobar resultados complejos.
Utilizando el soporte para expresiones regulares de J2SE a partir de la versión 4 que comentamos en el mensaje anterior, vamos a escribir un nuevo método assert, por ejemplo assertRegExp, que nos permita validar una cadena respecto de una expresión regular. Una posible implementación de este método se muestra a continuación.


 public static void assertRegExp(String message, String regexp, String s) {
  if (message==null)
   message="";
  if (!Pattern.matches(regexp, s))
   fail(message+" ["+regexp+"] over ["+s+"]");
 }
 
 public static void assertRegExp(String regexp, String s) {
  assertRegExp(null, regexp, s);
 }

Para que funcione, ambos métodos deben estar en una clase que herede de Assert, TestCase o TestDecorator.

Veamos un ejemplo. Supongamos un método "String getDNI()" para el que queremos escribir una prueba que verifique que el resultado está compuesto de 8 dígitos y una letra mayúscula. Una posible prueba utilizando nuestro método assertRegExp se muestra a continuación.


String dni = persona.getDNI();
String expReg = "[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][A-Z]";
assertRegExp("DNI incorrecto", expReg, dni);

Soporte de expresiones regulares en Java

2005-10-26T16:08:00.000Z

Saludos.

Existen muy buenas herramientas libres para trabajar con expresiones regulares en Java, como (http://lucene.apache.org/). Sin embargo, a partir de la versión 1.4, el kit estándar de Java incluye su propio soporte para expresiones regulares.
En el paquete 'java.util.regexp' encontramos las clases Matcher y Pattern. La primera clase permite aplicar una expresión sobre una cadena de texto. La segunda clase representa una expresión regular compilada para ganar en eficiencia.

La manera más sencilla y rápida de comprobar si una cadena satisface una expresión regular es mediante el método estático 'boolean Pattern.matches(cadena, expresión regular)'. Es posible conseguir el mismo efecto invocando el método matches sobre un objeto String. A continuación se muestra un sencillo ejemplo.

import java.util.regex.*;

public class EjemploRegExp {

// Números de 2 cifras que empiecen por 1 o 2
static String re = "\\b[1][0-9]|[2][0-9]";
static String cadena1 = "10";
static String cadena2 = "110";

public static void main(String[] args) {
if (Pattern.matches(cadena1, re))
System.out.println(cadena1+" cumple: "+re);
else
System.out.println(cadena1+" no cumple: "+re);
if (cadena2.matches(re))
System.out.println(cadena2+" cumple: "+re);
else
System.out.println(cadena2+" no cumple: "+re);
}
}

Además, la clase String también nos ofrece la manera de dividir un String mediante una expresión regular con el método:

String[] split(String regex)
String[] split(String regex, int limit)

En el próximo mensaje veremos una aplicación práctica extendiendo la herramienta JUnit (www.junit.org) para que soporte expresiones regulares.

Andalucía, tierra de SUN y Oracle

2005-10-10T10:59:00.000Z

La Junta de Andalucía es uno de los principales generadores de empleo en el mercado de la informática, bien de manera directa, bien creando y participando en empresas, o bien contratando trabajos a empresas privadas.
Por este motivo es muy importante para quien quiera trabajar en Andalucía conocer las tecnologías que la Junta de Andalucía ha decidido utilizar. En este caso y, hoy por hoy, la Junta desarrolla una apuesta clara por Java y Oracle para sus nuevos sistemas web y estos sistemas son los que salen a concurso.
Ya sabéis, todos los informáticos de Andalucía a estudiar SUN Y Oracle.

El lado oscuro de las pruebas.

2005-05-23T09:02:00.000Z

Saludos.

De un tiempo a esta parte, con la aparición de metodologías extremas, diseño guiado a pruebas y herramientas tipo jUnit, se han puesto de moda las pruebas. Parece que, cuantas más pruebas tenga un programa, mejor. Pero tener un número elevado de pruebas tiene un lado oscuro que puede traer problemas.

Si las pruebas son pequeñas y simples, las podemos escribir en un momento, pero si aumenta su tamaño (y no podemos dividirlas en pruebas más pequeñas) se hacen difíciles de escribir. Además a más código más errores, por lo que tenemos que perder tiempo depurándolas. Si nuestra prueba tiene mucho código o es compleja, ¿cómo podemos asegurarnos de que nuestra prueba funciona adecuadamente? ¿Tenemos que escribir una prueba para probar la prueba?.

Esto es malo, pero podemos encontrar algo todavía peor. Supongamos que tenemos una clase y 10 pruebas que dependen de dicha clase. Con el uso se ha descubierto que hay una manera mejor de crear objetos de esa clase cambiando los constructores. Ese cambio supondría, no solo cambiar en el código donde se crean objetos de esa clase (muy pocos si programamos bien 8) ) sino tener que modificar esas 10 pruebas.
Además habría que repasarlas para comprobar que sigan teniendo sentido después de la modificación y, probablemente, escribir pruebas nuevas.

En este caso el problema no es muy grande, pero si cambiamos (o refactorizamos) mucho código, el número de casos de casos de prueba a modificar aumenta, con el consiguiente gasto de tiempo para modificarlas. Recordemos que las pruebas no son parte del sistema (no se la entregamos al cliente ni, probablemente, el cliente aprecie su utilidad), por lo que no debemos gastar demasiado tiempo con ellas.

Esto nos puede llevar a dos decisiones igual de malas: o bien no modificar el código para seguir aprovechando las pruebas que ya tenemos, o, lo más común, modificar el código y tener un conjunto de pruebas obsoletas e inservibles.

Este problema no es exclusivo en las pruebas de código "tipo jUnit". También sucede lo mismo trabajando, por ejemplo, con robots de prueba que capturan pulsaciones de teclado o ratón y luego las reproducen. En este caso, un mínimo cambio en la interfaz gráfica puede obligar a modificar (o a volver a grabar) un buen número de pruebas.

En resumen. Cuanto más pruebas, por ejemplo pruebas de código, tengamos, más atados estamos a dicho código y menos ganas de cambiar nada tenemos..

¿Cuál puede ser una la solución?. Creo que una buena alternativa sería generar las pruebas de manera automática. Si tuviéramos un programa que permitiera apretar un botón y obtener un buen conjunto de pruebas (e incluso ejecutarlas), no nos preocuparíamos a lo hora de cambiar el código. En cada cambio descartaríamos todas las pruebas obsoletas y generaríamos pruebas nuevas fácilmente.

Esto es muy fácil de decir pero muy difícil de poner en práctica (por no decir imposible). Espero seguir hablando de esto en futuras entradas.

Texto con formato e imágenes en aplicaciones web

2005-05-02T19:24:00.000Z

Saludos.

Recientemente he estado haciendo una miniconsultoría (en plan "Amigetes Conculting") que me ha llevado a buscar editores web, o editores de texto lo más completos posibles para integrarlos en una aplicación PHP. A continuación comento lo que he encontrado.

En el siguiente enlace se puede encontrar una lista muy completa con opciones para todo tipo de plataformas y lenguajes: http://www.htmlarea.com/

De todos los que he visto, el que más me ha gustado para PHP (también disponible para ASP.NET) es Spaw, que se distribuye bajo licencia GPL para usos no comerciales (www.solmetra.com/spaw/ y sourceforge.net/projects/spaw/).

Sin embargo, aunque es un componente bastante evolucionado y cuenta con un foro bastante dinámico (en SourceForge), yo no he consegido hacerlo funcionar. Una lástima.

Por ese motivo he optado por htmlArea (http://www.dynarch.com/projects/htmlarea/) que, si bien no es tan vistoso ni icluye tantas opciones, cumple sobradamente. Además está íntegramente en JavaScript, por lo que se adapta a casi cualquier plataforma.

También existen plug-in que lo extienden, por ejemplo a la hora de incluir imágenes
(http://www.zhuo.org/htmlarea/). Su licencia es BSD.

HtmlArea lo utilizan aplicaciones tan importante como la plataforma de e-Learning Moodle.

Ya no hay excusas para crear formularios que no admitan texto con formato.

Lo mejor de la semana

2005-04-03T18:30:00.001Z

Saludos.

Sin duda lo mejor que esta semana he encontrado en la red es esta colección de enlaces a tiras cómicas.

La tira de Linux Hispano
http://www.linuxhispano.net/tira/tira.html

Raulito el Friki
http://recurrente.afraid.org/myblog/?q=ultima

La tira de Bit y Byte
http://tira.emezeta.com/

Tira Frikis
http://www.geocities.com/tirasfrikis/

Tira Ecol
http://tira.escomposlinux.org/

Un millón de gracias a sus autores por su tiempo y esfuerzo.

Una pregunta en el aire

2005-03-31T20:47:00.000Z

Saludos.

El otro día, leyendo una página web sobre una aplicación encontré lo siguiente:

Robusto: Más de 230 pruebas Junit.

La primera pregunta que se plantea es bastante obvia: ¿Podemos medir el grado de robustez o fiabilidad de un sistema mediante el número de pruebas?.

No. Un ejemplo muy claro, aunque tal vez un poco extremo. Imaginemos el
siguiente código (que sirve tanto para C como para Java).


int factorial(int n) {
 if (n == 1)
   return n;
 return n * factorial(n-1);
}

Supongamos que escribo 100 pruebas para comprobar los 100 primeros factoriales. ¿Puedo asegurar que el código anterior es robusto?. No. en cuanto reciba un 0 o un número negativo fallará a pesar de sus 100 (o 11000) pruebas.

Otra pregunta, tal vez no tan obvia, es si la robustez o fiabilidad de un sistema está garantizada únicamente por pruebas unitarias.

No. Un ejemplo muy claro lo encontramos en las aplicaciones web. Con pruebas
tipo JUnit, u otra herramienta similar, difícilmente podremos comprobar la respuesta del sistema a un gran número de peticiones concurrentes de distintos clientes, ni si el sistema es capaz de seguir funcionando o se colapsa.

La gran pregunta que habría que responder es: ¿Como podemos garantizar la robustez del sistema?. Lo cual nos lleva a plantearnos: ¿y qué es la robustez?.

Habrá que seguir con esto.

Probando exhaustivamente

2005-03-24T20:22:00.000Z

El siguiente ejemplo está sacado de un libro sobre pruebas bastante famoso.
Nos piden un programa para clasificar un triángulo en equilátero, isósceles o escaleno. Para que tres lados a, b y c formen un triángulo debe cumplirse que s (s = (a +b +c) / 2) sea mayor estricto que a, b y c.
Una posible solución se muestra a continuación.



 static final int NOTRIANGULO = 0;
 static final int EQUILATERO = 0;
 static final int ISOSCELES = 0;
 static final int ESCALENO = 0;
 
 public static int tipoTriangulo(int a, int b, int c) {
  int s;
  
  s = (a+b+c) / 2;
  if ( (s <= a) || (s <= b) || (s <= c)) 
   return NOTRIANGULO;
  
  if ( (a==b) && (b==c) )
   return EQUILATERO;
  
  if ( (a==b) || (b==c) || (a==c) )
   return ISOSCELES; 
  
  return ESCALENO;
 }

Sin embargo, lo más interesante es plantear que pruebas necesitamos para verificar a fondo que el código anterior funciona. En este caso, una prueba va a ser un conjunto de valores concretos y el resultado esperado, por ejemplo:

(3, 3, 3) : EQUILATERO
(3, 3, 4) : ISOSCELES
(3, 4, 5) : ESCALENO
(2, 2, 6) : NOTRIANGULO

¿Cuantas pruebas necesitamos para tener la certeza que hemos probado todas las posibles combinaciones?. ¿Cómo obtenemos esas pruebas?. Una técnica clásica que podemos utilizar es analizar las estructuras de control. Esta es una técnica de caja blanca.
Por ejemplo, en el caso de un triángulo isósceles, vemos que ha de cumplirse una de tres condiciones posibles. Por tanto, en este caso hemos de verificar las tres condiciones. Las pruebas resultantes se muestran a continuación:

(3, 3, 4), (3, 4, 3), (4, 3, 3) : ISOSCELES

Aplicando este mismo proceso al resto de los casos obtenemos el resto de pruebas. Sin embargo esto aún no es suficiente. Por ejemplo: ¿qué sucede cuando un lado es 0 o negativo, o cuando un lado vale el valor máximo que un tipo int puede almacenar?. ¿Es posible introducir lados decimales o lados que no sean valores numéricos?. Todas estas circunstancias deberían ser probadas también.
En este caso, para completar el conjunto de pruebas, podemos aplicar una técnica de prueba de caja negra llamada análisis de valores límites. Por ejemplo, para verificar que el programa sigue funcionando cuando uno de sus lados es 0 las pruebas serán:

(0, 3, 3), (3, 0, 3), (3, 3, 0) : NOTRIANGULO

Calculando todas las posibles combinaciones se obtiene aproximadamente 30 casos de prueba distintos, lo cual da una medida de lo importante que es probar convenientemente cualquier código.

Enlaces sobre refactorización

2005-03-22T20:41:00.000Z

Saludos.

Para aquellos interesados en tener a mano información breve y funcional sobre refactorizaciones, puede echarle un vistazo a estos dos enlaces publicados en Agile Spain (www.agile-spain.com/):

En el primero nos muestran una tabla con malos olores y enlaces a las refactorizaciones recomendadas para eliminarlas:
http://wiki.java.net/bin/view/People/SmellsToRefactorings

En el segundo nos explican las refactorizaciones mediante sencillos (muy sencillos) diagramas parecidoa a UML:
http://www.refactoring.be/thumbnails.html

Además de estos enlaces no hay que dejar de visitar el blog en español:
http://www.programacion.com/blogs/14_refactoring

Pruebas con aspectos

2005-03-15T22:53:00.000Z

Saludos.

Nos han publicado en JavaHispano un trabajo que presentamos el año pasado en un estupendo workshop. El trabajo versa sobre como aplicar programación orientada a aspectos para escribir pruebas unitarias, y que ventajas aporta frente a la clásica herramienta JUnit. Los pocos ejemplos están escritos en Java y AspectJ.

Para quien tenga interés, el enlace es: http://www.javahispano.org/articles.article.action?id=96

Fin de la operación limpieza.

2005-03-12T12:35:00.000Z

Saludos.

Aunque aún quedan algunos ejercicios con semáforos, la operación limpieza queda oficalmente clausurada. Si alguien quiere los ejercicios que faltan puede pedírmelos por correo electrónico.
Dentro de unos pocos meses empezaré otra operación de limpieza, pero esta vez para ejercicios básicos en Java.
Mientras tanto retomaré la idea original de este blog e iré escribiendo comentarios referentes a Java y reflexiones pruebas del software.

Sincroniazación entre procesos

2005-02-16T16:39:00.000Z

El siguiente porgrama crea 2 hijos. Uno de ellos pondrá los números del 1 al 5 en una variable compartida y el otro leerá esos valores y los mostrará por pantalla.

El primer procso pone el número 1 en la variable compartida, después, el segundo proceso lee el valor 1 y lo muestra por pantalla. Después el primer proceso pone el número 2 en la variable compartida, y así hasta el 5.

Para sincronizar ambos procesos se han utilizado dos grupos de un semáforo cada uno.



#include < errno.h>
#include < stdio.h>
#include < unistd.h>
#include < wait.h>
#include < sys/ipc.h>
#include < sys/sem.h>
#include < sys/stat.h>
#include < sys/types.h>

#include "sv.h"


union senum {
  int val;
};

int main() {

  pid_t pid;
  int c, r;
  int num;
  int sem_prod, sem_cons;
  struct sembuf arriba = {0,1,0};
  struct sembuf abajo = {0,-1,0};
  union senum arg;


  sv_init();

  sem_prod = semget(IPC_PRIVATE, 1, IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR);
  sem_cons = semget(IPC_PRIVATE, 1, IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR);
  if ((sem_prod == -1) || (sem_cons==-1)) {
    perror("Error creando semáforos");
    return -1;
  }

  arg.val = 1;
  r = semctl(sem_prod, 0, SETVAL, arg);
  if (r == -1) {
    perror("Error incializando el semáforo del productor - ");
    //Borrar los semáforos
    return -1;
  }

  for (c = 0; c < 2; c++) {
    pid = fork();
    if (pid == -1) {
      perror("Error creando procesos - ");
      // Borrar semáforos.
      return -1;
    }

    if (pid == 0) {

      // Productor
      if (c==0) {
 for (num = 1; num < 6; num++) {
   // Mi turno de producir
   r = semop(sem_prod, &abajo, 1);
   if (r == -1) {
     perror("Error bajando el semáforo del productor - ");
     // Eliminar semáforos
     return -1;
   }

   printf("Valor producido: %i\n", num);
   sv_set(num);

   // El turno de consumir
   r = semop(sem_cons, &arriba, 1);
   if (r == -1) {
     perror("Error subiendo el semáforo del consumidor - ");
     // Eso
     return -1;
   }
 }
 exit(0);
      }

      // Consumidor
      if (c==1) {
 for (num = 0; num < 5; num++) {
   // Voy a consumir 5 números
   r = semop(sem_cons, &abajo, 1);
   if (r == -1) {
     perror("Error bajando semáforo del consumidor - ");
     return -1;
   }

   printf("Valor consumido: %i\n", sv_get() );

   // Hora de producir
   r = semop(sem_prod, &arriba, 1);
   if (r == -1) {
     perror("Error subiendo semáforo del productos - ");
     return -1;
   }
 }
 exit(0);
      }

    }
  }

  pid = wait(&r);

  while ( (pid != -1) ||
   ( (pid == -1) && (errno == EINTR)) )
    pid = wait(&r);

  r = semctl(sem_prod, 0, IPC_RMID);
  if (r==-1) {
    perror("Error eliminando semáforo productor.");
  }
  r = semctl(sem_cons, 0, IPC_RMID);
  if (r == -1) {
    perror("Error eliminando semáforo consumidor. ");
  }

  sv_finish();

  printf("Fin.\n");
  return 0;
}

Acceso a un recurso compartido

2005-02-16T16:30:00.000Z

Saludos.

El siguinte código crea cuatro procesos hijos. Cada hijo incrementará una variable compartida en 5 unidades. Para garantizar la exclusión mútua sobre la variable compartida se utiliza un grupo de un semáforo que funciona como semáforo binario.

Hay que cabiar todas las " de los includes por mayor y menor excepto el include de sv.h.


/**
Implementa un  semáforo binario
utilizando directamente las funciones del sistema
**/

#include "sv.h"

#include "stdio.h"
#include "wait.h>
#include "unistd.h"
#include "sys/types.h"

#include "sys/stat.h"
#include "sys/ipc.h"
#include "sys/sem.h"


// Incrementa en 5 la variable compartida
#define INC 5

void inc(int);


// Esta unión hay que declararla
union semun {
  int val;
  struct semid_ds *buf;
  ushort *array;
};

int main() {
  int c;
  int hijos = 4;
  pid_t pid;

  int semaforo;
  union semun arg;
  int r;
  // { semaforo, valor, banderas }
  struct sembuf arriba = {0, 1, 0};
  struct sembuf abajo = {0, -1, 0};


  sv_init();
  printf("Valor de inicio: %i\n", sv_val());

  // Crear e inicializar un semaforo binario
  // para garantizar la exclusion mutua.
  semaforo = semget(42, 1, IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR);
  if (semaforo == -1) {
    perror ("Error en la creación del semáforo - ");
    return -1;
  }

  arg.val = 1;
  r = semctl(semaforo, 0, SETVAL, arg);
  if (r == -1) {
    perror ("Error inicializando semáforo - ");
    // Hay que eliminarlo.
    return -1;
  }


  for (c = 0; c < hijos; c++) {
    pid = fork();
    if (pid == -1) {
      perror("Error en fork - ");
      exit(-1);
    }   
    if (pid == 0) {
   
      // Decrementar semaforo
      r = semop(semaforo, &abajo, 1);
      if (r == -1) {
 perror("Error decrementando semáforo - ");
 // Eliminar el semáforo
 return -1;
      }

      inc(c);

      // Incrementar semaforo
      r = semop(semaforo, &arriba, 1);
      if (r == -1) {
 perror("Error incrementando semáforo - ");
 // Es necesario eliminarlo
 return -1;
      }

      exit(0);
    }
  }

  while ( wait(NULL)!=-1 );

  printf("-------------------------------\n");
  printf("Valor esperado: %i\n", hijos  * INC);
  printf("Valor real: %i", sv_val());

  // Borrar semaforo
  r = semctl(semaforo, 0, IPC_RMID);
  if (r == -1)
  {
    perror("Error elminando semáforo - ");
    return -1;
  }

  sv_finish();
  printf("\n");
}


//----------------------------
void inc(int id) {
  int c;
  int tmp;
  for(c=0; c < INC; c++) {
    tmp = sv_get();
    if ( (id == 0) && (c < 2)) sleep(1);
    tmp++;
    sv_set(tmp);
  }
}

Libería para implementar una variable compartida

2005-02-14T22:16:00.000Z

A continuación se incluye el código de una librería que permite crear y manipular una variable compartida, esto es, una variable común para todos los procesos que utilicen esta librería. Así, los cambios que haga un proceso sobre esta variable, serán visibles para los demás procesos.

Esta librería es un buen ejemplo de como utilizar el mecanismo IPC de memoria compartida.

Esta librería se utilizará en ejemplos posteriores con semáforos.

sv.h


#ifndef _SV_
#define _SV_

/**
Gestiona una variable entera mediante memoria compartida.
La variable es común a todos los procesos creados
después de llamar a sv_init();
**/


/**
Reserva la memoria compartida e inicializa la variable 
a 0.
-1 si error.
**/
int sv_init();

/**
Libera la memoria compartida.
-1 si error.
**/
int sv_finish();

/**
Devuelve el valor de la variable común
sv_get es un alias para sv_vsl
**/
int sv_val();
int sv_get();

/**
Incrementa la variable entera con el valor 
indicado como parámetro y devuelve su nuevo valor.
**/
int sv_inc(int);

/**
Asigna un valor a la variable común
Devuelve el valor asignado.
**/
int sv_set(int);

#endif

sv.c


#include "stdio.h"
#include "sys/ipc.h"
#include "sys/shm.h"
#include "sys/stat.h"
#include "sys/types.h"

int s_id;
int *sv = NULL;

//---------------------------------
int sv_init() {
  int tam = sizeof(int);
  s_id = shmget(IPC_PRIVATE, tam, IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR);
  if (s_id == -1)
    return -1;
  sv = (int *)shmat(s_id, NULL, 0);
  if (sv == (int *)-1) {
    sv = NULL;
    return -1;
  }
  (*sv)=0;
  return 1;
}

//--------------------------------
int sv_inc(int val) {
  int tmp;
  if (sv == NULL)
    return -1;
  tmp = (*sv);
  tmp += val;  
  (*sv)= tmp;
  return (tmp);
}

//--------------------------------
int sv_val() {
  if (sv == NULL)
    return 0;
  return (*sv);
}

//--------------------------------
int sv_get() {
  return sv_val();
}

//--------------------------------
int sv_set(int val) {
  (*sv) = val;
  return val;
}

//--------------------------------
int sv_finish() {
  if (s_id == -1)
    return -1;
  return shmctl(s_id, IPC_RMID, 0);
}

Mensaje con preaviso

2005-02-14T22:11:00.000Z

Saludos.

El siguiente código crea un proceso hijo que enviará cuatro mensajes al proceso padre, el cual los mostrará por pantalla. Para evitar que cualquier de los dos procesos se quede esperando en la tubería, el padre, antes de leer un mensaje de la tubería, avisará al hijo con una señal SIGUSR1. El hijo, al recibir la señal, pondrá un mensaje en la tubería y esperará a la siguiente señal.


#include "stdio.h"
#include "unistd.h"
#include "signal.h"
#include "wait.h"
#include "sys/types.h"

#define SIZE 256

int tub[2];
char msg[SIZE];

void manejador_hijo(int);

int main() {

  int c = 0;
  int status;
  pid_t pid;

  pipe(tub);  
  pid = fork();
  if (pid == -1) {
    perror("Error bifurcando proceso - ");
    return -1;
  }

  if (pid == 0) {
    if (signal (SIGUSR1, manejador_hijo) == SIG_ERR) {
      perror("Error instalando manejador - ");
      exit(-1);
    }
    close(tub[0]);
    while (1)
      pause();

    printf("Hijo, terminación inesperada.\n");
    exit(-1);
  }

  close(tub[1]);
  while(c < 4) {
    sleep(1);
    if ( kill(pid, SIGUSR1) == -1) {
      perror("Error enviando señal al hijo.");
      return -1;
    } 

    if (read(tub[0], msg, SIZE) == -1) {
      perror("Error leyendo de la tuberia - ");
      return -1;
    }

    printf("%i: %s\n", c, msg);
    c++;
  }

  close(tub[0]);
  
  if (kill(pid, SIGTERM) == -1) {
    perror("Error terminando hijo.");
    return -1;
  }

  while( pid != wait(&status) );

  printf("Fin\n");
  return 0;
}

//--------------------------------------------------

void manejador_hijo(int sig)
{
  if ( signal (SIGUSR1, manejador_hijo) == SIG_ERR) {
    perror("Error reinstalando el controlador.");
    exit(-1);
  }
  strcpy(msg, "Mensaje del hijo.");
  if ( write(tub[1], msg, strlen(msg)) == -1) {
    perror("Error escribiendo en la tuberia.");
    exit(-1);
  }
}

Mensaje repetitivo

2005-02-12T10:42:00.000Z

El siguiente código muestra un mensaje por pantalla drante 2 segundos, pasado estetiempo recibe una señal SIGALRM y el mensaje cambia. Este proceso se repite infinitas veces, o hasta que alguna variable se desborde.

Hay que cambiar las " de los includes por los signos de mayor y menor.


#include "unistd.h"
#include "signal.h"
#include "string.h"
#include "sys/types.h"

void sig_alarm(int);

char men[50];
int num_alarm = 0;


int main()
{
  if ( signal(SIGALRM, sig_alarm) == SIG_ERR) {
    perror("Error instalando manejador - ");
    return -1;
  }

  sprintf(men, "Alarma %i", num_alarm);
  alarm(2);

  while(1) {
    printf("%s\n", men);
    pause();
  }

  // Se ejcutará alguna vez esta línea ??
  printf("Se acabó.\n");

  return 0;
}

//---------------------------

void sig_alarm(int sig) {
  
  if ( signal(SIGALRM, sig_alarm) == SIG_ERR)  {
    perror("Error instalando manejador - ");
  }

  alarm(2);
  num_alarm++;
  sprintf(men, "Alarma %i", num_alarm);
}

Matar al hijo perezoso

2005-02-12T10:40:00.000Z

El siguiente programa lanza un proceso hijo, y si después de X segundos el proceso sige activo, lo mata con una señal SIGKILL.

Es conveniente jugar con el valor del sleep(..) del hijo para ver el comportamiento de este programa.


#include "unistd.h"
#include "signal.h"
#include "wait.h"
#include "sys/types.h"

int main()
{
  pid_t pid, pid_hijo;
  int status;
  int sleep_padre = 2;
  int sleep_hijo = 1;


  if ( (pid_hijo=fork()) == -1) {
    perror("Error en el fork - ");
    return -1;
  }

  if (pid_hijo == 0) {
    sleep(sleep_hijo);
    printf("Termina hijo.\n");
    exit(0);
  }

  sleep(sleep_padre);
  pid = waitpid(pid_hijo, &status, WNOHANG);

  printf("pid = %ld / pid_hijo = %ld / status = %i\n", pid, pid_hijo, status);

  if (kill(pid_hijo,0)==0) {
    printf("Hijo aún en activo. Lo termino\n");
    kill(pid_hijo, SIGTERM);
    waitpid(pid_hijo, NULL, 0);
  }
  printf("Termina padre.\n");

  return 0;
}

Contar señales SIGUSR1

2005-02-12T10:36:00.000Z

Saludos.

El siguiente programa queda a la espera de recibir una señal. Cunado recibe una señal SIGUSR1 incrementa un contador, y cuando recibe una señal SIGTERM muestra el contador y termina.

Una variante muy sencilla es añadirle un manejador para SIGUSR2 de tal manera que, al recibir esta señal, muestre el valor del contador pero continue su ejecución.

Para ejecutar un programa o comando en sgeundo plano, sin que deje la consola ocupada, hay que añadir & al final del nombre del programa o comando.


#include "signal.h"
#include "unistd.h"

void manejadorUSR1(int sig);
void manejadorTERM(int sig);

int cuenta = 0;

int main()
{

  if ( signal(SIGUSR1, manejadorUSR1) == SIG_ERR) {
    perror("Error instalando manejadorUSR1 - ");
    return -1;
  }

  if ( signal(SIGTERM, manejadorTERM) == SIG_ERR) {
    perror("Error instalando manejadorTERM - ");
    return -1;
  }

  while(1)
    sleep(5);

  return 0;
}

//-------------------------
void manejadorUSR1(int sig) {

  if ( signal(SIGUSR1, manejadorUSR1) == SIG_ERR) {
    perror("Error instalamdno manejadorUSR1 - ");
    exit(0);
  }

  cuenta++;
}

//---------------------------
void manejadorTERM(int sig) {

  printf("Señales USR1 recibidas: %i \n", cuenta);
  exit(0);
}

Sincronización padre-hijo con señales

2005-02-08T13:22:00.000Z

El siguiente programa muestra los números del 1 al 6 en orden creciente por pantalla. Los números impares los muestra el padre y los números pares los muestra el hijo.


#include "signal.h>

#include "unistd.h>

#include "sys/types.h>



void manejadorPadre(int sig);

void manejadorHijo(int sig);



int cuenta = 0;



int main() {



  pid_t pid;



  if ( (pid = fork()) == -1) {

    perror("Error en el fork - ");

    return -1;

  }



  if (pid == 0) {

    printf("Hijo instala manejador.\n");

    if ( signal(SIGUSR1, manejadorHijo) == SIG_ERR) {

      perror("Error instalando manejadorHijo - ");

      exit(-1);

    }



    printf("Hijo entra en el bucle\n");

    while(1)

      pause();

    exit(0);

  }



  // sleep(1);

  printf("Uno\n");



  if ( signal(SIGUSR1, manejadorPadre) == SIG_ERR) {

    perror("Error instalando manejadorHijo - ");

    exit(-1);

  }



  while(cuenta < 2) {

    kill(pid, SIGUSR1);

    pause();

  }

  kill(pid, SIGUSR1);





  printf("Esperando al hijo.\n");

  wait(NULL);

  return 0;

}





//--------------------------

void manejadorHijo(int sig)

{



  static int contador = 0;



  if ( signal(SIGUSR1, manejadorHijo) == SIG_ERR) {

      perror("Error instalando manejadorHijo - ");

      exit(-1);

    }



  if (contador == 0){

    printf("Dos\n");

    contador++;

    kill(getppid(), SIGUSR1);

  } else if (contador == 1) {

    printf("Cuatro\n");

    contador++;

    kill(getppid(), SIGUSR1);

  } else {

    printf("Seis\n");



    // Restauro el manejador original

    if (signal(SIGUSR1, SIG_DFL) == NULL) 

      perror("Error restaurando manejador original en el hijo - ");



    exit(0);

  };

}



//---------------------------------

void manejadorPadre(int sig)

{



  if ( signal(SIGUSR1, manejadorPadre) == SIG_ERR) {

      perror("Error instalando manejadorPadre - ");

      exit(-1);

  }



  if (cuenta == 0) {

    printf("Tres\n");

    cuenta++;

  } else if (cuenta == 1) {

    printf("Cinco\n");

    cuenta++;

    // Restauro el manejador original

    if (signal(SIGUSR1, SIG_DFL) == NULL) 

      perror("Error restaurando manejador original en el padre - ");

  }

}

Listado ordenado.

2005-02-08T13:16:00.000Z

El siguiente programa crea dos procesos hijos. El primer hijo ejecuta el comando "ls -l" y le pasa el resultado al segundo hijo. El segundo hijo ejecuta "sort -n +4" y redirecciona la salida al archivo "lsord.txt".

En otras palabras, el resultado de este programa es el mismo que el de ejecutar la siguiente expresión:

$ ls -l | sort -n +4 > lsord.txt


// Sustituir las "s por mayor y menos

#include "stdio.h"

#include "stdlib.h>

#include "unistd.h>

#include "fcntl.h>

#include "errno.h>

#include "sys/types.h>

#include "sys/wait.h>



int main()

{

  int fd[2];

  int status;

  int fd_salida;



  pipe(fd);



  if ( (fd_salida=open("lsord.txt", O_WRONLY | O_CREAT | O_TRUNC, 0600)) == -1) {

    perror("Error - ");

    return -1;

  }



  if (fork()==0)

  {

    // El hijo

    dup2(fd[1], STDOUT_FILENO);

    close(fd[0]);

    close(fd[1]);

    execlp("ls", "ls ", "-l", NULL);

    perror("Exec falló en ls");

    exit(-1);

  }

  if (fork()==0) {

    // El otro hijo

    dup2(fd[0], STDIN_FILENO);

    close(fd[0]);

    close(fd[1]);

    dup2(fd_salida, 1);

    close(fd_salida);

    execlp("sort", "sort", "-n", "+4", NULL);

    perror("Exec falló en sort");

    exit(-1);

  }



  close(fd[0]);

  close(fd[1]);



  // El padre espera a que terminen los hijos

  status = wait(NULL);

  while ( (status != -1) ||

	  (status == -1 && errno == EINTR))

    status = wait(NULL);

  

  exit(0);

}

Familia numerosa.

2005-02-06T13:29:00.000Z

El siguiente código crea tres procesos hijos y, cada proceso hijo, crea tres nuevos procesos nietos.
Este código se puede simplificar mucho utilizando exit(int).


#include "unistd.h"

#include "sys/types.h"



int main()

{

  int i, padre, prim_padre;



  prim_padre = padre = 1;



  for(i=0; i<3; i++) {

    if (padre == 1) {

      if (fork() == 0) {

	// Proceso hijo

	if (fork()==0) {

	  // Proceso nieto

	  printf("Nieto %i con padre %ld\n", getpid(), getppid());

	} else {

	  printf("Hijo %i con padre %ld\n", getpid(), (long)getppid() );

	}

	padre = 0;

      } else {

	sleep(2);

	if (prim_padre) {

	  printf("Padre %i\n", getpid());

	  prim_padre = 0;

	}

      }

    }

  }

  return 0;

}

Ejemplo de tuberías

2005-02-06T13:25:00.000Z

En el siguiente código, un proceso padre envía un mensaje a un proceso hijo mediante una tubería y el proceso hijo lo muestra por pantalla.


#include "unistd.h"

#include "sys/types.h"



int main()

{

  int tub[2];

  char msg[256];

  pid_t pid;

  int status;



  pipe(tub);

  pid = fork();



  if (pid !=0)    {

    // El padre

    write(tub[0], "Soy padre.\n", 12);

  }

  else {

    // El hijo

    read(tub[1], msg, 256) ;

    printf("Hijo > %s", msg);

  }



}

Copiar entrada en salida.

2005-02-06T13:22:00.000Z

El siguiente código espera una entrada por la consola y muestra dicha entrada en la salida estándar.


#include "stdio.h"

#include "stdlib.h"

#include "sys/file.h"



#define TAM_BUF 255





int main(int argc, char *argv[])

{

  char buf[TAM_BUF];

  int readed;



  readed = read(0, buf, TAM_BUF);

  while(readed > 0)

  {

    write(1, buf, readed);

    readed = read(0, buf, TAM_BUF);

  }

  

  

  printf("Hello, world!\n");



  return EXIT_SUCCESS;

}

Escribir un mensaje por la salida estándar

2005-02-06T13:17:00.000Z

Saludos.

El siguiente código escribe un mensaje por la salida estándar utilizando el mecanismo de descriptores de archivos.


#include "stdio.h"

#include "stdlib.h"



#include "sys/file.h"



#define TAM_BUF 255





int main(int argc, char *argv[])

{

  char buf[TAM_BUF];

  

  strcpy(buf, "Soy tocon.\n");

  write(1, buf, 10);

  

  printf("Hello, world!\n");



  return EXIT_SUCCESS;

}

Adivinanza 2

2005-02-05T10:36:00.000Z

¿Cuántas veces aparece por pantalla la palabra "Proceso" y que valor tiene en cada aparición la variable p?


#include "stdio.h"

#include "sys/types.h"

#include "unistd.h"



int main(void) {

 

  int c;

  int p=0;

  for (c = 0; c < 3 ; c++ )

  {

     fork();

  }

  p++;

  printf("Proceso %d\n", p);

}

Adivinanza 1

2005-02-05T10:34:00.000Z

¿Cuantas veces aparece por pantalla la palabra "Proceso"?.


// Cambiar las " por mayor y menor.

#include "stdio.h"

#include "sys/types.h"

#include "unistd.h"



int main(void) {

 

  int c;

  for (c = 0; c < 3 ; c++ )

  {

     fork();

  }

  printf("Proceso\n");

}

Redireccionar salia de errores

2005-02-05T10:31:00.000Z

Saludos.

El siguiente programa redirecciona la salida estándar de errores de la pantalla hasta un fichero y después simula un error.


// Cambiar las " de los include por mayor y menos.

#include "fcntl.h"

#include "stdio.h"

#include "unistd.h"

#include "sys/file.h"

#include "sys/types.h"



int main()

{

  int fp;

  int fpdup;



  fp = open("errores.txt", O_WRONLY | O_CREAT | O_TRUNC, 00600);

  if (fp == -1)

  {

    perror("Error abriendo fichero.\n");

    return -1;

  };



  fpdup=dup2(fp, 2);

  printf("%i / %i\n", fp, fpdup);



  close(fp);



  perror("Error simulado.\n");



  return 0;

}

Mostrar argumentos de la línea de comandos.

2005-02-05T10:28:00.000Z

Saludos.

El siguiente código muestra uno a uno y numerados los argumentos de la línea de comandos. También podría hacerse con un bucle for hasta el valor de la variable argc.


#include "stdio.h"



int main(int argc, char *argv[])

{

  int i = 0;

  while(argv[i]!=NULL) {

    printf("%i : %s \n", i, argv[i]);

    i++;

  }

return 0;

}

Listar la línea de argumentos

2005-02-02T18:34:00.000Z

Saludos.

El siguiente código lista todos los argumentos introducidos en la línea de comandos a continuación del nombre del programa y los numera. También podría hacerse mediante un bucle for con el valor de argc.




/**

 * Este programa prueba si argv termina en NULL

 **/ 

#include 



int main(int argc, char *argv[])

{

  int i = 0;

  while(argv[i]!=NULL) {

    printf("%i : %s \n", i, argv[i]);

    i++;

  }

return 0;

}

Comprara dos archivos.

2005-01-29T11:38:00.000Z

Saludos.

El siguiente programa permite comparar dos archivos de texto binários. Aunque funciona la mayoría de las veces, tiene bastantes errores de diseño y, con ciertas condiciones especiales falla.


#include 

#include 



#define SIZE 256



// Devuelve 1 si son distintos y 0 si son iguales.

int cmpArrays(char a1[], char a2[], int size);



int main(int argc, char *args[])

{

  char buff1[SIZE], buff2[SIZE];

  int fd1, fd2;

  int readed1, readed2;



  fd1 = open(args[1], O_RDONLY);

  fd2 = open(args[2], O_RDONLY);



  while ( (readed1=read(fd1, buff1, SIZE)) >0) {

    readed2=read(fd2, buff2, SIZE);

    if (readed1 != readed2) {

      printf("\nArchivos de distinto tamaño.\n");

      return 0;

    }

    if (cmpArrays(buff1, buff2, readed1)) {

      printf("\nArchivos con distinto contenido.\n");

      return 0;

    }

  }



  close(fd1);

  close(fd2);



  printf("\nArchivos iguales.\n");



  return 0;

}





//------------------------------------



int cmpArrays(char a1[],char a2[], int size)

{

  int c;



  for (c=0; c < size;c++)

    if (a1[c] != a2[c])

      return 1;



  return 0;

}

Guardar la entrada estándar en un fichero.

2005-01-29T11:36:00.000Z

Saludos.

El siguiente código va leyendo la entrada estándar y guardando lo leido en un archivo buffer.f




#include 

#include 

#include 



int main()

{

  int fd;

  char *buffer[256];

  int b_leidos, b_escritos;



  fd = open("buffer.f", O_WRONLY | O_APPEND);

  if (fd == -1)

  {

    printf("\nCreando fichero 'buffer.f'\n");

    fd = open("buffer.f", O_WRONLY | O_CREAT, 00600);

    if (fd == -1)

    {

      perror("Error creando 'buffer.f'\n");

      return -1;

    }

  }



  b_leidos = read(0, buffer, 256);

  while (b_leidos > 0)

  {

    b_escritos = write(fd, buffer, b_leidos);

    if (b_escritos == -1)

    {

      perror("Error escribiendo.\n");

      return -1;

    }

    b_leidos = read(0, buffer, 256);

  }

  close(fd);

}

Funciones potencial y factorial

2005-01-23T13:48:00.000Z

Saludos.

Como recordatorio de la manera de hacer bibliotecas de funciones y de las técnicas recursivas, se propuso como ejercicio implementar una biblioteca de funciones con una función potencial y otra factorial. A continuación se muestra dicha biblioteca con versiones recursivas y no recursivas.

Próximamente más.

pot_fac.h


#ifndef __pot_fac__

#define __pot_fac__



int potencial_nr(int, int);

int potencial_r(int, int);

int factorial_nr(int);

int factorial_r(int);



#endif

pot_fac.c


#include "pot_fac.h"



int potencial_nr(int valor, int potencia)

{

int i, resultado;

resultado = 1;

for (i=0; i 0; i--)

resultado *= i;

return resultado;

}



//---------------------------------------------

int factorial_r(int valor)

{

if (valor == 1)

return 1;

return valor * factorial_r(valor-1);

}

prueba_pot_fac.c


#include "pot_fac.h"



int main() {



  int resultado;



  resultado=potencial_nr(4, 3);

  printf("4 elevado a 3 %i (no resursivo)\n", resultado);



  resultado=potencial_r(3, 3);

  printf("3 elevado a 3 %i (resursivo)\n", resultado);



  resultado=factorial_nr(4);

  printf("4 factorial %i (no resursivo)\n", resultado);



  resultado=factorial_r(6);

  printf("6 factorial %i (resursivo)\n", resultado);



  return 0;

}

Contar caracteres de una frase

2005-01-23T13:25:00.000Z

Saludos.

Este ejercicio se propuso para que los alumnos repasaran sus conocimientos de manejo de cadenas en C. El objetivo es introducir una frase en la línea de comandos. El programa devolverá el número de veces que se repite cada una de las letras en la frase.

Próximamente más.


#include "stdlib.h"

#include "string.h"



// Variables globales;

char caracteres[29];

int car_index = 0;

int repeticiones[29];



// Prototipos

void incCaracter(char caracter)

{

  int pos = -1;

  int i;



  for (i=0; i< car_index; i++)

    if (caracteres[i] == caracter)

      pos = i;



  if (pos == -1) {

    //car_index++;

    caracteres[car_index] = caracter;

    repeticiones[car_index] = 0;

    pos = car_index;

    car_index++;

  }



  repeticiones[pos] ++;

}



//-----------------------------------------------------

int main(int argc, char *argv[])

{

  char cadena[255];

  int i = 0;

  

  if (argc < 2) {

    printf("Parámetros insuficientes. \n");

    return -1;

  }

  strcpy(cadena, argv[1]);

 

  while (cadena[i] != '\0')

  {

    incCaracter(cadena[i]);

    i++;

  }



  printf("Estadísticas de <%s>: \n", cadena);

  for (i=0; i < car_index; i++)

    printf("%c : %i \n", caracteres[i], repeticiones[i]);



  return 0;

}

Operación Limpieza

2005-01-19T17:22:00.000Z

Aviso a navegantes.

Por estas fechas termino de impartir una serie de clases sobre programación C básica en sistemas Unix/Linux (Fedora y SunOS). Por este motivo voy a ir publicando aquí en los próximos días el código de los ejemplos y problemas extra que he ido proponiendo a mis alumnos.

También pondré de vez en cuando algún otro post como los que hay más abajo para que esto no se convierta en un monográfico C bajo Unix.

Convertir double a caddena

2005-01-16T10:55:00.000Z

Saludos.

El otro día me preguntaron como pasar un tipo double a cadena con un número determinado de decimales, por ejemplo 2, en Java. Una posible solución se muestra a continuación:




import java.text.DecimalFormat ;



public class Decimal {



public static void main(String args[]) {



double d1 = 123456789.123456789;

double d2 = 1.7976931348623157d;

double d3 = 4415961481999.03D;

DecimalFormat df = new DecimalFormat ("##############.##");



System.out.println ("d1:"+df.format(d1));

System.out.println ("d2:"+df.format(d2));

System.out.println ("d3:"+df.format(d3));



/**

Salida:

>java Decimal

d1:123456789,12

d2:1,8

d3:4415961481999,03

}

}

Pruebas como indicadores del avance de un proyecto.

2005-01-14T13:16:00.000Z

¿Cuándo finaliza la construcción de un programa?. ¿Cuánto hemos avanzado esta semana?. ¿Vamos más rápidos o más lentos que el mes pasado?.

Todas estas preguntas se refieren a la velocidad con la que se crea o construye un programa y, en muchas ocasiones no son fáciles de responder. Una primera idea podría ser pensar que el avance de un programa tiene relación con las líneas de código escritas o número de clases implementadas, pero nada más lejos de la realidad. Es posible, por ejemplo, escribir 100.000 líneas de código o 50 clases en una semana y que el proyecto no avance ni un ápice, porque, por ejemplo, el código no funcione correctamente y necesite una depuración a fondo, o no pueda incorporarse al resto del programa o tenga que ser reescrito o, simplemente, se haya escrito código para una característica o función que no va a tener el sistema, por lo que no habrá servido de nada.

Una aproximación más fiable, pero aún no perfecta desde mi punto de vista, es relacionar el avance del proyecto con el cumplimiento de los requisitos. Un requisito es una característica que el sistema debe tener o algo que debe permitir hacer. A medida que vayamos escribiendo código, el sistema permitirá hacer cada vez más cosas, hasta que el sistema sea capaz de hacer todo lo que le piden los requisitos, momento en el que estará terminado. Sin embargo a veces es difícil cuantificar, a partir del código, el cumplimiento de requisitos. Por ejemplo, en un sistema típico de gestión comercial, si empleamos dos semanas en construir las bases de datos y las clases de acceso a las bases de datos (algo que será necesario para todos los requisitos), ¿qué grado de cumplimiento de los requisitos hemos conseguido un 1%, un 10%?. ¿Algún requisito habrá avanzado más que otro?. ¿Cuánto nos queda para satisfacer todos los requisitos?.

La mejor aproximación desde mi punto de vista, y que aúna características de las dos anteriores, es medir el avance del proyecto en función de la superación de pruebas. El proyecto estará terminado cuando sea capaz de superar todas las pruebas que lo verifiquen. Una semana se avanzará más que otra si ha sido capaz de superar todas las pruebas de la semana anterior y un número mayor de nuevas pruebas. Esta aproximación nos permite además, medir el desarrollo del código, mediante pruebas unitarias, y medir el cumplimiento de requisitos, mediante pruebas del sistema o pruebas de aceptación. En el momento en que ambas medidas alcancen el máximo, el sistema hará todo o que debe hacer sin errores en su código.

Un motivo más que justifica escribir pruebas para nuestros proyectos: no solo nos garantizan el cumplimiento de requisitos y la ausencia de errores, sino que nos permiten conocer el estado de nuestro proyecto, a que ritmo avanza y cuanto queda para su conclusión.

Límite de procesos en Unix/Linux

2005-01-06T18:28:00.000Z

Saludos.

Preparando una clase de programación en C Unix/Linux he intentado hacer un ejemplo donde un gran número de procesos accedieran simultáneamente a un trozo de memoria compartida y los resultados no fueran los esperados. Con esto pretendía ilustrar la necesidad de garantizar la exclusión mútua.

No lo he conseguido. Mi Knoppix solo me ha permitido lanzar 487 procesos simultáneamente, mientra que SunOS me dejaba algunos más, hasta 496, 497 más o menos. Por desgracia con este número de procesos todo funcionaba a la perfección y, aunque no garantizara la exclusión mútua, ningún proceso se pisaba a otro.

Tnedré que escribir un programa donde fuerce la situación con unos sleep estratégicamente colocados.

Es una alegría que los Linux/Unix funcionen bien incluso cuando uno quiere que fallen.

Felicitación al mayor genio de la informática.

2004-12-29T10:20:00.000Z

No quiero dejar pasar la ocasión de, en estas fiestas navideñas, felicitar al mayor genio de la informática de toda la historia, un visionario, un profeta adelantado a su tiempo, sin el cual esta ciencia y arte a la vez probablemente no existiría. No me refiero a Bill Gates, ni a Alan Turing, nia Dennis Ritchie, ni a Linus Torvarld, ni tampoco a Von Newman. Hablo del hombre que debe ser por méritos propios patrono de los informáticos (por encima de santa Tecla), el cual se merece todos los parabienes y homenajes, el hombre que tendría que tener una escultura en todas las escuelas de informática del mundo, el hombre que ha conseguido que en todas las casa y oficina hay un ordenador, y a veces, hasta más de uno, el hombre sin el cual no existiría Internet ni el 99% de los programas existentes en la actualidad..

Feliz navidad y próspero año nuevo para el hombre que inventó el copy&paste.

DumpTable

2004-12-22T19:06:00.000Z

Saludos.

Actualmente estoy realizando un trabajo sobre herramientas de álgebra relacional, por lo que he tenido la necesidad de disponer de una herramienta que me permitiera volcar el contenido de una tabla de una base de datos en un archivo de texto que siguiera un formato concreto. Por ejemplo, a partir de una tabla, crear un archivo de texto con sentencias INSERT para cada registro de la tabla.

Por ese motivo he creado una sencilla herramienta llamada DumpTable que está a disposición de quien la quiera en la página de proyectos JavaHispano.net (http://javahispano.net/projects/dumptable/).

Para algunos alumnos de facultades que tienen que sufrir la herramienta WinRDBI en prácticas, puede resultarles de ayuda ya que pueden generar bases de datos para esta herramienta a partir de una tabla de una base de datos con lo cual se ahorran tener que pelearse con la incómoda interfaz de usuario y tener que introducir los registros a mano.

También incluyo documentación sobre su diseño, principalmente diagramas UML, por lo que puede ser interesante como ejemplo pedagógico (a imitar o a evitar, eso lo dejo a consideración de quien lo vea).

Proyectos open-source en Rediris y Knoppix.

2004-12-15T19:09:00.000Z

Saludos.

En el servidor sunsite de rediris (http://sunsite.rediris.es/) se pueden encontrar gran cantidad de mirrors actualizados de muchos proyectos open-source interesantes (entre ellos varias distribuciones de Linux). Aparte de la ventaja de tenerlos todos en el mismo sitio, las velocidades de descarga de los archivos son bastante interesantes.

En cocnreto, en la carpeta de Knoppix (http://sunsite.rediris.es/mirror/knoppix/), he encontrado (además de las distribuciones), algunas utilidades interesantes y una lista con todos los paquetes que Knoppix incorpora, y la verdad es que me he llevado más de una grata sorpresa (por ejemplo, Knoppix es LAMP). Espero ir escribiendo más mensajes próximamente hablando de Knoppix y sus posibilidades.

Insertar un registro en MySQL con Java.

2004-12-12T18:09:00.000Z

Saludos.

Hace poco un alumno me comentó como podía insertar un registro en una base de datos en MySQL. Por si a alguien le resulta de utilidad, copio a continuación el código que le envié de ejemplo:

Lo primero que se necesita (además de tener NySQL instalado y en ejecución), es un driver JDBC, por ejemplo MySQL Connector que se puede descargar de la página de MySQL (www.mysql.com). Junto con el driver se distribuye también documentación y archivos de ejemplo.

A continuación se incluye el código fuente de una clase más sencilla que las que acompañan al driver y que muestra como insertar un registro. Para que dicha clase funcione es necesario que el JAR (por ejemplo "mysql-connector-java-3.0.16-ga-bin.jar") se encuentre en el CLASSPATH.


import java.sql.Connection;

import java.sql.DatabaseMetaData;

import java.sql.DriverManager;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;



import java.util.Properties;



public class InsertarRegistro  {



    protected Connection conn = null;

    protected Statement stmt = null;





    /**

     * Conecta con la base de datos 'cliente' de un servidor

     * MySQL local.

     */

    public void conectar() throws Exception {

        Class.forName("com.mysql.jdbc.Driver").newInstance();

        this.conn = DriverManager.getConnection("jdbc:mysql:///Clientes");

        this.stmt = conn.createStatement();

    }



    /**

     * @throws Exception DOCUMENT ME!

     */

    public void desconectar() throws Exception {

        if (this.stmt != null) {

            try {

                this.stmt.close();

            } catch (SQLException SQLE) {

                ;

            }

        }

        if (this.conn != null) {

            try {

                this.conn.close();

            } catch (SQLException SQLE) {

                ;

            }

        }

    }



    protected void insertarUnCliente() throws SQLException {

          String sql = "INSERT INTO Clientes VALUES ('', 'entidad', " + 

                                                        "'actividad'," + 

                                                        "'direccion', " + 

                                                        "'localidad', " +

                                                        "'codigo_postal', " + 

                                                        "'telefono', '', '', '');";

          stmt.execute(sql);          

    }



    

    public static void main(String[] args) {

      InsertarRegistro ie = new InsertarRegistro();

      try {

        ie.conectar();

        ie.insertarUnCliente();

        ie.desconectar();

      }  catch (Exception e) {

        e.printStackTrace();

      }

      System.out.println("Ok!");

    }

}

Java pierde popularidad.

2004-12-10T20:41:00.000Z

Saludos.

La notia ya tiene algunas semanas y ya ha sido comentada en otras páginas con mucha audencia, pero no me resisto a omentarlo aquí.
Al parecer, en una web (http://www.tiobe.com/tpci.htm) se dedican a calcular la popularidad de los distintos lenguajes de programación. En principio me pare que utilizan un método muy acertado (independientemente de su eficacia o no), que es, a grandes rasgos, contar enlaces en el Google.
Lo que me llama la atención no es tanto que Java baje posiciones, aunque se queda en el segundo puesto, sino que sea desbancado por el C de toda la vida (sin clases ni objetos), inventado allá por 1974, más o menos.
También me ha llamdo la atención ver el poco tirón que ese informe le adjudica a C#, un lenguaje que yo pensaba que estaba teniendo mucho tirón de la mano de Microsoft.

Mensaje inagural

2004-12-10T17:07:00.000Z

Saludos a todos.

Este blog tratará de temas d eprogramación y relacionados con la informática y, especialmente, de lenguaje Java. En este blog espero ir escribiendo mensajes útiles que rcojan las herramientas, enlaces y experiencia de mi trabajo cotidiano.

Por cierto, el tírulo es un pequeño homenaje al juego Warcraft III, en versión doblada al español.