MATHEUS CATARINO DE AGUILAR A REENGENHARIA COM O PROPÓSITO DE CRIAR UMA LINHA DE PRODUTO DE SOFTWARE

MATHEUS CATARINO DE AGUILAR

A REENGENHARIA COM O PROPÓSITO DE CRIAR UMA

LINHA DE PRODUTO DE SOFTWARE

LONDRINA 2018

MATHEUS CATARINO DE AGUILAR

A REENGENHARIA COM O PROPÓSITO DE CRIAR UMA

LINHA DE PRODUTO DE SOFTWARE

Versão Preliminar de Trabalho de Conclusão de Curso apresentado ao curso de Bachare-lado em Ciência da Computação da Univer-sidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Compu-tação.

Orientador: Prof(a). Dr(a). Jandira Guenka Palma

LONDRINA 2018

Ficha de identificação da obra elaborada pelo autor, através do Programa de Geração Automática do Sistema de Bibliotecas da UEL

Sobrenome, Nome.

Título do Trabalho : Subtitulo do Trabalho / Nome Sobrenome. - Londrina, 2017. 100 f. : il.

Orientador: Nome do Orientador Sobrenome do Orientador. Coorientador: Nome Coorientador Sobrenome Coorientador.

Dissertação (Mestrado em Ciência da Computação) - Universidade Estadual de Londrina, Centro de Ciências Exatas, Programa de Pós-Graduação em Ciência da Computação, 2017.

Inclui bibliografia.

1. Assunto 1 - Tese. 2. Assunto 2 - Tese. 3. Assunto 3 - Tese. 4. Assunto 4 - Tese. I. Sobrenome do Orientador, Nome do Orientador. II. Sobrenome Coorientador, Nome Coorientador. III. Universidade Estadual de Londrina. Centro de Ciências Exatas. Programa de Pós-Graduação em Ciência da Computação. IV. Título.

MATHEUS CATARINO DE AGUILAR

A REENGENHARIA COM O PROPÓSITO DE CRIAR UMA

LINHA DE PRODUTO DE SOFTWARE

Versão Preliminar de Trabalho de Conclusão de Curso apresentado ao curso de Bachare-lado em Ciência da Computação da Univer-sidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Compu-tação.

BANCA EXAMINADORA

Orientador: Prof(a). Dr(a). Jandira Guenka Palma

Universidade Estadual de Londrina

Prof. Dr. Segundo Membro da Banca Universidade/Instituição do Segundo Membro da Banca – Sigla instituição

Prof. Dr. Terceiro Membro da Banca Universidade/Instituição do Terceiro Membro da Banca – Sigla instituição

Prof. Ms. Quarto Membro da Banca Universidade/Instituição do Quarto Membro da Banca – Sigla instituição

Este trabalho é dedicado às crianças adultas que, quando pequenas, sonharam em se tornar cientistas.

AGRADECIMENTOS

Os agradecimentos principais são direcionados à Gerald Weber, Miguel Frasson, Leslie H. Watter, Bruno Parente Lima, Flávio de Vasconcellos Corrêa, Otavio Real Sal-vador, Renato Machnievscz1 _{e todos aqueles que contribuíram para que a produção de}

trabalhos acadêmicos conforme as normas ABNT com LA_{TEX fosse possível.}

Agradecimentos especiais são direcionados ao Centro de Pesquisa em Arquitetura da Informação2 _{da Universidade de Brasília (CPAI), ao grupo de usuários latex-br}3 _{e aos}

novos voluntários do grupo abnTEX24 _{que contribuíram e que ainda contribuirão para a}

evolução do abnTEX2.

1

Os nomes dos integrantes do primeiro projeto abnTEX foram extraídos de <http://codigolivre.org. br/projects/abntex/>

2 _{<http://www.cpai.unb.br/>}

3 _{<http://groups.google.com/group/latex-br>}

“Não vos amoldeis às estruturas deste mundo, mas transformai-vos pela renovação da mente, a fim de distinguir qual é a vontade de Deus: o que é bom, o que Lhe é agradável, o que é perfeito. (Bíblia Sagrada, Romanos 12, 2))

AGUILAR, M. A Reengenharia com o propósito de criar uma Linha de Produto

de Software. 2018. 34f. Trabalho de Conclusão de Curso – Versão Preliminar

(Bachare-lado em Ciência da Computação) – Universidade Estadual de Londrina, Londrina, 2018.

RESUMO

AGUILAR, M. Reengineering for the purpose of creating a Software Product

Line. 2018. 34p. Final Project – Draft Version (Bachelor of Science in Computer Science) –

State University of Londrina, Londrina, 2018.

ABSTRACT

LISTA DE ILUSTRAÇÕES

Figura 1 – Níveis de abstração. (Fonte: 1, p. 4) . . . 15 Figura 2 – Modelo de reengenharia. (Fonte: 1, p. 5) . . . 15 Figura 3 – Processo de engenharia reversa. (Fonte: 1, p. 6) . . . 17 Figura 4 – Único produto para todos vs produtos individuais. (Fonte: 2, p. 5) . . . 18 Figura 5 – Economia da engenharia de linha de produtos de software. (Fonte: 2,

p. 4) . . . 19 Figura 6 – O modelo de dois ciclos de vida da engenharia de linha de produtos de

software. (Fonte: 3, p. 48) . . . 20 Figura 7 – Engenharia de Domínio. (Fonte: 2, p. 24) . . . 21 Figura 8 – Engenharia de Aplicação. (Fonte: 2, p. 31) . . . 22 Figura 9 – Um modelo de características da FODA de uma linha de produtos de

telefonia móvel. (Fonte: 4, p. 29) . . . 24 Figura 10 – Processo de reengenharia de software para LPS. (Fonte: 5, p. 11) . . . 25

LISTA DE ABREVIATURAS E SIGLAS

ABNT Associação Brasileira de Normas Técnicas

BNDES Banco Nacional de Desenvolvimento Econômico e Social IBGE Instituto Nacional de Geografia e Estatística

IBICT Instituto Brasileiro de Informação em Ciência e Tecnologia NBR Norma Brasileira

SUMÁRIO

2.2 Linha de Produto de Software . . . . 17

2.2.1 Framework . . . 19

2.2.1.0.1 Engenharia de Domínio . . . 20

2.2.1.0.2 Engenharia de Aplicação . . . 22

2.2.2 Variabilidade . . . 23

2.2.2.0.1 Modelo de variabilidade . . . 23

2.3 Reengenharia para a criação de uma LPS . . . . 24

2.3.1 Detecção . . . 24

2.3.2 Análise . . . 25

2.3.3 Transformação . . . 25

2.4 Método de detecção de código similar . . . . 25

3 DESENVOLVIMENTO . . . . 27 3.1 Estudo de caso . . . 27 3.2 Aplicação do processo . . . . 27 4 CONCLUSÃO . . . . 28 REFERÊNCIAS . . . . 29

APÊNDICES

30

ANEXOS

32

13

1 INTRODUÇÃO

Na indústria de softwares, as empresas buscam reduzir os custos, tempo de produ-ção, melhorar a qualidade, facilidade de manutenprodu-ção, etc. Uma das estratégias utilizadas pelas empresas para atingir esses objetivos é a reutilização de software, utilizando arte-fatos existentes para a produção de novos, porém a maneira que a maioria das empresas emprega a reutilização é através da metodologia de cópia e adaptação.

Essa metodologia apresenta como principal desvantagem a manutenção, pois são artefatos copiados e alterados para atenderem as novas características pedidas pelo cliente. Com o passar do tempo, caso seja encontrado algum defeito ou tenha alguma otimização, a manutenção tem que ser realizada em todas as cópias, tornando-se algo trabalhoso. Para solucionar esse problema, temos outra metodologia, a Linha de Produto de Software (LPS), que visa atingir os objetivos, sem o problema da manutenção, pois é uma estratégia de reutilização de software que utiliza uma infraestrutura comum, criada sobre um domínio específico.

Com o passar dos anos, os softwares acabam ficando desatualizados, devido ao rápido avanço da técnologia. A falta de suporte para esses softwares, dificuldade para encontrar profissionais qualificados, alto custo de manutenção, complexidade de enten-dimento, arquiteturas mal definidas, são fatores que acabam gerando a necessidade de realizar uma reengenharia desse software, buscando melhorá-lo.

O intuíto deste trabalho é definir e aplicar o processo de reengenharia, alinhado com métodos de detecção de códigos similares para definir características comuns entre o software, utilizados em conjunto com os processos de LPS, visando criar uma plataforma comum para uma fámilia de produtos. Tendo em vista que a maioria das empresas só percebem a possibilidade de realizar uma LPS após terem desenvolvido vários produtos, a aplicação desses processos em conjunto é de suma importância no auxílio para uma melhoria desses softwares.

O documento esta organizado da seguinte forma: A seção 2 apresenta os conceitos fundamentais para o entendimento do trabalho e a base das afirmações aqui realizadas.

14

2 FUNDAMENTAÇÃO TEÓRICA

2.1

Reengenharia de Software

É comum que os negócios sejam impulsionados com softwares e com o passar do tempo, as regras de negócio das empresas sofrem alterações. Os softwares buscam acompanhar essas mudanças, sendo adicionadas novas funcionalidades ou alterando as já existentes. Alguns estão sendo desenvolvidos a muitos anos, e devido a essas alterações, podem se tornar muito complicados.[6, 7]

A industria dos computadores continua crescendo rapidamente, e novos hardwares e sistemas de softwares incluem novas funcionalidades, fazendo com que os softwares atu-ais fiquem desatualizados. A falta de suporte para tecnologias antigas, dificuldade para encontrar profissionais qualificados, custos de manutenção, complexidade de entendimento sobre o software, surgimento de novas tecnologias, entre outros fatores, fazem com que uma reengenharia desse software seja uma possibilidade para melhora-lo, ou seja, a reen-genharia consiste em transformar o software existente para que se torne mais eficiente e atenda as regras de negócio com um menor custo de manutenção.[6, 7, 1]

A necessidade da reengenharia tem aumentado, principalmente devido a softwares legado que estão se tornando obsoletos em termos de arquitetura, plataforma em que são executados, estabilidade em dar suporte a evoluções para as mudanças necessárias e a compatibilidade com novas tecnologias. A reengenharia é importante para recuperar e reusar artefatos existentes nesses softwares, estabelecendo uma base para sua evolução.[1] A reengenharia é a examinação, análise e alteração de um software para reconstitui-lo de uma nova forma, com sua subsequente implementação. O objetivo é entender o software existente e transforma-lo para melhorar suas funcionalidades, performance ou implementação, reduzindo custos e preparando-o para novas funcionalidades. [1]

O ciclo de vida em um desenvolvimento de software pode ser abstraído em níveis, sendo que cada nível representa uma parte do processo no desenvolvimento e na reege-nharia. Os níveis podem ser divididos em conceitual, requisitos, design e implementação, representados na Figura 1. [1]

O conceitual, sendo onde os conceitos do software e sua razão de existência são descritas, apenas em termos gerais. No nível de requisitos, as características funcionais são descritas em termos detalhados. Nesses dois níveis, detalhes internos do software não são mensionados. Em design, detalhes internos são abordados, como arquitetura, compo-nentes, interfaces, procedimentos de algoritmos e estruturas de dados. A implementação, é o nível de abstração mais baixo, onde o foco são as características de implementação e

15

Figura 1 – Níveis de abstração. (Fonte: 1, p. 4)

linguagens. [1]

A figura 2 detalha um modelo genérico para a reengenharia de software, indicando o processo de reengenharia para cada nível de abstração. [1]

Figura 2 – Modelo de reengenharia. (Fonte: 1, p. 5)

O processo para a reeengenharia aplica três princípios: abstração, alteração e re-finamento. Abstração ou também conhecida como engenharia reversa, é um aumento gradual no nível de abstração do software, com substituições de informações detalhas por informações mais abstratas, que representem seus componentes e suas relações, represen-tado como um movimento de subida na pirâmide da figura 2. Alteração são melhorias na

16 estrutura e qualidade da representação obtida na abstração, sendo conhecida como rees-truturação, representada pela separação da pirâmide. Por fim, o refinamento, ou também conhecido como engenharia direta, é a substituição de informações abstratas por mais detalhadas, onde é implementado a representação abstrata do software, representado pelo movimento de descida na pirâmide.[1, 8]

2.1.1 Engenharia Reversa

É o processo de analisar o software para identificar seus componentes e suas rela-ções, criando representações em outras formas com um maior nível de abstração. Durante esse processo, os requisitos, design, estrutura e conteúdo de um software legado, devem ser capturados. Assim como informações sobre regras de negócio e processos que se mostraram uteis na execução do negócio também devem ser recuperados. O objetivo da engenharia reversa é gerar alternativas de visualização, recuperar informações perdidas, sintetizar abstrações de alto nível e facilitar o reuso. A eficiência deste processo vai impactar o sucesso na reengenharia do projeto. [1, 8]

A engenharia reversa não envolve mudanças no software ou criação de um novo, é o processo de examinação sem mudanças de suas funcionalidades. O processo é ilustrado na figura 3, começando com a extração dos requisitos e informações detalhadas do código fonte e seus documentos. Uma documentação de requisitos é gerada e um nível de abstra-ção é extraído e expresso com a utilizaabstra-ção de fluxo de dados e controle de fluxo por meio de diagramas. O design é revisado para consistência e correções. [1]

Ao analisar o código fonte, o processo de engenharia reversa possuí técnicas que se encaixam em duas categorias: estática e dinâmica. Estática é a análise da estrutura, res-saltando fraquezas, complexidades e oportunidades para melhorias. Dinâmica é a análise em tempo de execução, devido a alta complexidade e pouca informação, são registrados traços do software durante a execução, sendo analisados posteriormente para recuperar representações abstratas do sistema.[8]

2.1.2 Reestruturação

É a transformação da representação abstrata que a engenharia reversa produz, em outras representações do mesmo nível de abstração. Tem como objetivo melhorar propriedades, como a estrutura de representação ou qualidade, como também introduzir novos requisitos de negócio. [1, 8]

2.1.3 Engenharia Direta

É o processo onde um novo software é criado, partindo das representações abstratas geradas na fase de reestruturação para a implementação física do software.[1, 8]

17

Figura 3 – Processo de engenharia reversa. (Fonte: 1, p. 6)

2.2

Linha de Produto de Software

A maneira como as mercadorias são produzidas tem mudado significativamente durante o tempo. Antigamente, eram feitas a mão para clientes individuais. Um a Um, o número de pessoas que podiam comprar vários tipos de produtos aumentavam. No domínio automotivo, isso levou a invenção da linha de produto por Ford, possibilitando a produção em massa com valores muito menores que produtos individuais. Entretanto, a linha de produto reduziu a possibilidade para diversificações. [2]

Os clientes estavam contentes com a padronização dos produtos por um tempo, porém nem todas as pessoas querem o mesmo tipo de carro. Certamente, carros são usados por vários motivos, como para levar uma única pessoa, outros para levar grandes famílias. A indústria, foi confrontada com a demanda de produtos individualizados, sendo o inicio da personalização em massa.[2]

A personalização em massa para a empresa, significa um maior investimento em tecnologia, gerando preços maiores para os produtos individualizados e/ou menor margem de lucro para a empresa. Ambos os efeitos não são desejáveis, com isso muitas empresas, especialmente a indústria de carros, começaram a introduzir plataformas comuns para os diferentes tipos de carros.[2]

Originalmente, uma plataforma automotiva era consistida de painéis de piso, sis-tema de suspensão e painéis de balancim. Posteriormente, mais partes foram adicionadas.

18 A plataforma provia uma estrutura para os componentes principais, determinando o corpo, motor e transmissão. As partes compostas pela plataforma eram usualmente as mais caras em termos de design e preparação de produção. Com o uso da plataforma em diferentes carros, levou a uma redução nos custos da produção para um tipo particular de carro.[2] A combinação da personalização em massa e a utilização de uma plataforma co-mum, possibilita um reuso de tecnologia e a realização de produtos mais próximos de acordo com os desejos do cliente, aumentando a velocidade de produção e o número de vendas, a figura 4 ilustra a situação. No domínio dos softwares, essa combinação resulta em um paradigma chamado linha de produto de software, também conhecido como LPS.[2]

Figura 4 – Único produto para todos vs produtos individuais. (Fonte: 2, p. 5) LPS, consiste em uma forma disciplinada do reuso de software. Utilizada visando criar uma família de produtos que compartilham características em comum. A principal vantagem dessa metodologia é o compartilhamento de uma infraestrutura para todos os produtos de um domínio específico, tendo cada produto a sua variação. Por ter uma infraestrutura em comum, auxilia na criação de tarefas complexas, garante facilidade de manutenção e reduz o tempo de ida do software ao mercado.[2, 9, 5]

A decisão para a introduzir uma LPS é uma decisão de negócio estratégica. As razões mais comuns são: aumentar a diversidade de produtos oferecidos pela empresa, servindo vários segmentos pequenos de mercado de uma maneira rápida; compartilhar experiência comum de usuário, por exemplo, compartilhar uma mesma estrutura de menu entre os softwares, gerando maior produtividade entre seus usuários; maior customização do produto, podendo gerar uma versão única do produto para o cliente; maior qualidade, devido o compartilhamento de código.[4]

19 motivações é a econômica, devido ao seu suporte para larga escala de reuso, melhorando aspectos do processo de desenvolvimento, redução de custos, tempo de ida para o mercado e melhora na qualidade. Quando artefatos de uma plataforma são reutilizados em vários softwares, implica em uma redução de custos para cada um. Entretanto, antes que os artefatos possam ser reutilizados, investimentos são necessários para cria-los, pensando na maneira que eles irão ser compartilhados para serem gerenciados. A figura 5 mostra os custos necessários acumulados para desenvolver n softwares diferentes.[2, 3]

Figura 5 – Economia da engenharia de linha de produtos de software. (Fonte: 2, p. 4) A linha sólida esboça o custo de desenvolvimento de softwares independentes, enquanto a tracejada mostra o custo de produtos em uma LPS. No caso de pequenos softwares, o custo para uma LPS é relativamente alto, enquanto significativamente pe-queno para grandes quantidades. O local onde as duas linhas se encontram marcam o ponto de Break-even. Nesse ponto os custos são iguais para ambos os paradigmas de desenvolvimento. Investigações empíricas revelam que, uma padronização da plataforma com um investimento inicial tem o Pay-off com aproximadamente três softwares.[2, 3]

2.2.1 Framework

A figura 6 representa um framework para a LPS, dividindo-a em: engenharia de domínio e engenharia de aplicação. Engenharia de domínio resulta em artefatos que juntos formam a plataforma da LPS. Engenharia de aplicação resulta em produtos entregues. Com dois ciclos de vida, contendo nove subprocessos, sendo oito deles: requisitos, desig, realização e teste. Ocorrem em ambos os processos, na engenharia de domínio e engenharia de aplicação, sendo que cada par é fortemente conectado. Os subprocessos da engenharia

20 de domínio resultam em artefatos comuns que são utilizados na engenharia de aplicação, seguindo de um retorno dos subprocessos da engenharia de aplicação, gerando feedback que é usado para melhorar os artefatos.[3]

Figura 6 – O modelo de dois ciclos de vida da engenharia de linha de produtos de software. (Fonte: 3, p. 48)

2.2.1.0.1 Engenharia de Domínio

Composto de cinco subprocessos, a Engenharia de Domínio (Domain Engineering) é representada pela figura 7.[2]

1) Gestão de Produtos (Product Management): lida com os aspectos econômicos da LPS e com a estratégia de marketing. O conceito principal é a gestão do portfólio de produtos da empresa, determinando quais características são comuns e quais são variáveis. Empregando técnicas de escopo, para definir o que esta dentro ou fora de escopo. A entrada para a gestão de produtos consiste dos objetivos da empresa. A saída da gestão de produtos é uma documentação de produtos existentes e de artefatos que são compartilhados, e um roteiro que determina as principais características comuns e variáveis dos produtos que serão lançados.[2, 3]

2) Requisitos de Domínio (Domain requirements): Engloba todas as atividades para selecionar e documentar os requisitos comuns e variáveis da LPS. Tendo como entrada o roteiro produzido na Gestão de produtos. Gerando uma saída que consiste de requisitos como textos e baseados em modelo, reutilizaveis, e um modelo de variabilidade da LPS, incluindo requisitos comuns e variações que a LPS deve suportar.[2, 3]

21

Figura 7 – Engenharia de Domínio. (Fonte: 2, p. 24)

3) Design de Domínio (Domain design): Engloba todas as atividades para definir a arquitetura da LPS. A arquitetura fornece uma estrutura comum em alto nível para todas as aplicações da LPS. Tendo como entrada os requisitos do domínio, e seu modelo de variabilidade. Gerando uma arquitetura de referência.[2, 3]

4) Realização de Domínio (Domain Realisation): lida com o design detalhado e a implementação de componentes de software reusáveis. As interfaces auxiliam no processo, servindo como um contrato entre o componente e seu contexto. Tem como entrada a arquitetura do desig de domínio e produz sua implementação, gerando artefatos que serão reutilizaveis.[2, 3]

5) Teste de Domínio (Domain Testing): A plataforma da LPS acaba em vários produtos diferentes. Erros na plataforma podem impactar cada produto, portanto é de extrema importância garantir que a plataforma tem qualidade suficiente. O teste de do-mínio é responsável pela validação e verificação dos componentes reusáveis, tendo como entrada as documentações produzidas nos processos anteriores e suas implementações. Gerando como saída os resultados dos testes aplicados, assim como os testes que foram realizados, para serem utilizados novamente no teste de aplicação.[2, 3]

22

2.2.1.0.2 Engenharia de Aplicação

Composto de quatro subprocessos, a Engenharia de Aplicação (Application

Engi-neering) é representada pela figura 8.[2]

Figura 8 – Engenharia de Aplicação. (Fonte: 2, p. 31)

1) Engenharia de Requisitos de Aplicação (Application Requirements Engineering): Especifica um produto particular, onde o modelo de variabilidade e os requisitos comuns produzidos na engenharia de domínio, formam uma ferramenta valiosa para um começo, porém não irão satisfazer todos os requisitos, apenas mostrar o que esta disponível. O que não estiver disponível, deve ser analisado. Tem como entrada os documentos produzidos na engenharia de domínio e requisitos especificos. Gera como saída novos requisitos com as especificações particulares do produto.[2, 3]

2) Design de Aplicação (Application Design): Engloba todas as atividades para a produção da arquitetura da aplicação. Usa como base a arquitetura do design de domínio e encorpora as adaptações específicas do produto. Tendo como entrada as especificações geradas na engenharia de requisitos da aplicação. Resultando em uma arquitetura ex-tendida com novos componentes e interfaces, satisfazendo os requisitos que não foram atingidos com a arquitetura de referência.[2, 3]

3) Realização de Aplicação (Application Realisation): O objetivo desse subprocesso é a implementação de produtos. Os artefatos comuns produzidos durante a realização de domínio são utilizados para diminuir o esforço e o tempo nessa implementação. Tem como

23 entrada a plataforma de artefatos comuns da LPS e gera uma aplicação executável, um produto particular para o cliente.[2, 3]

4) Teste de Aplicação (Application Testing): Consiste das atividades necessárias para validar e verificar a aplicação com seus requisitos. Repete-se os testes do domínio, e realiza novos testes, inclusive nos componentes da plataforma, pois como possuem varia-ções, devem ser testados novamente. Tem como entrada as documentações e o produto a ser testado e gera como saída os resultados dos testes aplicados.[2, 3]

2.2.2 Variabilidade

A necessidade por produtos individuais tem aumentando, assim como a pressão para aumentar o número de produtos de software colocados no mercado. Por várias ra-zões, algumas organizações exploram as características comuns e variáveis dos softwares, buscando um reuso de seus produtos. LPS é um exemplo de abordagem que busca o reuso dos artefatos de um software, com uma arquitetura voltada para famílias de produtos, com componentes pensados e produzidos para suportarem variações. Isso é suportado através da variabilidade, sendo a habilidade de um software ou artefato ser eficientemente extendido, mudado, customizado ou configurado para um contexto particular.[4]

2.2.2.0.1 Modelo de variabilidade

O modelo de variabilidade define a variabilidade da LPS, definindo os tipos de variações oferecidas para um ponto particular, variações oferecidas pela LPS e também relaciona a variabilidade que existe nos vários artefatos de desenvolvimento, como durante os subprocessos de requisitos, design e testes, assim como componentes.[2]

Uma prática comum na LPS para gerar um modelo de variabilidade é a modelagem de características comuns e variáveis com a perspectiva de características dos produtos. O modelo de características Feature-Oriented Domain Analysis(FODA)[10] é um modelo conhecido e utilizado para representar a variabilidade de produtos, sendo organizado em "consiste de"e "generalização/especialização"para criar suas relações, usando gráficos de E/OU. Características são classificadas como mandatórias, alternativa ou opcional. Os atributos das características também devem ser documentados. Um exemplo do modelo é representado na figura 9.

24

Figura 9 – Um modelo de características da FODA de uma linha de produtos de telefonia móvel. (Fonte: 4, p. 29)

2.3

Reengenharia para a criação de uma LPS

Com base em estudos realizados no trabalho "Reengineering legacy applications

into software product lines: a systematic mapping"[5], envolvendo 119 artigos acadêmicos,

extraídos de bases de dados distintas e renomadas. A reengenharia para a criação de uma LPS pode ser classificada em três fases: Detecção, sendo o início do processo, baseada na detecção de características comuns e variáveis dos artefatos; Análise é a organização das características, voltada para a criação de um modelo de variabilidade; Transformação, onde os artefatos são utilizados para a criação da LPS.

A figura 10 representa o processo de reengenharia baseado nessas três fases. Par-tindo da esquerda, em System Variants temos variações de um sistema, desenvolvidos utilizando a metodologia de reuso de copiar e adaptar o código. Seguindo o fluxo, temos a fase de detecção onde são identificadas as características comuns e variáveis. Logo após, a análise, onde é montado um modelo que atenda as variações de todos os sistemas, repre-sentado por uma árvore, usada para estabelecer relações entre características. Finalmente, a transformação, realizando modificações nos artefatos para criar a LPS.[5]

2.3.1 Detecção

Início do processo, com o objetivo de detectar as variabilidades e semelhanças de produtos existentes, representadas por características. Tendo suporte com técnicas de localização de características comuns, que buscam localizar artefatos responsáveis por implementar as funcionalidades do sistema. O gerenciamento de características e

mape-25

Figura 10 – Processo de reengenharia de software para LPS. (Fonte: 5, p. 11)

amento de artefatos que implementam as funcionalidades é uma tarefa do processo de engenharia de domínio da LPS.[5]

2.3.2 Análise

Envolve a organização das variabilidades e semelhanças descobertas na fase de detecção. Tendo como objetivo a criação de uma representação da variabilidade, para ex-pressar as combinações válidas de características de uma LPS. O modelo de variabilidade é um dos recurso mais utilizados para representar a variabilidade de um software.[5]

2.3.3 Transformação

Envolve as atividades, onde os artefatos que implementam as características do software em conjunto com o modelo de variabilidade são utilizados para criar a LPS.[5]

2.4

Método de detecção de código similar

A premissa das estratégias de reuso de software é reutilizar artefatos existentes para construir um novo software, visando reduzir o tempo de ida para o mercado, melhorando a produtividade e produzindo software com qualidade. Entretanto, geralmente o reuso é aplicado utilizando a estratégia de copiar e adaptar o código, onde funcionalidades de sistemas existentes são clonadas e reutilizadas.[5]

Essa estratégia, baseia-se na cópia e adaptação de artefatos existentes para atender as novas características de um produto. Por mais que seja desencorajada na literatura, é uma das abordagens de reuso mais utilizada, devido a simplicidade, disponibilidade e

26 indepedencia entre os desenvolvedores. Tem como a principal desvantagem a manutenção, por gerar produtos independentes, cada correção de erro ou otimização realizada em um artefato que foi copiado e adaptado em vários produtos, deve ser realizada em todos.[11, 5] Para que seja possível realizar a reengenharia, é necessário identificar as caracte-rísticas comuns e variáveis dos sistemas, e o código que as implementa. Uma maneira de facilitar essa identificação é a utilização de técnicas que examinam arquivos de código, comparando-os em busca de cópias e similaridade.[12, 13]

27

3 DESENVOLVIMENTO

3.1

Estudo de caso

28

4 CONCLUSÃO

Sed consequat tellus et tortor. Ut tempor laoreet quam. Nullam id wisi a libero tristique semper. Nullam nisl massa, rutrum ut, egestas semper, mollis id, leo. Nulla ac massa eu risus blandit mattis. Mauris ut nunc. In hac habitasse platea dictumst. Aliquam eget tortor. Quisque dapibus pede in erat. Nunc enim. In dui nulla, commodo at, consectetuer nec, malesuada nec, elit. Aliquam ornare tellus eu urna. Sed nec metus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

Phasellus id magna. Duis malesuada interdum arcu. Integer metus. Morbi pulvinar pellentesque mi. Suspendisse sed est eu magna molestie egestas. Quisque mi lorem, pulvi-nar eget, egestas quis, luctus at, ante. Proin auctor vehicula purus. Fusce ac nisl aliquam ante hendrerit pellentesque. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Morbi wisi. Etiam arcu mauris, facilisis sed, eleifend non, nonummy ut, pede. Cras ut lacus tempor metus mollis placerat. Vivamus eu tortor vel metus interdum malesuada.

Sed eleifend, eros sit amet faucibus elementum, urna sapien consectetuer mauris, quis egestas leo justo non risus. Morbi non felis ac libero vulputate fringilla. Mauris libero eros, lacinia non, sodales quis, dapibus porttitor, pede. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Morbi dapibus mauris condi-mentum nulla. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Etiam sit amet erat. Nulla varius. Etiam tincidunt dui vitae turpis. Donec leo. Morbi vulputate convallis est. Integer aliquet. Pellentesque aliquet sodales urna.

29

REFERÊNCIAS

[1] ROSENBERG, D. L. H. Software re-engineering prepared by: Dr. linda h. rosenberg.

Software Assurance Technology Center.

[2] POHL, D. G. B. P. D. K.; LINDEN, D. F. van der. Software Product Line

Engineering. [S.l.: s.n.], 2005.

[3] LINDEN FRANK J., S. K. R. E. Van der. Software Product Lines in Action. [S.l.: s.n.], 2007.

[4] CAPILLA JAN BOSCH, K.-C. K. R. Systems and Software Variability Management. [S.l.: s.n.], 2013.

[5] ASSUNçãO WESLEY K. G. LOPEZ-HERREJON, R. E. et al. Reengineering legacy applications into software product lines: a systematic mapping. Empirical Software

Engineering, 2017.

[6] LITTLEJOHN, D. E. W. J. P. L. M. J. P. K. A reuse approach to software reengineering. Elsevier BV, 1995.

[7] SHIU, W. C. C. C. L. C.; HE, X. Pattern-based software reengineering: a case study.

JOURNAL OF SOFTWARE MAINTENANCE: RESEARCH AND PRACTICE,

2000.

[8] PEREZ-CASTILLO, R. et al. Reengineering technologies. IEEE Software, v. 28, n. 6, p. 13–17, Nov 2011. ISSN 0740-7459.

[9] JIRAPANTHONG, W. Experience on re-engineering applying with software product line. ARXIV, 2012.

[10] KANG SHOLOM G. COHEN, J. A. H. W. E. N. A. S. P. K. C. Feature-oriented domain analysis (foda). Software Engineering Institute.

[11] DUBINSKY, Y. et al. An exploratory study of cloning in industrial software product lines. 17th European Conference on Software Maintenance and Reengineering, 2013. [12] XUE, Y.; XING, Z.; JARZABEK, S. Feature location in a collection of product

variants. In: 2012 19th Working Conference on Reverse Engineering. [S.l.: s.n.], 2012. p. 145–154. ISSN 1095-1350.

[13] KAMIYA, T.; KUSUMOTO, S.; INOUE, K. Ccfinder: a multilinguistic token-based code clone detection system for large scale source code. IEEE Transactions on

31

APÊNDICE A – QUISQUE LIBERO JUSTO

Quisque facilisis auctor sapien. Pellentesque gravida hendrerit lectus. Mauris ru-trum sodales sapien. Fusce hendrerit sem vel lorem. Integer pellentesque massa vel au-gue. Integer elit tortor, feugiat quis, sagittis et, ornare non, lacus. Vestibulum posuere pellentesque eros. Quisque venenatis ipsum dictum nulla. Aliquam quis quam non metus eleifend interdum. Nam eget sapien ac mauris malesuada adipiscing. Etiam eleifend neque sed quam. Nulla facilisi. Proin a ligula. Sed id dui eu nibh egestas tincidunt. Suspendisse arcu.

33

ANEXO A – MORBI ULTRICES RUTRUM LOREM.

Sed mattis, erat sit amet gravida malesuada, elit augue egestas diam, tempus scelerisque nunc nisl vitae libero. Sed consequat feugiat massa. Nunc porta, eros in eleifend varius, erat leo rutrum dui, non convallis lectus orci ut nibh. Sed lorem massa, nonummy quis, egestas id, condimentum at, nisl. Maecenas at nibh. Aliquam et augue at nunc pellentesque ullamcorper. Duis nisl nibh, laoreet suscipit, convallis ut, rutrum id, enim. Phasellus odio. Nulla nulla elit, molestie non, scelerisque at, vestibulum eu, nulla. Ut odio nisl, facilisis id, mollis et, scelerisque nec, enim. Aenean sem leo, pellentesque sit amet, scelerisque sit amet, vehicula pellentesque, sapien.

34

TRABALHOS PUBLICADOS PELO AUTOR

Trabalhos publicados pelo autor durante o programa. Publicações principais do trabalho.

1. Jose da silva, autor2 da silva, orientador da silva, Título do artigo, local onde foi publicado, mês/ano, editora, número de página, isbn, etc. (Qualis CC 2017, xx) 2. Jose da silva, autor2 da silva, orientador da silva, Título do artigo, local onde foi

publicado, mês/ano, editora, número de página, isbn, etc. (Qualis CC 2017, xx) 3. Jose da silva, autor2 da silva, orientador da silva, Título do artigo, local onde foi

publicado, mês/ano, editora, número de página, isbn, etc. (Qualis CC 2017, xx) Publicações complementares.

1. Jose da silva, autor2 da silva, orientador da silva, Título do artigo, local onde foi publicado, mês/ano, editora, número de página, isbn, etc. (Qualis CC 2017, xx) 2. Jose da silva, autor2 da silva, orientador da silva, etc. Título do artigo, local onde