Hispanopedia Wiki
Articulo de referencia

Árbol de comportamiento

Construyendo un sistema a partir de sus requisitos: perspectiva dinámica Construyendo un sistema a partir de sus requisitos: vista estática Un árbol de comportamiento es una téc...

Hispanopedia WikiContenido en espanolLectura gratuita

Construyendo un sistema a partir de sus requisitos: perspectiva dinámica
Construyendo un sistema a partir de sus requisitos: vista estática

Un árbol de comportamiento es una técnica de modelado visual estructurado que se utiliza en la ingeniería de sistemas y la ingeniería de software para representar el comportamiento de un sistema. Utiliza un diagrama de árbol jerárquico compuesto por nodos y conectores para ilustrar el flujo de control y las acciones del sistema. Al reemplazar las descripciones ambiguas del lenguaje natural con elementos visuales estandarizados —como cajas, flechas y símbolos estándar—, los árboles de comportamiento mejoran la claridad, reducen las malas interpretaciones y facilitan la comprensión de sistemas complejos. [ 1 ]

Descripción general

La gran cantidad de detalles que implica describir los numerosos requisitos de un sistema a gran escala utilizando lenguaje natural puede provocar una sobrecarga de memoria a corto plazo , [ 2 ] [ 3 ] lo que dificulta una comprensión integral de las necesidades del sistema. [ 4 ] El lenguaje natural a menudo introduce ambigüedades, alias, inconsistencias, redundancias e información incompleta en los conceptos. [ 5 ] Esto crea incertidumbre y complica excesivamente los sistemas.

La representación en árbol de comportamiento intenta eliminar la incertidumbre limitando el vocabulario a los requisitos originales. Los conjuntos de requisitos extensos pueden requerir la ayuda de una representación en árbol de composición [ 6 ] que resuelve alias y otros problemas de vocabulario en un paso previo. El objetivo es producir una representación profunda, precisa y holística de las necesidades del sistema [ 2 ] que pueda ser comprendida por todos los lectores (a menudo las partes interesadas ). Dado que la notación en árbol de comportamiento utiliza semántica formal , puede servir como entrada para un procesamiento posterior, como la creación de un ejecutable para un conjunto dado de requisitos.

Formas de árbol de comportamiento

Conjunto de cuatro árboles de comportamiento de requisitos
Proceso de integración de requisitos

Tanto las formas de árbol de comportamiento simples como las integradas (compuestas) son importantes para la aplicación de árboles de comportamiento en la ingeniería de sistemas y software .

  • Árboles de comportamiento de requisitos (RBT): Inicialmente, se construyen árboles de comportamiento de requisitos individuales para capturar todos los fragmentos de comportamiento de cada requisito en lenguaje natural, utilizando un proceso de traducción riguroso que preserva tanto la intención como el vocabulario. Este proceso de traducción puede revelar una serie de defectos en los requisitos originales en lenguaje natural .
  • Árboles de comportamiento integrados (TCI): Dado que un conjunto de requisitos implica el comportamiento integrado de un sistema, todos los árboles de comportamiento de requisitos individuales pueden combinarse para construir un árbol de comportamiento integrado que proporciona una visión holística única del comportamiento integrado emergente del sistema. Esto permite la construcción del comportamiento integrado del sistema a partir de sus requisitos. [ 7 ] Una analogía para ayudar a describir este proceso es la transición de un conjunto de piezas de un rompecabezas dispuestas al azar a colocar cada pieza en su lugar correspondiente. Cuando esto sucede, cada pieza de información se ubica en su contexto previsto y sus propiedades emergentes colectivas se vuelven claras.

Convertir todos los requisitos en árboles de comportamiento (RBT) es similar a tener todas las piezas de un rompecabezas esparcidas al azar sobre una mesa: hasta que todas las piezas estén conectadas, la imagen emergente permanece poco clara y no se sabe con certeza si faltan piezas o si alguna no encaja. La construcción de un árbol de comportamiento integrado (IBT) revela el comportamiento emergente y las piezas faltantes. [ 8 ] [ 5 ]

proceso de ingeniería del comportamiento

A continuación se enumeran los aspectos críticos de la representación y el proceso de ingeniería del comportamiento.

Representación:

  • La función del árbol de composición en el proceso general es proporcionar un medio para superar el conocimiento imperfecto asociado con el amplio conjunto de requisitos de un sistema.

Proceso:

  • La ingeniería del comportamiento utiliza árboles de comportamiento para controlar la complejidad al tiempo que fomenta una comprensión compartida de un sistema complejo.
  • Una comprensión holística compartida de un sistema complejo integra los requisitos para mostrar su comportamiento emergente implícito.

Historia

Los árboles de comportamiento y los conceptos para su aplicación en ingeniería de sistemas y software fueron desarrollados originalmente por Geoff Dromey. [ 8 ] [ 5 ] [ 9 ] [ 10 ] La primera publicación de algunas de las ideas clave fue en 2001. [ 11 ] Las primeras publicaciones sobre este trabajo utilizaron los términos "ingeniería de software genética" y "diseño genético" para describir la aplicación de los árboles de comportamiento. La razón para usar originalmente la palabra "genético" fue porque los conjuntos de genes, los conjuntos de piezas de rompecabezas y los conjuntos de requisitos, cuando se representan como árboles de comportamiento, parecen compartir varias propiedades clave:

  • En conjunto, contenían suficiente información como para permitir su composición; con los árboles de comportamiento, esto permite construir un sistema a partir de sus requisitos.
  • El orden en que se ensamblaban las piezas no era importante; en función de los requisitos, esto ayuda a afrontar la complejidad.
  • Cuando se reunieron todos los miembros del conjunto, la entidad integrada resultante exhibió un conjunto de importantes propiedades emergentes .

Para los árboles de comportamiento, las propiedades emergentes importantes incluyen:

  • El comportamiento integrado del sistema está implícito en los requisitos.
  • En los requisitos se hace referencia al comportamiento coherente de cada componente.

Estos paralelismos genéticos, en otro contexto, fueron descritos originalmente por Adrian Woolfson. [ 12 ] [ 13 ]

A pesar de estos legítimos paralelismos genéticos, se consideró que este énfasis generaba confusión con el concepto de algoritmos genéticos . En consecuencia, se introdujo el término ingeniería del comportamiento para describir los procesos que aprovechan los árboles de comportamiento para construir sistemas.

Desde que se concibió originalmente la notación de árbol de comportamiento, varias personas del Grupo de Sistemas Computacionales Complejos Confiables (DCCS, un grupo de investigación conjunto de la Universidad de Queensland y la Universidad de Griffith ) han realizado importantes contribuciones a la evolución y el perfeccionamiento de la notación y el uso del árbol de comportamiento. [ 14 ]

Investigadores como Rob Colvin, Lars Grunske y Kirsten Winter del DCCS han desarrollado árboles de comportamiento temporizados probabilísticos para poder expresar la fiabilidad, el rendimiento y otras propiedades de confiabilidad . [ 15 ]

Conceptos clave

Notación de árbol de comportamiento

Elementos centrales de la notación del árbol de comportamiento

Un árbol de comportamiento se utiliza para representar formalmente el fragmento de comportamiento en cada requisito. En general, el comportamiento de un sistema a gran escala, donde se admite la concurrencia , aparece abstractamente como un conjunto de procesos secuenciales que se comunican entre sí . La notación de árbol de comportamiento captura estos estados de componentes compuestos y los representa en forma de árbol.

Las etiquetas de trazabilidad (véase la Sección 1.2 de la notación del árbol de comportamiento [ 16 ] ) en los nodos del árbol de comportamiento vinculan la representación formal con el requisito correspondiente en lenguaje natural . [ 17 ]

Un árbol de comportamiento con nodos hoja puede revertir (simbolizado añadiendo el operador de intercalación "^") a un nodo ancestro para repetir el comportamiento o iniciar un nuevo hilo (simbolizado por dos intercalaciones "^^").

Para una referencia completa a la notación de árbol de comportamiento, consulte Notación de árbol de comportamiento v1.0 (2007). [ 16 ]

Semántica

La semántica formal de los árboles de comportamiento se da a través de un álgebra de procesos y su semántica operacional . [ 18 ] La semántica se ha utilizado como base para el desarrollo de simulación , verificación de modelos y análisis de modos y efectos de falla . [ 18 ] [ 19 ] [ 20 ]

Traducción de requisitos

Ejemplo de traducción de requisitos
Integración del árbol de comportamiento de requisitos

Integración de requisitos

Operaciones en árboles de comportamiento integrados

Una vez que se ha compuesto un árbol de comportamiento integrado, existen varias operaciones importantes que se pueden realizar sobre él.

Inspección: detección y corrección de defectos

En general, muchos defectos se hacen mucho más visibles cuando existe una visión integrada de los requisitos [ 2 ] y cada requisito se ha ubicado en el contexto de comportamiento donde debe ejecutarse. Por ejemplo, es mucho más fácil determinar si un conjunto de condiciones o eventos que emanan de un nodo es completo y coherente. Las etiquetas de trazabilidad [ 16 ] también facilitan la referencia a los requisitos originales en lenguaje natural. Además, existe la posibilidad de automatizar varias comprobaciones de defectos y coherencia en un árbol de comportamiento integrado. [ 21 ]

Cuando se han corregido todos los defectos y el IBT es lógicamente consistente y completo, se convierte en un árbol de comportamiento del modelo (MBT), que sirve como una especificación formal para el comportamiento del sistema que se ha construido a partir de los requisitos originales. Este es el punto de parada claramente definido para la fase de análisis. Con otras notaciones y métodos de modelado (por ejemplo, UML ), no está tan claro cuándo se puede detener el modelado. [ 22 ] En algunos casos, partes de un árbol de comportamiento del modelo pueden necesitar ser transformadas para hacer que la especificación sea ejecutable . Una vez que un MBT se ha hecho ejecutable, es posible realizar una serie de otras comprobaciones de confiabilidad.

Simulación

Se puede simular fácilmente un árbol de comportamiento del modelo para explorar las propiedades dinámicas del sistema. Se han desarrollado tanto una herramienta simbólica como una herramienta gráfica para apoyar estas actividades. [ 23 ] [ 24 ]

Verificación de modelos

Se ha escrito un traductor para convertir un árbol de comportamiento de modelo al lenguaje de "sistemas de acciones". Esta entrada se puede introducir en el verificador de modelos SAL [ 25 ] [ 26 ] para permitir comprobar si se cumplen ciertas propiedades de seguridad. [ 19 ] [ 27 ]

Análisis de modos y efectos de falla (AMFE)

La verificación de modelos se ha aplicado con frecuencia a modelos de sistemas para comprobar que no se puedan alcanzar estados peligrosos durante el funcionamiento normal del sistema. [ 28 ] Es posible combinar la verificación de modelos con árboles de comportamiento para proporcionar soporte automatizado para el análisis de modos y efectos de fallos (FMEA). [ 19 ] La ventaja de utilizar árboles de comportamiento para este propósito es que permiten ocultar los aspectos formales del método a los usuarios no expertos.

Cambios en los requisitos

El ideal que se busca al responder a un cambio en los requisitos funcionales de un sistema es que este pueda determinarse rápidamente:

  • dónde realizar el cambio,
  • cómo afecta el cambio a la arquitectura del sistema existente,
  • qué componentes del sistema se ven afectados por el cambio, y
  • ¿Qué cambios de comportamiento deberán realizarse en los componentes (y sus interfaces) que se ven afectados por el cambio de requisitos? [ 29 ]

Dado que es probable que un sistema experimente muchos cambios a lo largo de su vida útil, es necesario registrar, gestionar y optimizar su evolución impulsada por estos cambios.

Un modelo de trazabilidad, que utiliza árboles de comportamiento como notación formal para representar los requisitos funcionales, revela los impactos de los cambios en diferentes tipos de construcciones de diseño (documentos) causados ​​por las modificaciones de los requisitos. [ 30 ] El modelo introduce el concepto de documentos de diseño evolutivos que registran el historial de cambios de los diseños. A partir de estos documentos, se puede recuperar cualquier versión de un documento de diseño, así como la diferencia entre dos versiones cualesquiera. Una ventaja importante de este modelo es que las herramientas automatizadas pueden respaldar gran parte del procedimiento para generar estos documentos de diseño evolutivos. [ 21 ]

Generación y ejecución de código

La representación en árbol del comportamiento integrado del sistema ofrece varias ventajas importantes como modelo ejecutable. Separa claramente las tareas de integración de componentes de la tarea de implementación de componentes individuales . El comportamiento integrado del sistema resultante de la integración de requisitos puede servir como base para las decisiones de diseño. El resultado es un árbol de comportamiento de diseño (DBT): [ 5 ] una especificación ejecutable de integración de componentes multihilo que se ha construido a partir de los requisitos originales.

Los modelos de árbol de comportamiento se ejecutan en una máquina virtual denominada entorno de ejecución de comportamiento (BRE). El BRE enlaza componentes mediante middleware [ 31 ] , lo que permite que los componentes sean programas independientes escritos en diversos lenguajes que pueden ejecutarse en un entorno distribuido . El BRE también incluye un analizador de expresiones que realiza automáticamente operaciones sencillas para minimizar la cantidad de código que debe implementarse manualmente en el componente.

Se han desarrollado árboles de comportamiento ejecutables para estudios de caso [ 22 ] , incluyendo protección automatizada de trenes [ 32 ] , robots móviles con seguimiento dinámico de objetos, una bomba de infusión ambulatoria [ 20 ] y sistemas de gestión de semáforos. También está disponible una versión del BRE adaptada a sistemas embebidos (eBRE), con funcionalidad reducida diseñada para microcontroladores de tamaño reducido.

Aplicaciones

El modelado de árboles de comportamiento se puede aplicar, y de hecho se ha aplicado, a una amplia gama de aplicaciones durante muchos años. Algunas de las principales áreas de aplicación se describen a continuación.

Sistemas a gran escala

El modelado de sistemas a gran escala con amplios conjuntos de requisitos en lenguaje natural siempre ha sido un objetivo principal para la prueba de árboles de comportamiento y el proceso general de ingeniería de comportamiento. La realización de estas evaluaciones y pruebas del método ha implicado el trabajo con varios socios de la industria y departamentos gubernamentales en Australia. Los sistemas estudiados han incluido un número significativo de sistemas de defensa, sistemas empresariales, sistemas de transporte, sistemas de información, sistemas de salud y sistemas de control sofisticados con estrictos requisitos de seguridad. Los resultados de estos estudios se han clasificado como confidenciales. Sin embargo, los resultados de las extensas pruebas industriales [ 3 ] [ 4 ] con Raytheon Australia se presentan a continuación en la Sección de la Industria. Este trabajo ha demostrado que la traducción de requisitos a vistas integradas de árboles de comportamiento estáticos y dinámicos reveló sustancialmente más defectos importantes que los detectados por los procesos de revisión estándar de la empresa. [ 33 ]

Sistemas embebidos

El hecho de que un diseño no cumpla con los requisitos de un sistema puede resultar en sobrecostos y retrasos en el cronograma. [ 34 ] Si además existen problemas críticos de confiabilidad, no satisfacer los requisitos del sistema puede tener consecuencias potencialmente mortales. [ 35 ] Sin embargo, en los enfoques actuales, asegurar que se cumplan los requisitos a menudo se retrasa hasta etapas avanzadas del proceso de desarrollo, durante un ciclo de pruebas y depuración . [ 36 ] Este trabajo describe cómo el enfoque de desarrollo de sistemas, la ingeniería de comportamiento, puede utilizarse para desarrollar software para sistemas embebidos . [ 27 ]

Sistemas de hardware y software

Muchos sistemas a gran escala constan de una mezcla de software y hardware interdependientes. La naturaleza diferente del software y el hardware implica que a menudo se modelan por separado utilizando enfoques distintos. Esto puede generar problemas de integración debido a supuestos incompatibles sobre las interacciones entre hardware y software. [ 32 ] Estos problemas pueden superarse integrando árboles de comportamiento con el enfoque de modelado matemático Modelica . [ 32 ] El entorno y los componentes de hardware se modelan utilizando Modelica y se integran con un modelo de software ejecutable que utiliza árboles de comportamiento.

Control de acceso basado en roles

Para garantizar la correcta implementación de requisitos complejos de control de acceso , es importante que los requisitos validados y verificados se integren eficazmente con el resto del sistema. [ 37 ] También es importante que el sistema pueda validarse y verificarse al inicio del proceso de desarrollo. Se ha desarrollado un modelo de control de acceso integrado basado en roles . [ 38 ] El modelo se basa en la notación de árbol de comportamiento gráfico y puede validarse mediante simulación , así como verificarse utilizando un verificador de modelos . Utilizando este modelo, los requisitos de control de acceso pueden integrarse con el resto del sistema desde el principio, porque: se utiliza una única notación para expresar tanto los requisitos de control de acceso como los funcionales ; se puede adoptar un enfoque sistemático e incremental para construir una especificación formal de árbol de comportamiento; y la especificación puede simularse y verificarse mediante un modelo. La eficacia del modelo se ha evaluado utilizando un estudio de caso con requisitos de control de acceso distribuidos. [ 37 ]

Sistemas biológicos

Debido a que los árboles de comportamiento describen comportamientos complejos, pueden utilizarse para describir una variedad de sistemas que no se limitan a los basados ​​en computadoras. [ 39 ]

Modelado de IA para juegos

Si bien los árboles de comportamiento se han popularizado para modelar la inteligencia artificial en videojuegos como Halo [ 40 ] y Spore [ 41 ], estos tipos de árboles son muy diferentes de los descritos en esta página y se asemejan más a una combinación de máquinas de estados finitos jerárquicas o árboles de decisión . El modelado de jugadores de fútbol también ha sido una aplicación exitosa de los árboles de comportamiento [ 42 ] [ 43 ] .

Pruebas basadas en modelos

Las pruebas basadas en modelos son un enfoque para las pruebas de software que requiere que los evaluadores creen modelos de prueba a partir de los requisitos del software bajo prueba (SUT). Tradicionalmente, se han utilizado lenguajes de modelado como diagramas de estados UML, máquinas de estados finitos (FSM), máquinas de estados finitos extendidas (EFSM) y diagramas de flujo. Recientemente, también ha surgido un enfoque interesante en el que se utiliza la red de Petri de carriles de natación orientada a eventos (EDSLPN) como lenguaje de modelado. La notación de árbol de comportamiento también debería considerarse una buena notación de modelado para MBT, y tiene algunas ventajas sobre otras notaciones:

  1. Tiene el mismo nivel de expresividad que los diagramas de estados UML y EDSLPN.
  2. Su uso como notación de modelado resulta intuitivo debido a su naturaleza gráfica.
  3. Cada nodo del árbol de comportamiento tiene una etiqueta de requisito; estas facilitan enormemente la creación de una matriz de trazabilidad desde el requisito hasta el artefacto de prueba. [ 44 ]

Escalabilidad y aplicaciones industriales

Captura de pantalla de la herramienta de entorno de soporte para ingeniería de comportamiento
Árbol de comportamiento integrado: sistema de mayor tamaño (más de 1000 requisitos).

Las primeras pruebas industriales para probar la viabilidad del método y refinar su capacidad se llevaron a cabo en 2002. En los últimos tres años, se han llevado a cabo varias pruebas industriales sistemáticas en sistemas de defensa, transporte y empresariales a gran escala. [ 3 ] [ 33 ] Este trabajo ha establecido que el método se adapta a sistemas con un gran número de requisitos, pero también que es importante utilizar el soporte de herramientas [ 23 ] [ 45 ] para navegar y editar de manera eficiente las vistas integradas de gran tamaño resultantes de datos gráficos. En promedio, en varios proyectos, se han encontrado consistentemente 130 defectos mayores confirmados por cada 1000 requisitos después de que se hayan realizado revisiones y correcciones normales. [ 33 ] Con conjuntos de requisitos menos maduros, se han observado tasas de defectos mucho más altas.

Ventajas

Como representación de modelos de comportamiento, los árboles de comportamiento tienen una serie de beneficios y ventajas significativas:

Véase también

Referencias

  1. ↑ Lindsay, Peter A. (1 de septiembre de 2010). «Árboles de comportamiento: De la ingeniería de sistemas a la ingeniería de software» . 8.ª Conferencia Internacional IEEE de 2010 sobre Ingeniería de Software y Métodos Formales . IEEE. págs. 21-30 . doi : 10.1109/sefm.2010.11 . ISBN  978-1-4244-8289-4.
  2. 1 2 3 Dromey, RG 2007. Principios para la ingeniería de sistemas intensivos en software a gran escala
  3. 1 2 3 Boston, J. 2008. Raytheon Australia apoya la investigación pionera en sistemas. Archivado el 15 de septiembre de 2009 en Wayback Machine.
  4. 1 2 Raytheon Australia, 2008. La comprensión crece en los árboles de comportamiento. Archivado el 15 de septiembre de 2009 en Wayback Machine.
  5. 1 2 3 4 R.G. Dromey, De los requisitos al diseño: formalización de los pasos clave Archivado el 25 de julio de 2011 en Wayback Machine , (Discurso principal invitado), SEFM-2003, Conferencia internacional IEEE sobre ingeniería de software y métodos formales, Brisbane, septiembre de 2003, págs. 2-11.
  6. ↑ Ingeniería del comportamiento. Árboles de composición . Archivado el 2 de marzo de 2009 en Wayback Machine.
  7. ↑ Winter, K. 2007. Formalización de árboles de comportamiento con CSP
  8. 1 2 R.G. Dromey, "Formalizing the Transition from Requirements to Design" Archivado el 25 de julio de 2011 en Wayback Machine , en "Mathematical Frameworks for Component Software – Models for Analysis and Synthesis", Jifeng He y Zhiming Liu (Eds.), World Scientific Series on Component-Based Development, pp. 156–187, (Capítulo invitado) (2006)
  9. ↑ RLGlass, "¿Es esta una idea revolucionaria o no?" Archivado el 25 de julio de 2011 en Wayback Machine , Communications of the ACM, vol. 47(11), págs. 23–25, noviembre de 2004.
  10. ↑ RGDromey, "Superando el muro de ladrillos de 'No Silver Bullet'", archivado el 25 de julio de 2011 en Wayback Machine , IEEE Software, vol. 23, n.° 2, págs. 118-120, (marzo de 2006)
  11. ↑ RGDromey, Ingeniería de software genética: simplificación del diseño mediante la integración de requisitos, Conferencia de trabajo del IEEE sobre arquitectura de sistemas complejos y dinámicos, Brisbane, diciembre de 2001.
  12. ↑ A. Woolfson, Vida sin genes, Flamingo, 2000, ISBN 0-00-255618-9
  13. ↑ Berlin, I. La madera torcida de la humanidad: capítulos de la historia de las ideas, ed. H. Hardy, Princeton University Press, 1998 ISBN 0-691-05838-5
  14. ↑ "Behavior Engineering World » Historia de la ingeniería del comportamiento" . Consultado el 24 de mayo de 2025 . 
  15. ↑ Colvin, R., Grunske, L., Winter, K. 2007 Árboles de comportamiento temporizados probabilísticos Archivado el 25 de julio de 2011 en Wayback Machine
  16. 1 2 3 4 Grupo de árboles de comportamiento, Centro ARC para Sistemas Complejos , 2007. Notación de árbol de comportamiento v1.0 (2007) Archivado el 4 de marzo de 2016 en Wayback Machine
  17. ↑ Dromey, RG "Diseño genético: amplificando nuestra capacidad para lidiar con la complejidad de los requisitos" Archivado el 25 de julio de 2011 en Wayback Machine , en S. Leue y TJ Systra, Escenarios, Lecture Notes in Computer Science, LNCS 3466, págs. 95–108, 2005.
  18. 1 2 3 Colvin, R., Hayes, IJ 2006 Una semántica para árboles de comportamiento
  19. 1 2 3 4 L. Grunske, P. Lindsay, N. Yatapanage, K. Winter, Un análisis automatizado de modos y efectos de fallas basado en especificaciones de diseño de alto nivel con árboles de comportamiento , Quinta Conferencia Internacional sobre Métodos Formales Integrados (IFM-2005), Eindhoven, Países Bajos, 2005.
  20. 1 2 3 Zafar, S. y Dromey, RG, (2005), Integrating Safety and Security Requirements into Design of an Embedded System. Archivado el 25 de julio de 2011 en Wayback Machine Asia-Pacific Software Engineering Conference 2005, 15–17 de diciembre, Taipéi, Taiwán. IEEE Computer Society Press. págs. 629–636.
  21. 1 2 Smith, C., Winter, K., Hayes, I., Dromey, RG, Lindsay, P., Carrington, D.: Un entorno para construir un sistema a partir de sus requisitos , 19.ª Conferencia Internacional IEEE sobre Ingeniería de Software Automatizada, Linz, Austria, septiembre (2004).
  22. 1 2 Dromey, RG Uso de árboles de comportamiento para modelar el sistema de transbordador autónomo Archivado el 25 de julio de 2011 en Wayback Machine , 3er Taller Internacional sobre Escenarios y Máquinas de Estado: Modelos, Algoritmos y Herramientas (SCESM04) Taller ICSE W5S, Edimburgo, 25 de mayo de 2004
  23. 1 2 3 L.Wen, R.Colvin, K.Lin, J.Seagrott, N.Yatapanage, RGDromey, 2007, "Integrare, un entorno colaborativo para el diseño orientado al comportamiento" , en Actas de la Cuarta Conferencia Internacional sobre Diseño Cooperativo, Visualización e Ingeniería, LNCS 4674, pp. 122–131, 2007
  24. ↑ C. Sun, S. Xia, D. Sun, D. Chen. HF Shen, W. Cai: "Adaptación transparente de aplicaciones de un solo usuario para la colaboración en tiempo real de múltiples usuarios" , ACM Transactions on Computer-Human Interaction, vol. 13, n.º 4, diciembre de 2006, págs. 531–582.
  25. ^ Bensalem, S., Ganesh, V., Lakhnech, Y., Muñoz, C., Owre, et al.: "An Overview of SAL", Quinto taller de métodos formales de Langley de la NASA (LFM 2000), 2000, págs.
  26. ↑ Rushby, J. Métodos formales automatizados 2006 AFM-2006, Métodos formales automatizados 2006, Seattle, agosto de 2006, págs. 6–7.
  27. 1 2 3 Zafar, S. y Dromey, RG, 2005. Gestión de la complejidad en el modelado de sistemas embebidos. Archivado el 25 de julio de 2011 en la Wayback Machine Systems Engineering/Test and Evaluation Conference 2005, 7–9 de noviembre, Brisbane, Australia
  28. ↑ Grunske, L., Colvin, R., Winter, K. Soporte de verificación de modelos probabilísticos para la evaluación cuantitativa de sistemas mediante FMEA. QEST 2007. Cuarta Conferencia Internacional sobre la Evaluación Cuantitativa de Sistemas, 17-19 de septiembre de 2007, págs. 119-128.
  29. ↑ Wen, L., Dromey, RG 2007. Del cambio de requisitos al cambio de diseño: una ruta formal
  30. ↑ Wen, L., Dromey, RG 2005. Normalización de la arquitectura para sistemas basados ​​en componentes. Archivado el 25 de julio de 2011 en Wayback Machine. Actas del 2.º Taller Internacional sobre Aspectos Formales del Software de Componentes FACS'05, págs. 247–261.
  31. ↑ RTI Inc. 2007 "Cumplimiento de los requisitos en tiempo real en sistemas de defensa integrados", Libro blanco de RTI archivado el 20 de septiembre de 2008 en Wayback Machine .
  32. 1 2 3 Myers, T., Fritzson, P., Dromey, RG 2008. Integración perfecta de modelado de software y hardware para sistemas a gran escala. 2.º Taller Internacional sobre Lenguajes y Herramientas Orientados a Objetos Basados ​​en Ecuaciones (EOOLT 2008), Chipre, julio de 2008. págs. 5–15.
  33. 1 2 3 4 5 Powell, D. 2007. Evaluación de requisitos mediante árboles de comportamiento: hallazgos de la industria. Archivado el 25 de julio de 2011 en Wayback Machine.
  34. ↑ Barker, D. 2000. Tecnología de modelado de requisitos: una visión para sistemas mejores, más rápidos y más económicos. Actas del Taller de Otoño del Foro Internacional de Usuarios de VHDL, 2000. págs. 3–6.
  35. ↑ Leveson, NG Safeware: Seguridad de sistemas y computadoras: [una guía para prevenir accidentes y pérdidas causadas por la tecnología]. Addison-Wesley Publishing Company, 1995. ISBN 0-201-11972-2
  36. ↑ Futrell, RT, Shafer, DF, Shafer, LI Gestión de proyectos de software de calidad (Serie del Instituto de Calidad del Software). Prentice Hall, 2002 ISBN 0-13-091297-2
  37. 1 2 Zafar, S. Colvin, R., Winter, K., Yatapanage, N., Dromey, RG Validación y verificación tempranas de un modelo de control de acceso distribuido basado en roles. 14.ª Conferencia de Ingeniería de Software de Asia-Pacífico, Nagoya, Japón, diciembre de 2008. págs. 430–437.
  38. 1 2 Zafar, S., K. Winter, R. Colvin, RG Dromey, "Verificación de un modelo integrado de control de acceso basado en roles" Archivado el 25 de julio de 2011 en Wayback Machine , 1er Taller Internacional – Conferencia de Trabajo Asiática sobre Software Verificado (AWCVS'06), pp 230-240, Macao, octubre de 2006.
  39. 1 2 Milosevic, Z., Dromey, RG Sobre la expresión y el monitoreo del comportamiento en contratos , EDOC 2002, Actas, 6.ª Conferencia Internacional de Computación de Objetos Distribuidos Empresariales, Lausana, Suiza, septiembre de 2002, págs. 3-14.
  40. ↑ Damian Isla maneja la complejidad en la IA de Halo 2.
  41. ↑ Chris Hecker Mis notas de la carátula de Spore
  42. ↑ Xiao-Wen Terry Liu y Jacky Baltes Una arquitectura intuitiva y flexible para robots móviles inteligentes 2.ª Conferencia Internacional sobre Robots y Agentes Autónomos, 13-15 de diciembre de 2004 Palmerston North, Nueva Zelanda
  43. ↑ Yukiko Hoshino, Tsuyoshi Takagi, Ugo Di Profio y Masahiro Fujita. Descripción y control del comportamiento mediante un módulo de comportamiento para un robot personal.
  44. ^ "Una herramienta de prueba basada en modelos - MBTester · 测试之家" . testerhome.com . Consultado el 12 de junio de 2025 .
  45. ↑ Phillips, V., (Raytheon Australia), "Implementación de una herramienta de análisis de árbol de comportamiento utilizando los marcos de desarrollo de Eclipse" , Conferencia Australiana de Ingeniería de Software (ASWEC'08), Perth, marzo de 2008
  46. ↑ Boston, J., (Raytheon Australia), Árboles de comportamiento: ¿cómo mejoran el comportamiento en ingeniería?, 6.ª Conferencia Anual del Grupo de Procesos de Ingeniería de Software y Sistemas (SEPG 2008), Melbourne, agosto de 2008.
  47. ↑ Lin, K., Chen, D., Sun, C., Dromey, RG, Una estrategia de mantenimiento de restricciones y aplicaciones en entornos colaborativos en tiempo real , 2.ª Conferencia Internacional sobre Diseño Cooperativo, Visualización e Ingeniería (CDVE2005), 2005.
  48. ↑ Lin, K., Chen, D., Dromey, RG, Sun, CZ.: Propagación de restricciones de flujo de datos multidireccional en sistemas colaborativos en tiempo real. Archivado el 25 de julio de 2011 en Wayback Machine , IEEE, 2.ª Conferencia Internacional sobre Computación Colaborativa: Redes, Aplicaciones y Trabajo Compartido (CollaborateCom 2006), Atlanta, Georgia, EE. UU., noviembre de 2006.
  49. ↑ Grunske, L., Winter, K., Colvin, R., "Árboles de comportamiento temporizados y su aplicación a la verificación de sistemas en tiempo real" Archivado el 18 de noviembre de 2008 en Wayback Machine , Actas de la 18.ª Conferencia Australiana sobre Ingeniería de Software (AEWEC 2007), abril de 2007, aceptado para su publicación.
  • Ingeniería del comportamiento
  • Raytheon Australia apoya la investigación de sistemas pioneros.
  • Centro ARC para Sistemas Complejos – Programa ACCS: Sistemas Complejos Confiables Basados ​​en Computadoras
  • Consejo Australiano de Investigación – Resultados: Cómo domar la complejidad