A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Frameworks Conceituais para SMA Equipe do Curso de ES para SMA {lucena, choren,

Apresentações semelhantes


Apresentação em tema: "Frameworks Conceituais para SMA Equipe do Curso de ES para SMA {lucena, choren,"— Transcrição da apresentação:

1 Frameworks Conceituais para SMA Equipe do Curso de ES para SMA {lucena, choren,

2 Laboratório de Engenharia de Software (LES) – PUC-Rio 2 Definições concept: "a general idea derived or inferred from specific instances or occurrences." framework: "a fundamental structure", "a set of assumptions, concepts, values, and practices that constitutes a way of viewing reality. [www.dictionary.com]

3 Laboratório de Engenharia de Software (LES) – PUC-Rio 3 Framework Conceitual para SMA Motivação: não existe uma definição comumente aceita sobre agentes. Objetivo: definir os conceitos relacionados a SMA e descrever os contextos nos quais estes conceitos são utilizados. Um framework conceitual para SMA deve definir as abstrações comumente encontradas em SMAs, suas propriedades, seus relacionamos, suas ações e suas interações.

4 Laboratório de Engenharia de Software (LES) – PUC-Rio 4 Alguns Frameworks Conceituais para SMAs TAO (Silva et al., 2003) d'Inverno e Luck (d'Inverno et al., 2001) Yu e Schmid (Yu et al., 1999), KAoS (Dardenne et al., 1993)

5 TAO

6 Laboratório de Engenharia de Software (LES) – PUC-Rio 6 Camada de meta-modelo Camada de modelo de domínio Camada de meta-meta-modelo Camada de instância MOF meta-meta-modelo ER meta-meta-modelo UML meta-modelo TAO meta-modelo instanciação UML modelos MAS modelos Arquitetura MOF de 4 camadas

7 Laboratório de Engenharia de Software (LES) – PUC-Rio 7 Arquitetura MOF de 4 camadas AgentOrganizationRole playownership User AgentMarketplaceBuyer play ownership Bob's AgentWal-Mart play ownership Conceptual Framework Conceptual Model Clothes Buyer Entity Relationship Entity Relationship Camada de meta-modelo Camada de modelo de domínio Camada de meta-meta- modelo Camada de instância

8 Laboratório de Engenharia de Software (LES) – PUC-Rio 8 Entidades e Relacionamentos Organização Agente Papel de Agente Papel de Objeto AmbienteObjeto inhabit ownership play ownership play specialization dependency aggregation association specialization control dependency aggregation association specialization association aggregation dependency association specialization association play association

9 Laboratório de Engenharia de Software (LES) – PUC-Rio 9 Entidades Toda entidade possui: –Propriedades = estado + comportamento –Relacionamentos Estado: informações sobre si mesma e sobre outras entidades Comportamento: conjunto de ações que pode executar Relacionamentos: define o contexto no qual duas entidades estão relacionadas

10 Laboratório de Engenharia de Software (LES) – PUC-Rio 10 Objeto Estado: atributos –não tem qualquer estrutura predefinida –armazena informações sobre si mesmo, sobre o ambiente e outros objetos em seus atributos Comportamento: métodos –define as operações que podem ser executadas –as operações podem modificar o estado do objeto Um objeto tem controle sobre seu estado

11 Laboratório de Engenharia de Software (LES) – PUC-Rio 11 Objeto Objeto tradicional: –não tem controle sobre seu comportamento, ou seja, faz tudo solicitado por outra entidade –não pode modificar seu comportamento Os objetos são entidades passivas que fazem tudo que qualquer um pedir e somente quando solicitado

12 Laboratório de Engenharia de Software (LES) – PUC-Rio 12 Agente Estado: –crenças, objetivos, planos e ações Crenças: conhecimento sobre o ambiente, sobre si mesmo e sobre outras entidades –O que o agente sabe, o que ele vê, suas memórias e suas percepções Objetivos: estados futuros ou desejos que o agente pretende alcançar ou satisfazer –Associados a pelo menos um plano que o agente executa para alcançar o objetivo

13 Laboratório de Engenharia de Software (LES) – PUC-Rio 13 Agente Plano: composto por ações –Está relacionado a um conjunto de objetivos que o agente pode alcançar ao executá-lo Ações: execuções do agente –Exemplo: mudar o estado mental, enviar e receber mensagens de outros agentes e chamar métodos de objetos Um agente é capaz de escolher um plano com base nos objetivos.

14 Laboratório de Engenharia de Software (LES) – PUC-Rio 14 Agente Comportamento: –expresso por meio de seus planos e ações –se baseia nas características do agente, por exemplo, interação, autonomia e adaptação Interação: agentes interagem com outras entidades Autonomia: agente é pró-ativo, não precisam de estímulos externos –os agentes são entidades orientadas a objetivos Adaptação: agente pode adaptar seu estado e seu comportamento

15 Laboratório de Engenharia de Software (LES) – PUC-Rio 15 Objeto X Agente Estado –Armazena o conhecimento sobre si mesmo e sobre outras entidades Comportamento –não possui controle sobre o comportamento –precisa de estímulos para executar –comportamento pré-definido Estado mental: estende o estado de objeto –Adiciona ao estado definição de comportamento Comportamento: estende o comportamento de objeto –possui total controle sobre seu comportamento (pode dizer não) –não precisam de estímulos externos ou internos para executar; –podem adaptar o comportamento

16 Laboratório de Engenharia de Software (LES) – PUC-Rio 16 Agente Objeto X Agente Agente é uma entidade ativa e objeto uma entidade passiva. + - autonomia Objeto pró-ativo reativo + - interação

17 Laboratório de Engenharia de Software (LES) – PUC-Rio 17 Objeto Ativo XAgente Comportamento: –Comportamento pré-definido Interativo Até certo grau autônomo –Possui sua própria thread –Começa a executar sem estímulos externos –Atende a todas as solicitações de outras entidades Comportamento: –Pode adaptar o seu comportamento Interativo Autônomo –Possui sua própria thread –Executa sem estímulos externos –Pode dizer não às solicitações de outras entidades

18 Laboratório de Engenharia de Software (LES) – PUC-Rio 18 Ambiente É o habitat de agentes, organizações e objetos –eles não podem residir em mais de um ambiente ao mesmo tempo. Estado e o comportamento são definidos com base na característica Pode ser uma entidade passiva, como um objeto, ou pode ser uma entidade ativa, como um agente

19 Laboratório de Engenharia de Software (LES) – PUC-Rio 19 Ambiente Ambiente modelado como uma classe de objeto possui –métodos e atributos Ambiente modelado como um agente possuem –crenças, objetivos, ações e planos iniciais.

20 Laboratório de Engenharia de Software (LES) – PUC-Rio 20 Organização Organizações agrupam os agentes de um SMA Organização = grupo = comunidades = sociedades Pode definir sub-organizações, axiomas e papéis Sub-organizações: –organizações que desempenham papéis em uma organização

21 Laboratório de Engenharia de Software (LES) – PUC-Rio 21 Organização Papéis: –São desempenhados por agentes, objetos e sub- organizações dentro de uma organização Axioma: –regra, lei ou princípio estabelecido. –restrições globais da organização às quais os agentes e as sub-organizações devem obedecer. Axioma = regra = lei = norma

22 Laboratório de Engenharia de Software (LES) – PUC-Rio 22 Organização Uma organização estende um agente Estado: –crenças, objetivos, ações, planos e axiomas Comportamento: –ações e planos executados pela organização + –ações e planos executados pelos agentes e sub- organizações.

23 Laboratório de Engenharia de Software (LES) – PUC-Rio 23 Papéis Duas propriedades mais importantes: –São definidos no contexto de uma organização –Uma instância de papel deve ser exercida por um agente, por um objeto ou por uma sub-organização. Orienta e também restringe o comportamento de instâncias que exercem o papel.

24 Laboratório de Engenharia de Software (LES) – PUC-Rio 24 Papel de Objeto Descreve um conjunto de características que são vistas por entidades que usam o objeto Orienta o comportamento de objetos porque os objetos agem de acordo com chamadas feitas pelo papel Restringir o acesso ao objeto limitando as informações e o comportamento que outras entidades podem acessar

25 Laboratório de Engenharia de Software (LES) – PUC-Rio 25 Papel de Objeto Pode também adicionar informações (atributos) e comportamento (métodos) ao objeto que exerce o papel. Estado: atributos –mantém as informações Comportamento: métodos –são as operações

26 Laboratório de Engenharia de Software (LES) – PUC-Rio 26 Papel de Objeto Objeto atributo 1 atributo 2 método 1 método 2 Papel de Objeto atributo 1 método 1 método 3 Entidade B Entidade A

27 Laboratório de Engenharia de Software (LES) – PUC-Rio 27 Papel de Objeto Objeto atributo 1 atributo 2 método 1 método 2 Papel de Objeto atributo 1 método 1 método 3 Entidade B Entidade A

28 Laboratório de Engenharia de Software (LES) – PUC-Rio 28 Papel de Objeto Um objeto não tem consciência do papel que está exercendo O papel de objeto é que sabe a qual objeto está associado Todas as instâncias de papel de objeto são um membro de uma organização e são exercidas por um objeto

29 Laboratório de Engenharia de Software (LES) – PUC-Rio 29 Papel de Agente Orienta o comportamento de um agente descrevendo seus objetivos ao exercer o papel Restringe o comportamento definindo as ações que o agente deve exercer (deveres) e as ações que pode executar (direito) ao exercer o papel Pode adicionar novos objetivos e crenças ao agente Um agente e uma organização desempenham pelo menos um papel

30 Laboratório de Engenharia de Software (LES) – PUC-Rio 30 Papel de Agente Estado: –crenças e objetivos. Os objetivos dos papéis caracterizam os objetivos que um agente deve alcançar enquanto exerce o papel Comportamento: –deveres, direitos e protocolos

31 Laboratório de Engenharia de Software (LES) – PUC-Rio 31 Papel de Agente Deveres (ou obrigações) identificam as ações atribuídas ao agente que está exercendo o papel, ou seja, as responsabilidades Direitos (ou qualificações) identificam as ações que o agente pode executar ao exercer o papel, isto é, eles descrevem as permissões associadas às ações Protocolos definem as interações entre papéis por meio da especificação das mensagens

32 Laboratório de Engenharia de Software (LES) – PUC-Rio 32 Relacionamentos Inhabit: –especifica que a instância de entidade que reside – o cidadão – é criada e destruída no habitat e, portanto, pode entrar e sair dele, respeitando suas permissões –um cidadão não pode residir em dois habitats ao mesmo tempo –o habitat conhece todos os cidadãos que residem nele, e cada cidadão conhece seu habitat –Aplicabilidade: ambientes e agentes, ambientes e objetos e ambientes e organizações

33 Laboratório de Engenharia de Software (LES) – PUC-Rio 33 Relacionamentos Ownership: –Especifica que uma entidade – o membro – é definida no escopo de outra entidade – o proprietário – e que um membro deve obedecer a um conjunto de restrições globais definidas pelo proprietário –O membro não existe fora do escopo de seu proprietário –Os proprietários conhecem seus membros, e cada membro conhece seu proprietário –Aplicabilidade: classes de papel – os membros – e às classes de organização – os proprietários

34 Laboratório de Engenharia de Software (LES) – PUC-Rio 34 Relacionamentos Ownership: –Uma instância de papel (papel do agente ou papel de objeto) só pode ser exercida por entidades na organização que definiu o papel –A organização define quem exerce os papéis identificados –A organização define qual papel pode ser exercido por uma entidade

35 Laboratório de Engenharia de Software (LES) – PUC-Rio 35 Relacionamentos Play: –Especifica que uma entidade está relacionada a um papel –Os agentes e as organizações interagem por meio dos papéis que exercem –Os relacionamentos entre agentes, entre agentes e organizações e entre organizações são indiretamente definidos pelos papéis que estão exercendo –Quando um objeto está exercendo um papel, as entidades interagem com o objeto por meio de seu papel –Aplicabilidade: entre papel de agente e agente, papel de agente e sub-organização, papel de objeto e objeto

36 Laboratório de Engenharia de Software (LES) – PUC-Rio 36 Relacionamentos Specialization/Generalization: –Define que a sub-entidade que especializa a super- entidade herda as propriedades e os relacionamentos definidos na super-entidade –As propriedades herdadas também podem ser redefinidas pela sub-entidade –A sub-entidade também pode definir novas propriedades e novos relacionamentos –Aplicabilidade: todas as entidades

37 Laboratório de Engenharia de Software (LES) – PUC-Rio 37 Relacionamentos Control: –Define que a entidade controlada deve fazer tudo que a entidade do controlador pedir –A entidade controlador conhece as entidades controladas, e cada entidade controlada conhece as entidades que a controlam –As entidades controladas e do controlador serão os agentes ou as organizações que estão exercendo os papéis –Aplicabilidade: entre dois papéis do agente

38 Laboratório de Engenharia de Software (LES) – PUC-Rio 38 Relacionamentos Dependency: –Define que uma entidade – o cliente – pode ser definida para depender de outra – o fornecedor – para realizar seu trabalho –Especifica que uma alteração na especificação do fornecedor pode afetar o cliente, mas não necessariamente o contrário –O cliente sempre conhece seus fornecedores, mas o contrário pode não ser verdadeiro –Aplicabilidade: entre papéis de agente, entre papéis de objeto e entre papel de agente e papel de objeto,

39 Laboratório de Engenharia de Software (LES) – PUC-Rio 39 Relacionamentos Association: –Especifica um relacionamento de semântica que pode ocorrer entre instâncias –Se uma entidade estiver associada à outra entidade, ela saberá da existência da outra entidade e, então, poderá interagir com ela –Aplicabilidade: entre papéis (papéis de objeto e papéis de agente), ambientes, agentes e objetos, organizações e objetos, e papéis e objetos

40 Laboratório de Engenharia de Software (LES) – PUC-Rio 40 Relacionamentos Aggregation: –Define a entidade que é o agregador e a entidade que é a parte. –Se uma entidade estiver agregada a outra, dizemos que ela é o agregador de partes. –O agregador pode usar a funcionalidade disponível em suas partes para realizar seu trabalho. –Aplicabilidade: entre papéis de objeto e entre papéis do agente.

41 Laboratório de Engenharia de Software (LES) – PUC-Rio 41 Sistema Multi-Agentes Ambiente Sistema Multi-Agentes agente Organização principal objeto

42 Laboratório de Engenharia de Software (LES) – PUC-Rio 42 Sistema Multi-Agentes Ambiente Sistema Multi-Agentes agente Organização principal objeto Organização principal Papel de agente Papel de objeto

43 Laboratório de Engenharia de Software (LES) – PUC-Rio 43 Organização principal Sistema Multi-Agentes Ambiente agente Organização principal objeto Sub-Organização

44 Laboratório de Engenharia de Software (LES) – PUC-Rio 44 Organização principal Sistema Multi-Agentes Ambiente agente Organização principal objeto Sub-Organização Papel de agente Papel de objeto

45 Laboratório de Engenharia de Software (LES) – PUC-Rio 45 Comportamento das Entidades Análise do comportamento independente do domínio da aplicação Criação das entidades Destruição das entidades Interação entre as entidades –Agentes e sub-organizações interagindo com organizações –Agentes e sub-organizações interagindo com ambientes

46 Laboratório de Engenharia de Software (LES) – PUC-Rio 46 Criação das entidades Criação de papel de agente –A criação ocorre quando um agente ou sub-organização se compromete com o papel. –Condição: existência de um agente ou uma sub- organização para exercer o papel –Criador: organização

47 Laboratório de Engenharia de Software (LES) – PUC-Rio 47 Criação das entidades Criação do agente –Um papel deve ser imediatamente criado e associado ao agente –Condição: existência de uma organização –Criador: outro agente, uma organização ou um ambiente

48 Laboratório de Engenharia de Software (LES) – PUC-Rio 48 Criação das entidades Criação de organização –Se a organização sendo criada é uma sub-organização, uma instância de papel deve ser criada e associada à sub- organização –Condição: existência do ambiente –Criador de organização principal: ambiente –Criador de sub-organizações: agente, (sub-)organização ou ambiente

49 Laboratório de Engenharia de Software (LES) – PUC-Rio 49 Criação das entidades Criação de papel de objeto –Criado quando uma entidade (o criador) deseja acessar um objeto em uma organização que restringe a visão do objeto. –Deve ser associado a um objeto –Condição: existência do objeto –Criador: agentes e organizações

50 Laboratório de Engenharia de Software (LES) – PUC-Rio 50 Criação das entidades Criação de objetos –Condição: existência do ambiente –Criador: agentes, organizações, objetos e ambientes –Não depende do papel

51 Laboratório de Engenharia de Software (LES) – PUC-Rio 51 Criação das entidades Criação de ambiente –O ambiente deve ser criado antes de outras entidades porque elas residem no ambiente. –Condição: -- –Criador: máquina virtual do sistema, outro ambiente, agentes ou organizações que residem em outro ambiente.

52 Laboratório de Engenharia de Software (LES) – PUC-Rio 52 Destruição das entidades Destruição de papel do agente –Um papel exercido por um agente ou sub-organização é destruído quando este o cancela –Condição: -- –Destruidor: agente ou organização. O destruidor é quem está exercendo o papel –Conseqüência: se um agente (ou sub-organização) possui todos os seus papéis destruídos, isso significa que o agente (ou sub-organização) também será destruído

53 Laboratório de Engenharia de Software (LES) – PUC-Rio 53 Destruição das entidades Destruição de agente –Condição: todos os papéis do agente devem ter sido destruídos. –Destruidor: si mesmo, outro agente, organização ou ambiente.

54 Laboratório de Engenharia de Software (LES) – PUC-Rio 54 Destruição das entidades Destruição de organização –Condição (1): todos os papéis exercidos por agentes, objetos e sub-organizações devem ser destruídos –Condição (2): todos os papéis exercidos pela organização também devem ser destruídos –Destruidor: si mesmas, por ambientes, outras organizações ou agentes que residam em outras organizações. –Processo recursivo: todas as suas sub-organizações devem ser destruídas ou devem deixar a organização.

55 Laboratório de Engenharia de Software (LES) – PUC-Rio 55 Destruição das entidades Destruição de papel de objeto –Condição: -- –Destruidor: agente ou organização

56 Laboratório de Engenharia de Software (LES) – PUC-Rio 56 Destruição das entidades Destruição de objeto –Condição: todos os papéis do objeto devem ter sido destruídos –Destruidor: objetos, agentes, organizações e ambientes

57 Laboratório de Engenharia de Software (LES) – PUC-Rio 57 Destruição das entidades Destruição de ambiente –Condição: todas as entidades foram destruídas –Destruidor: si mesmo, por outro ambiente, por um agente ou por uma organização que reside em outro ambiente.

58 Laboratório de Engenharia de Software (LES) – PUC-Rio 58 Estados de um papel de agente Criado Ativo Destruído Inativo compromisso criado compromisso criado compromisso cancelado execução suspensa execução reiniciada

59 Laboratório de Engenharia de Software (LES) – PUC-Rio 59 Interação entre as entidades Relacionamentos ownership e play Agente ou sub-organização entrando em organização –Agente ou sub-organização se comprometendo com um papel ou ativando o papel Agente ou sub-organização saindo de organização –Agente ou sub-organização cancelando um papel ou desativando o papel

60 Laboratório de Engenharia de Software (LES) – PUC-Rio 60 Agente (ou sub-organização) se comprometendo com papel (em uma nova organização) 1.Agente procurar por uma organização no ambiente Decide qual organização com base nos seus objetivos e nos objetivos da organização 2.Agente pergunta a organização os papéis disponíveis 3.Organização informa o conjunto de papéis disponíveis de acordo com sua função de utilizada ou suas políticas

61 Laboratório de Engenharia de Software (LES) – PUC-Rio 61 Agente (ou sub-organização) se comprometendo com papel (em uma nova organização) 4.Agente avalia qual papel deseja desempenhar e informa a organização Verificação com base nos seus objetivos 5.Organização pode permitir ou negar 6.Se a org. permitir, o agente se compromete a desempenhar o papel O agente concorda em respeitar os deveres e os direitos do papel e concorda em tentar atingir a meta do papel

62 Laboratório de Engenharia de Software (LES) – PUC-Rio 62 Agente (ou sub-organização) se comprometendo com papel (em uma organização onde já desempenha outros papéis ) Similar ao anterior, porém agente não precisa procurar a organização no ambiente 1.Agente pergunta a organização os papéis disponíveis 2.Organização informa o conjunto de papéis disponíveis 4.Agente avalia qual papel deseja desempenhar e informa a organização 5.Organização pode permitir ou negar 6.Se a org. permitir, o agente se compromete a desempenhar o papel

63 Laboratório de Engenharia de Software (LES) – PUC-Rio 63 Agente (ou sub-organização) ativando um papel 1.Agente pergunta a organização se pode ativar papel 2.Organização informa se pode ou não organização pode definir axiomas para restringir a ativação de papéis Note que para a ativação de uma papel não importa se o agente está ou não desempenhando outro papel na mesma organização

64 Laboratório de Engenharia de Software (LES) – PUC-Rio 64 Agente (ou sub-organização) cancelando ou desativando um papel 1.Agente (ou sub-organização) checa se pode parar de desempenhar um papel (cancelar ou desativar) –Organização pode impedir Observação: –Se um agente cancelar seu único papel então ele deve ser destruído ou deve se comprometer com outro papel.

65 Laboratório de Engenharia de Software (LES) – PUC-Rio 65 Interação entre as entidades Relacionamento inhabit Agente (ou sub-organização) se movendo de um ambiente para outro –Para sair de um ambiente: agente ou sub-organização cancelam ou desativam todos os seus papéis nas organizações do ambiente –Para entrar em ambiente: agente ou sub-organização criam ou ativam pelo menos um papel em uma organização do ambiente

66 Laboratório de Engenharia de Software (LES) – PUC-Rio 66 Agente (ou sub-organização) se movendo de um ambiente para outro 1.Descobrir outro ambiente para o qual quer se mover 2.Pedir permissão para sair do ambiente onde está 3.Pedir permissão para entrar no outro ambiente 4.Cancelar / desativar todos os papéis 5.Ativar / criar pelo menos um papel Observação: Mobilidade de sub-organizações –Agentes e outras sub-organizações que desempenham papéis dentro da sub-organização que quer se mover devem parar de desempenhar tais papéis

67 Laboratório de Engenharia de Software (LES) – PUC-Rio 67 Saindo de um ambiente Entrando em um ambiente Agente (ou sub-organização) se movendo de um ambiente para outro Movendo de um ambiente para outro Saindo de uma organização Entrando em uma organização

68 Framework Conceitual de d'Inverno e Luck

69 Laboratório de Engenharia de Software (LES) – PUC-Rio 69 Framework Conceitual de d'Inverno e Luck Propõem uma hierarquia em quatro camadas –O ambiente consiste de entidades das quais algumas são objetos –Do conjunto de objetos, algumas são agentes, e dos agentes alguns são agentes autônomos. Entidades

70 Laboratório de Engenharia de Software (LES) – PUC-Rio 70 Entidade e Ambiente Entidade e ambiente: –Coleção de atributos

71 Laboratório de Engenharia de Software (LES) – PUC-Rio 71 Objeto Entidade com conjunto de capacidades Capacidade: –conjunto de ações que podem ser desempenhadas pelo objeto Ação: –muda o estado do ambiente (sub-conjunto de capacidades)

72 Laboratório de Engenharia de Software (LES) – PUC-Rio 72 Objeto Seleção de ações: –baseada no estado do ambiente e no estado objeto Estado: –estado do ambiente + ações Operação: –indica qual é alteração do estado do objeto dado a execução de uma ação –Podem mudar: estado do ambiente e a próxima ação –Não mudam: atributos, capacidades e função de seleção das ações

73 Laboratório de Engenharia de Software (LES) – PUC-Rio 73 Agente Objeto com metas Metas: (conjunto de atributos) –estado a ser atingido no ambiente

74 Laboratório de Engenharia de Software (LES) – PUC-Rio 74 Agente Percepção possível: –o que o agente pode enxergar do ambiente Percepção atual: –o que o agente realmente enxerga do ambiente Ações de percepção: –que possibilitam a percepção do ambiente

75 Laboratório de Engenharia de Software (LES) – PUC-Rio 75 Agente Seleção de ações: –baseada no estado do ambiente, nas percepções atuais e nas metas Estado: –estado do objeto + ações do agente + percepções atuais + percepções possíveis

76 Laboratório de Engenharia de Software (LES) – PUC-Rio 76 Agente Operação: –indica qual é alteração no estado do agente dado a execução de uma ação –Podem mudar: percepções possíveis, percepções atuais e a próxima ação –Não mudam: atributos, capacidades, metas, ações de percepção e função de seleção das ações e percepções

77 Laboratório de Engenharia de Software (LES) – PUC-Rio 77 Agente Autônomo Agente com motivação Motivação: –Possibilidade de gera suas próprias metas Também define percepções, ações e estado

78 Laboratório de Engenharia de Software (LES) – PUC-Rio 78 Descrição das entidades Agentes satisfazem metas Agentes autônomos, adicionalmente, criam metas Server-agents –Agentes que não são autônomos Neutral-objects: –Objetos que não são agentes

79 Laboratório de Engenharia de Software (LES) – PUC-Rio 79 SMA e Sociedade de agentes Sistema Multi-Agentes: –É composto por dois ou mais agentes –Tem pelo menos um agente autônomo (que tem a(s) meta(s)) –Existe pelo menos um relacionamento entre dois agentes onde um satisfaz a meta do outro Sociedade de agentes: conjunto de entidades e conjunto de relacionamentos em um SMA

80 Laboratório de Engenharia de Software (LES) – PUC-Rio 80 Relacionamentos Agentes adotam as metas de outros agentes Relacionamentos são definidos com base na adoção de metas. Engagement: quando um server-agent adota a meta de outro agente –server-agents são obrigados a adotarem uma meta de um agente autônomo Cooperação: quando um agente autônomo adota a meta de outro agente –um agente autônomo não é obrigado a adotar a meta de outro

81 Framework Conceitual de Yu e Schmid

82 Laboratório de Engenharia de Software (LES) – PUC-Rio 82 Framework Conceitual de Yu e Schmid Se baseia em workflows Workflows são usados para descrever a coordenação e a performance do trabalho dentro de uma organização Workflows são modelados como um conjunto de papéis relacionados Um agente é uma entidade ativa desempenhando papéis dentro de uma organização

83 Laboratório de Engenharia de Software (LES) – PUC-Rio 83 Papéis São descritos como uma coleção de deveres e permissões Deveres: ações que os agente são obrigados a executar quando desempenham o papel Permissões: ações que os agentes podem executar quando desempenham o papel

84 Laboratório de Engenharia de Software (LES) – PUC-Rio 84 Papéis... : precondições para atingir os goals AUTHORIZE COOPERATE_WITH IS_AUTHORIZED_BY : ordem de execução das obrigações

85 Laboratório de Engenharia de Software (LES) – PUC-Rio 85 Arquitetura Conceitual

86 Laboratório de Engenharia de Software (LES) – PUC-Rio 86 Uma Abordagem para o Desenvolvimento de SMA 1.Fase de Análise baseada nos Papéis 1.Identificação e decomposição de metas 2.Especificação de papéis 3.Modelagem de protocolos 2.Fase de Design orientada a Agentes 1.Identificação de tipos de agentes e associação de papéis a agentes 2.Definição dos agentes 3.Fase de Implementação orientada a Agentes

87 KAoS Framework Conceitual

88 Laboratório de Engenharia de Software (LES) – PUC-Rio 88 KAoS : Knowledge Acquisition in autOmated Specification Levantamento de requisitos orientados a meta Meta-modelo conceitual: –Nível meta –Nível de domínio –Nível de instância O meta-modelo conceitual define a estrutura da linguagem utilizada no levantamento dos requisitos

89 Laboratório de Engenharia de Software (LES) – PUC-Rio 89 KAoS

90 Laboratório de Engenharia de Software (LES) – PUC-Rio 90 Meta-modelo conceitual Nível meta: refere-se as abstrações independentes do domínio –Meta-conceitos (ex.: Agent) –Meta-relationamentos que ligam os meta-conceitos –Meta-atributos de meta-conceitos e meta- relacionamentos –Meta-restrições sobre meta-conceitos e meta- relacionamentos

91 Laboratório de Engenharia de Software (LES) – PUC-Rio 91 Meta-modelo conceitual Nível de domínio: refere-se aos conceitos específicos do domínio da aplicação –Conceito (ex.: Borrower) –Relacionamento –Atributos –Restrições Nível de instância: refere-se a específicas instâncias do conceitos do nível de domínio –Instância de Conceito (ex.: Steve) –Instância de Relacionamento –Instância de Atributos e Instâncias de Restrições

92 Laboratório de Engenharia de Software (LES) – PUC-Rio 92

93 Laboratório de Engenharia de Software (LES) – PUC-Rio 93 Objeto (Object) Objeto é uma coisa de interesse à qual se pode referir nos requisitos Instância muda de estado (devido a aplicações de ações) Meta-atributos (além do nome e da definição) : –Existe: verdadeiro se a instância existe no estado corrente –Invariante: descreve restrições em cima do objeto

94 Laboratório de Engenharia de Software (LES) – PUC-Rio 94 Entidade (Entity) Entidade é um objeto autônomo, isto é, suas instâncias podem existir independentemente de outras instâncias de outros objetos. Meta-atributos: não adiciona nenhum atributo além daqueles previamente definidos no conceito Objeto

95 Laboratório de Engenharia de Software (LES) – PUC-Rio 95 Relacionamento (Relationship) Relacionamento é um objeto subordinado, isto é, a existência de uma instância depende da existência de instâncias de objetos ligadas pelo relacionamento Meta-relacionamento com Objeto: –Link: todo relacionamento esta ligado a objetos Meta-atributo de Link: –Papel: papel das instâncias de objeto no relacionamento –Cardinalidade: cardinalidade das instâncias de objeto no relacionamento

96 Laboratório de Engenharia de Software (LES) – PUC-Rio 96 Evento (Event) Evento é um objeto instantâneo, isto é, sua instância existe em um dado estado apenas. Meta-atributo: –Freqüência: freqüência com a qual o evento aparece

97 Laboratório de Engenharia de Software (LES) – PUC-Rio 97 Ação (Action) Ação é uma relação matemática em cima de um objeto. –Muda o estado do objeto Meta-atributos: –Precondições: dado necessários para aplicação da ação –Condição de disparo: dados que disparam a ação –Pós-condições: dados que descrevem o efeito da aplicação da ação

98 Laboratório de Engenharia de Software (LES) – PUC-Rio 98 Agente (Agent) Agente é um objeto que é um processador de ações. Agentes controlam as transições de estado Agentes possuem alternativa aos seus comportamentos (em oposto aos outros objetos que não possuem) Meta-atributo: –Load: taxa de ocupação do agente

99 Laboratório de Engenharia de Software (LES) – PUC-Rio 99 Agente Meta-relacionamentos com Ação: –Capacidade: pode executar a ação –Executa: é um processador alocado a executar a ação Meta-relacionamento com Objeto: –Conhece: os estados dos objetos são observáveis pelo agente Um agente pode conhecer outro agente Meta-atributo de Conhece: –Interface: Forma como o agente acessa outro objeto

100 Laboratório de Engenharia de Software (LES) – PUC-Rio 100 Meta (Goal) Meta é um objetivo não operacional a ser atingido por um sistema Não operacional –a meta não é formulada em termos de objetos e ações disponíveis para um determinado agente no sistema –a meta quando formulada não pode ser estabelecida através de transições de estado controlada por um agente

101 Laboratório de Engenharia de Software (LES) – PUC-Rio 101 Meta Taxonomia de metas: usada para descrever metas e possibilita o reuso e a verificação Padrões de metas: –Atingir, descontinuar, manter, evitar e otimizar Categoria de metas: –Metas de sistemas e metas privadas Meta-atributo: –Prioridade: descreve a prioridade da meta

102 Laboratório de Engenharia de Software (LES) – PUC-Rio 102 Meta Meta-relacionamento com Objeto: –Concerns: liga a meta aos objetos aos quais ela se refere Meta-relacionamentos entre Metas: –Redução: liga uma meta e as suas sub-metas –Conflito: liga uma meta e outras as quais possui conflito Meta-relacionamento com Agente: –Desejo: introduzido entre um agente e uma meta

103 Laboratório de Engenharia de Software (LES) – PUC-Rio 103 Restrição (Constrain) Restrição é um objetivo operacional a ser atingido pelo sistema. Operacional –a restrição é formulada em termos de objetos e ações disponíveis para um agente no sistema Metas são operacionalizadas através de restrições

104 Laboratório de Engenharia de Software (LES) – PUC-Rio 104 Restrição Meta-relacionamento com Meta: –Operacionalização: a restrição R é uma das formas para atingir a meta M. –Uma meta pode ser operacionalizada através de várias restrições Meta-relacionamento com Ação: –Assegurar: mesmo com a aplicação da ação a restrição será mantida Meta-relacionamento com Objetivo: –Assegurar: mesmo que ocorra qualquer ação no objeto a restrição será mantida

105 Laboratório de Engenharia de Software (LES) – PUC-Rio 105 Restrição Meta-relacionamento com Agente: –Responsabilidade: agente é responsável por garantir a restrição

106 Laboratório de Engenharia de Software (LES) – PUC-Rio 106 Estratégia de Levantamento de Requisitos Estratégia orientada a metas: 1.Definição das metas (e a estrutura destas) e identificação dos objetos 2.Identificação dos agentes em potencial e suas capacidades 3.Operacionalização das metas em restrições Relação entre as metas e os objetos e ações de um agente 4.Refinamento dos objetos e das ações Identificação de novos objetos e ações decorrente da etapa 3

107 Laboratório de Engenharia de Software (LES) – PUC-Rio 107 Estratégia de Levantamento de Requisitos 5.Revisão dos objetos e ações para garantir as restrições Descrições de ações e objetos completos no passo 4 podem não necessariamente garantir que as restrições do passo 3 sejam garantidas 6.Identificação de responsabilidades alternativas Ligação dos agentes às restrições de acordo com suas responsabilidades 7.Associação de ações à agentes responsáveis

108 Laboratório de Engenharia de Software (LES) – PUC-Rio 108 Referências Dardenne, A.; Lamsweerde, A.; Fickas, S. (1993) "Goal-directed Requirements Acquisition." Science of Computer Programming. v.20, p d'Inverno, M.; Luck, M. (2001) "Understanding Agent Systems". New York: Springer, Luck, M.; d'Inverno, M. A conceptual framework for agent definition and development. The Computer Journal, 44(1):1--20, Yu, L.; Schmid, B. A Conceptual Framework for Agent-Oriented and Role- Based Work on Modeling. In: WAGNER, G.; YU, E. (Eds.). Proceedings of the 1st International Workshop on Agent-Oriented Information Systems, Silva, V.; Garcia, A.; Brandao, A.; Chavez, C.; Lucena, C.; Alencar, P. Taming Agents and Objects in Software Engineering In: Garcia, A.; Lucena, C.; Zamboneli, F.; Omicini, A; Castro, J. (Eds.), Software Engineering for Large- Scale Multi-Agent Systems, Springer-Verlag, LNCS 2603, pp. 1-26, 2003.


Carregar ppt "Frameworks Conceituais para SMA Equipe do Curso de ES para SMA {lucena, choren,"

Apresentações semelhantes


Anúncios Google