UNIVERSIDADE FEDERAL DE PELOTAS CDTec Centro de Desenvolvimento Tecnolgico

Trabalho Acadmico

Titulo Estudo das Linguagens para Modelagem de Sistemas Embarcados E

M i l e n a R o t a S e n a M a r q u e s

Pelotas, 2011

Banca examinadora:
................................................................................................. Prof. Dr. Lisane Brisolara de Brisolara (Orientador)

................................................................................................

................................................................................................

RESUMO MARQUES, Milena R. S. Estudo das Linguagens para Modelagem de Sistemas Embarcados. 2012. 42f. Trabalho acadmico (Mestrado) - Mestrado em Cincia da Computao. Universidade Federal de Pelotas, Pelotas. Sistemas Embarcados so sistemas cujo projeto envolve vrias 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 abstrao, alm das vantagens da construo de modelos visuais, atravs dos diversos diagramas disponveis. Porm, seu uso limitado em sistemas embarcados, o que motivou a definio de extenses da linguagem para este domnio especfico. O objetivo deste trabalho apresentar conceitos bsicos do domnio de sistemas embarcados, logo aps apresentar um estudo de dois perfis da UML que oferecem suporte modelagem de sistemas embarcados, o SysML e o MARTE. A combinao desses perfis avaliada neste trabalho para obter-se uma modelagem de alto nvel adequada, que inclui a modelagem detalhada de requisitos funcionais e no funcionais, bem como a modelagem completa de requisitos temporais.

Palavras-chave: Sistemas Embarcados, UML, SysML, MARTE.

ABSTRACT MARQUES, Milena R. S. Estudo das Linguagens para Modelagem de Sistemas Embarcados. 2012. 42f. Trabalho acadmico (Mestrado) - Mestrado em Cincia da Computao. 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

LISTA DE FIGURAS Figura 1 Nveis de abstrao para o processo do projeto de sistemas embarcados ........................................................................................................................... 12 Figura 2 Sistema de Superviso e Controle de tempo real. ................................... 18 Figura 3 Diagramas da UML 2.0 ............................................................................ 20 Figura 4 Sobreposio 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 restries do sistema. ............... 32 Figura 8 Pacote RTEM ........................................................................................... 36

LISTA DE TABELAS Tabela 1 Diagrama de Requisitos. ......................................................................... 29 Tabela 2 Categoria de esteretipos genricos para <<requirement>>. ................. 29

LISTA DE ABREVIATURAS E SIGLAS CCSL FPGA GQAM HCFSM MARTE MFS NFPs OMG RrUnit RTEM SE RFP SoC SO SPT SRT STR SysML UML Clock Constraint Specification Language Field-programmable gate array Generic Quantitative Analysis Modeling Mquina de Estados Finita Hierrquica e Concorrente. Modeling and Analysis of Real-time and Embedded System Mquina de Estados Finita Requisitos no funcionais Object Management Group Real-time unit Modelo de Design Marte System Engineering Request for Proposal System on Chip Sistema Operacional Profile for Schedulability, Performance and Time Specification Soft Real Time Systems Sistema de Tempo Real Systems Modeling Language Unified Modeling Language

SUMRIO 1 1.1 1.2 1.3 2 2.1 2.2 2.3 2.4 2.5 3 3.1 3.1.1 3.2 3.2.1 3.2.2 3.3 INTRODUO .............................................................................................. 8 Motivao .................................................................................................... 9 Objetivos ...................................................................................................... 9 Organizao do Trabalho ........................................................................... 9 SISTEMAS EMBARCADOS ....................................................................... 11 Introduo ................................................................................................. 11 Sistemas de Tempo Real .......................................................................... 14 Sistemas Orientados a Eventos............................................................... 17 Sistemas de Superviso e Controle ........................................................ 17 Sistema de Controle ................................................................................. 18 LINGUAGENS PARA MODELAGEM DE SISTEMAS EMBARCADOS .... 20 UML ............................................................................................................ 20 Uso da UML na modelagem de Sistemas Embarcados ........................ 22 SysML ........................................................................................................ 23 Diagrama de Requisitos ........................................................................... 27 Diagrama Paramtrico .............................................................................. 31 MARTE ....................................................................................................... 33

4 TRABALHOS RELACIONADOS................................................................ 37 5 CONCLUSES ........................................................................................... 39 REFERNCIAS ......................................................................................................... 40

1 INTRODUO

Devido ao avano tecnolgico grande parte das tarefas executadas por seres humanos so auxiliadas por computadores. Nesse pressuposto, Sistemas computacionais embarcados esto presentes em diversas atividades, por exemplo, uso de mp3, telefone celular, entre outros. Sistemas embarcados so sistemas dedicados que possuem uma funcionalidade restrita para atender uma tarefa especfica em sistemas maiores nos quais esto inseridos (MARWWEDEL, 2006). Segundo Brisolara et. al (2009) estes sistemas so naturalmente heterogneos, pois so constitudos de componentes de hardware e software. O projeto de desenvolvimento de software embarcado distinto do desenvolvimento de software de propsito geral. Tais sistemas possuem requisitos relevantes como: consumo de potncia e energia, desempenho, tamanho, peso, memria, restries de tempo, custo de projeto, entre outras. Um software dito embarcado quando projetado para executar em um sistema embarcado. Todos estes aspectos, aliados sofisticao crescente dos produtos e o curto perodo para lanamento dos mesmos, aumentam a complexidade envolvida no projeto. Para lidar com projetos complexos, linguagens de alto nvel de abstrao tm sido utilizadas. Dentre elas, destaca-se a linguagem UML (Unified Modeling Language) considerada padro para modelagem de software. UML uma linguagem genrica que pode ser usada para modelar diferente tipos de sistemas. No entanto, a generalidade faz com que a UML no suporte a modelagem de alguns aspectos especficos em um determinado domnio de aplicao, motivando a definio de linguagens de domnio especfico. Para atender esta demanda, a UML oferece mecanismos de extenso atravs da criao de perfis especficos para um dado domnio de aplicao. No domnio de sistemas embarcados, o suporte descrio de

comportamentos heterogneos (hardware/software e diferentes modelos de computao) e a especificao de requisitos no-funcionais so exemplos de necessidades especficas do domnio. Dentre os perfis propostos pela OMG (Object Management Group) (OMG, 2011a), com enfoque no domnio 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 especificao, anlise, projeto e verificao de sistemas

complexos, enquanto o MARTE enfoca a modelagem e anlise de sistemas embarcados e de tempo real. O objetivo deste trabalho realizar um estudo destas extenses com o intuito de analis-las quanto aos recursos suportados para a modelagem de sistemas embarcados, bem como as limitaes apresentadas.

1.1 Motivao

As linguagens de modelagem de alto nvel ajudam a modelar sistemas complexos, bem como, seus requisitos funcionais e no funcionais. Sistemas embarcados so complexos e se diferem dos sistemas tradicionais principalmente por seus requisitos no funcionais, tais como: consumo energtico, potncia dissipada, alm dos aspectos temporais exigidos em vrias aplicaes, etc. A UML no possui suporte para representar tais requisitos. A motivao deste trabalho estudar linguagens de alto nvel de abstrao para modelagem de Sistemas Embarcados.

1.2 Objetivos

O Objetivo estudar notaes para a modelagem de Sistemas Embarcados em alto nvel de abstrao. As notaes escolhidas foram SysML e MARTE, pois so perfis da UML 2.0 definidos e padronizados pela OMG. Sendo assim, neste trabalho sero avaliados estes perfis.

1.3 Organizao do Trabalho

Este trabalho divide-se em cinco captulos, de forma a explicar os principais conceitos envolvidos na modelagem de Sistemas Embarcados. No segundo captulo so introduzidos conceitos bsicos do domnio de sistemas embarcados, focando em sistemas de tempo real, sistemas orientados a eventos, sistemas de superviso e controle e sistemas de controle.

10

J no terceiro captulo so apresentados os trabalhos relacionados com este estudo. Enquanto que no quarto captulo sero apresentados conceitos de linguagem de modelagem de alto nvel de abstrao. Para modelagem de sistemas de propsito geral so apresentados conceitos de UML, logo aps so apresentados conceitos de SysML e MARTE, para representao de Sistemas Embarcados. Aps, no quinto captulo, so apresentadas as concluses deste estudo.

11

2 SISTEMAS EMBARCADOS

Este captulo tem por objetivo introduzir a rea de aplicao da cincia da computao denominada Sistemas Embarcados, mostrando seus principais conceitos e tipos de sistemas desse domnio.

2.1 Introduo

Sistemas

embarcados

so

sistemas

dedicados

que

possuem

uma

funcionalidade restrita para atender uma tarefa especfica em sistemas maiores nos quais esto inseridos (MARWEDEL, 2006). Sistemas embarcados so heterogneos por envolverem software e hardware. As aplicaes embarcadas possuem caractersticas que os diferem dos demais sistemas. Caractersticas como: sistemas dedicados, sistemas reativos, confiabilidade, restries de tempo real, tamanho do cdigo, desempenho, baixo consumo de potncia e energia, fsicas (tamanho e peso), devem ser consideradas no desenvolvimento de um sistema embarcado. As aplicaes de computao embarcada esto incorporadas em muitas reas tais como: eletrnica automotiva, eletrnica de aeronaves, sistemas de telecomunicao, eletrnica de consumo, equipamentos mdicos, aplicaes militares entre outros. Para lidar com essas

restries na construo de um sistema embarcado so utilizadas as linguagens de modelagem de alto nvel de abstrao. Sendo assim, o projeto de um sistema embarcado parte de uma viso abstrata e ao longo do desenvolvimento so feitos refinamentos at o produto finalizado. O projeto de um sistema embarcado envolve etapas com diferentes nveis de abstrao, conforme o fluxo ilustrado na Fig. 1. De acordo com este fluxo, as etapas de projeto compreendem: Anlise de Requisitos: definio dos requisitos do sistema. Especificao: detalhamento das funcionalidades do sistema. Arquitetura do Sistema: detalhamento interno do sistema, bem como os componentes que compem o sistema. Projeto de Componentes: projetar os componentes do sistema.

12

Integrao do Sistema: integrao dos componentes

desenvolvidos para o sistema e a validao dos mesmos.

Requisitos Projeto Top- Down Especificao Projeto Bottom-up

Arquitetura

Projeto de Componentes

Integrao do Sistema

Figura 1 Nveis de abstrao 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 viso mais abstrata e atravs de refinamentos sucessivos obtm-se o sistema propriamente dito. J na abordagem bottom-up, o projeto iniciado com uma descrio em nvel de componentes e a partir destes componentes constri-se o sistema completo. Em projetos reais so utilizadas as duas abordagens. A abordagem bottom-up permite tomar decises quanto ao custo dos componentes, por exemplo, para a deciso de qual ser a melhor arquitetura para o sistema. Sendo um misto das duas abordagens as decises crticas podem ser tomadas a tempo evitando o retrabalho. Em cada nvel de abstrao durante as etapas do projeto de um sistema embarcado, necessrio:

13

Analisar o projeto para determinar as caractersticas do estado atual do projeto. Refinar o projeto adicionando detalhes. Verificar o projeto para avaliar se os objetivos dos sistemas, tais como custo, velocidade sero alcanados.

A etapa inicial do processo de desenvolvimento de um sistema embarcado capturar as informaes que sero utilizadas para criao da arquitetura e dos componentes. As informaes dos requisitos so obtidas a partir do conhecimento do cliente e refinadas para uma especificao no qual contem informaes suficientes para o inicio do projeto da arquitetura do sistema. Os requisitos em um projeto de sistema embarcados podem ser funcionais ou no funcionais. Requisitos funcionais descrevem as funcionalidades que se espera que um sistema disponibilize, de forma completa e consistente. J os requisitos no funcionais mapeiam os aspectos qualitativos de um software, como: desempenho, portabilidade, consumo energtico, consumo de potncia, caractersticas fsicas (tamanho e peso). At pouco tempo a documentao dos requisitos era feita de forma textual com formulrios pr-definido. Atualmente, possvel documentar os requisitos atravs do diagrama de requisitos. Este diagrama esta disponvel no perfil SysML da UML 2.0. Podem-se destacar duas vantagens na utilizao deste diagrama. A primeira a minimizao da ambigidade das informaes dos requisitos, j que este diagrama representado de forma grfica. A segunda o suporte para a representao de requisitos funcionais e no funcionais. A prxima etapa no processo de desenvolvimento de um sistema embarcado a especificao. Nesta etapa os requisitos so detalhados independentes de arquitetura. As especificaes podem conter requisitos funcionais e no funcionais. Esta etapa, quando cumprida reduz erros no desenvolvimento do projeto. No deve ser ambgua, deve possuir informaes suficientes para o desenvolvedor do sistema. Tambm pode ser documentada com o diagrama de requisito, pois este diagrama pode representar um conjunto de requisitos (funcionais ou no funcionais) que esto contidos em uma especificao (FRIEDENTHAL, MOORE, STEINER, 2008). Na fase de arquitetura do projeto so implementadas as funcionalidades especificadas anteriormente (WOLF, 2008). Com diagrama de blocos possvel modelar a arquitetura do sistema, representando os componentes de hardware

14

(CPU, memria, entre outros) e os componentes de software. A descrio arquitetural do projeto deve satisfazer requisitos funcionais e no funcionais. Nesta fase diagrama de colaborao da UML pode ser utilizado para melhorar o entendimento do sistema. A construo dos componentes do projeto deve estar de acordo com a arquitetura e especificao. Os componentes utilizados em um projeto podem ser construdos para o sistema especficos, reutilizados de outro sistema, ou a utilizao de componente padro, como o caso de mdulos de software. Segundo Wolf (2008) a fase de integrao do sistema um desafio no projeto de sistemas embarcados. Nesta fase, os componentes que foram construdos so unificados e devem funcionar corretamente. Durante esta fase muitos erros so detectados. Para detectar rapidamente os erros uma alternativa fazer um plano de integrao de todos os componentes do sistema, tambm uma boa prtica executar testes exaustivos nas funcionalidades do sistema o mais breve possvel. 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 nvel de abstrao que pode ser utilizada para modelar cada fase do projeto de sistemas embarcados (WOLF, 2008). Com a UML 2.0 possvel ter vrias vises estruturais e comportamentais do sistema. Facilitando a tomada de deciso durante o desenvolvimento do projeto, e a visualizao do sistema atravs dos diversos diagramas disponveis. No domnio de sistemas embarcados a UML 2.0 possui o perfil MARTE que suporta a modelagem de tempo real de requisitos funcionais e no funcionais, para enriquecer o desenvolvimento do projeto desses sistemas tambm pode ser utilizado o perfil SysML que tambm suportam modelagem de requisitos funcionais, no funcionais e rastreabilidade.

2.2 Sistemas de Tempo Real

A utilizao de sistemas computacionais vem crescendo na sociedade, com isso, aplicaes de tempo real tornam-se freqentes. Segundo Farines et. al (2000) as aplicaes de tempo real variam em relao complexidade e s necessidades de garantia no atendimento dos requisitos temporais. Alguns exemplos de sistemas

15

simples so os controladores inteligentes embarcados em produtos de utilidade domsticas, como as lavadoras de roupa e microondas. J entre os sistemas mais complexos esto os sistemas militares, avinicos, mdicos. Um Sistema de Tempo Real (STR) um sistema computacional que deve reagir a estmulos oriundos do seu ambiente em prazos especficos. Grande parte das aplicaes de tempo real comporta-se como sistemas reativos com restries temporais. Sistemas reativos reagem a aes 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 especfico, sob pena de ocorrer uma falha temporal. O comportamento correto de um sistema de tempo real, no depende apenas da integridade dos resultados obtidos (correo lgica ou correctness), mas tambm dos valores de tempo em que so produzidos (correo temporal ou timeless). Uma reao que ocorra depois do prazo especificado pode ser intil ou representar uma ameaa dependendo do tipo de aplicao. Um dos conceitos mais importantes em sistemas de tempo real a previsibilidade. Segundo Farines et. al (2000) um sistema dito ser previsvel no domnio lgico e no domnio temporal quando, independente de variaes ocorrendo no nvel de hardware, da carga e de falhas, o comportamento do sistema pode ser antecipado, antes de sua execuo. Os sistemas de tempo real podem ser divididos em: Sistemas No Crticos de Tempo Real (ou SRTs brandos, Soft Real Time Systems), onde o no atendimento de uma tarefa no prazo especificado no representa uma falha no comportamento do sistema, e Sistemas Crticos de Tempo Real (ou SRTs duros, Hard Real Time Systems) onde o no atendimento de uma tarefa no prazo especificado pode ocasionar uma catstrofe (ex. sistemas de controle de vo). Conceitos de escalonamento em sistemas onde o tempo e a concorrncia so tratados explicitamente se tornam essenciais para previsibilidade do comportamento de sistemas de tempo real. Uma tarefa uma abstrao bsica que faz parte do problema de escalonamento. Tarefas ou processos so as unidades de processamento seqenciais que concorrem com um ou mais recursos

computacionais de um sistema. Uma aplicao simples de tempo real possui vrias tarefas que devem apresentar correo lgica (correctness) e temporal (timeless).

16

Tambm parte de um problema de escalonamento a definio do modelo de tarefas, que so as restries temporais, as relaes de precedncia e de excluso normalmente impostas sobre as tarefas. Todas as tarefas de tempo real esto sujeita a prazos: deadlines. Ou seja, uma tarefa deve ser concluda antes do seu prazo. As tarefas concludas aps seu prazo caracterizam dois tipos de tarefas de tempo real: Tarefas crticas (hard): Uma tarefa dita crtica se atendida aps seu prazo pode causar falhas catastrficas ao sistema. Tarefas brandas ou no crticas (soft): Uma tarefa dita branda se atendida aps seu prazo s falhas temporais so benignas, ou seja, a conseqncia do desvio do comportamento normal do sistema no representa um custo significativo. Os modelos de tarefas possuem dois tipos de tarefas segundo suas freqncias de ativao: Tarefas Peridicas: a ativao da tarefa realizada e a mesma ocorre infinitas vezes no perodo determinado. So tarefas que ocorrem com regularidade. Tarefas Aperidicas ou Assncronas: a ativao do processamento da tarefa responde a eventos internos ou externos. A ativao deste tipo de tarefa aleatria. As tarefas peridicas pela regularidade e, portanto pela previsibilidade, usualmente so associadas a "deadlines hard", ou seja, so tarefas crticas. As tarefas aperidicas pela falta de previsibilidade em suas ativaes, normalmente, tem "deadlines soft" associados a suas execues, compondo, portanto as tarefas brandas de um sistema de tempo real. Tarefas espordicas que correspondem a um subconjunto das tarefas aperidicas apresentam como caracterstica central a restrio de um intervalo mnimo conhecido entre duas ativaes consecutivas e por isso, podem ter atributos de tarefas crticas. As tarefas espordicas, portanto so tambm associadas a "deadlines hard" (FARINES, FRAGA, e OLIVEIRA, 2000). Quanto s caractersticas temporais as tarefas podem ter as seguintes restries: Tempo de computao: o tempo necessrio a execuo completa de uma tarefa.

17

Tempo de incio: corresponde ao instante de inicio da ativao do processamento de uma tarefa Tempo de trmino: o instante de tempo em que se completa a execuo da tarefa. Tempo de chegada: o instante em que o escalonador toma conhecimento da ativao da tarefa. Tempo de liberao: o instante em que a tarefa pode ser executada.

Atravs das polticas de escalonamento so definidas as regras para a ordenao das tarefas de tempo real. A utilizao dessas polticas pelos escalonadores produz escalas que se forem realizveis (feasible), garantem o cumprimento das restries 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 execuo, interrompendo a execuo da tarefa atual para executar outra tarefa mais prioritria) e no preemptivos (mesmo existindo na fila uma tarefa mais prioritria que a que esta sendo executa este algoritmo no interrompe sua execuo para executar outra de maior prioridade) (FARINES, FRAGA e OLIVEIRA, 2000). Escalonabilidade um requisito no funcional do sistema que determina se este atender os requisitos temporais de todas as tarefas, mesmo no pior caso. O perfil MARTE, disponvel na UML 2.0, apropriado para modelar as caractersticas temporais em projetos de desenvolvimento de sistemas embarcados, pois suporta escalonamento, compartilhamento e anlise de requisitos temporais.

2.3 Sistemas Orientados a Eventos

Sistemas embarcados so essencialmente orientados a eventos, ou seja, esperam a ocorrncia de um evento interno ou externo para executar o processamento apropriado. Sistemas orientados a eventos so tambm chamados de sistemas reativos. Estes sistemas so representados atravs dos seguintes modelos computacionais: tempo contnuo de evento discreto e tempo discreto.

2.4 Sistemas de Superviso e Controle

18

Sistemas

de

superviso

controle

so

usualmente

dedicados

ao

gerenciamento da execuo de um processo ou de um objeto fsico. Neste tipo de sistema possvel distinguir componentes, tais como: operador, sistema computacional de controle e o sistema a controlar. O sistema a controlar e o operador so considerados como ambiente do sistema computacional. A interao entre as partes ocorre atravs de interfaces de operador (FARINES, FRAGA e OLIVEIRA, 2000). A Fig. 3 mostra esses componentes em conjunto com elementos clssicos de um diagrama de controle.

Figura 2 Sistema de Superviso e Controle de tempo real. Fonte: (Romero; 2010, p12).

2.5 Sistema de Controle

Sistemas de controle so caracterizados por modelos computacionais baseados a eventos. O modelo computacional Sncrono/Reativo utilizado para representar este tipo de sistema. Um modelo sncrono reativo quando as sadas so sincronizadas com as entradas. Este modelo caracterizado por possuir as seguintes abstraes:

19

Forte sincronismo: partes do sistema respondem instantaneamente para as entradas. Reatividade: sistema reage a aes externas Memria limitada: sistema possui computao com memria limitada.

Outro modelo computacional utilizado para representar sistemas de controle so as mquinas de estados finitas (MFS). Porm, as MFS clssicas no modelam concorrncia. Para contemplar este aspecto, h extenses deste modelo como a Mquina de estados finita hierrquica e concorrente (HCFSM) capaz de representar hierarquia e concorrncia. Segundo Wolf (2007) uma maneira de especificar o comportamento de uma operao atravs de maquinas de estados. A UML utiliza o diagrama de mquina de estados para representar este tipo de modelo computacional. Atravs do diagrama de mquina de estados possvel visualizar a mudana entre um estado e outro pela ocorrncia de um evento, com alto nvel de abstrao. Um evento um tipo de ao. O evento pode ser uma ao externa do sistema, por exemplo, pressionar um boto, e pode ser uma ao interna do sistema como uma rotina, que quando finalizada envia o resultado para outra rotina. Os estados da mquina de estados representam diferentes operaes. A diviso de operaes 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 cdigo (Wolf, 2008). Com o diagrama de seqncia tambm possvel representar estes modelos computacionais.

20

3 LINGUAGENS PARA MODELAGEM DE SISTEMAS EMBARCADOS O presente captulo apresenta conceitos bsicos da linguagem de modelagem UML, utilizada para modelagem de software de propsito geral, e que atraiu o interesse da comunidade de sistemas embarcados. Alm da UML, este captulo revisa a linguagem SysML e MARTE, duas extenses da UML propostas para especificao de requisitos e modelagem de sistemas embarcados de tempo real, respectivamente.

3.1 UML

A UML uma linguagem visual para especificao, construo e documentao de artefatos do sistema (OMG, 2009 a). UML uma linguagem padro para modelagem de software de propsito geral. Esta linguagem proporciona ao usurio vises de alto nvel de abstrao do sistema. Tais vises so possveis atravs do conjunto de diagramas disponveis. Conforme a Fig. 3, a UML 2.0 suporta treze diagramas que esto divididos em duas categorias: Diagramas Estruturais e Diagramas Comportamentais.

Figura 3 Diagramas da UML 2.0

21

Segundo Fowler (2004), a viso estrutural do sistema se d a partir dos diagramas: Diagrama de Classe: um dos artefatos da UML para representar o modelo de negcio, onde os principias conceitos da aplicao so representados por classes. Este diagrama descreve os tipos de

objetos presentes no sistema e os vrios tipos de relacionamentos estticos entre eles. Tambm representa as propriedades e as operaes de uma classe e as restries que se aplicam maneira como os objetos esto conectados. Diagrama de Componentes: representa os vrios componentes de software de um sistema, alm das dependncias 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 Instalao: representa o layout fsico de um sistema, revelando quais partes do software so executadas em quais partes do hardware. Diagrama de Pacotes: representa os pacotes e suas dependncias. Este diagrama til em sistemas de grande porte, para obter uma viso das dependncias entre os principais elementos de um sistema. J a viso comportamental do sistema, segundo Fowler (2004), representada a partir dos diagramas: Diagrama de Atividade: uma tcnica para descrever a lgica de procedimento, processo de negcio e o fluxo de trabalho. Esse diagrama suporta o comportamento paralelo. Diagrama de Casos de Uso: uma tcnica utilizada para capturar os requisitos funcionais de um sistema. Possibilitam descrever as interaes tpicas entre os usurios de um sistema e o prprio sistema, fornecendo uma narrativa sobre como o sistema utilizado. Diagrama de Mquina de Estados: representa o comportamento de um objeto por intermdio de vrios casos de uso.

22

Diagrama de Interao: uma mistura de diagrama de atividade e diagrama de seqencia. Esse diagrama pode ser considerado como diagrama de atividade nos quais as atividades so substitudas por pequenos diagramas de seqencia ou como um diagrama de seqencia fragmentado, com a notao de digrama de atividades usada para representar o fluxo de controle.

Diagrama de Seqencia: captura a seqencia de processos. Este diagrama usado para representar os objetos e mensagens que so passadas entre esses objetos dentro de um caso de uso.

Diagrama de Temporizao: outra forma de diagrama de interao. Esse diagrama utilizado para mostrar restries de tempo entre mudanas de estado em diferentes objetos.

Diagrama de Comunicao mostra de maneira semelhante ao diagrama de seqncia, a colaborao dinmica entre os objetos. Se a nfase do diagrama for o decorrer do tempo, a melhor escolha o diagrama de seqncia, mas se a nfase for o contexto do sistema, vale priorizar o diagrama de comunicao.

UML uma linguagem genrica que pode ser usadas para modelar diferentes tipos de sistemas. No entanto, a generalidade faz com que a UML no suporte a modelagem de alguns aspectos especficos em um determinado domnio de aplicao, motivando a definio de linguagens de domnio especfico. Para atender esta demanda, a UML oferece mecanismos de extenso atravs da criao de perfis especficos para um dado domnio de aplicao.

3.1.1

Uso da UML na modelagem de Sistemas Embarcados

O projeto de desenvolvimento de software embarcado distinto do desenvolvimento de software de propsito geral. Sistemas embarcados possuem requisitos relevantes como: consumo de potncia e energia, desempenho, tamanho, peso, memria, restries de tempo, custo de projeto, entre outras. Para lidar com projetos complexos, linguagens de alto nvel de abstrao tm sido utilizadas, pois tais linguagens abstraem detalhes desnecessrios tornando fcil tanto a verificao como a validao, facilitando a reusabilidade e a evoluo desses

23

sistemas complexos. Uma linguagem que se destaca a UML possivelmente pelos perfis especializados em um domnio especfico. Um perfil um mecanismo padronizado pela OMG para criao de linguagens de modelagem de domnio especfico, eles refinam os conceitos existentes de uma linguagem padro, como a UML. No domnio de sistemas embarcados, o suporte descrio de

comportamentos heterogneos (hardware/software e diferentes modelos de computao) e a especificao de requisitos no-funcionais so exemplos de necessidades especficas do domnio. Os perfis aplicados a estas caractersticas so SysML e MARTE. SysML e MARTE consideram caractersticas no domnio de sistemas embarcados em diferentes nveis de abstrao, arquitetural e especialmente para fins especficos ou reas de aplicao. SysML possibilita a rastreabilidade de requisitos, estrutura e comportamento do sistema de blocos, bem como formalismo paramtrico para especificar equaes, enquanto MARTE trata de tempo real e aspectos de recursos limitados, inclui uma taxonomia detalhada de hardware e padres de software juntamente com os requisitos no funcionais para permitir anlise quantitativa (desempenho, consumo energtico).

3.2 SysML

SysML uma linguagem de modelagem grfica de propsito geral que suporta especificao, anlise, projeto, verificao e validao de sistemas complexos. Estes sistemas podem incluir hardware, software, informao, processos, pessoas e infra-estrutura (OMG, 2011a). Como indicado na Fig. 4, SysML reutiliza um subconjunto da UML e adiciona extenses 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 no sofreram alteraes, como o diagrama de casos de uso, diagrama de mquina de estados.

24

Figura 4 Sobreposio entre UML2.0 e SysML Fonte: (OMGa; 2010, pg.31)

SysML no metodologia ou ferramenta para desenvolvimento de software. SysML uma linguagem grfica que disponibiliza semntica (significado) e notao (representao do significado) para modelagem de software. O diagrama apresentado na Fig. 5 ilustra as modificaes ocorridas nos diagramas reutilizados da UML 2.0, bem como os novos diagramas da SysML. Os diagramas so classificados em trs classes: comportamentais, estruturais e de requisitos.

Diagramas SysML

Diagramas
Comportamentais

Diagrama de Requisitos

Diagramas Estruturas

Diagrama de Atividade

Diagrama de Sequenci

Diagrama de Mquina

Diagrama de Caso de Uso

Diagrama de Blocos

Diagrama de Bloco Interno

Diagrama de Pacote

Diagrama Paramtrico

25
Sem alterao Alterados a partir da UML 2.0 Novos diagramas

Figura 5 Diagramas da linguagem SysML Fonte: (OMGa; 2010, p.180)

As construes estruturais definem os elementos estticos e de estruturas utilizados em SysML. Diagramas que incluem essas construes so: o diagrama de pacotes, o diagrama de blocos, o diagrama de bloco interno e o diagrama paramtrico. As estruturas das construes so definidas atravs de: elementos de modelos (recapturados do ncleo de pacotes da UML 2.0 e incluem extenses para prover capacidades de fundamentao 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. Tambm possvel descrever as caractersticas de bloco, como: propriedades, operaes, restries, alocao, requisitos que o bloco satisfaz); portas e fluxos (provem a semntica para definir como blocos e partes interagem atravs de portas e como e quais itens fluem atravs delas); blocos de restries (definem como os blocos so estendidos para serem usados sobre diagramas paramtricos que modelam a rede de restries sobre as propriedades de um sistema, para dar suporte a anlise de desempenho e outros). As partes dinmicas utilizadas nos diagramas de comportamento da SysML so especificadas pelas construes comportamentais, atravs dos diagramas: o diagrama de atividades (utilizado para descrever o fluxo de controle e o fluxo de entradas e sadas entre as aes), o diagrama de seqncia, o diagrama de mquina de estados e o diagrama de casos de uso. As construes comportamentais, utilizadas nos diagramas, so separadas em: atividades (definidas na UML 2.0 com algumas extenses); interaes (onde so definidas as construes para o comportamento baseado em mensagens usado no diagrama de seqncia); mquinas de estados (usadas para descrever o comportamento de um sistema baseado em seus estados e suas transies); e casos de uso (que descreve o comportamento e a utilizao de um sistema em termos da sua funcionalidade de alto nvel).

26

J as construes cruzadas (crosscutting) so aplicadas nas construes estruturais e comportamentais. Essas construes so definidas em: alocaes (representam as relaes que mapeiam um elemento do modelo a outro) Segundo Espinoza (2010) a SysML apresenta as seguintes contribuies: Organizao Arquitetural - Incluem conceitos de modelagem para organizar descries da arquitetura de sistemas, definidas pelo padro IEEE 1471. Dentre eles, os conceitos de View, viewpoint e rationale so os mais importantes. Blocos e Fluxos - descrio e diagrama de blocos internos permitem a especificao de interaes genricas e fenmenos existentes em software. Isto inclui fluxos fsicos como os lquidos, energticos e eltricos. As dimenses e unidades de medida de tais fluxos fsicos podem ser definidas explicitamente (ex. litros, watts) Comportamentais - diagramas comportamentais so similares ao da UML (interao, mquina de estados, atividades e casos de uso). SysML refina o diagrama de atividade para a modelagem de modelos contnuos e probabilidades. Requisitos SysML dispe de uma modelagem facilitada para os requisitos do sistema, bem como rastreabilidade quanto evoluo do sistema. Os requisitos podem ser representados no formato grfico ou tabular. Parmetros o diagrama paramtrico permite descrever em SysML, de maneira grfica, relacionamentos analticos e restries, bem como equaes matemticas. A utilizao de SysML no projeto de sistemas complexos apresenta benefcios como: Abstrao de detalhes; Linguagens formais como SysML e UML reduzem ambigidade e erros, pois fornecem notaes precisas que minimizam os erros de interpretao. As alocaes e requisitos disponibilizam mecanismos que garantem a consistncia 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 mudanas necessrias durante o desenvolvimento do projeto.

3.2.1 Diagrama de Requisitos

Um requisito especifica uma funcionalidade ou condio que deve ser satisfeita pelo sistema, ou seja, uma funo que um sistema deve executar ou uma condio de desempenho que um sistema deve alcanar. Conforme Friedenthal et. al (2008) o que a engenharia clssica busca que o requisito tenha as seguintes caractersticas: no seja ambguo, seja compreensivo, correto, conciso, tenha rastreabilidade e verificveis. Os requisitos normalmente tm origem distinta. No nicho de embarcados, vale citar o exemplo do desenvolvimento de um aparelho celular, onde, normalmente a solicitao feita pela equipe do departamento de marketing da empresa. Essa equipe fornece as caractersticas necessrias do produto para a equipe de desenvolvimento de software, sendo que, tais caractersticas devem superar as expectativas do pblico alvo, portanto, neste cenrio so vrios stakeholders fornecendo informaes do produto. Para isso necessrio assegurar que os requisitos so consistentes (no contraditrios) e viveis, e refletem adequadamente as necessidades dos envolvidos. O diagrama de requisitos permite representar os requisitos, que usualmente so expressos em linguagem texto, de forma grfica. O diagrama tambm 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 derivaes existentes nos requisitos, que possibilitam associar um determinado requisito a outro modelo tornando visvel o rastreamento dos requisitos. O diagrama de requisitos ilustrado na Fig. 6 representa um exemplo genrico de diagrama de requisitos para um sistema automotivo. Nesse exemplo, so apresentados diferentes relacionamentos entre os requisitos e notaes alternativas, como: o bloco cmera deve satisfazer requisito chamado Sensor Decision, tambm

28

inclui trs tipos de relacionamentos: satisfy, verify, deriveReqt, alm de apresentar a hierarquia.

Figura 6 Diagrama de requisitos. Fonte: Friedenthal; Moore;Steiner; (2008),p.286) Em SysML as relaes entre os requisitos e de requisitos para outros elementos da modelagem, de projeto, ou casos de teste so descritas usando um conjunto de esteretipos. As relaes dos requisitos so representadas pelos esteretipos: 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 cpia 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 esteretipo Rationale um modelo de elemento SysML para anotao que pode ser associado com qualquer requisito ou relacionamento entre requisitos. uma notao SysML que destina-se a identificar um problema que precisa ser resolvido. O comentrio feito a partir do Rationale pode referir-se a um documento externo ou outro elemento do modelo bem como a um diagrama paramtrico.

29

Conforme ilustrado na Fig. 6, os requisitos so apresentados de forma grfica no diagrama de requisito. Neste diagrama, um requisito representado por um retngulo com a palavra chave <<Requirements>> seguida pelo nome do requisito. As propriedades mnimas dos requisitos so: id (identificao), Text (texto que descreve as caractersticas do requisito). Conforme Friedenthal (2008), os requisitos podem conter propriedades adicionais como status da verificao, criticidade, risco e categoria de um requisito. Para status da verificao, um requisito pode estar assinalado como no verificado (not verified), verificado pela inspeo (verified by inspection), verificado pelo analista (verified by analysis), verificado pela

demonstrao (verified by demonstration) ou verificado pelo teste (verified by test). Quanto ao nvel de criticidade ou risco, um requisito pode ser assinalado como de alto, mdio ou baixo risco. Por fim, podemos categorizar os requisitos como funcionais (Functional), de desempenho (Performance) ou fsicos (Phisycal). O Diagrama de Requisitos tambm pode ser representado de forma tabular, conforme a Tabela 1: Tabela 1 Diagrama de Requisitos.

name id Autonomia 1

text

O sistema deve apresentar quantos km o automvel pode percorrer com o combustvel

restante, conforme a velocidade do automvel. Velocidade 1.1. O sistema deve apresentar a velocidade atual do automvel.

Em SysML permitido criar categorias de requisitos definindo subclasses adicionais de esteretipos de requisitos. Um esteretipo permite adicionar restries que limitem um tipo especfico 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 mquina de estados. A Tab. 2 mostra as categorias de esteretipos genricos para

<<requiremet>>. Tabela 2 Categoria de esteretipos genricos para <<requirement>>.

30

Estertipo <<extendrequirent>>

Restrio N/A Uma

Descrio mistura de

esteretipo que contm atributos usados requisitos. verifyMethod) <<functionrequirement>> Deve ser satisfeito Requisitos por uma operao especificam ou comportamento. operao comportamento sistema sistema desempenhar. <<interfacerequirement>> Deve ser satisfeito Requisito por uma porta, especificam as que portas ou que parte que uma ou o do geralmente para (ex. os Risk,

devem

conector, e/ou

fluxo, para conectar sistemas e

propriedade partes do sistema e que, opcionalmente, pode

restritiva.

incluir o item que flui atravs do conector e / ou restries da interface. <<performancerequirement>> Deve ser satisfeito Requisito por propriedade valor que

uma quantitativamente mede o de grau em que um sistema, ou uma parte do sistema, satisfaz uma condio ou capacidade necessria.

<<physicalRequirement>>

Deve ser satisfeito Requisitos por um elemento especificam estrutural caractersticas

que

fsicas

e/ou restries fsicas dos sistemas, ou de uma

31

parte do sistema. <<designConstraint>> Deve ser satisfeito Requisito que representa por um bloco ou uma parte restrio na do parte como do o

implementao sistema sistema, ou tal

sistema deve utilizar o componente off-the-shelf . comercial

Diagrama de requisitos propicia a visualizao grfica dos requisitos do sistema, tornando fcil o entendimento dos mesmos. Este diagrama permite modelar requisitos, estrutura, comportamento e parmetros para prover uma descrio robusta do sistema, seus componentes e ambientes.

3.2.2 Diagrama Paramtrico

O diagrama paramtrico representa restries nos valores de propriedade do sistema tais como desempenho, confiabilidade, propriedades macias, e serve como meio para integrar os modelos das fases de especificao e projeto com modelos da fase de anlise (LINHARES, 2006). Um diagrama paramtrico tipicamente utilizado em sistemas com funcionalidades matemticas por representar com preciso frmulas matemtica. Os modelos paramtricos capturam as propriedades restritivas do sistema, para serem analisadas por ferramentas de anlise apropriadas. As restries so apresentadas por equaes, cujos parmetros esto vinculados s propriedades do sistema (FRIEDENTHAL, MOORE, STEINER, 2008). Este diagrama identificado pela palavra chave par. A SysML introduz bloco de restries para suportar a construo de modelos paramtricos. Um bloco de restrio um tipo especial usado para definir equaes. Tal bloco definido livre de contexto, permitindo a criao de uma biblioteca de restries que pode ser facilmente reutilizada em vrios projetos.

32

SysML inclui o conceito de restries que podem corresponder a qualquer expresso matemtica ou lgica, incluindo expresses com variveis temporais e equaes diferenciais. SysML no especifica uma linguagem de restries, mas permite que a linguagem seja especificada como parte da definio das restries (FRIEDENTHAL, MOORE e STEINER, 2008). Como mostra a Fig. 7 diferentes notaes so usadas em SysML para representar as restries das propriedades de blocos. O bloco 1, da Fig. 7 possui um compartimento explicito para restries, neste caso, expressas em Java, enquanto que o bloco 2 possui a conexo com uma nota, que expressa a restrio usando a linguagem MATLAB, uma ferramenta

especializada de anlise (FRIEDENTHAL, MOORE e STEINER, 2008).

Figura 7 Diagramas de blocos representando as restries do sistema. Fonte: (Friedenthal; Moore;Steiner; (2008),p.152) Um bloco de restrio define um conjunto de parmetros relacionado uns aos outros pela expresso de restrio. Estes parmetros podem ter tipos, unidades, dimenses e distribuies de probabilidade. Para facilitar tipos especficos de anlise (de desempenho, propriedades fsicas, etc.), blocos de restrio podem ser definidos nas bibliotecas modelo. No contexto de anlise, outro conceito importante do diagrama paramtrico, um bloco que fornece o contexto para o sistema ou componente sujeito a anlise. O contexto de anlise composto pelos blocos de restrio que correspondem ao modelo de anlise e referncias do sistema analisado. Um diagrama paramtrico, do qual a estrutura representa o contexto de anlise, usado para vincular as propriedades relevantes do bloco e os parmetros do modelo de anlise. O contexto de anlise pode ser passado para uma ferramenta de anlise de engenharia para realizar a anlise computacional, e os resultados analticos podem ser fornecidos de

33

volta como propriedades do contexto de anlise (FRIEDENTHAL, MOORE e STEINER, 2008).

3.3 MARTE

A UML tem sido adotada como uma linguagem de modelagem de propsito geral. No entanto, a UML no possui suporte para modelar aspectos como: tempo, escalonamento ou desempenho. Sendo assim, a primeira alternativa para tratar essa deficincia foi a definio do perfil SPT (UML Profile for Schedulability, Performance and Time Specification) (ROMERO, 2010). Este perfil fornecia conceitos para anlise de escalonabiliade, anlise de desempenho, alm de permitir a modelagem de aspectos temporais. Porm, no perfil SPT havia restries quanto modelagem temporal, pois se baseava em anotaes no modelo. Sendo assim, a OMG definiu um novo perfil, que ficou conhecido como MARTE (OMG, 20011b). A contribuio do perfil MARTE esta no seu modelo de tempo, enriquecendo a UML com elementos de modelo explcitos para representar tais modelos (relgios, 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; alocao de elementos; anlise de escalonabilidade e desempenho; especificao de caractersticas de sistemas embarcados, como tamanho de memria e consumo energtico; suporte a arquiteturas baseadas em componentes; outros paradigmas computacionais, como assncrono e sncrono (WEHMEISTER, 2009). Os sistemas embarcados de tempo real possuem caractersticas como: deadlocks e perodo da execuo de uma tarefa que devem ser atendidas conforme especificado. MARTE disponibiliza conceitos necessrios para modelar plataformas de hardware e software para executarem aplicaes embarcadas de tempo real. Incluindo suporte para a modelagem de hardware (memria, processadores, canais de comunicao e outros) e aspectos de software como tempo real do sistema operacional. O conceito de alocao usado para indicar que um elemento da aplicao est alocado em um elemento da plataforma. Segundo Andr et. al. (2007), MARTE apropriado para representao temporal de natureza fsica ou lgica. Sendo que o tempo fsico contnuo e pode

34

ser discretizado em relgios cronomtricos, enquanto que o tempo lgico menos reconhecido nos conceitos de modelagem explicitas. Um exemplo de tempo lgico, para Andr et. al. so os processamentos e as etapas de execuo realizada taxa de um ciclo do processador (que pode variar de acordo com o consumo de energia), ou disparado por ocorrncias sucessivas de um evento externo (tais como caractersticas da engenharia de um motor). MARTE consiste na definio de modelos de tempo real para sistemas embarcados, no qual inclui conceitos para modelagem e anlise (BRISOLARA, KREUTZ, e CARRO, 2009). O suporte a modelagem prove mecanismos (esteretipo) para detalhar o projeto de tempo real e as caractersticas de tempo real da aplicao, permitindo a especificao de requisitos no funcionais, tempo, e recursos gerais e de alocao. Para o suporte ao modelo de anlise, MARTE disponibiliza facilidades para anotar os modelos com as informaes necessrias para realizar uma anlise especfica. Segundo Espinoza et. al (2009), em relao UML, MARTE adiciona os seguintes recursos: NFPs: Uma estrutura com suporte a modelagem de requisito no funcionais (NFPs, do ingls, Non Functional Requirements)

proporciona especificar semanticamente propriedades no-funcionais (por exemplo: atrasos e uso de memria). Tempo: um modelo altamente refinado de tempo e integram conceitos de mecanismos de tempo a partir de diferentes subdomnios em projetos de sistemas embarcados, tal como tempo casual, tempo sncrono e tempo cronomtrico. Aplicao de software: Um modelo comum de computao que prove suporte semntica para paradigma de objeto de tempo real. Este paradigma permite especificao de aplicao com alto nvel de abstrao, por simultaneidade, comunicao e aspectos de restries 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 nveis de abstrao, incluindo seus

35

servios, como os das plataformas comuns de SO, e propriedades no funcionais comuns como consumo de energia ou uso de memria. Anlise quantitativa: Um conjunto pr-definido de anotao no funcional permite que os modelos em MARTE sejam a ligao com o estado da arte de ferramentas desempenho e de anlise. Em MARTE so integrados conceitos para tempo e comportamento, que so fortemente utilizados no domnio de sistemas embarcados. Neste perfil trs abstraes diferentes de tempo podem ser utilizadas para representar os fluxos de comportamento temporais, que so: Casual/temporal. A relao de precedncia/dependncia utilizada para determinar o comportamento. Relgio/sncrono. Adiciona a notao de simultaneidade e divide a estala do tempo em uma sucesso discreta de instantes. Esta classe de abstrao do tempo pode ser usada para modelagem de hardware e software. Fsico/tempo real. Oferece uma forma de especificar a modelagem precisa de tempo real, para escalonamento das questes crticas do sistema. Este modelo, tambm pode ser aplicado para o modelo sncrono, por exemplo, para obter a velocidade admissvel de uma reao. MARTE um perfil da UML composto por diversos pacotes, conforme pode ser observado na Fig. 8, os quais proveem conceitos adaptados para modelagem e anlise de sistemas embarcados e de tempo real. O perfil MARTE estruturado sob duas questes, uma para modelar as caractersticas de sistemas de tempo real e embarcados e outra para anotar modelos de aplicao, de modo a apoiar a anlise das propriedades do sistema. Estas questes so mostradas no pacote RTEM chamado "MARTE design model", conforme a Fig. 8. Estas duas questes principais compartilham caractersticas comuns com a descrio do tempo e o uso de recursos simultneos, que esto contidos no pacote compartilhado chamado Marte Foundations". Estas duas partes principais compartilham conceitos comuns como a descrio do tempo e o uso de recursos simultaneamente, os quais esto contidos no pacote chamado MARTE Foundations. Os recursos para Analysis Modeling so divididos em fundamentos genricos no pacote GQAM, e outros dois pacotes para domnios de anlise

36

especfica. Estes dois primeiros domnios de anlise especfica so inteiramente focados no tempo, no entanto, a estrutura do perfil permite incluir domnios de anlises adicionais, tais como consumo de energia, uso de memria, ou confiabilidade (OMG, 2011b).

Figura 8 Pacote RTEM Fonte: (OMGb; 2011, pg. 25) O perfil MARTE a extenso padro definida para a modelagem de sistemas embarcados e de tempo real. Este perfil foi uma evoluo do perfil UML-SPT (ROMERO, 2010), anteriormente adotado pela OMG para a modelagem de sistemas de tempo real. Esta evoluo inclui a parte de modelagem de hardware, no suportada pelo UML-SPT. MARTE prope novos esteretipos o perfil tambm prope a anotao de valores que representam aspectos temporais.

37

4 TRABALHOS RELACIONADOS

Neste capitulo so apresentados os trabalhos relacionados a este estudo. Uma avaliao da SysML foi realizada por Linhares, Silva e Oliveira (2006) onde os autores concluram que SysML permite que os engenheiros de sistemas descrevam um sistema em alto nvel de abstrao, considerando simultaneamente componentes de software e hardware. O artigo de Espinoza et al. (2009), apresenta estratgias para combinao dos perfis MARTE e SysML em um contexto comum de modelagem, evitando conflitos nas especificaes. Tambm mostram que apesar do overlapping de semntica e sintaxes esses dois perfis so altamente complementares. O artigo rene um conjunto de cenrios que julgam serem relevantes para o domnio de sistemas embarcados, apresentando os conflitos existentes nesses cenrios, autores sugerem algumas alteraes para combinao dos perfis em tais cenrios. Em Dubois et. al. (2010), o artigo propem o metamodelo, DARWIN4Req, para rastreabilidade de requisitos. Tal metamodelo esta baseado em trs fluxos independentes, que so: modelo de requisitos, modelo da soluo e modelo Validao &Verificao. O metamodelo DARWIN4Req estabelece um link entre os fluxos e permite total rastreabiliade dos requisitos incluindo modelos heterogneos. Em Peraldi-Frati et al. (2008) foi apresentada a modelagem e a anlise de sistemas de tempo real, em diferentes fases do projeto. Para a especificao das caractersticas temporais e estruturais do sistema, bem como a representao 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 mltiplos sistemas em chips (SoC), abrangendo as fases de concepo da modelagem do sistema para prottipos FPGA. O projeto de sistemas heterogneos aumenta o nvel de abstrao e fornece diversas ferramentas de automao de projeto. O sistema modelado em um ambiente de projeto UML seguindo um perfil UML que especifica as prticas para a aplicao e modelagem da arquitetura. As ferramentas de fluxo de projeto so regidas num framework nico, que combina as ferramentas em um fluxo contnuo e possibilita a visualizao do processo do projeto. Novas caractersticas incluem a explorao arquitetura automatizadas baseada nos modelos do sistema descrito em UML, bem como automatizao e

38

anotao das informaes no fluxo de projeto. A explorao arquitetura baseia-se na otimizao global dos sistemas que so compostos de subsistemas, os quais so localmente otimizados para os seus fins especficos. Como resultado, o fluxo de projeto produz um componente de alocao otimizado, o mapeamento de tarefa e escalonabilidade para a aplicao descrita. Alm disso, o fluxo suporta a implementao de todo o sistema em FPGA. A contribuio deste trabalho apresentar as diferenas entre as linguagens de modelagem SysML e MARTE, avaliando os recursos que estas oferecem aos desenvolvedores de sistemas embarcados.

39

5 CONCLUSES

Este trabalho apresentou um estudo sobre a modelagem de sistemas embarcados usando modelos de alto nvel de abstrao. O trabalho apresenta primeiramente fundamentos sobre o projeto e modelagem de sistemas embarcados, para ento apresentar abordagens de modelagem para estes sistemas. As abordagens estudadas baseiam-se na linguagem UML e suas extenses usadas na rea de sistemas embarcados, o SysML e o MARTE, os quais so 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 limitaes. Devido s diversas variaes das aplicaes para sistemas embarcados pode-se concluir que o uso combinado dos dois perfis possvel obter uma modelagem de alto nvel 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 representao grfica de requisitos de uma aplicao 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 atravs da realizao 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

REFERNCIAS

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; Joo 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.; GRARD, 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-padro 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. Avaliao da da SysML atravs da modelagem de uma unidade experimental de automao industrial. XII CBA Congresso Brasileiro de Automao, 2006.

MATTOS, J.; BRISOLARA, L. Desafios no Projeto de Sistemas Embarcados. MATTOS, J; ROSA, L; PILLA, M. Desafios e Avanos em Computao: o estado da arte. v., p. 153-175, 2009.

41

MARWEDEL, P., Embedded Systems Design. Dordrecht, The Netherlands: Springer, 2006.

OMG. (2011a) SysML. Disponvel em: http://www.omgsysml.org/. Acesso em: Outubro, 2011.

OMG. (2011b) UML Profile for MARTE. Disponvel http://www.omg.org/spec/MARTE/1.1/. Acesso em: Outubro, 2011.

em:

PERALDI-FRATI, M.; SOREL, Y. From high-level modeling of time in MARTE to realtime scheduling analysis. In MoDELS08 W. on Model Based Architecting and Construction of Embedded Systems on ACESMB, p.129143, 2008.

ROMERO, A. Uma Abordagem em Arquitetura Conduzida por Modelos e Aplicada a Software de Tempo Real Espacial. Dissertao 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.