Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Marco Arquitectonico
Marco Arquitectonico
SALIR
TESIS DOCTORAL
Dirigida por: D. Juan Manuel Murillo Rodrguez Titular de Universidad rea de Lenguajes y Sistemas Informticos
Presentada por: Da. Amparo Navasa Martnez para optar al grado de Doctor en Ingeniera Informtica
MEN
SALIR
MEN
SALIR
D. Juan Manuel Murillo Rodrguez, Titular de Universidad en el rea de Lenguajes y Sistemas Informticos del Departamento de Ingeniera de Sistemas Informticos y Telemticos de la Universidad de Extremadura
Certifica que
Da. Amparo Navasa Martnez, Licenciada en Matemticas, ha realizado en el Departamento de Ingeniera de Sistemas Informticos y Telemticos de la Universidad de Extremadura, bajo mi direccin, el trabajo de investigacin correspondiente a su Tesis Doctoral titulada
Fdo.: Juan Manuel Murillo Rodrguez Titular de Universidad rea de Lenguajes y Sistemas Informticos Universidad de Extremadura
MEN
SALIR
MEN
SALIR
Agradecimientos
Esta tesis doctoral es la culminacin de muchos aos de trabajo, que no hubiera podido llevar a cabo sin el apoyo y la ayuda de mi familia, mis amigos y mis compaeros. A todos ellos quiero agradecer el haber estado siempre ah, en los buenos y en lo malos momentos, que han sido muchos. No puedo, ni debo dejar de mencionar a mi director de tesis, Juan Manuel, y la confianza que deposit en m al empezar a trabajar juntos. Slo l sabe la dedicacin y el tiempo que ha supuesto dirigir mis pasos, dndome siempre libertad para aportar mis ideas a lo largo de estos aos. Una mencin especial tiene que ser para mi familia, mi marido y mis hijos, que, casi sin comprender lo que haca, han estado siempre cerca apoyndome, dndome nimos y como no, soportando mi estrs, mis viajes y mi dedicacin a la tesis, en lugar de a ellos. A mis padres, que vean con preocupacin que el trabajo me quitaba el tiempo que tena que dedicar a vivir. Gracias, ellos me han dado fuerzas para seguir luchando. Prometo compensar todas esas carencias que en ningn momento me han reprochado. Espero que no sea demasiado tarde. Quiero nombrar aqu a mis amigos y compaeros de fatigas, Miguel ngel, Marisol, Pedro, Pedro Lus y Myriam, que me han soportado estos largos aos de angustias y de algunos triunfos. A pesar de todo, me quedo con los buenos ratos que hemos pasado, sus consejos y sus nimos. Sin ellos, probablemente hubiera tirado la toalla hace tiempo. Quiero agradecer los comentarios y revisiones que han realizado sobre los borradores de esta tesis. Un recuerdo merecen los alumnos que a lo largo de estos aos han trabajado conmigo. De entre ellos, destacara, por ser los ltimos, a Maria, Ivn y Cristina, que me han facilitado el trabajo y, tras el tiempo que hemos compartido, creo que puedo decir que somos amigos. Esta tesis es fruto del tesn y del trabajo. Quiero dar gracias a Dios por darme fuerza para soportar todos los contratiempos y tantos aos de sinsabores. Por fin, hoy presento este trabajo, que debe ser el punto de partida para afrontar nuevos retos.
MEN
SALIR
MEN
SALIR
MEN
SALIR
MEN
SALIR
Resumen
La gestin de sistemas de software complejos es uno de los retos ms importantes de la Ingeniera del Software (IS). El ingeniero de software debe afrontar el desarrollo de sistemas software cada vez ms complejos y con requisitos ms estrictos. Adems, el mundo real cambia, evoluciona y los sistemas deben adaptarse a l para seguir siendo tiles. Por esta razn, la adaptacin debe realizarse de manera sencilla; los ingenieros de software deben encontrar tcnicas y herramientas que se lo permitan. Sin embargo, los mtodos tradicionales (mtodos estructurados o paradigmas orientados a objetos) slo permiten una reconfiguracin y adaptacin parcial de los sistemas. Se han considerado muchas soluciones a esta cuestin, siendo la separacin de aspectos una de ellas. La Programacin Orientada a Aspectos se propuso como una manera de aplicar la separacin de aspectos, tratando de superar las limitaciones de la Programacin Orientada a Objetos. Desde entonces, la Programacin Orientada a Aspectos y otras tcnicas centradas en la modularizacin del cdigo transversal se agruparon bajo el nombre de Separacin avanzada de intereses (concerns). La idea es extraer el cdigo relacionado con los crosscutting concerns (un concern captura los requisitos que atraviesan mltiples mdulos en un sistema), que est disperso a lo largo del cdigo del sistema, en mdulos independientes. Esta separacin evita el cdigo enmaraado y permite la reutilizacin de un aspecto. En muchos trabajos de investigacin, los aspectos se consideran como una parte importante del proceso de desarrollo de los sistemas complejos y proponen tcnicas para extraerlos de una manera efectiva. Muchos de estos mtodos Orientados a Aspectos se centran principalmente en la especificacin y extraccin de stos en el diseo detallado o en el nivel de implementacin, prestando menos atencin al impacto de los aspectos en las primeras fases del ciclo de vida. Desarrollo de Software Orientado a Aspectos (DSOA) es la denominacin utilizada para referirse a las tcnicas y tecnologas de modularizacin de los crosscutting concerns a lo largo del ciclo de vida. Por otra parte, los nuevos mtodos de la Ingeniera del Software consideran a la Arquitectura del Software (AS) como una parte importante de la etapa de diseo que ayuda a controlar la complejidad de los sistemas. En ella stos se definen como un conjunto de componentes que describen su funcionalidad a alto nivel y se conectan a travs de un conjunto de conectores arquitectnicos. Durante el diseo arquitectnico se lleva a cabo la definicin estructural del sistema. El inters de definir un diseo arquitectnico Orientado a Aspectos surge cuando se observa que los crosscutting concerns atraviesan tambin a los componentes arquitectnicos. Adems, considerar los aspectos en esta fase facilita la gestin de la evolucin al poder considerarlos artefactos software. Por ello, es necesario disponer de mecanismos que permitan identificar los aspectos durante la arquitectura del software.
MEN
SALIR
A su vez, el Desarrollo Software Basado en Componentes (DSBC) es otro paradigma de la ingeniera del software que pretende facilitar la construccin de grandes sistemas software de calidad, que evolucionen fcilmente, reduciendo el coste y el tiempo de los desarrollos. La filosofa de DSBC puede provocar un cambio en cuanto a la forma de afrontar los desarrollos, pasndose de considerar lneas de cdigo a la definicin de modelos. El uso combinado de los paradigmas y disciplinas mencionadas (DSOA, AS y DSBC) puede facilitar el desarrollo de sistemas software complejos, proporcionndose mtodos, procedimientos y herramientas. El trabajo que aqu se presenta considera conjuntamente el Desarrollo de Sistemas Orientado a Aspectos, la Arquitectura del Software y las caractersticas generales del Desarrollo de Sistemas Basado en Componentes. As, el objetivo de esta tesis es proporcionar un marco de trabajo para el desarrollo de sistemas software orientado a aspectos (AOSA Space), que est formado por un modelo arquitectnico: AOSA Model, una metodologa de trabajo, un lenguaje de descripcin arquitectnica (LDA) orientado a aspectos y una herramienta para su utilizacin. El modelo propone hacer una especificacin estructural de un sistema orientado a aspectos (OA) considerando los aspectos como entidades de primera clase, concretamente como componentes arquitectnicos. AOSA Model se basa en un LDA convencional y un modelo de coordinacin. Sin embargo, surge un problema al tratar de representar sistemas OA pues los LDA convencionales no soportan conceptos de OA. Adems se ha considerado fundamental que la insercin de los aspectos se realice observando el principio de inconsciencia. De este modo, los componentes que constituyen el sistema en el que se insertan los aspectos no cambian. Adems, para resolver el problema de la ejecucin coordinada de componentes y aspectos, en AOSA Model se ha considerado un modelo de coordinacin; concretamente Coordinated Roles que se basa en protocolos de notificacin de eventos. Por otra parte, hay varias propuestas para desarrollar sistemas OA a lo largo del ciclo de vida, pero slo algunas de ellas proporcionan un soporte lingstico. A lo largo de este trabajo se ha considerado interesante dotar a los sistemas OA de un soporte formal, igual que se hace en el desarrollo de sistemas convencionales. As, igual que los sistemas convencionales se representan en esta etapa mediante LDA, los sistemas OA deberan expresarse tambin mediante LDA adecuados. En este trabajo se muestra cmo es posible dotar al proceso de desarrollo de un sistema OA de un soporte lingstico durante la fase de diseo arquitectnico. En otro orden de cosas, los sistemas software tienen que adaptarse al mundo cambiante en el que se definen. Por ello, cuando se trabaja desde el punto de vista de la evolucin de los sistemas, es especialmente interesante considerar que los componentes que forman el sistema a actualizar no cambien al incluir nuevos requisitos. En estos casos, tales modificaciones pueden considerarse como aspectos, por lo que se podran aplicar los principios de DSOA. Por ello, cuando la evolucin se trata desde la fase de diseo arquitectnico se puede aplicar AOSA Space, pues tambin facilita la evolucin de los sistemas complejos, su representacin formal y el chequeo de la arquitectura obtenida.
MEN
SALIR
Una de las aportaciones de AOSA Space, el marco de trabajo que se propone, es la manera en la que se integran las aproximaciones en las que se basa, para aprovechar las ventajas que aporta cada una: La separacin de aspectos se considera desde las primeras fases del desarrollo, aplicando los principios de DSOA. Mejora el mantenimiento y la evolucin de los sistemas complejos, al tratar los cambios de sistemas existentes desde un punto de vista arquitectnico, considerndolos como aspectos, en aquellos casos en los que sea posible. Se aplican aqu conceptos de DSOA y de arquitectura del software. La definicin de los aspectos como componentes arquitectnicos, que permanecen separados (no se tejen) a lo largo del desarrollo, facilita la reutilizacin y su sustitucin. Se utilizan los tres paradigmas mencionados (DSOA, AS y DSBC). Tanto en tiempo de diseo como en tiempo de evolucin se mantiene el principio de inconsciencia por lo que los componentes que forman el sistema en el que se insertan los aspectos no se modifican. En este caso, se integran conceptos de DSOA y DSBC. La utilizacin de un LDA-OA en la representacin de los sistemas facilita la descripcin formal de los mismos, permite ejecutar un prototipo del mismo y chequear la arquitectura, para determinar si el comportamiento del sistema es el esperado, utilizndose conjuntamente las caractersticas del DSOA y de la AS. Un juego de herramientas facilita la labor del arquitecto de software a lo largo del proceso de desarrollo de un sistema orientado a aspectos. Sin embargo, podemos decir que la principal aportacin de esta tesis doctoral es tratar el problema de la separacin de aspectos como uno de coordinacin.
MEN
SALIR
MEN
SALIR
ndice general
1. Introduccin.....................................................................................1
1.1. Contexto de la tesis ...........................................................................................2 1.2. mbito del estudio............................................................................................2 1.3. Antecedentes.....................................................................................................3 1.4. Motivacin ........................................................................................................5
1.4.1. Definicin de modelos arquitectnicos OA ...................................................... 5 1.4.2. Definicin de un LDA-OA................................................................................ 6
MEN
SALIR
ndices
2.4.2. Reflexin......................................................................................................... 64
2.5. Desarrollo software basado en componentes..................................................72 2.6. Desarrollo software dirigido por modelos ......................................................73 2.7. Norma IEEE 1471...........................................................................................75
2.7.1. Definiciones .................................................................................................... 76 2.7.2. Marco conceptual ............................................................................................ 76 2.7.3. Arquitectura y evolucin................................................................................. 78 2.7.4. Usos de las descripciones arquitectnicas....................................................... 79
3.2. DSOA y evolucin..........................................................................................89 3.3. Modelado de aspectos a lo largo del ciclo de vida .........................................92
3.3.1. Ingeniera de requisitos orientada a aspectos .................................................. 92 3.3.2. Arquitectura software Orientada a Aspectos................................................... 96 3.3.3. Diseo Orientado a Aspectos ........................................................................ 100 3.3.4. Programacin Orientada a Aspectos ............................................................. 102 3.3.5. Aproximaciones al modelado OA ................................................................. 102 3.3.6. Conclusiones sobre el modelado de aspectos................................................ 117
4.2. Separacin de aspectos a nivel arquitectnico: problema de coordinacin..157 4.3. Estructura meta nivel ....................................................................................161
4.3.1. Descripcin detallada del meta nivel ............................................................ 164 4.3.2. Diagramas de actividad para los elementos del meta nivel ........................... 180
ii
MEN
SALIR
ndices
4.4.4. Caso 4............................................................................................................ 188 4.4.5. Caso general .................................................................................................. 190
5.5. Especificacin arquitectnica del sistema extendido ....................................227 5.6. Generacin del prototipo ..............................................................................227 5.7. Validacin de la arquitectura ........................................................................228 5.8. Metamodelo para AOSA Model ....................................................................229
5.8.1. Metaclase Aspecto ......................................................................................... 230 5.8.2. Metaclase Coordinador................................................................................. 231 5.8.3. Metaclase MetaCoordinador ........................................................................ 231 5.8.4. Metaclase BlackBoard .................................................................................. 232 5.8.5. Metaclase NuevaConexion ............................................................................ 232 5.8.6. Sistema base .................................................................................................. 233
iii
MEN
SALIR
ndices
6.7.2. Pestaa Aspecto ............................................................................................. 260 6.7.3. Pestaa Coordinador..................................................................................... 261 6.7.4. Pestaa AspectLEDA ..................................................................................... 261 6.7.5. Pestaa Sistema Extendido ............................................................................ 263 6.7.6. Pestaa Editor de texto .................................................................................. 264 6.7.7. Obtencin de un prototipo............................................................................. 265 6.7.8. Caso de estudio. CASO GENERAL ............................................................. 265
6.8. Similitudes y diferencias con otros LDA-OA...............................................270 6.9. Conclusiones.................................................................................................273 6.10. Apndice A: gramtica AspectLEDA ..........................................................274 6.11. Apndice B: mensajes de error ...................................................................275
B1.- Mensajes de error del intrprete de AspectLEDA............................................ 275 B2.- Mensajes de error del intrprete LEDA .......................................................... 276
A1.4. Refinamiento de Arquitecturas ..................................................................317 A1.5. Adaptadores ...............................................................................................317 A1.6. Implementacin LEDA...............................................................................318 A1.7. Conclusiones ..............................................................................................319
Anexo 2. EVADeS............................................................................321
A2.1. Justificacin ...............................................................................................321 A2.2. Generador de Cdigo LEDA ......................................................................322
A2.2.1. Antecedentes .............................................................................................. 322 A2.2.2. Requisitos y objetivos de EVADeS............................................................. 324
iv
MEN
SALIR
A2.6. Control de errores ......................................................................................336 A2.7. Actuaciones sobre la gramtica LEDA ......................................................337
A2.7.1. Cambios triviales........................................................................................ 337 A2.7.2. Otras modificaciones.................................................................................. 337
MEN
SALIR
MEN
SALIR
ndice de figuras
Figura 2.1. Resumen de la evolucin de la Arquitectura del Software. Hitos relevantes.18 Figura 2.2. Relacin entre los diferentes lenguajes basados en XML. ............................. 45 Figura 2.3. Modelo de reflexin de 2 niveles................................................................... 66 Figura 2.4. Marco conceptual definido por la Norma IEEE. ........................................... 77 Figura 3.1. Transformacin concernsmdulos, identificacin de aspectos tempranos. 86 Figura 3.2. Arquitectura AO-Rapide.............................................................................. 111 Figura 4.1. Estructura arquitectnica de AOSA Model. Representacin esquemtica. .. 161 Figura 4.2. Representacin detallada del nivel de aspecto............................................. 162 Figura 4.3. Elementos del nivel de aspecto.................................................................... 164 Figura 4.4a). Relacin Cliente-Servidor. Sistema Inicial. ............................................. 170 Figura 4.4b). Relacin Cliente-Servidor. Sistema Extendido. Inclusin de un aspecto. 170 Figura 4.5. Representacin en pseudocdigo de un componente cliente....................... 170 Figura 4.6. Representacin en pseudocdigo para un componente servidor. ................ 171 Figura 4.7. Comportamiento del coordinador, no se aplica el aspecto.......................... 172 Figura 4.8. Actividad de coordinador si when = before. ............................................... 173 Figura 4.9. Actividad de coordinador si when = after. .................................................. 174 Figura 4.10. Actividad de coordinador si when = around. ............................................ 174 Figura 4.11. Mensaje asncrono, si no hay matching..................................................... 175 Figura 4.12. Mensaje asncrono, si hay matching.......................................................... 176 Figura 4.13. Pseudocdigo del componente coordinador. ............................................ 177 Figura 4.14. Descripcin de MetaCoordinador. ........................................................... 178 Figura 4.15. Descripcin en pseudocodigo de MetaCoordinador. ................................ 179 Figura 4.16. Diagramas de actividad. Recibir mensaje sncrono. .................................. 181 Figura 4.17. Diagramas de actividad. Recibir mensaje asncrono. ................................ 182 Figura 4.18. Representacin esquemtica de caso 1. ..................................................... 184 Figura 4.19. Representacin esquemtica del caso 2. Dos aspectos. ............................. 185 Figura 4.20. Representacin esquemtica del caso 2*. Dos aspectos. ........................... 186 Figura 4.21. Representacin esquemtica de caso 3. Dos aspectos. .............................. 187 Figura 4.22. Representacin esquemtica de caso 4. Dos aspectos. .............................. 188 Figura 4.23. Pseudocdigo del coordinador cuando se aplican dos aspectos................ 193 Figura 5.1. Representacin esquemtica del modelo. .................................................... 196 Figura 5.2. Etapas de la metodologa............................................................................. 197 Figura 5.3. Caso de estudio. D. de casos de uso para el sistema inicial. ....................... 199 Figura 5.4a). Diagramas de secuencia, CU Reserva de habitacin................................ 200 Figura 5.4b). Diagramas de secuencia. CU Gestin del restaurante.............................. 201
vii
MEN
SALIR
ndices
Figura 5.5. Sistema inicial en LEDA. ............................................................................ 203 Figura 5.6. Extensin del diagrama de casos de uso con aspectos................................. 205 Figura 5.7. D. de secuencia para Counter, siguiendo una aproximacin No-OA. ......... 208 Figura 5.8. D. Sec. para Counter, CU ResRoomHander siguiendo AOSA Model. ........ 209 Figura 5.9. D. de secuencia para el aspecto WaitingList siguiendo AOSA Model. ........ 211 Figura 5.10. Diagrama de secuencia para el aspecto FindRoom.................................... 212 Figura 5.11. D. de secuencia para Counter en el C.U. RestaurantHandler. .................. 214 Figura 5.12a). D. de secuencia de aspecto Counter, CU ReserveRoom. ....................... 217 Figura 5.12b). D. de secuencia de aspecto WaitingList, CU ReserveRoom. .................. 217 Figura 5.13. D. Sec. para Counter y FindRoom, CU RoomHandler. Aprox. No-OA.... 220 Figura 5.14. D. Sec. para Counter y FindRoom, CU RoomHandler. AOSA Model....... 220 Figura 5.15. Despliegue final del sistema extendido para el caso de estudio. ............... 222 Figura 5.16. Relacin entre modelo y metamodelo. ...................................................... 229 Figura 5.17. Metamodelo que define AOSA Model. ...................................................... 230 Figura 5.18. Metaclase Aspecto. .................................................................................... 230 Figura 5.19. Metaclases Coordinador, SuperCoordinador y BlackBoard...................... 232 Figura 5.20. Metaclase NuevaConexion. ....................................................................... 233 Figura 5.21. Metaclase Componente.............................................................................. 233 Figura 5.22. Metaclase conexin y conexiones en el modelo. ....................................... 234 Figura 6.1. Expresiones regulares para AspectLEDA..................................................... 242 Figura 6.2. Tabla de palabras reservadas para AspectLEDA.......................................... 242 Figura 6.3. Seccin de composicin. ............................................................................. 244 Figura 6.4. Seccin de enlaces. ...................................................................................... 244 Figura 6.5. Estructura de una descripcin en AspectLEDA. .......................................... 246 Figura 6.6. Ejemplo de un programa en AspectLEDA. .................................................. 248 Figura 6.7. Esquema de proceso de traduccin de AspectLEDA a Java......................... 249 Figura 6.8. Ficheros de entrada y salida para la comunicacin de los analizadores. ..... 250 Figura 6.9. Descripcin arquitectnica de aspecto en LEDA......................................... 255 Figura 6.10. Descripcin arquitectnica de coordinador regular en LEDA.................. 256 Figura 6.11. Desc. arquitectnica de coordinador complejo (dos aspectos) en LEDA.. 256 Figura 6.12. Secciones de la ventana principal de AOSA Tool/LEDA. .......................... 258 Figura 6.13a. Elementos de datos de la pestaa Sistema Bsico. .................................. 259 Figura 6.13b. Ventana de edicin de la pestaa Sistema Bsico o Sistema Inicial........ 260 Figura 6.14. Elementos de inters de la pestaa Aspecto............................................... 261 Fgura 6.15. Elementos de la pestaa Coordinador. ....................................................... 262 Figura 6.16. Pestaa AspectLEDA. Insercin de un aspecto.......................................... 262 Figura 6.17. Pestaa Sistema extendido. Insercin de un aspecto. ................................ 263 Figura 6.18. Sistema extendido generado en LEDA. Inclusin de un aspecto. .............. 264 Figura 6.19. Arquitectura del ejemplo en calculo . Inclusin de un aspecto. .............. 265 Figura 6.20. Sistema extendido generado en LEDA. Inclusin de varios aspectos. ....... 268 Figura 6.21. Arquitectura del ejemplo en clculo . Inclusin de varios aspectos. ....... 270 Figura 7.1. Marco de trabajo propuesto. ........................................................................ 285 Figura A1.1. Especificacin de componente en LEDA.................................................. 311 Figura A1.2. Especificacin de rol en LEDA. Forma annima...................................... 312 Figura A1.3. Especificacin de rol en LEDA. Con identificador de clase. .................... 313 Figura A1.4. Especificacin de rol en LEDA. Definicin de manera implcita. ............ 313
viii
MEN
SALIR
Figura A1.5. Definicin independiente de rol en LEDA................................................ 313 Figura A1.6a). Definicin de conexiones reconfigurables en LEDA. Con if................. 314 Figura A1.6b). Definicin de conexiones reconfigurables en LEDA. Con Case. .......... 315 Figura A1.7. Extensin de roles en LEDA. .................................................................... 316 Figura A1.8. Definicin de componente derivado en LEDA. ........................................ 317 Figura A1.9. Refinamiento de arquitecturas en LEDA. ................................................. 317 Figura A2.1. Jerarqua de mens. .................................................................................. 328 Figura A2.2. Pantalla principal de la aplicacin. ........................................................... 329 Figura A2.3. Ventana de informacin de prototipo. ...................................................... 330 Figura A2.4. Ventana del Generador de cdigo. Vista Analizador lxico..................... 332 Figura A2.5. Ventana Analizador sintctico del Generador de cdigo.......................... 333 Figura A2.6. Ventana del Prototipo. .............................................................................. 334 Figura A2.7. Listado de Archivos del prototipo y Clases Bsicas................................. 336
ix
MEN
SALIR
MEN
SALIR
Indice de Tablas
Tabla 2.1. LDA considerados en este captulo................................................................. 30 Tabla 2.2. Caractersticas generales de los LDA estudiados............................................ 53 Tabla 2.3. Representacin de conceptos arquitectnicos en los LDA estudiados........... 55 Tabla 3.1. Tabla comparativa de los modelos de desarrollo OA.................................... 121 Tabla 3.2a). Conceptos reflexivos y aspectuales en PiLAR. ......................................... 143 Tabla 3.2b). Elementos sintcticos en PiLAR extendido............................................... 143 Tabla 3.3. LDA OA estudiados y AspectLEDA. .......................................................... 147 Tabla 3.4. Caractersticas generales de los LDA OA estudiados y propuesto. ............. 147 Tabla 3.5 Representacin de conceptos arquitectnicos en los LDA-OA estudiados y el propuesto................................................................................................................. 149 Tabla 3.6. Resumen de conceptos en los LDA-OA estudiados...................................... 151 Tabla 4.1. Elementos de cada fila de la estructura Common Items. ............................... 166 Tabla 4.2. Elementos caractersticos de los casos descritos........................................... 183 Tabla 4.3. Comportamiento de coordinador complejo. Ejemplo caso 4, dos aspectos.. 189 Tabla 5.1. Descripcin de los casos de uso. ................................................................... 199 Tabla 5.2. Componentes de diseo en los diagramas de secuencia................................ 201 Tabla 5.3a). Interfaz de los componentes del d. de secuencia Reserva de habitacin... 201 Tabla 5.3b). Interfaz de los componentes del d. de secuencia Gestin del restaurante. 202 Tabla 5.4a). Ampliacin de la descripcin de los casos de uso. .................................... 206 Tabla 5.4b). Descripcin de los use case extension asociados a los nuevos requisitos. 206 Tabla 5.5. Tabla de Common Items para el aspecto Counter. ........................................ 210 Tabla 5.6. Tabla de Common Items para el aspecto WaitingList.................................... 211 Tabla 5.7. Tabla de Common Items para el aspecto FindRoom. .................................... 213 Tabla 5.8. Tabla de Common Items para aspecto Counter aplicado a dos casos de uso.214 Tabla 5.9. Tabla de Common Items para los aspectos Counter y WaitingList. .............. 216 Tabla 5.10. Tabla de Common Items para los aspectos Counter y FindRoom............... 221 Tabla 5.11. Tabla de Common Items para los tres aspectos en los distintos IP.............. 225 Tabla 6.1. Smbolos terminales de AspectLEDA............................................................ 242 Tabla 6.2. Smbolos no terminales de AspectLEDA....................................................... 243
xi
MEN
SALIR
MEN
SALIR
CAPTULO 1 Introduccin
El objeto de esta tesis titulada Marco de trabajo para el desarrollo de arquitecturas software orientado a aspectos es: presentar un modelo de desarrollo de sistemas orientado a aspectos, desde un punto de vista arquitectnico. Para la aplicacin del modelo se dispondr de una metodologa, un Lenguaje de Descripcin Arquitectnica Orientado a Aspectos y una herramienta que ayude al ingeniero de software a desarrollar sistemas software complejos. Dado que los sistemas software tienen que mantenerse actualizados para adaptarse a los cambios del entorno en el que han sido definidos, se pretende as mismo que la propuesta permita que el desarrollador pueda disear sistemas fcilmente adaptables y de evolucin sencilla. Para ello, los cambios se promovern desde un punto de vista estructural. En este captulo se presenta el mbito en el que se inscribe este trabajo y se detallan los objetivos marcados. La estructura de este captulo es la siguiente: la seccin 1 enuncia el mbito en el que se realiza el trabajo; la seccin 2 resume los antecedentes que han motivado la realizacin del mismo y centra el universo del discurso; la seccin 3 presenta la justificacin de la estructura de esta memoria y el modo en el que se ha abordado el trabajo: por una parte la tarea de definir un modelo arquitectnico para sistemas orientados a aspectos; por otra, la definicin de un lenguaje de descripcin de arquitecturas orientado a aspectos; la seccin 4 explica los principales objetivos de esta tesis doctoral. Finalmente, en la seccin 5 se resume la estructura de los captulos que la componen.
1. Introduccin
MEN
SALIR
Captulo 1
MEN
SALIR
Introduccin
La metodologa abarca varias fases del ciclo de vida, que se ejecutan de modo iterativo, sirviendo de gua al arquitecto a travs de los pasos que se deben dar para desarrollar los sistemas siguiendo AOSA Model. A partir de la descripcin arquitectnica de un sistema, se facilita la inclusin de nuevos requisitos en forma de aspectos que se insertan en la arquitectura teniendo en cuenta las especificaciones del modelo. Los nuevos requisitos, para poder considerarlos como aspectos, deben ser ortogonales. El sistema obtenido se puede validar utilizando herramientas adecuadas, se puede generar un prototipo ejecutable de la nueva arquitectura. Adems, la metodologa est soportada por herramientas que automatizan el proceso. Un Lenguaje de Descripcin Arquitectnica Orientado a Aspectos: AspectLEDA, que se ha definido para formalizar y analizar las arquitecturas modeladas: AspectLEDA se describe en el capitulo 6; se ha diseado a partir de LEDA, un LDA basado en clculo que permite definir un prototipo de la arquitectura y generar cdigo Java. Una herramienta: AOSA Tool/LEDA, que asiste al arquitecto y facilita la obtencin de la arquitectura orientada a aspectos objetivo, as como la ejecucin de un prototipo generado automticamente tras el proceso. Una interfaz de usuario amigable ayuda al arquitecto del software a introducir la informacin necesaria para generar el sistema extendido en AspectLEDA.
1.3. Antecedentes
La gestin de sistemas complejos es uno de los retos que debe afrontar la Ingeniera del Software actual. Adems, el mundo real cambia y los sistemas deben adaptarse a l para seguir siendo tiles. Por esta razn, los ingenieros de software deben encontrar tcnicas y herramientas que le permitan adaptar los sistemas de manera sencilla. Sin embargo, los mtodos tradicionales (mtodos estructurados o paradigmas orientados a objetos) slo permiten una reconfiguracin y adaptacin parcial de los mismos. La Programacin Orientada a Objetos (POO) es un paradigma de programacin que realiza una descomposicin funcional [Par72] pero tiene la limitacin de que algunos temas de inters del problema no pueden localizarse en un nico mdulo sino que atraviesan varios elementos estructurales del sistema. La separacin de intereses (separation of concerns), introducida en [Par72], es un principio de la ingeniera del software que trata de resolver el problema de modo que los diferentes concerns (temas de inters, asuntos) de un sistema se consideren individualmente. Dijkstra en [Dij76] demostr que esta divisin proporciona mejores resultados y tiene mayores ventajas, incluyendo la reduccin de la complejidad del software y mejorando la modularidad, la reutilizacin y el mantenimiento de los artefactos software. En 1996, Kiczales [Kic+96] propuso la Programacin Orientada a Aspectos POA- (Aspect Oriented Programming AOP-) como una manera de aplicar la separacin de aspectos para resolver las limitaciones de la POO. Esta propuesta difiere de las anteriores en que la POA introduce una nueva definicin de concern: aquellos intereses que pertenecen al desarrollo del
MEN
SALIR
Captulo 1
sistema, su operacin o cualquier otro aspecto que sea importante para un usuario o desarrollador. Desde entonces, la POA y otras tcnicas, centradas en la modularizacin del cdigo transversal, se agruparon bajo el nombre de Separacin Avanzada de Intereses (o en su denominacin inglesa Advanced Separation of Concerns). La idea es extraer el cdigo relativo a los crosscutting concerns (concerns intereses o propiedades- que capturan requisitos y cruzan varios mdulos del sistema [AOSD]) que est disperso a lo largo del mismo, en mdulos independientes. Esta separacin evita el cdigo enmaraado (tangled) y permite la reutilizacin de los aspectos. En diversos trabajos de investigacin, los aspectos se consideran como una parte importante del proceso de desarrollo de los sistemas complejos y proponen tcnicas para extraerlos de una manera efectiva (como Composition Filters [BeAk01], AspectJ [Kic+01], Adaptive Programming [LiOrOv01], HyperJ [OsTa00], etc.). Muchas de estas aproximaciones orientadas a aspectos (OA) se centran en la especificacin y extraccin de aspectos durante el diseo detallado o en el nivel de implementacin, prestando menos atencin al impacto de los aspectos en las primeras fases del ciclo de vida. En 2002 se populariz el nombre de Desarrollo de Software Orientado a Aspecto (DSOA) para referirse a las tcnicas y tecnologas de modularizacin de los crosscutting concerns a lo largo del ciclo de vida. Por otra parte, los nuevos mtodos de la ingeniera del software consideran a la arquitectura del software como una parte importante de la etapa de diseo: la arquitectura del software es una actividad que ayuda a los desarrolladores a controlar la complejidad de los sistemas y a definir sus estructuras de modo que su mantenimiento y evolucin sean sencillos. Esto es as porque durante esta etapa, se define la estructura de un sistema como un conjunto de componentes que describen la funcionalidad del sistema a alto nivel y se conectan a travs de un conjunto de conectores arquitectnicos. Durante la arquitectura del software se lleva a cabo la definicin estructural del sistema; la conveniencia de definir un diseo arquitectnico orientado a aspectos surge cuando se observa que los crosscutting concerns atraviesan tambin los componentes arquitectnicos de modo que el diseo final es complejo. Adems, considerar los aspectos en esta fase facilita la gestin de la evolucin del sistema. Esto es as porque durante el diseo arquitectnico los aspectos se pueden considerar como artefactos software. En este sentido, diversas propuestas consideran los aspectos arquitectnicos como artefactos de distinto tipo: componentes, conectores, slices, vistas Una consideracin a tener en cuenta en el desarrollo de las arquitecturas del software OA es cmo expresarlas. Segn se documenta en el captulo 3 de esta memoria, hay varias propuestas para desarrollar sistemas OA a lo largo del ciclo de vida y en particular durante la fase del diseo arquitectnico, pero slo algunas de ellas proporcionan un soporte lingstico. Es necesario dotar a los sistemas OA de un soporte formal, igual que se hace en las propuestas de desarrollo de sistemas convencionales, particularmente durante su definicin estructural. Por tanto, igual que los sistemas ordinarios se describen en esta etapa mediante lenguajes de descripcin arquitectnica (LDA), los sistemas OA deberan expresarse tambin mediante LDA adecuados. Sin embargo, los LDA convencionales no permiten al diseador representar adecuadamente los sistemas orientados a aspectos. De ah la necesidad de definir Lenguajes de
MEN
SALIR
Introduccin
Descripcin Arquitectnica Orientados a Aspectos (LDA-OA). En esta memoria se muestra cmo es posible dotar al proceso de desarrollo de un sistema OA de un soporte lingstico durante la fase de diseo.
1.4. Motivacin
Concretando la exposicin realizada hasta el momento, en esta seccin se establecen las motivaciones principales que han llevado a la realizacin de esta tesis doctoral. El tratamiento de los intereses transversales (crosscutting concerns) a nivel arquitectnico y el modelado de aspectos son dos tcnicas que, en los ltimos aos, han captado el inters de la comunidad investigadora. Prueba de ello es la gran cantidad de publicaciones y conferencias internacionales especficas sobre el tratamiento de aspectos en fases tempranas del desarrollo. Dos de los puntos de inters en este mbito son el desarrollo de modelos que faciliten la construccin de Sistemas Orientados a Aspectos y la definicin de Lenguajes de Descripcin Arquitectnica Orientados a Aspectos.
En [Fil+05] un aspecto se define como una unidad modular diseada para implementar un concern.
MEN
SALIR
Captulo 1
La AS considera la estructura de los sistemas cuando sta se est definiendo y estudia su modularizacin, su composicin y sus consecuencias. Este concepto es prximo al de separacin de aspectos (separation of concerns) que establece que cada concern debera mantenerse en un mdulo independiente. Despus de que los mdulos se hayan definido, surge un conjunto de estructuras que los combinan para estudiarlos todos juntos. Por tanto, es til considerar la AS (como tcnica para la modularizacin y separacin de propiedades) de un sistema para reducir su complejidad. El DSOA facilita que el diseo de los sistemas sea claro y hace su evolucin ms sencilla: las propiedades transversales se implementan en unidades modulares, lo que mejora la posibilidad de reutilizacin y la adaptabilidad de los sistemas.
El concepto de aspecto, a nivel de arquitectura, introduce un nuevo tipo de modularizacin y composicin del software que define nuevas estructuras que deben ser estudiadas por la AS, as como determina las caractersticas arquitectnicas de los aspectos. Recientemente, se han presentado varios estudios cuyos resultados muestran los beneficios de la aproximacin arquitectnica en el marco de la orientacin a aspectos [AOSD, Early]. Para ello, es necesario definir mecanismos que permitan identificar y especificarlos durante esta fase, as como gestionar su interaccin con otros elementos arquitectnicos. Como consecuencia, el uso conjunto de ambos conceptos potencia las caractersticas de ambos. AOSA Model considera los aspectos arquitectnicos como componentes arquitectnicos, siguiendo una aproximacin asimtrica, en la que estos componentes permanecen independientes del contexto cuando se insertan en un sistema ya existente o durante el diseo de uno nuevo. El modelo propone realizar una especificacin estructural de un sistema considerando los aspectos como entidades de primera clase, se basa en el uso de un lenguaje de descripcin arquitectnica para expresar formalmente el diseo arquitectnico y en un modelo de coordinacin. La aplicacin de AOSA Model permitir incluir aspectos en un sistema sin que resulten modificados los componentes del sistema en los que se realiza la insercin.
MEN
SALIR
Introduccin
necesario para razonar sobre las propiedades de las arquitecturas OA en trminos de componentes, conexiones, aspectos y sus vnculos con el sistema. Como los aspectos se pueden incorporar a un sistema ya existente modificando as su comportamiento, y como esto se puede hacer de un modo transparente a los componentes que definen su arquitectura, el segundo punto adquiere especial relevancia en los objetivos de esta tesis. De hecho, cuando un aspecto se incorpora a una arquitectura existente, se produce un cambio en el comportamiento de los componentes afectados por la insercin. En el Captulo 6 de esta memoria se describe el LDA-OA, definido para expresar formalmente arquitecturas software de sistemas OA, obtenidas tras la aplicacin del modelo que se propone.
1.5. Objetivos
El objetivo principal de esta tesis es proporcionar un marco de trabajo para desarrollar sistemas complejos. ste debe integrar la definicin y especificacin de un sistema software y facilitar su proceso de desarrollo, su mantenimiento y evolucin. Para ello, el trabajo se basar en la utilizacin de tcnicas y aproximaciones que permitan obtener los resultados esperados: utilizando el paradigma de DSOA, considerando el DSBC y las tcnicas que proporciona la arquitectura del software como disciplina, en particular el uso de lenguajes de descripcin arquitectnica. Este objetivo principal puede dividirse en varios objetivos especficos: Estudio de los trabajos relacionados en el entorno del DSOA, prestando especial atencin a los realizados durante el diseo arquitectnico. Revisin de los principales LDA tanto convencionales como orientados a aspectos, estudio de sus caractersticas, ventajas e inconvenientes. Definicin de un modelo que integre DSOA y DSBC durante el diseo arquitectnico de los sistemas software. El modelo obtenido debe permitir la insercin de aspectos durante el diseo y la ejecucin de un prototipo de la arquitectura generada, partiendo de la especificacin de los requisitos de un cierto sistema. Adems, la insercin de los aspectos debe ser transparente al sistema en el que se incluyen, potencindose as la reutilizacin de componentes y aspectos. Definicin de un LDA orientado a aspectos que dote de soporte formal a las arquitecturas obtenidas tras la aplicacin del modelo propuesto. Este LDAOA debe disponer de suficiente expresividad para lograr una especificacin completa del sistema. Adems, se deben poder aplicar herramientas que permitan asegurar la correccin de la arquitectura.
MEN
SALIR
Captulo 1
Definicin de un metamodelo que especifique las caractersticas del modelo propuesto. Proposicin de una metodologa que sirva de gua al arquitecto del software a lo largo del proceso de desarrollo de los sistemas OA. Definicin de una herramienta que ayude al arquitecto a realizar las tareas que define la metodologa. El marco de trabajo desarrollado debe ser independiente de la tecnologa (entendiendo por tecnologa la relacin hardware sistema operativo) donde se ejecute.
MEN
SALIR
Introduccin