Estudo-das-Linguagens-para-Modelagem-de-Sistemas-Embarcados

Prévia do material em texto

UNIVERSIDADE FEDERAL DE PELOTAS
Centro de Desenvolvimento Tecnológico
 
 
 
 
 
 
Estudo das Linguagens para Modelagem de Sistemas E
 
 
 
 
M i l e n a R o t a S e n a 
 
 
 
 
 
 
 
 
 
UNIVERSIDADE FEDERAL DE PELOTAS
CDTec 
Centro de Desenvolvimento Tecnológico
 
 
 
 
 
 
Trabalho Acadêmico 
Titulo 
Estudo das Linguagens para Modelagem de Sistemas E
M i l e n a R o t a S e n a 
M a r q u e s 
 
 
Pelotas, 2011 
 
UNIVERSIDADE FEDERAL DE PELOTAS 
Centro de Desenvolvimento Tecnológico 
Estudo das Linguagens para Modelagem de Sistemas Embarcados 
M i l e n a R o t a S e n a 
 
 
 
 
 
1
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Banca examinadora: 
 
 
................................................................................................. 
Prof. Dr. Lisane Brisolara de Brisolara (Orientador) 
 
 
................................................................................................ 
 
 
................................................................................................ 
 
 
 
 
2
RESUMO 
 
MARQUES, Milena R. S. Estudo das Linguagens para Modelagem de Sistemas 
Embarcados. 2012. 42f. Trabalho acadêmico (Mestrado) - Mestrado em Ciência da 
Computação. Universidade Federal de Pelotas, Pelotas. 
 
Sistemas Embarcados são sistemas cujo projeto envolve várias fases e alta 
complexidade, pois inclui hardware e software. Para lidar com esses desafios, no 
projeto de sistemas embarcados, a UML é usada na modelagem de sistemas. A 
linguagem oferece um alto poder de abstração, além das vantagens da construção 
de modelos visuais, através dos diversos diagramas disponíveis. Porém, seu uso é 
limitado em sistemas embarcados, o que motivou a definição de extensões da 
linguagem para este domínio específico. O objetivo deste trabalho é apresentar 
conceitos básicos do domínio de sistemas embarcados, logo após apresentar um 
estudo de dois perfis da UML que oferecem suporte à modelagem de sistemas 
embarcados, o SysML e o MARTE. A combinação desses perfis é avaliada neste 
trabalho para obter-se uma modelagem de alto nível adequada, que inclui a 
modelagem detalhada de requisitos funcionais e não funcionais, bem como a 
modelagem completa de requisitos temporais. 
 
 
Palavras-chave: Sistemas Embarcados, UML, SysML, MARTE. 
 
 
3 
 
ABSTRACT 
 
MARQUES, Milena R. S. Estudo das Linguagens para Modelagem de Sistemas 
Embarcados. 2012. 42f. Trabalho acadêmico (Mestrado) - Mestrado em Ciência da 
Computação. Universidade Federal de Pelotas, Pelotas. 
 
Embedded systems are systems which project involves several phases and high 
complexity because it includes hardware and software. To deal with these 
challenges, the design of embedded systems, UML is used in modeling systems. The 
language provides a high power of abstraction and the benefits of building visual 
models, through the various diagrams available. However, its use is restricted in 
embedded systems, which motivated the definition of language extensions to this 
specific area. The objective of this paper is to present basic concepts of embedded 
systems domain, after presenting a study of two UML profiles that support the 
modeling of embedded systems, the SysML and MARTE The combination of these 
profiles is evaluated in this study to obtain a high level appropriate modeling, 
including detailed modeling of non-functional and functional requirements, as well as 
complete modeling of timing requirements. 
 
 
 
 
Keywords: Embedded Systems, UML, SysML, MARTE 
 
 
4 
 
LISTA DE FIGURAS 
 
Figura 1 – Níveis de abstração para o processo do projeto de sistemas embarcados
 ........................................................................................................................... 12 
Figura 2 – Sistema de Supervisão e Controle de tempo real. ................................... 18 
Figura 3 – Diagramas da UML 2.0 ............................................................................ 20 
Figura 4 – Sobreposição entre UML2.0 e SysML ...................................................... 24 
Figura 5 – Diagramas da linguagem SysML.............................................................. 25 
Figura 6 – Diagrama de requisitos. ........................................................................... 28 
Figura 7 – Diagramas de blocos representando as restrições do sistema. ............... 32 
Figura 8 – Pacote RTEM ........................................................................................... 36 
 
 
 
 
 
 
5 
 
LISTA DE TABELAS 
 
Tabela 1 – Diagrama de Requisitos. ......................................................................... 29 
Tabela 2 – Categoria de estereótipos genéricos para <<requirement>>. ................. 29 
 
6 
 
LISTA DE ABREVIATURAS E SIGLAS 
 
CCSL Clock Constraint Specification Language 
FPGA Field-programmable gate array 
GQAM Generic Quantitative Analysis Modeling 
HCFSM Máquina de Estados Finita Hierárquica e Concorrente. 
MARTE Modeling and Analysis of Real-time and Embedded System 
MFS Máquina de Estados Finita 
NFPs Requisitos não funcionais 
OMG Object Management Group 
RrUnit Real-time unit 
RTEM Modelo de Design Marte 
SE RFP System Engineering Request for Proposal 
SoC System on Chip 
SO Sistema Operacional 
SPT Profile for Schedulability, Performance and Time Specification 
SRT Soft Real Time Systems 
STR Sistema de Tempo Real 
SysML Systems Modeling Language 
UML Unified Modeling Language 
 
 
 
7 
 
SUMÁRIO 
 
1 INTRODUÇÃO .............................................................................................. 8 
1.1 Motivação .................................................................................................... 9 
1.2 Objetivos ...................................................................................................... 9 
1.3 Organização do Trabalho ........................................................................... 9 
2 SISTEMAS EMBARCADOS ....................................................................... 11 
2.1 Introdução ................................................................................................. 11 
2.2 Sistemas de Tempo Real .......................................................................... 14 
2.3 Sistemas Orientados a Eventos............................................................... 17 
2.4 Sistemas de Supervisão e Controle ........................................................ 17 
2.5 Sistema de Controle ................................................................................. 18 
3 LINGUAGENS PARA MODELAGEM DE SISTEMAS EMBARCADOS .... 20 
3.1 UML ............................................................................................................ 20 
3.1.1 Uso da UML na modelagem de Sistemas Embarcados ........................ 22 
3.2 SysML ........................................................................................................ 23 
3.2.1 Diagrama de Requisitos ........................................................................... 27 
3.2.2 Diagrama Paramétrico .............................................................................. 31 
3.3 MARTE ....................................................................................................... 33 
4 TRABALHOS RELACIONADOS................................................................ 37 
5 CONCLUSÕES ...........................................................................................39 
REFERÊNCIAS ......................................................................................................... 40 
 
 
8 
 
1 INTRODUÇÃO 
 
 Devido ao avanço tecnológico grande parte das tarefas executadas por seres 
humanos são auxiliadas por computadores. Nesse pressuposto, Sistemas 
computacionais embarcados estão presentes em diversas atividades, por exemplo, 
uso de mp3, telefone celular, entre outros. Sistemas embarcados são sistemas 
dedicados que possuem uma funcionalidade restrita para atender uma tarefa 
específica em sistemas maiores nos quais estão inseridos (MARWWEDEL, 2006). 
Segundo Brisolara et. al (2009) estes sistemas são naturalmente heterogêneos, pois 
são constituídos de componentes de hardware e software. 
O projeto de desenvolvimento de software embarcado é distinto do 
desenvolvimento de software de propósito geral. Tais sistemas possuem requisitos 
relevantes como: consumo de potência e energia, desempenho, tamanho, peso, 
memória, restrições de tempo, custo de projeto, entre outras. Um software é dito 
embarcado quando é projetado para executar em um sistema embarcado. Todos 
estes aspectos, aliados à sofisticação crescente dos produtos e o curto período para 
lançamento dos mesmos, aumentam a complexidade envolvida no projeto. 
Para lidar com projetos complexos, linguagens de alto nível de abstração têm 
sido utilizadas. Dentre elas, destaca-se a linguagem UML (Unified Modeling 
Language) considerada padrão para modelagem de software. UML é uma linguagem 
genérica que pode ser usada para modelar diferente tipos de sistemas. No entanto, 
a generalidade faz com que a UML não suporte a modelagem de alguns aspectos 
específicos em um determinado domínio de aplicação, motivando a definição de 
linguagens de domínio específico. Para atender esta demanda, a UML oferece 
mecanismos de extensão através da criação de perfis específicos para um dado 
domínio de aplicação. 
No domínio de sistemas embarcados, o suporte à descrição de 
comportamentos heterogêneos (hardware/software e diferentes modelos de 
computação) e a especificação de requisitos não-funcionais são exemplos de 
necessidades específicas do domínio. Dentre os perfis propostos pela OMG (Object 
Management Group) (OMG, 2011a), com enfoque no domínio de embarcados, 
destacam-se o SysML (Systems Modeling Language) (OMG, 2011 a) e o MARTE 
(Modeling and Analisys of Real-time and Embedded System) (OMG, 2011b). O 
SysML suporta a especificação, análise, projeto e verificação de sistemas 
9 
 
complexos, enquanto o MARTE enfoca a modelagem e análise de sistemas 
embarcados e de tempo real. 
O objetivo deste trabalho é realizar um estudo destas extensões com o intuito 
de analisá-las quanto aos recursos suportados para a modelagem de sistemas 
embarcados, bem como as limitações apresentadas. 
 
 
1.1 Motivação 
 
As linguagens de modelagem de alto nível ajudam a modelar sistemas 
complexos, bem como, seus requisitos funcionais e não funcionais. Sistemas 
embarcados são complexos e se diferem dos sistemas tradicionais principalmente 
por seus requisitos não funcionais, tais como: consumo energético, potência 
dissipada, além dos aspectos temporais exigidos em várias aplicações, etc. A UML 
não possui suporte para representar tais requisitos. A motivação deste trabalho é 
estudar linguagens de alto nível de abstração para modelagem de Sistemas 
Embarcados. 
 
1.2 Objetivos 
 
O Objetivo é estudar notações para a modelagem de Sistemas Embarcados 
em alto nível de abstração. As notações escolhidas foram SysML e MARTE, pois 
são perfis da UML 2.0 definidos e padronizados pela OMG. Sendo assim, neste 
trabalho serão avaliados estes perfis. 
 
 
1.3 Organização do Trabalho 
 
Este trabalho divide-se em cinco capítulos, de forma a explicar os principais 
conceitos envolvidos na modelagem de Sistemas Embarcados. 
No segundo capítulo são introduzidos conceitos básicos do domínio de 
sistemas embarcados, focando em sistemas de tempo real, sistemas orientados a 
eventos, sistemas de supervisão e controle e sistemas de controle. 
10 
 
Já no terceiro capítulo são apresentados os trabalhos relacionados com este 
estudo. 
Enquanto que no quarto capítulo serão apresentados conceitos de linguagem 
de modelagem de alto nível de abstração. Para modelagem de sistemas de 
propósito geral são apresentados conceitos de UML, logo após são apresentados 
conceitos de SysML e MARTE, para representação de Sistemas Embarcados. 
 Após, no quinto capítulo, são apresentadas as conclusões deste estudo. 
 
 
11 
 
 
 
2 SISTEMAS EMBARCADOS 
 
Este capítulo tem por objetivo introduzir a área de aplicação da ciência da 
computação denominada “Sistemas Embarcados”, mostrando seus principais 
conceitos e tipos de sistemas desse domínio. 
 
2.1 Introdução 
 
 Sistemas embarcados são sistemas dedicados que possuem uma 
funcionalidade restrita para atender uma tarefa específica em sistemas maiores nos 
quais estão inseridos (MARWEDEL, 2006). 
Sistemas embarcados são heterogêneos por envolverem software e 
hardware. As aplicações embarcadas possuem características que os diferem dos 
demais sistemas. Características como: sistemas dedicados, sistemas reativos, 
confiabilidade, restrições de tempo real, tamanho do código, desempenho, baixo 
consumo de potência e energia, físicas (tamanho e peso), devem ser consideradas 
no desenvolvimento de um sistema embarcado. As aplicações de computação 
embarcada estão incorporadas em muitas áreas tais como: eletrônica automotiva, 
eletrônica de aeronaves, sistemas de telecomunicação, eletrônica de consumo, 
equipamentos médicos, aplicações militares entre outros. Para lidar com essas 
restrições na construção de um sistema embarcado são utilizadas as linguagens de 
modelagem de alto nível de abstração. Sendo assim, o projeto de um sistema 
embarcado parte de uma visão abstrata e ao longo do desenvolvimento são feitos 
refinamentos até o produto finalizado. 
O projeto de um sistema embarcado envolve etapas com diferentes níveis de 
abstração, conforme o fluxo ilustrado na Fig. 1. De acordo com este fluxo, as etapas 
de projeto compreendem: 
• Análise de Requisitos: definição dos requisitos do sistema. 
• Especificação: detalhamento das funcionalidades do sistema. 
• Arquitetura do Sistema: detalhamento interno do sistema, bem como os 
componentes que compõem o sistema. 
• Projeto de Componentes: projetar os componentes do sistema. 
12 
 
• Integração do Sistema: integração dos componentes 
desenvolvidos para o sistema e a validação dos mesmos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1 – Níveis de abstração para o processo do projeto de sistemas embarcados 
Fonte: (Wolf; 2008, p.11) 
 
Segundo Wolf (2008) a abordagem para desenvolvimento de sistemas 
embarcados pode seguir o modelo top-down, em que o projeto se inicia com uma 
visão mais abstrata e através de refinamentos sucessivos obtêm-se o sistema 
propriamente dito. Já na abordagem bottom-up, o projeto é iniciado com uma 
descrição em nível de componentes e a partir destes componentes constrói-se o 
sistema completo. Em projetos reais são utilizadas as duas abordagens. A 
abordagem bottom-up permite tomar decisões quanto ao custo dos componentes, 
por exemplo, para a decisão de qual será a melhor arquitetura para o sistema. 
Sendo um misto das duas abordagens as decisões críticas podem ser tomadas a 
tempo evitando o retrabalho. 
Em cada nível de abstração durante as etapas do projeto de um sistema 
embarcado, é necessário: 
Projeto Top- Down Projeto Bottom-up 
Requisitos 
Especificação 
Arquitetura 
Projeto de 
Componentes 
Integração do 
Sistema 
13 
 
• Analisar o projeto para determinar as característicasdo estado atual do 
projeto. 
• Refinar o projeto adicionando detalhes. 
• Verificar o projeto para avaliar se os objetivos dos sistemas, tais como 
custo, velocidade serão alcançados. 
A etapa inicial do processo de desenvolvimento de um sistema embarcado é 
capturar as informações que serão utilizadas para criação da arquitetura e dos 
componentes. As informações dos requisitos são obtidas a partir do conhecimento 
do cliente e refinadas para uma especificação no qual contem informações 
suficientes para o inicio do projeto da arquitetura do sistema. 
Os requisitos em um projeto de sistema embarcados podem ser funcionais ou 
não funcionais. Requisitos funcionais descrevem as funcionalidades que se espera 
que um sistema disponibilize, de forma completa e consistente. Já os requisitos não 
funcionais mapeiam os aspectos qualitativos de um software, como: desempenho, 
portabilidade, consumo energético, consumo de potência, características físicas 
(tamanho e peso). 
Até pouco tempo a documentação dos requisitos era feita de forma textual 
com formulários pré-definido. Atualmente, é possível documentar os requisitos 
através do diagrama de requisitos. Este diagrama esta disponível no perfil SysML da 
UML 2.0. Podem-se destacar duas vantagens na utilização deste diagrama. A 
primeira é a minimização da ambigüidade das informações dos requisitos, já que 
este diagrama é representado de forma gráfica. A segunda é o suporte para a 
representação de requisitos funcionais e não funcionais. 
A próxima etapa no processo de desenvolvimento de um sistema embarcado 
é a especificação. Nesta etapa os requisitos são detalhados independentes de 
arquitetura. As especificações podem conter requisitos funcionais e não funcionais. 
Esta etapa, quando cumprida reduz erros no desenvolvimento do projeto. Não deve 
ser ambígua, deve possuir informações suficientes para o desenvolvedor do sistema. 
Também pode ser documentada com o diagrama de requisito, pois este diagrama 
pode representar um conjunto de requisitos (funcionais ou não funcionais) que estão 
contidos em uma especificação (FRIEDENTHAL, MOORE, STEINER, 2008). 
Na fase de arquitetura do projeto são implementadas as funcionalidades 
especificadas anteriormente (WOLF, 2008). Com diagrama de blocos é possível 
modelar a arquitetura do sistema, representando os componentes de hardware 
14 
 
(CPU, memória, entre outros) e os componentes de software. A descrição 
arquitetural do projeto deve satisfazer requisitos funcionais e não funcionais. Nesta 
fase diagrama de colaboração da UML pode ser utilizado para melhorar o 
entendimento do sistema. 
A construção dos componentes do projeto deve estar de acordo com a 
arquitetura e especificação. Os componentes utilizados em um projeto podem ser 
construídos para o sistema específicos, reutilizados de outro sistema, ou a utilização 
de componente padrão, como o caso de módulos de software. 
Segundo Wolf (2008) a fase de integração do sistema é um desafio no projeto 
de sistemas embarcados. Nesta fase, os componentes que foram construídos são 
unificados e devem funcionar corretamente. Durante esta fase muitos erros são 
detectados. Para detectar rapidamente os erros uma alternativa é fazer um plano de 
integração de todos os componentes do sistema, também é uma boa prática 
executar testes exaustivos nas funcionalidades do sistema o mais breve possível. 
As fases do desenvolvimento de um projeto de software embarcado podem 
ser capturadas utilizando um formalismo para projetos desses sistemas. A UML é 
uma linguagem formal com alto nível de abstração que pode ser utilizada para 
modelar cada fase do projeto de sistemas embarcados (WOLF, 2008). Com a UML 
2.0 é possível ter várias visões estruturais e comportamentais do sistema. 
Facilitando a tomada de decisão durante o desenvolvimento do projeto, e a 
visualização do sistema através dos diversos diagramas disponíveis. 
No domínio de sistemas embarcados a UML 2.0 possui o perfil MARTE que 
suporta a modelagem de tempo real de requisitos funcionais e não funcionais, para 
enriquecer o desenvolvimento do projeto desses sistemas também pode ser utilizado 
o perfil SysML que também suportam modelagem de requisitos funcionais, não 
funcionais e rastreabilidade. 
 
 
2.2 Sistemas de Tempo Real 
 
A utilização de sistemas computacionais vem crescendo na sociedade, com 
isso, aplicações de tempo real tornam-se freqüentes. Segundo Farines et. al (2000) 
as aplicações de tempo real variam em relação à complexidade e às necessidades 
de garantia no atendimento dos requisitos temporais. Alguns exemplos de sistemas 
15 
 
simples são os controladores inteligentes embarcados em produtos de utilidade 
domésticas, como as lavadoras de roupa e microondas. Já entre os sistemas mais 
complexos estão os sistemas militares, aviônicos, médicos. 
Um Sistema de Tempo Real (STR) é um sistema computacional que deve 
reagir a estímulos oriundos do seu ambiente em prazos específicos. Grande parte 
das aplicações de tempo real comporta-se como sistemas reativos com restrições 
temporais. Sistemas reativos reagem a ações do ambiente externo. 
O atendimento dos prazos dos requisitos temporais resulta no comportamento 
do sistema. Um sistema de tempo real deve entregar o resultado correto dentro do 
prazo específico, sob pena de ocorrer uma falha temporal. O comportamento correto 
de um sistema de tempo real, não depende apenas da integridade dos resultados 
obtidos (correção lógica ou correctness), mas também dos valores de tempo em que 
são produzidos (correção temporal ou timeless). Uma reação que ocorra depois do 
prazo especificado pode ser inútil ou representar uma ameaça dependendo do tipo 
de aplicação. 
Um dos conceitos mais importantes em sistemas de tempo real é a 
previsibilidade. Segundo Farines et. al (2000) um sistema é dito ser previsível no 
domínio lógico e no domínio temporal quando, independente de variações ocorrendo 
no nível de hardware, da carga e de falhas, o comportamento do sistema pode ser 
antecipado, antes de sua execução. 
Os sistemas de tempo real podem ser divididos em: Sistemas Não Críticos de 
Tempo Real (ou SRTs brandos, Soft Real Time Systems), onde o não atendimento 
de uma tarefa no prazo especificado não representa uma falha no comportamento 
do sistema, e Sistemas Críticos de Tempo Real (ou SRTs duros, Hard Real Time 
Systems) onde o não atendimento de uma tarefa no prazo especificado pode 
ocasionar uma catástrofe (ex. sistemas de controle de vôo). 
Conceitos de escalonamento em sistemas onde o tempo e a concorrência são 
tratados explicitamente se tornam essenciais para previsibilidade do comportamento 
de sistemas de tempo real. Uma tarefa é uma abstração básica que faz parte do 
problema de escalonamento. Tarefas ou processos são as unidades de 
processamento seqüenciais que concorrem com um ou mais recursos 
computacionais de um sistema. Uma aplicação simples de tempo real possui várias 
tarefas que devem apresentar correção lógica (correctness) e temporal (timeless). 
16 
 
Também é parte de um problema de escalonamento a definição do modelo de 
tarefas, que são as restrições temporais, as relações de precedência e de exclusão 
normalmente impostas sobre as tarefas. 
Todas as tarefas de tempo real estão sujeita a prazos: deadlines. Ou seja, 
uma tarefa deve ser concluída antes do seu prazo. As tarefas concluídas após seu 
prazo caracterizam dois tipos de tarefas de tempo real: 
• Tarefas críticas (hard): Uma tarefa é dita crítica se atendida após seu 
prazo pode causar falhas catastróficas ao sistema. 
• Tarefas brandas ou não críticas (soft): Uma tarefa é dita branda se 
atendida após seu prazo às falhas temporais são benignas, ou seja, a 
conseqüência do desvio do comportamento normal do sistema não 
representa um custo significativo. 
Os modelosde tarefas possuem dois tipos de tarefas segundo suas 
freqüências de ativação: 
• Tarefas Periódicas: a ativação da tarefa é realizada e a mesma ocorre 
infinitas vezes no período determinado. São tarefas que ocorrem com 
regularidade. 
• Tarefas Aperiódicas ou Assíncronas: a ativação do processamento da 
tarefa responde a eventos internos ou externos. A ativação deste tipo 
de tarefa é aleatória. 
As tarefas periódicas pela regularidade e, portanto pela previsibilidade, 
usualmente são associadas a "deadlines hard", ou seja, são tarefas críticas. As 
tarefas aperiódicas pela falta de previsibilidade em suas ativações, normalmente, 
tem "deadlines soft" associados a suas execuções, compondo, portanto as tarefas 
brandas de um sistema de tempo real. Tarefas esporádicas que correspondem a um 
subconjunto das tarefas aperiódicas apresentam como característica central a 
restrição de um intervalo mínimo conhecido entre duas ativações consecutivas e por 
isso, podem ter atributos de tarefas críticas. As tarefas esporádicas, portanto são 
também associadas a "deadlines hard" (FARINES, FRAGA, e OLIVEIRA, 2000). 
Quanto às características temporais as tarefas podem ter as seguintes 
restrições: 
• Tempo de computação: é o tempo necessário a execução completa de 
uma tarefa. 
17 
 
• Tempo de início: corresponde ao instante de inicio da ativação do 
processamento de uma tarefa 
• Tempo de término: o instante de tempo em que se completa a 
execução da tarefa. 
• Tempo de chegada: é o instante em que o escalonador toma 
conhecimento da ativação da tarefa. 
• Tempo de liberação: é o instante em que a tarefa pode ser executada. 
Através das políticas de escalonamento são definidas as regras para a 
ordenação das tarefas de tempo real. A utilização dessas políticas pelos 
escalonadores produz escalas que se forem realizáveis (feasible), garantem o 
cumprimento das restrições temporais impostas às tarefas de tempo real. 
Os algoritmos de escalonamento de tempo real podem ser classificados em 
preemptivos (de acordo com a tarefa a ser executada o algoritmo considera a 
prioridade de cada tarefa que esta na fila para execução, interrompendo a execução 
da tarefa atual para executar outra tarefa mais prioritária) e não preemptivos (mesmo 
existindo na fila uma tarefa mais prioritária que a que esta sendo executa este 
algoritmo não interrompe sua execução para executar outra de maior prioridade) 
(FARINES, FRAGA e OLIVEIRA, 2000). 
Escalonabilidade é um requisito não funcional do sistema que determina se 
este atenderá os requisitos temporais de todas as tarefas, mesmo no pior caso. 
O perfil MARTE, disponível na UML 2.0, é apropriado para modelar as 
características temporais em projetos de desenvolvimento de sistemas embarcados, 
pois suporta escalonamento, compartilhamento e análise de requisitos temporais. 
 
2.3 Sistemas Orientados a Eventos 
 
 Sistemas embarcados são essencialmente orientados a eventos, ou seja, 
esperam a ocorrência de um evento interno ou externo para executar o 
processamento apropriado. Sistemas orientados a eventos são também chamados 
de sistemas reativos. Estes sistemas são representados através dos seguintes 
modelos computacionais: tempo contínuo de evento discreto e tempo discreto. 
 
 
2.4 Sistemas de Supervisão e Controle 
18 
 
 
 
Sistemas de supervisão e controle são usualmente dedicados ao 
gerenciamento da execução de um processo ou de um objeto físico. 
Neste tipo de sistema é possível distinguir componentes, tais como: operador, 
sistema computacional de controle e o sistema a controlar. O sistema a controlar e o 
operador são considerados como ambiente do sistema computacional. A interação 
entre as partes ocorre através de interfaces de operador (FARINES, FRAGA e 
OLIVEIRA, 2000). A Fig. 3 mostra esses componentes em conjunto com elementos 
clássicos de um diagrama de controle. 
 
 Figura 2 – Sistema de Supervisão e Controle de tempo real. 
Fonte: (Romero; 2010, p12). 
 
 
2.5 Sistema de Controle 
 
Sistemas de controle são caracterizados por modelos computacionais 
baseados a eventos. 
O modelo computacional Síncrono/Reativo é utilizado para representar este 
tipo de sistema. Um modelo é síncrono reativo quando as saídas são sincronizadas 
com as entradas. Este modelo é caracterizado por possuir as seguintes abstrações: 
19 
 
• Forte sincronismo: partes do sistema respondem instantaneamente 
para as entradas. 
• Reatividade: sistema reage a ações externas 
• Memória limitada: sistema possui computação com memória limitada. 
Outro modelo computacional utilizado para representar sistemas de controle 
são as máquinas de estados finitas (MFS). Porém, as MFS clássicas não modelam 
concorrência. Para contemplar este aspecto, há extensões deste modelo como a 
Máquina de estados finita hierárquica e concorrente (HCFSM) capaz de representar 
hierarquia e concorrência. 
Segundo Wolf (2007) uma maneira de especificar o comportamento de uma 
operação é através de maquinas de estados. A UML utiliza o diagrama de máquina 
de estados para representar este tipo de modelo computacional. 
Através do diagrama de máquina de estados é possível visualizar a mudança 
entre um estado e outro pela ocorrência de um evento, com alto nível de abstração. 
Um evento é um tipo de ação. O evento pode ser uma ação externa do sistema, por 
exemplo, pressionar um botão, e pode ser uma ação interna do sistema como uma 
rotina, que quando finalizada envia o resultado para outra rotina. Os estados da 
máquina de estados representam diferentes operações. A divisão de operações 
complexas em diversos estados ajuda a documentar passo a passo os requisitos, 
bem como as sub-rotinas que podem ser utilizadas para a estrutura do código (Wolf, 
2008). Com o diagrama de seqüência também é possível representar estes modelos 
computacionais. 
 
 
 
 
 
 
 
 
 
 
 
 
20 
 
3 LINGUAGENS PARA MODELAGEM DE SISTEMAS EMBARCADOS 
O presente capítulo apresenta conceitos básicos da linguagem de modelagem 
UML, utilizada para modelagem de software de propósito geral, e que atraiu o 
interesse da comunidade de sistemas embarcados. Além da UML, este capítulo 
revisa a linguagem SysML e MARTE, duas extensões da UML propostas para 
especificação de requisitos e modelagem de sistemas embarcados de tempo real, 
respectivamente. 
 
3.1 UML 
 
A UML é uma linguagem visual para especificação, construção e 
documentação de artefatos do sistema (OMG, 2009 a). UML é uma linguagem 
padrão para modelagem de software de propósito geral. Esta linguagem proporciona 
ao usuário visões de alto nível de abstração do sistema. Tais visões são possíveis 
através do conjunto de diagramas disponíveis. Conforme a Fig. 3, a UML 2.0 
suporta treze diagramas que estão divididos em duas categorias: Diagramas 
Estruturais e Diagramas Comportamentais. 
 
 
 
Figura 3 – Diagramas da UML 2.0 
 
21 
 
Segundo Fowler (2004), a visão estrutural do sistema se dá a partir dos 
diagramas: 
• Diagrama de Classe: é um dos artefatos da UML para representar o 
modelo de negócio, onde os principias conceitos da aplicação são 
representados por classes. Este diagrama descreve os tipos de 
objetos presentes no sistema e os vários tipos de relacionamentos 
estáticos entre eles. Também representa as propriedades e as 
operações de uma classe e as restrições que se aplicam à maneira 
como os objetos estão conectados. 
• Diagrama de Componentes: representa os vários componentes de 
software de um sistema, além das dependências entre eles. 
• Diagrama de Objetos: representa os objetos do sistema em um 
determinado ponto no tempo. 
• Diagrama de Estrutura: permite decompor hierarquicamente uma 
classe em uma estrutura interna. Possibilitaque um objeto complexo 
seja dividido em partes. 
• Diagrama de Instalação: representa o layout físico de um sistema, 
revelando quais partes do software são executadas em quais partes do 
hardware. 
• Diagrama de Pacotes: representa os pacotes e suas dependências. 
Este diagrama é útil em sistemas de grande porte, para obter uma 
visão das dependências entre os principais elementos de um sistema. 
Já a visão comportamental do sistema, segundo Fowler (2004), é 
representada a partir dos diagramas: 
• Diagrama de Atividade: é uma técnica para descrever a lógica de 
procedimento, processo de negócio e o fluxo de trabalho. Esse 
diagrama suporta o comportamento paralelo. 
• Diagrama de Casos de Uso: é uma técnica utilizada para capturar os 
requisitos funcionais de um sistema. Possibilitam descrever as 
interações típicas entre os usuários de um sistema e o próprio sistema, 
fornecendo uma narrativa sobre como o sistema é utilizado. 
• Diagrama de Máquina de Estados: representa o comportamento de um 
objeto por intermédio de vários casos de uso. 
22 
 
• Diagrama de Interação: é uma mistura de diagrama de atividade e 
diagrama de seqüencia. Esse diagrama pode ser considerado como 
diagrama de atividade nos quais as atividades são substituídas por 
pequenos diagramas de seqüencia ou como um diagrama de 
seqüencia fragmentado, com a notação de digrama de atividades 
usada para representar o fluxo de controle. 
• Diagrama de Seqüencia: captura a seqüencia de processos. Este 
diagrama é usado para representar os objetos e mensagens que são 
passadas entre esses objetos dentro de um caso de uso. 
• Diagrama de Temporização: é outra forma de diagrama de interação. 
Esse diagrama é utilizado para mostrar restrições de tempo entre 
mudanças de estado em diferentes objetos. 
• Diagrama de Comunicação mostra de maneira semelhante ao 
diagrama de seqüência, a colaboração dinâmica entre os objetos. Se a 
ênfase do diagrama for o decorrer do tempo, a melhor escolha é o 
diagrama de seqüência, mas se a ênfase for o contexto do sistema, 
vale priorizar o diagrama de comunicação. 
UML é uma linguagem genérica que pode ser usadas para modelar diferentes 
tipos de sistemas. No entanto, a generalidade faz com que a UML não suporte a 
modelagem de alguns aspectos específicos em um determinado domínio de 
aplicação, motivando a definição de linguagens de domínio específico. Para atender 
esta demanda, a UML oferece mecanismos de extensão através da criação de perfis 
específicos para um dado domínio de aplicação. 
 
 
3.1.1 Uso da UML na modelagem de Sistemas Embarcados 
 
O projeto de desenvolvimento de software embarcado é distinto do 
desenvolvimento de software de propósito geral. Sistemas embarcados possuem 
requisitos relevantes como: consumo de potência e energia, desempenho, tamanho, 
peso, memória, restrições de tempo, custo de projeto, entre outras. 
 Para lidar com projetos complexos, linguagens de alto nível de abstração têm 
sido utilizadas, pois tais linguagens abstraem detalhes desnecessários tornando fácil 
tanto a verificação como a validação, facilitando a reusabilidade e a evolução desses 
23 
 
sistemas complexos. Uma linguagem que se destaca é a UML possivelmente pelos 
perfis especializados em um domínio específico. 
Um perfil é um mecanismo padronizado pela OMG para criação de linguagens 
de modelagem de domínio específico, eles refinam os conceitos existentes de uma 
linguagem padrão, como a UML. 
No domínio de sistemas embarcados, o suporte à descrição de 
comportamentos heterogêneos (hardware/software e diferentes modelos de 
computação) e a especificação de requisitos não-funcionais são exemplos de 
necessidades específicas do domínio. Os perfis aplicados a estas características são 
SysML e MARTE. 
SysML e MARTE consideram características no domínio de sistemas 
embarcados em diferentes níveis de abstração, arquitetural e especialmente para 
fins específicos ou áreas de aplicação. SysML possibilita a rastreabilidade de 
requisitos, estrutura e comportamento do sistema de blocos, bem como formalismo 
paramétrico para especificar equações, enquanto MARTE trata de tempo real e 
aspectos de recursos limitados, inclui uma taxonomia detalhada de hardware e 
padrões de software juntamente com os requisitos não funcionais para permitir 
análise quantitativa (desempenho, consumo energético). 
 
 
3.2 SysML 
 
SysML é uma linguagem de modelagem gráfica de propósito geral que 
suporta especificação, análise, projeto, verificação e validação de sistemas 
complexos. Estes sistemas podem incluir hardware, software, informação, 
processos, pessoas e infra-estrutura (OMG, 2011a). 
Como indicado na Fig. 4, SysML reutiliza um subconjunto da UML e adiciona 
extensões para atender aos requisitos da UML SE RFP (System Engineering 
Request for Proposal) (OMG, 2011a). O subconjunto da UML reutilizado pela SysML 
é chamado de UML4SysML. Alguns diagramas da UML foram alterados para 
SysML e outros não sofreram alterações, como o diagrama de casos de uso, 
diagrama de máquina de estados. 
 
24 
 
 
 
Figura 4 – Sobreposição entre UML2.0 e SysML 
Fonte: (OMGa; 2010, pg.31) 
 
SysML não é metodologia ou ferramenta para desenvolvimento de software. 
SysML é uma linguagem gráfica que disponibiliza semântica (significado) e notação 
(representação do significado) para modelagem de software. 
O diagrama apresentado na Fig. 5 ilustra as modificações ocorridas nos 
diagramas reutilizados da UML 2.0, bem como os novos diagramas da SysML. Os 
diagramas são classificados em três classes: comportamentais, estruturais e de 
requisitos. 
 
 
 
 
 
 
 
 
 
 
 
 
Diagramas 
SysML 
Diagramas 
Comportamentais 
Diagrama 
de 
Atividade 
Diagramas 
Estruturas 
Diagrama 
de 
Sequenci
Diagrama 
de 
Máquina 
Diagrama 
de Caso 
de Uso 
Diagrama 
de 
Blocos 
Diagrama 
de Bloco 
Interno 
Diagrama 
de Pacote 
Diagrama 
Paramétrico 
Diagrama 
de Requisitos 
25 
 
 
 
 
Figura 5 – Diagramas da linguagem SysML 
Fonte: (OMGa; 2010, p.180) 
 
As construções estruturais definem os elementos estáticos e de estruturas 
utilizados em SysML. Diagramas que incluem essas construções são: o diagrama de 
pacotes, o diagrama de blocos, o diagrama de bloco interno e o diagrama 
paramétrico. As estruturas das construções são definidas através de: elementos de 
modelos (recapturados do núcleo de pacotes da UML 2.0 e incluem extensões para 
prover capacidades de fundamentação e gerenciamento de modelos); os de blocos 
(reusam e estendem a estrutura de classes da UML 2.0 para prover a capacidade 
funcional para descrever estrutura de qualquer elemento do sistema, como: 
hardware, software, dados, processos. Também é possível descrever as 
características de bloco, como: propriedades, operações, restrições, alocação, 
requisitos que o bloco satisfaz); portas e fluxos (provem a semântica para definir 
como blocos e partes interagem através de portas e como e quais itens fluem 
através delas); blocos de restrições (definem como os blocos são estendidos para 
serem usados sobre diagramas paramétricos que modelam a rede de restrições 
sobre as propriedades de um sistema, para dar suporte a análise de desempenho e 
outros). 
As partes dinâmicas utilizadas nos diagramas de comportamento da SysML 
são especificadas pelas construções comportamentais, através dos diagramas: o 
diagrama de atividades (utilizado para descrever o fluxo de controle e o fluxo de 
entradas e saídas entre as ações), o diagrama de seqüência, o diagrama de 
máquina de estados e o diagrama de casos de uso. As construções 
comportamentais, utilizadas nos diagramas, são separadas em: atividades (definidas 
na UML 2.0 com algumas extensões); interações (ondesão definidas as construções 
para o comportamento baseado em mensagens usado no diagrama de seqüência); 
máquinas de estados (usadas para descrever o comportamento de um sistema 
baseado em seus estados e suas transições); e casos de uso (que descreve o 
comportamento e a utilização de um sistema em termos da sua funcionalidade de 
alto nível). 
 
 
 
Sem alteração 
Alterados a partir da UML 2.0 
Novos diagramas 
26 
 
Já as construções cruzadas (crosscutting) são aplicadas nas construções 
estruturais e comportamentais. Essas construções são definidas em: alocações 
(representam as relações que mapeiam um elemento do modelo a outro) 
Segundo Espinoza (2010) a SysML apresenta as seguintes contribuições: 
• Organização Arquitetural - Incluem conceitos de modelagem para 
organizar descrições da arquitetura de sistemas, definidas pelo padrão 
IEEE 1471. Dentre eles, os conceitos de View, viewpoint e rationale 
são os mais importantes. 
• Blocos e Fluxos - descrição e diagrama de blocos internos permitem a 
especificação de interações genéricas e fenômenos existentes em 
software. Isto inclui fluxos físicos como os líquidos, energéticos e 
elétricos. As dimensões e unidades de medida de tais fluxos físicos 
podem ser definidas explicitamente (ex. litros, watts) 
• Comportamentais - diagramas comportamentais são similares ao da 
UML (interação, máquina de estados, atividades e casos de uso). 
SysML refina o diagrama de atividade para a modelagem de modelos 
contínuos e probabilidades. 
• Requisitos – SysML dispõe de uma modelagem facilitada para os 
requisitos do sistema, bem como rastreabilidade quanto à evolução do 
sistema. Os requisitos podem ser representados no formato gráfico ou 
tabular. 
• Parâmetros – o diagrama paramétrico permite descrever em SysML, de 
maneira gráfica, relacionamentos analíticos e restrições, bem como 
equações matemáticas. 
A utilização de SysML no projeto de sistemas complexos apresenta benefícios 
como: 
• Abstração de detalhes; 
• Linguagens formais como SysML e UML reduzem ambigüidade e 
erros, pois fornecem notações precisas que minimizam os erros de 
interpretação. As alocações e requisitos disponibilizam mecanismos 
que garantem a consistência e complexidade do modelo. 
• Alinhamento entre hardware e software proporcionando a reusabilidade 
e agilidade no desenvolvimento de sistemas. 
27 
 
• O uso de modelos em um sistema facilita o entendimento da equipe 
que normalmente é composta por diferentes perfis e com o cliente. 
• SysML possibilita o rastreamento de requisitos, apoiando assim a 
gerencia de mudanças necessárias durante o desenvolvimento do 
projeto. 
 
3.2.1 Diagrama de Requisitos 
 
Um requisito especifica uma funcionalidade ou condição que deve ser 
satisfeita pelo sistema, ou seja, uma função que um sistema deve executar ou uma 
condição de desempenho que um sistema deve alcançar. Conforme Friedenthal et. 
al (2008) o que a engenharia clássica busca é que o requisito tenha as seguintes 
características: não seja ambíguo, seja compreensivo, correto, conciso, tenha 
rastreabilidade e verificáveis. 
Os requisitos normalmente têm origem distinta. No nicho de embarcados, vale 
citar o exemplo do desenvolvimento de um aparelho celular, onde, normalmente a 
solicitação é feita pela equipe do departamento de marketing da empresa. Essa 
equipe fornece as características necessárias do produto para a equipe de 
desenvolvimento de software, sendo que, tais características devem superar as 
expectativas do público alvo, portanto, neste cenário são vários stakeholders 
fornecendo informações do produto. Para isso é necessário assegurar que os 
requisitos são consistentes (não contraditórios) e viáveis, e refletem adequadamente 
as necessidades dos envolvidos. 
O diagrama de requisitos permite representar os requisitos, que usualmente 
são expressos em linguagem texto, de forma gráfica. O diagrama também permite 
relacionar estes requisitos a outros elementos do modelo do sistema (tais como um 
caso de teste, ou um componente do software). Este diagrama representa as 
hierarquias e derivações existentes nos requisitos, que possibilitam associar um 
determinado requisito a outro modelo tornando visível o rastreamento dos requisitos. 
O diagrama de requisitos ilustrado na Fig. 6 representa um exemplo genérico de 
diagrama de requisitos para um sistema automotivo. Nesse exemplo, são 
apresentados diferentes relacionamentos entre os requisitos e notações alternativas, 
como: o bloco câmera deve satisfazer requisito chamado Sensor Decision, também 
28 
 
inclui três tipos de relacionamentos: satisfy, verify, deriveReqt, além de apresentar a 
hierarquia. 
 
Figura 6 – Diagrama de requisitos. 
Fonte: Friedenthal; Moore;Steiner; (2008),p.286) 
Em SysML as relações entre os requisitos e de requisitos para outros 
elementos da modelagem, de projeto, ou casos de teste são descritas usando um 
conjunto de estereótipos. As relações dos requisitos são representadas pelos 
estereótipos: containment (representa a hierarquia dos requisitos), derive (usado 
para representar que um requisito é derivado de outro requisito base), satisfy 
(modelo de elemento satisfaz o requisito), verify (representa o caso de teste que 
verifica o requisito), refine (representa o elemento do modelo que esclarece um 
requisito, tipicamente é um caso de uso ou um diagrama comportamental), trace 
(relaciona o requisito ao elemento do modelo que representa a origem do requisito) 
e copy (refere-se a uma cópia do seu requisito original). Esses relacionamentos 
podem ser utilizados para suportar a rastreabilidade com alto grau de granularidade. 
A Fig. 6 mostra alguns desses relacionamentos. 
O estereótipo Rationale é um modelo de elemento SysML para anotação que 
pode ser associado com qualquer requisito ou relacionamento entre requisitos. É 
uma notação SysML que destina-se a identificar um problema que precisa ser 
resolvido. O comentário feito a partir do Rationale pode referir-se a um documento 
externo ou outro elemento do modelo bem como a um diagrama paramétrico. 
29 
 
Conforme ilustrado na Fig. 6, os requisitos são apresentados de forma gráfica 
no diagrama de requisito. Neste diagrama, um requisito é representado por um 
retângulo com a palavra chave <<Requirements>> seguida pelo nome do requisito. 
As propriedades mínimas dos requisitos são: id (identificação), Text (texto que 
descreve as características do requisito). Conforme Friedenthal (2008), os requisitos 
podem conter propriedades adicionais como status da verificação, criticidade, risco e 
categoria de um requisito. Para status da verificação, um requisito pode estar 
assinalado como não verificado (not verified), verificado pela inspeção (verified by 
inspection), verificado pelo analista (verified by analysis), verificado pela 
demonstração (verified by demonstration) ou verificado pelo teste (verified by test). 
Quanto ao nível de criticidade ou risco, um requisito pode ser assinalado como de 
alto, médio ou baixo risco. Por fim, podemos categorizar os requisitos como 
funcionais (Functional), de desempenho (Performance) ou físicos (Phisycal). O 
Diagrama de Requisitos também pode ser representado de forma tabular, conforme 
a Tabela 1: 
Tabela 1 – Diagrama de Requisitos. 
 
id 
name text 
1 
Autonomia O sistema deve apresentar quantos km o 
automóvel pode percorrer com o combustível 
restante, conforme a velocidade do automóvel. 
1.1. 
Velocidade O sistema deve apresentar a velocidade atual 
do automóvel. 
 
Em SysML é permitido criar categorias de requisitos definindo subclasses 
adicionais de estereótipos de requisitos. Um estereótipo permite adicionar restrições 
que limitem um tipo específico de modelo para que um determinado requisito seja 
satisfeito. Por exemplo, um requisitofuncional pode ser restrito de forma que só 
pode ser satisfeito por um elemento do modelo comportamental como: atividade ou 
máquina de estados. 
A Tab. 2 mostra as categorias de estereótipos genéricos para 
<<requiremet>>. 
Tabela 2 – Categoria de estereótipos genéricos para <<requirement>>. 
30 
 
Esterótipo Restrição Descrição 
<<extendrequirent>> N/A Uma mistura de 
estereótipo que contém 
atributos geralmente 
usados para os 
requisitos. (ex. Risk, 
verifyMethod) 
<<functionrequirement>> Deve ser satisfeito 
por uma operação 
ou comportamento. 
Requisitos que 
especificam uma 
operação ou 
comportamento que o 
sistema ou parte do 
sistema devem 
desempenhar. 
<<interfacerequirement>> Deve ser satisfeito 
por uma porta, 
conector, fluxo, 
e/ou propriedade 
restritiva. 
Requisito que 
especificam as portas 
para conectar sistemas e 
partes do sistema e que, 
opcionalmente, pode 
incluir o item que flui 
através do conector e / ou 
restrições da interface. 
<<performancerequirement>> Deve ser satisfeito 
por uma 
propriedade de 
valor 
Requisito que 
quantitativamente mede o 
grau em que um sistema, 
ou uma parte do sistema, 
satisfaz uma condição ou 
capacidade necessária. 
<<physicalRequirement>> Deve ser satisfeito 
por um elemento 
estrutural 
Requisitos que 
especificam 
características físicas 
e/ou restrições físicas dos 
sistemas, ou de uma 
31 
 
parte do sistema. 
<<designConstraint>> Deve ser satisfeito 
por um bloco ou 
parte 
Requisito que representa 
uma restrição na 
implementação do 
sistema ou parte do 
sistema, tal como “o 
sistema deve utilizar o 
componente comercial 
off-the-shelf” . 
 
Diagrama de requisitos propicia a visualização gráfica dos requisitos do 
sistema, tornando fácil o entendimento dos mesmos. Este diagrama permite modelar 
requisitos, estrutura, comportamento e parâmetros para prover uma descrição 
robusta do sistema, seus componentes e ambientes. 
 
 
3.2.2 Diagrama Paramétrico 
 
O diagrama paramétrico representa restrições nos valores de propriedade do 
sistema tais como desempenho, confiabilidade, propriedades maciças, e serve como 
meio para integrar os modelos das fases de especificação e projeto com modelos da 
fase de análise (LINHARES, 2006). Um diagrama paramétrico é tipicamente utilizado 
em sistemas com funcionalidades matemáticas por representar com precisão 
fórmulas matemática. 
Os modelos paramétricos capturam as propriedades restritivas do sistema, 
para serem analisadas por ferramentas de análise apropriadas. As restrições são 
apresentadas por equações, cujos parâmetros estão vinculados às propriedades do 
sistema (FRIEDENTHAL, MOORE, STEINER, 2008). Este diagrama é identificado 
pela palavra chave par. 
A SysML introduz bloco de restrições para suportar a construção de modelos 
paramétricos. Um bloco de restrição é um tipo especial usado para definir equações. 
Tal bloco é definido livre de contexto, permitindo a criação de uma biblioteca de 
restrições que pode ser facilmente reutilizada em vários projetos. 
32 
 
SysML inclui o conceito de restrições que podem corresponder a qualquer 
expressão matemática ou lógica, incluindo expressões com variáveis temporais e 
equações diferenciais. SysML não especifica uma linguagem de restrições, mas 
permite que a linguagem seja especificada como parte da definição das restrições 
(FRIEDENTHAL, MOORE e STEINER, 2008). Como mostra a Fig. 7 diferentes 
notações são usadas em SysML para representar as restrições das propriedades de 
blocos. O bloco 1, da Fig. 7 possui um compartimento explicito para restrições, neste 
caso, expressas em Java, enquanto que o bloco 2 possui a conexão com uma nota, 
que expressa a restrição usando a linguagem MATLAB, uma ferramenta 
especializada de análise (FRIEDENTHAL, MOORE e STEINER, 2008). 
 
Figura 7 – Diagramas de blocos representando as restrições do sistema. 
Fonte: (Friedenthal; Moore;Steiner; (2008),p.152) 
Um bloco de restrição define um conjunto de parâmetros relacionado uns aos 
outros pela expressão de restrição. Estes parâmetros podem ter tipos, unidades, 
dimensões e distribuições de probabilidade. Para facilitar tipos específicos de análise 
(de desempenho, propriedades físicas, etc.), blocos de restrição podem ser definidos 
nas bibliotecas modelo. 
No contexto de análise, outro conceito importante do diagrama paramétrico, é 
um bloco que fornece o contexto para o sistema ou componente sujeito a análise. O 
contexto de análise é composto pelos blocos de restrição que correspondem ao 
modelo de análise e referências do sistema analisado. Um diagrama paramétrico, do 
qual a estrutura representa o contexto de análise, é usado para vincular as 
propriedades relevantes do bloco e os parâmetros do modelo de análise. O contexto 
de análise pode ser passado para uma ferramenta de análise de engenharia para 
realizar a análise computacional, e os resultados analíticos podem ser fornecidos de 
33 
 
volta como propriedades do contexto de análise (FRIEDENTHAL, MOORE e 
STEINER, 2008). 
 
3.3 MARTE 
 
A UML tem sido adotada como uma linguagem de modelagem de propósito 
geral. No entanto, a UML não possui suporte para modelar aspectos como: tempo, 
escalonamento ou desempenho. Sendo assim, a primeira alternativa para tratar essa 
deficiência foi a definição do perfil SPT (UML Profile for Schedulability, Performance 
and Time Specification) (ROMERO, 2010). Este perfil fornecia conceitos para análise 
de escalonabiliade, análise de desempenho, além de permitir a modelagem de 
aspectos temporais. Porém, no perfil SPT havia restrições quanto à modelagem 
temporal, pois se baseava em anotações no modelo. Sendo assim, a OMG definiu 
um novo perfil, que ficou conhecido como MARTE (OMG, 20011b). A contribuição do 
perfil MARTE esta no seu modelo de tempo, enriquecendo a UML com elementos de 
modelo explícitos para representar tais modelos (relógios, tipos de clocks, etc.) 
(PERALDI-FRATI e SOREL, 2008) 
MARTE é um perfil da UML dedicado à modelagem de Tempo Real de 
Sistemas Embarcados. Este perfil aborda o projeto de sistemas embarcados no 
âmbito de hardware e software; alocação de elementos; análise de escalonabilidade 
e desempenho; especificação de características de sistemas embarcados, como 
tamanho de memória e consumo energético; suporte a arquiteturas baseadas em 
componentes; outros paradigmas computacionais, como assíncrono e síncrono 
(WEHMEISTER, 2009). 
Os sistemas embarcados de tempo real possuem características como: 
deadlocks e período da execução de uma tarefa que devem ser atendidas conforme 
especificado. MARTE disponibiliza conceitos necessários para modelar plataformas 
de hardware e software para executarem aplicações embarcadas de tempo real. 
Incluindo suporte para a modelagem de hardware (memória, processadores, canais 
de comunicação e outros) e aspectos de software como tempo real do sistema 
operacional. O conceito de alocação é usado para indicar que um elemento da 
aplicação está alocado em um elemento da plataforma. 
Segundo André et. al. (2007), MARTE é apropriado para representação 
temporal de natureza física ou lógica. Sendo que o tempo físico é contínuo e pode 
34 
 
ser discretizado em relógios cronométricos, enquanto que o tempo lógico é menos 
reconhecido nos conceitos de modelagem explicitas. Um exemplo de tempo lógico, 
para André et. al. são os processamentos e as etapas de execução realizada à taxa 
de um ciclo do processador (que pode variar de acordo com o consumo de energia), 
ou disparado por ocorrências sucessivas de um evento externo (tais como 
características da engenharia de um motor). 
MARTE consiste na definição de modelos de tempo real para sistemas 
embarcados, no qual inclui conceitos para modelagem e análise (BRISOLARA, 
KREUTZ,e CARRO, 2009). O suporte a modelagem prove mecanismos 
(estereótipo) para detalhar o projeto de tempo real e as características de tempo real 
da aplicação, permitindo a especificação de requisitos não funcionais, tempo, e 
recursos gerais e de alocação. Para o suporte ao modelo de análise, MARTE 
disponibiliza facilidades para anotar os modelos com as informações necessárias 
para realizar uma análise específica. 
Segundo Espinoza et. al (2009), em relação à UML, MARTE adiciona os 
seguintes recursos: 
• NFPs: Uma estrutura com suporte a modelagem de requisito não 
funcionais (NFPs, do inglês, Non Functional Requirements) 
proporciona especificar semanticamente propriedades não-funcionais 
(por exemplo: atrasos e uso de memória). 
• Tempo: É um modelo altamente refinado de tempo e integram 
conceitos de mecanismos de tempo a partir de diferentes subdomínios 
em projetos de sistemas embarcados, tal como tempo casual, tempo 
síncrono e tempo cronométrico. 
• Aplicação de software: Um modelo comum de computação que prove 
suporte à semântica para paradigma de objeto de tempo real. Este 
paradigma permite especificação de aplicação com alto nível de 
abstração, por simultaneidade, comunicação e aspectos de restrições 
de tempo para modelar uma unidade chamada real-time unit (RrUnit). 
• Componentes: O modelo de componentes de MARTE estende a UML. 
• Recursos Hardware/Software: Recursos de hardware e software 
podem ser descritos em diferentes níveis de abstração, incluindo seus 
35 
 
serviços, como os das plataformas comuns de SO, e propriedades não 
funcionais comuns como consumo de energia ou uso de memória. 
• Análise quantitativa: Um conjunto pré-definido de anotação não 
funcional permite que os modelos em MARTE sejam a ligação com o 
estado da arte de ferramentas desempenho e de análise. 
Em MARTE são integrados conceitos para tempo e comportamento, que são 
fortemente utilizados no domínio de sistemas embarcados. Neste perfil três 
abstrações diferentes de tempo podem ser utilizadas para representar os fluxos de 
comportamento temporais, que são: 
• Casual/temporal. A relação de precedência/dependência é utilizada 
para determinar o comportamento. 
• Relógio/síncrono. Adiciona a notação de simultaneidade e divide a 
estala do tempo em uma sucessão discreta de instantes. Esta classe 
de abstração do tempo pode ser usada para modelagem de hardware 
e software. 
• Físico/tempo real. Oferece uma forma de especificar a modelagem 
precisa de tempo real, para escalonamento das questões críticas do 
sistema. Este modelo, também pode ser aplicado para o modelo 
síncrono, por exemplo, para obter a velocidade admissível de uma 
reação. 
 MARTE é um perfil da UML composto por diversos pacotes, conforme pode 
ser observado na Fig. 8, os quais proveem conceitos adaptados para modelagem e 
análise de sistemas embarcados e de tempo real. 
O perfil MARTE é estruturado sob duas questões, uma para modelar as 
características de sistemas de tempo real e embarcados e outra para anotar 
modelos de aplicação, de modo a apoiar a análise das propriedades do sistema. 
Estas questões são mostradas no pacote RTEM chamado "MARTE design model", 
conforme a Fig. 8. Estas duas questões principais compartilham características 
comuns com a descrição do tempo e o uso de recursos simultâneos, que estão 
contidos no pacote compartilhado chamado “Marte Foundations". Estas duas partes 
principais compartilham conceitos comuns como a descrição do tempo e o uso de 
recursos simultaneamente, os quais estão contidos no pacote chamado “MARTE 
Foundations”. Os recursos para “Analysis Modeling” são divididos em fundamentos 
genéricos no pacote GQAM, e outros dois pacotes para domínios de análise 
36 
 
específica. Estes dois primeiros domínios de análise específica são inteiramente 
focados no tempo, no entanto, a estrutura do perfil permite incluir domínios de 
análises adicionais, tais como consumo de energia, uso de memória, ou 
confiabilidade (OMG, 2011b). 
 
Figura 8 – Pacote RTEM 
Fonte: (OMGb; 2011, pg. 25) 
O perfil MARTE é a extensão padrão definida para a modelagem de sistemas 
embarcados e de tempo real. Este perfil foi uma evolução do perfil UML-SPT 
(ROMERO, 2010), anteriormente adotado pela OMG para a modelagem de sistemas 
de tempo real. Esta evolução inclui a parte de modelagem de hardware, não 
suportada pelo UML-SPT. MARTE propõe novos estereótipos o perfil também 
propõe a anotação de valores que representam aspectos temporais. 
 
 
 
 
 
 
 
 
 
 
 
 
37 
 
 
4 TRABALHOS RELACIONADOS 
 
Neste capitulo são apresentados os trabalhos relacionados a este estudo. 
Uma avaliação da SysML foi realizada por Linhares, Silva e Oliveira (2006) 
onde os autores concluíram que SysML permite que os engenheiros de sistemas 
descrevam um sistema em alto nível de abstração, considerando simultaneamente 
componentes de software e hardware. 
O artigo de Espinoza et al. (2009), apresenta estratégias para combinação 
dos perfis MARTE e SysML em um contexto comum de modelagem, evitando 
conflitos nas especificações. Também mostram que apesar do overlapping de 
semântica e sintaxes esses dois perfis são altamente complementares. O artigo 
reúne um conjunto de cenários que julgam serem relevantes para o domínio de 
sistemas embarcados, apresentando os conflitos existentes nesses cenários, 
autores sugerem algumas alterações para combinação dos perfis em tais cenários. 
Em Dubois et. al. (2010), o artigo propõem o metamodelo, DARWIN4Req, 
para rastreabilidade de requisitos. Tal metamodelo esta baseado em três fluxos 
independentes, que são: modelo de requisitos, modelo da solução e modelo 
Validação &Verificação. O metamodelo DARWIN4Req estabelece um link entre os 
fluxos e permite total rastreabiliade dos requisitos incluindo modelos heterogêneos. 
Em Peraldi-Frati et al. (2008) foi apresentada a modelagem e a análise de 
sistemas de tempo real, em diferentes fases do projeto. Para a especificação das 
características temporais e estruturais do sistema, bem como a representação do 
hardware, foi utilizado o perfil MARTE em conjunto com a linguagem CCSL. 
Em Kangas et al. (2006), o artigo descreve um fluxo de projeto completo para 
múltiplos sistemas em chips (SoC), abrangendo as fases de concepção da 
modelagem do sistema para protótipos FPGA. O projeto de sistemas heterogêneos é 
aumenta o nível de abstração e fornece diversas ferramentas de automação de 
projeto. O sistema é modelado em um ambiente de projeto UML seguindo um perfil 
UML que especifica as práticas para a aplicação e modelagem da arquitetura. As 
ferramentas de fluxo de projeto são regidas num framework único, que combina as 
ferramentas em um fluxo contínuo e possibilita a visualização do processo do 
projeto. Novas características incluem a exploração arquitetura automatizadas 
baseada nos modelos do sistema descrito em UML, bem como automatização e 
38 
 
anotação das informações no fluxo de projeto. A exploração arquitetura baseia-se na 
otimização global dos sistemas que são compostos de subsistemas, os quais são 
localmente otimizados para os seus fins específicos. Como resultado, o fluxo de 
projeto produz um componente de alocação otimizado, o mapeamento de tarefa e 
escalonabilidade para a aplicação descrita. Além disso, o fluxo suporta a 
implementação de todo o sistema em FPGA. 
A contribuição deste trabalho é apresentar as diferenças entre as linguagens 
de modelagem SysML e MARTE, avaliando os recursos que estas oferecem aos 
desenvolvedores de sistemas embarcados. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
39 
 
 
5 CONCLUSÕES 
 
Este trabalho apresentou um estudosobre a modelagem de sistemas 
embarcados usando modelos de alto nível de abstração. O trabalho apresenta 
primeiramente fundamentos sobre o projeto e modelagem de sistemas embarcados, 
para então apresentar abordagens de modelagem para estes sistemas. 
As abordagens estudadas baseiam-se na linguagem UML e suas extensões 
usadas na área de sistemas embarcados, o SysML e o MARTE, os quais são dois 
perfis da UML padronizados pela OMG. Este estudo analisou os principais recursos 
oferecidos pelos dois perfis para a modelagem de sistemas embarcados, bem como 
suas limitações. 
Devido às diversas variações das aplicações para sistemas embarcados 
pode-se concluir que o uso combinado dos dois perfis é possível obter uma 
modelagem de alto nível adequada, que inclui tanto a modelagem detalhada de 
requisitos, bem como a modelagem completa de requisitos temporais. Nosso estudo 
demonstrou que o diagrama de requisitos do SysML pode ser usado para a 
representação gráfica de requisitos de uma aplicação embarcada e que as classes 
estereotipadas com recursos do MARTE podem ser usadas para a modelagem de 
requisitos de tempo real em um sistema embarcado. 
Como trabalhos futuros, planejamos estender este estudo através da 
realização de um estudo de caso mais completo de modelagem de um sistema 
embarcado, primeiramente só usando SysML, depois usando somente MARTE, e 
posteriormente usando ambas linguagens combinadas. 
 
 
 
 
 
 
 
 
 
 
40 
 
REFERÊNCIAS 
 
 
ANDRÉ, C.; MALLET, F.; SIMONE. R. Time modeling in MARTE. ECSI Forum on 
specification & Design Languages, p. 268-273, 2007. 
 
 
BRISOLARA, L.; KREUTZ, M.; CARRO, Luigi. UML as front-end language for 
embedded systems design. Luis Gomes; João M. Fernandes. (Org.). Behavioral 
Modeling for Embedded Systems and Technologies: Applications for Design and 
Implementation. v. , p. 244-266, 2009. 
 
 
DUBOIS, H.; PERALTI-FRATI. M.; LAKHAL, F. A model for requirements traceability 
in an heterogeneous model-based design process. Application to automotive 
embedded systems. IEEE Int. Conf. on Engineering of Complex Computer Systems. 
v.15, 19 p, 2010. 
 
 
ESPINOZA, H.; CANCILA, D.; SELIC, B.; GÉRARD, S. Challenges in Combining 
SysML and MARTE for Model-Based Design of Embedded Systems. Springer. 2009. 
 
 
FARINES, J. M.; FRAGA, J. S.; OLIVEIRA, R. S.. Sistemas de Tempo Real.. v.1, 201 
p, 2000. 
 
 
FOWLER, M. UML Essencial. Um breve guia para linguagem-padrão de modelagem 
de objetos. 3 ed, 160p, 2005. 
 
 
FRIEDENTHAL, S.; MOORE, A.; STEINER, R. A. Practical Guide to SysML: 
Systems Model.v., 560.p. 2008. 
 
 
KANGAS, T.; KUKKALA, P.; ORSILA, H.; SALMINEN, E.; HANNIKAINEN, M.; 
HAMALAINEN, T. UML-Based Multiprocessor SoC Design Framework. Transactions 
in Embedded Computing Systems. v. 5(2), p. 281-320, 2006. 
 
 
LINHARES, M.; SILVA, A.; OLIVEIRA, R. Avaliação da da SysML através da 
modelagem de uma unidade experimental de automação industrial. XII CBA – 
Congresso Brasileiro de Automação, 2006. 
 
 
MATTOS, J.; BRISOLARA, L. Desafios no Projeto de Sistemas Embarcados. 
MATTOS, J; ROSA, L; PILLA, M. Desafios e Avanços em Computação: o estado da 
arte. v., p. 153-175, 2009. 
 
41 
 
MARWEDEL, P., Embedded Systems Design. Dordrecht, The Netherlands: Springer, 
2006. 
 
 
OMG. (2011a) SysML. Disponível em: http://www.omgsysml.org/. Acesso em: 
Outubro, 2011. 
 
 
OMG. (2011b) UML Profile for MARTE. Disponível em: 
http://www.omg.org/spec/MARTE/1.1/. Acesso em: Outubro, 2011. 
 
 
PERALDI-FRATI, M.; SOREL, Y. From high-level modeling of time in MARTE to real-
time scheduling analysis. In MoDELS’08 W. on Model Based Architecting and 
Construction of Embedded Systems on ACESMB, p.129–143, 2008. 
 
 
ROMERO, A. Uma Abordagem em Arquitetura Conduzida por Modelos e Aplicada a 
Software de Tempo Real Espacial. Dissertação de Mestrado. Instituto Nacional de 
Pesquisas Espaciais. 203 p., 2010. 
 
 
WEHRMEISTER, M. A. An aspect-oriented model-driven engineering approach for 
distributed embedded real-time systems. 2009. 206 p. Tese (Doutorado) – 
Universidade Federal do Rio Grande do Sul, Porto Alegre, Brasil. 
2009. 
 
 
WOLF, W. Computers as components: principles of embedded computing system, 
v.2, p.1-53, 2008. 
 
 
WOLF, W. High-Performance Embedded Computing. Architectures, Applications, 
and Methodologies.v.,p.1-63, 2007.