sotac mobile – uma ferramenta de telefonia - Informática

UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA
BEATRIZ FRANCO MARTINS
SOTAC MOBILE – UMA FERRAMENTA DE
TELEFONIA MÓVEL PARA COMUNICAÇÃO
COM DEFICIENTES AUDITIVOS
VITÓRIA
OUTUBRO DE 2012
BEATRIZ FRANCO MARTINS
SOTAC MOBILE – UMA FERRAMENTA DE
TELEFONIA MÓVEL PARA COMUNICAÇÃO
COM DEFICIENTES AUDITIVOS
Monografia
apresentada
à
Universidade
Federal do Espírito Santo como requisito
parcial para obtenção do título de Bacharel em
Ciência
da
Computação,
na
área
de
Inteligência Artificial, sob orientação do Prof.
Dr. Orivaldo de Lira Tavares.
VITÓRIA
NOVEMBRO DE 2012
BEATRIZ FRANCO MARTINS
SOTAC MOBILE – UMA FERRAMENTA DE
TELEFONIA MÓVEL PARA COMUNICAÇÃO
COM DEFICIENTES AUDITIVOS
COMISSÃO EXAMINADORA
Prof. Orivaldo de Lira Tavares D.Sc.
Universidade Federal do Espírito Santo
Orientador
Prof. Jadir Eduardo Souza Lucas M.Sc.
Universidade Federal do Espírito Santo
Prof. Luis Cláudius Coradine D.Sc.
Universidade Federal de Alagoas
Prof. Wesley Lucas Breda M.Sc.
Faculdade Católica Salesiana do Espírito Santo
Vitória
12 de novembro de 2012
Agradeço a Deus.
Postumamente a minha querida madrinha
Belinha.
A meus pais pelo incentivo de uma vida toda.
A meu esposo Paulo Sérgio pela compreensão,
apoio e ajuda.
E a meus mestres da UFES.
Declaração dos Universal dos Direitos Humanos
Artigo 1º
Todos os seres humanos nascem livres e iguais em dignidade e em
direitos. Dotados de razão e de consciência, devem agir para uns
com os outros em espírito de fraternidade.
Artigo 2º
Todos os seres humanos podem invocar os direitos e as liberdades
proclamados na presente Declaração, sem distinção alguma,
nomeadamente de raça, de cor, de sexo, de língua, de religião, de
opinião política, de origem nacional ou social, de fortuna, de
nascimento ou de qualquer outra situação.
RESUMO
As novas tecnologias de telefonia celular, que a partir da mudança de
paradigma iniciada pela Apple na criação do iPhone, deram início a criação de
uma infinidade de smartphones e outros recursos, tais quais estão disponíveis
à população em geral a um custo bastante acessível de tal forma que hoje, no
Brasil, há mais celulares que pessoas, de acordo com dados do IBGE. Porém,
para os deficientes auditivos (DA), a realidade do celular limita-se a
comunicação por meio dos popularmente conhecidos torpedos ou por e-mail
para aqueles que possuem internet móvel, já que sua condição especial não os
permite usar todo o potencial das novas tecnologias da telefonia móvel atual.
Este trabalho visa abrir uma nova porta para a comunicação dos DA na
sociedade, permitindo-lhes usar um dispositivo móvel para fazer traduções
automáticas de português para LIBRAS como sendo uma evolução, baseada
no Sistema SOTAC, criado na Universidade Federal do Espírito Santo por
Wesley Lucas Breda e pelo Prof. Dr. Orivaldo Lira Tavares, que teve sua
origem em uma evolução do sistema FALIBRAS-MT.
SUMÁRIO
CAPÍTULO 1 ............................................................................................................................................14
INTRODUÇÃO .........................................................................................................................................14
1.1 Objetivos ..................................................................................................................................15
1.1.1 Objetivos gerais ......................................................................................................................................... 15
1.1.2 Objetivos específicos ................................................................................................................................. 15
1.2 Justificativa ..............................................................................................................................16
1.3 Metodologia............................................................................................................................. 17
1.4 Estrutura da monografia ..........................................................................................................17
1.5 Observações a respeito do texto dissertativo ............................................................................18
CAPÍTULO 2 ............................................................................................................................................19
TECNOLOGIA APLICADA E TRABALHOS CORRELATOS .........................................................................................19
2.1 Tradução Automática ...............................................................................................................19
2.2 FALIBRAS (CORADINE et al., 2002) ............................................................................................ 20
2.3 FALIBRAS-MT(TAVARES; CORADINE; BREDA, 2005) ..................................................................21
2.4 FALIBRAS-TS (CORADINE, 2006) ................................................................................................22
2.5 SOTAC (TAVARES; BREDA, 2008) ...............................................................................................23
2.6 FALIBRAS-WEB (FRANCO; SILVA; BRITO, 2010) .........................................................................24
2.7 Player Rybená ..........................................................................................................................25
2.8 Torpedo Rybená .......................................................................................................................25
2.9 Rybená TV ................................................................................................................................26
CAPÍTULO 3 ............................................................................................................................................28
TECNOLOGIA MÓVEL ................................................................................................................................28
3.1 Breve Histórico .........................................................................................................................28
3.2 Conceitos da telefonia móvel celular ........................................................................................ 31
3.3 Telefonia móvel analógica ........................................................................................................32
3.3.1 Primeira geração (1G) ............................................................................................................................... 32
3.4 Telefonia móvel digital .............................................................................................................33
3.4.1 Segunda geração (2G) ............................................................................................................................... 34
3.4.2 Segunda geração e meio (2,5G) ................................................................................................................ 35
3.4.3 Terceira geração (3G) ................................................................................................................................ 36
3.4.4 Quarta geração (4G) .................................................................................................................................. 37
3.5 Sistemas operacionais para DM ...............................................................................................38
3.5.1 EPOC OS ..................................................................................................................................................... 42
3.5.2 Palm OS ...................................................................................................................................................... 43
3.5.3 Windows Mobile ....................................................................................................................................... 43
3.5.4 Symbian...................................................................................................................................................... 44
3.5.5 Android ...................................................................................................................................................... 45
3.5.6 iOS .............................................................................................................................................................. 46
3.5.7 BlackBarry OS............................................................................................................................................. 47
3.5.8 Bada ........................................................................................................................................................... 48
3.5.9 Meego ........................................................................................................................................................ 48
3.6 Desenvolvimento de Software para DM....................................................................................49
3.6.1 Limitações .................................................................................................................................................. 49
3.6.2 Linguagens de programação ..................................................................................................................... 52
3.6.3 Bancos de dados ........................................................................................................................................ 54
3.6.4 Internet ...................................................................................................................................................... 55
3.7 O futuro da telefonia móvel ......................................................................................................57
CAPÍTULO 4 ............................................................................................................................................59
O SISTEMA SOTAC-MOBILE .....................................................................................................................59
4.1 Requisitos .................................................................................................................................59
4.1.1 Requisitos funcionais ................................................................................................................................. 59
4.1.2 Requisitos técnicos .................................................................................................................................... 60
4.2 Tecnologias avaliadas ..............................................................................................................60
4.2.1 Plataforma Java ......................................................................................................................................... 60
4.2.2 J2EE ............................................................................................................................................................ 63
4.2.3 J2ME ........................................................................................................................................................... 64
4.2.4 Dispositivos série S60 com Symbian ......................................................................................................... 66
4.2.5 Apache Tomcat .......................................................................................................................................... 67
4.2.6 Computação distribuída – RMI ................................................................................................................. 67
4.2.7 Arcademis / RME ....................................................................................................................................... 69
4.2.8 Streaming ................................................................................................................................................... 70
4.2.9 IDE NetBeans ............................................................................................................................................. 71
4.2.10 Astah ........................................................................................................................................................ 71
4.3 Modelagem ..............................................................................................................................72
4.3.1 Arquitetura do SOTAC–Mobile ................................................................................................................. 72
4.3.2 Casos de Uso .............................................................................................................................................. 74
4.3.3 Configurações ............................................................................................................................................ 80
4.3.4 UML ............................................................................................................................................................ 82
4.3.5 Recursos ..................................................................................................................................................... 84
4.4 Implementação ........................................................................................................................ 86
4.4.1 Versões das ferramentas .......................................................................................................................... 86
4.4.2 Plataformas de desenvolvimento ............................................................................................................. 86
4.4.3 Definição das camadas do sistema ........................................................................................................... 88
4.4.4 Streaming e formato dos arquivos de vídeo ............................................................................................ 89
4.4.5 Portabilidade ............................................................................................................................................. 90
4.4.6 Interface ..................................................................................................................................................... 91
4.4.7 Fluxo de desenvolvimento ........................................................................................................................ 95
4.4.8 Codificação................................................................................................................................................. 96
4.4.9 Resultados alcançados ............................................................................................................................ 105
CAPÍTULO 5 .......................................................................................................................................... 106
CONSIDERAÇÕES FINAIS .......................................................................................................................... 106
5.1 Análise de portabilidade ......................................................................................................... 106
5.1.1 Portablidade para dispositivos móveis compativeis com plataforma J2ME ......................................... 106
5.1.2 Portabilidade para dispositivos móveis com Android............................................................................ 107
5.1.3 Portabilidade para dispositivos móveis com Windows Mobile ou Windows Phone ........................... 109
5.1.4 Portablidade para dispositivos móveis BlackBerry ................................................................................ 109
5.1.5 Portabilidade para dispositivos Apple .................................................................................................... 110
5.1.6 Portabilidade para dispositivos de outras plataformas ......................................................................... 110
5.2 Análise de escalabilidade ........................................................................................................ 111
5.2.1 Expansão do SOTAC de forma completa para a web ............................................................................. 111
5.2.2 Melhoramento do SOTAC-Mobile no processo de seleção das Memórias de Tradução ..................... 112
5.2.3 Futura utilização de SOA. ........................................................................................................................ 113
5.2.4 Integração do SOTAC-Mobile com soluções de animação 2D ou 3D .................................................... 114
5.2.5 Futura migração do sistema para HTML5 e WAP .................................................................................. 115
5.3 Conclusão ............................................................................................................................... 116
REFERÊNCIAS ....................................................................................................................................... 117
ANEXO A .............................................................................................................................................. 123
LEI LIBRAS ......................................................................................................................................... 123
LEI Nº 10.436, DE 24 DE ABRIL DE 2002. ................................................................................... 123
ANEXO B .............................................................................................................................................. 125
SISTEMA MÓVEL CELULAR NO BRASIL ........................................................................................................ 125
ANEXO C .............................................................................................................................................. 128
ACESSO AO PROTÓTIPO .......................................................................................................................... 128
ÍNDICE DE FIGURAS
FIGURA 2.1 – PROPOSTA INICIAL DO PROJETO FALIBRAS ....................................................................................21
FIGURA 2.2 - MÓDULO DE TRADUÇÃO DO FALIBRAS-MT (BREDA, 2005, PÁG. 25) ...............................................22
FIGURA 2.3 – MÓDULO DE AUTORIA DE TRADUTORES DO FALIBRAS-MT (BREDA, 2005, PÁG. 26) ...........................22
FIGURA 2.4 – ARQUITETURA DO FALIBRAS-TS.................................................................................................22
FIGURA 2.5 – TRADUTOR DE TEXTOS PARA USUÁRIO PADRÃO SOTAC (BREDA, 2008 PÁG. 75) ..................................23
FIGURA 2.6 - MÓDULO DE INFERÊNCIA GRAMATICAL DO SOTAC (BREDA, 2008, PÁG. 64) .......................................23
FIGURA 2.7 – ARQUITETURA DO FALIBRAS-WEB. ............................................................................................ 24
FIGURA 2.8 – TELA PRINCIPAL DO PLAYER RYBENÁ.............................................................................................. 25
FIGURA 2.9 – TELA DE LOGIN DO TORPEDO RYBENÁ............................................................................................25
FIGURA 2.10 – TELA DA CAIXA DE ENTRADA DO TORPEDO RYBENÁ. ........................................................................26
FIGURA 2.11 – TELAS DE MENSAGEM DO TORPEDO RYBENÁ. ................................................................................26
FIGURA 2.12 – TELA DA PRINCIPAL DO RYBENÁ TV. ............................................................................................ 27
FIGURA 2.13 – TELA DE EXECUÇÃO DO RYBENÁ TV............................................................................................. 27
FIGURA 3.1 – DYNATAC 8000X DA MOTOROLA EM 1983. .................................................................................28
FIGURA 3.2 – EVOLUÇÃO DA TECNOLOGIA DE TELEFONIA MÓVEL NO BRASIL. ............................................................ 30
FIGURA 3.3 – REPRESENTAÇÃO DE UMA REDE AMPS DE TELEFONIA CELULAR. ..........................................................31
FIGURA 3.4 – DISPOSITIVOS 1G (NOKIA MOBIRA CYTYMAN 900 DE 1987, MOTOROLA MICROTAC DE 1989 E STARTAC DE
1996). ............................................................................................................................................33
FIGURA 3.5 – DISPOSITIVOS 2G (MOTOROLA STARTAC DE 1996 E NOKIA 3320 DE 2000). .......................................35
FIGURA 3.6 – DISPOSITIVOS 2,5G (LG CHAMP BX4170 E MOTOROLA RAZR V3 – AMBOS DE 2004). .........................35
FIGURA 3.7 – DISPOSITIVOS 3G (NOKIA 6120C DE 2007 E NOKIA SMARTPHONE E63 DE 2008, MODEM CELULAR DLINK,
APPLE IPHONE WWDC 2009 E IPAD 1 DE 2010). ...................................................................................37
FIGURA 3.8 – DISPOSITIVOS 4G (VODAFONE CONNECT PEN K5005, MOTOROLA TRIUNPH 4G AMBOS LANÇADOS EM JUNHO
E O IPHONE 4G AINDA NÃO LANÇADO NO BRASIL). ..................................................................................... 38
FIGURA 3.9 – CAMADAS DO WAP. .................................................................................................................56
FIGURA 3.10 – DISPOSITIVOS DO FUTURO IDEALIZADOS PELOS DESIGNERS DE DIVERSOS FABRICANTES. ............................ 58
FIGURA 4.1 – CODIFICAÇÃO EM PLATAFORMA JAVA. .........................................................................................61
FIGURA 4.2 – ARQUITETURA DA PLATAFORMA JAVA (ORACLE, 2012). ................................................................62
FIGURA 4.3 – ARQUITETURA DA PLATAFORMA J2EE (ORACLE, 2012). .................................................................63
FIGURA 4.4 – ARQUITETURA DA PLATAFORMA J2ME (ORACLE, 2012). ................................................................65
FIGURA 4.5 – CODIFICAÇÃO EM PLATAFORMA J2ME (ORACLE, 2012). ................................................................65
FIGURA 4.6 – CICLO PADRÃO DE EXECUÇÃO DE UM MIDLET. ................................................................................66
FIGURA 4.7 – CONTÊINER WEB. .....................................................................................................................67
FIGURA 4.8 – ARQUITETURA RMI. .................................................................................................................68
FIGURA 4.9 – ARQUITETURA DO SISTEMA SOTAC – MOBILE. ...............................................................................72
FIGURA 4.10 – INTERFACE ENTRE AS APLICAÇÕES DO SOTAC-MOBILE. ...................................................................73
FIGURA 4.11 – CASOS DE USO DO MIDLET SOTAC – MOBILE..............................................................................74
FIGURA 4.12 – CASOS DE USO DO SERVLET SOTAC – EMOBILE. .........................................................................78
FIGURA 4.13 – PERFIL PARA O SOTAC – MOBILE. NO SOTAC. ............................................................................81
FIGURA 4.14 – DIAGRAMA DE CLASSES DO MIDLET SOTAC – MOBILE. .................................................................82
FIGURA 4.15 – DIAGRAMA DE CLASSES DO SERVLET SOTAC – EMOBILE. ..............................................................83
FIGURA 4.16 – DIAGRAMA DE CLASSES DA TRADUÇÃO DO SOTAC.........................................................................83
FIGURA 4.17 – CAMADAS DO SISTEMA SOTAC-MOBILE......................................................................................88
FIGURA 4.18 – TELAS DE ABERTURA E PRINCIPAL DO SOTAC–MOBILE OBTIDAS VIA EMULADOR. ..................................91
FIGURA 4.19 – MENU PRINCIPAL E TRADUÇÃO NO SOTAC–MOBILE OBTIDAS VIA EMULADOR. .....................................92
FIGURA 4.20 – TELA DE ESPERA E EXIBIÇÃO DE VÍDEOS NO SOTAC–MOBILE OBTIDAS VIA EMULADOR. ...........................92
FIGURA 4.21 – SERVIÇO REMOTO SERVLET SOTAC –EMOBILE EM EXECUÇÃO NO SERVIDOR ......................................93
FIGURA 4.22 – TELA DE ACESSO AO SERVLET SOTAC –WMOBILE OBTIDA VIA BROWSER IE. ......................................94
FIGURA 4.23 – TELA DE TRADUÇÕES DO SERVLET SOTAC –WMOBILE OBTIDA VIA BROWSER IE..................................94
FIGURA 4.24 – TELA DE RESULTADO NO SERVLET SOTAC –WMOBILE OBTIDA VIA BROWSER IE. .................................95
FIGURA 4.25 – FLUXO DE DESENVOLVIMENTO DO SOTAC – MOBILE. ....................................................................95
FIGURA 5.1 – NOKIA S40 ASHA 311 E LG C205 PODEM EXECUTAR O MIDLET SOTAC – MOBILE. ............................ 107
FIGURA 5.2 – EXEMPLO DE NOVAS POSSÍVEIS CAMADAS PARA O SOTAC-MOBILE. ................................................... 108
FIGURA B.1 – PRESENÇA DAS PRESTADORAS DE TELEFONIA MÓVEL (ANATEL, 23/06/2009). .................................. 126
ÍNDICE DE TABELAS
TABELA 2.1 – PLATAFORMAS ACEITAS PELO TORPEDO RYBENÁ. .............................................................................26
TABELA 3.1 – EVOLUÇÃO DOS PRINCIPAIS SISTEMAS OPERACIONAIS PARA DISPOSITIVOS MÓVEIS. ...................................41
TABELA B.1 – EVOLUÇÃO DA TELEFONIA MÓVEL NO BRASIL. ............................................................................... 125
TABELA B.2 – TECNOLOGIAS NÃO USADAS NO BRASIL. ....................................................................................... 125
TABELA B.3 – O FUTURO DA TELEFONIA MÓVEL NO BRASIL. ................................................................................ 125
TABELA B.4 – EVOLUÇÃO DO NÚMERO DE TERMINAIS HABILITADOS NO SMC NO BRASIL (ANATEL, 2011). ................. 127
ÍNDICE DE GRÁFICOS
GRÁFICO 3.1 – DIVISÃO DO MERCADO DE SMARTPHONES NO BRASIL (GARTNER, 2010). ............................................41
GRÁFICO B.1 - EVOLUÇÃO DO NÚMERO DE TERMINAIS HABILITADOS NO SMC NO BRASIL (ANATEL, 2011). ................ 127
P á g i n a | 14
Capítulo 1
Introdução
De acordo com Breda (2005), os deficientes auditivos (DA) não são
contemplados com muitos recursos de acesso às informações,
principalmente nos que se referem ao aprendizado. Alguns aparatos
legais foram criados para suprir algumas necessidades básicas
dessas pessoas, mas pouco foi feito para levar esses aparatos a elas.
Uma criança DA que estuda em uma escola de alfabetização tem o
direito a um intérprete para acompanhamento, mas as escolas
relutam em aceitar esse tipo de aluno devido ao custo e a dificuldade
de manter intérpretes.
A Lei LIBRAS nº 10.436 de 22 de abril de 2002 veio oficializar a Linguagem
Brasileira de Sinais como a língua oficial dos DA no país. De fato no contexto
DA nacional, esta lei é muito importante, quando consideramos as dimensões
territoriais do nosso país, no sentido de mantermos um único idioma materno,
tanto no nível do Português quanto no nível de LIBRAS. Assim se abriram
inúmeras possibilidades para a inclusão social dos DA, tanto por meio de
cursos de LIBRAS, que estão disponíveis tanto para DA quanto para ouvintes
que querem estar abertos a essa língua, como por meio de ferramentas
multimídia que foram e estão sendo implementadas e aprimoradas para fins de
inclusão digital.
Vários são os projetos e ferramentas disponíveis, e mais recentemente foi
desenvolvido o Projeto SOTAC baseado no Sistema FALIBRAS-MT, cujo
principal objetivo é fazer a tradução automática de textos de uma linguagem
fonte (LF) para uma linguagem alvo (LA), sendo como estudo de caso o uso de
Português como LF e LIBRAS como LA. Destes projetos surgiu a evolução
FALIBRAS-WEB desenvolvido na Universidade Federal de Alagoas, que traz
para o ambiente da internet o projeto FALIBRAS-MT e SOTAC.
Este trabalho apresenta-se como uma solução móvel para o FALIBRAS-WEB,
SOTAC e FALIBRAS-MT, que deve estar disponível nos dispositivos de
telefonia móvel de mercado para em um primeiro momento fazer tradução de
P á g i n a | 15
Português no formato texto (LA) para LIBRAS (LF) em formato de sinais
(vídeos). Da mesma maneira que o SOTAC este trabalho não está
especificamente direcionado a estas linguagens, podendo ser direcionados
para quaisquer linguagens fonte e alvo. Chamaremos este sistema de SOTAC–
Mobile.
1.1 Objetivos
O objetivo deste trabalho é apresentar uma proposta de um sistema para
ambiente de telefonia móvel para complementar o projeto FALIBRAS a nível de
tradução automática de Português para LIBRAS dando mais liberdade na
comunicação dos DA.
1.1.1 Objetivos gerais
Projetar e desenvolver o sistema SOTAC–Mobile, que tem como finalidade
disponibilizar as funcionalidades até então desenvolvidas a nível desktop pelos
módulos FALIBRAS-MT e SOTAC e na web pelo FALIBRAS-WEB em
ambiente de telefonia celular, permitindo aos usuários DA, a real possibilidade
de inclusão social e digital.
1.1.2 Objetivos específicos
O sistema tem como proposta inicial, apenas a tradução da língua fonte o
Português, texto escrito no dispositivo móvel, para a língua alvo, vídeo
mostrado na tela do dispositivo móvel. Fica para uma adição posterior a
tradução do áudio (voz) para a linguagem texto em Português, que constitui a
primeira etapa de tradução do projeto FALIBRAS.
Não são abordadas questões relacionadas à edição dos dicionários, nem de
configurações de perfil usuário. Isso significa dizer que o sistema está sempre
funcionando com usuário único e no perfil de usuário móvel, não havendo
acesso
administrativo
nem
de
colaboradores
ou
usuários
padrão,
diferentemente do que ocorre no SOTAC. O usuário móvel tem as mesmas
funções do usuário padrão do SOTAC, mas para sua identificação é automática
P á g i n a | 16
e genérica e não é permitido a alteração de sua senha. A finalidade desta
opção é tornar o sistema o mais simples e leve possível, permitindo-o ser
executado em diferentes plataformas móveis de forma eficiente, já que as
mesmas possuem limitação de processamento e memória, em oposição ao que
ocorre nos computadores pessoais.
1.2 Justificativa
Desde a mudança de paradigma ocorrida com o advento da terceira geração
da telefonia móvel, conhecida popularmente como tecnologia 3G, a telefonia
celular vem sofrendo uma evolução rápida e avassaladora. Surgiram então
vários novos dispositivos conhecidos como smartphones, mas o lançamento do
iPhone pela Apple, é o real divisor de águas que transformou os aparelhos de
telefonia móvel em verdadeiros equipamentos multimídia, deixando para traz o
simples telefone para comunicação de voz.
Atualmente há mais telefones móveis no Brasil, do que pessoas. Segundo
dados do IBGE (Instituto Brasileiro de Geografia e Estatística) e da ANATEL
(Agência Nacional de Telecomunicações). Ao final de 2010 havia no país
202,94 milhões de telefones celulares, com crescimento de 16,66% em relação
a 2009. Isso equivale a 104,68 aparelhos para cada 100 habitantes. Em um
país com 185,71 milhões de habitantes (segundo o censo 2010), dos quais 5,7
milhões (segundo o censo 2000 – censo 2010 ainda em processamento) são
deficientes auditivos totais ou parciais, vemos que essas pessoas tornaram-se
uma classe de excluídos.
Neste cenário, para os deficientes auditivos (DA), a tecnologia de telefonia
móvel 3G permitiu uma nova forma de comunicação por meio de SMS (Short
Message Service), ou torpedos como são popularmente conhecidos. Porém
esta tecnologia limita-se a certas condições e não facilita a vida dos DA, afinal
seu idioma natural é LIBRAS e não o Português, que para eles é um segundo
idioma. O sistema SOTAC-Mobile, vem ocupar esta lacuna. Apesar da
proposta inicial não contemplar o uso do áudio, a possibilidade de tradução em
plataforma móvel, abre as portas para uma nova visão do projeto FALIBRAS.
P á g i n a | 17
1.3 Metodologia
Devido à vasta gama de plataformas móveis atualmente existentes, foi feito
uma pesquisa dos principais ambientes de desenvolvimento móvel por meio de
fontes como livros, artigos e internet. Desta forma optou-se pela linguagem de
programação Java (J2ME), pois é aceita pela maioria das plataformas. Para o
desenvolvimento optou-se pelo uso de uma das IDEs disponíves, de modo a
organizar melhor o desenvolvimento. A este tipo de ferramenta podem ser
adicionados vários SDKs para desenvolvimento nas várias plataformas móveis.
Cada plataforma tem suas peculiaridades e cada uma é indicada para uma
determinada marca e modelo de dispositivo móvel, isso varia de fabricante para
fabricante. Há outras particularidades no desenvolvimento para dispositivos
móveis, que estão relacionadas à banda de rede e ao sistema usados. Assim
preferimos restringir num primeiro momento o desenvolvimento para aparelhos
Nokia série S60 terceira edição (S60_3rd_Edition_SDK_Feature_Pack_2_v1_1
for Nokia devices), que incluem os modelos E62, E63 dentre outros, e utiliza o
sistema Symbian. do mesmo fabricante.
1.4 Estrutura da monografia
Capítulo 1 – Apresenta a proposta de trabalho, objetivos, justificativa e
metodologia.
Capítulo 2 – Faz uma breve análise da tradução automática e um histórico dos
projetos correlatos (Player Rybená, TLibras, FALIBRAS, FALIBRAS-TS,
FALIBRAS-MT, FALIBRAS-WEB e SOTAC).
Capítulo 3 – Trata da tecnologia móvel, histórico, evolução com vistas mais
especificamente à telefonia móvel celular no Brasil.
Capítulo 4 – Apresenta o projeto, a análise e a implementação do sistema
SOTAC – Mobile.
Capítulo 5 – Apresenta as considerações finais e as perspectivas futuras.
P á g i n a | 18
Anexo A – Lei nº 10.436/2002.
Anexo B – Sistema móvel celular no Brasil.
Anexo C – Informações de acesso ao protótipo.
1.5 Observações a respeito do texto dissertativo
No texto desta monografia são usados termos e palavras, que são jargões dos
profissionais das áreas de Tecnologia da Informação e Telecomunicações, os
quais possuem significados diferentes dos existentes e fixados pelos
dicionários da Lingua Portuguesa.
Também são usadas diversas siglas das áreas de Tecnologia da Informação e
Telecomunicações, cuja origem estão no Inglês, e tem seus significados
traduzidos ou explicados no decorrer do texto.
Neste trabalho é utilizado o Novo Acordo Ortográfico da Língua Portuguesa,
promulgado pelo Ex-presidente Luiz Inácio Lula da Silva no dia 29 de setembro
de 2008, e composto pelos Decretos Nº 6.583, Nº 6.584, Nº 6.585 e Nº 6.586.
P á g i n a | 19
Capítulo 2
Tecnologia aplicada e trabalhos correlatos
Neste capítulo falaremos brevemente sobre a tecnologia usada na tradução
automática, e os trabalhos relacionados à proposta deste projeto.
2.1 Tradução Automática
A tradução automática (TA) é o processo automático de tradução de um idioma
original para outro idioma alvo, através do computador.
A TA não é nada simples, muito pelo contrário. As línguas humanas consistem
em morfologia (modo como as palavras são montadas), sintaxe (estrutura da
frase) e semântica (sentido que se quer expor). Nesse cenário qualquer texto
simples pode estar cheio de ambiguidades.
Segundo Nirenburg (1987), a tradução automática teria sido a primeira
aplicação não numérica proposta dentro da nova área da ciência da
computação, instigada pela explosão da transmissão de informações e
pela relativa facilidade (segundo erroneamente se imaginava) de se
calcar o processo computacional em uma técnica humana
aparentemente simples.
Os aplicativos de auxílio à tradução podem ser encaixados em duas categorias:
os sistemas de tradução por computador, ou tradução automática:

MT (Machine Translation systems), são aqueles capazes de realizar o
processo tradutório completo, mas pode não excluir pré e/ou pós edição
humana.

MAT (Machine-Aided Translation systems) - são os sistemas automáticos
de auxílio à tradução. Estes subdividem-se em sistemas de tradução
automática assistida por humanos (HAMT - Human-Aided Machine
Translation) ou de tradução humana assistida por computador (MAHT Machine-Aided Human Translation), segundo quem realiza as tarefas
centrais e quem presta auxílio de forma mais secundária.
P á g i n a | 20
Existem determinados métodos
sistemas de tradução automática.
pares delas: tradução direta vs.
transferência e análise local vs.
Tucker, A. 1987).
que caracterizam os diferentes
Em geral faz-se referência a três
tradução indireta, interlíngua vs.
análise global (Slocum, J. 1985;
Há também dois paradigmas que subdividem os sistemas que usam os métodos
acima citados. O paradigma fundamental corresponde aos sistemas baseados
em conhecimento profundo, fundamental ou linguístico, enquanto o paradigma
empírico agrupa os sistemas que se baseiam em conhecimento superficial ou
empírico.
Tais métodos e paradigmas podem misturar e combinar-se de várias maneiras
diferentes. De forma geral a TA, tem se tornado cada vez mais uma tarefa
multidisciplinar, levando à Ciência da Computação uma busca constante de
soluções para atender as diversas necessidades da sociedade.
Atualmente estão sendo feitos vários estudos de caso de tradução automática
utilizando o Português como língua fonte e LIBRAS como língua alvo, para
melhorar a inclusão social e digital dos DA, como veremos a seguir.
2.2 FALIBRAS (CORADINE et al., 2002)
Com a finalidade de melhorar a inclusão social e digital dos DA foi criado na
Universidade Federal de Alagoas (UFAL), com o apoio do CNPq e da Fundação
de Amparo à Pesquisa do Estado de Alagoas (FAPEAL), o projeto FALIBRAS.
O projeto FALIBRAS tem como inicial principal objetivo, desenvolver um sistema
de tradução automática de Português (falado) para LIBRAS (em gestos). Para
tanto, o áudio em Português é captado pelo microfone e sofre a tradução, de
modo a ser apresentado em LIBRAS e em tempo real por meio de uma
sequência de vídeos.
P á g i n a | 21
ÁUDIO CAPTURADO
PELOS PERIFÉRICOS
TRADUÇÃO
TEXTO
FONTE
TRADUÇÃO
Processo
Cliente
Figura 2.1 – Proposta inicial do projeto FALIBRAS
O FALIBRAS é baseado em tecnologias de estruturas de dados, bancos de
dados e de animações e está dividido em etapas. Na primeira etapa o áudio
captado é convertida em texto usando recursos do IBM ViaVoice. Em seguida o
texto é analisado por um interpretador que corrige a ortografia do texto e define o
contexto em que as palavras estão inseridas na frase. Posteriormente o sistema
faz a tradução e executa as animações correspondentes ao que foi dito.
O
FALIBRAS
foi
projetado
para
utilizar
Java
como
ferramenta
de
desenvolvimento, pois é multiplataforma, orientada a objetos e perfeitamente
compatível com o IBM ViaVoice, MySQL como banco de dados por ser gratuito,
o JSpell como corretor ortográfico e para as animações foi usado o Macromedia
Flash, que atualmente foi comprado pela Adobe, porque gera dados que ocupam
pouco espaço.
A partir do projeto FALIBRAS descrito no item acima, surgiram várias iniciativas
para sua evolução, como veremos a seguir.
2.3 FALIBRAS-MT(TAVARES; CORADINE; BREDA, 2005)
Segundo Breda (2005), o sistema FALIBRAS-MT é constituído pelos
módulos de tradução e de autoria de tradutores. O módulo de tradução
disponibiliza um ambiente que contém todas as funcionalidades
necessárias para estabelecer traduções usando memórias de tradução,
[apresentado na Figura 2.2]. O módulo de autoria de tradutores
disponibiliza um ambiente contendo todas as funcionalidades
necessárias para que os usuários possam atuar diretamente nas
memórias de tradução, [como apresentado na Figura 2.3].
P á g i n a | 22
TEXTO
FONTE
TRADUÇÃO
VÍDEOS
Figura 2.2 - Módulo de tradução do FALIBRAS-MT (BREDA, 2005, pág. 25)
TEXTO
FONTE
TRADUÇÃO
TEXTO
PARCIAL
DICIONÁRIO
SÍMBOLOS
TRADUÇÃO
VÍDEOS
DICIONÁRIO
VÍDEOS
MEMÓRIA DE TRADUÇÃO
Figura 2.3 – Módulo de autoria de tradutores do FALIBRAS-MT (BREDA, 2005, pág. 26)
2.4 FALIBRAS-TS (CORADINE, 2006)
O FALIBRAS-TS foi desenvolvido como sendo uma interface tradutora baseada
em sintaxe, que utiliza técnicas baseadas no processamento de linguagem
natural, com gramáticas, usadas para processar expressões.
ANALISADOR LÉXICO
E SINTÁTICO
ÁUDIO CAPTURADO
PELOS PERIFÉRICOS
TRADUÇÃO
RECONHECEDOR
DE FALA
TEXTO
FONTE
TRADUÇÃO
VÍDEOS
DICIONÁRIO
VÍDEOS
Figura 2.4 – Arquitetura do FALIBRAS-TS.
A primeira versão do FALIBRAS-TS está implementada em PROLOG e em
Java. Uma segunda versão, baseada em componentes orientados a objetos,
está implementada em C++ (CALADO, 2006), usa tratamento de ambiguidade e
transferência sintática (RIBEIRO, 2007).
P á g i n a | 23
2.5 SOTAC (TAVARES; BREDA, 2008)
Segundo Breda (2008), o SOTAC é um ambiente para autoria e o uso
de tradutores automatizados, sendo, baseado na utilização de memória
de tradução e regras de tradução, derivadas de inferência gramatical,
sobre os exemplos da memória de tradução. A interface desse
ambiente está contextualizada na tradução de Português (texto) para
LIBRAS sinalizada (vídeos), tendo como produto parcial da tradução a
LIBRAS escrita (texto). No entanto, os algoritmos e os mecanismos de
tradução, utilizados pelo ambiente, estão generalizados de qualquer
língua-fonte escrita (textos) para qualquer língua-alvo falada (áudio)
e/ou sinalizada (vídeos), tendo como produto parcial da tradução a
língua-alvo escrita (textos).
Figura 2.5 – Tradutor de textos para usuário padrão SOTAC (BREDA, 2008 pág. 75)
A arquitetura do SOTAC é totalmente baseada na arquitetura do FALIBRAS-MT,
tendo sido adicionado a este o módulo de inferência gramatical.
MEMÓRIA DE
TRADUÇÃO
INFERÊNCIA
GRAMÁTICA
Figura 2.6 - Módulo de inferência gramatical do SOTAC (BREDA, 2008, pág. 64)
O SOTAC foi desenvolvido em linguagem C# (C Sharp) em ambiente
SharpDevelop 2.2.0.2595, e usou banco de dados PostgreSQL 1.4.3.
P á g i n a | 24
2.6 FALIBRAS-WEB (FRANCO; SILVA; BRITO, 2010)
O FALIBRAS-WEB foi desenvolvido na Universidade Federal de Alagoas, para
estender ao ambiente da internet o FALIBRAS, permitindo aos DA uma real
inclusão digital. O sistema tem a finalidade de executar a tradução de
documentos on-line a fim de proporcionar autonomia aos DA no ambiente da
internet. Para tanto foi desenvolvido um add-on para o browser Firefox, e a
concepção da interface gráfica adaptada às necessidades do público alvo.
TEXTO SOLICITADO
ADD-ON
INTERFACE
(XUL)
TEXTO EM UM TIPO JAVA
COMUNICAÇÃO
(JAVASCRIPT)
ADEQUAÇÃO DO GIF PARA XUL
TRADUTOR
FALIBRAS
GIF (CONJUNTO DE ANIMAÇÕES) COM A
TRADUÇÃO
Figura 2.7 – Arquitetura do FALIBRAS-WEB.
Foi utilizado o XUL, uma linguagem baseada em XML, para o desenvolvimento
da interface e para adicionar os elementos necessários ao Firefox. O JavaScript
foi usado para o desenvolvimento das funções de comunicação do sistema com
ao módulos do FALIBRAS.
P á g i n a | 25
2.7 Player Rybená
Rybená, significa comunicação, no idioma indígena Xavante. O Player Rybená
foi desenvolvido para tradução textos escritos ou de páginas web de Português
para LIBRAS.
Figura 2.8 – Tela principal do Player Rybená.
2.8 Torpedo Rybená
A partir do Player Rybená, em 2005 surgiu o Torpedo Rybená, que envia e
recebe mensagens no formato texto via SMS convertidas para LIBRAS.
Atualmente o software é de distribuição gratuita, mas funciona em um conjunto
limitado de aparelhos e é oferecido pela Brasil Telecom GSM, sendo cobrada
uma tarifa de R$0,26 (valor da época) por mensagem e conexão GPRS.
Figura 2.9 – Tela de login do Torpedo Rybená.
P á g i n a | 26
Figura 2.10 – Tela da caixa de entrada do Torpedo Rybená.
Figura 2.11 – Telas de mensagem do Torpedo Rybená.
A seguir os dispositivos compatíveis com o Torpedo Rybená.
Marca
Siemens
Nokia
Dispositivos móveis
Séries / Modelos
CX65, M65
6600, 3660
Tabela 2.1 – Plataformas aceitas pelo Torpedo Rybená.
O software pode ser baixado via site WAP (Wireless Application Protocol) da
Brasil Telecom GSM
2.9 Rybená TV
Recentemente surgiu também o Rybená TV, também como extensão do Rybená
Player, que permite aos DA terem acesso à TV digital por meio de LIBRAS
P á g i n a | 27
usando a tecla Close Captions padrão dos aparelhos de TV digitais. Porém esta
proposta se deparou com diversos problemas em relação a tradução em tempo
real bem como a obtenção dos textos em Close Captions.
A seguir estão mostradas as principais telas do sistema Rybená TV.
Figura 2.12 – Tela da principal do Rybená TV.
Figura 2.13 – Tela de execução do Rybená TV.
Para a implementação foi escolhido o Java EE, com biblioteca Java AWT para a
camada de visualização, e o banco de dados HSQLDB da Sun.
P á g i n a | 28
Capítulo 3
Tecnologia móvel
Neste capítulo falaremos sobre a tecnologia móvel, mais especificamente a
telefonia móvel celular no Brasil.
3.1 Breve Histórico
Várias empresas fizeram testes entre o ano de 1947 e 1973, mas foi a
Motorola, que criou o primeiro protótipo de aparelho de telefonia celular
realmente portátil, o DynaTAC (Dynamic Adaptative Total Area Coverage).
Já no Brasil, a primeira tentativa de introdução da Telefonia móvel ocorreu em
1972, com um sistema de baixa capacidade anterior à tecnologia celular, com
tecnologia IMTS (Improved Mobile Telephone System), em Brasília com
apenas 150 terminais habilitados.
O Japão ativou seu sistema de telefonia celular em 1978 seguido pela Suécia
em 1981, ambos com tecnologias próprias.
Em 1983, o primeiro modelo liberado comercialmente pela FCC (Federal
Comunication Comission) foi o DynaTAC 8000x, e por U$3.995,00 estava
disponível somente nos Estados Unidos.
Figura 3.1 – DynaTAC 8000x da Motorola em 1983.
P á g i n a | 29
O DynaTAC pesava 800 gramas, media 25 centímetros de comprimento por 3
centímetros de largura, tendo um comprimento de 7 centímetros e possuía uma
bateria que acabava em 20 minutos de conversação. Até então os aparelhos
celulares pesavam mais de 1 kilograma e eram enormes, geralmente sendo
acoplados em carros.
Em 1984 foi criado pela Bell Labs, nos Estados Unidos o padrão analógico
AMPS (Advanced Mobile Phone System) de primeira geração (1G). Este
padrão foi implantado em diversos países do continente Americano, da Ásia e
Austrália.
A partir daí, no início década de 90 os fabricantes já tinham condições
tecnológicas de lançar aparelhos de telefonia celular com um tamanho mais
aceitável, com um peso adequado e com baterias de duração mais prolongada.
O Sistema Móvel Celular (SMC) brasileiro foi inaugurado, usando o padrão
AMPS e banda A, oficialmente em 30 de dezembro de 1990, no Rio de Janeiro
com capacidade para 10 mil terminais. Nesta ocasião o país contava com 667
aparelhos. No ano (1991) seguinte passou a contar com 6.700 aparelhos e em
1992 ultrapassou a marca de 30 mil unidades. Em 1997 começou a operar o
primeiro serviço celular digital da banda B, em Brasília. Veja a evolução
quantitativa do SMC no Brasil, no gráfico B.1 do Anexo B.
O fator determinante para o crescimento do SMC no país foi a privatização, que
fez com que as antigas estatais e as novas empresas investissem no setor, de
modo a manter as vantagens competitivas. Assim houve um aumento na oferta
de serviços e redução de preços, em uma busca desenfreada para absorver o
novo mercado.
Em 2001, a ANATEL (Agencia Nacional de Telecomunicações) lançou novas
regras para a exploração do sistema de telefonia móvel no país, que foram
descritas no regulamento do SMP (Sistema de Telefonia Pessoal), propondo
uma simplificação nas áreas de atuação do mercado, leilão de novas licenças
para exploração das bandas D e E. As empresas que operavam segundo as
P á g i n a | 30
regras do SMC, foram incentivadas a migrar para o novo regulamento (vide a
figura B.1 do Anexo B sobre a situação atual).
Para melhor compreensão da telefonia móvel, faremos mais a frente uma
exposição sobre a sua evolução tecnológica que se subdividiu em Tecnologia
Analógica e a Tecnologia Digital, e no convencionou-se chamar de gerações.
No mundo, a geração mais nova é a 4G (quarta geração) já amplamente
difundida em alguns países como Japão e países da EU (União Europeia) tais
como Suécia e Noruega. No Brasil a 4G deverá estar disponível antes de 2014
nas principais capitais, impulsionada pela vinda da Copa do Mundo em julho
desse mesmo ano.
1G
2G
2,5G
3G
CDMA2000x1 EVDO
CDMA
CDMA2000x1
CDMA2000x1 EVDV
AMPS
TDMA
WCDMA
GSM
GPRS / EDGE
HSDPA
SISTEMA
ANALÓGICO
SISTEMA
DIGITAL
Figura 3.2 – Evolução da tecnologia de telefonia móvel no Brasil.
Passados 20 anos desde o início da telefonia móvel comercial, o conceito
procurado pelos consumidores mudou. O celular tornou-se muito mais do que
um telefone para comunicação de voz, hoje é um aparelho multimídia e
multifuncional que está ao alcance de todos, e com preços variando de
R$90,00 a R$2.500,00, com uma diversa gama de opções de serviço.
P á g i n a | 31
3.2 Conceitos da telefonia móvel celular
O conceito de telefonia móvel celular pode ser definido basicamente como; um
transmissor de baixa potência que atua em uma determinada área geográfica
(célula) e fornece cobertura sob frequências que podem ser reutilizadas por
células adjacentes. Cada célula é composta por uma torre de transmissão, uma
estação de rádio frequência que são denominadas Estações Rádio Base
(ERB). Abaixo o exemplo de uma área de cobertura celular.
CCC
ERB
ERB
ERB
ERB
ERB
ERB
ERB
ERB
ERB
EM
ERB
ERB
ERB
ERB
ERB
ERB
ERB
CCC
ERB
ERB
ERB
ERB
Figura 3.3 – Representação de uma rede AMPS de telefonia celular.
Usamos hexágonos para a representação das células, para facilitar o
entendimento, apesar da sua delimitação física não ser exatamente essa.
Estas ERB ficam conectadas a um Centro de Comutação e Controle (CCC). Os
CCC ficam conectados uns aos outros e ao resto da rede. Quando uma
Estação Móvel (EM) está ao alcance de uma ERB, esta faz todas as
verificações e mantém a EM em serviço. As ERB também fazem a função de
handoff, que é a passagem das EM de uma célula para outra, bem como a
função de roaming (itinerância) que é a capacidade das EM estarem em
serviço mesmo fora do local onde estão cadastradas.
P á g i n a | 32
3.3 Telefonia móvel analógica
A telefonia móvel analógica é marcada pela transmissão unicamente de voz,
que é modulada e transmitida. Na recepção, o processo inverso ocorre ou seja
o sinal é recebido e demodulado de modo a obter-se o sinal de voz novamente.
As primeiras tentativas analógicas foram usando sistemas half duplex
chamados Push-to-talk onde era necessário apertar um botão para a
transmissão do áudio.
O sistema analógico não suportava criptografia, portanto era basicamente
inseguro, além da qualidade do áudio não ser boa e ainda tinha baixa taxa de
transmissão.
3.3.1 Primeira geração (1G)
A primeira geração de telefonia móvel funcionava para apenas o serviço de
transmissão de voz. As principais tecnologias utilizadas nesta geração foram:

IMTS (Improved Mobile Telephone System);

AMPS (Advanced Mobile Phone System).
Também houve outras tecnologias menos conhecidas e usadas em outros
países: TACS, ETACS, NMT450, NMT900, C-450, RTMS, RADIOCOM2000,
NIT, JTACS/NTACS. No Brasil a única tecnologia de primeira geração aplicada
à telefonia celular foi o AMPS.
Os aparelhos celulares da época eram ainda muito volumosos e seus visores
eram apenas numéricos. A bateria era grande e com performance insuficiente.
No Brasil, ficaram popularmente conhecidos como “tijolões”, pois eram grandes
e pesados.
A exemplo dos modelos mostrados abaixo que pesavam 800g, 300g e
respectivamente. Foi na verdade a Motorola que ao lançar o StarTAC em 1996,
P á g i n a | 33
primeiro celular com “flip” (dobra em Português), mudou o conceito de
ergonomia do celular.
.
Figura 3.4 – Dispositivos 1G (Nokia Mobira Cytyman 900 de 1987, Motorola MicroTAC de 1989 e StarTAC de 1996).
3.4 Telefonia móvel digital
No processo de transmissão nestes sistemas, o sinal de voz é digitalizado e em
seguida é feita a adição dos bits de redundância para permitir a correção de
erros. Depois é adicionado um conjunto de bits para controle de comunicação
(tais como palavras de alinhamento e sincronização e etc.). Tudo isso gera um
aumento da taxa de transmissão. Na sequência ocorre o processamento da
faixa espectral e do sinal para a posterior modularização e transmissão.
Na recepção, ocorre a operação inversa, e a operação final consiste em
descartar os bits adicionais de redundância e controle e transformar o sinal
digital de voz novamente em sinal analógico.
A maior vantagem na transmissão digital está no fato de possuir um melhor
desempenho em ambientes difíceis, pois faz uso de recursos para correção de
erros. Há outras várias vantagens na comunicação digital, dentre elas:

melhoria na eficiência espectral;

rejeição à interferência;

sensibilidade.
P á g i n a | 34
A transmissão digital também tem dificuldades e um dos problemas mais
críticos que podem afetar a comunicação digital é o efeito multipercurso.
Quando a trajetória do sinal percorre vários caminhos de comprimentos
desiguais. Este efeito piora na proporção em que aumenta a taxa de
transmissão e quanto maior for o diâmetro da célula.
A telefonia digital produziu as gerações subsequentes da telefonia móvel
celular.
3.4.1 Segunda geração (2G)
A segunda geração de telefonia móvel caracterizou-se pela possibilidade de
transmissão não apenas de voz, mas também permitia a transmissão de dados
numéricos de pequeno volume. Surgiu o SMS (Short Message Service),
popularmente conhecido como torpedo.
As principais tecnologias utilizadas no Brasil nesta geração foram:

CDMA (Code Division Multiple Access);

TDMA ou D-AMPS (Time Division Multiple Access);

GSM (Group Special Mobile).
Também houve outras tecnologias menos conhecidas e usadas em outros
países: N-AMPS, E-TDMA e outras.
Os aparelhos celulares 2G eram bem mais ergonômicos e seus visores apesar
de ainda ser monocromáticos já forneciam recursos de menu com ícones. A
bateria ainda possuía certa limitação de uso, mas já não era mais necessário
que o usuário carregasse uma bateria sobressalente. Também passaram a
possuir outras funções como agenda eletrônica, toques variados, jogos e
outras.
P á g i n a | 35
Figura 3.5 – Dispositivos 2G (Motorola StarTAC de 1996 e Nokia 3320 de 2000).
3.4.2 Segunda geração e meio (2,5G)
Caracteriza-se pelo conjunto de tecnologias que possuem características
híbridas, ou seja características da segunda geração bem como da terceira
geração, assim devido a dificuldade em estabelecer uma posição, criou-se esta
denominação 2,5G. Esta geração ficou marcada pela transmissão de dados
numéricos de volume moderado, além da tradicional transmissão de voz.
As principais tecnologias utilizadas nesta geração foram:

CDMA2000x1 (Code Division Multiple Access 2000 One Time Radio
Transmission Technology);

GPRS (General Packet Radio System) / EDGE (Enhanced Data Rates
for Global Evolution).
Os aparelhos celulares 2,5G ganharam nova roupagem, toques polifônicos e
telas coloridas que no início possuíam 16 cores e chegaram a 65 mil cores o
que permitiu a instalação de câmeras fotográficas embutidas e mensagens
MMS (Multimedia Message Service).
Figura 3.6 – Dispositivos 2,5G (LG Champ BX4170 e Motorola RAZR V3 – ambos de 2004).
P á g i n a | 36
3.4.3 Terceira geração (3G)
A terceira geração de telefonia móvel caracterizou-se pela possibilidade de
transmissão não apenas de voz e dados de maior volume, mas também
permitia uma nova gama de serviços que vão desde suporte multimídia para
áudio MP3, vídeo, TV, até a conexão de internet banda larga com velocidades
razoáveis, para permitir um uso bastante funcional de correio eletrônico,
serviços WWW (World Wide Web), vídeo chamada e até GPS (Global
Positioning System).
As principais tecnologias utilizadas nesta geração foram:

CDMA2000x1 EVDO (Code Division Multiple Access 2000 One Time
Evolution Data Only);

CDMA2000x1 EVDV (Code Division Multiple Access 2000 One Time
Evolution Data/Voice);

WCDMA (Wideband Code Division Multiple Access);

HSDPA (High-Speed Downlink Packet Access).

Também houve outras tecnologias menos conhecidas e usadas em
outros países: UMTS.
A geração 3G proporcionou o desenvolvimento de várias novas tecnologias, a
exemplo do WAP (Wireless Application Protocol), que são páginas próprias
para celular criadas pelos portais.
Nesta ocasião surgiram os smartphones, celulares com funcionalidades
avançadas e com sistemas operacionais que aceitam instalação de diversos
softwares; os modens celulares para as conexões de internet 3G e os celulares
touch pad com tela sensível ao toque e mais recentemente o multitouch que
permite ao usuário manipular o dispositivo com vários dedos simultaneamente.
Assim surgiram o Blackberry, e vários outros. Recentemente foi lançado o iPad
que é o modelo de PCTablet (ou Tablet) da Apple. Os tablets como são
P á g i n a | 37
popularmente conhecidos, são dispositivos móveis do tamanho de uma
prancheta, que possuem funcionalidades de celular e de PC simultaneamente.
Na realidade os tablets estão mais próximos da quarta geração de telefonia
móvel do que da terceira geração.
Figura 3.7 – Dispositivos 3G (Nokia 6120c de 2007 e Nokia smartphone E63 de 2008, modem celular DLink, Apple
iPhone WWDC 2009 e iPad 1 de 2010).
3.4.4 Quarta geração (4G)
A quarta geração da telefonia móvel, já é uma realidade em vários países da
União Europeia, da Ásia e nos Estados Unidos. A Presidente Dilma Rousseff,
em entrevista no programa de
rádio “Café com a Presidenta”1
dia 12 de setembro passado,
divulgou que a tecnologia tem
previsão de funcional com 40
milhões de dispositivos antes do
1
"Presidenta" termo usado atualmente para referir-se à Presidente da República do Brasil,
Dilma Roussef. Segundo à norma clássica do idioma, presidenteadvem do ente que preside,
onde ente é substantivo comum de dois gêneros, logo o termo correto é Presidente Dilma
Roussef.
P á g i n a | 38
mês de julho de 2014, data na qual irá ocorrer a Copa do Mundo FIFA no
Brasil. A previsão é de um investimento de 200 milhões de Reais.
As principais tecnologias utilizadas nesta geração serão:

LTE (Long Term Evolution);

WiMAX (Worldwide Interoperability for Microwave Access).
O padrão 4G ainda não está totalmente definido pela ITU (International
Telecommunication Union) e nem pronto para uso. Assim há várias outras
propostas como: HSPA+, HSPA 14, WiMAX 2 e LTEA.
As tecnologias LTE e WiMAX estão na frente, e testes já estão sendo feitos no
Brasil apesar de ainda não estar definido entre estas duas qual será o padrão
usado no país. Fato é que a 4G trará conexão de internet em alta velocidade e
permitirá uso de HDTV, e de funcionar como cartão de crédito. A tecnologia 4G
promete conexões de 4 a 100 vezes mais rápidas do que as atuais.
Figura 3.8 – Dispositivos 4G (Vodafone Connect Pen K5005, Motorola Triunph 4G ambos lançados em junho e o
iPhone 4G ainda não lançado no Brasil).
3.5 Sistemas operacionais para DM
Nasceram inicialmente para atender aos PDAs (Personal Digital Assistent) e
passaram a ser utilizados na telefonia celular com a chegada da tecnologia 2G,
pois foi nesta ocasião que os dispositivos celulares passaram a ter display
compatível com menus e outras opções, apesar de serem, no início, ainda
monocromáticos.
P á g i n a | 39
Os primeiros sistemas operacionais para celular eram bem primitivos.
Abaixo, um resumo das versões dos principais sistemas operacionais para
dispositivos moves já lançadas:
Ano
Sistema Operacional /
Versão
1990
EPOC16
1996
Palm OS 1.0
1997
EPOC32 v1
Palm OS 2.0
1998
Palm OS 3.0
1999
EPOC32 v5 (Symbian OS 5)
2000
Windows CE/PocketPC 2000
2001
2002
PocketPC 2002
Symbian OS 6.0
Palm OS 4.0
Palm OS 5.0
Symbian OS 6.1
Symbian OS 7.0
2003
Symbian OS 7.0s
Windows Mobile 2003
Symbian OS 8.0 e 8.0b
2004
Symbian OS 8.1a e 8.1b
Windows Mobile 2003 SE
Symbian OS 9.0
Palm OS Cobalt
Symbian OS 9.1
2005
2006
Windows Mobile 2005
Blackberry OS 4.1
Symbian OS 9.2
Symbian OS 9.3
Comentários
Desenvolvido para organizadores
eletrônicos
Agenda eletrônica, lista de tarefas e
jogos
Primeira versão
Correio eletrônico
Suporte a HotSync com PC, e cores
em 8 bits
Ultima versão antes do consórcio
Totalmente compatível com as
principais ferramentas Office.
MSN Messenger e Media Player 8
Primeiro Symbian
Cores em 16 bits
Bluetooth
O primeiro com recurso para câmera
embutida
Suporte a EDGE e IPv6
Melhor compatibilidade com as
versões 6.x
Bluetooth, Internet Explorer
Uso de dois kernels diferentes,
suporte a CDMA, 3G e gráficos
vetoriais
Versão melhorada do 8.0
WPA, e variação da tela entre retrato
e paisagem
Fim dos dois kernels
Wi-Fi e Bluetooth
Novos recursos de segurança e
Bluetooth 2
GPS e interface de gerenciamento
Suporte ao idioma Vietnamita
Gerenciamento de memória
aprimorado, Wi-Fi e HSDPA
P á g i n a | 40
Ano
Sistema Operacional /
Versão
iOS 1.0
Windows Mobile 6
2007
Symbian OS 9.4
Symbian OS 9.5
Blackberry OS 4.2
iOS 2.0
Blackberry OS 4.5
2008
Windows Mobile 6.1
Google Android 1.0
Symbian^1 (S60)
Google Android 1.1 (Cupcake)
Palm WebOS
Google Android 1.2 (Donut)
2009
Google Android 2.0 e 2.1
(Eclair)
Blackberry OS 5
Windows Mobile 6.5
Samsung Bada 1.0
iOS 3.0
iOS 4.0
Blackberry OS 6
Windows Phone 7
Google Android 2.2 (Froyo)
2010
Google Android 2.3
(GingerBread)
Symbian^2
MeeGo
Symbian^3
HP Web OS
Comentários
Primeira versão
DotNet v2 SP2 compatível, SQL
Server 2005 CE e Windows Live
Paginação sob demanda
Suporte a DVB-H e ISBD-T
Voice notes
Sync Google Contacts e suporte a
aplicações Third-part
HTML e correio eletrônico rápidos
Zoom de página inteira no Internet
Explorer e
Primeira versão
Widgets interativos, Facebook IM
Chat
Bluetooth A2DP e AVRCP, upload de
vídeos do YouTube e fotos do Picasa
Multitarefa e Integração com correio
eletrônico Yahoo Mail e GMail,
Resolução de tela WVGA, navegação
Google turn-by-turn gratuita
HTML 5, MS Exchange Server e
Bluetooth 2.1
Wireless Sync, Blackberry Enterprise
Server 5
Suporte a multi-touch
Primeira versão
Navegação turn-by-turn, Voice
Memos, Push Notifications.
Pastas multitarefas
Nova interface de mídia, lista de
contatos múltipla e integração com
mídias sociais.
Multitarefas, suporte a serviços lowbased e Tiled UI
Funcionalidade USB e Wi-Fi e
suporte a Adobe Flash 10.1
Multi-touch, suporte a telas ultralargas e de alta resolução
Versão de avaliação gratuita
Desenvolvido vários sistemas
embarcados.
WebKit nativo, arquitetura de gráficos
2 e 3D, melhoramentos UI e suporte
a monitores externos com HDMI
Multitarefa, Synergy App e tela multitouch
P á g i n a | 41
Ano
2011
Sistema Operacional /
Versão
Google Android 3.0
(HoneyComb)
Comentários
Lançada especialmente para tablets
Multitarefa otimizada,
compartilhamento de Bluetooth,
suporte de transferência de mídias e
customização da tela principal
Google Android 3.1
(HoneyComb)
Tabela 3.1 – Evolução dos principais sistemas operacionais para dispositivos móveis.
Os sistemas operacionais para celular são mais importantes nos aparelhos
smartphones, porque as aplicações são desenvolvidas para estes dispositivos.
Abaixo vemos da distribuição do mercado de smartphones no Brasil.
Smartphones no Brasil
0,9%
4,2%
1,0%
0,4%
0,1%
0,1%
Nokia
RIM (Blackberry)
0,0%
Apple
8,4%
Motorola
8,5%
Samsung
54,4%
22,1%
HTC
Sony Ericsson
Palm (HP)
LG Eletronics
Others
Dell
Gráfico 3.1 – Divisão do mercado de smartphones no Brasil (Gartner, 2010).
A seguir faremos uma breve descrição sobre os principais sistemas
operacionais para dispositivos móveis utilizados atualmente.
P á g i n a | 42
3.5.1 EPOC OS
O EPOC era um sistema operacional rudimentar criado para organizadores
eletrônicos pela Psion (empresa criada em 1980). O EPOC16 era originalmente
chamado apenas de EPOC. Foi desenvolvido no final da década de 80, e
renomeado e lançado em 1990 como EPOC16 para o dispositivo Psion’s SIBO.
Era baseado nos processadores 8086 de 16 bits, e desenvolvido em assembly
e C, sendo formulado para rodar embarcado em ROM. Rodava com usuário
único.
A primeira versão do EPOC32 foi lançada em 1997, no Psion Series 5. Apesar
de levar o mesmo nome, o EPOC32 era praticamente um novo sistema. Foi
desenvolvido em C++, a partir de uma nova base de código. Era pré-emptivo
multitarefa,
com
usuário
único.
Originalmente
foi
desenvolvido
para
processadores da família ARM (primeiramente Acorn RISC Machine,
atualmente Advanced RISC Machine), porém permitia a compilação para
outros processadores. Possuía um desempenho surpreendente levando-se em
conta a capacidade limitada do hardware.
As versões 2 e 4 nunca foram publicadas e não chegaram ao mercado. Já a
versão 3 foi lançada em sequência da versão 1. A seguir seguiu-se a versão 5
que rodava no Psion Series 5mx , Revo / Revo Plus, Psion Series 7 / netBook,
netPad e Ericsson MC218. Esta versão foi apelidada retrospectivamente de
Symbian OS 5.
Durante o período de desenvolvimento do EPOC32, houve uma divisão da
Psion, de modo que seu departamento de software tornou-se a Psion Software.
Em junho de 1998 a Psion Software tornou-se Symbian Ltd. a partir um
consórcio de várias empresas. A partir daí o EPOC versão 6 ficou conhecido
com Symbian OS.
P á g i n a | 43
3.5.2 Palm OS
O pioneirismo da Palm na criação de PDAs deu origem ao Palm OS 1.0 em
1986, sistema para ser usado nestes dispositivos. Mas seu sucesso inicial no
mercado de consumo em geral não foi acompanhado pelo mercado
corporativo, especialmente depois que a Microsoft quando lançou o Windows
CE, que fazia perfeita interface com todas as ferramentas Microsoft para PC e
era extremamente intuitivo. Outras versões se seguiram até 2009 quando fui
lançado o Palm Pre rodando Palm WebOS.
O Palm WebOS é baseado em Linux, sendo altamente customizado, foi
desenvolvido para processadores ARM.
Em abril de 2010 foi efetivamente anunciada a compra da Palm pela HP.
Ao final de 2010 a HP lançou o Palm Pre 2 rodando HP Web OS sucessor do
Palm WebOS. Ambos tiveram baixa aceitação e foram descontinuados pela HP
em agosto de 2011.
3.5.3 Windows Mobile
Foi inicialmente desenvolvido pela Microsoft para dispositivos móveis do tipo
PDA e era chamado Windows CE ou PocketPC 2000. Sua segunda versão
lançada em 2000 chamou-se PocketPC 2002 ainda para plataformas PDA. Até
então foi pouco utilizado, pois herdou problemas oriundos de seu sistema
origem, o Windows para computadores pessoais. No marcado de PDAs
disputava com o Palm OS, sendo mais utilizado em ambientes comerciais e
industriais, enquanto o Palm OS fazia sucesso nas casas de seus usuários.
O sistema foi remodelado para melhorar sua performance e aceitar uma maior
variedade de hardwares, mesmo assim ainda é pesado para a maioria dos
dispositivos atuais.
Foram então criadas 3 versões, seguindo o padrão usado pela Microsoft, onde
separa as versões de seu sistema Windows de acordo com certas
P á g i n a | 44
características. Nesse caso específico a separação foi feita visando a
diferenciação do hardware a ser usado:

Windows Mobile Professional para smartphones com touchscreen;

Windows Mobile Standard para celulares convencionais;

Windows Mobile Classic para ser usado nos PDAs conhecidos agora
como PocketPCs.
Assim como o Windows para computadores pessoais, não é efetivamente
multitarefa, funciona simulando este recurso.
Como em tese é a versão reduzida do sistema Windows usado nos
computadores pessoais, o que a tornou muito popular no mercado.
A última versão possui recursos para integração com Xbox360 e Zune.
Em termos de desenvolvimento de aplicações para Windows Mobile, a
Microsoft aconselha utilizar a linguagem C++ preferencialmente com o Studio
.Net (dot Net), o qual já possui todos os recursos para desenvolvimento para
esta plataforma.
3.5.4 Symbian
A partir de um consórcio, fundado em 1988, entre várias empresas
fornecedoras de dispositivos móveis (Nokia, Siemens, Sony Ericsson e
Panasonic) surgiu o Symbian OS. Atualmente pertence à Nokia que comprou
praticamente todas as ações em 2008, porém outras empresas podem licenciar
o sistema para utilização em seus produtos.
O Symbian é derivado do EPOC Psion e foi desenvolvido de forma modular,
para permitir que cada empresa pudesse desenvolver sua própria interface,
inclusive variando de modelo para modelo de dispositivo. Essa característica
permanece nas versões mais atuais o que permitiu que ele fosse usado em
dispositivos mais simples (até mesmo monocromáticos), bem como esteja
P á g i n a | 45
sendo usado até hoje nos mais novos modelos de smartphones, e sendo a
atual líder de mercado. A interface mais conhecida desse sistema é a Nokia’s
series 60 (usada em dispositivos Nokia e Sony Ericsson).
Este sistema foi desenvolvido para funcionar em diversos tipos de
processadores da família ARM, bem como dar suporte a varias tecnologias de
comunicação celular: CDMA, CDMA2000 x1, WCDMA, GSM, EDGE, e outras.
O microkernel suporta vários protocolos de comunicação: TCP/IP, Ethernet, e
outros. Atende a navegação web: WAP e HTML, e mensagens: SMS, MMS, email. Permite o uso de multimídia em geral. Faz sincronização de dados
usando SyncML com PC via porta serial, USB, Bluetooth, infravermelho e etc.
Também possui segurança dando suporte a vários protocolos de criptografia.
Por causa dos mecanismos que limitam o consumo de recursos a programação
para Symbian é bem restrita e complexa. Porém com o conceito Open
Standard Operation System (Sistema operacional aberto padrão), ele permite
que sejam desenvolvidas aplicações 32 bits multitarefa usando as linguagens
JAVA e/ou C++ (com suporte a MIDP, CDC e CLDC).
Recentemente a Nokia abriu os códigos fontes do Symbian e está planejando
trocar o Symbian pelo Windows Mobile, nesse sentido transferiu os serviços
relacionados ao Symbian para a Accenture, uma empresa multinacional de
outsourcing. Esta troca está prevista até 2016, porém a Nokia pretende ainda
comercializar dispositivos como Symbian até lá.
3.5.5 Android
E agosto de 2005 a Google comprou a Android Inc que até então era uma
pequena empresa americana fundada em 2003.
Depois, em 2007, formou-se um consórcio de várias empresas chamado “Open
Handset Aliance” (OHA) com a intenção de criar padrões abertos para a
telefonia móvel. Entre as empresas participantes estão a Google, HTC, Dell,
Motorola, Qualcomm, Texas Instruments, Samsung, LG Eletronics, T-Mobile e
NVidia.
P á g i n a | 46
Em dezembro de 2007 foi lançado o Android Beta SDK. E no ano seguinte foi
lançado o primeiro dispositivo móvel com Android 1.0, o HTC Dream G1.
Atualmente o Android é desenvolvido com uma parceria com a Sun Corp,
porém todo o controle comercial e operacional é da Google.
O Sistema possui código aberto e foi desenvolvido com base no GNU/Linux e é
altamente customizado para funcionar em dispositivos móveis. Não está
limitado
a
nenhum
hardware
específico
e
é
multitarefa.
Permite
desenvolvimento em plataforma Java e possui uma infinidade de aplicativos
gratuitos disponíveis para uso. Suporta todo tipo de conexão sem fio (3G,
EDGE, Wi-Fi e Bluetooth).
Hoje o Android é usado em aproximadamente 20% dos dispositivos móveis do
mercado mundial.
3.5.6 iOS
Chegou ao mercado em 2007 e hoje o iOS ocupa boa parte do mercado mas é
utilizado apenas em dispositivos da Apple (iPhone e iPad).
A Apple desenvolveu o iOS a partir do Mac OS X, desenvolvido para sua linha
de computadores pessoais no início da década de 80 que é usado até hoje.
Entretanto o iOS é bastante customizado e simplificado para funcionar
adequadamente no iPhone, que tem sido um grande sucesso de vendas.
Este sistema foi projetado para arquitetura ARM até a versão 4, a partir da qual
está usando o chip A4, que também é usado no iPad.
Como o iOS foi baseado no UNIX BSD, assim como seu “pai”, o Mac OS X, ele
permite que vários usuários usem o sistema simultaneamente, isso foi
contornado por meio da divisão do sistema em 3 domínios diferentes. Porém
esta segurança já foi quebrada e esse procedimento de quebra é conhecido
como jailbreak.
P á g i n a | 47
Para evitar a pirataria a Apple faz o kernel ser carregado criptografado na
memória, bem como exige assinatura digital para que uma aplicação use
recursos do sistema. Entretanto a quebra citada acima permite que isso seja
contornado em aplicações feitas em C e Objective C.
Outra característica do iOS é que carrega drives de dispositivos direto no
kernel do sistema o que aumenta a eficiência nesse aspecto.
O desenvolvimento de aplicações para esta plataforma só pode ser feito em
Mac OS X, pois não há SDKs disponíveis para outros sistemas operacionais de
computadores pessoais.
A interface é intuitiva e de fácil compressão, desta forma tornou-se um
sucesso.
O iOS revolucionou o padrão de sistemas operacionais para dispositivos
móveis, e a cada dia vem ocupando uma maior fatia do mercado.
3.5.7 BlackBarry OS
Research In Motion (RIM) desenvolveu em o Blackberry OS especificamente
para sua linha de smartphones e handhelds Blackberry.
É multitarefa e é muito focado no uso de dispositivos especiais tais como
tracking balls e scroll wells (dispositivos para rolagens de páginas e textos,
similares aos encontrados em mouses e teclados de notebooks). Mas só
executa programas certificados.
Uma característica interessante dos dispositivos Blackberry é que possui o
teclado especialmente projetado para a digitação com polegares, desenvolvido
especialmente para facilitar o seu uso.
É notadamente conhecida por oferecer suporte para o e-mail corporativo, por
meio de MIDP 1.0 e, mais recentemente, um subconjunto do MIDP 2.0, que
permite a ativação sem fio completo e sincronização com Microsoft Exchange,
Lotus Domino ou Novell GroupWise e-mail, calendário, tarefas, notas e
P á g i n a | 48
contatos, quando utilizado em conjunto com o BlackBerry Enterprise Server. O
sistema operacional também suporta WAP 1.2.
No meio empresarial a plataforma é bastante conhecida mundo a fora, porém
no Brasil não é tão difundida.
Recentemente perdeu bastante mercado a nível mundial devido ao avanço do
iPhone.
3.5.8 Bada
O Bada é o sistema operacional desenvolvido pela Samsung em 2009, voltado
para os dispositivos da própria empresa.
O kernel é configurado e pode ser tanto o Linux como outro tipo RTOS (Real
Time Operation System). A empresa sugere o uso do Linux para dispositivos
mais complexos. É multitarefa e possui suporte nativo para multi-touch.
O sistema oferece soluções voltadas para interação e comunicação com redes
sociais como Twitter e Facebook, bem como para multimídia YouTube.
Só está sendo usado nos smartphones mais modernos da Samsung.
Não se pode dizer muito a respeito da aceitação no mercado, pois seu uso
ainda é restrito.
3.5.9 Meego
Surgiu a partir da fusão do Maemo (plataforma de tablets e smartphones da
Nokia) com o Moblin (plataforma de netbooks da Intel).
É uma distribuição Linux com interface diferente e otimizada para telas
pequenas e telas sensíveis. Foi criado para plataformas variadas, como
desktops, netbooks, tablets, smartphones, dispositivos automotivos, smartTVs,
e outros sistemas embarcados. Por esse motivo fornece suporte para
arquiteturas ARM e x86.
P á g i n a | 49
Roda qualquer aplicativo para Linux além dos que são desenvolvidos para ela
própria. Atualmente é hospedado pela Linux Foudation.
3.6 Desenvolvimento de Software para DM
Desenvolver aplicações para dispositivos móveis requer certo trabalho de
garimpagem de informações. Isso advém do fato de haver uma infinidade de
dispositivos no mercado e agregado a eles uma boa variedade de sistemas
operacionais e ainda alguns destes sistemas permitem interfaces variadas,
como já mostrado nos anteriormente.
Há alguns aspectos principais a serem considerados no desenvolvimento para
dispositivos móveis, como: as limitações de espaço físico para armazenamento
de dados, limitações de uso de memória, limitações no tamanho da tela,
velocidade de processamento, velocidade de transmissão de dados, e outras
mais. Vejamos a seguir os aspectos mais importantes.
3.6.1 Limitações
O
desenvolvimento
de
softwares
para
celular
requer
certo
cuidado
especialmente em relação a capacidade de memória e de processamento das
CPU dos dispositivos, porém há outros detalhes importantes, como a
velocidade atual fornecida para transmissão de dados.
Portanto ao pensarmos numa aplicação para celular temos que ter em mente
os seguintes aspectos, que são inerentes aos dispositivos celulares:

Tamanho de tela;

Capacidade da memória;

Capacidade de processamento;

Taxa de transmissão de dados;

Persistência dos dados.
P á g i n a | 50

Capacidade do cartão de memória;

Sistema operacional;

Linguagem de programação;
Ao falarmos de aplicações para celular, deve ficar claro que estaremos
trabalhando com telas muito pequenas, de 3 a 7 polegadas, partindo de
resoluções de 150 por 150 pixels, e logicamente a disposição das informações
e recursos dos aplicativos precisam obedecer certas regras visuais, sob pena
de não serem utilizadas ou não funcionarem adequadamente. Há também
considerações relativas às telas multi-touch.
Quando nos referimos à capacidade de memória dos dispositivos celulares,
estamos basicamente querendo dizer que variam de meros 32Mb a 512Mb,
isso significa dizer que um aparelho celular atual funciona com a mesma
capacidade de memória dos primeiros computadores.
Seguindo esta analogia, e voltando ao passado, podemos considerar os
diversos problemas que foram enfrentados pelos mantenedores de software
quando se depararam com milhões de linhas de códigos antigas, contendo
data com formato de ano com dois dígitos numéricos, à beira da virada do ano
2000.
Toda esta questão se deu porque nas décadas de 70 e 80, quando estes
códigos foram criados, não se avaliava a durabilidade dos sistemas, e julgou-se
que a economia de espaço, suprimindo-se dois dígitos das datas, era
adequada àquela realidade.
Hoje sabemos que há sistemas com mais de 30 anos rodando e são totalmente
funcionais, porém como foram migrados para plataformas mais robustas não
há tanta limitação física.
Mas em relação à durabilidade das aplicações para dispositivos celulares
móveis, temos que considerar na realidade a durabilidade do dispositivo. Como
P á g i n a | 51
os aparelhos celulares são na realidade em média trocados a cada ano por
seus usuários, graças às promoções e facilidades que as operadoras
oferecem, e sabendo que os aplicativos que neles são executados são
bastante dependentes da plataforma. Vemos que também a durabilidade das
aplicações para este tipo de dispositivo está cada vez mais relacionada à sua
portabilidade e modularidade. Isso significa dizer que quanto mais portável e
modular for o software para celular, mais tempo ele poderá ser usado.
Já a capacidade de processamento dos dispositivos atuais de mercado é
bastante razoável, podendo executar tarefas simultâneas, e executar arquivos
de
multimídia,
processadores
mas
de
a
capacidade
computadores
ainda
pessoais.
é
restrita
Nesse
comparada
sentido,
muito
aos
do
processamento de aplicativos móveis é executado em servidores por meio de
conexões web, wi-fi e etc.
É nesse cenário, que as taxas de transmissão de dados se tornaram muito
importantes, e com a chegada da tecnologia 4G as maiores velocidades
permitirão um grande avanço em se tratando de aplicações móveis. A taxa de
transmissão também é importantíssima, considerando que os aparelhos
celulares não possuem recursos para armazenamento de dados persistentes.
Estes dados ficam armazenados em servidores de banco de dados que são
também acessados por meio das diversas conexões. Os cartões de memória
podem ser utilizados para armazenamento de algum dado, mas ainda assim os
recursos de programação para manipulação destes dados são restritos e
exigem processamento que pode tornar a aplicação pouco funcional.
A tendência do mercado hoje é de cada vez mais restringir-se a duas ou três
plataformas operacionais para dispositivos móveis. Cada vez mais as
empresas estão procurando a utilização de sistemas operacionais mais
compatíveis que possibilitem o reaproveitamento das aplicações, até porque a
tendência é de estas aplicações se tornarem muito mais funcionais. Mesmo
assim há particularidades que precisam ser consideradas quando se trata do
desenvolvimento de aplicativos para celular. Na minha visão ficaremos
P á g i n a | 52
divididos entre Google Android, Microsoft Mobile Windows, Nokia Symbian
(apesar de já estar fase terminal) e Apple IOS.
Finalmente temos que considerar a linguagem de programação para
desenvolvimento das aplicações para dispositivos móveis. Esta é uma decisão
importante quando se trata das aplicações para celular, pois os recursos
disponíveis para o desenvolvimento são bastante limitados e estão
especialmente relacionados ao hardware. Para cada hardware há plug-ins com
recursos próprios, e à medida que os utilizamos tornamos as aplicações menos
portáveis.
3.6.2 Linguagens de programação
Atualmente há no mercado uma vasta quantidade e variedade de linguagens
de programação, direcionadas a várias aplicações e plataformas. Porém
quando falamos de desenvolvimento para dispositivos celulares, ficamos
restritos a:

C++;

Java (J2ME);

Python;

Dot Net Framework (.Net);

XCode e Objective-C.
A linguagem C++ é orientada a objetos e sendo poderosíssima, permite fazer
praticamente tudo, inclusive em celulares, até mesmo acessar informações
protegidas do sistema operacional, mas é compilada especificamente para
cada hardware, ou seja, cada dispositivo ou grupo de dispositivos, precisa de
uma compilação própria da mesma aplicação, e na proporção em que mais
recursos específicos são usados; menos portável se torna a aplicação. As
melhores ferramentas para desenvolvimento em C++ são pagas o que também
encarece o desenvolvimento.
P á g i n a | 53
A linguagem Java, possui uma plataforma voltada especificamente para
aplicativos para dispositivos móveis, o J2ME. É orientada a objetos, porém
possuem recursos restritos, comparada com as suas plataformas irmãs (J2EE,
J2SE), voltadas para desenvolvimento em computadores pessoais. Por outro
lado plataforma J2ME é extremamente portável e possui máquina virtual
instalada na maioria dos dispositivos móveis do mercado. Os aplicativos
criados em J2ME podem facilmente ser integrados a aplicativos criados para
outras plataformas Java (J2EE, J2SE, e plataformas para dispositivos
embarcados), mas não podem fazer acesso diretamente a certos recursos dos
dispositivos móveis, o que de certa forma está relacionado diretamente à
portabilidade das aplicações nela desenvolvidas. Há SDKs para praticamente
todos os modelos de dispositivos do mercado, que são distribuídos por seus
fabricantes. As ferramentas para desenvolvimento Java são em sua maioria
freeware ou open source (gratuitas ou de código aberto), o que também facilita
o desenvolvimento. Estas características tornam o Java como a grande fonte
da maioria das aplicações móveis do mercado.
A linguagem Python também é orientada a objetos, e é freeware (software
livre), é usada sob plataforma Palm OS e Symbian, bem como as tradicionais
plataformas para computadores pessoais. Por outro lado deixa de lado outras
plataformas móveis muito usadas, como o Android por exemplo. É bastante
usada industrial e academicamente, para vários propósitos. Usa gerenciamento
automático da memória e é bastante similar ao Pearl e Scheme.
Temos também a plataforma Dot Net (.Net) da Microsoft, que possui SDK para
programação voltada a dispositivos móveis que são capazes de rodar Dot Net,
em especial os que trabalham com Windows Mobile. É um ambiente bastante
robusto e totalmente integrado a PC, porém tem alto custo de desenvolvimento
já que todos os softwares são pagos.
Por fim temos o desenvolvimento iPhone, para o qual são utilizadas as
linguagens XCode e Objective-C. Porém o desenvolvimento de aplicativos para
iPhone está restrito a plataforma MacOSX, já que a Apple só disponibilizou o
P á g i n a | 54
SDK para rodar nesta plataforma. Em alguns casos é necessário também que
os aplicativos desenvolvidos sejam homologados para iPhone. Há no mercado
algumas tentativas de SDK para Windows, não autorizadas e desenvolvidas
geralmente por hackers, mas a maioria delas não funciona. Outros fazem uso
do VMWare rodando MacOSX, um emulador, mas o trabalho está sempre
comprometido, e não há garantias quanto à qualidade da compilação. Ou seja
o desenvolvimento de aplicativos para iPhone é bem restrito às plataformas da
Apple, não havendo portabilidade.
Outras chamadas linguagens são divulgadas no mercado, mas basicamente
foram desenvolvidas sob uma das quatro plataformas acima, o que na verdade
as torna restrita às características próprias das linguagens sob as quais foram
montadas.
3.6.3 Bancos de dados
Quando se trata de persistência de dados, em ambientes móveis temos várias
considerações a fazer. A primeira delas trata do volume dados, ou seja, em
geral o volume de dados contidos em qualquer banco de dados é totalmente
incompatível com o hardware dos dispositivos móveis, logo o banco de dados
obrigatoriamente está externo ao dispositivo. Isso significa dizer que o acesso
aos dados é feito por meio de conexão com um servidor de banco de dados
que pode estar em qualquer lugar. Assim toda e qualquer operação de
persistência dos dados está diretamente relacionada à velocidade de conexão
dos dispositivos com o servidor.
Outro aspecto é a segurança, quando uma aplicação abre uma conexão com
um determinado banco de dados, abrem-se também as portas para as
invasões com intuito de roubo, destruição e todo o tipo de situação. Para isso
há diversas formas de criptografia dos dados e recursos de segurança
fornecidos pelas arquiteturas dos bancos de dados incluindo também a própria
arquitetura da aplicação. Quer dizer, a aplicação ao fazer acesso a um banco
de dados, e precisa usar recursos para tratar as diretivas de segurança
necessárias.
P á g i n a | 55
Uma terceira questão está na manutenção dos dados em geral. Os bancos de
dados atuais são capazes de tratar as colisões e locks (bloqueios) de forma
bastante adequada, logo por ocasião da mobilidade, e provavelmente do
volume de acessos ao banco de dados, inclusive simultâneos, feitos pelos
dispositivos móveis, a aplicação precisa ter recursos para identificar os retornos
dados pelos bancos e tratar adequadamente cada situação.
Outra questão trata do controle de versão, quer dizer quando uma aplicação
para dispositivo móvel acessa um banco de dados, o faz por meio de recursos
disponíveis para uma dada versão do banco. Veja que neste caso não estamos
nem falando da arquitetura do banco, mas apenas da versão do banco daquela
aplicação. Ou seja, para cada alteração no dado banco, associada a esta
mudança, há na maioria das vezes uma inevitável alteração de versão da
aplicação. Isso exige uma atualização que pode ou não ser automática
conforme os recursos de cada dispositivo.
Os problemas relacionados à persistência de dados ainda são grande gargalo
para o desenvolvimento de aplicações para dispositivos móveis, esse cenário
provavelmente mudará na medida em que as taxas de transmissão fiquem
maiores com a chegada do 4G, pois a partir daí estarão abertas as portas para
novas aplicações.
3.6.4 Internet
O acesso a internet feito via dispositivos móveis celulares, recai também sob os
mesmos aspectos das aplicações para celulares, ou seja, as limitações do
hardware. Então em 1997 a Nokia, a Motorola, a Ericsson e a Unwired Planet
se juntaram para criar um padrão universal para acesso a internet por meio de
dispositivos móveis celulares, o WAP – Wireless Aplication Protocol. Desde
então 350 outras empresas aderiram ao WAP Forum hoje chamado de OMA
(Open Mobile Alliance). Mesmo assim até agora uma pouca fração sites na
internet tem possui funcionalidade WAP para acesso via aparelho celular.
P á g i n a | 56
O WAP é projetado para funcionar em qualquer um dos serviços existentes,
usando padrões SMS, CSD (High-speed Circuit-switched Data), GPRS
(General Pocked Radio Service), USSD (Unstructured Supplementary Services
Data).
O WAP usa a Linguagem de marcação de aplicações sem fio (WML – Wireless
Markup Language) que é baseada no XML (Extension Markup Language). O
WML é considerado basicamente uma metalinguagem, o que permite a criação
de componentes.
O WAP foi desenvolvido por meio de camadas que são apresentadas a seguir:
WAE
Wireless Application Enviroment
WSP
Wireless Session Protocol
WTP
Wireless Transaction Protocol
WTLS
Wireless Transport Layer Security
WDP
Wireless Datagram Protocol
Rede
Qualquer Conexão Wireless
Figura 3.9 – Camadas do WAP.
WAP
P á g i n a | 57

WAE – Ambiente de aplicação sem fio, que possui as ferramentas que
os desenvolvedores de conteúdo da internet usam. Incluem o WML e o
WML Script que é a linguagem script usada com a WML.

WSP – Protocolo de sessão sem fio, que determina se uma se uma
sessão entre o aparelho e a rede é orientada à conexão ou não.

WTP – Protocolo de transação sem fio, que mantém os dados fluindo de
uma maneira lógica e sem problemas. Também determina como
classificar cada pedido de transação (bidirecional confiável, unidirecional
confiável ou unidirecional não confiável).

WTLS – Segurança da camada de transporte sem fio, que fornece
muitas das mesmas características do TLS (Transport Layer Security)
que faz parte do TCP/IP. Ocorre a conferência da integridade dos dados,
codifica e realiza a autenticação do servidor e do cliente.

WDP –Protocolo de datagrama sem fio, que funciona em conjunto com a
camada de rede. Torna fácil a adaptação a uma variedade grande de
portadoras de rede.

Rede – Pode fazer uso de qualquer tecnologia existente usada pelas
operadoras e dispositivos, desde que a informação seja fornecida em
nível WDP para a interface do WAP.
Com o WAP o mundo da internet se abriu para os dispositivos móveis
celulares, e atualmente a demanda pelo uso do WAP está só aumentando, e
deve ficar cada vez mais atraente, na medida que se aproxima a chegada da
tecnologia 4G.
3.7 O futuro da telefonia móvel
O futuro da tecnologia celular móvel está bastante alem do que podemos
imaginar em termos de velocidade de conexão, tipos de comunicação, serviços
P á g i n a | 58
entre outras coisas. Quanto aos aparelhos muita coisa está se desenhando nas
ideias dos designers. Veja alguns exemplos:
Figura 3.10 – Dispositivos do futuro idealizados pelos designers de diversos fabricantes.
P á g i n a | 59
Capítulo 4
O sistema SOTAC-Mobile
Capítulo que descreve as tecnologias aplicadas neste trabalho, bem como trata
de sua relação e aplicação no sistema SOTAC-Mobile.
4.1 Requisitos
Baseado numa evolução do projeto FALIBRAS, é proposta a criação de um
protótipo de interface de tradução de linguagem textual em Português para
LIBRAS para ambiente móvel.
Neste sentido, o SOTAC-Mobile é executado em dispositivos móveis, tornandoos capazes de processar, com o mesmo nível de recursos, a tradução feita
pelo Sistema SOTAC.
4.1.1 Requisitos funcionais
A criação de uma interface amigável para os DA em ambiente móvel requer
alguns aspectos muito importantes:

Simplicidade – o entendimento e a navegação desta interface deve ser
intuitiva evitando que o DA tenha que executar muitos cliques a fim de
obter seu resultado.;

Portabilidade – deve permitir que vários dispositivos móveis possam
executá-la, também deve ser executada via web.

Eficiência – o processamento não pode ser lento e o tempo de resposta
deve ser adequado à solicitação do DA;
P á g i n a | 60
4.1.2 Requisitos técnicos
O protótipo deve executar as seguintes funções:

Validação de login;

Tradução de Português para Texto alvo;

Tradução de Português para LIBRAS;

O aplicativo móvel não fica transiente no dispositivo móvel, é iniciado
manualmente.
4.2 Tecnologias avaliadas
Devido a estas principais características, a escolha da linguagem JAVA (J2ME)
como ferramenta de desenvolvimento desta interface ficou clara, na medida em
que esta linguagem oferece todos os recursos necessários para esta
implementação, bem como é a linguagem mais utilizada atualmente no
mercado para desenvolvimento em plataformas móveis e/ou encapsuladas.
4.2.1 Plataforma Java
A linguagem Java, foi criada pela SUN Microsystems no final da década de 90,
é uma linguagem orientada a objetos que é compilada para um bytecode
intermediário, de modo que este código é interpretado e executado por uma
máquina virtual. Esta característica dá ao Java uma grande portabilidade, já
que o mesmo código pode ser executado em plataformas totalmente distintas.
Toda a codificação fonte para plataforma Java nada mais é do que o conjunto
de especificações definida pela Java Language Specification que é escrita em
formato texto, com arquivos de extensão .java.
Estas instruções do código fonte compiladas, resultam em mnemônicos
(comandos) montados (assembly da máquina virtual) que são chamados
ByteCodes. O nome ByteCode origina-se do fato da instrução ter o tamanho de
um byte.
P á g i n a | 61
A linguagem Java não é o único recurso da plataforma de desenvolvimento
JAVA. Esta plataforma está baseada em três pilares: A linguagem em si; o
JVM, que é a máquina virtual Java e um vasto conjunto de APIs.
CÓDIGO FONTE
Código.java + JSR
BYTECODE
Código.class
MÁQUINA VIRTUAL
JVM
SISTEMAS OPERACIONAIS
Qualquer sistema operacional
Figura 4.1 – Codificação em Plataforma JAVA.
A função do JVM é tratar as questões relacionadas à portabilidade, deixando o
desenvolvedor livre para os assuntos programáticos relevantes à sua
implementação. Por outro lado o usuário final que deseja executar uma
aplicação necessita ter em seu dispositivo uma série de instalações, que
atualmente são facilmente encontradas e instaladas, até mesmo em muitos,
casos já faz parte do pacote do dispositivo. Já os desenvolvedores, necessitam
das bibliotecas e outros recursos para desenvolvimento.
Por esta razão, a plataforma Java possui duas distribuições diferentes:

JDK – Java Development Kit, voltado para o desenvolvedor e usado
para o desenvolvimento das aplicações Java;

JRE – Java Runtime Enviroment – voltado para o usuário final e usado
apenas para a interpretação das aplicações Java.
P á g i n a | 62
Para os dispositivos, esta plataforma em sua versão 2 está dividida em:

J2SE
–
Java
2
Standard
Edition:
Tecnologia
projetada
para
computadores pessoais e ambientes de trabalho, neste caso as
aplicações são chamadas APLets;

J2EE – Java 2 Enterprise Edition: Tecnologia direcionada para
aplicações baseadas em servidores, neste caso as aplicações são
conhecidas como SERVLets e podem conter suporte interno para JSP
(JavaServer Pages) e XML (eXtensible Markup Language);

J2ME – Java 2 Micro Edition: Tecnologia direcionada para dispositivos
com poucos recursos computacionais como por exemplo, palms,
smartphones, tablets, onde as aplicações para estes são conhecidas
como MIDLets.
A seguir apresenta-se visualmente esta divisão da plataforma Java conforme
os dispositivos aplicáveis:
Figura 4.2 – Arquitetura da plataforma JAVA (ORACLE, 2012).
As APIs (bibliotecas) Java compreendem um conjunto de recursos, agrupados
em pacotes (packages) usado no desenvolvimento das aplicações Java. Estas
P á g i n a | 63
APIs variam de acordo com a aplicação. Este conceito é muito comum e é
usado, por exemplo, nas linguagens C e C++.
O Java é compatível com os principais WebBrowsers do mercado e é
extremamente difundido na web. Atualmente também está se tornando a
plataforma clássica para desenvolvimento de aplicações embarcadas como,
veículos
automotores,
equipamentos
industriais,
televisores,
e
até
eletrodomésticos. Por este motivo e por suas características foi a plataforma de
desenvolvimento escolhida para este protótipo.
4.2.2 J2EE
O J2EE, é direcionado para aplicações baseadas em servidores, neste caso as
aplicações são conhecidas como SERVLets são usadas para suprir as
necessidades das aplicações distribuídas, ou seja, aquelas que necessitam da
flexibilidade de disponibilizar acesso à sua lógica de negócio e dados para
diferentes tipos de dispositivos (navegadores, dispositivos móveis, aplicações
desktop, aplicações embarcadas, etc.).
Abaixo o modelo de arquitetura J2EE.
Figura 4.3 – Arquitetura da plataforma J2EE (ORACLE, 2012).
P á g i n a | 64
4.2.3 J2ME
O J2ME é a tecnologia direcionada para dispositivos com poucos recursos
computacionais como, por exemplo, palms, smartphones, tablets. As
aplicações desenvolvidas usando esta tecnologia são chamadas de MIDLets e
o ByteCode gerado na sua compilação é executado por meio de uma máquina
virtual reduzida chamada KVM (Kilobyte Virtual Machine), que nada mais é do
que a própria JVM mais enxuta (um subconjunto dela). O nome KVM é uma
alusão à pouca quantidade de memória exigida que é na ordem de Kilobytes.
Há uma configuração que define as características da família de dispositivos e
os recursos e bibliotecas que compõem a KVM, são:

CDC – Connected Device Configuration, que corresponde ao conjunto
de APIs para dispositivos “fixos”, por exemplo um computador ligado a
um televisor;

CLDC – Connected Limited Device Configuration, que corresponde ao
conjunto de APS para dispositivos com alguma capacidade de
processamento, vídeo e memória limitados, geralmente dispositivos
móveis.
Há perfis que definem o conjunto de APIs que fornece funcionalidade a uma
configuração, são eles:

Fundation Profile, que é a base para dispositivos em rede sem interface
gráfica usando CDC;

Personal Basics e Personal Profile, que é a base para dispositivos com
suporte gráfico e alta capacidade, usado com CDC;

Mobile Information Device Profile (MIDP), que é o perfil compatível com
o CLCD e implementa componentes, entrada, tratamento de eventos de
interface com o usuário, armazenamento persistente, interoperabilidade
de rede, segurança e outros vários recursos.
P á g i n a | 65
A seguir está apresentada a Arquitetura J2ME.
Figura 4.4 – Arquitetura da plataforma J2ME (ORACLE, 2012).
Figura 4.5 – Codificação em Plataforma J2ME (ORACLE, 2012).
P á g i n a | 66
O s MIDLets possuem um ciclo de processamento padrão definido pelo MIDP,
conforme a seguir:
PAUSADO
pauseApp()
destroyApp()
startApp()
ATIVO
destroyApp()
DESTRUIDO
Figura 4.6 – Ciclo padrão de execução de um MIDLet.
Normalmente os MIDLets são criados em um ambiente computacional padrão,
mas para efeito de desenvolvimento são utilizados emuladores de forma a
otimizar e aproximar a execução destes aplicativos em seus reais dispositivos.
Estes emuladores estão disponíveis sob a forma de plug-ins para as IDEs mais
utilizadas, e cada fabricante de dispositivos as disponibiliza em seus sites de
desenvolvimento, em geral de forma gratuita. Os plug-ins são compostos
também pelas SDKs necessárias para o desenvolvimento específico de
aplicações para um dado dispositivo.
4.2.4 Dispositivos série S60 com Symbian
Como o Symbian é atualmente o Sistema Operacional mais usado nos
dispositivos móveis no Brasil, optou-se por implementar a interface deste
protótipo voltada para este sistema. Mais especificamente para versão que é
compatível com os Smartphones série S60, atualmente os mais difundidos do
mercado.
O SDK para Symbian é o Nokia Developer Suite for J2ME e está disponível no
site do fabricante.
O modelo usado no projeto é o Nokia E63.
P á g i n a | 67
4.2.5 Apache Tomcat
O Apache Tomcat é um servidor de aplicações Java para Web, livre e de
código aberto, criado no projeto Jakarta com apoio formal da SUN
Microsystems como sendo a implementação de referência para as tecnologias
J2EE. Atualmente o Tomcat tem seu próprio projeto de desenvolvimento
independente, dentro da Apache Software Foudation.
O Tomcat é robusto e eficiente, sendo na realidade um Contêiner Web, parte
da plataforma corporativa J2EE. Entretanto pode também atuar como servidor
Web/HTTP autônomo, ou pode funcionar integrado a um servidor web
dedicado como o Microsoft IIS, ou ainda ser parte integrante de um servidor de
aplicações mais amplo como o GlassFish com versão livre (também possui
versão comercial) e promover recursos de Java Servlet e JSP.
Por outro lado o Tomcat não implementa um contêiner EJB (Enterprise
JavaBeans). Isto é, para aplicações J2EE que utilizam JavaBeans se faz
necessário o uso de um servidor completo JBoss AS, Sun GlassFish ou IBM
WebSphere.
Cliente Web
Apache Tomcat
Aplicações
Figura 4.7 – Contêiner Web.
Para a nossa aplicação está disponível na web apenas um contêiner com
servidor Apache Tomcat versão 6.0.35 configurado para executar o SERVLet
SOTAC-Enterprise Mobile, que é capaz de responder as solicitações da
interface móvel retornando as traduções solicitadas.
4.2.6 Computação distribuída – RMI
O RMI (Remote Method Invocation) é um pacote opcional da plataforma Java
que contém uma API de alto-nível construída em cima de sockets, que permite
P á g i n a | 68
a passagem de dados entre computadores. Por meio desta tecnologia
conseguimos passar dados entre diferentes sistemas e invocar métodos em
objetos remotos, que podem ser manipulados com se estivessem na máquina
local. A transferência de dados é gerenciada pela máquina virtual Java de
forma transparente.
Na realidade podemos considerar o RMI como sendo uma evolução da
arquitetura cliente/servidor, onde um cliente é um computador que efetua
requisições por serviços, e um servidor trabalha como componente de entrega
dos serviços solicitados.
Processo Cliente
Processo Servidor
Objeto Cliente
Objeto Servidor
STUB
SKELETON
Gerenciador
de Referências
Remotas
Gerenciador
de Referências
Remotas
Camada de Transporte RMI
Figura 4.8 – Arquitetura RMI.
A seguir estão descritos os principais componentes da arquitetura RMI:

Interface de objeto de servido, que é uma sub-interface que implementa
a interface do objeto remoto;

Implementação de servidor, que é uma classe que implementa a
interface com o servidor remoto;

Objeto de servidor: que é a instância da classe implementação de
servidor;
P á g i n a | 69

Registro RMI (RMI Register), que é um utilitário responsável pelo
registro dos objetos remotos e fornece serviços de nomes (naming
services) para a localização de objetos (lookup);

Programa cliente, que é o programa que invoca (chama) os métodos no
objeto de servidor remoto;

Stub (canhoto) de servidor, que é um objeto que reside na máquina
cliente e serve como substituto para o objeto de servidor remoto;

Skeleton (esqueleto) de servidor, que é um objeto que reside na
máquina servidor e comunica com o objeto de servidor real e o stub.
O RMI-op é um subconjunto do pacote RMI, que roda sobre a plataforma
J2ME, tendo nesta plataforma a mesma funcionalidade de seu conjunto origem.
Para a utilização do RMI-op em dispositivos móveis é necessário que os
dispositivos possuam como recurso o JSE-066 (RMI Optional Package
Specification). Como nem todos os dispositivos móveis do mercado possuem
este recurso, optou-se pelo uso de frameworks aumentando a rapidez e a
portabilidade do protótipo.
4.2.7 Arcademis / RME
Arcademis é um framework utilizado para facilitar o desenvolvimento de
sistemas baseados em objetos distribuídos que utilizam a invocação remota de
métodos como meio de comunicação.
O RME (Remote Method Invocation for J2ME) é um sistema orientado
a objetos, que permite a invocação remota de métodos segundo uma
sintaxe semelhante à de JAVA RMI, de acordo com Pereira et al.
(2006).
P á g i n a | 70
O RME foi derivado do Arcademis, sendo assim uma instância do
mesmo. Há duas implementações de RME, uma destinada à
plataforma J2SE e a outra para ser utilizada na configuração CLDC
da plataforma J2ME, contendo somente as funcionalidades
necessárias para aplicações clientes. Assim como RMI, RME
apresenta uma arquitetura orientada a serviços, segundo Baresi et al.
(2003).
O RME é usado no nosso protótipo na medida em que é necessário acessar e
trocar dados entre um serviço remoto contendo as funcionalidades de tradução
do Sistema SOTAC, originalmente desenvolvido em outra plataforma, mas que
é usado como base para a implementação de uma versão do mesmo para
ambientes móveis, o Sistema SOTAC-Mobile.
4.2.8 Streaming
A transmissão de arquivos de multimídia entre plataformas se tornou uma
tarefa muito comum atualmente, porém estes arquivos em geral são grandes e
requerem muito espaço físico de armazenamento. Assim com o surgimento da
possibilidade de execução destas informações em dispositivos móveis de
forma integrada com a Internet, esta limitação relacionada ao espaço físico dos
dispositivos passou a ser um aspecto importantíssimo.
A tecnologia conhecida com Streaming foi criada com a finalidade de permitir
que os pacotes multimídia possam ser transmitidos através da rede sem
necessidade de download e upload síncrono. Em Streaming as informações de
mídia não são efetivamente gravadas pelo recebedor dos dados, ao invés disso
as informações são exibidas utilizando um fluxo de transmissão de acordo com
a sua banda de rede, desde que esta banda tenha capacidade suficiente para a
execução em tempo real.
Esta abordagem se tornou bastante interessante, pois livra os recebedores de
mídia das questões relacionadas a direitos autorais, e ainda assim permite que
as mídias possam ser executadas em seu destino.
Para que um dispositivo móvel possa executar as funções de Streaming é
necessário que ele possua nativamente os protocolos RTP e RTSP. Os
P á g i n a | 71
dispositivos Nokia série S60 possuem este recurso nativamente, e este
também é um dos aspectos pesados na escolha do dispositivo móvel para o
qual o nosso protótipo está desenvolvido.
4.2.9 IDE NetBeans
De modo geral, o desenvolvimento Java não requer IDEs específicas, pois todo
o código pode ser criado em qualquer editor de texto padrão, e neste caso, a
organização necessária fica neste caso a critério do desenvolvedor. Porém o
uso de IDEs facilita, organiza e torna o desenvolvimento focado no resultado da
aplicação evitando-se perda de tempo com questões relacionadas a
manipulação de pastas e arquivos.
A SUN Microsystems oferece um IDE gratuitamente, porém este IDE ainda é
bastante dependente da organização do desenvolvedor, deixando boa parte da
organização do projeto por definir.
Atualmente a Oracle, é proprietária da SUN Microsystems, criadora do JAVA, e
indica como IDEs para desenvolvimento Java, o Oracle JDeveloper que é uma
ferramenta com custos de uso, e o NetBeans que é gratuito. Assim sendo,
apesar de haverem outras IDEs bastante populares e gratuitas, como o
Eclipse, a opção escolhida para o desenvolvimento da interface é o NetBeans
versão 7.1.2, considerada a última versão estabilizada do produto.
O NetBeans é totalmente compatível com os frameworks necessários ao
projeto, sendo uma ferramenta bastante robusta, estável e eficiente para
desenvolvimento Java.
4.2.10 Astah
O software para edição da documentação de Casos de Uso e UML é o Astah
Community versão 6.4.1 que é software livre. Ele é a escolha mais natural por
ser livre e possuir todos os recursos necessários à documentação deste
protótipo. Na realidade o Astah é a nova e última versão do Jude, que trocou
de nome por questões comerciais.
P á g i n a | 72
4.3 Modelagem
4.3.1 Arquitetura do SOTAC–Mobile
A proposta do SOTAC-Mobile, é implementar uma interface simples para a
execução das funcionalidades do Sistema SOTAC em dispositivos móveis.
O MIDLet, SOTAC-Mobile, proposto neste projeto está focado em CLCD com
perfil MIDP com a finalidade de ser a interface entre o usuário DA e a aplicação
de tradução SOTAC.
Assim o protótipo trabalha com a seguinte arquitetura:
Clowd Computing
SOTACMobile
TRADUÇÃO
J2ME - RME
TRADUTOR
SOTAC
TRADUÇÃO
VÍDEOS
Figura 4.9 – Arquitetura do Sistema SOTAC – Mobile.
Como vemos acima, o MIDLet SOTAC-Mobile que está instalado nos
dispositivos móveis Nokia, compatíveis com a série S60, com sistema
operacional Symbian. Esta instalação se dá por meio de empacotamento feito
especialmente para facilitar este processo.
Como o MIDLet SOTAC-Mobile, proposto é apenas uma interface visual entre
as funcionalidades oriundas do Sistema SOTAC e o DA, logo se faz necessária
a criação de uma aplicação, SERVLet SOTAC-Enterprise Mobile, responsável
pela integração entre a Camada de Negócios obtida a partir do SOTAC e esta
interface. Esta aplicação intermediária também tem uma função muito
P á g i n a | 73
importante que é manter os recursos do SOTAC disponíveis na web, já que o
SOTAC é um sistema desktop.
Desta forma, assim que o usuário DA executa a aplicação a mesma entra no
estado ATIVO, e fica aguardando a digitação de um texto em Português, que é
a opção inicial deste protótipo. Neste momento o DA deve enviar o texto para
uma das opções de Tradução.
O texto para Tradução é enviado para o SERVLet SOTAC-EMobile que está
disponível na web. Cabe então ao SERVLet SOTAC-EMobile providenciar a
tradução do texto e posteriormente o envio do resultado novamente ao MIDLet
SOTAC-Mobile.
Web Conteiner em Servidor
de Aplicação Tomcat
MIDLet
SOTAC - Mobile
RME
SERVLet
SOTAC - EMobile
J2EE
TRADUTOR
SOTAC
TRADUÇÃO
VÍDEOS
Figura 4.10 – Interface entre as aplicações do SOTAC-Mobile.
Como podemos observar o SOTAC-Mobile é composto de três módulos
principais distintos, são eles:

MIDLet SOTAC-Mobile – aplicação que é executada nos dispositivos
móveis e é a principal interface com o usuário DA;
P á g i n a | 74

SEVLet SOTAC-EMobile – aplicação responsável por receber as
chamada RME, via web ou dispositivo móvel, executar e gerenciar a
interface com a Camada de Negócios originada do SOTAC;

SOTAC versão 1.1 – nova versão do SOTAC usada para o cadastro e
configuração dos dados usados no nosso servidor de Banco de Dados.
Há também, na web uma interface (SERVLet SOTAC-Web Mobile) básica
apenas executar as mesmas funções do MIDLet SOTAC-Mobile a fim de
demonstrar que há portabilidade na solução. Ademais a função primordial do
SERVLet SOTAC-EMobile é apenas de comunicação entre o SOTAC e o
MIDLet SOTAC-Mobile. Isto significa dizer que a função desta aplicação é
apenas de usar os recursos disponíveis para apresentar na web os resultados
de tradução semelhantes aos feitos por meio do MIDLet SOTAC-Mobile, que
podem ser visualizados em qualquer WebBrowser.
4.3.2 Casos de Uso
O diagrama de casos de uso do MIDLet SOTAC-Mobile está apresentado a
seguir:
Figura 4.11 – Casos de uso do MIDLet SOTAC – Mobile.
P á g i n a | 75
UC1 – Efetuar Login:
Atores: Usuário final do MIDLet SOTAC-Mobile (DA).
Pré-condições: SERVLet SOTAC-EMobile operante e conexão estável com a
Internet.
Fluxo de eventos primário:
 Usuário final do MIDLet SOTAC-Mobile (DA) executa a aplicação;
 A função Efetuar Login é chamada;
 É feita a solicitação de acesso ao SERVLet SOTAC-EMobile que é
responsável pela chamada ao SOTAC;
 O SERVLet SOTAC-EMobile processa o Login e aguarda o retorno do
SOTAC;
 O SERVLet SOTAC-EMobile retorna a resposta ao MIDLet SOTACMobile, que trata este retorno;
 Caso o retorno esteja ok, o MIDLet SOTAC-Mobile abre a tela para
digitação do texto a ser traduzido e aguarda atuação do usuário. Caso
contrário o sistema exibe a mensagem com o tratamento de erro
adequado e retorna ao modo de espera.
Fluxos alternativos: Nenhum.
UC2 – Traduzir Texto de Português para Texto Alvo:
Atores: Usuário final do MIDLet SOTAC-Mobile (DA).
Pré-condições: Digitação de um texto em Português, SERVLet SOTACEMobile operante e conexão estável com a Internet.
P á g i n a | 76
Fluxo de eventos primário:
 Usuário final do MIDLet SOTAC-Mobile digita um texto em Português e
solicita a tradução para Texto;
 O MIDLet SOTAC-Mobile valida o preenchimento do texto;
 É feita a solicitação de acesso RMI ao SERVLet SOTAC-EMobile que é
responsável pela chamada às funções de tradução do SOTAC;
 Após o processamento da tradução o SERVLet SOTAC-EMobile retorna
a resposta ao MIDLet SOTAC-Mobile, que trata este retorno;
 Caso o retorno esteja ok, o MIDLet SOTAC-Mobile abre a tela para
exibir o Texto Alvo traduzido e aguarda atuação do usuário. Caso
contrário o sistema exibe a mensagem com o tratamento de erro
adequado e retorna ao modo de espera.
Fluxos alternativos: Nenhum.
UC3 – Traduzir Texto de Português para LIBRAS:
Atores: Usuário final do MIDLet SOTAC-Mobile (DA).
Pré-condições: Digitação de um texto em Português, SERVLet SOTACEMobile operante e conexão estável com a Internet.
Fluxo de eventos primário:
 Usuário final do MIDLet SOTAC-Mobile digita um texto em Português e
solicita a tradução para LIBRAS.
 O MIDLet SOTAC-Mobile valida o preenchimento do texto;
 É feita a solicitação de acesso RMI ao SERVLet SOTAC-EMobile que é
responsável pela chamada às funções de tradução do SOTAC;
P á g i n a | 77
 Após o processamento da tradução o SERVLet SOTAC-EMobile retorna
a resposta ao MIDLet SOTAC-Mobile, que trata este retorno;
 Caso o retorno seja de falha, o sistema exibe a mensagem com o
tratamento de erro adequado. Caso contrário, se o retorno for ok, o
MIDLet SOTAC-Mobile abre a tela para exibir a sequência de vídeos;
 O MIDLet SOTAC-Mobile solicita via internet a transmissão dos vídeos,
e apresentada uma a uma em tempo real;
 Ao final da apresentação do texto alvo e dos vídeos o MIDLet SOTACMobile retorna à tela inicial e aguarda outra atuação do usuário.
Fluxos alternativos: Nenhum.
UC4 – Apresentação dos Vídeos:
Atores: UC3.
Pré-condições: Pasta publicável no servidor web contendo os vídeos listados,
para transmissão via HTTP ou um servidor Streaming, para transmissão via
RTP ou RTSP, a lista de vídeos a serem apresentados e conexão estável com
a internet.
Fluxo de eventos primário:
 MIDLet SOTAC-Mobile recebe a lista de vídeos para apresentação;
 É feita a solicitação e a transmissão dos arquivos listados pelo SERVLet
SOTAC-EMobile;
 Caso haja falha de comunicação exibe a mensagem com o tratamento
de erro adequado e o MIDLet SOTAC-Mobile retorna ao modo de
espera. Caso a exibição seja ok, o MIDLet SOTAC-Mobile retorna ao
modo de espera.
Fluxos alternativos: Nenhum.
P á g i n a | 78
O diagrama de casos de uso do SERVLet SOTAC-EMobile está apresentado a
seguir:
Figura 4.12 – Casos de uso do SERVLet SOTAC – EMobile.
UC5 – Serviço Remoto:
Atores: MIDLet SOTAC-Mobile.
Pré-condições: Contêiner web funcionando adequadamente.
Fluxo de eventos primário:
 O SERVLet SOTAC-EMobile fica em estado de espera aguardando uma
solicitação do MIDLet SOTAC-Mobile;
 O MIDLet SOTAC-Mobile solicita a execução de uma função ao
SERVLet SOTAC-EMobile, que é responsável pela chamada dos
métodos do SOTAC;
 O SERVLet SOTAC-EMobile processa a solicitação, validando os
parâmetros informados;
P á g i n a | 79
 O SERVLet SOTAC-EMobile faz o repasse do retorno para o MIDLet
SOTAC-Mobile;
 O SERVLet SOTAC-EMobile retorna ao estado de espera para nova
solicitação do MIDLet SOTAC-Mobile.
Fluxos alternativos: Nenhum.
UC6 – Login:
Atores: UC5.
Pré-condições: Banco de dados do SOTAC funcionando adequadamente com
todos os parâmetros e cadastros preenchidos a partir do SOTAC 1.1.
Fluxo de eventos primário:
 O SERVLet SOTAC-EMobile solicita a execução do login à Camada de
Negócios para o processamento da solicitação;
 A Camada de Negócios processa a solicitação e retorna a resposta ao
SERVLet SOTAC-EMobile;
 O SERVLet SOTAC-EMobile faz a passagem do resultado "ok" ou "não
ok" para o MIDLet SOTAC-Mobile.
 O SERVLet SOTAC-EMobile retorna ao estado de espera para nova
solicitação do MIDLet SOTAC-Mobile.
Fluxos alternativos: Nenhum.
UC7 – Tradução Texto:
Atores: UC5.
Pré-condições: Banco de dados do SOTAC funcionando adequadamente com
todos os parâmetros e cadastros preenchidos a partir do SOTAC 1.1.
P á g i n a | 80
Também é necessário que os arquivos de vídeo estejam disponíveis em uma
pasta publicável na web, para transmissão via HTTP, ou em um servidor
Streaming, para transmissão via RTP ou RTSP.
Fluxo de eventos primário:
 O SERVLet SOTAC-EMobile solicita a execução da tradução à camada
de negócios o processamento da solicitação;
 A camada de negócios processa da solicitação e retorna a resposta ao
SERVLet SOTAC-EMobile;
 O SERVLet SOTAC-EMobile faz a passagem do resultado da tradução
para o MIDLet SOTAC-Mobile
 Caso haja a necessidade de transmissão da sequência de vídeos, o
SERVLet SOTAC-EMobile retorna também a lista de todos os vídeos
que devem ser apresentados, já na sequência correta, para o MIDLet
SOTAC-Mobile.
 O SERVLet SOTAC-EMobile retorna ao estado de espera para nova
solicitação do MIDLet SOTAC-Mobile.
Fluxos alternativos: Nenhum.
4.3.3 Configurações
O protótipo proposto faz uso de persistência por meio de Banco de Dados,
atravéz do Sistema SOTAC para efeito de cadastro, assim sendo estas
questões são tratadas de forma transparente ao sistema. Para consultas, a
persistência é feita diretamente pela aplicação SERVLet SOTAC-EMobile.
Porém duas questões importantes foram levantadas. A primeira trata do
cadastro do usuário para uso geral do SOTAC-Mobile, e a segunda trata da
seleção da Memória de Tradução a ser utilizada.
P á g i n a | 81
Com relação à questão relacionada à segurança e aos perfis usados no
Sistema SOTAC, ficou definido se fazer um cadastro contendo os seguintes
parâmetros:
 Perfil = U;
 Nome = Usuário Móvel;
 Login = movel;
 Senha = M.
Este cadastro está pré-fixado (hardcoded) na Camada de Negócios do SOTAC,
e é usado para todas as chamadas de tradução executadas por meio do
MIDLet SOTAC-Mobile. Esta abordagem, torna o MIDLet SOTAC-Mobile uma
ferramenta para uso irrestrito e livre.
A seguir a tela de cadastro do SOTAC 1.1 com o perfil acima citado, trazendo o
usuário cadastrado.
Figura 4.13 – Perfil para o SOTAC – Mobile. no SOTAC.
Este cadastro está programado para ser executado caso não haja este usuário
móvel inserido no banco de dados. Está implementada uma inclusão feita
P á g i n a | 82
diretamente via código durante a função de login na Camada de Negócios do
SOTAC.
Já para tratar a questão da seleção da Memória de Tradução a ser utilizada,
preferencialmente a seleção é feita utilizando-se a primeira memória
cadastrada no sistema, pois para efeito do nosso protótipo a questão primordial
não está na essência da tradução, mas na possibilidade de executá-la em
ambiente móvel. Desse modo a Memória de Tradução "1" está pré-fixada
(hardcoded) no sistema.
4.3.4 UML
A seguir está o diagrama UML usado do MIDLet SOTAC-Mobile.
Figura 4.14 – Diagrama de Classes do MIDLet SOTAC – Mobile.
P á g i n a | 83
A seguir está o diagrama UML usado do SERVLet SOTAC-EMobile.
Figura 4.15 – Diagrama de Classes do SERVLet SOTAC – EMobile.
A seguir está o diagrama UML referente às funcionalidades do SOTAC (Java).
Figura 4.16 – Diagrama de Classes da tradução do SOTAC.
P á g i n a | 84
4.3.5 Recursos
As seguintes tecnologias e recursos são usados para desenvolvimento deste
protótipo.
Para o MIDLet, SOTAC-Mobile:

J2ME(JDK 1.6.0_25);

SDK para dispositivos Nokia série S60 FP2;

Nokia OVI Suite versão 2.1.0.87;

Arcademis / RME framework (client) 2.0;

NetBeans versão 7.1.2;

Conexão Móvel Web 3G;

Dispositivo celular Nokia modelo E63 (série S60), habilitado.
Para o SERVLet, SOTAC-EMobile:

J2EE (JRE e JDK 1.6.0_25);

Arcademis / RME framework (server) 2.0;

NetBeans versão 7.1.2;

SharpDevelop versão 4.0.4;

Banco de Dados PostGreSQL versão 9.3.1;

JDBC;

Host do tipo clowd computing com recursos Java, fornecido por mim.

Contêiner web Apache Tomcat versão 6.0.35 em Windows 2008 Server.
P á g i n a | 85
Para o SERVLet, SOTAC-WMobile:

J2EE (JRE e JDK 1.6.0_25);

Arcademis / RME framework (client) 2.0;

NetBeans versão 7.1.2;

CSS;

HTML;

JSP;

Conexão Móvel Web 3G;

Host do tipo clowd computing com recursos Java, fornecido por mim;

Contêiner web Apache Tomcat versão 6.0.35 em Windows 2008 Server.
Para o SOTAC versão 1.1:

Banco de Dados PostGreSQL versão 9.3.1;

SharpDevelop versão 4.2.1;

Microsoft SKD para Windows versão 7;

SOTAC versão 1.0.
Para a Modelagem e Documentação:

Adobe Acrobat Reader 9;

Astah Community versão 6.4.1;

MS Work 2007;
P á g i n a | 86
4.4 Implementação
Para tratar dos aspectos relacionados à implementação, temos que considerar
algumas questões importantes ocorridas durante o desenvolvimento do projeto.
4.4.1 Versões das ferramentas
A primeira questão está relacionada às versões das ferramentas utilizadas no
SOTAC versão 1.0. Tanto a versão do SharpDevelop quanto a versão do
PostgreSQL do projeto original, já não estão mais disponíveis para uso, logo
não houve outra opção, a não ser utilizar versões mais recentes.
Diante do exposto surgiu a necessidade de optar por usar versões mais
próximas das anteriormente usadas ou as versões mais atuais. Decidiu-se
então pelas versões mais atuais das ferramentas, mesmo correndo o risco de
ser necessário algum ajuste no código.
Gerou-se a nova versão do SOTAC, versão 1.1, para configuração dos dados
deste projeto. Cumpre esclarecer, que a nova versão não sofreu nenhuma
alteração funcional em relação à versão anterior, e nem quaisquer ajustes de
código.
4.4.2 Plataformas de desenvolvimento
A seguir levantou-se a questão a respeito do Java como plataforma de
desenvolvimento do protótipo. Fez-se necessário determinar a melhor
abordagem a respeito da camada de negócios do SOTAC, o qual está
desenvolvido em C# (C Sharp).
Foram levantadas duas abordagens:
2

Tradução da camada de negócios para Java;

Criação de uma DLL (COM) em C# acessível pelo Java via JNA2 e C++.
JNA: Framework para Java que pode executar bibliotecas escritas em outras linguagens (C ou C++).
P á g i n a | 87
No primeiro caso avaliou-se o risco de não se obter os mesmos resultados no
processo de tradução, visto que a recodificação nem sempre resulta em
resultados satisfatórios, além do fato do trabalho de recodificação em si. Por
outro lado e baseado nos testes feitos, obteve-se ganho de performance, já
que não fez-se necessário o uso de chamadas externas.
No segundo caso fez-se necessário a criação de uma interface feita em C/C++
para executar a chamada à DLL em C#, já que o C# não é compatível com o
JNA (Java) diretamente, pois ambos, Java e C#, trabalham com máquinas
virtuais distintas entre si, ou seja; o resultado de seus assemblies é totalmente
incompatível. Neste sentido criou-se a DLL em C# com base no código original
do SOTAC, o que também trata-se de recodificação, bem com criou-se a DLL
de interface em C/C++, onde esta é disparada via JNA no Java.
A vantagem desta segunda abordagem está no fato de a recodificação feita
não alterar o código original diretamente, já que apenas se fez necessário
ajustar e código dos tratamentos de erros, para redução das mensagens de
forma a atender as restrições dos aplicativos móveis, e a separação da camada
de negócios em uma DLL a parte ao executável original. Por outro lado,
trabalhar com interface entre linguagens, C#, C++ e Java, gera menor
portabilidade e aumenta a complexidade.
A esta questão da interface entre bibliotecas desenvolvidas com linguagens
diferentes, também há dois agravantes. O problema de performance, já que
DLLs de componentes COM em C# são um pouco lentas, especialmente para
chamadas de chamadas. Bem como a passagem de parâmetros por referência
e à estabilidade deste processo, já que o Java trabalha unicamente com
passagem de parâmetros por valor.
Pensando de forma prática e vislumbrando o futuro onde a ideia é expandir
para outros dispositivos e plataformas os recursos de tradução do SOTAC,
verificou-se que a tradução da camada de negócio do SOTAC para Java
mostrou-se a melhor abordagem para este projeto. Ou seja, apesar de haver
um trabalho maior de recodificação da Camada de Negócios, e isto inclui a
P á g i n a | 88
parte de segurança e conexão com o Banco de Dados, com esta abordagem,
obteve-se o melhor resultado com vistas a longo prazo.
Todos os métodos traduzidos estão ajustados para terem o comprimento das
mensagens de retorno reduzido, a fim de permitir a apresentação das mesmas
em dispositivos móveis com recursos limitados de tela. Também estão
anexados novos métodos em função das configurações móveis mencionadas
anteriormente.
4.4.3 Definição das camadas do sistema
Diante do exposto, tornou-se claro a necessidade da divisão do sistema em
camadas, que podem ou não estarem localizadas no mesmo ambiente,
conforme os recursos que se fazem necessários.
Assim o sistema está dividido em diversas aplicações responsáveis pelas
várias camadas, conforme apresentado na figura a seguir.
CAMADA DE INTERFACE
SOTAC-Mobile
Aplicações web, ou móveis
SOTAC-WMobile
CAMADA DE SERVIÇO RMI
Serviço RME
SOTAC-EMobile
CAMADA DE NEGÓCIO DO SOTAC
Funções de login e tradução
BANCO DE DADOS
POSTGRESS
memoriatraducao
Figura 4.17 – Camadas do sistema SOTAC-Mobile.
Esta divisão é responsável não só pela portabilidade da solução proposta para
os diversos dispositivos que podem usar a tradução do SOTAC, mas também
P á g i n a | 89
pela possibilidade de alterações nos hardwares envolvidos, tanto para
expansão de recursos, como para a adição de novos itens de interface sem a
necessidade de alterações nas funções de negócio ou para futuras
modificações nas funções de negócio sem que haja a necessidade de maiores
alterações nas aplicações de interface com o DA.
As aplicações para dispositivos móveis e web, que são aplicações meramente
de interface entre o DA e o sistema, podem ser distribuídas e simultaneamente
usar os recursos de negócio do SOTAC. Daí fez-se necessário a criação de
uma camada especial no SERVLet SOTAC-EMobile, camada RME, para
gerenciar o uso da Camada de Negócios, recodificada a partir das funções do
SOTAC original, a fim de permitir que estas rotinas mantenham seu
encapsulamento original, fornecendo uma maior portabilidade do sistema.
4.4.4 Streaming e formato dos arquivos de vídeo
Posteriormente fez-se a avaliação a respeito da transmissão dos vídeos para
dispositivos móveis. Optou-se por executar este processo na própria aplicação
Java (MIDLet SOTAC-Mobile) de modo a minimizar o uso de recursos
específicos dos dispositivos. Nesse sentido, é fornecida a lista dos caminhos
(hosts e/ou paths) e arquivos de vídeo para exibição. Isso criou transparência e
ganho de performance.
Outro aspecto relacionado à exibição dos vídeos que exigiu tratamento, é que a
aplicação original trabalha com arquivos no formato AVI, que não é adequado
nem para o ambiente móvel nem para a web. Assim, os arquivos de vídeo
foram convertidos para o formato MP4, mais comummente utilizados para
exibição e transmissão de vídeos.
Neste processo de conversão, os vídeos também foram ajustados para o
tamanho 320 por 240 pixels, que é a medida padrão usada pelos dispositivos
Nokia S60, com relação ao tamanho de seus displays.
P á g i n a | 90
O formato MP4 se apresentou como o mais adequado ao projeto devido a uma
série de vantagens:

É perfeitamente compatível com os recursos MMAPI do J2ME (JSR
135).

Permite streaming.

Seus arquivos podem ser exibidos com relativa facilidade, pois a maioria
dos dispositivos atuais possuem recursos para a sua exibição.

Mais especificamente nos dispositivos Nokia série S60, há players e
codecs capazes de executar este tipo de arquivo sem outras adições.

Este formato gera arquivos bastante compactos o que não compromete
os limitados recursos dos dispositivos móveis.
Por fim também se fez necessário avaliar os recursos para a transmissão da
sequência destes arquivos para os dispositivos móveis, de modo a garantir
uma performance adequada e uma execução sem interferência do usuário DA.
Para tanto os recursos desenvolvidos dentro da camada de serviço RMI do
projeto, permitem que se possa trabalhar com a transmissão dos arquivos
utilizando-se tanto protocolo HTTP quanto o protocolo RTMP, bastando apenas
uma configuração no arquivo de properties da aplicação do SERVLet SOTACEMobile.
4.4.5 Portabilidade
Finalmente, optou-se por criar uma interface web, o SERVLet SOTACWMobile, para uso das funcionalidades do SOTAC e a título de demonstração
a fim de apresentar como o uso destas tecnologias é capaz de trazer
portabilidade.
P á g i n a | 91
Esta página também teve importância ao facilitar o desenvolvimento do projeto,
na medida em que os testes das duas camadas mais inferiores puderam ser
feitos de forma autônoma.
Também foram feitos testes em emulador para dispositivos móveis Nokia série
S40. Estes testes foram feitos com Nokia SDK 2.0 for Java — for Series 40
apps, e não exigiram maiores alterações de código. O uso de emulador nestes
testes se deu por uma questão de ausência de recurso físico. O resultado é
equivalente ao obtido na com a versão para Nokia série S60, portanto com
sucesso.
4.4.6 Interface
A partir dos módulos do sistema, a interface está separada em três partes, uma
para cada aplicação:
Do MIDLet SOTAC-Mobile:
A interface do MIDLet SOTAC-Mobile é bastante simples e minimalista.
Figura 4.18 – Telas de abertura e principal do SOTAC–Mobile obtidas via emulador.
P á g i n a | 92
Figura 4.19 – Menu principal e tradução no SOTAC–Mobile obtidas via emulador.
Figura 4.20 – Tela de espera e exibição de vídeos no SOTAC–Mobile obtidas via emulador.
P á g i n a | 93
No contexto das telas acima apresentadas, vemos que a navegação é bastante
simples e pode ser feita igualmente com dispositivos que possuem teclados
alfanuméricos ou numéricos com as mesmas funcionalidades.
Do SERVLet SOTAC-EMobile:
Como o SERVLet SOTAC-EMobile se trata de uma aplicação muito simples
apenas para execução do Serviço Remoto do sistema e das funções do
SOTAC, não há uma interface visual disponível, assim sendo; por meio do
prompt de comando do Windows é possível visualizar o processamento desta
camada.
Figura 4.21 – Serviço remoto SERVLet SOTAC –EMobile em execução no servidor
Do SERVLet SOTAC-WMobile:
A interface está criada, como já explicado anteriormente apenas para efeito
demonstrativo,
assim
há
apenas
as
páginas
mais
básicas
para
a
demonstração.
Estas páginas podem ser abertas nos browsers Internet Explorer, Google
Crome, e Mozila Firefox, que são mais comumente usados. Em todos os casos
o funcionamento apresentou-se correto e com os resultados adequados para a
tradução e apresentação dos vídeos.
P á g i n a | 94
A página de acesso ao sistema, para login de usuário.
Figura 4.22 – Tela de acesso ao SERVLet SOTAC –WMobile obtida via browser IE.
E a página para a execução da tradução.
Figura 4.23 – Tela de traduções do SERVLet SOTAC –WMobile obtida via browser IE.
P á g i n a | 95
Página com a apresentação de uma tradução após um teste.
Figura 4.24 – Tela de resultado no SERVLet SOTAC –WMobile obtida via browser IE.
Usa-se nesta aplicação o CSS como tecnologia de gerenciamento de estilos.
Do SOTAC:
Está mantida, exatamente a mesma interface já usada na versão 1.0, ou seja; a
nova versão 1.1 é apenas a reedição do SOTAC com atualização das
ferramentas de desenvolvimento e banco de dados. Esta interface pode ser
vista na tese de mestrado de Breda (2008).
4.4.7 Fluxo de desenvolvimento
Como o SOTAC-Mobile é uma evolução do Sistema SOTAC, podemos
representar o fluxo de desenvolvimento do protótipo da seguinte maneira:
FALIBRAS
FALIBRAS - MT
SOTAC
SOTAC-Mobile
Figura 4.25 – Fluxo de desenvolvimento do SOTAC – Mobile.
P á g i n a | 96
4.4.8 Codificação
A partir das camadas definidas e mostradas anteriormente, a implementação
está separada em três aplicações principais desenvolvidas na plataforma Java:
SERVLet SOTAC-EMobile:
O SERVLet SOTAC-EMobilet é na verdade um Serviço Remoto RMI capaz de
executar as funções do SOTAC traduzidas para Java.
Assim sendo, primeiramente há a interface RME é composta das chamadas às
funções de login (linha 2), tradução (linha 3) e uma função auxiliar para
impressão de informações na tela do Serviço Remoto (linha 4), esta interface é
também utilizada por em todos os módulos de interface do projeto.
1. public interface ServicoRemoto extends Remote{
2.
public String Login(String usuario, String senha) throws ArcademisException;
3.
public String[] Traduz(String perfil, String tipo, String TXTOrigem) throws
ArcademisException;
4.
public void mensagemServidor(String mensagem) throws ArcademisException;
5. }
A seguir a rotina da classe skeleton do RME para login e tradução, responsável
pelo vínculo com a classe stub RME.
1. public class ServicoRemotoImpl_Skeleton extends arcademis.server.Skeleton {
2.
3.
public Stream dispatch(RemoteCall r) throws Exception {
4.
RmeRemoteCall remoteCall = (RmeRemoteCall)r;
5.
Stream returnStr = OrbAccessor.getStream();
6.
Stream args = remoteCall.getArguments();
7.
switch (remoteCall.getOperationCode()) {
8.
case 0: {
9.
java.lang.String param0 = (java.lang.String)args.readObject();
10.
Marshalable retValue = null;
11.
((sotacsmobile.ServicoRemotoImpl)super.remoteObject).mensagemServidor(param0);
12.
returnStr.write(retValue);
13.
}
14.
break;
15.
case 1: {
16.
java.lang.String param0 = (java.lang.String)args.readObject();
17.
java.lang.String param1 = (java.lang.String)args.readObject();
18.
java.lang.String retValue =
((sotacsmobile.ServicoRemotoImpl)super.remoteObject).Login(param0, param1);
19.
returnStr.write(retValue);
20.
}
21.
break;
22.
case 2: {
23.
java.lang.String param0 = (java.lang.String)args.readObject();
24.
java.lang.String param1 = (java.lang.String)args.readObject();
25.
java.lang.String param2 = (java.lang.String)args.readObject();
26.
java.lang.String[] retValue =
((sotacsmobile.ServicoRemotoImpl)super.remoteObject).Traduz(param0, param1, param2);
27.
returnStr.write(retValue);
28.
}
P á g i n a | 97
29.
break;
30.
default: {
31.
throw new ArcademisException("Invalid operation in remote method request");
32.
}
33.
}
// end switch
34.
return returnStr;
35.
}
// end dispatch
36. }
Para efetuar o processamento das requisições RME, tem-se e classe de
implementação da interface acima (implementação do login e da tradução).
Observa-se que estas rotinas são bastante semelhantes às rotinas usadas na
aplicação em C# do projeto original do SOTAC de Breda (2008).
Abaixo há a implementação do login, onde é feita a chamada da função (linha
6) do SOTAC traduzida para Java.
1. @Override
2. public String Login(String usuario, String senha) {
3.
String ret = "";
4.
try {
5.
sotacemobile.sotac.Login lgn = new sotacemobile.sotac.Login();
6.
ret = lgn.Login(usuario,senha);
7.
} catch (Exception e) {
8.
ret = ret +". "+ e.getMessage();
9.
}
10.
return ret;
11. }
Observa-se que o retorno desta função é uma string alimentada com o valor
"Ok." em caso de sucesso ou de uma mensagem de erro em caso de
insucesso,
resultados
estes
obtidos
via
retorno
da
função
sotacemobile.sotac.Login.
Na implementação da tradução é feita a chamada à função (linha 9) do SOTAC
traduzida para Java.
1. @Override
2. public String[] Traduz(String perfil, String tipo, String TXTOrigem) {
3.
String ret = "";
4.
String TXTAlvo = "";
5.
Vector vret = new Vector();
6.
System.out.println("Traduzir texto origem: "+ TXTOrigem);
7.
sotacemobile.sotac.TraducaoTexto trdtxt = new sotacemobile.sotac.TraducaoTexto();
8.
try {
9.
ret = trdtxt.EfetuarTraducao(perfil,tipo,TXTOrigem);
10.
} catch (Exception e) {
11.
ret = ret +". "+ e.getMessage();
12.
}
P á g i n a | 98
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35. }
// alimenta a resposta com a tradução obtida
vret.add(ret);
if (ret.equals("Ok.")) {
// monta o retorno = primeiro a tradução depois a lista de aquivos
TXTAlvo = trdtxt.getTEXTOAlvoString()+" ";
System.out.println("Tradução: "+ TXTAlvo);
vret.add(TXTAlvo);
// carrega os vídeos
if (tipo.equals("V")) {
String[] videos = trdtxt.getSEQVideos();
// passando os vídeos para o retorno
for (int i = 0; i < videos.length; i++) {
vret.add(videos[i]);
}
}
}
// prepara o retorno
String[] retorno = new String[vret.size()];
for (int i = 0; i < vret.size(); i++) {
retorno[i] = (String)vret.get(i);
}
return retorno;
Observa-se que ao final da tradução ocorre a alimentação do vetor que contem
o conjunto de strings (cadeias de caractéres) com o resultado do
processamento, com a seguinte disposição:
Posição 0 (zero): retorno "Ok." ou mensagem de erro (linha 14);
Posição 1: texto Alvo (linha 19);
Posição 2 em diante: lista de arquivos (linha 25).
Por fim, há a função de execução do Serviço Remoto bem como a função main
da aplicação.
1. public void execute() {
2.
try {
3.
RmeConfigurator mc = new RmeConfigurator();
4.
mc.configure();
5.
ServicoRemotoImpl infoObj = new ServicoRemotoImpl();
6.
System.out.println("Registrando objeto Remoto...");
7.
RmeNaming.bind(URL,infoObj);
8.
System.out.println("Registrado!");
9.
infoObj.activate();
10.
} catch (Exception e) {
11.
System.err.println("Erro " + e);
12.
e.printStackTrace();
13.
System.exit(2);
14.
}
15.
System.out.println("Esperando por ação...");
16. }
Observando-se que a conexão RME (linha 7) é feita usando-se a URL prédefinida em um arquivo de properties, comumente usado em Java.
P á g i n a | 99
Abaixo a main da aplicação, com ênfase na geração das classes stub e
skeleton RME (linha 12), recurso este fornecido pelo Arcademis / RME.
1. public static void main(String[] args){
2.
String ret = "";
3.
// Obtem o nome do serviço registrado via properties
4.
try {
5.
ret = sotacemobile.SOTACEMobile.GetConfig();
6.
} catch (Exception e) {
7.
System.err.println("Ocorreu uma falha na leitura das propriedades." +
"\n\nDetalhes: \n"+e.getMessage());
8.
}
9.
// stubs e skeletons
10.
String localPath = new java.io.File("").getAbsolutePath() + "/src";
11.
rme.rmec.RmeC.main(new String[] {"-d", localPath, "sotacsmobile." +
ServiceName+"Impl"} );
12.
// executando
13.
try {
14.
new SOTACEMobile().execute();
15.
System.err.println("SOTACEMobile pronto ("+URL+").");
16.
} catch (Exception e) {
17.
System.err.println("Mensagem: " + e.toString());
18.
e.printStackTrace();
19.
}
20. }
MIDLet SOTAC-Mobile:
As funcionalidades principais do MIDLet SOTAC-Mobile são as que fazem
interface com o SERVLet SOTAC-EMobile, criadas em Java.
Primeiramente tem-se a rotina que efetua a conexão com o Serviço Remoto
(RME), que é feita por meio da String contendo a URL de conexão (linha 6):
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
try {
System.out.println("Configurando...");
RmeConfigurator mc = new RmeConfigurator();
mc.configure();
System.out.println("Procurando por objeto remoto...");
SRemoto = (ServicoRemoto)RmeNaming.lookup(URL);
}catch (Exception e) {
e.printStackTrace();
throw new Exception("Erro ao procurar o objeto remoto!\n" + e);
}
A seguir é feito o login (linha 4) com a finalidade de garantir o acesso ao
sistema, observando-se que todos os parâmetros estão definidos hardcoded:
1.
2.
3.
4.
5.
6.
7.
8.
9.
if (SRemoto != null) {
try {
SRemoto.mensagemServidor("Efetuando login remoto!");
ret = SRemoto.Login("movel","M");
}catch (Exception e) {
e.printStackTrace();
throw new Exception("Erro ao realizar a chamada remota!\n" + e);
}
}
P á g i n a | 100
Está definida uma classe chamada Locator inicializada juntamente com o
Serviço Remoto (SRemoto), e tem como principal finalidade armazenar a lista
de vídeos recebida com aspectos de playlist (lista de reprodução) permitindo
assim o sequenciamento dos vídeos sem atuação direta do usuário.
A seguir apresenta-se a definição desta classe:
1. public class Locator {
2.
public String[] locator = null;
3.
public int locatorindex = 0;
E finalmente a chamada para a função que efetua as traduções (linha 4),
incluindo a chamada a função para a alimentação da lista dos vídeos (linha 15)
definida na classe Locator mencionada acima:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
if (SRemoto != null) {
try {
SRemoto.mensagemServidor("Efetuando a tradução remota!");
sret = SRemoto.Traduz("U",tipo,textofonte);
ret = sret[0];
}catch (Exception e) {
ret = e.getMessage();
}
// trata o retorno do servlet
if (ret.equals("Ok.")){
TextField SM_T = MIDlet.getSM_traducao_textfield();
SM_T.setString(sret[1]);
// se a tradução é com vídeo prepara para a exibição
if (tipo.equals("V")) {
MIDlet.videos.intLocator(sret,2);
}
}
}
}
Esta aplicação faz uso da interface RME e da classe stub do RME com a
finalidade de integração com a implementação das funções de login e tradução
do SOTAC SERVLet-EMobile, abaixo está a classe stub do RME:
1. public java.lang.String Login(java.lang.String param0, java.lang.String param1)
throws arcademis.ArcademisException {
2.
java.lang.String resp = null;
3.
try {
4.
Stream args = OrbAccessor.getStream();
5.
args.write(param0);
6.
args.write(param1);
7.
int op = 1;
8.
Stream future = invoke(args, op, '?', 0);
9.
if(future.isException()) {
10.
Exception e = (Exception)future.readObject();
11.
throw e;
12.
}
13.
resp = (java.lang.String)future.readObject();
14.
} catch (arcademis.ArcademisException e) {
15.
throw e;
16.
} catch (Exception e) {
P á g i n a | 101
17.
throw new arcademis.UnspecifiedException(e.toString());
18.
}
19.
return resp;
20. }
21.
22. public java.lang.String[] Traduz(java.lang.String param0, java.lang.String param1,
java.lang.String param2) throws arcademis.ArcademisException {
23.
java.lang.String[] resp = null;
24.
try {
25.
Stream args = OrbAccessor.getStream();
26.
args.write(param0);
27.
args.write(param1);
28.
args.write(param2);
29.
int op = 2;
30.
Stream future = invoke(args, op, '?', 0);
31.
if(future.isException()) {
32.
Exception e = (Exception)future.readObject();
33.
throw e;
34.
}
35.
resp = (java.lang.String[])future.readObject();
36.
} catch (arcademis.ArcademisException e) {
37.
throw e;
38.
} catch (Exception e) {
39.
throw new arcademis.UnspecifiedException(e.toString());
40.
}
41.
return resp;
42. }
Por fim, a seguir estão apresentadas as rotinas para execução da lista de
vídeos, onde a exibição em si (linha 4) ocorre no evento start da classe
PlayerManager por meio de uma thread (fluxo de execução) separada.
1.
2.
3.
4.
5.
6.
7.
8.
String video = MIDlet.videos.getLocator();
if (!(video.equals("")) && !(video == null)) {
defplayer();
player = Manager.createPlayer(video);
player.addPlayerListener(this);
player.realize();
// aguarda o final da apresentação para iniciar o outro video
automaticamente
player.start();
Observa-se que não há um loop (fluxo de repetição) para a exibição da
sequencia de vídeos, pois um vídeo só é chamado após o evento
END_OF_MEDIA, disparado pelo objeto player, e utilizando a playlist vídeos da
classe Locator mencionada anteriormente. Conforme mostrado a seguir.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
} else if(event.equals(PlayerListener.END_OF_MEDIA)) {
form.deleteAll();
MIDlet.switchDisplayable(null, MIDlet.getSM_waitScreen());
MIDlet.videos.nextLocator();
if (MIDlet.videos.indexLocator() < MIDlet.videos.lenghtLocator()) {
// inicia o proximo vídeo
this.run();
} else {
// reinicia o locator
MIDlet.videos.firstLocator();
// volta para a tela anterior
MIDlet.switchDisplayable(null, MIDlet.getSM_form());
}
}
P á g i n a | 102
Todas as outras rotinas contidas no MIDLet SOTAC-Mobile são meramente
para tratamentos de GNU.
Do SOTAC-WMobile:
Na aplicação web, para as solicitações de login e tradução temos uma
repetição da lógica utilizada na aplicação móvel. sendo que estas rotinas foram
implementadas no dopost.
A interface RME e a classe stub do RME são exatamente as mesmas utilizadas
no MIDLet SOTAC-Mobile.
Todas as outras rotinas do SERVLet SOTAC-WMobilet são para tratamentos
usando CSS, XHTML e JSP.
Do SOTAC:
No SOTAC as principais rotinas traduzidas para Java estão relacionadas aos
processos de conexão ao banco de dados, login e tradução. Estes códigos
foram traduzidos do C# para Java.
Estas
rotinas
pertencem
atualmente
ao
SERVLet
SOTAC-EMobile,
contemplando a camada de negócios do SOTAC.
A seguir é apresentada a rotina utilizada para conexão (linha 2) com o banco
de dados, usando parâmetros de acesso obtidos a partir do arquivo de
properties Java, criado para substituir o config.ini usado no SOTAC que é
originalmente preenchido na rotina principal do SOTAC (program.cs).
1.
2.
3.
public static Connection getConnection() throws SQLException {
return DriverManager.getConnection(URL,UserID,Password);
}
P á g i n a | 103
Outro item de banco de dados é a rotina para a execução de querys (linha 7).
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
public static ResultSet runquery(String SQLquery) {
Connection CONEXAO = null;
ResultSet RS = null;
try {
CONEXAO = Conecta.getConnection();
Statement stm = CONEXAO.createStatement();
RS = stm.executeQuery(SQLquery);
} catch(SQLException e) {
e.printStackTrace();
} finally {
try {
CONEXAO.close();
} catch(SQLException onConClose) {
onConClose.printStackTrace();
}
return RS;
}
}
A rotina de login do sistema está criada para atender a nova configuração de
acesso via dispositivos móveis.
1. public class Login {
2.
public String Login(String user, String password)
3.
{
4.
String ret = "";
5.
try {
6.
ret = sotacemobile.jdbc.Conecta.GetConfig();
7.
} catch (Exception e) {
8.
return "Ocorreu uma falha na leitura das propriedades." + "\n\nDetalhes:
\n"+e.getMessage();
9.
}
10.
if (ret == "Ok.") {
11.
ret = CriarAdministrador();
12.
if (ret == "Ok.") {
13.
ret = CriarUsuarioMobile();
14.
if (ret == "Ok.") ret = EfetuarLogin(user,password);
15.
}
16.
}
17.
return ret;
18.
}
Observa-se que o usuário móvel é criado (linha 13) quando não existe na base
de dados, adequando-se ao novo contexto. Na sequência (linha 14) é feita a
chamada para a consulta de login via banco de dados.
P á g i n a | 104
A rotina para criação do usuário móvel assemelha-se muito àquela utilizada na
versão original do SOTAC para a criação de um usuário administrador
automaticamente, esta abordagem é proposital de forma a respeitar a lógica
original do SOTAC.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
private String CriarUsuarioMobile() {
String COMANDO = "";
int contagem = 0;
ResultSet rs = null;
try {
COMANDO = "select count(usuario) as total " +
"from usuarios " +
"where perfil = 'U' and usuario = 'movel'";
rs = sotacemobile.jdbc.Conecta.runquery(COMANDO);
if (rs.next()) contagem = rs.getInt("total");
if (contagem == 0) {
COMANDO = "select max(cod_us) as total " +
"from usuarios ";
rs = sotacemobile.jdbc.Conecta.runquery(COMANDO);
if (rs.next()) {
double total_us = rs.getDouble("total");
if (total_us>0) total_us++; else total_us = 1;
COMANDO = "insert into usuarios " +
"(cod_us,usuario,senha,nome,perfil) " +
"values ("+Double.toString(total_us)+",'movel','M','Usuário
Móvel','U')";
rs = sotacemobile.jdbc.Conecta.runquery(COMANDO);
}
}
} catch (Exception e) {
return "Ocorreu uma falha de conexão com o banco de dados." +
"\n\nDetalhes: \n"+e.getMessage();
}
return "Ok.";
}
Por fim, todas as outras rotinas foram traduzidas para Java, sem alteração de
sua lógica original em C#, sempre respeitando a autoria que é do SOTAC de
Breda (2008). No mais todas as diferenças de tradução estão relacionadas
apenas ao contexto de caixas de mensagens removidas e substituídas por
retorno string, e/ou com a retirada de objetos e eventos visuais.
Os códigos completos estão disponíveis para download por meio das URLs
apresentadas no ANEXO C.
P á g i n a | 105
4.4.9 Resultados alcançados
No processo de tradução foram alcançados os mesmos resultados obtidos na
tese de Breda (2008). Porém o contexto de apresentação destes resultados
está expresso de maneira diferente.
No dispositivo móvel Nokia E63 (modelo S60 disponível), fez-se a instalação da
aplicação empacotada correta e automaticamente, por meio dos recursos
próprios do modelo e de conexão com PC via USB.
A execução da aplicação é feita via menu principal do sistema operacional,
sem maiores dificuldades.
A navegação apresentou-se muito simples e tranquila e a tradução para
LIBRAS ocorre perfeitamente de acordo com a MT cadastrada.
A apresentação dos vídeos possui o tempo de resposta adequado e sua
visualização é muito boa.
Na web, apesar da função principal desta aplicação ser ilustrativa, a mesma
pôde ser acessada via WebBrowser Internet Explorer, Google Crome e Mozila
FireFox sem qualquer restrição e mantendo totalmente seus recursos
funcionais e visuais.
Assim sendo, vemos a implementação de um sistema portável para tradução
Português para LIBRAS é totalmente viável e eficiente.
P á g i n a | 106
Capítulo 5
Considerações finais
Neste capítulo são apresentadas, as análises de portabilidade e escalabilidade
bem como as considerações finais a respeito deste trabalho.
5.1 Análise de portabilidade
Considerando que atualmente há uma vasta quantidade de dispositivos móveis
em funcionamento e disponíveis no mercado, está claro que apesar deste
trabalho se limitar a um grupo específico de dispositivos móveis, é possível
expandir esta ideia para uma diversa gama de outros dispositivos e
plataformas.
5.1.1 Portablidade para dispositivos móveis compativeis com
plataforma J2ME
O MIDLet SOTAC-Mobile está codificado em J2ME e usa alguns recursos que
não estão presentes em todos os dispositivos compatíveis com J2ME. Desta
forma nem todos os dispositivos compatíveis com J2ME são capazes de
executar o MIDLet SOTAC-Mobile.
Dentre o conjunto dos dispositivos compatíveis com J2ME, todos aqueles que
possuírem JSR-118, JSR-135e JSR-139 são capazes de executar o MIDLet
SOTAC-Mobile. Para tanto, faz-se necessário gerar uma nova compilação do
aplicativo, vinculando a ela a SDK do conjunto dos dispositivos selecionados.
Por exemplo, considerando os dispositivos Nokia séries S40, uma série de
dispositivos mais antiga, é fato que nem todos os seus dispositivos desta série
podem executar o MIDLet SOTAC-Mobile, porém para a série S80, bem mais
recente, vemos que a maioria de seus dispositivos podem executar o MIDLet
SOTAC-Mobile.
P á g i n a | 107
Para dispositivos de outros fabricantes como a Samsung, Motorola e outros, a
regra é a mesma, é necessário observar suas especificações, ou seja; desde
que sejam compatíveis com J2ME e possuam recursos JSR-118, JSR-135 e
JSR-139, podem executar normalmente o MIDLet SOTAC-Mobile.
A seguir alguns exemplos de dispositivos que podem executar o MIDLet
SOTAC-Mobile, baseados em testes feitos com base em seus SDKs e usando
os seus respectivos emuladores (não foram executados testes nos dispositivos
fisicamente, por questões de viabilidade do recurso).
Figura 5.1 – Nokia S40 Asha 311 e LG C205 podem executar o MIDLet SOTAC – Mobile.
Para alguns dos dispositivos móveis compatíveis com J2ME que não possuam
todos os recursos JSR-118, JSR-135 e JSR-139, provavelmente é possível
também executar o MIDLet SOTAC-Mobile, mas são necessários ajustes no
código e isso depende muito de cada especificação. Como isso não está
testado, não há garantia nestes casos.
5.1.2 Portabilidade para dispositivos móveis com Android
A plataforma Android possui alguns recursos Java, mas não é totalmente
compatível com J2ME. Assim, para suprir esta diferença, há alguns emuladores
J2ME, também conhecidos como J2ME Runners, capazes de executar
aplicações J2ME no Android.
Na realidade os J2ME Runners, funcionam como máquinas virtuais J2ME
dentro do Android e normalmente não executam corretamente todas as
funções J2ME, fazendo com que os aplicativos não funcionem corretamente.
Isso ocorre principalmente nos processos de conexão via socket.
P á g i n a | 108
Como o MIDLet SOTAC-Mobile usa recursos Arcademis/RME baseados em
conexão via socket, faz se necessário avaliar e testar o MIDLet SOTAC-Mobile
nestas condições antes de determinar a portabilidade real desta solução.
Outra opção é gerar uma nova interface voltada para a plataforma Android de
forma nativa. Neste caso há a necessidade de verificar a capacidade desta
aplicação em acessar a Camada de Serviços RMI. Há algumas soluções para
esta questão, mas também precisam ser avaliadas e testadas antes de
determinar a portabilidade real desta solução.
Certamente é mais interessante para o futuro partir para outras opções de
desenvolvimento como a utilização de SOA (WebServices e SOAP).
Nestes casos a Camada de Serviço RMI é afetada, necessitaria de substituição
ou manutenção. Porém o mais adequado é adicionar novas camadas de
serviço de forma paralela à atual camada RMI, desta forma não há
necessidade de manutenção nas atuais interfaces que estão em J2ME.
CAMADA DE INTERFACE
CAMADA DE INTERFACE
Aplicações web, ou móveis
J2ME
Aplicações web, ou outras
plataformas móveis
CAMADA DE SERVIÇO RMI
CAMADA DE SERVIÇO SOA
Serviço RME
WebService
SOTAC-Mobile
SOTAC-WMobile
SOTAC-EMobile
CAMADA DE NEGÓCIO DO SOTAC
Funções de login e tradução
BANCO DE DADOS
memoriatraducao
Figura 5.2 – Exemplo de novas possíveis camadas para o SOTAC-Mobile.
As opções acima citadas são ideias para trabalhos futuros.
POSTGRESS
P á g i n a | 109
5.1.3 Portabilidade para dispositivos móveis com Windows
Mobile ou Windows Phone
Em geral a plataforma Windows Mobile ou Windows Phone é compatível com
J2ME, e isto está diretamente relacionado ao fabricante do dispositivo.
Portanto, da mesma maneira ao que já mencionado anteriormente se faz
necessário a aplicação de SDKs específicos dos fabricantes dos dispositivos
para recompilar o MIDLet SOTAC-Mobile para execução em Windows.
Como o MIDLet SOTAC-Mobile não usa nenhum recurso específico dos
dispositivos Nokia S60, a portabilidade não exige manutenções maiores. Porém
é interessante que faça uma avaliação e testes com relação a este caso, sendo
também uma proposta de trabalho futuro.
Em se tratando de versões mais antigas da plataforma Windows, ou seja, do
Windows CE, há diversas Máquinas Virtuais Java para esta plataforma no
mercado. Porém devido às limitações dos dispositivos móveis que usam
Windows CE, que são mais antigos, provavelmente não seja possível executar
o MIDLet SOTAC-Mobile na maioria deles. Há que se testar em trabalho futuro.
Um aspecto interessante a se citar, é que a plataforma Symbian está sendo
abandonada pela Nokia, em prol da plataforma Windows Phone. Isto significa
dizer que todos os aplicativos J2ME para Symbian que atualmente existem no
mercado em breve devem ser migrados caso se deseje mantê-los.
5.1.4 Portablidade para dispositivos móveis BlackBerry
Em geral a plataforma BlackBerry é compatível com J2ME. Portanto, da
mesma maneira ao que já mencionado anteriormente se faz necessário a
aplicação de SDKs específicos do fabricante, neste caso a RIM, para
recompilar o MIDLet SOTAC-Mobile para execução em BlackBerry.
Em geral os aplicativos J2ME quando executados no BlackBerry, não tem
acesso à maioria dos recursos próprios destes dispositivos, isto significa dizer
P á g i n a | 110
que para aplicações onde estes recursos são exigência o melhor e desenvolver
diretamente para a plataforma, ou seja nativamente.
Mas como o MIDLet SOTAC-Mobile não usa nenhum recurso específico dos
dispositivos Nokia S60, portar o MIDLet SOTAC-Mobile para a plataforma
BlackBerry não requer maiores manutenções. Porém é interessante que faça
uma avaliação e testes com relação a este caso, sendo também uma proposta
de trabalho futuro.
5.1.5 Portabilidade para dispositivos Apple
A plataforma Apple é totalmente diferente do que, até o momento, se discutiu e
testou no presente trabalho. Como o desenvolvimento para esta plataforma
requer ambiente Apple, se faz necessário criar uma nova interface.
Faz-se então necessário recodificar o MIDLet SOTAC-Mobile para o ambiente
nativo Apple. Porém, uma questão importante relacionada aos aplicativos para
plataforma Apple, está na necessidade de registro e pagamento de comissão
de 30% cobrada pela Apple.
Esta abordagem é uma proposta bastante interessante para o futuro.
5.1.6 Portabilidade para dispositivos de outras plataformas
Recaímos neste caso para a mesma questão, cada plataforma tem seus
aspectos particulares, devendo portanto para cada qual verificar-se a
viabilidade do projeto.
O aspecto mais importante é a relação custo benefício, que deve ser avaliada
quando se trata de desenvolvimento em plataformas móveis de pouca
expressão no mercado. Em especial, porque a tendência do mercado a partir
de 2012, é ficar restrito às plataformas Android, Windows Mobile ou Windows
Phone, Apple e com menor expressividade o BlackBerry.
Outra ideia interessante, e viabilizar a utilização do SOTAC-Mobile em outras
plataformas Java embarcadas, como TV, dispositivos automotores, dispositivos
P á g i n a | 111
de posicionamento global (GPSs) entre outros. Em todos estes casos a
plataforma Java (J2ME) já é uma realidade o que possibilita novas abordagens.
Logicamente a interface de cada caso é item de estudo e testes em trabalhos
futuros, mas a possibilidade de executar o SOTAC-Mobile em tão vasta gama
de dispositivos é extremamente interessante, levando-se em conta que
somente faz-se necessário trabalhar na Camada de Interface.
Dar ao DA a possibilidade de comunicação com todos estes dispositivos é uma
realidade muito próxima.
5.2 Análise de escalabilidade
Há várias possibilidades de expansão do sistema SOTAC-Mobile. A seguir
apresenta-se as ideias mais promissoras.
5.2.1 Expansão do SOTAC de forma completa para a web
Neste trabalho já está criado um pequeno site, no qual é possível executar
traduções pela web. Portanto é totalmente viável expandir este site de forma a
permitir o acesso a toda camada de negócios do SOTAC.
A respeito desta expansão temos três questões básicas a considerar:

Manter apenas a abordagem RMI atual.

Partir também para uma abordagem usando SOA.
Em ambos os casos a solução passa pelo que já está feito neste projeto, onde
necessita-se adicionar, ou melhor traduzir, todas as funções de negócio e
persistência do SOTAC para o SERVLet SOTAC-EMobile. Adições na Camada
de Negócios.
Porém, no primeiro caso faz-se necessário criar as interfaces RMI necessárias
para a manipulação das mesmas, fazendo-se da mesma forma como está feito
para as funções de login e tradução apresentadas neste projeto. Adição na
Camada de Serviços RMI.
P á g i n a | 112
A seguir parte-se para toda a interface web, e uso de todos os recursos do
SOTAC via Internet, seguindo o que já está feito neste projeto de forma
bastante simples para as traduções e login.
No segundo caso, há a necessidade da criação de uma segunda Camada de
Serviços para gerenciar as questões relacionadas a WebService. A criação de
WebServices em Java é relativamente normal e não traz problemas em termos
das adições a serem implementadas. Adição da Camada de Serviços SOA,
vide a figura 5.2.
Por fim então pode-se fazer toda a interface web, para uso de todos os
recursos do SOTAC, via Internet . Neste caso usa-se os serviços WebService
disponíveis na nova Camada de Serviços WS criada.
Outro aspecto é verificar o desempenho destas soluções comparativamente, o
que pode ser outra questão de estudo.
5.2.2 Melhoramento do SOTAC-Mobile no processo de seleção
das Memórias de Tradução
Na medida em que todas as funcionalidades do SOTAC estiverem disponíveis,
independentemente do uso de SOA ou RMI, as Memórias de Tradução estão
disponíveis para manipulação.
Isto significa dizer que o SERVLet SOTAC-WMobile, pode ter acesso ao
cadastro e manipulação das Memórias de Tradução, assim como o uso das
mesmas exatamente como o SOTAC original, tanto na web como em
dispositivos móveis.
No caso da web estamos tratando de uma aplicação similar ao SOTAC, que
pode executar todas as suas funcionalidades, isso inclui a persistência e o uso
das MT nas traduções.
Já para dispositivos móveis, é mais adequado a criação de uma outra interface
para gerenciar as funções administrativas do SOTAC. Quer dizer, trabalhar
P á g i n a | 113
separadamente com os perfis de usuário "Administrador" ou "Colaborador".
Isso evita aumentar a complexidade do MIDLet SOTAC-Mobile, que está criado
para usuários DA.
Neste caso é interessante notar que pode-se adicionar a opção de seleção de
Memórias de Tradução no atual MIDLet SOTAC-Mobile, tornando-o igual à
aplicação web, e consequentemente igual ao SOTAC original, neste quesito.
5.2.3 Futura utilização de SOA.
No projeto atual a Camada de Serviços utiliza RMI para integração entre a
Camada de Negócio e a Camada de Interface dos sistema. Porém, é possível o
uso de SOA, e para tanto é necessário a adição de uma nova da camada de
serviços para gerenciar os WebServices, como já mencionado anteriormente.
O uso de SOA, abre um leque de possibilidades, permitindo a expansão da
Camada de Interface, para diversas outras plataformas e tornando o SOTACMobile um sistema extremamente portável, especialmente porque é possível
manter a abordagem RMI atual rodando paralelamente à abordagem SOA.
É interessante salientar que ambas abordagens devem andar paralelamente,
até porque nem todos os dispositivos móveis possuem recursos para uso de
WebServices e manipulação de arquivos no formato XML. Isto significa dizer
que as abordagens de Serviço RMI e SOA são na realidade complementares
no sentido de atingir o maior volume de plataformas.
Como a Camada de Serviços não interfere no funcionamento das camadas
mais abaixo, todo o sistema pode ser modular e distribuído fisicamente em
diferentes ambientes. Até mesmo as diferentes Camadas de Serviço podem
estar em ambientes distintos, o que é bastante interessante pois podemos até
mesmo criar formas para balancear os recursos físicos para distribuir melhor o
serviço prestado.
Em um projeto futuro pode-se adicionar a abordagem SOA ao SOTAC-Mobile e
simultaneamente complementá-lo tanto na web como em uma outra plataforma
P á g i n a | 114
móvel como o Android ou em uma outra plataforma embarcada por exemplo de
TV.
5.2.4 Integração do SOTAC-Mobile com soluções de animação
2D ou 3D
Há diversos trabalhos com animações para LIBRAS, usando-se Avatares
(figuras humanas animadas para animações), estes trabalhos estão baseados
no melhoramento da forma de armazenamento e transporte dos vídeos. Como
exemplo pode-se consultar o projeto POLI-LIBRAS de Januário et. al. (2010),
no qual uma destas ideias é apresentada.
Isto pode tornar-se uma adição interessante ao projeto. E abre as portas para
que os vídeos possam ser substituídos por animações 2D ou 3D.
Neste caso, com o uso de XML e/ou de computação gráfica, pode criar-se um
padrão em XML para geração das traduções do texto em LIBRAS,
possibilitando maior velocidade de tradução. Cabe então à aplicação,
interpretar o XML de retorno da tradução e a partir dele gerar as animações
adequadas por meio dos Avatares.
A principal vantagem desta forma de exibição de LIBRAS é tornar a tradução
mais impessoal o que melhora o entendimento e a comunicação com o DA.
Outra vantagem é que torna-se desnecessário o uso de muitos recursos de
transmissão de dados, players e codecs, na medida em que as interfaces não
mais necessita exibir arquivos de vídeo.
As desvantagens do uso de Avatares são algumas, e dentre elas temos
primeiramente a incapacidade de dispositivos móveis mais antigos se
utilizarem dos recursos de animação 3D. Por outro lado, em geral; todo
dispositivo móvel capaz de executar jogos pode executar animações 2D, porém
estes perdem muito da linguagem LIBRAS pois alguns sinais em 2D podem
ficar confusos para o DA.
P á g i n a | 115
Depois há que se verificar se as diferenças entre os dispositivos móveis alvo
requerem muito tratamento de fabricante para fabricante, ou se o mesmo
código pode ser portável de um dispositivo para outro. Logicamente estamos
tratando, neste caso, de cada uma das plataformas individualmente. Por
exemplo; qual a possibilidade de portabilidade de código entre dispositivos
diferentes que usam uma mesma plataforma Android ou J2ME ou BlackBerry.
Há também questões inerentes à animação em si, como o caso da influência
das expressões faciais em LIBRAS. Como estas questões precisam ser
visualizadas em dispositivos móveis com recursos visuais reduzidos.
De certa forma a tendência é que os novos dispositivos móveis do mercado
possam lidar com isso facilmente e esta evolução venha em breve.
5.2.5 Futura migração do sistema para HTML5 e WAP
A linguagem HTML5 (Hypertext Markup Language, versão 5) é a nova versão
da linguagem de marcação de hipertexto HTML, que teve sua primeira
especificação divulgada em 2008 pela W3C.
Há uma série de adições a esta versão de HTML, voltadas para
desenvolvimento de aplicações web com a finalidade de recuperar o terreno
perdido nestes últimos tempos.
Devido a uma série de limitações o desenvolvimento em HTML, sempre
dependeu de outros recursos, o quê com esta nova versão propõe-se, sejam
padronizados.
Outra questão em que o HTML5 aparece com grande força é no
desenvolvimento de aplicações web para dispositivos móveis. Apesar do
HTML5 não substituir todos os recursos das plataformas nativas, ele vem com
grande força já que oferece portabilidade total, ou seja; uma aplicação web
escrita em HTML5 pode rodar em qualquer dispositivo móvel, desde que seu
WebBrownser assim o permita.
P á g i n a | 116
Em breve todos os dispositivos móveis do mercado aceitarão HTML5 assim
como os mais atuais dispositivos da linha Apple e Samsung Galaxy.
Uma proposta futura de implementar todas as funcionalidades do SOTAC e
SOTAC-Mobile em HTML5, assim flexibilizando e facilitando o uso geral de
seus recursos pelos DA.
Esta abordagem, também pode ser disponibilizada de forma paralela à
abordagem atual, pois também atua na Camada de Interface.
5.3 Conclusão
A principal conclusão deste trabalho está na validação da real possibilidade do
uso de técnicas de tradução em toda a sua gama de possibilidades em
ambientes variados e móveis.
Tais considerações são uma porta nova para a inclusão social dos DA no
mundo digital, podendo inclusive estender-se a outros tipos de linguagens,
idiomas e dispositivos.
P á g i n a | 117
Referências
LIBRAS.
Língua
Brasileira
de
Sinais.
Disponível
em:
http://www.libras.org.br/libras.php. Acessado em: setembro de 2011.
BREDA, W. L. Um ambiente para apoio à tradução baseado em conhecimento
– Estudo de caso com Português – LIBRAS. Dissertação (Mestrado) –
Universidade Federal do Espírito Santo, 2008.
BREDA, W L. Projeto FALIBRAS-MT – Um sistema para autoria e uso de
tradutores automáticos Português - LIBRAS. Dissertação (Bacharelado) –
Universidade Federal do Espírito Santo, 2005.
TAVARES, O. L.; CORADINE, L. C.; BREDA, W. L. FALIBRAS.MT. Autoria de
tradutores automáticos de texto do português para libras, na forma gestual
animada: Uma abordagem com memória de tradução. XXV Congresso da
Sociedade Brasileira de Computação 2005.
TAVARES, O. L.; CORADINE, L. C.; et al. Sistema FALIBRAS: Um intérprete
virtual, como ferramenta de apoio pedagógico à educação de surdos.
Universidade Federal de Alagoas, 2002.
CORADINE, L. C.; ALBUQUERQUE, F. C.; et al. Interpretação de pequenas
frases com análise léxica no sistema FALIBRAS: Tradutor do português para a
LIBRAS. III Fórum de informática aplicada a pessoas portadoras de
necessidades especiais – CBComp 2004.
FRANCO, M. N.; SILVA, W. L. A.; BRITO, P. H. S. FALIBRAS-WEB : Uma
proposta de inclusão social para surdos. Universidade Federal de Alagoas.
CORADINE, L. C. BRITO, P. H. S; SILVA, R.L; SILVA, T. F. L.; CUNHA, F;
Estruturação da Linguagem LIBRAS em Computador a Partir de um Locutor
P á g i n a | 118
Externo - Sistema FALIBRAS. Projeto FAPEAL / UFAL (Iniciação Científica),
2002.
JANUÁRIO, G. C. LEITE, L. A. F. KOKA, M.L. Projeto POLI-LIBRAS – Um
tradutor de Português para LIBRAS. Dissertação (Bacharelado) – Escola
Politécnica de São Paulo, 2010.
RYBENÁ, Player. Comunicação priorizando a acessibilidade. Instituto CTS.
Disponível em: http://www.rybena.com.br/default/index.jsp. Acessado em:
setembro de 2011.
LIRA, G. de A. Projeto TLIBRAS – Tradutor Português x LIBRAS. Disponível
em:
http://www.acessobrasil.org.br/index.php?itemid=39
e
http://www.acessobrasil.org.br/libras/. Acessados em: outubro de 2011.
NIRENBURG, S. "Knowledge and Choices in Machine Translation". Machine
Translation. Org. Sergei Nirenburg. Cambridge, Cambridge University Press,
1987, pp. 1-15.
SLOCUM, J. "A Survey of Machine Translation: Its History, Current Status, and
Future Prospects". Machine Translation Systems. Org. Jonathan Slocum.
Cambridge, Cambridge University Press, 1985, pp.1-41.
TUCKER, A. B. "Current Strategies in Machine Translation Research and
Development". Machine Translation. Org. Sergei Nirenburg. Cambridge,
Cambridge University Press, 1987, pp. 22-41.
DECLARAÇÃO
UNIVERSAL
DOS
DIREITOS
HUMANOS,
adotada
e
proclamada pela resolução 217 A (III) da Assembleia Geral das Nações Unidas
em 10 de dezembro de 1948. Tradução oficial, UNITED NATIONS HIGH
COMMISSIONER
FOR
HUMAN
RIGHTS.
Disponível
http://portal.mj.gov.br/sedh/ct/legis_intern/ddh_bib_inter_universal.htm.
Acessado em setembro de 2011.
em:
P á g i n a | 119
BRASIL, LEI Nº 10.436/2002, DE 24 DE ABRIL DE 2002. Braslília Gabinete da
Presidência
da
República.
Disponível
http://www.planalto.gov.br/ccivil_03/Leis/2002/L10436.htm.
em:
Acessado
em
setembro de 2011.
BRASIL,
DECRETOS
Nº
6.583,
Nº
6.584,
Nº
6.585
e
Nº
6.586.
http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6583.htm,
http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6584.htm,
http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6585.htm,
http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6586.htm.
Acessados em outubro de 2012.
ABNT
(Associação
Brasileira
de
Normas
Técnicas).
Informação
e
documentação – citações em documentos – apresentação: NBR 10520. Rio de
Janeiro, 2002a.
ABNT
(Associação
Brasileira
de
Normas
Técnicas).
Informação
e
documentação – referências – elaboração: NBR 6023. Rio de Janeiro, 2002b.
IBGE (Instituto Brasileiro de Geografia e Estatística), Censo 2010, publicado no
Diário Oficial da União no dia 04 de novembro de 2010. Disponível em
http://www.censo2010.ibge.gov.br/. Acessado em setembro de 2011.
GARTNER. Disponível em HTTP://www.gartner.com. Acessado em setembro
de 2011.
ANATEL
(Agência
Nacional
de
Telecomunicações).
Disponível
em
Disponível
em
http://www.anatel.org.br. Acessado em setembro de 2011.
INES,
Instituto
Nacional
de
Educação
dos
Surdos.
http://www.ines.org.br. Acessado em setembro de 2011.
APACHE TOMCAT. Disponível em http://tomcat.apache.org/. Acessado em
abril de 2012.
P á g i n a | 120
ORACLE,
–
Java
J2ME.
Disponível
em
http://www.oracle.com/us/technologies/java/mobile/overview/index.html.
Acessado em abril de 2012.
SUN MICROSYSTEMS, Disponível em http://java.sun.com. Acessado em abril
de 2012.
SUN
MICROSYSTEMS,
RMI-op.
Disponível
em
http://java.sun.com/products/rmiop/. Acessado em abril de 2012.
MICROSOFT,
Windows
Mobile.
Disponível
em
http://www.microsoft.com/windowsmobile. Acessado em setembro de 2011.
Linguagem Python. Disponível em http://www.python.org. Acessado em
outubro de 2011.
TELECO,
Telefonia
Celular
no
Brasil.
Disponível
http://www.teleco.com.br/tutoriais/tutorialcelular/pagina_1.asp.
Acessado
em
em
setembro de 2011.
TELECO, Desenvolvimento de aplicações móveis com J2ME. Disponível em
http://www.teleco.com.br/tutoriais/tutorialj2me/pagina_1.asp.
Acessado
em
setembro de 2011.
TELECO,
Aparelhos
celulares.
Disponível
em
http://www.teleco.com.br/celprod.asp. Acessado em outubro de 2011.
NOKIA Developer. Disponível em http://www.developer.nokia.com. Acessado
em setembro de 2011.
NOKIA
E63,
Device
Especifications
em
http://www.developer.nokia.com/Devices/Device_specifications/E63/. Acessado
em maio de 2012.
P á g i n a | 121
LG
Developer.
Disponível
em
http://developer.lge.com/resource/mobile/RetrievePhoneList.dev. Acessado em
outubro de 2012.
Plataforma Symbian. Disponível em http://www.symbian.org. Acessado em
setembro de 2011.
Plataforma
Google
Android.
Disponível
em
http://developer.android.com/index.html. Acessado em setembro de 2011.
PALM / HP, Developer. Disponível em http://developer.palm.com. Acessado em
setembro de 2011.
Plataforma Samsung BADA. Disponível em http://www.bada.com. Acessado
em setembro de 2011.
Plataforma Meego. Disponível em http://meego.com. Acessado em setembro
de 2011.
NETBEANS. Disponível em http://netbeans.org/. Acessado em abril de 2012.
Open Mobile Alliance. Disponível em http://www.openmobilealliance.org.
Acessado em outubro de 2011.
ACCENTURE
noticias.
Disponível
em
http://newsroom.accenture.com/article_display.cfm?article_id=5191. Acessado
em setembro de 2011.
FALIBRAS.
Disponível
em:
http://www.falibras.tci.ufal.br
Acessado
em:
setembro de 2011.
http://www2.dcc.ufmg.br/laboratorios/llp/projects/arcademis
ASTAH Community. Disponível em http://astah.net/. Acessado em abril de
2012.
P á g i n a | 122
Amazon
Clowd
Computing.
Acessado em agosto de 2012.
Disponível
em
http://aws.amazon.com/pt/.
P á g i n a | 123
ANEXO A
LEI LIBRAS
LEI Nº 10.436, DE 24 DE ABRIL DE 2002.
Dispõe sobre a Língua Brasileira de Sinais - Libras e dá outras providências.
O PRESIDENTE DA REPÚBLICA Faço saber que o Congresso Nacional
decreta e eu sanciono a seguinte Lei:
Art. 1o É reconhecida como meio legal de comunicação e expressão a Língua
Brasileira de Sinais - Libras e outros recursos de expressão a ela associados.
Parágrafo único. Entende-se como Língua Brasileira de Sinais - Libras a forma
de comunicação e expressão, em que o sistema linguístico de natureza visualmotora, com estrutura gramatical própria, constituem um sistema linguístico de
transmissão de ideias e fatos, oriundos de comunidades de pessoas surdas do
Brasil.
Art. 2o Deve ser garantido, por parte do poder público em geral e empresas
concessionárias de serviços públicos, formas institucionalizadas de apoiar o
uso e difusão da Língua Brasileira de Sinais - Libras como meio de
comunicação objetiva e de utilização corrente das comunidades surdas do
Brasil.
Art. 3o As instituições públicas e empresas concessionárias de serviços
públicos de assistência à saúde devem garantir atendimento e tratamento
adequado aos portadores de deficiência auditiva, de acordo com as normas
legais em vigor.
Art. 4o O sistema educacional federal e os sistemas educacionais estaduais,
municipais e do Distrito Federal devem garantir a inclusão nos cursos de
formação de Educação Especial, de Fonoaudiologia e de Magistério, em seus
P á g i n a | 124
níveis médio e superior, do ensino da Língua Brasileira de Sinais - Libras, como
parte integrante dos Parâmetros Curriculares Nacionais - PCNs, conforme
legislação vigente.
Parágrafo único. A Língua Brasileira de Sinais - LIBRAS não poderá substituir a
modalidade escrita da língua portuguesa.
Art. 5o Esta Lei entra em vigor na data de sua publicação.
Brasília, 24 de abril de 2002; 181o da Independência e 114o da República.
FERNANDO HENRIQUE CARDOSO
Paulo Renato Souza
Texto publicado no Diário Oficial da União de 25.4.2002
P á g i n a | 125
ANEXO B
Sistema Móvel Celular no Brasil
Abaixo estão apresentadas a evolução da tecnologia móvel no Brasil.
Geração
1G
2G
2,5G
3G
Tecnologia
Largura de
banda (Hz)
30K
30K
1,25M
200K
200K
1,25M
200K
5M
1,25M
1,25M
5M
AMPS
TDMA
CDMA
GSM
GPRS
CDMA-2000 1x (1XRTT)
EDGE
WCDMA
CDMA-2000 1xEVDV
CDMA-2000 1xEVDO
HSDPA
Taxa de
transmissão (b/s)
≤ 16,2K
≤ 28,8K
≤ 28,8K
≤ 28,8K
≤ 64K – 144K
≤ 64K – 144K
≤ 384K – 2M
≤ 384K – 2M
≤ 384K – 2M
≤ 384K – 2M
≤ 384K – 10M
Tabela B.1 – Evolução da telefonia móvel no Brasil.
Outras tecnologias de telefonia celular não utilizadas no Brasil.
Geração
1G
2G
2,5G
Tecnologia
DECT
D-AMPS
PHS
HSCSD
Tabela B.2 – Tecnologias não usadas no Brasil.
O futuro da tecnologia móvel no Brasil está previsto para 2014, com o SMC de
quarta geração.
Geração
4G
Tecnologia
WiMax
WiBro
iBurst
LTE 3GPP
LTE 3GPP2 UMB
Tabela B.3 – O futuro da telefonia móvel no Brasil.
P á g i n a | 126
Abaixo estão apresentadas as operadoras de telefonia móvel no Brasil, sua
cobertura e região de atuação.
Figura B.1 – Presença das Prestadoras de telefonia móvel (ANATEL, 23/06/2009).
P á g i n a | 127
Abaixo o gráfico evolutivo (ao longo dos anos) dos terminas SMC habilitados no Brasil.
31.726
191.402
755.224
1.416.500
2.744.549
4.550.175
7.368.218
1991
1992
1993
1994
1995
1996
1997
1998
46.373.266
34.880.967
6.700
1990
28.745.769
667
1972
23.188.171
150
50.000.000
15.032.698
100.000.000
120.980.103
86.210.336
65.605.577
150.000.000
99.918.621
173.959.368
200.000.000
151.949.077
220.352.712
250.000.000
202.944.033
Terminais habilitados no Brasil
0
1999
2000
2001
2002
2003
2004
2005
Gráfico B.1 - Evolução do número de terminais habilitados no SMC no Brasil (ANATEL, 2011).
Ano
1972
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
Terminais
habilitados
150
667
6.700
31.726
191.402
755.224
1.416.500
2.744.549
4.550.175
7.368.218
15.032.698
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
Tabela B.4 – Evolução do número de terminais habilitados no SMC no Brasil (ANATEL, 2011).
23.188.171
28.745.769
34.880.967
46.373.266
65.605.577
86.210.336
99.918.621
120.980.103
151.949.077
173.959.368
202.944.033
220.352.712
2006
2007
2008
2009
2010
2011
P á g i n a | 128
ANEXO C
Acesso ao Protótipo
Abaixo estão os links onde são encontradas as implementações do protótipo
apresentado.
SERVLet SOTAC-EMobile (via SSH):
http://ec2-23-23-199-102.compute-1.amazonaws.com.
SERVLet SOTAC-WMobile:
http://ec2-23-23-175-86.compute-1.amazonaws.com/SOTAC-WMobile/.
MIDLet SOTAC-Mobile (instalação):
http://ec2-23-23-175-86.compute-1.amazonaws.com/SOTACWMobile/donwloads/SOTAC-Mobile%20-%20instalacao.rar.
Estes host serão mantidos até agosto de 2013, podendo haver extensão deste
prazo caso necessário.
Também estão disponíveis links para todos os recursos utilizados bem como
acesso às planilhas de testes de Breda (2008).