Using Graph Grammars to Develop Embedded Systems Based on UML Models

Utilizando Gramatica de Grafos para o Desenvolvimento deSistemas Embarcados Baseado em Modelos UML∗

Nıcolas N. Bisi, Vinıcius Pazzini,Luciana Foss, Simone A. C. Cavalheiro, Lisane B. de Brisolara

1Centro de Desenvolvimento Tecnologico – Universidade Federal de Pelotas (UFPEL)Caixa Postal 354 – 96010-900 – Pelotas, RS - Brasil

{nnbisi,vspazzini,lfoss,simone.costa,lisane}@inf.ufpel.edu.br

Abstract. UML and Simulink models are widely used in embedded systems de-sign. UML offers proper high-level abstractions to software-oriented modelsspecification, while Simulink allows a better dataflow description. The featu-res of each model motivates the development of proposals unifying and creatingmappings between them. This article proposes a formal definition for a transla-tion from UML to Simulink model, previously proposed, using the graph gram-mar formalism. This mapping was previously described in natural language anda prototype implemented in Java. The formal definition using graph grammarsnot only eliminated possible ambiguities in the mapping, but also allowed theuse of Groove to automate the translation.

Resumo. Modelos UML e Simulink sao amplamente utilizados no projeto e de-senvolvimento de sistemas embarcados. UML fornece abstracoes de alto nıveladequadas para a modelagem de software orientado a modelos, ja Simulinkpermite uma melhor descricao de fluxo de dados. As especificidades de cadamodelo motivam propostas de unificacao e mapeamento entre eles. Este artigopropoe uma definicao formal para uma traducao de modelos UML em mode-los Simulink, previamente proposta, utilizando o formalismo de gramatica degrafos. Esta traducao foi previamente definida em linguagem natural e umprototipo implementado em Java. A definicao formal utilizando gramatica degrafos nao so eliminou possıveis ambiguidades no mapeamento, como tambempermitiu o uso da ferramenta Groove para a automatizacao da traducao.

1. IntroducaoTecnicas que partem de modelos de alto nıvel de abstracao sao requeridas para

lidar com a complexidade encontrada nas novas geracoes de sistemas embarcados, sendocruciais para o sucesso do projeto. Uma grande reducao do esforco no desenvolvimentode sistemas embarcados pode ser obtida com o uso de modelos, quando o codigo de umalinguagem de programacao e gerado automaticamente a partir desses modelos. Porem,ferramentas disponıveis para modelagem e geracao de codigo normalmente sao dependen-tes de domınio e o software embarcado normalmente possui comportamento heterogeneo,requerendo suporte a multiplos modelos de computacao.

Na area de engenharia de software, UML [OMG 2010] e uma das linguagens maisutilizadas, por fornecer abstracoes de alto nıvel adequadas para a modelagem de software

∗Trabalho financiado pelo CNPq e FAPERGS

orientado a modelos. Ja na area de sistemas embarcados um modelo largamente adotadopor engenheiros de hardware e de controle e o de blocos Simulink [Mathworks 2011].Uma comparacao feita entre as linguagens UML e modelos Simulink mostra que UML ebaseada em eventos e nao e adequada para modelar sistemas dataflow. Por outro lado, osmodelos Simulink suportam dataflow e geracao de codigo, porem eles provem abstracoesde mais baixo nıvel, quando comparados a UML. Conclui-se que tanto UML como Simu-link possuem vantagens e desvantagens para a sua adocao, o que motiva a integracao deambas as linguagens em um unico fluxo de projeto [Brisolara et al. 2008].

Neste sentido, um mapeamento de modelos UML para modelos Simulink foi pro-posto por Brisolara em [Brisolara et al. 2008], com o objetivo de permitir que desen-volvedores utilizem UML como linguagem de modelagem e ao mesmo tempo se be-neficiem com as facilidades de Simulink para simulacao e geracao de codigo. No en-tanto, a definicao deste mapeamento foi feita em linguagem natural e um prototipo foiimplementado com Java. Este artigo propoe uma definicao formal para esta traducaopreviamente proposta, utilizando o formalismo de gramatica de grafos [Rozenberg 1997,Ehrig et al. 1999]. A definicao formal utilizando gramatica de grafos nao so eliminoupossıveis ambiguidades na definicao em linguagem natural, como tambem permitiu o usoda ferramenta Groove [Rensink 2004] para a automatizacao da traducao.

A utilizacao de gramatica de grafos se mostra adequada para especificar lingua-gens visuais, como e o caso das linguagens UML e Simulink, por especificar um modeloa partir de regras de transformacao de grafos. Uma gramatica de grafos e definida por umgrafo inicial, que modela o estado inicial da especificacao, um grafo tipo, o qual limita osdiferentes tipos de vertices e arcos da especificacao e um conjunto de regras, que descre-vem as possıveis mudancas de estados que podem ocorrer. Na especificacao da traducaoem gramatica de grafos, uma representacao de UML como grafo define o estado inicial domapeamento e o conjunto de regras definiu formalmente o mapeamento proposto. O graforesultante da transformacao, obtido apos a aplicacao das regras ao grafo UML, constituiuma representacao de grafo para o correspondente modelo Simulink.

O restante deste artigo esta organizado como segue. A secao 2 descreve o forma-lismo de gramatica de grafos. A secao 3 define formalmente a conversao da linguagemUML para a linguagem Simulink. A secao 4 apresenta as conclusoes finais.

2. Gramatica de grafos

Nesta secao sao apresentados os principais conceitos de gramatica de grafos, se-guindo a abordagem Single Pushout [Rozenberg 1997]. Gramatica de grafos e uma lin-guagem de especificacao formal na qual grafos sao usados para representar estados deum sistema e mudancas no estado do sistema sao descritas por regras (mapeamento entregrafos).

Pesquisas na area de gramaticas de grafos iniciaram nos anos 70[Ehrig et al. 1973], e metodos, tecnicas e resultados nesta area ja foram estudadose aplicados em uma grande variedade de campos da Informatica, como teoria delinguagens formais, reconhecimento e geracao de imagens, construcao de compiladores,engenharia de software, modelagem de sistemas concorrentes e distribuıdos, projeto eteoria de bancos de dados, entre outros [Ehrig et al. 1999].

2.1. Sintaxe de gramatica de grafos

Os conceitos basicos desta abordagem sao os de grafo e morfismo de grafos. Gra-fos sao estruturas compostas por vertices e arestas, que permitem descrever situacoescomplexas de forma visual, compacta, clara e intuitiva.

Um grafo G = (VG, AG, LVG, LAG, oG, dG, lV , lA) consiste de um conjunto devertices VG, um conjunto de arestas AG, um conjunto de rotulos de vertices LVG, umconjunto de rotulos de arestas LAG, duas funcoes totais, oG, dG : AG → VG, denominadasfuncoes origem e destino, as quais associam cada aresta ao seu vertice origem e destino,respectivamente, e duas funcoes totais lV : VG → LVG, lA : AG → LAG que rotulamvertices e arestas.

Na abordagem usada neste artigo, atributos de algum tipo de dado podem serassociados aos vertices. Esse tipo de grafo, chamado de grafo com atributos, e definidocomo um grafo cujos conjuntos VG e AG sao compostos de dois subconjuntos disjuntos:VG = V rG]V aG, onde V rG e um conjunto de vertices regulares e V aG e um conjunto devertices de atributos; e AG = ArG ] AaG, onde ArG e um conjunto de arestas regularese AaG e um conjunto de arestas de atributos. Os vertices de atributos sao rotulados porconstantes de algum tipo de dado, por exemplo constantes numericas ou literais, e asarestas de atributos conectam vertices regulares a vertices de atributos. Deste modo, umgrafo com atributos G′ = (G,AlgG) e definido por um grafo G mais uma algebra AlgG, aqual define os rotulos dos vertices V aG, isto e, AlgG ⊆ LVG e para todo v ∈ V aG, tem-seque lV (v) ∈ AlgG.

A Figura 1 exibe um exemplo de grafo, onde os vertices sao representados porretangulos e as arestas por setas conectando os vertices de origem aos vertices de destino.Os rotulos dos vertices regulares estao inscritos nos retangulos e os das arestas regularessao escritos sobre as setas. Os atributos, tanto dos vertices quanto das arestas, nao sao re-presentados explicitamente, eles aparecem inscritos nos vertices regulares aos quais estaoassociados. Por exemplo, o vertice regular com rotulo IO (no canto esquerdo superior daFigura 1) tem o atributo id = “IODevice”, onde id e uma aresta de atributo que conecta IOao vertice de atributo “IODevice”.

SASchedResid = ”T3”

get

set

SFunctionid = ”calc”

set


set

SAengineid = ”CPU1”


varid = ”b”

varid = ”y”

get

varid = ”r1”

setIOgetIO

libid = ”mult”

varid = ”r2”

IOid = ”IODevice”


SFunctionid = ”dec”

getIO


varid = ”r3”

IOid = ”Sensor”


varid = ”a”

varid = ”x”


varid = ”r4”


get

src

result

result

tgt

arg

in

in

arg

result

src

arg

tgt

in

src

in

in

arg

arg

result

result

src

src

arg

tgt

src

tgt

tgt

tgt

src

arg

argin

result

in

tgt

arg

result

in

src

src

result

arg

resultin

tgt

result

arg

tgt

result

Figura 1. Exemplo de grafo.

Um morfismo f : L → R de um grafo L para um grafo R e definido por tresfuncoes parciais, uma funcao fv : VL → VR que mapeia vertices do grafo L em verticesno grafo R, tal que para todo v ∈ V rL.fv(v) ∈ V rR e para todo v ∈ V aL.fv(v) ∈V aR; uma funcao fa : AL → AR que mapeia as arestas do grafo L em arestas no grafoR, tal que para todo a ∈ ArL.fa(a) ∈ ArR e para todo a ∈ AaL.fa(a) ∈ AaR; euma funcao fl : LVL → LVR, que faz o mapeamento dos rotulos entre os respectivosgrafos, tal que para todo x ∈ AlgL.fl(x) ∈ AlgR. Estas funcoes devem obedecer algumasregras de compatibilidade. Compatibilidade aqui significa que cada vez que um arco dografo L for mapeado em um arco do grafo R, entao, em relacao ao arcos mapeados, overtice origem (respectivamente destino) do arco de L deve ser mapeado para o verticeorigem (respectivamente destino) do arco em R. Alem disso, o mapeamento dos rotulostambem deve ser compatıvel, isto e, se um vertice (ou arco) de L e mapeado em umvertice (ou arco) de R, seu rotulo deve ser mapeado para o rotulo do vertice (ou arco) emR. Um morfismo e total/injetivo se todas as funcoes que o definem sao totais/injetivas,respectivamente.

Regras especificam possıveis mudancas de estado em uma especificacao. Umaregra r : L → R em gramatica de grafos consiste de dois grafos, L (lado esquerdo) e R(lado direito), e um morfismo de grafos entre eles. O morfismo especifica elementos quedevem ser preservados, deletados ou criados pela aplicacao da regra. Regras podem serenriquecidas com NACs (Condicoes de Aplicacao Negativas).

Condicoes de aplicacao negativas (NACs, do ingles negative application conditi-ons) restringem a utilizacao de uma regra ao afirmar que uma determinada estrutura naopode estar presente no grafo estado. Dada uma regra r : L → R, condicoes de aplicacaonegativas sao conjuntos de morfismos totais e injetores que partem do lado esquerdo daregra, denotado por Mor(L). Cada morfismo l ∈Mor(L) e chamado de restricao.

SASchedRes

SAengine SASchedRes

set

varX

CPUCOMMUNid = ”Intra”

var

oC

arg

src

in tgt

in

!=

l r

SASchedRes

SAengine SASchedRes

set

var

in

in

tgt

src

arg

!=

SASchedRes

SAengine SASchedRes

var

X


in

in

oSarg

vardC

!=

(a) Morfismos l e r

SASchedRes

SAengine SASchedRes

set

var

XX



var

arg

!=

arg

in

tgt

var

dC

src

oS

in

oC

(b) Sintaxe de uma regra doGroove

Figura 2. Exemplo de regra

A Figura 2 mostra um exemplo de regra com condicao negativa de aplicacao. AFigura 2(a) detalha o morfismo l, que mapeia o lado esquerdo da regra para um grafo queinclui os elementos proibidos, e o morfismo r, que descreve a transformacao ocorrida naaplicacao da regra. Os elementos que nao podem estar presentes para habilitar a aplicacaodesta regra sao os vertices CPUCOMMUN e X e os arcos var e oC que nao estao na ima-gem de l. Os elementos que devem ser estar presentes para habilita-la, sao os vertices set,

SASchedRes, var, SAengine, SASchedRes e os arcos src, arg, in e !=, sendo que, dentreestes, o vertice set e os arcos que incidem nele sao deletados e os demais elementos saopreservados. Os elementos criados pela regra sao os vertices X e CPUCOMMUN, e os ar-cos dC, oS, var e arg que nao estao na pre-imagem de r. No simulador do Groove, e usadauma sintaxe mais compacta para as regras. Cada regra e representada por um unico grafo,com notacoes diferentes para cada tipo de elemento. A Figura 2(b) apresenta a sintaxe daregra da Figura 2(a) no Groove, onde os elementos criados sao representados por linhasespessas e contınuas, os elementos preservados sao representados por linhas simples econtınuas, os elementos deletados sao representados por linhas simples e tracejadas e oselementos proibidos (NACs) por linhas espessas e tracejadas.

Uma gramatica de grafos consiste dos seguintes componentes:

• Um grafo tipo que representa os diferentes tipos de itens que podem ocorrer emuma especificacao;• Um grafo inicial que modela o estado inicial de uma especificacao;• Um conjunto de regras que definem as possibilidades de mudancas nos estados de

uma especificacao.

Assim, uma gramatica de grafos com NACs e uma tupla GNN = (T,G0, R), onde T eum grafo tipo, G0 e um grafo tipado em T e R e um conjunto de regras com NACs.

2.2. Semantica da gramatica de grafos

Uma regra, sem NACs, e possıvel de ser aplicada se todos os componentes dografo esquerdo da regra estao presentes no grafo (estado), i.e., se houver um morfismototal de grafos do lado esquerdo da regra para o grafo. Este morfismo e denominadomatch. O grafo resultante da aplicacao de uma regra r : LT → RT a um grafo (estado) eobtido a partir das seguintes etapas:

• Adiciona-se ao grafo tudo que foi criado pela regra, ou seja, estruturas ausentesem L e presentes em R (que nao tem pre-imagem em L);• Deleta-se do grafo tudo que deve ser deletado pela regra, ou seja, estruturas pre-

sentes em L e nao mapeados em R;• Deleta-se arcos pendentes. Este passo e necessario no caso de haverem arcos

conectados a vertices deletados no passo anterior. Como o resultado da aplicacaode uma regra deve ser um grafo, este arcos devem ser deletados tambem.

Uma regra com NACs pode de ser aplicada ao grafo GT se ha um match m :LT → GT que satisfaz todas as NACs da regra. Um match m satisfaz todas as NACsse ele satisfaz cada uma das restricoes. Para m satisfazer um restricao l : LT → NT ,nao pode ser possıvel encontrar os elementos proibidos pela restricao l no contexto de m,isto e, nao pode existir um mapeamento de n : NT → GT que torne a seguinte igualdadeverdadeira n◦l = m. O resultado da aplicacao de um regra com NACs e o mesmo descritoanteriormente (para regras sem NACs).

3. UML para Simulink

A especificacao da traducao dos diagramas UML para um diagrama de blocos Si-mulink foi definida atraves de uma gramatica de grafos. Esta traducao utiliza diagramas

UML de sequencia e de implantacao. O diagrama de implantacao e utilizado para de-monstrar a organizacao do hardware e a ligacao do software com os dispositivos fısicos.Ele tambem modela a visao estatica da implantacao de um sistema entre seus nos fısicose seus relacionamentos, especificando os detalhes referentes a construcao. O diagramade sequencia mostra as interacoes entre objetos em uma sequencia temporal, facilitandoa visualizacao da dinamica do sistema, pois enfatiza o ordenamento das operacoes. Odiagrama de sequencia UML utilizado foi adaptado e, com isso, teve seu uso mais res-trito, onde a comunicacao entre objetos thread e entre objetos thread e IO (dispositivo deentrada e saıda) so e possıvel atraves da chamada de metodos get e set. Os objetos podemainda chamar metodos proprios ou metodos do objeto especial Plataforma. Este ultimoobjeto representa uma biblioteca de operacoes pre-definidas.

O processo de traducao de UML para Simulink, ilustrado na Figura 3, comecacom a construcao do grafo inicial da gramatica a partir dos diagramas de sequencia eimplantacao. Este grafo e descrito na linguagem interpretada pela ferramenta GROOVE,que o transforma, aplicando as regras definidas, em um grafo que representa um modeloSimulink. O grafo final e entao traduzido para a linguagem de entrada do Simulink. Esteprocesso ainda e semi-automatico, onde apenas a transformacao entre o grafo inicial efinal e automatizada, com o uso da ferramenta GROOVE.

Grafo Inicial SimulinkUML Grafo

Final

Transformação GROOVE

Figura 3. Processo de transformacao de diagrams UML para modelos Simulink

Na Figura 4 temos exemplos de diagramas de implantacao e de sequencia. O dia-grama de implantacao, descrito na parte superior da figura, descreve um sistema de hard-ware com duas CPUs (CPU1 e CPU2) interligadas por um barramento (bus). Alem disso,tambem esta definido como as tres threads, T1, T2 e T3, serao alocadas nestas CPUs. Porquestoes de simplificacao, os tres diagramas de sequencia, descrevendo o comportamentode cada uma das threads, foram representados no unico diagrama apresentado na parteinferior da figura. As chamadas dos metodos main task() realizadas pelo objeto Schedu-ler indicam o inicio da execucao de cada uma das threads. As setas entre as threads ouentre uma thread e um dispositivo de entrada e saıda (Sensor ou IODevice), representamas chamadas de metodos get e set. As demais setas, representam as chamadas de metodosdas proprias threads ou dos metodos do objeto Plataforma.

Simulink e uma ferramenta de modelagem, simulacao e analise de sistemasdinamicos baseado na representacao por esquemas de blocos. Ele fornece um ambientegrafico interativo e um conjunto personalizavel de bibliotecas de blocos que permitemprojetar, simular, implementar e testar uma variedade de diferentes sistemas com variacaode tempo, incluindo comunicacoes, controles, processamento de sinais, processamento devıdeo e imagem[Mathworks 2011]. Um diagrama de blocos e a representacao grafica deum processo ou modelo de um sistema complexo. Ele difere dos fluxogramas por re-presentar pequenas partes de um grande sistema com foco no processo logico. Nestesdiagramas, os sistemas sao compostos interligando os blocos. Para conexao entre os blo-cos, sao utilizadas linhas, atraves das quais os blocos trocam sinais. Alem disso, e possıvel

Figura 4. Diagramas de implantacao e de sequencia.

representar uma hierarquia entre os componentes, onde um bloco pode conter outros. AFigura 5 mostra o modelo Simulink correspondente aos diagramas exibidos na Figura 4.

Figura 5. Modelo Simulink.

A seguir e definida a gramatica de grafos que modela a traducao entre os diagra-mas UML e o modelo Simulink.

3.1. Grafo Inicial

Para modelagem da traducao, inicialmente e feita a conversao do diagrama desequencia UML em um grafo, que sera usado como grafo inicial da gramatica. A Figura 1ilustra o grafo correspondente aos diagramas da Figura 4.

No grafo, todos os elementos do UML foram representados por vertices, e suasrelacoes indicadas por arestas. Por exemplo, quando a thread 3 (T3) realiza a chamada deum metodo proprio calc(v=a):x no UML, sua correspondente no grafo e representada porum vertice SFunction calc, sendo que a aresta in indica que o metodo pertence a thread

T3. Alem disso, as arestas arg e result indicam que a variavel a e o argumento da funcaoe a variavel x e o seu resultado, respectivamente.

A partir do grafo inicial, aplicando as regras especificadas na gramatica, obtem-seum grafo que corresponde a um diagrama do Simulink. Essas regras agem transformandoo grafo ate que nenhuma regra possa mais ser aplicada, e com isso, obtem-se o grafo quedescreve o diagrama Simulink equivalente ao diagrama de sequencia UML inicial.

3.2. Regras

As regras que definem a gramatica, podem ser agrupadas em tres grupos:

• regras prefixadas por get;• regras prefixadas por set; and• regras prefixadas por Fun, Lib, ou Thr.

SAengine


get

X

SASchedRes

SASchedRes

X


var

vardSvar

tgt

in

!=

oC

result result

src

in

dC

(a) Regra getIntraC

get

CPUCOMMUNid = ”Inter”

X

var

SASchedResSASchedRes

X

SAengine


SAengine

X

result

dE

oE

dS

!=

tgt

inresult

oC

var

var var

src

dC

in

(b) Regra getInterC

get

SAengine

var

SASchedRes

X

SASchedRes


X

tgt

in

dC

var

!=

var

oC

result

in

result

dS

src

(c) Regra getIntra

getSASchedRes

X


X

SAengine

var

SASchedRes

X

SAengine

dE

result

dC

oE

dS

!=

oC

tgt

in

result

var

varvar

src

in

(d) Regra getInter

SAengine

IO

var

X

SASchedRes

X

getIO

result

var

dE

tgt

var

oE

result

oIin

dS

src

(e) Regra getIO

Figura 6. Regras prefixadas por get.

As regras prefixadas por get, ilustradas na Figura 6, criam as conexoes entre osblocos CPUCOMMUN ou IO e as entradas de thread, deletando a chamada dos metodosget.

As regras getIntra, getIntraC, getInter e getInterC possuem a mesma caracterısticade criar o caminho percorrido por uma variavel a partir de um dispositivo de comunicacaoCPUCOMMUN ate a entrada de uma thread, porem, as regras getIntraC e getInterC saoaplicadas quando CPUCOMMUN ainda nao foi criada, gerando-a. E as regras getInter egetIntra sao aplicadas apenas caso um CPUCOMMUN para a respectiva variavel ja exista.A regra getIO cria o caminho a partir da entrada (IO) ate o inicio de uma thread. As

Figura 7. Componentes do Simulink criados pelas regras prefixadas por get.

conexoes criadas por este conjunto de regras aplicadas ao grafo inicial da Figura 1 estaodestacadas na Figura 7.

Outro conjunto de regras exibido na Figura 8, contem as regras prefixadas por set.Estas regras criam o caminho percorrido de uma variavel derivada da thread ate um blocoCPUCOMMUN ou IO, deletando a chamada dos metodos set.

SAengine


set

X

SASchedRes

SASchedRes

X


var

var

oS

var

tgt

in

!=

arg

src

in

dC oC

arg

(a) Regra setIntraC

X

SAengine


SAengine

X

SASchedRes SASchedRes

var

X


set

dC

!=

oE

tgt

in

oC

dEvar

var

arg arg

var

src

in

oS

(b) Regra setInterC

SAengine

X

set

X

SASchedRes

SASchedRes


var

var

oC

var

tgt

in

!=

oS

arg

in

src

dC

arg

(c) Regra setIntra

SAengine

X


SASchedRes

var

SAengine

X

X

SASchedRes set

dE

!=

tgt

in

oC

var

arg argoS

oE var

src

var

dC

in

(d) Regra setInter

SAengine

setIO

X

IOSASchedRes

X vardI

var

var

oE

tgt

oS arg

in

src

dE

arg

(e) Regra setIO

Figura 8. Regras prefixadas por set.

As regras setInter, setInterC, setIntra e setIntraC, criam o caminho percorrido poruma variavel a partir de da entrada de uma thread ate um dispositivo de comunicacaoCPUCOMMUN. As regras setIntraC e setInterC sao aplicadas quando CPUCOMMUNainda nao foi criada, criando-a. E as regras setInter e setIntra sao aplicadas apenas casoseu CPUCOMMUN para a respectiva variavel ja existir. A regra setIO cria o caminho apartir da entrada thread ate a saıda (IO).

As regras detalhadas na Figura 9, criam as conexoes entre blocos de funcoes(SFunction e Lib) e outras funcoes/threads. Tais regras sao aplicadas quando o resultadode uma funcao/thread e utilizada como argumento de uma funcao/thread.

SFunction

Xvar

SFunction

SASchedRes

in oF

var

result

dFin arg

(a) Regra FunFun

lib

Xvar

SFunction

SASchedRes

in oF

var

result

in arg dL

(b) Regra FunLib

SFunction

Xvar

SASchedRes

result oF

dSarg

varin

(c) Regra FunThr

SFunction

Xvar

lib

SASchedRes

in oL

var

result

dFin arg

(d) Regra LibFun

lib

Xvar

lib

SASchedRes

in oL

var

result

in arg dL

(e) Regra LibLib

SASchedRes

Xvar

lib

oL

var

result

dS

in

arg

(f) Regra LibThr

SFunction

Xvar

SASchedRes

var

result

dF

oS

in

arg

(g) Regra ThrFun

lib

Xvar

SASchedRes

var

result oS

in

arg dL

(h) Regra ThrLib

Figura 9. Regras que criam conexoes entre funcoes e threads.

Figura 10. Componentes do Simulink criados pelas regras da Figura 9.

As regras prefixadas por Fun criam as conexoes entre a saıda de blocos de tipoSFunction e a entrada dos demais blocos. As regras prefixadas por Lib criam a conexoesentre a saıda de blocos de tipo Lib e a entrada dos demais blocos. E por fim, as regrasprefixadas por Thr criam a conexao entre a saıda de blocos de tipo Thread com funcoes.A Figura 10 destaca as conexoes criadas por estas regras.

3.3. Estado Final

O estado final obtido apos todas as possıveis regras terem sido aplicadas esta des-crito na Figura 11. A traducao deste grafo para blocos Simulink e imediata. VerticesIO, SAengine, CPUCOMMUN, SASchedRes, SFunction e lib representam os blocos demesmo identificador do Simulink representados na Figura 10. A hierarquia de blocos ecapturada pelos arcos rotulados com “in”. As conexoes e fluxo de dados entre os blocossao representados pelos vertices X juntamente com suas conexoes (arcos com origem emX no grafo). Arcos com prefixo “o” indicam a origem de uma conexao, e arcos prefixados

com “d” indicam o destino da conexao. Arcos rotulados com var indicam a variavel queesta sendo transmitida. Por exemplo, var com identificador “a” esta sendo transmitida deIODevice para CPU2 e de CPU2 para thread T3.

X

X

X


varid = ”x”

X


Xvarid = ”y”

X


varid = ”b”

X

varid = ”r2”

X

XX

X


X

X


X

varid = ”a”




X varid = ”r4”

X

SAengineid = ”CPU1”IO

id = ”Sensor”

varid = ”r1”

X


X


libid = ”mult”


X

X

X

X

X


SFunctionid = ”dec”

varid = ”r3”

X

X

X


X

oI

dE

var

oS

dE

dF

in

var

oF

dE

oS

var

var

var

in

oS

dF

var

dS

var

var

dE

dS

in

oC

oE

dF

varvar

dF

in

var

dS

var

oS

oF

oS

oE

dS

var

var

var

var

dE

dL

dC

in

oS

var

inoF

oE

dI

in

oI

oS

var

oE

dEoE

var

var

oE

oC

dC

dS

oL

in

oF

var

dSoS

oF

dS

dL

dS

var

oE

var

in

var

var

oC

dF

var

oS

var

dE

dS

dC

Figura 11. Grafo final 5

4. ConclusoesNeste artigo apresentou-se a definicao formal da traducao de UML para Simu-

link proposta em [Brisolara et al. 2008], utilizando Gramatica de Grafos. O uso de umalinguagem de especificacao formal nao so permitiu eliminar possıveis ambiguidades nadefinicao do mapeamento previamente descrita em linguagem natural, como tambem per-mitiu o uso da ferramenta Groove para automatizar a traducao.

Desta forma, um fluxo de projeto que comeca em um modelo UML e prove ummapeamento (semi-)automatico para um diagrama de blocos Simulink e proposto. Paraque o fluxo seja completamente automatico, ainda e necessario automatizar a geracao dografo inicial a partir dos diagramas UML (formato de entrada para o fluxo) e a conversaodo grafo resultante no formato usado para especificar diagrama de blocos no Simulink.Tambem se pretende explorar a verificacao de propriedades importantes em transformacaode modelos, como consistencia e terminacao, para o mapeamento definido.

ReferenciasBrisolara, L. B., Oliveira, M. F. S., Redin, R., Lamb, L. C., Carro, L., and Wagner, F.

(2008). Using uml as front-end for heterogeneous software code generation strategies.In Proc. of the conference on Design, automation and test in Europe, DATE ’08, pages504–509, NY, USA. ACM.

Ehrig, H., Engels, G., Kreowski, H.-J., and Rozenberg, G., editors (1999). Handbookof graph grammars and computing by graph transformation: volume 2: applications,languages, and tools. World Scientific Publishing Co., Inc., River Edge, NJ, USA.

Ehrig, H., Pfender, M., and Schneider, H. (1973). Graph grammars: an algebraic ap-proach. In 14th Annual IEEE Symposium on Switching and Automata Theory, pages167–180. IEEE.

Mathworks (2011). Simulink. http://www.mathworks.com/. ultimo acesso: Julho.

OMG (2010). Omg unified modeling language (omg uml) infrastructure version 2.3.Technical Report formal/2010-05-03.

Rensink, A. (2004). The groove simulator: A tool for state space generation. In Pfaltz,J., Nagl, M., and Bohlen, B., editors, Applications of Graph Transformations withIndustrial Relevance, volume 3062 of Lecture Notes in Computer Science, pages 479–485. Springer Berlin / Heidelberg.

Rozenberg, G., editor (1997). Handbook of graph grammars and computing by graphtransformation: volume 1. foundations. World Sci. Pub. Co., NJ, USA.

Using Graph Grammars to Develop Embedded Systems Based on UML Models

Documents