Pueden arquitecturas de abajo hacia arriba pueden programar de manera efectiva en los paradigmas de arriba hacia abajo?

Question

El arquitectura subsumption , propuesta por Rodney Brooks en 1986, es un "bottom-up" acercan, en el que los robots están diseñados utilizando modelos jerárquicos simples. Estos modelos se basan en y subsumen los módulos inferiores para formar un producto final. Por ejemplo, un robot puede darse un módulo de "encontrar la apertura", que está subsumido por un módulo más abstracto "encontrar umbral", el cual es entonces sí subsumido por un módulo de "salir del campo de juego".

Ahora, obviamente, en un diseño más "orientado a objetos", que podría haber comenzado el diseño con el "salir del módulo de campo de juego", pero por el bien del argumento, supongamos que algunos de los componentes más primitivas (como "funciones ") conseguirá probablemente reutilizados en otros conceptos superiores.

Al darse cuenta de que la implementación de este robot en un lenguaje de procedimiento (o una funcional, para el caso) podría ser la más simple, pero es contraproducente tratar de concebir un robot basado en la arquitectura de subsunción en un paradigma de programación orientado a objetos? (Darse cuenta también que es quizás difícil de ponderar un paradigma de la ingeniería de software en contra de una robótica) Para obtener una solución, ¿hay alguna forma de "adaptador" que se puede implementar para aumentar la eficacia de la utilización de lo que puede ser dos paradigmas en conflicto?

Answer 1

Me gustaría generalizar esto en un escenario más común. Esto creo que tiene sentido ya que los detalles de la arquitectura de subsunción no son tal vez un aspecto primordial en la pregunta (y los mismos problemas que se producen en los campos no robóticos también).

En archtitecture software en general hay un enfoque bidireccional, o multi-paradigma de enfoque, como en la cuestión. La capa más inferior de un entorno operativo es generalmente escrito hasta la parte inferior. bits de código muy específicas se escriben en los elementos de hardware muy específicas de controlador del sistema. Estos se combinan entonces para formar los componentes de nivel superior. Sospecho que podría fácilmente describir esto como un enfoque subsunción si nos limitamos a describir nuestro robot como el propio sistema y los objetivos a los aspectos específicos de control de dicho sistema. Aunque no estoy seguro de que es improtante para hacerlo.

A partir de las mayoría de las aplicaciones de arriba hacia abajo están escritos en lenguajes de alto nivel, o descrita en términos de una máquina abstracta. Esto se quita bastante lejos de la parte inferior mayoría de las bibliotecas, que realmente va a hacer el trabajo.

En algún momento estas dos capas tienen que cumplir - en realidad se encuentran en muchos lugares en una variedad de escenarios. Aquí es donde usted tiene que "adaptarse" a las capas sea adecuado para la otra capa. El término "adaptador" aquí es 100% correcto. En efecto, existe un patrón de software llamado "adaptador" que se utiliza para este propósito.

Además de los adaptadores específicos podemos considerar actualmente la totalidad de la cadena de herramientas de programación moderno. El compilador en sí, junto con el revestimiento y una ejecución VM, son la interfaz principal entre las dos capas. Es decir, un lenguaje de alto nivel está escrito en un dominio, y el compilador es lo que le permite trabajar en los dominios de nivel inferior.

Si usted está buscando específicamente para effectivness paradigma, tenga en cuenta que existen los lenguajes de alto nivel para la programación imperativo (C ++), la programación funcional (Haskell), y la programación declarativa (Prolog). Estos paradigmas todos en última instancia de trabajo en las mismas bibliotecas de bajo nivel subyacente.

Es la pregunta en robótica muy diferente? No, no lo creo. De hecho, si las mismas ideas fueron formuladas hoy no creo que tendrían un robot término específico (arquitectura de subsunción) ya que no hay gran diferencia con respecto a la arquitectura de software normal. Incluso se indica en su último párrafo tanto un paradigma funcional e imperativo para el control de un robot. sin embargo me gustaría utilizar un lenguaje específico de dominio para ser utilizado -. y de nuevo, la gran variedad de lenguajes específicos de dominio es una prueba más de que múltiples paradigmas pueden adaptarse de manera eficiente a la otra