O SEI (Software Engineering Institute), atrav´es da iniciativa PLP (Product Line Practice), estabeleceu as atividades essenciais a uma LPS (Northrop et al., 2009). Essas atividades s˜ao: (i) Desenvolvimento de Ativos Centrais, tamb´em conhecida como Engenharia de Dom´ınio; (ii) Desenvolvimento do Produto, tamb´em conhecida como Engenharia de Aplica¸c˜ao; e (iii) Gerenciamento da LPS. Clements e Northrop (2002), van der Linden et al. (2007) e B¨ockle et al. (2005) discutem as intera¸c˜oes entre essas atividades, a partir das quais compartilham uma mesma defini¸c˜ao, ilustrada na Figura 2.13.
Figura 2.13: Atividades essenciais (B¨ockle et al., 2005; Clements e Northrop, 2002; van der Linden et al., 2007).
A disposi¸c˜ao dos trˆes c´ırculos da Figura 2.13 indica que as atividades de uma LPS s˜ao altamente interligadas e iterativas. Na intersec¸c˜ao dos c´ırculos superiores, as setas rotativas n˜ao sugerem apenas que os ativos centrais s˜ao usados para o desenvolvimento
de produtos, mas tamb´em que poss´ıveis revis˜oes ou atualiza¸c˜oes relacionadas aos ativos podem ser feitas em sua respectiva atividade. A Figura 2.13 ´e neutra em rela¸c˜ao `a ordem de execu¸c˜ao das atividades, que podem variar de acordo com as necessidades do produto desejado.
`
A medida em que os produtos s˜ao desenvolvidos, os ativos centrais tendem a evoluir. Segundo OliveiraJr (2005), um exemplo disso ocorre quando se identifica um novo requisito relevante ao dom´ınio que inicialmente n˜ao fazia parte da especifica¸c˜ao de requisitos da LPS. Assim, essa especifica¸c˜ao evolui, incorporando o novo requisito identificado e um ou mais ativos centrais s˜ao atualizados.
A seguir, as atividades essenciais de uma LPS s˜ao descritas. Cada uma delas est´a em conformidade com a vers˜ao 5 do “Framework for Software Product Line Practice” (North- rop et al., 2009), uma das contribui¸c˜oes da iniciativa PLP do SEI.
2.3.1.1 Engenharia de Dom´ınio
O objetivo da atividade de Engenharia de Dom´ınio ´e estabelecer a capacidade de produ¸c˜ao de produtos (Northrop et al., 2009). A Figura 2.14 ilustra esta atividade, juntamente com suas sa´ıdas e fatores contextuais relevantes.
Figura 2.14: Engenharia de Dom´ınio (Northrop et al., 2009).
De acordo com a Figura 2.14, os elementos descritos `a esquerda da atividade de En- genharia de Dom´ınio s˜ao contextuais e os apresentados `a direta representam os elementos de sa´ıda.
Essa atividade, assim como as outras, ´e iterativa. As setas rotativas e suas tonalidades sugerem que n˜ao h´a um ´unico relacionamento entre o contexto e as sa´ıdas; a atividade de Engenharia de Dom´ınio pode sofrer altera¸c˜oes em seu contexto. Por exemplo, expandindo o escopo da linha de produtos (uma das sa´ıdas) uma nova classe de sistemas pode ser admitida, provendo assim ativos legados (parte do contexto). De maneira semelhante, uma restri¸c˜ao de produ¸c˜ao pode conduzir a restri¸c˜oes na arquitetura da LPS. Essa restri¸c˜ao,
por sua vez, determinar´a quais ativos preexistentes s˜ao candidatos a re´uso ou minera¸c˜ao (Northrop et al., 2009).
A Engenharia de Dom´ınio ocorre, obrigatoriamente, dentro de um contexto predefinido com suas respectivas restri¸c˜oes e recursos. Esse contexto influencia como o desenvolvi- mento dos ativos centrais ´e realizado e a natureza das sa´ıdas que o mesmo produz. Os quatro fatores contextuais mais importantes, apresentados na Figura 2.14, possuem as seguintes caracter´ısticas:
1. Restri¸c˜oes do produto: Northrop et al. (2009) apresentaram perguntas pertinentes na identifica¸c˜ao de restri¸c˜oes de produtos, os elementos chave de cada uma delas s˜ao: (i) similaridades16
e variabilidades17
; (ii) features comportamentais; (iii) features cujas previs˜oes de mercado e de tecnologia s˜ao otimistas; (iv) padr˜oes comerciais, militares ou de empresas espec´ıficas; (v) limites de desempenho; (vi) integra¸c˜ao com sistemas externos; (vii) restri¸c˜oes f´ısicas; e (viii) requisitos de qualidade.
Os ativos centrais devem incorporar as similaridades e acomodar as variabilidades previstas com o m´ınimo de impacto nos indicadores de qualidade do produto, tais como seguran¸ca, confiabilidade, usabilidade, entre outros. As restri¸c˜oes do produto podem ser derivadas de produtos pr´e-existentes, podem ser criadas do “zero”, ou uma combina¸c˜ao das duas coisas (Northrop et al., 2009).
2. Restri¸c˜oes de produ¸c˜ao: assim como no item anterior, os termos relevantes relaci- onados `as perguntas apresentadas por Northrop et al. (2009) para a defini¸c˜ao de restri¸c˜oes de produ¸c˜ao s˜ao: cronograma, capacidade de produ¸c˜ao, processo de de- senvolvimento de software e, por fim, recursos e ambientes de desenvolvimento. Esses termos implicam em decis˜oes sobre os mecanismos de variabilidade providos aos ativos centrais e que processo de desenvolvimento ser´a usado para produtos e, eventualmente, no plano de produ¸c˜ao (Northrop et al., 2009).
3. Estrat´egia de produ¸c˜ao: determina a origem da arquitetura e seus componentes associados, al´em de auxiliar no crescimento da mesma. Essa estrat´egia abrange os desenvolvimentos de ativos centrais e produtos.
4. Artefatos preexistentes: referem-se aos artefatos existentes como, por exemplo, com- ponentes, especifica¸c˜oes ou partes legadas do dom´ınio catalogadas para a sua futura reutiliza¸c˜ao.
De acordo com (Northrop et al., 2009), trˆes sa´ıdas da atividade de Engenharia de Dom´ınio s˜ao necess´arias para que seja poss´ıvel desenvolver produtos:
16
Tradu¸c˜ao utilizada neste trabalho para o termo commonalities.
17
1. Escopo da LPS: descri¸c˜ao dos produtos que constituir˜ao a LPS ou que ela ser´a capaz de produzir. Esta descri¸c˜ao apresenta as similaridades e as variabilidades entre os produtos, al´em de suas features, tais como desempenho e atributos de qualidade. Para que uma LPS seja bem sucedida, o escopo deve ser definido com cuidado. Se o escopo ´e muito grande e os produtos variam, os ativos centrais ser˜ao estendidos para al´em de sua variabilidade, economias de produ¸c˜ao ser˜ao perdidas e a linha de produtos entrar´a em colapso. Se o escopo ´e muito pequeno, os ativos centrais podem n˜ao ser desenvolvidos de um modo gen´erico o suficiente para acomodar evolu¸c˜oes futuras e a LPS estagnar´a.
´
E importante ressaltar que o escopo de uma LPS evolui em diversas situa¸c˜oes: quando as condi¸c˜oes de mercado mudam, quando os planos da organiza¸c˜ao s˜ao redefinidos, quando novas oportunidades surgem, ou quando a organiza¸c˜ao torna-se mais experiente com o conceito de LPS. A evolu¸c˜ao do escopo tamb´em pode ser um ponto de partida para a evolu¸c˜ao de uma LPS, a fim de mantˆe-la atualizada. A defini¸c˜ao do escopo ´e por si s´o um ativo central, evolu´ıdo e mantido ao longo do tempo de vida da LPS.
2. Ativos centrais comuns: inclui todos os ativos centrais, que s˜ao comuns para a produ¸c˜ao de produtos. Nem todo ativo central ser´a necessariamente usado em todo produto de uma LPS. Entretanto, todos eles devem ser usados em quantidade sig- nificativa de produtos, a fim de realizar um desenvolvimento coordenado em termos de manuten¸c˜ao e evolu¸c˜ao.
Cada ativo central deve estar associado a um processo vinculado18
que determina como o ativo central ser´a utilizado no desenvolvimento dos produtos.
Restri¸c˜oes de produto, restri¸c˜oes de produ¸c˜ao e estrat´egia de produ¸c˜ao (fatores con- textuais descritos anteriormente) influenciam na defini¸c˜ao dos processos vinculados. Todos esses processos seguem uma abordagem de implementa¸c˜ao, chamada m´etodo de produ¸c˜ao. Com o t´ermino do ciclo, eles passam a representar o plano de produ¸c˜ao para a LPS. A Figura 2.15 ilustra o conceito de processos vinculados e como eles s˜ao incorporados ao plano de produ¸c˜ao.
Finalmente, para a cria¸c˜ao do core asset base ´e necess´ario obter um conceito de opera¸c˜oes (CONOPS), respons´avel por auxiliar, em termos organizacionais, a im- planta¸c˜ao da LPS. A CONOPS define: (i) como os ativos centrais comuns ser˜ao atualizados quando a LPS evoluir; (ii) como mais recursos tornam-se dispon´ıveis;
18
Figura 2.15: Inclus˜ao de processos vinculados (Northrop et al., 2009).
(iii) como produtos s˜ao mantidos; (iv) como mudan¸cas de tecnologia e de mercado afetam o ˆambito LPS; entre outros.
3. Plano de produ¸c˜ao dos produtos: prescreve como os produtos s˜ao produzidos a partir dos ativos centrais, onde duas fun¸c˜oes s˜ao consideradas:
❼ Inclus˜ao do processo vinculado a ser utilizado para o desenvolvimento de pro- dutos (processo de produ¸c˜ao). Como mencionado anteriormente, cada ativo central deve ter um processo vinculado que define como este ser´a utilizado no desenvolvimento do produto. O conjunto de processos vinculados, juntamente com o processo necess´ario para uni-los de forma coerente, define o processo de produ¸c˜ao de produtos. Os processos vinculados e seu processo de uni˜ao s˜ao projetados para satisfazer a estrat´egia de produ¸c˜ao, restri¸c˜oes de produ¸c˜ao e refletir o m´etodo escolhido. O m´etodo de produ¸c˜ao, que ´e toda a aborda- gem de implementa¸c˜ao, especifica os modelos, processos e ferramentas a serem utilizadas nos processos vinculados por meio dos ativos centrais;
❼ Descri¸c˜ao dos detalhes do projeto para permitir a execu¸c˜ao e gest˜ao dos pro- cessos vinculados e, portanto, inclui detalhes como o cronograma de projeto, lista de materiais e m´etricas. Na pr´atica, estes detalhes podem estar em um documento separado, mas teoricamente tamb´em s˜ao uma parte do plano de produ¸c˜ao.
A Figura 2.16 refina a no¸c˜ao intuitiva do plano de produ¸c˜ao ilustrado na Figura 2.15. Nela os processos de produ¸c˜ao unem-se aos detalhes do projeto, caracterizando o plano de produ¸c˜ao. Tamb´em ´e poss´ıvel observar claramente a influˆencia dos fatores contextuais (restri¸c˜oes de produtos, estrat´egia de produ¸c˜ao e as restri¸c˜oes de produ- ¸c˜ao) e do m´etodo de produ¸c˜ao sobre o plano de produ¸c˜ao. Por estas raz˜oes, o plano de produ¸c˜ao ´e, em si, um importante ativo central (Northrop et al., 2009).
Figura 2.16: Plano de produ¸c˜ao (Northrop et al., 2009). 2.3.1.2 Engenharia de Aplica¸c˜ao
A atividade de Engenharia de Aplica¸c˜ao depende substancialmente dos artefatos de sa´ıda da atividade anterior, que nesta etapa atuam como artefatos de entrada. Esses artefatos s˜ao: o escopo da linha de produtos, os ativos centrais e o plano de produ¸c˜ao. Al´em desses, a descri¸c˜ao do produto tamb´em ´e necess´aria, conforme ilustrado na Figura 2.17.
Figura 2.17: Engenharia de Aplica¸c˜ao (Northrop et al., 2009).
Mais uma vez, as setas rotativas indicam itera¸c˜ao e relacionamentos intr´ınsecos. Por exemplo, a existˆencia e a disponibilidade de um determinado produto podem tamb´em afetar os requisitos de um produto subsequente (Northrop et al., 2009).
Os construtores de produtos devem utilizar os ativos centrais, de acordo com o plano de produ¸c˜ao, para produzir produtos que atendam a seus respectivos requisitos. Construtores tamb´em tˆem a obriga¸c˜ao de apresentar feedback sobre quaisquer problemas ou deficiˆencias encontradas nos ativos centrais, para que o n´ucleo de artefatos possa permanecer efetivo e vi´avel (Northrop et al., 2009).
2.3.1.3 Gerenciamento
A atividade de Gerenciamento deve garantir que todas as atividades t´ecnicas sejam rea- lizadas de acordo com um planejamento coordenado (Figura 2.18).
Figura 2.18: Gerenciamento (Northrop et al., 2009).
❼ Gerenciamento t´ecnico: coordena as atividades de desenvolvimento do n´ucleo de artefatos e desenvolvimento do produto para garantir que as equipes de desenvol- vimento sigam os processos definidos para a LPS e coletem dados suficientes para acompanhar o progresso desta;
❼ Gerenciamento organizacional: garante que as unidades organizacionais recebam os recursos corretos (por exemplo, treinamento) em quantidade suficiente.
Uma das a¸c˜oes mais importantes da atividade de Gerenciamento da LPS ´e a cria¸c˜ao de um plano de ado¸c˜ao que descreva o estado desejado da organiza¸c˜ao e uma estrat´egia para alcan¸car tal estado.
Por fim, o Gerenciamento tamb´em deve estabelecer como as atividades de Engenharia de Dom´ınio e Engenharia de Aplica¸c˜ao devem interagir para permitir a evolu¸c˜ao da LPS e o gerenciamento das similaridades e das variabilidades de cada ativo.
2.3.2
Estrat´egias de Ado¸c˜ao
Em linhas gerais, ´e poss´ıvel concluir que o conceito de LPS tem como principal objetivo promover a gera¸c˜ao de produtos espec´ıficos com base na reutiliza¸c˜ao de uma infraestrutura central (B¨ockle et al., 2005; Clements e Northrop, 2002; van der Linden et al., 2007). Essa infraestrutura ´e formada, normalmente, por uma arquitetura de software e seus componentes.
Esse conceito ´e adequado a dom´ınios em que existe uma demanda por produtos que possuem caracter´ısticas comuns, mas que contenham pontos de varia¸c˜ao bem definidos. No entanto, as atividades necess´arias para a ado¸c˜ao do conceito de LPS n˜ao s˜ao triviais e demandam tempo e esfor¸co consider´aveis.
Nesse sentido, Krueger (2002) apresenta trˆes diferentes estrat´egias de ado¸c˜ao – pro- ativa, reativa e extrativa – visando apoiar `as diferentes maneiras de se construir uma LPS.
A abordagem extrativa reutiliza um ou mais software existentes para a base inicial da LPS. Para ser considerada uma escolha adequada, essa abordagem n˜ao deve requerer tecnologias complexas para desenvolvimento da LPS e deve possibilitar o re´uso do software existente sem a necessidade de um alto grau de reengenharia. Krueger (2002) exemplifica esta estrat´egia de ado¸c˜ao aplicada a uma LPS software propriet´aria chamada GEARS, a qual tamb´em ´e utilizada nas abordagens seguintes. Essa representa¸c˜ao ´e ilustrada na Figura 2.19.
Figura 2.19: Estrat´egia de ado¸c˜ao extrativa (Krueger, 2002).
Na abordagem reativa, a LPS evolui incrementalmente quando h´a demanda por novos produtos ou quando surgem novos requisitos para os produtos existentes. Essa abordagem ´e adequada em situa¸c˜oes nas quais n˜ao ´e poss´ıvel predizer os requisitos para as varia¸c˜oes dos produtos. A Figura 2.20 ilustra este modelo de acordo com Krueger (2002).
Finalmente, na estrat´egia proativa cada atividade deve ser executada sequencial- mente, ou seja, cada atividade deve ser finalizada para que a pr´oxima possa ser iniciada. Dessa maneira, os desenvolvedores analisam, projetam e implementam uma LPS para apoiar completamente o escopo dos sistemas necess´arios em um cen´ario previs´ıvel. ´E um modelo apropriado quando os requisitos para o conjunto de produtos a serem criados s˜ao est´aveis e podem ser definidos antecipadamente. A Figura 2.21 ilustra a abordagem no contexto explorado por Krueger (2002).
Figura 2.20: Estrat´egia de ado¸c˜ao reativa (Krueger, 2002).
Uma vez que a LPS foi implementada, tudo o que resta ´e criar instˆancias de seus produtos com um simples clique ou, se necess´ario, por meio de uma configura¸c˜ao pr´evia. Com a abordagem proativa, se novos produtos s˜ao necess´arios, ´e mais prov´avel que eles estejam dentro do escopo existente e podem ser criados adicionando simplesmente uma nova defini¸c˜ao espec´ıfica. Sua manuten¸c˜ao e evolu¸c˜ao s˜ao realizadas diretamente na LPS, justificando sua natureza proativa.
Para Clements (2002), os modelos idealizados por Krueger (2002) s˜ao uma contribui- ¸c˜ao de primeira ordem para a vertente de re´uso sistem´atico, uma vez que apresentam evidˆencias de que a ado¸c˜ao do conceito de LPS pode ser uma alternativa vi´avel em termos de custo.
Para a constru¸c˜ao da LPS proposta nesta pesquisa o modelo proativo foi utilizado devido a existˆencia pr´evia de um amplo cat´alogo de requisitos. A viabiliza¸c˜ao dessa estrat´egia foi poss´ıvel por meio da deriva¸c˜ao do cat´alogo em quest˜ao, deixando-o mais adequado ao dom´ınio m-learning e provendo um conjunto de requisitos est´aveis para a aplica¸c˜ao do modelo proativo. Maiores detalhes sobre essa defini¸c˜ao s˜ao apresentados no Cap´ıtulo 3.
2.3.3
Abordagens de Desenvolvimento
Diversas abordagens relacionadas ao conceito de LPS podem ser encontradas na literatura. Algumas s˜ao baseadas em features, que apresentam uma solu¸c˜ao abrangente para ques- t˜oes relacionadas `a representa¸c˜ao de caracter´ısticas dentro das atividades de Engenharia de Dom´ınio e Engenharia de Aplica¸c˜ao. Outras s˜ao baseadas em fam´ılias de produtos que fornecem t´ecnicas centradas nos aspectos de defini¸c˜ao da fam´ılia, constru¸c˜ao da infraes- trutura arquitetural b´asica ou mesmo a implementa¸c˜ao de componentes reutiliz´aveis.
As atividades essenciais apresentadas anteriormente – Engenharia de Dom´ınio, Enge- nharia de Aplica¸c˜ao e Gerenciamento – fazem parte da iniciativa PLP do SEI. Adicional- mente, algumas abordagens auxiliares podem apoiar essas atividades em diferentes aspec- tos: (i) an´alise de dom´ınio (FODA); (ii) defini¸c˜ao de processos e metodologias (PuLSE, FAST e PLUS); ou (iii) gerenciamento de variabilidades (SMarty), conforme apresentado a seguir.
2.3.3.1 FODA
A abordagem FODA (Feature-Oriented Domain Analysis) ´e fundamentada na identifica- ¸c˜ao, an´alise e documenta¸c˜ao de funcionalidades, possibilitando determinar caracter´ısticas comuns, que levam a construir produtos gen´ericos, os quais podem ser aplicados em um determinado dom´ınio (Kang et al., 1990).
O FODA ´e um dos processos precursores na an´alise de dom´ınio orientada a features. As trˆes fases desse processo s˜ao ilustradas na Figura 2.22 (Kang et al., 1990):
Figura 2.22: Fases e produtos da an´alise de dom´ınio (Kang et al., 1990).
1. An´alise de contexto: define os limites e o escopo do dom´ınio em quest˜ao. Para isso um analista deve interagir com os usu´arios e os peritos do dom´ınio. A partir das informa¸c˜oes obtidas o analista ainda desenvolve os diagramas de estrutura e de contexto;
2. Modelagem do dom´ınio: descreve os problemas dentro do dom´ınio que s˜ao contro- lados por software. O analista do dom´ınio usa fontes de informa¸c˜ao e os outros produtos da fase anterior para conduzir a modelagem do dom´ınio. O principal pro- duto ´e o modelo de features, que consiste em uma representa¸c˜ao hier´arquica que captura os relacionamentos estruturais entre as features do dom´ınio em an´alise. Em um modelo de features, elementos comuns entre diferentes produtos s˜ao con- siderados como features obrigat´orias, enquanto que diferentes features podem ser consideradas opcionais ou alternativas. Features opcionais podem estar ou n˜ao pre- sentes em um produto, quando presentes, adicionam algum valor `as suas features obrigat´orias. As features alternativas s˜ao excludentes, ou seja, em cada produto apenas uma delas deve estar presente;
3. Modelagem da arquitetura: cria a arquitetura do software que fornece as solu¸c˜oes aos problemas encontrados no dom´ınio. Usando o modelo de features, o analista produz o modelo da arquitetura, que deve ser revisto por um perito.
A partir dessa abordagem foram desenvolvidas algumas extens˜oes. A FORM (Feature– Oriented Reuse Method ) (Kang et al., 1998), por exemplo, apresenta acr´escimos em termos arquiteturais e de componentes.
Ainda no contexto de extens˜oes, a FOOM (Feature–Object Oriented Modeling) (Ajila e Tierney, 2002) ´e uma s´ıntese da abordagem FODA e do modelo de reengenharia Horseshoe (Bergey et al., 1999) do SEI. O FOOM apresenta um processo unificado de desenvolvi- mento do software para desenvolver e descrever cada um dos modelos da arquitetura de uma LPS. Parte integral desta padroniza¸c˜ao ´e a ado¸c˜ao da UML (Unified Modeling Language) para a representa¸c˜ao dos recursos desenvolvidos nesse processo.
2.3.3.2 PuLSE
A PuLSE (Product Line Software Engineering), desenvolvida pelo IESE (Institute Expe- rimentelles Software Engineering) (Bayer et al., 1999), define uma metodologia de cons- tru¸c˜ao e utiliza¸c˜ao de LPS baseadas em componentes. A Figura 2.23 apresenta uma vis˜ao geral da estrutura da abordagem PuLSE.
Figura 2.23: Vis˜ao geral da abordagem PuLSE (Bayer et al., 1999).
De acordo com Bayer et al. (1999), a PuLSE inclui as seguintes fases e componentes fundamentais:
1. Fases de implementa¸c˜ao: s˜ao etapas l´ogicas que uma LPS atravessa. Elas descrevem as atividades realizadas para configurar e usar a LPS. As fases s˜ao as seguintes:
❼ Constru¸c˜ao de infraestrutura: corresponde `a defini¸c˜ao do escopo, modelagem e arquitetura da infraestrutura da LPS;
❼ Utiliza¸c˜ao da infraestrutura: uso da infraestrutura para criar membros da linha de produtos;
❼ Evolu¸c˜ao e gerenciamento: evolu¸c˜ao e gerenciamento da infraestrutura.
2. Componentes t´ecnicos: fornecem o know-how t´ecnico necess´ario para viabilizar o desenvolvimento da LPS. Esses componentes s˜ao os seguintes:
❼ PuLSE-BC: define como os componentes t´ecnicos s˜ao personalizados de acordo com um ambiente espec´ıfico;
❼ PuLSE-Eco: utilizado para identifica¸c˜ao de escopo para um membro da LPS; ❼ PuLSE-CDA: cont´em an´alise de dom´ınio e elabora¸c˜ao do modelo de decis˜ao
que ser´a utilizado para a cria¸c˜ao da arquitetura da linha de produtos;
❼ PuLSE-DSSA: apoia a defini¸c˜ao da arquitetura espec´ıfica de dom´ınio, que im- plica no desenvolvimento incremental da estrutura de LPS guiado por cen´arios; ❼ PuLSE-I: executa a instancia¸c˜ao do produto na fase que o utiliza;
❼ PuLSE-EM: lida com o gerenciamento de configura¸c˜ao e quest˜oes relacionadas `a evolu¸c˜ao do produto.
3. Componentes de apoio: pacotes de informa¸c˜oes ou orienta¸c˜oes, que permitem uma melhor adapta¸c˜ao, evolu¸c˜ao e implanta¸c˜ao da LPS. S˜ao eles:
❼ Pontos de entrada do projeto: personalizam a PuLSE para tipos maiores de