Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Apresenta o conceito de Linha de Produtos de Software (LPS) para
solução de problemas comumente enfrentados por desenvolvedores de aplicações
móveis. Descrevemos alguns problemas clássicos, os motivos que os fazem surgir
e os mecanismos que podemos utilizar para solucioná-los. Quando tratamos de desenvolvimento de aplicações móveis, fazem-se
necessários cuidados extremos quanto às características dos dispositivos de destino.
A LPS nos auxilia a manter o aumento da produtividade, qualidade e coesão de
projeto de software para dispositivos móveis evitando que estas características
não sejam extrapoladas. Na necessidade de disponibilizar uma aplicação móvel para fabricantes
de dispositivos móveis distintos com códigos coesos e consistentes. Muitos
destes fabricantes implementam funcionalidades de maneiras distintas e por isso
faz-se necessária a criação de diversas versões do projeto com codificações
diferenciadas. Neste artigo apresentamos os mecanismos básicos para gerenciar
esta necessidade. Autores: Josias Paes
Junior e Carlos Diego Quirino
Para que serve:
Em que situação o tema é útil:
A tecnologia evolui, avanços substanciais são realizados na indústria eletrônica, nos processos de concepção e desenvolvimento de software e nas comunicações. A difusão da informação através da internet, sobretudo pela necessidade de acesso a conteúdo em qualquer lugar, possibilita o aumento da “audiência” sobre os dispositivos móveis. Como consequência, surgem os mais variados tipos de equipamentos com capacidades de armazenamento e processamento distintas.
A difusão desses equipamentos ocasiona um grande impacto social. Nesse sentido, as empresas procuram fazer cada vez mais investimentos nos setores de marketing a fim de agregar cada vez mais valor aos seus produtos e, assim, tentar atender às exigências dos seus consumidores. Muito desse valor agregado, por sua vez, recai sobre o software que se encontra instalado no dispositivo vendido; trata-se de funções que um aparelho pode realizar para satisfazer os mais diversos públicos.
O software deve aderir a padrões de qualidade, como disponibilidade, confiabilidade, segurança, usabilidade, dentre outros. Desta forma, ele tem que se adequar satisfatoriamente a um conjunto cada vez mais diversificado de requisitos funcionais e não-funcionais. Estes últimos podem estar inseridos completamente, parcialmente ou de forma híbrida (ou seja, parte de um requisito funcional ou não-funcional A, complementada por parte de outro requisito funcional ou não-funcional B) em cada dispositivo, considerando cada modelo específico, ou em séries de um mesmo modelo de dispositivo.
Diante de tantas implicações, é importante recorrer às abordagens voltadas a Linhas de Produto de Software (LPS) (ler Nota DevMan 1) e, assim, poder tratar de maneira mais adequada a variabilidade de uma solução de software em diversos dispositivos, respeitando as características limitantes e particulares de cada equipamento. Por isso, neste artigo, serão apresentados os conceitos relacionados à abordagem de LPS e demonstrados alguns mecanismos utilizados para possibilitar a implementação de LPS em dispositivos móveis.
O conceito tradicional das linhas de produtos foi criado na indústria automobilística para substituir o modelo de fabricação existente na época no qual um produto era inteiramente produzido por uma única pessoa ou por um pequeno grupo delas. As linhas de produção introduziram o conceito de modularização, já que o trabalho poderia ser feito em “pedaços”, e possibilitava que os produtos fossem desenvolvidos em um tempo menor devido ao paralelismo das tarefas.
Este modelo de fabricação permitiu que mais clientes fossem atendidos, mas teve que ser adaptado para permitir a diferenciação dos produtos, já que até então, todos os carros tinham a mesma aparência e serviam a um determinado propósito. Era preciso adequar o modelo de fabricação para que fosse possível oferecer produtos diferenciados com a mesma rapidez de produção. O conceito de customização em massa representou a possibilidade de atender a produção de bens em larga escala com base em perfis de consumidores. As fábricas passaram a projetar automóveis levando em consideração os segmentos de clientes e suas necessidades, o que ocasionou versões diferentes de um mesmo modelo de carro. Surge, então, a idéia das famílias de produtos.
Para atingir esse grau de customização, plataformas de produção foram estabelecidas e passaram a ser usadas como moldes para aqueles componentes que eram comuns à maioria dos produtos: chassis, motor e câmbio. Os componentes que eram diferentes, a exemplo da carroceria e itens de conforto, eram responsáveis por permitir as variações dentro da família de produtos. Logo, a maneira como o reuso das peças foi utilizado permitiu que se produzissem diversos modelos de automóveis.
Os primeiros conceitos de Linhas de Produto de Software (LPS) surgiram da observação dos processos industriais na década de 70, contudo, apenas nos anos 90 foram completamente introduzidos através das contribuições do projeto FODA (Feature-Oriented Domain Analysis) e das pesquisas realizadas pelo SEI (Software Engineering Institute) no desenvolvimento de aplicações para o governo. Uma LPS segue os mesmos princípios das linhas encontradas na indústria, sendo que constituem um conjunto de aplicações de software relacionadas entre si que oferecem funcionalidades parecidas e que satisfazem as diferentes necessidades de um determinado segmento ou missão de mercado.
Linhas de Produto de Software
De acordo com Vander Alves, em sua tese intitulada “Implementing Software Product Line Adoption Strategies”, as concepções preliminares sobre LPS derivam de estudos realizados por Dijkstra e Parnas a respeito da Variabilidade de Software (Software Variability). Nestes estudos são avaliadas algumas questões importantes sobre: (i) as decisões em nível de projeto utilizadas para delimitar o escopo de componentes de software até que sejam definidos os membros individuais de uma família de produtos; (ii) a implementação dos aspectos de variabilidade de um módulo obedecendo a uma interface estável; (iii) o gerenciamento da variabilidade.
...
