Professional Documents
Culture Documents
Resumen
Estamos investigando la aplicación del modelo del sistema viable de Beer para el desarrollo de
software para aplicaciones "complejas" . Usamos este modelo como base para una arquitectura de
componentes del sistema, la Arquitectura del Sistema Viable. Una clave de la construcción de la
arquitectura es la estructura de un componente y su conjunto de interfaces especiales, un
"componente viable". Tras la presentación del Modelo de Sistemas Viables y la Arquitectura del
sistema viable, se esboza una metodología de diseño para el desarrollo de componentes de software
en este enfoque.
1. Introducción
Stafford Beer ha desarrollado el Modelo de Sistemas Viables (MSV) [1] con el fin de comprender,
predecir y controlar las las organizaciones humanas o "empresas". El MSV se basa en el estudio y la
observación de muchas organizaciones durante un período de treinta años. El objetivo de Beer fue
descubrir las estructuras invariantes y los comportamientos y los describen sobre la base de la
cibernética. Tomamos este modelo como punto de partida para el modelado de "complejos "
sistemas a fin de construir un mejor software.
Ejemplos de sistemas de software complejos incluyen entornos inteligentes, Informática Ambiental,
Sistemas Multi-Agente, Interfaces de Usuario adaptables / Inteligentes y Business-to-Business e-
Commerce. Estos sistemas se caracterizan por un gran número de componentes heterogéneos con
un alto grado de interconexiones, relaciones y dependencias. Ellos existen en un entorno de cambio
dinámico que exige un comportamiento de respuestas dinámicas. En otras palabras, estos sistemas
deben adaptarse a su entorno.
A modo de introducción y motivación para el enfoque considere el sistema de control del automóvil
crucero de la Figura 1. Se trata de un típico sistema de control de lazo cerrado en el controlador de
monitorea y mantiene una variable del sistema, la velocidad, dentro de ciertos límites deseados. El
sistema en general está sujeto a perturbaciones ambientales (tales como una colina empinada) y el
controlador, basado en la retroalimentación, ajusta el acelerador cuando sea necesario.
El control del automóvil crucero es uno de los problemas de diseño orientado a objetos "canónicos".
Shaw analiza este problema y desarrolla un paradigma de control para software [2]. Su idea es que
se trata de un sistema de control y hay un cuerpo de conocimientos de ingeniería asociadas a estos
sistemas. Ella sostiene que el paradigma orientado a objetos no puede ser el enfoque más adecuado
en este caso. Se desarrolla una arquitectura de software basada en la teoría clásica de control de
realimentación en lugar de una arquitectura basada exclusivamente en la identificación de objetos y
sus relaciones.
Señala el paradigma de control separado de la planta (el motor en este caso) del proceso principal
de la compensación por las perturbaciones externas, el control. Esta separación de interés produce
abstracciones apropiadas que conducen a resultados de diseño que de otra manera se puede perder
en el enfoque (de dominio neutro) orientado a objetos. En particular, el rendimiento y las
limitaciones de la corrección se identifican temprano en el proceso de diseño.
Shaw ofrece la siguiente regla de oro para el uso de la arquitectura del paradigma de control:
Cuando la ejecución de un sistema de software se ve afectada por perturbaciones externas, fuerzas,
o eventos que no son directamente visibles, o controlables, el paradigma de control debe ser
considerado para la arquitectura de software.
Al analizar el problema de control de crucero Shaw reconoció que la teoría de control fue el
contexto más apropiado para el problema. Reivindicamos la regla de oro es el caso general de los
sistemas "complejos" de software. Sostenemos que este tipo de sistemas de software debe ser
diseñado para adaptarse a las perturbaciones externas. La teoría del control en general y la
Cibernética en particular, ofrecen un enfoque para hacer esto. Si la teoría subyacente y principios de
la Cibernética son general de hecho, entonces no hay otra opción - que no se puede evitar en
cualquier sistema de procesamiento de información no trivial. Por ejemplo, hemos demostrado que
el patrón de diseño de mayor éxito, Modelo-Vista-controlador, es un sistema de control de lazo
cerrado [3].
Por lo tanto, después de una búsqueda y evaluación considerable, se optó por el MSV como base
para el desarrollo de la Arquitectura de Sistema Viable (ASV) [4]. Desde el punto de vista de
software, el MSV se puede considerar como el lenguaje de patrones de los sistemas complejos. El
ASV es el arquitectura de alto nivel basado en el MSV. La arquitectura ASV define una estructura
de componente único, el "componente viable" y un conjunto de interfaces de componentes que en
términos define el marco en sí.
En este artículo nos centramos en la estructura, diseño e implementación del componente
fundamental. Comenzamos con una breve introducción al MSV. A continuación, la ASV se presenta
como el marco de componente. Las cualidades deseadas del software desarrollado sobre la base de
este enfoque son presentados. Los principios que conducen a estas cualidades se describen. La
estructura interna del componente y sus interfaces se da en detalle. Por último, una metodología o
secuencia de pasos para el diseño de los componentes viables se describe.
Hay ciertas invariantes estructurales y de comportamiento claves en el MSV que se realizan sobre la
ASV. La separación fundamental de control y objeto de control (planta) es uno. La organización
interna del controlador es otro, las funciones 5-4-3-2-1 descritas en la última sección. El requisito
de autonomía en cada nivel es otro. La recursividad y la jerarquía son también invariantes en el
sistema viable. Estas invariantes dan lugar a la estructura auto-similar (fractal) del sistema. Una vez
que comprendidos estos, cualquier nivel de subsistema se puede entender. En gran medida el
concepto de auto-referencia abarca muchos de los principios de la arquitectura deseada. La auto-
referencia es la característica de un sistema de tal manera que cada parte tiene sentido en términos
de las otras partes. El sistema define o se produce sobre la base de las partes y su disposición. Esta
propiedad también se conoce como cierre lógico y está relacionado con la identidad, la conciencia
de sí mismo, auto-reparación y la recursividad misma.
La presentación de hasta el momento puede parecer muy abstracto, pero alegan que es la base
teórica necesaria para alcanzar el tipo de marco de componentes de software necesarios para apoyar
la diseño de sistemas complejos. La tarea de la siguiente sección de es hacer estas abstracciones
concretas.
Este conjunto de nueve tipos de interfaz es la clave de la construcción de la arquitectura. Ellos son
el mecanismo por el cual los principios descritos anteriormente se logran. Dada la naturaleza
recursiva y autorreferencial del modelo, la especificación de interfaz de componente viable define el
marco en sí. Este acuerdo preveía un sistema auto-similar de arquitectura de componentes de sub-
sistemas en los que puede ser cualquier nivel tratado como un componente o un marco de
componentes. Desde una perspectiva de interfaz ellos son equivalentes.
Una interfaz define la especificación de entrada y salida entre dos elementos del sistema. Algunos
ejemplos son las interfaces entre las operaciones en un nivel y operaciones en el nivel
inmediatamente inferior, entre la planta y su entorno y entre dos plantas. En el ASV todas las
interfaces son circuitos de retroalimentación (véase la leyenda en la figura 3). Estas interfaces
tienen una estructura particular que se muestra en la Figura 5
Tradicionalmente, los componentes de software se desarrollan en forma aislada. Se distribuyen con
una especificación de interfaz y es el trabajo del usuario (programador) para embalar, pegar o de
otra manera integrar el componente en el sistema previsto. La plataforma de componentes de la
ASV define un modelo estándar de las interfaces de un componente. Esto permite el diseño con el
conocimiento de los componentes en ambos lados de la interfaz. El objetivo es lograr un equilibrio
dinámico - homeostasis - para cada conjunto de componentes acoplados.
El diseño de interfaz comienza por establecer "criterios de estabilidad" para la interfaz entre los dos
sistemas. Por ejemplo, si un componente está transmitiendo a 2,4 GHz, el receptor debe ser capaz
de recibir a esa velocidad. De lo contrario, los búferes internos del receptor puede desbordarse,
provocando retransmisiones, etc En otras palabras, será el sistema impulsado fuera de equilibrio y
puede fallar lo que afecta a otras partes del sistema. Con base en los criterios de diseño para la
interfaz, "los acuerdos" de entrada y salida son diseñados e implementados.
La forma general de dicho acuerdo es un canal con transductores en cada extremo. El canal es el
medio para la comunicación. Los transductores pueden ser necesarios para que coincida con "los
acuerdos" de entrada / salida. Por ejemplo, la información se codifica en un formato (XML), la
transmisión (HTTP) y se descifra en otro formato (XSL a HTML). Puede haber múltiples acuerdos
involucrados en una interfaz. Los criterios de diseño deben ser desarrollados para acomodar a todos.
Por último, cabe señalar que las interfaces no están diseñadas de forma aislada. Por ejemplo,
supongamos que las tres plantas se van a conectar el uno al otro. En este caso las prescripciones de
estabilidad se deben desarrollar con todas las interfaces en mente, o el diseño rehecho, como los
nuevos requerimientos de interfaz descubiertos.
En esta sección se describe una metodología, una secuencia de pasos para el diseño de sistemas de
software basados en la ASV. Estos pasos son una síntesis de los enfoques que figuran en Beer [1], el
control tradicionalboth [6] y los aspectos de control difuso [5]. El objetivo es describir un método
de diseño de un componente a un nivel en una jerarquía recursiva de sub-sistemas. En primer lugar,
es necesario elegir un nivel en el que se inicia. Esta elección estará determinada por los
requerimientos de la aplicación. Por ejemplo, nuestra tarea puede ser ensamblar un conjunto de
componentes viables en un nuevo sistema de software viable para algunos fines declarados. En ese
caso, habría, en cambio, los componentes de software construidos según las especificaciones del
marco de ASV. Es decir, un componente de software con un conjunto de interfaces como se describe
anteriormente y se muestra en las figuras 4 y 5. Estos pueden ser tratados como componentes de
"caja negra". En este caso, el conjunto de especificaciones de la interfaz y una descripción del
comportamiento de los componentes proporcionar toda la información necesaria para diseñar en el
siguiente nivel de la jerarquía. Por otro lado, puede ser iniciado al "nivel base." Aquí se nos da una
planta, por ejemplo, una cámara digital o un servidor de archivos, y la tarea es diseñar un
controlador de conforme al marco de ASV para que pueda convertirse en un sub-sistema viable
dentro de nuestra arquitectura general del sistema. Presentamos este caso el diseño seguidamente.
El primer paso es identificar el "sistemafoco". Es decir, definir con claridad y dar un nombre al
sistema por el que se construye el controlador. El meta-sistema o tipo de meta-sistema al que se
integrará el "Sistema-foco", es generalmente conocido. (El sistema foco suele ser incorporado en
muchos meta-sistemas.) También, definir claramente los sistemas que incorpora el sistema foco, si
los hay. Es útil usar una técnica de diagramación como en la Figura 3. Al referirse a esa figura,
elegimos "1 A + A "como el sistema foco para el resto de esta sección. Nuestro objetivo ahora es
crear el controlador, "1A", para la planta "A". Nosotros nombramos el sistema foco como sistema
A. both
Una vez identificado el sistema foco, el sistema A, se lleva a cabo un análisis detallado. El propósito
de este análisis es determinar los requisitos de rendimiento del sistema A en relación con su meta-
sistema y el medio ambiente. El análisis describe las principales subdivisiones del sistema: Planta,
Control y Medio Ambiente. Los requisitos de rendimiento global del sistema A se especifican como
flujos de información entre sus principales subdivisiones. Esto incluye la identificación de los
sensores y actuadores. El resultado de este paso debe ser un modelo y una simulación del sistema.
Las técnicas de modelado elegidas dependerán de la naturaleza de la planta. Estos van enfocados
desde sistemas "duros " o "suaves" . Los sistemas duros se puede describir explícitamente por
ecuaciones mientras que los sistemas blandos se describen mediante heurísticas (por ejemplo,
basado en reglas). Por lo general, una mezcla de los dos es necesario.
Con la comprensión de un sistema, sus requerimientos funcionales y su simulación, un diseño
detallado de su controlador se puede lograr. Este diseño está necesariamente limitada por la planta y
el meta-sistema en el que deben operar. Es decir, los dos pasos siguientes, el diseño del controlador
y el diseño de la interfaz del meta-sistema están relacionados entre sí. Se describe el diseño de
interfaz seguidamente.
Las interfaces del sistema A con su meta-sistema donde se empotra se determinan (si existe) o
diseñados según sea necesario. Estas son exactamente las nueve interfaces descritas anteriormente y
se muestra en la Figura 4. Tenga en cuenta que hay tres grupos de interfaces para tener en cuenta:
sistema A al meta-sistema (enumerados del 2 al 7), el sistema A con el medio ambiente (0 y 1), y _el
sistema A con otros sistemas en el mismo nivel (2 ' y 6). La naturaleza de estas interfaces se
describe en detalle en la sección anterior. Tenga en cuenta que cada una de estas interfaces entre los
elementos dentro del sistema A, un controlador del sistema y la planta y los elementos del sistema
de otro sistema como se indica en la Figura 5.
El controlador consta de la elementos 2-5 como se muestra en la Figura 3. El problema es ahora
para el diseño. El orden en que fueron concebidos depende de las siguientes consideraciones. Si hay
componentes existentes en el nivel inmediatamente superior, que puede tener una fuerte influencia
sobre la representación de las construcciones fundamentales como las políticas, planes, etc En este
caso, el examen de las interfaces como se describe arriba primero puede indicar un enfoque de
arriba abajo. Es decir, puede ser más fácil empezar con la función ejecutiva (5) . Además, si hay
sistemas en el mismo nivel con la participación directa y conexiones a cabo, el diseño del regulador
(2) para la programación y la coordinación estará parcialmente determinada.
En ausencia de restricciones conocidas, comenzar el diseño del controlador con la triada de
Operaciones-Regulador-Auditor , ya que está más estrechamente asociado con la planta. Esto
corresponde a un "controlador estándar" en la mayoría de los enfoques de diseño del controlador.
En la ASV, el Regulador y el Auditor se distinguen por la naturaleza jerárquica de la estructura.
Tienen vínculos explícitos con los elementos similares con otros controladores en los niveles
superiores y en el mismo nivel. Por tanto, es conveniente para ellos representar como objetos
separados. Ahora, es preciso señalar que sólo en la medida se puede dar en el diseño de un
controlador. El diseño exacto es intrínsecamente dependiente de la planta específica. Las referencias
generales sobre el control se dan al principio de esta sección. Ha sido nuestra experiencia en
dominios tales como entornos inteligentes y de empresa a empresa, de que los elementos de los
enfoques de la teoría de control estándar, la teoría de control difusa y enfoques, basado en reglas
(AI) generalmente se combinan para lograr una solución. Teniendo esto en mente, la orientación
general se imparte.
La función de las Operaciones ejerce un control inmediato de la planta. Lo hace a través de los
sensores y actuadores identificadas en la fase de modelado. En la fase de diseño, la simulación es lo
más importante. La simulación especifica qué variables de control están disponibles para la
manipulación y se utiliza para el prototipo del módulo de Operaciones. Una serie de comandos
básicos se implementa normalmente como Start, Stop, Pause, Reset, etc. En términos de supervición
de la planta, si es posible, una capa de software o en la parte superior de la planta proporciona
informes de estado de rutina en un formato apropiado para las Operaciones y las funciones de
control. Estos informes de estado (sobre las variables internas de la planta) son la principal fuente
de información en la cual el algoritmo de operaciones de control estan diseñadas. Hemos
encontrado un enfoque basado en reglas que ofrece una considerable flexibilidad en la aplicación de
estos algoritmos.
Las operaciones dirigen tanto el regulador y como al Auditor. La principal función del regulador es
la implementación de un Plan. Un plan es un programa de actividades para la planta. El regulador
también coordina el plan con los componentes en el siguiente nivel superior y en el mismo nivel. Es
necesario determinar una representación del plan y sus actividades en relación con las posibles
acciones de la Planta. Una plantilla para representar las actividades que hemos encontrado útil es:
Actividad #: <Acción> <Objeto> [Antes de <Condición>] | [Después de <Condición>] | [Satisfacer
<Condición>] [, si <Condición>] [Donde <Condición>] [, de lo contrario la actividad <#> ].
La regulación es dinámica como los planes pueden ser modificados con frecuencia. Una vez más, la
aplicación del regulador utilizando un enfoque basado en reglas puede ayudar o un planificador
personalizado se puede escribir. En algunos sistemas, un regulador puede estar ya presente de
alguna forma y se puede utilizar directamente. Por ejemplo, la mayoría de bases de datos
proporcionan para el modelado de flujo de trabajo. También puede darse el caso de que la propia
planta contenga un planificador y su uso puede basarse en el enfoque más simple.
El auditor lleva a cabo inspecciones y controles para proporcionar verificación y garantía de las
operaciones que la planta está funcionando correctamente. Esto es además y con independencia del
estado normal o el estado de rutina reportado por la planta. El controlador en un nivel superior en la
jerarquía también pueden imponer condiciones para las variables de la auditoría de planta. Un
beneficio clave del Auditor es que se puede configurar para inspeccionar las variables de control en
momentos esporádicos o al azar. La información obtenida se utiliza para informar las operaciones
en el medio del ciclo de informes del estado de rutina de las plantas. En la implementación de la
función de auditoría que hemos considerado útil para proporcionan también una función separada
Contable de la Planta, si no tiene ya uno. El auditor puede estar directamente conectado con este
contador.
Planificación realiza dos funciones principales: "sintonía" de operaciones y comandos de la
transmisión del Ejecutivo de Operaciones. Mientras que las operaciones se ocupa de control interno
de la planta; Planificación anticipa las condiciones futuras a fin de informar las operaciones.
Planificación hace esto mediante la modificación de los algoritmos de las operaciones de control,
por ejemplo, cambiando las reglas en su base de reglas. Esto se refleja en cambios en las actividades
programadas por el Regulador.
Planificación debe tener un modelo con el fin de cumplir su función. Esto puede tomar la forma de
conjuntos de datos basados en ejecuciones anteriores de la planta. Este enfoque permite la
aplicación de métodos estadísticos para detectar las tendencias que se pueden utilizar para mejorar
los algoritmos de las operaciones de control. Planificación también puede hacer uso de la
simulación de planta desarrollada anteriormente. La simulación puede tomar ventaja de los datos en
tiempo real desde la planta de ejecución, así como los datos obtenidos del Entorno para ayudar a las
operaciones. La segunda función importante de la planificación es la de mediar entre el Ejecutivo y
las funciones de operaciones. Órdenes emitidas por el Ejecutivo se filtran, traducido y,
posiblemente, reordenado basado en el modelo actual de Planificación de la Planta.
Por último podemos diseñar la función Ejecutiva para el controlador del sistema "A". El Ejecutivo
sirve para proporcionar la supervisión general de las funciones de Planificación - Operaciones. Es
decir, se limita el número posible de acciones de los niveles más bajos de control. Elegimos para
expresar estas condiciones que rigen como las políticas. Por ejemplo, un lenguaje para especificar la
política como un conjunto de reglas es [7]:
Regla #: <role> [es] (obligados | Prohibida | Autorizada) [a] [hacer] (<Acción> [Antes de
<condición>] | Satisfacer <condición>) [, si <condición>] [, condición en la que <>] [, de lo
contrario ver Regla <#>].
La política es una síntesis de la política de transmisión de mando de nivel superior y la política
local. El Ejecutivo debe trasladar las normas sintetizadas en las instrucciones y los planes para la
implementación de Planificación y las operaciones. Tenga en cuenta que los términos obligados,
prohibido, y permitido hacen el lenguaje de la política por encima de una especificación declarativa.
Esta forma de regla puede ser usado para probar las afirmaciones sobre el comportamiento del
sistema. Además, las reglas declarativas pueden ser asignadas en los planes (imprescindible) y las
actividades como se describe anteriormente. Una vez más, los enfoques de programación basados
en reglas son apropiados para la aplicación de estos tipos de representaciones del conocimiento.
Esto completa la descripción del desarrollo de un componente viable a partir de una planta
existente. Ahora volvemos al problema de diseño mencionado al principio de esta sección, la de
montaje de componentes existentes en un sistema viable. Hay dos posibilidades: el diseño de un
nuevo componente (en el siguiente nivel superior) para controlar los componentes existentes y la
integración de los componentes de la salida en un sistema existente. En el primer caso el enfoque es
similar a los pasos descritos anteriormente. Es decir, un nuevo controlador está diseñado sobre la
base de los componentes existentes que proporcionan especificaciones de la interfaz de
componentes viables. En este último caso, los componentes viables existentes son ensamblados en
un marco existente. Esto puede requerir extender los componentes en ambos niveles: la dificultad
de esta tarea depende de la flexibilidad de como los componentes se implementan. Puede ser
posible introducir los transductores adecuados (como se muestra en la Figura 5) para permitir el
montaje de los componentes sin cambios. Por último, es factible desarrollar un protocolo para el
ensamblado dinámico de los componentes en los sistemas. El desarrollo de dicho protocolo se ve
facilitada por la estructura de interfaz única de los componentes. Sin embargo, los protocolos de
esta naturaleza son de dominio específico y requiere considerar la experiencia en el desarrollo de
una gama de componentes y marcos de referencia basados en estos componentes.
6. Conclusión
En este artículo hemos mostrado cómo el modelo de sistemas viables de Stafford Beer puede servir
como modelo de referencia para el desarrollo de la arquitectura de un sistema de componentes de
software para atender las necesidades de los sistemas complejos. A esto le llamamos arquitectura de
software de la arquitectura del sistema viable. El aporte clave de la arquitectura es la estructura
única de un componente y su conjunto de interfaces especiales, el "componente viable". Esta
estructura de componentes única recursivamente define el marco en sí. Hemos esbozado una
metodología de diseño para el desarrollo de esta clase de componentes. La metodología se basa en
nuestra experiencia en el desarrollo de entornos inteligentes [8] y los sistemas de negocio a negocio
(b2b) [9]. Actualmente estamos desarrollando una implementación de referencia de la arquitectura
de la plataforma de comercio electrónico en un comercio negocio a negocio (b2b).
Referencias
1. Beer, S., Diagnosing the system for organizations. 1985, Great Britain: John Wiley and Sons
Ltd.
2. Shaw, M., Beyond objects: A software design paradigm based on process control. ACM
Software Engineering Notes, 1995. 20(1).
3. Herring, C. and S. Kaplan. Cybernetic Components: A Theoretical Basis for Component
Software Systems. In Component Oriented Software Engineering Workshop (COSE'98).
1998. Adelaide, Australia: (http://www.dstc.edu.au/TU/staff/herring/cose98-ref.pdf).
4. Herring, C. and S. Kaplan. Viable Systems: The Control Paradigm for Software Architecture
Revisited. In Australian Software Engineering Conference. 2000. Canberra.
5. Passino, K.M. and S. Yurkovish, Fuzzy Control. 1998, Reading, Massachusetts: Addison-
Wesley.
6. Franklin, G.E., J.D. Powell, and A. Emami-Naeini, Feedback control of dynamic systems. 2
ed. Control Engineering, ed. T. Robbins. 1991, Reading, Massachusetts: Addison-Wesley.
7. Steen, M. and J. Derrick. Formalizing ODP Enterprise Policies. in Proceedings of Enterprise
Distributed Object Computing Conference (EDOC'99). 1999.
8. Herring, C. and S. Kaplan, Component-based software systems for smart environments, in
IEEE Personal Communications. 2000.
9. Herring, C. and Z. Milosevic. Implementing B2B Contracts Using BizTalk. in Thirty-Fourth
Hawaii International Conference on System Sciences (HICSS-34). 2000. Maui, Hawaii:
submitted.