Sie sind auf Seite 1von 13

See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221412167

Using Graph Grammars to Develop Embedded


Systems Based on UML Models

Conference Paper · August 2011


DOI: 10.1109/WEIT.2011.16 · Source: DBLP

CITATIONS READS

2 40

6 authors, including:

Nicolas Bisi Vinicius Pazzini


Universidade Federal de Pelotas Universidade Federal de Pelotas
3 PUBLICATIONS 5 CITATIONS 4 PUBLICATIONS 5 CITATIONS

SEE PROFILE SEE PROFILE

Luciana Foss Simone André da Costa Cavalheiro


Universidade Federal de Pelotas Universidade Federal de Pelotas
53 PUBLICATIONS 202 CITATIONS 44 PUBLICATIONS 107 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Formal Specification of Multiagent Systems View project

Model-driven Approach for efficient code generation to cross-platform mobile applications View
project

All content following this page was uploaded by Lisane Brisolara on 12 October 2014.

The user has requested enhancement of the downloaded file.


Utilizando Gramática de Grafos para o Desenvolvimento de
Sistemas Embarcados Baseado em Modelos UML∗
Nı́colas N. Bisi, Vinı́cius Pazzini,
Luciana Foss, Simone A. C. Cavalheiro, Lisane B. de Brisolara
1
Centro de Desenvolvimento Tecnológico – 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 models
specification, while Simulink allows a better dataflow description. The featu-
res of each model motivates the development of proposals unifying and creating
mappings 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 and
a prototype implemented in Java. The formal definition using graph grammars
not only eliminated possible ambiguities in the mapping, but also allowed the
use of Groove to automate the translation.

Resumo. Modelos UML e Simulink são amplamente utilizados no projeto e de-


senvolvimento de sistemas embarcados. UML fornece abstrações de alto nı́vel
adequadas para a modelagem de software orientado a modelos, já Simulink
permite uma melhor descrição de fluxo de dados. As especificidades de cada
modelo motivam propostas de unificação e mapeamento entre eles. Este artigo
propõe uma definição formal para uma tradução de modelos UML em mode-
los Simulink, previamente proposta, utilizando o formalismo de gramática de
grafos. Esta tradução foi previamente definida em linguagem natural e um
protótipo implementado em Java. A definição formal utilizando gramática de
grafos não só eliminou possı́veis ambiguidades no mapeamento, como também
permitiu o uso da ferramenta Groove para a automatização da tradução.

1. Introdução
Técnicas que partem de modelos de alto nı́vel de abstração são requeridas para
lidar com a complexidade encontrada nas novas gerações de sistemas embarcados, sendo
cruciais para o sucesso do projeto. Uma grande redução do esforço no desenvolvimento
de sistemas embarcados pode ser obtida com o uso de modelos, quando o código de uma
linguagem de programação é gerado automaticamente a partir desses modelos. Porém,
ferramentas disponı́veis para modelagem e geração de código normalmente são dependen-
tes de domı́nio e o software embarcado normalmente possui comportamento heterogêneo,
requerendo suporte a múltiplos modelos de computação.
Na área de engenharia de software, UML [OMG 2010] é uma das linguagens mais
utilizadas, por fornecer abstrações de alto nı́vel adequadas para a modelagem de software

Trabalho financiado pelo CNPq e FAPERGS
orientado a modelos. Já na área de sistemas embarcados um modelo largamente adotado
por engenheiros de hardware e de controle é o de blocos Simulink [Mathworks 2011].
Uma comparação feita entre as linguagens UML e modelos Simulink mostra que UML é
baseada em eventos e não é adequada para modelar sistemas dataflow. Por outro lado, os
modelos Simulink suportam dataflow e geração de código, porém eles provêm abstrações
de mais baixo nı́vel, quando comparados a UML. Conclui-se que tanto UML como Simu-
link possuem vantagens e desvantagens para a sua adoção, o que motiva a integração de
ambas as linguagens em um único 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 simulação e geração de código. No en-
tanto, a definição deste mapeamento foi feita em linguagem natural e um protótipo foi
implementado com Java. Este artigo propõe uma definição formal para esta tradução
previamente proposta, utilizando o formalismo de gramática de grafos [Rozenberg 1997,
Ehrig et al. 1999]. A definição formal utilizando gramática de grafos não só eliminou
possı́veis ambiguidades na definição em linguagem natural, como também permitiu o uso
da ferramenta Groove [Rensink 2004] para a automatização da tradução.
A utilização de gramática de grafos se mostra adequada para especificar lingua-
gens visuais, como é o caso das linguagens UML e Simulink, por especificar um modelo
a partir de regras de transformação de grafos. Uma gramática de grafos é definida por um
grafo inicial, que modela o estado inicial da especificação, um grafo tipo, o qual limita os
diferentes tipos de vértices e arcos da especificação e um conjunto de regras, que descre-
vem as possı́veis mudanças de estados que podem ocorrer. Na especificação da tradução
em gramática de grafos, uma representação de UML como grafo define o estado inicial do
mapeamento e o conjunto de regras definiu formalmente o mapeamento proposto. O grafo
resultante da transformação, obtido após a aplicação das regras ao grafo UML, constitui
uma representação de grafo para o correspondente modelo Simulink.
O restante deste artigo está organizado como segue. A seção 2 descreve o forma-
lismo de gramática de grafos. A seção 3 define formalmente a conversão da linguagem
UML para a linguagem Simulink. A seção 4 apresenta as conclusões finais.

2. Gramática de grafos

Nesta seção são apresentados os principais conceitos de gramática de grafos, se-


guindo a abordagem Single Pushout [Rozenberg 1997]. Gramática de grafos é uma lin-
guagem de especificação formal na qual grafos são usados para representar estados de
um sistema e mudanças no estado do sistema são descritas por regras (mapeamento entre
grafos).
Pesquisas na área de gramáticas de grafos iniciaram nos anos 70
[Ehrig et al. 1973], e métodos, técnicas e resultados nesta área já foram estudados
e aplicados em uma grande variedade de campos da Informática, como teoria de
linguagens formais, reconhecimento e geração de imagens, construção de compiladores,
engenharia de software, modelagem de sistemas concorrentes e distribuı́dos, projeto e
teoria de bancos de dados, entre outros [Ehrig et al. 1999].
2.1. Sintaxe de gramática de grafos
Os conceitos básicos desta abordagem são os de grafo e morfismo de grafos. Gra-
fos são estruturas compostas por vértices e arestas, que permitem descrever situações
complexas de forma visual, compacta, clara e intuitiva.
Um grafo G = (VG , AG , LVG , LAG , oG , dG , lV , lA ) consiste de um conjunto de
vértices VG , um conjunto de arestas AG , um conjunto de rótulos de vértices LVG , um
conjunto de rótulos de arestas LAG , duas funções totais, oG , dG : AG → VG , denominadas
funções origem e destino, as quais associam cada aresta ao seu vértice origem e destino,
respectivamente, e duas funções totais lV : VG → LVG , lA : AG → LAG que rotulam
vértices e arestas.
Na abordagem usada neste artigo, atributos de algum tipo de dado podem ser
associados aos vértices. Esse tipo de grafo, chamado de grafo com atributos, é definido
como um grafo cujos conjuntos VG e AG são compostos de dois subconjuntos disjuntos:
VG = V rG ] V aG , onde V rG é um conjunto de vértices regulares e V aG é um conjunto de
vértices de atributos; e AG = ArG ] AaG , onde ArG é um conjunto de arestas regulares
e AaG é um conjunto de arestas de atributos. Os vértices de atributos são rotulados por
constantes de algum tipo de dado, por exemplo constantes numéricas ou literais, e as
arestas de atributos conectam vértices regulares a vértices de atributos. Deste modo, um
grafo com atributos G0 = (G, AlgG ) é definido por um grafo G mais uma álgebra AlgG , a
qual define os rótulos dos vértices V aG , isto é, AlgG ⊆ LVG e para todo v ∈ V aG , tem-se
que lV (v) ∈ AlgG .
A Figura 1 exibe um exemplo de grafo, onde os vértices são representados por
retângulos e as arestas por setas conectando os vértices de origem aos vértices de destino.
Os rótulos dos vértices regulares estão inscritos nos retângulos e os das arestas regulares
são escritos sobre as setas. Os atributos, tanto dos vértices quanto das arestas, não são re-
presentados explicitamente, eles aparecem inscritos nos vértices regulares aos quais estão
associados. Por exemplo, o vértice regular com rótulo IO (no canto esquerdo superior da
Figura 1) tem o atributo id = “IODevice”, onde id é uma aresta de atributo que conecta IO
ao vértice de atributo “IODevice”.
IO var arg SFunction
id = ”IODevice” id = ”a” id = ”calc”
IO
tgt result SAengine SAengine id = ”IODevice”
id = ”CPU2” id = ”CPU1”
in result tgt
getIO
in set in setIO
src src tgt get in
tgt src arg
SASchedRes src
tgt SASchedRes result
id = ”T3” get arg src
id = ”T1” tgt SASchedRes var
src src
getIO result set id = ”T2” id = ”r4”
arg
var in
tgt id = ”x” in var
result tgt src in result
src id = ”r3”
result
IO in arg SFunction
id = ”Sensor” in id = ”dec” arg
var SFunction
id = ”b” SFunction
tgt id = ”calc”
get arg id = ”calc”
set result
arg var
arg var id = ”r2”
result id = ”r1” result
SFunction arg
var arg lib
id = ”calc” result
id = ”y” id = ”mult”

Figura 1. Exemplo de grafo.


Um morfismo f : L → R de um grafo L para um grafo R é definido por três
funções parciais, uma função fv : VL → VR que mapeia vértices do grafo L em vértices
no grafo R, tal que para todo v ∈ V rL .fv (v) ∈ V rR e para todo v ∈ V aL .fv (v) ∈
V aR ; uma função fa : AL → AR que mapeia as arestas do grafo L em arestas no grafo
R, tal que para todo a ∈ ArL .fa (a) ∈ ArR e para todo a ∈ AaL .fa (a) ∈ AaR ; e
uma função fl : LVL → LVR , que faz o mapeamento dos rótulos entre os respectivos
grafos, tal que para todo x ∈ AlgL .fl (x) ∈ AlgR . Estas funções devem obedecer algumas
regras de compatibilidade. Compatibilidade aqui significa que cada vez que um arco do
grafo L for mapeado em um arco do grafo R, então, em relação ao arcos mapeados, o
vértice origem (respectivamente destino) do arco de L deve ser mapeado para o vértice
origem (respectivamente destino) do arco em R. Além disso, o mapeamento dos rótulos
também deve ser compatı́vel, isto é, se um vértice (ou arco) de L é mapeado em um
vértice (ou arco) de R, seu rótulo deve ser mapeado para o rótulo do vértice (ou arco) em
R. Um morfismo é total/injetivo se todas as funções que o definem são totais/injetivas,
respectivamente.
Regras especificam possı́veis mudanças de estado em uma especificação. Uma
regra r : L → R em gramática de grafos consiste de dois grafos, L (lado esquerdo) e R
(lado direito), e um morfismo de grafos entre eles. O morfismo especifica elementos que
devem ser preservados, deletados ou criados pela aplicação da regra. Regras podem ser
enriquecidas com NACs (Condições de Aplicação Negativas).
Condições de aplicação negativas (NACs, do inglês negative application conditi-
ons) restringem a utilização de uma regra ao afirmar que uma determinada estrutura não
pode estar presente no grafo estado. Dada uma regra r : L → R, condições de aplicação
negativas são conjuntos de morfismos totais e injetores que partem do lado esquerdo da
regra, denotado por M or(L). Cada morfismo l ∈ M or(L) é chamado de restrição.

CPUCOMMUN CPUCOMMUN CPUCOMMUN CPUCOMMUN


id = ”Intra” id = ”Intra” id = ”Intra” id = ”Intra”
dC
oC l r X dC
oC
var
X var var var var X
oS X
arg arg arg var
var
SASchedRes src set SASchedRes src set SASchedRes var
oS
arg arg

in != tgt in != tgt in != SASchedRes src set

in != tgt
SAengine in SASchedRes SAengine in SASchedRes SAengine in SASchedRes
SAengine in SASchedRes

(a) Morfismos l e r (b) Sintaxe de uma regra do


Groove

Figura 2. Exemplo de regra

A Figura 2 mostra um exemplo de regra com condição negativa de aplicação. A


Figura 2(a) detalha o morfismo l, que mapeia o lado esquerdo da regra para um grafo que
inclui os elementos proibidos, e o morfismo r, que descreve a transformação ocorrida na
aplicação da regra. Os elementos que não podem estar presentes para habilitar a aplicação
desta regra são os vértices CPUCOMMUN e X e os arcos var e oC que não estão na ima-
gem de l. Os elementos que devem ser estar presentes para habilita-lá, são os vértices set,
SASchedRes, var, SAengine, SASchedRes e os arcos src, arg, in e !=, sendo que, dentre
estes, o vértice set e os arcos que incidem nele são deletados e os demais elementos são
preservados. Os elementos criados pela regra são os vértices X e CPUCOMMUN, e os ar-
cos dC, oS, var e arg que não estão na pré-imagem de r. No simulador do Groove, é usada
uma sintaxe mais compacta para as regras. Cada regra é representada por um único grafo,
com notações diferentes para cada tipo de elemento. A Figura 2(b) apresenta a sintaxe da
regra da Figura 2(a) no Groove, onde os elementos criados são representados por linhas
espessas e contı́nuas, os elementos preservados são representados por linhas simples e
contı́nuas, os elementos deletados são representados por linhas simples e tracejadas e os
elementos proibidos (NACs) por linhas espessas e tracejadas.
Uma gramática de grafos consiste dos seguintes componentes:
• Um grafo tipo que representa os diferentes tipos de itens que podem ocorrer em
uma especificação;
• Um grafo inicial que modela o estado inicial de uma especificação;
• Um conjunto de regras que definem as possibilidades de mudanças nos estados de
uma especificação.
Assim, uma gramática de grafos com NACs é uma tupla GN N = (T, G0 , R), onde T é
um grafo tipo, G0 é um grafo tipado em T e R é um conjunto de regras com NACs.

2.2. Semântica da gramática de grafos


Uma regra, sem NACs, é possı́vel de ser aplicada se todos os componentes do
grafo esquerdo da regra estão presentes no grafo (estado), i.e., se houver um morfismo
total de grafos do lado esquerdo da regra para o grafo. Este morfismo é denominado
match. O grafo resultante da aplicação de uma regra r : LT → RT a um grafo (estado) é
obtido a partir das seguintes etapas:

• Adiciona-se ao grafo tudo que foi criado pela regra, ou seja, estruturas ausentes
em L e presentes em R (que não tem pré-imagem em L);
• Deleta-se do grafo tudo que deve ser deletado pela regra, ou seja, estruturas pre-
sentes em L e não mapeados em R;
• Deleta-se arcos pendentes. Este passo é necessário no caso de haverem arcos
conectados a vértices deletados no passo anterior. Como o resultado da aplicação
de uma regra deve ser um grafo, este arcos devem ser deletados também.

Uma regra com NACs pode de ser aplicada ao grafo GT se há um match m :
LT → GT que satisfaz todas as NACs da regra. Um match m satisfaz todas as NACs
se ele satisfaz cada uma das restrições. Para m satisfazer um restrição l : LT → N T ,
não pode ser possı́vel encontrar os elementos proibidos pela restrição l no contexto de m,
isto é, não pode existir um mapeamento de n : N T → GT que torne a seguinte igualdade
verdadeira n◦l = m. O resultado da aplicação de um regra com NACs é o mesmo descrito
anteriormente (para regras sem NACs).

3. UML para Simulink


A especificação da tradução dos diagramas UML para um diagrama de blocos Si-
mulink foi definida através de uma gramática de grafos. Esta tradução utiliza diagramas
UML de sequência e de implantação. O diagrama de implantação é utilizado para de-
monstrar a organização do hardware e a ligação do software com os dispositivos fı́sicos.
Ele também modela a visão estática da implantação de um sistema entre seus nós fı́sicos
e seus relacionamentos, especificando os detalhes referentes à construção. O diagrama
de sequência mostra as interações entre objetos em uma sequência temporal, facilitando
a visualização da dinâmica do sistema, pois enfatiza o ordenamento das operações. O
diagrama de sequência UML utilizado foi adaptado e, com isso, teve seu uso mais res-
trito, onde a comunicação entre objetos thread e entre objetos thread e IO (dispositivo de
entrada e saı́da) só é possı́vel através da chamada de métodos get e set. Os objetos podem
ainda chamar métodos próprios ou métodos do objeto especial Plataforma. Este último
objeto representa uma biblioteca de operações pré-definidas.
O processo de tradução de UML para Simulink, ilustrado na Figura 3, começa
com a construção do grafo inicial da gramática a partir dos diagramas de sequência e
implantação. Este grafo é descrito na linguagem interpretada pela ferramenta GROOVE,
que o transforma, aplicando as regras definidas, em um grafo que representa um modelo
Simulink. O grafo final é então traduzido para a linguagem de entrada do Simulink. Este
processo ainda é semi-automático, onde apenas a transformação entre o grafo inicial e
final é automatizada, com o uso da ferramenta GROOVE.

Transformação
UML Grafo GROOVE Grafo
Simulink
Inicial Final

Figura 3. Processo de transformação de diagrams UML para modelos Simulink

Na Figura 4 temos exemplos de diagramas de implantação e de sequência. O dia-


grama de implantação, descrito na parte superior da figura, descreve um sistema de hard-
ware com duas CPUs (CPU1 e CPU2) interligadas por um barramento (bus). Além disso,
também está definido como as três threads, T1, T2 e T3, serão alocadas nestas CPUs. Por
questões de simplificação, os três diagramas de sequência, descrevendo o comportamento
de cada uma das threads, foram representados no único diagrama apresentado na parte
inferior da figura. As chamadas dos métodos main task() realizadas pelo objeto Schedu-
ler indicam o inicio da execução de cada uma das threads. As setas entre as threads ou
entre uma thread e um dispositivo de entrada e saı́da (Sensor ou IODevice), representam
as chamadas de métodos get e set. As demais setas, representam as chamadas de métodos
das próprias threads ou dos métodos do objeto Plataforma.
Simulink é uma ferramenta de modelagem, simulação e análise de sistemas
dinâmicos baseado na representação por esquemas de blocos. Ele fornece um ambiente
gráfico interativo e um conjunto personalizável de bibliotecas de blocos que permitem
projetar, simular, implementar e testar uma variedade de diferentes sistemas com variação
de tempo, incluindo comunicações, controles, processamento de sinais, processamento de
vı́deo e imagem[Mathworks 2011]. Um diagrama de blocos é a representação gráfica de
um processo ou modelo de um sistema complexo. Ele difere dos fluxogramas por re-
presentar pequenas partes de um grande sistema com foco no processo lógico. Nestes
diagramas, os sistemas são compostos interligando os blocos. Para conexão entre os blo-
cos, são utilizadas linhas, através das quais os blocos trocam sinais. Além disso, é possı́vel
Figura 4. Diagramas de implantação e de sequência.

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

Figura 5. Modelo Simulink.

A seguir é definida a gramática de grafos que modela a tradução entre os diagra-


mas UML e o modelo Simulink.

3.1. Grafo Inicial


Para modelagem da tradução, inicialmente é feita a conversão do diagrama de
sequência UML em um grafo, que será usado como grafo inicial da gramática. A Figura 1
ilustra o grafo correspondente aos diagramas da Figura 4.
No grafo, todos os elementos do UML foram representados por vértices, e suas
relações indicadas por arestas. Por exemplo, quando a thread 3 (T3) realiza a chamada de
um método próprio calc(v=a):x no UML, sua correspondente no grafo é representada por
um vértice SFunction calc, sendo que a aresta in indica que o método pertence a thread
T3. Além disso, as arestas arg e result indicam que a variável a é o argumento da função
e a variável x é o seu resultado, respectivamente.
A partir do grafo inicial, aplicando as regras especificadas na gramática, obtém-se
um grafo que corresponde a um diagrama do Simulink. Essas regras agem transformando
o grafo até que nenhuma regra possa mais ser aplicada, e com isso, obtém-se o grafo que
descreve o diagrama Simulink equivalente ao diagrama de sequência UML inicial.

3.2. Regras
As regras que definem a gramática, podem ser agrupadas em três grupos:
• regras prefixadas por get;
• regras prefixadas por set; and
• regras prefixadas por Fun, Lib, ou Thr.

CPUCOMMUN CPUCOMMUN CPUCOMMUN CPUCOMMUN


id = ”Intra” id = ”Intra” id = ”Inter” id = ”Inter”

dC oC dC
oC
X X X
X
var dE
var var
dS var
var SAengine != SAengine

result oE var
result
var
SASchedRes src get in X in
result result
in != tgt dS

SAengine in SASchedRes SASchedRes src get tgt SASchedRes

(a) Regra getIntraC (b) Regra getInterC


CPUCOMMUN CPUCOMMUN
id = ”Intra” id = ”Inter”

oC dC oC dC
X X X X
var var dE
var var
dS var
SAengine != SAengine SAengine dE X
result result oE var oE var
SASchedRes src get var
in X in in X var var oI
tgt result result
in != dS dS result
result

SAengine in SASchedRes SASchedRes src get tgt SASchedRes SASchedRes src getIO tgt IO

(c) Regra getIntra (d) Regra getInter (e) Regra getIO

Figura 6. Regras prefixadas por get.

As regras prefixadas por get, ilustradas na Figura 6, criam as conexões entre os


blocos CPUCOMMUN ou IO e as entradas de thread, deletando a chamada dos métodos
get.
As regras getIntra, getIntraC, getInter e getInterC possuem a mesma caracterı́stica
de criar o caminho percorrido por uma variável a partir de um dispositivo de comunicação
CPUCOMMUN até a entrada de uma thread, porém, as regras getIntraC e getInterC são
aplicadas quando CPUCOMMUN ainda não foi criada, gerando-a. E as regras getInter e
getIntra são aplicadas apenas caso um CPUCOMMUN para a respectiva variável já exista.
A regra getIO cria o caminho a partir da entrada (IO) até o inicio de uma thread. As
Figura 7. Componentes do Simulink criados pelas regras prefixadas por get.

conexões criadas por este conjunto de regras aplicadas ao grafo inicial da Figura 1 estão
destacadas na Figura 7.
Outro conjunto de regras exibido na Figura 8, contém as regras prefixadas por set.
Estas regras criam o caminho percorrido de uma variável derivada da thread até um bloco
CPUCOMMUN ou IO, deletando a chamada dos métodos set.

CPUCOMMUN CPUCOMMUN CPUCOMMUN CPUCOMMUN


id = ”Intra” id = ”Intra” id = ”Inter” id = ”Inter”

oC dC oC
dC
X X X
X var
var oE var var

oS var SAengine != SAengine


arg
arg dE
SASchedRes src var var
set
in X in
in != tgt arg arg
oS

SAengine in SASchedRes SASchedRes src set tgt SASchedRes

(a) Regra setIntraC (b) Regra setInterC


CPUCOMMUN
CPUCOMMUN
id = ”Inter”
id = ”Intra”
dC oC
dC oC
X X X
X
var var oE
var var
SAengine != SAengine SAengine oE X
oS var
arg var
arg dE dE
var var
var X var
SASchedRes src set in X in dI
in
arg arg
in != tgt oS oS arg arg

SAengine in SASchedRes SASchedRes src set tgt SASchedRes SASchedRes src setIO tgt IO

(c) Regra setIntra (d) Regra setInter (e) Regra setIO

Figura 8. Regras prefixadas por set.

As regras setInter, setInterC, setIntra e setIntraC, criam o caminho percorrido por


uma variável a partir de da entrada de uma thread até um dispositivo de comunicação
CPUCOMMUN. As regras setIntraC e setInterC são aplicadas quando CPUCOMMUN
ainda não foi criada, criando-a. E as regras setInter e setIntra são aplicadas apenas caso
seu CPUCOMMUN para a respectiva variável já existir. A regra setIO cria o caminho a
partir da entrada thread até a saı́da (IO).
As regras detalhadas na Figura 9, criam as conexões entre blocos de funções
(SFunction e Lib) e outras funções/threads. Tais regras são aplicadas quando o resultado
de uma função/thread é utilizada como argumento de uma função/thread.
SFunction SFunction

result oF SFunction
in result oF
in result oF
SASchedRes var var X in var var X
SASchedRes var var X
in arg arg dS
dF in arg dL

SFunction lib SASchedRes

(a) Regra FunFun (b) Regra FunLib (c) Regra FunThr

lib
lib
lib
in result oL result oL
in result oL
SASchedRes var var X in var var X
SASchedRes var var X

in arg arg dS
in arg dL
dF

SFunction lib SASchedRes

(d) Regra LibFun (e) Regra LibLib (f) Regra LibThr

SASchedRes SASchedRes
result oS
result oS
var var X
in var var X in

arg dF arg dL

SFunction lib

(g) Regra ThrFun (h) Regra ThrLib

Figura 9. Regras que criam conexões entre funções e threads.

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

As regras prefixadas por Fun criam as conexões entre a saı́da de blocos de tipo
SFunction e a entrada dos demais blocos. As regras prefixadas por Lib criam a conexões
entre a saı́da de blocos de tipo Lib e a entrada dos demais blocos. E por fim, as regras
prefixadas por Thr criam a conexão entre a saı́da de blocos de tipo Thread com funções.
A Figura 10 destaca as conexões criadas por estas regras.

3.3. Estado Final


O estado final obtido após todas as possı́veis regras terem sido aplicadas está des-
crito na Figura 11. A tradução deste grafo para blocos Simulink é imediata. Vértices
IO, SAengine, CPUCOMMUN, SASchedRes, SFunction e lib representam os blocos de
mesmo identificador do Simulink representados na Figura 10. A hierarquia de blocos é
capturada pelos arcos rotulados com “in”. As conexões e fluxo de dados entre os blocos
são representados pelos vértices X juntamente com suas conexões (arcos com origem em
X no grafo). Arcos com prefixo “o” indicam a origem de uma conexão, e arcos prefixados
com “d” indicam o destino da conexão. Arcos rotulados com var indicam a variável que
está sendo transmitida. Por exemplo, var com identificador “a” está sendo transmitida de
IODevice para CPU2 e de CPU2 para thread T3.
IO
id = ”IODevice” IO
id = ”IODevice”
oI CPUCOMMUN SAengine
IO SAengine id = ”Inter” id = ”CPU1” dI
X dE dE
id = ”Sensor” id = ”CPU2” dC oC oE
oE X X
X
oE CPUCOMMUN dE
oI dE var
oE oE dE dE dC id = ”Inter” oE
oE
X oC
var var X dE var
X
id = ”r4”
var X X X X in
X in var
in var X
var varvar
var
var var id = ”y” CPUCOMMUN X
var
var id = ”Intra”
dS dS oS oS var dS
dS dC oC oS
var X X var
id = ”b” var oS dS
id = ”a” var var SASchedRes
SASchedRes var var SASchedRes id = ”T2”
var id = ”T3” id = ”x” id = ”T1” var
oS id = ”r3”
var var var var oS dS
X oS dS dS
oS oS var var
in X in in
X in X X X
in X dS X
dF oF dF in oF dF oF
dF
SFunction SFunction
SFunction SFunction dL id = ”dec” id = ”calc”
id = ”calc” id = ”calc”
SFunction X dF
oF oF
id = ”calc”
var lib X var
var X dL oL var
id = ”r1” id = ”mult” id = ”r2”

Figura 11. Grafo final 5

4. Conclusões
Neste artigo apresentou-se a definição formal da tradução de UML para Simu-
link proposta em [Brisolara et al. 2008], utilizando Gramática de Grafos. O uso de uma
linguagem de especificação formal não só permitiu eliminar possı́veis ambiguidades na
definição do mapeamento previamente descrita em linguagem natural, como também per-
mitiu o uso da ferramenta Groove para automatizar a tradução.
Desta forma, um fluxo de projeto que começa em um modelo UML e provê um
mapeamento (semi-)automático para um diagrama de blocos Simulink é proposto. Para
que o fluxo seja completamente automático, ainda é necessário automatizar a geração do
grafo inicial a partir dos diagramas UML (formato de entrada para o fluxo) e a conversão
do grafo resultante no formato usado para especificar diagrama de blocos no Simulink.
Também se pretende explorar a verificação de propriedades importantes em transformação
de modelos, como consistência e terminação, para o mapeamento definido.

Referências
Brisolara, 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, pages
504–509, NY, USA. ACM.
Ehrig, H., Engels, G., Kreowski, H.-J., and Rozenberg, G., editors (1999). Handbook
of 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, pages
167–180. IEEE.
Mathworks (2011). Simulink. http://www.mathworks.com/. último 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 Böhlen, B., editors, Applications of Graph Transformations with
Industrial 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 graph
transformation: volume 1. foundations. World Sci. Pub. Co., NJ, USA.

View publication stats

Das könnte Ihnen auch gefallen