Mauricio Puc Rio (Er) Aula 7 Primeiro Artigo

  • 316 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
316
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Representing and Using Nonfuctional Requirements: A Process-Oriented Approach Aluno: Maurício Serrano Abril 2008 Análise do Artigo Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 2. Índice
    • Introdução
    • Trabalhos Relacionados
    • Abordagem Orientada a Processo
    • Framework proposto pelos Autores
    • Exemplos:
      • Requisito Não-Funcional de Precisão ( Accuracy )
      • Requisito Não-Funcional de Performance ( Performance )
    • Conclusão
    • Referência
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 3. Introdução Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 4. Introdução
    • A complexidade em Sistemas de Informação é dada por FRs e NFRs ;
    • NFRs são utilizados como critérios de seleção;
    • Erros em NFRs são os mais caros e mais difíceis de serem corrigidos; e
    • NFRs recebem menos atenção que os FRs e outros fatores menos importantes.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 5. Introdução
    • NFRs são tratados informalmente na fase de requisitos;
    • NFRs são normalmente contraditórios;
    • NFRs são difíceis de se garantir durante o Desenvolvimento de Software;
    • NFRs são difíceis de se validar junto ao usuário final; e
    • NFRs não possuem uma definição formal ou mesmo uma lista completa.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 6. Trabalhos Relacionados Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 7. Trabalhos Relacionados Abordagem Informal Em um relatório publicado em Rome Air Development Center ( RADC ) [7], NFRs são classificados em: Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Technically-Oriented Consumer-Oriented
  • 8. Trabalhos Relacionados Abordagem Formal As abordagens formais podem ser divididas em: Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Product-Oriented Process-Oriented
  • 9. Trabalhos Relacionados – Product-Oriented
    • Existe um overview publicado em [26];
    • Boehm et al. [5] considera características de qualidade de software e percebe que a experiência do designer aumenta a qualidade do produto final; e
    • Basili e Musa [3] propõem modelos e métricas (quantitativas) para o processo de engenharia de software sob o ponto de vista da gerência.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 10. Trabalhos Relacionados – Base para a Proposta
    • Sistemas de apoio à decisão [19] [28] [29];
    • Modelos para representar Design Rationales [38];
    • Ambientes para desenvolvimento de Sistemas de Informação DAIDA [23]:
      • Framework para o desenvolvimento de software com notações para modelagem de requisitos, design , implementação e apoio à decisão;
      • Ponto de partida para o tratamento de requisitos não-funcionais;
      • A especificação dos requisitos restringe a especificação do design;
      • A especificação do design restringe a implementação; e
      • Utiliza dependency links .
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 11. Abordagem Orientada a Processo Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 12. Abordagem Orientada a Processo
    • É a abordagem utilizada pelos autores;
    • Justifica decisões de design durante o Processo de Desenvolvimento de Software;
    • Evita avaliar o produto;
    • As decisões de design podem afetar positivamente ou negativamente NFRs particulares; e
    • Utiliza essas contribuições como base para questionar se o software contempla um certo NFR .
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 13. Abordagem Orientada a Processo
    • Pode ser quantitativa ou qualitativa;
    • A proposta dos autores é qualitativa;
    • Uma abordagem quantitativa poderia, por exemplo, medir a visibilidade do software em desenvolvimento;
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Qualitativa Quantitativa X
  • 14. Framework proposto pelos Autores Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 15. Framework proposto pelos Autores Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework proposto pelos autores utiliza cinco componentes:
    • Goals;
    • Link Types;
    • Methods;
    • Correlation Rules; e
    • Labelling Procedure.
  • 16. Framework proposto pelos Autores - Goals Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Três classes mutuamente exclusivas de goals :
    • Nonfunctional Requirement Goals (NFRGoals):
      • Compreende o espaço dos vários NFRs.
      • Exemplo: Accuracy[attributes(Employee)]
    • Satisficing Goals (SatGoals):
      • Compreende as decisões de design que podem ser adotadas para satisfazer NFRGoals .
      • Exemplo: Validation[attributes(Employee)]
    • Argumentation Goals (ArgGoals);
      • Compreende afirmações formais ou informais.
      • Exemplo:
  • 17. Framework proposto pelos Autores – Link Types Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework utiliza links para refinar um goal em outros goals :
      • AND : equivalente a árvores AND/OR ;
      • OR : idem;
      • sup : supergoal ;
      • sub : subgoal ;
      • eql : equivalente;
      • und : indeterminado.
  • 18. Framework proposto pelos Autores – Link Types Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Satisficing Link:
      • Utilizado para “ligar” goals.
    • Dependency Link:
      • Utilizados para mapear objetos.
    • Justification-for-selection Link.
      • Utilizados para justificar dependências através de SatGoals .
  • 19. Framework proposto pelos Autores – Link Types Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework define formalmente esses links e os seguintes predicados:
      • Proposition ;
      • Satisficed ;
      • Denied ;
      • Satisficeable ; e
      • Deniable .
  • 20. Framework proposto pelos Autores – Methods Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework proposto pelos autores utiliza três métodos, um para cada tipo de goal :
    • Goal Decomposition Methods:
      • Decompõem um goal em outros goals ;
      • Links do tipo AND e OR.
    • Goal Satisficing Methods:
      • Decompõem um NFRGoal em SatGoals;
      • Links do tipo und, eql, sup e sub.
    • Argumentation Methods:
      • Refinam um goal ou um link em um ArgGoal, indicando evidência ou contra-evidência para satisfação desse goal ;
      • Links do tipo AND .
  • 21. Framework proposto pelos Autores – Correlation Rules Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Regras de correlação detalham ou restringem as interações entre goals . Essas regras têm as seguintes características:
      • São regras expressas formalmente;
      • Podem inferir novas regras de correlação;
      • Pode-se aplicar um procedimento de expansão, expandindo goals e aplicando regras de correlação.
  • 22. Framework proposto pelos Autores – Labelling Procedure Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Pode-se atribuir os seguintes rótulos aos goals :
      • Satisficed;
      • Denied;
      • Conflicting; e
      • Undertermined.
    • Como poucas informações estão inseridas formalmente, o designer pode ter que determinar o rótulo.
  • 23. Framework proposto pelos Autores – Labelling Procedure Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Um procedimento de rotulação interativo é utilizado de forma a obter rótulos para todos os goals ;
    • Regras de propagação também são utilizadas;
    • O procedimento pode ser comparado com os utilizados em Sistemas de Manutenção de Fatos que mantêm crenças, justificativas e suposições;
    • Não é automático.
  • 24. Exemplo: Requisito Não-Funcional de Precisão Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 25.  
  • 26.  
  • 27. Exemplo: Requisito Não-Funcional de Performance Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 28.  
  • 29. Conclusão Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 30. Conclusão
    • O framework :
      • é um framework concreto para integrar requisitos não-funcionais no Processo de Desenvolvimento de Software;
      • ainda está sendo refinado;
      • possui uma ferramenta protótipo.
      • precisa ser aplicado em outros requisitos não-funcionais;
      • precisa ser utilizado em exemplos mais reais;
      • precisa de uma base teórica com semântica para NFRs e uma teoria de prova.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 31. Referência Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 32. Referência
    • John Mylopoulos, Lawrence Chung, and Brian Nixon. “ Representing and Using Nonfuctional Requirements: A Process-Oriented Approach .” IEEE TRANSACTIONS ON SOFTWARE ENGINEbRING, VOL. 18. NO. 6, pp. 483-497, JUNE 1992.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)