Metodologias
Equipe do Curso de ES para SMA
{lucena, furtado, choren, viviane}@inf.puc-rio.br
Metodologias
• Tropos (olhar paper [2004.017])
• Prometheus
Laboratório de Engenharia de Software (LES) – PUC-Rio
Tropos
Elementos
• Ator
– Entidade que possui metas e intenções
• Meta
• Soft-meta: o seu cumprimento não pode ser
descrito precisamente
• Plano
– Maneira de fazer determinada coisa
– Sua execução satisfaz metas
• Recurso
– Entidade física ou de informação
Laboratório de Engenharia de Software (LES) – PUC-Rio
Elementos
• Dependência
– Relacionamento entre atores para atingir uma meta,
executar um plano ou compartilhar um recurso
• Capacidade
– Habilidade do ator em definir, escolher ou executar um
plano para cumprir uma meta
• Crença:
– Conhecimento sobre o mundo
Laboratório de Engenharia de Software (LES) – PUC-Rio
Tropos
• Análise de requisitos
– Fase de Early Requirements
– Fase de Late Requirements
• Design
– Fase de Design Arquitetural
– Fase de Design Detalhado
• Implementação
– Fase de Implementação
Laboratório de Engenharia de Software (LES) – PUC-Rio
Modelagem
• Diagrama de atores
– Modelagem de atores
– Modelagem de dependências
• Diagrama de metas
– Modelagem de metas
– Modelagem de planos
• Diagrama de capacidades
– Modelagem de capacidades
• Diagrama de planos
– Modelagem de capacidades
Laboratório de Engenharia de Software (LES) – PUC-Rio
Modelagem Ator
Dependência
Meta
Plano
Capacidade
Fase
Early
Requirements
X
X
X
X
Late
Requirements
X
X
X
X
Design
Arquitetural
X
X
Design
Detalhado
X
X
X
X
Implementação
Laboratório de Engenharia de Software (LES) – PUC-Rio
X
Fase Early Requirements
• Foco em como o sistema é utilizado
• Modelagem de atores:
– Objetivo é modelar os atores externos e as suas
interações (através das metas) com o sistema
• Modelagem de dependências:
– Objetivo é modelar as dependências entre os atores para
atingir uma meta, executar um plano ou prover um
recurso
Laboratório de Engenharia de Software (LES) – PUC-Rio
Projeto eCultura
Diagrama de atores
Laboratório de Engenharia de Software (LES) – PUC-Rio
Fase Early Requirements
• Modelagem de metas: (analisar as metas de 3
formas)
– Análise de possibilidade: identificar os planos, recursos e
soft-metas que possibilitem o ator atingir a meta
– Análise de contribuição: identificar as metas que podem
contribuir positivamente ou negativamente para uma
outra meta ser atingida
– Composição and/or: decomposição das metas em submetas
Laboratório de Engenharia de Software (LES) – PUC-Rio
Fase Early Requirements
• Modelagem de planos:
– Análise de possibilidade: identificar as metas e recursos
que possibilitem a execução do plano
– Análise de contribuição: identificar os planos que podem
contribuir positivamente ou negativamente para um
outro plano ser executado
– Composição and/or: decomposição de planos em subplanos
Laboratório de Engenharia de Software (LES) – PUC-Rio
Projeto eCultura
Diagrama de metas
Laboratório de Engenharia de Software (LES) – PUC-Rio
Late Requirement
• Foco no sistema em si
• Modelagem de atores:
– foco na identificação do ator sistema
• Modelagem de dependências:
– descreve como é a dependência do ator sistema com os
atores externos
• Modelagem de metas:
– Detalha as metas do sistema
• Modelagem de planos:
– Detalha os planos do sistema
Laboratório de Engenharia de Software (LES) – PUC-Rio
Projeto eCultura
Diagrama de atores
Diagrama de metas
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Arquitetural
• Define a arquitetura geral do sistema em termos de
sub-sistemas.
• Modelagem de atores:
– Introdução e especificação de novos atores (sub-atores)
– Associação de sub-metas a sub-atores
• Modelagem de dependências:
– Modelagem do fluxo de dados e de controle entre os subatores
Laboratório de Engenharia de Software (LES) – PUC-Rio
Projeto eCultura
Diagrama de
atores
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Arquitetural
• Modelagem de capacidades:
– Associar a cada ator capacidades específicas para atingir
as metas e executar os planos
– Definição de tipos de agentes e associação de cada tipo a
uma ou mais diferentes capacidades
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Detalhado
• Lida com o detalhamento da especificação dos
agentes
• Relacionada a plataforma de implementação e da
linguagem de programação
• Modelagem de ator:
– Os agentes do sistema são definidos especificando-se
todas as noções requeridas pela plataforma
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Detalhado
• Modelagem de capacidade:
– Uso do diagrama de atividades de UML para modelar
capacidades e planos de um agente
– Diagramas de capacidade e de plano
Laboratório de Engenharia de Software (LES) – PUC-Rio
Implementação
• Propõe implementar o sistema utilizando Jack
• Descreve o mapeamento dos elementos do sistema
para Jack
Laboratório de Engenharia de Software (LES) – PUC-Rio
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
Laboratório de Engenharia de Software (LES) – PUC-Rio
Especificação do Sistema
• 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
Laboratório de Engenharia de Software (LES) – PUC-Rio
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)
Laboratório de Engenharia de Software (LES) – PUC-Rio
Especificação do Sistema
• 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
Laboratório de Engenharia de Software (LES) – PUC-Rio
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).
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Arquitetural
• 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
Laboratório de Engenharia de Software (LES) – PUC-Rio
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)
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Arquitetural
• 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
Laboratório de Engenharia de Software (LES) – PUC-Rio
Ex.: diagrama geral do sistema
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Detalhado
• 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
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Detalhado
• 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
Laboratório de Engenharia de Software (LES) – PUC-Rio
Design Detalhado
• 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
Laboratório de Engenharia de Software (LES) – PUC-Rio