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)