Beruflich Dokumente
Kultur Dokumente
discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221412167
CITATIONS READS
2 40
6 authors, including:
Some of the authors of this publication are also working on these related projects:
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.
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.
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
in != tgt
SAengine in SASchedRes SAengine in SASchedRes SAengine in SASchedRes
SAengine in SASchedRes
• 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).
Transformação
UML Grafo GROOVE Grafo
Simulink
Inicial Final
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.
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.
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
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
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.
oC dC oC
dC
X X X
X var
var oE var var
SAengine in SASchedRes SASchedRes src set tgt SASchedRes SASchedRes src setIO tgt IO
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
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
SASchedRes SASchedRes
result oS
result oS
var var X
in var var X in
arg dF arg dL
SFunction lib
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.
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.