UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA
CURSO SUPERIOR DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
RENAN RAMON RAMOS MENDES
LINHAS DE PRODUTO DE SOFTWARE: UM ESTUDO DE CASO
PARA O DESENVOLVIMENTO DE UM SISTEMA DE FAQ
TRABALHO DE CONCLUSÃO DE CURSO
PONTA GROSSA 2015
LINHAS DE PRODUTO DE SOFTWARE: UM ESTUDO DE CASO
PARA O DESENVOLVIMENTO DE UM SISTEMA DE FAQ
Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do título de Bacharel em Ciência da Computação, do Departamento Acadêmico de Informática, da Universidade Tecnológica Federal do Paraná.
Orientadora: Prof.ª Simone Nasser Matos
PONTA GROSSA 2015
TERMO DE APROVAÇÃO
Linhas de Produto de Software: Um Estudo de Caso para o Desenvolvimento de um Sistema de FAQ
por
RENAN RAMON RAMOS MENDES
Este Trabalho de Conclusão de Curso (TCC) foi apresentado em 26 de maio de 2015 como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação. O candidato foi arguido pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado.
_________________________________________ ______________________________________ Profª Drª Simone Nasser Matos Prof. Dr. Tarcizio Alexandre Bini Orientadora Membro titular
_____________________________________ ______________________________________ Prof. Dr. Ionildo José Sanches Prof. MSc Vinicius Camargo Andrade Responsável pelos Trabalhos Membro titular
de Conclusão de Curso
______________________________________ Prof. Dr Gleifer Vaz Alves
Coordenador do curso
Ministério da Educação
Universidade Tecnológica Federal do Paraná
Câmpus Ponta Grossa
Diretoria de Graduação e Educação Profissional
RESUMO
MENDES, Renan Ramon Ramos. Linhas de Produto de Software: Um Estudo de
Caso para o Desenvolvimento de um Sistema de FAQ. 2015. 130f. Trabalho de
Conclusão de Curso (Bacharelado em Ciência da Computação) - Universidade Tecnológica Federal do Paraná. Ponta Grossa, 2015.
As Linhas de Produto de Software (LPS) surgiram como alternativa ao paradigma de desenvolvimento tradicional do software, impulsionadas principalmente por técnicas de reutilização de código. Nesta abordagem, os desenvolvedores preocupam-se em identificar similaridades e variabilidades de um domínio, para criar e manter um núcleo de software, que definirá a plataforma da linha. A partir do núcleo, é possível construir produtos com características diferentes, atendendo a requisitos específicos de cada cliente. Este trabalho aplicou um método de desenvolvimento baseado em Linhas de Produto de Software para modelagem e implementação de um sistema de FAQ (Perguntas Frequentes). Para isto, analisaram-se três produtos neste domínio: O Globo, Lojas Americanas e FAQ FrameMK, com o objetivo de determinar as características que fariam parte do núcleo e as que são específicas da aplicação. Para validar a linha foram criados projetos para cada produto analisado, porém o produto que teve seu desenvolvimento completo foi o FAQ FrameMK, o qual foi integrado ao framework de formação de preço de venda que está sendo desenvolvimento pelo Grupo de Pesquisa em Sistemas de Informação do Câmpus Ponta Grossa. O sistema FAQ proposto foi implementado em uma linguagem de programação web. São apresentados também os procedimentos de como usar e adicionar novos requisitos à linha.
Palavras-chave: Linhas de Produto. Sistema de FAQ. Framework de Domínio.
ABSTRACT
MENDES, Renan Ramon Ramos. Linhas de Produto de Software: Um Estudo de
Caso para o Desenvolvimento de um Sistema de FAQ. 2015. 130f. Trabalho de
Conclusão de Curso (Bacharelado em Ciência da Computação) - Federal Technology University - Parana. Ponta Grossa, 2015.
The Software Product Lines (LPS) arose as alternative to the traditional software development paradigm, driven primarily by code reuse techniques. In this approach, developers are concerned with identifying similarities and variabilities of a domain, to create and maintain a software core that will define the line platform. From the core, it is possible to build products with different features, catering to specific requirements of each client. This study applied a method of development based on Software Product Lines for modeling and implementing a FAQ System (Frequently Asked Questions). For this, analyzed three products in this domain: O Globo, Lojas Americanas and FAQ FrameMK, in order to determine the features that would be part of the core and those that are specific application. To validate the line, projects were created for each product analyzed; however the product that had its full development was the FAQ FrameMK, which was integrated into the framework of selling price formation being development by the Research Group in Information Systems campus Ponta Grossa. The proposed FAQ system was implemented in a web programming language. Also presents the procedures of using and adding new requirements to the line.
LISTA DE ILUSTRAÇÕES
Figura 1 - Atividades essenciais em Linhas de Produto de Software ... 18
Figura 2 - Execução da atividade de Desenvolvimento de Ativos-Base ... 19
Figura 3 - Execução da atividade de Desenvolvimento de Produtos ... 20
Figura 4 - Interação das atividades de Engenharia de Domínio e de Aplicação ... 21
Figura 5 - Abordagens para construção de Linhas de Produto de Software ... 22
Figura 6 - Classificação das características a partir de três produtos ... 24
Figura 7 - E-Shop representado através do Modelo de Características ... 25
Figura 8 - Processo do Método FAST ... 27
Figura 9 - Método FODA ... 30
Figura 10 - Método PLUS ... 32
Figura 11 - Engenharia da Linha de Produto do Método PLUS ... 33
Figura 12 - Método Delazeri e Wolf ... 34
Figura 13 - Linha cronológica de trabalhos no desenvolvimento do FrameMK ... 39
Figura 14 - Arquitetura atual do FrameMK ... 40
Figura 15 - Rotina de manutenção de preços do webERP, antes e depois da integração com o FrameMK ... 41
Figura 16 - Tela do webERP para o método Sebrae de formação de preço de venda ... 41
Figura 17 - Tela do webERP com o preço atualizado pelo FrameMK ... 42
Figura 18 - Sistema de FAQ Lojas Americanas ... 45
Figura 19 - Sistema de FAQ Jornal O Globo ... 46
Figura 20 - Interfaces e funcionalidades do FAQ do FrameMK ... 47
Figura 21 - Diagrama de contexto para o domínio de FAQ ... 50
Figura 22 - Características do sistema de FAQ das Lojas Americanas ... 53
Figura 23 - Características do sistema de FAQ do Jornal O Globo ... 55
Figura 24 - Interface gráfica do sistema de FAQ para o FrameMK ... 56
Figura 25 - Diagrama de características para os sistemas estudados ... 58
Figura 26 - Diagrama de features das características de núcleo ... 62
Figura 27 - Diagrama de features das características opcionais ... 62
Figura 28 - Diagrama de casos de uso das similaridades ... 63
Figura 29 - Interfaces de sistema das similaridades ... 66
Figura 30 - Diagrama de conceitos de negócio das similaridades ... 66
Figura 31 - Interfaces de negócio das similaridades ... 67
Figura 32 - Interfaces de sistema e de negócio das similaridades ... 68
Figura 33 - Diagrama de componentes das similaridades ... 69
Figura 34 - Estrutura do projeto da linha de produto ... 71
Figura 35 - Estrutura do pacote Gerenciador de Categorias ... 71
Figura 36 - Classes Category e CategoryDAO... 72
Figura 38 - Arquivo de mapeamento entre a classe e tabela Category ... 73
Figura 39 - Classe responsável pela comunicação com o banco ... 73
Figura 40 - Teste de aceitação da linha ... 74
Figura 41 - Testes de aceitação da linha ... 75
Figura 42 - Esquema de monitoramento de perguntas enviadas ... 76
Figura 43 - Diagrama de casos de uso das variabilidades ... 76
Figura 44 - Diagrama de classes das variabilidades ... 77
Figura 45 - Estrutura do projeto FAQFrameMK... 78
Figura 46 - Métodos do monitoramento de perguntas ... 79
Figura 47 - Testes de aceitação da aplicação ... 80
Figura 48 - Exemplo utilização das Interfaces de Negócio da linha de produtos ... 82
Figura 49 - Interface do usuário do sistema de FAQ do FrameMK ... 84
Figura 50 - Interface de usuário do FAQ das Lojas Americanas, obtida a partir do uso da linha ... 85
Figura 51 - Interface de usuário do FAQ Jornal O Globo, obtida a partir do uso da linha ... 85
Figura 52 - Processo para ampliar a linha ... 86
Figura 53 - Arquitetura do FrameMK com a instância do Sistema de FAQ ... 89
Figura 54 - Detalhe da integração do sistema de FAQ ao FrameMK ... 89
Figura 55 - Detalhe da área restrita do Sistema de FAQ. ... 90
Figura 56 - Tela de autenticação de funcionário no sistema de FAQ do FrameMK 102 Figura 57 - Tela de controle de respostas do sistema de FAQ do FrameMK ... 104
Figura 58 - Tela principal do administrador do sistema de FAQ do FrameMK ... 105
Figura 59 - Tela de monitoramento de perguntas do sistema de FAQ do FrameMK ... 107
Figura 60 - Tela de controle de perguntas e categorias do sistema de FAQ do FrameMK... 109
Figura 61 - Tela de controle de funcionários do sistema de FAQ do FrameMK ... 110
Figura 62 - Tela de controle de especialidades do sistema de FAQ do FrameMK .. 112
Figura 63 - Arquitetura do processo UML Components ... 119
Figura 64 - Processo de desenvolvimento do método UML Components ... 119
Figura 65 - Diagrama de Processos de Negócio ... 121
Figura 66 - Casos de Uso a partir do Diagrama de Processos de Negócio ... 123
Figura 67 - Diagrama de Casos de Uso ... 124
Figura 68 - Descrição do Caso de Uso Autenticar ... 124
Figura 69 - Casos de Uso e suas Interfaces ... 125
Figura 70 - Modelo de Conceitos de Negócio ... 125
Figura 71 - Modelo de Conceitos de Negócio com as Interfaces de Negócio ... 126
Figura 72 - Modelo de Tipos de Negócio ... 126
Figura 73 - Componentes do Sistema ... 127
Figura 74 - Interações da Interface Autenticar ... 128
Figura 76 - Modelo de Informação da Interface... 129
Figura 77 - Pré e Pós Condições da Interface Saldo ... 129
Figura 78 - Contrato de Realização entre as Interfaces Autenticar e Sacar ... 130
Figura 79 - Os sete passos do método UML Components ... 130
Gráfico 1 - Comparativo entre a abordagem tradicional e a abordagem de LPS ... 28
Quadro 1 - Fundamentos das Linhas de Produto de Software relacionados com os conceitos do trabalho de Parnas (1976) ... 17
Quadro 2 - Artefatos de entrada e saída produzidos no Método Adaptado ... 36
Quadro 3 - Conjunto de características por contexto ... 51
Quadro 4 - Características de interface gráfica e lógica para o sistema de FAQ das Lojas Americanas ... 53
Quadro 5 - Características de interface gráfica e lógica para o sistema de FAQ do Jornal O Globo ... 55
Quadro 6 - Características de interface gráfica e lógica para o sistema de FAQ do FrameMK... 57
Quadro 7 - Lista de características identificadas ... 60
Quadro 8 - Classificação das características encontradas ... 61
Quadro 9 - Descrição para o caso de uso consultar pergunta e resposta ... 64
Quadro 10 - Descrição para o caso de uso manter pergunta e resposta ... 64
Quadro 11 - Descrição para o caso de uso enviar resposta ... 65
Quadro 12 - Elementos codificados na linha ... 83
Quadro 13 - Relação dos contextos implementados e não implementados ... 88
Quadro 14 - Características da tela de autenticação do funcionário do Sistema de FAQ do FrameMK ... 102
Quadro 15 - Características da tela de controle de respostas para o Sistema de FAQ do FrameMK ... 104
Quadro 16 - Características da tela principal do administrador do Sistema de FAQ do FrameMK... 105
Quadro 17 - Características da tela de monitoramento do Sistema de FAQ do FrameMK... 107
Quadro 18 - Características da tela de controle de perguntas e categorias do Sistema de FAQ do FrameMK ... 109
Quadro 19 - Características da tela controle de funcionários do Sistema de FAQ do FrameMK... 111
Quadro 20 - Características da tela controle de especialidades do Sistema de FAQ do FrameMK ... 112
Quadro 21 - Descrição para o caso de uso Buscar Pergunta/Categoria ... 114
Quadro 22 - Descrição para o caso de uso Monitorar Perguntas Enviadas ... 114
Quadro 23 - Descrição para o caso de uso Consultar Funcionário ... 114
Quadro 24 - Descrição para o caso de uso Consultar Categoria ... 114
Quadro 26 - Descrição para o caso de uso Manter Categoria ... 115 Quadro 27 - Descrição para o caso de uso Manter Funcionário ... 116 Quadro 28 - Descrição para o caso de uso Enviar Pergunta ... 116 Quadro 29 - Subfases da fase de Especificação dos Componentes do método UML Components ... 120
LISTA DE SIGLAS
ABC Activity Based Costing EE Enterprise Edition
ESPLEP Evolutionary Software Product Line Engineering Process FODA Feature Oriented Domain Analysis
GUI Graphical User Interface
IDE Integrated Development Environment JDBC Java Database Connectivity
LPS Linhas de Produto de Software MBSE Model-Based Software Engineering PLE Product Line Engineering
UML Unified Modeling Language
LISTA DE ACRÔNIMOS
ARPANET Advanced Research Projects Agency Network FAQ Frequently Asked Questions
FAST Family-Oriented Abstraction, Specification and Translation NASA National Aeronautics and Space Administration
PLUS Product Line UML-Based Software Engineering ROIC Return On Invested Capital
SEBRAE Serviço Brasileiro de Apoio às Micro e Pequenas Empresas SEI Software Engineering Institute
SUMÁRIO 1INTRODUÇÃO ...12 1.1 OBJETIVOS ...13 1.1.1Objetivo Geral ...13 1.1.2Objetivos Específicos ...14 1.2 ORGANIZAÇÃO DO TRABALHO ...14 2LINHAS DE PRODUTO ...15
2.1 ORIGEM DE LINHAS DE PRODUTO ...15
2.2 ATIVIDADES E ABORDAGENS DE UMA LPS ...17
2.2.1Variabilidade da Linha e Ativos de Núcleo ...23
2.3 MODELOS DE DESENVOLVIMENTO DE LPS ...24
2.3.1FAST ...27
2.3.2FODA ...29
2.3.3PLUS ...31
2.3.4Método Adaptado de Delazeri e Wolf ...33
3FRAMEWORK DE DOMÍNIO PARA FORMAÇÃO DE PREÇO DE VENDA ...37
3.1 DEFINIÇÃO ...37
3.2 DESENVOLVIMENTO DO FRAMEMK ...38
3.2.1Linha Cronológica do FrameMK ...38
3.2.2Arquitetura do FrameMK ...40
4SISTEMAS FAQS (FREQUENTLY ASKED QUESTIONS) ...43
4.1 ORIGEM E DEFINIÇÃO ...43
4.2 EXEMPLOS DE SISTEMAS DE FAQ ...44
4.2.1Sistema de FAQ das Lojas Americanas ...45
4.2.2Sistema de FAQ do jornal O Globo ...46
4.2.3Sistema de FAQ proposto para o FrameMK ...47
5MODELAGEM DO SISTEMA DE FAQ USANDO LPS ...49
5.1 ANÁLISE DO DOMÍNIO ...49 5.2 IDENTIFICAÇÃO DE CARACTERÍSTICAS ...51 5.2.1Requisitos do Domínio ...52 5.2.2Modelagem do Domínio ...63 5.2.3Projeto do Domínio ...65 5.2.4Implementação do Domínio ...70 5.2.5Testes do Domínio ...74 5.3 REQUISITOS DA APLICAÇÃO ...75 5.4 IMPLEMENTAÇÃO DA APLICAÇÃO...78 5.5 TESTES DA APLICAÇÃO ...79 6RESULTADOS ...81 6.1 USO DA LINHA ...81
6.2 PRODUTOS GERADOS A PARTIR DA LINHA ...84
6.3 PROCEDIMENTOS PARA AMPLIAR A LINHA ...86
6.4 RESTRIÇÕES DA LINHA ...87
6.5 INTEGRAÇÃO COM O FRAMEMK ...88
7CONCLUSÃO ...91
7.1 TRABALHOS FUTUROS ...92
REFERÊNCIAS ...93
APÊNDICE A -CONTINUAÇÃO DA ETAPA DE REQUISITOS DE DOMÍNIO DO FAQ FRAMEMK ...101
APÊNDICE B -DESCRIÇÃO DOS CASOS DE USO DAS CARACTERÍSTICAS DE NÚCLEO E OPCIONAIS ...113
1 INTRODUÇÃO
Os desenvolvedores impulsionados pela estruturação do software em componentes e o desenvolvimento orientado a objetos, passam a buscar iniciativas para tornar viável o reuso em diversas etapas do processo de desenvolvimento de sistemas (PEREIRA, 2010).
Um dos resultados dessa busca foi a definição do processo de desenvolvimento baseado em Linhas de Produto de Software (LPS). As LPS se caracterizam por permitir o desenvolvimento de um conjunto de sistemas que compartilham características, atendendo a um mercado ou domínio, e que são construídos a partir de uma plataforma que reúne as funcionalidades principais de cada produto da linha (CLEMENTS; NORTHROP, 2001). Ela representa uma alternativa ao paradigma tradicional que aborda o desenvolvimento individual de produtos. Nas LPS, os esforços passam ser concentrados na criação e manutenção de um conjunto de produtos similares, formando assim uma família de produtos (PEREIRA, 2010).
Este trabalho apresenta a aplicação dos conceitos sobre linha de produto de software no domínio de FAQ (Frequently Asked Questions). Os sistemas de FAQ consistem em uma base de dados que possui as perguntas mais frequentes sobre um determinado assunto (SILVA, 2003).
Para o desenvolvimento do sistema foram estudados quatro métodos voltados à linha de produto de software, a saber, método FAST (WEISS; LAI, 1999), método FODA (KANG et al., 1990), método PLUS (GOMAA, 2004) e o método adaptado de Delazeri e Wolf (2012). Dentre eles, selecionou-se o método de Delazeri e Wolf (2012) para a modelagem do sistema FAQ proposto, pois ele reúne características dos outros três métodos citados.
Este método exige a análise de três produtos pertencentes ao domínio. Neste trabalho selecionou-se: FAQ O Globo (O GLOBO, 2014), FAQ das Lojas Americanas (LOJAS AMERICANAS, 2014) e FAQ FrameMK. Dentre outros sistemas de FAQ identificados, foram estes os que apresentavam variações em suas características, dentre elas, divisão das perguntas em categorias e formulário para envio de perguntas que não estão presentes no sistema. Dessa forma, a modelagem da linha apresenta-se mais completa para o domínio estudado.
As características dos dois primeiros produtos foram identificadas acessando suas respectivas páginas e executando suas opções funcionais, já para o FAQ FrameMK as características foram obtidas por meio de entrevista com a responsável pelo projeto do framework de formação de preço de venda FrameMK, que está sendo desenvolvido pelo grupo de pesquisa em Sistemas de Informação, na área de Engenharia de Software desta instituição.
A partir da análise dos produtos foi gerada a linha que visa atender o controle de perguntas e respostas, funcionários e de categorias. A linha contém as características que foram classificadas como núcleo, opcionais e alternativas. A linha foi implementada no ambiente Eclipse EE versão Indigo (ECLIPSE, 2012), na qual foram acrescentadas as bibliotecas do Framework Hibernate (HIBERNATE, 2015), JDBC (Java Database Connectivity) Jaybird (FIREBIRD, 2015), Apache Commons Email (APACHE COMMONS, 2014) e JavaMail (ORACLE, 2014). O banco de dados utilizado foi o Firebird 2.5 (FIREBIRD, 2011). Para sua modelagem foi utilizado a Astah Professional (CHANGE VISION, 2015) e Odyssey (ODYSSEY, 2015).
Os três produtos analisados foram instanciados com o objetivo de verificar se suas características estavam sendo atendidas e para isto criou-se três novos projetos dentro do ambiente de implementação.
O produto que foi gerado com todas as suas funcionalidades foi o FAQ FrameMK, pois o mesmo será usado no framework de formação de preço de venda.
Este trabalho descreve também os procedimentos necessários para ampliar a linha, ou seja, quando novos requisitos são adicionados a ela.
1.1 OBJETIVOS
Esta seção aborda os objetivos do trabalho. A subseção 1.1.1 descreve o objetivo geral e os objetivos específicos são apresentados na subseção 1.1.2.
1.1.1 Objetivo Geral
Desenvolver uma linha de produto de software para o FAQ, na qual foram analisados três produtos no domínio, e a partir desta criar um produto que pudesse ser integrado ao framework de domínio de formação de preço de venda FrameMK.
1.1.2 Objetivos Específicos
Identificar métodos para construção de linhas de produtos de software e dentre eles escolher um que pudesse ajudar no desenvolvimento da linha proposta.
Escolher três produtos no domínio de FAQ.
Aplicar um método de modelagem de linha de produto de software no domínio de FAQ.
Implementar a linha de produto de software na linguagem Java.
Estender as características de núcleo para os três produtos analisados. Apresentar o procedimento de uso e modificação da linha.
1.2 ORGANIZAÇÃO DO TRABALHO
O trabalho é constituído de sete capítulos. O Capítulo 2 aborda conceitos sobre a abordagem de desenvolvimento de software baseado em Linhas de Produto.
O Capítulo 3 traz a definição de framework de domínio e informações sobre o FrameMK, juntamente com trabalhos publicados a seu respeito.
O Capítulo 4 aborda o conceito de FAQ, acompanhado de exemplos de FAQ disponibilizados por algumas organizações.
O Capítulo 5 apresenta a modelagem do sistema FAQ usando o método de Delazeri e Wolf (2012).
O Capítulo 6 descreve os resultados atingidos com o desenvolvimento da linha. Por fim, o último Capítulo apresenta as considerações finais do trabalho bem como a relação de trabalhos futuros que podem ser desenvolvidos a partir deste.
2 LINHAS DE PRODUTO
Este Capítulo apresenta a definição sobre Linhas de Produto de Software (LPS), relatando sua origem, modelos, métodos e abordagens de desenvolvimento. A seção 2.1 relata a contextualização histórica das linhas de produto e suas primeiras utilizações no desenvolvimento de software. A seção 2.2 descreve a definição de linhas de produto de software e suas abordagens de construção. A seção 2.3 aborda os modelos e métodos de desenvolvimento para LPS.
2.1 ORIGEM DE LINHAS DE PRODUTO
O processo produtivo dos bens de consumo foi constantemente modificado com o passar do tempo. No âmbito dos automóveis, uma dessas modificações foi a criação da linha de produção, também chamada de linha de montagem, implantada por Henry Ford em 1913. Ela possibilitou produzir automóveis para o mercado de massa com custos e prazos inferiores, se comparada com a base de produção artesanal. Em contrapartida, a diversificação de produtos fora comprometida (SILVA et al., 2011; PEREIRA, 2010).
Nem todos os clientes desejavam adquirir o mesmo tipo de carro, afinal, cada um tinha sua necessidade particular. Dessa forma, a indústria adaptou-se novamente e criou a chamada customização em massa, ou seja, produtos que atendam às exigências de grupos específicos de clientes (SILVA et al., 2011).
A produção individualizada gera mais custos a indústria, sendo forçada a aumentar o preço dos produtos ou diminuir a margem de lucro. Ambas as medidas são indesejáveis no cenário competitivo de mercado. A solução encontrada pelas indústrias foi estabelecer uma plataforma comum para seus diferentes produtos, nesse caso, os carros, e administrar as peças que seriam utilizadas em vários tipos de automóveis (SILVA et al., 2011).
Com o passar do tempo, as indústrias investiram no aperfeiçoamento da plataforma para deixá-la mais adaptável à inserção de novos componentes. Esses investimentos tornaram o desenvolvimento da plataforma comum mais cara, se comparado às fases de projeto e fabricação. Porém, com a adoção dessa medida,
houve uma redução nos custos totais de produção dos automóveis que pertenciam àquela plataforma (POHL et al., 2005).
A mudança na forma de produção na indústria dos automóveis pode ser adotada também na indústria de software. As empresas atendem a diversos requisitos individuais dos clientes e também as características similares, definindo componentes de produção em massa. Os softwares construídos devem ter maior qualidade, custo reduzido, adaptabilidade às mudanças e rápida inserção no mercado. Objetivando garantir essas vantagens, vários esforços de criação de processos e arquiteturas têm sidos realizados (LINDEN et al., 2007).
Uma abordagem que adota esses princípios da indústria automotiva e ainda incorpora técnicas reutilização de software têm se destacado no ambiente acadêmico e profissional. A Linha de Produtos de Software (LPS) surgiu com a ideia de construir um conjunto de sistemas que compartilham características e atendam necessidades de um segmento, gerenciando suas funcionalidades específicas, por meio de artefatos previamente planejados e desenvolvidos (CLEMENTS; NORTHROP, 2001).
Com o objetivo de identificar as primeiras utilizações documentadas a respeito das Linhas de Produto de Software, Lucrédio (2009) localiza em sua pesquisa, o trabalho de Parnas (1976), que define uma família de programas, a qual estabelece a base para as Linhas de Produto de Software.
Foram estudados pontos similares de uma família de programas, e após, os aspectos diferentes. Nesse trabalho é possível observar a mudança do processo de desenvolvimento tradicional de software em que são considerados os requisitos de um único sistema. O desenvolvedor esforça-se em atender os requisitos de um conjunto de sistemas similares, sendo possível reutilizar os componentes comuns e construir apenas as partes novas do programa. Este conjunto de sistemas similares é denominado família de produtos ou domínio de aplicações.
As partes reutilizáveis são chamadas de arquitetura de referência e de artefatos do núcleo (core assets). O processo de construção de partes comuns é chamado de Engenharia de Domínio e o processo construtivo de um produto é denominado Engenharia de Aplicação (CLEMENTS; NORTHROP, 2001).
Referindo-se ainda ao trabalho de Parnas (1976), os conceitos apresentados são similares aos conceitos pertencentes às linhas de produto de software, apresentados no Quadro 1.
Fundamento da Linha de Produto de Software
Definição do Fundamento Equivalente no trabalho de Parnas (1976)
Gerenciamento das
variabilidades
Determinar, modelar e programar as similaridades e variabilidades de uma família de produtos.
Análise das semelhanças e diferenças entre programas de uma mesma família.
Definição arquitetural Arquitetura de referência que oferece meios concretos para a construção de diferentes produtos
Definição de quais pontos de um programa devem ser deixados sem implementação. Abordagem em dois ciclos Divisão do processo de
desenvolvimento em
Engenharia de Domínio e Engenharia de Aplicações
Refinamento por etapas ou especificação dos módulos e à criação dos programas.
Quadro 1 - Fundamentos das Linhas de Produto de Software relacionados com os conceitos do trabalho de Parnas (1976)
Fonte: Parnas (1976) apud Lucrédio (2009)
A principal diferença da abordagem de Parnas para a de linhas de produto de software é a definição do domínio de acordo com os objetivos de negócio e estratégias de mercado, objetivando benefícios em longo prazo. São determinados quais serão os produtos desenvolvidos, as características a serem implementadas nas primeiras versões, atualizações futuras, entre outras estratégias (LINDEN et al. 2007 apud LUCREDIO, 2009).
2.2 ATIVIDADES E ABORDAGENS DE UMA LPS
Em Clements e Northrop (2001) encontra-se a definição mais aceita de Software Product-Line, termo internacional para Linha de Produto de Software:
A linha de produtos de software (LPS) é um conjunto de sistemas intensivos de software que compartilham um conjunto comum e gerenciado de recursos que satisfaçam as necessidades específicas de um determinado segmento de mercado ou missão e que são desenvolvidos a partir de um conjunto comum de recursos do núcleo de uma forma prescrita. (CLEMENTS; NORTHROP, 2001, p.563).
Resumindo, uma LPS é desenvolvida a partir da especificação do domínio, no qual será definido um conjunto de recursos (funcionalidades) que atendam a este domínio. São identificadas também funcionalidades em comum, que formam o núcleo do software, e as variáveis, que dependem da aplicação específica do produto a ser construído.
O termo Engenharia de Linha de Produto de Software se refere a técnica de engenharia e gerenciamento para criar, manter e aperfeiçoar uma LPS. Ao longo dos últimos anos, esses processos se consolidaram em uma abordagem conhecida como Engenharia de Linha de Produto (PLE, em inglês Product Line Engineering) para Sistemas e Software, englobando todas as atividades envolvidas no planejamento, produção, fornecimento, implantação, manutenção e retirada do produto (SOFTWARE PRODUCT LINES, 2014).
Para desenvolver corretamente uma LPS, Clements e Northrop (2001) definem três atividades essenciais interligadas: Desenvolvimento de Ativos-Base (Core Asset Development) ou Ativos do Núcleo, Desenvolvimento de Produtos (Product Development) e Gestão (Management). Estas atividades são altamente interativas e misturam práticas de negócios e tecnologia.
A Figura 1 ilustra a interação entre elas através de sua ligação e o movimento contínuo (LONG, 2002).
Figura 1 - Atividades essenciais em Linhas de Produto de Software Fonte: Linda Northrop (2008)
A Engenharia de Domínio se preocupa em estabelecer os ativos-base que compõe a plataforma da linha de produto, ou seja, as características (componentes) comuns e variáveis, obtendo artefatos reutilizáveis, aumentando a produtividade da
família de softwares. Os ativos incluem a definição da arquitetura e documentação, especificações, componentes e ferramentas de software, frameworks, modelos de desempenho, estratégias de produção, cronogramas, estratégias de teste entre outras atividades (LONG, 2002; POHL et al., 2005; LINDEN et al., 2007).
Os ativos-base podem ser adaptados dependendo do domínio que está sendo considerado, tornando-os mais reutilizáveis em um contexto mais amplo. Dessa forma, é preciso planejar antes do desenvolvimento.
Como pode ser observado na Figura 2, após a execução do processo de Engenharia de Domínio, é determinado o escopo da linha de produto (product line scope), com a base de ativos do núcleo (core assets base) e o Plano de Produção (Production Plan), que contém todo o processo de produção e os detalhes do projeto (NORTHROP, 2008).
Figura 2 - Execução da atividade de Desenvolvimento de Ativos-Base Fonte: Northrop (2008)
Os artefatos gerados na Engenharia de Domínio formam a estrutura para a construção dos produtos na Engenharia de Aplicação. O Plano de Produção delimita as exigências para cada parte do produto a ser desenvolvido e detalha como os ativos-base serão utilizados (AHMED et al., 2009).
Ao final da atividade de Desenvolvimento de Produtos são disponibilizados os produtos acabados (products) (Figura 3). A direção da seta indica a interação
entre as três atividades. O retorno da informação (feedback) é obrigatório para indicar eventuais problemas e deficiências no processo. Além disso, pode ocorrer de produtos possuírem similaridades não definidas previamente, necessitando assim a atualização dos ativos-base (new assets), ou a disponibilidade e existência de um afetar os requisitos dos próximos produtos, gerando restrições (product constraints) (LONG, 2002).
Figura 3 - Execução da atividade de Desenvolvimento de Produtos Fonte: Northrop (2008)
Os processos de Engenharia de Domínio e de Aplicação são a base para o desenvolvimento de uma linha de produto de software. Com elas é possível verificar a separação de objetivos para conseguir uma plataforma robusta e produtos com fins específicos em curto prazo. A interação entre eles deve existir de maneira benéfica para todo o processo (SILVA et al., 2011).
A Figura 4 mostra a interação entre as atividades. É possível observar que, em cada processo da Engenharia de Domínio, o artefato gerado (artefatos reusáveis ou plataforma) fornece a base para o desenvolvimento de outro processo da Engenharia de Aplicação. Em ambas as atividades são realizados os processos de análise, arquitetura, implementação e testes (SILVA et al., 2011).
Figura 4 - Interação das atividades de Engenharia de Domínio e de Aplicação Fonte: Silva et al. (2011)
Quando são realizados todos os processos da Engenharia de Aplicação o produto está finalizado. Gera-se, então, a informação sobre os resultados de todo o processo para possíveis adaptações, tanto na Engenharia de Domínio quanto na Engenharia de Aplicação. Essas modificações ficam a cargo da atividade de Gestão. A Gestão supervisiona as atividades das Engenharias de Domínio e de Aplicação, garantindo que os elementos que compõe a LPS estejam envolvidos nas atividades, obedecendo ao processo estabelecido. Este acompanhamento é feito em nível técnico, gerencial e organizacional (AHMED et al., 2009).
Outro objetivo da Gestão é garantir o controle e a plena utilização dos ativos-base. Existe grande investimento organizacional em uma linha de produto; o ambiente é estudado previamente para verificar a viabilidade de sua implantação. Conclui-se que as LPS estão mais relacionadas às práticas de negócio do que técnicas, definindo a gestão como a atividade responsável pelo sucesso da linha e seus produtos desenvolvidos (LONG, 2002).
Para o desenvolvimento de Linhas de Produto de Software, Chen (2006) define três abordagens principais (Figura 5).
Figura 5 - Abordagens para construção de Linhas de Produto de Software Fonte: Silva et. al (2011)
A abordagem Proativa permite que os ativos-base (plataforma) sejam construídos e planejados do zero para a produção dos produtos. A empresa delimita antecipadamente quais serão os produtos gerados pela linha, realizando um
planejamento completo, incluindo a Análise do Domínio, Arquitetura e Projeto da linha.
Ao contrário da Proativa, na abordagem Reativa os ativos-base já estão prontos, assim como uma versão da LPS. Então, a empresa evolui a linha existente, atendendo aos requisitos para instanciação de novos produtos.
Na abordagem Extrativa são analisados produtos do domínio escolhido para extrair suas similaridades e variabilidades. A partir desta análise é construída uma versão inicial da linha de produtos, em que são obtidos os produtos que formaram a base para a linha.
A próxima subseção aborda o conceito de variabilidade de um domínio de uma Linha de Produtos de Software. A variabilidade define as características que são implementadas no núcleo da linha e as que serão classificadas como variáveis, sendo desenvolvidas individualmente para cada produto.
2.2.1 Variabilidade da Linha e Ativos de Núcleo
A variabilidade é a capacidade de um sistema, um ativo (asset), ou um ambiente de desenvolvimento suportar a produção de um conjunto de artefatos que diferem uns dos outros de uma forma pré-estabelecida. No contexto da linha de produtos de software, a variabilidade significa a capacidade de um ativo de núcleo (core asset) se adaptar a diferentes usos no contexto dos diversos produtos que estejam dentro do âmbito de uma linha de produtos (BACHMANN; CLEMENTS, 2005).
Um ativo de núcleo é um artefato ou recurso construído para ser utilizado na produção de mais do que um produto de uma linha de produto de software. Eles formam o conjunto de ativos ou artefatos reutilizáveis no desenvolvimento de novos produtos. Podem ser componentes, padrões de projeto, documentação, arquitetura, cronogramas, entre outros artefatos. São itens utilizados por todos os produtos da linha (GASPAR, 2010).
Uma interessante discussão é determinar quando que um ativo pode ser considerado um ativo de núcleo (BACHMANN; CLEMENTS, 2005). Para este trabalho, será adotada a classificação encontrada em Santana et al. (2009). Segundo esta classificação, o núcleo de ativos da linha de produto é formado por
funcionalidades comuns e variáveis. As funcionalidades comuns são utilizadas por todos os produtos da LPS, denominadas de núcleo (Kernel). Já as funcionalidades opcionais (Optional) são encontradas em mais de um produto da linha, porém não em todos os produtos. As funcionalidades que são específicas para cada produto são denominadas funcionalidades de aplicação (Application). O diagrama da Figura 6 ilustra essa representação das funcionalidades de núcleo, opcionais e de aplicação.
Figura 6 - Classificação das características a partir de três produtos Fonte: Santana et al. (2009)
Nesta ilustração os produtos são sobrepostos, ou seja, as características são comparadas e classificadas em:
Caraterísticas de Núcleo (Kernel): são encontradas em todos os produtos analisados.
Características Opcionais (Optional): são encontradas em mais de um produto, mas não em todos.
Características de Aplicação (Application): são encontradas em apenas um produto.
Desta forma, é possível acrescentar flexibilidade ao núcleo da Linha de Produto, considerando o desenvolvimento estratégico das características de núcleo e opcionais.
2.3 MODELOS DE DESENVOLVIMENTO DE LPS
Por meio das atividades essenciais definidas por Clements e Northrop (2001) é possível implantar uma LPS utilizando métodos de modelagem, como é o
caso do método FAST (HARSU, 2002). Porém, foram criados outros modelos, chamados de modelos de variabilidades.
Os modelos mais utilizados são o Modelo de Características (Feature Model), Modelo de Arquitetura e o Modelo de Configuração (Configuration Knowledge) (GURP et al., 2001; CARVALHO, 2013). Eles visam identificar melhor as semelhanças e diferenças em uma LPS. Neste trabalho será explicado apenas o Modelo de Características que é a base para os métodos FODA e PLUS (LOBO; RUBIRA, 2009).
O Modelo de Característica identifica os pontos comuns e variáveis da LPS em termos de suas propriedades. O conceito de característica (feature) foi apresentado pelo método FODA (Feature Oriented Domain Analysis) (KANG et al., 1990). Uma característica é definida como “uma unidade lógica de comportamento que é especificada por um conjunto de requisitos funcionais e de qualidade” (SILVA et al., 2011). Ela agrupa as exigências para a construção do produto, abstraindo os requisitos.
Quando as características são reunidas graficamente, é construído um modelo de funcionalidades. Ele apresenta uma visão de alto nível das similaridades e variabilidades de uma linha. Considerando o contexto das LPS, o modelo representa a própria linha de produtos (SILVA et al., 2011). Na Figura 7 pode ser observado como exemplo, o modelo de características de um shopping eletrônico.
Figura 7 - E-Shop representado através do Modelo de Características Fonte: Silva et. al (2011)
Obrigatória (Mandatory): a funcionalidade precisa estar em todos os produtos da linha. No exemplo anterior, é obrigatório ter catálogo (Catalogue) e informações (Info) sobre seus itens, forma de pagamento (Payment) e interface gráfica com o usuário (GUI – Graphical User Interface).
Opcional (Optional): a presença da funcionalidade não é obrigatória em todos os produtos da linha. As funcionalidades de ofertas (Offers), busca no catálogo (Search), segurança (Security) e Banners são opcionais no exemplo.
Alternativa: esta funcionalidade é composta por um conjunto de outras funcionalidades, sendo preciso indicar se as funcionalidades reunidas podem ser executadas simultaneamente (Or) ou se elas são excludentes (Alternative). Sobre as informações dos itens no catálogo, as imagens (Image), descrições (Description) e preços (Price) podem ser inseridos em conjunto. Assim ocorre com a busca básica (Basic) e avançada (Advanced), o pagamento em cheque (Bank Draft) e cartão de crédito (Credit Card) e as interfaces para computador (PC) e dispositivos móveis (Mobile).
Outra notação utilizada no Modelo de Características é a interação entre as funcionalidades. Uma funcionalidade pode estar relacionada à outra, mas não em grau de parentesco. Esta relação pode ser de:
Exigência (Require): nesse tipo de situação, a inclusão de uma funcionalidade exige que outra seja empregada no produto. No exemplo, o pagamento em cartão de crédito exige que a segurança no sistema seja alta (High).
Exclusão (Exclude): nessa situação, o produto que incluir determinada funcionalidade obrigatoriamente excluíra a funcionalidade a qual está sendo ligada. Na modelagem do exemplo, caso seja escolhida a interface para dispositivos móveis é excluída a funcionalidade de Banners e vice-versa.
Nas próximas seções serão abordados quatro métodos de desenvolvimento para Linhas de Produto de Software. O método FAST foi escolhido por apresentar um processo adicional além das Engenharias de Domínio e Aplicação. O método
FODA possui atividades bem definidas na fase de Engenharia de Domínio. O método PLUS é baseado na UML e integrável a outras metodologias, demonstrando ser um método adaptável a vários ambientes de desenvolvimento. O Método Adaptado de Delazeri e Wolf (2012) foi desenvolvido baseando-se nos três métodos principais da literatura para LPS.
2.3.1 FAST
O método FAST (Family-Oriented Abstraction, Specification and Translation), criado por Weiss e Lai (1999) define o processo de engenharia de software totalmente baseado em linhas de produto. Harsu (2002) descreve a divisão do método em fases, conforme a Figura 8.
Figura 8 - Processo do Método FAST Fonte: Weiss e Lai (1999)
A fase Qualify Domain (Qualificar Domínio) determina a viabilidade econômica da implantação da linha de produto no domínio selecionado. Uma das formas de se obter essa viabilidade é através de um gráfico comparativo entre a
prática desenvolvimento de software corrente (current practice) e a abordagem com LPS, identificada no Gráfico 1 como product line approach.
Gráfico 1 - Comparativo entre a abordagem tradicional e a abordagem de LPS Fonte: Weiss e Lai (1999)
Neste gráfico é indicado o ponto que determinada quantidade de produtos construídos apresentam o mesmo custo nas duas abordagens (payoff point), e a partir desse ponto a linha de produtos torna-se mais vantajosa. Caso esta vantagem ocorra, os próximos passos do método podem ser executados.
A fase Engineer Domain (Engenharia de Domínio) procura identificar os pontos comuns e diferentes da família, além de desenvolver a base para a linha. É um processo iterativo e contínuo de análise e implementação do domínio.
A subfase Analyze Domain (Analisar Domínio) se concentra em descrever o que está dentro do domínio, bem como os seus limites. Esta descrição é feita por meio de itens que o compõe, identificação de subdomínios, regras de inclusão e exclusão do domínio. São utilizados diagramas de contexto e o principal artefato produzido é o Modelo de Domínio, uma especificação para o Ambiente de Engenharia de Aplicação.
A subfase Implement Domain (Implementar Domínio) desenvolve ou aprimora o ambiente que satisfaz o Modelo de Domínio construído na Análise de Domínio. Também é responsável pelo fornecimento de um conjunto de ferramentas para formar o Ambiente de Engenharia de Aplicação.
Ao final da Engenharia de Domínio, é disponibilizado o Application Engineering Environment (Ambiente de Engenharia de Aplicação), que fornece toda a base para a definição dos produtos que serão construídos no processo de Engenharia de Aplicação.
A fase de Engenharia de Aplicação é realizada em paralelo com a Engenharia de Domínio. Os engenheiros de aplicação utilizam a base localizada no Ambiente de Engenharia de Aplicação para produzir as aplicações da família. Eles devem estar em contato frequente com os clientes para que o produto satisfaça a todos os requisitos. Basicamente, A Engenharia de Aplicação possui três atividades, sendo que as duas primeiras podem ser feitas de forma iterativa. As atividades são:
Definição do Modelo de Aplicação: Por meio dos requisitos identificados pelo cliente, o engenheiro de aplicação projeta o Modelo de Aplicação. Podem ser realizados diferentes modelos e refiná-los diversas vezes para ter a certeza que ele corresponda aos requisitos estabelecidos.
Produção da Aplicação: De acordo com o Modelo de aplicação, será feita toda a documentação e implementação do produto que também poderá ser revisto várias vezes.
Entrega e Suporte da Aplicação: Quando se obtém um produto satisfatório, ele é entregue aos clientes juntamente com resultados de análises dos engenheiros de aplicação.
Ao final do processo de Engenharia de Aplicação é gerado um membro da linha de produtos. Caso o produto deste processo não satisfaça seus clientes, todo o processo poderá ser revisto.
2.3.2 FODA
O FODA (Feature Oriented Domain Analysis), desenvolvido pelo SEI (Software Engineering Institute) em 1990, é um método de análise de domínio baseado em características (features). Ele é considerado parte integrante da fase de Engenharia de Domínio apenas, sem abranger atividades aplicadas na fase de Engenharia de Aplicação (SILVA et al., 2011).
O método na sua configuração atual possui duas atividades essenciais: Análise de Contexto e Modelagem de Domínio (Figura 9). Quando foi desenvolvido ele possuía uma terceira atividade denominada Modelagem da Arquitetura que em 1997 foi transferida para a fase de Projeto de Domínio do MBSE (Model-Based Software Engineering) (LOBO; RUBIRA, 2009).
Figura 9 - Método FODA Fonte: Lobo e Rubira (2009)
A atividade de Análise de Contexto tem o propósito de definir o escopo do domínio. São analisadas as relações entre o domínio e os elementos externos, bem como as variabilidades dessas relações. Os resultados finais da Análise de Contexto são documentados no Modelo de Contexto, que define o limite do domínio, ou seja, o escopo que será modelado na próxima atividade.
A atividade de Modelagem de Domínio analisa as similaridades e variabilidades entre as aplicações no domínio, gerando uma série de modelos que representam diferentes aspectos do problema. Ela é subdividida em três subatividades:
Análise de Características: tem o propósito de representar em um modelo as características similares e variáveis do domínio e seus relacionamentos. Nesta é definido o Modelo de Características que traz as funcionalidades classificadas em mandatórias, opcionais ou alternativas, além de informações adicionais como restrição, descrição e
dependência. Esta é considerada a principal subatividade do método FODA e o Modelo de Características é usado para generalizar e parametrizar outros modelos.
Modelagem Entidade-Relacionamento: tem a finalidade de capturar e definir o conhecimento essencial para a implementação de aplicações no domínio. O Modelo de Entidade-Relacionamento representa o conhecimento em termos de entidades e seus relacionamentos tornando-os disponíveis para a derivação de objettornando-os e definição de dadtornando-os durante a atividade de análise funcional.
Análise Funcional: identifica em termos funcionais as diferenças e semelhanças das aplicações do domínio. Ela abstrai e estrutura as funcionalidades comuns em um Modelo Funcional. Os Modelos de Característica e Entidade-Relacionamento são utilizados para orientar o desenvolvimento do Modelo Funcional. As características mandatórias e as entidades são a base de definição para um modelo funcional abstrato e todos os fatores que causam diferenças funcionais entre os futuros produtos são definidos como questões e decisões utilizadas para o refinamento e parametrização da família. As especificações do Modelo Funcional são classificadas em especificações de funções, representadas por meio de um diagrama de atividades, e especificações de comportamento, representadas pelo diagrama de estados. Além disso, o Modelo Funcional pode ser representado também pelo diagrama de casos de uso.
A chave para o método FODA é a modelagem das funcionalidades de maneira minuciosa e explícita. Essa característica, juntamente com a descrição detalhada da Modelagem de Domínio tornou o método um dos mais populares nos anos 90.
2.3.3 PLUS
O PLUS (Product Line UML-Based Software Engineering) é baseado na UML (Unified Modeling Language) podendo ser integrado a outros métodos e processos de desenvolvimento tradicionais de software. Ele é utilizado pelo
processo ESPLEP (Evolutionary Software Product Line Engineering Process) apresentando uma perspectiva de desenvolvimento de linhas de produto de software. Conforme a Figura 10, este processo é executado de forma incremental e iterativa, possuindo duas atividades principais (DONEGAN, 2007): Engenharia de Linha de Produto de Software e Engenharia de Aplicação.
Figura 10 - Método PLUS Fonte: Donegan (2007)
A atividade de Engenharia de Linha de Produto de Software consiste na construção dos modelos de caso de uso, de análise e de arquitetura baseados nos requisitos da linha de produtos levantados pelos engenheiros. Também são desenvolvidos componentes reusáveis que são armazenados no repositório da LPS. O processo inicia-se na Modelagem de Requisitos (Figura 11) por meio da definição dos requisitos, representados por atores e casos de uso. Na Modelagem de Análise, os casos de uso passam a ser descritos por objetos e suas interações. A Modelagem de Projeto desenvolve a arquitetura da linha de produto baseada em componentes.
Na subatividade de Implementação Incremental de Componentes é realizada a codificação dos componentes e a execução de testes unitários. Na última atividade são feitos os testes de integração e sistêmico da LPS. O processo pode ser reiniciado caso não seja obtido o resultado esperado. Todos os artefatos produzidos
em cada atividade do processo de Engenharia de Linha de Produto de Software são armazenados no repositório da LPS.
Figura 11 - Engenharia da Linha de Produto do Método PLUS Fonte: Donegan (2007)
A atividade de Engenharia de Aplicação permite identificar os requisitos de cada aplicação para o seu desenvolvimento. São utilizados os modelos construídos na atividade anterior para derivar os modelos de cada aplicação. A partir da definição desses modelos e a utilização dos componentes do repositório, são obtidas aplicações executáveis. Se forem encontrados requisitos insatisfeitos, erros ou se houver a necessidade de adaptação da aplicação, o processo deverá ser executado novamente até conseguir o resultado desejado.
2.3.4 Método Adaptado de Delazeri e Wolf
Procurando reunir as principais características dos três métodos descritos anteriormente, Delazeri e Wolf (2012) descreveram em seu trabalho um método adaptado para o desenvolvimento de linhas de produto de software. O método disponibiliza fases, documentações e diagramas específicos para esta abordagem
de desenvolvimento. Este método possui duas fases principais, Engenharia de Domínio e Engenharia de Aplicação, conforme a Figura 12.
Figura 12 - Método Delazeri e Wolf Fonte: Adaptado de Delazeri e Wolf (2012 p.41).
Na fase de Engenharia de Domínio o escopo da linha de produto é modelado por meio da construção de artefatos reutilizáveis. Esta fase apresenta duas subfases:
Análise de domínio: derivada do método FAST, esta subfase preocupa-se em analisar e definir o escopo do software. O produto final desta é o Modelo de Contexto
Identificação das Características: Nessa subfase são identificadas e modeladas as características comuns e variáveis do domínio. Ela possui cinco atividades:
o Requisitos do domínio: esta etapa está baseada na fase de Análise de características dos métodos FODA e PLUS, que tem por finalidade levantar os pontos comuns e variáveis da linha. O Modelo de Características é o artefato gerado ao final dessa atividade.
o Modelagem do domínio: fundamentada nas atividades iniciais da Engenharia de Linhas de Produto de Software do método PLUS. Realiza a decomposição do problema, e a modelagem estática por meio de Diagramas de Classe e/ou Diagramas de Caso de Uso.
o Projeto do domínio: baseado nas atividades intermediárias da Engenharia de Linhas de Produto de Software do método PLUS. Nesta
atividade é definida a escolha da arquitetura dos componentes de cada produto. O resultado é o Modelo de Projeto de software baseado em componentes.
o Implementação do domínio: Adaptação da atividade de implementação incremental de componentes do método PLUS. Além de programar os componentes reutilizáveis, também é definida a linguagem de programação utilizada no software.
o Testes do domínio: proveniente do método PLUS, esta atividade consiste em validar e verificar os componentes construídos, enfatizando sua integridade e funcionalidade.
A fase de Engenharia de Aplicação utiliza as definições obtidas na fase de Engenharia de Domínio para desenvolver uma aplicação individual. Possui quatro subfases:
Requisitos da Aplicação: deriva-se dos métodos PLUS e FAST. Além de identificar e modelar os requisitos em diagramas de caso de uso específicos da aplicação, essa subfase é responsável pela criação do diagrama de características das variabilidades do domínio.
Implementação da Aplicação: subfase adaptada do método FAST que realiza a programação do produto conforme os requisitos extraídos nas atividades anteriores.
Testes da Aplicação: esta subfase não está descrita explicitamente nos três métodos estudados, porém é uma atividade contida na Engenharia de Linhas de Produto. Seu objetivo é validar o produto da linha por meio de testes funcionais e de integração e análises da integridade dos requisitos.
Entrega e Suporte da Aplicação: Originalmente utilizada no método FAST, a fase de Entrega e suporte é importante para garantir a satisfação do cliente. O produto é entregue e caso necessário é feito o suporte da aplicação.
O Quadro 2 descreve os artefatos gerados em cada fase do método de Método Delazeri e Wolf (2012).
Fases Subfases Artefatos de Entrada Artefatos de Saída
Engenharia de Domínio
Análise de domínio Definição do Domínio a ser modelado
Modelo de contexto definindo o escopo do domínio Ide nt if ic aç ão d e Ca rac terís ti c as Requisitos do domínio Dois exemplos de aplicações no domínio, no mínimo.
-Descrição narrativa de cada exemplo. Caso não se tenha a descrição narrativa, devem-se utilizar os aplicativos disponíveis. Neste caso, a análise será realizar por meio da execução do software.
Identificação dos pontos comuns entre os estudos de caso.
- Requisitos identificados
- Diagrama de características (contendo os pontos de comuns)
Modelagem do domínio
Descrição narrativa de cada exemplo.
Pontos de comuns
- Diagrama de Caso de Uso - Cenários dos casos de uso - Diagrama de classe
Projeto do domínio
Diagrama de Caso de Uso
- Arquitetura da parte Similar (baseada em componentes)
- Diagramas de classe para a concepção da arquitetura
- Especificação das Interfaces do Sistema.
- Identificação das Interfaces de Negócio.
Identificação dos Componentes.
Implementação do domínio
Arquitetura da parte Similar
- Codificação dos componentes da arquitetura similar
Testes do
domínio Codificação Validação dos componentes
Engenharia de Aplicação Requisitos da aplicação Requisitos da aplicação (pontos de variabilidade) oriundos da fase Requisitos do domínio
- Lista de requisitos das variabilidades -Diagrama de caso de uso da aplicação
- Diagrama de classe
Implementação da
Aplicação. Diagrama de classe - Codificação dos pontos variáveis Testes da Aplicação Codificação da
aplicação
- Plano de testes funcionais e de integração
- Produto validado
Entrega e Suporte da
Aplicação Aplicação validada - Aplicação
Quadro 2 - Artefatos de entrada e saída produzidos no Método Adaptado Fonte: Delazeri e Wolf (2012)
Dentre os métodos listados nesta seção, optou-se por utilizar para a modelagem do domínio o Método Adaptado de Delazeri e Wolf (2012), por reunir atividades presentes em diferentes métodos de desenvolvimento para uma LPS.
3 FRAMEWORK DE DOMÍNIO PARA FORMAÇÃO DE PREÇO DE VENDA
Este Capítulo aborda assuntos referentes ao Framework de Formação de Preço de Venda (FrameMK). A seção 3.1 faz uma revisão sobre a definição de framework e framework de domínio. A seção 3.2 apresenta as características do FrameMK, pois o sistema FAQ proposto por este trabalho será incorporado a sua arquitetura.
3.1 DEFINIÇÃO
A definição mais adequada para o contexto do framework abordado nesse trabalho é uma síntese das definições apresentadas por Pree (1995), Buschmann et. al (1996), Pinto (2000) e Fayad e Schmidt (1997). Segundo eles, um Framework é uma aplicação parcialmente completa e reusável, projetada para ser instanciada ou especializada para construção de outras aplicações. Ele disponibiliza a arquitetura e elementos básicos para a criação de um conjunto de subsistemas. Também são determinados os pontos extensíveis (hot-spots) no qual são realizadas adaptações no código para o funcionamento de módulos específicos.
Essa definição, além de evidenciar a capacidade de reutilização do Framework, permite que uma família de produtos possa ser gerada por meio de uma única estrutura, capturando conceitos gerais da família de aplicações (PINTO, 2000 apud BARRETO).
Assim sendo, é possível criar uma relação entre Framework e Linhas de Produto de Software, pois ambos os conceitos priorizam a reusabilidade.
Uma das formas de classificar um framework, apresentada por Dalebout et al. (1998), é segundo a sua dependência de domínio. Ele pode ser um Framework de Aplicação ou Framework de Domínio:
Framework de Aplicação: independe de um domínio em particular. Ele atende a uma fatia horizontal de funcionalidade, como é o caso, por exemplo, de um framework de acesso a arquivos, que pode ser utilizado para desenvolvimento em diferentes domínios.
Framework de Domínio: refere-se a um domínio particular. Apresenta uma fatia vertical de funcionalidade, abrangendo todo domínio no qual foi estabelecido.
Por meio da utilização de frameworks decorrem diversos benefícios, como reusabilidade, modularidade, extensibilidade e inversão de controle. Todavia, encontram-se desafios na sua adoção e uso, como por exemplo, integração, eficiência, manutenibilidade, falta de padronização, validação e remoção de defeitos (FAYAD et al., 1999).
3.2 DESENVOLVIMENTO DO FRAMEMK
O FrameMK (Framework para Formação de Preço de Venda) é um framework de domínio que esta sendo desenvolvido pelo Grupo de Pesquisa em Sistemas de Informação, Linha Engenharia de Software, Câmpus Ponta Grossa. Este framework tem por objetivo a criação de um modelo arquitetural de um framework de domínio na área de formação de preço de venda, por meio de métodos já estabelecidos, identificando aspectos comuns e específicos para sua modelagem e desenvolvimento (MAZER JR, 2013).
Ainda não existem softwares que estabeleçam o preço de venda de produtos e/ou serviços e que disponibilizem diferentes métodos de formação de preço de venda, justificando assim o estudo na área e seu desenvolvimento (MAZER JR, 2013). Por meio do FrameMK, o trabalho dos administradores é facilitado, pois com diversos métodos de precificação é possível atribuir um valor ideal de mercado ao produto ou serviço.
3.2.1 Linha Cronológica do FrameMK
Em Barbosa e Beluzzo (2013) é feita uma relação dos estudos realizados para a construção do FrameMK que possibilitou estabelecer uma linha cronológica (Figura 13) dos trabalhos publicados e seus respectivos autores.
Figura 13 - Linha cronológica de trabalhos no desenvolvimento do FrameMK Fonte: Autoria própria
Em 2008, o trabalho de Crazuski et al. (2008) estudou o domínio e a modelagem de três métodos de formação de preço de venda: Método de Custeio em Atividades (ABC – Activity Based Costing), Método Sebrae e Método Custo Pleno. Em 2009, Oliveira e Crema (2009) realizam uma pesquisa do domínio e executaram a modelagem de mais dois métodos: Custeamento Marginal e o do Retorno Sobre o Capital (ROIC – Return On Invested Capital). No ano seguinte, Andrade e Capeller (2010) começam o desenvolvimento da arquitetural do FrameMK e implementam os métodos Custo Pleno, Custeio Baseado em Atividade e SEBRAE para a plataforma Swing.
Rodrigues Junior (2010) construiu um serviço para busca de preços de venda de produtos em sítios de e-commerce. O trabalho de Ramos (2011) realizou a refatoração da camada de apresentação do FrameMK, utilizando os frameworks de aplicação Struts e o Tiles.
Já em 2012, Silva (2012) desenvolveu um módulo de acesso (login) baseado em aspectos, que foi utilizado no FrameMK. Lacerda (2012) realizou a refatoração do aplicativo gerenciador do sítio ArcaboMK, no qual ficam armazenados toda a documentação do processo de desenvolvimento do software.
Em 2013, Mazer Jr (2013) desenvolveu um Web service para o framework disponibilizando-o na Web. Ainda neste ano, Barbosa e Beluzzo (2013) estendem o FrameMK com a inclusão dos método ABC, Marginal e ROIC.
3.2.2 Arquitetura do FrameMK
O FrameMK atualmente possui a arquitetura ilustrada na Figura 14.
Figura 14 - Arquitetura atual do FrameMK Fonte: Mazer Jr (2013)
Por meio de um local com acesso à Web, os servidores das empresas podem acessar o Servidor do FrameMK. Este por sua vez, possui uma camada de serviços que faz a comunicação com as funções da API do framework.
Mazer Jr (2013) citou em seu trabalho exemplos de integração entre servidores ERP e o servidor do FrameMK. A (a) (b)
Figura 15 ilustra a integração entre o webERP (2013) e o FrameMK.
Com a utilização da camada de serviços desenvolvida, foi criada uma versão do webERP que implementa métodos para a definição de preços de venda de um produto (MAZER JR, 2013).
Isto é apresentado na (a) (b)
(a) (b)
Figura 15 - Rotina de manutenção de preços do webERP, antes e depois da integração com o FrameMK
Fonte: Mazer Jr (2013)
A Figura 15 (a) refere-se a tela original de manutenção de preço do sistema webERP. Já a Figura 15 (b) apresenta a alteração feita, inserindo o link Calcular preço com FrameMK, que encaminha o usuário à tela de cálculo de preços de venda, podendo escolher entre os métodos Sebrae, Custo Pleno ou ABC. Ao escolher uma opção, será carregada a tela do método correspondente. A Figura 16 apresenta a tela do Método Sebrae.
Figura 16 - Tela do webERP para o método Sebrae de formação de preço de venda Fonte: Mazer Jr (2013)
Após a inserção dos dados o usuário seleciona o botão Calcular e o valor de venda será calculado. Ao selecionar o botão Atualizar, a aplicação retorna a tela de manutenção de preço de produtos, conforme a Figura 17.
Figura 17 - Tela do webERP com o preço atualizado pelo FrameMK Fonte: Mazer Jr (2013)
Ao retornar a tela, o campo Preço será atualizado com o valor calculado pelo FrameMK. Cada método de precificação possui uma tela específica, contendo as variáveis necessárias para o cálculo. Uma descrição detalhada da integração pode ser obtida em Mazer Jr (2013).
Observando a arquitetura e o exemplo de funcionamento do FrameMK não existe nenhum módulo responsável para ajudar os usuários em suas dúvidas de utilização do aplicativo. Este módulo é denominado de FAQ e é descrito no próximo capítulo.
4 SISTEMAS FAQS (FREQUENTLY ASKED QUESTIONS)
Neste Capítulo encontra-se o referencial sobre as FAQs. A seção 4.1 relata as origens, definição do acrônimo FAQ e sua importância no mercado atual. Na seção 4.2 encontram-se os sistemas de FAQ escolhidos para análise das características do domínio a serem modelados usando LPS proposto nesta pesquisa.
4.1 ORIGEM E DEFINIÇÃO
Com a popularização das tecnologias Web, a quantidade de sítios aumentou e o volume de informações disponíveis também. Isto ocasionou uma sobrecarga de informações, e muitas vezes o usuário não tem condições de encontrar o que realmente deseja (CHEN, 1994 apud SILVA, 2003). Diante deste fato, alguns portais corporativos passaram a disponibilizar uma lista de FAQs. Este acrônimo para Frequently Asked Questions (Perguntas Frequentes) consiste em uma lista que contém as perguntas mais frequentes e suas respectivas respostas para um determinado assunto.
Além de facilitar a localização de áreas específicas do sítio ou encontrar informações sobre produtos e/ou serviços, tais perguntas também diminuem as requisições feitas a especialistas humanos para solucionar dúvidas, os chamados Call Centers (SILVA, 2003).
As Perguntas Frequentes são um tipo de ferramenta Help Desk. Essas ferramentas são constituídas de um mecanismo computacional de perguntas e respostas na qual é realizada uma consulta a uma base de dados por meio de uma pergunta selecionada pelo usuário (MATOS et al., 2006).
Embora as Perguntas Frequentes sejam utilizadas no ambiente da Internet, o seu formato existe antes do surgimento dessa tecnologia. A obra Suma Teológica, escrita por Tomás de Aquino na segunda metade do século XIII, apresenta uma série de perguntas e respostas sobre o cristianismo, caracterizando um dos primeiros métodos para solucionar dúvidas frequentes (AQUINO, 2003).
A origem do acrônimo FAQ na Internet é creditada a Eugene Miya. Em 1982 ele utilizou o termo em uma lista de discussão da NASA na ARPANET. Eugene
