Engenharia do Domínio

O processo de Domain Engineering ou Engenharia do Domínio tem como finalidade identificar, construir, catalogar e disseminar conjuntos de componentes que possuam aplicabilidade em softwares existentes e futuros de um determinado domínio. Assim, engenheiros de software podem compartilhar componentes para reutilizá-los no desenvolvimento de sistemas futuros (PRESSMAN, 2011).

Para Pohl et al. (2005), a Engenharia do Domínio é formada para atender basicamente três objetivos:

 Definir as comunalidades e variabilidades da Linha de Produto de Software;

 Definir e construir artefatos reusáveis que atendam as variabilidades;  Definir qual tipo de softwares (o domínio), do conjunto de softwares que

será construído através da Linha de Produto.

Essa etapa de identificar, construir e validar a engenharia de domínio é composta por quatro atividades não sequenciais, ou seja, a qualquer momento da etapa da construção da Engenharia do Domínio, o engenheiro de software, poderá voltar a outras etapas para realizar melhorias constantes.

As etapas do processo de Engenharia de Domínio serão vistas nas subseções 3.1.1 a 3.1.4.

Durante o desenvolvendo destas etapas, também é recomendado a documentação das variabilidades nos diferentes artefatos. Para cada etapa, existe uma forma mais adequada para realizar a documentação.

3.1.1 Engenharia de Requisitos do Domínio

Para Nuseibeh e Easterbrook (2000), engenharia de requisitos é o processo de descobrir o objetivo e as necessidades dos stakeholders, realizar análises, documentar as informações para posteriormente realizar implementações. Este processo também é o responsável por realizar a separação dos problemas e as soluções.

Na Linha de Produto de Software, o Domain Requirement Engineering ou Engenharia de Requisitos do Domínio tem o papel de determinar as comunalidades

e variabilidades, assim como realizar a documentação. Embora seja a primeira etapa a ser realizada, ela será trabalhada ao longo de todo o desenvolvimento da linha de produto.

Durante o processo de busca dos requisitos, são elencados os problemas (as necessidades que o software precisa atender), que terão relação constante com Projeto do Domínio, que buscará a solução dos problemas identificados nesta etapa. Após identificados os requisitos que serão atendidos, pode ser criada uma Matriz de Requisitos entre os requisitos identificados e as aplicações existentes, caso existam. Para cada combinação deve verificar se o requisito está presente ou não em cada aplicação conforme o exemplo da Figura 10:

Figura 10 – Modelo de uma Matriz de Requisitos

Fonte: Elaborada pelo autor

Diante dos valores obtidos com a Matriz de Requisitos é possível listar quais informações são características comuns a todos os softwares ou a maioria desde que não entre em conflito com outros requisitos (comunalidade); quais são flexíveis (variabilidade); e quais são exclusivas de um software.

Tendo identificado as comunalidades e variabilidades, o engenheiro de software pode representá-las através de uma Feature Model, como foi visto anteriormente.

Outra tarefa importante a ser realizada é documentar os pontos de variabilidade presentes na etapa de Engenharia de Requisitos do Domínio, que pode ser tanto de forma textual ou na linguagem de modelagem, Unified Modeling

Language (UML) com diagramas. UML é uma linguagem visual para modelagem de

sistemas de software orientados a objetos (BOOCH et al., 2005).

Na representação visual por UML o engenheiro de software pode optar por diagramas como Diagrama de Caso de Uso e de Sequência, que é mais fácil para os clientes que vão utilizar o sistema entenderem o funcionamento, como também pode optar por diagramas de estado, para facilitar o entendimento do comportamento de certos componentes pelo programador.

3.1.2 Projeto do Domínio

Pressman (2010) define uma arquitetura sendo um conjunto de componentes de uma construção de forma a coexistir como um todo. Já na visão de arquitetura em software ou sistemas se trata da estrutura que abrangem os componentes de softwares, propriedades externas visíveis e a relação entre eles.

Seguindo essa concepção, o Projeto do Domínio será trabalhado com os requisitos identificados no processo de Engenharia de Requisitos do Domínio, de forma a criar uma estrutura que solucione os problemas e que possam ser implementadas na etapa seguinte.

Durante a construção da arquitetura é interessante trabalhar com o uso de Diagrama de Componentes, pois este permite que peças possam ser retiradas e encaixadas com facilidade sem grandes impactos no sistema. Ao trabalhar com interfaces, permitirá que o sistema esteja apto a receber um componente futuro que ainda não tenha sido vislumbrado até o exato momento.

3.1.3 Implementação do Domínio

A etapa de Implementação do Domínio tem como finalidade implementar os artefatos reusáveis em formas de um framework com componentes e interfaces, que represente a arquitetura planejada.

Nesta etapa também é possível observar o nível de abstração das interfaces, de forma que uma abstração alta permite trabalhar diversos tipos de componentes, o que também pode ocasionar ao uso de componentes não desejados. Em contrapartida, uma abstração baixa, pode ter uma flexibilidade muito limitada.

A documentação da variabilidade dos artefatos na etapa de implementação ocorre diretamente com a demonstração do Diagrama de Classe, principalmente com o uso de interfaces para mostrar uma visão abstrata de como algo pode ser implementado de diferentes formas.

3.1.4 Teste do Domínio

No teste de domínio são realizados os testes que buscam tanto erros nas funcionalidades, algo básico de qualquer desenvolvimento de software, como

também das comunalidades e variabilidades, para verificar se estas estão atendendo de fato os requisitos dos clientes.

Quando mais cedo um erro for identificado menor será seu custo. Uma relação desses custos poderia ser representada de forma que um erro identificado na definição do projeto, tendo um custo médio de 1 dólar, ao ser identificado na produção do código teria um custo de 10 dólares e na etapa de teste seu custo subiria para 50 dólares (DUSTIN, 2002).

Por outro lado, um teste completo pode se tornar algo inviável numa LPS devido a quantidade de opções existentes. Desta forma o engenheiro pode optar por testes menos completos, como as seguintes estratégias (POHL et al., 2005):

 Sample Application Strategy – Essa estratégia consiste em criar algumas aplicações completas para verificar se a plataforma está atendendo algumas flexibilidades, porém devido ao fato de não testar todas as possibilidades, ainda há o risco de existir componentes e interfaces que não se adequem a diferentes softwares.

 Commonality and Reuse Strategy – Essa estratégia é semelhante ao

Sample Application, porém o teste é focado em testar todas

comunalidades e componentes reusáveis. Desta forma, ao invés de criar diversas aplicações para cada combinação, utiliza-se as mesmas aplicações já implementadas, modificando apenas as partes envolvendo os pontos de variação, para verificar se o ponto de variabilidade atende ou não a flexibilidade desejada.

A documentação dos pontos de variação no Teste do Domínio pode ser realizada em duas etapas: Planejamento e execução do Teste, por fim é avaliado através do relatório.

Ao completar as quatro etapas da Engenharia do Domínio (requisitos, projeto, implementação e teste), a plataforma comum que será utilizada na Engenharia de Aplicação deverá estar pronta para o uso.