Metodologias (Parte I) Viviane Torres da Silva

Slides:



Advertisements
Apresentações semelhantes
Análise e Projeto Orientado a Objetos
Advertisements

Análise e Projeto de Sistemas I
Linguagens de Programação para SMA Viviane Torres da Silva
Os Sistemas Multi-agente Viviane Torres da Silva
Requisitos de Software
Engenharia de Software
UML Modelando um sistema.
UML Visões – Parte 2.
UML – Visões Parte 1 Modelando um sistema.
(Unified Modeling Language)
Projeto conceitual Mostra ao cliente exatamente o que o sistema fará
Diagrama de Classes.
Engenharia de Software
Rational Unified Process(RUP)
Valéria Maria Lauande Março/2010
UML Material retirado da apostila do Professor Cesar Augusto Tacla
Metodologias Equipe do Curso de ES para SMA
Metodologias Equipe do Curso de ES para SMA {lucena, furtado, choren,
Metodologias Equipe do Curso de ES para SMA
Linguagens de Modelagem (cont.) (IV)
Viviane Torres da Silva
Frameworks Conceituais
Linguagens de Modelagem para SMA
Viviane Torres da Silva
Os Sistemas Multi-agente Viviane Torres da Silva
SISTEMA É UMA ENTIDADE QUE MANTEM SUA EXISTÊNCIA ATRAVÉS DA INTERAÇÃO DE SUAS PARTES ( Bertalanffy ) Interação Mútua Diferente duma simples.
Aprendizagem Viviane Torres da Silva
Linguagens de Modelagem para SMA
Metodologias Orientadas a Agentes
Modelagem de Sistemas de Informação
AORML Agent-Object-Relationship Modeling Language Inteligência Artificial 2007/02 Renata S.S. Guizzardi.
Análise e Projeto de Sistemas
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
RUP: Fluxo de Análise e Projeto
Simone Sawasaki Tanaka
Análise e Projeto de Sistemas
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Metodologias para construção de SMA
Ferramenta: E extrair para c:\Temp
Caso de Uso - Definição Um caso de uso é uma descrição narrativa de uma seqüência de eventos que ocorre quando um ator (agente externo) usa um sistema.
Diagramas de Atividade
Metodologias (Parte II) Viviane Torres da Silva
Bruno Silva Desenvolvido a partir de
METODOLOGIA, MÉTODOS E FERRAMENTAS
Laboratório de Programação
RUP - Cap. 3 – Processo Dirigido por Caso de Uso
Revisão 2º Bimestre Engenharia de Software I
Capítulo 10 – Qualidade de Produtos de Software Escrito por: Renata Araújo Vírginia Chalegre Apresentado por: Cleice.
Análise e Projeto de Sistemas
Fluxos secundários Só devem ser analisados e descritos após a descrição dos fluxos básicos. Fluxos alternativos situações especiais (desconto para um cliente)
IEEE Melhores Práticas para Descrições de Projeto de Software (DPS)
Ferramenta de Modelagem de Requisitos e Agentes (TAOM4e) Laís Xavier Prof.: Jaelson Castro.
Gestão de projetos de Software GTI-16
Linguagem de Modelagem Unificada
Modelo de Análise e Projeto
Diagramas de Caso de Uso
Engenharia de Software e Sistemas
Sistemas Propriedades de Sistemas SITP – Módulo 3.
Desenvolvendo Sistemas Multi-agentes usando o Framework Tropos
Requisitos Não funcionais
Organização de Sistemas Multiagentes Prof. Fred Freitas CIn - UFPE.
André Drummond RA Danilo Benzatti RA
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
Projetar Cápsulas Parte 1. Copyright © 2002 Qualiti. Todos os direitos reservados. Qualiti Software Processes Projetar cápsulas | 2 Objetivos deste módulo.
Interações entre objetos
/ de Julho de UFPE - Universidade Federal de Pernambuco CIn - Centro de Informática Pós-Graduação em Ciência da Computação Tópicos Avançados.
1 Especificação de Sistemas de Software e a UML. 2 Modelagem de sistema A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

Metodologias (Parte I) Viviane Torres da Silva

Metodologias  Tropos  Prometheus  Gaia  Message  MaSE

Tropos

 Objetivo: fazer o dezenvolvimento de SMA orientado a requisitos  Está baseada no framework de modelagem para a análise de requisitos chamado i* –Conceitos: actor, 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 adciona o ator sistema a modelagem –Descrição do sistema através de suas funções (requisitos funcionais e não funcionais)

Etapas de 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 datos de entrada e saída dos subsistemas

Etapas de 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 propiedade autônoma, social, reativa e proactiva.  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 impossivel afirmar que foi alcançado –Utilizado para modelar os requisitos não funcionales  Plano –Maneira de fazer determinada coisa –Sua execução alcaç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 diagrama desta etapa são:  Modelagem de dependências (Strategic Dependence Model): –modela os atores, seus objetivos e suas dependências  Modelagem de racionalização (Strategic Rational Model): –modela como os objetivos de um ator podem ser alcançados através da contribuçã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 atorobjetivo-suave objetivo tarefas recursos Modelagem de Dependências

Exemplo Tarefa principal Modelagem do Raciocíneo 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 actor para modelagam 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 funcionáis e não funcionáis do sistema

Ator sistema Modelagem de Dependências Exemplo Ator sistema

Tarefa principal Modelagem do Raciocíneo Exemplo

Exemplo: Decomposição em subatores Ator sistema

Etapa de Projeto Arquitetural Os diagramas desta etapa são:  Modelagem de requisitos não funcionáis: –Fazer o mapeamento dos requisitos não funcionáis a um estilo arquitetural. –Estilos arquiteturales: pirâmide, cooperação, integração vertical,…  Revisar a modelagem de dependências e a modelagem de raciocíneo: –Se necessário, introduzir novos atores no sistema e suas dependências. –Se necessário, decompor os atores e dependências en subatores e subdependências

! ou !! prioridade dos objetivos √ objetivo aceito X 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 diagrama 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

 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 SistemaI/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 SistemaII/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 CourierCompany (Order Handling) 10. DecreaseStock (Order Handling ! Stock Manager) Variations: steps 9 ( 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 ArquiteturalI/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 ArquiteturalII/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 Seqüência AUML

Etapa de Projeto DetalhadoI/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 DetalhadoII/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 Proyecto DetalladoIII/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