O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

1ARQUITECTURA

Control calidad

de los programasLos ordenadores se encargan del vuelo de los aviones comerciales,

de los sistemas bancarios, de las comunicaciones, de las ventas al por menor

y de muchos procesos fabriles. Poderosos instrumentos de verificación

comprobarán la fiabilidad de los programas informáticos

Baniel Jackson

E1 aeropuerto internacional de Denverse inauguró hace once años. Entre susmaravillas técnicas y arquitectónicas,la rnayor era un sistema automático degestión de equipajes que debía condu-cir, sin intervención humana, bultos y

maletas por una red de 40 kilómetros de cintastransportadoras para entregarlos rápidamente ysin tropiezos a los aviones o a los viajeros. Peroel sistema padeció un sinfín de problemas in-formáticos, que obligaron a retrasar 16 meses laentrada en servicio del aeropuerto y añadieron alpresupuesto centenares de millones de dólares.Nunca llegó a ser del todo fiable, pese a añosde reajustes. En otoño de 2005, los responsablesdel aeropuerto decidieron desconectarlo y volvera utilizar los tradicionales trenes de vagonetas,cargados a mano, conducidos por seres humanos.La compañía que lo diseñó, BAE Automated Sys-tems, ya no existe. La bancarrota en que se encontró su mayor usuario, United Airlines, se debióen parte a este desastre informático.

Millones de frustrados usuarios pechan a diariocon los elevados costes de los programas maldiseñados. Entre otros casos sonados se cuen-tan los onerosos fiascos de la agencia tributariaestadounidense, con una primera y fallida ten=tativa de modernización en 1997 que costó másde 4000 millones de dólares, seguida por una"actualización" no menos accidentada (8000 mi-llones de dólares); un sistema de gestión virtualde ficheros de casos del FBI (170 millones dedólares) que tuvo que ser eliminado por inútilen 2005; o el persistente y aún infructuoso in-

tento de la Administración Federal de Aviaciónde renovar su envejecido sistema de control deltráfico aéreo.

Estos fracasos colosales se deben a que losproyectos contienen errores capitales que se des-cubren demasiado tarde. La inadecuación de losdiseños sólo queda de manifiesto después de quelos programadores hayan empezado a construirel código, las instrucciones que ha de recibir lamáquina para ejecutar un programa. A veces elfallo reside en alguna incongruencia u omisiónfatal, pero lo más frecuente es que el diseño deconjunto sea impreciso y no esté suficientementemeditado. Conforme el código va creciendo, conadición de parches y arreglos parciales, empiezaa cuajar un diseño con una estructura detalladapero llena de casos particulares y puntos débiles,falta de principios coherentes. Y lo mismo queen los edificios, cuando los cimientos no tienenfirmeza, la estructura es inestable.

Los directivos implicados en los "apagones"informáticos más sonados podrían aducir en sudefensa que se atuvieron a la manera establecí-da de proceder, y desdichadamente estarían enlo cierto. Los programadores de sistemas raravez enuncian sus diseños de forma rigurosa, nianalizan suficientemente si cuentan con todaslas propiedades deseadas. Pero los ordenadoresse encargan hoy del vuelo de los aviones yde la conducción de trenes y vehículos. Sobreellos reposa la gestión de las finanzas, de lastelecomunicaciones, de las fábricas y del co-mercio minorista de todo el mundo. La sociedadtiene una necesidad apremiante de mejorar la

O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

2ARQUITECTURA

fiabilidad de los programas infor-máticos.

Está germinando una nueva gene-ración de útiles para el diseño deprogramas (véase el recuadro "Utilespara verificar diseños informáticos").Sus ingenios de análisis se asemejan,en principio, a ciertas herramientascada vez más utilizadas en ingenieríaeléctrica para verificar los diseñosde los ordenadores. Se modeliza eldiseño del programa que se va acrear mediante una codificación dealto nivel (la manera compendiada deimpartir instrucciones a la máquina)y después se aplica una herramien-ta que explora miles de millones deposibles ejecuciones del sistema,buscando situaciones inusitadas quepudieran provocar que se comporta-ra de forma ah~mala. Este procesopermite detectar rallos sutiles en eldiseño, antes de que se proceda a sucodificación, pero, lo que es más im-portante, engendra diseños precisos,robustos y concienzudamente proba-dos. Un ejemplo de tales herramientases Alloy, concebida por el autor y sugrupo de investigación. El analizadorAlloy (disponible gratuitamente enla Red) ha demostrado su utilidaden aplicaciones tan diversas comola informática para la aviónica, latelefonía, los sistemas criptográficoso los equipos para el tratamiento delcáncer (véase el recuadro "Depura-ción de máquinas para el tratamientodel cáncer").

Tanto Alloy como otros instru-mentos de verificación de diseñosinformáticos hunden sus raíces enlas investigaciones, desarrolladas alo largo de un cuarto de siglo conla intención de encontrar modos dedemostrar matemáticamente si losprogramas son o no correctos. Peroen lugar de exigir que las demos-

R

2. SISTEMA FALLIDO de distribución automática de equipajes en el AeropuertoInternacional de Denver.

traciones se efectúen "a mano", sevalen de técnicas de razonamientoautomatizado, que tratan los diseñosinformáticos como si fueran gigantescos "rompecabezas". Estos ana-lizadores operan sobre diseños, nosobre el código de los programas,por lo que no pueden garantizar queun determinado programa no vaya aestrellarse. Sí ofrecen, posiblemen-te, a los informáticos los primerosinstrumentos prácticos para garan-tizar que sus diseños son robustosy carecen de fallos conceptuales;proporcionarán así sólidos cimientos sobre los que levantar sistemasde programas fiables.

Evaluación de proyectosEl problema de los programas deescasa calidad no es de hoy. Lasadvertencias de una posible crisisinformática se remontan a hace unos

~sumen/Verificad0res de diseño de pr0aramas¯ A pesar de la importancia de los programas informáticos en la vida

diaria, cada vez mayor, rara vez se analiza, para garantizar su fia-bilidad, su diseño. Una situación que comienza a cambiar debido aldesarmUo reciente de instrumentos de verificación del diseño de pro-gramas, entre ellos Alloy.

¯ En AIIoy se ha combinado un lenguaje que facilita la modebzación deldiseño de programas complejos con un motor de análisis que verificaautomáticamente la posible existencia de rallos estrueturales y trata alos diseños como si constituyeran enormes rompecabezas.

¯ En un futuro no muy lejano, instrumentos similares a Alloy mejoraránmucho la fiabilidad de los programas. Basarán el desarrollo de losmismos en procedimientos de diseño más robustos y constructivos.

40 años y no han parado de inten-sificarse al irse entretejiendo cadavez más la informática en el tejidosocial (véase "La crisis crónica de laprogramación", por W. Wayt Gibbs;INVESTIGACIÓN Y CIENCIA, noviem-bre de 1994].

En nuestros días, casi todos losprogramas se depuran y refinanmediante ensayos. Los informáticosejecutan el programa para una granvariedad de condiciones iniciales afin de comprobar que su funcionamiento corresponde a lo previsto. Asísuele sacarsc a la luz una variedadde pequeños defectos, pero a menudose pasan por alto rallos graves en laconcepción básica de los programas.En cierto sentido, tales ensayos dejande ver los bosques enfermos parafijarse en los árboles podridos.

Y lo que es peor: los gazaposcorregidos durante el proceso deensayo exacerban, a menudo, losproblemas de diseño, pues a la vezque los programadores depuran elcódigo introducen nuevos elemen-tos; el programa tiende inexorablemente a generar complejidades ycrear nuevas ocasiones de error yde funcionamiento ineficiente. Estasituación invita a pensar en la teoríaptolcmaica de los movimientos planetarios con sus epiciclos, originadaen la antigua Grecia, en los días dellmperio Romano. Cuando las obserraciones hicieron ver en la Edad Me-dia que las prcdicciones ptolemaicas

O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

3ARQUITECTURA

ALLOY EN ACCION

AIIoy facilita a los diseñadores de programas el descubrimiento y corrección de errores de diseño. Les proporcionaun lenguaje que aclara la estructura de los programas.Les suministra también un analizador automático queexplora el enorme número de posibles ejecucÍones de unsistema en busca de un "contraejemplo" que permita verque podría no funcionar como se espera. En el ejemploelemental que sigue, se utiliza AIIoy para evaluar el dise-

ño de un sistema de archivos de ordenador, compuestopor los programas que los organizan en carpetas y losaimacena en un disco. Una tarea esencial que AIIoy deberealizar es establecer los efectos de las diversas opera-ciones sobre la estructura de archivos. Aquí se muestrata modelización y comprobación de la operación quetraslada una carpeta, o "directorio", de una posición de lajerarquia de archivos a otra.

CODIGO ALLOY

PASO 1: DEFINICION DE LOS OBJETOS ,El proyectista identifica los objetos del sistema (los ...... ~ ~ Larchivos, los directorios y el sistema de archivos comoun todo) y sus relaciones mutuas. El modelo de AIIoydeclara que el sistema de a~chivos (FS) tiene tres com- ponentes: "archivos" (su conjunto de archivos), "dirs" (su :conjunto de carpetas) y "contiene" (una correspondenciaque proporciona, para cada directorio, et conjunto dearchivos y carpetas que contiene),

EFECTObjetos,Mapa

de relaciones . .................... Raizi Contiene

Dirs

Archivos i

PASO 2: MODELO DE LA OPERACIONA continuación se modeHza la traslación ("more dir")del sistema de archivos previo ("fs") a un sistema archivos posterior ("fs’"), En la operación intervienendos carpetas: "d", que es la carpeta que se estátrasladando, y "to", el lugar al que se está mudando, sunuevo directorio padre. Se siguen tres restricciones, quedescriben el efecto pretendido en otras tantas gneasPrimera: eI objeto trasladado y la nueva ubicación soncarpetas del sistema de archivos. Segunda, y esenciade la operaci6n: la nueva correspondencia de contenidoes la antigua, eliminada toda asignaciÓn de una carpetaa "d" y añadida la correspondencia de ’to" a "d". Latercera linea dice que nada cambia.

Operación "MoveP’

,%

PASO 3: ESPECIFICACIONDE REQUISITOS .....El proyectista formula entonces un requisito esencial:todos ]es archivos y carpetas han de ser "alcanzables"(tener una ruta de acceso) desde cierta raíz. En el mo-delo AIIoy queda registrado como un "aserto" (llamado"more OK’), que dice que la ejecución de la operación"mover" no hace inalcanzable los archivos o carpetasdesde una ra{z.

PASO 4: BUSQUEDA Y CORRECCIONDE FALLOS

chic, mc~ c~

[ Problema: la carpeta no se; puede llevar a si misma

han de seralcanzables

/

Nueva restricción que impidetraslados erróneos

Para ejecutar "check more OK", AIIoy generatodos los estados posibles del sistema (hastacierto tamaño) y verifica el aserto en cada uno deellos; simula así todos los traslados que podrianpresentarse durante el funcionamiento del programa.AIIoy descubre un contraejemplo del aserto: quea un directorio se le puede trasladar a sl mismo,acción que lo desconectar[a de la raíz y lo hadainalcanzabte. Para remediado, el proyectista poddaañadir una nueva restricción que prohfbiera que sepueda trasladar una carpeta a si misma o a alguna ~/de sus descend entes.

~-’

O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

4ARQUITECTURA

eran inexactas, se retocó el sistema.Cuando los reajustes demostraron serinsuficientes, se añadieron epiciclosa los epiciclos. Las afinaciones efec-tuadas a lo largo de siglos no lle-garon nunca a resolver el problema,porque la concepción de partida erairremediablemente errónea.

De igual manera, los programasmal concebidos tienden a hacerse ca-da vez más cmnplicados y menosfiables, por mucho tiempo y dineroque se invierta en tratar de mejorar-los. Es bien sabido que los problemasgraves de los sistemas de programasrara vez se deben a errores de pro-gramación; al buscar el origen de lasdificultades serias, se ve casi siem-pre que se retrotraen a errores deconcepto cometidos antes inclusode que comenzase la programación.En cambio, el pequeño trabajo demodelización y análisis durante la de-terminación inicial de requisitos, es-pecificaciones y diseños cuesta sólouna minúscula porción del preciode comprobar todo el código, paraproporcionar una gran parte de losbeneficios de un análisis exhaustivo.Si al principio le prestamos suficienteatención al diseño, nos ahorraremosmuchos dolores de cabeza cuandovayamos avanzando.

Los instrumentos de diseño para laconfección de programas han tardadoen llegar porque la programación noobedece a leyes físicas. Dado que los

programas son, en esencia, objetosmatemáticos que se construyen condígitos binarios, no son objetos conti-nuos, sino discretos (,compuestos porpartículas). En ingeniería mecánicase puede someter un componente agrandes esfuerzos y dar por seguroque, si sobrevive, no fallará bajo so-licitaciones algo menores. Cuando unobjeto está sometido a los principios(casi siempre continuos) del mundomaterial, un cambio pequeño en unamagnitud produce, por lo general,cambios pequeños en las demás. Des-dichadamente, esto no vale para losprogramas: no cabe extrapolar entrecasos ensayados. Que un determina-do fragmento de programa funcioneno garantiza nada sobre el funciona-miento de otra porción similar; sonobjetos discretos y separados.

En los primeros tiempos de la in-formática se tenía la esperanza deque se llegaría a demostrar que loscódigos de los programas eran correc-tos, lo mismo que los matemáticosdemuestran la veracidad de sus tenremas. Pero al no poder automatizarlos muchos pasos necesarios, buenaparte del trabajo tenía que ser reali-zado por un experto humano. Estosmétodos formales, muy exigentes,sólo resultaban viables en el caso deprogramas bastante modestos, perode importancia crítica, como los al-goritmos de control de los cambiosde agujas de los ferrocarriles.

3. ALLOY CONTRIBUYO a lograr un sistema de aviónica a prueba de fisgones.

En tiempos más recientes se haadoptado un enfoque muy diferente,que, con el concurso de la potenciade los procesadores modernos, sepropone ensayar todos los posiblessupuestos. Este método, denomina-do de "verificación de modelos", seutiliza para comprobar los diseñosde los circuitos integrados. La ideaconsiste en simular todas las posiblessecuencias de estados (la situacióndel sistema en momentos concretos)que se presenten en la práctica, yccrciorarse de que ninguna de ellasdesemboca en un fallo. Aunque en elcaso del diseño de un mierochip elnúmero de estados que se ha de eva-luar suele ser enorme, del orden de10100 o mayor, el problema es todavíapeor en el caso de los programas.Pero sagaces técnicas de codificación(gracias a las cuales resulta posiblerepresentar de forma muy compac-ta grandes conjuntos de estados delsistema) hacen posible verificar cadaestado mediante el examen simultá-neo de estos grandes conjuntos.

Lamentablemente, la verificaciónde modelos no puede por sí sola ma-nejar estados con estructuras comple-jas, como las presentes en la mayoríade los diseños informáticos. Hemosdesarrollado un método que comparteel mismo espíritu, aunque se vale deun mecanismo diferente. Al igual quela verificación de modelos, examinala casi totalidad de las situacionesposibles (si bien requiere introducirciertas cotas para que el problemasea finito, pues los programas tienenlas limitaciones de tamaño que lesimpone el soporte material). A dife-rencia de la verificación de modelos,nuestra técnica no va examinandoexplícitamente un supuesto tras otro,a razón de uno por vez. Busca si-tuaciones malas --es decir, que provoquen fallos- asignando los bitsde cada estado de forma automática,a razón de uno por vez, sin ordenpredeterminado.

Hasta cierto punto, cabe compa-rar este proceso con un brazo ro-bótico que fuese encajando una poruna las piezas de un rompecabezas,tanteando al azar, hasta que por finapareciera la figura completa. Si talimagen corresponde a una mala situa-ción, Alloy habría hecho su trabajo.Así pues, Alloy trata el análisis dediseños como si tuviera que com-poner un rompecabezas. Algunos

O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

5ARQUITECTURA

otros programas de verificación pormodelos recientes operan también deeste modo.

La solución, en un acertijoPara comprender de qué modo pro-cede Alloy en la resolución de esosrompecabezas del diseño de programas puede venir a cuento un viejoacertijo: Un campesino va a la feriay compra un zorl-o, un ganso y unsaco de grano. Para volver a casatiene que cruzar un río en un bote.Sin embargo, el chinchorro solamente tiene capacidad para transportar alhombre y a uno de sus bienes en cadatravesía. Y aquí está el problema: sise les deja solos, el zorro se comeráel ganso, y el ganso, el grano delsaco. /,Cómo ha de hacer el granje-ro para trasladar intactos todos susbienes hasta la otra orilla’?

Este tipo de problemas entraña laideación de situaciones que satisfa-cen un conjunto de restricciones. Pararesolver el problema mentalmenteimaginamos una serie de pasos. Elcampesino traslada primero el ganso;en el viaje siguiente, lleva al zorro,pero se trae al ganso en el viaje devuelta, lo deja en la primera orillay vuelve a cruzar con el saco degrano: por último, retorna para traerel ganso. Tras comprobar que en cadapaso se respetan las restricciones, noscercioramos de que todos los elemen-tos permanecen a salvo.

Un programa que funcione debida-mente ha de respetar un conjunto dereglas parecidas, aunque mucho máscomplicadas. Un instrumento de veri-ficación de diseños, para que resulteútil, ha de ser capaz de encontrarejemplos de fallos o "contraejem-plos", es decir, soluciones del acertijoque cumplan con todos los requisitos"debidos" (y puedan, por consiguien-te, darse cuando el programa fimcio-ne) y alguna restricción "indebida"adicional (y producir así un resultadoinaceptable). La aparición de alguno de tales contraejemplos revelala existencia de errores de diseño.Nos alegra encontrar una solución del"acertijo del campesino"; en cambio,una solución del rompecabezas deldiseño de programas es mala noticia: significa que existe una situaciónimprevista e indeseable y que el di-seño es defectuoso. Tal vez, en lapráctica, el contraejemplo no origineproblemas, pero quizá haga ver una

Depuración de máquinaspara el tratamiento del cáncerLOS modernos equipos utilizados en medicina dependan de programas para casitodas las faeetas de su funcionamiento. En uha máquina de las que se utilizanpara el tratamiento de cáneeres ni siquiera el botbn de paro urgénté’ es unauténtico interruptor eléctrico, sino un programa: la pulsación del bot6n provocala ejecución de unas 15.000 IJneas de código que se encargan de apagar elsistema a menos, claro está, que ese programa contenga errores de pr0grama-c=ón o de diseño. Aaui es ooncfe interviene AIIoy, que analiza los programas paradetectar tallos en su diseño.

Hemos trabajado con los creadores de un s~stema r)ara el tratamiento delcáncer para exNorar con Alloy el diseño de algunas de sus caracteristicas. Enun caso tomamos e= diseño de un nuevo sistema de planificación que dieterminala sala de tratamiento a la que se ha de enviar el haz de radiación. Pusimos aAgoy a buscar situaciones en las que las interacciones entre el operadorde lasala armc~pa= y los terapeutas de las salas de tratamiento provocaran resultados"nesparados. AIIoy sacó a la luz varios eupuestos que no se habtan prev~sto

En otro caso aelicarsos AIIoy al diseño de un complicado protocolo de colo-cación del paciente balo el haz de prorones, que resulto tener una consecuenciasutil a inesperada: el ángulo del cabezal g ratoño iba variando con el frañscursodel tlemoo. Con un pequeño modelo. A[[oy h=zo ver que, eligiendo las sbstraccto~nes correctas, este problema podJa reducirse a otro bastante" m~ sencilla, queequivalia al de diseñar un accesorio que recordase tas posiciones del~Sieato,dalconductor de un automóvil. El sis~ersa de terapia iiene mu¢hes sa~guár~às~ elmovimiento del cabezal no era un problema peligroso. Pero Si’~~~’ I~ÑSrar~ ütilFzado desde el principio las abstracoicoee eorrectas el diseño haN’Ja~side muchomás simple y los programas para gestionarlo, considerablemente rn~a,f~~lés.

Enel tratamiento del c~ncer, lama- es de eritica in

incongruencia en la caracterizaciónde los resultados inaceptables tal ycomo la formuló el proyectista. Lomismo en un caso que en otro. serequiere modificar algo: o bien eldiseño, o bien las expectativas delproyectista.

La gran dificultad que plantea labúsqueda de contraejemplos estribaen el número de posibles supuestos de un proyecto informático, queincluso en uno de moderada com-plejidad, suele ser enorme, aunque

solamente una diminuta proporcióncorresponde a los contraejemplos.Imaginemos que estamos tratando deplanificar quién se ha de sentar juntoa quién en un banquete de bodas. Sitodos los asistentes se llevan bien, lasolución es trivial. Pero introduzca-mos unos cuantos ex cónyuges quese detestan y han de ocupar lugaresalejados: el problema se complicará.Pensemos ahora en lo que podña ha-ber ocurrido en el banquete de bodasde Romeo y Julieta. Supongamos que

O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

6ARQUITECTURA

hubiese habido veinte invitados. Sehabrían podido sentar de 20! formas(20 x 19 x 18 x...x 3 x 2), un par lar-go de trillones de formas. Aunqueel ordenador pudiera comprobar milmillones de esas urdenaciones porsegundo, tardaría unos 77 años enexaminarlas todas.

En los años ochenta se recono-ció que los problemas de este tipoconstituían una clase especial deproblemas que, de darse el peor delos casos, sólo podrían resolversemediante enumeración exhaustiva.Pero en el decenio pasado, merceda nuevas estrategias y algnritmos debúsqueda, en sinergia con potenciasde cómputo cada vez mayores, sedesarrollaron unos instrumentos de-nominados "solucionadores de satis-

factibilidad" SAT, capaces de habér-selas con relativa facilidad con estosproblemas. En la actualidad son muchos los existentes, bastantes de libredisposición, que a menudo permitenresolver problemas con millones derestricciones.

la importancia de la abstracciónAlloy, como su nombre sugiere (sig-nifica en inglés aleación), mezcla doselementos que posibilitan diseñosinformáticos más robustos. Uno deellos es un nuevo lenguaje que facilita la elucidación de la estructuray comportamiento del diseño infor-mático. El otro es una analizadorautomático (que integra un solucio-nador SAT) destinado a revisar unamultitud de posibles situaciones.

Utiles para verificar diseños informáticosSe ha desarrollado una nueva generación de instrumentos de verificación deproyectos informátieos (entre ellos AIIoy) que ayudan a descubrir incongruenciasestructurales o conceptuales que puedan desembocar en fallos del sistema. Engeneral, estos instrumentos de evaluación de diseños, sean comerciales o delibre disposición, se basan en lenguajes especializados de alto nivel (notacionesque resumen bloques de código) desarrollados previamente con el fin de facilitarla especificación, modelización y simulación de diferentes tipos de esquemas deprogramación.Dichos útiles incorporan motores de análisis automático, que exploran el grannúmero de posibles ejecuciones de los sistemas en busca de sutiles fallos quepuedan descarriarlos (se los denomina "eontraejemplos"). Estos útiles para eldiseño de programas disponen de medios que facilitan a los diseñadores lavisualización de contraejemplos o la relación entre bloques de código.

LENGUAJE HERRAMIENTA FUENTE SITIO WEB

B B-Toolkit B-Core www.b-core.com

Atelier-B Staria www.atelierb.societe.corn

Pro-B Universidadde Southanlpton

CSP FDR Formal SystemEurope

FSP LTSA Colegio Imperialde Londres

Lotos CADP Institutode InvestigaciónINRIA

OCL USE Universidadde Braman

PROMELA Spin LaboratoriosBell

Statecharts Statemate I-Logix

VDM VDMTools CSK Corp.

Z Jaza Universidadde Waikato

Zing Zing MicrosoftResearch

www.ecs.soton.ac.u kJ-mal/systems/prob.htmlwww.fsel,com

www.doc.ic.ac.uk/-jn m/book/Itsa/

LTSA.html

www.inrialpes.fr/vasy/cadp/

www.db.informatik.uni-bremen.de/projects/USE/spinroot.com/

www.ilogix.com

www.csk.com/support_e/vd m/www.vdmbook.com/tools.phpwww.cs.waikato.ac.nzJ-mar ku/jaza/

research.mierosoft.com/zing/

Para aplicar Alloy, el primerpaso consiste en crear un mode-lo del diseño: no un esbozo máso menos burdo, ni el diagrama deflujo característico en ingeniería desistemas, sino un modelo detalla-do que enuncie con precisión las"piezas móviles" y los comporta-mientos concretos, tanto deseadoscomo indeseables, del sistema y desus componentes. Un ingeniero desistemas se encarga primero de con-signar por escrito las definicionesde los diversos tipos de objetos deldiseño. Seguidamente, agrupa talesobjetos en conjuntos matemáticos,es decir, en colecciones de entes deestructura y comportamiento seme-jantes (por ejemplo, el conjunto detodos los Capuletos) y vinculadospor relaciones matemáticas (como larelación que asocia a los invitadosque se sientan juntos).

A continuación, están los hechosque constriñen a los conjuntos y alas relaciones anteriores. En un dise-ño informático, se contarán entre loshechos el mecanismo del sistema deprogramas y las hipótesis que atañena otros componentes (enunciados so-bre la forma en que se espera queactúen los usuarios humanos). Algu-nos de tales hechos son hipótesis sen-cillas; verbigracia, nadie es a la vezCapuleto y Montesco o cada invitadotiene exactamente dos vecinos. Otros,en cambio, son reflejo del propio di-seño: en el caso de nuestro maestrode ceremonias, la regla de que cadamesa, exceptuada la de los novios,ha de estar asignada a sólo una delas dos familias.

Están, por último, los asertos, queson limitaciones que se espera que sededuzcan de los hechos. En nuestroejemplo, que a excepción de Romeoy Julieta, ningún Capuleto debe estarsentado al lado de un Montesco. Losasertos declaran que el sistema nuncapuede alcanzar ciertos estados inde-seables y que nunca pueden ocurrirdeterminadas malas secuencias desucesos.

El componente analizador de Alloycuenta con un solucionador SAT parala búsqueda de contraejemplos, esdecir, posibles situaciones del sis-tema de programas que su diseñoconsiente, pero no superan una ve-rificación de cordura (que se plasmaen la redacción de asertos que tienenque ser verdaderos si el sistema está

O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

7ARQUITECTURA

correctamente diseñado). Dicho deotro modo, el instrumento trata deconstruir situaciones que respeten loshechos e infrinjan alguno de los aser-tos declarados. En nuestro caso, segeneraría un reparto de puestos en elque un Capuleto (aparte de Julieta)se sienta al lado de un Montesco(distinto de Romeo) en la mesa prin-cipal. Para restañar la asignación deasientos, podemos añadir un nuevohecho: que la mesa principal sóloestá ocupada por Romeo y Julieta.Ahora Alloy no podría hallar un con-traejemplo.

Las declaraciones de los conjuntosy relaciones, juntamente con los he-chos y los asertos, constituyen unaabstracción que capta la esencia deldiseño del programa. Al formularsetodo ello por escrito, se explicitan laslimitaciones del diseño y se obligaa los ingenieros a pensar cuidadosa-mente qué abstracciones funcionaránmejor. En la raíz de muchos siste-mas innecesariamente complicadoso escasamente fiables encontramosabstraeciones deficientes.

Los sistemas que se basan en pro-gramas construidas sobre abstrac-ciones sencillas y robustas deberíanser, asimismo, más fáciles de usar.Reparemos en lo mucho que se hansimplificado los viajes gracias a laventa electrónica de billetes, o en lafacilidad de las compras merced alos sistemas universales de codifica-ción de productos. Cada una de es-tas innovaciones ha emanado de unatransformación de las abstraccionesbásicas incrustadas en los programascorrespondientes.

Por la senda de la fiabilidadInstrumentns similares a Alloy seestán empleando ya en trabajos deinvestigación y en instalaciones in-dustriales punteras. Se han utilizadotécnicas de este tipo en la explo-ración de nuevas arquitecturas parasistemas de conmutación de centralestelefónicas, en el diseño de proce-sadores para aviónica inmunes a lospiratas informáticas y en el controlde acceso a redes de telecomunica-ciones. Nosotros lo hemos aplicadapara comprobar elementos de progra-mación robustos y muy utilizados,como los protocolos que encuentranimpresoras en las redes o instrumen-tos que sincronizan archivos residen-tes en equipos distintos.

El analizador Alloy ha descubier-to, además, graves deficiencias endiseños de programas publicados,entre ellos un protocolo de gestiónde claves encargado de aplicar re-glas especiales de acceso basadas enla pertenencia a un grupo. Resultóque concedía el acceso también aantiguos miembros, a pesar de quese les debería haber negado. Es deseñalar que muchos programadoresque han utilizado Alloy han vistocon sorpresa el número de fallas queeste instrumento revela incluso en susaplicaciones más sencillas.

Es probable que una adopciónmás amplia de instrumentos pareci-dos a Alloy en la industria sea sólocuestión de tiempo. Los perfeceio-namientos de los solucionadorcsSAT subyacentes lograrán que lasherramientas de análisis sean másveloces y más versátiles para tra-tar con sistemas muy grandes. Enel ínterin, una generación de pro-yectistas informáticas, formadas enestos métodos, irán incorporándolosa su trabajo. La modelización estáadquiriendo popularidad, sobre todo,entre los responsables de los siste-mas, que necesitan desesperadamentever alguna descripción del diseño delos programas que vaya más allá delcódigo propiamente dicho.

4. ALLOY VERIFICO UN PROGRAMAde búsqueda de impresoras en redesinalámbricas.

Ha de llegar un momento en quelos programas informáticas sean tanesenciales en las infraestructuras dela vida ordinaria, que la sociedadya no pueda consentir que presen-ten deficiencias. Quizá se establez-can entonces por ley inspecciones ylicencias que impongan técnicas dealta calidad en la confección de losprogramas. Tal vez llegue el día enque, gracias al diseño de sus pro-gramas, los sistemas de programassean verdaderamente robustos, ofrez-can un comportamiento predeeible yresulte sencilIo utilizarlas.

El autorDaniel Jackson dirige el Grupo de Diseño de Programas del Laboratorio de Infor-mática e Inteligencia Artificial del Instituto de Teenelogia de Massacbusetts. Estudi6en la Universidad de Oxford y se doctoró en informática en el Mff. Antes de serprofesor en el MIT ejerció en la Universidad Carnegie Mellom

Bibliografía complementariaEXPLORmG THE DESlGN OF AN INTENTtONAI NAM;NS SCHEME WITa AN AOTOMATIC GONSTRAINT

ANALYZER. Sarfraz Khurshid y Daniel Jockson en Proceedings of the 15th IEEE In-ternational Conference on Automatad Software En#ineerin#, Grenob/e, France. IEEE,septiembre de 2000.

AUTOMATmG FIRST-ORDEa R£tATIONAI LOGIC. Daniel Jaekson en Proceadings of the 8th ACMSIGSOFT International Symposium on Feundations of Software Engineerin#: Twenty.FirstCentury Applications. ACM Press, 2000.

A MICROMODUIARITY MECHANISM. Daniel Jackson, Ilya Shlyakhtm y Manu Sridharan enPraceedin#s of the Joint 8th Eurapean Software En#inaerin# Confarence (ESEC) and9th ACM SIGSOFT Sympasium on the Foondotions of Software Engineerin#. ACMPress, 2001.

ALLOY: A LlaltTWEIGHT OBJECT MOD[ILING NOTATIOr~. Daniel Jaekson en ACM Transactionson Software En#inaaring ah Methodalogy, col. 11, n.° 2, págs. 256.290; abril de2002.

SOFTWARE ABSTRACTIONS: LOGIC, LANGUA6E ANO ANALYSIS. Daniel Jaekson. MIT Press,2006.

O.J.D.:

E.G.M.:

Fecha:

Sección:

Páginas:

22370

126000

01/08/2006

REPORTAJE

76-83

8ARQUITECTURA