martes, 9 de octubre de 2007
Documentación de seminario de Metadatos SQL
jueves, 3 de mayo de 2007
Uso de metadatos para errores SQL
De forma genérica los metadatos son datos sobre los datos.
En los sistemas gestiores de base de datos, los metadatos almacenan la estructura de las tablas, los campos, las restricciones, etc.... Suelen ser vistas o tablas especiales de diccionario.
También podemos considerar metadatos como las descripciones que podemos dar de tablas o campos para que puedan ser entendibles por un usuario final.
Así, podemos darle dos utilidades inmediatas al concepto de metadatos:
- Dar una información más detallada de lo ocurrido ante una excepción de SQL. En lugar de un mensaje de error del tipo : "Se ha violado la restricción PK_OP" podemos llegar a generar un mensaje más claro, del tipo "Se ha violado la clave primaria PK_OP, de la tabla OPERACIONES. Los campos de la clave son: ID_OPERACION, ID_ANYO" De esta forma un desarrollador puede encontrar mucho más rápido la causa de un error, sobre todo en modelos complejos.
- Dar información orientada al usuario final. Ante el mismo error, podríamos llegar a generar algo del estilo: "Se ha producido un error por insertar una operación que ya existía"
Los metadatos del tipo 1 necesarios nos los proporciona el Sistema Gestor de Base de Datos.
Los de tipo 2 tendríamos que mantenerlos nosotros, como una extensión del diccionario de base de datos con repecto a entidades de negocio inteligibles por un usuario.
Hasta aquí la introducción. Ahora pasemos a ver un posible uso de los metadatos de tipo 1
jueves, 15 de marzo de 2007
Próximos Artículos Tecnológicos
- Uso de metadatos para la gestión de errores SQL con java. Autor: David Valdés. Impartido ya.
- Etiquetado en EJB 3.0. Autor: David Valdés
- Plugins de BBDD para eclipse 3.2. Autor: David Valdés
- Hipersonic. Autora: Mireya del Teso(12/11/2007)
- Izpack. Autora: Mireya del Teso
- Ajax. Autor: Oscar Mena
- json. Autor: Oscar Mena
- XSLT. Autor: Oscar Mena
- Spring. Autor: Isaac Remiro
- JSF. Autor: Isaac Remiro . Impartido (05/11/2007)
- JMS y MBeans con EJB 3.0. Autor: Diego Núñez
- jakarta-commons BeanUtils. Autor: Diego Núñez
- JUnit4. Autor: Diego Núñez. Impartido ya(mayo/2007).
- CSS Level 2. Autor: Isaac Remiro
- Jakarta-commons configuration. Autora: Mireya del Teso
- iBatis. Autor: Jose Luis Domínguez. Impartido (30/10/2007).
- SQL Avanzado: Javier Berrocal
- Novedades de Java 5: Pio Castro. Impartido(22/10/2007)
- Batik: Ivan Georgiev. Impartido (04/12/2007)
viernes, 9 de marzo de 2007
MDA
De momento he encontrado androMDA como herramienta opensource.
jueves, 8 de marzo de 2007
JUnit 4
Este artículo está orientado a desarrolladores java sin ningún conocimiento previo excepto nociones básicas de programación en Java. No es necesario conocimientos previos en Junit 3.x.
ResumenEste artículo explica las novedades que ofrece la nueva versión del framework para realizar pruebas unitarias con Java JUnit versión 4.x, sobre la versión 3.x. Repasa brevemente las funcionalidades y estructura de la versión 3.x para posteriormente repasara en mas detalle las nuevas funciones de JUnit 4.x con la incorporación de las anotaciones de Java 5 siguiendo unos ejemplos simples que prueban un EJB tipo calculadora y su integración en el IDE de desarrollo eclipse 3.2.x y ANT para la automatización de las pruebas, como aconseja las metodologías ágiles de automatizar toda la fase de integración y pruebas todo lo que se pueda. Por último se dan una serie de consejos de buenas prácticas para implementar buenas pruebas unitarias.
Introducción
JUnit es una herramienta fundamental en el contexto de las metodologías ágiles capitaneadas por el Extrem Programming[1] cuyos fundadores Martin Fowler[2] y Ken Beck [3] a través de múltiples artículos y estudios han puesto encima de la mesa de los programadores subconjuntos de metodologías, buenas prácticas o estilos de programación como el Test Driven Developement (TDD) donde el desarrollo se comienza por las pruebas unitarias y se termina con los componentes que pasan dichas pruebas, y la Integración continua que persigue como objetivo principal que la fase de construcción del software dede el código fuente sea un proceso idealmente automático donde las pruebas de regresión JUnit son parte de la garantía de la calidad del software. En resumen es más efectivo dedicar tiempo a diseñar una buena prueba unitaria que estar dejándote las pestañas con el debugger para ver que está ocurriendo.
Siguiendo estas buenas prácticas se consigue que:
EL sistema esté cubierto enteramente por pruebas unitarias.
Fomenta un diseño con bajo acoplamiento y alta cohesión, simplemente por el hecho que a la hora de programar estamos pensando ya en como probarlo.
El sistema crece de forma incremental, construyendo cada vez más piezas con su correspondiente prueba unitaria.
Pasar las pruebas de regresión una y otra vez tiene un coste mínimo podríamos decir que despreciable frente a un sistema que carece de ellas.
La aparición de de JUnit se produjo en 1999 de manos Erich Gamma com la versión Java del primer desarrollo del framework realizado por Ken Beck SUnit Simple Smalltalk Testing: With Patterns para Smaltak y que posteriormente se ha generado dicho framework para otros lenguajes de programación conocida como Xunit.
Bibliografía