Artigo Transp Sw

587 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
587
On SlideShare
0
From Embeds
0
Number of Embeds
43
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Artigo Transp Sw

  1. 1. REQUISITOS NÃO FUNCIONAIS: DA ELICITAÇÃO AOS MODELOS CONCEITUAIS [email_address] PUC-RJ TRANSPARÊNCIA DE SOFTWARE
  2. 2. <ul><li>Introdução </li></ul><ul><li>Sistemas de Software devem se preocupar não somente com aspectos funcionais, mas também com aspectos não funcionais: </li></ul><ul><ul><li>Confiança </li></ul></ul><ul><ul><li>Segurança </li></ul></ul><ul><ul><li>Precisão </li></ul></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>“ Look and Feel” Requirements </li></ul></ul>
  3. 3. <ul><li>Introdução </li></ul><ul><li>Esses Aspectos devem ser tratados como Requisitos Não-Funcionais (NFR) </li></ul><ul><li>Deve-se dedicar atenção aos NFRs durante todo o Processo de Desenvolvimento </li></ul><ul><li>Caso clássico de não conformidade dos NFRs : London Ambulance System </li></ul>
  4. 4. <ul><li>Introdução </li></ul><ul><li>NFRs tem recebido pouca atenção no desenvolvimento de software </li></ul><ul><li>A maioria dos trabalhos em NFRs usa uma abordagem orientada a produto </li></ul><ul><li>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 </li></ul>
  5. 5. <ul><li>Introdução </li></ul><ul><li>Existem trabalhos em NFRs que usam abordagem orientada a processo </li></ul><ul><li>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 </li></ul>
  6. 6. <ul><li>Introdução </li></ul><ul><li>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 </li></ul><ul><li>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 </li></ul>
  7. 7. <ul><li>Introdução </li></ul><ul><li>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 </li></ul>
  8. 8. <ul><ul><li>Visão do desenvolvimento de software como 2 perspectivas independentes e evolutivas </li></ul></ul><ul><ul><li>Uma perspectiva cuida dos aspectos funcionais e a outra de aspectos não-funcionais </li></ul></ul><ul><ul><li>Mudanças nos requisitos são geralmente motivadas por aspectos funcionais e não funcionais, logo tratá-los separadamente facilita o aspecto evolutivo </li></ul></ul>Overview da Estratégia
  9. 9. Overview da Estratégia
  10. 10. <ul><ul><li>Formada por: BUILD LEL; BUILD FUNCTIONAL PERSPECTIVE; BUILD NON - FUNCTIONAL PERSPECTIVE; INTEGRATE BOTH PERSPECTIVES </li></ul></ul><ul><ul><li>Perspectivas funcionais e não funcionais ligadas pelo LEL – vocabulário comum </li></ul></ul><ul><ul><li>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) </li></ul></ul>Overview da Estratégia
  11. 11. <ul><ul><li>1. Construção do Léxico </li></ul></ul><ul><ul><li>O LEL registra o vocabulário de um Universo de Discurso </li></ul></ul><ul><ul><li>Baseado na simples ideia: entender a linguagem do problema sem se preocupar em entender profundamente o problema </li></ul></ul><ul><ul><li>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) </li></ul></ul><ul><ul><li>Suas entradas são naturamente ligadas em um grafo </li></ul></ul>Overview da Estratégia
  12. 12. <ul><ul><li>2. Construção da Perspectiva Funcional </li></ul></ul><ul><ul><li>Após o LEL, inicia-se a construção do modelo funcional </li></ul></ul><ul><ul><li>O artigo não detalha o processo, sugerindo qualquer modelagem OO (por exemplo, RUP) </li></ul></ul>Overview da Estratégia
  13. 13. <ul><ul><li>3. Construção da Perspectiva Não - Funcional </li></ul></ul><ul><ul><li>É construida em paralelo a perspectiva funcional </li></ul></ul><ul><ul><li>Nessa atividade, os NFRs desejados são inseridos no recém criado LEL </li></ul></ul><ul><ul><li>Em seguida, os NFRs são representados por um conjunto de grafos, usando NFR framework de Chung </li></ul></ul><ul><ul><li>O NFR framework propõe o uso de requisitos não funcionais para guiar o design do sistema </li></ul></ul>Overview da Estratégia
  14. 14. <ul><ul><li>4. Integração das Perspectivas </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>É 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. </li></ul></ul>Overview da Estratégia
  15. 15. Construção da Perspectiva Não - Funcional
  16. 16. <ul><ul><li>Para construir a perspectiva não funcional, utiliza-se o LEL existente, ou caso não exista, deve-se construir um novo </li></ul></ul><ul><ul><li>Deve-se adicionar ao LEL os NFRs desejados pelos clientes </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Em seguida, aplicam-se heurísticas na procura de possíveis interdependências </li></ul></ul><ul><ul><li>Possíveis conflitos devem ser negociados com os Stakeholders </li></ul></ul>Construção da Perspectiva Não - Funcional
  17. 17. <ul><ul><li>Três motivos para o uso de LEL: </li></ul></ul><ul><ul><li>Linguagem natural de representação (cliente leigo não tem dificuldades em lidar com isto) </li></ul></ul><ul><ul><li>É estruturado em grafos </li></ul></ul><ul><ul><li>É usado como base para futuras representações, provendo uma rastreabilidade natural </li></ul></ul>Usando LEL Como Apoio na Elicitação dos NFRs
  18. 18. <ul><ul><li>Construção do LEL: </li></ul></ul><ul><ul><li>Deve ser orientada pelos princípios do vocabulário mínimo e da circularidade </li></ul></ul><ul><ul><li>O princípio da circularidade prevê a maximização do uso de símbolos do LEL quando da descrição de entradas do LEL </li></ul></ul><ul><ul><li>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 </li></ul></ul>Usando LEL Como Apoio na Elicitação dos NFRs
  19. 19. <ul><ul><li>Deve-se extender o LEL para ajudar na elicitação dos NFRs </li></ul></ul><ul><ul><li>LEL está agora estruturado para expressar que um símbolo necessita de um ou mais NFRs </li></ul></ul><ul><ul><li>Para cada NFR expresso deve-se recorrer a base de conhecimentos para tentar encontrar possíveis refinamentos e operacionalizações para este NFR </li></ul></ul><ul><ul><li>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 </li></ul></ul>Usando LEL Como Apoio na Elicitação dos NFRs
  20. 20. <ul><ul><li>Base de conhecimento em forma de catálogo. Disponível em: http://www.math.yorku.ca/~cysneiro/nfrs.htm </li></ul></ul><ul><ul><li>Tanto o LEL quanto a extensão com suporte aos NFRs estão implementados na ferramenta OORNF </li></ul></ul><ul><ul><li>Esta ferramenta possui uma variedade de NFRs e maneiras de os decompor. </li></ul></ul><ul><ul><li>A ferramenta suporta cenários, LEL e class responsibility collaboration (CRC) cards </li></ul></ul>Usando LEL Como Apoio na Elicitação dos NFRs
  21. 21. <ul><ul><li>Exemplo OORNF Tool: </li></ul></ul><ul><ul><li>Laboratório de Análises Clínicas </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>A figura ao lado mostra o símbolo Sample (amostra), com sua notion e behavioral response, além do catálogo de NFRs </li></ul></ul>Usando LEL Como Apoio na Elicitação dos NFRs
  22. 22. <ul><ul><li>Exemplo OORNF Tool: </li></ul></ul><ul><ul><li>Adição do NFR Traceability </li></ul></ul><ul><ul><li>Padrão do link de rastreabilidade: “NocaoOrg[“+ Simbolo_LEL + “&”+ NFR+ “&”+ numero_interno] </li></ul></ul><ul><ul><li>Uma amostra deve ser rastreável. Temos que entender como alcançar então esse NFR (perguntar ao cliente) </li></ul></ul>Usando LEL Como Apoio na Elicitação dos NFRs
  23. 23. <ul><ul><li>Exemplo OORNF Tool: </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Criado novo símbolo Aliquote Sample </li></ul></ul>Usando LEL Como Apoio na Elicitação dos NFRs
  24. 24. Usando LEL Como Apoio na Elicitação dos NFRs
  25. 25. <ul><ul><li>Goal satisficing sugere que uma solução espera ser satisfeita com limites aceitáveis </li></ul></ul><ul><ul><li>Utiliza-se o NFR Framework </li></ul></ul><ul><ul><li>O NFR framework vê os NFRs como objetivos que são conflitantes entre sí </li></ul></ul><ul><ul><li>Esses objetivos são representados por softgoals para serem satisfeitos </li></ul></ul><ul><ul><li>Cada softgoal será decomposto em subgoals representado por uma estrutura de grafo inspirado em árvores and/or </li></ul></ul>Representando NFRs
  26. 26. <ul><ul><li>Extensão do NFR Framework: operacionalização estática e dinâmica </li></ul></ul><ul><ul><li>Operacionalizações Dinâmicas são aquelas que chamam por ações a serem executadas (círculo pontilhado) </li></ul></ul><ul><ul><li>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) </li></ul></ul>Representando NFRs
  27. 27. <ul><ul><li>Exemplo símbolo Room: </li></ul></ul><ul><ul><li>Has NFR Safety </li></ul></ul><ul><ul><li>O sistema deve manter um caminho seguro através de uma determinada quantidade de luz no ambiente </li></ul></ul>Construindo Grafos NFR
  28. 28. <ul><ul><li>Após representar o nó raiz do grafo NFR, deve-se buscar por operacionalizações </li></ul></ul>Construindo Grafos NFR
  29. 29. <ul><ul><li>Usando o behavioral responses presente no LEL, são representadas possíveis operacionalizações </li></ul></ul>Construindo Grafos NFR
  30. 30. <ul><ul><li>Em seguida, deve-se verificar se existe possíveis subgoals. Se existirem, devem ser representados como um passo intermediário. </li></ul></ul><ul><ul><li>Deve-se proceder de 2 maneiras distintas: </li></ul></ul><ul><ul><ul><li>Decompondo a raíz usando abordagem top-down </li></ul></ul></ul><ul><ul><ul><li>Pode-se continuar a avaliação usando uma abordagem bottom-up </li></ul></ul></ul><ul><ul><li>No fim, para cada símbolo do LEL teremos um conjunto de grafos NFR, modelando a perspectiva não-funcional </li></ul></ul><ul><ul><li>Deve-se checar cada grafo verificando possíveis conflitos </li></ul></ul>Construindo Grafos NFR
  31. 31. Representando NFRs
  32. 32. <ul><ul><li>Uma vez feito os grafos NFRs, deve-se procurar por possíveis interdependências entre NFRs </li></ul></ul><ul><ul><li>Por exemplo, um software que precisa ter um alto nível de segurança irá impactar negativamente em outro NFR, como a usabilidade </li></ul></ul><ul><ul><li>3 Heurísticas: </li></ul></ul><ul><ul><ul><li>Comparar todos os grafos do mesmo tipo, procurando por possíveis interdependências. Ex: todos os NFRs sobre Safety </li></ul></ul></ul><ul><ul><ul><li>Comparar todos os grafos que são classificados na base de conhecimentos com NFRs possivelmente conflitantes. Ex: Segurança x Usabilidade </li></ul></ul></ul><ul><ul><ul><li>Comparar par a par todos os grafos que não foram comparados aplicando-se as heurísticas anteriores. </li></ul></ul></ul>Identificando e Resolvendo Conflitos
  33. 33. Identificando e Resolvendo Conflitos
  34. 34. <ul><ul><li>Os subgoals parcialmente satisfeitos devem ser negociados com os stakeholders </li></ul></ul><ul><ul><li>Importante: </li></ul></ul><ul><ul><li>Essas heurísticas tornam-se inapropriadas para uso quando se trata de sistemas com um número muito grande de NFRs </li></ul></ul><ul><ul><li>A sugestão seria automatizar o processo </li></ul></ul>Identificando e Resolvendo Conflitos
  35. 35. <ul><ul><li>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 </li></ul></ul><ul><ul><li>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 </li></ul></ul>Integrando Perspectivas Funcionais e Não-Funcionais
  36. 36. <ul><ul><li>Para cada diagrama de caso de uso na perspectiva funcional, identificar se algum símbolo do LEL aparece no nome do diagrama </li></ul></ul><ul><ul><li>Também deve-se identificar se algum símbolo do LEL aparece em algum caso de uso ou ator desse diagrama </li></ul></ul><ul><ul><li>Para cada símbolo encontrado, deve-se procurar o conjunto de grafos NFRs para identificar onde o símbolo aparece </li></ul></ul><ul><ul><li>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 </li></ul></ul>Integrando NFRs nos Casos de Uso
  37. 37. <ul><ul><li>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]} </li></ul></ul><ul><ul><li>O uso dessa expressão ajuda a reatreabilidade </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>A rastreabilidade ajuda ao engenheiro de software na revisão e mudança dos modelos </li></ul></ul><ul><ul><li>Pode ser necessário estabelecer condições especiais como pré e pós condições para satisfazer algum NFR </li></ul></ul>Integrando NFRs nos Casos de Uso
  38. 38. Integrando NFRs nos Casos de Uso
  39. 39. <ul><ul><li>O processo de integração também será baseado no uso do LEL </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Para cada símbolo encontrado, observa-se o conjunto de grafos NFRs procurando este símbolo </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Caso não forem satisfeitas, deve-se atualizar os cenários para satisfazer essa condição </li></ul></ul><ul><ul><li>Esse processo continua até todos os cenários serem analisados </li></ul></ul>Integrando NFRs em Cenários
  40. 40. Integrando NFRs em Cenários
  41. 41. <ul><ul><li>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 </li></ul></ul><ul><ul><li>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]} </li></ul></ul>Integrando NFRs em Cenários
  42. 42. Integrando NFRs em Cenários
  43. 43. <ul><ul><li>O processo de integração também será baseado no uso do LEL </li></ul></ul><ul><ul><li>Cada classe pertencente ao diagrama de classes deve ser nomeada usando símbolos do LEL </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>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 </li></ul></ul>Integrando NFRs em Diagramas de Classes
  44. 44. Integrando NFRs em Diagramas de Classes
  45. 45. <ul><ul><li>Inicialmente, pega-se uma classe do diagrama, em qualquer ordem </li></ul></ul><ul><ul><li>Em seguida, procura-se em todos os grafos NFRs a ocorrência desse símbolo </li></ul></ul><ul><ul><li>Em cada grafo que o símbolo apareça, deve-se identificar as operacionalizações estáticas e dinâmicas para este grafo </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Caso não esteja, deve-se adicionar novas operações e atributos a classe </li></ul></ul><ul><ul><li>A inserção de novas operações e atributos muitas vezes requer uma nova análise </li></ul></ul>Integrando NFRs em Diagramas de Classes
  46. 46. <ul><ul><li>1. Classes criadas para satisfazer um NFR deve ter seu nome seguido de um link para rastreabilidade, no padrão: {NFR [LEL symbol]} </li></ul></ul><ul><ul><li>A classe FMCP foi criada observando-se a classe Control Panel </li></ul></ul><ul><ul><li>Procurou-se nos grafos NFRs pelo símbolo </li></ul></ul><ul><ul><li>Observou-se duas operacionalizações dinâmicas – Set Password e Ask Password </li></ul></ul><ul><ul><li>Como não foi encontrado nada na classe Control Panel para satisfazer esses NFRs, criou-se a subclasse Facility Manager Control Panel - FMCP </li></ul></ul>Heurísticas de Como Usar Didagramas de Classes para Tratar NFRs
  47. 47. <ul><ul><li>2. Adjacente a cada operação incluída para satisfazer um NFR, deve-se adicionar um link para a perspectiva não-funcional </li></ul></ul><ul><ul><li>Como na primeira heurística, esse procedimento reforça a rastreabilidade do modelo </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Essa heurística é usada para tratar restrições operacionais que alguns NFRs impõem </li></ul></ul><ul><ul><li>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 </li></ul></ul>Heurísticas de Como Usar Didagramas de Classes para Tratar NFRs
  48. 48. Heurísticas de Como Usar Didagramas de Classes para Tratar NFRs
  49. 49. <ul><ul><li>A integração de NFRs no diagrama de sequência e colaboração é feita examinado cada classe do diagrama de classes </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Deve-se representar as novas mensagens juntas as prés e pós condições nos diagramas onde foram adicionadas para tratar os NFRs </li></ul></ul><ul><ul><li>As mensagens também devem conter os links de rastreabilidade, como visto anteriormente </li></ul></ul>Integrando NFRs em Diagramas de Sequência e Colaboração
  50. 50. Integrando NFRs em Diagramas de Sequência e Colaboração
  51. 51. <ul><ul><li>Para comprovar o uso da estratégia, foram realizados 3 estudos de casos </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>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 </li></ul></ul>Usando a Estratégia
  52. 52. Usando a Estratégia <ul><ul><li>É fácil observar que todos os 3 estudos de caso apresentaram um número considerável de mudanças nos modelos conceituais analisados </li></ul></ul>
  53. 53. <ul><ul><li>Erros ao tratar os NFRs são os mais caros e difíceis de corrigir </li></ul></ul><ul><ul><li>A maioria dos métodos na engenharia de software não tratam os NFRs de uma maneira explicita </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>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 </li></ul></ul>Conclusões
  54. 54. <ul><ul><li>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) </li></ul></ul>Referência

×