Suscríbete a DeepL Pro
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 sistema. Tal vez unas pocas personas
17
para poder editar este documento.
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
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
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 que motivan y justifican diseños con
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
18
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
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 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 inquietante, de que la mayoría de los
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
19
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
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.
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
20
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 teorías (con el informático teórico que
programas; de las técnicas las garantiza).
especiales de desarrollo necesarias
para asegurar un software fiable, Ingeniero de Software
robusto, tolerante a fallos y seguro; Cuando una persona se ocupa de los
y codificación. aspectos sintácticos y pragmáticos del
proceso de desarrollo de programas
Ingeniería de Software informáticos, por ejemplo, de las
limitaciones tecnológicas actuales no
La ingeniería de funcionales, el seguimiento de los
software es la requisitos externos de diseño
práctica de los [limitación], el registro de los
programas y la documentos de desarrollo, la creación y
programación: el mantenimiento de las versiones de
los documentos de especificación,
-que incluye las preocupaciones diseño y código, su configuración en
sintácticas y pragmáticas tanto los productos y la validación de los
humanas como mecánicas requisitos no funcionales, entonces esa
(construcción y uso de herramientas) de persona es un ingeniero de programas
cómo producir, validar, controlar y informáticos. El ingeniero de
supervisar los documentos necesarios programas informáticos es un
en el proceso de desarrollo de software, constructor de herramientas (las
no sólo desde el punto de vista de herramientas siempre reflejan una
apoyar estos proce.s.ses nueva instancia de una metodología,
mecánicamente, sino también de pero están sujetas a las limitaciones de
asegurar la interacción (los procesos la tecnología actual y a los
sociales) entre las personas: conocimientos teóricos).
clientes/usuarios y desarrolladores, y
entre los desarrolladores. Programador vs. Ingeniero de
Por lo tanto, definimos el concepto Software
de Ingeniería de Software más
estrechamente que lo que se hace El ingeniero de software
normalmente. La definición del IEEE, "aprovecha" las leyes de la
por ejemplo, abarca nuestra Ciencia de naturaleza, el programador las leyes
la Computación. de las matemáticas, la informática y
la computación. El ingeniero de
software interactúa con las
1.2 El desarrollador Röles
limitaciones siempre actuales de la
Programador tecnología de hardware, el
Cuando una persona se ocupa de los programador con las siempre fijas
aspectos semánticos del proceso de leyes de la computación. La misma
programación, por ejemplo: qué persona es a veces un programador,
propiedades funcionales hay que captar a veces un ingeniero de software, y
en la especificación abstracta y en un buen programador sabe
cuáles hay que centrarse en el diseño y exactamente cuándo se hacen las
la codificación concretos, qué
transiciones entre las dos
formulación hay que dar a los
documentos de desarrollo, qué actividades, y cuándo se requiere la
significan, cómo verificar qué asistencia de un informático para
documentos describen y cómo ayudar a asegurar los fundamentos
transformar las descripciones abstractas de lo que se está describiendo.
en otras más concretas, entonces esa
persona es un programador y está
programando. Un programador propone

21
 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.
22
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.
(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
23
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 a los cambios. El software es robusto si
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
24
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) 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
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 La primera actividad es la de
aspectos de forma satisfactoria! definir el proyecto en sí mismo.
Esta actividad se centra, en nuestro
2.5 Garantía de calidad caso, en (I) el desarrollo por etapas
del gráfico de desarrollo de software
Distinguimos entre las cualidades de un
del proyecto, ver secciones 3-4. A
proyecto y de su producto resultante.
continuación se inician dos
Para que un proyecto sea de calidad es necesario
actividades, actividades que abarcan
que sea (1) ingenioso y predecible, es decir, que,
basándose por ejemplo en un gráfico de desarrollo toda la duración del proyecto:
de software completo y consistente, se puedan establecer y mantener, (2) a
r
estimar correctamente todos los recursos .rernuinología, y (3) una biblioteca.
necesarios. personas, máquinas y finanzas mes a
mes; 2) controlable: debe haber un principio 2.6.1 Terminología
objetivo mediante el cual se pueda supervisar y, si Hoy en día la mayoría de los
es necesario, modificar el consumo de recursos; 3) programas informáticos [proyectos
económico: debe haber alguna tnea.segura de de desarrollo] introducen una serie
amnistía entre la presupuestación, la financiación,
la contabilidad y los resultados (esperados); 4)
de nuevos conceptos, y se basan
seguro: el proyecto debe conducir a los resultados también en conceptos previamente
esperados; y 5) divertido: el proyecto. establecidos no del todo
El personal debe confiar en que la establecidos. Por lo tanto, parece
dirección tiene plena autoridad y importante crear (electrónicamente),
que se enriquece intelectual, maint.ain y durante todo el proyecto
educativa y educativamente con el adherirse a una Ternünología: un
proyecto. conjunto de definiciones precisas de
Para que un producto tenga calidad los conceptos utilizados e
debe satisfacer los puntos (1-7) de la introducidos. La importancia de
sección 2.4 anterior. establecer, rnaintaintain (incluido el
La garantía es el doble acto de ajuste) y adherirse a una
asegurar tanto la calidad del proyecto Terminología fue enfatizada, para
como la del producto. mí, por Peter Naur, a quien por la
Podremos apoyar formalmente el presente reconozco con gratitud.
logro de la calidad del producto. Se Los malentendidos relativos a los
cree que los puntos informales nombres de los conceptos, la
planteados en la sección 2.5 y el forrnal vaguedad de su significado, etc., son
de las secciones 3-4 ayudan muy perjudiciales para la
indirectamente a lograr la calidad del consecución de un proyecto. La
proyecto. disciplina de establecer, mantener y
adherirse a una Terminología es una
2.6 Componentes del proyecto actividad intelectualmente muy
Se ha considerado necesario un gratificante (educadora y
número de componentes del liberadora).
proyecto, además de los pasos de En un sentido, la terminología es un
objeto formal en el que se basa en la
desarrollo de la especificación,
precisión y la economía, es decir, en la
diseño y codificación adecuados y concisión.
reales, para ayudar a garantizar una
alta calidad del proyecto y del 2.6.2 Biblioteca
producto. Dado que no están
pensados en el contexto del En cada etapa de un proyecto se
desarrollo de software, los estudian los documentos científicos,
enumeramos y explicamos técnicos y de otro tipo (informes y
brevemente aquí. publicaciones): se descartan o se

25
utilizan. Se construye una biblioteca 3 Un gráfico concreto de
de todo ello, para su posterior
consulta y para la documentación desarrollo de software
completa del proyecto. Por El gráfico de desarrollo de
Biblioteca entendemos una cosa de software [Bjørner 86a], [Bjørner 86b] es,
tres partes: sintácticamente hablando, un gráfico
1) un esquema que estructura direct.ed finito y sin ciclos. Los nodos
taxonómicamente la bib-liografía; 2) una denotan actividades de desarrollo de
bibliografía anotada, es decir, una lista de software que son parte de la
entradas, cada una de las cuales no sólo especificación, diseño y codificación. Estas
contiene una referencia bibliográfica actividades conducen a documentos de
propia, sino también, a medida que el especificación, diseño o codificación. Los
proyecto avanza, un conjunto bordes también denotan actividades que
acumulativo, de anotaciones relativas a la (primero) motivan y (después) justifican el
disposición de la referencia (su valor para paso de desarrollo. designadas por el
el proyecto, etc.); y 3) la colección de nódulo-borde-nodo triple identificado por
papel propiamente dicha. el borde. Las actividades son realizadas
De manera similar (a la Terminología) por una combinación de prograrnIners,
una Biblioteca se convierte en un objeto científicos, ingenieros de software y
formal. manager.s. Los documentos suelen ser
formales.
2.6.3 Estudio-Experiencia-Acción Desarrollo de software. Los gráficos
Cada componente del desarrollo pueden ser abstractos, pero sin sentido,
propiamente dicho, para nosotros como en la Fig. 3.1, o relacionados con el
consiste en tres actividades pha.sed: tema del software, como en la Fig. 3.2.
estudio-experimentación. Su consumo de Para que se familiaricen con los
recursos y duración de tiempo son conceptos de los gráficos de desarrollo de
típicamente 1-2-8. En la primera, la fase software, revisamos brevemente el último
de estudio, todos los miembros del gráfico basado en el uso de V DM.
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.

26
 Un gráfico del software
DoveDopment para los
sistemas ComplOor + Runtime

Especificaci Definición del lenguaje de programación:

ón
Resumen
Sintaxis. Semántica estática y dinámica

Estructura de Diseño los datos en tiempo de ejecución y

mecánica
Diseño de la representación de la operación

Coda
Codificación del lenguaje de aplicación

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
27
conjunto de ecuaciones de dominio, en el
Meta-IV, que se abstiene
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
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
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
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
de 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.
la 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
u Fig.3.3
4 Gráficos de desarrollo
de software en general
4.1 Desarrollo de gráficos
Meta-Gráficos
del 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
28
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
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
29
(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
30
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
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 los desarrolladores y el sistema de acuerdo
método basado en gráficos. Hemos con el significado de los gráficos, nodos y
explicado, de forma puntual, algunos de sus bordes, y como parametrizado por el
puntos detallados sobre el uso de VDM. conjunto de técnicas embebidas (es decir,
Otras técnicas foráneas, diferentes a las de instanciadas) (por ejemplo, VDM).
VDM, podrían instanciar el método basado El siguiente "árbol" solariza la
en gráficos del software Clevclopnnent. estructura taxonómica básica y las
Ejemplos de esto último son: JSD ("Jackson características salientes del sistema
System Design"), HDM ("Hierarchical propuesto.
Developnnent Method"), HOS ("Higher
Order Software"), RAISE ("Rigorous
Approach to Industrial Software Desarrollo de Gráficos Soporte
Engineering"), etc. del Subsistema Soporte del
En esta sección esbozaremos la Repositorio de Gráficos
arquitectura de un sistema de apoyo total al (Biblioteca de Meta Gráficos)
desarrollo de software. Por tal sistema nos c Soporte del Refinamiento de
referimos a un sistema computarizado Gráficos
(hardware/software) que proporciona (Especificación y diseño)
herramientas mecanizadas para todos los
aspectos del desarrollo (especificación, Gráfico Inst, soporte de antiationes
diseño y codificación), tanto de los gráficos (De Meta-, vía Proyecto- a Gráfico de
de desarrollo de software (Ineta, proyecto y Producto)
producto) como del software cuyo desarrollo Atributo. Apoyo a la asignación
prescriben ; para todos los grupos de
Atributo Apoyo a la Cornputación
desarrolladores (programadores, ingenieros
de software, administradores y científicos); y Soporte del subsistema de ejecución de
que refleja de manera transparente todo el gráficos
gráfico de desarrollo de software basado en
Ejecutor de nodos
el método Ineta, así como el conjunto
Herramientas sintácticas
particular de técnicas de especificación,
diseño y codificación (como para exanil)le Estructura y Sintaxis Dirigida por
VDM) al que está instanciado. Editores
Por lo tanto, la arquitectura debe Impresoras bonitas
directamente, en el nivel más externo, el Soporte de diario * Referencia
desarrollo de software gráfico, elnbody el cruzada etc. Apoyo
no.iones de (1) gráficos de desarrollo de Herramientas sensuales
soft.ware -incluyendo meta-, proyecto- y Herramientas de análisis de datos,
gráficos de productos; (2) su desarrollo e lógica y control de flujo
inauguración-incluyendo la asignación de Herramientas de comprobación
atributos y el cálculo; (3) nodos y bordes- estática (tipo)
incluyendo sus .significados sintácticos, Herramientas de interpretación de
semánticos y prácticos, tanto para Dynanlic * Proveedores y
programadores, ingenieros de software, verificadores de Theorelii
gerentes y científicos residentes; (4) la Herramientas pragmáticas
ejecución de gráficos de desarrollo de
Herramientas de rastreo de decisiones
software - permitiendo la ejecución
de diseño y de requerimientos
simultánea de nodos y aristas
Herramientas de control de
independientes, y dentro de cada uno de
versión y configuración
ellos la ejecución simultánea (de un nodo o
Generadores, probadores y
arista) por varios desarrolladores de las
cuatro categorías de desarrolladores. Los validadores de casos de prueba
puntos (1-2-3) se relacionan, en un sen.se, Edge. Ejecutor
con el desarrollo de gráficos de desarrollo
- Herramientas de derivación automática de
de software. El punto (4) a su ejecución;ión.
nodos
Por ejecución de un gráfico de desarrollo de
software entendemos una interacción entre
31
 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
32
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, 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 departamentos de informática
reducción significativa del tiempo de orientados a la programación de la
desarrollo. En lugar de ello, esperamos Inetología; muchos han aprendido las
poder entregar eventualmente un software teorías sobre los progrmas que no
confiable, un software que satisfaga todas sirven para la programación; 2) empleo
las calidades de producto descritas en las de esas personas en grupos de masa
secciones 2.4-2.5. También nos hemos crítica; y 3) instrumentos apropiados.
convencido de que el desarrollo de software La producción de candidatos
es demasiado costoso. ¡Creo que se hace adecuadamente educados y capacitados
demasiado barato! es responsabilidad de las universidades,
Los clientes no se levantarán para y los Ino.st aún no comprenden y
exigir todas estas cualidades, aunque distinguen la ciencia de la computación
unos pocos (como el Departamento de de la informática, y no hacen hincapié
Defensa de EE.UU.) pedirán un hijo. en la ciencia de la computación! El
En cambio, las nuevas empresas de empleo es el reino de las casas de
informática podrán garantizar cada vez software, y muy, muy pocos de sus
más a Inore esas cualidades, y es "a su gerentes entienden la necesidad de
manera" que veremos llegar el uso de contratar personas formalmente
formalismos: mediante productos más capacitadas, y mucho menos de asignar,
adecuadamente iluminados, mediante a los pocos que consiguen, para formar
software más fiable, mediante una grupos con suficiente personal. La
mayor productividad (relativa), pero producción de herramientas está, de
también porque la generación más nuevo, en el dominio de la industria.
joven de desarrolladores de software no Las herramientas producidas en la
querrá: hacerlo de otra manera. universidad son generalmente
Hay pocas esperanzas de que las semánticamente avanzadas, pero los
empresas de software y los fabricantes prototipos en los sentidos t.hc. (1) de
de computadoras existentes ("viejos") ser aplicables sólo a datos muy
se den cuenta de los métodos foráneos pequeños (es decir, no aplicables de
de desarrollo de software. Las viejas manera realista al tipo de grandes
formas de hacer software están ejemplos que suelen surgir en la
demasiado arraigadas en la industria), y (2) de ser pobremente
administración y el personal. He (¡locutnados! Las herramientas
experimentado en la industria producidas por la industria son
establecida enormes lagunas en el invariablemente siempre vacías
conocimiento l)asico sobre incluso el sernanamente, presentando sólo
concepto más básico. s--o sea, lo que herramientas sintácticas y pragrnat.ic, y
los actuales graduados están luego en combinaciones ad hoc.
aprendiendo. La mayoría de los Nunca se demostrará que las viejas
gerentes existentes ni siquiera son formas en que el software está siendo
capaces de desarrollar software y por lo diseñado hoy en día por IBM y todos
tanto no tienen autoridad para hacer sus competidores están equivocadas.
gestión. y están completamente a Eventualmente morirán por falta de
merced de la jerga y las excusas de sus uso, ya que la nueva generación ha
"programadores-ingenieros de crecido con los nuevos métodos:
software".
Creo que el progreso en el uso de los "Las viejas teorías nunca se
métodos formales sólo se producirá si prueban equivocadas. Sólo... se
se cumplen tres condiciones: l) dictan por la falta de uso por
parte de las nuevas
producción de suficientes candidatos de
generaciones...
habiendo crecido con nuevas teorías" - desarrollad teoría en el sentido de
Erwin Schrödinger, Autobiografía. ores de ser demostrable, es
Lo que hemos propuesto en este software..: decir, demostrable "la
documento es una "teoría". Hay muchas "%net.hods teoría". Es, como las
"teorías". Esta, como Inost, otros ", no es una "teorías" de la
33
informática de Inost, más bien una [Bjørner 85b] [Folkjær 80]
conjetura. No se puede probar su
superioridad, ni las "teorías" de otros. y
Sólo la práctica lo dirá, y controlará tal Requerimi
"cambio de mando": entos,
Dansk
"No hay teorías, y no hay pruebas. Datamat.ik
Puede haber conjeturas, y a veces [Jackson 75]
Center,
hay tristes refutaciones" - esencia Techn.
de un aspecto de la Teoría de la Rcpt.,
Ciencia de ICarl Poppers. RAISE/D
[Jackson 83]
DC/EM/I
Para terminar, hemos intentado para cada
faceta y aspecto del software y su desarrollo, v6, -10.
identificar formas y medios de formalizar Diciembre
[Jones 801
estas características en la mayoría de las 85, 1.985.
D.Bjørner. Gráficos y
secciones y subsecciones. [Bjørner
meta-programas del
86a]
proyecto: Towards a
Theory of Software
Referencias Development, Capri
Conference on Innovative
H. Bekié y otros..: A Formal Definition of
Software Factories y Ada,
PL/1, TR25.139,
mayo de 1986, para
IBM Laboratory,
aparecer en Springer
Viena, 1974.
Lecture Notes in Computer
[Bjørner & Jones 78] D. Science, eds. N.
Bjørner & C.B. Habermann y U.
[Bjørner Montanari, 1987.
Jones: The Vienna
86b]
Development
D.Bjørner: Gráficos de
Method: tlLe Meta.-
Language, Springer Desarrollo de Software: A
Verlag, Lecture Unifying Theory for
Notes in Computer Software Development?,
Science, vol. 61, New Delh, 6th Conf. on
1978. Foundations of Software
Technology and
Towa.rds a. Formal Description of Ada, Theoretical Computer
Springer Verlag, Science, Springer Lecture
Lecture Notes in [Bjørner y Notes in Computer
Computer Science, otros 87] Science, vol. 241, ed.
(eds. D. Bjørner & K.Nori, págs. 1 a 9, 1986.
O.N. oest), vol. 98,
1980. VDM Symposium '87 - a
Formal Method at work,
D. Bjørner & C.B. Jones: Formal VDM Europe Conference,
Specification a.nd Bruselas, Marzo 87,
Softwarc Springer Verlag, Lecture
Dcvcl.opne-nt, Notes in Computer
[Bjørner 88] Science, (eds. D. Bjørner,
Prentice-Hall Intl.,
1982. C.B. Jones, M. Mac an
[Bjørner 85a] D.Bjørner: El R,öl.e y el Airchinnig, E. Neuhold),
alcance de la definición [Blilde
formal 83] 1987.
de Ada, Dansk Datamatik D. Bjørner: Arquitecturas
Center, Techn.Rept. AdaFD/ de software y diseño de
DDC/ DB/ sistemas de programación,
6 1985-12-09, 1985. 6 volúmenes, 1988.
34
A.J.B1ik1e & A.Tar1ecki: Naive
Denotational Semantics, in: Information
Processing 83, ed. R.E.A. Mason, IFIP
Congress Proc. , North-Holland Publ.,
1983.
P.F01kjær & D.Bjørner. A Formal Model of
a Generalised CSPlike Language,
Information Processing 80 (ed.
S.H.Lavington), North-Holland Publ., pp.
95-99, 1980.
M.A. Jackson: Principios de Diseño de
Programas, Acadernic Press, 1975.

M.A. Jackson: Desarrollo de sistemas,

Prentice-Hall Intl., 1983.
C.B.- Jones: Software Development, a
Rigorous Approach, Prentice-Hali Intl.,
1980.

35
[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