1

SMartyParser: Um Parser XMI para Modelos UML de Linha de Produto de Software

Leandro Alves Lanceloti1, Edson A. Oliveira Junior2 Resumo. A adoção da linha de produto de software (LP) tem ajudado empresas a diminuírem custos e melhorarem seus produtos. O gerenciamento de variabilidade é uma das fases mais importantes de uma LP. A abordagem SMarty propõe o gerenciamento de variabilidades por meio de estereótipos UML e diretrizes. Este artigo apresenta um parser XMI para modelos UML de LP com o objetivo de permitir que tais modelos possam ser interpretados e carregados para ferramentas de gerenciamento de LP. A LP Arcade Game Maker (AGM) é usada para ilustrar a aplicação do parser.

Palavras-chave: linha de produto de software, parser, UML, variabilidade, XMI. Abstract. The adoption of software product line (PL) has helped companies to lower costs and improve its products. Variability management is one of the most important activities of a PL. The SMarty approach proposes variability management by means of UML stereotypes and guidelines. This paper presents an XMI parser for UML models of a PL aimed at interpreting and loading such models into PL management tools. The Arcade Game Maker (AGM) PL is used to illustrate the application of such a parser. Keywords: parser, software product line, UML, variability, XMI.

1. Introdução A cada dia aumenta a demanda por sistemas de software e demais serviços computacionais. A adoção da abordagem de linha de produto de software (LP) tem permitido às empresas diminuírem os custos no desenvolvimento e encurtar o tempo para um produto chegar ao mercado (time to market). Empresas como Boeing e Bosch Group têm relatos de casos de sucesso ao abordarem LP (SEI, 2012a).

O gerenciamento de variabilidades é uma das atividades mais importantes no ciclo de vida de uma LP. Dentre as várias abordagens existentes de gerenciamento de variabilidades (CHEN, 2009), SMarty (Stereotype-based Management of Variability) (OLIVEIRA JUNIOR et al., 2010) baseia-se em um perfil UML (Unified Modeling Language) e um processo com atividades definidas para identificar, delimitar e representar variabilidades em modelos UML de uma LP.

Como a abordagem SMarty é totalmente compatível com o modelo UML, é possível exportar seus modelos para outras ferramentas por meio do formato XMI (XML Metadata Interchange) (OMG, 2011).

Este trabalho apresenta um parser XMI para modelos UML baseado na abordagem SMarty e suas diretrizes para análise de linha de produto de software e variabilidade.

Este artigo está organizado da seguinte forma: na Seção 2 são apresentados os principais conceitos sobre LP e variabilidade; na Seção 3 são apresentados os principais

1 Aluno do curso de especialização em Desenvolvimento de Sistemas para Web – Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 – Bloco C56 – Maringá – PR – Brasil – leandro@lancelotti.com.br 2 Departamento de Informática – Universidade Estadual de Maringá (UEM) - Av. Colombo, 5790 – Bloco C56 – Maringá – PR – Brasil - edson@din.uem.br

2

conceitos sobre XMI, sua funcionalidade e principais tags; a Seção 4 apresenta o SMartyParser para Modelos UML e LP; a Seção 5 apresenta o SMartyParser aplicado à LP Arcade Game Maker (AGM); a Seção 6 discute os trabalhos relacionados; e a Seção 7 apresenta a conclusão e direções para trabalhos futuros.

2. Linha de Produto de Software e Variabilidade Uma LP é um conjunto de sistemas de software que compartilham funcionalidades em comum e gerenciáveis que satisfazem as necessidades específicas de um determinado segmento do mercado (LINDEN et al., 2007). Esse conjunto de sistemas também é chamado de família de produtos e seus membros são desenvolvidos especificamente a partir de uma infraestrutura comum de LP, o núcleo de artefatos. O núcleo de artefatos forma a base de uma LP e, normalmente, inclui a arquitetura de LP, componentes reutilizáveis, modelos de domínios, requisitos da LP, planos de teste e modelos de características e de variabilidades (OLIVEIRA JUNIOR et al., 2010). Segundo Weiss e Lai (1999) e Chen et al. (2009), variabilidade é a maneira com que os membros de uma família de produtos se distinguem entre si. Variabilidade pode estar ligada entre diferentes níveis de abstração, como na descrição da arquitetura, na documentação do projeto, no código fonte, no código compilado e no código executável. As variabilidades possibilitam que muitas decisões de projeto sejam adiadas, assim, quanto mais tarde forem tomadas, maior é o número de variabilidades de uma LP. Decisões tomadas precocemente afunilam o domínio ao qual o sistema pode ser aplicado, prejudicando a reutilização. O gerenciamento de variabilidades está ligado a todas as etapas do processo de desenvolvimento de uma LP e envolvem atividades como a identificação, delimitação e implementação de variabilidade, bem como o gerenciamento de variantes (CHEN et al., 2009). Com base nesses conceitos, a abordagem SMarty (OLIVEIRA JUNIOR et al., 2010, FIORI; OLIVEIRA JUNIOR, 2012) foi proposta. SMarty é composta por um perfil UML, o SMartyProfile, e um processo, o SMartyProcess. O SMartyProfile contém um conjunto de estereótipos e meta-atributos para representar variabilidade em modelos UML de LP, conforme ilusta a Figura 1. Basicamente, o SMartyProfile usa a notação UML e o seu mecanismo de profiling (OMG, 2011) para fornecer uma extensão do metamodelo padrão da UML e permitir a representação gráfica dos conceitos de variabilidade.

3

Figura 1: O Perfil SMartyProfile (FIORI; OLIVEIRA JUNIOR, 2012)

O SMartyProcess é um processo sistemático que guia o usuário na identificação, delimitação, representação, rastreamento de variabilidades e análise de configurações de produtos de uma LP. O processo é apoiado pelo SMartyProfile e por um conjunto de diretrizes que guiam o usuário na realização das suas atividades principais. Os principais conceitos adotados pelo SMartyProfile são: variabilidade, que diferencia os membros de uma LP; ponto de variação, que representa um local exato onde ocorre a variação; variante, que é um artefato que sofre determinada variação; e restrição entre variantes, que define os relacionamentos entre as variantes para que seja possível resolver um ponto de variação ou uma variabilidade. A identificação de variabilidades é uma atividade que depende do conhecimento e habilidade dos gerentes e analistas de LP (LINDEN et al., 2007, OLIVEIRA JUNIOR et al., 2010). Para tanto, o SMartyProcess fornece algumas diretrizes, que são:

D.1. elementos de modelos de caso de uso relacionados aos mecanismos de extensão e de pontos de extensão (OMG, 2011) sugerem ponto de variação com variantes associadas, as quais podem ser inclusivas e exclusivas. Assim, os casos de uso estendidos representam pontos de variação, enquanto os casos de uso que estendem, representam variantes.

D.2. em modelos de classes, pontos de variação e suas variantes são identificados nos seguintes relacionamentos (OMG, 2011):

a. generalização, os classificadores mais gerais são os pontos de variação, enquanto os mais específicos são as variantes;

b. realização de interface, os “supliers” (especificações) são os pontos de variação e as implementações (clientes) são as variantes;

c. agregação, as instâncias tipadas com losangos não preenchidos são os pontos de variação e as instâncias associadas são as variantes; e

d. composição, as instâncias tipadas com losangos preenchidos são os pontos de variação e as instâncias associadas são as variantes.

4

D.3. elementos de modelos de casos de uso relacionados com a associação de inclusão (<<include>>) ou associados a atores (OMG, 2011) sugerem variantes obrigatórias ou opcionais;

D.4. elementos de modelos de classes, relacionados à associações nas quais os seus atributos aggregationKind possuem valor none (OMG, 2011), ou seja, não apresentam nem agregação nem composição, sugerem variantes obrigatórias ou opcionais;

D.5. variantes que, ao serem selecionadas para fazer parte de um produto, exigem a presença de outra(s) determinada(s) variante(s) devem ter seus relacionamentos de dependência marcados com o estereótipo <<requires>>;

D.6. variantes mutuamente exclusivas para um determinado produto, devem ter seus relacionamentos de dependência marcados com o estereótipo <<mutex>>; e

D.7. componentes formados por classes com variabilidades são marcados com o estereótipo <<variable>>.

D.8. elementos de modelos de diagramas de atividades como DecisionNode sugerem pontos de variação marcados com <<variationPoint>>, pois é um local formado explicitamente por possíveis caminhos para grupos de ações distintas.;

D.9. elementos Action dos diagramas de atividades podem ser definidos como variantes obrigatórias ou opcionais;

D.10. elementos Action que representam fluxos alternativos de saída de um DecisionNode sugerem variantes alternativas inclusivas ou exclusivas;

D.11. elementos ActivityPartition que possuem elementos variáveis, DecisionNode como ponto de variação ou Action como variantes, devem ser marcados como <<variable>>, pois são compostos por elementos que sofrem algum tipo de variação.

Para exemplificar a aplicação da abordagem SMarty, a LP AGM (SEI, 2010b) é utilizada. AGM é uma LP pedagógica para jogos criada pelo Software Engineering Institute (SEI) para apoiar o aprendizado e a experimentação de conceitos de LP. A AGM não é uma LP comercial, porém tem sido usada para ilustrar os conceitos de várias abordagens distintas de LP e estudos de caso e avaliação de arquiteturas de LP. AGM é dividida em vários artefatos fundamentais que são: o modelo de características, o modelo de casos de uso, o modelo de classes e a arquitetura lógica de componentes (OLIVEIRA JUNIOR, 2010).

A Figura 2 apresenta o diagrama de casos de uso da LP AGM. Um ponto de variação é identificado em Play Selected Game (segundo a diretriz D.1). As três opções de jogos estão marcadas com o estereótipo <<alternative_OR>> já que o usuário pode escolher mais de um jogo (segundo a diretriz D.1). O caso de uso Check Previous Best Score depende do Save Score cuja associação está marcada com o estereótipo <<requires>> de acordo com a diretriz D.5.

5

Figura 2: Diagrama de casos de uso da LP AGM (OLIVEIRA JUNIOR et al., 2010)

A Figura 3 mostra o diagrama de classes da AGM, o Core Assets, que detalha o componente Game da Figura 7. Um ponto de variação é encontrado em GameSprite (diretriz D.2) com as variantes inclusivas StationarySprite ou MovableSprite, marcadas com o estereótipo <<alternative_OR>> (diretriz D.2 - a). Outro ponto de variação é identificado em MovableSprite contendo as variantes Puck e Paddle sendo alternativas inclusivas marcadas com o estereótipo <<alternative_OR>> (diretriz D.2 - a).

<<variability>>name = "play game"minSelection = 1maxSelection = 3bindingTime = DESIGN_TIMEallowsAddingVar = truevariants = {Play Brickels, Play Pong, Play Bowling}

<<variability>>name = "save score"minSelection = 0maxSelection = 1bindingTime = DESIGN_TIMEallowsAddingVar = truevariants = {Save Score}

<<variability>>name = "check score"minSelection = 0maxSelection = 1bindingTime = DESIGN_TIMEallowsAddingVar = truevariants = {Check Previous Best Score}

<< mandatory >>Animation Loop<< mandatory >>

Initialization

<< mandatory >>Install Game

<< mandatory >>Uninstall Game

<< optional >>Check Previous Best Score

<< alternative_OR >>Play Bowling

<< alternative_OR >>Play Pong<< alternative_OR >>

Play Brickles

<< mandatory , variationPoint >>Play Selected Game

Extension Pointsinitialization_ext_point:animation_ext_point:

<< mandatory >>Exit Game

<< optional >>Save Score

<< mandatory >>Save Game

<< mandatory >>

GameInstaller

<< mandatory >>

GamePlayer

ud: AGM - Use Case Model

<< include >>

<< include >>

<< include >>

<< include >><< include >>

<< include >>

<< extend >><< extend >> << extend >>

<< requires>>

6

Figura 3: Diagrama de classes da LP AGM segundo a Abordagem SMarty (OLIVEIRA

JUNIOR et al., 2010)

A Figura 4 representa o diagrama de atividades do método buildGameBoard(). Um ponto de variação é identificado no DecisionNode logo após a execução dos métodos movableComponents.removeAllElements(); e stationaryComponents.removeAllElements(); de acordo com a diretriz D.8. Assim, é possível decidir quais instruções devem ser executadas na sequência do fluxo. As três possíveis ações são marcadas com o estereótipo <<alternative_OR>> (segundo a diretriz D.10), já que no momento da construção do tabuleiro de um jogo ele pode conter mais de um formato. A verificação de qual fluxo seguir está nas condições de guarda do DecisionNode, de acordo com a diretriz D.8. Uma variabilidade está associada ao DecisionNode que representa um ponto de variação com atributos e valores.

coreA ssets

<< compo nent , variable >>Gam e

<<va riability>>name = "ga me sprite"minS election = 1maxS election = 2bindingT ime = DE SIGN_TIM EallowsAdd in gVar = truevariant s = {core Assets.Mova bleSpr it e,coreA ssets.S tationaryS prite}

<<va riability>>name = "wall"minS election = 0maxS election = 1bindingT ime = DE SIGN_TIM EallowsAdd in gVar = falsevariant s = {core Assets.Wall}

<<va riability>>name = "m ovable sprite"minS election = 1maxS election = 2bindingT ime = DE SIGN_TIM EallowsAdd in gVar = truevariant s = {core Assets.Paddle,coreA ssets.P uck}

<<va riability>>name = "spr ite pair"minS election = 0maxS election = 1bindingT ime = DE SIGN_TIM EallowsAdd in gVar = falsevariant s = {core Assets.SpritePair}

cd: A GM - Core A ssets

<< mand atory >>Men u

(from coreA ssets)

<< mand atory >>Rectangle

(from coreA ssets)

<< mand atory >>Board

(from coreA ssets::Wall)

<< variation Point , mand atory >>GameSp rite

(from coreA ssets)

<< altern ative_OR >>P uck

(from coreA ssets)

<< altern ative_OR >>P addle

(from coreA ssets)

<< altern ative_OR >>Statio nar ySp rite(from coreA ssets)

<< optiona l>>Wall

(from coreA ssets)

<< optiona l >>S prit ePa ir

(from coreA ssets)

<< mand atory >>GameMenu

(from coreA ssets)

<< altern ative_OR , variation Point >>MovableS pr ite

(from coreA ssets)

<< mand atory >>P oint

(from coreA ssets)

<< mand atory >>S ize

(from coreA ssets)

<< mand atory >>V elocity

(from coreA ssets)

second-

boar d#

app#

first-s-

v#

r#

p-

boar d#

7

Figura 4: Diagrama de atividades buildGameBoard() (FIORI; OLIVEIRA JUNIOR, 2012)

A Figura 5 apresenta o diagrama de atividades do método saveGame(). Um ponto de variação é identificado no DecisionNode logo após a instrução String byteString = null; de acordo com a diretriz D.8. Assim, é possível decidir quais instruções devem ser executadas na sequência do fluxo. As três possíveis ações são marcadas com o estereótipo <<alternative_OR>> (segundo a diretriz D.10), já que um produto pode conter mais de um jogo. A verificação de qual fluxo seguir está nas condições de guarda do DecisionNode, de acordo com a diretriz D.8. Uma variabilidade está associada ao DecisionNode que representa um ponto de variação com atributos e valores.

< <v ari ab il i ty >>n ame = "ad d p ie ce s"mi nSe le cti on = 1ma xSe le ctio n = 3b in di ng Ti me = DESIG N_TIM Ea ll owAd di ng Var = trueva ria nts = {}rea l iz es = {}

F im

< < a ltern ati ve _OR > >p uck su pp ly = ne w Pu ck Su pp l y();i nt pa dd le Wi d th = ge tWi dth () / 8;i nt pa dd le Hei gh t = 3;d l = n ew Di vi di ng Li ne (ne w Recta ng le (ne w Po in t(ge tW i dth(), ge tHei gh t()), ne w Si ze (ge tW i dth(), ge tHei gh t())));a dd Sta ti on ary Pie ce (dl );top Pad dl e = n ew Top Pad dl e(n ew Rec tan gl e(n ew Poi nt((ge tWi dth () / 2) - (pa dd le Wi dth / 2) + 15 , (ge tHei gh t() / 10 )), ne w Si ze (pa dd le Wi dth , p ad dl eHe ig ht)));top Pad dl e.sta rtM ovi n g();b ottomPa dd le = ne w Bo tto mPa dd le (ne w Re cta ng le (ne w Po in t((g etW id th() / 2 ) - (p ad dl eW id th / 2 ) + 1 5, ge tHe ig ht()- (ge tHe i gh t() / 1 0)), ne w Si ze (pa dd le W id th , p ad dl e Hei gh t)));b ottomPa dd le .startMo vi ng ();p uck = pu ck su pp ly .g etPuc k(n ew Poi nt((ge tWi dth () / 2), (3 * ge tHe i gh t() / 4)));a dd Mov ab le Pie ce (pu ck);sb = n ew Score Boa rd(n ew Rec ta ng l e(n ew Poi nt(0, 0), ne w Si ze (0, 0)));sb .rese tScore ();a dd Sta ti on ary Pie ce (sb);ce i li ng = ne w Cei li n g(ne w Rec ta ng le (ne w Po i nt(-5, -5), ne w Si ze (ge tW i dth() + 1 0, 5)), tru e);a dd Sta ti on ary Pie ce (cei l in g);f lo or = n ew F l oo r(n ew Re ctan gl e(n ew Poi n t(-5 , g etHei g ht()), n ew Siz e(g etWi d th () + 10 , 5 )), true );a dd Sta ti on ary Pie ce (fl oo r);l eftwal l = ne w L eftWa l l(n ew Rec ta ng l e(n ew Poi nt(-5, -5), ne w Si ze (5,ge tHei gh t() + 10 )), fal se );a dd Sta ti on ary Pie ce (le ftwa ll );ri gh twa ll = n ew Ri gh tW al l (ne w Re cta ng le (ne w Po in t(g etW id th(), -5),ne w Si ze (5, ge tHe i gh t() + 1 0)), fa l se);a dd Sta ti on ary Pie ce (ri g htwal l );a dd Mov ab le Pie ce (to pPa dd le );a dd Mov ab le Pie ce (bo tto mPad dl e);top HitL as t = fa ls e;

g ame Ove r = fal se ;sc ore = 0;

< < a ltern ati ve _OR > >p uck su pp ly = ne w Pu ck Su pp l y();i nt pa dd le Wi d th = ge tWi dth () / 10 ;i nt pa dd le Hei gh t = 2;p ad dl e = n ew Pad dl e(n ew Re ctan gl e(n ew Poi n t((g etW id th () / 2 )- (p ad dl eWid th / 2 ) + 1 5, ge tHe ig ht() - (g etHei g ht() / 10 )),n ew Siz e(p ad dl eW id th, pa dd le Hei gh t)));p ad dl e.sta rtM ovi n g();p uck = pu ck su pp ly .g etPuc k(n ew Poi nt((ge tWi dth () / 2),(ge tHei gh t() / 2)));a dd Mov ab le Pie ce (pu ck);ce i li ng = ne w Cei li n g(ne w Rec ta ng le (ne w Po i nt(-5, -5), ne w Si ze (ge tW i dth() + 1 0, 5)), fa l se);a dd Sta ti on ary Pie ce (cei l in g);f lo or = n ew F l oo r(n ew Re ctan gl e(n ew Poi n t(-5 , g etHei g ht()), n ew Siz e(g etWi d th () + 10 , 5 )), true );a dd Sta ti on ary Pie ce (fl oo r);l eftwal l = ne w L eftWa l l(n ew Rec ta ng l e(n ew Poi nt(-5, -5), ne w Si ze (5,ge tHei gh t() + 10 )), fal se );a dd Sta ti on ary Pie ce (le ftwa ll );ri gh twa ll = n ew Ri gh tW al l (ne w Re cta ng le (ne w Po in t(g etW id th(), -5),ne w Si ze (5, ge tHe i gh t() + 1 0)), fa l se);a dd Sta ti on ary Pie ce (ri g htwal l );b ri ck pi l e = n ew Bric kPi le (ne w Re ctan gl e (ne w Po in t(g etW id th() / 2 0,g etHei gh t() / 20 ), n ew Siz e(g etW id th () - (g etW id th() / 1 0), ge tHei gh t() / 5)));a dd Sta ti on ary Pie ce (bri ckp il e );a dd Mov ab le Pie ce (pa dd le );

< < a ltern ati ve _OR > > en dOfAll ey = ne w End OfAl le y(n ew Re ctan gl e(n ew Poi nt(-5 , -5), ne w Si ze (ge tWi dth () + 10 , 5 )), true ); la ne = ne w La ne (n ew Re ctan gl e(n ew Poi n t(0 , 0 ), n ew Siz e(g etW id th () - 6 0, ge tHei gh t()))); ad dStatio na ryPi ec e(e nd OfAl le y); ad dStatio na ryPi ec e(l an e); ra ck Pin s(); bo wlNu m = 1 ; fra me = 1;

< < va ria tio nPo in t > >

mo va bl eCo mp on en ts .re mo ve Al l Ele men ts();sta ti o na ry Com po ne nts.rem ov eAl lEl eme nts ();

Iníci o

a d: b ui ld Gam eBo ard()

[b oa rd in stan ce of Bowl in gBo ard ]

[b oa rd in stan ce of Bric kl esBo ard ][b oa rd in stan ce of Pon gBoa rd ]

8

Figura 5 : Diagrama de atividades saveGame() da LP AGM segundo a abordagem

SMarty (FIORI; OLIVEIRA JUNIOR, 2012)

Na Figura 6 é representado o diagrama de atividades do método loadGame(). Um ponto de variação é identificado no DecisionNode logo após a execução da instrução byteString = new String(rs.getRecord(i)); de acordo com a diretriz D.8. Assim, é possível decidir quais instruções devem ser executadas na sequência do fluxo. As três possíveis ações são marcadas com o estereótipo <<alternative_OR>> (segundo a diretriz D.10), já que em um mesmo produto pode haver vários jogos a serem carregados e salvos. A verificação de qual fluxo seguir está nas condições de guarda do DecisionNode, de acordo com a diretriz D.8. Uma variabilidade está associada ao DecisionNode que representa um ponto de variação com atributos e valores.

rs.setRecord( 1, byteS tring.getBytes (), 0, byteString.length()) ;setMessage( "Game saved." ); bytes [0] == (byte) 'G'

rs.closeRecordStor e();

numR ecor ds = = 1

byte[] bytes = rs .getRecord(1) ;

rs.addRecor d(byteString.getBytes(), 0, byteS tring.length( ));setMessage( "Game saved." );

numR ecor ds = = 0

Fim

<<variability>>name = "r ecor d stor e"minSelection = 1maxSelection = 3bindingTime = DE SIGN_TIMEallowA ddingV ar = truevariants = {}realizes = {}

<< alternative_OR >>rs = R ecordStore.openRecordStor e("PongGame", tr ue);int numRecords = r s.getN umRecor ds( );byteString = " G" + ((P ongBoard) board) .getSaveData( );

<< alternative_OR >>rs = R ecordStore.openRecordStor e("BowlingGame" , true);int numRecords = r s.getN umRecor ds( );byteString = " G" + ((B owli ngBoard) board).getSaveData();

<< alternative_OR >>rs = R ecordStore.openRecordStor e("Br icklesGame" , true);int numRecords = r s.getN umRecor ds( );byteString = " G" + ((B rickl esBoard) board).getSaveData();

<< variationPoint >>

Str ing byteS tring = null;

board.gameOver()

setMessage( "Sorr y, you can't save this game.");

Início

ad: saveGame( )

[false]

[true]

[board instanceof BowlingB oard]

[board instanceof PongBoar d][board instanceof BricklesB oard]

[true]

[false]

[true]

[false][true] [false]

9

Figura 6 : Diagrama de atividades loadGame() da LP AGM segundo a abordagem

SMarty (FIORI; OLIVEIRA JUNIOR, 2012)

A Figura 7 apresenta o diagrama de componentes da LP AGM. Um componente variante pode ser identificado, Game. Tal componente é marcado como <<variable>>, de acordo com a diretriz D.7, por ser formado por classes que possuem variabilidade.

Fim

setMessage(" No saved games were found!");

!byteS tring.substring(0, 1).equal s("G")

int i = 1

i <= numR ecords

<<variability>>name = " save data"minSelecti on = 1maxS election = 3bindingTime = DESIGN_TIMEal low AddingV ar = truevariants = {}realizes = {}

resume() ;break;

<< al ter nati ve_OR >>((P ongBoard) board).setS aveData(byteString.subs tring(1));

<< al ter nati ve_OR >>((B olwlingBoard) board).setSaveData(byteString.substring(1));

<< al ter nati ve_OR >>((B ricklesBoard) board).setS aveData(byteString.subs tring(1));

<< variationPoint >>

by teS tring.substri ng(0, 1).equals ("G")

by teS tring = new S tr ing(rs .getRecord(i) );

[board instanceof Bri cklesBoard ]

[board instanceof BowlingBoard ]

[board instanceof PongBoard ]

String byteStri ng = null;int numR ecords = rs.getN umR ecords();

Início

ad: loadGame()

[true] [false]

10

Figura 7: Diagrama de componentes da LP AGM segundo a abordagem SMarty

(OLIVEIRA JUNIOR et al., 2010)

3. XML Metadata Interchange (XMI) O XMI é um padrão baseado em XML (Extensible Markup Language) criado pela OMG (Object Management Group) para facilitar o intercâmbio de metadados entre diferentes sistemas como, por exemplo, ferramentas de modelagem baseadas em UML e em MOF (Meta Object Facility).

O XMI tem sido cada vez mais utilizado pela sua capacidade de representar os elementos UML, incluindo diagramas, classes, interfaces, relacionamentos, herança e até mesmo informações peculiares como cores, fontes, formatos, posicionamento, ordem e outros atributos. Algumas ferramentas de modelagem como ArgoUML (TIGRIS, 2012) e Poseidon (GENTLEWARE, 2012) passaram a usar o XMI como padrão para salvar os seus arquivos, não sendo mais necessário exportá-los para outras ferramentas que já trabalhem com o mesmo formato.

Embora XMI seja um padrão amplamente adotado, intercambiar modelos entre ferramentas diferentes pode ser muito difícil. Existem várias versões de implementação do XMI e uma ferramenta geralmente só suporta uma delas. Além disso, cada ferramenta pode estender a UML ou gerar código fora dos padrões, o que causa perda de

<< com ponent >>Serv erM achi ne

<< com ponent >>DB

<< com ponent >>DBSe rve r

<< com ponent >>Platf orm

<< com ponent , var ia ble >>Game

<< com ponent >>Op erat ing System

<< com ponent >>SoundDriver

<< com ponent >>KeyBoard Driv er

<< com ponent >>DisplayDr iver

<< com ponent >>Mo use Drive r

<< com ponent >>DBClient

cd: AGM - Architectur e

11

informação quando o arquivo for importado para outra ferramenta, especialmente informações de layout e disposições dos elementos no diagrama.

Neste artigo são considerados somente exemplos na versão 1.2, por ser a versão gerada pela ferramenta Poseidon (GENTLEWARE, 2012), porém SMartyParser suporta todas as versões de XMI existentes.

A Figura 8 apresenta a estrutura de um arquivo XMI e seus principais elementos. Grande parte do arquivo é omitido por ser muito extenso.

Figura 8: Partes do arquivo XMI extraído da LP AGM a partir da ferramenta Poseidon

(GENTLEWARE, 2012)

Na Figura 8 o elemento UML:Diagram (linha 6) representa um diagrama de classes, como indicado pelo atributo typeInfo = ‘ClassDiagram‘ (linha 13). Cada diagrama contém referências para os seus elementos inseridas na tag UML:Graphelement.Contained (linha 18). Tais elementos foram omitidos deste exemplo para não torná-lo muito extenso. Também é na tag UML:Diagram que estão informações sobre como o diagrama está organizado em relação à disposição dos elementos e demais aspectos visuais.

O elemento UML:Diagram.Owner (linha 19) indica que o diagrama pertence ao elemento UML:Model (linha 27). Ambos referenciados por meio de propriedades xmi.idref (linha 22) e xmi.id (linha 27). O atributo xmi.id é o identificador único de cada objeto e não deve se repetir em um mesmo arquivo XMI. Já o atributo xmi.idref sempre faz referência a um atributo xmi.id, por isso podem existir vários objetos que apontam para um mesmo xmi.id.

12

O UML:Model (linha 27) é um elemento fundamental para o XMI. Nele estão contidos todos os elementos do modelo UML hierarquicamente organizados no elemento UML:Namespace.ownedElement (linha 29). O elemento UML:Stereotype (linha 30) é um exemplo disso. Os demais elementos também foram omitidos.

A Tabela 1 apresenta elementos do XMI com maior importância para LP e a abordagem SMarty.

Tabela 1: Elementos XMI importantes para LP e a abordagem SMarty

Elemento XMI Descrição

UML:Diagram Um diagrama (useCaseDiagram, classDiagram etc).

UML:Stereotype Um estereótipo.

UML:Comment Uma nota (comentário).

UML:Actor Um ator.

UML:UseCase Um caso de uso.

UML:Interface Uma interface.

UML:Action Uma ação.

UML:Component Um componente.

UML:Dependency Uma dependência.

UML2:Activity Uma atividade.

UML2:DecisionNode Um nó de decisão.

4. O SMartyParser para Modelos UML de LP O SMartyParser, cuja construção foi baseada no framework Open Core (SDMETRICS, 2011). Ele possui um núcleo de artefatos para analisar arquivos XMI e extrair os elementos de modelos UML.

O processamento do arquivo XMI é controlado por dois outros arquivos baseados em XML, o Metamodel Definition File (MDF) e o XMI Transformation File (XTF). Para cada MDF pode haver vários XTF, um para cada versão do XMI ou particularidade de determinada ferramenta. Tais arquivos são facilmente customizáveis para atender as necessidades de cada modelo específico.

O MDF define o metamodelo dos elementos conhecidos da UML. Cada elemento tem seus atributos, relacionamentos, tipo, meta-classe, etc., porém não é necessário que contenha toda a especificação UML, mas somente o que for relevante para cada caso.

Na Figura 9 é apresentada a definição do metamodelo do elemento stereotype. Há dois atributos de dados, representados por type=”data” (linhas 206 e 207), que armazenam o id e o nome do estereótipo, respectivamente. O atributo context (linha 205) é do tipo referência cruzada (type=”ref”) e referencia o elemento pai (parent) dentro do modelo UML. O atributo extendedelements (linha 208) é similar ao anterior, porém pode conter mais de uma referência (multiplicity=”any”) e referencia os elementos que estendem esse estereótipo.

13

Figura 9: Exemplo do metamodelo do elemento stereotype da UML

O XMI Transformation File define como os dados serão extraídos do arquivo XMI. Nele é feito um mapeamento dos metamodelos UML de acordo com as especificações do XMI. O arquivo de transformação deve variar de acordo com a versão do XMI a ser lido e ainda pode variar dependendo da ferramenta de modelagem que exportou os dados.

Na Figura 10 é possível ver como é mapeada a transformação do elemento stereotype da UML 1.4 e XMI 1.2. O xmitransformation (linha 462) contém todas as informações necessárias para extrair os dados de um UML:Stereotype (Tabela 1) de um modelo UML.

O atributo modelelement (linha 462) indica o tipo de elemento ao qual aquela regra se assimila e deve coincidir com o tipo declarado no MetaModel Definition File. O atributo xmipattern (linha 462) corresponde ao padrão desse elemento no arquivo XMI, como detalhado na Tabela 1.

Cada trigger mapeia como os atributos de stereotype serão extraídos. O atributo name declara qual é o atributo a ser recuperado e seu valor deve corresponder ao declarado no arquivo de metamodelos. O type diz como o valor será recuperado e o attr diz de onde virá o valor. Pode haver dois ou mais xmitransformation para um mesmo elemento UML, bastando pra isso variar o xmipattern, para garantir compatibilidade com o XMI gerado por ferramentas diferentes.

Figura 10: Exemplo de XMI Transformation File mapeando como extrair o elemento

UML:Stereotype

A Figura 11 mostra um trecho de um arquivo XMI que representa o elemento UML:Stereotype como proposto pelos arquivos anteriores. Tal elemento é um variationPoint.

14

Figura 11: Trecho de código de um arquivo XMI representando o elemento Stereotype

da UML

Na Figura 12 é apresentado o diagrama de classes do SMartyParser e sua principal classe ProductLineModelParser.

Figura 12: Diagrama de classes do SMartyParser.

A classe MetaModel representa o arquivo MDF e MetaModelElement representa cada elemento do metamodelo (Figura 9). A classe Model representa o elemento base do XMI (UML:Model) onde estão todos os elementos da modelagem representados pela classe ModelElement. A classe XMITransformations representa o arquivo XTF, XMITransformation corresponde a cada elemento de transformação e Trigger a suas triggers, como visto na Figura 10. A classe ProductLineModelParser, que é a principal classe SMartyParser, implementa as interfaces IProductLineUMLModelParser e IProductLineVariabilityParser. A primeira contém os métodos necessários para a

XMITrigger

XMITransformati on

MetaModelElement

XMITransformati ons

XMIReader

MetaModel

Model ProductLi neModelP arser

<< interface >>IProductLineVariabilityParser

<< interface >>IProductLineU MLModel Parser

ModelE lem ent

cd: SMarty Parser - Diagrama de Classe s

*

1

1

*

1

*

1

*

1

*

*

*

1

*

1

1

15

manipulação dos elementos base de uma UML (classes, interfaces, casos de uso, etc) e a segunda contém os métodos específicos para o tratamento de variabilidade em LP. A Tabela 2 descreve os principais métodos de cada uma das interfaces.

Na Tabela 2 são apresentados os principais métodos definidos nas interfaces IProductLineUMLModelParser e IProductLineVariabilityParser e implementados pela classe ProductLineModelParser.

Tabela 2: Principais métodos definidos nas interfaces IProductLineUMLModelParser e

IProductLineVariabilityParser

Método Descrição

IProductLineUMLModelParser

getAllDiagrams Obtém todos os diagramas presentes na modelagem.

getStructureDiagrams Obtém todos os diagramas estruturais (classe, componente e etc).

getBehaviourDiagrams Obtém todos os diagramas de comportamento (atividade, casos de uso e etc).

getInteractionDiagrams Obtém todos os diagramas de interação (sequência, comunicação e etc).

getElementsByDiagram Dado um diagrama, obtém todos os seus elementos.

getElementsByDiagramByType Dado um diagrama, obtém todos os seus elementos, considerando um tipo específico.

getElementByID Obtém um elemento específico, cujo ID (xmi.id) é passado como referência.

getElementsByType Obtém todos os elementos de um determinado tipo (classe, componente, interface, caso de uso e etc).

IProductLineVariabilityParser

getAllVariabilities Obtém todas as variabilidades.

getAllVariationPoints Obtém todos os pontos de variação.

getAllVariables Obtém todos os elementos variáveis (componentes e partições de atividades).

getOptionalVariants Obtém todas as variantes opcionais (<<optional>>)

getMandatoryVariants Obtém todas as variantes obrigatórias (<<mandatory>>).

getInclusiveVariants Obtém todas as variantes inclusivas (<<alternative_OR>>).

getExclusiveVariants Obtém todas as variantes exclusivas (<<alternative_XOR>>).

getVariabilityByName Obtém uma variabilidade baseada em seu nome (atributo name de <<variability>>).

getVariantsOfAVariability Obtém todas as variantes de uma variabilidade.

getVariationPointOfAVariant Obtém o ponto de variação de uma variante.

getChildrenVariabilities Obtém todas as variabilidades filhas de uma determinada variabilidade.

getVariantRequiredElements Obtém todas as variantes que possuem dependência entre si (<<required>>).

getVariantMutexElements Obtém todas as variantes que são mutuamente exclusivas (<<mutex>>).

16

5. Exemplo de Aplicação do SMartyParser à LP AGM Nesta seção são apresentados os resultados do SMartyParser aplicado à LP AGM (Seção 3). Embora os diagramas tenham sido apresentados separadamente, todos fazem parte de uma mesma modelagem UML e formam apenas um arquivo XMI.

O Quadro 1 mostra um exemplo de como o SMartyParser pode ser utilizado. É necessário instanciar a classe ProductLineModelParser (linha 1) passando como parâmetro os arquivos XMI, metamodelo UML e transformação do XMI, como visto na Seção 4. O método getAllVariabilities() (linha 2) retorna todos os ModelElement correspondentes à variabilidade e os armazena em vars. Um laço (linha 3) percorre todos os elementos e imprime o nome de cada um na saída padrão do programa. Na linha 4 tem-se um exemplo dos dados de saída.

Quadro 1: Exemplo de uso do SMartyParser aplicado à LP AGM

1)

ProductLineModelParser smartyParser = new ProductLineModelParser ("AGM.xmi","metamodel.xml","xmiTrans1_2.xml");

2)

List<ModelElement> vars = smartyParser.getAllVariabilities();

3)

for (ModelElement element : vars) {

System.out.println(element.getName());

}

4)

sprite pair

movable sprite

wall

game sprite

...

17

A Tabela 2 apresenta, de forma resumida, o resultado da execução dos demais métodos do SMartyParser aplicados a LP AGM e todos os seus diagramas.

Tabela 2: Dados retornados pelos principais métodos da classe ProductLineModelParser

Método Dados retornados

getBehaviourDiagrams() AGM - Use Case Model, saveGame(), loadGame(), buildGameBoard().

getStructureDiagrams() AGM - Core Assets, AGM - Architecture

getElementsByType(type = usecase)

Save Game, Save Score, Exit Game, Play Brickles, Play Pong, Play Bowling, Check Previous Best Score…

getElementsByType(type = class)

GameMenu, GameSprite, Menu, MovableSprite, Paddle, Point, Rectangle, Size, SpritePair, StationarySprite...

getElementsByType(type = component)

Game, MouseDriver, DisplayDriver, KeyBoardDriver, SoundDriver, Operating System, DBClient, Platform…

getElementsByType(type = actor)

GamePlayer e GameInstaller.

getAllVariabilities()

sprite pair, movable sprite, wall, game sprite, check score, save score, play game, brickles wall, pong wall…

getAllVariationPoints

GameMenu, GameSprite, Play Selected Game, Wall, Menu, StationarySprite, MovableSprite, Paddle e Board.

getOptionalVariants

PuckSupply, Save Score, Check Previous Best Score, SpritePair e Wall.

getMandatoryVariants

GameMenu, GameSprite, Play Selected Game, Point, Velocity, GamePlayer, Initialization, Size, Exit Game…

getInclusiveVariants()

Brickles, PongGameMenu, TopPaddle, Brick, BowlingGameMenu, RackOfPins, BottomPaddle...

18

A Figura 13 apresenta um exemplo hipotético de tela de uma ferramenta que pode utilizar o SMartyParser para visualização dos resultados obtidos da análise do XMI em forma de árvore. Os elementos mais internos são variantes, os superiores são ponto de variação e variabilidade.

Figura 13: Exemplo hipotético de tela com dados obtidos a partir do SMartyParser

6. Trabalhos Relacionados Muitos são os parsers XMI encontrados na literatura ou em projetos de pesquisa de software livre, porém, nenhum trata especificamente LPs, tampouco variabilidade. A maior parte se preocupa apenas em gerar código fonte em determinada linguagem ou framework. Além disso, não suportam todas as versões do XMI e muito menos tratam as particularidades entre as ferramentas de modelagem e seus formatos proprietários.

O EMF (Eclipse Modeling Framework) (ECLIPSE, 2012) é uma ferramenta de modelagem UML de código fonte aberto. Apesar de completo e robusto, o EMF não é comumente usado para analisar arquivos XMI, acredita-se que pela complexidade na implantação. Geralmente é usado para transformar modelos UML em código fonte para a linguagem Java.

19

O Netbeans XMI Writer (ORACLE, 2012) é uma ferramenta de código fonte aberto para leitura e escrita de XMI muito difundida no mercado. Atualmente, importantes softwares como o ArgoUML e Poseidon a utilizam como base para importar e exportar arquivos XMI. Porém, ela só suporta a versão 1.2 do XMI e foi descontinuada e removida das versões mais recentes do Netbeans. Um novo módulo para modelagem UML (EidosUML) está sendo discutido pela comunidade que mantém a ferramenta, porém ainda sem previsão de lançamento.

Petry (2008) criou um parser XMI para gerar código fonte na linguagem Python, porém, só são processadas classes, atributos e associações. O parser gera código fonte para o framework Django e só suporta arquivos XMI gerados pela ferramenta ArgoUML. Nenhum arquivo metamodelo ou de transformação é usado, então, todas as customizações devem ser feitas diretamente no código fonte, dificultando a adequação para outras ferramentas de modelagem.

O SMartyParser analisa variabilidade em LP segundo a abordagem SMarty para diagramas de classes, componentes, casos de uso e atividades. Além disso, é compatível com todas as versões do XMI e trata com facilidade as particularidades entre os arquivos gerados pelas ferramentas e seus formatos proprietários. Para tanto, bastam simples adaptações no arquivo de transformações do XMI, que já está adaptado para as ferramentas mais populares incluindo Rose, Together, Enterprise Architect, ArgoUML, Poseidon, MagicDraw e Ideogramic UML.

7. Conclusão e Trabalhos Futuros Este trabalho apresentou um parser XMI para modelos UML de LP com o objetivo de facilitar a análise de variabilidade segundo a abordagem SMarty. O framework Open Core foi estendido para LP e variabilidade. Exemplos de aplicação foram criados para ilustrar o funcionamento de tal parser.

Vários trabalhos foram encontrados em projetos de código fonte aberto e na literatura, porém nenhum trata efetivamente de LP. Cada trabalho contribuiu de forma indireta, porém, somente o Open Core se mostrou flexível o suficiente e de fácil customização.

O SMartyParser criou novos elementos no Metamodel Definition File e várias modificações no XMI Transformation File para garantir compatibilidade com o gerenciamento de variabilidade proposto pela abordagem SMarty, além se suportar arquivo XMI gerado pelas mais diversas ferramentas de modelagem existentes no mercado.

Este trabalho limita-se em analisar arquivos XMI e extrair informações sobre LP e variabilidade segundo a abordagem SMarty. Todas as demais características dos elementos UML foram descartadas por não fazerem parte do objetivo principal, podendo ser tratadas em trabalhos futuros.

Como trabalhos futuros indica-se: (i) projeto e implementação de um ambiente experimental gráfico de avaliação de LP com base na abordagem SMarty, o método SystEM-PLA (OLIVEIRA JUNIOR et al., 2011) e métricas para LP (OLIVEIRA JUNIOR et al., 2008, OLIVEIRA JUNIOR et al., 2010b); (ii) análise de métricas de modelo UML a fim de identificar problemas na modelagem e na abordagem de LP; (iii) proposta e validação experimental de métricas para arquitetura de LP; e (iv) realização de experimentos e análises de trade-off para priorizar atributos de qualidade de LP.

20

Referências bibliográficas CHEN, L.; Babar, M. A.; ALI, N. “Variability Management in Software Product Lines: a Systematic Review”. In Proceedings of the Software Product Line Conference, Pittsburg, PA, USA: Carnegie Mellon University, 2009, p. 81-90.

ECLIPSE Eclipse Modeling Framework. 2012. Disponível em http://www.eclipse.org/modeling/emf/ (Acessado em 06/03/2012).

GENTLEWARE Model to Business. 2012. Disponível em http://www.gentleware.com/new-poseidon-for-uml-8-0.html (Acessado em 10/01/2012).

FIORI, D. R.; OLIVEIRA JUNIOR, E. A. “Gerenciamento de Variabilidade de Linha de Produto de Software em Diagrama de Atividades da UML”. 2012. Artigo científico (Curso de Especialização em Desenvolvimento de Sistemas para Web) – Departamento de Informática, Universidade Estadual de Maringá, Maringá, 2012.

LINDEN, F. J. D.; SCHMID, K.; ROMMES, E. “Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering”. Secaucus, NJ, USA, Springer-Verlag New York, Inc., 2007.

OLIVEIRA JUNIOR, E. A. “SystEM-PLA: um Método Sistemático para Avaliação de Arquitetura de Linha de Produto de Software baseada em UML”. 2010. Tese (Doutorado em Ciências de Computação e Matemática Computacional) - Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo, São Carlos, 2010.

OLIVEIRA JUNIOR, E. A. ; GIMENES, Itana Maria de Souza ; MALDONADO, José Carlos . Avaliação Sistemática de Arquitetura de Linha de Produto de Software. In: Conferencia Latinoamericana de Informática, 2011, Quito. Analles de la Conferencia Latinoamericana de Informática, 2011. v. 1. p. 77-92.

OLIVEIRA JUNIOR, E. A. ; GIMENES, Itana Maria de Souza ; MALDONADO, José Carlos. A Metric Suite to Support Software Product Line Architecture Evaluation. In: XXXIV Conferência Latinoamericana de Informática (CLEI), 2008, Santa Fe. Anais da XXXIV Conferência Latinoamericana de Informática (CLEI), 2008. p. 489-498.

OLIVEIRA JUNIOR, E. A. ; GIMENES, Itana Maria de Souza ; MALDONADO, José Carlos . Empirical Validation of Complexity and Extensibility Metrics for Software Product Line Architectures. In: Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software, 2010b, Salvador. Proceedings of the Brazilian Symposium on Components, Software Architecture and Software Reuse, 2010. v. 1. p. 31-40.

OMG OMG Formally Released Versions Of Xmi. 2011. Disponível em http://www.omg.org/spec/XMI/ (Acessado em 22/11/2011).

ORACLE Netbeans EidosUML. 2012. Disponível em http://wiki.netbeans.org/EidosUML (Acessado em 06/03/2012).

PETRY, M. D. “UML2Django: Gerador de Código para Framework Web MVC”. 2008. Monografia (Curso de Bacharelado em Ciência da Computação) – Departamento de Informática, Universidade de Caxias do Sul, Caxias do Sul, 2008.

SDMETRICS The Software Design Metrics tool for the UML. 2011. Disponível em http://www.sdmetrics.com/ (Acessado em 03/08/2011).

SEI A Framework for Software Product Line Practice. 2010b. Disponível em http://www.sei.cmu.edu/productlines (Acessado em 24/02/2012).

SEI Arcade Game Maker Pedagogical Product Line. 2010c. Disponível em http://www.sei.cmu.edu/productlines/ppl (Acessado em 24/02/2012).

SEI Product Line Hall Of Fame. 2010a. Disponível em http://www.splc.net/fame.html (Acessado em 20/02/2012).

TIGRIS Open Source Software Engineering Tools. 2012. Disponível em http://argouml.tigris.org/ (Acessado em 10/01/2012).

21

WEISS, D. M.; LAI, C. T. R. “Software Product-Line Engineering: a Family-Based Software Development Process”. Boston, MA, USA. Addison-Wesley Longman Publishing CO., INC., 1999.