as a PDF

Integración
predecible
La bola de cristal para el software
Magnus Larsson, Anders Wall, Kurt Wallnau
Todo el que trabaja con
ordenadores sabe que, a veces, el
software no se comporta de la forma
prevista. En las oficinas, estos problemas se
suelen resolver sin grandes dificultades, de modo
que se trata más de una molestia que de un obstáculo real. En las aplicaciones industriales, sin embargo, el
asunto es más serio. El mal funcionamiento de una máquina no sólo supone pérdida de producción, sino que
afecta a la calidad y a la seguridad. La gran complejidad
del software hace que algunos errores de los programas
superen las fases de prueba sin ser detectados; los métodos de verificación tradicionales ya no bastan para evaluar todas las situaciones posibles. Los métodos de
desarrollo y verificación basados en modelos matemáticos reducen los riesgos y contribuyen en gran
medida a la gestión de la calidad. La Universidad Carnegie-Mellon y ABB están desarrollando conjuntamente técnicas para
el diseño de software de alta
calidad.
Revista ABB 2/2005
49
Integración predecible
ABB depende del software para poder
entregar soluciones innovadoras a sus
clientes. Los programas a menudo se
ejecutan en entornos con rigurosos requisitos de temporización, seguridad,
fiabilidad y protección. Los fallos del
software en estas aplicaciones resultan
caros y pueden tener resultados catastróficos. Aun así, el gran coste que supone desarrollar programas de alta fiabilidad plantea un reto a todo el sector
del software. La magnitud de los sistemas actuales, por no mencionar los del
futuro, pone en evidencia los grandes
inconvenientes de confiar en la verificación para conseguir una alta garantía
de seguridad. ABB y el Instituto de Ingeniería de Software (SEI, Software Engineering Institute) de la Universidad
Carnegie Mellon han desarrollado un
método para garantizar que el comportamiento de los sistemas durante el
tiempo crítico de ejecución sea predecible gracias a la construcción misma.
Esto reducirá los costes de verificación
y acelerará la comercialización de los
nuevos programas con garantía de seguridad.
Con frecuencia se ha dicho que los tres
principios fundamentales de la programación son modularidad, modularidad
y modularidad. Pronto se dirá también
que los tres principios fundamentales
de la ingeniería del software son restricción, restricción y restricción.
Las restricciones están en el núcleo de
todas las disciplinas de ingeniería. Todo nuevo problema técnico puede presentar desafíos singulares, pero el ingeniero especializado sabe cómo reducir
los nuevos problemas a una forma en
que sean resolubles con técnicas probadas y bien definidas. Estas técnicas
imponen restricciones tanto al problema por resolver como a la forma que
1
pueden adoptar las soluciones. La pérdida de libertad que imponen las restricciones se compensa sobradamente,
ya se hace posible resolver de forma
rutinaria y predecible clases completas
de problemas.
En ingeniería de software, la cuestión a
menudo no está en los programas en
sí, sino en las redes de programas
interactivos a gran escala. A esta escala
surgen desafíos técnicos que van mucho más allá de la corrección funcional
(el texto de la programación) y abarcan
calidades no funcionales igualmente
cruciales (a veces llamados “atributos
de calidad”), tales como seguridad, rendimiento, disponibilidad, tolerancia a
los fallos, etc. Un reto esencial para la
investigación en ingeniería de software
es proporcionar los medios para que
los ingenieros construyan rutinariamente sistemas que tengan una calidad no
funcional predecible. En consecuencia,
estas técnicas imponen restricciones al
diseño de los sistemas futuros de software.
Este artículo muestra cómo pueden introducirse “restricciones inteligentes”
en la práctica del desarrollo del software para que los sistemas de programas
presenten una calidad predecible. Se
pueden integrar restricciones inteligentes en la infraestructura del software
para que los sistemas sean predecibles
por construcción; los ensayos de verificación de la calidad del software pueden tener sus días contados. Además,
la predecibilidad por construcción se
puede utilizar para imponer estándares
de calidad objetivos y mensurables para el software de terceros; estos estándares tienen gran utilidad predictiva.
Predecible por construcción
El enfoque adoptado en este artículo se
basa en dos premisas:
Lenguaje de contenedores
Conector estándar
Propiedades certificadas
Componente de software
Contenedores prefabricados
Interfaz estímulo
Interfaz estándar
Código de cliente
Componente estándar
de interfaz de tiempo
de ejecución
Restricciones a
la interacción
Entorno del tiempo de ejecución
del componente
Plataforma ( hardware / OS )
50
Sólo comportamiento reactivo
Ciclo de vida estándar
Tiempo estándar de ejecución
1) Las restricciones inteligentes conducen a sistemas con cualidades de
tiempo de ejecución predecibles.
2) La tecnología de componentes empaqueta restricciones que hacen predecible por construcción el software.
Presentamos algunas ideas que ayudarán a comprender el sentido de estas
premisas: una cualidad de tiempo de
ejecución se ha de definir en términos
de observaciones que puedan efectuarse sobre trazas de ejecución. Una cualidad de tiempo de ejecución es predecible si existe, y sólo si existe, una teoría
(regla) que prevea futuras observaciones. El aspecto crucial aquí es que la
calidad se define en relación con una
teoría predictiva y que esta teoría ha de
generar confianza sobre las predicciones deducidas de la misma.
Esta idea no es nueva, ni en la ciencia
ni en el software. El comportamiento
de temporización de un sistema de
software puede ser predecible aplicando la teoría de programación monotónica de velocidad generalizada o teoría
de colas de espera en tiempo real. Ambas teorías (en general, todas las teorías) establecen suposiciones sobre los
sistemas que son su objeto, y todo sistema que satisfaga estas suposiciones
es predecible en estas teorías. Las restricciones inteligentes garantizan la
satisfacción de estas suposiciones, es
decir, son inteligentes porque se basan
en teorías predictivas.
Una cosa es definir una restricción inteligente y otra muy distinta garantizar el
cumplimiento de la misma. En 1 se
describe un lenguaje de tecnología de
componentes recurrentes que es particularmente eficaz para empaquetar restricciones inteligentes.
En este lenguaje, el software personalizado se despliega en contenedores prefabricados [1]. Un contenedor restringe
la visibilidad del código específico hacia su entorno externo, y la visibilidad
desde el entorno externo hacia el código específico. Diferentes tipos de contenedores pueden desempeñar funciones distintas en un esquema de coordinación global (definido por la arquitectura). En este lenguaje, un componente
del software es un contenedor combinado con un código específico. Los
componentes son rigurosamente reactivos: sólo reaccionan a los estímulos recibidos por la interfaz del contenedor y
sólo responden a través de dicha interfaz. Un entorno de tiempo de ejecución
de componentes proporciona mecanismos de coordinación (o “conectores”) e
implementa otros criterios para la gesRevista ABB 2/2005
Integración predecible
Revista ABB 2/2005
se si queremos que sus efectos sean
predecibles. Una tecnología de componentes impone un empaquetamiento
estándar del software; esto incluye la
forma de especificar los componentes y
los detalles de implementación de componentes que han de ser expuestos por
los proveedores. En conjunto, estas
consideraciones proporcionan una base
práctica para establecer estándares ob-
ningún trabajo anterior ha generalizado
estas ideas para múltiples atributos no
funcionales, ni ha enfatizado el papel
de la validación y certificación en la
medida en que lo ha hecho el trabajo
que presentamos en este artículo.
Calidad certificable
Las teorías analíticas revelan qué propiedades del software han de conocer-
Interpretación
opPos
OPC 0
gateway 8
opPos
0
1
opSel
CSWI
opSel
swSboPos swSboPos
2
0
3
1
swSboSel swSboSel
swDoPos
2
1
Signal
0
0
CLK
3
SwPos
SwSel
SwPos SwPos
6
0
swMonSink
7
1
SwSel
SwSel
XCBR
SwPos
SwSel
2
4
3
5
BrPos
V
SwPos
BrPos
0
4
Signal
1
5
SwSel
BrPos
C
2
BrTrip
0
C
V
0
TCTR
1
TVTR
1
PIOC
0
C
V
C
1
3
BrTrip
C
2
swDoPos
4
C
0
1
OPCgateway
2
swMonSource
tión de los recursos compartidos por
componentes.
La cuestión concreta es que el usuario
no debe estar vinculado de forma fija a
una determinada tecnología de componentes: son posibles muchas implementaciones del lenguaje y frecuentemente
se pueden realizar implementaciones
sencillas. Lo importante es que los tipos de contenedores y de conectores,
el entorno del tiempo de ejecución y la
capacidad para imponer restricciones
en patrones admisibles de interacción
de componentes puedan utilizarse para
codificar o empaquetar restricciones inteligentes. Además, el pequeño número
y la uniformidad de las abstracciones
en este lenguaje simplifican considerablemente la tarea de automatizar partes
sustanciales del proceso de construcción y predicción, proporcionando así
la deseada predecibilidad por construcción.
La idea es simple y para entenderla
bien lo mejor es hacer una analogía.
Un compilador Java o C# comprueba
que los programas están bien creados,
es decir que un programa determinado
cumple la teoría del tipo de lenguaje
de programación. Si se satisface esta
restricción, el compilador garantiza entonces ciertas propiedades de ejecución
del programa (las propiedades de seguridad, en términos técnicos). En nuestro caso se aplica la misma idea, pero
no a los programas sino al ensamblaje
de los componentes. En lugar de teorías de tipos tenemos teorías de comportamientos para cualidades no funcionales de tiempo de ejecución.
En lugar de especificaciones en un lenguaje de programación se utilizan especificaciones en un lenguaje de descripción de la arquitectura (CCL [4]). En
efecto, CCL formaliza el lenguaje de
contenedores y hace posible la predicción y generación automatizada de códigos. El resultado es la predecibilidad
por construcción. Si se han creado correctamente las especificaciones en CCL
de acuerdo con el lenguaje de los contenedores y éstas satisfacen las restricciones específicas adicionales de estructuras de razonamiento, los sistemas
que especifiquen serán predecibles por
construcción. La expresión definitiva
de la predecibilidad por construcción
consiste en crear únicamente sistemas
cuyos comportamientos puedan predecirse.
Otros proyectos de ABB ya han explotado la afinidad de la tecnología de
componentes con el comportamiento
predecible de carácter no funcional,
por ejemplo PECOS [13]. Sin embargo,
5
MMXU 2
W
V
W
V
6
IEC61850 like controller
λaba Interpretation
λaba Simulation Model
Trace
Recorder
0
C
S
Task
Count
V
1
2
3
1
Task
End
Subtask
#
C
p
L
CPU
#
Exit
(4)
T
AvgL
X
1
Tp
0,95
4
+
Up
1
Ap. QL Sum
SS FP
CPU
2
0
C
Count
V
1
2
3
1
taskld
S
#
SSTask
QL
Trace
Recorder
Trace
Recorder
#
SS
Subtask
C
p
CPU
SSTask
End
L
Q
T
AvgL
Exit
(4)
30
2
200
1
File
Out
now
51
Integración predecible
jetivos de calidad para el software de
terceros.
Para ilustrar el tema se considera la
predicción del comportamiento de temporización de conjuntos de componentes utilizando la teoría de Lehoczky sobre colas de espera en tiempo real [2].
Entre otras cosas, esta teoría asume:
una disciplina de programación
como, por ejemplo, EDF (“Earliest
Deadline First”, en primer lugar el
plazo más temprano),
la identificación de entidades programables, como los encadenamientos,
y
el segundo momento de tiempo de
servicio previsto de cada entidad
programable.
La primera propiedad es satisfecha por
el entorno del tiempo de ejecución del
componente y la segunda por los contenedores. Sin embargo, la tercera ha
de ser satisfecha por el proveedor del
componente. Conviene señalar algunos
aspectos de esta ilustración. En primer
lugar, lo que ha de conseguirse es una
medición exacta del segundo momento
del tiempo de servicio; esto corresponde a las “propiedades certificadas” mostradas en 1 . Aunque podría ser deseable imponer requisitos a los valores
que puedan tomar estas mediciones,
este aspecto se considera una cuestión
aparte. En segundo lugar, la teoría del
rendimiento es necesaria para proporcionar una definición precisa de la medición; también puede proporcionar
una guía firme del propio proceso de
medición.
Evidentemente, la búsqueda de un software fiable no finaliza cuando se consigue una calidad certificable. Para alcanzar la fiabilidad se requiere un planteamiento de más envergadura, que exige
mejoras en tecnología y procesos de
software y también en procesos sociales [10] [12]. No obstante, el método
3
presentado en este artículo es un primer paso hacia el establecimiento de
estándares de calidad que sean objetivos y predictivos. En particular, merece
la pena observar el método descrito directamente con dispositivos de software, en vez de hacerlo indirectamente,
por ejemplo a través de mediciones de
la madurez del proceso de las organizaciones desarrolladoras.
Aplicación de ABB
ABB y SEI (Software Engineering Institute, de la Universidad Carnegie Mellon) probaron por primera vez la viabilidad de la predecibilidad por construcción en el campo de automatización de subestaciones [3]. Este trabajo
produjo tres resultados principales.
1) Se demostró cómo el CEI61850, un
estándar en el campo de la energía,
se puede correlacionar con una tecnología de componentes de software. Se especificaron en lenguaje
CCL diversos componentes y conjuntos que cumplen el estándar
CEI61850. Este resultado, menor en
sí mismo, sirvió como base para
enlazar más directamente el estándar
y los sistemas de software que lo
implementan.
2) Se desarrolló la estructura de razonamiento λaba (“λ” significa tiempo
de latencia y “aba” “caso medio, con
interacciones asíncronas y de bloqueo”) para predecir la latencia del
caso medio de ensamblajes de protección y control CEI61850. λaba utiliza restricciones inteligentes para
garantizar que se satisfagan varias
suposiciones fundamentales de análisis monotónico de velocidad generalizada [5].
El mecanismo de predecibilidad por
construcción se muestra en 2 . Un
ensamblaje CEI61850 se describe en
la notación gráfica de CCL ( 2 , parte
superior). Si el ensamblaje está bien
construido para Ïaba, se crea una
“vista de funcionamiento” analizable
( 2 , parte inferior). Obsérvese que
CCL se basa en abstracciones familiares para los ingenieros que utilizan bloques funcionales CEI61131 o
UML. De hecho, CCL se puede sustituir por cualquier número de notaciones de diseño.
3) Se demostró la eficiencia de una técnica para la rigurosa validación empírica de la fuerza predictiva de Ïaba
o de cualquier otra estructura de razonamiento destinada a predecir el
comportamiento de temporización
[6]. La técnica utiliza la generación
de ensamblajes aleatorios restringidos para construir muestras representativas en un dominio de aplicación y, a partir de ellas, crear intervalos de confianza (o tolerancia) estadística que sean útiles para inferir
la exactitud de las predicciones futuras. En efecto, esta etiqueta estadística sirve para certificar la propia estructura de razonamiento. En 3 y [7]
se discute cómo se interpretan las
etiquetas estadísticas.
ABB y el SEI transfirieron las conclusiones de este experimento inicial al
ámbito del control de robots industriales. Este trabajo ha dado dos resultados
importantes que es necesario comunicar. El primero se refiere a la pregunta
siguiente: ¿Es posible ampliar de forma
segura un sistema de control en riguroso tiempo real, por medio de software
de terceros y con comportamiento estocástico de ejecución, garantizando al
mismo tiempo un óptimo servicio para
la ampliación? En resumen, ¿es posible
"abrir" un duro sistema de control en
tiempo real y no obstante proporcionar
firmes garantías de tiempo? Para responder a esta pregunta se desarrolló la
estructura de razonamiento λss (“λ” por
tiempo de latencia, “ss” por “servidor
Estructura de razonamiento certificada
Nivel estándar para teorías de latencia
Predicción Facts
para λ* ( análisis de latencia )
Medición estándar de interferencia estadística
Intervalo de confianza
Parámetro de población: 8 de cada 10 conjuntos pueden tener comportamiento predecible
Proporción† (ρ)
80 %
Parámetro de confianza: tenemos una confianza
> 99 % en que el límite superior es correcto
Límite superior (ub)
< 1%
Confianza (γ)
99,29 %
Valores basados en una muestra de 75
conjuntos, 156 tareas y 2.952 trabajos
†
Límite superior: la latencia actual puede
diferir de la latencia predicha en < 1 %
Muestra: detalle importante pero no
exhaustivo sobre cómo interpretar el nivel
Versión 1
52
Revista ABB 2/2005
Integración predecible
La verificación descubrió una violación
(o “contraejemplo” en el vocabulario
de comprobación de modelos) de la
tercera propiedad. Los ingenieros de
producto confirmaron que el contraejemplo era sin duda un problema, pero
éste había sido diagnosticado y reparado en una versión posterior del código.
Lo extraordinario, sin embargo, es que
el problema, aunque se sospechaba
que existía, había permanecido oculto
durante varios años. Visto retrospectiRevista ABB 2/2005
vamente no sorprende este hecho,
pues es bien conocido que los errores
de concurrencia en software son difíciles de reproducir. Esto se refleja también en algunas estadísticas sobre este
ejercicio particular de comprobación de
modelos.
El espacio de estados de sólo las
partes relevantes del código fue
≅101932 estados después de la abstracción.
El estado de error surgió en la interacción número 179 entre encadenamientos de comunicación.
Estas cifras muestran que era muy improbable que un método de verificación convencional hubiera descubierto
el error.
Desde que se realizó este trabajo, la estructura de razonamiento de comprobación de modelos ComFoRT ha seguido
desarrollándose. ComFoRT explota tecnología de componentes de software e
implementa diversas técnicas complementarias que reducen la complejidad
del estado tecnológico actual [9] [11].
El mayor reto de la tarea de verificación IPC –un desafío con el que se enfrenta todo aquél que utilice comprobadores de modelos de la generación
actual- es producir modelos que sean
abstracciones válidas del sistema bajo
examen. Una característica fundamental
de ComFoRT es la generación totalmente automática de modelos abstractos y válidos a partir de especificaciones de diseño CCL 5 . Esta es una de
las características de ComFoRT que
sirven para facilitar a los programadores e ingenieros de software el uso de
la comprobación de modelos.
Conclusiones
El ensamblaje predecible no es una solución universal para la calidad del
software. Ha de encajar dentro de una
estrategia global de calidad basada en
procesos acreditados de desarrollo del
software, en desarrolladores de software competentes y motivados, en estándares de arquitectura bien documenta-
5
4
Tiempo de latencia predecible de plug-in
Latency in milliseconds ( E [ W ] )
esporádico”). λss utiliza contenedores
de servidores esporádicos como restricción inteligente fundamental [8]. El contenedor de servidores aleatorios protege las tareas periódicas contra ráfagas
estocásticas. La estructura de razonamiento permite “abatir” de forma efectiva todo el comportamiento periódico
en un efecto periódico neto y luego
utiliza este efecto neto en una familia
de ecuaciones de colas de espera para
establecer límites al tiempo medio de
servicio de los módulos 4 . El resultado
final es que se garantiza que los plugins sólo puedan invadir de forma limitada y predecible el comportamiento
de temporización periódica, tengan
acceso garantizado al procesador y presenten una latencia predecible.
El segundo resultado demostró hasta
qué punto ha progresado la comprobación de modelos de software en los
últimos años (véase glosario en página
54), y su potencial para seguir avanzando si se combina eficazmente con el
desarrollo basado en componentes. La
comprobación de modelos es especialmente eficaz para verificar de forma
demostrable el correcto comportamiento del software concurrente y reactivo,
el tipo de software predominante en la
automatización industrial. El código IPC
(Inter-Process Communication) de comunicación entre procesos de un controlador de robots fue sometido a un
comprobador de modelos usual en el
mercado. Las propiedades comprobadas son típicas del código IPC:
Cuando se envía un mensaje a X, X
recibe ese mensaje (excluyendo los
tiempos de espera).
Cuando se envía un mensaje a X, Y
no recibe ese mensaje.
Cuando un emisor recibe una respuesta, ésta corresponde al último
mensaje enviado.
Un emisor nunca es bloqueado
mientras trata de escribir en una cola
de mensajes no llena.
Los mensajes (o las respuestas) nunca se escriben en un slot desconectado.
100
90
80
70
60
50
40
30
20
0
0.2
0.4
0.6
0.8
1
Periodic Utilization (Up)
Tp = 1
Tp = 100000
dos y en una cultura de la excelencia.
Teniendo esto bien presente podemos
sacar algunas conclusiones sobre la viabilidad de este método para los negocios de ABB.
Nuestra conclusión principal es que la
premisa en que se basa este trabajo
–utilizar restricciones inteligentes con
fines de predecibilidad y empaquetar
restricciones inteligentes en tecnología
de componentes– es válida y útil. La
premisa no depende de una determinada elección de la tecnología de componentes, especificaciones o análisis.
Aunque no todas las opciones tecnológicas serán igualmente eficaces, este
trabajo resalta lo más importante de
cada una de ellas, si han de servir al
objetivo de obtener la predecibilidad
por construcción.
No obstante, antes de poder adoptar la
tecnología de predecibilidad por construcción se han de satisfacer varias condiciones:
1) La organización ha de tener control
sobre las decisiones de diseño de la
arquitectura del software. Existen
disyuntivas entre predecibilidad y
libertad de diseño; una organización
que no pueda imponer o reducir
restricciones en el diseño se verá
limitada al tomar estas decisiones
esenciales de elección de técnicas.
Los sistemas ya existentes también
Construcción automatizada de modelos de ComFORT utilizando la depuración
de abstracciones guiada por contraejemplos
Modelo completo
demanda ϕ
Abstracción
del predicado
Perfeccionamiento
del predicado
Modelo abstracto
ϕ
Funcionamiento
en falso
Contraejemplo
Prueba
del modelo
ϕ verdadero
Contraejemplo
ϕ falso
¿Funcionamiento
en falso?
Contraejemplo
53
Integración predecible
plantean retos que restringen tales
alternativas.
2) La calidad predecible ha de tener
valor real. Esta afirmación puede parecer vacua, pero no lo es. Algunos
sistemas de información de gestión,
por ejemplo, tienen una tolerancia
de diseño “poco estricta” para el
comportamiento de la latencia. Unas
predicciones muy precisas de temporización pueden no tener gran valor en nuestro caso, aunque podrían
tenerlo las de seguridad. Un controlador integrado, sin embargo, podría
tener una tolerancia “estricta” de
diseño para el comportamiento de
temporización.
La parte más costosa de la infraestructura técnica para la predecibilidad por
construcción es la estructura validada
de razonamiento. Algunos elementos,
como las tecnologías de componentes
y especificaciones, son fundamentales
pero no son un gran desafío técnico. La
lección que podemos aprender es que,
probablemente, las estructuras de razonamiento serán más importantes para
ABB que esos otros elementos y po-
drán desempeñar una función importante en el establecimiento de estándares “inteligentes” de diseño empresarial.
Los trabajos actuales
Los trabajos se concentran actualmente
en la búsqueda de un sistema suave y
predecible de protección y control (Soft
P&C) en el campo de la automatización
de subestaciones. Soft P&C es en esencia un sistema completo de automatización de subestaciones que se implementa en un ordenador centralizado,
más o menos estándar, sin hardware
propio de un determinado fabricante.
Hoy es tecnológicamente posible construir tal sistema. Sin embargo, hacen
falta pruebas para convencer a los
clientes de que esta solución cumple
los requisitos esenciales de calidad,
como son el rendimiento y la fiabilidad. Los conceptos presentados en este
artículo pueden proporcionarlas.
certificables. Esta colaboración ha sido
beneficiosa para ambas partes.
CMU/SEI ha conseguido un contexto
industrial para desarrollar su tecnología, que más tarde se puede adaptar a
una clase más amplia de problemas
análogos. ABB disfruta de la ventaja de
ser pionero en la aplicación de tecnologías que abren nuevas vías a la predicción de atributos de calidad en sistemas complejos de software.
Dr. Magnus Larsson
Dr. Anders Wall
ABB AB, Corporate Research
Västerås, Suecia
[email protected]
Colaboración ABB-MU
ABB Corporate Research y SEI empezaron a trabajar juntos en 2001 en el ensamblaje predecible con componentes
Kurt Wallnau
Software Engineering instiitute
Carnegie Mellan University
Glosario
Traza de ejecución: Secuencia de cambios que ocurren en un sistema o componente, observada a lo largo del tiempo.
Comprobador de modelos: Herramienta de software que realiza la comprobación de modelos.
Comprobación de modelos: Enfoque con el que se examinan exhaustivamente todas las posibles trazas de ejecución de un sistema (hardware o software) para verificar
que se conservan determinadas propiedades; si no se examinan exhaustivamente todas las trazas posibles, esto se debe a que la abstracción analítica revela que no
proporcionan nueva información (por ejemplo, debido a simetrías, relevancia o repetición).
Espacio de estados: Un estado es un valor que el conjunto de variables de un sistema puede asumir durante la ejecución. Por ejemplo, un conmutador simple puede
asumir dos estados: ON u OFF. El conjunto de todos los estados que puede asumir un sistema se llama espacio de estados, cuyo tamaño aumenta con la complejidad
del sistema y, concretamente, de forma exponencial con el número de variables del sistema. Cuando un sistema tiene muchas variables, el número de estados crece de
tal modo que el comprobador de modelos ya no puede analizarlos en tiempo útil ni almacenarlos físicamente. Este desafío se denomina explosión de estados. Los comprobadores de modelos utilizan poderosos mecanismos de abstracción para reducir la explosión de estados. Los modernos comprobadores de modelos pueden verificar
sistemas muy grandes con gran rapidez.
UML: Lenguaje de modelado unificado, un formalismo muy utilizado para la descripción y especificación del software.
References:
[1] Ward-Dutton, N., “Containers: A sign components are growing up.” Application Development Trends, pp 41–46, Jan 2000.
[2] Lehoczky, J. P., “Real-time queuing theory,” in Proceedings of the IEEE Real-Time Systems Symposium, 186–195, IEEE, New York, 1996.
[3] Hissam et. al., Predictable Assembly of Substation Automation Systems: An Experiment Report, Second Edition, Technical Report CMU/SEI-2002-TR-031,
www.sei.cmu.edu/publications/documents/02.reports/02tr031.html
[4] Wallnau, K., Ivers, J., Snapshot of CCL: A Language for Predictable Assembly, Technical Note CMU/SEI-2003-TN-025,
www.sei.cmu.edu/publications/documents/03.reports/03tn025.html
[5] Klein et. al., A Practitioner’s Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993.
[6] Larsson M., Predicting Quality Attributes in Component-based Software Systems, Ph. D thesis Mälardalen University Press, ISBN 91-88834-33-6
[7] Moreno, G., Hissam, S. Wallnau, K. “Statistical Models for Empirical Component Properties and Assembly-Level Property Predictions: Toward Standard Labeling,”
in the 5th ICSE Workshop on Component-Based Software Engineering, May 2002, www.preview.sei.cmu.edu/pacc/CBSE5/Moreno-cbse5-final.pdf
[8] Hissam et. al., Performance Property Theories for Predictable Assembly from Certifiable Components, Technical Report CMU/SEI-2004-TR-017,
www.sei.cmu.edu/publications/documents/04.reports/04tr017.html
[9] Ivers, J., Sharygina, N., Overview of ComFoRT: A Model Checking Reasoning Framework, Technical Note CMU/SEI-2004-TN-018,
www.sei.cmu.edu/publications/documents/04.reports/04tn018.html
[10] Meyer, B. “The Grand Challenge of Trusted Components,” 660–667. Proceedings of the 25th International Conference on Software Engineering (ICSE).
Portland, Oregon, May 3-10, 2003. Los Alamitos, CA: IEEE Computer Press, 2003.
[11] Clarke, E., Kroening, D., Sharygina, N., Yorav, K., “Predicate Abstraction of ANSI-C Programs Using SAT,” in Formal Methods in System Design, 25, 105–127,
2004, Kluwer Academic Publishers.
[12] Wallnau, K., Software Component Certification: 10 Useful Distinctions, Technical Note CMU/SEI-2004-TN-031,
http://www.sei.cmu.edu/publications/documents/04.reports/04tn031.html
[13] Nierstrasz, O., et al, “A Component Model for Field Devices” Proceedings First International IFIP/ACM Working Conference on Component Deployment, ACM,
Berlin, Germany, June 2002. See also http://www.pecos-project.org/
54
Revista ABB 2/2005