Índice tecnologías para el desarrollo de aplicaciones …canal/sabc/curso0506/cbsd_aosd.pdf ·...

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

[email protected]

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


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



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



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



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


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



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


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


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


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


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

persistencia, transacciones, seguridad, …Modelo multi-sistema operativo, lenguaje, …

En contraposición a EJB que está basado en Java y a .NET basado en productos de Microsoft 14


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


Componente CCM

16


Ejemplo: Filósofos comiendoInterfaz del Componente Filósofo

17


Ejemplo: Filósofos comiendoInterfaz del Componente Tenedor

18


Ejemplo: Filósofos comiendoComponente Tenedor

Descriptor de componente

4

19


Ejemplo: Filósofos comiendoConexión entre componentes

20


Implementaciones CCM Open Source

OpenCCMhttp://www.objectweb.org/OpenCCM/

MicoCCMhttp://www.fpx.de/MicoCCM/

FreeCCMhttp://sourceforge.net/projects/cif/

21


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


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



Beneficios del uso de componentes COTSMayor estabilidad del softwareMayor eficiencia del softwareReduce el tiempo de desarrolloReduce el coste del producto final

24



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


componentsource.com: venta

26


componentsource.com:compra

27


componentsource.com:encargo

28


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

Evaluación Selección Adaptación Integración Modificación

??

?

29


Diseño Arquitectónico Basado en Componentes

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


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


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


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


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


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


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


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


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


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


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


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


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


Motivación

En orientación a objetos la funcionalidad suele estar dispersa en varias clases

44


Motivación

Utilizando plataformas de componentes a) Llamadas al mismo código desde distintos

componentesb) Propiedades extra-funcionales referenciadas

desde componentes// 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) {




}

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 ();




}

}

}

syn chro niz ed voi d r eap () {






ap pSe ssi on. val idat e() ;

}

}

}

seguridad

persistencia

a)

b)

transacción

Concepto que está replicado en varios componentes

45


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


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


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


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


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





i nva lid ate ();




}

}

}

syn chro niz ed voi d i nva lida te( ) {







}

}





}



}





}


}

// w e'v e ex cee ded it





i nva lid ate ();




}

}

Serv erS essi onM ana ger ss m =



}

}

}



}



}



}



}

// XXX



// 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 ();




}

}

}








}

}

}






}

}





}



}





}


}



}



}



}



}

// XXX










}

}

}

ASPECTO (concern oraspect)

50


Código resultanteclass Document {....open(user,document) {

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


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


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


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


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


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


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


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


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


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


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


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


Ejemplo de AspectJ

Después de invocarse los métodos setP1() y setP2()“inyectar código” de redibujado: Display.update()

63


Ejemplo completo

Introducir Display.update en otrosmétodos (sencillo, natural, ...)

64


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

[email protected]@aspectj.org

Página webhttp://eclipse.org/aspectj/

65


Desventajas de AspectJ

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


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


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


CAM ModelLidia Fuentes

69


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


DAOP Platform

71


DAOP PlatformLidia Fuentes

72


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

Lidia Fuentes

13

73


DAOP-ADL Schema- <applicationArchitecture>+ <components>

(list of components)+ <aspects>

(list of aspects)+ <properties>

(list of properties) + <compositionConstraints>

(component-aspect weaving)+ <deploymentInformation>

(localisation of components and instantiation of aspects)+ <initialContext>

(list of initial components and properties instantiated at application launch)</applicationArchitecture>

Lidia Fuentes

74


Lenguaje de Componentes y Aspectos en XML

<?xml version="1.0" encoding="UTF-8"?><applicationArchitecture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ... /AASchema.xsd">

<componentsDescription><component role="privateRoom" .../> <component role="meetingRoom".../> ........

</componentsDescription><aspectsDescription>

<aspect role="authentication".../> <aspect role="multipleview".../> .........</aspectsDescription><compositionConstraints>

<componentCompositionRules.../><aspectsCompositionRules>

<aspectCompositionRule compRole="privateRoom meetingRoom"><rule>

<inputAspects><includedMessages>enter</includedMessages><aspectList> <aspect evaluation="critical">authentication</aspectList><aspectList><aspect evaluation="noncritical">multipleview </aspectList>

</inputAspects><outputAspects> .....

</rule> ......</compositionConstraints><initialContext/>

</applicationArchitecture>

75


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 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


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


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


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


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


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


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


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


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


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


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


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

(request:sender (agent-identifier :name i):receiver(set(agent-identifier :name j)):content

((action(agent-identifier :name j)(enviar caja109 (loc 12 13))))

:protocol fipa-request:language FIPA-SL:reply-with orden145)

(agree:sender (agent-identifier :name j):receiver(set(agent-identifier :name i)):content

((action(agent-identifier :name j)(enviar caja109 (loc 12 13)))(priority orden145 low))

:in-reply-to orden145:protocol fipa-request:language FIPA-SL)

88


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:

FIPA-request - FIPA-interacted-contract-netFIPA-query - FIPA-auction-englishFIPA-request-whenFIPA-contract-net

89


Protocolo de InteracciónFIPA-request

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

inform-proposition 7:

not-understood 2:

inform-action 6:

refuse 3:

failure 5:

agree 4:

request 1:

ReceptorEmisor

request 1:

not-understood 2:

refuse 3:

agree 4:

failure 5:

inform-proposition 7:

inform-action 6:

request

not-understood refuse agree

fallo inform-action inform-proposition

or

or

90


Envío de mensajes FIPAMensaje en un ACL(request

:sender (agent-identifier :name Agi):receiver(set(agent-identifier :name Agj)):content

((action(agent-identifier :name j)(enviar caja109 (loc 12 13))))

:protocol fipa-request:language FIPA-SL)

<fipa-message act=“request"conversation-id="ID000003">

<sender><agent-identifier>

<name id=“Agi" /></sender><receiver>

<agent-identifier><name id=“Agj" />

</agent-identifier></receiver>...</fipa-message>

Codificación del Mensaje

(XML, String, BitEfficient)

<fipa-message act=“request" conversation-id="ID000003"><sender><agent-identifier>

<name id=“Agi" /></sender><receiver>

<agent-identifier><name id=“Agj" /><addresses><url href=“http://jade:1099/"/></addresses>

</agent-identifier></receiver>...</fipa-message>

Receiver: http://jade:8080/Agj

Se coloca en un sobre

Agente j

Transporte del Mensaje Agi

XML, BitEfficient

Servicio de Transporte

de Mensajes Agj

IIOP, HTTP, ...

16

91


Desarrollo de Agentes Software en JADE

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

92


addBehaviour(new OfferRequestsServer());addBehaviour(new PurchaseOrdersServer());

+act ion()

jade.core.behaviours.Behaviour

+action()

PurchaseOrdersServer

+action()

OfferRequestsServer

+setup()

BookSellerAgent

-catalogue : Hashtable

OneShotBehaviour

+action()

UpdateCatalogue

jade.core.Agent

CyclicBehaviour

BookSellerGui

En cada clase se entremezla el protocolode interacción y el acceso al catálogo

Agente vendedor de libros en JADE

93


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


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

{notat ion=OWL-S}

<<ComponentInterface>>BookSeller +createMult icastMessage()

+createForwardMessage()

+createReplyMessage()

+createMessage()

BasicAgentActions

+handleOutputMessage()+handleInputMessage()+handleMessage()

AspectProtocolDescription<<InteractionPattern>>

CoordinationAspect DistributionAspect

+sendMessage()+bindAP()

MTSAdapter

AgentContext

JadeAdapter

invokeService handleMessage

sendMessage

handleMessage

receiveMessage

handleInputMessage

handleOutputMessage

realizes

realizes

<<use>>

Implementación del catálogo (en un sitio)

Descripción de los protocolos fuera del componente

Independencia de la plataforma de agentes

95


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

Índice tecnologías para el desarrollo de aplicaciones …canal/sabc/curso0506/cbsd_aosd.pdf ·...

Documents