Download - Mauricio Puc Rio (Er) Aula 7 Primeiro Artigo
1
Representing and Using Nonfuctional
Requirements: A Process-Oriented Approach
Aluno: Maurício SerranoAbril 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-OrientedConsumer-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 QuantitativaX
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: SecIeEmpStatusEmployeeattributeseyValidatedBemFormalClai ,)](,[:
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)