Los árboles de comportamiento son un lenguaje formal de modelado gráfico que se utiliza principalmente en sistemas e ingeniería de software . Los árboles de comportamiento emplean una notación bien definida para representar de forma inequívoca los cientos o incluso miles de requisitos de lenguaje natural que se utilizan normalmente para expresar las necesidades de las partes interesadas en un sistema integrado de software a gran escala. [1] [2] [3] [4]
La cantidad de detalles en el gran número de requisitos de lenguaje natural para un sistema a gran escala provoca una sobrecarga de memoria a corto plazo [1] [5] y puede crear una barrera que impida a cualquiera obtener una comprensión profunda, precisa y holística de las necesidades del sistema. [6] Además, debido al uso del lenguaje natural , es probable que haya muchas ambigüedades, alias, inconsistencias, redundancias y problemas de incompletitud asociados con la información de los requisitos. [3] Esto aumenta aún más la incertidumbre y la complejidad. Generalmente, en el mejor de los casos, unas pocas personas entienden bien partes del sistema o la situación, pero nadie tiene más que una comprensión superficial del todo, es decir, el comportamiento integrado detallado del sistema.
La representación del árbol de comportamiento (con la ayuda de la representación del árbol de composición [7] que resuelve los alias y otros problemas de vocabulario con grandes conjuntos de requisitos) permite a las personas evitar la sobrecarga de la memoria a corto plazo y producir una representación profunda, precisa y holística de las necesidades del sistema [1] que puede ser entendida por todas las partes interesadas porque utiliza estrictamente el vocabulario de los requisitos originales. Debido a que la notación del árbol de comportamiento utiliza una semántica formal , para cualquier ejemplo dado, ya es, o puede hacerse ejecutable .
Tanto las formas de árbol de comportamiento simples como las compuestas o integradas son importantes en la aplicación de árboles de comportamiento en sistemas e ingeniería de software .
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 no las juntamos todas, no podemos ver la imagen emergente ni si faltan piezas o no encajan. Construir un árbol de comportamiento integrado (IBT) nos permite hacer esto. [2] [3]
Los árboles de comportamiento y los conceptos para su aplicación en sistemas e ingeniería de software fueron desarrollados originalmente por Dromey [2] [3] [9] [10] y algunas de las ideas clave se publicaron por primera vez 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 por la que se utilizó originalmente la palabra genético fue porque los conjuntos de genes, los conjuntos de piezas de rompecabezas y los conjuntos de requisitos representados como árboles de comportamiento parecían compartir varias propiedades clave:
Para los árboles de comportamiento, las propiedades emergentes importantes incluyen:
Estos paralelismos genéticos, en otro contexto, fueron originalmente formulados por Woolfson, [12] (A. Woolfson, Living Without Genes, Flamingo, 2000)
El término genético recibió un mayor peso del pensador del siglo XVIII Giambattista Vico , quien dijo: "Entender algo, y no simplemente ser capaz de describirlo o analizarlo en sus partes componentes, es entender cómo llegó a existir - su génesis, su crecimiento... la verdadera comprensión es siempre genética". [13] A pesar de estos legítimos paralelismos genéticos, se consideró que este énfasis conducía a confusión con el concepto de algoritmos genéticos . Como resultado, se introdujo el término ingeniería del comportamiento para describir los procesos que explotan árboles de comportamiento para construir sistemas. El término "ingeniería del comportamiento" se ha utilizado anteriormente en un área especializada de la inteligencia artificial: la investigación robótica. El uso actual abarca una formalización e integración rigurosa mucho más amplia de grandes conjuntos de requisitos de comportamiento y composición necesarios para modelar sistemas a gran escala.
Desde que se concibió originalmente la notación de árboles de comportamiento, varias personas del DCCS (Grupo de Sistemas Computacionales Confiables y Complejos, un grupo de investigación conjunto de la Universidad de Queensland y la Universidad Griffith ) han hecho importantes contribuciones a la evolución y el refinamiento de la notación y al uso de árboles de comportamiento. Entre los miembros de este grupo se incluyen: David Carrington, Rob Colvin, Geoff Dromey, Lars Grunske, Ian Hayes, Diana Kirk, Peter Lindsay, Toby Myers, Dan Powell, John Seagrott, Cameron Smith, Larry Wen, Nisansala Yatapanage, Kirsten Winter, Saad Zafar y Forest Zheng.
Colvin, Grunske y Winter han desarrollado recientemente árboles de comportamiento cronometrado probabilístico para que se puedan expresar propiedades de fiabilidad, rendimiento y otras propiedades de seguridad. [14]
Se utiliza un árbol de comportamiento para representar formalmente el fragmento de comportamiento en cada requisito individual. El comportamiento de un sistema a gran escala en general, donde se admite la concurrencia , aparece de manera abstracta como un conjunto de procesos secuenciales que se comunican . La notación del árbol de comportamiento captura estos estados de componentes compuestos en una forma simple similar a un árbol.
El comportamiento se expresa en términos de componentes que realizan estados y componentes que crean y rompen relaciones. Utilizando las formas lógicas y gráficas de las convenciones que se encuentran en los lenguajes de programación , los componentes pueden admitir acciones, composición, eventos, flujo de control, flujo de datos y subprocesos. [3]
Las etiquetas de trazabilidad (consulte la Sección 1.2 de la notación del árbol de comportamiento [15] ) en los nodos del árbol de comportamiento vinculan la representación formal con el requisito de lenguaje natural correspondiente . Los árboles de comportamiento capturan con precisión el comportamiento expresado en la representación en lenguaje natural de los requisitos funcionales. Los árboles de comportamiento de los requisitos utilizan estrictamente el vocabulario de los requisitos en lenguaje natural, pero emplean formas gráficas para la composición del comportamiento con el fin de eliminar el riesgo de ambigüedad. Al hacer esto, proporcionan una relación directa y claramente rastreable entre lo que se expresa en la representación en lenguaje natural y su especificación formal . [16]
Una base de la notación es que el comportamiento siempre está asociado con algún componente. Los estados de los componentes que representan nodos de comportamiento se componen de manera secuencial o concurrente para construir un árbol de comportamiento que representa el comportamiento expresado en los requisitos del lenguaje natural. Un árbol de comportamiento con nodos de hoja puede revertir (simbolizado mediante la adición del operador de intercalación ^) a un nodo antecesor para repetir el comportamiento o iniciar un nuevo hilo (simbolizado por dos intercalaciones ^^).
Un árbol de comportamiento especifica los cambios de estado en los componentes, cómo se pasan los datos y el control entre los componentes y cómo interactúan los subprocesos . Existen construcciones para crear y romper relaciones. También existen construcciones para establecer y probar estados de componentes, así como mecanismos para la comunicación entre procesos que incluyen el paso de mensajes (eventos), el bloqueo de variables compartidas y la sincronización .
Para obtener una referencia completa a la notación del árbol de comportamiento, versión 1.0, consulte: Notación del árbol de comportamiento v1.0 (2007) [15]
La semántica formal de los árboles de comportamiento se da a través de un álgebra de procesos y su semántica operacional . [17] La semántica se ha utilizado como base para el desarrollo de simulaciones , verificación de modelos y análisis de modos de falla y efectos . [17] [18] [19]
La traducción de requisitos es el vehículo utilizado para cruzar la barrera formal-informal. Consideremos el proceso de traducción del requisito R1 a continuación. Las primeras tareas son identificar los componentes ( negrita ), identificar los comportamientos ( subrayado ) e identificar los indicadores del orden ( cursiva ) en el que se dan los comportamientos. Luego se puede construir el árbol de comportamientos correspondiente.
Lo que queda claro del resultado de este proceso es que, aparte de los pronombres, artículos definidos, etc., se han tenido en cuenta y utilizado esencialmente todas las palabras de las oraciones que contribuyen al comportamiento que describen.
Una vez que el conjunto de requisitos se formaliza como árboles de comportamiento de requisitos individuales, es necesario explotar dos propiedades conjuntas de los sistemas y los requisitos para proceder a componer el árbol de comportamiento integrado:
Para los requisitos representados como árboles de comportamiento, esto equivale a encontrar dónde se encuentra el nodo raíz de un árbol en otro árbol de comportamiento e integrar los dos árboles en ese nodo.
El siguiente ejemplo ilustra la integración de requisitos para dos requisitos, R1 y R3. En otras palabras, muestra cómo interactúan estos dos requisitos.
Una vez compuesto un árbol de comportamiento integrado, hay una serie de operaciones importantes que se pueden realizar en él.
En general, muchos defectos se hacen mucho más visibles cuando existe una visión integrada de los requisitos [1] y cada requisito se ha colocado en el contexto de comportamiento donde necesita 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 consistente. Las etiquetas de trazabilidad [15] también facilitan la referencia a los requisitos originales en lenguaje natural. También existe la posibilidad de automatizar una serie de comprobaciones de defectos y consistencia en un árbol de comportamiento integrado. [20]
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, con UML ) es menos claro cuándo se puede detener el modelado. [21] En algunos casos, puede ser necesario transformar partes de un árbol de comportamiento del modelo para hacer que la especificación sea ejecutable . Una vez que un MBT se ha hecho ejecutable, es posible llevar a cabo una serie de otras comprobaciones de confiabilidad.
Se puede simular fácilmente un árbol de comportamiento del modelo para explorar las propiedades dinámicas del sistema. Se han construido tanto una herramienta simbólica como una herramienta gráfica para respaldar estas actividades. [22] [23]
Se ha escrito un traductor para convertir un árbol de comportamiento de modelo en el lenguaje de "sistemas de acciones". Esta entrada puede luego introducirse en el verificador de modelos SAL [24] [25] para permitir que se realicen comprobaciones sobre si se cumplen determinadas propiedades de seguridad. [18] [26]
La verificación de modelos se ha aplicado a menudo a los modelos de sistemas para comprobar que no se pueden alcanzar estados peligrosos durante el funcionamiento normal del sistema. [27] Es posible combinar la verificación de modelos con árboles de comportamiento para proporcionar soporte automatizado para el análisis de modos de fallo y efectos (FMEA). [18] La ventaja de utilizar árboles de comportamiento para este propósito es que permiten ocultar los aspectos formales del método del enfoque a los usuarios no expertos.
El ideal que se busca al responder a un cambio en los requisitos funcionales de un sistema es que se pueda determinar rápidamente:
Dado que es probable que un sistema experimente muchos conjuntos de cambios a lo largo de su tiempo de servicio, también existe la necesidad de registrar, gestionar y optimizar la evolución del sistema impulsada por la secuencia de 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 los distintos tipos de construcciones de diseño (documentos) causados por los cambios de los requisitos. [28] El modelo introduce el concepto de documentos de diseño evolutivo 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 la mayor parte del procedimiento para generar estos documentos de diseño evolutivo puede ser respaldada por herramientas automatizadas. [20]
La representación del comportamiento integrado del sistema en forma de árbol de comportamiento ofrece varias ventajas importantes como modelo ejecutable. Separa claramente las tareas de integración de componentes de las tareas de implementación de componentes individuales . El comportamiento integrado del sistema que surge de la integración de los requisitos se puede utilizar como base para crear un diseño mediante la aplicación de decisiones de diseño. El resultado es un árbol de comportamiento de diseño (DBT): [3] una especificación de integración de componentes ejecutable y multiproceso que se ha creado a partir de los requisitos originales.
Los modelos de árboles de comportamiento se ejecutan en una máquina virtual llamada entorno de ejecución de comportamiento (BRE). El BRE vincula los componentes mediante middleware, [29] lo que permite que los componentes sean programas independientes escritos en uno de varios lenguajes que se pueden ejecutar en un entorno distribuido . El BRE también contiene un analizador de expresiones que realiza automáticamente operaciones simples para minimizar la cantidad de código que se requiere implementar manualmente en el componente.
La implementación de componentes se apoya en vistas que se pueden extraer automáticamente del DBT. Estas vistas proporcionan los árboles de comportamiento de componentes (CBT) de componentes individuales junto con las interfaces de componentes individuales. Esta información, junto con la información en el árbol de composición integrado (ICT) capturada sobre cada componente individual, proporciona la información necesaria para implementar cada componente individual.
Se pueden vincular varios BRE para formar sistemas complejos mediante una construcción de sistema de sistemas y el entorno de integración de componentes de ingeniería de comportamiento (BECIE). BECIE también se utiliza para supervisar y controlar los modelos de árboles de comportamiento que se ejecutan dentro de un BRE, de forma similar a los sistemas de control de supervisión y adquisición de datos (SCADA) utilizados en el control de procesos industriales.
Se han desarrollado árboles de comportamiento ejecutables para estudios de casos [21] , entre los que se incluyen la protección automatizada de trenes, [30] robots móviles con seguimiento dinámico de objetos, una bomba de infusión ambulatoria [19] y sistemas de gestión de semáforos. También está disponible una versión del BRE adaptada a sistemas integrados (eBRE) que tiene una funcionalidad reducida para adaptarla a microcontroladores de tamaño reducido.
El modelado de árboles de comportamiento se puede aplicar y se ha aplicado a una amplia gama de aplicaciones a lo largo de varios años. A continuación se describen algunas de las principales áreas de aplicación.
El modelado de sistemas a gran escala con grandes conjuntos de requisitos en lenguaje natural siempre ha sido el principal objetivo de los ensayos de árboles de comportamiento y del proceso general de ingeniería del comportamiento. La realización de estas evaluaciones y ensayos del método ha implicado trabajar con varios socios de la industria y departamentos gubernamentales de Australia. Los sistemas estudiados han incluido una cantidad significativa 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 han sido todos confidenciales comercialmente. Sin embargo, los resultados de los extensos ensayos de la industria [5] [6] con Raytheon Australia se presentan a continuación en la Sección de la Industria. Lo que todo este trabajo ha demostrado de manera consistente es que al traducir los requisitos y crear vistas integradas dinámicas y estáticas de los requisitos, se descubre una cantidad muy significativa de defectos importantes de manera temprana, además de los defectos que se encuentran con las mejores prácticas actuales de la industria. [31] [32]
El fracaso de un diseño para satisfacer los requisitos de un sistema puede resultar en sobrecostos y cronogramas. [33] Si también hay problemas críticos de confiabilidad, no satisfacer los requisitos del sistema puede tener consecuencias potencialmente mortales. [34] Sin embargo, en los enfoques actuales, garantizar que se cumplan los requisitos a menudo se retrasa hasta el final del proceso de desarrollo durante un ciclo de prueba y depuración. [35] Este trabajo describe cómo el enfoque de desarrollo de sistemas, ingeniería de comportamiento, se puede utilizar para desarrollar software para sistemas integrados . [26] El resultado es un enfoque de desarrollo impulsado por modelos que puede crear software de sistema integrado que satisfaga sus requisitos, como resultado de la aplicación del proceso de desarrollo.
Muchos sistemas a gran escala consisten en una mezcla de software y hardware co-dependientes. La diferente naturaleza del software y el hardware significa que a menudo se modelan por separado utilizando diferentes enfoques. Esto puede conducir posteriormente a problemas de integración debido a suposiciones incompatibles sobre las interacciones hardware/software. [30] Estos problemas se pueden superar integrando árboles de comportamiento con el enfoque de modelado matemático Modelica . [ 30] Los componentes del entorno y del hardware se modelan utilizando Modelica y se integran con un modelo de software ejecutable que utiliza árboles de comportamiento.
Para asegurar la correcta implementación de requisitos complejos de control de acceso , es importante que los requisitos validados y verificados se integren efectivamente con el resto del sistema. [36] También es importante que el sistema pueda ser validado y verificado temprano en el proceso de desarrollo. Se ha desarrollado un modelo de control de acceso integrado basado en roles. [37] El modelo se basa en la notación de árbol de comportamiento gráfico, y puede ser validado por simulación , así como verificado utilizando un verificador de modelos . Usando este modelo, los requisitos de control de acceso pueden integrarse con el resto del sistema desde el principio, porque: se usa una sola notación para expresar tanto el control de acceso como los requisitos funcionales ; se puede adoptar un enfoque sistemático e incremental para construir una especificación de árbol de comportamiento formal; y la especificación puede ser simulada y verificada por modelo. La efectividad del modelo ha sido evaluada usando un estudio de caso con requisitos de control de acceso distribuidos. [36]
Debido a que los árboles de conducta describen un comportamiento complejo, se pueden utilizar para describir una variedad de sistemas que no se limitan a los que están basados en computadoras. [38] En un contexto biológico, los árboles de conducta se pueden utilizar para armar una interpretación procedimental de las funciones biológicas descritas en artículos de investigación, tratando los artículos como los documentos de requisitos como se describió anteriormente. Esto puede ayudar a construir una descripción más concreta del proceso de lo que es posible a partir de la lectura únicamente, y también se puede utilizar como base para comparar teorías competitivas en artículos alternativos. En la investigación en curso, la notación del árbol de conducta se está utilizando para desarrollar modelos de la función cerebral en ratas bajo condicionamiento del miedo .
Si bien los BT se han vuelto populares para modelar la inteligencia artificial en juegos de computadora como Halo [39] y Spore [40], este tipo de árboles son muy diferentes de los descritos en esta página y se acercan 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 BT. [41] [42]
[43] es 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 utilizan diagramas de estado UML, FSM, EFSM y diagramas de flujo como lenguaje de modelado. Recientemente, también ha aparecido un enfoque interesante en el que se utiliza la red de Petri de carriles de natación impulsada por eventos (EDSLPN) como lenguaje de modelado. La notación de árbol de comportamiento también debe considerarse como una buena notación de modelado para MBT, y tiene algunas ventajas entre otras notaciones:
En este caso, se ha hecho un intento similar. [44] El MBTester se compone de un modelador y un motor de generación de casos de prueba. Los propietarios de empresas o los evaluadores traducen sus requisitos en árboles de comportamiento utilizando el modelador y, a continuación (opcionalmente), integran algunos árboles de comportamiento relacionados en uno compuesto. Se puede introducir un árbol de comportamiento en el motor de backend para generar casos de prueba, secuencias de comandos de prueba y datos de prueba de forma automática.
Los primeros ensayos industriales para probar la viabilidad del método y refinar su capacidad se llevaron a cabo en 2002. Durante los últimos tres años se han llevado a cabo varios ensayos sistemáticos en la industria sobre sistemas de defensa, transporte y empresariales a gran escala. [5] [31] Este trabajo ha establecido que el método se escala a sistemas con un gran número de requisitos, pero también que es importante utilizar el apoyo de herramientas [22] [45] para navegar y editar de manera eficiente esas grandes vistas integradas de datos gráficos. Varios resultados principales han surgido de este trabajo con la industria. En promedio, en varios proyectos, se han encontrado sistemáticamente 130 defectos importantes confirmados por cada 1000 requisitos después de que se hayan realizado revisiones y correcciones normales. [31] Con conjuntos de requisitos menos maduros se han observado tasas de defectos mucho más altas.
Una parte importante de este trabajo con la industria ha implicado la aplicación de la parte de análisis del método a seis proyectos de defensa a gran escala para Raytheon Australia. Consideran el método como "una estrategia clave de mitigación de riesgos, que se puede utilizar tanto en el desarrollo de soluciones como en la forma de asesorar al cliente sobre problemas con la documentación de adquisiciones". [32] [46] Un resultado de estas pruebas en la industria ha sido el desarrollo conjunto [6] con Raytheon Australia de una herramienta de gran calidad para respaldar el análisis, la edición y la visualización de grandes conjuntos integrados de requisitos. [45] Se pueden encontrar detalles más amplios de los hallazgos de la industria en el sitio web de Behavior Engineering. [47]
El Dr. Terry Stevenson (director técnico de Raytheon Australia) y el Sr. Jim Boston (director de proyectos de Raytheon Australia), el Sr. Adrian Pitman de la Organización Australiana de Material de Defensa , el Dr. Kelvin Ross (director ejecutivo de KJRoss & Associates) y Christine Cornish (Bushell & Cornish) han proporcionado las oportunidades especiales necesarias para apoyar esta investigación y llevar a cabo los ensayos industriales [5] [31] y el trabajo del proyecto en vivo. Este trabajo ha sido respaldado por el Consejo Australiano de Investigación – Centro ARC para Sistemas Complejos y fondos recibidos de la industria. [ cita requerida ]
[48]
Como representación de modelos de comportamiento, los árboles de comportamiento tienen una serie de beneficios y ventajas importantes: