Artigo Transp Sw

REQUISITOS NÃO FUNCIONAIS: DA ELICITAÇÃO AOS MODELOS CONCEITUAIS [email_address] PUC-RJ TRANSPARÊNCIA DE SOFTWARE

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

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

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

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

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

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

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

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

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

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

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

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

Construção da Perspectiva Não - Funcional

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

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

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

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

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

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

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

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

Usando LEL Como Apoio na Elicitação dos NFRs

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

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

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

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

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

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: Decompondo a raíz usando abordagem top-down 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

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: Comparar todos os grafos do mesmo tipo, procurando por possíveis interdependências. Ex: todos os NFRs sobre Safety Comparar todos os grafos que são classificados na base de conhecimentos com NFRs possivelmente conflitantes. Ex: Segurança x Usabilidade Comparar par a par todos os grafos que não foram comparados aplicando-se as heurísticas anteriores. Identificando e Resolvendo Conflitos

Identificando e Resolvendo Conflitos

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

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

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

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

Integrando NFRs nos Casos de Uso

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

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

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

Integrando NFRs em Diagramas de Classes

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

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

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

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

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

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

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

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

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

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

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Artigo Transp Sw (8)

Mais de transparenciadesoftware (9)

Artigo Transp Sw