Uml-Marte Relatorio

Projeto SIAMES: Modelagem UML-MARTE
Cleiber Marques, Giovani Gracioli e Mateus Ludwich

Disciplina de Sistemas Embarcados
Programa de Pós-Graduação em Engenharia de Automação e Sistemas
Universidade Federal de Santa Catarina
Florianópolis, Outubro de 2009

Conteúdo
Lista de Figuras v
1 Introdução 1
2 UML 3
2.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Diagrama de Máquina de Estados . . . . . . . . . . . . . . . . . . . . 9
3 UML-MARTE 11
3.1 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Utilização do Perfil MARTE . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 Profile Generic Resource Modeling (GRM) . . . . . . . . . . . 13
3.3.2 Profile Hardware Resource Modeling (HRM) . . . . . . . . . . 15
3.3.3 Profile Generic Quantitative Analysis Modeling (GQAM) . . . 16
4 Modelagem do Projeto SIAMES usando UML-MARTE 19

4.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Diagrama de Máquina de Estados . . . . . . . . . . . . . . . . . . . . 21
4.3 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4 Diagramas de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Considerações Finais 27
iii
Lista de Figuras
2.1 Organização dos diagramas UML . . . . . . . . . . . . . . . . . . . . 3

2.2 Diagramas estruturais da UML . . . . . . . . . . . . . . . . . . . . . 4
2.3 Diagramas comportamentais da UML . . . . . . . . . . . . . . . . . . 4
2.4 Representação de uma classe em UML . . . . . . . . . . . . . . . . . 5
2.5 Diagramas de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 Associação em UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7 Agregação e composição em UML . . . . . . . . . . . . . . . . . . . . 6
2.8 Realização de interface e dependência em UML . . . . . . . . . . . . 7
2.9 Diagrama de Casos de Uso em UML . . . . . . . . . . . . . . . . . . 8
2.10 Diagrama de Sequência em UML . . . . . . . . . . . . . . . . . . . . 9
2.11 Diagrama de Máquina de Estados em UML . . . . . . . . . . . . . . 10
3.1 Arquitetura MARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Casos de Uso da especificação MARTE . . . . . . . . . . . . . . . . . 13
3.3 Arquitetura do pacote GRM . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Arquitetura do pacote HRM . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Arquitetura do pacote GQAM . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Diagrama de casos de uso do projeto SIAMES. . . . . . . . . . . . . . 20

4.2 Diagrama de máquina de estados. . . . . . . . . . . . . . . . . . . . . 21
4.3 Diagrama de classes do projeto SIAMES. . . . . . . . . . . . . . . . . 23
4.4 Diagrama de sequência para o monitoramento dos sensores. . . . . . . 24
4.5 Diagrama de sequência do verificador de restrições. . . . . . . . . . . 24
4.6 Diagrama de sequência do controlador do sistema de estacionamento
autônomo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
v
Capı́tulo 1
Introdução
Este trabalho descreve e modelagem do Sistema Autônomo de Estacionamento

(SIAMES) em UML-MARTE. SIAMES trata-se de um projeto cuja proposta é a
construção de um sistema que realize o estacionamento autônomo de um carro con-
vencional, considerando que a vaga de estacionamento esteja localizada paralela-
mente ao carro. O sistema identifica a vaga disponı́vel e é capaz de dirigir o carro
até a vaga encontrada. Uma especificação detalhada dos requisitos do sistema pode
ser encontrada em:
http://moodle.ufsc.br/mod/resource/view.php?id=39362
Os próximos capı́tulos deste trabalho estão organizados da seguinte maneira, o

capı́tulo 2 apresenta a linguagem UML e seus principais diagramas, o capı́tulo 3
apresenta o perfil MARTE da UML, o capı́tulo 4 apresenta a modelagem do projeto
SIAMES em UML-MARTE e são feitas as considerações finais no capı́tulo 5.
2 Capı́tulo 1: Introdução
Capı́tulo 2
UML
Unified Modeling Language (UML) é uma linguagem de modelagem mantida pela

Object Management Group (OMG). A OMG é formada por diversas organizações
e empresas, e cria e mantém diversos padrões além da UML, como por exemplo a
Meta Object Facility (MOF) e a Model Driven Architecture (MDA). A UML provê
diagramas para a modelagem de diversas visões do sistema, são 13 diagramas de
acordo com a UML versão 2.x. Como ilustrado na figura 2.1 estes diagramas especi-
ficam basicamente a estrutura e o comportamento daquilo que se está modelando.
Figura 2.1: Organização dos diagramas UML
A figura 2.2 apresenta os 6 os diagramas estruturais da UML. São eles: Dia-

grama de Classes, Diagrama de Pacotes, Diagrama de Componentes, Diagrama de
Objetos, Diagrama de Estrutura Composta e Diagrama de Utilização. Dentre os
diagramas estruturais, neste trabalho, focamos no Diagrama de Classes, detalhado
mais adiante. Os 7 diagramas restantes da UML, apresentados na figura 2.3, focam
no comportamento. São eles: Diagrama de Casos de Uso, Diagrama de Máquina
de Estados, Diagrama de Atividades, Diagrama de Sequência, Diagrama de Co-
municação, Diagrama de Temporização e Diagrama de Visão Geral de Interação.
Dentre os diagramas de comportamento, neste trabalho, focamos no Diagrama de
Casos de Uso, no Diagrama de Máquinas de Estado e no Diagrama de Sequência,
detalhados mais adiante.
4 Capı́tulo 2: UML
Figura 2.2: Diagramas estruturais da UML
Figura 2.3: Diagramas comportamentais da UML
2.1 Diagrama de Classes

O Diagrama de Classes é um dos diagramas estruturais da UML. Este tipo de
diagrama mostra classes e os relacionamentos entre classes. Uma classe representa
uma categoria do domı́nio que está sendo modelado. Ela especifica um conjunto
infinito de entidades pertencentes a classe, chamadas de objetos. A figura 2.4 apre-
senta como é representado uma classe no Diagrama de Classes. O espaço mais acima
do retângulo contém o nome da mesma (e.g Chronometer). Mais abaixo aparecem
os atributos da classe (e.g. tsc). Os atributos possuem um tipo (e.g. TSC) que
podem ser outras classes ou tipos primitivos (e.g inteiro, caractere). No terceiro sub-
retângulo da classe são apresentadas as assinaturas dos métodos (também chamadas
de operações). Os métodos especificam o que um objeto pertencente a classe em
questão pode fazer, ou seja, seu comportamento. Os valores que são atribuı́dos aos
atributos de um objeto definem seu estado. Dentre as possı́veis relações entre classes
temos: generalização/especialização, associação, agregação e composição (que são
2.1 Diagrama de Classes 5
tipos de associação), realização de interface e dependência.
Figura 2.4: Representação de uma classe em UML
A relação de generalização/especialização, que pode ser vista na figura 2.5, é

definida visualmente por um triângulo. Na figura 2.5 pode-se dizer que a classe
Thread é uma generalização da classe Periodic, lendo-se o triângulo de cima para
baixo. Ao mesmo tempo pode-se dizer que a classe Periodic é uma especialização
da classe Thread, lendo-se o triângulo de baixo para cima. A relação general-
ização/especialização define a chamada “herança” entre classes. No mecanismo de
herança a classe conectada com a base do triângulo é chamada de subclasse ou classe
filha e a classe conectada a um dos vértices do triângulo é chamada de superclasse
ou classe pai. Na figura 2.5 a classe Periodic é subclasse da classe Thread, o que
equivale a dizer que a classe Thread é superclasse da classe Periodic. Pela herança
a subclasse “herda” os atributos e métodos da superclasse. Assim, por exemplo se a
classe Thread possuir um atributo state e um método resumo, estes também estarão
presentes na classe Periodic.
Figura 2.5: Diagramas de classes
A relação de associação diz que uma classe pode “possuir” um determinado

número de elementos de uma outra classe. De acordo com a figura 2.6 a classe Pessoa
possui duas relações com a classe Carro. A associação é representada visualmente
por um segmento de reta. Em uma associação pode ser especificada a multiplicidade
(i.e. número de ocorrências) das instâncias de uma classe, presentes em cada lado
da associação. Na figura 2.6 a associação mais acima indica que uma pessoa pode
possuir zero ou mais carros, indicado pelo asterisco (*) e que o carro por sua vez,
pertence a uma única pessoa, indicado pelo número um (1). Nesta associação ainda
podemos observar o nome de papel “dono”, que detalha qual a função (o papel) do
objeto da classe Pessoa na associação em questão.
Figura 2.6: Associação em UML
Agregação e composição são tipos mais fortes de associação, sendo a composição

a associação mais forte de todas. Na figura 2.7 temos duas composições e uma
agregação. A agregação é indicada por um diamante branco em uma de suas pontas
e a composição, por sua vez, é indicada por um diamante preto. O lado da agregação
que possui o diamante é o lado que “agrega” e o lado oposto é o lado “agregado”.
Na figura 2.7 a classe Equipe de Projeto agrega 1 ou mais objetos da classe Em-
pregado. De forma semelhante à agregação, o lado que possui o diamante, em uma
composição, é o lado que “é composto por” e o lado oposto é o lado “que faz parte
da composição”. Na figura 2.7, na composição mais acima, um objeto da classe
Empresa é composto por uma ou mais equipes de projeto e um objeto da classe
Equipe de Projeto, por sua vez, pertence a um único objeto da classe Empresa. A
multiplicidade do diamante negro de uma composição é implicitamente 1.
Figura 2.7: Agregação e composição em UML
A figura 2.8 demonstra outras duas relações entre classes. São elas: “realização
de interface” e “dependência”. A realização de interface é semelhante a relação
generalização/especialização da herança. A diferença aqui é que se está lidando
com interface e classe ao invés de classe e classe. A diferença entre uma inter-
face e uma classe é que a primeira possui apenas as assinaturas dos métodos e
nunca sua implementação. A classe que realiza a interface, deve portanto imple-
mentar todos os métodos especificados na interface. De forma semelhante à gen-
eralização/especialização a realização de interface é representada por um triângulo,
2.2 Diagrama de Casos de Uso 7
mas neste caso a linha ligando a interface à classe é tracejada. Na figura 2.8 a
classe Classe 1 realiza a interface InterfaceClass. Dependência é um outro tipo de
relação entre classes. Seu significado é mais amplo: uma classe depende da outra se
de alguma forma pode fazer referência a pelo menos uma instância da outra, seja
por associação, ou por chamada de método (parâmetro ou retorno de um objeto da
classe da qual se depende). Na figura 2.8 a classe Classe 2 depende da interface
InterfaceClass.
Figura 2.8: Realização de interface e dependência em UML
Na figura 2.8, pode-se observar que acima do nome InterfaceClass, existe a

palavra “interface” entre “<<>>”. O conjunto “<<interface>>” é chamado de
esteriótipo. Esteriótipo é um mecanismo fornecido pela UML para estender a lin-
guagem. Assim, um retângulo que representaria uma classe, no digrama de classes,
ao possuir o esteriótipo <<interface>>, ganha um novo significado - passa a rep-
resentar uma interface. Além de <<interface>> a UML possui outros esteriótipos
padrões. Alguns deles são aplicados a diagramas de classes e outros são aplica-
dos a outros tipos de diagramas (e.g. sequência, comunicação). Na seção sobre
UML-Marte, um perfil que estende a UML, serão apresentados diversos exemplos
de esteriótipos.
2.2 Diagrama de Casos de Uso

O Diagrama de Casos de Uso é um dos diagramas comportamentais da UML. Os
elementos básicos deste diagrama são os casos de uso e os atores. Um caso de uso
representa uma funcionalidade que o sistema fornece, descrevendo como o usuário do
sistema, chamado de ator, interagirá com o mesmo. O caso de uso pode descrever
quais os passos desta interação e pode inclusive prever interações alternativas à
interação principal. No diagrama de Diagrama de Casos de Uso um caso de uso
é representado por uma elipse contendo o seu nome e um ator é representado por
um boneco (stick man). Uma segmento de reta ligando um caso de uso a um ator
indica que o ator em questão possui participação no caso de uso. Na figura 2.9 o
caso de uso “Pesquisar produtos” possui a participação do ator “Cliente”, o caso de
uso “Cadastrar produtos” possui a participação do ator “Vendedor” e o caso de uso
“Realizar compra” possui a participação de ambos os atores.
Figura 2.9: Diagrama de Casos de Uso em UML
2.3 Diagrama de Sequência
O Diagrama de Sequência é um dos diagramas da UML focado na modelagem

de comportamento. Este diagrama mostra quais mensagens são trocadas entre os
objetos durante a realização de uma determinada tarefa. Dentre os elementos de um
Diagrama de Sequência estão os objetos, as linhas de vida dos objetos, as mensagens
e as execuções das mensagens. Um objeto é uma instância de uma determinada
classe do sistema, sendo representado por um retângulo com o nome da sua classe
e opcionalmente com o seu próprio nome. Uma linha de vida de um objeto é um
elemento que representa que o objeto está “vivo” no sistema, podendo também
mostrar qual o ponto em que o objeto foi criado e qual o ponto em que o objeto será
destruı́do. Uma linha de vida é representada por um segmento de reta tracejado,
desenhado abaixo do retângulo que representa o objeto. As execuções das mensagens
são representadas por pequenos retângulos colocados em cima da linha de vida do
objeto. Das execuções das mensagens partem e chegam as mensagens propriamente
ditas, representadas por segmentos de reta.
A figura 2.10 mostra a pesquisa de produtos em uma loja, informando-se a de-
scrição de um produto. O ator “Cliente” do diagrama de casos de uso mostrado na
figura 2.9, foi modelado como um objeto da classe Cliente. Uma instância da classe
Loja, representa o sistema. Na execução deste diagrama de sequência a loja deve
retornar ao cliente todos os produtos que casem com a descrição por ele informada.
As mensagens desenhadas com segmentos de reta tracejados indicam uma mensagem
de retorno. A caixa contendo a marcação “loop” representa um laço que itera sobre
cada produto da loja. A caixa contendo a marcação “opt” representa uma condi-
cional, que é executada caso a expressão entre colchetes (“[”,“]”) seja verdadeira.
2.4 Diagrama de Máquina de Estados 9
Figura 2.10: Diagrama de Sequência em UML
2.4 Diagrama de Máquina de Estados

O Diagrama de Máquina de Estados é um dos diagramas da UML focado na
modelagem comportamental. Este diagrama mostra quais os estados do sistema e
a evolução dos mesmos. O sistema muda de estado quando um evento ocorre, o
que é representado por uma “transição” entre estados. São elementos básicos do
Diagrama de Máquina de Estados os estados e as transições. Os estados são rep-
resentados visualmente por retângulos de borda arredondada e as transições entre
estados por segmentos de reta. A figura 2.11 mostra o diagrama de Máquina de
Estados de um simulador qualquer. Os estados especiais de inı́cio e fim, são repre-
sentados respectivamente por um cı́rculo preto simples e por um cı́rculo preto com
um com uma circunferência em volta. Os nomes que aparecem próximos as setas de
transição são os nomes dos eventos que ocorrem para que a transição seja efetuada.
“solicitacao de pausa”, por exemplo é o nome do evento que ocorre quando ocorre
uma transição do estado “EXECUTANDO” para o estado “EM PAUSA”.
Figura 2.11: Diagrama de Máquina de Estados em UML

Capı́tulo 3
UML-MARTE
A Unified Modeling Language (UML) foi criada para ser uma linguagem de mod-
elagem para o desenvolvimento de softwares de propósito geral. Porém, com a sua
ampla aceitação, também tornou-se uma opção interessante para projetos de sis-
temas embarcados de tempo real. No entanto, os seus diagramas não possuem
representações adequadas para este domı́nio de aplicação. Como tentativa de su-
perar as deficiências da UML foi desenvolvido primeiramente o perfil Schedulability
Performance and Time (SPT), mas na prática este perfil relevou deficiências na
modelagem de fenômenos de tempo real.
Devido aos problemas encontrados no perfil SPT decidiu-se criar um perfil suces-
sor especı́fico para a modelagem de sistemas embarcados de tempo real, chamado
de Modeling and Analysis of Real-Time and Embedded systems (MARTE). A es-
pecificação do UML-MARTE adiciona ao UML o model-driven development (MDD)
para sistemas embarcados de tempo real (RTES).
O MARTE basicamente fornece, por meio de estereótipos, uma forma de rep-
resentar caracterı́sticas de sistemas embarcados de tempo real em modelos UML.
Foca-se principalmente na análise de escalonabilidade e desempenho. Mas, também
define um framework de análise geral para ser utilizado por outros tipos de análise.
Os principais benefı́cios do perfil MARTE são:
• Fornecer uma forma comum para modelagem de hardware e software utilizando

os aspectos RTES, a fim de melhorar a comunicação entre os desenvolvedores.
• Interoperabilidade entre ferramentas usadas para especificação, projeto, veri-
ficação, geração de código, etc.
• Promover a construção de modelos que possam fazer previsões quantitativas
de tempo, levando em consideração caracterı́sticas de hardware e software.
3.1 Organização
O perfil MARTE é basicamente estruturado em 2 linhas principais: uma re-
sponsável por modelar as caracterı́sticas de sistemas de Tempo Real; outra de análise
12 Capı́tulo 3: UML-MARTE
das propriedades do sistema. Um overview do perfil é apresentado na figura 3.1, ele

é composto por 4 pacotes e os pacotes definem conjuntos de estereótipos:
MARTE Foundantion : fornece meta-modelos para os conceitos, caracterı́sticas

e relações fundamentais do MARTE, ou seja define a semântica para a DSML
fornecida pelo perfil. E os elementos deste pacote são compartilhados por
outros pacotes.
MARTE Design Model : fornece estereótipos para a construção de modelos que
especificam fenômenos especı́ficos de tempo-real e sistemas embarcados. Ele
permite modelagem de plataforma em termos de software ou hardware, po-
dendo ser uma modelagem genérica ou detalhada.
RTEA : fornece estereótipos para análise baseada em software (escalonabilidade e
performance) e também para utilização de memória, energia, confiabilidade e
segurança.
MARTE Annexes : reuni todos os anexos como a definição textual da linguagem.
Figura 3.1: Arquitetura MARTE
3.2 Utilização do Perfil MARTE

Esta seção é destinada a descrever brevemente quais os potenciais atores que
podem utilizar especificação MARTE e como eles podem fazê-lo. Os atores descritos
3.3 Profiles 13
não representam um conjunto exclusivo da utilização da especificação, mas servem

de base de uma utilização ou expansão. Na figura 3.2 é ilustrado um caso de usos
da utilização do perfil MARTE.
Model Designer : estes atores projetam os modelos que serão aplicados no con-
texto de desenvolvimento de sistema. Seus modelos serão utilizados para a
fase de implementação, análise de desempenho, escalonabilidade e requisitos.
estes
Model Analyst : estes atores estão preocupados com anotação dos modelos, a fim
de realizar uma análise das metodologias aplicadas.
Execution Platform Provider : estes atores são os desenvolvedores e fornece-

dores de tecnologias (hardware/software), por exemplo, um sistemas opera-
cional com Real-Time CORBA ou componentes especı́ficos de hardware.
Methodology Provider : estes atores são responsáveis pela definição do modelo

de domı́nio baseado em uma metodologia.
Figura 3.2: Casos de Uso da especificação MARTE
3.3 Profiles
Dentro dos pacotes do MARTE existem uma enormidade de perfis, neste docu-
mento serão abordados somente os que contêm os estereótipos que serão utilizados
para a modelagem do projeto SIAMES (capı́tulo 4).
3.3.1 Profile Generic Resource Modeling (GRM)

Este perfil faz parte do pacote MARTE Foundantion e o seu objetivo é oferecer
conceitos para modelar plataformas para aplicações embarcadas de tempo real. O
principal conceito deste pacote é o de Recurso, o qual pode representar uma entidade
fı́sica ou lógica que oferece serviços. O modelo pode ser feito de diferentes platafor-
mas e nı́veis de detalhes. Por exemplo, pode ser tanto de hardware (mémoria) ou
software (sistema operacional Real-time).
Na figura 3.3 é apresentada a arquitetura do pacote GRM. Dentre os compo-
nentes da arquitetura é possı́vel destacar os seguintes:
ResourceCore : define elementos básicos e suas relações.
ResourceTypes : define os tipos e os serviços fundamentais.
ResourceManagement : especifica recursos de gerenciamento e associação de

serviços.
Scheduling : define componentes, polı́tica e mecanismos para um Scheduling.
Figura 3.3: Arquitetura do pacote GRM
Estereótipos
Alguns exemplos de estereótipos deste perfil:
<<TimingResource>> : representa uma entidade de hardware ou software capaz

de seguir os eventos de tempo.
<<ConcurrencyResource>> e <<SchedulableResource>> : representa re-

cursos protegidos e ativos que podem exercer atividades concocrrentes.
<<Scheduler>> : coordena o acesso ao <<ProcessingResource>> de um

<<SchedulableResource>>.
<<MutualExclusionResource>> : controla o acesso concorrente aos recursos.

3.3 Profiles 15
3.3.2 Profile Hardware Resource Modeling (HRM)

Este perfil faz parte do pacote MARTE Design Model e o seu objetivo é fornecer
mecanismos para modelar o hardware de sistemas embarcados, o que é essencial para
cumprir a especificação de uma aplicação. Os modelos deste perfil pretendem estudar
interdependências de hardware e software que afetam nas decisões de projetos. Na
figura 3.3 é apresentada a arquitetura do pacote GRM. Dentre os componentes da
arquitetura é possı́vel destacar os seguintes:
Figura 3.4: Arquitetura do pacote HRM
HwPhysical : este componente representa os componentes fı́sicos com detalhes de

forma, tamanho, consumo de energia, e outras proprieadades fı́sicas.
HwLogical : o objetivo deste componente é prover modelos funcionais das enti-
dades de hardware.
HwTiming : este componente tem o objetivo de modelar recursos referentes ao
tempo, como relógio, watchdog.
HwPower : este componente tem o objetivo de descrever detalhadamente consumo
de energia e dissipação de calor dos componentes de hardware.
HwStorage : este componente tem o objetivo de modelar os recursos de armazena-
mento de dados, desde memória cache, RAM e também velocidade e tipo de
memória.
Estereótipos
Alguns exemplos de estereótipos deste perfil:
<<hwProcessor>> : mapeia o recurso de hardware processador.

<<hwCache>> : mapeia o recurso de hardware memória Cache.
<<hwBus>> : mapeia o recurso de hardware barramento.
<<hwSupport>> : mapeia recursos de hardware que servem como suporte, por
exemplo, uma bateria.
3.3.3 Profile Generic Quantitative Analysis Modeling

(GQAM)
Este perfil faz parte do pacote RTEA, inclui domı́nios especializados em análise
comportamental do software, desempenho, escalonabilidade, utilização de mémória,
consumo de energia, disponibilidade e segurança. A figura 3.5 apresenta a arquite-
tura do pacote GQAM. Dentre os componentes da arquitetura é possı́vel destacar
os seguintes:
GQAM Workload : define workloads, um workload refere-se a situações (Ex.

decolagem de um avião). Cada workload é representado por uma série de
eventos (WorkloadEvent).
GQAM Resources : define recursos como plataforma de hardware, comunicação
entre dispositivos de hardware, recursos de concorrência, etc.
GQAM Observers : função de observador, fica coletando e medindo unidades
entre intervalos de eventos definidos pelo usuário.
Estereótipos
Para o melhor entendimento dos estereótipos deste pacote é importante o con-

ceito que em resposta a um evento, é definido um BehaviorScenario na qual é com-
posto por sub-operações (Steps) podendo ser de software ou hardware. Alguns
exemplos de estereótipos deste perfil:
<<gaAcqStep>> : um Step que adquiri um recurso. Pode ser utilizado com os

diagramas de máquina de estados, interação, atividades.
<<gaExecHost>> : define um processador que executa Steps.
<<gaResourcesPlatform>> : elemento lógico que define uma plataforma.
<<gaWorkLoadEvent>> : conjunto de eventos relacionados ao comportamento
do sistema.
3.3 Profiles 17
Figura 3.5: Arquitetura do pacote GQAM
<<gaWorkloadGenerator>> : gerador de eventos. Pode ser utilizado com os

diagramas de classes, deployment, sequência, componentes, objetos.
Capı́tulo 4
Modelagem do Projeto SIAMES

usando UML-MARTE
A modelagem do projeto SIAMES utilizando UML-MARTE seguiu as seguintes

fases:
• Análise dos requisitos

Os requisitos do projeto SIAMES foram devidamente analisados conforme a
descrição das especificações funcionais e não-funcionais do comportamento do
sistema. Nesta fase, foram identificadas importantes operações que o sistema
deve possuir, entre elas, um algoritmo de procura de vagas, um algoritmo
para o controle da manobra de estacionamento, controle do movimento do
carro, controle da velocidade do carro e entrada/saı́da de comandos enviados
ou recebidos pelo motorista.
• Diagrama de casos de uso

A partir da análise de requisitos foram desenvolvidos os casos de uso relaciona-
dos com o sistema. Os casos de uso são a descrição das necessidades ou desejos
do sistema. As principais entidades do sistema (atores em um diagrama de
caso de uso) são representadas no diagrama de caso de uso e sua modelagem
permite visualizar o acesso e a utilização de funções requeridas pelos atores.
Tais funções são chamadas de casos de uso e são importantes para gerar uma
visão geral das funcionalidades que o sistema deve possuir.
• Diagrama de máquina de estados

Com base no digrama de casos de uso, verificou-se que o sistema de estaciona-
mento autonômo possuı́a o comportamento de um sistema baseado em eventos
(event-driven), ou seja, o sistema fica à espera de um evento interno ou externo
a ele para que reaja através de uma atividade. Com isso, decidiu-se represen-
tar os possı́veis estados do sistema através de um diagrama de máquina de
estados.
• Diagrama de classes
20 Capı́tulo 4: Modelagem do Projeto SIAMES usando
UML-MARTE
Um diagrama de classes possibilita ter uma visão geral sobre o sistema através
da representação das classes, seus atributos e os relacionamentos entre as
classes. O diagrama de classes foi modelado para representar e assim pos-
sibilitar a implementação dos estados presentes no diagrama de máquina de
estados.
• Diagramas de sequências
Um diagrama de sequência mostra como processos ou objetos trocam men-
sagens e em qual ordem essas mensagens são enviadas. É uma representação
gráfica de um cenário de execução de uma determinada atividade ou operação
do sistema. Os diagramas de sequência foram produzidos utilizando os requi-
sitos funcionais e não funcionais levantados na análise de requisitos com base
nos diagramas de máquina de estados e de classes.
Nas próximas seções serão apresentados os digramas de casos de uso, máquina

de estados, classes e de sequência modelados para o projeto SIAMES. Foi utilizada
a ferramenta de modelagem TopCased e a ferramenta de desenho de diagramas dia
para a modelagem e confecção dos diagramas do projeto.
4.1 Diagrama de Casos de Uso

A Figura 4.1 mostra o diagrama de casos de usos. Foram levantados 3 atores:
o motorista, sensor de distância e sensor de velocidade. O motorista pode iniciar
e parar o sistema de estacionamento autônomo. Ambos sensores de distância e
velocidade são utilizados no algoritmo de procura de vaga. Finalmente, o sensor de
velocidade é utilizado pelo controle da manobra do estacionamento.
Figura 4.1: Diagrama de casos de uso do projeto SIAMES.

4.2 Diagrama de Máquina de Estados 21
4.2 Diagrama de Máquina de Estados

O diagrama de máquina de estados apresentado na Figura 4.2 exemplifica os
possı́veis estados que o sistema pode estar. O sistema é iniciado no estado desabili-
tado. Após receber um comando start do motorista e a velocidade do carro estiver
abaixo de 20km/h, o sistema entra no estado executando (RUNNING). Este estado
é composto por 2 estados concorrentes, um deles composto por 4 sub-estados e outro
composto de apenas 1 estado.
Figura 4.2: Diagrama de máquina de estados.
O estado composto por 4 sub-estados (SCANNING, SLOT FOUND, CHECK-

ING PARK e PARKING) começa pelo estado SCANNING, ou seja, procurando
vaga. Se a vaga é encontrada, há uma transição para o estado SLOT FOUND. Se o
motorista aceitar a vaga, o estado do sistema muda para CHECKING PARK, caso
contrário volta para a procura de vaga (SCANNING).
O estado CHECKING PARK verifica se o carro está parado e se o carro está há
uma distância menor de 20 metros da vaga. Se as duas restrições são verdadeiras, o
estado do sistema muda para estacionando (PARKING). Neste estado, o controle de
manobra de estacionamento calcula a rota e começa o procedimento de estacionar
o carro. Após estacionar o carro, o estado muda para desabilitado.
O segundo sub-estado composto pelo estado VERIFYING EMERGENCY, con-
correntemente ao outro estado, verifica se alguma das seguintes restrições são ver-
dadeiras: (i) velocidade maior que 20 km/h por mais de 2 segundos; (ii) o motorista
pressionou o acelerador; (iii) o motorista pressionou o freio; e (iv) o motorista movi-
mentou o volante. Caso alguma das restrições seja verdadeira, o estado do sistema
muda para emergencyStop, parando o carro e saindo do estado RUNNING.
É importante salientar que as trocas de estados estão sempre relacionadas com
eventos do sistema. No diagrama de classes apresentado na próxima seção, nota-se
que os estados dos sistemas são correlacionados a algumas classes do sistema.
UML-MARTE
4.3 Diagrama de Classes

O diagrama de classes da Figura 4.3 apresenta a visão geral das classes que
compõem o SIAMES. Basicamente, existem 4 tipos de SchedulableResources: Park-
ingSystem, DriverInterface, ConstraintsVerifier e os monitores do sistema que real-
izam a interface Monitor.
Os monitores do sistema (monitores de velocidade, acelerador, distância, e
freio) são executados periodicamente e são responsáveis por realizar uma leitura
em um dos sensores e escrever o valor lido em um objeto global da classe Sen-
sorsData. Esta classe armazena os valores lidos pelos monitores e é compartilhada
com as classes ParkingSystem e ConstraintsVerifier. Por esta razão, o estereótipo
<<MutualExclusionResource>> é usado nesta classe. A interface Sensor abstrai o
acesso aos sensores fı́sicos do veı́culo. O mesmo estereótipo poderia ser usado para
garantir acesso exclusivo em cada atributo e não como a classe inteira. Também
notou-se que não existe concorrência entre os monitores, mas sim entre apenas
um monitor e as classes que realizam a leitura dos valores (ParkingSystem e Con-
straintsVerifier ).
A classe ConstraintsVerifier é responsável por verificar as condições apresen-
tadas no estado VERIFYING EMERGENCY do diagrama de máquina de estados
anterior. O verificador usa a classe Alarm para agendar um alarme de 2 segundos
quando a velocidade ultrapassa os 20 km/h. O alarme usa um temporizador em
hardware (<<HW Timer>>) para a contagem de tempo.
A interface do motorista é responsável por enviar e receber eventos ao/do mo-
torista. Quando uma vaga é encontrada, o motorista deve decidir se aceita a vaga ou
não. O motorista também deve iniciar o sistema e pode pará-lo a qualquer momento.
A modelagem da interface do motorista não entra no escopo deste trabalho.
Por fim, a classe ParkingSystem implementa o sub-estado do estado RUNNING
composto por 4 estados, como apresentado no diagrama de máquina de estados an-
terior. ParkingSystem faz chamadas aos algoritmos de procura de vaga e controle de
manobra de estacionamento sempre que o sistema entra em um estado que os uti-
liza. Tais algoritmos acessam os dados do sensores e atuadores pelo ParkingSystem.
O atributo compartilhado (<<MutualExclusionResource>>) systemState possui o
estado atual em que o sistema se encontra. Este atributo pode ser modificado pela
própria classe ParkingSystem, ou pelo ConstraintsVerifier ou ainda pela interface
com o motorista.
4.4 Diagramas de Sequência

A Figura 4.4 mostra o diagrama de sequência de um dos monitores apresentados
no diagrama de classes. Como o monitor é um SchedulableResource, existirá um
escalonador associado ao objeto, conforme o perfil MARTE. O escalonador libera
o monitor para ser executado a cada “P” ms. O monitor, por sua vez, realiza a
leitura do dado do sensor (velocidade neste caso) e escreve o dado lido no objeto
que armazena os dados dos sensores (SensorsData). Vale-se ressaltar que os outros
4.4
Figura 4.3: Diagrama de classes do projeto SIAMES.

Diagramas de Sequência 23
UML-MARTE
monitores têm comportamento similar, lendo um ou mais sensores e escrevendo os

dados lidos e os armazenando no mesmo objeto.
Figura 4.4: Diagrama de sequência para o monitoramento dos sensores.
O diagrama de sequência do verificador de restrições é apresentado na Figura 4.5.

A cada 20ms o escalonador escolhe o verificador para entrar em execução. A tarefa
do verificador é parar o sistema caso alguma das restrições abaixo sejam verdadeiras:
1. a velocidade do veı́culo permanece acima dos 20km/h por mais de 2 segundos.
2. o motorista pressiona freio.
3. o motorista pressiona o acelerador.
Figura 4.5: Diagrama de sequência do verificador de restrições.
Para atender a restrição (1), o verificador primeiramente recupera a velocidade

do carro armazenada no objeto dos dados dos sensores. Os dados deste objeto
foram previamente preenchidos pelos monitores dos sensores, como apresentado no
diagrama da Figura 4.4. De posse da velocidade, o verificador testa se a velocidade
está maior que 20km/h e, em caso positivo, também testa se o atributo hasAlarm não
é verdadeiro, agendando um alarme para ser executado em 2 segundos e alterando
4.4 Diagramas de Sequência 25
o valor de hasAlarm para verdadeiro. Se a velocidade é menor que 20km/h e um

alarme já foi agendado, isso significa que o veı́culo ultrapassou os 20km/h em algum
momento mas não permaneceu acima por mais de 2 segundos. O tratador (handler )
do alarme é o método stopAll da classe SystemParking responsável por parar o
sistema.
Para satisfazer as restrições (2) e (3), o verificar realiza as leituras dos dados dos
sensores para testar se o freio ou o acelerador foram pressionados. Em caso positivo,
o verificador pára o sistema chamando o método stopAll.
A Figura 4.6 apresenta o diagrama de sequência do controlador do sistema de
estacionamento. A cada “P” ms o escalonador coloca o controlador para ser exe-
cutado. O controlador é baseado nos estados descritos no diagrama de máquina de
estados e para cada estado, um conjunto de tarefas é realizado:
• Estado SCANNING
O controlador faz uma chamada (hasSlot) ao algoritmo de procura de vaga.
O retorno desta chamada é um valor booleano que representa se uma vaga
de estacionamento foi encontrado ou não. Em caso verdadeiro, o controlador
muda o estado do sistema para vaga encontrada (SLOT FOUND).
• Estado CHECKING PARK

Ao mudar o estado para SLOT FOUND, o sistema deve perguntar ao mo-
torista se aceita ou não a vaga encontrada. Esta tarefa é realizada pela in-
terface do motorista. O diagrama de sequência da interface do motorista não
foi construı́do pois fugia do escopo do trabalho. Porém, seu comportamento é
similar ao digrama do controlador do estacionamento, pois deve ler o estado do
sistema periodicamente, e ao detectar o estado SLOT FOUND, perguntar ao
motorista se deseja a vaga e realizar a mudança de estado conforme ao evento
do motorista, voltando ao estado de procura de vaga (SCANNING) ou indo
para o estado de verificar as condições previstas na análise de requisitos antes
de estacionar o veı́culo (CHECKING PARK).
O estado CHECKING PARK testa se a velocidade é 0, ou seja, o veı́culo está
parado e se a distância do veı́culo até a vaga não é maior que 20 metros. Se
ambas as restrições forem satisfeitas, o estado é mudado para PARKING.
• Estado PARKING
Neste estado, o controlador começa o procedimento de estacionamento
chamando primeiramente o método que calcula a trajetória (calculateRoute).
Este calculo não deve demorar mais que 2 segundos para ser realizado. Após
o calculo da trajetória, o método park realiza o estacionamento atuando no
sistema.
UML-MARTE
Figura 4.6: Diagrama de sequência do controlador do sistema de estacionamento

autônomo.
Capı́tulo 5
Considerações Finais
Este trabalho apresentou a modelagem em UML-MARTE do projeto de esta-

cionamento autônomo SIAMES. Foram produzidos os diagramas de casos de uso,
máquina de estados, classes e sequência. Observou-se que UML permite partir da
especificação de requisitos e chegar a um primeiro nı́vel de implementação através da
geração de código que pode ser feita com base nos diagramas de classes e sequência.
UML-MARTE foi utilizado para colocar restrições no sistema, conforme a especi-
ficação de requisitos. Também, UML-MARTE pode ser utilizado para fazer testes
de escalonabilidade e desempenho, integrando uma ferramenta UML-MARTE com
uma ferramenta de análise. Outro ponto referente a UML-MARTE é a difı́cil escolha
dos estereótipos. O perfil apresenta um grande número de estereótipos, sendo que
a escolha de um deles para uma determinada situação não é simples.

Uml-Marte Relatorio

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uml-Marte Relatorio

Enviado por

Direitos autorais:

Formatos disponíveis

Projeto SIAMES: Modelagem UML-MARTE

Cleiber Marques, Giovani Gracioli e Mateus Ludwich

Florianópolis, Outubro de 2009

4 Modelagem do Projeto SIAMES usando UML-MARTE 19

2.1 Organização dos diagramas UML . . . . . . . . . . . . . . . . . . . . 3

3.1 Arquitetura MARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Diagrama de casos de uso do projeto SIAMES. . . . . . . . . . . . . . 20

Este trabalho descreve e modelagem do Sistema Autônomo de Estacionamento

Os próximos capı́tulos deste trabalho estão organizados da seguinte maneira, o

Unified Modeling Language (UML) é uma linguagem de modelagem mantida pela

Figura 2.1: Organização dos diagramas UML

A figura 2.2 apresenta os 6 os diagramas estruturais da UML. São eles: Dia-

Figura 2.2: Diagramas estruturais da UML

Figura 2.3: Diagramas comportamentais da UML

2.1 Diagrama de Classes

tipos de associação), realização de interface e dependência.

Figura 2.4: Representação de uma classe em UML

A relação de generalização/especialização, que pode ser vista na figura 2.5, é

Figura 2.5: Diagramas de classes

A relação de associação diz que uma classe pode “possuir” um determinado

Figura 2.6: Associação em UML

Agregação e composição são tipos mais fortes de associação, sendo a composição

Figura 2.7: Agregação e composição em UML

Figura 2.8: Realização de interface e dependência em UML

Na figura 2.8, pode-se observar que acima do nome InterfaceClass, existe a

2.2 Diagrama de Casos de Uso

Figura 2.9: Diagrama de Casos de Uso em UML

2.3 Diagrama de Sequência

O Diagrama de Sequência é um dos diagramas da UML focado na modelagem

Figura 2.10: Diagrama de Sequência em UML

2.4 Diagrama de Máquina de Estados

Figura 2.11: Diagrama de Máquina de Estados em UML

• Fornecer uma forma comum para modelagem de hardware e software utilizando

das propriedades do sistema. Um overview do perfil é apresentado na figura 3.1, ele

MARTE Foundantion : fornece meta-modelos para os conceitos, caracterı́sticas

Figura 3.1: Arquitetura MARTE

3.2 Utilização do Perfil MARTE

não representam um conjunto exclusivo da utilização da especificação, mas servem

Execution Platform Provider : estes atores são os desenvolvedores e fornece-

Methodology Provider : estes atores são responsáveis pela definição do modelo

Figura 3.2: Casos de Uso da especificação MARTE

3.3.1 Profile Generic Resource Modeling (GRM)

ResourceCore : define elementos básicos e suas relações.

ResourceTypes : define os tipos e os serviços fundamentais.

ResourceManagement : especifica recursos de gerenciamento e associação de

Scheduling : define componentes, polı́tica e mecanismos para um Scheduling.

Figura 3.3: Arquitetura do pacote GRM

Alguns exemplos de estereótipos deste perfil:

<<TimingResource>> : representa uma entidade de hardware ou software capaz

<<ConcurrencyResource>> e <<SchedulableResource>> : representa re-

<<Scheduler>> : coordena o acesso ao <<ProcessingResource>> de um

<<MutualExclusionResource>> : controla o acesso concorrente aos recursos.

3.3.2 Profile Hardware Resource Modeling (HRM)

Figura 3.4: Arquitetura do pacote HRM

HwPhysical : este componente representa os componentes fı́sicos com detalhes de

Alguns exemplos de estereótipos deste perfil:

<<hwProcessor>> : mapeia o recurso de hardware processador.

3.3.3 Profile Generic Quantitative Analysis Modeling

GQAM Workload : define workloads, um workload refere-se a situações (Ex.

Para o melhor entendimento dos estereótipos deste pacote é importante o con-

<<gaAcqStep>> : um Step que adquiri um recurso. Pode ser utilizado com os

Figura 3.5: Arquitetura do pacote GQAM