Linguagens de Modelagem para SMA Viviane Torres da Silva [email protected] viviane.silva/isma.
Estudo Das Linguagens Para Modelagem de Sistemas Embarcados
42
UNIVERS Centro d Estudo das Lin M i l e SIDADE FEDERAL DE PEL CDTec de Desenvolvimento Tecnoló Trabalho Acadêmico Titulo nguagens para Modelagem de Sistema n a R o t a S e M a r q u e s Pelotas, 2011 LOTAS ógico as Embarcados n a
Transcript of Estudo Das Linguagens Para Modelagem de Sistemas Embarcados
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 PELOTASCDTec
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 E mbarcados
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ísticas do 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 modelos de 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. Possibilita que 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.
Diagrama s SysML
Diagrama s Comportamentais
Diagrama de
Atividade
Diagrama s 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 (onde sã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 requisito funcional 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 estudo sobre 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.
