ES2334041T3 - Sistema analitico de diseño de software. - Google Patents
Sistema analitico de diseño de software. Download PDFInfo
- Publication number
- ES2334041T3 ES2334041T3 ES05742438T ES05742438T ES2334041T3 ES 2334041 T3 ES2334041 T3 ES 2334041T3 ES 05742438 T ES05742438 T ES 05742438T ES 05742438 T ES05742438 T ES 05742438T ES 2334041 T3 ES2334041 T3 ES 2334041T3
- Authority
- ES
- Spain
- Prior art keywords
- specifications
- design
- formal
- verified
- generator
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
- G06F8/24—Object-oriented
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Executing Machine-Instructions (AREA)
- Debugging And Monitoring (AREA)
- Saccharide Compounds (AREA)
Abstract
Sistema analítico de diseño de software dispuesto para recibir especificaciones (14, 18, 22) informales de diseño de sistema, para permitir el desarrollo de diseños (102, 104) de especificaciones formales para una pluralidad de componentes del sistema y para convertir los diseños (102, 104) de especificaciones formales en especificaciones (66, 68, 70, 72) de diseño verificadas para su uso en la creación automática de código (76) fuente y llevar a cabo pruebas de implementación del código (76) fuente, comprendiendo el sistema: un módulo (91) editor dispuesto para permitir la edición por un usuario de las especificaciones (102, 104) formales para cada componente; un generador (90) de especificaciones de caja negra verificadas dispuesto para permitir desarrollar las especificaciones (14, 18, 22) informales de diseño de sistema recibidas para cada componente en: (i) especificaciones (102) formales de diseño representativas de una función de caja negra completamente especificada; y (ii) especificaciones (104) formales de interfaz representativas de una especificación de caja negra infraespecificada, en el que se consigue una infraespecificación introduciendo predicados indefinidos para capturar, para un estímulo s dado, una pluralidad de posibles respuestas y comportamiento posterior, en el que las especificaciones (i) y (ii) se desarrollan usando el módulo (91) editor, y el generador (90) de especificaciones de caja negra está dispuesto además para probar la corrección de las especificaciones (102) formales de diseño y especificaciones (104) formales de interfaz y para generar las especificaciones (66, 68, 70, 72) de diseño verificadas; comprendiendo el generador (90) de especificaciones de caja negra: medios para presentar, a través del módulo (91) editor, tablas (160) de enumeración para capturar las especificaciones formales como especificaciones basadas en secuencias, en el que cada fila de una tabla identifica un estímulo, su respuesta y su equivalencia; un generador (106) de modelos dispuesto para generar automáticamente un modelo (108) matemático en notación CSP del comportamiento del sistema para cada componente a partir de las especificaciones (102) formales de diseño y las especificaciones (104) formales de interfaz expresadas en las tablas (160) de enumeración, donde CSP significa Comunicación de Procesos Secuenciales; y un comprobador (110) de modelos dispuesto para analizar los modelos (108) matemáticos para determinar si tienen el comportamiento requerido para ese componente, para identificar errores en las especificaciones (102) formales de interfaz y en las especificaciones (104) formales de diseño, para realimentar los errores en las especificaciones (102, 104) de diseño informales y/o formales; en el que el generador (90) de caja negra verificada está dispuesto para permitir a un usuario ajustar las especificaciones (102) formales de interfaz y las especificaciones (104) formales de diseño a través de las tablas (160) de enumeración, para generar modelos (108) matemáticos corregidos, para analizar los mismos, para identificar errores y para realimentar los errores hasta que se consiga el comportamiento requerido para ese componente; y para derivar las especificaciones (66, 68, 70, 72) de diseño verificadas requeridas a partir de los modelos (108) matemáticos libres de errores.
Description
Sistema analítico de diseño de software.
La presente invención se refiere a un sistema
analítico de diseño de software y, más en particular, aunque no
exclusivamente, a un sistema de diseño de software que está
dispuesto para mejorar la eficacia y la efectividad del desarrollo
de software en un entorno industrial aplicando técnicas matemáticas
para especificar, modelar y verificar diseños de software antes de
que se implementen.
En prácticamente todas las ramas reconocidas de
la ingeniería, las implementaciones se basan en diseños
verificados; es decir, los requisitos funcionales del producto
final se especifican de manera rigurosa, se construyen modelos
matemáticos para representar estos y los diseños propuestos, y los
modelos de diseño se verifican matemáticamente frente a los modelos
de requisitos para garantizar que cumplen su función prevista antes
de que empiece la implementación.
El software no se desarrolla por lo general de
esta forma. La mayor parte de los sistemas de software se
especifican mediante especificaciones informales de requisitos que
se escriben en lenguaje natural en términos específicos del negocio
y el campo por expertos en el campo que generalmente no son expertos
en diseño e implementación de software. Se reconoce ampliamente que
tales especificaciones adolecen de un carácter incompleto,
ambigüedad e inconsistencias; en otras palabras, una falta de rigor
y precisión.
Los diseños los realizan expertos en diseño e
implementación de software, pero cuyos conocimientos de base del
campo a menudo son superficiales o incompletos. Como consecuencia, a
menudo no reconocerán las deficiencias de las especificaciones a
partir de las cuales trabajan hasta muy avanzada la implementación
de la fase de pruebas de un proyecto, si es que lo hacen.
El comportamiento de software integrado,
accionado por eventos, es a menudo extremadamente complejo
recurriéndose a muchos paralelismos y el diseño debe afrontar
numerosas cuestiones relacionadas con la concurrencia. Los errores
en tales diseños son habituales porque es extremadamente difícil
entender y razonar sistemas concurrentes. En caso de no detectarse,
tales errores de diseño llevan a errores de implementación que son
extremadamente difíciles de detectar y diagnosticar mediante
pruebas porque suelen ser intermitentes en su efecto y difíciles de
reproducir.
Como resultado, es habitual lanzar este tipo de
software con un gran número de defectos sin descubrir y que estos
permanezcan sin detectar durante meses o incluso años.
Resulta útil definir varios términos que se usan
a lo largo de esta memoria descriptiva para describir los enfoques
de la técnica anterior y las realizaciones de la presente invención
(también denominada como el sistema ASD) y estos se exponen a
continuación:
Software informático desarrollado principalmente
por motivos comerciales. Este tipo de software se desarrolla con
fines comerciales y/o constituye un producto previsto para la
explotación comercial o constituye una parte de algún otro producto
desarrollado a su vez con fines comerciales y/o previsto para su
explotación comercial.
El software industrial debe cumplir las normas
de calidad normalmente exigidas y esperadas de productos comerciales
en el mercado. El software industrial habitualmente necesita tener
una vida sostenible de muchos años y poder modificarse y mantenerse
por muchos (equipos de) expertos en desarrollo de software
diferentes durante su vida.
Esto contrasta con el software desarrollado por
individuos u organizaciones académicas, de investigación o de otro
tipo por motivos no comerciales tales como promover el conocimiento
o por otros motivos cuya principal motivación no es la
comercial.
Cualquier actividad para el desarrollo de
software industrial. El desarrollo de software industrial se lleva
a cabo en un contexto empresarial y está sujeto a limitaciones de
coste y tiempo de salida al mercado. A menudo conlleva un esfuerzo
de muchos años de desarrollo y se compone de miles y hasta millones
de líneas de código de programa fuente y las especificaciones y
diseños materializan un extenso conocimiento específico del producto
y el campo. La escala y complejidad del desarrollo de software
industrial hace que esté fuera de las capacidades de personas
individuales y requiere equipos de expertos en desarrollo de
software que trabajan junto con especialistas en el producto y el
campo.
Actividades de diseño emprendidas durante el
desarrollo de software industrial.
La especificación del comportamiento visible
externamente del componente de software en términos de función
matemática absoluta que correlaciona cualquier posible secuencia de
estímulos de entrada con la respuesta apropiada. La forma exacta de
esta función y su especificación se indica en [PP03]. En el sistema
ASD, se emplean dos variedades de especificaciones de función de
caja negra:
1. Una función de caja negra
infraespecificada se usa para especificar interfaces de
componentes de una manera que captura el comportamiento no
determinístico habitualmente presente en especificaciones de
interfaces porque se especifican a un nivel de abstracción en el que
se ocultan detalles de implementación. En el sistema ASD, tales
especificaciones también se denominan especificaciones formales de
interfaces.
2. Una caja negra totalmente especificada
se usa para especificar el diseño de un componente. Siempre se
pretende que los diseños de componentes sean determinísticos al
nivel de abstracción al que se especifica el comportamiento
diseñado. En el sistema ASD, tales especificaciones también se
denominan especificaciones formales de diseño de componentes.
Una especificación de caja negra especifica el
comportamiento en términos de secuencias de estímulos de entrada y
respuestas. No se incluye información de flujo de estado o de
control.
Una especificación de caja de estado es una
refundición de una especificación de caja negra en forma de una
función matemática absoluta que correlaciona un par (estado,
estímulos) con un par (nuevo estado, respuesta). Las secuencias de
estímulos de entrada se sustituyen por datos de estado que capturan
la misma información. En el sistema ASD, se requieren
especificaciones de caja de estado, también denominadas
especificaciones de implementación, únicamente para aquellas partes
del software para las que el código fuente de programa no puede
generarse automáticamente por el generador de código y por tanto
deben programarse a mano. Una caja de estado debe especificar
exactamente el mismo comportamiento que la caja negra de la que se
deriva.
Un conjunto de afirmaciones que especifican el
comportamiento requerido de un componente o sistema de software. Los
requisitos funcionales tienen que ver únicamente con el
comportamiento; otras propiedades requeridas del sistema o
componente se denominan requisitos no funcionales.
Una especificación de interfaz que describe el
comportamiento de un componente en términos de sus respuestas
visibles frente a secuencias de estímulos de entrada en una de sus
interfaces.
Una afirmación de requisitos, funcionales y no
funcionales que el sistema o componente de software ha de
satisfacer.
Una descripción de un sistema de software que
identifica sus partes componentes, las interfaces entre esos
componentes, las funciones que ha de realizar cada componente y
todos los demás requisitos técnicos y reglas de diseño que deben
cumplir todos los diseños de componente y especificaciones de
interfaz.
La especificación detallada de un componente, su
organización y estructura y su comportamiento detallado.
Pruebas diseñadas para probar componentes
individuales específicos en cuanto a su corrección frente al diseño
y especificación de componente. En el sistema ASD, normalmente se
generan automáticamente a partir del diseño por el Generador de
casos de prueba en forma de programas de prueba de
autoejecución.
La implementación del software en un lenguaje de
programación. Normalmente no está en una forma que pueda ejecutarse
por un ordenador; primero debe traducirse a una forma ejecutable
mediante traductores especiales denominados compiladores. Un
compilador es específico del lenguaje de programación que está
traduciéndose y el conjunto de instrucciones y la arquitectura del
procesador de ordenador objetivo.
\vskip1.000000\baselineskip
Una especificación de un diseño de componente en
términos de su comportamiento.
\vskip1.000000\baselineskip
Se dice que un diseño es funcionalmente correcto
si y sólo si el comportamiento del componente cumple sus
especificaciones de requisitos funcionales, las especificaciones de
interfaces funcionales de las interfaces de componentes que debe
implementar y las interfaces de componentes hacia otros componentes
que usa.
También ha de apreciarse que la presente memoria
descriptiva hace referencia a diversos estudios académicos y, por
motivos de comodidad, se proporciona una bibliografía totalmente
detallada al final de la descripción especí-
fica.
fica.
En referencia ahora al diagrama de bloques de la
figura 1, se muestra un sumario de alto nivel de las fases
esenciales de un proceso 10 de desarrollo de software convencional
habitualmente usado en la industria. Por motivos de claridad, se
ignoran cuestiones tales como fases que se solapan en la práctica y
que extienden la descripción más allá de la fase de prueba de
integración, ya que no son relevantes para la presente invención.
Adicionalmente, se supone que todos los datos/documentos generados
por cualquier etapa se arrastran como entrada a todas las etapas
posteriores (por ejemplo, la especificación 14 informal de
requisitos está disponible para las cinco fases del proceso de
desarrollo que siguen a la etapa 12 de análisis de requisitos). Las
etapas realizadas para el desarrollo de software, según se describe
en la figura 1, se resumen de la siguiente manera:
- 1.
- Análisis de requisitos 12: analistas de negocios y expertos en el campo desarrollan especificaciones 14 informales de requisitos que describen, entre otras cosas, el comportamiento funcional requerido del sistema de software. Se escriben según la práctica actual y pueden usar técnicas tales como diagramas de UML, casos de uso, escenarios, diagramas de secuencias y diagramas de flujo junto con descripciones en lenguaje natural en un intento de capturar el comportamiento esencial de la manera más clara posible.
- 2.
- Especificar y diseñar la arquitectura 16: Los expertos en diseño de software analizan los requisitos 14 informales y dividen el sistema de software en componentes, identificando interfaces entre ellos y asignando requisitos funcionales a los mismos. El resultado de este trabajo se documenta en una especificación 18 de arquitectura informal.
- 3.
- Especificar y diseñar componentes 20: Para cada componente identificado en la arquitectura 16, expertos en diseño de software analizan los requisitos informales y la especificación de arquitectura informal y desarrollan especificaciones detalladas del comportamiento requerido de cada componente, sus interfaces y un diseño detallado para implementar el comportamiento requerido. El resultado de este trabajo es un conjunto de documentos 22 de especificaciones informales de componentes y diseños.
- 4.
- Implementar manualmente los componentes 24: Los expertos en implementación de software escriben el código 26 de programa fuente a mano, usando todos los documentos producidos por las etapas anteriores. También diseñan y producen los casos 28 de prueba de componentes detallados necesarios para probar los programas, y detectar y eliminar defectos de los mismos.
- 5.
- Pruebas de componentes 30: Los programas 26 fuente que implementan cada componente se prueban individualmente y de manera independiente entre sí usando los casos 28 de prueba de componentes definidos en la etapa anterior. Dependiendo de la naturaleza de los componentes que estén implementándose, la prueba de componentes 30 será algún tipo de mezcla de casos de prueba automatizados y procedimientos de prueba ejecutados manualmente. Durante esta etapa, normalmente se descubren muchos errores en el código de programa. Algunos de ellos son errores de implementación; otros reflejan errores realizados en etapas anteriores y son defectos en los requisitos informales, la arquitectura y/o en los diseños de componentes y especificaciones. En la figura 1, las consecuencias de esto se ilustran en forma de los bucles 32, 34 de realimentación de defectos de especificación, diseño e implementación. Las salidas resultantes de esta etapa son componentes 36 probados.
- 6.
- Pruebas de integración 38: En esta etapa, los componentes 36 probados individualmente se integran y prueban para formar el sistema de software completo. Durante esta etapa, normalmente se encuentran por primera vez una clase de defectos referentes a las interacciones entre los componentes. Debido a cuestiones tales como la concurrencia, se reconoce que éstos se encuentran entre los más difíciles de detectar y resolver. Algunos de ellos son errores de implementación; otros reflejan errores realizados en etapas anteriores y son defectos en los requisitos informales, la arquitectura y/o diseño de componentes y especificaciones. En la figura 1, las consecuencias de esto se ilustran en forma de bucles 32, 34 de realimentación de defectos de especificación, diseño e implementación.
Como se muestra en la figura 1, todas las
especificaciones y diseños se describen como "informales": no
se describen en una notación rigurosa basada en principios
matemáticos. Por consiguiente, (i) los diseños no pueden
verificarse de manera rigurosa respecto a sus especificaciones de
requisitos antes de que empiece la implementación; y (ii) los
desarrolladores de software se basan en probar su implementación con
el fin de detectar errores en las especificaciones y diseños
originales, así como errores introducidos durante la implementación.
La figura 1 ilustra este problema de manera visual porque los
bucles 32 de defectos de especificación y diseño conectan entre sí
todas las fases del proceso 10 de diseño de software.
Esta forma de llevar a cabo diseño de software
convencional y sus efectos se ilustran gráficamente en la figuras 2
y 3. La figura 2 es un gráfico 50 que muestra cómo se introducen
habitualmente defectos a lo largo del proceso de desarrollo de
software, aunque la mayoría de ellos no se detectan y eliminan hasta
que empiezan las pruebas tarde en el proceso. La figura 3 es un
gráfico 52, que ilustra las consecuencias del enfoque convencional
en un proyecto típico. Cuando empiezan las pruebas, se descubren
defectos y aumenta de manera incontrolada la cantidad de trabajo
repetido.
Como se ha mostrado anteriormente existe un
problema en que los errores en especificaciones y diseños no se
detecten y eliminen antes de la implementación y, como resultado,
las pruebas de software deben detectar y eliminar por tanto errores
que se originan en la especificación y diseños, así como errores de
implementación. Para el software desarrollado en un marco
industrial, el hecho de basarse de este modo únicamente en las
pruebas lleva a que queden niveles inaceptables de defectos en el
software. Algunos de los motivos de esto, que se han apreciado en
la industria se resumen de la siguiente manera:
- 1.
- Las pruebas de software nunca pueden ser completas y no pueden "demostrar" la corrección; y
- 2.
- El software industrial es demasiado complejo de probar de manera exhaustiva y por tanto sólo puede probarse un subconjunto relativamente pequeño de la funcionalidad total.
En términos generales, se han adoptado dos
enfoques principales para intentar abordar estos problemas:
- \bullet
- Enfoques basados en procesos, en los que se establecen flujos de trabajo disciplinados y se soportan por prácticas de gestión apropiadas en un intento de reducir los defectos inyectados durante la fase de especificación y diseño. Esto se consigue mediante técnicas sociales tales como revisiones de documentos, repasos del diseño, inspecciones de código, etc.;
- \bullet
- Enfoques basados en procedimientos formales, en los que se usan técnicas matemáticas para especificar requisitos y diseños y realizar una cierta verificación de corrección basada en matemáticas antes de la implementación.
Los enfoques basados en procesos informales
surgen generalmente de la propia industria de desarrollo de
software. Su mayor debilidad es su firme rechazo a reconocer la
necesidad de las matemáticas en la especificación y verificación de
diseños de software antes de su implementación. Estos enfoques,
aunque valiosos como forma de procesos de ingeniería disciplinados,
siguen basándose en procedimientos informales de especificación de
requisitos y diseños y no proporcionan medios para analizar el
comportamiento dinámico de los diseños propuestos antes de su
implementación. También tienden a dirigir la concentración a la
corrección de componentes individuales en lugar de a los sistemas
en su conjunto y no abordan las cuestiones de diseño más difíciles
de concurrencia en grandes sistemas.
Los enfoques basados en procedimientos formales
se han desarrollado en gran medida en ámbitos académicos y se basan
en las matemáticas. Normalmente, el comportamiento requerido se
especifica usando una notación matemática rigurosa y los diseños
evolucionan mediante un proceso denominado Refinamiento por
pasos en el que se producen diseños y eventualmente
implementaciones en series de pasos pequeños que preservan la
corrección, de manera bastante similar en concepto a la forma en la
que se presentan demostraciones matemáticas.
"Using CSP to Support the Cleanroom
Development Method for Software Development" de Broadfoot G H es
una tesis doctoral de la Universidad de Oxford con fecha de
septiembre de 2001 que proporciona información de base sobre el
álgebra de procesos CSP y un proceso establecido de desarrollo de
software denominado el procedimiento Cleanroom (sala limpia).
"Academia and industry meet: some experiences
of formal methods in practice" de Broadfoot G H, y Broadfoot P
J, páginas 49-58 de Proceedings of the Tenth
Asia-Pacific Software Engineering Conference, 2003,
es un artículo publicado que proporciona una visión general de la
aplicación de procedimientos formales de verificación, con
referencia al procedimiento Cleanroom y a CSP.
En teoría, el enfoque de procedimientos formales
ha sostenido desde hace ya varios años la promesa de abordar los
problemas descritos en la sección anterior. Existen numerosos
procedimientos formales que se han desarrollado durante las últimas
décadas, que tienen la teoría matemática necesaria para modelar los
diseños de sistemas de software y razonar acerca de su corrección.
En la práctica, sin embargo, los procedimientos formales casi nunca
se encuentran en el entorno de trabajo industrial. Algunos de los
motivos de esto que han apreciado los presentes inventores se
resumen de la siguiente manera:
Falta de integración en el proceso de
software: existe un vacío de comunicación entre los expertos en
procedimientos formales por un lado y los analistas de negocios y
expertos en el campo por otro lado. Apenas hay nada por la vía del
conocimiento común compartido entre ellos. Los analistas de negocios
y expertos en el campo no son por lo general expertos en ningún
procedimiento formal específico y no pueden participar en el
proceso de desarrollo de especificaciones formales. Los expertos en
procedimientos formales por lo general no son expertos en el campo
del sistema que está especificándose e implementándose y no estarán
familiarizados con la práctica empresarial que subyace al producto;
deben fiarse de los analistas de negocios y expertos en el campo
para adquirir este conocimiento. Este vacío de comunicación plantea
la siguiente cuestión: si los analistas de negocios y los expertos
en el campo que tienen el conocimiento específico del producto no
pueden entender las especificaciones formales y los expertos en
procedimientos formales que escriben y entienden estas
especificaciones formales no tienen una comprensión suficientemente
profunda del campo del producto para estar seguros de que no están
cometiéndose errores, ¿cómo pueden validarse estas especificaciones
formales? Quienes las entienden no conocen demasiado y quienes
conocen lo suficiente no las entienden. Este vacío debe superarse
con el fin de integrar un enfoque formal en un proceso de desarrollo
de software en la industria. Debe haber bucles de realimentación
hacia y desde cada fase del proceso de desarrollo, incluyendo a los
clientes y a los expertos en el campo. Resistencia dentro de la
industria: los desarrolladores de software y sus gerentes no
están acostumbrados a aplicar las matemáticas en el desarrollo de
software y muchos no tienen la formación y experiencia necesaria
para hacerlo. Hay una gran resistencia entre los desarrolladores de
software frente a un enfoque formal y los costes de hacerlo se
perciben como prohibitivos por los gerentes. En la actualidad, la
industria está dedicada a un enfoque basado en la detección y
eliminación de defectos e intenta abordar los problemas
actuales volviéndose más eficaz en las pruebas. El uso de
procedimientos formales requiere un cambio de actitud que se aleja
de este enfoque y se centra en la prevención de defectos, una
práctica común en todas las demás ramas de la ingeniería y este
cambio es muy difícil de conseguir.
La inmadurez de los procedimientos y
herramientas formales: Las técnicas y herramientas de los
procedimientos formales son inmaduras y no pueden asumir los
desarrollos de software a escala industrial. Esto supone problemas
técnicos importantes que no se han resuelto. También hay obstáculos
importantes en la progresión porque sin herramientas, todas las
obligaciones de demostración deben llevarse a cabo a mano. Esto es
tanto susceptible a errores como inviable, dada la escala de los
sistemas de software modernos que están desarrollándose.
Un objetivo de la presente invención es reducir
al menos sustancialmente los problemas que se han descrito
anteriormente y proporcionar un sistema para el desarrollo de
software que, cuando se use para desarrollar un producto de
software dé como resultado menos errores presentes en ese producto,
acortando así el tiempo de desarrollo y reduciendo los costes de
generación de software industrial totalmente probado y libre de
defectos importantes.
Según un aspecto de la presente invención se
proporciona un sistema de diseño de software analítico dispuesto
para recibir especificaciones informales de diseño de sistema, para
permitir el desarrollo de diseños de especificaciones formales para
una pluralidad de componentes del sistema y para convertir los
diseños de especificaciones formales en especificaciones de diseño
verificadas para su uso en la creación automática de código fuente y
para llevar a cabo pruebas de implementación del código fuente,
comprendiendo el sistema: un módulo editor dispuesto para permitir
a un usuario editar las especificaciones formales para cada
componente; un generador de especificaciones de caja negra
verificadas dispuesto para permitir desarrollar las especificaciones
informales de diseño de sistema recibidas, para cada componente, en
(i) especificaciones formales de diseño representativas de una
función de caja negra totalmente especificada y (ii)
especificaciones formales de interfaz representativas de una
especificación de caja negra infraespecificada, consiguiéndose la
infraespecificación introduciendo predicados indefinidos para
capturar, para un estímulo s dado, una pluralidad de posibles
respuestas y comportamiento posterior, en el que las
especificaciones (i) y (ii) se desarrollan usando el módulo editor,
y el generador de especificaciones de caja negra está dispuesto
además para probar la corrección de las especificaciones formales
de diseño y las especificaciones formales de interfaz y para generar
las especificaciones de diseño verificadas; comprendiendo el
generador de especificaciones de caja negra: medios para presentar,
a través del módulo editor, tablas de enumeración para capturar las
especificaciones formales como especificaciones basadas en
secuencias, en las que cada fila de una tabla identifica un
estímulo, su respuesta y su equivalencia; un generador de modelos
dispuesto para generar automáticamente un modelo matemático en
notación CSP del comportamiento del sistema para cada componente a
partir de las especificaciones formales de diseño y las
especificaciones formales de interfaz expresadas en las tablas de
enumeración, donde CSP significa Comunicación de Procesos
Secuenciales; y un comprobador de modelos dispuesto para analizar
los modelos matemáticos para determinar si tienen el comportamiento
requerido para ese componente, para identificar errores en las
especificaciones formales de interfaz y las especificaciones
formales de diseño, para realimentar los errores en las
especificaciones informales y/o formales de diseño; en el que el
generador de caja negra verificada está dispuesto para permitir a
un usuario ajustar las especificaciones formales de interfaz y las
especificaciones formales de diseño a través de las tablas de
enumeración, para generar modelos matemáticos corregidos, para
analizar los mismos, para identificar errores y para realimentar
los errores hasta que se consiga el comportamiento requerido para
ese componente; y para derivar las especificaciones de diseño
verificadas requeridas a partir de los modelos matemáticos libres
de errores.
La presente invención aborda los problemas de la
técnica anterior proporcionando un sistema en el que las
especificaciones y los diseños se verifican de modo que se eliminan
errores antes de que empiece la implementación. La derivación
de especificaciones de diseño requeridas de este modo permite la
separación de los dos tipos diferentes de pruebas, lo que significa
que las pruebas de componentes y de integración pueden concentrarse
en detectar y eliminar únicamente errores de implementación lo que a
su vez reduce el coste y el número de días requerido para llevar a
cabo las pruebas de implementación. Esto se consigue por lo general
mediante la presente invención franqueando el vacío entre la
práctica industrial existente y los procedimientos formales
desarrollados en el ámbito académico de modo que estos
procedimientos formales pueden aplicarse de manera más
generalizada.
Según otro aspecto de la presente invención, se
proporciona un procedimiento para desarrollar y convertir diseños
de especificaciones formales de un sistema de software que va a
diseñarse, en especificaciones de diseño verificadas para su uso en
la creación automática de código fuente y para llevar a cabo pruebas
de implementación del código fuente para el sistema de software,
comprendiendo el procedimiento: recibir especificaciones informales
de diseño de sistema para una pluralidad de componentes del sistema
de software, permitir a un usuario, usando un módulo editor; editar
los diseños de especificaciones formales para cada componente;
proporcionar un generador de especificaciones de caja negra
verificadas para desarrollar, para cada componente, a partir de las
especificaciones informales de diseño de sistema recibidas (i)
especificaciones formales de diseño representativas de una función
de caja negra totalmente especificada, y (ii) especificaciones
formales de interfaz representativas de una especificación de caja
negra infraespecificada, consiguiéndose la infraespecificación
introduciendo predicados indefinidos para capturar, para un estímulo
s dado, una pluralidad de posibles respuestas y el comportamiento
posterior, en el que las especificaciones (i) y (ii) se desarrollan
usando el módulo editor, probando la corrección de las
especificaciones formales de diseño y las especificaciones formales
de interfaz; generando las especificaciones de diseño verificadas;
presentando, a través del módulo editor, tablas de enumeración para
capturar las especificaciones formales como especificaciones basadas
en secuencias, en las que cada fila de una tabla identifica un
estímulo, su respuesta y su equivalencia; produciendo
automáticamente, usando un generador de modelos, un modelo
matemático en notación CSP del comportamiento del sistema para cada
componente a partir de las especificaciones formales de diseño y
las especificaciones formales de interfaz expresadas en las tablas
de enumeración, donde CSP significa Comunicación de Procesos
Secuenciales; analizando, usando un comprobador de modelos, los
modelos matemáticos para determinar si tienen el comportamiento
requerido para ese componente, para identificar errores en las
especificaciones formales de interfaz y las especificaciones
formales de diseño, y para realimentar los errores en las
especificaciones informales y/o formales de diseño; y usando el
generador de especificaciones de caja negra para permitir a un
usuario ajustar las especificaciones formales de interfaz y las
especificaciones formales de diseño a través de las tablas de
enumeración, para generar modelos matemáticos corregidos, para
analizar los mismos, para identificar errores y para realimentar
los errores hasta que se consiga el comportamiento requerido para
ese componente; y para derivar las especificaciones de diseño
verificadas requeridas a partir de los modelos matemáticos libres de
errores.
En términos generales, las ventajas técnicas del
sistema analítico de diseño de software (ASD) que realiza la
presente invención son tres:
- 1.
- Los expertos en desarrollo de software pueden usar el sistema ASD para producir especificaciones formales y diseños de sistema verificados, totalmente integrados en los procesos de desarrollo de software convencionales existentes convencionales. Totalmente integrados, en este contexto, implica que (i) hay bucles de realimentación continua en el proceso de desarrollo para tratar errores, extensiones y modificaciones que surgen en la práctica, y (ii) se franquea el vacío entre las especificaciones formales y los diseños producidos usando ASD y el resto del ciclo de desarrollo industrial. La consecuencia de esto es que se evita que los errores realizados durante las fases de análisis de requisitos, especificación y diseño de la arquitectura y diseño y especificación de componentes lleguen a la fase de implementación y más lejos. Esto se ilustra en la figura 4 (descrita más adelante) mediante el bucle de realimentación de defectos de especificación y diseño que ya no se extiende a las fases de implementación manual de componentes, prueba de componentes y pruebas de integración.
- 2.
- El sistema ASD genera preferiblemente código de programa fuente automáticamente a partir de los diseños verificados para partes del sistema reduciendo así la cantidad de código de programa fuente que ha de producirse manualmente. La ventaja de esto es una reducción en errores introducidos durante la fase de implementación.
- 3.
- El sistema ASD genera preferiblemente casos de prueba de componentes automáticamente a partir de los diseños de componentes verificados. Esto también es ventajoso porque aumenta tanto la efectividad como la cobertura de las pruebas de componentes, dando como resultado menos defectos restantes cuando el software entra en la fase de pruebas de integración.
Las figuras 5 y 6 describen gráficamente el
efecto resultante de extender el proceso de desarrollo de software
al sistema ASD en cuanto a tasas de inyección de errores (véase el
gráfico 54 de la figura 5) y tasas de detección (véase el gráfico 56
de la figura 6), y estos dos gráficos también hacen una comparación
directa con el enfoque convencional.
A continuación se exponen otras ventajas de la
presente invención y características descritas en la descripción y
reivindicaciones adjuntas.
- \sqbullet
- El sistema ASD garantiza que la fase de implementación empieza a partir de diseños correctos de manera verificable y evita que errores de diseño lleguen a la fase de implementación. Esto lleva a los siguientes beneficios:
- \circ
- Las pruebas sólo tienen que abordar errores de implementación.
- \circ
- Una reducción significativa en trabajo repetido evitable; los errores de diseño son con frecuencia los más caros y problemáticos de arreglar.
- \circ
- Una reducción significativa en el esfuerzo y tiempo para las pruebas de integración.
- \circ
- Una reducción significativa en el tiempo hasta la comercialización.
- \circ
- Un tiempo, coste y calidad de desarrollo más predecible.
- \sqbullet
- Franqueo rastreable: El procedimiento de enumeración basada en secuencias proporciona una trazabilidad total entre los modelos formales que se analizan y los requisitos informales, participantes y miembros del proyecto. Esto proporciona la unidad requerida en la práctica entre especificaciones y el modelo formal que está verificándose.
- \sqbullet
- Generación automatizada de modelos de CSP usando los algoritmos proporcionados. Esto significa que los beneficios de usar modelado matemático basado en CSP pueden ponerse a disposición más fácilmente porque los expertos en diseño de software no necesitan el nivel de conocimientos matemáticos necesario para realizar los modelos a mano. Además, dado que los modelos se generan automáticamente a partir de diseños y especificaciones, cuando estos diseños y especificaciones cambian, no hay apenas dificultad en mantener los modelos matemáticos actualizados; sencillamente vuelven a generarse.
- \sqbullet
- El lenguaje CSP se diseñó con fines de descripción de sistemas concurrentes y por tanto permite un análisis riguroso de cuestiones de concurrencia que surgen durante la fase de diseño. Tales cuestiones se sabe que están entre los problemas más difíciles de tratar en el diseño de software y son inviables de solucionar en la fase de implementación. Antes de proporcionar el sistema ASD dado a conocer en una realización de la presente invención, había un prejuicio importante contra el uso de procedimientos formales tales como CSP en la industria, ya que se percibía como demasiado complicado y comercialmente inaceptable de usar. Esto se debe a que la mayoría de los expertos en diseño de software no tienen el conocimiento matemático especializado requerido para construir modelos razonables en CSP. Además, la construcción y mantenimiento de tales modelos a mano es muy caro. El sistema ASD hace posible realizar los beneficios de CSP de manera mucho más generalizada y tiene como resultado que llegan menos errores de diseño a la implementación.
- \sqbullet
- El sistema ASD proporciona una verificación totalmente automatizada del comportamiento funcional de especificaciones y diseños usando el comprobador de modelos FDR. Al igual que los requisitos de sistema, esto incluye verificar los diseños en cuanto a propiedades tales como falta de determinismo accidental, seguridad y vitalidad, evitación de bloqueos y libertad de divergencia.
- \sqbullet
- Se reconoce de manera generalizada en la industria del software que la reutilización de software ofrece el potencial de reducir de manera significativa el tiempo y el coste de desarrollo de software y de reducir de manera significativa el número de errores todavía presentes en el software cuando se lanza a sus usuarios finales. Un impedimento principal para una adopción más generalizada de la reutilización de software es la dificultad a la hora de especificar el comportamiento de componentes complejos con suficiente precisión. Las especificaciones formales de interfaces de componentes producidas por el sistema ASD son tanto precisas de manera rigurosa como comprensibles. Además, pueden convertirse automáticamente en los modelos matemáticos necesarios para verificar el diseño de software usando tales componentes reutilizables. El sistema ASD facilita por tanto la reutilización de software.
- \sqbullet
- Un sistema de software debe extenderse y mantenerse a lo largo de toda su vida. En un entorno de desarrollo de software convencional, se trata de una actividad cara y susceptible a errores porque gran parte de la información de diseño importante no se pone por escrito y se basa en el conocimiento personal acumulado de las personas que diseñan y programan el software. El sistema ASD mejora esta situación porque produce un conjunto completo de especificaciones y diseños verificados. Pueden realizarse cambios planificados en estas especificaciones y diseños verificados y volverse a verificar usando el sistema ASD antes de cambiar la implementación, dando como resultado una mejor calidad y costes reducidos.
- \sqbullet
- Certificación de diseños de software.
- \sqbullet
- Puede usarse en sistemas de cualquier tamaño debido a la capacidad de composición de CSP.
- \sqbullet
- La generación de código implica menos errores.
- \sqbullet
- La verificación automática de caja de estado frente a caja negra implica menos errores.
- \sqbullet
- La verificación automática de caja de estado frente a caja de estado implica que pueden realizarse optimizaciones a nivel de caja de estado y verificarse; esto no puede realizarse a nivel de código.
A continuación se describirán a modo de ejemplo
procedimientos y aparatos según realizaciones preferidas de la
presente invención para diseñar analíticamente y probar software,
con referencia a los dibujos adjuntos en los que:
la figura 1 es un diagrama de bloques
esquemático que muestra un proceso de desarrollo de software
convencional;
la figura 2 es un gráfico tridimensional que
ilustra el problema técnico de las tasas de inyección de errores y
detección de defectos en el ciclo de vida del proceso de desarrollo
de software convencional de la figura 1;
la figura 3 es un gráfico tridimensional que
ilustra la cantidad de trabajo repetido requerido a lo largo del
proceso de desarrollo de software como resultado de la manera de
realizar las pruebas empleada en el proceso de desarollo de software
convencional de la figura 1;
la figura 4 es un diagrama de bloques
esquemático que muestra un proceso y sistema de desarrollo de
software modificado, que incluye un sistema de diseño analítico de
software (ASD) integrado, según una primera realización de la
presente invención;
la figura 5 es un gráfico tridimensional que
muestra una comparación gráfica entre la tasa de inyección de
defectos real en el proceso de desarrollo de software
convencional y la tasa de inyección de defectos modificada
conseguida con la primera realización de la figura 4, que introduce
el sistema de diseño de software analítico (ASD);
la figura 6 es un gráfico tridimensional que
muestra una comparación gráfica entre la tasa de detección de
defectos real en el proceso de desarrollo de software
convencional y la tasa de detección de defectos modificada de
la primera realización de la figura 4, que introduce el sistema
ASD;
la figura 7 es un diagrama de bloques general
esquemático del sistema ASD de la primera realización de la figura
4, que muestra un generador de especificaciones de caja negra
verificadas y un generador de especificaciones de implementación
verificadas;
la figura 8 es un diagrama de bloques
esquemático del sistema ASD que muestra una visión general más
detallada del generador de especificaciones de caja negra
verificadas de la figura 7;
la figura 9 es un diagrama de bloques
esquemático del sistema ASD que muestra una visión general más
detallada del generador de especificaciones de implementación
verificadas de la figura 7;
la figura 10 es un diagrama de flujo de bloques
esquemático que muestra una visión general más detallada de un
proceso para generar modelos matemáticos para un único componente A
de software usando la primera realización de la figura 7;
la figura 11 es un diagrama de flujo de bloques
esquemático que muestra una visión general más detallada de un
proceso para verificar formalmente si la especificación de diseño de
un componente A cumple todas las especificaciones de interfaz
necesarias usando la primera realización de la figura 7;
la figura 12 es un diagrama de flujo de bloques
esquemático que muestra una visión general más detallada de un
proceso para generar modelos matemáticos para la especificación de
implementación de un único componente A de software usando la
primera realización de la figura 7;
la figura 13 es un diagrama de flujo de bloques
esquemático que muestra una visión general más detallada de un
proceso para verificar formalmente si la especificación de caja de
estado de un componente A cumple la correspondiente especificación
de caja negra usando la primera realización de la figura 7;
la figura 14 es una tabla para ilustrar un
ejemplo de una tabla de enumeración para alguna secuencia C
canónica;
la figura 15 es una tabla para ilustrar un
ejemplo de la aplicación del algoritmo 1 a una tabla de enumeración
para alguna secuencia C canónica y generar el correspondiente
proceso P_{C} de CSP;
la figura 16 es una tabla que ilustra un ejemplo
de una caja de estado para algún estímulo s;
la figura 17 es una tabla que ilustra un ejemplo
de la presente aplicación del algoritmo 4 a tablas de caja de estado
y generar el correspondiente proceso P_{SB} de CSP;
la figura 18 es una representación esquemática
de una pantalla de interfaz generada mediante un módulo editor de
ASD del sistema ASD mostrado en la figura 7;
la figura 19 es una representación esquemática
de una pantalla de enumeración de secuencias generada por el módulo
editor de ASD del sistema ASD mostrado en la figura 7;
la figura 20 es una representación esquemática
de una pantalla de requisitos derivados generada por el módulo
editor de ASD del sistema ASD mostrado en la figura 7;
la figura 21 es una representación esquemática
de una pantalla de análisis canónico generada por el módulo editor
de ASD del sistema ASD mostrado en la figura 7;
la figura 22 es un diagrama de bloques
esquemático que ilustra el proceso de ejecutar código fuente
generado para un componente que está diseñándose (CBD) dentro de su
entorno de tiempo de ejecución que consiste en todos los demás
componentes con los que interacciona;
la figura 23 es un diagrama de bloques
esquemático que ilustra el proceso de ejecutar código fuente
generado para un componente que está diseñándose (CBD) dentro de su
entorno de tiempo de ejecución junto con los verificadores de
protocolo de interfaz para cada uno de los componentes con los que
interacciona según una segunda realización de la presente
invención;
la figura 24 es un diagrama de bloques
esquemático que muestra un proceso y sistema de desarrollo de
software modificado, que incluye un sistema ASD integrado y
verificadores de protocolo de interfaz, según la segunda realización
de la presente invención como se muestra en la figura 23; y
la figura 25 es un diagrama de bloques general
esquemático del sistema ASD de la segunda realización de la figura
24, que muestra un generador de especificaciones de caja negra
verificadas, un generador de especificaciones de implementación
verificadas y un generador de verificadores de protocolo de
interfaz.
En referencia ahora de nuevo a la figura 4, se
describe ahora un proceso para desarrollo 60 de software que
incorpora un sistema 62 de diseño analítico de software (ASD) según
una primera realización de la presente invención. El sistema 62 ASD
se integra en un proceso de desarrollo de software convencional y
tiene algunos componentes comunes como se describe en detalle más
adelante. Cuando se usa el sistema 62 ASD, el proceso de desarrollo
de software modificado es como sigue:
- 1.
- Análisis de requisitos 12: Es igual a como se ha descrito anteriormente en relación con la figura 1.
- 2.
- Especificar y diseñar la arquitectura 16: Es igual a como se ha descrito anteriormente en relación con la figura 1.
- 3.
- Especificar y diseñar componentes 20: Es igual a como se ha descrito anteriormente en relación con la figura 1.
- 4.
- Sistema 62 de diseño analítico de software (ASD): Las entradas al sistema 62 ASD son las especificaciones 14 informales de requisitos, las especificaciones 18 informales de arquitectura y las especificaciones 22 informales de componentes y diseños. Las salidas del sistema 62 ASD son las siguientes:
- a.
- Salida 64 de especificación verificada:
- i.
- Especificación 66 de requisitos verificada;
- ii.
- Especificación 68 de arquitectura verificada;
- iii.
- Especificaciones 70 de diseño de componentes verificadas;
- iv.
- Especificaciones 72 de interfaces de componentes verificadas;
- v.
- Especificaciones 74 de implementación de componentes verificadas.
- b.
- Código 76 de programa fuente generado por máquina para partes del sistema de software.
- c.
- Casos 78 de prueba de componentes generados por máquina se generan también para su uso en un procedimiento de pruebas de componentes.
- d.
- Gráficos y tablas 79 de máquina de estados también se generan.
Más adelante se da una descripción detallada del
sistema ASD.
- 5.
- Implementar manualmente componentes 80: los expertos en implementación de software escriben el resto de programas fuente a mano para aquellas partes del sistema que no pueden generarse automáticamente por el sistema 62 ASD, usando las especificaciones 66, 68, 70, 72, 74 verificadas producidas por el sistema 62 ASD.
- 6.
- Pruebas de componente 84: los programas 82 fuente que implementan cada componente se prueban individualmente y de manera independiente entre sí frente a las especificaciones y diseños verificados usando los casos 78 de prueba de componentes generados por máquina por el sistema 62 ASD. Dado que la implementación se basa en especificaciones y diseños verificados, los errores descubiertos en esta fase son principalmente errores de implementación únicamente y sólo están relacionados con aquellas partes de los programas fuente escritos a mano 80. Los programas 82 fuente generados por el sistema 62 ASD son una representación funcionalmente correcta del diseño. Esto contrasta con la situación en el proceso de desarrollo de software no modificado cuando no se usa el sistema 62 ASD. La figura 4 muestra que el bucle 32 de realimentación de defectos de especificación y diseño mostrado en la figura 1, ya no se extiende a las fases de implementación y prueba.
- 7.
- Pruebas de integración 88: en esta etapa, los componentes 86 probados individualmente se integran y se prueban para formar el sistema de software completo. Durante esta etapa, normalmente se encuentran por primera vez una clase de defectos referentes a las interacciones entre los componentes. Dado que la implementación se basa en especificaciones y diseños verificados, los errores descubiertos en esta fase son principalmente errores de implementación únicamente. Las cuestiones más difíciles tales como la concurrencia se han eliminado durante la verificación del diseño. La figura 4 muestra que el bucle 32 de realimentación de defectos de especificación y diseño ya no se extiende a las fases de implementación y prueba.
El sistema 62 ASD descompone de manera eficaz
las pruebas de diseño en dos partes diferentes que no se solapan:
siendo la primera la prueba de requisitos, arquitectura y
componentes en busca de defectos en su especificación y diseño;
siendo la segunda la prueba de requisitos verificados, arquitectura
verificada, diseño de componentes verificado, interfaces de
componentes verificadas e implementaciones de componentes
verificadas, individualmente y de manera integrada en busca de
defectos en su implementación.
\vskip1.000000\baselineskip
En referencia ahora a la figura 7, el sistema 62
ASD se describe ahora más detalladamente. El sistema 62 ASD es el
corazón de la primera realización y comprende los siguientes
elementos:
- 1.
- Generador 90 de especificaciones de caja negra verificadas: la primera fase de procesamiento del sistema 62 ASD llevada a cabo por el generador 90 de especificaciones de caja negra verificadas es producir especificaciones formales funcionales de los requisitos, arquitectura, diseños de componentes e interfaces de componentes a partir de las especificaciones 14, 18, 22 informales de los requisitos, arquitectura, diseños de componentes e interfaces de componentes. La salida de esta fase son:
- a.
- Especificación 66 de requisitos verificada,
- b.
- Especificación 68 de arquitectura verificada,
- c.
- Especificaciones 70 de diseño de componentes verificadas, y
- d.
- Especificaciones 72 de interfaces de componentes verificadas.
- El generador 90 de especificaciones de caja negra verificadas del sistema 62 ASD incluye un módulo de procesamiento denominado un editor 91 de ASD, que forma parte del sistema 62 ASD, que sirve de interfaz para arquitectos y diseñadores de software y se usa para capturar los resultados de este trabajo en forma tabular. El editor 91 de ASD almacena los resultados en archivos 93 de datos en una forma que puede usarse como entrada para el generador de modelos, descrito más adelante.
- Capturar especificaciones y diseños funcionales de este modo es un proceso iterativo con realimentación continua entre especialistas de producto, expertos en el campo, arquitectos y diseñadores de software con realimentación en todas las fases previas en el proceso de desarrollo de software para corregir los defectos de especificación y/o diseño realizados en esas fases más tempranas. En cualquier momento durante o después de este proceso, los arquitectos y diseñadores de software pueden usar el editor 91 de ASD para imprimir los resultados en forma de tablas y gráficos 79 de máquina de estados.
- 2.
- Generador de código: El generador 92 de código es un programa informático que toma como entrada la especificación 66 de requisitos verificada, la especificación 68 de arquitectura verificada, las especificaciones 70 de diseño de componentes verificadas y las especificaciones 72 de interfaces de componentes verificadas en los archivos de datos producidos por el editor 91 de ASD y produce código 76 fuente de programa generado en un lenguaje de programación que implementa (parte de) el diseño de componentes. Esta primera realización genera programas fuente en C y C++. Es fácilmente extensible a otros lenguajes de programación cuando sea necesario. Este componente se describe en detalle más adelante.
- 3.
- Generador 94 de especificaciones de implementación verificadas: aquellas partes del software para las que el código 82 de programa fuente no puede generarse automáticamente por el generador 92 de código, deben programarse a mano. Para hacer esto lo más sencillo y libre de errores posible, se generan especificaciones 74 de implementación verificadas detalladas usando el procedimiento de desarrollo de estructura en caja como se describe más adelante. Las entradas son los diseños 66, 68, 70, 72 de componentes verificados producidos por el generador 90 de caja negra verificada y las salidas son las especificaciones 74 de implementación de componentes verificadas. El editor 91 de ASD del generador 90 de caja negra verificada se usa para capturar las especificaciones 72 de implementación de componentes verificadas, y almacenarlas en forma de archivos de datos (no mostrados).
- 4.
- Generador 96 de casos de prueba de componentes: el generador 96 de casos de prueba de componentes es un módulo de procesamiento que toma como entradas los archivos de datos producidos por el editor 91 de ASD, concretamente, la especificación 66 de requisitos verificada, la especificación 68 de arquitectura verificada, especificaciones 70 de diseño de componentes verificadas y especificaciones 72 de interfaces de componentes verificadas, y genera una amplia selección de casos 78 de prueba de componentes estadísticamente seleccionados. Una de las posibles formas en las que estos casos de prueba pueden generarse son programas fuente de ordenador en un lenguaje de programación apropiado. La realización de la presente invención se da a conocer generando casos de prueba de componentes en Perl, C, C++, Visual Basic y Java. Esto es fácilmente extensible a otros lenguajes de programación cuando sea necesario. Este componente se describe con más detalle más adelante.
En referencia ahora a la figura 8, el generador
90 de especificaciones de caja negra verificadas introducido en la
figura 7, se describe ahora más detalladamente. El generador 90 de
especificaciones de caja negra verificadas, produce
especificaciones formales funcionales de los requisitos,
arquitectura, diseños de componentes e interfaces de componentes a
partir de las especificaciones informales de los requisitos,
arquitectura y diseños de componentes y las verifica en cuanto a su
corrección. Las especificaciones verificadas producidas son:
especificación 66 de requisitos verificada, especificación 68 de
arquitectura verificada, especificaciones 70 de diseño de
componentes verificadas y especificaciones 72 de interfaces de
componentes verificadas. Además, produce una versión tabular
impresa de las especificaciones y una representación gráfica del
comportamiento especificado en forma de gráficos y tablas 79 de
máquina de estados para permitir la validación.
El generador 90 de especificaciones de caja
negra verificadas, comprende los siguientes componentes:
- 1.
- Generador 100 de especificaciones basadas en secuencias: usando el editor 91 de ASD, que se describe más adelante, los expertos en diseño de software analizan las especificaciones 14, 18, 22 informales y aplican el procedimiento de especificaciones basadas en secuencias [PTLP98, PP03] para producir una especificación de caja negra infraespecificada que describe el comportamiento funcional requerido, visible en cada interfaz, de cada componente de software que va a implementarse. Al mismo tiempo, también se identifican todos los demás componentes de hardware y/o software, con los que el software que va a desarrollarse debe estar interconectado, y, si no existen ya las especificaciones de caja negra para ellos, se producen. Estas especificaciones 104 de caja negra infraespecificadas son una definición formal, matemáticamente completa y consistente del comportamiento funcional requerido de cada componente que es visible por sus interfaces. Se describen como infraespecificadas porque se suprimen todos los detalles de implementación y se ocultan de sus eventuales usuarios. Como resultado, el comportamiento de interfaz casi siempre es no determinístico. Cuando todas las interfaces se han especificado formalmente en las especificaciones 104 formales de interfaz, cada componente debe diseñarse. Los expertos en diseño de software usan el editor 91 de ASD y aplican de nuevo el procedimiento de especificaciones basadas en secuencias, esta vez para desarrollar un diseño determinístico de cada componente 102. El diseño debe reflejar apropiadamente el comportamiento de interfaz requerido especificado en la especificación 72 de interfaz de componente y debe cumplir apropiadamente con el comportamiento de interfaz especificado de los componentes que utiliza. Para garantizar que éste es el caso, los diseños y especificaciones de interfaz se verifican unos frente a otros y frente a cualquier otro requisito de comportamiento derivado de las especificaciones informales. Además, en cualquier momento durante o después de este proceso, el editor 91 de ASD puede usarse para producir una versión tabular impresa de las especificaciones y una representación gráfica del comportamiento especificado en forma de gráficos y tablas 79 de máquina de estados para permitir la validación.
- 2.
- Generador 106 de modelos: el generador 106 de modelos es un programa informático que toma como entrada las especificaciones 104 de interfaces de componentes y las especificaciones 102 de diseño de componentes generadas por el generador 100 de especificaciones basadas en secuencias. Éstas están en forma de archivos de datos almacenados por el editor de ASD. A partir de estos archivos de datos, el generador 106 de modelos genera modelos 108 matemáticos con el fin de verificar los diseños e interfaces de componentes y guarda estos modelos como archivos de datos almacenados en un ordenador y disponibles para su introducción en el verificador 110 de modelos.
\newpage
- El generador 106 de modelos implementa los algoritmos genéricos descritos más adelante y automáticamente genera los modelos matemáticos necesarios en una notación adecuada. Una notación matemática de este tipo es el álgebra de procesos existente CSP [Hoa85, Ros98], que es la implementación usada en la presente primera realización. El generador 106 de modelos se describe con más detalle más adelante.
- 3.
- Verificador 110 de modelos: una vez generados los modelos matemáticos del comportamiento del sistema, se analizan para determinar que los componentes de software modelados tienen el comportamiento requerido. Los modelos matemáticos generados por el generador 106 de modelos se introducen en una herramienta de verificación formal existente (no mostrada) apropiada para la notación matemática en la que se generan los modelos. Para modelos expresados en CSP, la herramienta de verificación apropiada es el comprobador de modelos FDR [Ros94, For03]. La primera realización de la presente invención se da a conocer usando esta herramienta de verificación. Este componente se describe con más detalle más adelante.
- El verificador 110 de modelos identifica errores en las especificaciones 104 de interfaces de componente y en las especificaciones 102 de diseño e inconsistencias entre las mismas. Cuando se identifican errores de este tipo, se realimentan a las especificaciones informales y/o a las especificaciones formales resultado del generador 100 de especificaciones basadas en secuencias. Una vez realizadas las correcciones, se generan modelos 108 matemáticos actualizados usando el generador 106 de modelos y se verifican de nuevo usando el verificador 110 de modelos. Este proceso iterativo continúa hasta que se consiga un conjunto libre de errores de especificaciones 72 de interfaces de componentes verificadas y especificaciones 70 de diseño de componentes verificadas. Esto se ilustra en la figura 8 como el bucle 32 de realimentación de defectos de especificación y diseño.
En referencia ahora a la figura 9, se describe
ahora el generador 94 de especificaciones de implementación
verificadas. Produce especificaciones 74 de implementación
verificadas detalladas para aquellas partes de los componentes de
software para las que no puede generarse automáticamente el código
82 fuente de programa necesario y debe programarse a mano.
Comprende el editor 91 de ASD (descrito más adelante), el generador
106 de modelos descrito en detalle más adelante, el verificador 110
de modelos descrito en detalle más adelante y la aplicación de un
procedimiento existente, el procedimiento 112 de desarrollo de
estructura en caja (BSDM) [PTLP98].
Como entradas, el generador 94 de
especificaciones de implementación verificadas toma las
especificaciones 70 de diseño de componentes verificadas producidas
como salida por el generador 90 de especificaciones de caja negra
verificadas y almacenadas en forma de archivos de datos mediante el
editor de ASD.
Las salidas producidas son especificaciones 74
de implementación de componentes verificadas en forma de
especificaciones de función de caja de estado a partir de las que
los desarrolladores de software pueden producir el código de
programa fuente necesario a mano y frente a las que puede validarse
el código de programa fuente mediante las prácticas de inspección
de código convencionales.
Según se describe en la figura 9, el generador
94 de especificaciones de implementación verificadas comprende los
siguientes componentes:
- 1.
- Procedimiento 112 de desarrollo de estructura en caja (BSDM): los expertos en diseño de software usan el editor 91 de ASD para aplicar el procedimiento 112 de desarrollo de estructura en caja a las especificaciones 70 de diseño de componentes verificadas de un componente con el fin de producir especificaciones 114 formales de implementación. Esta salida se captura en forma de un conjunto de tablas de caja de estado que representan conjuntamente una especificación de caja de estado determinística que describe la implementación detallada del componente. Se trata de una especificación matemáticamente completa y consistente a partir de la que los expertos en desarrollo de software pueden producir código fuente de programa a mano. El editor 91 de ASD almacena las especificaciones de implementación generadas en un archivo de datos en una forma que puede introducirse por el generador 106 de modelos.
- Aplicar el BSDM 112 para producir especificaciones de implementación detalladas es una actividad susceptible a errores y una vez realizada, es necesario verificar las especificaciones 114 formales de implementación resultantes frente a las especificaciones 70 de diseño de componentes verificadas con el fin de detectar y eliminar cualquier error que se haya realizado.
- 2.
- Generador 106 de modelos: se trata de un programa informático que toma como entradas las especificaciones 70 de diseño de componentes verificadas y las especificaciones 114 formales de implementación en forma de archivos de datos almacenados por el editor de ASD. A partir de estos archivos de datos, el generador 106 de modelos genera modelos 108 matemáticos con el fin de verificar si las especificaciones 114 formales de implementación cumplen las especificaciones 70 de diseño de componentes verificadas. Estos modelos 108 se almacenan como archivos de datos en el ordenador y están disponibles como entradas para el verificador 110 de modelos. El generador 106 de modelos implementa los algoritmos genéricos presentados a continuación y automáticamente genera los modelos 108 matemáticos necesarios en una notación adecuada. Una notación matemática de este tipo es el álgebra de procesos existente CSP [Hoa85, Ros98], que es la implementación usada en la presente primera realización de la presente invención. Esto se describe en detalle a continuación.
- 3.
- Verificador 110 de modelos: una vez generados los modelos 108 matemáticos de las especificaciones 70 de diseño de componentes verificadas y las especificaciones 114 formales de implementación propuestas, se analizan para determinar que las especificaciones 114 formales de implementación modeladas cumplen todas las propiedades especificadas por la especificación 70 de diseño de componentes verificada. Los modelos 108 matemáticos generados por el generador 106 de modelos se introducen en una herramienta de verificación formal existente apropiada para la notación matemática en la que se generan los modelos 108. Para modelos108 expresados en CSP, la herramienta de verificación apropiada es el comprobador de modelos FDR [Ros94, For03]. La presente primera realización usa esta herramienta de verificación.
- El verificador 110 de modelos se describe en detalle más adelante. El verificador 110 de modelos identifica errores en las especificaciones 74 de implementación de componentes y cualquier inconsistencia entre las especificaciones 74 de implementación de componentes y las especificaciones 70 de diseño de componentes verificadas. Cuando se identifican errores de este tipo, deben realimentarse en la fase de procedimiento 112 de desarrollo de estructura en caja para producir especificaciones 114 formales de implementación actualizadas. Una vez realizadas las correcciones, se generan nuevos modelos 108 matemáticos por el generador 106 de modelos y vuelven a verificarse usando el verificador 110 de modelos. Este proceso iterativo continúa hasta que se producen especificaciones 74 de implementación de componentes verificadas libres de errores. Esto se ilustra en la figura 9 como el bucle 32 de realimentación de defectos de especificación y diseño.
- Con frecuencia sucede que las versiones iniciales de las especificaciones 114 formales de implementación, aunque sean correctas con respecto a las especificaciones 70 de diseño de componentes verificadas, no son inmediatamente adecuadas para su uso por los expertos en desarrollo de software para producir el código fuente de programa a mano. En este caso, las especificaciones 74 de implementación verificadas se transforman y optimizan a mano, usando técnicas matemáticas tales como álgebra booleana y lógica de predicados; esto contrasta con las prácticas de programación convencionales en las que tales optimizaciones detalladas se realizan como parte de la fase de programación.
- En el sistema 62 ASD, tales transformaciones y optimizaciones se realizan en la medida de lo posible sobre las especificaciones 114 formales de implementación por el siguiente motivo: cada vez que las especificaciones 114 formales de implementación se transforman y optimizan manualmente, el generador 106 de modelos se usa para generar modelos 108 matemáticos correspondientes y el verificador 110 de modelos se usa para verificar automáticamente que cumplen con las especificaciones 70 de diseño de componentes verificadas. En cambio, en el enfoque de la técnica anterior convencional descrito en la figura 1, tales transformaciones se harían manualmente durante la fase de programación y no pueden verificarse automáticamente.
El generador 106 de modelos se describe ahora
más detalladamente con referencia a la figuras 10 y 12. La figura
10 ilustra cómo se generan modelos 108 a partir de especificaciones
72 de interfaces de componentes y especificaciones 70 de diseño de
componentes. La figura 12 ilustra cómo se generan modelos 108 a
partir de la especificación 74 de implementación de
componentes.
El generador 106 de modelos es un módulo de
procesamiento que toma como entrada la especificación 104 de
interfaz de componente y las especificaciones 102 de diseño de
componentes generadas por el generador 100 de especificaciones
basadas en secuencias y las especificaciones 74 de implementación de
componentes generadas por el procedimiento 112 de desarrollo de
estructura en caja. Están en forma de archivos de datos almacenados
por el editor 91 de ASD (descrito más adelante). A partir de estos
archivos de datos, el generador 106 de modelos genera modelos 108
matemáticos con el fin de verificar los diseños de componentes,
interfaces e implementación prevista y guarda estos modelos como
archivos de datos almacenados en un ordenador y disponibles para su
introducción en el verificador 110 de modelos.
El generador 106 de modelos implementa los
algoritmos genéricos presentados más adelante y automáticamente
genera los modelos matemáticos necesarios en una notación adecuada.
Una notación matemática de este tipo es el álgebra de procesos
existente CSP [Hoa85, Ros98], que se usa en la presente primera
realización de la presente invención.
El generador 106 de modelos constituye una parte
inventiva importante del sistema 62 ASD al permitir traducir la
salida a partir de la especificación basada en secuencias y el
desarrollo de estructura en caja anteriormente descrito,
directamente en los modelos 108 matemáticos necesarios para las
posteriores etapas de verificación de diseño. Los algoritmos usados
en esta traducción se han demostrado matemáticamente por el presente
inventor que producen modelos 108 matemáticos que describen
exactamente el mismo comportamiento que las especificaciones
basadas en secuencias y las especificaciones de implementación de
componentes a partir de las cuales se traducen. Es este enlace
exclusivo entre técnicas y teorías formales existentes el que
permite que se integren en un entorno de desarrollo de software
industrial y hace posible y práctico que arquitectos y diseñadores
de software verifiquen matemáticamente los diseños de los sistemas
de software a escala industrial sin tener que convertirse en
expertos en las técnicas de verificación matemática empleadas.
\newpage
Para entender completamente las funciones del
generador 106 de modelos y el verificador 110 de modelos, es
necesario y útil considerar los antecedentes de los procedimientos
formales existentes que se usan para implementar el componente
generador 106 de modelos del sistema 62 ASD. La siguiente
descripción representa estos antecedentes.
El procedimiento de desarrollo de estructura en
caja [Mil88, MLH86] proporciona un marco para la aplicación de la
teoría de funciones en el desarrollo de software. Define tres vistas
funcionales de un sistema de software, formando una jerarquía de
abstracción que permite el refinamiento por pasos y la verificación:
una caja negra es una descripción, sin estados, de la vista
externa del sistema; una caja de estado se deriva de la caja
negra e introduce el estado interno; y la vista final es la caja
limpia que es una implementación de la caja de estado en un
lenguaje seleccionado. Cada vista debe ser completa, consistente y
correcta de manera rastreable. A continuación, se proporcionan los
antecedentes necesarios acerca de las cajas negras y las cajas de
estado para entender y dar a conocer completamente el sistema 62
ASD.
Una especificación de caja negra es la vista más
abstracta y define el comportamiento externo de un sistema o
componente en términos de estímulos de entrada desde y respuestas de
salida observables hacia su entorno; S y R indican el conjunto de
estímulos y respuestas respectivamente. Una caja negra se
caracteriza por una función de caja negra BB:
S^{\text{*}}\rightarrowR que correlaciona el historial de
estímulos con respuestas, donde S^{\text{*}} es el conjunto de
todas las secuencias finitas respecto a S.
Una función de caja negra debe ser absoluta:
cada secuencia de estímulos se correlaciona con una respuesta. En la
práctica, puede haber un estímulo que no invoque una respuesta; por
motivos de exhaustividad, una respuesta especial cero se añade al
conjunto R para tratar este caso.
Por ejemplo, en el estado inicial de un sistema
antes de cualquier entrada de estímulo, ninguna respuesta puede
suceder (espontáneamente) por lo que BB (\langle\rangle) = cero.
Deben incluirse secuencias de estímulos ilegales y correlacionarse
con el valor especial \omega\inR. Las secuencias ilegales son
cerradas en extensión: todas las extensiones de secuencias ilegales
también son ilegales y dan como resultado la respuesta w.
La caja negra se desarrolla a partir de los
requisitos informales y se requiere que sea completa, consistente y
correcta de manera rastreable con respecto a los mismos. En [PP03],
se presenta un procedimiento de especificación de software
basada en secuencias para definir de manera sistemática una
especificación de caja negra que garantiza la exhaustividad y
consistencia, así como mantener una trazabilidad completa con los
requisitos informales originales.
El procedimiento de especificación basado en
secuencias implica la enumeración ordenada de todas las posibles
secuencias de estímulos en S^{\text{\text{*}}} por orden de
longitud, empezando con la secuencia vacía (es decir, de longitud
0), y la asignación de una respuesta de R a cada una. Para cada
longitud, la ordenación debe ser completa. Durante esta enumeración,
pueden surgir equivalencias entre secuencias: dos secuencias
u,v\inS^{\text{\text{*}}} son equivalentes Mealy, escrito
u\equiv_{\rho Me}v, precisamente cuando todas las extensiones no
vacías de las mismas dan como resultado la misma respuesta; es
decir, para todas
Cuando surge una equivalencia entre una
secuencia u y una previamente enumerada v, se indica la respuesta
asociada con u, junto con su equivalencia con v. El conjunto
S^{\text{\text{*}}} se divide en un conjunto finito de clases de
equivalencia según se define por _{\rho Me} donde, para cada
secuencia u\inS^{\text{*}}, hay una forma v única normal
irreducible de manera que u\in[v]_{\rho Me}. Estas
formas normales únicas para el sistema de reducción definido por
_{\rho Me} se conocen como secuencias canónicas.
El formato presentado en [PTLP98] se usa a lo
largo de este documento, en el que la enumeración de secuencias se
presenta como un conjunto de tablas de enumeración: una para cada
secuencia canónica. Por ejemplo, una tabla de enumeración para
alguna secuencia canónica c_{j} adopta la forma:
donde {s_{1}, s_{2}} = S
(puesto que cada extensión debe ser completa), r_{1},
r_{2}\inR y c_{j} es una secuencia canónica existente
(identificada anteriormente en la ordenación). Sólo se usan
secuencias no reducidas en las equivalencias. La primera fila de la
tabla reza lo
siguiente:
y esta etapa puede rastrearse de
vuelta al requisito R_{1} en la especificación informal de
requisitos. Debido a la equivalencia establecida, no tienen que
considerarse extensiones adicionales de esta
secuencia.
En la tabla anterior, extender secuencias en
[c_{i}]_{\rho Me} con s_{2} invoca la respuesta r_{2}
y no son reducibles a una secuencia previamente enumerada. Por
tanto, c_{i}^{\cap}\langleS_{2}\rangle es una nueva
secuencia canónica, para la que debe definirse una tabla de
enumeración.
El proceso de enumeración se completa una vez
que todas las secuencias se han asignado a una equivalencia; clase:
una enumeración completa especifica exactamente un valor para cada
secuencia z\inS^{\text{*}}, y por lo tanto define una
especificación de caja negra completa y consistente [PP03].
Una especificación de caja de estado es la
siguiente etapa hacia la implementación y se deriva de una
especificación de caja negra. Introduce variables de estado para
capturar características distintivas del historial de estímulos, de
manera que el comportamiento externo sea equivalente al especificado
por la caja negra (sin necesidad de hacer referencia al historial
de estímulos). Se caracteriza por una función de caja de estado
absoluta SB: (Q X S) \rightarrow (Q X R), donde Q, S y R son los
conjuntos de estados, estímulos y respuestas respectivamente.
Los estados en Q representan predicados
característicos, un estado distinto para cada clase de equivalencia,
sobre la partición de S^{\text{\text{*}}}. Definir variables de
estado y sus instanciaciones únicas para cada clase de equivalencia
se consigue a través de un proceso denominado el análisis de la
secuencia canónica y se describe en [PTLP98].
Una caja negra y una caja de estado con
funciones BB:S^{\text{*}}\rightarrowR y SB: (Q X
S)\rightarrow(Q X R) respectivamente son
equivalentes en comportamiento precisamente cuando, para cada
secuencia en S^{\text{*}}, invocan la misma respuesta.
La especificación de caja de estado se
representa como un conjunto de tablas, una para cada estímulo
s\inS de la forma:
donde q_{1}, q_{2}\inQ y
r_{1}, r_{2}\inR. En una especificación de caja de estado
completa y consistente, a partir de cada tabla, para un estímulo
S\inS, debe poder determinarse la respuesta única en cualquier
estado dado del sistema. Por tanto, la columna de estado actual debe
abarcar todos los
estados.
CSP [Hoa85, Ros98] es un álgebra de procesos
para describir procesos concurrentes que interaccionan entre sí o
con su entorno a través de alguna forma de comunicación. CSP tiene
un lenguaje expresivo rico y una colección de modelos semánticos
para razonar acerca del comportamiento de los procesos.
Un proceso se define en términos de
comunicaciones atómicas sincrónicas, conocidas como eventos,
que puede realizar con su entorno. Por ejemplo, el proceso
a\rightarrowP puede realizar inicialmente el evento a y después
actuar como el proceso P. La notación ? x:A\rightarrowP(x)
(constructo de elección de prefijo) indica un proceso que desea
realizar cualquier evento en A y después comportarse como el proceso
P(x).
Los canales llevan conjuntos de eventos; por
ejemplo, c.5 es un evento de canal c. El proceso
c?x\rightarrowP_{x} introduce un valor x del canal c y después
actúa como P_{x}. El proceso d.x\rightarrowQ realiza el evento
d.v, donde v es el valor asignado a x, y después actúa como el
proceso Q.
\newpage
En CSP, hay dos tipos de operadores de elección:
P \boxempty Q indica una elección externa entre P y Q; los eventos
iniciales de ambos procesos se ofrecen al entorno; cuando se realiza
un evento, se resuelve la elección. P\PiQ indica una elección
interna entre P y Q; el proceso puede actuar como P o como Q,
realizándose la elección según algún criterio interno (y por tanto,
el entorno no tiene control sobre cómo se resuelve la elección).
Como un ejemplo, considérese una sencilla
máquina dispensadora de bebidas que ofrece una elección de menú de
dispensación de té y café, la elección de cuál de ellas la realiza
el entorno. Esto podría modelarse mediante el siguiente proceso
CSP:
La elección (en el estado inicial del proceso
MáquinaDispensadora) entre té y café se modela como una externa,
reflejando el hecho de que la máquina dispensadora está preparada
para ofrecer cualquiera de las bebidas, la decisión sobre cuál de
ellas la realiza el entorno (es decir, el usuario de la máquina
dispensadora). Una vez resuelta la elección, el proceso dispensa la
bebida seleccionada, modelado por los eventos dispensar.té y
dispensar.café respectivamente.
Como un segundo ejemplo, considérese la
siguiente extensión del modelo de máquina dispensadora presentado
anteriormente: una vez que el entorno (es decir, el usuario) ha
seleccionado la bebida que va a dispensarse, la máquina
dispensadora o bien dispensa la bebida elegida (como en el caso
anterior) o bien visualiza un mensaje de error indicando que no hay
ingredientes suficientes para la bebida elegida. La elección de qué
respuesta realiza la máquina dispensadora se realiza internamente
dentro de la máquina dispensadora y por tanto se modela como una
elección interna dentro del modelo CSP como sigue:
Los procesos pueden ponerse en paralelo,
sincronizándose en caso de (todos o especificados) eventos comunes
o intercalándose, cuando se ejecutan de manera independiente entre
sí. Por ejemplo, si dos procesos en un sistema de software se
comunican entre sí mediante intercambio de mensajes, cada proceso se
modelará de manera individual en CSP y los dos modelos se pondrán
en paralelo, sincronizándose sobre un conjunto de eventos
correspondiente al conjunto de mensajes que están
intercambiándose.
\vskip1.000000\baselineskip
El punto de partida para especificar un
componente usando el procedimiento de desarrollo de estructura en
caja es construir una especificación de caja negra que describa el
comportamiento externo requerido del componente, usando el
procedimiento de especificación basada en secuencias.
El algoritmo 1 presentado a continuación es una
implementación de cómo puede traducirse un conjunto de tablas de
enumeración basadas en secuencias que codifican una especificación
de caja negra en un correspondiente proceso CSP. Por motivos de
claridad, una tabla de enumeración para alguna secuencia canónica c
se representa como el conjunto Filas_{BB} (c) que comprende un
elemento por cada fila de la tabla y que adopta la forma (s, r,
c_{j}), donde s, r y c_{j} representan las columnas de estímulo,
respuesta y equivalencia respectivamente. La figura 14 ilustra un
ejemplo de una tabla de enumeración para alguna secuencia canónica c
y su correspondiente conjunto Filas_{BB} (c). Con el fin de
generar el modelo CSP, la primera columna que contiene el número de
secuencias único de la fila y la cuarta columna que captura la
trazabilidad con requisitos informales se ignoran, ya que no son
relevantes en el análisis CSP del sistema.
\newpage
Algoritmo 1: para una especificación basada en
secuencias dada, que codifica una especificación de caja negra con
función BB: S^{\text{*}}\rightarrowR, se define un proceso CSP
correspondiente P_{BB} como sigue:
- 1.
- La especificación basada en secuencias comprende un conjunto de tablas de enumeración, una por cada secuencia canónica. Para cada secuencia canónica c_{i} en la enumeración, se define un proceso CSP P_{ci} como sigue:
- donde
- Esto produce una colección de procesos CSP mutuamente recursivos P_{c0},..., P_{cn}, un proceso P_{ci} para cada secuencia canónica c_{i} en la enumeración.
- 2.
- El proceso CSP P_{BB} se define entonces como sigue:
donde c_{0} representa la
secuencia canónica más corta que, por definición, es
\langle\rangle.
La figura 15 ilustra la aplicación del algoritmo
1 para traducir una tabla de enumeración en un proceso CSP
correspondiente. Muestra el CSP correspondiente a cada fila en la
tabla y cómo se combina en una ecuación de proceso CSP que
representa el comportamiento de la tabla de enumeración en su
conjunto.
El algoritmo 1 anterior no concierne al caso en
el que los estímulos se definen usando predicados. Una
característica importante del enfoque de enumeración basado en
secuencias para un uso práctico es la posibilidad de abstraer
detalles introduciendo predicados que posibilitan distinguir las
respuestas resultantes y el futuro comportamiento de un único
estímulo de entrada. Por ejemplo, lo siguiente ilustra cómo puede
dividirse un único estímulo s en dos estímulos abstractos usando
predicados dentro de una tabla de enumeración:
donde, s\inS es por tanto un
estímulo de entrada, p es un predicado, r_{1} \neq r_{2} y
C_{i} \neq C_{j} (es decir, las respuestas resultantes y los
comportamientos futuros son distintos, y dependen del valor del
predicado
p).
Además, los predicados se definen normalmente en
términos de funciones de especificación que, a su vez, se definen
sobre el historial de secuencia de estímulos. Por ejemplo, el
predicado p puede determinar si hay o no suficientes recursos para
permitir que tenga lugar el estímulo s. En este caso, p puede
definirse como sigue:
donde Recurso(h) es una
función de especificación sobre el historial de secuencias h. Dada
h, Recurso devuelve el conjunto de recursos que están disponibles.
Si este conjunto es no vacío, entonces p evalúa verdadero, si no p
es falso. Un estímulo s cuya respuesta dependa de este predicado
(por ejemplo, té), se modela entonces mediante los estímulos
abstractos especiales s:p y s:\textlnotp. Por ejemplo, la tabla
anterior puede convertirse
en:
El algoritmo 2 a continuación extiende el
algoritmo 1 para tratar tablas de enumeración que contienen
estímulos que se definen en términos de predicados que implican
funciones de especificación sobre historial de estímulos, y los
traduce en los correspondientes modelos CSP. Esto se consigue
modelando el historial de estímulos como variables de estado; en
lugar de remitiendo al historial de secuencias, las funciones de
especificación se calculan en términos de los datos de estado
correspondientes dentro de los modelos CSP. Las variables de estado
deben definirse por tanto para reflejar de manera precisa las
funciones de especificación y el historial.
Algoritmo 2: dado un conjunto de tablas de
enumeración basadas en secuencias que capturan una función de caja
negra BB:S^{\text{*}}\rightarrowR, se define un proceso CSP
correspondiente P_{BB} como sigue:
- 1.
- Para cada función de especificación usada por predicados que definen estímulos de entrada, definir variables de estado apropiadas. Por ejemplo, la función de especificación Recurso(h ) para un historial h dado definido anteriormente podría capturarse por la variable Res que representa un conjunto de Recursos disponibles en cualquier estado dado.
- 2.
- Para cada secuencia canónica c_{i}, expresar las funciones de especificación en términos de sus variables correspondientes y, para cada estímulo, calcular todos los posibles valores anteriores y posteriores asignados a cada variable. Esta representación debe ser de tal manera que, dado cualquier estado del sistema y un estímulo, pueden determinarse los valores precisos que han de asignarse a todas las variables de estado. Una posible implementación es capturar esto en forma tabular.
- 3.
- Sean x_{1},..., x_{k} las variables de estado que capturan las correspondientes funciones de especificación derivadas en la etapa anterior. Para cada secuencia canónica c_{i}, se define un proceso CSP P_{ci}(x_{1},..., x_{k}) como sigue:
\hskip1cm13
- donde la función actualizar devuelve el valor resultante para cada variable de estado. Estos valores se derivan directamente de las tablas construidas en la etapa anterior. El proceso Q se define como sigue:
- si s=s':p, para algún s'\inS y el predicado p, si no.
- donde la función estado(p) representa el predicado p en términos de las correspondientes variables de estado en oposición a las funciones de especificación. Por ejemplo, si p se definió previamente como:
- y la función de especificación Recurso(h) se define en términos de la variable de estado Res según se describe en la etapa anterior del algoritmo, entonces el estado (p) puede definirse como sigue:
- El proceso Q (s, r, c_{j}, (y_{1},..., y_{k})) se define en términos de los siguientes dos casos:
- Caso 1 (Predicados): El estímulo s se define en términos de un predicado y por tanto adopta la forma s=s':p. El proceso CSP resultante captura el predicado como un estado de guardia (p), definido en términos de las variables de estado, sobre la secuencia estándar del evento de estímulo s' seguida por el evento de respuesta r y que lleva al proceso P_{ci}.
- Caso 2 (No predicados): El estímulo s no implica predicados y por tanto da como resultado la definición CSP estándar como se define en el algoritmo 1.
- 4.
- El proceso CSP P_{BB} se define entonces como sigue:
- donde c_{0} representa la secuencia canónica más corta \langle\rangle y I_{1},..., I_{k} son los valores iniciales de cada variable de estado respectivamente. Estos valores iniciales se derivan directamente de las definiciones de las funciones de especificación.
Pueden usarse funciones de predicado en
especificaciones basadas en secuencias para la infraespecificación
[PP03] (sin romper la teoría de funciones sobre la que se construye
este enfoque). Esta forma de abstracción se usa para diseñar
interfaces de componentes, en las que las acciones internas se
ocultan de su entorno. La infraespecificación se consigue
introduciendo predicados indefinidos para capturar el hecho de que
para un estímulo s dado, hay un número de posibles respuestas y un
comportamiento posterior, la decisión de cuál de ellas todavía es
indefinida. El estímulo s se modela entonces como los estímulos
abstractos s:p y s:\textlnotp donde p es indefinido.
El algoritmo 3 a continuación extiende el
algoritmo 2 y presenta una implementación de cómo pueden traducirse
tales especificaciones basadas en secuencias en modelos CSP
correspondientes.
Algoritmo 3: dado un conjunto de tablas de
enumeración basadas en secuencias que capturan una función de caja
negra BB:S^{\text{*}}\rightarrowR, se define un proceso CSP
correspondiente P_{BB} como sigue:
- 1.
- Sea U el conjunto de todos los predicados indefinidos {p_{1},..., p_{n}}.
- 2.
- (Igual que en la etapa 1 en el algoritmo 2) Para cada función de especificación usada por predicados que definen estímulos de entrada, definir variables de estado apropiadas.
- 3.
- (Igual que en la etapa 2 en el algoritmo 2) Para cada secuencia canónica c_{i}, expresar las funciones de especificación en términos de sus correspondientes variables y, para cada estímulo, calcular todos los posibles valores anteriores y posteriores asignados a cada variable. Según se describe en el algoritmo 2, una posible implementación de esto sería una forma tabular.
- 4.
- Sean x_{1},..., x_{k} las variables de estado que capturan las correspondientes funciones de especificación derivadas en la etapa anterior. Para cada secuencia canónica c_{i}, se define un proceso CSP P_{ci}(x_{1},..., x_{k}) como sigue:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
- donde la función actualizar devuelve el valor resultante para cada variable de estado. Estos valores se derivan directamente de las tablas construidas en la etapa anterior. El proceso Q se define como sigue:
\vskip1.000000\baselineskip
\hskip1cm19
- donde la función estado(p) representa el predicado p en términos de las correspondientes variables de estado (como se define en la etapa 3 del algoritmo 2). El proceso Q (s, r, c_{j}, (y_{1},...,y_{k})) se define en términos de los siguientes tres casos:
- Caso 1 (Predicados definidos): El estímulo s es un estímulo abstracto en la forma s=s':p, donde s' es algún estímulo en S y p es un predicado definido (es decir p\notinU). El proceso CSP resultante se define según la etapa 3 (Caso 1) del algoritmo 2.
- Caso 2 (Predicados indefinidos): El estímulo s es un estímulo abstracto en la forma s=s':p, donde s' es algún estímulo en S y p es un predicado indefinido (es decir, p\inU). El proceso CSP resultante captura este elemento indefinido ignorándolo (en oposición a construir una guardia) y extrayendo simplemente el estímulo s' como el evento inicial ofrecido seguido por el correspondiente evento de respuesta r.
- Caso 3 (Ausencia de predicados): El estímulo s no implica predicados y por tanto da como resultado la definición de CSP estándar según se define en el Algoritmo 1.
- 5.
- (Igual que en la etapa 4 en el algoritmo 2) El proceso CSP P_{BB} se define entonces como sigue:
- donde c_{0} representa la secuencia canónica más corta \langle\rangle y I_{1},..., I_{k} son los valores iniciales de cada variable de estado respectivamente. Estos valores iniciales se derivan directamente de las definiciones de las funciones de especificación.
La especificación de caja de estado es la
siguiente etapa hacia la implementación en el procedimiento de
desarrollo de estructura en caja y se deriva de la especificación
de caja negra. Captura el historial de estímulos como datos de
estado, de manera que el comportamiento externo sigue siendo igual a
como se ha definido en la especificación de caja negra. Una caja de
estado de un componente dado (o sistema) define una función de caja
de estado SB desde un estado y estímulo antiguo a un
correspondiente estado y respuesta nuevo (SB: (Q X
S)\rightarrow(Q X R), donde Q es el conjunto de
posibles estados, S es el conjunto de estímulos y R es el conjunto
de respuestas). Una vez introducidos tales datos de estado, ya no
es necesario hacer referencia al historial de estímulos (como era
el caso para las especificaciones de caja negra).
Hay una caja de estado definida para cada
estímulo s\inS en la forma:
El algoritmo 4 a continuación presenta una
posible implementación para traducir especificaciones de caja de
estado en correspondientes modelos CSP. Por motivos de claridad (y
como se ha hecho para el algoritmo 1), la información presentada en
una caja de estado para un estímulo s\inS se captura como el
conjunto Filas_{SB}(s), comprendiendo un elemento por cada
fila de la tabla de caja de estado: para un estímulo s\inS dado,
el conjunto Filas_{SB}(s) se define como un conjunto de
tríos que contienen un trío (q, r, q') para cada fila en la tabla
de caja de estado para s, donde q es el estado actual, r es la
respuesta y q' es el nuevo estado. Por ejemplo, considérese la
siguiente tabla de caja de estado para algún estímulo s:
Entonces Filas_{SB}(s) se definiría
como el siguiente conjunto:
La figura 16 ilustra un ejemplo de una tabla de
caja de estado para algún estímulo s y su correspondiente conjunto
Filas_{SB}(s).
\newpage
Algoritmo 4: dada una especificación de caja de
estado para alguna función de caja de estado SB: (Q X S)
\rightarrow(Q X R), se define un proceso CSP
correspondiente P_{SB} como sigue:
- 1.
- Sean x_{1},..., x_{k} las variables de estado según se definen por la especificación de caja de estado.
- 2.
- El proceso P_{SB} se define como sigue:
- donde inic_{1},..., inic_{k} son los valores iniciales de las variables de estado. Estos valores iniciales se derivan directamente de las definiciones de las correspondientes funciones de especificación.
- 3.
- El proceso P_{SB}' se define como sigue:
- Hay un Q(s) por cada caja de estado para el estímulo s.
- 4.
- Para cada estímulo s\inS, Q(s) se define como sigue:
- donde
- Para un estímulo s, hay un proceso Q' (q, s, r, q') para cada fila en su caja de estado. El valor de q refleja la condición previa para la cual s invoca la respuesta r y el estado actualizar q', y se modela como una guardia booleana en CSP.
La figura 17 ilustra un ejemplo de la aplicación
del algoritmo 4 a un par de tablas de caja de estado, habiendo una
tabla para cada estímulo s_{1} y s_{2}. El diagrama ilustra las
ecuaciones CSP correspondientes a cada tabla de caja de estado y
cómo se combinan para formar el modelo CSP para la caja de estado
completa.
Una vez descritos los antecedentes para entender
cómo funciona el generador 106 de modelos, se describe ahora el
verificador 110 de modelos con más detalle con referencia a las
figuras 11 y 13. El verificador 110 de modelos comprende un módulo
120 de procesamiento que introduce modelos 116, 118 matemáticos de
las especificaciones formales de diseño, las especificaciones
formales de interfaces y las especificaciones formales de
implementación según se han generado y almacenado (no mostrado) en
archivos de datos por el generador 106 de modelos y los verifica en
cuanto a su corrección.
Se realizan las siguientes verificaciones de
corrección estándar:
- 1.
- Los modelos 118 de las especificaciones formales de interfaces de componentes se verifican para garantizar que están libres de bloqueos y divergencias y cumplen con cualquier ley de control derivada de las especificaciones 66 de requisitos verificadas.
- 2.
- Los modelos 116 de cada uno de los diseños formales de componentes se verifican junto con los modelos 118 de sus respectivas interfaces de componentes, los modelos 108 de todas las demás interfaces de componentes que usan y los modelos de cualquier ley de control derivada de las especificaciones 66 de requisitos verificadas. Esto es para garantizar que, para cada componente, (i) el diseño de componentes implementa todo el comportamiento y sólo el comportamiento especificado por las especificaciones de interfaces de los componentes; (ii) todos los demás componentes usados por el diseño de componentes que están verificándose se usan según sus respectivas especificaciones de interfaces de componentes y que no se realizan acciones definidas como ilegales por esas especificaciones de interfaces; (iii) los diseños de componentes preservan cualquier ley de control derivada de las especificaciones 66 de requisitos verificadas; (iv) el diseño de componentes está libre de falta de determinismo, bloqueos y divergencias cuando interacciona con todos los demás componentes con los que está interconectado e interacciona. Esta verificación se lleva a cabo por el módulo 120 de procesamiento del verificador 110 de modelos como se ilustra en la figura 11.
- 3.
- Para aquellas partes del software que deben programarse a mano y para las que se requieren especificaciones de implementación detalladas, se verifican modelos 108 de los diseños (en forma de especificaciones de caja negra) y modelos 108 de las especificaciones de implementación detalladas (en forma de especificaciones de caja de estado) para garantizar que son exactamente equivalentes y que las especificaciones de implementación detalladas están por tanto libres de errores. Esta verificación se lleva a cabo por el módulo 120 de procesamiento del verificador 110 de modelos como se ilustra en la figura 13.
Las verificaciones de corrección descritas
anteriormente y en las siguientes secciones no son una lista
exhaustiva; son representativas de verificaciones de corrección que
normalmente se requerirán en la mayoría de los casos. La presente
realización se describe basándose en cualquier verificación de
corrección que puede expresarse en el álgebra de procesos elegida y
su verificador 110 de modelos asociado puede formularse y aplicarse
según sea necesario, como resultará evidente para el destinatario
experto.
En general, las verificaciones son un proceso
iterativo. Los modelos 108 se generan por el generador 106 de
modelos, el verificador 110 de modelos descubre errores en las
interfaces y diseños que están modelándose y verificándose y se
ponen a disposición de los expertos en diseño de software. Estos
corrigen entonces esas interfaces y diseños, y el sistema genera
entonces nuevos modelos e intenta volver a verificarlos.
En cada fase del procedimiento 112 de desarrollo
de estructura en caja para un diseño de componente, una vez
modelada la especificación en CSP, pueden formularse propiedades
tales como exhaustividad, determinismo y cumplimiento de leyes de
control especificadas en los requisitos del sistema (por ejemplo,
verificando que la máquina dispensadora nunca dispense bebidas sin
pago) en CSP y verificarse automáticamente en FDR.
En el caso de las cajas de estado, al definir
los predicados de características como datos de estado, es
importante garantizar que dividen correctamente S^{\text{*}}: no
deben solaparse y deben ser completos. En la práctica, a menudo se
introducen errores durante esta fase. Ambas propiedades se
comprueban fácilmente en FDR. La primera de ellas se captura
comprobando la ausencia de determinismo; si hay predicados que se
solapan, entonces habrá un estado en el que, para un estímulo s
dado, al menos dos guardias evalúan verdadero, llevando a una
elección no determinística en cuanto a cuál de ellas se realiza.
Para garantizar que los predicados de estado que se solapan siempre
dan como resulto ausencia de determinismo, el modelo CSP se extiende
introduciendo eventos únicos inmediatamente después de cada evento
de estímulo. Por ejemplo,
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
donde x es el predicado de estado
(que se solapa) derivado en la caja de estado, s es un estímulo,
r_{1} y r_{2} son respuestas, g y f modelos de las
actualizaciones de estado, y e_{1} y e_{2} son los eventos
únicos insertados en el modelo. La ausencia de determinismo se
introduce claramente cuando x = verdadero. Sin los eventos
adicionales, los predicados que se solapan no llevan necesariamente
a ausencia de determinismo; en el ejemplo anterior, si r_{1} =
r_{2} y f(x) = g(x), entonces no se introduce
ausencia de determinismo. El generador 106 de modelos genera el
modelo 108 CSP con estos eventos adicionales insertados para
permitir comprobar esta propiedad. Una vez comprobada, los modelos
108 se generan sin estos eventos adicionales para el análisis
posterior.
Cada etapa en el procedimiento 112 de desarrollo
de estructura en caja se verifica. En cuanto a cajas negras y cajas
de estado, es importante verificar que son equivalentes en
comportamiento. Cuando en la técnica anterior se usa el
procedimiento BSDM por sí mismo en un proceso de diseño de software
sin usar el sistema ASD de la presente realización, tal
verificación se realiza derivando el comportamiento de caja negra de
la caja de estado y comprobando si es equivalente a la
especificación de caja negra original. Esto lleva tiempo, es
susceptible a errores y económicamente inviable en la práctica. Los
algoritmos presentados anteriormente (algoritmos 1 a 4) permiten
traducir ambas especificaciones en correspondientes modelos CSP
respectivamente y realizar las comprobaciones de verificación
necesarias automáticamente en FDR.
La equivalencia de comportamiento entre una
especificación basada en secuencias y una especificación de caja de
estado puede formularse en términos de las trazas de los
correspondientes procesos CSP: Una especificación determinística
basada en secuencias Espec_{BB} y una especificación
determinística de caja de estado Espec_{SB} son equivalentes en
comportamiento precisamente cuando sus respectivos modelos CSP
P_{BB} y P_{SB} son equivalentes en trazas, escrito como P_{BB
\equiv T} P_{SB}. Esto se comprueba automáticamente usando FDR.
Si la comprobación fracasa, entonces FDR produce contraejemplos.
El procedimiento 112 de desarrollo de estructura
en caja se centra en componentes en el desarrollo de diseños;
aborda los diseños de componentes individuales sin tener en cuenta
el comportamiento del sistema en su conjunto comprendido por sus
numerosos componentes. Una vez traducidas en CSP, las interacciones
entre componentes y el comportamiento del sistema pueden analizarse
en su conjunto, analizando su composición paralela y comprobando
que cumplen la especificación del sistema. Propiedades tales como
evitación de bloqueos y cumplimiento de leyes de control
especificadas por los requisitos se formulan en CSP y se verifican
automáticamente en FDR. La propiedad de capacidad de composición de
CSP proporciona la escalabilidad para un desarrollo de este tipo en
la práctica.
Verificar si un diseño de componente implementa
por completo exactamente el comportamiento especificado en sus
especificaciones 104 de interfaces, supone verificar que el modelo
108 CSP de una especificación basada en secuencias de un diseño es
un refinamiento en el modelo de fallos del modelo 108 CSP de una
especificación basada en secuencias de una interfaz. Esta
verificación se realiza automáticamente por FDR para
especificaciones de interfaces sin divergencia no determinísticas y
diseños de componentes determinísticos.
Como se ha mencionado anteriormente, el editor
91 de ASD es el módulo de procesamiento usado por los arquitectos y
expertos en diseño de software. Ahora se describe con más detalle a
continuación. El editor 91 de ASD proporciona funcionalidad para dar
soporte a estos usuarios en las siguientes actividades:
1. Realizar la especificación 104 formal de
interfaz de una interfaz de componente usando el generador 100 de
especificaciones basadas en secuencias para definir el
comportamiento de la interfaz como una función de caja negra
infraespecificada;
2. Realizar la especificación 102 formal de
diseño de un componente usando el generador 100 de especificaciones
basadas en secuencias para definir el comportamiento del componente
como una función de caja negra totalmente especificada.
3. Realizar la especificación 114 formal de
implementación de cada parte del componente para la que el código
82 fuente de programa no puede generarse automáticamente por el
generador 92 de código, sino que en lugar de ello debe programarse
a mano. La especificación 114 formal de implementación se realiza
aplicando el procedimiento 112 de desarrollo de estructura en caja
para especificar el diseño requerido en forma de una caja de
estado.
4. Anotar la especificación 102 formal de diseño
con la información adicional necesaria por el generador 96 de casos
de prueba para permitirle generar casos 78 de prueba que se ponderan
por la probabilidad de que se produzcan secuencias de estímulos
particulares. Tal especificación 102 formal de diseño anotada se
denominada un modelo de uso.
5. Producir salidas impresas en copia física de
las especificaciones de caja negra y los modelos de uso en forma
tabular y trazarlos como gráficos 79 directos que representan el
comportamiento de máquina de estados de interfaces y diseños de
componentes. Estas salidas 79 representan un medio mediante el que
los usuarios pueden validar mediante inspección manual si las
especificaciones de caja negra reflejan o no las especificaciones
14, 18, 22 informales a partir de las cuales se derivan. Además,
también se producen salidas 79 impresas de las especificaciones de
caja de estado en forma tabular. Las funciones del editor 91 de ASD
se proporcionan a sus usuarios a través de un conjunto de
interfaces de usuario, habiendo un conjunto para cada una de las
áreas principales de funcionalidad anteriormente descritas. Las
interfaces de usuario se describen a continuación con referencia a
la figuras 18 a 21 que muestran los cuatro tipos principales de
interfaz de usuario.
Todas las especificaciones producidas mediante
el editor 91 de ASD se almacenan en la base de datos (véase la
figura 7) del sistema 62 ASD en una forma en la que puede
reutilizarse y modificarse usando el editor 91 de ASD y se
introducen en otras partes del sistema 62 ASD. La realización de la
presente invención se da a conocer siendo el almacenamiento en
forma de archivos 93 de datos. También está previsto que puedan
usarse otras formas de almacenamiento informático tales como bases
de datos relacionales.
El editor 91 de ASD proporciona un conjunto de
interfaces de usuario para todas las funciones que proporciona. La
presente realización incorpora las interfaces de usuario descritas a
continuación; aunque ha de apreciarse que son posibles otras
variaciones e interfaces de usuario.
Al especificar una interfaz de componente usando
el procedimiento especificaciones basadas en secuencias para
producir una especificación formal de interfaz en forma de una caja
negra infraespecificada, se presentan las siguientes pantallas al
usuario:
- 1.
- La pantalla 138 de interfaz como se muestra en la figura 18, que contiene la siguiente información:
- a)
- El nombre de la interfaz;
- b)
- Un prefijo con el que el generador 106 de modelos identifica de manera unívoca cada estímulo y la respuesta perteneciente a esta interfaz;
- c)
- Una lista de todos los estímulos de entrada que pueden enviarse a la interfaz, especificando para cada uno un nombre corto abreviado, una breve descripción, un código que describe cómo han de trazarse las transiciones provocadas por el estímulo (color de línea, estilo, etc.) y el nombre de procedimiento que ha de usarse por el generador de código para el procedimiento que ha de llamarse cuando se recibe el estímulo;
- d)
- Una lista de respuestas que pueden emitirse por la interfaz 138, especificando para cada una un nombre abreviado, una breve descripción y el nombre de procedimiento que ha de usarse por el generador 92 de código al generar un código fuente de programas del correspondiente procedimiento de respuesta.
Esta interfaz se describe más detalladamente a
modo de un ejemplo que se describe más adelante con referencia a la
figura 18.
- 2.
- La pantalla 160 de enumeración de secuencias como se muestra en la figura 19: contiene todas las tablas de enumeración, habiendo una tabla por cada clase de equivalencia de secuencias de estímulos de entrada, resultado del procedimiento de especificaciones basadas en secuencias. Conjuntamente, estas tablas definen la función de caja negra total que especifica el comportamiento de un componente tal como es visible en la interfaz. Cada tabla consiste en:
- a)
- Una fila de cabecera que identifica la secuencia canónica de la clase de equivalencia;
- b)
- Una colección de filas, habiendo una o más filas por cada estímulo de entrada.
- Los estímulos de entrada se listan en las colecciones de filas en cada tabla en el mismo orden. En la mayoría de los casos, hay exactamente una fila para cada estímulo de entrada. Habrá más de una fila para un estímulo dado si hay más de un resultado posible (es decir, elección de respuesta y/o comportamiento de sistema futuro) que puede ser resultado del estímulo. En tal caso, hay una fila por cada resultado posible y cada fila se anota mediante un predicado que representa uno de los posibles casos. Los predicados se expresarán en términos de expresiones que implican funciones recursivas de prefijo sobre las secuencias de entrada y debe abarcarse cada caso. Si la elección entre resultados es determinística y conocida, las funciones recursivas de prefijo deben estar totalmente especificadas y definidas; si la elección no es determinística al nivel de abstracción al que se expresa la interfaz (es decir, depende de eventos ocultos por la implementación), entonces las funciones recursivas de prefijo se identifican pero todavía no se especifican. La función de caja negra sigue siendo infraespecificada. Dentro de cada tabla, cada fila en la colección de filas tiene las siguientes columnas definidas que contienen la siguiente información:
- a)
- Número de secuencia de fila - todas las filas en todas las tablas se numeran secuencialmente con una única secuencia de numeración con el fin referenciarlas;
- b)
- Estímulo - el nombre abreviado del estímulo de entrada;
- c)
- Predicado - un predicado según se ha descrito anteriormente. El predicado puede estar presente o no en cada fila;
- d)
- Respuesta - el nombre abreviado de la respuesta emitida por la interfaz;
- e)
- Clase de equivalencia - la identificación de la clase de equivalencia correspondiente al futuro comportamiento del sistema tras este estímulo;
- f)
- Un comentario explicando y justificando la respuesta y el futuro comportamiento del sistema;
- g)
- Etiquetas de requisitos - referencias a requisitos etiquetados en la especificación informal de requisitos que justifican el resultado tras el estímulo.
Esta interfaz se describe más detalladamente a
modo de un ejemplo que se describe más adelante con referencia a la
figura 19.
- 3.
- La pantalla de especificación de función (no mostrada): una especificación de todas las funciones recursivas de prefijo usadas por los predicados. Para aquellas funciones que no pueden especificarse en términos de estímulos de entrada visibles a este nivel de abstracción, las funciones se identifican y se especifican los posibles valores de función sin especificar las ecuaciones recursivas de prefijo que definen el valor de función.
- 4.
- La pantalla 180 de requisitos derivados como se muestra en la figura 20 comprende una lista etiquetada de requisitos 182 que faltan o son incorrectos en las especificaciones informales de requisitos. Durante la especificación basada en secuencias, es habitual que deban hacerse elecciones relativas a cuestiones sobre qué especificación informal de requisitos está ausente, es inconsistente o incorrecta. Para resolver tales cuestiones, se realizan requisitos o modificaciones adicionales y se graban y etiquetan en la pantalla 180 de requisitos derivados. Cuando la interfaz se ha especificado y validado por completo, se actualizan los requisitos informales según los requisitos derivados.
Esta interfaz se describe más detalladamente a
modo de un ejemplo que se describe más adelante con referencia a la
figura 20.
Al especificar un diseño de componente usando el
generador 100 de especificaciones basadas en secuencias para
producir una especificación 102 formal de diseño, en forma de una
caja negra totalmente especificada, se presentan las siguientes
pantallas al usuario:
- 1.
- La pantalla 138 de interfaz que es igual a la descrita anteriormente salvo porque habrá una pantalla de interfaz para cada interfaz implementada o usada por el componente que está diseñándose.
- 2.
- La pantalla 160 de enumeración de secuencias que es igual a la descrita anteriormente, salvo porque:
- a.
- El conjunto de estímulos de entrada es la unión de (i) todos los estímulos de entrada de todas las interfaces que están implementándose por el componente, y (ii) para cada interfaz usada, el subconjunto de respuestas a las que debe reaccionar el componente.
- b.
- Todas las funciones recursivas de prefijo referenciadas en cualquier predicado deben especificarse completamente para eliminar ausencia de determinismo intencionada.
- c.
- La función de caja negra resultante debe ser determinística; si no lo es, se trata de un error de diseño.
- d.
- Deben añadirse columnas adicionales para hacer un seguimiento de los estados de componentes usados como ayuda para el experto en diseño de software que realiza el diseño.
- 3.
- La pantalla 190 de análisis canónico como se muestra en la figura 21. Esta pantalla 190 tiene una fila por cada clase de equivalencia y cada fila tiene las siguientes columnas:
- a.
- El número de secuencia de la secuencia canónica en la pantalla 160 de enumeración de secuencias;
- b.
- La propia secuencia canónica en forma de una lista separada por comas de estímulos de entrada, con predicado asociado si lo hay;
- c.
- Un nombre simbólico de la clase de equivalencia que se usa para anotar tanto las tablas de enumeración de secuencias como la representación gráfica trazada del correspondiente comportamiento de máquina de estados finita de la función de caja negra total;
- d.
- Una o más columnas de propiedades de sistema definidas según el procedimiento 112 de desarrollo de estructura en caja.
Esta interfaz se describe más detalladamente a
modo de un ejemplo que se describe más adelante con referencia a la
figura 21.
- 4.
- La pantalla de especificación de función (no mostrada): Igual a la descrita anteriormente salvo porque todas las funciones recursivas de prefijo referenciadas en cualquier predicado deben especificarse completamente para eliminar ausencia de determinismo intencionada.
- 5.
- La pantalla 180 de requisitos derivados que es igual a la descrita anteriormente.
Al especificar una implementación en forma de
una caja de estado para aquellas partes del componente para las que
el código fuente de programa no puede generarse automáticamente por
el generador 92 de código, se presentan al usuario las siguientes
pantallas:
- 1.
- La pantalla 160 de enumeración de secuencias que es igual a la inicialmente descrita anteriormente salvo porque se añaden dos columnas adicionales, concretamente:
- a)
- Para cada fila para la que se especifica un predicado, una columna que contiene el mismo predicado expresado en términos de elementos de datos de estado en lugar de funciones recursivas de prefijo sobre las secuencias de entrada;
- b)
- Para cada fila para la que se especifica un predicado, una columna que contiene la especificación de actualizaciones de elementos de datos de estado.
\newpage
- 2.
- La pantalla de especificación de elementos de datos de estado (no mostrada). Una pantalla que identifica y define el tipo de cada elemento de datos de estado y especifica el valor inicial.
Al anotar una especificación 102 formal de
diseño de componentes para definir un modelo de uso necesario para
el generador 96 de casos de prueba para generar casos 78 de prueba,
se presentan al usuario las siguientes pantallas:
- 1.
- La pantalla 160 de enumeración de secuencias que es igual a la inicialmente descrita anteriormente, salvo porque se añade una columna adicional para permitir que cada resultado se etiquete con una probabilidad estimada de suceso.
- 2.
- La pantalla de generación de programa de prueba (no mostrada): Esta pantalla permite al usuario especificar tres tipos de información usada por el generador de casos de prueba de componentes para generar casos de prueba de componentes ejecutables:
- a)
- El prólogo de código de caso de prueba. Se trata de una secuencia de código de programa en el lenguaje de programación en el que van a generarse las pruebas. Cada programa de prueba generado empieza con esta secuencia.
- b)
- El epílogo de código de caso de prueba. Se trata de una secuencia de código de programa en el lenguaje de programación en el que van a generarse las pruebas. Cada programa de prueba generado termina con esta secuencia.
- c)
- El mapa de código de estímulo. Especifica para cada estímulo de entrada usado en el diseño, la secuencia de codificación que va a generarse en los casos de prueba para invocar el procedimiento correcto en la interfaz hacia el componente que está probándose.
En referencia ahora de nuevo a la figura 18,
puede verse que la pantalla 138 de interfaz se divide en varias
secciones como sigue:
Hay una sección 140 de canales, que lista los
nombres de los canales 140 de comunicación mediante los que
interacciona este componente especificado con otros componentes y el
entorno. En el ejemplo mostrado en la figura 18, ISS e ISSCB son
los nombres de canales que representan partes de las interfaces que
están implementándose por el componente que está especificándose.
Esta información la usa el generador 106 de modelos al generar
modelos 108 matemáticos de la interfaz y diseño del componente.
Se proporciona una sección 142 de colas que
identifica cualquier cola 142 necesaria para modelar correctamente
un comportamiento de interfaz sincrónico. Una cola 142 se especifica
por (i) su nombre 143; (ii) su nombre 144 de canal de entrada;
(iii) su nombre 145 de canal de salida; y (iv) la longitud 146 de
cola (el número de entradas que puede contener). En el ejemplo
mostrado en la figura 18, se especifica una cola 142; el nombre de
cola es DPCQ, los canales de entrada y salida se denominan
DPCQin y DPCQout respectivamente y la longitud de cola
es 12.
Esta información la usa el generador 106 de
modelos al generar modelos 108 matemáticos de la interfaz y el
diseño del componente. Permite modelar correctamente la naturaleza
sincrónica de una interfaz automáticamente.
La pantalla 138 de interfaz tiene una sección
147 de enlaces que especifica información adicional necesaria para
el generador 106 de modelos para generar correctamente modelos 108
matemáticos. Las afirmaciones se escriben en el lenguaje de
modelado elegido, en esta realización se expresan en la forma
legible por máquina de CSP denominada CSP_{m}. Las afirmaciones
especificadas se emiten como parte de la salida generada sin cambio.
En este ejemplo no se muestra ninguna.
Se proporciona una sección 148 de interfaz
implementada adicional. Esta sección define el conjunto de
interfaces implementadas por el componente que está
especificándose. En el ejemplo en la figura 18, la interfaz 148 se
denomina ISubStage y se implementa por el diseño especificado
en la tabla de enumeración de secuencias denominada
ISubStage. La finalidad de esta sección es definir los
estímulos y respuestas que pasan a través de la interfaz
implementada.
Cada estímulo y respuesta se define mediante una
única fila en la tabla mostrada como parte de la pantalla 138 de
interfaz. El significado de las columnas mostradas en la pantalla es
el siguiente:
Columna 149 más a la izquierda: Una breve
descripción del estímulo o respuesta. Es para comodidad del usuario
humano del editor 91 de ASD; no tiene significado para el ASD o para
el editor 91 de ASD y puede ser cualquier texto libre.
Columna 150 de estímulos: si la fila define un
estímulo, esta columna contiene su nombre con su canal como
prefijo.
Columna 151 de respuesta: si la fila define una
respuesta, esta columna contiene su nombre con su canal como
prefijo.
Hay tres respuestas que tienen nombres
reservados predefinidos y se usan con significados predefinidos.
Estos significados y nombres son parte del sistema ASD y no pueden
cambiarse. Son (i) Cero usado en aquellos casos en los que
un estímulo no tiene respuesta visible para representar la ausencia
de una respuesta; (ii) Ilegal usado para identificar
secuencias de estímulos de entrada que no tienen sentido o no pueden
suceder por el diseño; (iii) Bloqueado- se usa para
identificar secuencias que no pueden observarse en una situación
particular. Tiene una semántica similar a la Ilegal salvo
porque el estímulo y la respuesta se omiten ambos de los modelos
matemáticos generados.
Columna 152 de trazado: esta columna se usa para
controlar la apariencia de la representación trazada del diseño. Se
usa para especificar el color y estilo de línea de las líneas de
transición en la salida trazada.
En el ejemplo de la figura 18, se han agrupado
estímulos y respuestas y se han separado por títulos para aumentar
la claridad de la memoria descriptiva. El editor 91 de ASD permite
total libertad a este respecto.
Además de la interfaz implementada, hay una
sección 153 de interfaz usada. Es decir, interfaces usadas por el
componente que está especificándose pero no implementadas por él.
Cada interfaz 153 usada se define del mismo modo que la interfaz
implementada, en términos de los estímulos y respuestas que
pasan a través de la misma.
En referencia de nuevo a la figura 19, la
pantalla 160 de enumeración de secuencias se usa para definir el
comportamiento funcional visible externamente de una interfaz de
componente y el comportamiento diseñado de un diseño de componente.
La pantalla 160 visualiza una tabla que está dividida en un número
de secciones, habiendo una sección para cada secuencia
canónica que resulta de aplicar el Procedimiento de
especificaciones basadas en secuencias. Cada sección va
precedida de una línea 161 de cabecera que contiene la
identificación y especificación de la secuencia canónica a
la que se aplica la sección. La línea de cabecera se
especifica en un color de contraste seleccionado por el usuario por
motivos de claridad.
Cada sección especifica la única extensión de
estímulo de la secuencia canónica más todas las demás
secuencias en la misma clase de equivalencia. Dentro de cada
sección, hay una o más filas para cada estímulo.
Cada fila consiste en la siguiente
información:
- \bullet
- Columna 162 de número: esta columna es el número de secuencia de fila al que se ha hecho referencia previamente.
- \bullet
- Columna 163 de estímulo: es el estímulo de entrada al que se ha hecho referencia previamente.
- \bullet
- Columna 164 de predicado: esta columna contiene el predicado al que se ha hecho referencia previamente.
- \bullet
- Columna 165 de respuesta: es la respuesta a la que se ha hecho referencia previamente.
- \bullet
- Columna 166 de actualizar estado: esta columna se refiere a una modificación de la presente realización que puede incorporarse en una realización adicional. La columna 166 contiene actualizaciones de los predicados para reflejar el estado del sistema después de cualquiera de las secuencias representadas por la fila. Esta variación se describe a continuación.
- \bullet
- Columna 167 de equivalencia: es la clase de equivalencia a la que se ha hecho referencia previamente.
- \bullet
- Columna 168 de comentarios: esta columna contiene los comentarios a los que se ha hecho referencia previamente.
- \bullet
- Columna 169 de etiquetas: esta columna contiene las etiquetas de requisitos a las que se ha hecho referencia previamente.
\vskip1.000000\baselineskip
El ejemplo mostrado en la figura 19 muestra las
dos primeras secciones de un diseño de componente. Obsérvese que la
organización, disposición y apariencia de las tablas es importante
en la descripción de la interfaz más que el contenido particular
que se proporciona meramente como datos de ejemplo ilustrativos. Una
especificación de interfaz de componente tiene la misma disposición
y estructura.
En referencia de nuevo a la figura 21, la
pantalla 190 de análisis canónico tiene un formato y una disposición
que es parte de la interfaz de usuario del editor de ASD, pero el
contenido son datos de ejemplo dados con fines de ilustración
únicamente. De manera más específica, la pantalla 190 de análisis
canónico comprende:
Una columna 192 más a la izquierda: corresponde
al número de secuencia como se ha especificado anteriormente. Una
columna 194 de secuencia canónica: corresponde a la secuencia
canónica como se ha especificado anteriormente. Una columna 196 de
nombre de estado: corresponde al nombre simbólico de la clase de
equivalencia correspondiente como se ha especificado anteriormente.
Columnas 198 de propiedad 1 y propiedad 2: una o más columnas, cada
una de las cuales contiene una de las propiedades del sistema como
se ha especificado anteriormente. En la pantalla mostrada en la
figura 21, se muestran dos columnas que son únicamente ejemplares;
el número de columnas y los nombres de las columnas se especifican
por el usuario del editor de ASD y son específicos de cada
especificación de componente individual.
Una variación de lo que se ha descrito
anteriormente en relación con la pantalla 160 de enumeración de
secuencias, se describe ahora como parte de una realización
diferente. En la primera realización se describió el uso de
funciones recursivas de prefijo sobre las secuencias de entrada como
medio para especificar predicados asociados con secuencias de
estímulos de entrada. Originalmente se mencionó que una pantalla
de especificación de función era parte del editor 91 de ASD para
especificar estas funciones.
En la práctica, resulta muy difícil que el
generador de modelos y el generador de código generen los modelos
matemáticos y el código fuente apropiados que representan el
comportamiento de las funciones recursivas de prefijo. En lugar de
ello, como una extensión de la aplicación de la primera realización,
se usan variables de estado en las especificaciones de predicado.
Esto significa que hay una forma de especificar el efecto de una
secuencia de estímulos sobre los valores de estas variables de
estado. De este modo, se consigue el mismo efecto que usando
funciones recursivas de prefijo, pero la generación de modelos puede
llevarse a cabo más fácilmente.
El efecto de esto puede verse en la pantalla 160
de enumeración de secuencias mostrada en la figura 19. La
columna 164 de predicado contiene extensiones de predicado
que usan variables de estado. La columna 166 de actualizar
estado, se usa para especificar los nuevos valores de las
variables de estado como una consecuencia de las secuencias de
estímulos de entrada. Finalmente, las variables de estado deben
tener valores definidos después de la secuencia vacía. Esto se
consigue especificándolas en la línea 161 de cabecera de la primera
sección de la tabla. Se trata de la sección que corresponde a la
secuencia canónica vacía.
Esta modificación de la primera realización
tiene los siguientes beneficios:
- 1.
- La mayor parte de los ingenieros de software consideran el uso de variables de estado en predicados más intuitivo y fácil que definir funciones recursivas de prefijo;
- 2.
- Hace que la generación de modelos sea más directa;
- 3.
- Hace la generación de códigos más sencilla.
Además, significa que la pantalla 160 de
enumeración de secuencias mencionada anteriormente tiene el mismo
formato que el usado anteriormente.
Una modificación adicional es que la columna 167
de EQU tiene un código de color por el editor 91 de ASD para ayudar
al usuario a distinguir entre diferentes casos.
El generador 96 de casos de prueba de
componentes toma como entrada los modelos de uso en forma de los
archivos 93 de datos almacenados por el editor 91 de ASD, genera
los casos 78 de prueba de componentes necesarios y analiza los
resultados de prueba. Se compone de los siguientes módulos de
procesamiento:
- 1.
- Un generador de secuencias de prueba (no mostrado) que genera un conjunto de casos de prueba en forma de secuencias de estímulos de entrada con las respuestas esperadas, ponderado estadísticamente según el modelo de uso según los principios descritos en [PTLP98]. En la presente realización, los modelos de uso se registran en el lenguaje TML como se describe en [PRO00] y el generador de secuencias de prueba funciona como el programa JUMBL según se especifica en [PRO03].
- 2.
- Un generador de programas de prueba (no mostrado) que toma como entrada los casos de prueba generados por el generador de secuencias de prueba y genera los programas de prueba correspondientes a cada caso de prueba. En la presente realización, los casos de prueba se generan en forma de programas informáticos individuales, cada uno de los cuales corresponde a uno de los casos de prueba generados por el generador de secuencias de prueba. Puede elegirse cualquier lenguaje de programación adecuado; las secuencias de código de programa se generan según las secuencias introducidas usando el editor 91 de ASD y almacenadas como parte del modelo de uso. Para cada caso de prueba, el programa de prueba se genera como sigue:
- a.
- Se genera el prólogo de código (véase anteriormente).
- b.
- Para cada estímulo de entrada en el caso de prueba, se genera la secuencia de código especificada en el mapa de código de estímulo (véase anteriormente).
- c.
- Después de la última secuencia de código de estímulo de entrada, se genera el epílogo de código (véase anteriormente).
- 3.
- Un oráculo de prueba (no mostrado) que toma como entrada archivos de datos generados por los programas de prueba cuando se ejecutan y que registran los resultados de la prueba y analiza los resultados con el fin de determinar si la prueba ha tenido éxito o ha fracasado y calcula estadísticas en cuanto al progreso de la prueba y la probable fiabilidad del componente que está probándose. En la realización de la presente invención, este análisis se realiza mediante el programa JUMBL especificado en [PRO03].
Un conjunto de programas informáticos que,
cuando se compilan y están listos para su ejecución por un ordenador
y que implementan el comportamiento de máquina de estados de un
componente se denomina una máquina de estados ejecutable.
Una máquina de estados ejecutable tiene tres partes:
- \bullet
- Un entorno de ejecución que determina cómo recibe la máquina de estados ejecutable estímulos de entrada. Es específico del sistema y la implementación y es independiente de cualquier máquina de estados particular que esté implementándose. Se diseña y programa a mano del modo habitual, posiblemente haciendo uso de componentes reutilizables. Su función es proporcionar los estímulos de entrada en el orden correcto para hacer que la máquina de estados opere según se especifica en la especificación 70 de diseño de componentes verificada.
- Este código de programa no se genera por el generador 92 de código.
- \bullet
- Un conjunto de procedimientos de respuesta, habiendo un procedimiento de respuesta para cada respuesta r\inR y cada uno de los cuales implementa una de las respuestas en R. Este código de programa se desarrolla a mano basándose en las especificaciones 74 de implementación de componentes verificadas.
- Este código de programa no se genera por el generador 92 de código.
- \bullet
- Una implementación de la máquina de estados que, dado un estímulo, invoca el procedimiento de respuesta correspondiente y ejecuta la función de transición de estado según su diseño especificado por las especificaciones 70 de diseño de componentes verificadas.
- Todo este código se genera automáticamente por el generador 92 de código a partir de la especificación 70 de diseño de componentes verificada.
El código 82 de programa fuente que implementa
el comportamiento de máquina de estados puede generarse en
cualquier lenguaje de programación. La presente realización genera
código de programa fuente en C++ y C; otros lenguajes de
programación tales como JAVA o ADA podrían usarse igualmente.
El algoritmo (no mostrado) para generar el
código fuente de programa en C++ es el siguiente:
- 1.
- Generar la definición de un estado de clase de base abstracto con un procedimiento puro virtual definido para cada estímulo s\inS. La firma de cada procedimiento debe incluir el valor devuelto de tipo referencia a estado.
- 2.
- Generar la definición de una clase denominada contexto para representar el estado del componente y que contiene datos de estado variables necesarios para mantener los valores de los diversos predicados. Para cada uno de tales elementos de datos, definir un elemento de datos con un nombre adecuado y un par de procedimientos de acceso para recuperar y actualizar los valores de elemento de datos. Para cada uno de tales predicados, definir una función booleana con un nombre adecuado que devuelve el valor del predicado.
- 3.
- Para cada secuencia canónica C_{i}, generar la definición de una subclase concreta de clase abstracta estado, denominada estado_{i}, todas las instancias de la cual proporcionan una implementación para cada procedimiento puro virtual en la clase de base abstracta estado. La finalidad de cada procedimiento es (i) evaluar cualquier predicado usando los datos de estado encapsulados en la clase contexto y determinar la función de respuesta apropiada que debe invocarse y el estado sucesor; (ii) invocar la función de respuesta; (iii) capturar cualquier actualización de datos de estado en contexto necesarias para evaluar predicados en el futuro; y (iv) devolver una referencia al estado sucesor. Los datos de estado se recuperan y actualizan a través de los procedimientos de acceso implementados en la clase contexto.
Puede adoptarse un enfoque similar para generar
código fuente para otros lenguajes orientados a objetos tales como
Java.
Para lenguajes de procedimiento, tales como C,
es necesario un enfoque diferente. Un algoritmo de este tipo es
generar un módulo que encapsula todo el comportamiento de estado.
Las características del módulo generado son las siguientes:
- 1.
- El módulo define variables de datos locales estáticas para contener los datos de estado requeridos para evaluar predicados. Un elemento de datos de estado especial se denomina estado actual y se usa para identificar la secuencia canónica correspondiente a la clase de equivalencia de secuencias de estímulos de entrada ya introducidos.
- 2.
- Para cada uno de los predicados, el módulo define una función booleana con un nombre adecuado que evalúa el predicado y devuelve su valor.
- 3.
- El módulo define un procedimiento para cada estímulo s\inS. Los nombres de procedimiento tienen un ámbito global y el entorno de ejecución debe invocar el procedimiento que corresponde a cada estímulo cuando se produce. La finalidad de estos procedimientos es delegar el procesamiento real a un procedimiento de estímulo P_{i,j} diseñado para llevar a cabo las acciones necesarias para el estímulo s_{i} después de cualquier secuencia en la clase de equivalencia identificada por la secuencia canónica C_{j};
- 4.
- Para cada estímulo s_{i}\inS y cada secuencia canónica C_{j}, el módulo contiene un procedimiento de estímulo local P_{i,j} para ejecutar las acciones definidas para el estímulo s_{i} después de cualquier secuencia en la clase de equivalencia representada por C_{j}. Cada uno de tales procedimientos debe (i) evaluar cualquier predicado basándose en valores de datos de estado; (ii) invocar el procedimiento de respuesta apropiado; (iii) realizar cualquier actualización de datos de estado necesaria; y (iv) devolver un valor que representa la clase de equivalencia a la que pertenecen las secuencias recién formadas.
\vskip1.000000\baselineskip
Un enfoque similar puede adoptarse para
cualquier lenguaje de programación de procedimiento.
Para facilitar la prueba de componentes, el
generador de código opcionalmente genera afirmaciones de programa
de diagnóstico adicionales que registran el estímulo que está
procesándose y la respuesta generada en forma de un archivo de
datos que puede introducirse por el oráculo de prueba para analizar
los resultados de pruebas de componentes.
Una segunda realización de la presente invención
se describe ahora con referencia a la figuras 22 a 25. De manera
más específica, la segunda realización es muy similar a la primera
realización y por tanto, por motivos de concisión, sólo se
comentarán a continuación detalladamente las diferencias entre las
realizaciones.
En la realización anterior, el generador 90 de
especificaciones de caja negra verificadas era responsable de
generar especificaciones de caja negra para las siguientes:
1. Una especificación funcional de interfaz del
componente que está diseñándose (que se denomina a continuación como
CBD);
2. Un diseño y especificación de componente del
CBD;
3. Especificaciones de interfaces funcionales
para todos los demás componentes con los que interacciona el
CBD.
Según se describe en la primera realización,
esto permite verificar el diseño del CBD en cuanto a su corrección
tanto con respecto a su propia especificación funcional de interfaz
como con respecto a las especificaciones funcionales de interfaces
de los demás componentes con los que interacciona. Estos componentes
usados (denominados a continuación como UC) pueden implementarse en
software o hardware o alguna combinación de ambos.
Cuando los UC se han desarrollado o se
desarrollarán sin usar el sistema 62 ASD, por ejemplo, porque ya
existen o van a suministrarse por una organización o equipo de
proyecto diferente que usa procedimientos de desarrollo
convencionales, no puede garantizarse su corrección con respecto a
sus especificaciones funcionales de interfaces usando el sistema 62
ASD para desarrollar el CBD. Por tanto existe la posibilidad de que
las especificaciones funcionales de interfaces de uno o más de los
UC puedan diferir del comportamiento implementado real. Esto es
importante porque el diseño del CBD se verifica frente a estas
especificaciones funcionales de interfaces y no frente a los
diseños o implementaciones de los UC.
En la práctica esto significa que los defectos
en el sistema implementado provocados por diferencias entre una
especificación funcional de interfaz de UC y su implementación real
pueden quedar sin detectar hasta las pruebas de integración. Con el
fin de aislar y detectar tales defectos, el sistema 62 ASD de la
segunda realización se extiende para incluir los nuevos conceptos
de verificadores 206 de protocolo de interfaz y un generador 208 de
verificadores de protocolo de interfaz (figura 25).
En referencia ahora a la figura 22, se muestra
una arquitectura 200 de ejecución de un CBD junto con un número de
UC 202 con los que interacciona. El diseño del CBD se ha verificado
como correcto suponiendo que cada UC implementa correctamente el
comportamiento especificado por su especificación 72 de interfaces
de componentes verificada, y el código 204 de programa del CBD se
ha generado a partir de este diseño verificado.
Como se muestra en la figura 23, un verificador
206 de protocolo de interfaz es un componente de procesamiento de
software que se inserta entre el CBD 204 y un UC 202. Su finalidad
es observar todas las interacciones desde el CBD 204 hasta el UC
202 y desde el UC 202 hasta el CBD 204 y verificar las interacciones
entre ellos según la especificación 72 de interfaz de componente
verificada del UC 202.
No es necesario verificar que el CDB 204
interacciona correctamente con el UC 202 según la especificación 72
de interfaz de componente verificada del UC porque ya se ha
verificado matemáticamente usando el sistema 62 ASD para diseñar e
implementar el CBD. La finalidad de un verificador 206 de protocolo
de interfaz es detectar cualquier diferencia entre el
comportamiento del UC observado y su especificación 72 de interfaz
de componente verificada y proporcionar información de diagnóstico
(no mostrada) para permitir analizar estas diferencias y adoptar
acciones correctivas. Obsérvese que esto no es necesario si el UC se
ha desarrollado usando el sistema 62 ASD; en ese caso, su diseño se
habrá verificado matemáticamente como correcto con respecto a su
especificación funcional de interfaz.
Cada verificador 206 de protocolo de interfaz es
un módulo de procesamiento generado a partir de una especificación
72 de interfaz de componente verificada por el generador ASD de
verificadores 208 de protocolo de interfaz. El módulo 206 de
procesamiento generado implementa una máquina de estados (no
mostrada) que representa el comportamiento especificado de la
interfaz de componente para la que se genera. Cuando se ejecuta el
sistema, cada interacción del CBD 204 con el UC 202 a través de su
interfaz se intercepta por el verificador 206 de protocolo de
interfaz y pasa a través de su máquina de estados al UC 202 que
implementa la interfaz. En cada interacción desde el CBD 204, el
verificador 206 de protocolo de interfaz actualiza su máquina de
estados según la especificación 72 de interfaz de componente
verificada para reflejar esta interacción y la reenvía al UC 202
implementado.
Cada interacción del UC 202 dirigida hacia el
CBD 204 se intercepta de manera similar por el verificador 206 de
protocolo de interfaz y se valida frente a la máquina de estados de
verificador de protocolo de interfaz. Si se permite, según el
estado actual de verificador de protocolo de interfaz, entonces la
interacción se reenvía al CBD 204. De lo contrario, se crea un
registro de la información de diagnóstico y, opcionalmente, se
detiene la ejecución del
sistema.
sistema.
Cada verificador 206 de protocolo de interfaz
generado puede configurarse durante la generación para mantener
durante la ejecución una traza de un número especificado de las
interacciones más recientes del CBD 204 y el UC 202 para ayudar a
diagnosticar el error.
El verificador 206 de protocolo de interfaz
sigue en su sitio durante la integración y las pruebas del sistema
y puede eliminarse después o dejarse en su sitio permanentemente
para proporcionar una monitorización continua del comportamiento
del resto de componentes.
Dado que el verificador 206 de protocolo de
interfaz es específico para una interfaz de componente dada, se
genera un verificador 206 de este tipo para cada interfaz de UC.
El generador 208 de verificadores de protocolo
de interfaz mostrado en la figura 25, es un módulo de procesamiento
que es una versión modificada del generador 92 de código de ASD.
Toma como entrada la especificación 72 de interfaz de componente
verificada de un UC 202 en forma de una especificación de caja negra
verificada y genera un verificador 206 de protocolo de interfaz en
forma de un módulo de procesamiento de software escrito en un
lenguaje de programación adecuado.
Una causa habitual de defectos en sistemas de
software desarrollados usando procedimientos convencionales es que
los componentes (UC) usados no se comportan según sus
especificaciones de Interfaces de componente verificadas. A menudo
se da el caso de que hay incertidumbre respecto al comportamiento
del UC.
Esto lleva a una clase de defectos que no pueden
detectarse hasta que haya empezado la integración y las pruebas del
sistema y que son extremadamente difíciles de detectar y
eliminar.
El beneficio técnico de esta realización es
permitir que el sistema detecte e identifique tales defectos de
manera más eficaz que en la práctica del diseño de software
convencional y proporcionar información detallada relativa a la
causa del defecto. En combinación con el resto del sistema 62 ASD,
esto lleva a eliminar los defectos de manera más eficaz y más
segura en comparación con otros procedimientos de desarrollo. Si se
determina que el UC 202 se comporta de manera diferente a su
especificación funcional de interfaz y que este comportamiento se
considera el comportamiento correcto, usando el sistema 62 ASD de la
segunda realización, el problema se aborda de la siguiente
manera:
- 1.
- Usando el editor 91 de ASD, se actualiza la especificación funcional de interfaz del componente para reflejar el comportamiento real observado y se produce una nueva especificación usando el generador 90 de especificaciones de caja negra verificadas de ASD. El generador de modelos de ASD se usa para generar un nuevo modelo 108 matemático de la interfaz modificada a partir de la especificación 72 de interfaz de componente verificada recién generada.
- 2.
- Usando el verificador 208 de modelos de ASD, se verifica el diseño del CBD en cuanto a su corrección frente a estos cambios. En caso necesario, el diseño del CBD se modifica par reflejar este comportamiento cambiado, se generan nuevos modelos matemáticos usando el generador 106 de modelos de ASD y los cambios de diseño se verifican usando el verificador 110 de modelos de ASD. Este ciclo se repite según sea necesario hasta que el diseño del CBD modificado se haya verificado como correcto.
- 3.
- El generador 92 de código de ASD se usa para generar el código de programa para el diseño de CBD modificado.
- 4.
- El generador 208 de verificadores de protocolo de interfaz de ASD se usa para generar un nuevo verificador de protocolo de interfaz según la interfaz cambiada.
\newpage
La presente realización tiene una salida
adicional del sistema ASD en comparación con la primera realización.
Esta salida adicional es un verificador de protocolo de interfaz
para uno o más UC como se muestra en las figuras 24 y 25.
La segunda realización incorpora un editor 91 de
ASD mejorado que tiene muchas más funciones de edición. El editor
91 de ASD se extiende para proporcionar las siguientes
funciones:
Insertar línea: una línea de número de secuencia
vacía, y correctamente formateada se inserta en la tabla de
enumeración de secuencias en el punto designado.
Insertar respuesta: el editor 91 de ASD presenta
una lista de todas las respuestas definidas en la pantalla 138 de
interfaz y permite al usuario elegir una o más de ellas. Estas
respuestas se insertan en la tabla de enumeración de secuencias
(pantalla 160) en el punto designado en el orden especificado.
Insertar estímulo: el editor 91 de ASD presenta
una lista de todos los estímulos 150 definidos en la pantalla 138
de interfaz y permite al usuario seleccionar uno o más de ellos.
Para cada estímulo 150 seleccionado, se inserta una nueva línea en
el lugar designado en las tablas en el orden especificado.
Definir nueva secuencia canónica: al aplicar el
procedimiento de especificaciones basadas en secuencias para
construir tablas de enumeración de secuencias, se descubrirán e
identificarán nuevas secuencias canónicas. Cada una de ellas
requiere su propia sección en las tablas de enumeración de
secuencias (pantalla 160). El editor 91 de ASD calcula la nueva
secuencia 194 canónica, determina dónde debe insertarse la
correspondiente sección en las tablas e inserta una nueva sección,
cuyos valores se copian de la primera sección en la tabla. Una
referencia a esta secuencia 194 canónica seleccionada se inserta en
la columna 167 de equivalencia en las tablas de enumeración de
secuencias (pantalla 160) en la fila designada.
Definir nueva secuencia canónica a partir de: se
trata de una variación de la función descrita inmediatamente antes.
En lugar de insertar una nueva sección creada copiando los valores
de la primera sección, el editor 91 de ASD presenta una lista de
todas las secuencias 194 canónicas actualmente definidas y permite
al usuario elegir una de ellas. La nueva sección se crea copiando
la sección correspondiente a la secuencia 194 canónica seleccionada
por el usuario. Una referencia a esta secuencia 194 canónica
seleccionada se inserta en la columna 167 de que en las tablas de
enumeración de secuencias (pantalla 160) en la fila designada.
Enlazar a secuencia canónica existente: cuando
el futuro comportamiento del sistema es igual que el comportamiento
ya definido, el usuario debe especificar la secuencia 194 canónica a
la que es equivalente el futuro comportamiento. El editor 91 de ASD
visualiza una lista de todas las secuencias 194 canónicas ya
definidas y el usuario selecciona la que tiene el mismo
comportamiento de sistema futuro. Una referencia a esta secuencia
194 canónica seleccionada se inserta en la columna 167 de
equivalencia en las tablas de enumeración de secuencias (pantalla
160) en la fila designada.
Clasificar secuencias canónicas: editar las
tablas de enumeración de secuencias puede dar como resultado
redefiniciones de secuencias 194 canónicas con la consecuencia de
que las correspondientes secciones en la tabla están desordenadas.
El editor 91 de ASD regenerará todas las secuencias 194 canónicas
para garantizar que son la secuencia de longitud mínima en su
respectiva clase de equivalencia y entonces clasifica las secciones
de tabla para que reflejen el orden de longitud de las secuencias
194 canónicas.
Una vez descritas realizaciones preferidas
particulares de la presente invención, ha de apreciarse que las
realizaciones en cuestión son sólo meramente ejemplares, y que
pueden realizarse variaciones y modificaciones, tales como las que
concebirán quienes tengan el conocimiento y las aptitudes
apropiados, sin alejarse del alcance de la invención según se
establece en las reivindicaciones adjuntas.
\vskip1.000000\baselineskip
[For03] Formal Systems (Europe) Ltd.
Failures-Divergence Refinement: FDR2 User Manual,
2003. Véase
http://www.fsel.com.
http://www.fsel.com.
[Hoa85] C. A. R. Hoare. Communicating
Sequential Processes. Prentice Hall, 1985.
[Mil88] H. D. Mills. Stepwise Refinement
and Verification in Box Structured Systems. Computer,
21(6):23-26, 1988.
[MLH86] H. D. Mills y R. C. Linger
y A. R. Hevner. Principles of Information Systems Analysis
and Design. Academic Press, 1986.
[PP03] S. J. Prowell y J. H.
Poore, Foundations of Secuence-Based Software
Especification. IEEE Transactions of Software Engineering,
29(5):417-429, 2003.
[Pro00] S. J. Prowell, TML: A Description
Language for Markov Chain Usage Models. Information and Software
Technology, 42(12):835-844, septiembre de
2000.
[Pro03] S. J. Prowell, JUMBL: A Tool for
Model-Based Statistical Testing. En Proceedings of
the 36th Hawaii International Conference on System Sciences
(HICSS'03), 2003.
[PTLP98] S. J. Prowell, C. J.
Trammell, R. C. Linger y J. H. Poore, Cleanroom
Software Engineering - Technology and Process.
Addison-Wesley, 1998.
[Ros94] A. W. Roscoe,
Model-Checking CSP. A Classical Mind: Essays in
Honour of C.A.R. Hoare, páginas 353-378.
Prentice-Hall, 1994.
[Ros98] A. W. Roscoe, The Theory and
Practice of Concurrency. Prentice Hall, 1998.
Claims (21)
1. Sistema analítico de diseño de software
dispuesto para recibir especificaciones (14, 18, 22) informales de
diseño de sistema, para permitir el desarrollo de diseños (102, 104)
de especificaciones formales para una pluralidad de componentes del
sistema y para convertir los diseños (102, 104) de especificaciones
formales en especificaciones (66, 68, 70, 72) de diseño verificadas
para su uso en la creación automática de código (76) fuente y
llevar a cabo pruebas de implementación del código (76) fuente,
comprendiendo el sistema:
un módulo (91) editor dispuesto para permitir la
edición por un usuario de las especificaciones (102, 104) formales
para cada componente;
un generador (90) de especificaciones de caja
negra verificadas dispuesto para permitir desarrollar las
especificaciones (14, 18, 22) informales de diseño de sistema
recibidas para cada componente en:
(i) especificaciones (102) formales de diseño
representativas de una función de caja negra completamente
especificada; y
(ii) especificaciones (104) formales de interfaz
representativas de una especificación de caja negra
infraespecificada, en el que se consigue una infraespecificación
introduciendo predicados indefinidos para capturar, para un
estímulo s dado, una pluralidad de posibles respuestas y
comportamiento posterior,
en el que las especificaciones (i) y (ii) se
desarrollan usando el módulo (91) editor, y el generador (90) de
especificaciones de caja negra está dispuesto además para probar la
corrección de las especificaciones (102) formales de diseño y
especificaciones (104) formales de interfaz y para generar las
especificaciones (66, 68, 70, 72) de diseño verificadas;
comprendiendo el generador (90) de
especificaciones de caja negra:
medios para presentar, a través del módulo (91)
editor, tablas (160) de enumeración para capturar las
especificaciones formales como especificaciones basadas en
secuencias, en el que cada fila de una tabla identifica un estímulo,
su respuesta y su equivalencia;
un generador (106) de modelos dispuesto para
generar automáticamente un modelo (108) matemático en notación CSP
del comportamiento del sistema para cada componente a partir de las
especificaciones (102) formales de diseño y las especificaciones
(104) formales de interfaz expresadas en las tablas (160) de
enumeración, donde CSP significa Comunicación de Procesos
Secuenciales; y
un comprobador (110) de modelos dispuesto para
analizar los modelos (108) matemáticos para determinar si tienen el
comportamiento requerido para ese componente, para identificar
errores en las especificaciones (102) formales de interfaz y en las
especificaciones (104) formales de diseño, para realimentar los
errores en las especificaciones (102, 104) de diseño informales y/o
formales;
en el que el generador (90) de caja negra
verificada está dispuesto para permitir a un usuario ajustar las
especificaciones (102) formales de interfaz y las especificaciones
(104) formales de diseño a través de las tablas (160) de
enumeración, para generar modelos (108) matemáticos corregidos, para
analizar los mismos, para identificar errores y para realimentar
los errores hasta que se consiga el comportamiento requerido para
ese componente; y para derivar las especificaciones (66, 68, 70, 72)
de diseño verificadas requeridas a partir de los modelos (108)
matemáticos libres de errores.
2. Sistema según la reivindicación 1, en el que
el sistema está dispuesto para manejar especificaciones informales
de diseño de sistema que comprenden especificaciones informales de
requisitos, especificaciones informales de arquitectura y diseños
de componentes y especificaciones informales.
3. Sistema según la reivindicación 2, en el que
el generador (90) de especificaciones de caja negra está dispuesto
para permitir la creación de especificaciones (104) formales de
interfaz del comportamiento funcional requerido de cada componente
que es visible mediante sus interfaces.
4. Sistema según la reivindicación 3, en el que
el generador (90) de especificaciones de caja negra está dispuesto
para permitir la creación de las especificaciones (104) formales de
interfaz como especificaciones de caja negra infraespecificadas del
comportamiento funcional requerido.
5. Sistema según cualquiera de las
reivindicaciones 2 a 4, en el que el generador (90) de
especificaciones de caja negra está dispuesto para permitir la
creación de especificaciones (102) formales de diseño de componentes
del comportamiento funcional requerido de cada componente.
\newpage
6. Sistema según la reivindicación 5, en el que
el generador (90) de especificaciones de caja negra está dispuesto
para permitir la creación de las especificaciones (102) formales de
diseño de componentes como especificaciones de caja negra
totalmente especificadas del comportamiento funcional requerido.
7. Sistema según la reivindicación 5 ó 6, en el
que el generador (90) de especificaciones de caja negra está
dispuesto para garantizar que las especificaciones (102) formales de
diseño de componentes se crean para ser compatibles con el
comportamiento de interfaz requerido.
8. Sistema según cualquier reivindicación
anterior, en el que el generador de especificaciones de caja negra
está dispuesto para generar una especificación de requisitos
verificada, una especificación de arquitectura verificada, una
especificación de diseño de componentes verificada y una
especificación de interfaces de componentes verificada.
9. Sistema según cualquier reivindicación
anterior, en el que el módulo (91) editor está dispuesto para
presentar una pantalla (138) de interfaz para permitir al usuario
especificar una interfaz de componente, incluyendo la pantalla de
interfaz el nombre de la interfaz, un identificador único para cada
estímulo y respuesta pertenecientes a la interfaz, una lista de
estímulos de entrada, y una lista de respuestas.
10. Sistema según cualquier reivindicación
anterior, en el que el módulo editor está dispuesto para presentar
tablas (160) de enumeración que están divididas cada una en
secciones, una sección para una secuencia canónica que resulta de
la especificación basada en secuencias.
11. Sistema según cualquier reivindicación
anterior, en el que el generador (90) de especificaciones de caja
negra comprende un generador (100) de especificaciones basadas en
secuencias para facilitar la creación por el usuario de las
especificaciones (102, 104) formales de diseño y de interfaz a
partir de las especificaciones (14, 18, 22) informales de diseño de
sistema recibidas.
12. Sistema según la reivindicación 11, en el
que el generador (100) de especificaciones basadas en secuencias
está dispuesto para emitir datos de análisis para su consideración
por el usuario de las especificaciones de diseño.
13. Sistema según cualquier reivindicación
anterior, en el que el comprobador (110) de modelos comprende un
comprobador de modelos FDR para comprobar los modelos matemáticos
descritos en notación CSP.
14. Sistema según cualquier reivindicación
anterior, en el que el módulo (91) editor está dispuesto para
almacenar datos como archivos (93) de datos.
15. Sistema según cualquier reivindicación
anterior, que comprende además un generador (92) de código
automatizado para crear código (76) fuente de programa generado por
máquina a partir de las especificaciones (64)
verifica-
das.
das.
16. Sistema según cualquier reivindicación
anterior, que comprende además un generador (96) de casos de prueba
de componentes automatizado para crear casos (78) de prueba de
componentes generados por máquina a partir de las especificaciones
(64) verificadas.
17. Sistema según la reivindicación 16, en el
que el generador (96) de casos de prueba automatizado comprende:
un generador de secuencias de prueba dispuesto
para generar un conjunto de casos de prueba en forma de secuencias
de estímulos de entrada con las respuestas esperadas;
un generador de programas de prueba que toma los
casos de prueba y genera programas de prueba correspondientes a
cada caso de prueba; y
un oráculo de prueba que toma archivos de datos,
generados por los programas de prueba, que registran los resultados
de la prueba y está dispuesto para analizar los resultados para
determinar si se ha pasado la prueba.
18. Sistema según cualquier reivindicación
anterior, que comprende además un generador (94) de especificaciones
de implementación verificadas para ayudar a los usuarios a crear
especificaciones (74) de implementación verificadas a partir de las
especificaciones (64) verificadas para componentes de software que
no pueden generarse automáticamente.
19. Sistema según cualquier reivindicación
anterior, que comprende además un generador de verificadores de
protocolo de interfaz para crear verificadores de protocolo de
interfaz generados por máquina a partir de las especificaciones
verificadas.
20. Un soporte de datos que tiene almacenado en
el mismo un programa para un ordenador para configurar el ordenador
para que funcione como un sistema como se expone en la
reivindicación 1.
21. Procedimiento para desarrollar y convertir
diseños (102, 104) de especificaciones formales de un sistema de
software que va a diseñarse, en especificaciones (66, 68, 70, 72) de
diseño verificadas para su uso en la creación automática de código
(76) fuente y para llevar a cabo pruebas de implementación del
código (76) fuente para el sistema de software, comprendiendo el
procedimiento:
recibir especificaciones (14, 18, 22) informales
de diseño de sistema para una pluralidad de componentes del sistema
de software;
permitir, usando un módulo (91) editor, a un
usuario editar las especificaciones (102, 104) formales para cada
componente;
proporcionar un generador (90) de
especificaciones de caja negra verificadas para:
desarrollar para cada componente, a partir de
las especificaciones (14, 18, 22) informales de diseño de sistema
recibidas:
(i) especificaciones (102) formales de diseño
representativas de una función de caja negra completamente
especificada; y
(ii) especificaciones (104) formales de interfaz
representativas de una especificación de caja negra
infraespecificada, en el que la infraespecificación se consigue
introduciendo predicados indefinidos para capturar, para un estímulo
s dado, una pluralidad de posibles respuestas y comportamiento
posterior,
en el que se desarrollan las especificaciones
(i) y (ii) usando el módulo (91) editor,
probando la corrección de las especificaciones
(102) formales de diseño y de las especificaciones (104) formales de
interfaz;
generando las especificaciones (66, 68, 70, 72)
de diseño verificadas;
presentando, a través del módulo (91) editor,
tablas (160) de enumeración para capturar las especificaciones
formales como especificaciones basadas en secuencias, en el que cada
fila de una tabla identifica un estímulo, su respuesta y su
equivalencia;
producir automáticamente, usando un generador
(106) de modelos, un modelo (108) matemático en notación CSP del
comportamiento del sistema para cada componente a partir de las
especificaciones (102) formales de diseño y las especificaciones
(104) formales de interfaz expresadas en las tablas (160) de
enumeración, donde CSP significa Comunicación de Procesos
Secuenciales;
analizando, usando un comprobador (110) de
modelos, los modelos (108) matemáticos para determinar si tienen el
comportamiento requerido para ese componente, para identificar
errores en las especificaciones (102) formales de interfaz y las
especificaciones (104) formales de diseño, y para realimentar los
errores en las especificaciones (102, 104) informales y/o formales
de diseño; y
usando el generador (90) de especificaciones de
caja negra para permitir a un usuario ajustar las especificaciones
(102) formales de interfaz y las especificaciones (104) formales de
diseño a través de las tablas (160) de enumeración, para generar
modelos (108) matemáticos corregidos, para analizar los mismos, para
identificar errores y para realimentar los errores hasta que se
consiga el comportamiento requerido para ese componente; y para
derivar las especificaciones (66, 68, 70, 72) de diseño verificadas
requeridas a partir de los modelos (108) matemáticos libres de
errores.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0410047.5A GB0410047D0 (en) | 2004-05-05 | 2004-05-05 | An analytical software design system |
| GB0410047 | 2004-05-05 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2334041T3 true ES2334041T3 (es) | 2010-03-04 |
Family
ID=32482728
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05742438T Active ES2334041T3 (es) | 2004-05-05 | 2005-05-05 | Sistema analitico de diseño de software. |
Country Status (10)
| Country | Link |
|---|---|
| US (2) | US8370798B2 (es) |
| EP (1) | EP1749264B1 (es) |
| AT (1) | ATE434216T1 (es) |
| DE (1) | DE602005014970D1 (es) |
| DK (1) | DK1749264T3 (es) |
| ES (1) | ES2334041T3 (es) |
| GB (1) | GB0410047D0 (es) |
| HK (1) | HK1104100A1 (es) |
| SI (1) | SI1749264T1 (es) |
| WO (1) | WO2005106649A2 (es) |
Families Citing this family (79)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4516001B2 (ja) * | 2005-11-14 | 2010-08-04 | 富士通株式会社 | ソフトウェアテスト管理プログラム、ソフトウェアテスト管理装置、ソフトウェアテスト管理方法 |
| WO2007056807A1 (en) * | 2005-11-18 | 2007-05-24 | Robert Arthur Crewdson | Computer software development system and method |
| US7813911B2 (en) * | 2006-07-29 | 2010-10-12 | Microsoft Corporation | Model based testing language and framework |
| US8756561B2 (en) | 2006-12-05 | 2014-06-17 | International Business Machines Corporation | Software model normalization and mediation |
| US8930890B2 (en) | 2006-12-05 | 2015-01-06 | International Business Machines Corporation | Software model skinning |
| US8191044B1 (en) * | 2006-12-14 | 2012-05-29 | Fannie Mae | System and method for maintaining requirements traceability |
| US8473910B2 (en) * | 2007-08-09 | 2013-06-25 | Infonovus Technologies, Llc | Method and system for defining a software application as a complete and consistent specification in a software development process |
| EP2037359A1 (en) * | 2007-09-14 | 2009-03-18 | Siemens Aktiengesellschaft | A method and a system for generating project-related requirements |
| US9098635B2 (en) * | 2008-06-20 | 2015-08-04 | Cadence Design Systems, Inc. | Method and system for testing and analyzing user interfaces |
| EP2329376A1 (en) * | 2008-08-15 | 2011-06-08 | Verum Holding B.V. | A method and system for testing complex machine control software |
| US20100114939A1 (en) * | 2008-10-24 | 2010-05-06 | Schulman Elad | Software test management system and method with facilitated reuse of test components |
| JP5236564B2 (ja) * | 2009-04-20 | 2013-07-17 | 株式会社日立製作所 | ソフトウェア再利用支援方法及び装置 |
| US8448133B2 (en) * | 2009-06-24 | 2013-05-21 | International Business Machines Corporation | Software development, deployment and evolution system, method and program product |
| US20110041116A1 (en) * | 2009-08-14 | 2011-02-17 | Gm Global Technology Operations, Inc. | Formal analysis driven based evolution of requirements specifications |
| US8719771B2 (en) * | 2009-09-28 | 2014-05-06 | Cadence Design Systems, Inc. | Method and system for test reduction and analysis |
| US9703550B1 (en) * | 2009-09-29 | 2017-07-11 | EMC IP Holding Company LLC | Techniques for building code entities |
| US8429605B2 (en) * | 2009-12-30 | 2013-04-23 | The United States Of America As Represented By The Secretary Of The Navy | Finite state machine architecture for software development |
| US8949773B2 (en) * | 2010-03-25 | 2015-02-03 | International Business Machines Corporation | Deriving process models from natural language use case models |
| WO2011149553A1 (en) | 2010-05-27 | 2011-12-01 | The Mathworks, Inc. | Partitioning block diagrams into executable contextual models |
| US10657208B2 (en) | 2010-05-27 | 2020-05-19 | The Mathworks, Inc. | Analyzing model based on design interest |
| US10719645B1 (en) | 2010-05-27 | 2020-07-21 | The Mathworks, Inc. | Model structure analysis with integration of transformed slice |
| US8904358B1 (en) | 2010-06-08 | 2014-12-02 | Cadence Design Systems, Inc. | Methods, systems, and articles of manufacture for synchronizing software verification flows |
| US8799867B1 (en) * | 2010-06-08 | 2014-08-05 | Cadence Design Systems, Inc. | Methods, systems, and articles of manufacture for synchronizing software verification flows |
| US9020792B2 (en) * | 2010-09-17 | 2015-04-28 | International Business Machines Corporation | Coupling architectural and implementation/behavioral models of a computer-based system |
| US8413249B1 (en) * | 2010-09-30 | 2013-04-02 | Coverity, Inc. | Threat assessment of software-configured system based upon architecture model and as-built code |
| US9747187B2 (en) | 2010-10-27 | 2017-08-29 | International Business Machines Corporation | Simulating black box test results using information from white box testing |
| CN102270130A (zh) * | 2011-06-27 | 2011-12-07 | 浙江工业职业技术学院 | 一种运行时自适应软件体系结构的形式化描述方法 |
| US8661305B2 (en) * | 2011-07-10 | 2014-02-25 | Ravishankar Rajarao | Method and system for test vector generation |
| US8972928B2 (en) * | 2011-08-30 | 2015-03-03 | Uniquesoft, Llc | System and method for generating application code |
| US9063673B2 (en) * | 2011-08-30 | 2015-06-23 | Uniquesoft, Llc | System and method for implementing application code from application requirements |
| GB201116440D0 (en) * | 2011-09-23 | 2011-11-02 | Airbus Operations Ltd | Conversion method and system |
| US9977655B2 (en) | 2012-03-20 | 2018-05-22 | Massively Parallel Technologies, Inc. | System and method for automatic extraction of software design from requirements |
| US9324126B2 (en) | 2012-03-20 | 2016-04-26 | Massively Parallel Technologies, Inc. | Automated latency management and cross-communication exchange conversion |
| US8959494B2 (en) | 2012-03-20 | 2015-02-17 | Massively Parallel Technologies Inc. | Parallelism from functional decomposition |
| US8762946B2 (en) | 2012-03-20 | 2014-06-24 | Massively Parallel Technologies, Inc. | Method for automatic extraction of designs from standard source code |
| US9424168B2 (en) | 2012-03-20 | 2016-08-23 | Massively Parallel Technologies, Inc. | System and method for automatic generation of software test |
| US20130317889A1 (en) * | 2012-05-11 | 2013-11-28 | Infosys Limited | Methods for assessing transition value and devices thereof |
| US8806425B1 (en) * | 2012-05-25 | 2014-08-12 | The Boeing Company | Method and apparatus for generating infrastructure code |
| US9146709B2 (en) | 2012-06-08 | 2015-09-29 | Massively Parallel Technologies, Inc. | System and method for automatic detection of decomposition errors |
| US9632754B2 (en) * | 2012-07-06 | 2017-04-25 | International Business Machines Corporation | Auto generation and linkage of source code to test cases |
| US9323650B2 (en) | 2012-07-23 | 2016-04-26 | Infosys Limited | Methods for generating software test input data and devices thereof |
| US9021432B2 (en) | 2013-03-05 | 2015-04-28 | Sap Se | Enrichment of entity relational model |
| US9229688B2 (en) * | 2013-03-14 | 2016-01-05 | Massively Parallel Technologies, Inc. | Automated latency management and cross-communication exchange conversion |
| US9081411B2 (en) * | 2013-05-10 | 2015-07-14 | Sri International | Rapid development of virtual personal assistant applications |
| US9710263B2 (en) * | 2013-09-26 | 2017-07-18 | International Business Machines Corporation | Understanding computer code with human language assistance |
| US9195570B2 (en) | 2013-09-27 | 2015-11-24 | International Business Machines Corporation | Progressive black-box testing of computer software applications |
| JP6185148B2 (ja) * | 2014-03-25 | 2017-08-23 | 株式会社日立製作所 | ソフトウェア仕様間依存関係検証装置、及びソフトウェア仕様間依存関係検証方法 |
| CN105446711B (zh) * | 2014-08-08 | 2018-10-02 | 国际商业机器公司 | 获取用于软件开发任务的上下文信息的方法及装置 |
| US9536093B2 (en) * | 2014-10-02 | 2017-01-03 | Microsoft Technology Licensing, Llc | Automated verification of a software system |
| US10318653B1 (en) | 2015-02-26 | 2019-06-11 | The Mathworks, Inc. | Systems and methods for creating harness models for model verification |
| US10831449B2 (en) * | 2015-04-28 | 2020-11-10 | Lexica S.A.S. | Process and system for automatic generation of functional architecture documents and software design and analysis specification documents from natural language |
| US10733520B2 (en) | 2015-05-13 | 2020-08-04 | Microsoft Technology Licensing, Llc | Making a prediction regarding development of a software product |
| DE102015209715A1 (de) * | 2015-05-27 | 2016-12-01 | Siemens Aktiengesellschaft | Verfahren und System zur rechnergestützten Überführung eines Architektur-Konzepts eines technischen Systems in eine Architekturspezifikation |
| US10346140B2 (en) * | 2015-08-05 | 2019-07-09 | General Electric Company | System and method for model based technology and process for safety-critical software development |
| US9952965B2 (en) | 2015-08-06 | 2018-04-24 | International Business Machines Corporation | Test self-verification with integrated transparent self-diagnose |
| US9720652B2 (en) * | 2015-08-06 | 2017-08-01 | Symphore, LLC | Generating a software complex using superordinate design input |
| US10049337B2 (en) | 2015-08-31 | 2018-08-14 | Salesforce.Com, Inc. | Quantitative metrics for assessing status of a platform architecture for cloud computing |
| US10372421B2 (en) * | 2015-08-31 | 2019-08-06 | Salesforce.Com, Inc. | Platform provider architecture creation utilizing platform architecture type unit definitions |
| US10048946B2 (en) | 2016-03-24 | 2018-08-14 | Microsoft Technology Licensing, Llc | Converting visual diagrams into code |
| GB201611967D0 (en) | 2016-07-08 | 2016-08-24 | Cocotec Ltd | An interoperable extensible system for the generation of verified software |
| CN106201538B (zh) * | 2016-07-18 | 2019-05-31 | 北京航空航天大学 | 一种基于rucm的实时性测试方法 |
| US10331415B2 (en) | 2016-11-08 | 2019-06-25 | International Business Machines Corporation | Formal specification generation using examples |
| US10521197B1 (en) | 2016-12-02 | 2019-12-31 | The Mathworks, Inc. | Variant modeling elements in graphical programs |
| EP3862871A1 (en) * | 2016-12-19 | 2021-08-11 | (Un)Manned N.V. | Method and apparatus for real-time control loop application execution from a high-level description |
| CN106951368A (zh) * | 2017-03-12 | 2017-07-14 | 北京工业大学 | 基于uml时序图的测试用例自动生成方法 |
| CN107066388A (zh) * | 2017-04-19 | 2017-08-18 | 艾瑞克·李 | 软件行为模型面向对象建模方法 |
| US10248385B1 (en) * | 2017-11-30 | 2019-04-02 | International Business Machines Corporation | Extracting mobile application workflow from design files |
| JP6890557B2 (ja) * | 2018-01-17 | 2021-06-18 | 株式会社日立製作所 | 分析モデル作成システム、プログラミング装置および分析モデル作成方法 |
| CN108509339A (zh) * | 2018-03-22 | 2018-09-07 | 京北方信息技术股份有限公司 | 基于浏览器和思维导图的测试用例生成方法、装置及设备 |
| EP3608773A1 (en) * | 2018-08-09 | 2020-02-12 | Audi Ag | Method for providing an automatic software development/generation and deployment functionality in at least one vehicle and corresponding backend server system |
| US11126658B1 (en) * | 2018-09-12 | 2021-09-21 | Amazon Technologies, Inc. | Scalable graph authoring and versioning techniques |
| CN109711710A (zh) * | 2018-12-24 | 2019-05-03 | 浙江蓝卓工业互联网信息技术有限公司 | 一种数据分析模型中组件的排序方法及装置 |
| US10860295B1 (en) * | 2019-01-03 | 2020-12-08 | Amazon Technologies, Inc. | Automated detection of ambiguities in software design diagrams |
| US11144314B2 (en) | 2020-01-17 | 2021-10-12 | Accenture Global Solutions Limited | Systems and methods for software documentation and code generation management |
| US11829689B1 (en) | 2020-06-09 | 2023-11-28 | The Mathworks, Inc. | Systems and methods for creating variant regions in acausal simulation models |
| US11580284B1 (en) * | 2021-01-06 | 2023-02-14 | Cadence Design Systems, Inc. | System, method, and computer program product for finding and analyzing deadlock conditions associated with the formal verification of an electronic circuit design |
| US11675582B2 (en) | 2021-07-15 | 2023-06-13 | Kyndryl, Inc. | Neural networks to identify source code |
| WO2023060306A1 (en) * | 2021-10-15 | 2023-04-20 | SquareBear Technology Pty Ltd | Systems and methods for generating and maintaining work units |
| DE102022118722A1 (de) | 2022-07-26 | 2024-02-01 | Cariad Se | Anpassungsvorrichtung, eingerichtet zur Anpassung eines Betriebs einer Steuervorrichtung eines Fahrzeugs, Verfahren und Fahrzeug |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2147536A1 (en) * | 1994-06-01 | 1995-12-02 | Gerard Johan Holzmann | On-the-fly model checking with partial-order state space reduction |
| US6259969B1 (en) * | 1997-06-04 | 2001-07-10 | Nativeminds, Inc. | System and method for automatically verifying the performance of a virtual robot |
| WO2001022228A1 (en) * | 1999-09-17 | 2001-03-29 | Nortel Networks Limited | System and method for producing a verification system for verifying procedure interfaces |
| US6532554B1 (en) * | 1999-11-29 | 2003-03-11 | Sun Microsystems, Inc. | Network event correlation system using formally specified models of protocol behavior |
| US6681383B1 (en) * | 2000-04-04 | 2004-01-20 | Sosy, Inc. | Automatic software production system |
| WO2002103466A2 (en) * | 2001-01-19 | 2002-12-27 | Engeneos, Inc. | Methods and systems for designing machines including biologically-derived parts |
| US20030033406A1 (en) * | 2001-06-14 | 2003-02-13 | Rekesh John | Apparatus for and a method of network load testing |
| US7694276B2 (en) * | 2003-02-28 | 2010-04-06 | Microsoft Corporation | Contracts and futures in an asynchronous programming language |
| US7543274B2 (en) * | 2003-12-22 | 2009-06-02 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | System and method for deriving a process-based specification |
-
2004
- 2004-05-05 GB GBGB0410047.5A patent/GB0410047D0/en not_active Ceased
-
2005
- 2005-05-05 DE DE602005014970T patent/DE602005014970D1/de active Active
- 2005-05-05 EP EP05742438A patent/EP1749264B1/en not_active Not-in-force
- 2005-05-05 DK DK05742438T patent/DK1749264T3/da active
- 2005-05-05 US US11/579,715 patent/US8370798B2/en active Active
- 2005-05-05 SI SI200530768T patent/SI1749264T1/sl unknown
- 2005-05-05 WO PCT/GB2005/001704 patent/WO2005106649A2/en active Application Filing
- 2005-05-05 ES ES05742438T patent/ES2334041T3/es active Active
- 2005-05-05 AT AT05742438T patent/ATE434216T1/de not_active IP Right Cessation
-
2007
- 2007-08-07 HK HK07108596.4A patent/HK1104100A1/xx not_active IP Right Cessation
-
2012
- 2012-12-21 US US13/724,465 patent/US8943465B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20130117727A1 (en) | 2013-05-09 |
| HK1104100A1 (en) | 2008-01-04 |
| SI1749264T1 (sl) | 2009-12-31 |
| WO2005106649A2 (en) | 2005-11-10 |
| US8370798B2 (en) | 2013-02-05 |
| US8943465B2 (en) | 2015-01-27 |
| EP1749264A2 (en) | 2007-02-07 |
| EP1749264B1 (en) | 2009-06-17 |
| ATE434216T1 (de) | 2009-07-15 |
| DE602005014970D1 (de) | 2009-07-30 |
| US20080263506A1 (en) | 2008-10-23 |
| WO2005106649A3 (en) | 2006-03-23 |
| DK1749264T3 (da) | 2009-10-19 |
| GB0410047D0 (en) | 2004-06-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2334041T3 (es) | Sistema analitico de diseño de software. | |
| US6948154B1 (en) | Methodology for testing spreadsheets | |
| Matallaoui et al. | Model-driven serious game development integration of the gamification modeling language gaml with unity | |
| Dwyer et al. | Formal software analysis emerging trends in software model checking | |
| Ergin et al. | Design pattern oriented development of model transformations | |
| Stephens et al. | Design driven testing: test smarter, not harder | |
| Oortwijn | Deductive techniques for model-based concurrency verification | |
| Nanthaamornphong et al. | Extended ForUML for Automatic Generation of UML Sequence Diagrams from Object‐Oriented Fortran | |
| Rossiter | Simulation design: Trans-paradigm best-practice from software engineering | |
| Cok et al. | SPEEDY: An Eclipse-based IDE for invariant inference | |
| de Carvalho et al. | Business language driven development: joining business process models to automated tests | |
| Signoles | From static analysis to runtime verification with Frama-C and E-ACSL | |
| Caracaş | Modeling, compiling, and efficiently executing business processes on resource-constrained wireless sensor networks | |
| Machado et al. | Automatic test-case generation | |
| Olszewski | Scaling up stepwise feature introduction to construction of large software systems | |
| Hessellund et al. | Interfaces and metainterfaces for models and metamodels | |
| Sharma et al. | CMMI based software metrics to evaluate OOAD | |
| Cabeda | Automated Test Generation Based on an Applicational Model | |
| Bianculli et al. | Software Engineering and Formal Methods | |
| Stapp et al. | Chapter 4 Test Analysis and Design | |
| van der Meijde et al. | A Practical Application of Model Learning and Code Generation | |
| Piho et al. | Test Driven domain modelling | |
| Nagler | Extreme Programming with Perl | |
| Sindhu | Incremental Learning and Testing of Reactive Systems | |
| Acher | Modelling, Reverse Engineering, and Learning Software Variability |