Metodologias
Viviane Torres da Silva
[email protected]
http://www.ic.uff.br/~viviane.silva/isma
Metodologias

Motivação: o desenvolvimento de SMA é diferente devido as características das
entidades
– Como descobrir quais são os agentes do sistema?
– Como definir as tarefas que serão executadas por cada agente?

Objetivo: dar suporte ao desenvolvimento de SMA desde a análise dos requisitos até
a implementação do sistema

Solução: metodologias para SMA
– Tropos, Prometheus, Gaia, Message, MaSE
Tropos
Tropos

Objetivo: fazer o desenvolvimento de SMA orientado a
requisitos

Está baseada no framework de modelagem para a análise de
requisitos chamado i*
– Conceitos: ator, agente, posição e papel
– Dependências entre atores: objetivo, objetivo-suave, tarefa e recurso
Etapas da Metodologia Tropos
Análise de requisitos
 Etapa 1 de requisitos
– Entender o problema estudando-se as organizações que já existem
– Resultado: modelagem organizacional com atores e seus objetivos

Etapa 2 de requisitos
– Se adiciona o ator sistema a modelagem
– Descrição do sistema através de suas funções
(requisitos funcionais e não funcionais)
Etapas da Metodologia Tropos
Projeto
 Etapa de Projeto Arquitetural
– Descrição dos subsistemas que são representados como atores
– Mapeamento do ator sistema para um conjunto de agentes e suas
capacidades

Etapa de Projeto Detalhado
– Definição das capacidades dos agentes e suas interações
– Definição dos dados de entrada e saída dos subsistemas
Etapas da Metodologia Tropos
Implementação
 Etapa de Implementação
– Mapeamento dos conceitos do projeto detalhado aos conceitos da
plataforma
– Propõe o uso de Jack, uma plataforma para a implementação de SMA
Elementos Definidos pela Metodologia

Ator
– Entidade que tem objetivos e intenções
– Representa um agente físico, um agente de software, um papel ou uma
posição

Agente
– Software que tem propriedade autônoma, social, reativa e proativa.

Papel
– Define o comportamento de atores em um determinado contexto

Posição (≈ Organização)
– Representa um conjunto de papéis que costumam ser desempenhados
por um agente

Recurso
– Entidade física ou de informação
Elementos Definidos pela Metodologia

Objetivo
– Estado futuro que o ator quer alcançar (sua intenção)

Objetivo-suave (soft-goal)
– É difícil ou impossível afirmar que foi alcançado
– Utilizado para modelar os requisitos não funcionais

Plano
– Maneira de fazer determinada coisa
– Sua execução alcança um objetivo ou um objetivo-suave

Capacidade
– Habilidade do ator em definir, eleger ou executar um plano para
alcançar um objetivo

Crença
– Conhecimento sobre o mundo
Elementos Definidos pela Metodologia

Dependência
– Relação entre atores para alcançar um objetivo, executar um plano ou
partilhar um recurso

Tipos de dependência:
– Objetivo ou objetivo-suave: um agente delega a outro seu objetivo
– Tarefa: o outro agente tem que executar a tarefa
– Recurso: o outro agente tem que prover um recurso
Etapa 1 de Requisitos
Os diagramas desta etapa são:
 Modelagem de dependências (Strategic Dependence Model):
– modela os atores, seus objetivos e suas dependências

Modelagem de raciocínio (Strategic Rational Model):
– modela como os objetivos de um ator podem ser alcançados através da
contribuição de outros atores
– Link de decomposição:
• uma tarefa pode ser dividida em outras tarefas, em objetivos, ou em
objetivos-suaves.
• um objetivo-suave pode ser dividido em outros objetivos-suaves ou em
tarefas
– Link de realização: um objetivo é alcançado quando uma tarefa é
realizada
Exemplo: Projeto MediaShop
Modelagem de Dependências
tarefas
objetivo
ator
objetivo-suave
recursos
Link de realização
Exemplo
Tarefa
principal
Modelagem
do Raciocínio
Link de decomposição
Etapa 2 de Requisitos
Os diagramas desta etapa são gerados a partir da revisão dos
diagramas da etapa anterior:
 Incluir a modelagem de dependências um ator para modelagem
do sistema
 Fazer a análise da modelagem do raciocínio com o novo ator
 Se necessário, decompor o ator sistema em subatores e revisar
os modelos anteriores
 Encontrar os requisitos funcionais e não funcionais do sistema
Exemplo
Ator
sistema
Modelagem de
Dependências
Ator sistema
Exemplo
Tarefa
principal
Modelagem do
Raciocínio
Exemplo: Decomposição em subatores
Ator
sistema
Etapa de Projeto Arquitetural
Os diagramas desta etapa são:
 Modelagem de requisitos não funcionais:
– Fazer o mapeamento dos requisitos não funcionais a um estilo
arquitetural.
– Estilos arquiteturais: pirâmide, cooperação, integração vertical,…

Revisar a modelagem de dependências e a modelagem de
raciocínio:
– Se necessário, introduzir novos atores no sistema e suas dependências.
– Se necessário, decompor os atores e dependências em subatores e
subdependências
Modelagem de
Requisitos
não funcionais
! ou !! prioridade dos objetivos
√ objetivo aceito
X objetivo negado
++ positivo suficiente
+ positivo parcial
-- negativo suficiente
- negativo parcial
Modelagem de
Dependências
Novos
atores
Etapa de Projeto Detalhado
Os diagramas desta etapa são:
 Diagrama de classe: criado a partir da modelagem de
dependências e do racionamento

Diagramas de seqüência e colaboração: modelagem da
interação entre os atores

Diagrama de planos: modelar a dinâmica da parte interna dos
atores e a interação entre eles
Exemplo: Diagrama de Classe
Exemplo: Diagrama de Seqüência
Exemplo: Diagrama de Planos
Etapa de Implementação

Descreve o mapeamento dos elementos do sistema a elementos
definidos na plataforma de implementação que será utilizada

Propõe implementar o sistema utilizando Jack
Mapeamento de i* para Jack
Prometheus
Prometheus

Fase de Especificação do Sistema
– Foco na identificação das funcionalidades básicas do sistema
juntamente com os dados de entrada (percepções), de saída (ações) e
qualquer informação importante de troca de dados

Fase de Design Arquitetural
– Identifica os agentes e como eles interagem

Fase de Design Detalhado
– Detalha a parte interna do agente e define como o agente irá cumprir
suas tarefas
Prometheus
Etapa de Especificação do Sistema
I/II

Descrição das funcionalidades e de casos de uso

Descritor de funcionalidades:
– Nome
– descrição em linguagem natural
– lista de ações
– lista de percepções relevantes
– dados usados e produzidos
– breve descrição das interações com outras funcionalidades
Exemplo: Descritor de funcionalidades
Name: Welcoming
Description: Welcomes a new visitor to the world wide
web site (with personalised information if possible).
Percepts/events/messages: CustomerArrived (message),
CustomerInformation (message)
Messages sent: CustomerInformationRequest (message),
CustomisedWWWPage (message),
Actions: DisplayCustomisedWWWPage
Data used: CustomerDB, CustomerOrders
Interactions: CustomerManager (via CustomerInformationRequest,
CustomerInformation) OnlineInteraction
(via CustomisedWWWPage, CustomerArrived)
Etapa de Especificação do Sistema

II/II
Cenários de caso de uso:
– Descrevem um conjunto de passos de uma operação/funcionalidade do
sistema
– Cada passo é anotado com o nome da funcionalidade e as
informações/dados usados ou produzidos

Descritor de cenário
– Identificador
– Descrição
– Contexto de uso
– Cenário em si (seqüência de passos)
– Informações/dados usados e produzidos
– Invariantes
Scenario: Book Order
Overview: The user orders a book. Delivery options are
explored and then confirmed (with an OrderRequest). The
books are shipped, stock updated, and the user notified.
Context: Assumes the book is in stock.
Steps:
1. EVENT BookOrder (! Online Interaction)
2. DeliveryOptionQuery (Online Interaction!Transport
Information)
3. DeliveryOptions (Transport Information ! Online
Interaction) Data read: Transport DB
4. Obtain preferred delivery option (Online Interaction)
5. MakePayment (Online Interaction ! Sales Transaction)
6. ACTION BankTransaction (Sales Transaction)
7. PlaceOrder (Sales Transaction!Order Handling)
8. Register order (Order Handling) Writes data: CustomerOrders
9. ACTION EmailCourierCompany (Order Handling)
10. DecreaseStock (Order Handling ! Stock Manager)
Variations: steps 9 (email courier) and 10 (decrease
stock) replaced with notification of delay (Order Handling
to Customer Contact) and then placing an order for more
stock (Order Handling to Stock Manager).
Etapa de Projeto Arquitetural


I/II
Definição dos agentes grupando funcionalidades
Diagrama de agentes:
– liga os agentes que interagem

Descritor de agente:
– Nome,
– Descrição
– Breve descrição das interações
– Lista de funcionalidades que são incorporadas ao agente
– Dados lidos e dados escritos
Name: Sales Assistant agent
Description: greets customer, follows through site, assists with finding books
Cardinality: one/customer.
Lifetime: Instantiated on customer arrival at site. Demise when customer logs
out or after inactivity period.
Initialisation: Obtains cookie. Reads Customer DB.
Demise: Closes open DB connections.
Functionalities included: Online Interaction, Sales Transaction, Welcomer,
Book Finder.
Uses data: Customer DB, Customer Orders, Book DB.
Produces data: Customer preferences, orders, queries
Goals: Welcome customer; Update customer details; Respond to queries;
Facilitate purchases;
Events responded to: new arrival; customer query; customer purchase; credit
check response customer response;
Actions: Display information to customer (greetings, book info, info requests,
Display customisedWWWpage, RequestCreditCheck messages
Interacts with: Warehouse Manager (book request protocol),
Delivery Manager (order protocol, order query protocol),
Customer Manager (customer information query protocol, customer information
update protocol)
Etapa de Projeto Arquitetural
II/II

Identificação dos objetos compartilhados pelos agentes
Identificação dos eventos

Diagrama geral do sistema:

– Liga agentes, eventos e dados compartilhados

Diagrama de interação:
– Usa AUML para modelar a interação entre agentes e protocolos de
interação
Exemplo: Diagrama do sistema
dados
mensagem
Exemplo: Diagrama de Sequência AUML
Etapa de Projeto Detalhado
I/III

Foco na definição de capacidades, eventos internos, planos e
detalhamento da estrutura dos dados

Dependente da plataforma de implementação

Descritor de capacidade
– Nome
– Descrição
– Informação sobre a interface externa da capacidade (quais eventos são
imput e quais são output)
– Interação com outras capacidades
– Inclusão de outras capacidades (sub-capacidades)
– Informação sobre dados lidos e escritos pela capacidade
Etapa de Projeto Detalhado

II/III
Diagrama geral do agente:
– Modela as capacidades de um agente e o fluxo de eventos ou tarefas
entre as capacidades, assim como os dados internos de um agente
mensagem
capacidade
dados
Etapa de Projeto Detalhado

III/III
Diagrama de capacidades:
– Mostra o refinamento de capacidades até planos

Descritor de planos
– Identificador
– Descrição
– Evento que dispara o plano
– Passos do plano
– Contexto de uso
– Lista de dados lidos e escritos

Descritor de eventos
– Descreve o propósito do evento e os dados que o evento carrega

Descritor de dados
– Descreve os campos e os métodos utilizados para guardar os dados