IGOR DA COSTA QUITERIO

PROPOSTA DE UMA ABORDAGEM ORIENTADA AMODELOS PARA LINHA DE PRODUTOS DE SOFTWARE

LONDRINA2018

IGOR DA COSTA QUITERIO

PROPOSTA DE UMA ABORDAGEM ORIENTADA AMODELOS PARA LINHA DE PRODUTOS DE SOFTWARE

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computaçã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.

IGOR DA COSTA QUITERIO

PROPOSTA DE UMA ABORDAGEM ORIENTADA AMODELOS PARA LINHA DE PRODUTOS DE SOFTWARE

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computaçã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))

SOBRENOME, N. A.. Proposta de uma Abordagem Orientada a Modelos paraLinha de Produtos de Software. 2018. 33f. Trabalho de Conclusão de Curso (Bachare-lado em Ciência da Computação) – Universidade Estadual de Londrina, Londrina, 2018.

RESUMO

Segundo a 1, 3.1-3.2, o resumo deve ressaltar o objetivo, o método, os resultados e as con-clusões do documento. A ordem e a extensão destes itens dependem do tipo de resumo(informativo ou indicativo) e do tratamento que cada item recebe no documento original.O resumo deve ser precedido da referência do documento, com exceção do resumo inseridono próprio documento. (. . . ) As palavras-chave devem figurar logo abaixo do resumo, an-tecedidas da expressão Palavras-chave:, separadas entre si por ponto e finalizadas tambémpor ponto.

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

SOBRENOME, N. A.. Title of the Work. 2018. 33p. Final Project (Bachelor of Sciencein Computer Science) – State University of Londrina, Londrina, 2018.

ABSTRACT

This is the english abstract. The Abstract in English should be faithful to the Resumo inPortuguese, but not a literal translation.

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

LISTA DE ILUSTRAÇÕES

Figura 1 – Representação do processo de software [2] . . . . . . . . . . . . . . . . 15Figura 2 – Principais elementos do MDD [3] . . . . . . . . . . . . . . . . . . . . . 17Figura 3 – PIM gerando multiplos PSM [4] . . . . . . . . . . . . . . . . . . . . . . 19Figura 4 – Dois ciclos de vida que separam engenharia de domínio e aplicação [5]. 20

LISTA DE TABELAS

Tabela 1 – Exemplo dos diversos níveis de abstração onde pontos de variabilidadepodem ser aplicados [6]. . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Tabela 2 – Descrição dos benefícios tangíveis [6]. . . . . . . . . . . . . . . . . . . . 22Tabela 3 – Descrição dos benefícios intangíveis [6]. . . . . . . . . . . . . . . . . . . 22

LISTA DE ABREVIATURAS E SIGLAS

SPL Software Product Line / Linha de Produto de Software

MDD Model-Driven Development / Desenvolvimento Orientado a Modelos

DSL Domain-Specific Language / Linguagem de Domínio Específico

MDA Model-Driven Arquitecture / Arquitetura Orientada a Modelos

CIM Computational Independent Model / Modelo Independente de Compu-tação

PIM Platform Independent Model / Modelo Independente de Plataforma

PSM Platform-Specific Model / Modelo Específico de Plataforma

PLA Product-Line Architecture / Arquitetura de Linha de Produto

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 152.1 Processo de software . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.1 Modelagem de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Desenvolvimento Orientado a Modelos . . . . . . . . . . . . . . 162.2.1 Vantagens e Desvantagens . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Modelagem de domínio . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3 Transformação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 Linha de Produtos de Software . . . . . . . . . . . . . . . . . . . 182.3.1 Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.2 Gestão de Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.3 Engenharia de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.4 Engenharia de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.5 Conjunto de Ativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.6 Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4 Desenvolvimento Orientado a Modelos atrelado a uma Linha

de Produtos de Software . . . . . . . . . . . . . . . . . . . . . . . 23

3 PROPOSTA DA ABORDAGEM DE DESENVOLVIMENTODE UMA SPL COM MDD . . . . . . . . . . . . . . . . . . . . . 24

3.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Analise de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Projeto de Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Implementação de Domínio . . . . . . . . . . . . . . . . . . . . . . 243.5 Modelo de Processo . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 ESTUDO DE CASO DA PROPOSTA . . . . . . . . . . . . . . 254.1 Passo a Passo da Proposta . . . . . . . . . . . . . . . . . . . . . . 254.1.1 Levantamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.3 Analise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Analise de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.1 Projeto de Produtos Futuros . . . . . . . . . . . . . . . . . . . . . . . 25

5 DISCUSSÃO E CONCLUSÃO . . . . . . . . . . . . . . . . . . . 265.1 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Implicações e Limitações . . . . . . . . . . . . . . . . . . . . . . . 265.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

APÊNDICES 29

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

ANEXOS 31

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

Trabalhos Publicados pelo Autor . . . . . . . . . . . . . . . . . 33

14

1 INTRODUÇÃO

Com a Evolução do mercado de software, alguns sistemas se tornaram mais com-plexos e a alta competitividade entre as empresas demanda rapidez no lançamento denovos produtos, de modo a ganhar vantagem de mercado sobre os concorrentes. A meto-dologia de desenvolvimento dessas plataformas precisa levar em consideração as constantesmudanças do meio, além de estabelecer uma estratégia para se aproveitar do ambiente ,buscando fornecer o maior número de aplicações com base em uma solução. Novas abor-dagens são necessárias a fim de permitir um gerenciamento mais eficaz dos requisitos emcaso de mudança, também levando em conta maior praticidade em atualizações e ma-nutenções de código, meios mais práticos de teste e integração na produção. Dado taiscaracterísticas, o reuso do software surge como uma possível solução para as novas exi-gências do mercado [7].

Estratégias de reuso são vastamente empregadas em abordagens ad hoc na produ-ção de softwares, com o intuito de aumentar a produtividade e reduzir tempo necessáriopara uma aplicação chegar ao mercado. Quando um cliente solicita alguma melhoria, oque usualmente se faz é uma cópia de uma solução parecida já realizada, e em seguidasão feitas adaptações para que ela se adéque ao novo projeto. Quando se opta por essaintervenção a manutenção se mostra como uma grande desvantagem, visto que é geradouma variação de um produto toda vez que um código é reaproveitado. Caso alguma falhaseja encontrada, ela deverá ser corrigida em todas as variações produzidas. Um meio deresolver este problema se encontra em abordar o uso de linha de produtos de software [8].

Em uma linha de produto de software, o sistema é construído de forma modula-rizada separando em blocos todas características importantes, de modo que esses blocospossam ser usados mais tarde para criar novos produtos. Associando essa abordagem aodesenvolvimento orientado a modelo, uma equipe pode especificar blocos e suas inter re-lações através de uma linguagem de domínio específico (domain-specific language - DSL),focando assim na elaboração da solução, e não em complexidades de implementação [9].

Mediante ao fato de que seria interessante uma abordagem na prática desse ar-ranjo, a fim de averiguar possíveis benefícios. Esse trabalho propõe o desenvolvimento deuma linha de produtos de aplicações mobile utilizando metodologias de desenvolvimentoorientado a modelo

15

2 FUNDAMENTAÇÃO TEÓRICA

2.1 Processo de software

Um processo de software é um conjunto de ações compostas por atividades, res-ponsáveis pelo controle administrativo de projetos de software, que ditam o contexto paraqual as metodologias técnicas são aplicadas, assegurando assim qualidade e gerenciamentode modificações através de modelos, documentos e formulários [2].

Figura 1 – Representação do processo de software [2]

2.1.1 Modelagem de Sistemas

A modelagem de sistemas consiste em abstrair modelos de forma representar visõesdo mesmo, com o intuito de auxiliar tanto no levantamento de requisitos interpretandoas regras de um domínio proposto pelo cliente, como na fase de projeto servindo de pontode referencia para que uma equipe se oriente, ou ao final do projeto sendo utilizado comodocumentação da estrutura do software [2][10].

16

2.2 Desenvolvimento Orientado a Modelos

O planejamento de um software encontra-se em uma posição desfavorável no pro-cesso de elaboração de uma aplicação, é algo novo e de onde se espera muito. O progra-mador não necessita extrair grandes quantidades de terras ou dobrar metais difíceis dese trabalhar, a facilidade de se escrever um código pode instigar uma equipe de desen-volvimento a iniciar um trabalho com pouco planejamento ou apenas um conhecimentosuperficial sobre o assunto tratado no projeto, outro ponto é que devido a pressão do mer-cado, usuários e até mesmo desenvolvedores estão solicitando sistemas que muitas vezesvão além da nossa capacidade atual de construção[11].

Mesmo tendo sido inventados vários paradigmas de programação desde então, onível de abstração das linguagens dominantes no mercado permaneceram praticamenteconstantes, uma declaração de IF ou LOOP em uma linguagem de programação maismoderna como Python ou Java não é mais potente do que uma declaração de de IF ouLOOP em Fortran, apesar de todo o trabalho feito para polir os detalhes. Com isso emvista muitos especialistas desistiram de acreditar que o progresso viria das tecnologias deprogramações, e passaram a apostar nas melhorias em processo de software, O que explicao interesse atual em metodologias ágeis[11].

A premissa do Desenvolvimento Orientado a Modelos, ou Model-Driven Develop-ment(MDD) (Figura 2), é de que o desenvolvimento de software e seus produtos foquemem modelos ao invés de programas,dessa forma o engenheiro se encontra em uma camadasuperior a da implementação, ficando livre para projetar as funcionalidades sem esbararem complexidades de implementação, dando assim mais valor ao domínio do problema,o que torna os modelos mais fáceis de especificar, manter e entender, deslocando a ta-refa de produção de um sistema dos especialistas em computação para especialistas dedomínios[11]. Durante a modelagem de domínio deve-se levar em conta que o modelosera interpretado por um computador ou uma equipe especifica de codificação através daArquitetura Orientada a Modelos, ou Model-Driven Arquitecture (MDA), para que issoocorra esse modelo devera seguir rigorosamente as regras semânticas da DSL [12]. A ideiaé que o o planejamento em alto nível seja progressivamente transformado em modelos deníveis cada vez mais baixos, a ponto de que o projeto possa ser executado empregandogeração automática de código dos seus respectivos modelos[13].

2.2.1 Vantagens e Desvantagens

VantagensPortabilidade: Um modelo pode ser usado para gerar código em diversas plata-

formas, diminuindo assim a complexidade e aumentando sua capacidade de reutilização[3][14].Produtividade: O tempo gasto na elaboração dos modelos de mais alto nível,

poupa os desenvolvedores de esforços repetitivos na implementação através da geração de

17

Figura 2 – Principais elementos do MDD [3]

códigos, deixando a equipe livre para se preocupar com trechos de código que realmentenecessitam de tempo[3][14].

Interoperabilidade: Pode-se gerar cada parte do modelo em plataformas di-ferentes, o que resultaria em um software heterogêneo localmente, porem com aspectohomogêneo quando olhado sob perspectiva global[3][14].

Especificidade de Domínio: Garante-se uma especificidade de domínio da apli-cação ao transformar questões de implementação em elementos de nível mais alto deabstração[14].

Manutenção e documentação: Os modelos servem também com parte da do-cumentação, e como o código é gerado a partir deles, as alterações serão realizadas dire-tamente neles. Dessa forma a documentação nunca fica desatualizada, o que facilita demodo geral as tarefas de manutenção[3].

DesvantagensComplexidade : as ferramentas necessárias para a abordagem baseada em mode-

los(programas de modelagem, geradores de código, interpretadores ), adicionam um graude complexidade em todo o processo de criação, por se tratarem de instrumentos maisdifíceis de construir e manter[3]. Bibliotecas de Código já Implementadas: Algumas bibliotecas já existen-tes podem não ser compatíveis com os modelos finais, o que acarretaria em um custo demanutenção de código toda vez que se deseja usar a biblioteca em questão[14].

Desempenho: Mesmo realizando algumas otimizações em nível mais alto de abs-tração, a regra geral é que geradores de código acabam incluindo código desnecessário, equando comparado com o código gerada a mão o desempenho de um gerado por modelospode não ser o esperado[3].

18

2.2.2 Modelagem de domínio

O domínio representa um campo limitado por interesses ou conhecimentos, a Ar-quitetura Orientada a Modelos é responsável por sua modelagem através de um metamo-delo, que são representados por uma DSL, ou um meta-metamodelo.[15] O MDA dividea modelagem em 3 camadas que definiriam todo o processo desde a modelagem até ageração do código propriamente dito sendo elas:

Modelo Independente de Computação: Ou Computational Independent Mo-del (CIM), foca no meio no qual o sistema de interesse irá executar suas funções e nascaracterısticas necessárias ao domınio do negócio [16].

Modelo Independente de Plataforma: Ou Platform Independent Model(PIM), foca em expressar as regras de negócios e funcionalidades do sistema sob umaabordagem genérica, a ponto de que independente da tecnologia abordada, o diagramasera sempre o mesmo [17].

Modelo Específico de Plataforma: Ou Platform-Specific Model (PSM), gerao resultado especifico de uma plataforma, criado a partir dos elementos do PIM[16].

2.2.3 Transformação

Segundo Belix(2006) (figura 3), as transformações podem ser classificadas como:CIM para PIM: Esta transformação é a única que não depende de nenhum tipo

de software, sendo de responsabilidade do Engenheiro.PIM para PIM: Aqui, o principal objetivo é o aprimoramento, filtragem e espe-

cialização dos modelos.PIM para PSM: Neste caso, a transformação acontece afim de transformar um

modelo tradicional em um modelo de execução sendo necessário um PIM bastante refi-nado.

PSM para PSM: Aqui, o principal objetivo é o aprimoramento, filtragem e es-pecialização dos modelos.

PSM para PIM: Engenharia reversa(extração de modelos de plataformas jaimple- mentadas)

2.3 Linha de Produtos de Software

Linha de produtos de software (software product line - SPL) são grupos de sistemasque comutam procedimentos em cima de uma base comum facilitando o reuso de umasolução em um segmento de mercado.

Uma linha de produtos de software consiste em uma associação de sistemas com-partilhando um conjunto de características comuns sendo gerenciados por um núcleo.Para possibilitar o reuso em larga escala a engenharia de linha de produto(software pro-

19

Figura 3 – PIM gerando multiplos PSM [4]

duct line engineering - SPLE) deve identificar, gerenciar semelhanças e variações atravésde um conjunto de artefatos tais como requerimentos, arquiteturas, componentes de có-digo e casos de teste, criando assim, uma possibilidade de desenvolvimento mais produtivaem medidas de termos de custo, qualidade e tempo[18].

Uma linha de produtos de software se advém através de uma etapa de engenhariade domínio e outra de engenharia de aplicação. o principal benefício dessa segmentação éque os objetivos de cada etapa estão também separados, permitindo de um lado focar emproduzir uma base robusta, e do outro construir os produtos específicos em curto períodode tempo.

A figura 4 elucida o modo com que estas etapas interagem entre si, e exibe o resul-tado esperado através do fluxo de informações.Tanto na engenharia de domínio quanto naengenharia de aplicação são realizadas atividades de análise, arquitetura, implementaçãoe testes para ao final serem gerados os produtos [5].

2.3.1 Variabilidade

A variabilidade representa a capacidade de diversificação de uma SPL, no iniciodo desenvolvimento existe uma expectativa, o que torna vasta a possibilidade de sistemasa serem desenvolvidos, ao desenrolar do processo são feitas decisões de design que acabamrestringindo o número de sistemas realizáveis [6].Para que seja realizado o estudo de variabilidade, artefatos de referência são empregados,eles validam o software dentro de um domínio de aplicação especifico. E uma SPL exis-tem vários artefatos de referência tal como requisitos de linha de produto, teste de linhasproduto, etc, mas o principal é a arquitetura de linha de produto ou Product-Line Archi-tecture(PLA), ela é necessária pois é o vinculo entre os requisitos do cliente, o domínio eo novo produto a ser instanciado [6].Arquitetura de software comuns são utilizadas para descrever estrutura, comportamentoe a relação entre os diversos componentes do sistema. Já uma PLA é mapeada somenteem um domínio especifico e precisa ser mais genérica possível, de modo a atender todo

20

Figura 4 – Dois ciclos de vida que separam engenharia de domínio e aplicação [5].

o escopo. As variabilidades de uma PLA são modeladas a partir da elucidação de pontosde variabilidade e variantes[6] segundo NASCIMENTO(2015):

Pontos de variabilidade: Define um conjunto de possíveis variantes, o meca-nismo de variabilidade para instanciar as variantes e o tempo de ativação das variantes.Os pontos de variabilidade podem ser descritos em diversos níveis de abstração (Tabela1)

Variantes: Corresponde a uma opção do conjunto de possíveis instâncias devariação que um ponto de variabilidade poderá originar.

Nivel de abstração Descrição

ArquiteturaUtilização de documentos de alto nível de designcomo linguagens de descrição de arquitetura edocumentação de texto.

Diagramas Utilização de diagramas UMLCódigo-fonte Descrição dos pontos na forma de código fonte.Código compilado O código fonte é compilado para ser analisado.

Código ligado

Os resultados obtidos na fase de compilaçãosão ligados de forma estática em tempo decompilação ou de forma dinâmica em tempo deexecução.

Código de execuçãoO sistema é construído e configurado.Devido ao dinamismo, mudanças ocorrema todo o tempo.

Tabela 1 – Exemplo dos diversos níveis de abstração onde pontos de variabilidade podemser aplicados [6].

21

2.3.2 Gestão de Variabilidade

Por resultar em múltiplos produtos, uma alta demanda de requisitos deve ser aten-dida, e com isso se manifesta uma necessidade de adaptação em larga escala, para estepropósito foi criado o conceito de gestão de variabilidade (variability management - VM),atividade cujo objetivo é documentar explicitamente as variações dos produtos dentro dociclo de vida de uma linha de produto como forma de dar apoio às suas instanciações[5].Tornando a SPL o mais dinâmico possível, segundo NASCIMENTO(2015) a gestão devariabilidade consiste nas seguintes tarefas:

Identificação de variabilidades: Na fase inicial de desenvolvimento de uma SPLexiste um confronto de uma série de requisitos. Uma análise de requisitos é necessária paragerar uma especificação adequada. O objetivo desta tarefa é identificar as diferenças en-tre os produtos e as características que existem em comum. A forma mais tradicional econhecida para representar pontos de variabilidade são os modelos de feature;

Introdução de variabilidade no sistema: Após a identificação dos pontos devariabilidade, ocorre o projeto do sistema customizado para introdução das mesmas.

Agrupamento de variantes: O resultado desta fase é um conjunto de variantesassociadas a um ponto de variabilidade. Este conjunto de variantes pode ser represen-tada de quatro formas: implícita, quando as variantes são baseadas no conhecimento dosdesenvolvedores ou usuários; explícita, quando o sistema de forma independente decidequais variantes deseja fazer uso (está associada a sistemas inteligentes); fechada, quandonenhuma variante pode ser acrescentada; aberta, quando novas variantes podem ser in-troduzidas.

Vinculação de sistemas a variantes: O resultado é a associação de um pontode variabilidade a uma de suas variantes. Esta associação poderá ser interna ou externa.Na associação interna o sistema possui a capacidade de uma variante. Já em uma associ-ação externa o sistema precisa de outras ferramentas para vincular a variante como, porexemplo, ferramenta para gerenciamento de configuração.

2.3.3 Engenharia de Domínio

Responsável por estabelecer o cerne da linha de produto e, assim definir comuna-lidade e a variabilidade da linha de produtos. A plataforma consiste em todos as tipos deartefatos de software (requisitos, design,testes, etc.) também chamados de ativos base[5].

2.3.4 Engenharia de Aplicação

Responsável por produzir os produtos a partir do cerne definido na engenharia dedomínio. Através da gestão de variabilidade ela assegura uma instanciação de acordo comos requisitos apontados em levantamento para as aplicações finais[5].

22

2.3.5 Conjunto de Ativos

É a ideia principal por trás de uma SPL, são os elementos customizáveis que se-rão utilizados na construção do software. Essa customização pode atuar em componentesde software, modelos de documentos utilizados em processos, padrões de projeto, docu-mento de requisitos, arquitetura de linha de produto entre outros, o fator limitante é acriatividade da equipe[6].

2.3.6 Vantagens

segundo NASCIMENTO(2015) os benefícios da adoção de uma SPL podem serdescritos de duas formas: benefícios tangíveis e benefícios intangíveis. Benefícios tangí-veis (Tabela2) são benefícios que podem ser medidos diretamente e estão relacionados abenefícios comerciais, e os benefícios intangíveis(Tabela3) são benefícios relatados pelosprofissionais de TI, mas que não podem ser medidos e estão relacionados a benefíciosorganizacionais

Benefícios Tangíveis

Lucratividade

Repositório de ativos permite que umaorganização foque sua produção em umsegmento de mercado aumentando aparticipação no mercado.

Qualidade

Existe uma redução no número de defeitos,assim como redução no tempo de correçõese redução do efeito ripple (defeitosoriginários de correções).

Performance Aumento do desempenho devido aumento damaturidade da SPL, aumentando a otimização.

Tempo deintegração

Facilita o tempo devido ao desenvolvimentoincremental.

Produtividade Redução da equipe, custo total de desenvolvimento,cronograma e aumento do feedback.

Tabela 2 – Descrição dos benefícios tangíveis [6].

Benefícios IntangíveisDesgasteprofissional

Redução de desgaste profissionale deturnover (rotatividade de profissionais).

Aceitabilidade Maior aceitabilidade dos profissionais.Satisfaçãoprofissional

Concentração das atividades emaperfeiçoamento e inovação.

Satisfaçãodos clientes

Redução de riscos e defeitos, aumentode previsibilidade de entrega.

Tabela 3 – Descrição dos benefícios intangíveis [6].

23

2.4 Desenvolvimento Orientado a Modelos atrelado a uma Li-nha de Produtos de Software

O desenvolvimento orientado a modelos e linha de produtos de software se manifes-tam como arquiteturas complementares visando o aumento de produtividade fornecendométodos e ferramentas para a elaboração de programas, uma vez que o desenvolvimentoorientado a modelo dá bastante ênfase na fabricação de modelos de sintaxe e semânticasbem definidas ao invés do código fonte, e a linha de produtos por sua vez lida com o de-senvolvimento sistemático de produtos pertencentes a um conjunto de sistemas, ao invésde gerar cada instância da linha desde o princípio [19].

Fabricas de software (Software factories) [20] é como a Microsoft denomina aabordagem de um desenvolvimento que integra linguagens de domínio específico utili-zando ferramentas configuráveis e extensıveis para modelagem com a engenharia de linhade produtos de software [21].

Essa abordagem apresenta um ganho qualitativo durante a etapa do levantamentode requisitos na indústria, visto que permite ao cliente visualizar a solução por meio deconjuntos de componentes pré-definidos, sem se preocupar com detalhes de implementa-ção, o que facilita na comunicação empresa-cliente ao longo do planejamento de atividades[9].

24

3 PROPOSTA DA ABORDAGEM DE DESENVOLVI-MENTO DE UMA SPL COM MDD

3.1 Visão Geral

3.2 Analise de Domínio

3.3 Projeto de Domínio

3.4 Implementação de Domínio

3.5 Modelo de Processo

25

4 ESTUDO DE CASO DA PROPOSTA

4.1 Passo a Passo da Proposta

4.1.1 Levantamento

4.1.2 Requisitos

4.1.3 Analise

4.2 Analise de Resultados

4.2.1 Projeto de Produtos Futuros

26

5 DISCUSSÃO E CONCLUSÃO

5.1 Trabalhos Relacionados

5.2 Implicações e Limitações

5.3 Conclusão

27

REFERÊNCIAS

[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 6028 : Resumo -apresentação. Rio de Janeiro, 2003. 2 p.

[2] PRESSMAN, R. S. Engenharia de Software: Uma abordagem profissional. PortoAlegre: Amgh: 7.ed., 2011.

[3] LUCREDIO, D. Uma abordagem orientada a modelos para reutilização de software.2009. Tese de Doutorado, Instituto de Ciências Matemáticas e de Computação,Universidade de São Paulo, São Carlos.

[4] BELIX, J. E. Um estudo sobre MDA: suporte fornecido pela UML e reuso desoluções pré-definidas. 2006. Dissertação, Escola Politécnica, Universidade de SãoPaulo, São Paulo.

[5] SILVA, A. F. et al. Linhas de produtos de software: Uma tendência da indústria.Escola Regional de Informática, p. 7–31, 11 2011.

[6] NASCIMENTO, R. J. O. do. Linha de Produto de Software. 2015. <https://www.devmedia.com.br/linha-de-produto-de-software/33894>.

[7] JUSTO, J. L. B.; ARAUJO, N. M.; GARCIA, A. G. Software reuse and continuoussoftware development: A systematic mapping study. IEEE Latin AmericaTransactions, v. 16, n. 5, p. 1539–1546, May 2018. ISSN 1548-0992.

[8] ASSUNÇÃO, W. K. G. et al. Reengineering legacy applications into softwareproduct lines: a systematic mapping. Empirical Software Engineering, v. 22,n. 6, p. 2972–3016, Dec 2017. ISSN 1573-7616. Disponível em: <https://doi.org/10.1007/s10664-017-9499-z>.

[9] DAGEFöRDE, J. C. et al. Generating app product lines in a model-driven cross-platform development approach. In: 2016 49th Hawaii International Conference onSystem Sciences (HICSS). [S.l.: s.n.], 2016. p. 5803–5812. ISSN 1530-1605.

[10] SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Education Limited:6.ed., 2003.

[11] SELIC, B. The pragmatics of model-driven development. IEEE Software, v. 20, n. 5,p. 19–25, Sept 2003. ISSN 0740-7459.

[12] EISHIMA, T. Proposta de um processo de desenvolvimento de software orientadoa modelo. 2014. Trabalho de Conclusão de Curso, Departamento de Computação,Universidade Estadual de Londrina, Londrina, Paraná.

[13] RICCA, F. et al. On the impact of state-based model-driven development on main-tainability: a family of experiments using unimod. Empirical Software Engineering,Nov 2017. Disponível em: <https://doi.org/10.1007/s10664-017-9563-8>.

[14] HAILPERN, B.; TARR, P. Model-driven development: The good, the bad, and theugly. IBM Systems Journal, v. 45, n. 3, p. 451–461, 2006. ISSN 0018-8670.

28

[15] STAHL, T.; VOELTER, M.; CZARNECKI, K. Model-Driven Software Development:Technology, Engineering, Management. USA: John Wiley &#38; Sons, Inc., 2006.ISBN 0470025700.

[16] FRANCE, R.; RUMPE, B. Model-driven development of complex software: Aresearch roadmap. In: 2007 Future of Software Engineering. Washington, DC,USA: IEEE Computer Society, 2007. (FOSE ’07), p. 37–54. ISBN 0-7695-2829-5.Disponível em: <https://doi.org/10.1109/FOSE.2007.14>.

[17] SOLEY, R. Model driven architecture. OMG white paper. <https://www.omg.org/~soley/mda.html>. Accessed: 2018-05-13.

[18] BABAR, M. A.; CHEN, L.; SHULL, F. Managing variability in software productlines. IEEE Software, v. 27, n. 3, p. 89–91, 94, May 2010. ISSN 0740-7459.

[19] BUCHMANN, T.; SCHWäGERL, F. Breaking the boundaries of meta models andpreventing information loss in model-driven software product lines. In: Proceedingsof the 11th International Conference on Evaluation of Novel Software Approaches toSoftware Engineering. [S.l.: s.n.], 2016. p. 73–83. ISBN 978-989-758-189-2.

[20] GREENFIELD, J. Software factories: Assembling applications with patterns, models,frameworks, and tools. [s.n.], 2004. v. 3154. 304 p. (Lecture Notes in ComputerScience (including subseries Lecture Notes in Artificial Intelligence and LectureNotes in Bioinformatics), v. 3154). Cited By :3. Disponível em: <www.scopus.com>.

[21] AZEVEDO, S.; MACHADO, R. J.; MUTHIG, D. Multistage model transformationsin software product lines. In: 2009 Fourth International Conference on SoftwareEngineering Advances. [S.l.: s.n.], 2009. p. 565–569.

Apêndices

30

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

32

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.

33

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)