Com as atividades de SPLE mapeadas na técnica OOFM, percebe-se que diferentes tipos de atores, atividades e transições podem ser aplicados em cada passo descrito. Tratam- se de elementos que podem ser combinados em diagramas de atividades para modelar: o processo geral do negócio; a lógica capturada em um único cenário de uso; ou a lógica detalhada de uma regra de negócio (Booch, Rumbaugh e Jacobson, 1998).
Assim, tem-se no OOFM Process (Figura 18) um diagrama de atividades que ilustra o processo de modelagem OOFM baseado em atividades de SPLE adaptadas. Dentre os atores identificados no OOFM Process, destacam-se: o Domain Specialist, o OOFM Specialist, o
Application Creator e o Technology Specialist.
O Domain Specialist é responsável pela identificação de features representativas de um domínio de software. Estas features podem ser ou específicas para uma família de softwares ou genéricas para qualquer família de softwares possível de ser representada neste domínio de software.
O OOFM Specialist é responsável pela extensão do OOFM Framework, criando novas estruturas OOFM para domínios de software específicos. Ele segue as features identificadas pelo Domain Specialist, as quais guiam a especialização dos recursos abstratos disponíveis no OOFM Framework.
O Application Creator gera aplicações concretas a partir dos recursos do OOFM Framework e das features desejadas num domínio de software específico. Trata-se de um
61
produtor de FCs que gera features a partir de uma família de software projetada (FM associado). Features geradas também podem ser usadas para contextualizar estruturas OOFM modeladas com a ajuda do OOFM Specialist. FMs especializados também podem ser criados pelo Application Creator a partir de FMs genéricos, antes de se construir os FCs desejados para cada aplicação de domínio projetada.
Finalmente, o Technology Specialist trabalha na integração dos recursos do OOFM Framework com os recursos da tecnologia de implementação escolhida. Trata-se de um ator que fornece as estruturas Adapter necessárias para se criar sistemas concretos, bem como ajuda o Application Creator a usar tais estruturas Adapter quando necessário.
Figura 18 Diagrama de Atividades do OOFM Process.
Ou seja, Domain Specialist e OOFM Specialist executam atividades relacionadas ao primeiro passo, criando recursos OOFM representativos de FMs de uma SPL de domínio específico. Application Creator executa na maior parte do seu tempo atividades do segundo
passo, gerando FCs com base nos recursos de FM especializados. Entretanto, caso algum
recurso de FM tenha se mantido abstrato mesmo após a sua especialização para um domínio específico, Application Creator pode atuar como produtor de recursos de FM especializados, assumindo o papel de um Domain Specialist ou de um OOFM Specialist. Já o Technology
62
Specialist fica responsável pelas atividades do terceiro passo, adaptando os recursos OOFM
definidos para os respectivos artefatos de implementação do sistema.
3.4 CONCLUSÃO DO CAPÍTULO
Este capítulo apresentou uma abordagem de criação padronizada de SPLs avançadas com base na OOFM. Para tal, foram descritos o OOFM Framework e as atividades de SPLE organizadas no OOFM Process.
OOFM Framework é basicamente formado por um conjunto de estruturas que se caracterizam como uma Product Line Architecture (PLA) capaz de representar FMs e FCs avançados via recursos OOFM. Já o OOFM Process define os atores e atividades necessárias para converter as estruturas abstratas do OOFM Framework numa SPL concreta e especializada. Atividades do OOFM Process também indicam como produzir sistemas concretos com base na SPL definida.
Como resultado, uma nova abordagem de desenvolvimento de SPLs foi obtida com a OOFM, sendo esta formada por FMs e FCs avançados aplicados numa PLA simples e padronizada. Ou seja, uma abordagem inversa às técnicas tradicionais de produção de SPL, as quais são baseadas em modelos FODA simples manipulados por PLAs distintas e complexas (Sarinho, Apolinário e Almeida, 2012).
O próximo capítulo irá apresentar um exemplo de SPL baseada na OOFM para o domínio dos jogos digitais denominada Feature-based Environment for Digital Games (FEnDiGa), bem como seu uso na produção de uma versão simplificada do jogo Pacman, corroborando assim a capacidade da OOFM em fornecer sistemas de software concretos.
63
Este capítulo apresenta o Feature-based Environment for Digital Games (FEnDiGa), uma especialização do OOFM Framework e do OOFM Process para o domínio dos Jogos Digitais. FEnDiGa foi aplicada na produção de uma versão simplificada do jogo digital Pacman, demonstrando assim a capacidade da OOFM em gerar sistemas concretos desejados.
4 IMPLEMENTANDO JOGOS DIGITAIS COM A OOFM
OOFM Framework melhora a técnica OOFM ao fornecer um tratamento estático e dinâmico de FMs e FCs modelados. OOFM Process apresenta atores, atividades e transições de atividades de SPLE com base em recursos definidos na OOFM. Tratam-se de recursos importantes para a OOFM que auxiliam na produção de sistemas concretos desejados. Entretanto, tratam-se também de estruturas abstratas projetadas para trabalhar apenas com recursos genéricos representativos de features. Neste sentido, versões especializadas do OOFM Framework e do OOFM Process precisam ser fornecidas, no intuito de tratar a variabilidade de domínios de software específicos bem como gerar sistemas concretos desejados.
Com relação ao domínio dos jogos digitais, trata-se de um domínio de grande variabilidade e complexidade, tanto no aspecto conceitual como também no aspecto de implementação de jogos digitais específicos. De fato, trabalhar com jogos digitais significa trabalhar com diferentes tipos de: simulações (e.g. esportes, aventuras, lutas, batalhas), hardwares (e.g. jogos móveis, jogos para web, acelerômetros), interações humanas (e.g. imersão, multiplayer) e estórias complexas (e.g. jogos derivados do cinema, séries de RPGs) (Sarinho e Apolinário, 2008). Ou seja, trata-se de um excelente campo de prova para a abordagem OOFM proposta. Este capítulo apresenta a geração de uma SPL OOFM para o
Capítulo
64
domínio dos jogos digitais denominada Feature Environment for Digital Games (FEnDiGa) (Sarinho, Apolinário e Almeida, 2011-2012). Trata-se de uma especialização do OOFM Framework e do OOFM Process, tendo como base os modelos de features NESI (Sarinho e Apolinário, 2008) e GDS (Sarinho e Apolinário, 2009) representativos de jogos digitais.
FEnDiGa permite a integração das visões conceituais e de implementação de jogos representadas nas features dos modelos NESI e GDS, respectivamente. FEnDiGa também permite a adaptação direta de FMs representativos de jogos digitais para múltiplas game engines, algo importante para garantir a portabilidade do G-Factor (Binsubaih e Maddock, 2008) em jogos digitais modelados.