Criar o Diagrama de Features

Nesta atividade foi desenvolvido o diagrama de features da LRMLPS apoiada pela diretriz “D3 - Desenvolver o Diagrama de Features” o qual utiliza a notação PLUS (Gomaa, 2004). O desenvolvimento do digrama de features é uma atividade iterativa que foi conduzida com auxilio de informações contidas no artefato TFC, apresentado na Tabela 4-2. Por exemplo, a primeira linha da TFC foi utilizada como ponto de partida para o desenvolvimento e agrupamento das features. Posteriormente, as colunas “Nome Feature”, “Categoria Feature”, “Nó Pai” e “Nó(s) Filho(s)” foram utilizadas pelo engenheiro de domínio para começar a criação do diagrama de features. Dessa forma, a feature MobileRobots no qual representa o domínio da LPS foi decomposta em sete sub-features (Connection, Actuator, Navigation, VehicleType, Behaviors, LocomotionDevice e Sensor). De forma, semelhante à feature Connection foi composta de outras duas features (Bluetooth e Wi-Fi). Em seguida, foi feita uma iteração por todo o artefato TFC para o desenvolvimento do diagrama de features. Na Figura 4-4 é apresentado o digrama de features da LRMLPS. Após o desenvolvimento do diagrama de features foi iniciada a atividade ”Criar a Arquitetura da LPS” no qual é descrito a seguir.

Camera Alternativa Sensor -- Funcionalidade

de câmera

Controller Obrigatório Tele-operado Phone/PC/WiiControl

Representa os tipos de controller disponíveis

Charger Alternativa CargoShip -- Representa o

tipo de RM

ForkLift Alternativa CargoShip -- Representa o

tipo de RM

Alg1 Alternativa HomeSentry -- Representa o

tipo de RM

Alg2 Alternativa HomeSentry -- Representa o

tipo de RM

Alg3 Alternativa Homesentry -- Representa o

tipo de RM

Phone Alternativa Controller -- Representa o_{tipo de}

controller

PC Alternativa Controller -- Representa o_{tipo de}

controller

WiiControl Alternativa Controller -- Representa o_{tipo de}

4.5 Criar a Arquitetura da LPS

Atividade responsável por criar a arquitetura da LRMLPS. O mesmo foi criado utilizando a notação PLUS (Gomaa, 2004) juntamente com as diretrizes propostas por Almeidaet al., (2007).

As diretrizes propostas por Almeida et al., (2007) foram úteis para auxiliar o engenheiro de domínio a modelar a estrutura, e a delinear as features comuns e variáveis da LRMLPS, ou seja, para a criação da arquitetura da linha. Por exemplo, os conjuntos de features Sensor (Ultrasonic, Light, Touch e Camera) e Actuator (MotorLeft, MotorRight, Neck e Fork) foram modelados utilizando o padrão Builder (Gamma, 2002). Features alternativas foram implementadas utilizando o padrão AbstractFactory ou Factory Method. Dessa forma, na Figura 4-5 é apresentada a arquitetura da LRMLPS.

Após o desenvolvimento da arquitetura da linha de produtos, deu-se inicio à atividade “Implementar os Artefatos da LPS, descrita a seguir.

4.6 Implementar os Artefatos da LPS

Atividade responsável por implementar as variabilidades e similaridades da LRMLPS. Dessa forma, foi utilizado como entrada o modelo de arquitetura criado anteriormente. O IDE (Integrated Development Environment) Eclipse (Eclipse, 2011) foi utilizado como principal ferramenta juntamente com a máquina virtual LeJOS (LeJOS, 2011) para sintetizar as variabilidades e similaridades da LPS em códigos- fontes. A saída desta atividade consiste de um conjunto de arquivos que estão contidos os códigos-fontes.

Conforme descrito por Anastasopoules e Gacek (2001) existem várias abordagens para implementar variabilidades, no entanto, o hardware do Lego Mindstorms não é tão eficiente para fornecer apoio a algumas dessas abordagens, como AspectJ (AspectJ, 2011). Dessa maneira, padrões de projeto (Gamma, 1994) foram utilizados para implementar as variabilidades e similaridades da LRMLPS. Na Figura 4-6 são apresentados trechos de códigos fontes nos quais foram aplicados o padrão Builder para implementar as respectivas features: ultrasonic e camera. A classe DirectorSensor (Figura 4-6(a)) é responsável por gerenciar a sequência

correta de criação dos sensores da LRMLPS, enquanto que BuilderSensor, (Figura 4-6(b)) representa uma classe abstrata a qual tem a responsabilidade de criar sensores da linha. As classes BuilderUltraSonicSensor (Figura 4-6(c)) e

BuilderCamera (Figura 4-6(d)) fornecem uma implementação da classe BuilderSensor, as quais auxiliam a criação de instâncias dos seus respectivos

Figura 4-6 - Trechos de código-fonte da variabilidade Ultrassônico

Na Figura 4-7 é apresentada uma visão geral da estrutura da LRMLPS. A camada de hardware contém todos os sensores e atuadores disponíveis da linha, tais como, ultrassônico, sensor de toque, sensor de luz, câmera e três servos motores. Além dos sensores e atuadores, essa camada também contém um micro controlador. Tais hardwares são utilizados para a construção dos produtos pertencentes à linha. A camada de plataforma oferece ao desenvolvedor uma camada de abstração, implementada em software, entre o hardware e os artefatos. Essa camada deve existir para abstrair os detalhes de baixo nível dos hardwares (sensores e atuadores) permitindo o desenvolvimento de aplicações de maneira mais fácil. A terceira camada representa os artefatos da LPS que foram implementados nessa atividade, ou seja, todas as features comuns e varáveis da LRMLPS são armazenadas para serem reutilizadas posteriormente. A quarta camada representa as aplicações que são instanciadas utilizando os artefatos da camada inferior.

Para auxiliar o processo de instanciação de um determinado membro da LRMLPS foi desenvolvida uma DSL gráfica que agiliza o desenvolvimento de

membros da linha. O processo de desenvolvimento da DSL é descrita na próxima seção.

Figura 4-7 - Visão Geral da LRMLPS

4.7 Implementar a DSL Gráfica

Atividade responsável por criar uma DSL gráfica intitulada Features-To- ModelOrCode (F2MoC) para auxiliar e agilizar a tarefa do engenheiro de aplicação na instanciação de um membro da linha de produtos.

A partir do diagrama de features, o engenheiro de domínio especificou o metamodelo da F2MoC, com suas metaclasses, meta-atributos, e meta- relacionamentos utilizando o meta-metamodelo Ecore do Eclipse Modeling Framework (EMF) (EMF, 2011).

O Ecore fornece uma metalinguagem para definição de metamodelos no IDE Eclipse. Por exemplo, as features Ultrasonic, Touch, Camera, Light, MotorLeft, MotorRight, Neck e Fork ilustradas no diagrama de features da Figura 4-4 foram mapeadas para as metaclasses de mesmo nome destacadas no metamodelo da Figura 4-8.

Figura 4-8 - Metamodelo da DSL

Adicionalmente, o EMF possibilita ao engenheiro de domínio gerar código Java a partir do metamodelo e de um editor de modelos que auxilia na especificação

dos membros da LRMLPS na etapa de EA. Nesse editor os modelos são persistidos no formato de XML metadata Interchange (XMI), um padrão da Object Managment Group (OMG) utilizado para representar modelos em eXtensible Markup Language (XML). Esse formato define uma estrutura de documentos que considera a relação entre dados e seus correspondentes metadados, o que facilita realizar transformações M2M e M2C. Como exemplo, na Figura 4-9 é apresentado um trecho de código gerado automaticamente o qual corresponde à metaclasseUltrasonic.

Figura 4-9 - Implementação do Metamodelo (metaclasse Ultrasonic)

A F2MoC criada é representada na forma de diagrama de features. Para instanciar um membro da LRMLPS utilizando a F2MoC o engenheiro de aplicação escolhe um conjunto de features disponível da linha. Além disso, tais features são utilizadas para realizar transformações M2M e M2C. Assim, a partir das features escolhidas a F2MoC cria um diagrama de classe e os códigos-fontes do membro da linha de produtos.

Para realizar tais transformações foram desenvolvidos templates utilizando o framework Java Emitter Template (JET) (Jet, 2011). Tais templates interpretam as features selecionadas e consequentemente realizam as transformações M2M e M2C. Na Figura 4-10 é apresentado um trecho de umtemplate utilizado para realizar transformações M2C. Esse template é invocado pelo JET quando for encontrado a feature Ultrasonic durante a leitura do XMI. De acordo com a feature selecionada um determinado trecho desse template será executado, ou seja, quando feature ultrasonic for selecionado as linhas 6-11 serão executadas; quando a feature “Navigation” for selecionada as linhas 14-17 serão executadas.

Em transformações M2M, o objetivo principal é transformar um modelo de entrada especificado em alto nível em outro modelo mais especifico (Czarnecki e Antkiewicz, 2004). Neste trabalho o diagrama defeatures modelado pelo engenheiro de aplicação é transformado em um diagrama de classe. Essa transformação é feita tendo como base o uso de templates juntamente com padrões de projeto. Os templates desenvolvidos para realizar as transformações M2M utilizaram a ferramenta Papyrus que é uma ferramenta gráfica, open source utilizada para fornecer suporte para UML (OMG, 2011).

Figura 4-10 - Template para geração de código

Na próxima seção é descrito a Engenheira de Aplicação. Nessa etapa o engenheiro de aplicação deve utilizar a F2MoC, a fim de agilizar o processo de instanciação de um determinado membro pertencente à LRMLPS.