Mauricio Puc Rio (Er) Aula 7 Primeiro Artigo

465 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
465
No SlideShare
0
A partir de incorporações
0
Número de incorporações
45
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Mauricio Puc Rio (Er) Aula 7 Primeiro Artigo

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

×