tecnologias de negócio electrónicoeol/tne/apont/auml_slides.pdf · 1 janeiro 2004 mei-leic /...

1

Janeiro 2004 MEI-LEIC / Eugénio Oliveira

Extensões ao formalismo

UML

para Agentes e Sistemas Multi-Agente

Tecnologias de Negócio Electrónico


• Definição de Agente de Software:

Entidade computacional situada em um ambientedo qual recebe percepções e no qual efectua acçõescom autonomia e pró-actividadePode ter raciocínio e adaptação


•Sistema Multi-Agente:

Conjunto de agentes que interagem entendendo-see coordenando-se em tarefas globais envolvendoquer cooperação quer competição

2


•Sistema Multi-Agente• Coordenação não é hierárquica• Auto-organização (estratégica ou emergente)• Exemplo: Bando de pássaros auto-coordenam-seusando 3 comportamentos simples:1- manter uma distância mínima de outros2- tentar manter velocidade compatível3- tentar aproximar-se do centro de massa doconjunto na vizinhança


• Agentes como delegados• gestão de redes, gestão de processos, pesquisa info...• Agentes e Negócio Electrónico• B2B e B2C (compra, venda, intermediário, negociador)


Agentes como extensões a Objectos Activos

• autonomia (aceitação/recusa de pedidos) “NO”

• pró-actividade (iniciar actividade sem invocação externa) “GO”

Agentes não agem só isoladamente mas coordenados (cooperando) com Outros Agentes à Sistemas Multi-Agente

Unified Modeling Language (UML) para modelação de software orientado a Objectos (adoptado por OMG Novembro 1997)AUML: Variações e Extensões a UML para modelação de actividades dos Agentes

n FIPA (www.fipa.org) en Grupo de Agentes do OMG-AUML (http://aot.ce.unipr.it/auml/)n Representação de Protocolos de interacção para Agentes


3



• “Representing Agent Interaction Protocols in UML”James J. Odell* H. Van Dyke Parunak† Bernhard Bauer‡* James Odell Associates, 3646 W. Huron River Dr., Ann Arbor,MI 48103 USA† ERIM Center for Electronic Commerce, P.O. Box 134001,Ann Arbor, MI 48113 USA‡ Siemens, ZT IK 6, D-81730 München, Germany

Quem trabalha nestes formalismos?

• “Agent UML: A Formalism for Specifying Multiagent Interaction”Bernhard Bauer*, Jörg P. Müller*, James Odell+* Siemens, ZT IK 6, D-81730 München, Germany+ James Odell Associates, 3646 W. Huron River Dr,Ann Arbor, MI 48103 USA

Interacção



AgentClassifier

AgentClass

AgentRoleClass

Agent

AgentifiedGroup

Non-AgentifiedGroup

Group

0..*0..*0..*1..*

0..*0..*

Classifier(from Kernel)

classifiedinstanceclassifier

/groupmember

permittedroles

InstanceSpecification(from Kernel)

Structured Classifier(from Composite

Structures)

supportingbasic class

1..*

1..*grouproles

assignedgroup/group

Agent RoleClass

AgentClass

Buyer

CybeleAgentClass

InfoBroker

supporting “basic” agent classes permitted agent roles

AgentCityProvider

ZeusAgentClass

JadeAgentClass

••••••

0..*0..*

permittedroles

supportingbasic class

4



Agentes e capacidades



Agentes e Serviços

5


Papeis diferentes de um Agente podem ser descritos pelasintaxe UML

name/role:classMais Diagramas de Colaboração


Papel do Agente é o conjunto de propriedades, interfaces, descrições de serviços ou comportamentosdistintivos

Em UML podemos ter classificações:• Múltiplas. Ex: Um Agente com o papel de retalhista pode ser comprador e Vendedor em simultâneo)

• Dinâmicas quando um Agente pode mudar a sua classificação durante a sua existência.


Um Agente “Leiloeiro” num Leilão (por exemplo Inglês) tem esse papel (leiloeiro) e pode ser da Classe “Vendedor”

Os que interagen com o leiloeiro podem ter o papel de “participante de leilão” e serem da Classe “Comprador”


Leilões são procedimentos interactivos dedeterminação de preço de um item tal que:Valor Comprador >=Preço>= Custo Vendedor

6


Protocolos de Leilão:n Leilão inglês (aberto)


vendedor anuncia valor inicial de venda (valordesejado)leiloeiro (pode ser o vendedor) decresce valorgradualmentetermina quando um comprador aceita o valor actual

compradores submetem propostas iniciais (valoresdesejados)leiloeiro dá a conhecer ou todas ou a melhor propostacompradores oferecem propostas crescentes(limites valores de reserva)termina quando existe apenas uma proposta

? Leilão holandês (aberto)


- compradores submetem propostas conhecidas apenaspara o vendedor- comprador com proposta mais elevada vence o leilão, edeve pagar o valor anunciado


? Leilão “Vickrey” (fechado)

Protocolos de Leilão:

n Leilão “primeiro preço” (fechado)

- compradores submetem propostas conhecidasapenas para o vendedor- comprador com proposta mais elevada vence oleilão, e deve pagar o valor da 2ª maior proposta

7


UML Suporta :Modelos Estáticos: Diagramas de Classe e Package e a semântica de mensagens

n Diagramas de Classes usados de duas formas:n Modelam o domínio do Problema (para o utilizador)n Modelam a implementação das Classes (para o projectista)

n Diagramas de “packages” agrupam classes em agrupamentos conceptuais


ReléFusível

Vedante Rolamento

Parafuso

comprimento : DoublecabecaParafuso : String = hexagonal, allel, estrelada

Porcas

largura : DoubletipoFreio : String = plático, nylon, mecânico, sem freio Anel

largura : Double

Caixa Direção

percurso : Double Bomba Direção

Sistema

tipo : String = monotronic, k-jetronic, mono-jetronic

EspecificacaoMotordescricao

RodasDentadas

numeroDente : IntegertipoDente : String = reto, espiral, cônico

Pneulargura : DoublerelacaoAspecto : IntegerdiametroInterior : Double

diametroInterno : Doublelargura : DoublenumFuros : Integermaterial : String = liga de aço, alumínio, aço

Transmissõescomprimento : Doublediametro : DoubletipoSistemaRotula : String = por bolas, por cruzes, de agulhas

ABS

AirBag

SegurançaPassiva

Bomba

pressaoTrabalho : DoubletipoBomba : String = pistões, embulo, ...

DiscoTravão

arqProjeto : arquivo

TuboTravagemarqProjeto : arquivo

Corrente

largura : Doublecomprimento : DoubletipoDentes : String = quadrado, redondo, trapéziotipoBorracha : String

Cabo da Corrente

comprimento : Doubleresistencia : Integermaterial : String = LISTA

Eletrônica

11

11

Relé-Fusivelintensidade : IntegersistemaFuncionamento : String = contador, ruptor

Vela

resistencia : Integerdiametro : Doubleassento : String = cônico, anel

Engrenagem

1..n1..n

Transmissão

1..n1..n

1..n1..n

1..n1..n

Outrosquantidade : IntegerdiâmetroNominal : String

Janelaaltura : Doublecomprimento : Doubleespessura : DoubletipoCristal : String = laminado simples, laminado duploformato : StringarqProjeto : arquivo

BorrachaVedante

comprimento : DoubletipoBorracha : String = macia, oca, ...

TuboBorracha

diametroInterior : Doublecomprimento : DoublepressaoMaxima : Double

Tintacor : Integerkg : Double

SistemaSegurança

arqProjeto : arquivo

1..n1..n

1..n1..n

1..n1..n

SistemaTravagem

1..n1..n

1..n1..n

1..n1..n

Vedante-Rolamento

diametroExterior : DoublediametroInterior : DoubleExpessura : DoublenumRotacao : Integer

Motor

11

1..n1..n

1..n1..n

1..n1..n

1..n1..n

Caixa

11

Automovel

conceito

1..n1..n

1..n1..n

1..n1..n

11

1..n1..n

1..n1..n

11

11

11

Componentequantidade : IntegerpressaoTrabalho : Doublealimentacao : String = mecânica, elétrica

Direção

11

11

Sinônimo

descriçãoSinônimo : StringSinonimizavel

1..n1..n 1..n1..n

temTodas as classes, com excessão das subclasses herdam da classe Sinonimizavel. Nem todos os relacionamentos foram colocados para não dificultar a visualizaçãoe leitura do diagrama.

Especificação UMLde Ontologia “Carro” (ex.)

8


Modelos Dinâmicos: Incluindon Diagramas de Interacção (diagramas de Sequência e de Colaboração), n Diagramas de Estados e n Diagramas de Actividades

Casos: especificiação de acções que o sistema ou as classes executam quando interagem


• Modelos de implementação: como os modelos de componentes e diagramas de distribuição dessas componentes em diferentesplataformas


Extensões às representações UML com :n “packages” (pacotes)n “templates” (moldes)n Diagramas de Sequêncian Diagramas de Colaboraçãon Diagramas de Actividadesn Diagramas de Estados

Como extender UML para exprimir Protocolos de Interacçãoentre Agentes-PIA ( agent interaction protocols -AIP)?


9


n Diagramas de Interacção, n Diagramas de Sequência + Diagramas de SequênciaDefinem o Comportamento de Grupos de Objectos:

n Interacções básicas entre Objectos ao nível da invocação dos Métodos. Para cada caso específicon Não são apropriados para interacção social nos Sistemas Multi -Agente

n

n Diagramas de Estadosn Usados para modelar o comportamento do sistema total.Definem todos os Estados possíveis dos objectos e as transições dependentes das Mensagens. Para vários casosn Não apropriados para descrevêr comportamentos de Objectos Cooperantes



n Diagramas de Actividadesn Definem o curso dos acontecimentos eventos/acções

para diferentes objectos em diferentes casos

n São úteis para interacção social nos Sistemas Multi-Agente

n Não são necessárias alterações nem extensões


10


A especificação de um AIP serve como exemplo para ajudar na especificação e análise de um projecto

Usamos semântica formal e intuitiva e notação gráfica amigável.

Uma semântica precisa é importante no processo de Engenharia de Software


Extensão

Notação Gráfica fornece uma linguagem comum para a comunicação nos AIP

Exemplo:n Tipos de conecçõesn Linha de vida do Agente

divide-se em “threads”


Um AIP descreve um padrão de comunicação incluindo mensagenspermitidas entre agentes e as restrições impostas ao seu conteúdo

Fig. 1. Package (pacote) de um Template (molde) exprimindo um AIP

Cfpcfp

recusanão-entendido

proposta

tempolimite

aceitaproposta

rejeitapropostainforma

cancela

Decisão“x” = OUExclusivo


Protocolo

Rede de Contratos

11


UMLAirlines/Leilão:Vendedor

Participantes-Leilão:Consumidor

Início tempo cfp Cfp(initial price)

Início tempo cfp+1 minuto

Inform(start-auction , departure,arrival)

{m?0} not-understood (syntax error)

{m?0} not-understood (ontology)

Propose(price, departurearrival

Reject-proposal(wrong price)

Accept-proposal(correct-price)

Cfp(new-price)

1/ inform(endofauction, departure,arrival)

{0..1}[actual-price>=reserved price

2/request(pay-price)

cfp -2

AIP-Protocolo do Leilão Inglês para sobras de Bilhetes de Avião.

Diagramas de sequênciacombinados com a notação dos Diagramas de Estados

Leiloeiro apresenta preço inferior ao esperado no mercado e incrementa -o gradualmente.Quando todos desistem,Aúltima proposta é válida se > preço de reserva

k

1

1

1

1

1

1

1

k

k

k

k

k

k

k

Fig. 2. AIP p/ Leilão Inglês


Abordagem por Camadas (Níveis) à Especificação dos Protocolos

Figura 1 é um Diagrama de Sequência em UML do Protocolo RedeContractual.

O Protocolo é aqui visto como uma Entidade:A notação no canto superior esquerdo indica que o protocolo é uma “package” (agregação conceptual de uma sequência de interacções)


A caixa tracejada no canto superior direito exprime uma “pattern” (padrão) como a especificação de um “template ” (molde) identificando entidades na “package” (pacote) que necessitam ser definidas quando o “template ” da “package” for instanciada

12


O AIP considerado não especifica:

n Qual o procedimento do Iniciador para definir a CFP(Chamada a Propostas)n Qual o procedimento do Participante para gerar as Propostas

n Tais procedimentos podem detalhar o processo de Interacção através de Diagramas de Interacção, de Estados ou de Actividades

n O detalhe pode continuar a vários níveis (Fig3)



Fig3. Podem combinar-se Diagramas para exprimir com maior detalhe os Protocolos de Interacção


13


Cada nível pode exprimir actividades Inter e Intraagentes

Em conclusão, os exemplos ilustram:

n Um Protocolo (como um todo) é uma entidadea alto nível

n O Diagrama de Sequência descreve as transacções inter-agentes necessárias para implementar o protocolo

n Actividades intra-Agentes podem ser especificadas por Diagramas de Actividades(UML)



Nível 1 – Representar o Protocolo como um todo

n Patterns(Padrões) são conceitos úteis em um contexto e reutilizáveis noutros.

n Em UML quer “packages” quer “templates” expressam protocolos para reutilização


14


Fig4. Uso de “packages” para descrever protocolos encaixados(“nested”. Outros autores chamam “interleaved”)

Protocolos de Interacção entre Agentes podemser visualizados em termos conceptuais como naFig1 através do “envelope” no canto



Na Fig.4 temos dois “packages”:

• Compra (“Purchasing”) exprimindo um protocolosimples entre um Intermediário (“Broker”) e Retalhista (“Retailer”)

• Fornecimento(“Supplying”)


15


• Para certos produtos o retalhista pode fazer um pedido aogrossista (“Wholesaler”) sobre custos e disponibilidade do produto.

• Essa informação pode servir para a proposta a fazer ao “Broker”

• Podiamos ter um única package de “Purchasing”. Mas há packages “Purchasing” mais atómicas não necessitando dainteracção com o Grossista

• Melhor ter 2 Packages:• Compra (“Purchasing”)• Fornecimento(“Supplying”)



Na Fig4 o comportamento “Fornecimento” é utilizado como definido pela package “Fornecimento”

Para ser não só uma componente re-utilizável mas uma Packagemolde tem de poder ser “custumizável” (instanciada para o cliente)


Fig5 o Protocolo FIPA-Contract Net (Rede Contratual) é aplicado ao cenário de Vendedores-Compradores

Iniciador = CompradorParticipante = Vendedor

Cfp = seller-rfp

Recusa pode ser de dois tipos “Recusa-1” e “Recusa-2”

Existe uma “Deadline” específica para a resposta do vendedor

16


Fig. 5. Aplicação do template (molde) da Fig1 a um cenário particular com Vendedores e Compradores


AIP da Fig1 é um padrão:“custumizada”:Iniciador/Partcipante àComprador / Vendedor

CFP à seller-rfp2 tipos de recusa

Deadline explícita


Em UML a package AIP serve como Template (Molde)

Um Template é um modelo parametrizável em tempo de especificação (quando o novo modelo “custumizável” é produzido)

Na Fig1, a caixa tracejada indicava que a “Package” era um “Template” (Molde).

Os parâmetros a instanciar são divididos por linhashorizontais em 3 categorias:

Parâmetros de “papeis” (“role parameters”)RestriçõesActos de Comunicação


17


Fig. 6. Desenho da nova Package usando o Template da Fig1

A Fig5 foi o Molde (“Template”) resultante

Vendedor,

CompradorIniciador,

Participante

Deadline 8/8/99 12:00

CFP, Recusa, não-entendido,

Proposta,

Rejeição,

Aceitação,

Cancelar,

Informar

Seller-rfp, recusa-1, recusa-2,

Não-compreendido,

Proposta, rejeição, aceitação,

cancelar,

informar



Nível 2: representação das Interacções entre os Agentes

UML tem modelos dinâmicos úteis para a interacção

Diagramas de Interacção: capturam os padrões estruturais na interacção

Diagramas de Sequência: membro da família dos Diagramas de InteracçãoO formalismo gráfico enfatiza a sequência cronológicada comunicação


Nível 1 – Representar o Protocolo como um todo

18


Diagramas de Colaboração:

são outro membro dessa família.O formalismo gráfico enfatisa as associações entre Agentes

Diagramas de Actividade e Diagramas de Estados capturam o fluxodo processamento na comunidade dos Agentes



Fig. 7. Formato básico para a comunicação entre Agentes

Extensão do UML ao etiquetar a seta com o “acto de comunicação” do Agente (em vez do estilo de mensagensorientadas a Objectos)

Agente1/Papel:Classe Agente2/Papel:Classe

Actos de Comunicação

Diagramas de Sequência


19


Na Fig7 temos elementos básicos para a comunicação entre Agentes

Rectângulo exprime Agentes individuais ou conjuntos (Papeis ou classes) de Agentes

Ex: Agente individual Bob/Customer (Bob é uma instancia de Agente com o papel de Cliente.Bob podia ter o papel de fornecedor, empregado, dono de animais.

Bob: Person indica que independentemente do papel o Agente Bob é da classe Pessoa.

O formato da etiqueta do rectângulo é: nome-agente/papel:classe

Ex: Bob/Customer:PersonBob/Employee:Person



O formato nome-agente/Papel: Classe é análogo ao já usado pelo UML para objectos

Na especificação do Agente individual sublinha-se a etiqueta (Fig10)


O retângulo também pode especificar um conjunto de Agentes tendo um papel específico

Ex: Employee:PersonSupplier:PartnerNão é especificado nome para o Agente

20


Fig. 8 Algumas extensões recomendadas para suportar“fios-de-execução” (“threads”) de interacçãoconcorrentes

(a) Todos os “trheads” lançados em concorrência (E lógico)(b) Decisão sobre Qual dos “threads” (0 ou mais) serão lançados em concorrência (se >0, então OU inclusivo)(c) Decisão qual é o único “thread” selecionado para ser lançado (OU exclusivo)



Formalismos variados:

Na Fig9 usam-se as representações dos “threads” concorrentes da Fig8

As barras verticais indicam que os agentes receptores processam concorrentemente os “threads” de comunicação

(a) ou (b) é indiferente


21


Fig. 9. Multiplas técnicas expressando comunicaçãoconcorrente e agentes com múltiplos papeis ourespondendo a diferentes Actos de Comunicação (CAs)

Os CAs podem serenviados ao mesmo ou a diferentesAgentes


Fig. 10. Exemplo de Diagrama de Colaboração especificando a interacção entre agentes com múltiplos papeis (dimensão tempo

não existe)


B/Contractor

A/Costumer

C/CompetitorB/Competitor

Analyzer

C/Contractor2A/NegotiatorC/Contractor1

D/ContractorD/Debtor

Change Role

Change Role 2:Question

3:

1:1 Request 4:refuse

1:2Request5:Propose7: Commit

12:Assert+Request14: 13:Ship

8:Commit11:Ship

1:3Request

6:

9:Assert

10:Refuse

Change Role

22


Figura 10 é um exemplo de Diagrama de Colaboração

• Aqui os Agentes (retângulos) podem ser desenhados em qualquer posição no diagrama.

• Nos Diagramas de Sequência os Agentes estão numa linha horizontal no topo do diagrama

• No Diagrama de Colaboração a sequência das interacções é dada pela numeração nas linhas associando agentes.

Nos Diagramas de Interacção a sequência temporal é expressa numa leitura de cima para baixo

Os diagramas são graficamente semelhantes e semanticamente equivalentes

Na Fig. 10 o Diagrama de Colaboração exprime o mesmo significado que a Fig 11 com o Diagrama de Sequência



Fig. 11. Versão Diagrama de Sequência da Fig10


23



Fig.12Modelação de papeis representando cada nó “objecto” como uma classe de papeis


AIP- Protocolos de Interacção de Agentes podem requererespecificações claras da semântica das “threads” de processamento

Os Diagramas de Actividade exprimem as operações e oseventos que os despoletam


24


Na Fig.13um Protocolo para processar uma encomenda entre vários Agentes

Um evento “encomenda” activa o “Broker” (intermediário) para colocar a encomenda que é aceite por um Agente na Rede de Comércio Electrónico.Bom para Processamento concorrente e complexo


Agentes “Market Maker” e “Broker” passam a ser notificados sobre o negócio.

Diagrama de Actividades difere dos Diagramas de Interacção porque mostra uma linha de execução (thread) de controlo explícita.

Bom para Processamento concorrente e complexo


Diagramas de Actividade são similares à natureza das redesde Petri Coloridas porque:


1. Diagramas de Actividade são representação gráfica paravisualização de processos facilitando o projecto e a comunicaçãodos módulos comportamentais

2. Diagramas de Actividade podem representar Processosconcorrentes assíncronos

3. Diagramas de Actividade podem exprimir comunicaçõessimultâneas com vários correspondentes.

Redes de Petri a vêr mais tarde

25


A diferença principal entre os dois formalismos:• Diagramas de Actividade são baseados formalmente no modelo Máquina de Estados Extendida definida pelo UML

• Outros formalismos como BRIC (J.Ferber) extendem as Redes de Petri para descrever Sistemas baseados em Agentes, tal como o formalismo aqui apresentado (AUML)


Fig. 13. Diagrama de Actividades para um protocolo de venda de acçõesentre vários Agentes

Mercado tipo “spot”

Rede de Comércio Electrónico



Diagrama de Estados é um grafo representando uma Máquina de Estados.

Estados = rectângulos arredondadosTransições = arcos dirigidos entre estados

Na Fig. 14 exemplo de Diagrama de Estados para um protocolo de Encomenda.

26


Tecnologias de Negócio Electrónico• Encomenda está em Estado “requerido”, o agente fornecedor B compromete-se com a negociação requerida resultando numa transição para um estado de negociação “comprometido”.

•A acção de comprometimento depende da encomenda estar no estado “requerido”. Este estado tem outras 2 possíveis acções:

Fornecedor recusa ou o consumidor desiste.•Fornecedor pode recusar quando a encomenda está nos estados “proposto” ou “requerido”


Diagrama de Estados é “estado-centrico” e não agente ou processo-centricoDiagramas de Interacção são Agente-centricos

• Perspectiva Processo-centrico enfatiza o fluxo dos processos (pelosagentes) e a resultante mudança de estados (eventos) depois.• Perspectiva Estado-centrica enfatiza estados permitidos mais que o processo das transições.

Mas o Diagrama de estados mostra as restrições ao protocolo


Fig. 14. Diagrama de Estados com estados válidos para protocolo de Encomenda.

27


Nível 3: Representação do processamento interno do Agente

Tecnologias de Negócio ElectrónicoNível 1 – Representar o Protocolo como um todo

Nível 2: Representação das Interacções entre os Agentes

Fig. 15. Diagrama de Actividades especificando o comportamento de um Agente que satisfaz uma Encomenda. A Tracejado interfaces com Agentes externos

cliente Proc.encomenda Envio factura Recebe pagam.

Faz encomenda Pede factura

Pagamento recebidoCompleto

Encomenda aceite Encomenda enviadaEncomenda produzidaEncomendacompleta

AceitarEncomenda

ProduzirEncomenda

EnviarEncomenda

TerminarEncomenda

Fazer/enviarFactura

Processarpagamento

Pagamentoaceite



Diagramas de Actividade

• Na Fig. 15 o processo dentro do Agente que satisfaz Encomenda.

• O diagrama de sequência mostra o processo a ser despoletado por um acto de comunicação “Fazer Encomenda” e termina com o eventode “Encomenda completa”

• O processamento interno é expresso pelo Diagrama de Actividades onde o processador da Encomenda:

aceita, produz (ou junta), empacota e fecha a encomenda.

28



Diagramas de Actividade

• As caixas de operação ponteadas representam interfaces a processos de Agentes externos.

• Por exemplo: •Depois da produção/montagem da encomenda, ambas as acções (Encomenda Montada e Preparar/Enviar Factura) são disparadas em simultâneo.

• Só depois de “pagamento” aceite e Encomenda enviada, o processo Fecho de Encomenda pode ser invocado.


• O processo interno de um Agente pode também ser expresso por Diagramas de Estado

• A Fig.16 mostra os estados internos e as transições dos Agentes:

• Processador de Encomenda• Emissor de Factura• Receptor de Pagamentos

Como no anterior Diagrama de Actividades os Agentes tem interfaces entre eles (linhas tracejadas)


Diagrama de Estados

29



Figure 16. Diagrama de Estados especificando o comportamento de três agentesPara as actividades de processamento de Encomenda.

Processador de

Encomenda

Receptor

PagamentoEmissor Factura


CONCLUSÕES

Mecanismos de extensão baseados em UML fornecem formalismospara especificar interacção de agentes a vários níveis:

• Especificar protocolos como um todo;

• Exprimir padrões de interação entre Agentes por Protocolo;

• Expressar o comportamento interno a um Agente;

• Formalização da especificação dos Agentes e AIPs importantePara Especificação e Implementação de Sistemas de NegócioElectrónico


tecnologias de negócio electrónicoeol/tne/apont/auml_slides.pdf · 1 janeiro 2004 mei-leic /...

Documents