artigo transp sw

1

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

[email protected]

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


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)


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


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)


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


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.


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


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


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


http://www.math.yorku.ca/~cysneiro/nfrs.htm

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


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)


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


24


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


29

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


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


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


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


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


38


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


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]}


42


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


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


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


48


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

artigo transp sw

Documents