Metodologias

Viviane Torres da Silvaviviane.silva@ic.uff.br

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

ator objetivo-suave

objetivo

tarefasrecursos

Modelagem de Dependências

ExemploTarefaprincipal

Modelagem do Raciocínio

Link de realização

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

Ator sistema

Modelagem de Dependências

Exemplo

Ator sistema

Tarefaprincipal

Modelagem do Raciocínio

Exemplo

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

! ou !! prioridade dos objetivos√ objetivo aceitoX objetivo negado++ positivo suficiente+ positivo parcial

-- negativo suficiente- negativo parcial

Modelagem de Requisitos não funcionais

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 wideweb 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 OrderOverview: The user orders a book. Delivery options areexplored and then confirmed (with an OrderRequest). Thebooks 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!TransportInformation)3. DeliveryOptions (Transport Information ! OnlineInteraction) Data read: Transport DB4. 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: CustomerOrders9. ACTION EmailCourierCompany (Order Handling)10. DecreaseStock (Order Handling ! Stock Manager)Variations: steps 9 (email courier) and 10 (decreasestock) replaced with notification of delay (Order Handlingto Customer Contact) and then placing an order for morestock (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 agentDescription: greets customer, follows through site, assists with finding booksCardinality: 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, queriesGoals: 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 messagesInteracts 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

mensagem

dados

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

capacidade

mensagem

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