Blogs

Agreement Technologies (AT) - Tecnologías de Acuerdo

 

AT es el mayor proyecto de investigación al que se ha enfrentado el IIIA. Se trata de la búsqueda de un nuevo paradigma para sistemas distribuidos. Este nuevo paradigma se estructura a través del concepto de acuerdo entre agentes software… bueno… creo que el coordinador del proyecto, el Prof. Carles Sierra, seguro que lo explica mejor que yo y además en menos de 2 min.:

 


Get the Flash Player
to see this player.

 

¿Cómo?

Las líneas de investigación se han estructurado en una arquitectura de torre de 5 niveles.

Arquitectura AT

 

  • Nivel 1: Semántica y gestión de recursos. Solucionar incompatibilidades semánticas y establecer ontologías para comprender las normas o acuerdos.
  • Nivel 2: Definición de las normas que determinan las restricciones que todo acuerdo debe satisfacer. En este nivel se debe estudiar la capacidad del software para adaptarse a la normativa.
  • Nivel 3: Organizar las estructuras sociales de los agentes: roles y relaciones entre ellos.
  • Nivel 4: Este nivel es para el estudio de métodos de argumentación y negociación. Esto se traduce en alcanzar acuerdos que respeten las restricciones que las normas y organizaciones imponen a los agentes.
  • Nivel 5: La capa de confianza que se encargará de construir las relaciones entre agentes a partir de la reputación que adquieran estos. Muy importante para un sistema abierto como éste.

¿Quién? ¿Cuándo?

Más información

www.agreement-technologies.org

 

Desde la UDT-IA seguimos dando nuestro apoyo al proyecto.

Metodología de desarrollo de sotware. El Modelo en V o de Cuatro Niveles.

 

Imaginemos, si no hubiera crisis (desaceleración debido a la coyuntura económica internacional, que diría mi primo) que quiero construirme una casa.

¿Qué pensaríais de mí si empezara a poner ladrillos sin antes haber hecho un estudio...
...del suelo, materiales, recursos, y sin haber hecho un diseño previo? Pensaríais de mí, lo mismo que yo pienso de la gente que se pone a programar sin seguir una metodología de programación.

La metodología que os presento es el Modelo en V, o Modelo de Cuatro Niveles

¿En qué casos la utilizo?
Se trata de un proceso ideal, por su robustez, para proyectos pequeños, con equipos de una a cinco personas. 

También es ideal, por su claridad, para toda esa gente que nunca ha programado siguiendo una metodología. Para el proyecto final de carrera o para ese cliente que te ha conseguido un amigo de un amigo que te lo pide a ti y no se dirige a una empresa por esto de la desaceleración.

¿En que consiste exactamente?
La figura que aparece a continuación presenta el Modelo en V, o Modelo de Cuatro Niveles, del ciclo de vida de un proyecto de desarrollo de software. El modelo representa, en forma de V, las relaciones temporales entre las distintas fases del ciclo de desarrollo de un proyecto.

 

Modelo en V o Modelo de Cuatro Niveles

 

En los niveles lógicos del 1 al 4, para cada fase del desarrollo, existe una fase correspondiente o paralela de verificación o validación. Esta estructura obedece al principio de que para cada fase del desarrollo debe existir un resultado verificable.

En la misma estructura se advierte también que la proximidad entre una fase del desarrollo y su fase de verificación correspondiente va decreciendo a medida que aumenta el nivel dentro de la V. La longitud de esta separación intenta ser proporcional a la distancia en el tiempo entre una fase y su homóloga de verificación.

  • El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.
  • El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.
  • El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema.
  • El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del programa.

¿Tengo que hacer documentación de todo?
Por supuesto. Cada fase tiene que estar respaldada por su documento correspondiente y test.

¿Por qué utilizar una metodología?
Porque es lo más rápido y barato. Volviendo al ejemplo de la casa, imaginad la cantidad de veces que debería volver atrás y tirar paredes ya hechas porque de pronto descubro que el suelo es inestable, la bañera no cabe, la instalación eléctrica no la había tenido en cuenta… 
Pues, con el código pasa exactamente lo mismo.

Usabilidad en las Interfaces Gráficas de Usuario - GUI (I)

 

Alguien dijo una vez que "el hardware es aquella parte del ordenador que se lleva las hostias cuando falla el software". La frase va más allá de una simple gracia y tiene implicaciones muy importantes.

La implicación más inmediata, a parte de los destrozos que nuestra ira pueda causar, sería el reconocimiento de que el software muchas veces no cumple nuestras expectativas.

 

Yo voy más allá,  simplifico la cuestión al Problema de Realizar Interfaces de Usuario o,  como es el caso que nos ocupa, interfaces gráficas de usuario. Sí, sí… estoy diciendo que si estuvieran bien hechas, no perderíamos la paciencia tan fácilmente con nuestro PC.

Existe toda una teoría que intenta abordar esta cuestión, metodizando el proceso de creación de GUIs para que el diseño sea centrado en el usuario, aunque pocos nos hemos interesado por ella.

Como desarrollador de software, durante un tiempo se me encasilló en el papel de "experto en GUIs". ¡Qué fácil es ser experto en algo en este país!

La verdad es que experto no era, pero a ojos de las empresas en las que buscaba trabajo sí (que es lo que cuenta). Recuerdo una entrevista para una conocidísima inmobiliaria en que La Prueba consistía en criticar una GUI de un producto propio.  Abordé, con éxito, las siguientes cuestiones que quiero compartir con mis lectores porque son básicas para un buen diseño:

 


1. Simplicidad

El punto óptimo se alcanza cuando la GUI ha sido simplificada al máximo sin reducir un ápice su funcionalidad.

 

El éxito de Google es que es sólo un buscador

El éxito de Google, la simplicidad. Buscador que busca.

 

2. Mantenibilidad

No establecer nunca los elementos de nuestra GUI en posiciones absolutas. Utilizar siempre posiciones relativas o layouts. A ser posible.

 

Poco mantenible
Este es el penoso aspecto que tiene ahora una de mis primeras aplicaciones
en Java, de hace 4 ó 5 años, por no haber usado layouts

 

Tener en cuenta ésto mejora el aspecto de nuestras aplicaciones a lo largo de los años (se adapta a nuevas resoluciones, plataformas, etc.), también permite añadir nuevos elementos a la GUI sin trastocarla. 


3. Distribución

Para los formularios, hacer "uniones lógicas" de campos, esto es que los campos que se encuentren próximos entre sí tengan relación. Idealmente los campos se colocan en el orden de tabulación de izquierda a derecha y de arriba a abajo.

 

Campos bien distribuidos
Campos bien distribuidos. Porción de una aplicación que, junto a
mi antigua empresa, hice para el gobierno de la Generalitat.

Malísima distribución
Una conocidisísma empresa de transporte de paquetería, para la cual me obligaron a trabajar.
¿No seria más claro agrupar dirección-población-provincia? ¿Teléfono-eMail?

 

Continuará...

Usabilidad en las Interfaces Gráficas de Usuario - GUI (II) [Actualización 13/10/2008]

Nueva imagen, nuevas rutas en la I+D

Bienvenidos a nuestra nueva web, y si es la primera vez que descubrís
la existencia de la UDT-IA, esperamos que la ampliación de este canal
de comunicación os ayude a saber de nosotros.

Drupal vs Plone

 

Drupal vs PloneHe tenido la oportunidad de trabajar con ambos sistemas de gestión de contenidos para construir sitios web y me gustaría compartir algunas conclusiones personales.

Ambos son Sistemas de Gestión de Contenidos con licencia GPL, escalables, modulares, con flexibilidad en el uso de plantillas y permisos, de fácil instalación, multiidioma, con soporte a la localización, workflow y con una gran comunidad tras ellos. Plone está basado en lenguaje Python y Drupal en PHP.

Drupal es mucho más reducido en comparación a Plone. La complejidad de este último reside en que se trata de una capa de usuario sobre un poderoso framework, el Content Management Framework CMF, que se ejecuta en el servidor de aplicaciones Zope. Esto convierte a Plone en un sistema tan potente como complejo. 

Gadgets y supervivencia

No hay semana en la que no aparezcan nuevos cacharritos informáticos para llevar en el bolsillo. De hecho hay webs de noticias diarias exclusivamente especializadas en gadgets tecnológicos. Algún estudioso podría trazar un mapa en árbol de las diversas familias de gadgets. El gadget informático es una especie que habita en los mismos nichos ecológicos que los seres humanos. Bien domesticados son indudablemente útiles, cualquier madre sabe lo distinto que es ir con su hijo a la consulta del médico con una GameBoy o sin ella.

Syndicate content