strategy software reusable patterns pattern oriented gof example design-patterns blackboard

design-patterns - software - strategy pattern uml



¿Alguien sabe de una implementación exitosa del patrón Blackboard? (4)

He estado interesado en el patrón de Blackboard durante años (especialmente cuando estudiaba AI), sin embargo, todavía no he podido encontrar una buena implementación fuera del ámbito académico, aunque parece un patrón muy útil para la corriente tendencias en el desarrollo de software, no puedo pensar en ningún gran marco construido alrededor del patrón.

¿Alguien aquí conoce historias de éxito o fracaso relacionadas con este patrón?

Nota: Otros enlaces

Editar: Ahora me pregunto si el patrón podría tener uso como un patrón para un ecosistema mashup-able o algo así

Editar: Después de investigar un poco más, encontré un documento interesante que propone cosas como Wikipedia, es una pizarra, pero depende de los humanos como agentes. Eso solo me llevó a darme cuenta de que StackOverflow es prácticamente un sistema de Blackboard, con nosotros como agentes, compartiendo nuestro conocimiento experto sobre los problemas indeterminados establecidos en la pizarra ... de todos modos es algo de reflexión.

El patrón de pizarra es bueno para aplicaciones colaborativas. Aparte de eso, tiendo a pensar que realmente no es una muy buena idea.

La pizarra tiene una tendencia a terminar como una gran bolsa de estado compartido que crea todo tipo de patrones de acceso interesantes. Los lenguajes y las técnicas modernas intentan encapsular y controlar la gestión del estado tanto como sea posible, la pizarra es todo lo contrario.

Las veces que he encontrado que se usa en algoritmos, generalmente es una señal reveladora de no tener una comprensión inicial adecuada del problema a resolver. Entonces, "para estar seguro", usted pone demasiado estado a disposición de demasiados actores.

He eliminado este patrón de dos aplicaciones y lo reemplacé con interfaces buenas y sólidas que representaban la funcionalidad real y los requisitos de datos, y fue un éxito en ambas ocasiones;)

Es común en los sistemas C4I, donde muchos de los actores que actualizan el estado son humanos, pero algunos son agentes de software.

También he visto espacios Tuple utilizados en sistemas SCADA, pero generalmente no se llaman así, y sin tanto énfasis en el aspecto del agente de software. (aunque generalmente hay un sistema de reglas simple conectado al espacio para monitoreo)

Mi opinión es que un patrón de pizarra funcionaría muy bien cuando se tiene un conjunto limitado de datos, que varios actores pueden trabajar en paralelo, y donde el conjunto de datos debe ser refinado y refinado. Permite que los actores se escriban completamente separados, con una interfaz muy simple y todos ejecutando de forma asíncrona.

Como buen candidato para esto sería nuestro sistema.

Nuestro sistema de visión tiene algunos datos fundamentales (imágenes) y tenemos muchos algoritmos que producen nuevos datos a partir de estos. Muy a menudo vemos que un algoritmo podría hacer un buen uso de la información que producen otros algoritmos, pero tenemos formas muy pobres de compartirlos, ya que los argumentos normales a través de los mensajes en un o-sistema rápidamente harían una lista para manejar. También tenemos el problema de que parte de la información que encontramos al final del proceso podría mejorar las suposiciones tempranas, pero hacerlo requeriría un mayor flujo de argumentos.

Lamentablemente, tal refactorización requerirá más recursos de los que tenemos actualmente :(

Eche un vistazo a tuplespaces y sus implementaciones. Nunca tuvo un gran impacto, pero sigue siendo un enfoque interesante hacia la construcción de aplicaciones distribuidas.