MATHEUS CATARINO DE AGUILAR

A REENGENHARIA COM O PROPÓSITO DE CRIAR UMALINHA DE PRODUTO DE SOFTWARE

LONDRINA2018

MATHEUS CATARINO DE AGUILAR

A REENGENHARIA COM O PROPÓSITO DE CRIAR UMALINHA DE PRODUTO DE SOFTWARE

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

Orientador: Prof(a). Dr(a). JandiraGuenka Palma

LONDRINA2018

Ficha de identificação da obra elaborada pelo autor, através do Programa de GeraçãoAutomá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 daComputaçã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, NomeCoorientador. III. Universidade Estadual de Londrina. Centro de Ciências Exatas. Programade 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 UMALINHA DE PRODUTO DE SOFTWARE

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

BANCA EXAMINADORA

Orientador: Prof(a). Dr(a). Jandira GuenkaPalma

Universidade Estadual de Londrina

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

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

Prof. Ms. Quarto Membro da BancaUniversidade/Instituição do Quarto

Membro da Banca – Sigla instituição

Londrina, 24 de novembro de 2018.

Este trabalho é dedicado às crianças adultasque, 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 detrabalhos acadêmicos conforme as normas ABNT com LATEX fosse possível.

Agradecimentos especiais são direcionados ao Centro de Pesquisa em Arquiteturada Informação2 da Universidade de Brasília (CPAI), ao grupo de usuários latex-br3 e aosnovos voluntários do grupo abnTEX2 4 que contribuíram e que ainda contribuirão para aevoluçã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>4 <http://groups.google.com/group/abntex2> e <http://abntex2.googlecode.com/>

“Não vos amoldeis às estruturas destemundo, mas transformai-vos pela renovação

da mente, a fim de distinguir qual é avontade 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 Produtode 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

Palavras-chave: Latex. Template ABNT-DC-UEL. Editoração de texto.

AGUILAR, M. Reengineering for the purpose of creating a Software ProductLine. 2018. 34p. Final Project – Draft Version (Bachelor of Science in Computer Science) –State University of Londrina, Londrina, 2018.

ABSTRACT

Keywords: Latex. ABNT-DC-UEL template. Text editoration.

LISTA DE ILUSTRAÇÕES

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

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

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

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

LISTA DE TABELAS

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

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 142.1 Reengenharia de Software . . . . . . . . . . . . . . . . . . . . . . 142.1.1 Engenharia Reversa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.2 Reestruturação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.3 Engenharia Direta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Linha de Produto de Software . . . . . . . . . . . . . . . . . . . . 172.2.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.1.0.1 Engenharia de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.1.0.2 Engenharia de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2 Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2.0.1 Modelo de variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Reengenharia para a criação de uma LPS . . . . . . . . . . . . . 242.3.1 Detecção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.2 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.3 Transformação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4 Método de detecção de código similar . . . . . . . . . . . . . . . 25

3 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . 273.1 Estudo de caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Aplicação do processo . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

APÊNDICES 30

APÊNDICE A – QUISQUE LIBERO JUSTO . . . . . . . . . 31

ANEXOS 32

ANEXO A – MORBI ULTRICES RUTRUM LOREM. . . . 33

Trabalhos Publicados pelo Autor . . . . . . . . . . . . . . . . . 34

13

1 INTRODUÇÃO

Na indústria de softwares, as empresas buscam reduzir os custos, tempo de produ-ção, melhorar a qualidade, facilidade de manutenção, etc. Uma das estratégias utilizadaspelas 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 empresasemprega a reutilização é através da metodologia de cópia e adaptação.

Essa metodologia apresenta como principal desvantagem a manutenção, pois sãoartefatos 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égiade reutilização de software que utiliza uma infraestrutura comum, criada sobre um domínioespecífico.

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

O intuíto deste trabalho é definir e aplicar o processo de reengenharia, alinhadocom métodos de detecção de códigos similares para definir características comuns entre osoftware, utilizados em conjunto com os processos de LPS, visando criar uma plataformacomum 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 umamelhoria desses softwares.

O documento esta organizado da seguinte forma: A seção 2 apresenta os conceitosfundamentais 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 passardo tempo, as regras de negócio das empresas sofrem alterações. Os softwares buscamacompanhar 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 hardwarese sistemas de softwares incluem novas funcionalidades, fazendo com que os softwares atu-ais fiquem desatualizados. A falta de suporte para tecnologias antigas, dificuldade paraencontrar profissionais qualificados, custos de manutenção, complexidade de entendimentosobre o software, surgimento de novas tecnologias, entre outros fatores, fazem com queuma 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 eatenda as regras de negócio com um menor custo de manutenção.[6, 7, 1]

A necessidade da reengenharia tem aumentado, principalmente devido a softwareslegado que estão se tornando obsoletos em termos de arquitetura, plataforma em que sãoexecutados, estabilidade em dar suporte a evoluções para as mudanças necessárias e acompatibilidade com novas tecnologias. A reengenharia é importante para recuperar ereusar 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 osoftware existente e transforma-lo para melhorar suas funcionalidades, performance ouimplementaçã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ãodescritas, apenas em termos gerais. No nível de requisitos, as características funcionaissão descritas em termos detalhados. Nesses dois níveis, detalhes internos do software nãosã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, indicandoo 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 aumentogradual no nível de abstração do software, com substituições de informações detalhas porinformaçõ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émconhecido como engenharia direta, é a substituição de informações abstratas por maisdetalhadas, onde é implementado a representação abstrata do software, representado pelomovimento 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. Duranteesse processo, os requisitos, design, estrutura e conteúdo de um software legado, devem sercapturados. Assim como informações sobre regras de negócio e processos que se mostraramuteis na execução do negócio também devem ser recuperados. O objetivo da engenhariareversa é gerar alternativas de visualização, recuperar informações perdidas, sintetizarabstrações de alto nível e facilitar o reuso. A eficiência deste processo vai impactar osucesso 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 é ilustradona figura 3, começando com a extração dos requisitos e informações detalhadas do códigofonte e seus documentos. Uma documentação de requisitos é gerada e um nível de abstra-ção é extraído e expresso com a utilização de fluxo de dados e controle de fluxo por meiode 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 seencaixam 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áliseem tempo de execução, devido a alta complexidade e pouca informação, são registradostraços do software durante a execução, sendo analisados posteriormente para recuperarrepresentaçõ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 melhorarpropriedades, como a estrutura de representação ou qualidade, como também introduzirnovos requisitos de negócio. [1, 8]

2.1.3 Engenharia Direta

É o processo onde um novo software é criado, partindo das representações abstratasgeradas 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 significativamentedurante 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. Nodomínio automotivo, isso levou a invenção da linha de produto por Ford, possibilitandoa 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 usadospor 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 inicioda personalização em massa.[2]

A personalização em massa para a empresa, significa um maior investimento emtecnologia, gerando preços maiores para os produtos individualizados e/ou menor margemde 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 osdiferentes 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 carasem termos de design e preparação de produção. Com o uso da plataforma em diferentescarros, 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 deacordo com os desejos do cliente, aumentando a velocidade de produção e o número devendas, a figura 4 ilustra a situação. No domínio dos softwares, essa combinação resulta emum 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 visandocriar uma família de produtos que compartilham características em comum. A principalvantagem dessa metodologia é o compartilhamento de uma infraestrutura para todos osprodutos de um domínio específico, tendo cada produto a sua variação. Por ter umainfraestrutura em comum, auxilia na criação de tarefas complexas, garante facilidade demanutençã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. Asrazõ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; compartilharexperiência comum de usuário, por exemplo, compartilhar uma mesma estrutura de menuentre os softwares, gerando maior produtividade entre seus usuários; maior customizaçãodo produto, podendo gerar uma versão única do produto para o cliente; maior qualidade,devido o compartilhamento de código.[4]

As razões para a decisão da introdução de uma LPS é variada, uma das maiores

19

motivações é a econômica, devido ao seu suporte para larga escala de reuso, melhorandoaspectos do processo de desenvolvimento, redução de custos, tempo de ida para o mercadoe melhora na qualidade. Quando artefatos de uma plataforma são reutilizados em váriossoftwares, implica em uma redução de custos para cada um. Entretanto, antes que osartefatos possam ser reutilizados, investimentos são necessários para cria-los, pensandona maneira que eles irão ser compartilhados para serem gerenciados. A figura 5 mostraos 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 pequenossoftwares, o custo para uma LPS é relativamente alto, enquanto significativamente pe-queno para grandes quantidades. O local onde as duas linhas se encontram marcam oponto de Break-even. Nesse ponto os custos são iguais para ambos os paradigmas dedesenvolvimento. Investigações empíricas revelam que, uma padronização da plataformacom 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 dedomínio e engenharia de aplicação. Engenharia de domínio resulta em artefatos que juntosformam 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 engenhariade 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 feedbackque é 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ômicosda LPS e com a estratégia de marketing. O conceito principal é a gestão do portfólio deprodutos 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 entradapara 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 umroteiro que determina as principais características comuns e variáveis dos produtos queserão lançados.[2, 3]

2) Requisitos de Domínio (Domain requirements): Engloba todas as atividadespara selecionar e documentar os requisitos comuns e variáveis da LPS. Tendo como entradao roteiro produzido na Gestão de produtos. Gerando uma saída que consiste de requisitoscomo 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 definira arquitetura da LPS. A arquitetura fornece uma estrutura comum em alto nível paratodas as aplicações da LPS. Tendo como entrada os requisitos do domínio, e seu modelode variabilidade. Gerando uma arquitetura de referência.[2, 3]

4) Realização de Domínio (Domain Realisation): lida com o design detalhado e aimplementaçã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 aarquitetura do desig de domínio e produz sua implementação, gerando artefatos que serãoreutilizaveis.[2, 3]

5) Teste de Domínio (Domain Testing): A plataforma da LPS acaba em váriosprodutos diferentes. Erros na plataforma podem impactar cada produto, portanto é deextrema 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 comoentrada 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 foramrealizados, 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 comunsproduzidos 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 quenão estiver disponível, deve ser analisado. Tem como entrada os documentos produzidosna engenharia de domínio e requisitos especificos. Gera como saída novos requisitos comas especificações particulares do produto.[2, 3]

2) Design de Aplicação (Application Design): Engloba todas as atividades para aprodução da arquitetura da aplicação. Usa como base a arquitetura do design de domínioe encorpora as adaptações específicas do produto. Tendo como entrada as especificaçõesgeradas na engenharia de requisitos da aplicação. Resultando em uma arquitetura ex-tendida com novos componentes e interfaces, satisfazendo os requisitos que não foramatingidos 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 dedomí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, umproduto particular para o cliente.[2, 3]

4) Teste de Aplicação (Application Testing): Consiste das atividades necessáriaspara validar e verificar a aplicação com seus requisitos. Repete-se os testes do domínio, erealiza 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 aser 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ãopara 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 reusodos artefatos de um software, com uma arquitetura voltada para famílias de produtos,com componentes pensados e produzidos para suportarem variações. Isso é suportadoatravés da variabilidade, sendo a habilidade de um software ou artefato ser eficientementeextendido, 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 devariações oferecidas para um ponto particular, variações oferecidas pela LPS e tambémrelaciona a variabilidade que existe nos vários artefatos de desenvolvimento, como duranteos subprocessos de requisitos, design e testes, assim como componentes.[2]

Uma prática comum na LPS para gerar um modelo de variabilidade é a modelagemde 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 modeloconhecido 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 deE/OU. Características são classificadas como mandatórias, alternativa ou opcional. Osatributos 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 telefoniamóvel. (Fonte: 4, p. 29)

2.3 Reengenharia para a criação de uma LPS

Com base em estudos realizados no trabalho "Reengineering legacy applicationsinto 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 umaLPS pode ser classificada em três fases: Detecção, sendo o início do processo, baseada nadetecção de características comuns e variáveis dos artefatos; Análise é a organização dascaracterí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, desenvolvidosutilizando a metodologia de reuso de copiar e adaptar o código. Seguindo o fluxo, temos afase de detecção onde são identificadas as características comuns e variáveis. Logo após, aaná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çasde produtos existentes, representadas por características. Tendo suporte com técnicas delocalização de características comuns, que buscam localizar artefatos responsáveis porimplementar 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 deengenharia de domínio da LPS.[5]

2.3.2 Análise

Envolve a organização das variabilidades e semelhanças descobertas na fase dedetecçã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 dosoftware 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 paraconstruir um novo software, visando reduzir o tempo de ida para o mercado, melhorandoa produtividade e produzindo software com qualidade. Entretanto, geralmente o reuso éaplicado utilizando a estratégia de copiar e adaptar o código, onde funcionalidades desistemas existentes são clonadas e reutilizadas.[5]

Essa estratégia, baseia-se na cópia e adaptação de artefatos existentes para atenderas 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 umartefato 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 defacilitar 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

3.2 Aplicação do processo

28

4 CONCLUSÃO

Sed consequat tellus et tortor. Ut tempor laoreet quam. Nullam id wisi a liberotristique semper. Nullam nisl massa, rutrum ut, egestas semper, mollis id, leo. Nullaac 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, commodoat, 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 turpisegestas.

Phasellus id magna. Duis malesuada interdum arcu. Integer metus. Morbi pulvinarpellentesque 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 aliquamante hendrerit pellentesque. Class aptent taciti sociosqu ad litora torquent per conubianostra, 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 velmetus 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 liberoeros, lacinia non, sodales quis, dapibus porttitor, pede. Class aptent taciti sociosqu adlitora torquent per conubia nostra, per inceptos hymenaeos. Morbi dapibus mauris condi-mentum nulla. Cum sociis natoque penatibus et magnis dis parturient montes, nasceturridiculus mus. Etiam sit amet erat. Nulla varius. Etiam tincidunt dui vitae turpis. Donecleo. 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 LineEngineering. [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 legacyapplications into software product lines: a systematic mapping. Empirical SoftwareEngineering, 2017.

[6] LITTLEJOHN, D. E. W. J. P. L. M. J. P. K. A reuse approach to softwarereengineering. 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 productline. ARXIV, 2012.

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

[11] DUBINSKY, Y. et al. An exploratory study of cloning in industrial software productlines. 17th European Conference on Software Maintenance and Reengineering, 2013.

[12] XUE, Y.; XING, Z.; JARZABEK, S. Feature location in a collection of productvariants. 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-basedcode clone detection system for large scale source code. IEEE Transactions onSoftware Engineering, 2002.

Apêndices

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 posuerepellentesque eros. Quisque venenatis ipsum dictum nulla. Aliquam quis quam non metuseleifend interdum. Nam eget sapien ac mauris malesuada adipiscing. Etiam eleifend nequesed quam. Nulla facilisi. Proin a ligula. Sed id dui eu nibh egestas tincidunt. Suspendissearcu.

Anexos

33

ANEXO A – MORBI ULTRICES RUTRUM LOREM.

Sed mattis, erat sit amet gravida malesuada, elit augue egestas diam, tempusscelerisque nunc nisl vitae libero. Sed consequat feugiat massa. Nunc porta, eros in eleifendvarius, erat leo rutrum dui, non convallis lectus orci ut nibh. Sed lorem massa, nonummyquis, egestas id, condimentum at, nisl. Maecenas at nibh. Aliquam et augue at nuncpellentesque ullamcorper. Duis nisl nibh, laoreet suscipit, convallis ut, rutrum id, enim.Phasellus odio. Nulla nulla elit, molestie non, scelerisque at, vestibulum eu, nulla. Ut odionisl, 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 foipublicado, 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 foipublicado, 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 foipublicado, 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 foipublicado, 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 ondefoi publicado, mês/ano, editora, número de página, isbn, (Qualis CC 2017, xx)