1 / 17

Centro de Informática ( cin.ufpe.br ) Universidade Federal de Pernambuco (Cin/UFPE)

Requirements as Goals and Commitments too. Rômulo César rcda2@cin.ufpe.br. Centro de Informática ( www.cin.ufpe.br ) Universidade Federal de Pernambuco (Cin/UFPE). Autores.

mandy
Download Presentation

Centro de Informática ( cin.ufpe.br ) Universidade Federal de Pernambuco (Cin/UFPE)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements as Goals and Commitments too Rômulo César rcda2@cin.ufpe.br Centro de Informática (www.cin.ufpe.br) Universidade Federal de Pernambuco (Cin/UFPE)

  2. Autores John Mylopoulos recebeu seu grau de BEng Brown University em 1966 e seu doutorado em Princeton em 1970, ano em que se juntou ao corpo docente da Universidade de Toronto. Seus interesses de pesquisa incluem informações técnicas de modelação, abrangendo notações técnicas, execução e aplicações, sistemas baseados em conhecimento, modelos de dados semânticos, projeto de sistema de informação e engenharia de requisitos. Departamento de Ciência da Computação Universidade de Toronto jm@cs.toronto.edu Amit Chopra PhD, Ciência da Computação, North Carolina State University, dezembro 2008. MS, Ciência da Computação, North Carolina State University, 2003 Fabiano Dalpiaz, Paolo Giorgini and Munindar P. Singh

  3. Introdução Em engenharia de software de pesquisa tradicional e na prática, os requisitos são classificados como funcionais ou não funcionais. Os requisitos funcionais consistem de todas as funções do sistema a ser deveria apoiar, e foram modelados e analisados em termos de diagramas e flechas. Os requisitos não funcionais incluem qualidades software desejado para o sistema a ser desenvolvido e têm sido descritos em linguagem natural, quer seja em termos de métricas. • Requisitos têm sido tradicionalmente conceituado como o que o sistema precisa ser capaz de executar. Os casos de uso é um tipo de classificador tradicional que representa uma unidade funcional . • O objetivo principal do trabalho é propor um próximo passo da linha de pesquisa, adicionando conceito de compromisso condicional e metas.

  4. Introdução O trabalho está estruturado da seguinte forma: A Seção 2 fornece uma visão abrangente sobre os compromissos, especialmente em seu uso em sistemas multiagentes. Seção 3 ilustra como os compromissos podem ser usados com objetivos para especificar os requisitos, e introduz alguns princípios de raciocínio. Seção 4 exemplifica como o raciocínio pode ser aplicado em um ambiente de agência de viagens. Seção 5 compara o nosso modelo de trabalho relacionado. Seção 6 conclui com um resumo da nossa abordagem.

  5. 2 Commitments in Multiagent Systems O conceito de compromisso abrange muitas disciplinas, de Filosofia da Mente, a Psicologia, Sociologia e Economia. Uma revisão da literatura sugere que o conceito só foi estudada na segunda metade do século passado (é verdade: Aristóteles não descobriu tudo!). Os compromissos têm sido aplicados como base para a interação flexível entre os agentes,para a formulação de linguagens de comunicação do agente [17], como uma abstração para os negócios processo de concepção [11, 14], no sentido de uma teoria de tipo para protocolos [6, 24], para a compreensão de interoperabilidade entre os agentes [6, 7] e para a formulação de uma arquitetura orientada a serviço [38]. Aspectos relacionados ao raciocínio sobre os compromissos tenham sido abordadas em [7, 13, 16, 36]. Compromissos também foram recentemente aplicados em engenharia de requisitos [39], e para o acompanhamento em conjunto com os objetivos [26].

  6. 2.1 Multiagent Systems Sistemas Multiagentes (SMA) são sistemas abertos: entidades autônomas e heterogêneas. Um agente da autonomia significa que nenhum agente tem controle sobre ele. Um agente da heterogeneidade significa que é um agente interno de construção é inacessível a outros agentes. Um agente pode ser uma organização humana, ou algum dos interessados previsto no sistema de software. É importante ressaltar que os sistemas sócio-técnicos(interação entre tecnologias e pessoas) são, em primeiro lugar, Sistemas Multiagentes. Nós especificamos as expectativas em termos de compromissos. Um agente que não cumprir seus compromissos para com os outros é não-conformidade. Um agente pode fazer o que quiser, mas a partir da perspectiva do sistema pode ser não-conformidade.

  7. 2.2 The Concept of Commitment O compormisso é da forma C (devedor, credor, antecedente, conseqüente), onde o devedor e o credor são agentes, e antecedente e conseqüente são proposições. Um compromisso C (x, y, r, u) significa que x tem o compromisso de que, se y r mantém, então ele vai trazer u. Se r detém, então C (x, y, r, u) é independente, e com o compromisso C (x, y, T, U) detém (T é a constante de verdade). Se u tem, o compromisso é alta e não se sustenta mais. Todos os compromissos são condicionais, um compromisso incondicional é apenas um caso especial em que o antecedente é igual Exemplos T. 05/03 ilustrar esses conceitos. Nos exemplos, eBook é uma livraria, e Alice é uma cliente, deixe BNW e US $ 12 referem-se às proposições Brave New World foi entregue e o pagamento de US $ 12 foi feito, respectivamente. Exemplo . (Compromisso), C (EBook, Alice, 12 dólares, AMN) significa que Alice paga 12 dólares e, em seguida EBook irá enviar-lhe o livro Admirável Mundo Novo. Um compromisso surge em um contexto social ou legal. O contexto define as regras do encontro entre as partes que interagem e, muitas vezes serve como um árbitro em disputas e impõe sanções aos partidos que violarem seus compromissos. Por exemplo, o eBay é o contexto de todos os leilões que ocorrem através do seu serviço, se o licitante não cumprir uma obrigação de pagamento de um leilão que ganhou, o eBay pode suspender o licitante.

  8. 2.3 System Specification: Protocols As abordagens tradicionais descrevem um protocolo, em termos da ocorrência e da ordem relativa de mensagens específicas. O protocolo da Figura. 1 Começa com um envio de uma orferta do EBook para Alice. Alice pode aceitar ou rejeitar a oferta. Se ela o rejeitar, o protocolo termina, se ela aceita, EBook manda o livro. Em seguida, Alice envia o pagamento para o EBook. Fig. 1. Um protocolo de compra como uma máquina de estado finito.Cada mensagem é marcada com o emissor e o receptor (e aqui abaixo, E é EBook; A é Alice).

  9. 2.3 System Specification: Protocols Tabela 1, um protocolo de aquisição expresso em termos de compromissos A figura. 2, mostra uma possível aprovação do protocolo descrito na Tabela 1. Ao enviar Criar (cB), infere EBook CB; após o recebimento da mensagem de Alice cB conclui. Ao declarar o envio ($ 12), conclui que Alice tem 12 dólares. Conseqüentemente, ela deduz que CB é individual, gerando CUB. EBook Quando recebe Declare ($ 12), infere CUB. EBook finalmente envia Declare (AMN), concluindo que seu compromisso é descarregada. Quando Alice recebe Declare (AMN).

  10. 2.4 Architecture, Interoperability, and Middleware Architecture: especificam as interconexões entre os agentes (através de papéis). protocolos de compromisso abstrair a partir de considerações de controle e fluxo de dados, em vez incidindo sobre as relações contratuais entre os agentes. Interoperability: Interoperabilidade é a capacidade de um sistema (informatizado ou não) de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não). Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos. ...pt.wikipedia.org/wiki/Interoperabilidade São abordados em [6, 7] através do conceito de alinhamento compromisso. Middleware: seria idealmente capaz de monitorar metas e compromissos, a razão sobre a conformidade e interoperabilidade, e adaptações de apoio. Em essência, o middleware que codificam uma semântica de negócios e formar um substrato comum para todos os tipos de aplicações de negócio. O middleware seria oferecer um novo modelo de programação: ele suporta a gravação de serviços diretamente em termos de metas e compromissos, e irá aliviar significativamente o encargo de escrever agentes.

  11. 3 From Goals to Commitments Resumindo a discussão sobre os compromissos: • Compromissos resumo sobre os dados e controle de fluxo. • Compromissos são uma abstração social estar fundamentada na interação, eles codificam publicamente verificáveis relações entre os agentes. • Compromissos de apoio a noção de respeito que permite a um agente para agir com flexibilidade. • Protocolos podem ser especificados como a compromissos que possam surgir entre os agentes participantes do sistema. Noção de metas como estudado em ER • Metas resumo sobre os dados e especificações de controle de fluxo. • Metas representam os estados do mundo particular de um agente quer atingir • Os agentes podem ser especificados em termos de abstrações como metas, recursos, e assim por diante. • As metas também pode ser apoiada em middleware: um agente pode monitorar as metas e agir para alcançá-los.

  12. 3 From Goals to Commitments Metas e compromissos são complementares. Um agente tem determinados objetivos que quer cumprir, e ao fazê-lo normalmente deve fazer (para outros) sobre autorizações de determinadas metas. Como alternativa, um agente tem compromissos com outros (e uma meta a cumprir), e, em seguida, adota objetivos específicos para cumprir seus compromissos. Exemplo. Considere objetivo Alice BNW. O compromisso C (comerciante, Alice, o pagamento, AMN) o comerciante apóia o objetivo, mas só se apóia se Alice fazer o pagamento. • Um agente malicioso ou imprudente só cuidada para que suas metas sejam suportadas, independentemente de seus compromissos são suportados • Um agente prudente, por outro lado seria assegurar que os compromissos são também suportados.

  13. 4 Applying Goals and Commitments Os clientes estão interessados em comprar bilhetes de avião, por algum motivo (por exemplo, férias ou viagens de negócios), agências de viagens fornecer um serviço de bilhetes vendidos para os clientes, reservar bilhetes de vôos de companhias aéreas, transportadores oferecem um serviço de entrega de bilhetes. Fig 4. Compromissos são retângulos que se conectam (via seta direcionada) de um devedor ao credor. O protocolo é definido como um conjunto de papéis (círculos) ligados através de compromissos.

  14. 4 Applying Goals and Commitments Tabela 3. Compromissos assumidos no protocolo de agência de viagens

  15. 5 Discussion • Engenharia requisitos orientada a meta é uma metodologia que foi concebida com uma visão tradicional de software em mente. Ela é adequada para o projeto de sistemas onde as partes interessadas cooperarão num determinado ambiente. • A identificação das partes interessadas na análise cenário organizacional e modelo desses atores (agentes) interessados em termos de suas próprias metas e as dependências entre eles. • Começa a partir da identificação das partes interessadas (stakeholders) na análise e definição do modelo organizacional estes atores interessados em termos de suas próprias metas e as dependências entre eles.

  16. 6 Conclusions O poder de qualquer técnica de elicitação, modelagem e análise de requisitos repousa sobre os conceitos primitivos usados para conceituar-los. O advento da orientação por meta na ER provocou uma mudança a partir de um funcional a uma visão intencional dos sistemas de software. As implicações desta mudança ainda estão sendo trabalhadas. O conceito de compromisso e de conceitos relacionados ao social, exige uma nova forma de especificação do sistema que prescreve sistema de um curso de ação mais concreta do que orientada técnicas e metas. Vemos nesta proposta mais um passo no sentido de uma visão orientada para agente de sistemas sócio-técnicos, sua conceituação, design e evolução.

  17. FIM !!!

More Related