MATTOS VIRTUAL MACHINE (MVM): MÁQUINA VIRTUAL MOBILE

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
MATTOS VIRTUAL MACHINE (MVM): MÁQUINA
VIRTUAL MOBILE
ANDREY DE OLIVEIRA
BLUMENAU
2012
2012/2-03
ANDREY DE OLIVEIRA
MATTOS VIRTUAL MACHINE (MVM): MÁQUINA
VIRTUAL MOBILE
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Ciência
da Computação — Bacharelado.
Prof. Mauro Marcelo Mattos, Doutor – Orientador
BLUMENAU
2012
2012/2-03
MATTOS VIRTUAL MACHINE (MVM): MÁQUINA
VIRTUAL MOBILE
Por
ANDREY DE OLIVEIRA
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
Presidente:
______________________________________________________
Prof. Mauro Marcelo Mattos Orientador, Doutor – Orientador, FURB
Membro:
______________________________________________________
Prof. Antonio Carlos Tavares, Mestre – FURB
Membro:
______________________________________________________
Prof. Miguel Alexandre Wisintainer, Mestre – FURB
Blumenau, 10 de dezembro de 2012
Dedico este trabalho a todos os amigos,
especialmente aqueles que me ajudaram
diretamente na realização deste.
AGRADECIMENTOS
A Deus, pelo seu imenso amor e graça.
À minha família, que mesmo longe, sempre esteve presente.
Aos meus amigos, pelos empurrões e cobranças.
Ao meu orientador, Mauro Marcelo Mattos, por ter acreditado na conclusão deste
trabalho.
Ao meu amigo Marco Caramori pela consultoria e auxílio em diversos imprevistos.
À amiga Sara Schmitt pelo auxílio nos testes do aplicativo.
Não há nada que seja maior evidência de
insanidade do que fazer a mesma coisa dia
após dia e esperar resultados diferentes.
Albert Einstein
RESUMO
Este trabalho apresenta a especificação e a implementação de uma máquina virtual
denominada Mattos Virtual Machine (MVM) para o sistema operacional Android para o
auxílio ao ensino de sistemas operacionais. São apresentadas as funções do aplicativo e as
instruções que são suportadas pela máquina. O aplicativo foi desenvolvido em Java com
suporte ao banco de dados Sqlite para armazenamento dos códigos desenvolvidos.
Palavras-chave: Ferramenta de ensino. Máquina hipotética. Android.
ABSTRACT
This paper presents the specification and implementation of a virtual machine called Mattos
Virtual Machine (MVM) for the Android operating system to aid teaching of operating
systems. There are presented the application functions and instructions that are supported by
the machine. The application was developed in Java with support for SQLite database for
storage of codes developed.
Key-words: Teaching tool. Virtual machine. Android.
LISTA DE ILUSTRAÇÕES
Figura 1 – Diagrama de funcionamento do Android. ............................................................... 14
Figura 2 - Classificação das tecnologias de virtualização. ....................................................... 18
Figura 3 – arquitetura geral da Mattos Virtual Machine .......................................................... 19
Figura 4 – Arquitetura do MVM .............................................................................................. 20
Figura 5 – Estrutura da MVM expressa em linguagem Java. ................................................... 21
Quadro 1 – Lista de comandos suportados pela máquina ........................................................ 21
Figura 6 – Simulador SOsim versão 1.2. .................................................................................. 25
Figura 7 – Tela inicial do HIPO ............................................................................................... 26
Figura 8 – Interface VXt cliente Java com registradores e log de instrução. ........................... 27
Figura 9 - Funcionamento do sistema ...................................................................................... 28
Figura 10 - Interface BrasilOS para simulação de escalonamento de processos..................... 29
Figura 11 - Resultado da simulação de escalonamento de processos....................................... 30
Figura 12 – Janela que simula o funcionamento do escalonamento circular com prioridade. . 31
Figura 13 – Exemplo de interface do SISO .............................................................................. 32
Figura 14 – Detalhamento do fluxo operacional do IO Simulator.. ......................................... 33
Figura 15 – Integração entre processador e sistema de entrada/saída ...................................... 34
Figura 16 – Tela principal do simulador de entrada e saída ..................................................... 35
Figura 17 – Protótipo do simulador .......................................................................................... 36
Figura 18 – Diagrama de classes .............................................................................................. 38
Quadro 2 – Controle das opções ............................................................................................... 39
Quadro 3 – Parte do código de execução do programa ............................................................ 40
Quadro 4 – Criação do banco de dados .................................................................................... 41
Figura 19 – Regiões da interface da MVM .............................................................................. 43
Figura 20 – Tela de criação do novo projeto ............................................................................ 43
Figura 21 – Tela de localização dos projetos já existentes ....................................................... 44
Figura 22 – Mensagem de erro durante a verificação .............................................................. 44
Figura 23 – Ciclo de busca, decodificação e execução ............................................................ 46
Figura 24 – Atribuição de valor imediato ................................................................................. 46
Figura 25 – Resultado das instruções da figura 24 ................................................................... 47
Figura 26 – Desvio incondicional imediato.............................................................................. 47
Figura 27 – Resultado das instruções da figura 26 ................................................................... 48
Figura 28 – Operação de pilha.................................................................................................. 48
Figura 29 – Resultado da execução do programa da figura 28. ............................................... 49
Figura 30 – Endereçamento por base e deslocamento .............................................................. 49
Figura 31 – Correção do exemplo de endereçamento por base e deslocamento ...................... 50
Figura 32 – Device driver ......................................................................................................... 51
Figura 33 – Resultado da execução do programa da figura 32 ................................................ 51
Quadro 5 – Código fonte de uma aplicação de chamada de interrupções por software ........... 52
Figura 34 – Percentual de aparelhos e suas determinadas versões do Android ....................... 54
LISTA DE SIGLAS
ABI - Application Binary Interface
API - Application Programming Interface
APK - Android Package File
BCC – Curso de Ciência da Computação – Bacharelado
CPU - Central Processing Unit
DSC – Departamento de Sistemas e Computação
DVM - Dalvik Virtual Machine
EDGE - Enhanced Data Rates for GSM Evolution
FCFS - First Come, First Served
GB - Giga Byte
GHZ - Giga Hertz
GSM - Global System for Mobile Communications
IDE - Integrated Development Environment
ISA - Instruction Set Architecture
MMU - Memory Management Unit
RAM - Random Access Memory
ROM - Read Only Memory
SBC – Sociedade Brasileira de Computação
USB - Universal Serial Bus
XMPP - eXtensible Messaging and Presence Protocol
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 13
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 13
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 14
2.1 SISTEMA OPERACIONAL ANDROID ......................................................................... 14
2.2 MÁQUINAS VIRTUAIS .................................................................................................. 16
2.3 A MVM ............................................................................................................................. 19
2.4 TRABALHOS CORRELATOS ........................................................................................ 24
2.4.1 SOSIM ............................................................................................................................ 24
2.4.2 HIPO – O computador hipotético ................................................................................... 25
2.4.3 VXT ................................................................................................................................ 26
2.4.4 BrasilOS: ......................................................................................................................... 29
2.4.5 EPSOSIM ........................................................................................................................ 30
2.4.6 SISO – SIMULADOR DE SISTEMA OPERACIONAL............................................... 32
2.4.7 IO Simulator .................................................................................................................... 33
2.4.8 SOIS – Sistema Operacional Integrado Simulado .......................................................... 34
2.4.9 VM Simulator ................................................................................................................. 35
3 DESENVOLVIMENTO .................................................................................................... 37
3.1 REQUISITOS PRINCIPAIS DO APLICATIVO ............................................................. 37
3.2 DIAGRAMA DE CLASSES............................................................................................. 38
3.3 IMPLEMENTAÇÃO ........................................................................................................ 41
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 41
3.3.2 Operacionalidade da implementação .............................................................................. 42
3.3.3 Casos de testes ................................................................................................................ 45
3.4 RESULTADO E DISCUSSÃO......................................................................................... 52
4 CONCLUSÕES .................................................................................................................. 55
4.1 EXTENSÕES .................................................................................................................... 55
12
1 INTRODUÇÃO
Conforme Gagné, Brigss e Wagner (1992 apud CASAS, 1999), instrução, no contexto
da escola, é um processo oferecido por instrutores humanos e envolve o professor e o
aprendiz. Os méritos da instrução proporcionada por professores humanos são os aspectos
dinâmicos e interativos do ensino.
Segundo Fagundes (1998) apud Veiga (2001), aprender por projetos é uma forma
inovadora de romper com as tradições educacionais, dando um formato mais ágil e
participativo ao trabalho de professores e educadores. Trata-se mais do que uma estratégia
fundamental de aprendizagem, sendo um modo de ver o ser humano construir, aprendendo
pela experimentação ativa do mundo. Ao elaborar seus projetos, o professor conduzirá seus
alunos a um conjunto de interrogações, quer sobre si mesmo ou sobre o mundo à sua volta,
levando o aluno a interagir com o desconhecido ou com novas situações, buscando soluções
para os problemas.
Conforme Maziero (2002), “uma das principais características da disciplina de sistemas
operacionais é a relativa dificuldade em definir um sequenciamento didático claro entre seus
diferentes tópicos”.
Mattos (2012) vem utilizando conceitos de máquinas virtuais já há algum tempo em
suas aulas de sistemas operacionais (Mattos et al., 2004). Recentemente ele adotou uma
estratégia diferente: conduzir os acadêmicos ao longo de um semestre no processo de
concepção de uma máquina virtual hipotética (denominada Mattos Virtual Machine ou MVM)
sobre a qual são desenvolvidos os conceitos básicos da disciplina a partir de uma visão
bottom-up. Ao término da atividade a MVM é promovida a: My Virtual Machine permitindo
ao acadêmico apropriar-se do fato de que o mesmo foi capaz de construir a sua própria versão
a partir da especificação original da MVM.
Na perspectiva de ampliar as possibilidades de interesse dos alunos (já que as
atividades de laboratório são desenvolvidas para desktops) e considerando a enorme
expansão1 do mercado de dispositivos móveis considerou-se como uma oportunidade de
pesquisa explorar a possibilidade de disponibilizar a MVM como infraestrutura para o
desenvolvimento dos conceitos de sistemas operacionais nesta plataforma.
1
Segundo a Anatel (2009, p. 73), o Brasil fechou o ano de 2009 com 173,9 milhões de telefones celulares em
operação, o que representa um crescimento de 15,47% em relação a dezembro de 2008, quando existiam no País
150,6 milhões de telefones móveis em funcionamento.
13
1.1 OBJETIVOS DO TRABALHO
Este trabalho tem como objetivo desenvolver uma aplicação para o sistema operacional
Android que simule uma máquina virtual hipotética destinada a atividades de ensino de
conceitos básicos de sistemas operacionais.
Os objetivos específicos podem ser detalhados da seguinte maneira:
a) migrar a estrutura da MVM desktop para a plataforma Android;
b) validar a aplicação através de estudos de casos.
1.2 ESTRUTURA DO TRABALHO
O trabalho está organizado em quatro capítulos: introdução, fundamentação teórica,
desenvolvimento e conclusão. O capítulo 2 apresenta os aspectos teóricos estudados para o
desenvolvimento do trabalho. São relatados temas como linguagens de descrição e consulta
para web semântica e processamento de linguagem natural. Também são relacionados alguns
trabalhos correlatos. No capítulo 3 é abordado o desenvolvimento, detalhando os requisitos, a
especificação e a implementação, além dos resultados e discussões. Por fim, no capítulo 4 são
apresentadas as conclusões, bem como sugestões para possíveis extensões.
14
2 FUNDAMENTAÇÃO TEÓRICA
A primeira seção apresenta os conceitos básicos sobre o sistema operacional Android.
A segunda seção apresenta conceitos de máquina virtuais, a terceira seção introduz a estrutura
da MVM e finalmente são apresentados trabalhos correlatos.
2.1 SISTEMA OPERACIONAL ANDROID
O Android é um sistema operacional livre que roda sobre núcleo Linux desenvolvido
por uma pequena empresa chamada Android Inc., criada em 2003 e situada em Palo Alto,
Califórnia, USA (AQUINO, 2007). Em 2005 a Google adquiriu os direitos da empresa e
iniciou o desenvolvimento do sistema operacional para o uso em celulares e demais
dispositivos móveis.
A Figura 1 mostra a estrutura do sistema Android.
Fonte: Aquino (2007, p. 5).
Figura 1 – Diagrama de funcionamento do Android
A arquitetura do sistema operacional Android, segundo Aquino (2007, p. 5) é formada
por camadas onde os níveis mais baixos são expostos para os níveis mais altos através de
interfaces.
A primeira camada é o núcleo do sistema (kernel) que funciona como uma camada de
15
abstração entre o hardware e o restante de softwares da plataforma. Utilizando Linux 2.6.27
ela é responsável pelo gerenciamento de memória, processos, threads, pilha de protocolos de
rede, módulo de segurança e vários módulos do núcleo de infraestrutura.
A segunda camada contém um conjunto de bibliotecas C/C++ usada por vários
componentes do sistema e a Dalvik Virtual Machine (DVM). A DVM foi escrita de forma que
um dispositivo possa executar múltiplas máquinas virtuais concorrentemente de maneira
eficiente. Ela usa o kernel do Linux para prover a funcionalidade de múltiplas threads e
gerenciamento de memória de baixo nível. Cada aplicação do Android roda em um processo
separado, com sua própria máquina virtual, número do processo e dono do processo, isso
garante que caso a aplicação apresente erros, ela possa ser isolada e removida da memória
sem comprometer o resto do sistema. Ao desenvolver as aplicações em Java, a DVM compila
o bytecode (.class) e converte para o formato Dalvik Executable (.dex), que representa a
aplicação do Android compilada. Depois disso, os arquivos .dex e outros recursos do projeto
são compactados em um único arquivo com a extensão Android Package File (.apk), que
representa a aplicação final.
A terceira camada é composta por frameworks de aplicações. Os desenvolvedores têm
acesso completo à mesma interface de programação de aplicativos que é usada pelas
aplicações essenciais da plataforma. Esta camada fornece um conjunto de serviço tais como
Activity Manager, que gerencia o ciclo de vida das aplicações; Package Manager, que
mantêm quais aplicações estão instaladas no dispositivo; Window Manager, que gerencia as
janelas das aplicações; Telephony Manager, que são os componentes para acesso aos recursos
de telefonia; Content Providers, que permitem que as aplicações acessem dados de outras
aplicações ou compartilhem os seus próprios dados; Resource Manager, que fornece acesso
aos recursos gráficos e arquivos de layout; View System, que é um conjunto rico e extensível
de componentes de interface do usuário; Location Manager, que gerência a localização do
dispositivo; Notification Manager, que permite que todas as aplicações exibam alertas na
barra de status e XMPP Service que é o suporte para o uso do protocolo eXtensible Messaging
and Presence Protocol (XMPP).
A quarta camada é composta pelas aplicações propriamente ditas.
A plataforma Android oferece suporte a diversas tecnologias de conectividade tais
como Bluetooth, enhanced data rates for “global system for mobile communications” (GSM)
16
evolution (EDGE), 3G e Wi-Fi2. Este suporte disponibiliza a comunicação com a internet,
podendo ser usado o conceito sockets, através da linguagem Java que é compilada e executada
na DVM para realizar esta conexão com a rede mundial de computadores.
2.2 MÁQUINAS VIRTUAIS
O termo máquina virtual foi descrito na década de 1960 como uma abstração de
software para um sistema físico. A virtualização é obtida inserindo-se uma camada
intermediária entre o hardware e o sistema operacional. Segundo Morimoto (2010), o sistema
principal passa a ser um hospedeiro da máquina virtual, podendo acessar os recursos do
sistema através de instruções lógicas definidas pela máquina virtual.
Conforme Santos et al. (2006, p. 342), virtualização é o modo de apresentação ou
agrupamento de um subconjunto lógico de recursos computacionais de modo que possam ser
alcançados resultados e benefícios como se o sistema estivesse executando sobre a
configuração nativa. Outro tipo popular de virtualização e atualmente muito utilizado é a
virtualização de hardware para rodar mais de um sistema operacional ao mesmo tempo,
através de microkernels ou de camadas de abstração de hardware, como por exemplo o XEN.
A virtualização nativa, também conhecida como virtualização acelerada ou híbrida, é
uma combinação de virtualização nativa e virtualização de I/O (entrada e saída). Tipicamente,
este método é iniciado com um Virtual Machine Monitor (VMM) com suporte a virtualização
completa, como o XEN (SANTOS et al., 2006, p. 342), por exemplo, e então, baseando-se na
análise de desempenho, emprega as técnicas de aceleração. O uso do processador e também
dos drivers de rede são os recursos mais comuns, onde é empregada a virtualização nativa
(SANTOS et al, 2006, p. 344).
Ainda conforme Santos et al. (2006, p. 342), há diversas formas de virtualização:
a) emulação: a máquina virtual simula todo o hardware, permitindo que um sistema
operacional sem modificações rode em um processador central completamente
diferente do hardware nativo. Existem softwares desenvolvidos para emular a
arquitetura X86, onde se simula simultaneamente mais de um sistema operacional.
2
Segundo Landim (2012) é uma marca registrada pela empresa Wi-Fi Alliance que permite a conexão entre
diversos
dispositivos
sem
fio.
17
O Bochs e PearPC são dois emuladores bastante conhecidos;
b) virtualização nativa ou “virtualização cheia": a máquina virtual somente simula
parcialmente o hardware para permitir que um Sistema Operacional sem
modificações funcione isoladamente no hardware, mas o Sistema Operacional
convidado deve ser projetado para o tipo de processador central. VMware, Parallels
Desktop, Adeos, Mac-on-Linux são plataformas que constituem a virtualização
nativa;
c) paravirtualização: a máquina virtual não simula o hardware mas oferece
preferencialmente uma Application Program Interface (API) especial que requer
modificações no kernel do sistema operacional hóspede. O XEN é um exemplo de
plataforma de virtualização, onde é permitida a execução de vários sistemas
operacionais em um mesmo hardware ao mesmo tempo;
d) virtualização no nível do sistema operacional: virtualiza-se um servidor no nível do
sistema operacional, permitindo-se múltiplos isolamentos de modo seguro aos
servidores virtualizados, em um único servidor físico. Os ambientes dos sistemas
operacionais hóspedes são os mesmos que o do sistema hospedeiro, já que o
mesmo kernel do hardware é usado para executar os ambientes no hospedeiro.
(Linux-VServer, Virtuozzo e OpenVZ, Solaris Containers, User Mode Linux e
FreeBSD Jails).
Existem três características principais para que um software seja considerado um
monitor de máquina virtual, quais sejam (ADAM e AGESEN; 2006):
a) fidelidade: o software no monitor de máquina virtual executa identicamente a sua
execução no hardware exceto pelas barreiras de tempo impostas pela virtualização;
b) performance: a grande maioria das instruções do hardware virtual são executadas
pelo hardware real sem a intervenção do monitor de máquina virtual;
c) segurança: o monitor de máquina virtual gerencia todos os recursos do hardware
virtual.
A Figura 2 apresenta uma classificação das tecnologias de virtualização (SCOPE;
2008, p. 10). Esta classificação é baseada em software que fornece um Instruction Set
Architecture (ISA) ou um Application Binary Interface (ABI). O lado esquerdo da figura
caracteriza tecnologias que suportam máquinas virtuais e o lado direito caracteriza tecnologias
que suportam processos que implementam máquinas virtuais. A principal diferença é que uma
máquina virtual é auto contida, ou seja, necessita de todo o software necessário (sistema
operacional) para executar uma aplicação enquanto um processo de máquina virtual suporta
18
somente aplicações. (ADAM e AGESEN; 2006)
Fonte: Adams e Agesen (2006).
Figura 2 - Classificação das tecnologias de virtualização
A CPU3 de uma máquina virtual genérica tem como objetivo o processamento de
instruções conforme uma máquina real. Ela simula os registradores e demais operações de
uma máquina real mimetizando seus estados de memória e processamento. Em outras
palavras, uma máquina virtual atua como uma camada, permitindo o tratamento e alterações
de estados da máquina sem afetar diretamente a máquina real. Dentre as vantagens de uma
máquina virtual, tem-se a mobilidade de código, uma vez que um programa não se torna
dependente de um sistema operacional e sim de uma máquina virtual pré-programada, como é
o caso do Java.
3
Central Processing Unit (CPU).
19
2.3 A MVM
A Mattos Virtual Machine (MVM) é um exemplo acadêmico utilizado para propósitos
educacionais que possibilita a implementação de um pequeno sistema operacional embarcado.
Ao contrário do que é comumente utilizado (ver seção de trabalhos correlatos), em geral as
propostas didáticas partem de um modelo concebido e permitem que o aluno exercite dentro
de parâmetros pré-concebidos.
Conforme Mattos (2012), em 2004 esta prática foi adotada em pelo menos dois
projetos: Moritz (2004) e em Mattos et al (2004).
A perspectiva acadêmica no projeto MVM é permitir que o aluno construa a sua
própria máquina (daí a denominação “My Virtual Machine”) e, a partir desta construção possa
acompanhar todo o processo de desenvolvimento dos conceitos de sistemas operacionais e a
sua vinculação ao hardware. (MATTOS;2012).
Um modelo hipotético de hardware é utilizado para permitir que o desenvolvimento do
hardware e dos conceitos associados possam acontecer dentro de um semestre letivo.Em
função disto, o modelo de arquitetura utilizado é apresentado na figura 3.
Fonte: Mattos (2012).
Figura 3 – arquitetura geral da Mattos Virtual Machine
Conforme apresentado em aula (figura 4), computador é composto por:
a) um array de memória (array de bytes);
20
b) um processador (CPU) composto por conjunto de registradores e a Unidade Lógica
e Aritmética (ULA) que implementa as funcionalidades do mesmo;
c) um barramento que conecta a memória ao processador (system bus);
d) um processador de interrupções programável que conecta os periféricos a CPU.
Fonte: Mattos (2012).
Figura 4 – Arquitetura do MVM
Um processador, depois de ligado, repete infinitamente o ciclo de:
a) busca uma instrução na memória;
b) decodifica a instrução,
c) executa a operação correspondente e volta ao passo a.
O processador repete este loop até que a instrução HALT tenha sido encontrada ou um
erro de decodificação tenha ocorrido4. A figura 5 apresenta a arquitetura da MVM e expressa
em termos de um programa Java.
4
Um exemplo de erro de decodificação é perceptível em programas para a plataforma Windows quando o
sistema operacional apresenta a mensagem: “Este programa executou uma instrução ilegal e será fechado”.
21
Fonte: Mattos (2012).
Figura 5 – Estrutura da MVM expressa em linguagem Java
A CPU possui um registrador de propósitos gerais (AX), dois registradores auxiliares
(BX e CX), um registrador de topo da pilha (SP), um registrador de stack frame (BP), um
registrador apontador de instruções (IP) e um registrador de decodificação (RI).
A CPU possui quatro tipos de desvio:
a) incondicional: ex. JMP 50;
b) condicional: ex. TESTAX0,50;
c) baseado em pilha: ex. CALL 50;
d) baseado em interrupções por software e por hardware: ex. INT 30.
Com estes recursos é possível implementar programas que utilizem laços de repetição,
sub-rotinas e device drivers baseados em tabela de vetores de interrupção.
A memória da MVM é concebida originalmente com 256 bytes, mas para comportar o
núcleo de sistema operacional é alterada na metade do semestre para 1024 bytes conduzindo
os acadêmicos a refletir a respeito do tamanho do barramento e suas consequências em termos
de implementação.
No quadro 1 apresenta-se o conjunto de instruções da máquina. Para cada instrução
especifica-se o código, o mnemônico, o tamanho em bytes e o comportamento da mesma.
Quadro 1 – Lista de comandos suportados pela máquina
Instrução Mnemônico
Tamanho Descrição da Operação
0 init ax
1 incrementa o valor de AX.
1 move ax,bx
1 move o valor de AX para BX.
22
2
3
4
5
move ax,cx
move bx,ax
move cx,ax
move ax,[
6 move ax,[bx+
7 move ax,[bp8 move ax,[bp+
9 move [
1
1
1
2
move o valor de AX para CX.
move o valor de BX pra AX.
move o valor de CX para AX.
move conteúdo da posição X da memória p/ax.
Ex: move ax,[50] significa: move conteúdo da posição
50 para AX.
2 move o conteúdo da posição [bx+X] da memória p/ax.
Ex: move ax,[bx+2].
2 move conteúdo da posição [bp-X] para AX.
Ex: move ax,[bp-2].
2 move conteúdo da posição [bp+X] para AX.
Ex: move ax,[bp+2].
2 move o valor de AX para a posição X de memória.
Ex: move [30],ax -> significa move o valor de AX
para a posição 30 da memória.
10 move [bx+
2 move valor de ax para a posição de memória
indexada por [bx+valor].
Ex: move [bx+3],ax -> significa move o valor de
AX para a posição [bx+3];
se bx=50, o resultado é: move [53],ax.
11 move bp,sp
12 move sp,bp
13 add ax,bx
1 move o valor de BP para SP.
1 move o valor de SP para BP.
1 incrementa o valor de AX com o valor de BX (AX = AX +
BX).
1 incrementa o valor de AX com o valor de BX (AX = AX +
CX).
1 incrementa o valor de BX com o valor de BX (BX = BX +
CX).
1 decrementa o valor de AX com BX (AX = AX - BX).
1 decrementa o valor de AX com CX (AX = AX - CX).
1 decrementa o valor de BX com CX (BX = BX - CX).
1 incrementa o valor de AX em 1.
1 incrementa o valor de BX em 1.
1 incrementa o valor de CX em 1.
1 decrementa o valor de AX em 1.
1 decrementa o valor de BX em 1.
1 decrementa o valor de CX em 1.
2 se o valor de ax é igual a 0, move o ponteiro IP
para a posição definida.
2 move para a posição de memória definida.
Ex: jmp 150.
2 faz uma chamada de sub-rotina. Empilha o valor
do registrador IP e move para o
novo ponteiro de memória definido. Ex: call 150.
14 add ax,cx
15 add bx,cx
16
17
18
19
20
21
22
23
24
25
sub ax,bx
sub ax,cx
sub bx,cx
inc ax
inc bx
inc cx
dec ax
dec bx
dec cx
test ax0,
26 jmp
27 call
28 ret
29 in ax
30 out ax
1 efetua o retorno de uma sub-rotina.
1 solicita uma tecla do teclado para inserir o valor no
registrador AX.
1 imprime na console o valor do registrador AX.
23
31
32
33
34
35
36
37
38
39
40
41
42
push ax
push bx
push cx
push bp
pop bp
pop cx
pop bx
pop ax
nop
halt
dec sp
move [bp-
43 move [bp+
44 move ax,{
45 test axEqbx
46
47
48
49
50
51
inc sp
move ax,sp
move sp,ax
move ax,bp
move bp,ax
iret
52 int
1
1
1
1
1
1
1
1
1
1
1
2
empilha o valor de AX.
empilha o valor de BX.
empilha o valor de CX.
empilha o valor de BP.
empilha o valor de BP.
empilha o valor de CX.
empilha o valor de BX.
empilha o valor de AX.
comando que não realiza nenhuma operação.
finaliza a execução do programa.
decrementa o valor de SP.
move o conteúdo de AX para a posição [bp-X].
Ex: move [bp-2], ax.
2 move o conteúdo de AX para a posição [bp+X].
Ex: move [bp+2], ax.
2 move o valor imediato entre chaves para o registrador AX.
Ex: move ax,{50} -> move para AX o valor 50.
2 move para a instrução X se o valor de AX for igual à BX.
Ex: test AXEqBX, 150 -> se o valor de AX for igual à BX,
move para a posição 150.
1
1
1
1
1
1
incrementa o valor de sp em 1.
move para AX o valor de SP.
move para SP o valor de AX.
move para AX o valor de BP.
move para BP o valor de AX
efetua o retorno de uma interrupção, é equivalente a
pop cx, pop bx, pop ax, pop bp, ret.
2 gera uma interrupção, é equivalente a
push ip, push bp, push ax, push bx, push cx.
Fonte: Mattos (2012).
A MVM possui os seguintes modos de endereçamento:
a) imediato: ex. move AX,{30}
a) direto: ex. move [30],AX
b) indireto baseado em registradores: ex. move [BX+3],AX
c) baseado em stack frame: ex. move [BP+2],AX
A MVM possui duas instruções específicas para acesso ao hardware:
a) IN AX: recebe um caractere do teclado;
b) OUT AX: envia um caractere para a tela virtual.
A MVM não implementa registrador de flags nem o tratamento de underflow,
overflow e “vai um” nas operações aritméticas.
24
2.4 TRABALHOS CORRELATOS
Nesta seção são apresentados os trabalhos de Machado e Maia (2004) seguido do
trabalho Schouery (2007). Por sequência serão abordados alguns trabalhos voltados
especificamente ao desenvolvimento de ferramentas para o ensino de sistemas operacionais.
Os trabalhos apresentados são:
a) SOSIM;
b) HIPO – O computador hipotético;
c) VXT (MATTOS et al., 2004);
d) BrasilOS (SILVA et al. 2011);
e) EPSOSIM (CARVALHO, 2011, p. 55);
f) SISO (CARVALHO, 2011);
g) IO Simulator (MEDEIROS et al., 2011);
h) SOIS - Sistema Operacional Integrado Simulado (Cruz; Silva; Gonçalves, 2007);
i) VM Simulator (SOUZA; SOUZA, 2011, p. 550).
2.4.1 SOSIM
Conforme Machado e Maia (2004), o SOsim é um simulador com recursos visuais que
tem como principal objetivo apresentar os conceitos e técnicas encontradas nos Sistemas
Operacionais multiprogramáveis modernos. Alguns dos algoritmos implementados podem ser
encontrados em sistemas operacionais comerciais, como no HP OpenVMS e Microsoft
Windows NT/2000/XP.
O simulador emula os principais subsistemas de um sistema operacional
multiprogramável, como gerência de processos, escalonamento e memória virtual por
paginação e foi concebido com o propósito de ser uma ferramenta de apoio ao ensino de
Sistemas Operacionais (MACHADO; MAIA; 2004).
25
O software foi concebido para ser executado no sistema Windows da Microsoft,
possuindo uma interface simples e de fácil interação e permitindo ao usuário acompanhar
visualmente os diversos eventos assíncronos que ocorrem em um sistema operacional (figura
6).
Fonte Machado e Maia (2002).
Figura 6 – Simulador SOsim versão 1.2
Conforme relatado por Machado e Maia (2002, p. 10), na experiência realizada, o uso
do simulador SOsim mostrou-se importante no auxílio da construção do saber, pois
possibilitou a maior atenção do aprendiz com o objeto de estudo. Uma grande vantagem
pedagógica em utilizar tal ferramenta é a construção de um ambiente híbrido de ensinoaprendizado, onde aulas expositivas tradicionais e simulações podem ser combinadas.
2.4.2 HIPO – O computador hipotético
O HIPO é um sistema feito em JAVA que permite a simulação de programas escritos
em uma linguagem de máquina simplificada para o auxílio de estudantes sobre o
26
funcionamento de uma máquina real.
Ele possui um número de instruções limitado, definido pela própria máquina.
Conforme Schouery (2007, p. 14), são definidas as instruções suportadas pela máquina e as
funções são:
a) carregar e salvar o conteúdo na memória;
b) efetuar operações aritméticas, como por exemplo, somar, subtrair, etc;
c) leitura de dados de entrada como teclas por exemplo e impressão do conteúdo;
d) instruções comparativas como, por exemplo, igualdade entre valores.
Fonte: Schouery (2012).
Figura 7 – Tela inicial do HIPO
2.4.3 VXT
O Virtual XT (VXT) é um projeto iniciado em 1997 e que simula uma máquina
baseada no processador 8086. Concebido para suportar atividades de sala de aula, foi
desenvolvido através de alguns trabalhos de conclusões de curso e projetos de iniciação
científica (MATTOS et al, 2004).
O VXT possui uma interface gráfica que interage com o usuário com a finalidade de
mostrar passo a passo a execução de um programa em modo de instruções de máquina.
Segundo Mattos et al. (2004), este projeto tem um grande valor didático, por auxiliar no
27
ensino de sistemas operacionais. Além disso, o VXT possui outras características importantes
como:
a) trabalha no conceito de cliente-servidor;
b) tem interface completamente isolada da implementação do processador;
c) permite que sejam executados vários simuladores em paralelo;
d) permite que seja salvo ou carregado o contexto de execução de uma determinada
simulação;
e) permite salvar log de uma simulação, possibilitando assim efetuar uma análise
destas informações.
Fonte: Goedert (2006, p. 75).
Figura 8 – Interface VXt cliente Java com registradores e log de instrução
A ultima versão do sistema permitia que a tela do professor pudesse ser propagada
para todas as máquinas dos alunos através de um middleware escrito em Java. A figura 8
apresenta um exemplo de funcionamento do sistema conforme os rótulos abaixo:
a) cliente Java 1: recebe dados do middleware;
b) cliente Java 2: recebe dados do middleware;
c) cliente Delphi: envia dados para o middleware;
d) janela de log de instruções do cliente Delphi;
e) janela de log de instruções do cliente Java 1;
f) janela de log de instruções do cliente Java 2;
28
g) middleware Java: gerencia clientes, recebe mensagens do cliente Delphi e
transmite para as interfaces Java.
Fonte: Goedert (2006, p. 76).
Figura 9 - Funcionamento do sistema
Conforme Goedert (2006, p.77), a versão implementada permitiu propagar a interface
do VXt para clientes remotos. Com essas novas características implantadas no VXt, ele torna
mais interessante a aprendizagem dos alunos, pois poderão ver na prática o funcionamento de
uma CPU, assimilando melhor os assuntos relacionados a sistemas operacionais. Com relação
a performance da transmissão dos dados, pôde-se constatar que o tempo de atraso desde o
envio até o recebimento pelos clientes das informações, não foi significativo a ponto de
comprometer a aplicação.
Com essa versão foi possível propagar a interface do VXt sem perdas de informações
e num teste realizado com 20 computadores conectados ao middleware, praticamente não
houve tempo de atraso no envio de informações a 500 ms.
Através de testes realizados com o VXt, foi observado que ele também funciona
utilizando como meio de transmissão a internet, sendo teste realizado somente entre 2
computadores. Também foram feitos testes com os clientes sendo executados no sistema
29
operacional Linux e percebeu-se que o VXt propaga sua interface sem nenhum problema
com relação a plataforma (GOEDERT; 2006, p.77).
2.4.4 BrasilOS:
O BrasilOs é um ambiente didático para o auxílio ao ensino e aprendizado de sistemas
operacionais desenvolvida por Marcos Aurélio Medeiros Silva¹, Rogério Guerra Diógenes
Filho¹, Emanuel Feliciano Queiroz¹, Hedwio Carvalho e Silva¹ e Verônica Pimentel de Sousa
O BrasilOS é uma ferramenta de simulação de sistemas operacionais. O sistema faz
uso de recursos gráficos para que a dinâmica de cada algoritmo seja bem visualizada
durante sua simulação. Para tornar o software mais completo, são inseridos pequenos
textos durante a execução do algoritmo, o que possibilita uma formação conceitual
mais abrangente para o efetivo aprendizado (Silva et al., 2011, p. 2).
Implementada em C#, a fase atual contempla o módulo de algoritmos de
escalonamento de processos, com simulação dos algoritmos first come, first served (FCFS),
shortest job first (SJF), alternância circular e prioridade. Além disso contém textos objetivos
para bom embasamento teórico e um guia de utilização da ferramenta tornando possível que
todos os seus recursos sejam bem utilizados (SILVA ET ALL;2011).
A Figura 10 mostra como o usuário pode configurar estas opções. Para isso, é
necessário que as informações de cada processo sejam adicionadas antes de inseri-lo no
escalonador.
Fonte: Silva et al. 2011.
Figura 10 - Interface BrasilOS para simulação de escalonamento de processos
30
Após adicionar os processos necessários para a simulação é possível selecionar o
algoritmo de escalonamento na lista de seleção do lado direito da imagem. A partir daí, o
usuário pode executar a simulação e comparar os resultados (figura 11).
Fonte: Silva et al. 2011.
Figura 11 - Resultado da simulação de escalonamento de processos
A partir dos resultados iniciais, os autores planejam a ampliação do escopo da
ferramenta para contemplar outros algoritmos de escalonamento de processos, além do
gerenciamento de memória (SILVA et al., 2011).
2.4.5 EPSOSIM
Conforme Carvalho (2011), o EPSOSIM é um simulador de escalonamento de
processos em sistemas operacionais e busca, de forma simples, pratica e detalhada, simular os
algoritmos de escalonamento de processos.
31
Fonte: Carvalho (2011, p. 55)
Figura 12 – Janela que simula o funcionamento do escalonamento circular com prioridade
O Simulador permite a visualização gráfica do funcionamento de 8 algoritmos de
escalonamento ( Carvalho (2011, p. 58):
a) FIFO;
b) SJF;
c) SRT;
d) Circular;
e) Circular com prioridade;
f) Por prioridade preemptiva;
g) Por prioridade não-preemptivo;
h) Múltiplas filas.
Além disso, o simulador permite a visualização do diagrama de Gantt, onde é possível
visualizar o comportamento dos processos desde o início até o final. Com este instrumento, os
alunos tem mais facilidade em aprender sobre o funcionamento dos mecanismos de
escalonamento estudados (Carvalho, 2011, p.58).
32
2.4.6 SISO – SIMULADOR DE SISTEMA OPERACIONAL
Conforme Carvalho (2011), o SISO é um applet java desenvolvido com o intuito de
auxiliar no processo de ensino-aprendizagem da disciplina de sistemas operacionais. O SISO
é um simulador muito prático e seu funcionamento não exige instalação.
Conforme Paulo (2011), o objetivo do SISO é:
a) auxiliar no ensino/aprendizagem da disciplina de sistemas operacionais, facilitando
o entendimento prático do algoritmo de detecção de deadlock;
b) permitir a visualização da montagem das matrizes do algoritmo;
c) permitir que o aluno antecipasse os resultados da detecção, antes de serem
exibidos.
Fonte: Carvalho (2011).
Figura 13 – Exemplo de interface do SISO
33
2.4.7 IO Simulator
Medeiros et al. (2011) descrevem um ambiente de simulação denominado IO
Simulator, destinado a demonstrar na prática os conceitos teóricos relativos as peculiaridades
do comportamento de mecanismos de gerenciamento de dispositivos de entrada e saída. A
interatividade da ferramenta fornece aos alunos um ambiente agradável de aprendizado,
detalhando o fluxo operacional deste módulo do sistema operacional por meio de animações
dinâmicas (MEDEIROS et al.;2011).
Fonte: Medeiros et al. (2011).
Figura 14 – Detalhamento do fluxo operacional do IO Simulator
Por meio do IO Simulator é possível interagir com qualquer componente persente na
animação, permitindo consultar seu conceito ou entender a sua função dentro do fluxo de
entrada e saída.
34
2.4.8 SOIS – Sistema Operacional Integrado Simulado
Conforme Cruz, Silva e Gonçalves (2007), a ferramenta Sistema Operacional
Integrado Simulado (SOIS) visa a criação de um ambiente completo de simulação
computacional, integrando compilador, sistema operacional, sistema de entrada e saída e
interface de visualização.
Devido a sua complexidade, em 2007 estava implementado o núcleo básico do
processador envolvendo a unidade de decodificação de instruções IA-32 e o módulo de
simulação de entrada e saída embora operando sobre um conjunto de instruções simplificado.
A Figura 15 apresenta a arquitetura do sistema.
Fonte: Cruz, Silva e Gonçalves (2007).
Figura 15 – Integração entre processador e sistema de entrada/saída
A figura 16 apresenta um snapshot da execução de um programa pelo simulador
(CRUZ; SILVA; GONCALVES; 2007).
35
Fonte : Cruz, Silva e Gonçalves (2007).
Figura 16 – Tela principal do simulador de entrada e saída
2.4.9 VM Simulator
Conforme Sousa e Souza (2011, p.550), o VM Simulator, é um simulador para apoiar
o ensino e a aprendizagem de gerência de memória virtual. A importância do trabalho se deve
ao fato desse conteúdo ser geralmente lecionado de forma excessivamente teórica em salas de
aula e da falta de simuladores educacionais relacionados que abordem esse conteúdo de forma
completa e satisfatória. Com o VM Simulator, pretende-se mostrar o funcionamento dos
principais componentes desse tipo de gerência de forma visual e dinâmica.
Através do simulador, o usuário poderá criar uma simulação escolhendo os tamanhos
das páginas virtuais e dos frames, do espaço de endereçamento virtual, da memória principal e
o algoritmo de substituição de páginas. Após a configuração desses parâmetros, o
aluno/professor visualiza uma tela similar à apresentada na figura 17.
36
Fonte: Sousa e Souza (2011, p. 552).
Figura 17 – Protótipo do simulador
O usuário poderá incluir processos que serão mostrados na seção da área 4 (quatro) e
cada espaço de memória ocupado por esse processo será mostrado na seção da área 6 (seis) e
identificado pelo número do seu endereço, pelo número do processo que o contém e pela
mesma cor atribuída ao processo. Com base no seu tamanho e nas configurações de tamanho
de memória informadas anteriormente, a ferramenta criará um espaço de endereçamento
virtual para ele, com as páginas alocadas sendo mostradas na seção da área 2 (dois). Dessa
forma, uma página virtual poderá ser buscada a partir do seu número e a ferramenta mostrará
na seção da área 5 (cinco) como essa requisição chega à memória a partir da CPU e da MMU.
Os dados das páginas de um processo estarão mapeados e mostrados na seção das áreas 1
(um) e 3 (dois) ,onde será mostrado qual página foi escolhida e que endereço de memória real
essa página tem. Se for necessária uma substituição de páginas, a ferramenta mostrará como
isso irá ocorrer de acordo com o algoritmo de substituição de páginas escolhido em uma
animação na seção da área 2 (dois) (Sousa; Souza, 2011, p. 553).
37
3 DESENVOLVIMENTO
Neste tópico serão abordados os requisitos principais do aplicativo, seguido do
diagrama de classes da aplicação, dos dados da implementação como as técnicas utilizadas, a
memória disponível, comandos suportados e operacionalidade da ferramenta, finalizando com
a descrição dos resultados obtidos e situações encontradas durante o desenvolvimento.
3.1 REQUISITOS PRINCIPAIS DO APLICATIVO
Os requisitos funcionais e não funcionais do sistema são:
a) o sistema deve permitir que o aluno desenvolva programas para a MVM no
dispositivo móvel (Requisito Funcional - RF);
b) o aplicativo deve permitir que sejam carregados os projetos já salvos no
dispositivo móvel (RF);
c) permitir a edição dos valores da memória da máquina (RF);
d) permitir que o código fonte do projeto escrito possa ser salvo e carregado
novamente (RF);
e) permitir a exclusão do projeto (RF);
f) permitir que a execução do programa possa ser interrompida (RF);
g) o sistema deve oferecer uma interface amigável ao usuário (Requisito Não
Funcional RNF);
h) o sistema deve ser implementados na linguagem Java (RNF);
i) o sistema deve ser implementado usando o ambiente de desenvolvimento Eclipse
(RNF);
j) o sistema operacional no qual o software está instalado deve rodar no sistema
operacional Android (RNF).
38
3.2 DIAGRAMA DE CLASSES
O diagrama de classes (figura 18) apresenta as classes do aplicativo e suas ligações
com as classes responsáveis pelo controle da máquina virtual.
class Getting Started
EA 9.3 Unregistered
Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
DataHelper
-
Opcao
context :Context
db :SQLiteDatabase
i d :i nt
EA
9.3 Unregistered
Trial Version
EA 9.3 Unregistered Trial Version EA 9.3 Unregi
INSERT
:Stri ng = "i nsert into " ... {readOnly}
i mage :i nt
-
i nsertStmt :SQLiteStatement
T ABLE_NAME :Stri ng = "PROJET O"
-
nome :Stri ng
+ getId() :i nt EA 9.3 Unregistered Trial Version
EA
9.3
Unregistered
EA 9.3 Unregi
+ atual
izarProjeto(Stri
ng, Stri ng) :voi d Trial Version
+ getImage() :i nt
+
+
+
+
DataHelper(Context)
excl ui rProj eto(Stri ng) :long
i nsert(Stri ng, String) :l ong
sel ecionarT odosProjetos() :ArrayLi st<Proj eto>
+
+
getNome() :Stri ng
Opcao(int, String, i nt)
BaseAdapter
MsgGenericAdapter
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered
Trial Version EA 9.3 Unregi
-dataHel per
Acti vity
OnItemCl ickLi stener
-
context :Context
corFundo :int
li stMsg :Li st<Stri ng> = new ArrayLi st<S...
+
+
getCount() :i nt
getItem(i nt) :Obj ect
EA 9.3 Unregistered
Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
MainActiv ity
-
codi go_fonte_edittext :EditT ext
+ console :Li stVi ew
getItemId(i nt) :l ong
EA
9.3 Unregistered
Trial Version EA 9.3++ Unregistered
Trial Version EA 9.3 Unregi
dataHelper
:DataHelper
getView(i nt, View, ViewGroup) :Vi ew
-
funcaoPrograma :Li nearLayout
isAlter :boolean = false
li stMemori a :Li stView
li stMenu :Li stVi ew
lv :PosicaoMemoria
menu :OpcoesMenu
msgConsol e :MsgGeneri cAdapter
msgRegistradores :MsgGeneri cAdapter
mvm :Maqui naVi rtual = new Maqui naVi rtual()
proj etoAtual :Proj eto
regi stradores :Li stView
stopCPU :boolean = true
tamanho_memori a :i nt = 1024 {readOnl y}
ui Handler :Handler = new UIHandl er()
ui HandlerConsol e :UIHandl erConsole = new UIHandlerCo...
+
+
+
+
-
al ertDi al og(Stri ng) :voi d
atual i zarConsol e(Stri ng) :voi d
atual i zarProj eto(Proj eto) :voi d
atual i zarRegistradores() :voi d
carregarLi staMemori a() :voi d
carregarProjeto() :void
compi larProj eto() :voi d
cpu(boolean) :voi d
excluirProjeto() :void
executar(bool ean) :void
isStopCpu(boolean) :boolean
li mparConsol e() :voi d
li mparRegistradores() :voi d
novoProj eto(Opcao) :voi d
onCreate(Bundle) :voi d
onCreateOptionsMenu(Menu) :bool ean
onItemCli ck(AdapterVi ew<?>, View, int, long) :void
pararExecucao() :void
sal varBancoDados(Stri ng) :void
sal varProj eto() :void
toast(int) :void
toast(String) :void
-msgRegistradores
-msgConsol e +
+
+
insert(Stri ng) :voi d
li mpar() :voi d
MsgGeneri cAdapter(Context, i nt)
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
Proj eto
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered
Trial Version EA 9.3 Unregi
-
codi goFonte :Stri ng
memoria :int ([])
nome :String
+
+
+
+
+
+
+
+
getCodi goFonte() :String
getMemori a() :i nt[]
getNome() :String
Proj eto(Stri ng, String)
setCodi goFonte(Stri ng) :voi d
setMemori a(int, i nt) :void
setNome(Stri ng) :void
toString() :Stri ng
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
-proj etoAtual
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
BaseAdapter
EA 9.3 Unregistered Trial Version -menu
EA 9.3 Unregistered
Trial Version EA 9.3 Unregi
OpcoesMenu
-
context :Context
stateLi st :List<Opcao>
+
+
getItem(i nt) :Obj ect
getItemId(i nt) :l ong
+
+
li mparLi sta() :void
OpcoesMenu(Context, List<Opcao>)
EA 9.3 Unregistered Trial Version EA+ 9.3
Unregistered Trial Version EA 9.3 Unregi
getCount() :int
getView(i
nt, Vi ew, Vi ewGroup) :Vi ew
EA 9.3 Unregistered Trial Version EA++ 9.3
Unregistered
Trial Version EA 9.3 Unregi
inserirBotoes(Opcao) :voi d
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
-lv
BaseAdapter
EA 9.3 Unregistered Trial Version EA 9.3
Unregistered Trial Version EA 9.3 Unregi
PosicaoMemoria
-mai n
-
context :Context
stateList :ArrayList<Integer>
+
+
getCount() :i nt
getItem(i nt) :Object
+
PosicaoMemori a(Context, ArrayLi st<Integer>)
-ui Handl
erConsol
e
EA
9.3
Unregistered
Trial Version+ alterVal
EA ue(i
9.3
Unregistered Trial Version EA 9.3 Unregi
nt, Integer) :void
Handler
UIHandlerConsole
EA
9.3 Unregistered Trial Version++ getItemId(int)
EA 9.3:l ong
Unregistered Trial Version EA 9.3 Unregi
+ handl eMessage(Message) :void
getView(i nt, View, ViewGroup) :View
-mvm
EA 9.3 Unregistered
Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
Handler
handleMessage(Message) :voi d
SQLi teOpenHel per
MaquinaVirtual
UIHandler
+
~
~
~
~
~
~
~
~
~
~
~
+
~
acerto :i nt = 0
ax :int = 0
bp :i nt = 0
bx :int = 0
cl ockBusc :i nt = 0
cl ockComplExec :int = 0
cl ockExec :int = 0
cx :i nt = 0
erro :String = ""
i :i nt = 0
ip :i nt = 0
main :Mai nActi vi ty
mem :int ([]) = new i nt[1024]
sp :i nt = 0
+
+
decodi ficar(Stri ng) :void
impri meVal oresConsol e(int) :Stri ng
OpenHelper
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered
Version EA 9.3 Unregi
DB :Stri ng = "MVMDB"Trial
{readOnl y}
ConstMenu
-
T ABELA_PROJETO :Stri ng = "PROJETO" {readOnly}
+
+
~
onCreate(SQLi teDatabase) :voi d
EA
9.3 Unregistered
Trial Version EA 9.3 Unregistered
Trial
Version
EA 9.3 Unregi
+ CARREGAR
:int = 2 {readOnly}
onUpgrade(SQLiteDatabase,
i nt, int)
:voi d
+
+
+
+
+
+
+
COMPILAR :i nt = 4 {readOnl y}
EXCLUIR :int = 8 {readOnly}
EXECUT AR :i nt = 5 {readOnl y}
EXECUT AR_PASSO :i nt = 6 {readOnl y}
NOVO :i nt = 1 {readOnl y}
PARAR_EXECUCAO :i nt = 7 {readOnl y}
SALVAR :i nt = 3 {readOnl y}
OpenHelper(Context)
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
EA 9.3 Unregistered Trial Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
+ li Version
mparConfi guracoes(iEA
nt) :void
EA 9.3 Unregistered Trial
9.3 Unregistered Trial Version EA 9.3 Unregi
+ li mparConfi guracoesReg(i nt) :voi d
EA 9.3 Unregistered Trial
Version EA 9.3 Unregistered Trial Version EA 9.3 Unregi
Figura 18 – Diagrama de classes
39
A classe MainActivity é a responsável pelo controle dos componentes visuais, ela
utiliza as classes DataHelper para o controle do banco de dados, onde é efetuada a inserção
dos registros, consulta dos dados e remoção dos registros.
As opções de menu são inseridas em um componente chamado listView
com
eventos de clique para a execução da devidas rotinas. Todas as opções do aplicativo são
tratadas por um único listener, onde chama a rotina necessária para a opção selecionada
conforme apresentado no quadro 2.
Quadro 2 – Controle das opções
A classe MainActivity também instancia a classe MaquinaVirtual que é responsável
pelo controle dos registradores e da memória que é suportada. Conforme especificado na
seção anterior, a MVM suporta 1024 posições de memória (implementada como um array de
bytes) e possui um total de 6 registradores.
A execução das instruções é realizada pela classe MainActivity. Esta abordagem foi
necessária pois a execução deve ocorrer de forma independente da interface e para isto foi
necessário instanciar uma thread5 contendo um handler6 para passar as mensagens ao
componente gráfico e fazer a atualização dos camnpos em tempo real. O quadro 3 apresenta
uma parte do código para execução das instruções na memória.
5
Permite que possam ser executadas várias tarefas diferentes ao mesmo tempo (Alcântara, 1996).
6
Uma referência a um objeto para poder enviar mensagens a uma thread ou o programa principal (Parkhi, 2011).
40
Quadro 3 – Parte do código de execução do programa
A criação do banco de dados é realizada na classe OpenHelper, que é ativada no
momento da criação da classe DataHelper. O nome do banco de dados utilizado na
aplicação foi definido como “MVMBD” e caso haja alguma alteração dos dados, todos os
registros são excluídos e o banco de dados é recriado. O quadro 4 abaixo apresenta a rotina de
criação do banco de dados.
As classes Opcao, OpcoesMenu, PosicaoMemoria e MsgGenericaAdapter são
utilizadas para a criação dos listview das opções de menu, registradores, console e
memória.
41
Quadro 4 – Criação do banco de dados
3.3 IMPLEMENTAÇÃO
Nesta seção são abordadas as técnicas e ferramentas utilizadas para o desenvolvimento
do aplicativo, bem como características da arquitetura implementada e uma descrição sobre as
funcionalidades da ferramenta.
3.3.1 Técnicas e ferramentas utilizadas
Para o desenvolvimento do aplicativo foi utilizada a linguagem de programação Java
com API de desenvolvimento Android para o modo de compatibilidade com a versão 2.2 até
4.1 disponível no plug-in Android Development Tools (ADT) em sua versão 20.0.3. Este
plug-in é incluso a Integrated Development Environment (IDE) Eclipse e adiciona recursos
para a criação e execução de aplicações, possibilitando inclusive a execução a partir de um
dispositivo Android.
O desenvolvimento da aplicação foi realizado utilizando o emulador Android na versão
4.1 e o tablet da marca Genesis no modelo GT-1230 com o sistema Android 4.0. O Genesis
GT-1230 possui um processador Cortex A8 com capacidade de 1.2 Giga Hertz (GHz),
memória de 1 Giga Byte (GB) de Random Access Memory (RAM) e 8 GB de Read Only
Memory (ROM).
42
O armazenamento dos projetos é feito utilizando o banco de dados Sqlite, disponível
por padrão nos sistemas operacionais Android.
3.3.2 Operacionalidade da implementação
Um programa na MVM pode ser construído de 2 formas:
a) inserção da sequencia de códigos de operação diretamente nas posições de
memória ou;
b) edição de um arquivo texto com a sequencia de instruções.
No primeiro caso após a inserção da instrução HALT o valor do registrador IP é
inicializado para a posição contendo a primeira instrução do programa e ao pressionar o botão
Executar a sequencia de instruções será executada.
No segundo caso é necessário um passo de “montagem” onde a sequencia de
instruções expressa através dos mnemônicos é traduzida para os respectivos códigos de
instrução e os mesmos são armazenados nas respectivas posições de memória a partir de um
“endereço de carga” previamente fornecido.
A interface do aplicativo é dividida em 5 regiões (figura 19).
a) opções do programa: onde são disponibilizados as funções de:
− novo projeto: cria um novo projeto para ser executado na MVM;
− carregar projeto: localiza um projeto já criado com o código fonte salvo;
− salvar projeto: salva o projeto alterado na máquina;
− compilar projeto: efetua a transcrição dos comandos inseridos na área do
código fonte para a memória da máquina. Neste momento é validado se todos
os comandos inseridos são suportados pela máquina, caso contrário, apresenta
ao usuário o comando que encontrou o problema e a linha que o mesmo
pertence;
− executar projeto: executa as instruções que estão na memória;
− executar passo-passo: executa as instrução que estão na memória, porém, com
um temporizador de 6 segundos para cada instrução executada;
− parar execução: Finaliza a execução do programa em execução;
− excluir: Exclui o projeto atual.
43
b) código fonte: Área para a edição do código fonte a ser compilado pela máquina;
c) console: Área onde serão apresentadas as mensagens de saída do comando “out”;
d) registradores: Área em que será apresentado em tempo real o valor de cada
registrador da máquina, estes valores são atualizados durante a execução;
e) memória da CPU: Área em que são apresentados os valores de cada posição de
memória. Cada posição de memória pode ter seu valor alterado e será executado
pela máquina no momento da execução.
Figura 19 – Regiões da interface da MVM
Em um primeiro momento deve-se criar um novo projeto ou carregar projetos já
salvos, como mostram as figuras 20 e 21.
Figura 20 – Tela de criação do novo projeto
44
Figura 21 – Tela de localização dos projetos já existentes
Ao ser carregado um projeto são geradas as 1024 posições de memória em um
listview o que permite a edição dos valores. Neste momento é possível a edição de
instruções que serão compiladas ou a alteração direta das posições de memória.
A compilação do projeto é necessária para a conversão das instruções para seus
respectivos códigos de operação. Havendo algum erro nesta etapa será apresentada uma
mensagem indicando que o comando que não foi encontrado e a linha que ele se
encontra. O tratamento de erros é sequencial, ou seja, para que seja encontrado o próximo
comando não suportado, deve-se corrigir o primeiro (figura 22).
Figura 22 – Mensagem de erro durante a verificação.
45
Com o programa devidamente carregado para a memória inicia-se o processo de
execução onde a cada momento são atualizadas as outras 3 listview: a primeira de
execução das instruções, a segunda para atualização dos registradores e a terceira para
atualização da console que apresenta a saída dos comandos.
Este processo foi realizado para permitir que a execução e a alteração dos
registradores ocorram em tempo real, permitindo que o aluno possa acompanhar a
execução do programa. Quando a aplicação está em processamento é possível finalizar a
mesma, entretanto, os valores de memória não irão condizer com o resultado do
programa, apenas se manterão com o status anterior ao cancelamento da aplicação. A
cada nova execução os registradores são inicializados com zero e a execução é realizada
em função do conteúdo atual da memória.
3.3.3 Casos de testes
Objetivando validar a implementação, nesta seção são apresentados alguns exemplos
de programas que são suportados pela máquina virtual conforme apresentados por Mattos
(2012).
A figura 23 ilustra uma sequência simples que permite ao aluno validar o conceito de
ciclo de busca, decodificação e execução de instruções. Na primeira coluna existe a referência
explicita a posição de memória (ex. mem[0]), o mnemônico da instrução e na terceira coluna
o código da operação que deverá ser armazenado na respectiva posição. Ao final do programa
é apresentado o resultado esperado da execução do mesmo.
46
Fonte: Mattos (2012).
Figura 23 – Ciclo de busca, decodificação e execução
O exemplo da figura 24 demonstra explicitamente que os parâmetros das instruções
ocupam o próximo byte na sequencia. Além disso, o exemplo serve para caracterizar a
diferença entre valor imediato e endereçamento direto.
Fonte: Mattos (2012).
Figura 24 – Atribuição de valor imediato
47
A figura 25 apresenta o resultado do programa da figura 25 na MVM mobile.
Figura 25 – Resultado a execução do programa da figura 24.
A figura 26 apresenta um programa para validar as instruções de desvio incondicional
e desvio condicional. São apresentados os resultados esperados da execução do programa para
que os acadêmicos possam validar as suas respectivas implementações.
Fonte: Mattos (2012).
Figura 26 – Desvio incondicional imediato
A figura 27 apresenta o resultado da execução do programa.
48
Figura 27 – Resultado das instruções da figura 26
O próximo exemplo (figura 28) demonstra o uso das operações de pilha de execução
através das instruções push e pop.
Fonte: Mattos (2012).
Figura 28 – Operação de pilha
49
A figura 29 demonstra a saída da MVM para o exemplo da figura 28.
Figura 29 – Resultado da execução do programa da figura 28
A figura 30 apresenta exemplo de acesso a memória através de modo de
endereçamento por base e deslocamento. No exemplo, o registrador base é o registrador BX.
Fonte: Mattos (2012).
Figura 30 – Endereçamento por base e deslocamento
50
O exemplo acima propositalmente contém um erro que faz com que a MVM aborte a
execução. Isto porque há uma sobrescrita da instrução HALT fazendo com que o sistema
atinja o topo da memória executando operações INIT AX (código 0). Os alunos são levados a
refletir o porque do erro e então a solução é publicada conforme apresentado na figura 31.
Fonte: Mattos (2012).
Figura 31 – Correção do exemplo de endereçamento por base e deslocamento
Finalmente o exemplo a seguir demonstra o conceito de device driver validando o
processo de interrupção por software e o fluxo de retorno de uma interrupção. Este é o ponto
de partida para a construção de um núcleo de multitarefa com vários processos. A única
modificação do código abaixo foi a alteração da instrução move ax,{1024} para move
ax,{1023},
0.
pois a máquina suporta apenas 1024 posições de memória, partindo da posição
51
Fonte: Mattos (2012).
Figura 32 – Device driver
A figura 33 demonstra o funcionamento do exemplo na MVM.
Figura 33 – Resultado da execução do programa da figura 32
52
O código do quadro 5 mostra um exemplo de um programa que simula a chamada de
interrupções por software.
Quadro 5 – Código fonte de uma aplicação de chamada de interrupções por software
3.4 RESULTADO E DISCUSSÃO
O presente trabalho apresentou o desenvolvimento da MVM para Android. Conforme
apresentado, a aplicação permite demonstrar de forma clara e objetiva o passo a passo de uma
máquina de um único processador, sendo um excelente ponto de partida para a introdução aos
conceitos de sistemas operacionais.
A partir dos recursos desenvolvidos é possível a criação de um núcleo de multitarefa
onde os alunos tem uma visão completa da interação hardware e software e o papel de um
sistema operacional como gerenciador de recursos.
O sistema foi desenvolvido em Java sendo a escolha da versão 20.0.3 do plugin ADT
escolhida pelo fato de ser a última versão estável disponibilizada além de permitir o
tratamento para a compatibilidade com outras versões do sistema operacional. O aplicativo
desenvolvido é compatível a partir da versão 2.2 do Android e permite que a aplicação seja
compatível com mais de 98% dos aparelhos no mercado segundo a Google (2012 apud
HECKE, 2012) (figura 34).
53
Fonte: Hecke (2012)
Figura 34 – Percentual de aparelhos e suas determinadas versões do Android
Esta decisão de projeto acarretou alguns problemas como a falta de componentes
visuais para o desenvolvimento da interface e performance do programa. Outros problemas
que foram encontrados durante o desenvolvimento foi o controle de thread’s do sistema.
Atualmente o Android trabalha com diversas threads para determinadas execuções, como por
exemplo, a chamada de um AlertDialog.builder.
Durante a execução da MVM, esta
situação fazia com que o sistema questionasse ao usuário o novo valor do registrador AX,
porém, não interrompia a execução e fazia com que o programa continuasse independente do
valor entrado. Para que esta situação fosse corrigida foi necessária a implementação de uma
rotina de controle juntamente com a chamada da classe AlertDialog.builder e assim foi
possível
simular
a
execução
JOptionPane.showMessageDialog
modal
do
comando,
semelhante
ao
método
nativo do framework7 swing.
Outra situação encontrada foi quanto ao cancelamento da execução para casos de
problemas na execução do programa. Isto ocorre pois o Android possui problemas ao
interpretar a chamada entre as threads criadas, impossibilitando que seja cancelado
diretamente a execução. Para esta situação foi necessária a utilização de um método
synchronized
para a alteração de uma variável global, permitindo assim a alteração de seu
valor e a paralização da execução MVM. Outra forma de resolver seria a criação de um
handler
para o cancelamento da execução, entretanto, havia uma grande quantidade de
lugares para ser tratada esta questão e acabaria fazendo com que houvessem chamadas
7
Segundo a Müller (2008) um framework é uma abstração que unifica os códigos comuns entre vários projetos
para uma funcionalidade genérica.
54
repetidas vezes ao mesmo handler, podendo causar conflito na execução e finalizando a
aplicação.
O modelo de tablet que foi utilizado para testes, o Genesis GT-1230, possui tratamento
para rotatividade da tela com base no acelerômetro8 do aparelho. Em função disto, quando
era efetuado o ajuste da tela, acabava por chamar o método onCreate do aplicativo. Este
problema também foi relatado ao ser testado com um tablet da marca Acer.
Mesmo com um número limitado de instruções e posições de memória, a simulação de
uma série de rotinas, incluindo a criação de sub-rotinas para a execução, cálculos e
interrupções ocorrem de forma eficiente permitindo que sejam simulados vários casos reais
ocorridos em sistemas operacionais além de simulação de núcleos multitarefas.
8
Segundo Prada (2009), o acelerômetro é um equipamento que mede a aceleração do aparelho, podendo assim,
detectar movimentos e fazer tratamento como por exemplo, rotacionar o visor juntamente com a posição relativa
do aparelho.
55
4 CONCLUSÕES
O presente trabalho descreve a implementação de uma máquina virtual hipotética
denominada MVM. Os objetivos propostos foram atendidos na medida em que é possível a
criação, execução e persistência de programas exemplo.
O sistema permite a simulação de interrupções e, com isto, a possibilidade de
construção de um núcleo de multitarefa. Conforme Mattos (2012), este é o ponto máximo de
utilização da ferramenta uma vez que o aluno pode, executando passo a passo o código
fornecido pelo professor, acompanhar o processo de troca de contexto entre processos não
perdendo de perspectiva tanto o comportamento do hardware como o comportamento do
software do sistema operacional.
Como ferramenta didática a MVM tem demonstrado ser útil na fixação de conceitos
importantes. Como ferramenta de motivação, a versão mobile desenvolvida neste trabalho traz
um agregado importante pois permite a mobilidade à solução construída.
Como apresentado no levantamento de trabalhos correlatos, a tendência dos projetos é
a demonstração de algoritmos de alto nível relacionados a gerência de memória, processos e
entrada e saída ou utilizando simuladores de arquitetura X86 (como o VXT) ou utilizando
simuladores que abstraem demasiadamente o funcionamento do hardware. Portanto todos
utilizam a abordagem top-down enquanto a MVM permite a demonstração de conceitos de
forma bottom-up.
O trabalho apresentado é um aplicativo de simulação de uma máquina virtual com o
intuito de apresentar de forma clara e simples o funcionamento e desenvolvimento de
pequenos programas que simulam rotinas internas de um sistema operacional, tais como
controle de eventos, chamada de métodos, cálculos e criação de sub-rotinas.
4.1 EXTENSÕES
Este é um projeto em andamento e algumas funcionalidades adicionais poderiam ser
consideradas como complementares ao ambiente já desenvolvido. Dentre elas destacam-se as
propostas a seguir:
a) implementação da funcionalidade de carga e relocação de programas;
56
b) implementação da funcionalidade de ligação dinâmica de bibliotecas;
c) implementação do mecanismo de overlays para gerenciamento de memória real;
d) implementação de dispositivos periféricos como unidade de disco;
e) implementação do mecanismo de memória virtual com paginação.
57
REFERÊNCIAS BIBLIOGRÁFICAS
ADAMS, Keith; AGESEN, Ole. A comparison of software and hardware techniques for x86
virtualization. In: Proceedings of the 12th international conference on architectural support for
programming languages and systems, 2006, California-USA.
ALCÂNTARA, Andreia A. O que são threads? [S.1], [1996]. Disponível em: <
http://www.di.ufpe.br/~java/verao/aula8/definicao.html>. Acesso em: 10 nov. 2012.
AMARAL, Fabio E. O que é virtualização? [S.1.], [2009]. Disponível em:
<http://www.tecmundo.com.br/web/1624-o-que-e-virtualizacao-.htm>. Acesso em: 20 abr.
2012.
ANATEL. Relatório anual 2009 - Anatel. [S.1.], [2009]. Disponível em:
<http://www.anatel.gov.br/Portal/verificaDocumentos/documento.asp?numeroPublicacao=24
5429&assuntoPublicacao=Relat%F3rio%20Anual%20da%20Anatel%202009&caminhoRel=
null&filtro=1&documentoPath=245429.pdf>. Acesso em: 10 jun. 2012.
AQUINO, Juliana F. S. Plataformas de desenvolvimento para dispositivos móveis. 2007.
14 f. Monografia (Pós Graduação em Informática) – Departamento de Informática, Pontifícia
Universidade Católica do Rio de Janeiro, Rio de Janeiro.
CARVALHO, Joel O. EPSOsim - simulador de escalonamento de processos em sistemas
operacionais. 2011. 92 f. Monografia de Graduação (Bacharelado em Ciências
da Computação) - Faculdade Farias Brito, Fortaleza. Disponível em:
<http://www.ffb.edu.br/sites/default/files/tcc-20111-joel-oliveira-carvalho.pdf>. Acesso em:
10 set. 2012.
FRES, Osmar A.; ALONSO, Ignacio G. Rovim: a generic and extensible virtual machine for
mobile robots. [S.1.], [2010]. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5464168&tag=1>. Acesso em: 20
abr. 2012.
HECKE, Caroline. Ice Cream Sandwich está em 7% dos aparelhos com Android. [S.1],
[2012]. Disponível em: <http://www.tecmundo.com.br/android/24517-ice-cream-sandwichesta-em-7-dos-aparelhos-com-android.htm>. Acesso em: 04 nov. 2012.
HONORATO, Renata. ‘Vamos começar pelo professor', diz Mercadante sobre projeto de
R$ 180 mi que levará tablets a escolas públicas. [S.1.], [2012]. Disponível em:
<http://veja.abril.com.br/noticia/educacao/vamos-comecar-pelo-professor-diz-mercadantesobre-projeto-de-r-180-milhoes-que-levara-tablets-a-escolas-publicas>. Acesso em: 01 jun.
2012.
LANDIM, Wikerson. O que é Wi-Fi? [S.1.], [2012]. Disponível em:
<http://www.tecmundo.com.br/wi-fi/197-o-que-e-wi-fi-.htm>. Acesso em: 13 nov. 2012.
58
MACHADO, Francis B.; Maia, Luis P. Um Framework construtivista no aprendizado de
Sistemas Operacionais - uma proposta pedagógica com o uso do simulador SOsim. In:
WORKSHOP DE EDUCAÇÃO EM COMPUTAÇÃO, 24., 2004, Salvador. Anais
eletrônicos... Salvador: UFBA, 2004. Disponível em:
<http://www.training.com.br/sosim/sbcwei04.pdf>. Acesso em: 13 nov. 2012.
MATTOS, Mauro M. et al. VXt: um ambiente didático para ensino de conceitos básicos de
sistemas operacionais e arquitetura de computadores. In: WORKSHOP DE COMPUTAÇÃO
DA REGIÃO SUL, 1., 2004, Florianópolis. Anais… Florianópolis: Unisul, 2004. Paginação
irregular.
MATTOS, Mauro M. Sistemas operacionais. 2012. Paginação irregular. Notas de aula
(Disciplina de Sistemas Operacionais, Bacharelado em Ciências da Computação) - Centro de
Exatas e Naturais, Departamento de Sistemas e Computação, Universidade Regional de
Blumenau, Blumenau.
MAZIERO, Carlos. Reflexões sobre o ensino prático de sistemas operacionais. In.
WORKSHOP SOBRE EDUCAÇÃO EM COMPUTAÇÃO, (WEI2002), 1., 2002,
Florianópolis. Anais... Florianópolis: PUCPR, 2002. p. 1-4.
MEDEIROS, Thiago R. et al. IO Simulator: Um Simulador de Dispositivos de Entrada e
Saída para Auxiliar o Ensino de Sistemas Operacionais. In: WORKSHOP SOBRE
EDUCAÇÃO EM COMPUTAÇÃO, 19., 2011, Natal. Anais eletrônicos... Disponível em:
<http://www.dimap.ufrn.br/csbc2011/anais/eventos/contents/WEI/Wei_Secao_5_Artigo_2_M
edeiros.pdf>. Acesso em: 13 nov. 2012.
MORIMOTO, Carlos E. Introdução aos sistemas de virtualização. [S.1.], [2010].
Disponível em: <http://www.hardware.com.br/dicas/intro-sistemas-virtualizacao.html>.
Acesso em: 17 nov. 2012.
MORITZ, Gustavo. Simulador de mecanismos de gerência de memória real e virtual.
2004. 81 f. Trabalho de Conclusão de Graduação (Bacharelado em Ciências
da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,
Blumenau. Disponível em: <http://campeche.inf.furb.br/tccs/2004-II/20042gustavomoritzvf.pdf>. Acesso em: 10 out. 2012.
MÜLLER, Nícolas. Framework, o que é e para que serve? [S.1], [2008]. Disponível em:
<http://www.oficinadanet.com.br/artigo/1294/framework_o_que_e_e_para_que_serve>.
Acesso em: 04 nov. 2012.
PARKHI, Vaibhav. Multi-threading in Android using handler for message queue. [S.1],
[2011]. Disponível em: <http://marakana.com/forums/android/examples/500.html>. Acesso
em: 16 nov. 2012.
PAULO, Marcus. SISO 2.0 – simulador de sistema operacional (módulo de deadlock). [S.1.],
2009. Disponível em: <http://www.martins.eti.br/2009/03/siso-20-simulador-desistema.html>. Acesso em 15 de novembro de 2011
59
PRADA, Rodrigo. O que é um acelerômetro? [S.1.], [2009]. Disponível em:
<http://www.tecmundo.com.br/curiosidade/2652-o-que-e-um-acelerometro-.htm>. Acesso em
02 nov. 2012.
SANTOS, Rogério S. et al. Guia de estruturação e administração do ambiente de cluster
e grid. [S.1.], 2006. Disponível em <http://www.governoeletronico.gov.br/anexos/guia-decluster>. Acesso e 13 nov. 2012.
SCHOUERY, Rafael C. S. Manual do desenvolvedor do HIPO: o computador hipotético.
[S.1.], [2007]. Disponível em: <http://hipo.sourceforge.net/desenvolvedor.pdf>. Acesso em:
20 abr. 2012.
SCHOUERY, Rafael C. S. Linux – inside III. [S.1.], [2012]. Disponível em:
<http://blog.sirandsir.com/tag/hipo/>. Acesso em: 02 nov. 2012.
SCOPE. Virtualization: state of the art. [S.l.], 2008. Disponível em: <http://www.scopealliance.org/pr/SCOPE-Virtualization-StateofTheArt-Version-1.0.pdf>. Acesso em: 22 set.
2008.
SILVA, Marcos A. et al. BrasilOS: Um ambiente didático para auxílio ao ensino e
aprendizado de sistemas operacionais. In: WORKSHOP SOBRE EDUCAÇÃO EM
COMPUTAÇÃO, 21., 2011, Natal. Anais eletrônicos... Disponível em:
<http://www.dimap.ufrn.br/csbc2011/anais/eventos/contents/WEI/Wei_Secao_2_Artigo_4_Si
lva.pdf>. Acesso em: 13 nov. 2012.
VEIGA, Marise S. Computador e educacão? Uma ótima combinação. [S.1.], [2001].
Disponível em: <http://www.pedagogiaemfoco.pro.br/inedu01.htm>. Acesso em: 14 abr.
2012.