Proteus marco de desarrollo de arquitecturas software con enfoque a la adaptabilidad

El desarrollo de arquitecturas de software adaptables usando patrones de diseño: un
enfoque NFR
Resumen
Casi todo cambia, y así que si un sistema de software en consecuencia con el fin de sobrevivir y
tener éxito. Pero ¿cómo podemos desarrollar un sistema de este tipo de software?
Últimamente, un número creciente de profesionales han mostrado un gran interés en el uso de
patrones de diseño para el desarrollo de un sistema adaptable, ya que los patrones de diseño
representan abstracciones de alto nivel que reflejan la experiencia de ningún otro que los
propios profesionales cualificados. De acuerdo con un formato determinado, los patrones de
diseño describen el contexto, los problemas, las soluciones y las consecuencias de la toma de
decisiones de diseño específicos. Este artículo presenta, Proteus-un marco que está destinada a
apoyar el desarrollo de arquitecturas de software adaptables utilizando patrones de diseño. Los
principales conceptos de Proteus se ilustran por medio de un sistema de control del aparato
electrodoméstico.
Introducción
Casi todo cambia, y así que si un sistema de software en consecuencia con el fin de sobrevivir y
tener éxito. Esto es especialmente cierto en el espíritu de Brooks [1] quien afirma que el éxito
trae cambios a la mayoría de los sistemas de software y, a menudo, mayor será el éxito, mayores
serán los cambios.
Pero ¿cómo podemos desarrollar un sistema de este tipo de software? Últimamente, un número
creciente de profesionales han mostrado interés serio en el uso de patrones de diseño para el
desarrollo de un sistema adaptable, tal vez debido a los patrones de diseño representan
abstracciones de alto nivel que reflejan la experiencia de ningún otro que los propios
profesionales cualificados. En pocas palabras, patrones de diseño son abstracciones de alto nivel
que describen, de acuerdo con un formato dado, el contexto, problemas, soluciones y
consecuencias de la toma de decisiones de diseño específicos [6].
Debido a su utilidad pragmática anticipado, patrones de diseño están atrayendo un interés
comercial creciente, que se manifiesta a través de su uso en los marcos comerciales, en
particular, la Plataforma Java 2, Enterprise Edition (J2EE) -un estándar abierto para la
implementación y el despliegue de aplicaciones empresariales basadas en componentes , y su
versión bebé, la Plataforma Java 2, Mobile Edition (J2ME) para funcionar en dispositivos móviles
tales como PDA, Palm-tops, etc.
Este artículo presenta, Proteus-un marco que está destinada a apoyar el desarrollo de
arquitecturas de software adaptables utilizando patrones de diseño.
Proteus es un proyecto en curso [4,5], que tiene un enfoque orientadas hacia fines específicos
aumentar los patrones de diseño enfoque orientado a objetos subyacentes. Proteus utiliza el
marco NFR [3,10], en el que la capacidad de adaptación de software, como un requisito no
funcional (NFR), se trata como un softgoal que se satisficed (es decir, no se logra absolutamente
pero dentro de límites aceptables). Formalmente, esta noción de '' satisfacción '' es fundamental
en la comprensión de lo que realmente se está intentando durante el desarrollo de software.
Esto se debe, por un lado el significado de la capacidad de adaptación como parte del
planteamiento del problema es más a menudo que no depende del contexto, poco clara y
contradictoria con otras NFR, y el espacio del espacio de diseño para cumplir con los requisitos
de adaptabilidad es potencialmente enorme, si no se infinita, por el otro. Muy apropiadamente,
Proteus también se beneficia de otros trabajos relacionados, incluyendo [14], que también
utiliza el Marco NFR para el desarrollo de la arquitectura de software adaptable, pero no en
relación con los patrones de diseño y, además, en el establecimiento de sistemas embebidos.
Otra fuente de ideas para Proteus es, por supuesto, los diversos trabajos en los patrones de
diseño, incluyendo [2,6,8,9,11 - 13]. énfasis Proteus' en adaptabilidad es complementaria a [7],
que mira a los patrones de diseño con agente de orientación como un énfasis.
Ejecucion de example
A lo largo del resto del documento, usamos como nuestro ejemplo de funcionamiento de un
sistema de control del aparato electrodoméstico (HAC). El uso de un HACS, un usuario controla,
supervisa y coordina los aparatos electrodomésticos tales como aire acondicionado, hornos de
microondas, televisores, luces de interior / exterior, rociadores de agua, e incluso dispositivos
de seguridad para el hogar y spas. Una parte principal del sistema es un controlador situado
típicamente dentro de una casa, que por un lado se comunica con los aparatos
electrodomésticos, y también con un dispositivo remoto tal como un teléfono móvil o un
ordenador de bolsillo, por el otro. Podría haber varios tipos de cambios en las necesidades de
este tipo de sistema debido a los cambios en la tecnología subyacente (por ejemplo, los avances
en los protocolos de comunicación) y también debido a los cambios en las necesidades del
cliente (por ejemplo, usted podría quedar atrapado en un atasco de tráfico,
La sección 2 presenta una visión general de Proteus, en particular, los pasos a seguir en el
desarrollo de arquitecturas de software adaptables utilizando patrones de diseño. La sección 3
presenta la fase de requisitos del proceso de Proteus. La sección 4 presenta el diseño
arquitectónico macroscópica, mientras que la Sección 5 presenta la forma de analizar y utilizar,
o no usar, esos patrones de diseño que tienen el potencial para mejorar la capacidad de
adaptación del software a un nivel más microscópico. Un resumen de las contribuciones y las
direcciones futuras se describen en la Sección 6.
2. Proteus: Visión general
Proteus tiene como objetivo apoyar el desarrollo de arquitecturas de software adaptables
utilizando patrones de diseño. Proteus es un proyecto en curso [4,5], que tiene un enfoque
orientado a los objetivos mediante la adopción del Marco NFR [3,10], por lo tanto, aumentar el
enfoque orientado a objetos subyacentes a los mecanismos de representación de patrones de
diseño. En Proteus, adaptabilidad software como un requisito no funcional (NFR) se trata como
un softgoal que se satisfice (es decir, consigue no absolutamente pero dentro de límites
aceptables). Formalmente, esta noción de '' satisfacción '' es fundamental en la comprensión de
lo que realmente se está intentando durante el desarrollo de software. Esto se debe, por un lado
el significado de la capacidad de adaptación como parte del planteamiento del problema es más
a menudo que no depende del contexto, poco clara y contradictoria con otras NFR, y el espacio
del espacio de diseño para cumplir con los requisitos de adaptabilidad es potencialmente
enorme, si no es infinita. Muy apropiadamente, Proteus entonces explora ambas alternativas de
definición y de diseño para satisfice la softgoal adaptabilidad, analiza las compensaciones entre
las alternativas, estima el impacto de los patrones de diseño alternativos a la capacidad de
adaptación de software, y selecciona entre las alternativas en relación con las características del
dominio (es decir, el contexto y problema).
Uso de Proteus, entonces, un proceso de diseño arquitectónico sería proceder como sigue:
(1) los requisitos de Post-adaptabilidad, junto con cualquier otro NFR importantes, así como los
requisitos funcionales.
(2) Refinar los NFR y dar prioridad a ellos, teniendo en cuenta las características particulares del
dominio previsto.
(3) Considere conceptos arquitectónicos y alternativas, a nivel macroscópico, para cumplir con
los requisitos indicados, tanto funcionales y no funcionales.
(4) Considere los patrones de diseño, a un nivel más microscópico, que satisfice los conceptos
arquitectónicos y alternativas que están siendo consideradas. Esta consideración debe hacerse
en términos del contexto y los problemas asociados con cada uno de los patrones de diseño.
(5) Analizar las compensaciones entre las alternativas de arquitecturas y sus correspondientes
patrones de diseño, en relación a la capacidad de adaptación y cualquier otra NFR declarados,
mientras que la realización de análisis de impacto.
(6) Seleccionar entre las alternativas de arquitecturas y sus correspondientes patrones de diseño
que mejor satisfice la adaptabilidad y otros NFR en el contexto del dominio de aplicación
prevista.
(7) componen los patrones de diseño seleccionados en partes del diseño arquitectónico
seleccionado.
Los pasos en el proceso completo se intercalación e iterativo, y llevaron a cabo en términos de
una representación visual, llamado gráfico interdependencia softgoal (SIG), donde cada nodo
representa un softgoal y cada enlace entre un objetivo matriz y sus descendientes representa el
grado en que los descendientes (positiva o negativamente) contribuyen a la satisficing del
softgoal padres. Con capacidad representaciones informales, semiformales y formales, un SIG
actúa no sólo como un medio para llegar al final (un diseño arquitectónico), sino también como
una historia de desarrollo, que luego puede usarse para entender la razón de ser de varias
decisiones de diseño y hacer mejoras.
3. Refinamientos de los Requisitos de adaptabilidad.
En Proteus, el primer paso es los requisitos post-adaptabilidad, junto con cualquier otro NFR
importantes, así como los requisitos funcionales (FRs). En este trabajo, se supone que FRs se
indican en una (y orientado a agentes) de manera orientada a objetos.
Desafortunadamente, sin embargo, la idea de la capacidad de adaptación es a menudo poco
claras cuyo significado parece depender más fuertemente en el alcance y la naturaleza del
proyecto de desarrollo de software en particular para los que el requisito se ha indicado. Por lo
tanto, sin una clarificación adecuada de lo que los requisitos de adaptabilidad realmente podrían
significar, cualquier intento de alcanzar los requisitos es más probable que va a ser inútil. En
Proteus, el primer paso hacia el desarrollo de un sistema de software adaptable es refinamientos
de los requisitos de adaptabilidad.
Por ejemplo, la Fig. 1 muestra un SIG para el desarrollo de un sistema de control del aparato
electrodoméstico adaptable. El requisito de adaptabilidad '' El HACS será adaptable '' se
representa como un softgoal (una nube fina), la adaptabilidad [HACS], que se refina a
continuación, en términos de una y la descomposición (un solo arco) en dos objetivos
descendientes: detectabilidad [ cambio en el ambiente] y Transformabilidad [HACS]. Aquí, un Edescomposición significa que con el fin de satisfice Adaptabilidad [HACS], debemos satisfice sus
dos descendientes softgoals: maximizar la capacidad de detectar los cambios en el medio
ambiente y aumentar al máximo la capacidad de transformar el sistema. Este último softgoal,
Transformabilidad [HACS], a su vez es más y descompuesta en dos sub-objetivos: reconocibilidad
[Cambio en HACS] y Enactability [Cambio en HACS], respectivamente, para maximizar la
capacidad de reconocer los cambios necesarios a realizar en el sistema y la maximización de la
capacidad para realizar el cambio reconocido. El objetivo superior es también OR-descompone
(un doble arco) en Automatic Adaptabilidad [HACS] y Adaptabilidad Manual [HACS],
respectivamente, para la fabricación de adaptación de tiempo de ejecución (por ejemplo,
usando rutinas de biblioteca) y para hacer que la adaptación en tiempo de desarrollo. Cuando
un objetivo se descompone se multiplican, no puede haber un producto cartesiano de subobjetivos.
Para este sistema, las respuestas rápidas del sistema se considera que son de suma importancia,
ya que por ejemplo puede haber una anciana en el interior de la casa y un incendio en el horno
o en una entrada de robo potencialmente convertirse en una amenaza para la vida, situación.
Por lo tanto, la velocidad [HACS] también está publicada como requisito NFR, y dado una mayor
prioridad (! Symbol) que el requisito de la capacidad de adaptación, presumiblemente, de
acuerdo a las necesidades del cliente.
4. Operacionalizar los Requisitos de adaptabilidad. Arquitecturas utilizando
Una vez que la capacidad de adaptación y otros tipos de NFR se han perfeccionado lo suficiente,
el siguiente paso en Proteus es considerar alternativas arquitectónicas, a nivel macroscópico,
para cumplir con los requisitos establecidos, tanto funcionales como no funcionales. Para que
esto suceda, sin embargo, el tipo de refinamientos en el apartado anterior no es suficiente,
aunque puede ser para el cliente. Es el momento de estar preocupado con más orientado a la
arquitectura-satisficing de los requisitos de adaptabilidad refinados.
La Fig. 2 muestra cómo se hace esto. Transformabilidad [HACS] está conectado a dos nubes
oscuras a través de negrita, líneas verdes (+): Low acoplamiento [Arquitectura, HACS] y alta
cohesión [Arquitectura, HACS] (un módulo que lleva a cabo una sola función tiene una alta
cohesión, y vice versa), que representan las técnicas de diseño de nivel de arquitectura para
satisficing positivamente Transformabilidad [HACS]. La Fig. 2 muestra también la consideración
de conexión indirecta [Arquitectura, HACS] (por ejemplo, la conexión no basado en ninguna
invocación procedimiento explícito) y Conexión Mediada (por ejemplo, la conexión sobre la base
de un tercero o incluso múltiples partes) como un par de arquitectura técnicas -level a satisfice
bajo acoplamiento [Arquitectura, HACS].
En el lado funcional, observamos que HACS necesita mecanismos para la comunicación entre los
dispositivos y la coordinación entre los procesos. También observamos que HACS necesita
mecanismos para adaptarse a diferentes necesidades del usuario. Por ejemplo, cuando el
usuario está muy hambriento, el horno microondas puede tener que responder a la solicitud del
usuario que opere al máximo para cocinar la comida tan rápido como se pueda.
5. Arquitecturas Operacionalizar utilizando el diseño de patrones
Una vez que se han determinado las consideraciones de diseño arquitectónico macroscópicas,
el siguiente paso en Proteus es considerar los patrones de diseño, a un nivel más microscópico,
que satisfice las alternativas arquitectónicas están considerando. Esta consideración debe
hacerse en términos del contexto y los problemas asociados con cada uno de los patrones de
diseño.
Varios modelos han sido identificados como (potencialmente) la mejora de la adaptabilidad de
los sistemas de software en tiempo real [13]. Algunos de estos que parecen encajar las
necesidades funcionales y funcionales de las consideraciones arquitectónicas en el apartado
anterior incluyen la envoltura, Reactor, y los patrones de estrategia.
La intención del patrón Wrapper (consulte la Fig. 3) es encapsular funciones de nivel inferior
dentro de interfaces de clase portátiles de tipo seguro, modular, y. Ayuda a (1) evitar tedioso y
propenso a errores, y la programación no portátil de mecanismos IPC de bajo nivel (por ejemplo,
a través de tuberías, memoria compartida, semáforos, tomas de corriente, llantas, etc.) y (2)
combinar múltiples relacionado, pero independiente, funciones en un único abstracción
cohesiva. Observamos aquí que este modelo utiliza un tercero, es decir, una envoltura, entre el
cliente y el servidor, por lo tanto, una conexión mediada, en el manejo de mecanismos IPC (por
ejemplo, entre el controlador y un electrodoméstico), y mejora la cohesión.
La intención de la Patrón Reactor (véase la Fig. 4) es disociar demultiplexación evento y
controlador de eventos envío de los servicios realizados en respuesta a eventos. Ayuda a (1)
demultiplexar múltiples tipos de eventos desde múltiples fuentes de eventos de manera
eficiente dentro de un único hilo de control y (2) se extienden comportamiento de la aplicación
sin requerir cambios en la demultiplexación evento / envío de marco. Observamos aquí que este
patrón no utiliza ningún tipo de invocación explícita, sino un mecanismo de eventos, por lo
tanto, la conexión indirecta, pero al mismo tiempo un uso más intensivo de los eventos que
puede conducir a la degradación del rendimiento de la velocidad.
La intención de la patrón de estrategia (véase la Fig. 5) es definir una familia de algoritmos,
encapsular cada uno, y que sean intercambiables. Estrategia permite que el algoritmo de variar
independientemente de los clientes que lo utilizan. Esto ayuda a extender las políticas para la
publicidad, escuchar, crear, aceptar y ejecutar un controlador de servicio sin modificar el
algoritmo central. Observamos aquí que este patrón también utiliza '' estrategia '' como un
objeto intermedio.
La Fig. 6 muestra cómo el SIG en la Fig. 2 se ha ampliado con los tres patrones de diseño. Aunque
no se muestra en el SIG, la descripción de cada patrón de diseño se puede asociar con su
correspondiente softgoal (nube). Tenga en cuenta que estos patrones de diseño siguen siendo
tratadas como softgoals, ya que sus significados parecen todavía no es muy clara y también
parece que hay ninguna garantía de que se logrará absolutamente. La Fig. 6 muestra también
cómo estos patrones potenciales de diseño adaptabilityenhancing se comercializan fuera, en
relación a la capacidad de adaptación y cualesquiera otros NFR se indica en el contexto del
dominio de aplicación prevista. Este análisis compensación conduce a la selección entre los
patrones de diseño de la competencia, por lo tanto, entre las arquitecturas alternativas.
La Fig. 6 muestra tales consideraciones que implican detectabilidad [Cambio en medio
ambiente] y el patrón Reactor [Arquitectura, HACS]. La detección de cambios en el entorno suele
ser una tarea que consume mucho tiempo, por lo tanto, perjudicando la velocidad. Esta relación
negativa se muestra con una línea en negrita rojo (-). Del mismo modo, la detección de eventos
para el patrón Reactor podría inducir pérdida de rendimiento significativa. Para el sistema HACS,
donde la velocidad es considerada una llave NFR, puede necesitar ser comprometida en favor
de la velocidad de adaptación. Aunque se omite aquí, este proceso implicaría la realización de
análisis del efecto de elegir o no elegir un patrón de diseño en sus softgoals padres y todo el
camino hasta los softgoals de alto nivel, utilizando el algoritmo de propagación de la etiqueta
como se describe en la Ref. [3].
El último paso en Proteus es componer los patrones de diseño seleccionados en partes del
diseño arquitectónico seleccionado. Asumir la estrategia y los patrones de envoltura son
elegidos por el sistema. Ahora, cómo deberían ser utilizados en la arquitectura de destino?
Algunas de las posibilidades son: no hay interacción entre los dos, hay solapamiento entre los
dos, pero con algunas interacciones directas, cierta superposición, al menos con interfaces, etc.
La Fig. 7 muestra cómo el diseñador ha compuesto los dos patrones, el patrón de envoltura para
activar los aparatos electrodomésticos y el patrón de estrategia para permitir diferentes formas
de cocinar. Por ejemplo, si el usuario está hambriento, cansado y puede volver a casa tarde,
entonces el sistema se le puede pedir a cocinar completamente la comida junto a la hora
prevista de llegada, y periódica calentando cada 10 minutos después.
6. Conclusiones
La mejora de la capacidad de adaptación de software es una tarea formidable tanto como la
adaptación de software es inevitable en la realidad. Un concepto bastante intrigante que
promueve fuertemente la capacidad de adaptación es patrones de diseño, que recientemente
ha estado atrayendo cada vez mayores intereses en la academia y la industria. En este trabajo
se ha presentado Proteus que pretende ayudar a los arquitectos de software desarrollar
arquitecturas de software adaptables utilizando patrones de diseño. En particular, este trabajo
se ha presentado la forma de analizar y utilizar patrones de diseño como posibles potenciadores
de adaptabilidad en el desarrollo de sistemas de software.
El trabajo futuro incluye el uso del enfoque de Proteus para J2EE / J2ME y otros tipos de
aplicaciones del sistema. Otra línea de investigación se refiere Construcción y pueblan las bases
de conocimiento Proteus hacia un soporte de herramientas. base de conocimientos Proteus' de
patrones de diseño se organizará a lo largo de un conjunto de jerarquías, la captura de patrones
generales y-adaptabilidad específica (por ejemplo, [6,9,11,13]). Una investigación más
fundamental estaría considerando métodos para mapear las categorías lenguaje de patrones en
las categorías de representación SIG.
referencias
[1] FP Brooks Jr., Sin bala de plata: esencia y accidentes de ingeniería de software, Computer
Magazine, 1987 (abril) 10 - 19.
[2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, patrón-Oriented Software
Architecture-un sistema de modelos, Wiley, Nueva York, Nueva York, 1996.
[3] L. Chung, BA Nixon, E. Yu, J. Mylopoulos, requisitos no funcionales en Ingeniería de Software,
Kluwer Academic Publishing, Boston, MA, 2000.
[4] L. Chung, patrones de diseño para adaptables sistemas de tiempo real, UKC'01 10 de agosto
- 12, Boston, MA.
[5] L. Chung, K. Cooper, A. Yi, Desarrollo de arquitecturas de software adaptables para sistemas
de tiempo real utilizando patrones de diseño, SERP'02, 24 de junio - 27, Las Vegas, Nevada.
[6] E. Gamma, R. Helm, R. Johnson, J. Vlissides, patrones de diseño: Elementos de software
reutilizables orientada a objetos, Addison-Wesley, Reading, MA, 1994.
[7] D. Gross, E. Yu, en: A partir de requisitos no funcionales de diseño a través de patrones,
Ingeniería de Requisitos, vol. 6, Springer, Londres, Reino Unido, 2001, pp. 18 - 36.
[8] G. Gullekson, B. Selic, patrones de diseño de software en tiempo real, sistemas integrados
Conf., West'96.
[9] C. Irving, D. Eichmann, Patrones de Diseño y adaptabilidad, 3ª Conferencia Anual sobre el
patrón de Idiomas de los programas, Allenon Park, Illinois 4 de septiembre - 6, 1996.
[10] J. Mylopoulos, L. Chung, SSY Liao, H. Wang, E. Yu, Extensión de análisis orientado a objetos
para explorar alternativas, IEEE Software (2001 enero / febrero) 2 - 6.
[11] W. Pree, patrones de diseño para el desarrollo orientado a objetos, Reading, MA: Addison
Wesley y pulse ACM, 1995.
[12] A. Sane, R. Campbell, mensajes compuestos: Un modelo estructural para la comunicación
entre los componentes, OOPSLA Taller sobre patrones de diseño para concurrente, paralelo y
Sistemas Distribuidos orientada a objetos, 1995.
[13] DC Schmidt, M. Stal, H. Rohnert, F. Buschmann, PatternOriented Arquitectura de Software:
Patrones de objetos concurrentes y en red, Wiley, Nueva York, Nueva York, 2000.
[14] N. Subramanian, L. Chung, Software Architecture Adaptability: An NFR Approach, IWPSE’01,
IEEE Computer Society Press.