Desenvolvimento de sistemas embarcados
Metodologia OMEGA
Gregório Baggio Tramontina (RA 014864)
Ricardo Ribeiro dos Santos (RA 030060)
IC - UNICAMP
MO409
1
Roteiro
 Contexto de desenvolvimento de software embarcado
 Metodologia Omega
Motivação
Características
Fases
Modelos
 Ferramentas
 Parceiros
 Prós e contras
 Conclusões
IC - UNICAMP
MO409
2
Metodologias para desenvolvimento
de software embarcado
 Software Embarcado: realiza uma tarefa muito específica relacionada com o
ambiente ao qual está inserido
 Exemplos: controle de aparelhos domésticos, sistemas de
processamento de sinais, entre outros
 Software embarcado possui particularidades
 divisão de tarefas com HW
 forte integração com plataforma de baixo nível
 requisitos de tempo
 Contexto do trabalho: Software que atua em um dispositivo móvel e
possibilita que um usuário possa realizar algumas operações relacionadas ao
sistema de hotel
IC - UNICAMP
MO409
3
OMEGA
 Resultado do projeto Omega (http://www-omega.imag.fr) iniciado em 2002
 Motivação: Suporte formal (notações e ferramentas) em todas as fases de
desenvolvimento
 Foco: Sistemas Embarcados de tempo real
 Seleção e extensão de um subconjunto de notações UML
 Ênfase na modelagem dos aspectos comportamentais e estáticos do sistema
 Processo de desenvolvimento inspirado em abordagens utilizadas pela
indústria:
 Requisitos, arquitetura, análise e projeto e implementação
Requisitos
IC - UNICAMP
Definição
da
arquitetura
MO409
Análise e Projeto
Refinar
Produzir versão do sistema
4
Requisitos
 Requisitos são expressos por meio de diagramas de casos de uso
 Segue a especificação UML
 Nesta fase, substitui-se o diagrama de seqüência pelo Live Sequence Chart
(LSC) para representar as interações entre elementos de um cenário
 LSC com recursos de temporização
Algumas características dos LSCs:
 distinguem entre cenários que podem (existencial) dos que devem (universal)
acontecer no sistema
 inclusão de condições que podem ser verdadeiras (condições “frias”) e condições
que devem ser verdadeiras (condições “quentes”)
 permite atribuições explicitamente
IC - UNICAMP
MO409
5
Exemplo - Requisitos

Estudo de caso: sistema de hotel
Verificar
Disponibilidade
Verificar
Despesas
Realizar
Préreserva
cliente
Realizar
Cadastro
Emitir
relatórios
gerentes
empresários
IC - UNICAMP
MO409
6
Exemplo - Requisitos

Caso de uso: Verificar disponibilidade
 Modelagem usando LSC
Cliente
Dispositivo
Condição quente
Controle de Cadastro
Pre-chart
Estado=ocioso
loop
Consulta sist. disponibilidade
*
Requisita lista hotéis
Atribuição
T1: Time
chart
Informações dos hotéis
Time<T1+30
Informações dos hotéis
Condição fria
Seleciona hotel, período da
reserva
*
Verifica disponibilidade no período
T2: Time
Lista quartos livres
Lista quartos livres
IC - UNICAMP
Time<T2+30
MO409
7
Arquitetura
 Arquitetura do software é descrita por componentes que interagem
através de interfaces
 Componente: parte modular do sistema que encapsula conteúdo e expõe
um conjunto de interfaces
 Componentes são representados pelo diagrama de componentes
 A definição e modelagem da arquitetura segue o documento UML 2.0
Proposal v. 0.671 (draft)
IC - UNICAMP
MO409
8
Exemplo - Arquitetura
 Definição e relacionamento entre componentes do sistema de
disponibilidade
inf_hotel
inf_reserva
«component»
hotel
Sist
Disponibilidade
Hotel
reserva
IC - UNICAMP
«component»
«component»
Reserva
MO409
hóspede
«component»
Hospede
9
Análise e Design
 Análise inicial do domínio da aplicação
 Iteração das etapas:
 Análise e design de uma parte do sistema (incremental)
 Gradualmente adicionam-se detalhes até que se esteja próximo
de uma implementação concreta (refino)
 Inicialmente protótipos rápidos, depois produção de sucessivas
releases com funcionalidade crescente
 Use-case driven: a cada iteração, um use-case é desenvolvido
 Notação básica: diagrama de classes
 Object Constraint Language (OCL)
 diagrama de estados (classes reativas)
IC - UNICAMP
MO409
10
Exemplo - Análise e Design
 Diagrama de classes
IC - UNICAMP
MO409
11
Exemplo - Análise e Design
 Statechart
IC - UNICAMP
MO409
12
Implementação
 Mapeamento do design detalhado em uma arquitetura
física particular e codificação
 Enriquecimento dos diagramas UML com
 limites de tempos de execução
 mapeamento de processos para processadores
 políticas de escalonamento
 prioridades
 etc.
 Principal notação: Deployment diagram
 visão estática da distribuição dos componentes no sistema
especifica a distribuição de “artefatos” (componentes,
softwares de terceiros, etc.) para os “nós” (recursos
computacionais)
IC - UNICAMP
MO409
13
Exemplo - Implementação
 Deployment diagram
<<Wireless>>
<<device>>
:ServAplicação
{SO=LinuxRT}
<<TCP/IP>>
<<artifact>>
VerificaDisp
<<device>>
:DispositivoMóvel
{SO=PalmOS}
<<artifact>>
Navegador Web
{fornecedor=Palm}
{componente=Sist. Disponibilidade
Local=/app/bin/}
<<artifact>>
CadHoteis.so
{componente=Hotel
Local=/app/bin/}
<<device>>
:ServBD
{SO=Linux}
BD do Hotel
<<database>>
{fornecedor=Oracle
Versão=9i}
<<artifact>>
Reservas.so
{componente=Reserva
Local=/app/bin/}
IC - UNICAMP
MO409
14
Apoio ferramental
 Desenvolvimento pela própria equipe do projeto e por terceiros
Fonte: http://www-omega.imag.fr
IC - UNICAMP
MO409
15
Parceiros
Fonte: http://www-omega.imag.fr
16
MO409
IC - UNICAMP
Prós e Contras
 Busca ser completa e rigorosa
 Usa UML, que já é conhecida
 Processo de desenvolvimento
proposto pela metodologia
segue um workflow simples
 Traz os requisitos de tempo
real do domínio não funcional
para o funcional
 Projeto desenvolve ferramentas
para suporte à metodologia
 Possui parceiros acadêmicos e
industriais que ajudam na avaliação
da metodologia
IC - UNICAMP
 Não contempla a fase
de testes e manutenção
MO409
 As ferramentas ainda não estão
completas
 Integração hardware-software
precisa de mais atenção
 Ainda está em desenvolvimento
17
Conclusões
 No estágio atual, OMEGA é voltada para características de
tempo real
 Espera-se que, quando mais desenvolvida, contemple a
integração hardware-software mais fortemente
 Não serve apenas para softwares embarcados
 No geral, metodologias ainda não estão bem definidas
 Geralmente específicas para cada domínio
 Literatura apresenta vários processos, ferramentas,
linguagens de especificação, mas há lacunas quanto a
metodologias completas
IC - UNICAMP
MO409
18
Referências

Hooman, J., Towards Formal Support for UML-based Development of Embedded
Systems. Proc. of the 3d PROGRESS Workshop on Embedded Systems, Technology
Foundation STW, p. 71-76, 2002.

Graf, S., Hooman, J., Correct Development of Embedded Systems. Proc. of the First
European Workshop on Software Architecture (EWSA 2004), LNCS 3047, SpringerVerlag, pp. 241-249, 2004.

Damm, W., Harel, D.,LSCs: Breathing Life into Message Sequence Charts. Formal
Methods in System Design, v. 19, p. 45-80, 2001, Kluwer Academic Publishers.
Netherlands.

Harel, D., Marelly, R., Playing with Time: On the Specification and Execution of TimeEnriched LSCs. In Proc. 10th IEEE/ACM Int. Symp. on Modeling, Analysis and
Simulation of Computer and Telecommunication Systems, Fort Worth, Texas 2002.

Agrawal, S., Bhatt, P., Real-time Embedded Software Systems – An Introduction.
Technology Review #2001-04, Tata Consultancy Services, August, 2001, Disponível em
http://www.tcs.com/0_whitepapers/htdocs, Visitado em 08/11/2004.
IC - UNICAMP
MO409
19
Referências

Gurd, A., Using UML 2.0 to Solve Systems Engineering Problems. Telelogic White
Paper, 2003, disponível em http://www.telelogic.com/download/paper, Visitado em
08/11/2004.

OMG, UML 2.0 Proposal v. 0.671 (draft), disponível em
http://www.omg.org/cgi-bin/doc?ad/02-01-12, visitado em 23/11/2004.

Site oficial OMEGA, http://www-omega.imag.fr, visitado em 25/11/2004.

OMG, OMG Unified Modeling Language Specification, versão 1.5, Março/2003,
disponível em http://www.omg.org/cgi-bin/apps/doc?formal/03-03-01.pdf,
visitado em 25/11/2004.

Site oficial PVS Specification and Verification System, http://pvs.csl.sri.com/,
visitado em 25/11/2004.
IC - UNICAMP
MO409
20
Fases, UML e Ferramentas
Workflow
Omega/UML
Ferramentas
Requisitos
-Use Case Diagrams
-LSCs, OCL
-Máq. Estados
-Play-in/play-out (LSCs)
-Consistência dos LSCs e OCL
-Refino das especificações
-Dedução de propriedades
Arquitetura
-Componentes, Connectores,
Portas, Interfaces, LSCs, OCL,
Máq. Estados
-Corretude com os requisitos
-Verificação composicional
-Análises de aspectos de
tempo
Análise e Design
-Diagramas de classes
-OCL
-Máq. Estado
-Corretude com componentes
-Síntese de statecharts
-Corretude dos passos de
refinamento
Implementação
Deployment diagram
Verificação e síntese de
escalonamento
IC - UNICAMP
MO409
21