UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
Marcela Balbino Santos de Moraes
mbsm@cin.ufpe.br
Processo de Engenharia de Requisitos e Linhas de Produto de
Software
Marcela Balbino Santos de Moraes
mbsm@cin.ufpe.br
Processo de Engenharia de Requisitos e Linhas de Produto de Software
Trabalho apresentado à disciplina de Engenharia de Requisitos do Centro de Informática da Universidade Federal de Pernambuco como requisito para a obtenção de seus créditos.
Orientador: Prof. Ph.D Jaelson Brelaz de Castro
Recife 15/07/2008
RESUMO
Com o aumento das capacidades de produção das empresas, cresce a necessidade por sistemas de maior complexidade e qualidade. Desta forma, o mercado busca por mudanças que viabilizem as necessidades exigidas aos sistemas atuais. Neste contexto, Linha de Produto de Software surgiu como um paradigma de desenvolvimento de software importante, porém tal paradigma apresenta um contexto mais complexo do que sistemas únicos, havendo a necessidade de empregar-se soluções confiáveis de obtenção de requisitos completos e consistentes. Estas soluções podem ser obtidas com processos sistemáticos de Engenharia de Requisitos, processos estes que variam de acordo com as diferentes situações da Linha de Produto de Software. Sendo assim, este trabalho visa a investigação do cenário do emprego de processos consolidados de Engenharia de Requisitos em Linhas de Produto de Software, bem como resume a abordagem de Model-Driven Development (Desenvolvimento Orientado a Modelos ou MDD) em Linhas de Produto de Software focando a Engenharia de Requisitos.
Palavras-chave: Processos de Engenharia de Requisitos, Linhas de Produto de Software, MDD.
LISTA DE FIGURAS
Figura 1: Modelo Espiral do Processo de Engenharia de Requisitos. Fonte: [Kotonya, 1998].
Figura 2: Processo de Elicitação de Requisitos. Fonte: [Kotonya, 1998].
Figura 3: Processo de Análise e Negociação de Requisitos. Fonte: [Kotonya, 1998].
Figura 4: Processo de Revisão de Requisitos. Fonte: [Kotonya, 1998].
Figura 5: Estágios do Processo de Gerenciamento de Mudanças. Fonte: [Kotonya, 1998].
Figura 6: Atividades essenciais da Linha de Produto de Software. Fonte: [Clements, 2002].
Figura 7: Ciclo de Vida do VODRD. Fonte: [Mannion, 1998].
Figura 8: Exemplo de Modelo de Features com Ligação a Componentes. Fonte: [Pashov, 2004].
Figura 9: Tipos de Caso de Uso. Fonte: [Gomma, 2005].
Figura 10: Natureza Complementar Entre o Modelo de Features e o de Casos de Uso. Fonte:
[Kovacevic, 2007].
Figura 11: Modelo de Feature em FeatRSEB. Fonte: [Kovacevic, 2007].
Figura 12: Modelo de Variabilidade Ortogonal em Casos de Uso. Fonte: [Kovacevic, 2007].
Figura 13: Gráfico and/or de Decomposição de Metas. Fonte: [Kovacevic, 2007].
Figura 14: Relacionamento Entre Modelos, Meta Modelos e Meta Meta Modelos. Fonte:
[Kovacevic, 2007].
Figura 15: Exemplo de Como Relações n-para-n Entre Features e Componentes Podem Ser Separadas por Responsabilidades. Fonte: [ Kovacevic, 2007 ].
Figura 16: Visão do Modelo de Features (CIM) Para a Arquitetura de Software (PIM). Fonte: [ Kovacevic, 2007 ].
LISTA DE TABELAS
Tabela 1 – Características Suportadas e Não Suportadas Pela a Abordagem. Fonte: [ Kovacevic, 2007 ].
GLOSSÁRIO
Features: características do sistema visíveis ao usuário.
Assets: artefatos.
Core Assets: artefatos básicos.
Stakeholders: todos direta ou indiretamente afetados pela produção do sistema.
RiSE: Grupo de Pesquisa de Reuso em Engenharia de Software, coordenado pelo Profº Silvio Meira.
SUMÁRIO
1 INTRODUÇÃO ... 7
2 PROCESSO DE ENGENHARIA DE REQUISITOS ... 9
2.1 ELICITAÇÃO ... 10
2.2 ANÁLISEENEGOCIAÇÃO ... 11
2.3 DOCUMENTAÇÃO ... 12
2.4 VALIDAÇÃO 14
3 LINHAS DE PRODUTO DE SOFTWARE ... 16
4 PROCESSO DE ENGENHARIA DE REQUISITOS NO ÂMBITO DE LPS ... 18
4.1 TÉCNICASUTILIZADASDURANTEOPROCESSODEENGENHARIADEREQUISITOSEM LPS ... 20
4.1.1 Análise de domínio 20
4.1.2 Ponto de vista( view points ) 21
4.1.3 Features 21
4.1.4 Casos de uso(use cases) 23
4.1.5 Rastreabilidade 24
4.1.6 Baseada em features e casos de uso 24
4.1.7 Variabilidade ortogonal 25
4.1.8 Baseada em metas 26
4.2 LPS EAABORDAGEM MODEL-DRIVEN DEVELOPMENT(MDD) COMFOCOEM ER ... 27
4.2.1 Relação entre MDD e LPS com base nos requisitos 29
4.2.2 Abordagens de MDD em Engenharia de Requisitos 30
4.2.2.1 Abordagens não orientadas a aspectos 32
4.2.2.2 Abordagens orientadas a aspectos 36
5 CONCLUSÃO ... 37
REFERÊNCIAS...39
1 INTRODUÇÃO
Com o decorrer dos anos o avanço tecnológico fez-se presente, e com ele a necessidade crescente de sistemas bem projetados e de qualidade. Neste contexto, tem-se no reuso uma forma de busca pelo aumento de qualidade, produtividade e diminuição de custos no desenvolvimento de software.
O reuso é uma prática que surgiu em 1968 durante a conferência da NATO de engenharia de software,onde McIlroy [McIlroy, 1968], em seu revolucionário artigo, intitulado: “Mass Produced Software Components”, apresentou a tese que dizia: “a indústria de software é fracamente fundada e um aspecto dessa fraqueza é a ausência de uma indústria de componentes de software” (pág. 80).
O autor propunha investigar técnicas de produção em massa de software, conforme algumas idéias da construção industrial. Nesta época o grande foco era a crise que a produção de software sofria, onde dentre os motivos da crise destacava-se os custos de desenvolvimento. Neste cenário de reuso surgiu a idéia de Linhas de Produto de Software(LPS), cuja definição segundo o Software Engineering Institute(SEI) [SEI, 2008]é: um conjunto de software que partilham de políticas comuns, apresentando características que satisfaçam as necessidades específicas de um determinado segmento de mercado, e que são desenvolvidos a partir de uma base comum de artefatos.
A reutilização de software é um aspecto critico para empresas interessadas em melhorias de qualidade e produtividade [Krueguer, 1992]. A qualidade pode ser melhorada por reusar todas as formas de experiências, incluindo produtos e processos, como também modelos de qualidade e produtividade. Por outro lado, a produtividade pode ser otimizada através da reutilização de experiências existentes, ao contrário de começar do início.
Através dos anos, diversos trabalhos de pesquisa, incluindo relatório de empresas [Endres, 1993; Bauer, 1993; Griss, 1995; Joos, 1994], pesquisas informais [Frakes, 1994] e estudos empíricos [Rine, 1997; Morisio, 2002; Rothenberger, 2003] têm mostrado que, um modo eficiente de se obter os benefícios da reutilização é adotar um processo de reuso. Entretanto, os processos existentes de reutilização apresentam problemas cruciais, como, por exemplo, lacunas em importantes atividades como o desenvolvimento para e com reuso, além de dar mais ênfase sobre algumas atividades específicas (análise, projeto e implementação) [Almeida, 2005]. Mesmo hoje, com as idéias de Linhas de Produtos de Software, ainda não existe nenhum consenso entre as
atividades (entradas, saídas e artefatos) e os requisitos que um processo efetivo de reutilização deve ter. Sendo assim, uma das grandes preocupações no reuso é com a obtenção de requisitos através de processos de Engenharia de Requisitos bem definidos, visando principalmente a diminuição de custos, já que a obtenção dos requisitos representam cerca de 15 % dos custos de desenvolvimento de um software [Kotonya, 1998].
Com processos de Engenharia de Requisitos de elevado nível de maturidade é possível desenvolver software com baixos custos, alta produtividade e diminuição do tempo de entrega dos produtos, características essenciais a LPS [Pohl, 2005], além disso requisitos de software são a base a partir da qual a qualidade é medida. Desta forma, a falta de conformidade aos requisitos significa falta de qualidade [Carvalho, 2001]. Desse modo, é substancial o alto nível de maturidade que deve apresentar os processos de Engenharia de Requisitos(ER) na constituição de LPS, tendo em vista a importância dos requisitos dentro do processo de desenvolvimento, não só para melhorar a qualidade do produto, mas também para influenciar em outros fatores cruciais para as Linhas de Produto. Porém, alcançar o nível ideal neste processo é algo extremamente difícil e que é influenciado por uma série de fatores, como: o grau de conhecimento da equipe, além de fatores sociais e organizacionais . Tais fatores tornam-se ainda mais críticos quando trata-se de LPS, já que o desenvolvimento das mesmas envolve grande quantidade de stakeholders. Estes por sua vez apresentam objetivos diferentes, o que inevitavelmente acarretará em problemas na definição dos requisitos, tendo em vista que requisitos prioritários para alguns podem ser completamente descartáveis para outros.
Em LPS o processo de Engenharia de Requisitos deve não só descobrir os requisitos essenciais para toda Linha de Produto, como também definir os requisitos específicos para partes das LPS de acordo com a plataforma de reuso, estes destacam-se como aspectos cruciais do processo de ER no contexto de LPS.
De acordo com o que foi apresentado, este trabalho fará uma abordagem do cenário dos processos de Engenharia de Requisitos em Linhas de Produto de Software, abordando o que foi realizado na área até o presente momento. Assim, o capítulo 2 aborda o Processo de Engenharia de Requisitos, o capítulo 3 apresenta o que é Linhas de Produto de Software, bem como suas caracterísiticas, o capítulo 4 mostra o cenário de Processos de Engenharia de Requisitos com foco no contexto de linhas de Produto de Software, o capítulo 5 apresenta as considerações finais e o capítulo 6 por fim ilustra as referências utilizadas na composição do trabalho.
2 PROCESSO DE ENGENHARIA DE REQUISITOS
A engenharia de requisitos de sistemas de software é o processo para descobrir qual o propósito do sistema através da identificação dos stakeholders e de suas necessidades, e documentar estes em uma forma que seja conveniente para análise, comunicação, e posterior implementação [Nuseibeh, 2000]. Processos de ER caracterizam-se por um conjunto de atividades, podendo estas serem estruturadas ou não, de acordo com o grau de maturidade do processo, os estruturados não seguem uma metodologia rígida, dependem do nível de conhecimentos da equipe envolvida no processo, enquanto que o estruturado apresenta alguma metodologia de análise, sendo portanto mais independentes do julgamento inicial de cada componente das equipes. Além disso, processos em Engenharia de Requisitos podem ser considerados como um conjunto organizado de atividades que transformam entradas em saídas, onde descrições de processos encapsulam conhecimento e permitem que sejam reusados.
De acordo com Kotonya [Kotonya, 1998] são diversos os fatores que contribuem para a variabilidade dos processos de engenharia de requisitos.
• Maturidade Técnica: As tecnologias e métodos utilizados para engenharia de requisitos variam de uma organização para outra;
• Cultura organizacional: A cultura de uma organização tem um importante efeito em todos os processos de negócio e, como a cultura varia, assim também o processo de engenharia de requisitos;
• Envolvimento das disciplinas: Os tipos de disciplinas de engenharia e gerencial envolvidas na engenharia de requisitos variam de uma organização para outra;
• Domínio de aplicação: Diferentes tipos de sistemas de aplicação necessitam de diferentes tipos de processos de engenharia de requisitos.
Segundo o Processo de Engenharia de Requisitos de Kotonya [Kotonya, 1998], as atividades constituintes do mesmo são dubdivididas em quatro:
● Elicitação;
● Análise e Negociação;
● Documentação;
Figura 1: Modelo Espiral do Processo de Engenharia de Requisitos. Fonte: [Kotonya, 1998].
2.1 ELICITAÇÃO
A elicitação consiste da descoberta dos requisitos, cabendo a mesma a tarefa de identificar os fatos que compõem os requisitos do sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado pelo software.
A elicitação de requisitos é a primeira atividade a ser desenvolvida na engenharia de requisitos. Na elicitação busca-se descobrir os requisitos do sistema, normalmente obscuros, vagos e confusos no início do desenvolvimento de um sistema de software [Johnson, 1996]. Nessa etapa, usuários e desenvolvedores trabalham em conjunto para definir o problema a ser solucionado, enfocando principalmente os serviços que o sistema deve oferecer.
Várias dificuldades podem ser encontradas na fase de elicitação, o que conseqüentemente ocasionará erros na obtenção dos requisitos, estas dificuldades são causadas por:
● Idéias imprecisas que os usuários têm do sistema;
● Dificuldades dos usuários em descreverem seu conhecimento sobre o domínio do problema;
● Diferentes pontos de vista entre usuários e analistas;
● Antipatia do usuário com o sistema, negando-se a fazer parte da etapa de elicitação.
A elicitação é uma atividade dotada de um processo bem definido como pode ser visto na figura 2, no qual inicialmente definem-se os objetivos organizacionais, incluindo objetivos gerais do negócio, um descrição geral do problema a ser resolvido, porque o sistema é necessário e suas limitações, em seguida deve-se adquirir informações de background do sistema incluindo informações acerca da organização onde o sistema será instalado, o domínio de aplicação do sistema e informação acerca de outros sistemas existentes, depois disso a grande quantidade de conhecimento que foi coletada nos estágios anteriores devem ser organizadas e colocadas em ordem e por fim os stakeholders do sistema são consultados para descoberta de seus requisitos.
Figura 2: Processo de Elicitação de Requisitos. Fonte: [Kotonya, 1998].
2.2 ANÁLISE E NEGOCIAÇÃO
Na análise são descobertas as inconsistências e incompletudes dos requisitos que foram anteriormente elicitados, ela ocorre intercaladamente com a elicitação, pois os problemas são descobertos com a elicitação. A análise de requisitos envolve a quebra de requisitos de alto nível em requisitos funcionais detalhados.
Alguns cheques são realizados durante esta etapa para que seja possível a descoberta dos erros. Encontrados os erros é necessária uma abordagem para resolução dos requisitos defeituosos, chegando-se a uma negociação de quais decisões serão tomadas para solucionar os problemas dos requisitos, isso fica claro na figura 3.
Figura 3: Processo de Análise e Negociação de Requisitos. Fonte: [Kotonya, 1998].
2.3 DOCUMENTAÇÃO
O documento de requisitos de software ou especificação de requisitos de software, para Sommerville [Sommerville, 2003], “é a declaração oficial do que é exigido dos desenvolvedores de sistema”. O documento de requisitos é o documento formal que será usado para comunicar os requisitos a seus usuários, como: clientes, engenheiros e gerentes. É de fundamental importância que haja qualidade no documento de requisitos, pois esta característica afeta diretamente o sucesso do projeto. Para que tal qualidade seja alcançada faz-se necessário o uso de padrões para confecção do documento. No documento de requisitos são descritos:
● Os serviços e funções que o sistema deve prover;
● As limitações sobre as quais os sistema deve operar;
● Propriedades gerais do sistema, isto é limitações nas propriedades emergentes;
● Definições de outros sistemas com o qual o sistema deve se integrar;
● Informações sobre o domínio da aplicação do sistema, ex., como calcular um certo tipo de computação;
● Limitações nos processos usados para desenvolver o sistema;
● Descrições sobre o hardware no qual o sistema irá executar.
12
São vários os riscos a serem evitados no documento de requisitos, segundo Lawrence [Lawrence 2001] eles são:
● Não incluir um requisito crucial: deixar de incluir um requisito vital pode implicar em grande volume de retrabalho; se o problema é descoberto apenas na fase de testes, podem ser necessárias mudanças na estrutura do sistema e nos componentes previstos;
● Falta de inspeções nos requisitos: o custo da remoção de defeitos em requisitos cresce geometricamente ao longo do ciclo de desenvolvimento. Inspeções podem detectar defeitos precocemente, ainda na fase de requisitos, diminuindo o retrabalho e custos associados;
● Representação inadequada de clientes: se uma classe de clientes ou usuários não foi representada no conjunto de interessados, é bastante provável que suas necessidades em relação ao software não estejam presentes no documento de requisitos;
● Busca da perfeição nos requisitos antes de iniciar a construção do software: deve-se assumir que alterações em requisitos são inevitáveis, e, portanto é necessário um efetivo controle de mudanças. Devem-se identificar áreas de incerteza, mantendo atenção nas solicitações de alteração e buscando o preenchimento de lacunas antes da implementação estar concluída;
● Modelar apenas aspectos funcionais: a ênfase na elicitação de requisitos costuma ser maior em relação a requisitos funcionais; atributos não funcionais, no entanto, são relacionados à qualidade que o software deve apresentar e não são facilmente modelados em casos de uso. O software, além de apresentar as funcionalidades necessárias, deve apresentar características relacionadas à facilidade de uso, desempenho, tolerância a falhas, segurança e integridade. Outra característica importante para a evolução é a estruturação adequada dos componentes, voltada à facilidade de manutenção.
● Estabelecer requisitos não implementáveis ou não evolutíveis: deve-se considerar restrições de hardware e software para o projeto em questão, principalmente para projetos de software embarcado (ou embutido). Em projetos deste tipo, restrições relacionadas à capacidade de armazenamento e velocidade devem estar sempre presentes, pois o custo final do produto deve estar afinado com o mercado ao qual ele se destina e também precisa ser competitivo.
● Definir requisitos incorretamente: se a definição está incorreta, a implementação também estará. Provavelmente o problema só será detectado na fase de validação do software ou após liberação da versão. Os requisitos devem ser validados pelos clientes e usuários antes da fase de desenho iniciar.
2.4 VALIDAÇÃO
A validação apresenta características semelhantes a análise, porém na validação são avaliados aspectos adicionais ao já avaliados na análise, além disso nesta etapa faz-se a verificação a partir do documento de requisitos final, sendo assim aspectos como estrutura, organização bem como o padrão do documento é verificado. Sendo assim, o objetivo da validação é verificar se o documento de requisitos é uma descrição aceitável do sistema a ser implementado, ou seja, A preocupação maior desta fase é com a qualidade do documento de requisitos produzido [Rodrigues, 2006].
Para efetivar a validação algumas técnicas são utlizadas, dentre elas estão:
● Revisões : Na revisão o documento de requisitos é distribuído entre uma equipe de revisores, estes o analisarão para identificar possíveis problemas, posteriormente uma reunião é realizada para definir as ações que serão tomadas quanto aos requisitos defeituosos. Este processo de revisão pode ser visto na figura 4.
● Validação por Protótipos: Com o auxílio de um stakeholder, um desenvolvedor tem a possibilidade de construir protótipos para validar um conjunto de requisitos. Este tipo de validação não se restringe a realização de discussões de interfaces com o usuário. Um protótipo simula uma parte do sistema e pode ser desenvolvido de diversas maneiras.
Figura 4: Processo de Revisão de Requisitos. Fonte: [Kotonya, 1998].
Além das atividades mostradas no processo espiral segundo [Kotonya, 1998], a Engenharia de Requisitos possui uma atividade importantíssima, a Gerência de Requisitos. O gerenciamento de requisitos é o processo de gerenciar as mudanças nos requisitos do sistema.
Mudanças de requisitos ocorrem durante todo o processo de desenvolvimento do sistema, desde a elicitação até o sistema está em serviço, sendo mais difícil e custoso de gerir as mudanças quando as mesmas são descobertas em fases avançadas do processo de desenvolvimento. O gerenciamento de mudanças permite que informação similar seja coletada para cada mudança proposta e que um julgamento geral seja realizado sobre os custos e benefícios das mudanças propostas.
As principais preocupações do gerenciamento de requisitos são:
● Gerenciar mudanças nos requisitos que foram concordados;
● Gerenciar o relacionamento entre requisitos;
● Gerenciar as dependências entre os documentos de requisitos e outros documentos produzidos no processo de engenharia de sistemas.
O processo de gerenciamento de mudanças irá ocorrer segundo uma série de fatores: errors, conflitos e inconsistências nos requisitos; evolução do conhecimento do cliente/usuário-final do sistema; problemas técnicos, de custo e prazo; mudança na prioridade dos clientes; mudanças ambientais; mudanças organizacionais. Ao detectar-se algum fator de mudança o processo de gerenciamento será então executado segundo os passos mostrados na figura 5.
Figura 5: Estágios do Processo de Gerenciamento de Mudanças. Fonte: [Kotonya, 1998].
3 LINHAS DE PRODUTO DE SOFTWARE
Embora tendências tecnológicas e novos paradigmas de desenvolvimento surjam, complexos sistemas de reutilização sistemática de software continuam a ser um objetivo difícil.
Como consequência há a necessidade de conceber estratégias eficazes, permitindo assim reutilização em grande escala e superação dos riscos envolvidos no uso de novas tecnologias [Ayala, 2006]. Neste contexto de busca de novas estratégias para concepção eficaz de reuso surgiu no final da década de 90 o conceito de Linhas de Produto de Software, que é relativamente novo comparado ao de reuso. LPS surgiram como um processo mais efetivo de desenvolvimento e segundo [Gomaa, 2005] é um conjunto de sistemas intensivos de software, que compartilham um conjunto comum de features para satisfazer necessidades especificas de um segmento de mercado particular, e que são desenvolvidos de um conjunto de artefatos básicos, em uma maneira bem definida.
Engenharia de Software é uma disciplina que está em constante evolução, em busca de soluções melhores e mais eficientes para resolver problemas críticos de desenvolvimento de sistemas tais como: tempo, custo, qualidade e flexibilidade. Os tradicionais métodos de desenvolvimento de sistemas são insuficientes para resolver desafios de mudança e crescimento rápido das necessidades. Esta dita a necessidade de melhorar a reusabilidade do desenvolvimento dos artefatos[Kovacevic, 2007. Assim, SPL pode contribuir para minimizar custos e encurtar o tempo de entrega, caso identificação, representação e composição das variações sejam suportadas por práticas de desenvolvimento de software de forma automática ou semi-automático [Kovacevic, 2007].
Para constituição de Linhas de Produto de Software são necessárias três atividades principais [SEI, 2008]: desenvolvimento de core assets, desenvolvimento dos produtos e gerenciamento.Tais atividades são ilustradas na figura 6. Para o sucesso das LPS um fator é crucial, a dominação das áreas práticas que caracterizam-se como um conjunto de atividades que as organizações devem seguir para alcançar o sucesso repetitivo em Linhas de produto de Software.
Dentre estas áres, pode-se citar a Engenharia de Requisitos, que como será visto na próxima seção, tem papel importante no sucesso de LPS.
Figura 6: Atividades Essenciais da Linha de Produto de . Fonte: [Clements, 2002].
Para construção de LPS é necessário que as empresas adotem práticas efetivas de reuso, práticas essas cujo custo inicial de aplição são altos, mas que a médio ou longo prazo automatizará o desenvolvimento de produtos da empresa, acarretando em entregas mais rápidas, diminuição dos custos de produção e qualidade dos produtos desenvovidos. Por estes motivos, a escolha pela construção de bases de reuso que favoreçam o desenvolvimento de LPS vem sendo largamente adotadas pelas empresas, que vêem em LPS uma forma de automatizar ou semi-automatizar os processos de desenvolvimento de produtos de software. Porém, a criação de uma Linha de Produtos de Software é uma decisão de negócio que não deve ser feita aleatoriamente. Qualquer organização que lança uma linha de produtos deve ter em mente objetivos específicos e de negócio sólidos do que se pretende alcançar através das práticas de LPS [SEI, 2008].
4 PROCESSO DE ENGENHARIA DE REQUISITOS NO ÂMBITO DE LPS
Para a construção de LPS com alto grau de sucesso faz-se necesária a utilização de práticas bem definidas de reuso, para isso deve-se ter uma base arquitetural bem definida, profundo conhecimento do domínio da aplicação e artefatos desenvolvidos com orientação prévia ao reuso.
Sendo assim, dentro deste contexto um processo bem definido de Engenharia de Requisitos é crucial para construção de artefatos de fato reusáveis, já que ainda hoje a definição de requisitos consistentes, completos e corretos é a causa da maioria das falhas de software. Por isso, em Linhas de Produto de Software é realizada uma extensa análise de requisitos, bem como é verificada a viabilidade dos mesmos dentro das LPS [SEI, 2008], tais requisitos são divididos em dois grupos:
requisitos comuns, que são os requisitos para toda linha de produtos e os requisitos variáveis, específicos para determinados subconjuntos da linha.
Dentro das atividades dos processos de Engenharia de Requisitos há certas especificidades aplicadas em particular a LPS [SEI, 2008]:
● Elicitação: Deve capturar antecipadamente variações explícitas que ocorrerão ao longo do tempo de vida da linha de produtos. Isto significa a necessidade de envolvimento de mais stakeholders do que seria necessário em sistemas únicos.
● Análise: Deve encontrar e identificar variações comuns nos requisitos elicitados. Esta análise deve envolver um mecanismo de resposta mais vigoroso para as solicitações, apontando onde um sistema particular pode encontrar economia se estiver hábil para usar mais requisitos comuns e menos requisitos únicos. Capturar requisitos para um grupo de sistemas pode requerer uma análise sofisticada e negociação intensiva para a escolha de requisitos comuns e variáveis. Uma das técnicas muito utilizadas nesta atividade para LPS é a análise de domínio.
● Especificação: É realizada a documentação dos requisitos comuns à linha de produto,bem como evidenciando o conjunto de exigências e necessidades especificas de cada produto. A especificação dos requisitos comuns da linha de produtos deve incluir expressões simbólicas que permita que os requisitos específicos de um produto possam ser preenchidos, expandidos ou instanciados.
● Verificação: inclui uma ampla concentração de revisores e ocorre em estágios. Em primeiro lugar, os requisitos comuns da linha de produtos devem ser verificados. Em seguida, quando um produto é desenvolvido ou atualizado, os requisitos específicos do produto devem ser verificados. Nesta fase, os requisitos comuns da linha de produtos também devem ser verificados para certificar-se de que eles fazem sentido para este produto.
● Gerenciamento: deve apresentar subsídios para tratar as atividades comuns e variáveis do processo de engenharia de requisitos. Políticas de gerenciamento de mudanças devem prever um mecanismo formal para propor alterações na linha de produtos e apoiar a avaliação sistemática do modo como alterações propostas terão um impacto na linha. Políticas de gerenciamento de mudanças governam como as mudanças nos requisitos da linha de produtos são propostas, analisadas e revisadas. O acoplamento entre os requisitos da linha de produtos e os core assets é identificada através da utilização de relações de rastreabilidade entre os requisitos e seus core assets associados.
Uma diferença significativa em requisitos para linhas de produtos envolve uma rápida passagem dos requisitos iniciais para a captação dos requisitos de alto nível, afetando desta forma o design inicial, ou seja, o projeto arquitetural. O propósito desta passagem é a de comprimir o tempo de entrega inicial, possibilitando a demonstração da viabilidade dos requisitos e estabelecendo a credibilidade do produto na linha, permitindo assim justificar o investimento inicial.
Como ficou claro até agora, a Engenharia de Requisitos desempenha um papel fundamental na determinação de viabilidade de um produto como parte da LPS, esta é uma actividade contínua que faz parte do plano de negócios de uma linha de produto. No contexto de linha de produto é possível utilizar-se da análise dos requisitos específicos para estimar o custo do desenvolvimento do produto candidato a integrar a linha de produtos, requisitos tais quais tendem muitas vezes a generalizar-se por toda linha. Esse é o principal mecanismo para a evolução das LPS ao longo do tempo. Atividades de ER em particular elicitação e análise vão servir de apoio ao plano de negócios, facilitando na determinação precisa dos requisitos dos produtos.
4.1 TÉCNICAS UTILIZADAS DURANTE O PROCESSO DE ENGENHARIA DE REQUISITOS EM LPS
São várias as técnicas utilizadas durante o Processo de Engenharia de Requisitos para LPS, isto visa ajudar na obtenção dos requisitos. Abaixo algumas delas serão definidas, bem como apresentados alguns exemplos das mesmas.
4.1.1 ANÁLISE DE DOMÍNIO
A análise de domínio pode ser utilizada para aumentar o grau de exigências referentes a aplicação na fase de elicitação, a fim de identificar e antecipar mudanças, possibilitando a determinação de similaridades e variações nos produtos da linha de produtos, dando apoio à criação de arquiteturas robustas [SEI, 2008].
Uma dessas técnicas, o FODA, foi incorporado recentemente em uma nova abordagem de Engenharia de Requisitos para linhas de produtos [SEI, 2008]. O FODA possui atividades, papéis, entradas e saídas bem definidos, e alguns produtos de trabalho são determinados com diretrizes. Seu principal produto é o modelo de features, que é útil para a representação do domínio, em que variabilidade e comunhão são identificadas. Além disso, modelo de features é entrada de outros modelos no processo [Kang, 1990]. O FODA é constituído de duas fases: análise de contexto, cujo foco é o escopo do domínio a ser analisado, considerando restrições de projeto e informações específicas disponíveis sobre o mesmo; e modelagem do domínio, que identifica e modela as principais similaridades e variabilidades das aplicações do domínio. No entanto, existem algumas lacunas no processo, como segue. Ele não descreve como realizar a elicitação, ele apenas diz que features comuns e variáveis devem ser capturados. A validação do modelo de features é definida, mas não possui diretrizes. Não são definidos atividades para o gerenciamento e negociação de requisito. Os requisitos são documentados como modelos de features e entidade-relacionamento, que são representações de alto nível de abstração. Assim, a sua especificação não é suficiente para orientar a equipe de desenvolvimento.
4.1.2 PONTO DE VISTA (VIEWPOINTS)
Esta técnica pode ser utilizada para apoiar a modelagem das linhas de produto, priorizando requisitos importantes do ponto de vista dos stakeholders. Esta modelagem é baseada no reconhecimento de que um sistema tem que satisfazer as necessidades e expectativas dos muitos interessados nele, sob as perspectivas próprias de cada stakeholder.
Em um viewpoint pode conter, além dos requisitos, informações sobre o ambiente, domínio do sistema, fontes e razões dos requisitos [Sommerville, 1997].
Um exemplo de método orientado a viewpoints é o VODRD (Viewpoint-Oriented Domain Requirements Definition) [Mannion, 1998]. O VODRD é um método iterativo para análise de requisitos do domínio a partir da perspectiva dos stakeholders. Suas atividades são conduzidas em quatro etapas: definir escopo do domínio (scope domain), caracterizar domínio (characterize domain), documentar pontos de vista (document viewpoints), e analisar pontos de vista do documento (analyze document viewpoints). Na figura 8 é explicitado o ciclo de vida do VODRD.
Figura 7: Ciclo de Vida do VODRD. Fonte: [Mannion, 1998].
4.1.3 FEATURES
Features são características, qualidades ou aspectos do sistema visíveis pelo usuário [Kang, 1990]. Sua modelagem é definida de maneira abstrata, sendo útil para parametrização dos produtos
do domínio, possibilitando a identificação de diferenças entre aplicações através de refinamentos.
Assim, o modelo de features pode ser utilizado por analistas de requisitos para negociar as funcionalidades das aplicações com os usuários. Os desenvolvedores podem utilizar o modelo de features para identificar o que necessita ser parametrizado em outros modelos e na arquitetura, e como essa parametrização deve ser feita. Além disso, este modelo representa um espaço de decisões para o desenvolvimento de software, em que é possível identificar candidatos de componentes reusáveis [kang, 1998]. Na figura 9 é mostrado um exemplo de aplicação do modelo de features.
Exemplos desta técnica de modelagem são: o método FODA (Feature-Oriented Domain Analysis) [Kang, 1990], que propõe uma modelo de features para linhas de produto, em que são aplicadas primitivas de agregação e generalização para capturar as semelhanças das aplicações no domínio em termos de abstrações e o método FORM (Feature-Oriented Reuse Method) [Kang, 1998], que define a modelagem de features como uma extensão do modelo do FODA [Kang, 1990].
Sua estrutura é direcionada para auxiliar o desenvolvimento da arquitetura do domínio e de componentes.
Figura 8: Exemplo de Modelo de Features com Ligação a Componentes. Fonte: [Pashov, 2004].
4.1.4 CASOS DE USO(USE CASES)
Esta técnica pode ser usada para capturar pontos de variação, bem como descrever requisitos comuns e com variabilidade dentro das Linhas de Produto de Software [SEI, 2008]. Em LPS a utilização de casos de uso sofrem algumas adaptações, o que permitirá representar as variabilidades do domínio, permitindo a instanciação das aplicações.
Um dos métodos que utiliza este tipo de modelagem é o PLUS(Product Line UML-Based Software Engineering) [Gomma, 2005], que descreve a variabilidade do domínio através de casos de uso e modelos de features. O método classifica os casos de uso em três tipos, eles são:
● Casos de uso obrigatórios (kernel), que são necessários para todos os membros da LPS;
● Casos de uso opcionais, que são necessários para apenas alguns membros da LPS;
● Casos de uso alternativos, onde diferentes casos de uso são necessários para diferentes membros da linha de produto.
Além dos casos de uso, os atores também podem apresentar variabilidade. Assim, os atores podem ser opcionais, alternativos ou obrigatórios. Na figura 9 são mostrados os tipos de casos de uso.
Figura 9: Tipos de Caso de Uso. Fonte: [Gomma, 2005].
4.1.5RASTREABILIDADE
Esta técnica pode ser usada para assegurar que a concepção e implementação de um sistema satisfaça os requisitos desse sistema.
As exigências de rastreabilidade são cruciais para determinar o impacto das modificações propostas em um sistema. Sendo assim, requisitos não podem ser gerenciados efetivamente sem rastreamento de requisitos. Um requisito é rastreável se for possível descobrir quem sugeriu o requisito, porque ele existe, quais os requisitos relacionados a ele e como o requisito está relacionado com outras informações tais como: projeto do sistema, implementações e documentação do usuário.
4.1.6 BASEADA EM FEATURES E CASOS DE USO
Diversas abordagens combinam a utilização de features com casos de uso para a obtenção de requisitos em Linhas de Produto de Software. Em geral, essas abordagens partilham da opinião de que modelos de caso de uso e modelo de features tem características distinta, mas objetivos complementares: o modelo de caso de uso é orientado para usuário (engenheiro da aplicação), enquanto que o modelo de features é orientado ao reutilizador (engenheiro de domínio), como ilustrado na figura 10.
Figura 10: Natureza Complementar Entre o Modelo de Features e o de Casos de Uso. Fonte:
[Kovacevic, 2007].
O exemplo mais representativo desta abordagem é o FeatRSEB, nele o modelo de features não é “side-by-side” com o modelo de casos de usos, mas com todos os modelos. O modelo de features provê uma abstrata e concisa sintaxe para expressar similaridades e variabilidades no domínio e é representado por modelo UML, como mostrado na figura 11.
Figura 11: Modelo de Feature em FeatRSEB. Fonte: [Kovacevic, 2007].
4.1.7 VARIABILIDADE ORTOGONAL
Pohl et al. [Pohl, 2005] propõe o Modelo de Variabilidade Ortogonal (MVO), este relaciona as variações dos artefatos de requisitos com pontos de variação, variantes e restrições destas entidades, e explicitamente define a variabilidade das linhas de produtos. Na figura 12 é mostrado o modelo de variabilidade para um modelo de casos de uso.
Figura 12: Modelo de Variabilidade Ortogonal em Casos de Uso. Fonte: [Kovacevic, 2007].
O MVO define variabilidade e restrições no contexto de uma linha de produtos ou em um conjunto de linhas de produtos: uma variante pode ser obrigatória em uma linha de produtos, mas pode ser opcional em outra. Além disso, restrições são válidas para uma ou mais linhas de produtos.
Adicionalmente, o modelo visa facilitar a criação de pontos de vista sobre o documentado de variabilidade e restrições. O Modelo de Variabilidade Ortogonal suporta ainda o raciocínio sobre informações de variabilidade, tais como determinar as sobreposições e as diferenças entre duas linhas de produtos, utilizando uma variante específica.
4.1.7 BASEADA EM METAS
Esta abordagem foca na modelagem da variabilidade a partir da pespectiva do domínio do problema. As metas identificam o porque dos requisitos da Linha de Produto de Software, podendo estes ser funcionais ou não-funcionais.
As metas são representadas por diagramas em árvores de decomposição and/or, um exemplo desta representação é mostrada na figura 13.
26
Figura 13: Gráfico and/or de Decomposição de Metas. Fonte: [Kovacevic, 2007].
Após esta apresentação de algumas das técnicas usadas durante o Processo de Engenharia de Requisitos em Linhas de Produto de Software, este trabalho definirá na próxima seção a abordagem Model-Driven Development, tendo em vista que a mesma apresenta potencial para apoiar o paradigma de Linhas de Produto de Software.
4.2 LPS E A ABORDAGEM MODEL-DRIVEN DEVELOPMENT (MDD) COM FOCO EM ER
A seguir será exibida a abordagem MDD e sua relação com LPS, focando em ER.
O desenvolvimento de grandes sistemas de software é difícil, tendo em vista que tais sistemas estão constantemente sujeito a mudanças, havendo a necessidade de se adaptar de maneira ágil e flexível as mesmas [Kovacevic, 2007]. Destes fatores surge a necessidade de se desenvolver novas técnicas e paradigmas que viabilizaem a adaptabilidade a mudanças, proporcionando consequentemente diminuição de custos, prazos e aumento de qualidade. Sendo assim, a utilização de Model-Driven Development (Desenvolvimento Orientado a Modelos) e Linhas de Produto de Software com Engenharia de Requisitos busca as melhores práticas para produção de software de
O MDD faz uso sistemático de modelos, especificamente modelos de transformação, onde a idéia é fazer com que o processo de criação de novos software seja automático e facilitem a adaptação rápida na ocorrência de mudança de ambientes. O principal objetivo é a utilização de modelos para elevar o nível de abstração em que os desenvolvedores criam os software, simplificando e formalizando as diversas atividades e tarefas que compõem o ciclo de vida do software. Sendo assim, LPS podem beneficiar-se com o uso de MDD, visto que ambos necessitam de modelos de transformação durante todo ciclo de vida de desenvolvimento de software baseados em requisitos. Isto faz de MDD uma abordagem bem adaptada a Linhas de Produto de Software.
Nos trabalhos referentes a MDD presentes na literatura pode-se identificar modelos, modelos de transformação, meta modelos e meta meta modelos como conceitos básicos, porém neste trabalho será tido como base o conceito adotado pela AMPLE, no qual é verificada a relação entre modelos, meta modelos e meta meta modelos (figura 10).
Figura 14: Relacionamento entre modelos, meta modelos e meta meta modelos. Fonte: [Kovacevic, 2007].
Os modelos representam uma visão particular do sistema ou a visão do sistema como um todo, segundo seu meta modelo que por sua vez deve está em conformidade com o meta meta modelo.
28
Com a evolução dos estudos sobre Desenvolvimento Orientado a Modelos surgiram alguns frameworks e ferramentas de apoio, dentre os mais conhecidos destaca-se o framework Model- Driven Architecture (MDA) [OMG, 2001]. O principal objetivo deste framework é permitir aos desenvolvedores especificar seus sistemas arquiteturais independentemente de plataformas de implementação específicas.
Além de ser apoiada por frameworks e ferramentas diversas, o MDD utiliza-se de Domain Specific Language (DSL ou Linguagens de Domínio Específico), estas são linguagens criadas para problemas de um domínio específico, podendo ser processada com o uso de ferramentas. A DSL permite a especificação de software a partir de um ponto de vista especifico e para um domínio específico.
4.2.1 RELAÇÃO ENTRE MDD E LPS COM BASE NOS REQUISITOS
Uma vez que os grupos de trabalho que abordam MDD, bem como LPS com requisitos são limitados não há um conjunto de métricas bem estabelecidas para possibilitar a comparação entre MDD e LPS, porém pode-se estabelecer uma comparação com base em boas práticas de Engenharia de Software, segundo Kovacevic [Kovacevic, 2007] MDD e LPS possuem em comum a busca pelas seguintes características:
● Evolução: A capacidade de se adaptar a mudanças nos artefatos causada pela mudança de requisitos já existentes ou pela adição ou remoção de requisitos. Esta característica é importante porque as mudanças são inevitáveis nas construção de sistemas, sendo assim os artefatos devem manter sua essências conceitual e estrutural face as mudanças, caso contrário a estrutura dos artefatos será corrompida e os mesmos tornarse-ão inutilizáveis.
● Verificação: Envolve verificar se os artefatos estão de acordo com suas especificações. Isto pode ser verificado com um refinamento progressivo.
● Análise Trade-off: Critérios são relatados para resolução de conflitos. Conflitos entre requisitos são inevitáveis e podem está relacionados a requisitos funcionais e não- funcionais. Estes critérios servirão para ajudar os Engenheiros de Requisitos a encontrar soluções para os conflitos.
● Escalabilidade: É uma caracterísitica desejável porque abordagens de desenvolvimento viáveis devem está bem adaptadas para pequenos e grandes projetos, além disso projetos que
● Rastreabilidade: permite especificar um conjunto de relações que define associações e dependências entre artefatos de software.
● Ferramentas de Suporte: Indica se a abordagem possui alguma ferramenta de suporte a gerência de requisitos, rastreabilidade arquitetural ou evolução. Este suporte deve ocorrer também na verificação de requisitos e na análise trade-off.
4.2.2 ABORDAGENS DE MDD EM ENGENHARIA DE REQUISITOS
Nesta seção será feita uma análise de MDD em ER referente a características como:
evolução, verificação, análise trade-off, rastreabilidade e ferramentas de suporte. Além disso serão explicitadas as seguintes abordagens de MDD focada a requisitos: não orientada a aspectos e orientada a aspectos.
Inicialmente a análise será feita segundo os critérios gerais de Engenharia de Requisitos que se adequam as técnicas de MDD, posteriormente a análise abordará aspectos específicos de ER que são aplicados apenas no contexto de MDD.
Análise das características de acordo com os aspectos gerais de Engenharia de Requisitos em MDD [Kovacevic, 2007]:
● Evolução: Os grandes sistemas de software estão sujeitos a mudanças de requisitos, por conseguinte ser flexível e ágil na adaptação a estas mudanças é imprescindível. Assim, os modelos de requisitos precisam ser capazes de se adaptar a mudanças de maneira fácil. No contexto de MDD, este critério está relacionado com a facilidade de mudar os modelos produzidos durante a especificação de ER, adicionando novos requisitos ou removendo os já existentes.
● Verificação: No contexto de MDD, a verificação é um processo de avaliação do modelo, para determinar se este satisfaz as condições impostas no início do processo de transformação. Isso envolve a avaliação das seguintes propriedades: (i) conformidade e (ii) consistência. Enquanto que modelo de conformidade refere-se à capacidade de verificar se o modelo satisfaz as restrições impostas pelos seus respectivos meta modelos, modelo de consistência refere-se ao processo de manutenção do sistema a partir de modelos de diferentes níveis ou perspectivas. Neste contexto, consistência entre modelos significa que a
30
● informação dada em um modelo específico deveria corresponder à informação dada em outro modelo, em todos os casos em que os dois modelos interagirem ou compartilharem informação. Assim, dois modelos são consistentes quando: (i) não existem contradições entre as informações providas por eles, (ii) não há nenhuma incompletude entre eles.
● Análise Trade-Off: Depois de identificar conflitos com base em requisitos, o tipo de contribuição (positivo, negativo ou "nenhuma") destes requisitos possibilita ter uma melhor compreensão dos conflitos e um melhor entendimento da arquiteteura durante o ciclo de vida do software . A especificação de modelos de requisitos em abordagens MDD pode contribuir para entender a razão dos diferentes requisitos de sistema, bem como compreender o modo como se interrelacionam. A definição e escolha de diferentes linguagens de modelagem, para especificar o srequisitos de sistema, podem ajudar a identificar as suas relações e torná-las explícitas.
● Rastreabilidade: MDD oferece informações intrínsecas básicas, que podem ajudar no apoio a rastreabilidade. Modelos evoluem através de transformações, e estas transformações são sistemáticas e rigorosas, exigindo ferramentas bem definidas para suportar tais transformações. Assim, isso significa que a maior parte das decisões e passos de evolução estão documentados em termos das transformações deles próprios. Esta informação pode, portanto, ser utilizada como entrada para ajudar na rastreabilidade.
● Ferramenta de Suporte: Idealmente, MDD exigiria transformações automáticas, ou seja, ferramentas que implementariam as transformações e os modelos resultantes automaticamente. No entanto, isto só é possível após um primeiro modelo, com toda a informação necessária obtida. Mas a nível de requisitos, tal modelo ainda não existe. A obtenção desse primeiro modelo de requisitos exige um processo sócio-técnico, que envolve decisões de stakeholders, na maior parte do tempo, e elicitação de requisitos.
Análise das características de acordo com aspectos específicos de ER para MDD [Kovacevic, 2007]:
● Linguagens de Suporte a Modelos de Requisitos: Este critério está relacionado com a linguagem utilizada para suportar a especificação do modelo de requisitos. Ele define a forma como os modelos, a partir da abordagem MDD, estão representados. É composto de dois elementos principais: (i) representação dos modelos, e (ii) meta meta modelo utilizado.
● A representação dos modelos pode variar, podendo ser feita como texto, diagramas, esquemas, etc. A representação dos modelos pode tornar mais fácil ou mais difícil de aplicar transformações nos modelos. Uma questão deve ser respondida por este critério: qual é o formato do alvo e da fonte dos modelos, antes e depois das transformações (texto, diagramas, esquemas de XML)? Já o meta meta modelo é usado por duas razões: (1) como o nome auto descreve, ele define a linguagem que é usada para definir o meta modelo, e (2) é importante para a integração do modelo, uma vez que é a base para a transformação entre os meta modelos [Volter, 2006; Kovacevic, 2007]. Neste critério, o interesse basicamente está em responder a seguinte questão: qual é o meta meta modelo utilizado?
● Suporte a Transformação: A transformação é especificada usando uma linguagem de transformação e pode ser automática, semi-automática, ou manual. O principal objetivo de MDD é o de propor uma abordagem tão automática quanto possível; por isso, transformações automáticas são completamente desejáveis (embora nem sempre seja possível). Este critério pode ainda ser decomposto em linguagem de transformação, papéis de transformações, e grau de automatização. Uma linguagem de transformação assume que o modelo fonte está de acordo com o meta modelo e produz um modelo alvo de acordo com um diferente meta modelo. Quanto aos papéis de transformação, estes podem ser diferentes.
As transformações podem ser utilizadas para: (i) aplicar simples aperfeiçoamentos no modelo, no sentido de que mesmo com uma mudança, ele ainda permanece no mesmo nível de abstração, (ii) alterar o modelo transformando-o em um modelo com um nível inferior de abstração. Já o grau de automatização de linguagens de transformação de modelo, refere-se à capacidade de suporte automático as transformações entre os modelos.
4.2.2.1 ABORDAGENS NÃO ORIENTADAS A ASPECTOS
São várias as abordagens de Desenvolvimento Orientado a Modelos não orientada a aspectos, segundo citado em [Kovacevic, 2007] elas são: (1) From Early Requirements to Late Requirements (FELRE), (2) Model-Driven Security (MDS), (3) UML Web Engineering (UWE), (4) Feature-Oriented Component-Based Approach, (5) Template Approach to Mapping Features to Models, (6) Integrating Natural Language Oriented Requirements Models into MDA, (7) ProjectIT.
Como o foco do trabalho é Requisitos em LPS, a abordagem de MDD não orientada a aspectos que será discutida será a (4): Feature-Oriented Component-based Approach (Abordagem Baseada em Componentes Orientada a Features). Nesta abordagem o objetivo é manter um relacionamento estreito entre transformações Computation Independent Model (CIM) e Platform Independent Model (PIM), onde features e componentes são considerados elementos chaves de CIM e PIM, respectivamente. Esta abordagem possui duas características importantes: (i) provê um método para decompor n-para-n relações entre features e componentes em dois grupos de 1-para-n relações; e (ii) propõe uma forma de criar componentes por grupos de responsabilidades que são operacionalizados de features. Estas duas características têm por objectivo resolver dois problemas básicos relacionadas com a transformação de CIM-para-PIM : um é a rastreabilidade entre CIM e PIM, e o outro problema diz respeito a construção de PIM baseado em CIM.
A rastreabilidade entre PIM e CIM é gerenciada pelo conceito de responsabilidades [OMG;
Kovacevic, 2007 ] . As responsabilidades são usadas para separar relações do tipo n-para-n entre features e componentes. Depois n-para-n relações são decompostas em dois conjuntos de 1-para-n relações. Um conjunto contém 1-para-n relações entre features e responsabilidades, o que indica que uma feature pode ser geralmente operacionalizada em várias responsabilidades como está representado na figura 11. A outra contém 1-para-n relações entre componentes e responsabilidades, o que mostra que um componente pode ser atribuído a várias responsabilidades.
Figura 15: Exemplo de Como Relações n-para-n Entre Features e Componentes Podem Ser Separadas por Responsabilidades. Fonte: [ Kovacevic, 2007 ].
O outro problema como dito anteriormente é a construção de PIN baseado em CIM. Muitas vezes a arquitetura de software não existe [ Kovacevic, 2007 ]. Sendo assim, em transformação, a arquitetura de software deve ser construída com base no modelo de features. Para construir a arquitetura de software, esta abordagem apresenta um método em que features são primeiro operacionalizadas em responsabilidades, containers de recursos e interacções entre eles. Em seguida, responsabilidades e containers de recursos são agrupados para formar a arquitetura de software, ao nível PIM.
Na figura 12 é mostrada a visão geral da transformação do modelo de features (CIM) para a arquitetura de software (PIM) . Nela são mostrados dois níveis: (i) o nível de requisitos, onde os requisitos são organizadas em um modelo de features; e (ii) o nível de especificação, onde o programa de especificações são primeiramente particionados em responsabilidades e containers de recursos, com um conjunto de interacções entre eles. Em seguida, as responsabilidades e os containers de recursos são agrupadas em um conjunto de componentes conceituais e interações entre estes componentes.
Figura 16: Visão do Modelo de Features (CIM) Para a Arquitetura de Software (PIM). Fonte:
[ Kovacevic, 2007 ].
Como visto anteriormente esta abordagem utiliza modelos de features como CIM, de forma que adicionar ou remover features pode não ser muito difícil. No entanto, o arquiteto necessita ainda se assegurar que remover uma feature não irá romper com restrições nas features, e também analisar as dependências entre antigas e novas features.
Atualmente, esta abordagem não fornece suporte para a verificação. Contudo alguns grupos vêm trabalhando neste aspecto. Do mesmo modo, não tem suporte a ferramentas especiais e nem a análise trade-off. A escalabilidade também não é suportada e os componentes são especificados de forma construtiva .
Como já foi dito há suporte para a rastreabilidade de CIM para PIM. Para apoiar a rastreabilidade entre as features e componentes, é utilizada representação gráfica, esta representação pode ser apoiada por especificações textuais baseadas em padrões linguísticos.
Modelos de features são utilizados ainda para expressar requisitos e seus relacionamentos.
Mas a utilização de meta meta modelo não é considerada nesta abordagem. Nela também é permitida a transformação de CIM para PIM. Na tabela 1 são exibidas as características suportadas e não suportadas por esta abordagem.
Tabela 1 – Características Suportadas e Não Suportadas Pela a Abordagem. Fonte: [Kovacevic,
4.2.2.2 ABORDAGENS ORIENTADAS A ASPECTOS
Nesta seção será feita apenas uma enumeração das abordagens orientadas a aspectos em MDD, visto que o foco da seção 4.2, assim como de suas subceções é de definir de maneira geral a abordagem MDD, com intuito de mostrar que a mesma tem potencial para ser utilizada em LPS, sendo assim abaixo serão elicitadas as abordagens orientadas a aspectos, com uma breve descrição das mesmas.
As abordagens de MDD orientadas a aspectos são [Kovacevic, 2007 ]:
● Towards a Subject-Oriented Model-Driven Framework (TSOMDF): É uma abordagem que propõe suporte a rastreabilidade automática entre modelos de MDA, visando o controle de mudanças e detectando conflitos entre os modelos em iguais ou diferentes níveis de abstração.
● Scenario Modelling with Aspects (SMA): É uma abordagem na qual os requisitos são modelados com base em cenários e com o apoio de princípios de orientação a aspectos. Os cenários são importantes aliados na modelagem de requisitos de um sistema, tendo em vista que são naturalmente intuitivos na especificação das interações entre os usuários e o sistema, sendo muito utilizados em Engenharia de Requisitos para descrever casos de uso.
● Modelling Volatile Concerns as Aspects (MVCA): Esta abordagem descreve como identificar, representar e compor características voláteis com aspectos. Esta abordagem especificamente não é baseada em MDD, porém ela propõe um conjunto de regras informais para a transformação de modelos UML em outros modelos UML, por exemplo a transformação de um modelo de casos de uso em um diagrama de atividades.
● An Aspect Oriented Model Driven Framework (AOMDF): Destina-se a facilitar a separação de características verticais e horizontais. Na separação de características verticais, fornece técnicas para transformar modelos de um nível de abstração para outro, já na horizontal a separação é realizada com modelagem transversal de features separadamente como aspectos.
● Model-Driven Development for Early Aspects (MDD4EA) : É uma abordagem que visa a construção automática de modelos de projetos arquiteturais orientados a aspectos em conformidade com modelos de Engenharia de Requisitos, com base em MDD.
5 CONCLUSÃO
Neste trabalho foram exibidas as principais técnicas utilizadas durante o Processo de Engenharia de Requisitos em Linhas de Produto de Software e analisada a abordagem MDD e sua relação com LPS e ER. Sendo feita inicialmente uma contextualiação sobre Processo de ER e Linhas de Produtos de Software.
Por tudo que foi abordado fica claro que o processo de ER em LPS necessita de definições mais precisas, necessitando as técnicas e abordagens apresentarem as atividades de maneira clara e sistemática. São várias as lacunas existentes no processo, onde um dos grandes problemas é a capacidade de adaptar-se a mudanças o que é altamente crucial durante o tempo de vida de uma linha de produto.
Uma característica que é latente ao analizar-se as técnicas e abordagens é que estão totalmente voltadas aos aspectos tecnológicos, deixando de lado fatores sociais e organizacionais, os quais influenciam diretamente nas tomadas de decisões durante a construção dos produtos e que são largamente citados pela Engenharia de Requisitos como fatores influenciadores na construção de sistemas.
Com a análise da abordagem MDD foi nítida a busca da mesma por conceitos, técnicas e tecnologias em prol da busca pela adaptabilidade, esta abordagem prega que os modelos de transformações proporcionam um meio promissor para ajudar a detectar e transmitir as variações de requisitos identificadas durante a implementação de uma linha de produtos. Tendo em vista que, a gerência de requisitos é uma das atividades mais precárias durante o processo de ER, a abordagem MDD pode ser uma solução razoável para LPS.
Quanto a trabalhos relacionados, pode-se citar alguns que complementariam este trabalho, um deles é o trabalho que vem sendo desenvolvido pelo RISE que refere-se a definição de um Processo de Engenharia de Requisitos para Linhas de Produtos de Software, além deste há o trabalho de Birk et al. [Birk, 2003] que apresenta o relatório do Grupo de Trabalho GI, composto por Robert BoschGmbH, Hewlett-Packard (HP), Fraunhofer IESE, Universidade de Aachen e empresa sd&m AG. Este relatório faz uma descrição dos resultados de uma inspeção sistemática de problemas e soluções associado a requisitos em linhas de produto existentes, apresentadas pelas
Algumas idéias que foram avaliadas durante o andamento do grupo de trabalho também são apresentadas neste estudo. Nele é feita uma descrição real deste cenário na indústria. Além destes há também o trabalho de [Schmid, 2006] que consiste de um relatório que afirma que a persistência de problemas com a adopção de linhas de produtos de software tem sido a falta de instrumentos eficazes para apoiar a Engenharia de Requisitos em LPS. Este relatório descreve o Gerenciamento de Requisitos para linhas de produtos.
6 REFERÊNCIAS
[Ayala, 2006] Ayala, C. & Franch, X., Domain Analysis for Supporting Commercial Off-The-Shelf Components Selection, ER 2006.
[Bauer, 1993] Bauer, D., A Reusable Parts Center, IBM Systems Journal, Vol. 32, No. 04, June, 1993, pp. 620-624.
[Birk, 2003] Birk, A.; Heller, G.; John, I.; Joos, S.; Müller, K.; Schmid, K. & Maßen, T.
(2003) ,Report of the GI Work Group "Requirements Engineering for Product Lines", Relatório Técnico, Disponivel em Fraunhofer IESE Eprints: http://publica.fraunhofer.de/eprints.har, Germany.
[Carvalho, 2001] Carvalho, A.E.S.; Tavares, H.C. & Castro, J.B., Uma estratégia para Implantação de uma Gerência de Requisitos Visando a Melhoria dos Processo de , WER01 - Workshop em Engenharia de Requisitos, Buenos Aires, Argentina, 2001. Anais p. 32-54.
[Clements, 2002] Clements P. & Northrop L. M., Product Lines: Practices and Patterns. Boston, MA, USA: Addison-Wesley, 2002.
[Endres, 1993] Endres, A., Lessons Learned in an Industrial Software Lab, IEEE Software, Vol. 10, No.
05, September, 1993, pp. 58-61.
[Frakes, 1994] Frakes, W. B. & Isoda, S., Success Factors of Systematic Reuse, IEEE Software, Vol. 11, No. 05, September/October, 1994, pp. 14-19.
[Gomaa, 2005] Gomaa, H., Designing Product Lines with UML: From Use Casesto Pattern-Based Architectures, Addison-Wesley, 2005.
[Griss, 1995] Griss, M. L.; Wosser, M. & Pfleeger, S. L., Making Software Reuse Work at Hewlett- Packard, IEEE Software, Vol. 12, No. 01, January, 1995, pp. 105-107.
[Johnson, 1996] Johnson, D. M., “The Systems Engineer and the Crisis”, ACM SIGSOFT, Engineering Notes, Vol. 21, N. 2, March/1996.
[Kang, 1990] Kang, K. C.; Cohen, S. G.; Hess, J. A.; Novak, W. E. & Peterson, A. S., Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical report, Carnegie-Mellon University Engineering Institute, 1990.
[Kang, 1998] Kang, K. C.; Kim, S.; Lee, J.; Kim, K.; Shin, E. & Huh, M., FORM: A feature-oriented reuse method with domain-specific reference architectures, in , J. C. Baltzer AG, Science Publishers, Red Bank, NJ, USA, 1998, pp. 143-168.
[Kotonya, 1998] Kotonya, G. & Sommerville, I., Requirements Engineering: Processes and Techniques, John Wiley & Sons, Inc. New York, NY, USA, 1998.
[Kovacevic, 2007] Kovacevic J.; Alferez, M.; Kulesza, U.; Moreira, A.; Araujo, J. & Amaral, V., Survey of the state-of-the-art in Requirements Engineering for Product Line and Model-Driven Requirements Engineering (AMPLE Aspect-Oriented, Model-Driven, Product Line engineering Specific Targeted Research project: IST-33710), Technical report, Lancaster University.
[Mannion, 1998] Mannion, M.; Keepence, B. & Harper, D. ,Using Viewpoints to Define Domain Requirements, IEEE Computer Society Press, Los Alamitos, CA, USA, 1998, pp. 95—102.
[Krueguer, 1992] Krueger, C. W., Software Reuse , ACM Computing Surveys, Vol. 24, No. 02, June, 1992, pp. 131-183.
[McIlroy, 1968] M. D. McIlroy, Mass Produced Components, In the NATO Engineering Conference, 1968.
[Morisio, 2002] Morisio, M.; Ezran, M. & Tully, C., Success and Failure Factors in Software Reuse, IEEE Transactions on Software Engineering, Vol. 28, No. 04, April, 2002, pp. 340-357.
[Nuseibeh, 2000] Nuseibeh, B. & Easterbrook, S., Requirements engineering: a roadmap, in 'ICSE '00:
Proceedings of the Conference on The Future of Engineering', ACM Press, New York, NY, USA, pp.
35-46, 2000.
Object Management Group (OMG), "MOF QVT Final Adopted Specification", http://www.omg.org/docs/ptc/05-11-01.pdf, 05. 07. 2008.
Object Management Group (OMG), "UML 1.5 Specification", http://www.uml.org/, 06.07.2008.
