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


3

Introdução


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.


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.


6




7


Abordagem Informal

Em um relatório publicado em Rome Air Development Center (RADC) [7], NFRs são classificados em:


Technically-OrientedConsumer-Oriented

8


Abordagem Formal

As abordagens formais podem ser divididas em:


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.


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.


11




12


É 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.


13


Pode ser quantitativa ou qualitativa;

A proposta dos autores é qualitativa;

Uma abordagem quantitativa poderia, por exemplo, medir a visibilidade do software em desenvolvimento;


Qualitativa QuantitativaX

14




15



O framework proposto pelos autores utiliza cinco componentes:

Goals;

Link Types;

Methods;

Correlation Rules; e

Labelling Procedure.

16

Framework proposto pelos Autores - Goals


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


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



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



O framework define formalmente esses links e os seguintes predicados:

● Proposition;

● Satisficed;

● Denied;

● Satisficeable; e

● Deniable.

20

Framework proposto pelos Autores – Methods


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


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


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


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



27

Exemplo:

Requisito Não-Funcional de Performance



29

Conclusão



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.


31

Referência



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.


mauricio puc rio (er) aula 7 primeiro artigo

Documents