5 IMPLEMENTAÇÃO 49
5.1 Sistema Embarcado 49
5.1.2 Cliente/Servidor C++ (Processa) 54
O conceito cliente e servidor é bastante difundido entre os sistemas distribuídos (PASTOR, 2014), logo é possível encontrar facilmente diversas bibliotecas que implementem essa teoria.
No SiNDi foi utilizado protocolo TCP/IP para comunicação entre bibliotecas de Cliente e de Servidor. A porta utilizada foi 30000, onde a escolha desta foi aleatória para fins de validação da solução.
5.1.3 Festival C++ (Sintetiza)
Por se tratar de uma ferramenta de síntese de fala, ele carrega consigo a necessidade de inúmeras bibliotecas específicas, criadas exclusivamente para sua execução com diversas possibilidades de interface com outros sistemas. (BLACK; TAYLOR ;CALEY, 1999).
Para o SiNDi, foi decidido pela a utilização da API C/C++ onde ele estaria embarcado na aplicação. (item 28.4 da documentação do Festival (BLACK; TAYLOR ;CALEY, 1999)).
Apesar de fornecido pelos próprios desenvolvedores do Festival - documentação, bibliotecas, exemplos e orientações - a implementação não foi trivial.
Dentre os arquivos fornecidos alguns deles possuíam erros, o que impedia o teste de unidade do festival de ser realizado propriamente. Esse foi o motivo pela qual a unidade do Festival C++ foi a mais complexa, dentre todas as demais.
As principais funções oferecidas pela API são a função de inicialização e do sintetizador. A função de inicialização deve ser chamada antes de qualquer outra função para preparar o sintetizador. A função do sintetizador é responsável pela síntese do texto passado como parâmetro, retornando verdadeiro ou falso dependendo se a execução realizada corretamente.
Apesar de se ressaltar a importância da qualidade da fala, para a satisfação do usuário do transporte público de Curitiba (LANZONI, 2013), devido a limitação da ferramenta por não possuir síntese da língua Portuguesa, foi utilizado para a síntese padrões da língua Inglesa. Sendo assim, os arranjos ficaram distorcidos por sintetizar frases da língua Portuguesa com padrão Inglês.
Entretanto, esse item é propício para desenvolvimento em trabalhos futuros, já que o festival permite a criação de novas vozes independente de suas origens.
5.1.4 Estrutura de Dados
Algumas estruturas foram definidas para que o SiNDi possuísse um código otimizado seguindo os padrões de implementação de orientação objeto. Estas foram:
localização no globo;
b. Estrutura de Mensagens composta por: identificador de mensagem;
o código único para cada mensagem; texto da mensagem;
o mensagem definida pelo funcionário da URBS a ser falada nos ônibus;
tipo de mensagem;
o definição se é uma mensagem educacional ou por localização; coordenada GPS;
o se mensagem por localização, esse campo indica o local onde a mensagem deve ser acionada;
se ela pode ser executada;
o se mensagem por localização, ela só pode ser executada uma vez, quando dentro do perímetro aceitável para execução; horário de última execução;
o se mensagem educacional, esse campo indica a última vez que mensagem foi executada.
e se ela está na fila a para ser executada;
o esse atributo é utilizado a fim de que a mesma mensagem não esteja duplicada na fila de execução;
c. Estrutura de elementos utilizados por todos os processos do SE, sendo estes:
Fila de mensagens;
o armazena todos as mensagens recebidas da Central; Fila de mensagens para execução;
o armazena as mensagens temporariamente conforme o agendamento para serem executadas pelo festival; após execução as mensagens são removidas do vetor;
Fila de mensagens de emergência;
o armazena as mensagens de emergência temporariamente para que sejam executadas; a mensagem é removida única e exclusivamente por algum pedido que venha da Central;
Tempo de intervalo de mensagens educativas;
o define o valor em minutos do intervalo que as mensagens educativas devem ser executadas;
Raio de limite do perímetro;
o define o valor em metros do perímetro aceitável para a execução das mensagens por localização;
três semáforos para cada uma das filas;
o são implementados para que seja garantido a integridade na fila de mensagens em acessos concorrentes; cada variável é associada a um vetor diferente;
O diagrama de classes a seguir representa a relação entre os elementos apresentados nesse capítulo.
Figura 27 - Diagrama de Classes da estrutura de dados Fonte: Autoria Própria, 2015.
As estruturas de dados -declarações ou agrupamentos de ações diretas implementadas pela linguagem de programação- não possuem a necessidade de teste de unidade. Neste caso, as verificações de erros são realizadas ao utiliza-las em elementos que implementam a lógica do programa.
5.1.5 Tratamento de Mensagem
A Central envia mensagem com a seguinte sintaxe:
tag messageID [latitude] [longitude] (messageText)
com itens entre colchetes sendo opcionais para mensagens educativas e de emergência.
Exemplos de mensagem educacional e de emergência:
MensagemEducacional 0 (Mensagem para ser Falada) MensagemEmergencia 0 (Mensagem para ser Falada)
E exemplo de mensagem por localização:
MensagemLocalizacao 0 -25.4387 -49.2694 (Proxima parada, praca eufrasio correia)
O SE também implementa funções para tratamento do intervalo de repetição de mensagens educativas, limite do perímetro da localização e limpar lista de mensagens. A sintaxe para essas mensagens é:
tag [value]
com o item entre colchetes sendo opcional para os comando de limpar vetores.
Nesses casos as possibilidades de mensagens são exemplificadas a seguir:
intervaloEducacional 5 limiteLocalizacao 400
limparVetorExecucao limparVetorEmergencia limparVetorArmazenadas
O tratamento de mensagens recebidas é realizado na thread do servidor que, implementa o estado processa conforme especificado o item 4.3.1.
A sequência no processamento de mensagens é definida pelo fluxo abaixo.
Figura 28 – Fluxo de tratamento de mensagens Fonte: Autoria Própria, 2014
Os delimitadores de cada palavra são os espaçamentos, logo as mensagens de exemplo apresentadas acima retornaram um vetor de tamanho 6, 6 e 9, respectivamente. É importante ressaltar, que a quantidade de tokens da mensagem, depende da quantidade de palavras que existe no texto definido pela URBS.
Como não é interessante, em termos de organização de objetos, manter as palavras do texto da mensagem em tokens separados, o servidor faz um pós- tratamento procurando os parênteses dentre os tokens, para poder concatená-los novamente. Essa etapa não possui efetividade alguma quando nas mensagens recebidas, não houver parênteses.
Recebe mensagem pela porta disponivel pelo servidor Separa tokens Concatena palavras do texto da mensagem Identifica tag Realiza tratamento especifico para cada tag
5.2 Central
A Central é um elemento complementar no projeto, no qual seu objetivo é fornecer ao usuário interface com SE.
Seu desenvolvimento foi feito em C#, devido a disponibilidade da IDE, Visual Studio 2013 Ultimate, em integrar automaticamente o BD SQL Server 2012 definido no
Outra facilidade da ferramenta, é a programação por gráfico. Para gerar o layout ao usuário, o ambiente permite que o mesmo seja montado diretamente na janela, tornando intuitiva o desenvolvimento da interface da Central.
As linhas códigos necessárias na implementação foram para realizar comunicação TCP/IP com o SE e a conversão dos elementos de entrada na interface gráfica para elementos de tabelas no SQL.
Seu teste de unidade foi realizado em separado tanto para o BD quanto para a comunicação via socket do tipo TCP/IP.
6 RESULTADOS
Este capítulo apresenta os resultados dos testes descritos no item 4.1.6 que simulam o comportamento do usuário e exponhem as ações da Central e do SE. Neste contexto, apresentam-se 5 pontos reais para 2 linhas reais (Figura 30) para efeitos de teste.
A Figura 29, apresenta o SE com seus elementos, utilizados no decorrer do projeto.
Figura 29 – Sistema Embarcado SiNDi Fonte: Autoria Própria, 2014.
Figura 30 – Mapas das linhas 203 e 503 Fonte: Google Maps, 2014.
Esses itens que foram supostamente inseridos pelo usuário da URBS através do programa instalado na Central, os resultando no BD os dados como dispostos no Quadro 7, Quadro 8 e Quadro 9. Destaca-se que é previsto que, no momento da criação da Linha, o usuário já tenha cadastrado Pontos para poder relacionar com a Linha.
Quadro 7 – Dados para a tabela Ponto
nPontoID cNomePonto Latitude Longitude
108022 Passeio Público -25,42366 -49,26835 108024 Central -25,429982 -49,267561 108025 Praça Eufrásio Correia -25,437553 -49,266655 108028 Alferes Poli -25,439367 -49,271254 108032 Praça Oswaldo Cruz -25,44108 -49,275554 108065 Praça Carlos Gomes -25,433706 -49,270224 108067 UTFPR -25,439061 -49,268113 108070 Getúlio Vargas -25,443629 -49,265721 108072 Almirante Gonçalves -25,447435 -49,263822 108073 Conselheiro Dantas -25,45149 -49,261923
Fonte: Autoria Própria, 2014. Quadro 8 – Dados para tabela Linha nLinhaID cLinha
503 Boqueirão Horário
203 Santa Cândida / Capão Raso Horário Fonte: Autoria Própria, 2014.
Quadro 9 – Dados para tabela LinhaPonto nLinhaID nPontoID nSequenciaPonto
203 108022 1 203 108024 2 203 108025 3 203 108028 4 203 108032 5 503 108065 1 503 108067 2 503 108070 3 503 108072 4 503 108073 5
Fonte: Autoria Própria, 2014.
Do mesmo modo, o usuário deve cadastrar os ônibus, no qual ficariam dispostos no apresentado no Quadro 10. Destaca-se nesse caso, que é através do cadastro do ônibus que o usuário consegue informar qual a linha operante do mesmo, resultando com isso os itens dispostos no Quadro 11.
Quadro 10 – Dados para tabela Onibus
nOnibusID cChassiOnibus cIPOnibus nPortaOnibus 1000 BWCA11J0Y4OOOOO1 192.168.1.100 30000 1001 BWCA11J0Y4OOOOO2 192.168.1.101 30000 1002 BWCA11J0Y4OOOOO3 192.168.1.102 30000 1003 BWCA11J0Y4OOOOO4 192.168.1.103 30000
Quadro 11 – Dados para tabela LinhaOnibus nLinhaID nOnibusID 203 1000 203 1001 503 1002 503 1003
Fonte: Autoria Própria, 2014.
Após a configuração dos pontos, linhas e ônibus, o usuário deve cadastrar as mensagens referentes aos mesmos. É importante ressaltar que, apesar de não ser mandatório, realizar as associações no momento do cadastro, assegura que o SE alocado para cada ônibus receberá instantaneamente a configuração realizada, caso o SE esteja em operação. Assim sendo, ao realizar o cadastro, o usuário possuirá no BD os dados alocados como no Quadro 12, Quadro 13 e Quadro 14.
Quadro 12 – Dados para tabela Mensagem
nMensagemID cMensagem bCurrent
2000 Próxima parada, estação Passeio Público. Desembarque por todas as portas. 1
2001 Próxima parada, estação Central Desembarque por todas as portas. 1
2002 Próxima parada, estação praça Eufrásio Correia Desembarque por todas as portas. 1
2003 Próxima parada, estação Alferes Poli. Desembarque pelas portas 2 e 4. 1
2004 Próxima parada, estação Praça Oswaldo Cruz. Desembarque pelas portas 2 e 4. 1
2005 Próxima parada, estação Praça Carlos Gomes. Desembarque por todas as portas. 1
2006 Próxima parada, estação UTFPR. Desembarque por todas as portas. 1
2007 Próxima parada, estação Getúlio Vargas. Desembarque pelas portas 2 e 4. 1
2008 Próxima parada, estação Almirante Gonçalves. Desembarque pelas portas 2 e 4. 1
2009 Próxima parada, estação Conselheiro Dantas. Desembarque pelas portas 2 e 4. 1 2010 Cuidado com furtos no interior do veículo. 1
2011
Esta linha estará inoperante no domingo, dia 14 de dezembro, das
6 às 10 horas da manhã, devido a Caminhada do Coração. 1
2012 Aguarde sempre o desembarque. 1
Quadro 13 – Dados para tabela MensagemPonto nMessagemID nPontoID 2000 108022 2001 108024 2002 108025 2003 108028 2004 108032 2005 108065 2006 108067 2007 108070 2008 108072 2009 108073
Fonte: Autoria Própria, 2014.
Quadro 14 – Dados para tabela MensagemLinha nMensagemID nLinhaID 2010 503 2011 503 2012 503 2010 203 2011 203 2012 203
Fonte: Autoria Própria, 2014.
Os pacotes a seguir serão enviados para os ônibus 1000 e 1001 com os IPs 192.168.1.100 e 192.168.1.101 e portas 30000 e 30001, respectivamente.
MensagemLocalizacao 2000 -25.42366 -49.26835 (Próxima parada, estação Passeio Público. Desembarque por todas as portas.)
MensagemLocalizacao 2001 -25.429982 -49.267561 (Próxima parada, estação Central Desembarque por todas as portas.)
MensagemLocalizacao 2002 -25.437553 -49.266655 (Próxima parada, estação praça Eufrásio Correia Desembarque por todas as portas.)
MensagemLocalizacao 2003 -25.439367 -49.271254 (Próxima parada, estação Alferes Poli. Desembarque pelas portas 2 e 4.)
MensagemLocalizacao 2004 -25.44108 -49.275554 (Próxima parada, estação Praça Oswaldo Cruz. Desembarque pelas portas 2 e 4.)
Os pacotes a seguir serão enviados para os ônibus 1002 e 1003 com os IPs 192.168.1.102 e 192.168.1.103 e portas 30002 e 30003, respectivamente.
MensagemLocalizacao 2005 -25.433706 -49.270224 (Próxima parada, estação Praça Carlos Gomes. Desembarque por todas as portas.)
MensagemLocalizacao 2006 -25.439061 -49.268113 (Próxima parada, estação UTFPR. Desembarque por todas as portas.)
MensagemLocalizacao 2007 -25.443629 -49.265721 (Próxima parada, estação Getúlio Vargas. Desembarque pelas portas 2 e 4.)
MensagemLocalizacao 2008 -25.447435 -49.263822 (Próxima parada, estação Almirante Gonçalves. Desembarque pelas portas 2 e 4.)
MensagemLocalizacao 2009 -25.45149 -49.261923 (Próxima parada, estação Conselheiro Dantas. Desembarque pelas portas 2 e 4.)
As mensagens 2010, 2011 e 2012 são do tipo Educacional, e foram configuradas para serem executadas nas linhas 203 e 503. Assim sendo, todos os ônibus receberão os pacotes a seguir.
MensagemEducacional 2010 (Cuidado com furtos no interior do veículo.)
MensagemEducacional 2011 (Esta linha estará inoperante no domingo, dia 14 de dezembro, das 6 às 10 horas da manhã, devido a Caminhada do Coração.)
MensagemEducacional 2012 (Aguarde sempre o desembarque.)
Dentro da sequência apresentada, o programa se comportou de modo esperado, executando as mensagens de localização ao estarem 300 metros (valor padrão) dos pontos somente uma vez. Assim também como repetiam as mensagens educativas a cada 10 minutos (valor padrão), onde a cada 30 minutos todas as mensagens educativas se repetiam.
Para o próximo teste, o usuário reconfigurou o intervalo das mensagens educativas de 10 para 5 minutos e limite do perímetro do ponto das mensagens por localização de 300 para 100 metros.
Neste pedido os seguintes pacotes foram enviados a todos os ônibus. intervaloEducacional 5
limiteLocalizacao 100
Com a mudança citada no parágrafo anterior, as mensagens de localização passaram a ser executadas bem próximo aos pontos cerca de 100 metros e mantinham a funcionalidade de ser executada apenas dentro do perímetro. Assim também as mensagens educativas alteraram seu comportamento passando a serem executadas cada 5 minutos, onde após 15 minutos todas as mensagens educativas se repetiam.
Outro teste realizado foi o carregamento de uma sequência de mensagens referente a uma linha, para um ônibus que operava em outra. Apresenta-se a situação onde, o ônibus 1000, que opera na linha 203, passará a operar na linha 503. Neste caso a Central coordenará uma sequência de ações para que a mudança seja realizada propriamente.
Para o usuário da URBS, a única ação necessária é a alteração do registro do ônibus pela interface da Central, enquanto no plano de fundo a seguinte sequência será executada:
2. Alteração do BD na tabela LinhaOnibus;
3. Envio de pacotes configurando nova linha no ônibus. Nos testes os resultados apresentados foram:
1. Limpeza das listas de mensagens existentes no ônibus; Envio de pacotes de limpeza para o ônibus 1000;
limparVetorExecucao limparVetorEmergencia limparVetorArmazenadas
2. Alteração do BD na tabela LinhaOnibus;
Quadro 15 – Dados para tabela LinhaOnibus
nLinhaID nOnibusID
503 1000
203 1001
503 1002
503 1003
Fonte: Autoria Própria, 2014.
3. Envio de pacotes configurando nova linha no ônibus.
Envio dos pacotes de mensagens a seguir, para os ônibus 1000 de IP 192.168.1.100 e portas 30000.
MensagemLocalizacao 2005 -25.433706 -49.270224 (Próxima parada, estação Praça Carlos Gomes. Desembarque por todas as portas.)
MensagemLocalizacao 2006 -25.439061 -49.268113 (Próxima parada, estação UTFPR. Desembarque por todas as portas.)
MensagemLocalizacao 2007 -25.443629 -49.265721 (Próxima parada, estação Getúlio Vargas. Desembarque pelas portas 2 e 4.)
MensagemLocalizacao 2008 -25.447435 -49.263822 (Próxima parada, estação Almirante Gonçalves. Desembarque pelas portas 2 e 4.)
MensagemLocalizacao 2009 -25.45149 -49.261923 (Próxima parada, estação Conselheiro Dantas. Desembarque pelas portas 2 e 4.)
Acredita-se que os cenários testados satisfizem as expectativas levantadas junto à URBS ao apresentar um sistema flexível, com fácil configuração de mensagens e maior eficiência na comunicação com os usuários do transporte coletivo.
7 CONCLUSÃO
Neste trabalho de conclusão de curso utilizou-se de conhecimentos estudados no decorrer do curso de Engenharia de Computação: programação utilizando linguagens diversas: C++, C# e SQL; desenvolvimento e compilação de códigos em diferentes plataformas e ambientes: Linux, Windows, Eclipse, GCC e Visual Studio; teorias apresentadas em Sistemas Distribuídos: cliente/servidor; em Sistemas Embarcados: máquina de estados, cross-compile e interação com módulos periféricos; em Sistema Operacional: semáforos; em Engenharia de Software: diagramas UML; e em Estrutura de Dados: programação orientada objeto. Também apropiou-se de temas e ferramentas não abordados no curso como, síntese de fala.
O SiNDi é projeto composto de um SE (Sistema Embarcado) que deve ser instalado no ônibus, e uma Central que se comunica com o SE utilizada por funcionários da URBS para configuração de novas mensagens.
O cliente – Central – é um computador onde se implementou funções de cadastro de ônibus, linhas, pontos e mensagens. Também pela interface, é possível configurar as mensagens de acordo com seu objetivo, podendo esta ser uma mensagem temporizada ou dependente da localização. Outrora, essas características são assimiladas de acordo com a relação explicita da mensagem com ônibus, linha ou ponto.
O servidor – SE, por sua vez, é composto por um hardware e software. O hardware é o conjunto dos elementos Raspberry PI Model B, módulo wi-fi, módulo GPS, antena externa para GPS e alto-falantes. O software é responsável por receber os pacotes enviados pelo cliente, escalona-los e sintetizar as mensagens conforme sua configuração. Para a síntese foi utilizada a biblioteca do Festival, permitindo que a síntese fosse realizada diretamente pelo software.
Na arquitetura proposta, a comunicação Central-SE desempenha um papel secundário, pois havendo mensagens configuradas, o SE tem um comportamento autônomo. Porém, sem esta comunicação, a flexibilidade do sistema é reduzida, ficando a mercê do seu reestabelecimento.
O protocolo TCP/IP funcionou adequadamente e foi testada com um módulo
wi-fi, comprovando conceitualmente que é possível a conexão remota da Central
com o SE.
Socialmente, este trabalho espera contribuir para uma melhor aceitação do transporte coletivo ao promover melhor comunicação com os usuários.
Do ponto de vista tecnológico, o projeto inova com a implementação de um processo moderno envolvendo novas tecnologias no setor de transporte público. Do econômico, o SiNDi reduz o tempo no qual a URBS demorava para realizar alterações de mensagens nos ônibus de 10 dias, para alguns minutos, além da redução de gastos com impressão e distribuição de avisos para a notificação dos usuários da RIT.
Por fim, acredita-se que esta monografia tenha atingido seu objetivo proposto ao entregar um sistema:
flexível, permitindo configuração e reconfiguração de mensagens de maneira instantânea pela URBS;
com acesso remoto, devido a implementação do protocolo TCP/IP; que utiliza um receptor GPS para identificar os locais onde mensagens
devem ser reproduzidas;
e que utiliza de um software de síntese de fala para gerar áudio- mensagens nos ônibus da RIT.
7.1 Trabalhos Futuros
Essa monografia abre possibilidade de trabalhos futuros nos seguintes aspectos:
Participação dos usuários para avaliação dos componentes informativos;
Implementação de nova voz em Português, melhorando a qualidade da fala;
Implementação do sistema para pontos de ônibus e estações-tubos; Substituição de rede internet por rede ad-hoc entre todos os elementos
da RIT;
de transporte;
Estudo de viabilidade da implementação real do SiNDi em toda RIT. Implementação de alertas que notifiquem a URBS sobre possíveis
falhas no sistema: falha de comunicação, recepção de satélite GPS perdida, mensagem não configurada, falha do SE e etc.
8 REFERÊNCIAS BIBLIOGRÁFICAS
ALBUQUERQUE, Almir dos S. Análise Comparativa dos Métodos de
Sintetização de Voz. 2001. 76 f. Dissertação (Mestrado em Ciência da
Computação) - Área de Concentração de Sistemas de Computação, Universidade Federal de Santa Catarina, Florianópolis, 2001. Disponível em: < http://repositorio.ufsc.br/bitstream/handle/123456789/80028/206429.pdf?sequence= 1&isAllowed=y>. Acesso em: 30 mar. 2015.
ANTONELLI, Diego; BARÃO, Gisele. Sistema de ônibus curitibano perdeu 14 milhões de usuários em 4 anos. Gazeta do Povo, Curitiba, 2 jun. 2012. Disponível em: <http://www.gazetadopovo.com.br/vida-e-cidadania/sistema-de-onibus- curitibano-perdeu-14-milhoes-de-usuarios-em-4-anos-1ug8szlhgxi2gjunpt88pbqdq>. Acesso em: 15 abr. 2013.
BLACK, Alan W.; LENZO, Kevin A. Flite: A Small Fast Run-Time Synthesis Engine. In: ISCA TUTORIAL AND RESEARCH WORKSHOP ON SPEECH SYNTHESIS, PERTHSHIRE. 2001. p. 20-4.
BLACK, Alan W.; TAYLOR, Paul; CALEY, Richard. The Festival Speech Synthesis
System: System documentation. 1999. Edition 1.4, for Festival Version 1.4.0. 17th
June 1999. Disponível em: <http://www.cstr.ed.ac.uk/projects/festival/manual/>. Acesso em: 13 dez. 2014.
BRAMBILLA, Flávio R.; PEREIRA, Luciana V.; PEREIRA, Paula B. Marketing de Relacionamento: Definição e Aplicações. INGEPRO – Inovação, Gestão e
Produção, v. 2, n. 12, dez. 2010, ISSN 1984-6193. Disponível em:
<http://www.ingepro.com.br/Publ_2010/Dez/306-941-1-PB.pdf>. Acesso em: 13 dez. 2014.
CUERVO, Luciane. Introdução à Fisiologia da Voz. Departamento de Música – UFRGS. Práticas Vocais para a Educação Musical. Porto Alegre. 2010. Material
produzido para fins didáticos. Disponível em:
<http://www.ufrgs.br/musicalidade/midiateca/praticas-musicais-vocais-e-
instrumentais/praticas-vocais/ovas-praticas-vocais/fisiologia>. Acesso em: 23 mar. 2015.
DUARTE, Fábio; LIBARDI, Rafaela; SÁNCHEZ, Karina. Introdução à mobilidade
urbana. Curitiba: Juruá, 2007.
ECLIPSE. Conceito: Modelo de Caso de Uso. Disponível em: <http://epf.eclipse.org/wikis/openuppt/openup_basic/guidances/concepts/use_case_ model,_2jyfUAhVEduRe8TeoBmuGg.html>. Acesso em: 27 abr. 2015.
EMBARQ BRASIL. De cá para lá: um guia criativo de marketing BRT para atrair
e cativar usuário. 2011. Disponível em: <http://www.ctsbrasil.org/marketingbrt>.
Acesso em: 15 abr. 2013.
FALBO, Ricardo de A. Engenharia de Software. 2005. 146 f. Notas de Aula - Universidade Federal do Espírito Santo. Disponível em :
<http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-2/NotasDeAula.pdf>. Acesso em: 13 dez. 2014.
FANT, Gunnar. Acoustic Theory of Speech Production. Mounton: The Hague, 1960.
FOLDOC. Spiral Model. [1997?]. Disponível em: <http://foldoc.org/spiral+model>. Acesso em: 13 dez. 2014.
GABRIEL, Philipe. Como funciona o GPS?. Oficina da Net, 12 abr. 2014 - 10h30. Disponível em: <http://www.oficinadanet.com.br/post/12406-como-funciona-o-gps>. Acesso em: 13 dez. 2014.
GARMIN. What is GPS?. Disponível em: <http://www8.garmin.com/aboutGPS/>.