Lidia Fuentes Component&Aspect-Oriented Software Development Group http://caosd.lcc.uma.es Departamento de Lenguajes y Ciencias de la Computación Universidad de Málaga. España [email protected]Tecnologías para el desarrollo de aplicaciones distribuidas 2 Lidia Fuentes Fernández Índice Desarrollo de software basado en componentes Modelos y plataformas de componentes Mercado global de componentes (componentes COTS) Desarrollo de software orientado a aspectos Motivación del desarrollo orientado a aspectos El lenguaje AspectJ Conferencia del 3 de mayo Otras propuestas de aspectos Separación de aspectos en las plataformas de componentes Ingeniería del Software Orientada a Agentes Concepto de Agente La Arquitectura de Referencia FIPA Componentes y aspectos al servicios de los agentes Desarrollo de Software Basado en Componentes 4 Lidia Fuentes Fernández Antecedentes Programación de Sistemas Abiertos y Distribuidos Deficiencias de la Programación Orientada a Objetos (POO): Dificultad a la hora de reutilizar objetos Acoplamiento entre tipos e implementación (mejorado con la definición de interfaces) Extensión caja blanca ClaseA obja=new ClaseA(); obja.m1(10); A +m1( i : int ) B 5 Lidia Fuentes Fernández Antecedentes Programación de Sistemas Abiertos y Distribuidos Deficiencias de la Programación Orientada a Objetos (POO): Noción de composición no explícita (extensión caja negra) Implementación A1 B1 b=new B1(); Int i=b.m1(); Implementación B1 m1(); Composición en OO Implementación B1 Implementación A1 Composición caja negra 6 Lidia Fuentes Fernández Antecedentes Programación de Sistemas Abiertos y Distribuidos Deficiencias de la Programación Orientada a Objetos (POO): Paso de mensajes síncrono No incorpora aspectos de mercadotecnia Desarrollo de aplicaciones distribuidas mediante mecanismos rudimentarios (sockets, RPC)
16
Embed
Índice Tecnologías para el desarrollo de aplicaciones …canal/sabc/curso0506/CBSD_AOSD.pdf · 2013-11-05 · “Extensión” de la POO Basada en la noción de COMPONENTE ... en
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
Lidia Fuentes
Component&Aspect-OrientedSoftware Development Group
http://caosd.lcc.uma.es
Departamento de Lenguajes y Ciencias de la ComputaciónUniversidad de Málaga. España
Tecnologías para el desarrollo de aplicaciones distribuidas
2
Lidia Fuentes Fernández
ÍndiceDesarrollo de software basado en componentes
Modelos y plataformas de componentesMercado global de componentes (componentes COTS)
Desarrollo de software orientado a aspectosMotivación del desarrollo orientado a aspectosEl lenguaje AspectJ
Conferencia del 3 de mayoOtras propuestas de aspectosSeparación de aspectos en las plataformas de componentes
Ingeniería del Software Orientada a AgentesConcepto de AgenteLa Arquitectura de Referencia FIPAComponentes y aspectos al servicios de los agentes
Desarrollo de Software Basado en Componentes
4
Lidia Fuentes Fernández
AntecedentesProgramación de Sistemas Abiertos y Distribuidos
Deficiencias de la Programación Orientada a Objetos (POO):Dificultad a la hora de reutilizar objetos
Acoplamiento entre tipos e implementación (mejorado con la definición de interfaces)Extensión caja blanca
ClaseA obja=new ClaseA();obja.m1(10);
A
+m1( i : int )
B
5
Lidia Fuentes Fernández
AntecedentesProgramación de Sistemas Abiertos y Distribuidos
Deficiencias de la Programación Orientada a Objetos (POO):
Noción de composición no explícita (extensión caja negra)Implementación
A1
B1 b=new B1();Int i=b.m1();
Implementación B1
m1();
Composición en OO
Implementación B1
Implementación A1
Composición caja negra
6
Lidia Fuentes Fernández
AntecedentesProgramación de Sistemas Abiertos y Distribuidos
Deficiencias de la Programación Orientada a Objetos (POO):
Paso de mensajes síncronoNo incorpora aspectos de mercadotecniaDesarrollo de aplicaciones distribuidas mediante mecanismos rudimentarios (sockets, RPC)
2
7
Lidia Fuentes Fernández
AntecedentesProgramación de Sistemas Abiertos y Distribuidos
Plataformas Distribuidas Orientadas a Objetos:Bus de datos para la comunicación entre objetosTransparencia de la heterogeneidad, dispersión y activación de objetosLenguaje de Descripción de Interfaces (IDL), utilizando mecanismos de extensión OO (ej: herencia)Repositorios de interfacesComunicación síncrona basada en RPCServicios (seguridad, transacciones, ...)Ej: CORBA (1.1, 2.0), JavaBeans y COM
8
Lidia Fuentes Fernández
Estructura básica de un ORB
Adaptador de Objetos
Object Request Broker
DII IDL Stub IDLSkelDSI
Interfaz ORB
ClienteImplementación
Servidor
DII: Dynamic Invocation Interface DSI: Dynamic Skeleton Interface–Un stub permite que un cliente invoque una operación remota como si fuese local. –Un skeleton permite que una invocación remota recibida por un servidor
sea enviada al sirviente adecuado
9
Lidia Fuentes Fernández
AntecedentesProgramación de Sistemas Abiertos y Distribuidos
Desarrollo de Software Basado en Componentes (Component-BasedSoftware Development, CBSD)
“Extensión” de la POO Basada en la noción de COMPONENTEIncluye nociones de mercadotecnia (componentes COTS, o Commerciaoff-the shelf)
Unidad de composición de aplicaciones software que posee un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes, de forma independiente en tiempo y espacio.
Szyperski, 199810
Lidia Fuentes Fernández
Desarrollo de una Aplicación Basada en Componentes
Descomposición funcional en una colección de componentesArquitectura de la aplicación (AA)
Colección de componentesPropios -> Desarrollo top-downComponentes COTS (adquiridos en el mercado de componentes) -> Desarrollo bottom-up
Información de composición de componentes (coordinación)Dentro de los propios componentesIncluye el uso de adaptadores cuando los componentes no son compatibles
Ejecución en una plataforma de componentes
11
Lidia Fuentes Fernández
Especificación de la Arquitectura de la aplicación (AA)
LDAs (ADLs, Architecture Description Languages)Basados en formalismosNo generan código válido, entonces se pierde la información
En las plataformas de componentesInterfaz del componente
Siempre aparece la interfaz proporcionadaTendencia a incorporar la interfaz requerida, eventos, excepciones, protocolos, ...
Descripción de componentesInformación de despliegue (deployment) en XML en contenedores, servicios utilizados, servidores, ...
Conexiones entre componentesSuele estar mezclada en el código de implementaciónNo se tiene una visión global de la arquitectura de la aplicación 12
Lidia Fuentes Fernández
Modelos/Plataformas de Componentes
CCM (CORBA Component Model), CCM/CORBAEvolución de la plataforma distribuida OO, CORBA (Common Object Request Broker Architecture) de OMGEl modelo de componentes más puro y evolucionado de los “comerciales”
EJB (Enterprise JavaBeans) EJB/J2EEEvolución del modelo JavaBeans de Java/Sun
Microsoft ofrece la plataforma .NET, pero no incluye un nuevo modelo de componentes aparte de COM
3
13
Lidia Fuentes Fernández
El modelo CCM
Un modelo orientado a componentes distribuidosDefine una arquitectura para diseñar componentes y sus interacciones
Tanto del lado del cliente (GUIs) como del servidor (componentes de negocio)
Define una tecnología de “paquetes” para “desplegar”componentes ejecutables, binarios multi-lenguajeMecanismo de “contenedor” para inyectar código de
En contraposición a EJB que está basado en Java y a .NET basado en productos de Microsoft 14
Lidia Fuentes Fernández
Interfaz de un componente CCM
Atributos (attributes)Facetas (facets)
Interfaz proporcionadaReceptáculos (receptacles)
Interfaz requeridaFuente de eventos (event sources)Sumidero de eventos (event sinks)
15
Lidia Fuentes Fernández
Componente CCM
16
Lidia Fuentes Fernández
Ejemplo: Filósofos comiendoInterfaz del Componente Filósofo
17
Lidia Fuentes Fernández
Ejemplo: Filósofos comiendoInterfaz del Componente Tenedor
18
Lidia Fuentes Fernández
Ejemplo: Filósofos comiendoComponente Tenedor
Descriptor de componente
4
19
Lidia Fuentes Fernández
Ejemplo: Filósofos comiendoConexión entre componentes
20
Lidia Fuentes Fernández
Implementaciones CCM Open Source
OpenCCMhttp://www.objectweb.org/OpenCCM/
MicoCCMhttp://www.fpx.de/MicoCCM/
FreeCCMhttp://sourceforge.net/projects/cif/
21
Lidia Fuentes Fernández
CCM vs EJB, COM y .NETSimilitudes con EJB
Los componentes CORBA se crean y gestionan en “homes”Se ejecutan en contenedores pudiendo acceder a los servicios comunes de forma transparenteResiden en servidores de aplicaciones de componentes
Similitudes con COMPueden definirse varias interfaces tanto de entrada como de salida
Tanto envío de mensajes síncronos como eventos asíncronosCapacidad de introspección
Similitudes con .NETPueden desarrollarse en diferentes lenguajes de programaciónSe pueden empaquetar para ser distribuidos
Lo que hace CCM diferenteUna aplicación es realmente distribuida
Se puede desplegar y ejecutar en nodos distribuidosUn componente CCM se puede segmentar en diferentes clases
22
Lidia Fuentes Fernández
Mercado Global de Componentes
Reutilización de componentes externos (Commercial-Off-The-Shelf, COTS)COTS es una clase especial de componente software, normalmente de grano grueso, que presenta estas características [Meyer 2001]:
son vendidos o licenciados al público en generallos mantiene y actualiza el propio vendedor, quien mantiene los derechos de la propiedad intelectualestán disponibles en forma de múltiples copias, todas idénticas entre sísu código no puede ser modificado por el usuario
23
Lidia Fuentes Fernández
Mercado Global de Componentes
Beneficios del uso de componentes COTSMayor estabilidad del softwareMayor eficiencia del softwareReduce el tiempo de desarrolloReduce el coste del producto final
24
Lidia Fuentes Fernández
Mercado Global de Componentes
ActoresProgramadores autónomosProveedores de Software Independientes, intermediarios, ...Usuarios compradores
Catálogos de componentesExtensión de IDLs para incorporar información de mercadotecnia
Autor, Calidad de Servicio, Licencia, Demos,....Ej: componentsource.com, www.flashline.com,
www.wrldcomp.com
5
25
Lidia Fuentes Fernández
componentsource.com: venta
26
Lidia Fuentes Fernández
componentsource.com:compra
27
Lidia Fuentes Fernández
componentsource.com:encargo
28
Lidia Fuentes Fernández
Desarrollo Basado en COTS
El uso de COTS sugiere nuevos ciclos de desarrolloEl éxito del uso de COTS depende de la eficacia del proceso de selección
Definición de una arquitectura abstracta, reutilización a posteriori (enfoque top-down)Reutililización de COTS, la arquitectura surge sola (enfoque bottom-up)
Especificación de Requisitos
Análisis (arquitectura de alto nivel)
Diseño (arquitectura detallada)
Implementación (uso de COTS)
Requisitos
COTS
Arquitectura
30
Lidia Fuentes Fernández
Arquitectura Abstracta (enfoque top-down)(+) Arquitectura bien definida(+) Interfaces completos y bien definidos(+) Incorpora todos los requisitos, no más(–) Difícil la reutilización de COTS(–) Necesidad de adaptadores(–) ¿Coste en relación a la implementación
desde cero? Puede hacer inviable el uso de COTS
6
31
Lidia Fuentes Fernández
Reutilización de COTS (enfoque bottom-up)(+) Fácil reutilización de COTS(+) Minimiza la codificación(+) Aplicación resultante más robusta y con
funcionalidad añadida(–) Poca atención a los aspectos
arquitectónicos(–) Solapamiento en la funcionalidad de los
COTS(–) La actualización de la aplicación depende de
las nuevas versiones de los COTS adquiridos32
Lidia Fuentes Fernández
Adquisición de COTSCondiciones
La funcionalidad del componente COTS cumple con todo o parte de los requisitos del clienteEl lenguaje de programación o plataforma de desarrollo es la deseada por el clienteDependencia con el entorno mínimaLa calidad de servicio es excelenteEl cliente prevé usarlo más de una vezEl cliente confía en la reputación del proveedorEl precio y condiciones de la licencia del componente
33
Lidia Fuentes Fernández
Problemas del DBC COTS(comprador)
¿Cómo reconozco los componentes que necesito? (COTS trading)
Los COTS no están bien documentados, entonces el proceso de selección es muy difícil
¿Cómo adapto los componentes COTS de acuerdo a mis requisitos? Necesidad de adaptar los productos adquiridos
Si hay que adaptar más del 20% de la funcionalidad de un componente, es mejor desarrollarlo a medida!
Los compradores no tienen acceso al diseño e implementación interna de los productos COTS
34
Lidia Fuentes Fernández
Problemas del DBC COTS (comprador)
El problema de las “dependencias”¿Cómo gestiono las incompatibilidades, los conflictos, y las lagunas al componer COTS?
Necesidad de integrar productos de diferentes vendedores
¿Cómo se gestionan los requisitos “extra-funcionales”?El ciclo de vida del producto COTS lo determina el vendedorDependencia total del vendedor para actualizaciones, mantenimiento, ....
35
Lidia Fuentes Fernández
Problemas del DBC COTS (vendedor)
¿Cómo diseño los componentes para maximizar su reutilización?
“Maximizing reuse minimizes use”¿Cómo gestiono las versiones de los componentes? ¿Y el mantenimiento?El problema de las “dependencias”, ¿qué solución ofrezco?¿Para cuántas plataformas desarrollo?¿Cómo se tratan los requisitos extra-funcionales?
36
Lidia Fuentes Fernández
COTS: Problemas de mercadoEl Software: ¿producto o servicio?¿Me interesa vender mis componentes?
¿Si tengo un componente bueno, quiero vendérselo a la competencia?¿Lo vendo o lo licencio?¿Me interesa mantenerlo? ¿Y la formación?
¿Qué vende mi compañía, productos o servicios?¿Qué pasa con la calidad?¿Legalmente a qué me comprometo?
7
37
Lidia Fuentes Fernández
Problemas del DBC COTS(comprador)
¿Cómo reconozco los componentes que necesito? (COTS trading)
Los COTS no están bien documentados, entonces el proceso de selección es muy difícil
¿Cómo adapto los componentes COTS de acuerdo a mis requisitos? Necesidad de adaptar los productos adquiridos
Si hay que adaptar más del 20% de la funcionalidad de un componente, es mejor desarrollarlo a medida!
Los compradores no tienen acceso al diseño e implementación interna de los productos COTS
38
Lidia Fuentes Fernández
Problemas del DBC COTS (comprador)
El problema de las “dependencias”¿Cómo gestiono las incompatibilidades, los conflictos, y las lagunas al componer COTS?
Necesidad de integrar productos de diferentes vendedores
¿Cómo se gestionan los requisitos “extra-funcionales”?El ciclo de vida del producto COTS lo determina el vendedorDependencia total del vendedor para actualizaciones, mantenimiento, ....
39
Lidia Fuentes Fernández
Problemas del DBC COTS (vendedor)
¿Cómo diseño los componentes para maximizar su reutilización?
“Maximizing reuse minimizes use”¿Cómo gestiono las versiones de los componentes? ¿Y el mantenimiento?El problema de las “dependencias”, ¿qué solución ofrezco?¿Para cuántas plataformas desarrollo?¿Cómo se tratan los requisitos extra-funcionales?
40
Lidia Fuentes Fernández
Conclusiones
Los componentes mejoran la modularización y ponen énfasis en la noción de composición tipo “caja negra” e introducen la noción de mercadotecnia
Desarrollo de Software Orientado a Aspectos
42
Lidia Fuentes Fernández
Motivación
La propiedad de “parsing” de un documento XML aparece localizada en una clase
Modularización en Apache Tomcat
La propiedad de “logging” aparece dispersa (scattered) en varias clases
8
43
Lidia Fuentes Fernández
Motivación
En orientación a objetos la funcionalidad suele estar dispersa en varias clases
44
Lidia Fuentes Fernández
Motivación
Utilizando plataformas de componentes a) Llamadas al mismo código desde distintos
( int )(S yst em.c urr ent Tim eMi lli s() - l ast Acc ess ed) / 1 000 ;
if (t his Int erv al > in act ive Int erv al) {
i nva lid ate ();
S erv erS ess ionM ana ger ss m =
Ser ver Sess ion Man age r.g etM anag er( );
s sm. rem ove Sess ion (th is) ;
}
}
}
syn chro niz ed voi d i nva lida te( ) {
Enu mer ati on enu m = app Ses sio ns. key s() ;
whi le (en um. has Mor eEle men ts( )) {
Ob jec t k ey = e num. nex tEl eme nt( );
Ap pli cat ion Ses sion ap pSe ssi on =
( App lic ati onSe ssi on) app Ses sio ns.g et( key );
ap pSe ssi on. inv alid ate ();
}
}
pub lic voi d p utV alu e(S trin g n ame , O bje ct valu e) {
if (na me == nul l) {
St rin g m sg = s m.ge tSt rin g(" ser ver Sess ion .va lue .ia e") ;
th row ne w I lle galA rgu men tEx cep tio n(ms g);
}
rem ove Val ue( nam e); // re mov e a ny exi stin g b ind ing
val ues .pu t(n ame , v alue );
}
pub lic Obj ect ge tVa lue (Str ing na me) {
if (na me == nul l) {
St rin g m sg = s m.ge tSt rin g(" ser ver Sess ion .va lue .ia e") ;
th row ne w I lle galA rgu men tEx cep tio n(ms g);
}
ret urn va lue s.g et( name );
}
pub lic Enu mer ati on get Valu eNa mes () {
ret urn va lue s.k eys ();
}
pub lic voi d r emo veV alu e(St rin g n ame ) {
val ues .re mov e(n ame );
}
pub lic voi d s etM axI nac tive Int erv al( int in terv al) {
ina cti veI nte rva l = int erv al;
}
pub lic int ge tMa xIn act iveI nte rva l() {
ret urn in act ive Int erva l;
}
// XXX
// sync 'd for sa fty -- no oth er thr ead sh ould be ge tti ng som ethi ng
// from th is whi le we are rea pin g. Thi s i sn't th e m ost op tim al
// solu tio n f or thi s, but we' ll det erm ine som eth ing el se lat er.
if (thi sIn ter val > ina ctiv eIn ter val ) {
i nva lid ate ();
S erv erS ess ionM ana ger ss m =
Ser ver Sess ion Man age r.g etM anag er( );
s sm. rem ove Sess ion (th is) ;
}
}
}
syn chro niz ed voi d r eap () {
Enu mer ati on enu m = app Ses sio ns. key s() ;
whi le (en um. has Mor eEle men ts( )) {
Ob jec t k ey = e num. nex tEl eme nt( );
Ap pli cat ion Ses sion ap pSe ssi on =
( App lic ati onSe ssi on) app Ses sio ns.g et( key );
ap pSe ssi on. val idat e() ;
}
}
}
seguridad
persistencia
a)
b)
transacción
Concepto que está replicado en varios componentes
45
Lidia Fuentes Fernández
Motivación
Una propiedad que “atraviesa” varios componentes o clases es un crosscuttingconcernConsecuencias de los crosscutting concerns
Código disperso (scattered). La especificación relativa a una propiedad o funcionalidad NO se encuentra localizada en un módulo sino que se encuentra dispersa en una serie de ellos.Código enmarañado (tangled). Los diferentes módulos contienen descripciones mezcladasrelativas a varias propiedades no funcionales.
46
Lidia Fuentes Fernández
Coste del código enmarañado (tangled code)
Dificultad para:Encontrar el código redundanteRealizar los cambios de forma consistenteConseguir realizar los cambios sin “romper” el códigoIncrementa el tamaño del código finalIncrementa de forma exponencial el coste de mantenimientoCodificar el último 10% de código “enmarañado”produce el 90% de los dolores de cabeza tantodurante el desarrollo como en el mantenimiento
47
Lidia Fuentes Fernández
Causas del “código enmarañado”
Tiranía de la descomposición dominante“…the tyranny of the dominantdecomposition is the single mostsignificant cause of the failure, to date,toachieve many of the expected benefits ofseparation of concerns”
Ossher and Tarr – HyperJ User Manual, 2001
No puede extraerse el código enmarañado usando las técnicas de modelado convencionales
48
Lidia Fuentes Fernández
Modularización
Desarrollo de software extensible y adaptablenecesita la descomposición de sistemas en módulos totalmente independientes
TAREA DÍFICILLa “separación de aspectos” propone extraer aquellos “aspectos” o propiedades que atraviesan varios componentes o clases, y/o que están enmarañadas
MEJORA LA MODULARIZACIÓN
9
49
Lidia Fuentes Fernández
BeneficiosSeparación – la identificación de un “aspecto” permite tratarlo como una entidad independienteLocalización – la implementación de un un “aspecto” aparece sólo en una parte del programaGestión – el aspecto tendrá una interfaz clara que mejorará la gestión de cambiosReutilización – se incrementa la reutilización de código
// w e'v e ex cee ded it
if (in act ive Int erv al ! = - 1) {
in t t his Int erv al =
( int )(S yst em.c urr ent Tim eMi lli s() - l ast Acc ess ed) / 1 000 ;
if (t his Int erv al > in act ive Int erv al) {
i nva lid ate ();
S erv erS ess ionM ana ger ss m =
Ser ver Sess ion Man age r.g etM anag er( );
s sm. rem ove Sess ion (th is) ;
}
}
}
syn chro niz ed voi d i nva lida te( ) {
Enu mer ati on enu m = app Ses sio ns. key s() ;
whi le (en um. has Mor eEle men ts( )) {
Ob jec t k ey = e num. nex tEl eme nt( );
Ap pli cat ion Ses sion ap pSe ssi on =
( App lic ati onSe ssi on) app Ses sio ns.g et( key );
ap pSe ssi on. inv alid ate ();
}
}
pub lic voi d p utV alu e(S trin g n ame , O bje ct valu e) {
if (na me == nul l) {
St rin g m sg = s m.ge tSt rin g(" ser ver Sess ion .va lue .ia e") ;
th row ne w I lle galA rgu men tEx cep tio n(ms g);
}
rem ove Val ue( nam e); // re mov e a ny exi stin g b ind ing
val ues .pu t(n ame , v alue );
}
pub lic Obj ect ge tVa lue (Str ing na me) {
if (na me == nul l) {
St rin g m sg = s m.ge tSt rin g(" ser ver Sess ion .va lue .ia e") ;
th row ne w I lle galA rgu men tEx cep tio n(ms g);
}
ret urn va lue s.g et( name );
}
// w e'v e ex cee ded it
if (in act ive Int erv al ! = - 1) {
in t t his Int erv al =
( int )(S yst em.c urr ent Tim eMi lli s() - l ast Acc ess ed) / 1 000 ;
if (t his Int erv al > in act ive Int erv al) {
i nva lid ate ();
S erv erS ess ionM ana ger ss m =
Ser ver Sess ion Man age r.g etM anag er( );
s sm. rem ove Sess ion (th is) ;
}
}
Serv erS essi onM ana ger ss m =
Ser ver Sess ion Man age r.g etM anag er( );
s sm. rem ove Sess ion (th is) ;
}
}
}
pub lic Enu mer ati on get Valu eNa mes () {
ret urn va lue s.k eys ();
}
pub lic voi d r emo veV alu e(St rin g n ame ) {
val ues .re mov e(n ame );
}
pub lic voi d s etM axI nac tive Int erv al( int in terv al) {
ina cti veI nte rva l = int erv al;
}
pub lic int ge tMa xIn act iveI nte rva l() {
ret urn in act ive Int erva l;
}
// XXX
// sync 'd for sa fty -- no oth er thr ead sh ould be ge tti ng som ethi ng
// from th is whi le we are rea pin g. Thi s i sn't th e m ost op tim al
// solu tio n f or thi s, but we' ll det erm ine som eth ing el se lat er.
if (thi sIn ter val > ina ctiv eIn ter val ) {
i nva lid ate ();
S erv erS ess ionM ana ger ss m =
Ser ver Sess ion Man age r.g etM anag er( );
s sm. rem ove Sess ion (th is) ;
}
}
}
syn chro niz ed voi d r eap () {
Enu mer ati on enu m = app Ses sio ns. key s() ;
whi le (en um. has Mor eEle men ts( )) {
Ob jec t k ey = e num. nex tEl eme nt( );
Ap pli cat ion Ses sion ap pSe ssi on =
( App lic ati onSe ssi on) app Ses sio ns.g et( key );
ap pSe ssi on. val idat e() ;
}
}
}
whi le (en um. has Mor eEle men ts( )) {
Ob jec t k ey = e num. nex tEl eme nt( );
Ap pli cat ion Ses sion ap pSe ssi on =
( App lic ati onSe ssi on) app Ses sio ns.g et( key );
ap pSe ssi on. inv alid ate ();
}
}
pub lic voi d p utV alu e(S trin g n ame , O bje ct valu e) {
if (na me == nul l) {
St rin g m sg = s m.ge tSt rin g(" ser ver Sess ion .va lue .ia e") ;
th row ne w I lle galA rgu men tEx cep tio n(ms g);
}
rem ove Val ue( nam e); // re mov e a ny exi stin g b ind ing
val ues .pu t(n ame , v alue );
}
pub lic Obj ect ge tVa lue (Str ing na me) {
if (na me == nul l) {
St rin g m sg = s m.ge tSt rin g(" ser ver Sess ion .va lue .ia e") ;
th row ne w I lle galA rgu men tEx cep tio n(ms g);
}
ret urn va lue s.g et( name );
}
pub lic Enu mer ati on get Valu eNa mes () {
ret urn va lue s.k eys ();
}
pub lic voi d r emo veV alu e(St rin g n ame ) {
val ues .re mov e(n ame );
}
pub lic voi d s etM axI nac tive Int erv al( int in terv al) {
ina cti veI nte rva l = int erv al;
}
pub lic int ge tMa xIn act iveI nte rva l() {
ret urn in act ive Int erva l;
}
// XXX
// sync 'd for sa fty -- no oth er thr ead sh ould be ge tti ng som ethi ng
// from th is whi le we are rea pin g. Thi s i sn't th e m ost op tim al
syn chro niz ed voi d r eap () {
Enu mer ati on enu m = app Ses sio ns. key s() ;
whi le (en um. has Mor eEle men ts( )) {
Ob jec t k ey = e num. nex tEl eme nt( );
Ap pli cat ion Ses sion ap pSe ssi on =
( App lic ati onSe ssi on) app Ses sio ns.g et( key );
if access(user,document)// Permiso concedidoprocess(user,document)
else// Permiso denegado
....
class Room {....join(user,room) {
if access(user,room)// Permiso concedidoenter(user,room)
else// permiso denegado
....
if access(user,resource)// Permiso concedido
else// permiso denegado
• Cada llamada a open() y join() irá precedida por la evaluación del aspecto de “control de acceso”
Aspecto “control de acceso”
class Document {....open(user,document) {
process(user,document)....
.... class Room {....join(user,room) {enter(user,room)....
....
Código “limpio”
51
Lidia Fuentes Fernández
Definición de DSOA (en inglés AOSD)
AntecedentesSeparation of concerns (separación de conceptos)Aspect Oriented Programming (AOP)
Programación orientada a aspectos [Kiczales97]
Desarrollo de Software Orientado a Aspectos (DSOA) en inglés Aspect Oriented Software Development, AOSD)
Basado en la noción de “aspecto”Abarca todas las fases del ciclo de vida del desarrollo software (early aspects, design aspects, ....)Conferencia internacional (AOSD, http://aosd.net) 52
Lidia Fuentes Fernández
Identificación de aspectosAspectos que resulta útil tratar de forma independiente
Propios de sistemas distribuidos – sincronización, coordinación, seguridad, persistencia, tolerancia a fallos, ...Específicos de dominio (ej: EVC: presencia, colaboración, ....)
Requisitos para la separación y composición de aspectosPrever cambios en el futuro y reutilización altaMínimo acoplamiento entre aspectosAdición no intrusiva de aspectos a los componentes
GranularidadDesde un par de líneas de código a semejantes a un componente
53
Lidia Fuentes Fernández
EnfoquesEnfoques para separar aspectos a nivel de implementación
Biblioteca de funciones convencionalDiseñar un lenguaje de aspectos
Definen un lenguaje de propósito específico (ej: AspectJ, HyperJ, ...)
Marcos de Trabajo (framework) de aspectosUtilizan un lenguaje de propósito general (ej: Java)Marcos de Trabajo OO (definen un patrón de diseño)Plataformas (middleware) basadas en componentes y aspectos Web sobre DSOA
54
Lidia Fuentes Fernández
Enlazado de Componentes-Aspectos
Estático: El código de componentes y aspectos se mezcla parasu ejecución
Basado en el uso de Lenguajes de Aspectos (ej: AspectJ, HyperJ, …)El código resultante está optimizadoNo hay reutilización ni composición dinámica de aspectos
Dinámico: Integración de componentes y aspectos en tiempo de ejecución
Basado en lenguajes de propósito general (ej: JAC, DAOP)Sistema más adaptable y extensibleSobrecarga, sistema menos eficiente
10
55
Lidia Fuentes Fernández
Enlazado de Componentes-Aspectos Estático
Programa de componentes
Programa de aspectos
Compilador
Tejedor(Weaver)
Ci
Ai
Lenguaje base
Lenguaje deAspectos o extensión
Ejecutable
C1
A!
A2
C2A3
Código mezclado
56
Lidia Fuentes Fernández
Enlazado de Componentes-Aspectos Dinámico
C1
Tejedor(Weaver)
C2
C3
A1 A2 A3
C1 ⊗ A2
Punto de corte
C2 ⊗
A1 A3||;
operator
C3
antesdespués.... Un método/mensaje{ }
57
Lidia Fuentes Fernández
AspectJ de Eclipse/IBMEs una extensión orientada a aspectos de Java™que soporta la programación orientada a aspectos de propósito general Se codifican los aspectos en el lenguaje AspectJ y luego se usa un precompilador que genera código JavaEl “enlazado” (link) de código con los aspectos es estático
58
Lidia Fuentes Fernández
Ejemplo de AspectJ (1)
Código repetido,debemos extraerlo ymodelarlo como un aspecto y definir el “punto de corte”o join point(cuando se debe invocar el código)
59
Lidia Fuentes Fernández
Join points en AspectJJoin points
Puntos en la ejecución de programas Java donde va a inyectarse código relativo a crosscutting concerns.
Ej: después de invocar el método setP1() del ejemplo
1. Modelo de Join points de AspectJLlamada/Recepción a un método o constructorEjecución de un método o constructorAcceso a camposEjecución de manejadores de excepciónInicialización estática o dinámicaCódigo dentro de una clase o métodoOtros puntos
60
Lidia Fuentes Fernández
Join points (puntos de intercepción)
a Point
a Line
a Point
Ejecución del método: Line.moveBy(2,2)
Todo este flujo de ejecuciónse correspondería con el mismo join point
11
61
Lidia Fuentes Fernández
Definición de un aspecto en AspectJ
Aspecto (aspect)
Punto de corte(pointcut)
Advice
2. Un modo de identificar join points (pointcut)3. Un modo de especificar comportamiento en los join points (advice)4. Un modo de encapsular unidades que combinen join points y
comportamiento (aspect)2. Un mecanismo de ligadura entre unidades y programas
(preprocesado y generación de código)
62
Lidia Fuentes Fernández
Ejemplo de AspectJ
Después de invocarse los métodos setP1() y setP2()“inyectar código” de redibujado: Display.update()
63
Lidia Fuentes Fernández
Ejemplo completo
Introducir Display.update en otrosmétodos (sencillo, natural, ...)
64
Lidia Fuentes Fernández
Ventajas de AspectJLa gran variedad de join points que se pueden definir (se puede interceptar prácticamente cualquier parte del programa)Al realizar composición estática es igual de eficiente que no usarloEs un producto comercial propiedad de IBM, muy probadoMuy difundido, también a nivel de empresaEs gratuito (el compilador es Open Source)Incluye soporte desde EDI (entornos de desarrollo)
emacs, JBuilder, EclipseTienen listas de distribución
Dificultad de reutilización de los aspectos (los pointcut y advices están mezclados)No es posible cambiar el número y tipo de aspectos aplicados a un objeto en ejecuciónEs difícil conocer la lista de aspectos que pueden afectar a un objetoTodo esto dificulta otra vez la gestión de la evolución de los crosscutting concerns
66
Lidia Fuentes Fernández
Nuestro enfoque: CAM/DAOPNuestra propuesta de una plataforma dinámica de componentes y aspectosCAM es un modelo de componentes y aspectos
Los componentes y los aspectos son entidades de primer ordenIntroduce aspectos de forma no invasiva al componente
DAOP es una plataforma de componentes y aspectosHace composición dinámica en tiempo de ejecuciónUsa y representa de forma explícita la arquitectura de la aplicación dentro de la plataforma
DAOP-ADL es un lenguaje de descripción de arquitectura en XMLIncluye los descriptores de componentes y de aspectos además de las reglas de composición de componentes y evaluación de aspectos
12
67
Lidia Fuentes Fernández
Modelo CAM
CAM (Component and Aspect Model)Perfil UML del modelo CAMSe aplican los aspectos a componentes caja-negra
MensajesEventosCreación de componentesDestrucción de componentes
Lidia Fuentes
68
Lidia Fuentes Fernández
CAM ModelLidia Fuentes
69
Lidia Fuentes Fernández
Plataforma DAOPDAOP (Dynamic Aspect Oriented Platform)
Realiza composición en tiempo de ejecución y no en tiempo de carga (en Java con RMI y applets)Arquitectura de la Aplicación
Se representa explícitamente dentro de la plataformaEsta información se puede modifcar en tiempo de ejecución (agregar, borraro reemplazar componentes, aspectos e incluso reglas de composición)
Servicios de la plataformaServicio de comunicación (eventos, mensajes síncronos y asíncronos)Servicios de factoría (creación de componentes)Servicio de evaluación de aspectos (definición del advice)Servicio de propiedades (resuelve dependencias de datos entre componentesy aspectos)Servicio de persistencia (para implementar el aspecto de persistencia)Servicios de configuración (modifica la AA en tiempo de ejecución)
Lidia Fuentes
70
Lidia Fuentes Fernández
DAOP Platform
71
Lidia Fuentes Fernández
DAOP PlatformLidia Fuentes
72
Lidia Fuentes Fernández
DAOP-ADL: Lenguaje de componentes y aspectos
DAOP-ADL es un lenguaje de descripción de arquitecturaDefinido en un esquema XMLDAOP-ADL está basado en el modelo CAM, peropuede ser interpretado por un entorno de ejecución(como la plataforma DAOP)La plataforma DAOP crea y compone componentes y aspectos según la información especificada en el lenguaje DAOP-ADL para una aplicaciónDAOP-ADL acorta el salto entre diseño e implementación porque un diseño especificado en DAOP-ADL se interpreta directamente, sin ningunageneración de código
Los componentes mejoran la modularización y ponen énfasis en la noción de composición tipo “caja negra” e introducen la noción de mercadotecniaPero los aspectos mejoran aún más la modularización, acaban con el código enmarañado y entremezclado y mejoran la gestión de la evolución
Ingeniería del SoftwareOrientada a Agentes
77
Lidia Fuentes Fernández
Concepto de AgentesDefinición de Agente Software
“Entidad autónoma proactiva y reactiva”“Sistema computacional que actúa en entornos dinámicos complejos, percibe y actúa de forma autónoma (independiente) sobre este entorno, llevando a cabo un conjunto de objetivos o tareas, para los cuales están diseñados” [P. Maes]
AutonomíaLlevar a cabo objetivos o tareasEntorno cambiante, complejo
78
Lidia Fuentes Fernández
Concepto de AgentesCaracterísticas básicas
Autonomía: actúan sin intervención externaSociabilidad: comunicación con otros agentesReactividad: responde a los cambios del entornoIniciativa (proactividad): capaz de tomar la iniciativaContinuidad: ejecución continuaConocimiento: sobre un dominio específicoAutoridad: poseer derechos de accesoMovilidad: son capaces de migrar
14
79
Lidia Fuentes Fernández
Aplicaciones Internet
Correo electrónico inteligente. Todos los usuarios tienen un sistema de agentes. A un agente de correo electrónico inteligente se le puede dar unmensaje (puede ser un documento) y un itinerario. El agente sigue el itinerario, y puede ser modificado en su camino.
80
Lidia Fuentes Fernández
Justificación del uso de agentes
Campo de aplicaciónCódigo móvilMonitorizaciónTrabajo colaborativoSistemas de búsqueda de información
Ventajas del uso de agentesEficiencia de cara a conseguir un objetivoAdaptación al clientePueden formar sociedades de agentes imitando nuestra forma de organizarnos
81
Lidia Fuentes Fernández
Sistemas multiagentesLos sistemas multiagentes:
Agentes autónomos trabajan juntos para resolver problemas, caracterizado porque cada agente tiene una información o capacidad incompleta para solucionar el problema
Sistemas que se centran en la conducta individualNo hay un sistema global de controlLos datos están descentralizadosLa Computación es asíncronaLos agentes pueden decidir dinámicamente que tareas deben realizar y quien realiza cada tarea, ....
82
Lidia Fuentes Fernández
Ingeniería del Software basada en Agentes
La Ingeniería del Software está mostrando interés en analizar la potencia de los agentes como nuevo paradigma de diseño Ingeniería del Software Basada en Agentes(AOSE, Agent-oriented Software Engineering)Los objetos encapsulan y tienen autonomía sobre su estado interno, mientras que los agentes tienen autonomía sobre su estado y su comportamiento¿Cómo podemos adaptar el concepto de agente como un paradigma de diseño software?¿Qué beneficios obtenemos de un diseño orientado a agentes frente a otros paradigmas (objetos o componentes)?
83
Lidia Fuentes Fernández
Diseño de sistemas basados en agentes
Los mensajes deben ser transportados entre diferentes agentes (procesos) TCP/IP, SMTP, HTTP, etc.Un lenguaje de comunicación de agentes define el formato de los mensajes y un lenguaje de contenido los tipos de mensajes informar, pedir un dato, aseveración, etc.Los agentes participan en diálogos protocolos de interacciónEl comportamiento comunicativo del agente está regido por sus estados mentalesFIPA es el organismo que estandarización de agentes
84
Lidia Fuentes Fernández
Lenguajes de Comunicación y Lenguajes de Contenido
– Lenguajes de Comunicación (ACL)FIPA-ACL (Agent Communication Language)KQML (Knowledge Query and Manipulation Language), no se usa
– Lenguajes de ContenidoFIPA-SLKIF (Knowledge Communication Language)
– Una ontología que representa un vocabulario comúnOntología-medicina, ontología-comercio electrónico
15
85
Lidia Fuentes Fernández
El modelo de referencia FIPA
Agent Platform
Agent Platform
Message Transport Service
AgentManagement
System
DirectoryFacilitator
Message Transport Service
Software
Agent
AgenteAID
AMS Sistema de Gestión de Agentes
DF Servicio de Localización de Agentes
MTSServicio de Transporte de Mensajes entre agentes
Este modelo de referencia se compone de un conjunto de entidades que ofrecen diferentes servicios.
86
Lidia Fuentes Fernández
FIPA ACL (lenguaje de comunicación)
Sintaxis del mensajeÚnico elemento obligatorio es la performativa (acto comunicativo), y normalmente se incluye también el emisor, receptor y contenido
87
Lidia Fuentes Fernández
Actos comunicativosRealización de una acción , ej.: agree
El emisor está de acuerdo en hacer la acción pedida (request), pero no antes de que se cumpla la precondiciónContenido: una expresión de acción y una proposiciónEjemplo: el agente i le pide al j que entregue una caja en una cierta localización y el le contesta que vale pero que su prioridad es baja
Protocolo de InteracciónConversaciones entre agentes siguen unos patrones determinados, secuencia de mensajes intercambiados: Protocolos de Interacción(PI), cada agente sabe que mensajes enviar y cuales recibirLos agentes pueden involucrarse en diálogos múltiples, quizás con agentes diferentes, simultáneamente. Un agente puede mantener concurrentemente múltiples conversaciones, con agentes diferentes, y utilizando protocolos diferentesProtocolos estándar definidos por FIPA:
Es el más comúnUn agente pide a otro que realice una acción. El receptor puede aceptar o rechazar la petición. En caso de aceptar, debe realizar la acción e informar al finalizar, en caso de fallo o si tiene que pasar algún resultado
Define un marco de trabajo (application framework) orientado a objetos para desarrollar agentesEs prácticamente el más usadoPresenta el problema del “código enmarañado” (tangledcode)
En la misma clase hay que programar tanto la funcionalidad y protocolos de interacciónDependencia no deseable que impide una buena gestión de la evoluciónLa funcionalidad no puede (re)utilizarse en diversos agentes del mismo dominio de aplicación
En cada clase se entremezla el protocolode interacción y el acceso al catálogo
Agente vendedor de libros en JADE
93
Lidia Fuentes Fernández
DSBC y DSOA al servicio de los agentes: El modelo Malaca
La funcionalidad se encapsula en componentes COTS (commercial-off-the-shelf)Otras propiedades se modelan como aspectos
Coordinación (protocolo de interacción)Distribución (acceso a una plataforma de agentes)Representación (codificación de los mensajes)
VentajasProgramación, configuración y despliegue de forma independiente de la funcionalidad y de los diferentes aspectosComposición de componentes y aspectos (weaving) de forma transparente a ambos elementos (obliviousness)
94
Lidia Fuentes Fernández
Agente vendedor de libros en Malaca
Mediator
+PurchaseOrderService( bookT itle : string ) : int+OfferRequestService( bookTit le : string ) : int
+updateCatalogue()
BookSellerComponent
-catalogue : java.util.Hashtable
StringRepresentationAspect
Descripción XML del protocolo PurchaseOrderProtocol
Descripción XML del protocolo OfferRequestProtocol
Descripción de los protocolos fuera del componente
Independencia de la plataforma de agentes
95
Lidia Fuentes Fernández
ConclusionesLos componentes mejoran la modularización y ponen énfasis en la noción de composición tipo “caja negra” e introducen la noción de mercadotecniapero los aspectos mejoran aún más la modularización, acaban con el código enmarañado y entremezclado y mejoran la gestión de la evoluciónLos agentes representan un paradigma diferente, más cercano a la IA, aunque hemos visto que pueden implementarse usando tecnologías de componentes y aspectos