Suscríbete a DeepL Pro para poder
Entra en www.DeepL.com/pro para más información.
Sobre el uso de métodos formales en el desarrollo de
software
Dines Bjørner
Depto. de Comp.Sci., Techn. Univ. de Dinamarca
DK-2800 Lyngby, Dinamarca
Papel Invitado*
Resumen
Proponemos un marco total para las etapas de desarrollo de
software de especificación (definición), diseño y codificación.
Este marco se basa en tres piedras angulares: a) el concepto
de gráficos de desarrollo de software que especifican todas
las etapas y pasos del desarrollo; b) el uso de métodos
formales, en nuestro caso el VDM, el Método de Viena para
el Desarrollo de Software, en todas las etapas y pasos del
desarrollo; y c) los roles claramente separados de los
informáticos teóricos, programadores, ingenieros de software
y gerentes de desarrollo en todos los aspectos del desarrollo
de software. Así pues, no sólo se formaliza la programación
(es decir, los programas se consideran objetos formales), sino
también el desarrollo, su ingeniería y su gestión (es decir,
toda la programación en sí misma se considera también un
objeto formal sobre el que razonar).
Preludio personal
Se me ha pedido que relaten 14 años de experiencia en "el uso
de formalismos en la ingeniería de software". He elegido
abordar esto proponiendo, como se anuncia en el resumen, un
marco total para el desarrollo de software. Identificamos
todos los factores igualmente importantes que entran en el
desarrollo y mapeamos cada uno de estos aspectos en nuestro
modelo de desarrollo de software. Wc no utiliza formalismos
por el hecho de ser sólo fornmal. Utilizamos formalismos (1)
porque parecen ayudar a estructurar más finamente el
desarrollo, (2) porque arquean los medios primarios que
conocemos para ayudar a garantizar
*El uso de formalismos en la ingeniería de software
El permiso para copiar sin cargo todo o parte de este material se
concede siempre que las copias no se realicen o distribuyan para
obtener un beneficio comercial directo, aparezca el aviso de derechos
de autor de la ACM y el título de la publicación y su fecha, y se
notifique que la copia se realiza con permiso de la Asociación de
17
editar este docu
Maquinaria de Computación. Para copiar de otra manera, o para volver
a publicar, se requiere una cuota y/o un permiso específico.
0 1987 ACM 02705257/87/0300/0017$00.75
la corrección de los programas informáticos, 3) porque
los desarrollos que han utilizado formalismos han sido
mucho más productivos, en un orden de magnitud de 3 a
5 veces, que los desarrollos que no utilizan formalismos,
y 4) porque es divertido, incluso intelectualmente
satisfactorio, utilizar el formalismo. Una parte intrínseca
del formalismo (VDM) que hemos desarrollado y
utilizado es la abstracción. La abstracción en la definición
(especificación) del software, pero también la abstracción
en su diseño. Es decir: (I) primero (especificación) nos
abstraemos de cualquier implementación y nos
concentramos sólo en las [propiedades de las] funciones
que deseamos exhibir al usuario; (2) luego (diseño
abstracto) nos abstraemos del software logra estas
funciones centrando nuestra atención en lo que los
componentes conceptuales del software computan; (3)
luego (diseño concreto) describimos abstractamente
cómo el software computa, antes de (4) finalmente
codificar el software. La abstracción, y en estos diversos
niveles, ayuda a (1) "dividir y conquistar" la complejidad
[aparentemente intrínseca] del software, ayuda a
construir (2) conceptualmente Inore t.ransparent
irnplementaciones del sistema. Tal vez unas pocas
personas puedan desarrollar sistemas tan bellos sin
utilizar formalismos (aunque lo dudo), pero estamos aquí
para desarrollar métodos para otros que no sean los
genios únicos- y, cuando todo está dicho y hecho, sólo el
desarrollo formal puede posiblemente dar alguna
confianza en la corrección del sistema de software.
El papel no es técnico. (1) El corto tiempo dado
(diciembre-enero 86) para escribir el trabajo, (2)
cuatro semanas de conferencias en este período
(India, China, Japón y los EE.UU.), (3) el hecho de
que otros tres trabajos también tuvieron que ser
escritos, (4) Navidad y Año Nuevo, y (5) curso de
primavera de preparación de conferencias - todo eso
puede ser una mala excusa. Pero de todas formas
rogaré a los lectores que lo entiendan. Por supuesto,
creo que en este artículo he tratado aspectos
cruciales del "uso de formalismos en la ingeniería
de software". He elegido identificar las muchas
facetas, aspectos y conceptos que entran en el
desarrollo de software y trato de señalar los que ya
pueden ser formalizados, presentando el conjunto de
tal manera que se invite a más...
malización. No estoy postulando ideas no probadas. Todo lo
que se describe a continuación ha sido probado y demostrado
como deseable - sólo que todavía carecemos de herramientas
formales para su apoyo.
S ummary
(Las partes i-iv abajo se encuentran en las secciones 1-6.)
Este documento consta de seis partes. Las primeras
cinco (i-v) partes constituyen unidades más o menos
independientes que, al estar ensartadas, preparan el
camino para la última parte: (vi) reflexiones solas sobre
lo que se necesita para conseguir que las ideas se
propaguen en general, ¡y qué obstáculos puede haber
para ello! En primer lugar i) definimos los conceptos de
"ciencia teórica de la informática", "ciencia de la
informática" (o: "metodología de programación"),
"ingeniería de software" y "gestión del desarrollo de
software", y discutimos brevemente los roles de las
siguientes categorías de personal de desarrollo de
software: "científicos residentes" "programadores"
"ingenieros de software" y "administradores". A
continuación, ii) definimos el concepto de "métodos
formales" y nos centramos en el estado actual del uso de
los métodos formales en la programación profesional.
También definimos el tipo de proyectos y productos de
software a los que se pueden aplicar los métodos
formales. Ahora (iii) sigue una parte central del
documento en la que introducimos el concepto de
gráficos de desarrollo de software: se trata de gráficos
acíclicos y dirigidos cuyos nodos en general denotan
actividades de especificación, diseño o codificación que
conducen a documentos y cuyos bordes en general
denotan actividades que motivan y justifican diseños
con especificaciones, diseño con código, etc. Los nodos
sin bordes de entrada o "tempranos" en el gráfico
denotan especificación; los nodos sin bordes de salida o
"tardíos" en el gráfico denotan codificación; los nodos
interiores denotan diseño. Este concepto de desarrollo
de programas informáticos se examina a continuación iv)
desde varios puntos de vista: en primer lugar, desde las
18
cuádruples facetas de la informática teórica, la
programación, la ingeniería de programas informáticos
y la gestión; y v) desde el punto de vista de sus
repercusiones, con un entorno de apoyo total, no sólo
orientado a la sintaxis y la pragmática, sino también al
desarrollo de programas informáticos orientados a la
semántica. La conclusión vi) examina la realidad, la
"filosofía" y la sociología de conseguir que la gente
utilice métodos formales.
Introducción
El resumen y la reseña han esbozado nuestro objetivo.
En esta introducción vamos a motivar y justificar
nuestro enfoque.
Aunque los términos "crisis del software" e
"ingeniería de software" parecen haber sido
ampliamente adaptados a partir de 1969 [Randell 691
vemos pocos cambios, en la industria (casas de software,
fabricantes de computadoras que programan
centros), en el camino de la mejora. La mayoría de los
desarrolladores de los compiladores de Ada@, por
ejemplo, fueron más allá de las estimaciones iniciales, no
utilizaron ninguna, o sólo "al azar", de las muchas
técnicas formales disponibles en la actualidad y, como
consecuencia, parece que dieron lugar a productos poco
fiables que son difíciles y costosos de mantener.
En los años transcurridos desde 1969 se han
propuesto un gran número de técnicas formales (por
algunos incluso llamados métodos), casi
exclusivamente en el ámbito académico, y muy
pocas de ellas se utilizan realmente en la industria.
Nos referimos aquí primero a tales técnicas como (1)
probar que las anotaciones de los programas en
forma de afirmaciones usando sonle forni de Hoare
Logic (Proof Systenl), (2) definir formalmente las
funciones de software usando semántica algebraica
o denotacional, y (3) transformar los programas
desde sus especificaciones, a través de su diseño, en
código. Dentro de cada una de estas tres áreas (1-2-
3) hay hoy en día una abundancia de teoría y
también propuestas para su explotación práctica.
Pero, llegando a la segunda parte de la primera frase
de este párrafo, muy poco de esto está siendo
utilizado realmente por la industria.
Las razones de esta falta de adopción de técnicas
formales por parte de los videntes de la industria no sólo
son sociológicas, sino también la falta de un método
firme y total que ofrezca un marco unificador para al
menos algunas de las técnicas. La razón sociológica de la
falta de aceptación parece tener sus raíces en varios
factores: los directores de desarrollo de programas
pertenecen a una generación a la que no se le enseñó
informática y programación, o se le enseñó de maneras
muy diferentes a las que suponen estas técnicas formales
más recientes, que también pueden ser diferentes de la
manera en que se enseñaron los programadores, que se
supone que son los directores. El resultado es
básicamente -que un mínimo común denominador
concerniente al desarrollo de software ennoblece
subconscientemente. En esto no hay lugar para técnicas
formales. La brecha entre las técnicas formales que
ofrece la investigación y las "técnicas" del desarrollo de
software industrial se está ampliando!
En contraste con esto vemos la existencia de más
y mayores departamentos de ciencias de la
computación que producen no sólo interesantes
resultados de ciencias de la computación, y muchos
candidatos entrenados forzosamente en estos, sino
también, afirmo, una insuficiencia de resultados en
la metodología de programación, especialmente en
lo que se refiere a los aspectos de "método" de la
puesta en marcha de "técnicas".
Es un signo revelador, a veces inquietante, de que la
mayoría de los llamados "métodos" que se están
propagando fueron creados básicamente en pequeñas
empresas de software, y por individuos con poca o
ninguna inclinación a considerar una base foránea para su
trabajo. Así, la mayoría de los
@Ada es una marca registrada del Gobierno de los Estados
Unidos (Ada
Conjunta, Oficina de Progranune)
estos métodos (con la refrescante y notable excepción de
JSP/JSD [Jackson 75,Jackson 83]) no llegaron al entorno
abierto de revisiones por pares que ofrece el mundo
académico, sino a uno industrial impulsado por motivos
comerciales. Las revolucionarias posibilidades de largo
alcance y de horizonte lejano de la investigación universitaria
formal, bien fundada y criticada abiertamente, han sido
sustituidas por las ofertas evolutivas y de corto alcance, aquí
y ahora, de propuestas ad hoc en tirnes, incluso celosamente
religiosas.
Por lo tanto, sobre el trasfondo de las afirmaciones
fanfaristas de arriba, tal vez sea presuntuoso afirmar
ahora que el objetivo de este documento es reducir la
brecha entre los resultados semánticos exóticamente
bellos de la academia y las siempre pedantes
preocupaciones sintácticas y pragmáticas de la industria:
en resumen, proponer un fratnework, un método para el
desarrollo "total", en el que se entiende por "total": todo
el espectro desde la especificación funcional hasta la
codificación, todo el espectro desde los gestores,
pasando por los ingenieros de software y los
programadores, hasta los científicos "residentes" del
proyecto, y toda la fuerza de todos los resultados
teóricos aplicables aplicados a todo el espectro.
19
1 Las ciencias de la computación y
los roles de los desarrolladores
En esta sección damos un vistazo a las profesiones y a los
profesionales de nuestro campo (de desarrollo de software).
El objetivo es proporcionar una comprensión más refinada del
entorno interno en el que se desarrolla el software. El entorno
externo, que tiene que ver con las relaciones con los clientes,
no se tratará aquí. Creemos que una descomposición más fina
de las ciencias y la ingeniería, y los roles de las personas que
se describen a continuación, es beneficiosa para el desarrollo.
Evidentemente, no podemos demostrarlo, pero podemos
referirnos a los desarrollos [Oest 86] que, encarnando el
espíritu de esta descomposición, han tenido éxito no sólo en
conducir a un software fiable desarrollado a tiempo y con
recursos, todo ello a un nivel mucho mejor que los desarrollos
compulsivos, sino que también fueron proyectos "divertidos":
intelectualmente satisfactorios, y proyectos en los que todo el
personal tenía confianza. Atribuimos parte de estos éxitos a la
comprensión de los aspectos tratados en esta sección.
Atribuimos parte de estos éxitos a haber utilizado un
"met.hod" formal (en este caso VDM), y a haber formado una
odisea de cuatro años de desarrollo en torno a un gráfico de
desarrollo de software claramente aceptado. Pero lo primero
es lo primero.
1.1 Las ciencias de la computación
Las ciencias de la computación y la ingeniería consisten aquí
en: ciencias de la computación, ciencia de la computación,
ingeniería de software y hardware.
Informática
La ciencia teórica de la computadora de maíz es el estudio de
los progresos:
-de lo que es computable (meta-matemática, teoría
de la computabilidad, de lo complejo que es
computar las cosas (análisis de algoritmos, teoría de
la complejidad), del fundamento Inathematlcal para
varias abstracciones de la computación (teoría de
los autómatas, teoría del lenguaje formal, teoría de
redes, teoría del dominio de puntos fijos, semántica
denotacional, semántica algebraica), y del
fundamento del razonamiento que se da en la
programación (sistemas de prueba, Hoare Logics, )
Ciencias de la computación o ciencias de la
programación y metodología
La ciencia convincente es el estudio de la
programación:
-de las metodologías, lenguajes, técnicas y
herramientas que intervienen en el desarrollo de
software: análisis y definición de requisitos;
especificación funcional y no funcional;
transformación de programas; de las técnicas
especiales de desarrollo necesarias para asegurar un
software fiable, robusto, tolerante a fallos y seguro;
y codificación.
Ingeniería de Software
La ingeniería de software es la
práctica de los programas y la
programación:
-que incluye las preocupaciones sintácticas y
pragmáticas tanto humanas como mecánicas
(construcción y uso de herramientas) de cómo producir,
validar, controlar y supervisar los documentos necesarios
en el proceso de desarrollo de software, no sólo desde el
punto de vista de apoyar estos proce.s.ses
mecánicamente, sino también de asegurar la interacción
(los procesos sociales) entre las personas:
clientes/usuarios y desarrolladores, y entre los
desarrolladores.
Por lo tanto, definimos el concepto de Ingeniería de
Software más estrechamente que lo que se hace
normalmente. La definición del IEEE, por ejemplo,
abarca nuestra Ciencia de la Computación.
1.2 El desarrollador Röles
Programador
Cuando una persona se ocupa de los aspectos semánticos
del proceso de programación, por ejemplo: qué
propiedades funcionales hay que captar en la
especificación abstracta y en cuáles hay que centrarse en
el diseño y la codificación concretos, qué formulación
hay que dar a los documentos de desarrollo, qué
significan, cómo verificar qué documentos describen y
cómo transformar las descripciones abstractas en otras
más concretas, entonces esa persona es un programador
y está programando. Un programador propone teorías
(con el informático teórico que las garantiza).
Ingeniero de Software
Cuando una persona se ocupa de los aspectos sintácticos
y pragmáticos del proceso de desarrollo de programas
informáticos, por ejemplo, de las limitaciones
tecnológicas actuales no funcionales, el seguimiento de
los requisitos externos de diseño [limitación], el registro
de los documentos de desarrollo, la creación y el
mantenimiento de las versiones de los documentos de
especificación, diseño y código, su configuración en los
productos y la validación de los requisitos no
funcionales, entonces esa persona es un ingeniero de
programas informáticos. El ingeniero de programas
informáticos es un constructor de herramientas (las
20
herramientas siempre reflejan una nueva instancia de
una metodología, pero están sujetas a las limitaciones de
la tecnología actual y a los conocimientos teóricos).
Programador vs. Ingeniero de Software
El ingeniero de software "aprovecha" las leyes de
la naturaleza, el programador las leyes de las
matemáticas, la informática y la computación. El
ingeniero de software interactúa con las
limitaciones siempre actuales de la tecnología de
hardware, el programador con las siempre fijas
leyes de la computación. La misma persona es a
veces un programador, a veces un ingeniero de
software, y un buen programador sabe exactamente
cuándo se hacen las transiciones entre las dos
actividades, y cuándo se requiere la asistencia de un
informático para ayudar a asegurar los fundamentos
de lo que se está describiendo.
2 Sobre el desarrollo de software y
sobre sistemas de software
Esta sección tiene dos partes. En las secciones (2.1-2-3)
se habla de los métodos forrnales, y en las secciones
(2.4-5-6) se habla de las propiedades y cualidades de los
productos de software y proyectos de desarrollo, objeto
y portador de los métodos formales.
El objetivo de la presente sección es, en primer lugar,
definir (sec. 2.1) los conceptos de "método" y de
"método formal" en relación con el desarrollo de
programas informáticos, motivar y justificar (sec. 2.2)
por qué es necesario utilizar métodos formales (técnicas
y herramientas) siempre que sea posible en todas las
facetas del desarrollo de programas informáticos, y (sec.
2.3) presentar brevemente un candidato a "método
formal" que haya superado la prueba de ser aplicado
ampliamente, en Europa, en entornos industriales. Tal
vez no en plena formalidad, pero sí en forma sistemática.
Por consiguiente, en la primera sección (2.1) se definirán
los modificadores adicionales: "sistemático" y
"riguroso", y en la sección (2.3) se esbozará brevemente
lo que, en la
forma del proyecto ESPRIT 315 RAISE del Mercado
Común Europeo de DDC/STC/NBB [Meiling 86], se
está haciendo para ofrecer un método que satisfaga más
de las necesidades de desarrollo de software industrial
tal como se esbozan en la segunda parte de esta sección.
En la sección (2.4) se enumeran las propiedades del
software (system.s) que los métodos formales deben
atender, y en la sección (2.5) las cualidades del proyecto
y del producto de software resultante, respectivamente.
Por último, en la sección 2.6, detallamos algunos, pero
no todos, los componentes informales que parecen
necesarios, además de utilizar los métodos formales,
para ayudar a asegurar las propiedades y cualidades.
2.1 Sobre los métodos sistemáticos, rigurosos
y formales
Por un %método' entenderemos un conjunto de
procedimientos (directrices) para seleccionar y secuenciar el
uso de 'técnicas' y 'herramientas' para construir un
determinado artefacto. Por 'método formal' entenderemos un
rnet.hod (i) en el que todas las técnicas y herramientas que lo
componen son formales, es decir, se le da un significado
matemático preciso, y (ii) en el que el uso de los métodos y
las técnicas puede justificarse formalmente. Nos explayamos
sobre el punto (ii). Para ser formal debe ser posible razonar
matemáticamente (lógicamente) sobre los programas
producidos (ya sean abstractos, en forma de definiciones o
especificaciones, o menos abstractos, digamos en forma de
diseños, o sean ejecutables, en forma de código), de ahí el
requisito de técnicas formales que se piensa que se aplican a
un individuo, o a pares adyacentes de pasos de desarrollo.
Pero eso no es suficiente. Para ser formal también debe ser
posible razonar sobre el desarrollo en sí mismo -como
veremos en la sección 4- de ahí el requisito de métodos
formales, donde la parte de Inet.hod: la selección y
secuenciación ordenada, habla de la programación. Así pues,
no sólo consideramos los programas como objetos formales,
sino que también la programación, el proceso, se ve como un
objeto formal, igualmente sujeto al razonamiento. Las
herramientas son cosas tales como los sistemas de anotación
(lenguajes de especificación y diseño) utilizados, y las ayudas
mecánicas necesarias para apoyar clericalmente
(sintácticamente), semántica y pragmáticamente el uso del
método y sus técnicas. Por técnicas entendemos, entre otras
cosas, por qué principios (1) especificamos definiciones
abstractas, (2) las transformamos en diseños, y los diseños en
código, (3) probamos que tales transformaciones son
correctas, y (4) descargamos otras pruebas obligatorias en
general.
Las herramientas de apoyo a las técnicas y el método
Inust son, por lo tanto, formalmente explicables. Es
decir, la arquitectura general del sistema de apoyo de
herramientas completo debe transponer las propiedades
formalmente expresables del método, y del mismo
modo para las sub-herramientas vs. las técnicas.
Decimos que un desarrollo es formal si todos los pasos de
developine.nt.: definición, de.firma y codificación se llevan a
cabo formalmente, y si se cumplen todas las obligaciones de
prueba derivadas de este desarrollo.
Decimos que un desarrollo es riguroso si carece de
formalidad por la ausencia de pruebas reales y formales. Es
decir: somos rigurosos cuando seguimos los pasos del método:
especificar, diseñar y codificar, y cuando relacionamos
forzosamente las etapas de desarrollo en la forma, por
ejemplo, de relaciones de inyección, fimcciones de
al)estracción, predicados de adecuación o imple.mentabilidad,
y teoremas de corrección, pero omitiendo las pruebas
detalladas.
Decimos que un desarrollo es sistemático si carece de rigor
por la omisión de relaciones formales entre las etapas del
desarrollo.
21
(Nuestra distinción entre "riguroso" y "sistemático" no es
consistente con el uso de las palabras sanne en [Jones
80,Jones 861.)
Por lo tanto, para nosotros, el espectro formal-
rigurosamente sistemático, es uno dentro del cual deseamos
que nuestro desarrollo tenga lugar apoyado, siempre que sea
posible, por la disponibilidad de herramientas formales.
2.2 Justificación de los métodos formales
Antes del costoso desarrollo de software, como por ejemplo
t.hat de compiladores, sistemas operativos, sistemas de
gestión de bases de datos, redes de área local y amplia y
sistemas distribuidos, incluyendo componentes de ISO/OSI,
antes de que el desarrollo de dicho software tenga lugar
asumimos (como un dogma) la creación de una especificación.
Al igual que las concepciones y dibujos de los arquitectos de
un edificio, una especificación sirve (1) como contrato "legal"
entre el cliente y el desarrollador, (2) como base para el
desarrollo, y (3) como base para la redacción de los manuales
del cliente/usuario. De una especificación esperamos que sea
(4) consistente y cornple.te, (5) corta y concisa, (6) accesible
y referenciable, y (7) expresada de tal manera que las
propiedades forrnales del software resultante puedan ser
probadas wrt. la especificación-un ejemplo es: la corrección.
Como consecuencia de los requisitos especiales (1,2,4,5,7)
llegamos a la conclusión de que la especificación debe
formalizarse, aunque de tal manera que se cumplan los
requisitos 3) y G).
Bjørner 85a] se extiende sobre los puntos anteriores a
la luz de la elaboración por parte de DDC/CRAI/CNR y
la Universidad de Génova de una definición matemática
formal y completa de Ada.
2.3 Un método "formal"
El VDM (Método de Desarrollo de Viena) surgió por primera
vez el Laboratorio de Viena del IBM alrededor de 1973-74 (a
través del trabajo en la construcción de un compilador para
PL/1 [Bekié 74]).
Posteriormente, el DM V se desarrolló aún más, como
lo atestiguan, por ejemplo, los libros de texto y las
monografías: Bjørner & Jones 78,Jones 80,Bjørner &
Jones 82,Jone Actualmente se está preparando un
conjunto de 5-6 volúmenes sobre' todos los aspectos de
la VDM para su publicación en 1988 [Bjørner 88].
V DM se ha utilizado en muchos proyectos de
desarrollo, Inostly sólo sistemáticamente. El más
notable de estos desarrollos debe ser sin duda el
desarrollo del Centro Dansk Datamatik del DDC Ada
Compiler SY+ tern [Bjørner & Oest 80,0est 86). Un
número creciente de empresas de maíz europeas están
utilizando uno u otro aspecto del MDV. Como
consecuencia de ello (y, puede decirse, del éxito del
DDC Ada Compiler), la CEE (Comunidad Económica
Europea) ha establecido un Foruln Europa VDM cuyos
miembros industriales y académicos se reúnen 3-4 veces
al año para discutir temas de (1) experiencia en el uso
de VDM y sus aplicaciones, (2) requerimientos de
entrenamiento y educación, (3) herramientas, (4)
fundamentos formales y (5) facetas de VDM
potencialmente sujetas a la estandarización de la
industria. El Foro Europeo de VDM celebró su primer
simposio abierto del 23 al 26 de marzo de 1987 [Bjørncr
et al. 87].
VDM es básicamente una semántica denotacional (es
decir, un método teórico, constructivo y basado en
modelos). Las facetas del VDM es (1) su lenguaje de
especificación y diseño de amplio espectro: Meta-IV
[Bjørner & Jones 78], (2) un gran número de
operaciones de descomposición y técnicas de reificación
de datos [Jones 80,Jones 86]. El Meta-IV, en toda su
extensión, no es un lenguaje formal, pero a grandes
subconjuntos del Meta-IV se les puede dar, o se les ha
dado, una semántica formal, y a las partes se les ha dado
un sistema de prueba formal (véase los documentos en
[Bjørner y otros 87]). El Meta-IV es aplicable a la
especificación, diseño y codificación de sistemas
deterministas. Se han hecho algunas aplicaciones a
sistemas no determinísticos, y se han utilizado
extensiones operacionales del Meta-IV, para incluir
características de CSP [Folkjær 80] para desarrollar
sistemas concurrentes y distribuidos.
¡Pero el VDM, en su etapa actual, no es lo
suficientemente bueno! Uno quiere una formalidad
completa, o al menos esforzarse por una mayor
formalidad en el uso de VDM. El proyecto
DDC/STC/NBB RAISE, patrocinado en parte por el
programa ESPRIT de la CEE, intenta remediar las
deficiencias de mayor alcance del VDM. El Lenguaje de
Especificación y Diseño R.AISE presenta (1)
instalaciones de estructuración de especificación
algebraica y diseño (abstracto. tipos de datos y
operaciones de tipo de datos: enriquecer, derivar,
colübinar, resumir. y aplicar), (2) concurrencia en el
Cortn de aserciones de trazas y CSP, (3) una semántica
completa y formal, y (4) un sistema de pruebas. El
método RAISE ofrece un conjunto completo de
principios de perfeccionamiento del desarrollo,
centrados en torno a un modelo de datos plenamente
desarrollado para todas las etapas y facetas del
desarrollo, ya sean de interés para los socios de
programas, los ingenieros de software o la gestión de
proyectos... Referencia [Meiling 861 ofrece una
introducción general a RAISE mientras que [Bjørner
85b] ofrece una visión de röle y alcance (orientada a los
requirernent.s) de RAISE.
2.4 Propiedades del software
Deseamos desarrollar programas informáticos para a)
deterministas así como b) no determinantes, c) secuenciales
así como d) sistemas concurrentes, y para sistemas que
funcionan en e) tiempo real y están f) distribuidos. Deseamos
que el software para estos sistemas sea (1) apto para su
propósito, (2) con especificaciones correctas de la red, (3)
22
fiable, (4) tolerante a fallos, (5) seguro, (6) mantenible, y (7)
robusto. El software fiable rechaza claramente los datos no
especificados como entrada. El software tolerante a fallos
repara o "corrige" los datos erróneos (hasta la entrada más
"cercana" a la especificación) y también detecta y corrige o
desvía los cambios espurios e intermitentes en los datos
almacenados (o en el programa). Los sistemas de software
seguros impiden que los usuarios no autorizados descubran: i)
lo que hacen los sistemas, y ii) cómo lo hacen. Además, un
sistema seguro evita que los usuarios no autorizados (iii)
impidan que el sistema haga lo que está haciendo, y (iv) les
deja sin saber si lo saben (iii-iii-iv)! Asumiendo que alguna
inasistencia de un cambio razonable en la funcionalidad, u
otra, de un sistema, se dice que su software es rnaint.able si
los recursos requeridos para la inserción de estos cambios
pueden ser precisamente est.ilnat.ed y en .sorne (aquí no
especificado) manera son proporcionales a los cambios. El
software es robusto si cualquier cambio en él no altera
ninguna de sus propiedades (1-7)!
La utilidad de los formalismos para abordar todos los
aspectos (1-7) está aún por demostrar. Ciertamente, los
aspectos (2-3-4) vistos por separado se pueden obtener [Ravn
86], y los aspectos (67) vistos por separado resultan del uso
de definiciones conceptualmente limpias y transformaciones
homolórficas de éstas. Pero todavía hay un largo camino por
recorrer antes de que podamos garantizar plenamente todos
los aspectos de forma satisfactoria!
2.5 Garantía de calidad
Distinguimos entre las cualidades de un proyecto y de
su producto resultante.
Para que un proyecto sea de calidad es necesario que sea (1)
ingenioso y predecible, es decir, que, basándose por ejemplo en un
gráfico de desarrollo de software completo y consistente, se puedan
estimar correctamente todos los recursos necesarios. personas,
máquinas y finanzas mes a mes; 2) controlable: debe haber un
principio objetivo mediante el cual se pueda supervisar y, si es
necesario, modificar el consumo de recursos; 3) económico: debe
haber alguna tnea.segura de amnistía entre la presupuestación, la
financiación, la contabilidad y los resultados (esperados); 4) seguro:
el proyecto debe conducir a los resultados esperados; y 5) divertido:
el proyecto.
El personal debe confiar en que la dirección tiene
plena autoridad y que se enriquece intelectual,
educativa y educativamente con el proyecto.
Para que un producto tenga calidad debe satisfacer los
puntos (1-7) de la sección 2.4 anterior.
La garantía es el doble acto de asegurar tanto la
calidad del proyecto como la del producto.
Podremos apoyar formalmente el logro de la calidad
del producto. Se cree que los puntos informales
planteados en la sección 2.5 y el forrnal de las secciones
3-4 ayudan indirectamente a lograr la calidad del
proyecto.
2.6 Componentes del proyecto
Se ha considerado necesario un número de
componentes del proyecto, además de los pasos de
desarrollo de la especificación, diseño y
codificación adecuados y reales, para ayudar a
garantizar una alta calidad del proyecto y del
producto. Dado que no están pensados en el
contexto del desarrollo de software, los
enumeramos y explicamos brevemente aquí.
La primera actividad es la de definir el proyecto
en sí mismo. Esta actividad se centra, en nuestro
caso, en (I) el desarrollo por etapas del gráfico de
desarrollo de software del proyecto, ver secciones
3-4. A continuación se inician dos actividades,
actividades que abarcan toda la duración del
proyecto: establecer y mantener, (2) a
r
.rernuinología, y (3) una biblioteca.
2.6.1 Terminología
Hoy en día la mayoría de los programas
informáticos [proyectos de desarrollo] introducen
una serie de nuevos conceptos, y se basan también
en conceptos previamente establecidos no del todo
establecidos. Por lo tanto, parece importante crear
(electrónicamente), maint.ain y durante todo el
proyecto adherirse a una Ternünología: un conjunto
de definiciones precisas de los conceptos utilizados
e introducidos. La importancia de establecer,
rnaintaintain (incluido el ajuste) y adherirse a una
Terminología fue enfatizada, para mí, por Peter
Naur, a quien por la presente reconozco con gratitud.
Los malentendidos relativos a los nombres de los
conceptos, la vaguedad de su significado, etc., son
muy perjudiciales para la consecución de un
proyecto. La disciplina de establecer, mantener y
adherirse a una Terminología es una actividad
intelectualmente muy gratificante (educadora y
liberadora).
En un sentido, la terminología es un objeto formal en el que
se basa en la precisión y la economía, es decir, en la concisión.
2.6.2 Biblioteca
En cada etapa de un proyecto se estudian los
documentos científicos, técnicos y de otro tipo
(informes y publicaciones): se descartan o se
utilizan. Se construye una biblioteca de todo ello,
para su posterior consulta y para la documentación
completa del proyecto. Por Biblioteca entendemos
una cosa de tres partes:
1) un esquema que estructura taxonómicamente la bib-
liografía; 2) una bibliografía anotada, es decir, una lista de
entradas, cada una de las cuales no sólo contiene una
23
referencia bibliográfica propia, sino también, a medida que
el proyecto avanza, un conjunto acumulativo, de
anotaciones relativas a la disposición de la referencia (su
valor para el proyecto, etc.); y 3) la colección de papel
propiamente dicha.
De manera similar (a la Terminología) una Biblioteca se
convierte en un objeto formal.
2.6.3 Estudio-Experiencia-Acción
Cada componente del desarrollo propiamente dicho, para
nosotros consiste en tres actividades pha.sed: estudio-
experimentación. Su consumo de recursos y duración de
tiempo son típicamente 1-2-8. En la primera, la fase de
estudio, todos los miembros del componente del proyecto
estudian lo que creen que es la literatura relevante para el
componente del proyecto en cuestión. Las presentaciones
de los coloquios, por parte de todos los miembros,
identifican aquellas ideas y técnicas que podrían ser de
interés para el proyecto. Éstas se investigan más a fondo en
la siguiente fase, en la que se llevan a cabo experimentos
(ya sea en la especificación, el diseño o la codificación) que
implican estas ideas y técnicas. Es decir: aplicadas a
aspectos pequeños, pero difíciles, del problema. Por último,
de las fases de estudio-experimento debe surgir suficiente
confianza en cuanto a las opciones técnicas a adoptar, y se
lleva a cabo una aplicación a gran escala al problema "real",
en esta, la fase de acción.
El plan de estudio-experimento-acción está
explícitamente dirigido a fomentar el uso de técnicas
formales.
3 Un gráfico concreto de desarrollo de
software
El gráfico de desarrollo de software [Bjørner
86a], [Bjørner 86b] es, sintácticamente hablando, un
gráfico direct.ed finito y sin ciclos. Los nodos denotan
actividades de desarrollo de software que son parte de la
especificación, diseño y codificación. Estas actividades
conducen a documentos de especificación, diseño o
codificación. Los bordes también denotan actividades que
(primero) motivan y (después) justifican el paso de
desarrollo. designadas por el nódulo-borde-nodo triple
identificado por el borde. Las actividades son realizadas por
una combinación de prograrnIners, científicos, ingenieros
de software y manager.s. Los documentos suelen ser
formales.
Desarrollo de software. Los gráficos pueden ser
abstractos, pero sin sentido, como en la Fig. 3.1, o
relacionados con el tema del software, como en la Fig. 3.2.
Para que se familiaricen con los conceptos de los gráficos
de desarrollo de software, revisamos brevemente el último
gráfico basado en el uso de V DM.

Un gráfico del software DoveDopment para
los sistemas ComplOor + Runtime
Especificación Definición del lenguaje de programación: Resumen
Sintaxis. Semántica estática y dinámica
Estructura de los datos en tiempo de ejecución y mecánica
Diseño Diseño de la representación de la operación
Codificación del lenguaje de aplicación
Coda
302 : Gráfico de desarrollo de UndvusaD Softwmn
Aseguramos un BNF granunar para el Ada sintáctico dado.
Frente a ello (etc.) desarrollamos una Sintaxis Abstracta, un
conjunto de ecuaciones de dominio, en el Meta-IV, que se
24
abstiene de consideraciones tales como palabras clave,
secuencia lineal de objetos (como declaración.s cuyo
ordenamiento lineal es accidental y que no tienen
significado). A partir de la Sintaxis Abstracta desarrollamos,
de la forma más abstracta posible, tanto una Semántica
Estática, como una Sernántica Dinámica, ambas incluyendo
el tratamiento de la concurrencia, etc. Juntos estos cuatro
nodos (y sus bordes intermedios) representan la parte de
especificación del desarrollo. Ahora sigue, en general, un
número de etapas de diseño. Primero centramos nuestra
atención de desarrollo en lo que hay que hacer en lo (cada
vez más) concreto, luego en cómo realizar las funciones así
diseñadas. Es decir: primero desarrollamos una versión más
concreta y secuenciada de la Semántica Estática (llamada
Análisis Ccmántico), y versiones más operativas, o mecánicas,
de aspectos secuenciales de la Semántica Dinámica (llamada
Semántica Mecánica o Macro-Sustitución). Esta última
exhibe fimdament.als de la estructura de tiempo de
ejecución de los programas [Ada]. De la Semántica Dinámica
Mecánica derivamos primero la definición de un Vil% tual
Target Machine, una máquina "óptimamente" adecuada
para ejecutar programas en el lenguaje fuente (viz.: Ada); o
tal Target Machine (viz.: DEC VAX) ya está dada. m-om la
definición de Target Machine y la Semántica Dinámica
Mecánica u Operacional semant.ic Semántica i.s derivó un
llamado Connpiling Algoritlun. Este último define la
secuencia exacta de la instrucción de la máquina de destino
que debe generarse para cada construcción (esquemática)
del lenguaje de origen. A partir de los datos concretos del
front end (Sernant.ic Analysis) y del back-end (Cornpiling
Algoritlun) desarrollamos la posible estructura multipaso del
compilador, de todos los lenguajes intermedios y del
administrador multipaso. De la Semántica Dinámica también
se deriva una descripción concreta de lo que hay que
manejar en la asignación de tareas; y a partir de esto y de la
definición de la Máquina Objetivo se desarrolla un diseño
para el Run-Tirne (Objetivo) Systern. Esto concluye el diseño.
A partir de los respectivos nodos de diseño se desarrolla
finalmente la codificación real del compilador y el sistema de
tiempo de ejecución.
Cada uno de los nodos puede, usando VDM en general, ser
refinado en una subgrafia de ocho nodos, ...ver... Fig. 3.3.
A cada uno de los nodos y bordes corresponde un
conjunto bien definido de técnicas de förmal.
Explicamos estas, en general, para cada una de las cuatro
áreas de T.H.C.: programación, ingeniería, administración y
ciencia de la computación básica; pero, primero, echamos un
vistazo general a los gráficos.

Dominio
Bien formado
3. Función auxiliar 6. Definiciones de la función auxiliar 7. Definiciones
semánticas
Tipos de función
8. Semántica
Definiciones de la función
El caso de la semántica de Denotationai
Fig.3.3
4 Gráficos de desarrollo de software
en general
4.1 Desarrollo de gráficos
Meta-Gráficos
A cada clase ("equivalencia") de software le
corresponde un gráfico de desarrollo de meta software.
Así, un gráfico de desarrollo de meta software describe
cómo desarrollar toda una clase de software "similar".
El gráfico anterior es un metagráfico para el desarrollo
de compiladores de la clase ALGOL/Pascal pero con
asignación de tareas (procesos, concurrencia). Por lo
tanto, es válido para el desarrollo de compiladores para
lenguajes como Concurrent Pascal, Pascal Plus, CHILL,
occam@, Modual-2, y Ada. Existen otras clases: un
gráfico, básicamente es necesario para el desarrollo de,
por ejemplo, sistemas operativos UNIX, o LAN (redes de
área local), o Sistemas de Gestión de Bases de Datos
Relacionales, etc. Así pues, los metagráficos son
genéricos y su estructura y significado es el resultado de
la investigación y a ellos deberían llegar los científicos de
la universidad o la industria.
Gráficos del proyecto
La industria del software cuando se enfrenta al inicio. de
desarrollo: de software selecciona un apropiado.e
metagráfico a partir del cual desarrolla un gráfico de
proyecto. El gráfico del proyecto. es una versión
posiblemente enriquecida o derivada del Ineta-graph
junto con sus cuatro clases de anotaliones. Estas cuatro
clases son las que dan atributos de nodos y bordes a-
priori que definen las tareas que tienen por delante los
programadores, ingenieros de software, gerentes y
25
científicos "residentes", así como observaciones a-
posteriores que describen las principales propiedades
del desarrollo del software, también occarn es una
marca registrada de inmos Ltd. (REINO UNIDO)
para cada una de las cuatro clases, a.s que transpiraron
al llevar a cabo el proyecto en sí.
Así pues, destacamos la importancia de llevar a cabo
minuciosamente la cuidadosa planificación que se manifiesta
en el acto de asignar atributos.
Gráficos de productos
La ingeniería de software abarca desde el seguimiento
de los requisitos, las pruebas hasta la ingeniería de
productos. A cada configuración de versiones (véase el
apartado 4.2) le corresponde un producto y a él un
gráfico, una "versión" del gráfico del proyecto. En lugar
de ciertas, y además de otras anotaciones de proyecto
(es decir, de proceso) contiene adicionalmente producto
(es decir, resultado) attril)utes.
4.2 Atributos de la programación
El principal atributo en este caso es el del método
utilizado en el desarrollo (ejemplos: VDM, HDM, HOS,
JSD, RAISE, Este atributo pertenece a un gráfico
completo. En base a nodos y bordes tenemos,
refiriéndonos aquí sólo a los atributos secundarios
relacionados con V DM). Nodos: técnicas de
especificación como configuración, o reanudación, o
salida, o semántica directa para modelar los GOTO y las
excepciones; modelo de almacenamiento de
localización/valor plano, localización/valor
estructurado plano, o localización/valor estructurado;
modelo imperativo; Inodel aplicativo; definiciones de
funciones principalmente putativas; definiciones de
funciones principalmente plicit (pre/post condición);
etc., etc. Bordes: técnicas de transformación del diseño
como pliegue/despliegue/abstracto [regla instancial
transformat.iones grudados; transformación
completamente automática (es decir, compilación); o
transformaciones manuales -esta última anotada más
adelante con sununario del teorema- que prueban las
estrategias y tácticas; etc., etc. En caso de desarrollo no
basado en VDM, otros atributos pueden ser pertinentes.
4.3 Atributos de la ingeniería de software
Aquí hay cuatro tributos primarios: (1) nanne y
características del syst.em de soporte mecanizado
(herramientas); (2) los principios de rastreo de
requerimientos; (3) la estrategia de generación de t.est.;
y (4) el principio de registro, versión y configuración.
Atributos secundarios para cada una de las áreas
respectivas siguen trivialmente.
4.4 Atributos de la gestión
Hay dos a-priori, atributos primarios de gestión input.s:
por nodo y por borde hay una estimación, en forma de
histograma, de los requerimientos de Inanpower
(máquina, etc.) por mes (tiempo virtual) (para hacer la
actividad del nodo, respectivamente borde), y para todo
el proyecto (es decir, su gráfico) hay un histograma de
la mano de obra total disponible (máquina, etc.). Un
"resultado" primario es un mapeo de los recursos
requeridos en tiempo real de acuerdo con uno de varios
principios de asignación y según lo restringe el
histograma de disponibilidad (Lynenskjold 87].
Hay otros atributos de gestión primarios:
principio para la supervisión y control del proyecto,
incluidos los planes de prioridad y reasignación,
principio para la generación de planes renovables
(informes), etc. La vigilancia incluye la frecuencia
del muestreo de los recursos realmente utilizados;
el control estipula los principios para las medidas
correctivas o de ajuste (por sobreutilización o
infrautilización de los recursos); y el plan móvil es
una presentación tabular de estos asuntos destinada
a ser utilizada en (1) las reuniones de gestión del
proyecto, y (2) la contabilidad.
4.5 Atributos de la informática teórica
Los nodos denotan documentos, y los documentos (de
especificación, diseño o código) denotan teorías. Los
bordes denotan mapeos, a veces morfismos, entre teorías.
La naturaleza exacta de las teorías y mapeos puede ser
planificada y los documentos resultantes comprobados
con estos atributos.
Normalmente las especificaciones definen las
funciones totales y, por lo tanto, normalmente requiere
un razonamiento en una lógica de 2 valores.
Normalmente los documentos de diseño definen
funciones parciales y por lo tanto requieren un
razonamiento en una lógica de 3 valores. Los bordes
entre, por ejemplo, los "nodos" de la lógica de 2 y 3
valores también denotan morfismos institucionales.
Algunos, normalmente nodos de especificación, denotan
documentos que definen dominios en una teoría de Scott
de retracciones, mientras que otros, normalmente nodos
de diseño, denotan documentos para los que basta una
teoría de dominio simple (setteórica) å lå Blikle [Blikle
83]. Se podrían enumerar muchos otros atributos de la
informática.
4.6 Observaciones
No hemos explicado en detalle los tributos de
proyecto versus producto, ni los atributos (de nodos
y aristas) que se asignan durante el proyecto
propiamente dicho. Tampoco hemos distinguido
26
sistemáticamente entre los atributos de entrada del
desarrollador ab init.io y los atributos parcial o
totalmente derivados (computados). Hay muchos
otros att.ributes, esquemas de atributos y propert.ies
que tampoco hemos tratado.
El objetivo de asignar homenajes y luego, en el
desarrollo adecuado, adherirse a sus prescripciones,
es fortificar tantos aspectos del desarrollo como sea
razonable. Esta "disciplina" da libertad durante la
ac-
desarrollo del t.ual.
5 Arquitectura de un software total
Sistema de apoyo al desarrollo
Hemos esbozado, en la sección 4, un método basado en
gráficos. Hemos explicado, de forma puntual, algunos de sus
puntos detallados sobre el uso de VDM. Otras técnicas
foráneas, diferentes a las de VDM, podrían instanciar el
método basado en gráficos del software Clevclopnnent.
Ejemplos de esto último son: JSD ("Jackson System Design"),
HDM ("Hierarchical Developnnent Method"), HOS ("Higher
Order Software"), RAISE ("Rigorous Approach to Industrial
Software Engineering"), etc.
En esta sección esbozaremos la arquitectura de un sistema
de apoyo total al desarrollo de software. Por tal sistema nos
referimos a un sistema computarizado (hardware/software)
que proporciona herramientas mecanizadas para todos los
aspectos del desarrollo (especificación, diseño y codificación),
tanto de los gráficos de desarrollo de software (Ineta, proyecto
y producto) como del software cuyo desarrollo prescriben ;
para todos los grupos de desarrolladores (programadores,
ingenieros de software, administradores y científicos); y que
refleja de manera transparente todo el gráfico de desarrollo de
software basado en el método Ineta, así como el conjunto
particular de técnicas de especificación, diseño y codificación
(como para exanil)le VDM) al que está instanciado.
Por lo tanto, la arquitectura debe directamente, en el nivel
más externo, el desarrollo de software gráfico, elnbody el
no.iones de (1) gráficos de desarrollo de soft.ware -
incluyendo meta-, proyecto- y gráficos de productos; (2) su
desarrollo e inauguración-incluyendo la asignación de
atributos y el cálculo; (3) nodos y bordes-incluyendo
sus .significados sintácticos, semánticos y prácticos, tanto
para programadores, ingenieros de software, gerentes y
científicos residentes; (4) la ejecución de gráficos de
desarrollo de software - permitiendo la ejecución simultánea
de nodos y aristas independientes, y dentro de cada uno de
ellos la ejecución simultánea (de un nodo o arista) por varios
desarrolladores de las cuatro categorías de desarrolladores.
Los puntos (1-2-3) se relacionan, en un sen.se, con el
desarrollo de gráficos de desarrollo de software. El punto (4)
a su ejecución;ión. Por ejecución de un gráfico de desarrollo
de software entendemos una interacción entre los
desarrolladores y el sistema de acuerdo con el significado de
los gráficos, nodos y bordes, y como parametrizado por el
conjunto de técnicas embebidas (es decir, instanciadas) (por
ejemplo, VDM).
 El siguiente "árbol" solariza la estructura taxonómica
básica y las características salientes del sistema
propuesto.
Desarrollo de Gráficos Soporte del Subsistema
Soporte del Repositorio de Gráficos
(Biblioteca de Meta Gráficos) c Soporte del
Refinamiento de Gráficos
(Especificación y diseño)
Gráfico Inst, soporte de antiationes
(De Meta-, vía Proyecto- a Gráfico de Producto)
Atributo. Apoyo a la asignación
Atributo Apoyo a la Cornputación
Soporte del subsistema de ejecución de gráficos
Ejecutor de nodos
Herramientas sintácticas
Estructura y Sintaxis Dirigida por Editores
Impresoras bonitas
Soporte de diario * Referencia cruzada etc. Apoyo
Herramientas sensuales
Herramientas de análisis de datos, lógica y control
de flujo
Herramientas de comprobación estática (tipo)
Herramientas de interpretación de Dynanlic
Proveedores y verificadores de Theorelii
Herramientas pragmáticas
Herramientas de rastreo de decisiones de diseño y de
requerimientos
Herramientas de control de versión y configuración
Generadores, probadores y validadores de casos de
prueba
Edge. Ejecutor
- Herramientas de derivación automática de nodos
Herramientas de reglas de transformación, unificación y
reescritura
Herramientas de derivación de nodos "manuales".
Editor de la estructura, sustituto, herramientas de la
regla de reescritura * Herramientas de prueba de
obligación y de descarga (Proving and
Verific.ations)
Sub-sistema de gestión
Asignación de recursos, -Supervisión y apoyo al
control
Gráficos de apoyo a la evaluación, la vigilancia y el
control
Apoyo a la evaluación, vigilancia y control de los
nódulos
Edge. Apoyo a la evaluación, la supervisión y el
control
R.esident' Científico Sub-Systexn
Algunas observaciones pueden ser necesarias.
(i) El "árbol" anterior refleja las ofertas funcionales
del .syst.ems, no su estructura implementada. El hecho
de que pueda haber un "gestor de ventanas", un "shell
de conunancl" y una "base de datos orientada a objetos"
posiblemente di.stribuída, un "procesador de
transacciones t.ransaction" que permita copias de
seguridad y recuperación, etc., es realmente una
preocupación muy menor para el usuario. No reflejan ni
el método ni sus técnicas, sino más bien las limitaciones
de la aplicación (tecnología).
(ii) El "árbol" de la función refleja, por lo tanto, que el
conjunto de herramientas del sistema está
profundamente arraigado en la serenidad del método, en
lugar de representar, por error, el habitual método ad hoc
de evaluación de herramientas principalmente
sintácticas y pragmáticas que no están vinculadas a
ningún método.
(iii) Deseamos que el usuario del sistema (el desarrollador)
tenga, en todos los tirnes, un conocimiento exacto y
"pago" por donde en el proceso de desarrollo (es decir,
donde en el gráfico) se encuentra, y que tenga acceso a
herramientas para todas las facetas sernánticas,
sintácticas y pragmáticas del rnethod y sus técnicas. En
sununary deseamos que el usuario se sienta como en el
asiento del conductor de un coche de conducción
* avanzada cornfort.able: rueda, pedales de acelerador,
frenos, cambio de marchas (palanca o automático) y una
variedad de interruptores, uno para cada una de las
funciones. La conducción puede ser una interacción
agradable entre el coche y el conductor, así como el uso
del sistema de apoyo al desarrollo.
(iv) En toto la estructura conceptual más que la de aplicación
del sistema de apoyo airn.s a inducir el uso de un método
formal con todas sus técnicas e instrumentos formales
constituyentes.
6 La realidad, la filosofía y la sociología
del uso de formalismos en el
desarrollo de software
Hemos propuesto un marco total para el desarrollo de
software. Hemos construido este marco alrededor de znany
años de uso de VDM; y el aspecto más básico del marco se ha
utilizado durante al menos 6 años. Así que no estamos
postulando nuevas ideas no probadas, no comprobadas. Al
contrario. Pero básicamente hemos usado estas ideas de forma
sistemática, en lugar de formalmente, básicamente porque no
hemos tenido el apoyo informático necesario para ayudarnos.
Hemos reconocido repetidamente, a lo largo de los años, la
necesidad de apoyo informático, pero no nos hemos
precipitado (sabiamente, creemos ahora) a instrumentar ideas
que entonces no estaban conceptualmente completamente
desarrolladas. Donde antes, sin usar herramientas, de
cualquiera de los tipos descritos anteriormente (ni sintácticas,
27
ni senáticas, ni antes) podíamos registrar
el desarrollo. cuesta sólo el 25% de los de otros desarrollos,
esperamos. ¡hacerlo mucho mejor con herramientas
formalizadas! Pero no esperamos que éstas resulten en
ahorros en los costos reales de desarrollo, ni en una reducción
significativa del tiempo de desarrollo. En lugar de ello,
esperamos poder entregar eventualmente un software
confiable, un software que satisfaga todas las calidades de
producto descritas en las secciones 2.4-2.5. También nos
hemos convencido de que el desarrollo de software es
demasiado costoso. ¡Creo que se hace demasiado barato!
Los clientes no se levantarán para exigir todas estas
cualidades, aunque unos pocos (como el Departamento
de Defensa de EE.UU.) pedirán un hijo. En cambio, las
nuevas empresas de informática podrán garantizar cada
vez más a Inore esas cualidades, y es "a su manera" que
veremos llegar el uso de formalismos: mediante
productos más adecuadamente iluminados, mediante
software más fiable, mediante una mayor productividad
(relativa), pero también porque la generación más joven
de desarrolladores de software no querrá: hacerlo de otra
manera.
Hay pocas esperanzas de que las empresas de software
y los fabricantes de computadoras existentes ("viejos")
se den cuenta de los métodos foráneos de desarrollo de
software. Las viejas formas de hacer software están
demasiado arraigadas en la administración y el personal.
He experimentado en la industria establecida enormes
lagunas en el conocimiento l)asico sobre incluso el
concepto más básico. s--o sea, lo que los actuales
graduados están aprendiendo. La mayoría de los gerentes
existentes ni siquiera son capaces de desarrollar software
y por lo tanto no tienen autoridad para hacer gestión. y
están completamente a merced de la jerga y las excusas
de sus "programadores-ingenieros de software".
habiendo crecido con nuevas teorías" - Erwin
Schrödinger, Autobiografía.
Lo que hemos propuesto en este documento es una
"teoría". Hay muchas "teorías". Esta, como Inost,
otros desarrolladores de software..: "%net.hods", no
es una teoría en el sentido de ser demostrable, es decir,
demostrable "la teoría". Es, como las "teorías" de la
informática de Inost, más bien una conjetura. No se
puede probar su superioridad, ni las "teorías" de otros.
Sólo la práctica lo dirá, y controlará tal "cambio de
mando":
"No hay teorías, y no hay pruebas. Puede haber
conjeturas, y a veces hay tristes refutaciones" -
esencia de un aspecto de la Teoría de la Ciencia
de ICarl Poppers.
Para terminar, hemos intentado para cada faceta y
aspecto del software y su desarrollo, identificar formas y
medios de formalizar estas características en la mayoría de
las secciones y subsecciones.
28
Creo que el progreso en el uso de los métodos formales
sólo se producirá si se cumplen tres condiciones: l)
producción de suficientes candidatos de departamentos
de informática orientados a la programación de la
Inetología; muchos han aprendido las teorías sobre los
progrmas que no sirven para la programación; 2) empleo
de esas personas en grupos de masa crítica; y 3)
instrumentos apropiados. La producción de candidatos
adecuadamente educados y capacitados es
responsabilidad de las universidades, y los Ino.st aún no
comprenden y distinguen la ciencia de la computación de
la informática, y no hacen hincapié en la ciencia de la
computación! El empleo es el reino de las casas de
software, y muy, muy pocos de sus gerentes entienden la
necesidad de contratar personas formalmente
capacitadas, y mucho menos de asignar, a los pocos que
consiguen, para formar grupos con suficiente personal.
La producción de herramientas está, de nuevo, en el
dominio de la industria. Las herramientas producidas en
la universidad son generalmente semánticamente
avanzadas, pero los prototipos en los sentidos t.hc. (1) de
ser aplicables sólo a datos muy pequeños (es decir, no
aplicables de manera realista al tipo de grandes ejemplos
que suelen surgir en la industria), y (2) de ser pobremente
(¡locutnados! Las herramientas producidas por la
industria son invariablemente siempre vacías
sernanamente, presentando sólo herramientas sintácticas
y pragrnat.ic, y luego en combinaciones ad hoc.
Nunca se demostrará que las viejas formas en que el
software está siendo diseñado hoy en día por IBM y
todos sus competidores están equivocadas.
Eventualmente morirán por falta de uso, ya que la nueva
generación ha crecido con los nuevos métodos:
"Las viejas teorías nunca se prueban equivocadas.
Sólo... se dictan por la falta de uso por parte de
las nuevas generaciones...
of PL/1,
Referencia TR25.139,
s IBM
Laboratory,
H. Bekié y otros..: Viena, 1974.
A
[Bjørner
F & Jones 78] D.
o Bjørner &
r C.B. Jones:
m The Vienna
a Developme
nt Method:
l
D tlLe Meta.-
e Language,
f Springer
i Verlag,
n Lecture
i Notes in
t Computer
i Science, vol.
o 61, 1978.
n
Towa.rds a. Formal Description of Ada, Springer Verlag, [Folkjær 80] VDM Symposium '87 - a Formal
Lecture Notes in Computer Science, Method at work, VDM Europe
(eds. D. Bjørner & O.N. oest), vol. Conference, Bruselas, Marzo 87,
98, 1980. Springer Verlag, Lecture Notes in
Computer Science, (eds. D. Bjørner,
D. Bjørner & C.B. Jones: Formal Specification a.nd C.B. Jones, M. Mac an Airchinnig,
Softwarc Dcvcl.opne-nt, Prentice- E. Neuhold), 1987.
Hall Intl., 1982. [Jackson 75]
[Bjørner 85a] D.Bjørner: El R,öl.e y el alcance D. Bjørner: Arquitecturas de
de la definición formal de Ada, software y diseño de sistemas de
Dansk Datamatik Center, programación, 6 volúmenes, 1988.
Techn.Rept. AdaFD/ DDC/ DB/ [Jackson 83]
A.J.B1ik1e & A.Tar1ecki:
6 1985-12-09, 1985. Naive Denotational Semantics,
[Bjørner 85b] D.Bjørner y otros..: El levantamiento in: Information Processing 83,
[Jones 801
Proyecto: D.Bjørner. ed. R.E.A. Mason, IFIP
Ediciones Gráficos y meta- Congress Proc. , North-Holland
y Requerimientos, Dansk programas del Publ., 1983.
Datamat.ik Center, Techn. Rcpt., proyecto:
RAISE/DDC/EM/I v6, -10. Towards a Theory P.F01kjær & D.Bjørner. A Formal
Diciembre 85, 1.985. of Software Model of a Generalised CSPlike
[Bjørner 86a] Development, Language, Information Processing
Capri Conference 80 (ed. S.H.Lavington), North-
on Innovative Holland Publ., pp. 95-99, 1980.
Software
Factories y Ada, M.A. Jackson: Principios de Diseño
de Programas, Acadernic Press,
mayo de 1986,
1975.
para aparecer en
Springer Lecture M.A. Jackson: Desarrollo de
Notes in
sistemas, Prentice-Hall Intl.,
Computer Science,
eds. N. 1983.
[Bjørner 86b]
Habermann y U. C.B.- Jones: Software Development,
Montanari, 1987. a Rigorous Approach, Prentice-Hali
Intl., 1980.
D.Bjørner:
Gráficos de
Desarrollo de
Software: A
Unifying Theory
for Software
Development?,
[Bjørner y otros 87] New Delh, 6th
Conf. on
Foundations of
Software
Technology and
Theoretical
Computer Science,
Springer Lecture
[Bjørner 88] Notes in
Computer Science,
vol. 241, ed.
K.Nori, págs. 1 a 9,
[Blilde 83] 1986.

29
[Jones 86] C.B. Jones: Systematic
Development Using the VDM
Approa.ch, Prentice-Hall Intl.,
1986.
[Lynenskjold 87] s. Lynenskjold: Project
Graph based Resource Allocation
Schetne, Techn. Rept., Comp. Sci.
Dept., Techn. Univ. de Dinamarca,
Jan.87, 31 páginas.

[Meiling 86] E. Meiling & C.W. George: The

RAISE Language and Method,
Proc. ESPRIT Techno week, Sept.
1986, North-Holland Publ.,
también: Dansk Datamatik Center
Techn. Rept. RAISE/ DDC/ EM/
21 VI, 11. sept. 1986.
[Oest 86] O.N. Oest: VDM from Research to
Practice, IFIP Congress '86, North-
Holland, Proc. 'Infomnation
Processing 86', pp. 527-533, 1986.

[Randell 69] Ingeniería de Software, R.ept.

NATO Sci. Comm., (NATO Sci.
Affairs Div., Bruselas 1039,
Bélgica), enero de 1969 (eds. P.
Naur & B. Randell).
[Ravn 86] A.P.Ravn: Clasificación de Fallas
en Sistemas Distribuidos, en:
Information Processing 86, ed.
H.J.Kug1er, IFIP Congress
Proceedings, North-Holland Publ.,
pp. 735-738, 1986.
29