Artigo Transp Sw

1

REQUISITOS NÃO FUNCIONAIS:DA ELICITAÇÃO AOS MODELOS CONCEITUAIS

fnapolitano@inf.puc-rio.br

PUC-RJ

TRANSPARÊNCIA DE SOFTWARE

2

Introdução

Sistemas de Software devem se preocupar não somente com aspectos funcionais, mas também com aspectos não funcionais: Confiança Segurança Precisão Performance “Look and Feel” Requirements

3

Introdução

Esses Aspectos devem ser tratados como Requisitos Não-Funcionais (NFR)

Deve-se dedicar atenção aos NFRs durante todo o Processo de Desenvolvimento

Caso clássico de não conformidade dos NFRs: London Ambulance System

4

Introdução

NFRs tem recebido pouca atenção no desenvolvimento de software

A maioria dos trabalhos em NFRs usa uma abordagem orientada a produto

Essa abordagem orientada a produto está relacionada a medida do quanto o software está de acordo com o conjunto de NFRs que ele deveria satisfazer

5

Introdução

Existem trabalhos em NFRs que usam abordagem orientada a processo

A abordagem orientada a processo propõe o uso de técnicas para justificar decisões de design na inclusão ou exclusão dos requisitos

6

Introdução

O artigo propõe uma estratégia para elicitar NFRs e orientar o engenheiro de software a obter modelos conceituais que terão rastros explícitos para os NFRs e vice-versa

O processo de elicitação proposto é baseado no uso de léxico, que não servirá somente para unir modelos funcionais e não funcionas, mas também para guiar a elicitação de NFRs

7

Introdução

Por fim, a estratégia propões uma maneira sistemática de integrar os NFRs elicitados com casos de uso e cenários, bem como diagramas de classe, seqüência e colaboração

8

– Visão do desenvolvimento de software como 2 perspectivas independentes e evolutivas

– Uma perspectiva cuida dos aspectos funcionais e a outra de aspectos não-funcionais

– Mudanças nos requisitos são geralmente motivadas por aspectos funcionais e não funcionais, logo tratá-los separadamente facilita o aspecto evolutivo

Overview da Estratégia

9

Overview da Estratégia

10

– Formada por: BUILD LEL; BUILD FUNCTIONAL PERSPECTIVE; BUILD NON - FUNCTIONAL PERSPECTIVE; INTEGRATE BOTH PERSPECTIVES

– Perspectivas funcionais e não funcionais ligadas pelo LEL – vocabulário comum

– Inicialmente, constrói-se o léxico e em seguida, os modelos funcionais e não funcionais paralelamente. Posteriormente integra-se os 2 modelos preocupando-se com os diferentes feedbacks durante a evolução do processo (novos símbolos no LEL e discrepâncias)

Overview da Estratégia

11

1. Construção do Léxico

– O LEL registra o vocabulário de um Universo de Discurso

– Baseado na simples ideia: entender a linguagem do problema sem se preocupar em entender profundamente o problema

– Inicialmente, constrói-se o léxico e em seguida, os modelos funcionais e não funcionais paralelamente. Posteriormente integra-se os 2 modelos preocupando-se com os diferentes feedbacks durante a evolução do processo (novos símbolos no LEL e discrepâncias)

– Suas entradas são naturamente ligadas em um grafo

Overview da Estratégia

12

2. Construção da Perspectiva Funcional

– Após o LEL, inicia-se a construção do modelo funcional

– O artigo não detalha o processo, sugerindo qualquer modelagem OO (por exemplo, RUP)

Overview da Estratégia

13

3. Construção da Perspectiva Não - Funcional

– É construida em paralelo a perspectiva funcional

– Nessa atividade, os NFRs desejados são inseridos no recém criado LEL

– Em seguida, os NFRs são representados por um conjunto de grafos, usando NFR framework de Chung

– O NFR framework propõe o uso de requisitos não funcionais para guiar o design do sistema

Overview da Estratégia

14

4. Integração das Perspectivas

– O processo de integração pode acontecer tanto na early phase, integrando os NFRs aos casos de usos e cenários, ou depois, integrando os NFRs aos diagramas de classes, sequência e colaboração

– É importante ressaltar que a integração é baseada na ideia que os grafos NFRs e o diagramas de classes, sequência e colaboração serão construídos utilizando símbolos do LEL.

Overview da Estratégia

15

Construção da Perspectiva Não - Funcional

16

– Para construir a perspectiva não funcional, utiliza-se o LEL existente, ou caso não exista, deve-se construir um novo

– Deve-se adicionar ao LEL os NFRs desejados pelos clientes

– Uma vez que se tem o léxico mostrando os NFRs desejados e algumas de suas operacionalizações, representa-se esses NFRs em um conjunto de grafos NFRs, de acordo com o framework NFR

– Em seguida, aplicam-se heurísticas na procura de possíveis interdependências

– Possíveis conflitos devem ser negociados com os Stakeholders

Construção da Perspectiva Não - Funcional

17

Três motivos para o uso de LEL:

– Linguagem natural de representação (cliente leigo não tem dificuldades em lidar com isto)

– É estruturado em grafos

– É usado como base para futuras representações, provendo uma rastreabilidade natural

Usando LEL Como Apoio na Elicitação dos NFRs

18

Construção do LEL:

– Deve ser orientada pelos princípios do vocabulário mínimo e da circularidade

– O princípio da circularidade prevê a maximização do uso de símbolos do LEL quando da descrição de entradas do LEL

– O princípio do vocabulário mínimo prevê a minimização do uso de símbolos externos ao LEL quando da descrição destes símbolos

Usando LEL Como Apoio na Elicitação dos NFRs

19

– Deve-se extender o LEL para ajudar na elicitação dos NFRs

– LEL está agora estruturado para expressar que um símbolo necessita de um ou mais NFRs

– Para cada NFR expresso deve-se recorrer a base de conhecimentos para tentar encontrar possíveis refinamentos e operacionalizações para este NFR

– Uma vez que a operacionalização é inserida, é necessário introduzir um link de rastreabilidade em notion ou behavioral response (impacto) apontando para o NFR que originou a operacionalização

Usando LEL Como Apoio na Elicitação dos NFRs

20

– Base de conhecimento em forma de catálogo. Disponível em: http://www.math.yorku.ca/~cysneiro/nfrs.htm

– Tanto o LEL quanto a extensão com suporte aos NFRs estão implementados na ferramenta OORNF

– Esta ferramenta possui uma variedade de NFRs e maneiras de os decompor.

– A ferramenta suporta cenários, LEL e class responsibility collaboration (CRC) cards

Usando LEL Como Apoio na Elicitação dos NFRs

21

Exemplo OORNF Tool:

– Laboratório de Análises Clínicas

– Para cada um dos símbolos representados no LEL, devemos nos perguntar e também aos clientes quais possíveis NFRs devem ser alcançados para que o símbolo seja completamente representado

– A figura ao lado mostra o símbolo Sample (amostra), com sua notion e behavioral response, além do catálogo de NFRs

Usando LEL Como Apoio na Elicitação dos NFRs

22

Exemplo OORNF Tool:

– Adição do NFR Traceability

– Padrão do link de rastreabilidade: “NocaoOrg[“+ Simbolo_LEL + “&”+ NFR+ “&”+ numero_interno]

– Uma amostra deve ser rastreável. Temos que entender como alcançar então esse NFR (perguntar ao cliente)

Usando LEL Como Apoio na Elicitação dos NFRs

23

Exemplo OORNF Tool:

– Toda vez que uma amostra for dividida, ou passar de um recipiente para outro, deve ficar gravado para que qualquer um saiba a amostra original

– Criado novo símbolo Aliquote Sample

Usando LEL Como Apoio na Elicitação dos NFRs

24

Usando LEL Como Apoio na Elicitação dos NFRs

25

– Goal satisficing sugere que uma solução espera ser satisfeita com limites aceitáveis

– Utiliza-se o NFR Framework

– O NFR framework vê os NFRs como objetivos que são conflitantes entre sí

– Esses objetivos são representados por softgoals para serem satisfeitos

– Cada softgoal será decomposto em subgoals representado por uma estrutura de grafo inspirado em árvores and/or

Representando NFRs

26

– Extensão do NFR Framework: operacionalização estática e dinâmica

– Operacionalizações Dinâmicas são aquelas que chamam por ações a serem executadas (círculo pontilhado)

– Operacionalização Estática geralmente expressa a necessidade do uso de algum dado no design do software para armazenar a informação que é necessária para satisfazer o NFR (círculo em negrito)

Representando NFRs

27

Exemplo símbolo Room:

– Has NFR Safety

– O sistema deve manter um caminho seguro através de uma determinada quantidade de luz no ambiente

Construindo Grafos NFR

28

– Após representar o nó raiz do grafo NFR, deve-se buscar por operacionalizações

Construindo Grafos NFR

29

– Usando o behavioral responses presente no LEL, são representadas possíveis operacionalizações

Construindo Grafos NFR

30

– Em seguida, deve-se verificar se existe possíveis subgoals. Se existirem, devem ser representados como um passo intermediário.

– Deve-se proceder de 2 maneiras distintas:

1. Decompondo a raíz usando abordagem top-down

1. Pode-se continuar a avaliação usando uma abordagem bottom-up

– No fim, para cada símbolo do LEL teremos um conjunto de grafos NFR, modelando a perspectiva não-funcional

– Deve-se checar cada grafo verificando possíveis conflitos

Construindo Grafos NFR

31

Representando NFRs

32

– Uma vez feito os grafos NFRs, deve-se procurar por possíveis interdependências entre NFRs

– Por exemplo, um software que precisa ter um alto nível de segurança irá impactar negativamente em outro NFR, como a usabilidade

– 3 Heurísticas:

1. Comparar todos os grafos do mesmo tipo, procurando por possíveis interdependências. Ex: todos os NFRs sobre Safety

3. Comparar todos os grafos que são classificados na base de conhecimentos com NFRs possivelmente conflitantes. Ex: Segurança x Usabilidade

5. Comparar par a par todos os grafos que não foram comparados aplicando-se as heurísticas anteriores.

Identificando e Resolvendo Conflitos

33

Identificando e Resolvendo Conflitos

34

– Os subgoals parcialmente satisfeitos devem ser negociados com os stakeholders

– Importante:

– Essas heurísticas tornam-se inapropriadas para uso quando se trata de sistemas com um número muito grande de NFRs

– A sugestão seria automatizar o processo

Identificando e Resolvendo Conflitos

35

– A estratégia permite a integração dos NFRs aos casos de uso, cenários, modelos de classes e diagramas de classes, sequência e colaboração

– Ao integrar os NFRs aos casos de uso e cenários na early fase do desenvolvimento do software, os artefatos produzidos posteriormente irão naturalmente refletir os NFRs

Integrando Perspectivas Funcionais e Não-Funcionais

36

– Para cada diagrama de caso de uso na perspectiva funcional, identificar se algum símbolo do LEL aparece no nome do diagrama

– Também deve-se identificar se algum símbolo do LEL aparece em algum caso de uso ou ator desse diagrama

– Para cada símbolo encontrado, deve-se procurar o conjunto de grafos NFRs para identificar onde o símbolo aparece

– Pega-se cada grafo onde o símbolo aparece e verifica-se o diagrama de caso de uso para saber se ele realiza a operacionalização dinâmica no grafo

Integrando NFRs nos Casos de Uso

37

– Cada caso de uso ou ator incluído para satisfazer um determinado NFR deve ser seguido pela expressão seguindo o padrão: {NFR_Type[NFR_topic]}

– O uso dessa expressão ajuda a reatreabilidade

– Os NFRs tem uma natureza muito vaga, em oposição aos requisitos funcionais, e não é muito usual tê-los claramente na mente do engenheiro de software

– A rastreabilidade ajuda ao engenheiro de software na revisão e mudança dos modelos

– Pode ser necessário estabelecer condições especiais como pré e pós condições para satisfazer algum NFR

Integrando NFRs nos Casos de Uso

38

Integrando NFRs nos Casos de Uso

39

– O processo de integração também será baseado no uso do LEL

– Cada cenário será analisado, procurando-se símbolos do LEL no título do cenário, na descrição de recursos, na desrição de atores, ou na descrição de objetivos

– Para cada símbolo encontrado, observa-se o conjunto de grafos NFRs procurando este símbolo

– Uma vez encotrado um ou mais grafos NFRs, deve-se checar se as operacionalizações em cada grafo já são satisfeitas na descrição dos cenários

– Caso não forem satisfeitas, deve-se atualizar os cenários para satisfazer essa condição

– Esse processo continua até todos os cenários serem analisados

Integrando NFRs em Cenários

40

Integrando NFRs em Cenários

41

– Assim como nos casos de uso, caso não seja encontrado pelo menos um símbolo do LEL no título do cenário, deve-se atualizar o LEL

– Também como nos casos de uso, a informação inserida nos cenários para satisfazer um NFR deve estar no padrão: Constraint{NFR_Type[NFR_topic]}

Integrando NFRs em Cenários

42

Integrando NFRs em Cenários

43

– O processo de integração também será baseado no uso do LEL

– Cada classe pertencente ao diagrama de classes deve ser nomeada usando símbolos do LEL

– Caso não se encontre símbolos do LEL no nome das classes, pode se considerar que algum símbolo não foi considerado ou o LEL precisa ser atualizado

– O processo de integração é centrado na procura dos símbolos que aparecem em ambos os modelos, e analisando os impactos de adicionar a operacionalização dos NFRs no diagrama de classes

Integrando NFRs em Diagramas de Classes

44

Integrando NFRs em Diagramas de Classes

45

– Inicialmente, pega-se uma classe do diagrama, em qualquer ordem

– Em seguida, procura-se em todos os grafos NFRs a ocorrência desse símbolo

– Em cada grafo que o símbolo apareça, deve-se identificar as operacionalizações estáticas e dinâmicas para este grafo

– Para operacionalizações dinâmicas encontradas, deve-se verificar se as operações pertencentes as classes preenchem as necessidades expressas na operacionalização do grafo

– Caso não esteja, deve-se adicionar novas operações e atributos a classe

– A inserção de novas operações e atributos muitas vezes requer uma nova análise

Integrando NFRs em Diagramas de Classes

46

1. Classes criadas para satisfazer um NFR deve ter seu nome seguido de um link para rastreabilidade, no padrão: {NFR [LEL symbol]}

– A classe FMCP foi criada observando-se a classe Control Panel

– Procurou-se nos grafos NFRs pelo símbolo

– Observou-se duas operacionalizações dinâmicas – Set Password e Ask Password

– Como não foi encontrado nada na classe Control Panel para satisfazer esses NFRs, criou-se a subclasse Facility Manager Control Panel - FMCP

Heurísticas de Como Usar Didagramas de Classes para Tratar NFRs

47

2. Adjacente a cada operação incluída para satisfazer um NFR, deve-se adicionar um link para a perspectiva não-funcional

– Como na primeira heurística, esse procedimento reforça a rastreabilidade do modelo

3. Se um NFR necessita de pré ou pós condições para aplicar uma operação, deve-se adicionar essas pré e pós condições a essas respectivas operações

– Essa heurística é usada para tratar restrições operacionais que alguns NFRs impõem

4. Adjacente a cada atributo que foi adicionado para satisfazer um NFR, deve-se usar a mesma expressão usada nas operações para manter um link para as perspectivas não-funcionais

Heurísticas de Como Usar Didagramas de Classes para Tratar NFRs

48

Heurísticas de Como Usar Didagramas de Classes para Tratar NFRs

49

– A integração de NFRs no diagrama de sequência e colaboração é feita examinado cada classe do diagrama de classes

– Para cada operação incluída para satisfazer um NFR, deve-se procurar os diagramas de sequência e colaboração em que essas classes aparecem

– Para cada diagrama encontrado, deve-se verificar se as novas operações adicionadas estão de acordo com os NFRs e se isso irá resultar em alguma alteração ou adição de classes e/ou mensagens nos diagramas

– Deve-se representar as novas mensagens juntas as prés e pós condições nos diagramas onde foram adicionadas para tratar os NFRs

– As mensagens também devem conter os links de rastreabilidade, como visto anteriormente

Integrando NFRs em Diagramas de Sequência e Colaboração

50

Integrando NFRs em Diagramas de Sequência e Colaboração

51

– Para comprovar o uso da estratégia, foram realizados 3 estudos de casos

– O estudo de caso I foi conduzido usando os modelos conceituais criado por Breitman como parte de sua tese de PhD. Trata-se da implementação de um Light Control System, para a Universidade de Kaiserslautern

– O estudo de caso II foi conduzido utilizando os modelos conceituais criado por um grupo de alunos de graduação da PUC-Rio durante um projeto de software

– O estudo de caso III foi conduzido junto a uma software house especializada em construir softwares para laboratórios de análises clínicas. Eles eram responsáveis pelo desenvolvimento de um novo sistema de informação para um laboratório

Usando a Estratégia

52

Usando a Estratégia

– É fácil observar que todos os 3 estudos de caso apresentaram um número considerável de mudanças nos modelos conceituais analisados

53

– Erros ao tratar os NFRs são os mais caros e difíceis de corrigir

– A maioria dos métodos na engenharia de software não tratam os NFRs de uma maneira explicita

– O trabalho apresentado mostra um forte e mais sistemático processo de elicitação, extendendo o LEL para ajudar a elicitar NFRs, usando heurísticas para solução de conflitos e um importante processo de integração de perspectivas funcionais e não funcionais

– Por fim, comprovou-se a estratégia realizando 3 estudos de caso. Os resultados sugerem que o uso da estratégia ajuda a melhorar a qualidade do modelo conceitual final, além de tornar o processo de desenvolvimento de software mais produtivo

Conclusões

54

CYSNEIROS, Luiz Marcio; LEITE, Julio Cesar Sampaio do Prado. Nonfunctional Requirements: From Elicitation to Conceptual Models. IEEE Transactions on Software Engineering, Maio 2004 (Vol 30, n 05)

Referência