Modelagem em Sistemas com Restrição de Tempo Real … · Os diagramas de interação descrevem como grupo de ... sobre elementos comuns da UML, ele não representa uma nova linguagem

Revista Pensar Tecnologia, v. 4, n. 1, jan. 2015

Modelagem em Sistemas com Restrição de Tempo Real

Modeling in Systems with Real Time Restriction

Modelado en sistemas con restricción de Tiempo real

Fernando Antônio Gomes1

Rafael Drumond Maciel2

Marcelo Nassau Malta3

Resumo: Este artigo tem como objetivo apresentar a modelagem de sistemas com restriçõesde tempo real (STR).O desenvolvimento dos sistemas de tempo real está diretamente ligado aaplicações que envolvem índices críticos de confiabilidade e segurança, estas característicasvem contribuindo para o aumento da complexidade dos sistemas tempo real e seuconsequente desenvolvimento.Palavras chave: Tempo-real. Modelagem. Restrições de tempo.

Abstract: This article aims to present systems modeling with real-time constraints(STR). Thedevelopment of real-time systems is directly linked to applications involving critical levels ofreliability and security, this feature has contributed to increase complexity of real-time systemsand its development.Keywords: Real-time. Modeling.Time constraints.

Resumen: Este artículo tiene como objetivo presentar el modelado de sistemas conrestricciones de tiempo real(STR). El desarrollo de sistemas de tiempo real está directamenterelacionado con las solicitudes relativas a los niveles críticos de fiabilidad y seguridad, estacaracterística ha contribuido a la creciente complejidad de los sistemas en tiempo real y suconsecuente desarrollo.Palabras clave: en tiempo real. Modelado. La falta de tiempo.

1 - INTRODUÇÃO

Constitui-se tema deste artigo a modelagem em sistemas com

restrições de tempo real. Tais sistemas têm sido alvo de pesquisas voltadas

para técnicas e processos de desenvolvimento, verificação e validação

(Alves, Machado e Ramalho, 2011), devido à sua crescente

importância, aplicabilidade e complexidade. Douglass (2004)

O desenvolvimento de sistemas com restrições é um grande desafio,

por possuírem maior complexidade de desenvolvimento, quando comparado aos

sistemas tradicionais, afirma Sommervile(2011). Este desafio pode ser melhor

tratado com o uso de abstração. Segundo Booch(2012), existem limites para a

capacidade humana de compreender complexidades na modelagem de

1 Graduando do curso Bacharelado em Sistemas de Informação pela Faculdade Infórium [email protected] Graduando do curso Bacharelado em Sistemas de Informação pela FaculdadeInfórium de [email protected]

3 Professor da Faculdade Infórium de [email protected]


sistemas. Neste contexto, destacam-se os sistemas de tempo real, onde a

modelagem se torna uma atividade fundamental na busca por uma solução que

possa atender satisfatoriamente a todos os requisitos e suas restrições de

tempo. Além disso, a modelagem desempenha um papel importante no

processo de desenvolvimento de software.

Segundo Alves, Machado e Ramalho (2011), justifica-se a

compreender a representação dos modelos existentes entre a estrutura e o

comportamento, antes do código ser produzido, com o objetivo de evitar os altos

custos de correção de defeitos de requisitos.

Uma abordagem típica para o desenvolvimento de software é fazer a

modelagem do problema e solução antes de sua construção, pois a

modelagem é uma parte central das atividades que levam à implantação de um

bom software, afirma Booch(2012). Os modelos são construídos para

comunicar a estrutura e os comportamentos desejados do sistema, para

visualizar e controlar a arquitetura do software e para compreender melhor o

sistema.

A UML (Unified Modeling Language), linguagem de modelagem

unificada para desenvolvimento de software, é utilizada frequentemente para

modelagem de software de tempo real, apesar de não ser adequada para este

fim Silvestre(2012). A UML apresenta limitações para modelar software de

tempo real, como a dificuldade para modelar tempo. Segundo Booch(2012), a

UML fornece uma linguagem-padrão para elaboração de estrutura de projeto

de software, mas não é possível expressar todas as mudanças possíveis de

todos os modelos em qualquer domínio e escalonamento Douglass(2004).

Segundo Silvestre(2012), os diagramas comportamentais da UML,

como o Diagrama de Sequência, não podem representar restrições de tempo

efetivamente porque são não temporais, expressando apenas a ordem

cronológica na troca de mensagens entre os objetos.

A utilização correta de linguagens de modelagem tem um papel

importante no desenvolvimento de software. Se a linguagem de modelagem

não for bem definida e não for capaz de produzir modelos expressivos e

completos o suficiente, erros não serão descobertos e poderão ser propagados

para a etapa de construção do software. Além disso, erros podem até mesmo

ser criados na etapa de modelagem. Desta forma, a modelagem de software


não atingirá o seu objetivo principal que é facilitar a construção do software e a

atividade de modelagem.

Assim, delimitou-se o tema deste artigo a criação de um perfil e um

conjunto de diretrizes para apoio a modelagem de sistemas com restrições de

tempo real.

A pergunta norteadora deste artigo é: Como a modelagem em

sistema com restrições de tempo real podem aumentar a abstração reduzindo a

complexidade dos sistemas tempo real e seu consequente desenvolvimento?

O objetivo geral deste artigo é apresentar as características dos

sistemas de tempo real, levantando as principais técnicas de modelagem e

melhores práticas, visando a redução da complexidade para o desenvolvimento

de software. São objetivos específicos conceituar sistemas de tempo real e

propor uma solução para a modelagem em sistemas com restrições de tempo,

por meio deum conjunto de diretrizes e estereótipos.

A relevância deste trabalho consiste em mostrar a importância da

modelagem em sistemas com restrições de tempo.

A pesquisa bibliográfica, fonte primaria, se baseia principalmente em

autores como Booch (2012) e Douglass (2004).

Para compreensão deste tema dividiu-se este artigo em oito seções.

A seção 1, esta introdução, e indicativa do estudo; a seção 2 apresenta

os Sistemas de Tempo Real; a seção 3 aborda a modelagem de dados

para Sistemas de Tempo Real; a seção 4 trata-se de Perfis UML de Tempo

Real; a seção 5 apresenta a Modelagem de Novas Propriedades; a seção 6aborda um Estudo de Caso recorrente ao tema do trabalho; a seção 7apresenta Trabalhos Relacionados; a seção 8 tece as conclusões do artigo.

2 - SISTEMAS DE TEMPO REAL

Segundo Marques (2011), vários critérios podem ser utilizados para

classificar sistemas operacionais. Contudo, existem três dimensões relevantes

por terem implicações profundas sobre a estrutura e utilização dos

sistemas operacionais:


Relação de execução com o tempo cronológico;

Dimensão do sistema;

Política de distribuição e comercialização;

Os sistemas em que o tempo cronológico é relevante são conhecidos

como sistemas de tempo real. Esses têm um objetivo de garantir que o

computador produza uma resposta a um evento externo ao fim de um intervalo

de tempo limitado e previamente especificado.

Para Sommerville(2009), sistema de software de tempo real é um

sistema cujo funcionamento correto depende tanto dos resultados produzidos

pelo sistema quanto do tempo em que esses resultados são produzidos. A

operação corrente é degradada se os resultados não forem produzidos em

conformidade com os requisitos de tempo específicos.

Segundo Silvestre(2012), tais sistemas de tempo real são

frequentemente reativos, embarcados, distribuídos e complexos. Os sistemas

reativos são aqueles em que o agendamento de tarefas é dirigido pela sua

interação com o ambiente.

Um sistema de tempo real é usado quando existem requisitos de

tempo rígidos na operação de um processador ou fluxo de dados. Dessa forma,

ele é usado como dispositivo de controle em uma aplicação dedicada. Um

sistema de tempo real possui restrições bem definidas e com tempo fixo. O

processamento precisa ser feito dentro das restrições definidas, caso contrário,

o sistema falhará. Um sistema de tempo real restrições de tempo.

3 - MODELAGEM EM SISTEMAS DE TEMPO REAL

Os diagramas de interação descrevem como grupo de

objetos colaboram em algum comportamento. A UML define várias formas de

interação das quais a mais comum é o Diagrama de Sequência Fowler(2005).


Figura 1- Diagrama de sequência.

Fonte: elaboração do autor.

3.1 - Mecanismos de Extensibilidade da UML

A UML se torna mais simples e portável devido a presença de quatro

mecanismos que são aplicados de maneira consistente nas especificações. São

os adornos, divisões comuns e mecanismos de extensibilidade, segundo

Booch(2012). Esse mesmo autor afirma que a UML é aberta, permitindo que se

amplie a linguagem de maneira controlada.

Os mecanismos de extensibilidade da UML incluem estereótipos,

valores atribuídos e restrições. Esses três mecanismos de extensibilidade

permitem ampliar a UML com a criação de perfis, de acordo com a

necessidade do projeto, permitindo que a UML se adapte a novas tecnologias de

software.

4 - PERFIS DE UML DE TEMPO REAL

Segundo Booch(2012), um perfil em UML é um conjunto de

estereótipos predefinidos, valores atribuídos, restrições e classes de base. Eles

também selecionam um subconjunto dos tipos de elementos da UML para uso, de

maneira que um modelador não fique confuso em função dos tipos de elementos

que não são necessários para área de aplicação particular. Um perfil define uma


versão especializada da UML para uma determinada área. Como o perfil é criado

sobre elementos comuns da UML, ele não representa uma nova linguagem e

pode ser suportado por ferramentas comuns da UML.

4.1 - UML SPT

O perfil SPT (UML Profile for Schedulability, Performance, and Time) foi

criado como tentativa de superar os problemas da UML para modelagem de

software de tempo real. Porém, não foi bem recebido pela comunidade de

desenvolvimento de software, como afirma Silveira (2012).

4.2 UML MARTE

A partir dos problemas encontrados no SPT, um novo profile UML foi

proposto: MARTE (Modeling and Analysis of Real-Time and Embedded

Systems), com foco na UML 2.0. MARTE é uma evolução do SPT, especializando

a UML ao adicionar conceitos para modelar e analisar sistemas embutidos de

tempo real Silveira(2012). O perfil MARTE fornece conceitos necessários para

descrever características que especificam a semântica de sistemas de tempo

real em diferentes níveis de abstração e consiste na definição de fundamentos

para uma descrição baseada em modelos de sistemas embutidos de tempo

real. Os principais conceitos são refinados para interesses de modelagem e

análise. As partes de modelagem fornecem suporte necessário para uma

especificação de um projeto de sistemas contemplando características

de tempo real desde a especificação até o projeto.

Silveira(2012) enfatiza que as extensões fornecidas pelo MARTE são

focadas em estereótipos, restrições, valores rotulados e enumerações e o

modelo é organizado em pacotes. Os fundamentos dos pacotes MARTE são

compostos por subpacotes, elementos principais, propriedades não funcionais,

modelagem de tempo, modelagem de recursos genéricos e modelagem de

alocação.


5 - MODELAGEM DE NOVAS PROPRIEDADES.

Segundo Booch(2012), ao usar a UML para criar um modelo,

deve-se trabalhar de acordo com as regras que a UML se baseia, pois assim será

possível expressar tudo que se deseja sem ambiguidade a qualquer pessoa que

saiba interpretar a UML.

A UML incluiu um dispositivo que permite adequar os modelos a um

determinado domínio, permitindo que estes se tornem mais expressivos e

condizentes com o contexto que devem representar. São os chamados perfis

(profiles).

Para melhor identificar e modelar sistemas reativos um novo perfil foi

proposto. Sabe-se que na literatura existem alguns perfis que se propõem a

auxiliar a modelagem de sistemas reativos, conforme descritos na Seção 4.Porém, estes lidam nas suas especificações com artefatos em nível de abstração

mais baixo com informações de baixo nível podem ser complexos de construir

e acabam por confundir os desenvolvedores, especialmente se estes forem

iniciantes ou com pouca experiência no desenvolvimento de sistemas reativos.

O perfil proposto é composto por dez estereótipos, baseados no

trabalho de Douglass (2004). Os estereótipos presentes no perfil proposto

são aplicados aos elementos do Diagrama de Sequência da UML descritos na

Seção 3. A aplicação destes estereótipos, em geral, tem por objetivo identificar

aspectos importantes na modelagem de Sistema de Tempo Real são exibidos no

Quadro 1.


Quadro 1- Definição dos estereótipos

Estereótipo Descrição

<<RTpriority>> Estereótipo aplicado aprioridade da ação de uma tarefa.

<<RTblockingTime>>Estereótipo aplicado aduração do tempo que a ação deespera para os recursos bloqueados.

<<RTreadyTime>>

Estereótipo aplicado ao tempo de libertação efectivaexpressa como o período de tempo desde o início de umperíodo; com efeito, um atraso entre o momento em queuma entidade é elegível para a execução de um começoreal de execução.

<<RTDelayTime>>Estereótipo aplicado ao período de tempo uma ação queé elegível para espera de execução, enquanto aaquisição e liberação de recursos.

<<RTreleaseTime>>O instante de tempo em que um trabalho deprogramação torna-se elegível para execução.

<<RTpreempted Time>>

Estereótipo aplicado a Tempo que será usado por cadaprocesso, e tem o poder de tomar de volta este tempo edá-lo para outro processo segundo seu esquema deprioridades.

<<RTstart>>Estereótipo aplicado no inicio de uma ação com restriçãode tempo.

<<RTend>>Estereótipo aplicado ao fim de uma ação com restriçãode tempo.

<<RTduration>>Estereótipo aplicado a duração total de uma ação comrestrição de tempo.

<<RTisr>>Estereótipo aplicado a qualquer elemento cujasemântica faz referência a interrupção.

Fonte: elaboração do autor

Com estes elementos, torna-se mais simples e completa a execução

das atividades do processo de modelagem. Os modelos ficam mais

claros e expressivos, possibilitando que os desenvolvedores compreendam

melhor o projeto para produzir os artefatos de software corretamente.

5.1 - Diretrizes para Modelagem com Restrições de Tempo


Com o objetivo de apoiar a atividade de modelagem usando UML, um

conjunto de treze diretrizes de modelagem foi definido exibidas no Quadro 2,

as diretrizes foram baseadas nos trabalhos de Douglass(2004), Booch(2012)

e Alves, Machado e Ramalho(2011). As diretrizes propostas são destinadas aos

diagramas dinâmicos da UML.

Quadro 2 – Conjunto de diretrizes

ID DESCRIÇÃO

D1

Para cada evento existente em uma iteração, considere se ele deve ser

iniciado em algum tempo absoluto. Faça a modelagem dessa

propriedade de tempo real com restrição de tempo utilizando o

estereótipo <<RTstart>> e<<RTend>>.

D2

Para cada sequência de mensagem relevante em uma iteração,

considere se existe um tempo relativo máximo associado a essa

sequência. Caso exista, utilize o estereótipo <<RTduration>>para a

propriedade com restrição de tempo para sequência.

D3Considerar as questões de segurança, volatilidade e qualidade de

serviço.

D4 Nomes significativos a marcas de tempo devem ser utilizados.

D5 Diferencie com clareza expressões de tempo relativo e absoluto.

D6

Mostre as propriedades de espaço somente quando isso for

importante para visualizar a localização dos elementos em um

sistema implantado.

D7 O contexto para interação deve ser definido.

D8 A linha de vida para cada objeto deve ser definida.

D9Se for necessário especificar restrições de tempo ou espaço adorne

cada mensagem com uma marca de tempo anexe as restrições.

D10 Escolha os estados inicial e final para o objeto.

D11 Distribua os elementos de forma a minimizar o cruzamento de linhas.

D12 Anotar os componentes que possuem características reativas com oestereótipo «RTreactive».

D13 Usar o estereótipo «RTisr» para sinalizar as transições que possuemeventos ou tratamento de uma interrupção.




6 - ESTUDO DE CASO

Considerando a necessidade dos Registradores Eletrônicos de Ponto

(REP) registrarem fielmente as marcações efetuadas, não sendo permitida

qualquer ação que desvirtue os fins legais a que se destinam, foi publicada em

05 de dezembro de 2013 a portaria n.º 595 que determina os requisitos

essenciais devem ser atendidos pelo REP, com foco no desempenho, visando

ao registro fiel das marcações de ponto efetuadas, preservando a

inviolabilidade do REP ampliando a segurança da informação deste objeto, em

complementaridade à Portaria MTE nº 1.510/2009.

A portaria MTE nº 595/2013 descreve um conjunto de requisitos

funcionais que possuem restrições de tempo. A portaria define que os

requisitos funcionais são um conjunto de serviços que o REP deve fornecer e

como deve reagir a entradas específicas e como devem se comportar em

determinadas situações de forma a registrar fielmente as marcações de ponto.

Alguns desses requisitos definidos no documento possuem um prazo ou

tempo-limite para os estímulos a serem processados para gerar a saída correta.

Portanto, o REP pode ser considerado um sistema de tempo real.

A empresa Keypass Tecnologia LTDA, situada em Belo Horizonte -

MG, atualmente está desenvolvendo o REP modelo KP1510-IN, com o objetivo

de atender aos requisitos essenciais estabelecidos na portaria MTE nº 595/2013

e manter sua competitividade no segmento de relógios de ponto. O REP

KP1510 IN é representado na Figura 2.

Figura 2 – REP modelo KP1510-IN



Segundo a portaria MTE nº 595/2013 os requisitos essenciais

referem- se aos aspectos de desempenho do produto e estabelecem diretrizes

do Programa de Avaliação da Conformidade para Registrador Eletrônico de

Ponto. Os requisitos funcionais do KP1510-IN foram representados através do

diagrama de caso de uso representado na Figura 3.

Figura 3- Diagrama de caso de uso requisitos funcionais


6.1 - Análise dos Requisitos de Rempo Real

O processo de modelagem iniciou-se a partir de uma necessidade

após a reprovação no processo de análise da conformidade quanto aos

requisitos funcionais com restrições de tempo, descrito nos itens 5.1.8.2 e

5.2.11 da portaria MTE nº 595/2013. O projeto de software foi desenvolvido

sem documentação adequada, a modelagem dos requisitos com restrições de

tempo não foi realizada no inicio do projeto, ocasionando erros na codificação e

arquitetura que só foram percebidos no momento dos testes de certificação.

Os testes foram realizados no laboratório de medidas do Instituto

Nacional de Telecomunicações (INATEL) situado em Santa Rita do Sapucaí -

MG, na primeira quinzena do mês de agosto de 2014.


Os requisitos funcionais com restrições de tempo que devem ser

atendidos pelo registrador eletrônico de ponto, estão descritos na portaria MTE

nº 595/2013. De acordo com o item

5.1.8.2, o REP deve sempre apresentar o horário no mostrador do

Real Time Clock (RTC) e a base de tempo que gera informações para o

mostrador do REP. Este deve comparar suas medições pelo menos a cada

um segundo com o RTC, ajustando seu horário para aquele indicado pelo

RTC. O Item 5.2.11 determina que o REP deve respeitar a uma serie de

condições de tempo de gravação do Arquivo Fonte de Dados (AFD) na porta

fiscal. Esse arquivo é gerado a partir dos dados armazenados na Memória de

Registro Permanente (MRP), contendo todos os dados armazenados na MRP

na Porta Fiscal.

A taxa de transferência real mínima de transmissão dos dados da

MRP para o dispositivo externo de memória, por meio da Porta Fiscal, deve

ser 219,73 Kbits/s. O tempo máximo de captura da MRP esgotada deve ser 40

minutos. A contagem de tempo de captura do AFD deve ser suspendida

quando ocorrer marcação de ponto simultaneamente à referida captura.

Uma vez identificados os requisitos com restrições de tempo

reprovados no processo de análise de conformidade, foi possível iniciar a

atividade de análise do código fonte e iniciar a modelagem dos requisitos com

restrições de tempo.

O software embarcado do REP KP1510-IN foi desenvolvido em

parceria com a empresa chinesa ZK Software. O software embarcado foi

desenvolvido em linguagem de programação C e é executado em um sistema

operacional de tempo real proprietário, conforme descrito nos requisitos não

funcionais da portaria.

Durante a análise do código fonte, constatou-se que o software

desenvolvido não utiliza os recursos de tempo real corretamente.

Softwares embarcados que não possuem controle temporal explícito

são conhecidos como super-loop, onde a aplicação consiste de um loop infinito

sem uma condição de saída. A lógica da aplicação é definida por chamadas a

sub-rotinas numa ordem sequencial, dentro do loop, levando em consideração

que essa sequência determina o comportamento temporal da aplicação.


O loop principal é chamado de background, o qual pode ser

interrompido por interrupções, que fazem as rotinas de tratamento, a

essas rotinas é dado o nome de foreground. Após o término do processamento

dessas funções, o sistema troca o contexto de execução novamente para a

operação de background conforme o ilustrado na Figura 4.


Figura 4- Software super-loop


Esse tipo de desenvolvimento possui uma grande desvantagem, pois

não é determinístico no que se refere a tempo. Uma simples alteração no loop

principal pode alterar o comportamento temporal de todo processamento

posterior ao ponto modificado.

6.2 - Modelagem dos Requisitos com Restrições de Tempo

Para iniciar a etapa de modelagem dos requisitos com restrições de

tempo real, fizemos o uso do Diagrama de Sequência para representar os

aspectos dinâmicos do sistema e o conjunto de diretrizes e estereótipos

propostos neste artigo para representar comportamento temporal do sistema.

O Diagrama de Sequência é um diagrama de interação que dá ênfase

à ordenação temporal de mensagens, conforme descrito na Seção 3 deste

trabalho. O diagrama é representado graficamente por dois eixos, sendo o X

para representar as mensagens, e o Y para representar o tempo.

A solução proposta para solucionar o problema do KP1510- IN, foi

representada por meio da modelagem as características que um sistema

operacional de tempo real oferece e as tarefas com restrições de tempo, para

que elas sejam executadas no tempo máximo estipulado.

A modelagem proposta consistiu em dividir o sistema em tarefas e

definir as prioridades de acordo com as características de tempo real de cada

uma delas, resolvendo os travamentos das funções blocantes que

provocaram a reprovação do REP KP1510-IN. Dá-se o nome de tarefas


aos pedaços de código que executam um trabalho específico e bem definido,

que podem se comunicar com outras tarefas do sistema por meio de serviços

oferecidos pelo kernel do RTOS.

Todas as funcionalidades do sistema com restrições de tempo

serão divididas em tarefas. Desta forma, o kernel decide quando uma tarefa deve

ser executada de acordo com a sua prioridade.

Em sistemas multitarefa, temos a impressão de que todas as tarefas

estão sendo executadas ao mesmo tempo. Porém, o processador só pode

executar uma tarefa de cada vez, pois é realizado um chaveamento entre as

tarefas, conforme ilustrado na Figura 5.

Figura 5- Escalonamento entre as tarefas


A Figura 6 apresenta a modelagem proposta, fazendo uso do

diagrama de sequência para a correção dos problemas que ocasionaram a

reprovação no processo de certificação. Devido a dificuldade em expressar com

riqueza de detalhes a modelagem em um único diagrama, as Figuras 7, 8, 9 e 10

demonstram o uso do conjunto de estereótipos e diretrizes propostas neste

artigo.


Figura 6 - Modelagem dos requisitos com restrições de tempo

Fonte:elaboração do autor


Figura7-Detalhe da utilização dos estereótipos RTduration


Figura 8-Detalhe da utilização dos estereótipos RTStart e RTisr



Figura 9-Detalhe da utilização dos estereótipos RTstart


Figura 10-Detalhe da utilização dos estereótipos RTend


7 - TRABALHOS RELACIONADOS

Algumas abordagens de modelagem surgiram ao longo das últimas

décadas para modelar software de tempo real. Entre as representações mais

conhecidas na literatura estão à análise estruturada com extensões para tempo

real, as abordagens formais e as abordagens orientadas a objetos. As

abordagens orientadas a objetos são representadas principalmente pela UML

SPT e MARTE. Um estudo detalhado destes perfis encontra-se no trabalho de

Silveira(2012) onde é realizado um estudo sobre a modelagem de software de

tempo real utilizando o profile MARTE da UML.


8 - CONCLUSÃO

Para a compreensão do tema da modelagem em sistema com

restrições de tempo real, buscou-se inicialmente rever a base conceitual e a

teoria sobre essa questão.

A fundamentação teórica permitiu verificar que a modelagem em

sistemas com restrições de tempo é complexa e demanda a elaboração de

modelos com objetivo de aumentar a abstração e, consequentemente, a

simplificação no processo de modelagem de sistema com restrições de tempo.

Autores como Booch(2012) e Douglass(2004) caracterizam a

modelagem em sistemas em sistema de tempo real como complexas. Isso

permite afirmar que o conjunto de diretrizes e estereótipos propostos neste artigo

auxilia o desenvolvedor, aumentando a abstração.

Dessa forma, pode-se concluir que a modelagem proposta neste artigo

é recomendada para sistemas com restrições de tempo, pois permite prever as

diferentes mudanças que podem ocorrer. A modelagem também pode facilitar de

forma significativa a manutenção e as atualizações do sistema ao longo do seu

ciclo de vida.

Como trabalho futuro pretende-se realizar outro estudo a fim de aferir

de forma mais precisa as vantagens e limitações das diretrizes propostas, além

de contribuir para a sua evolução e aplicação em contextos práticos,

considerando diferentes aplicações e plataformas e possível evolução dos

artefatos gerados neste artigo, perfil e diretrizes para uso em outros contextos.


REFERÊNCIAS

ALVES, Everton L. G; MACHADO, Patrícia D. L; RAMALHO, Franklin

Diretrizes para Modelagem Independente de Plataforma de Sistemas deTempo Real usando UML, 2011.

BOOCH, Grady ;Rumbaugh, James; Jacobson, Ivar; UML guia do usuário. 2a

ed. RJ:Elsier, 2012.

BRASIL. Portaria nº 595, de 05 de dezembro de 2013.

DOUGLASS. B.P. Real-time UML: developing efficient objects for embedded

systems.Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2004

FOWLER, Martin. UML Essencial: Um Breve Guia para Linguagem Padrão. 3a

ed. SP: Bookman, 2004.

SILVESTRE, Eduardo. Modelagem de software de tempo real utilizando o profile

MARTE da UML, 2012

SOMMERVILE,Ian. Engenharia de Software. 9a ed. SP :Pearson Education, 2011.

MARQUES, José Alves. Sistemas Operacionais.2a ed. RJ: LTC, 2011.

Documents

Modelagem em Sistemas com Restrição de Tempo Real … · Os diagramas de interação descrevem como grupo de ... sobre elementos comuns da UML, ele não representa uma nova linguagem