Projeto de Software para Internacionalização em Línguas de ... · Mundial da Saúde traduzido para Libras pela Faculdade Letras da Universidade Federal de Goiás (UFG), em parceria

UNIVERSIDADE FEDERAL DE GOIÁSINSTITUTO DE INFORMÁTICA

PAULO MARCOS SOARES RODRIGUES

Projeto de Software paraInternacionalização em Línguas de

Sinais

Goiânia2017

PAULO MARCOS SOARES RODRIGUES

Projeto de Software paraInternacionalização em Línguas de

Sinais

Dissertação apresentada ao Programa de Pós-Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emCiência da Computação.

Área de concentração: Ciência da Computação.

Orientador: Prof. Dr. Cássio Leonardo Rodrigues

Co-Orientadora: Profa. Dra. Neuma Chaveiro

Goiânia2017

2

Ficha de identificação da obra elaborada pelo autor, através doPrograma de Geração Automática do Sistema de Bibliotecas da UFG.

CDU 004

SOARES RODRIGUES, PAULO MARCOS Projeto de Software para Internacionalização em Línguas de Sinais[manuscrito] / PAULO MARCOS SOARES RODRIGUES. - 2017. xci, 91 f.: il.

Orientador: Prof. Dr. CÁSSIO LEONARDO RODRIGUES; coorientadora Dra. NEUMA CHAVEIRO. Dissertação (Mestrado) - Universidade Federal de Goiás, Institutode Informática (INF), Programa de Pós-Graduação em Ciência daComputação, Goiânia, 2017. Bibliografia. Apêndice. Inclui tabelas, lista de figuras, lista de tabelas.

1. língua de sinais. 2. internacionalização. 3. surdo. 4. arquitetura desoftware. 5. projeto de software. I. LEONARDO RODRIGUES,CÁSSIO, orient. II. Título.

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Paulo Marcos Soares Rodrigues

Tecnólogo em Redes de Comunicação, Instituto Federal de Educação – IFG,Goiânia

5

A minha família. Esposa, filhos e irmãos que sempre estiveram ao meu lado nashoras mais difíceis.

6

Agradecimentos

À minha esposa, Ivonilda Teixeira dos Santos, que de forma especial e carinhosame encorajou, corroborando nos momentos de dificuldades não me deixando desistir,quero agradecer também aos meus filhos Maria Eduarda, João Miguel e Arthur, quemesmo sem conhecimento sobre isso, me iluminaram e me ajudaram a prosseguir.

À todos os professores que me acompanharam durante o curso e em especial aomeu orientador, Cássio Leonardo Rodrigues, pelo suporte oferecido a mim, pelas suascorreções e incentivos.

Aos amigos e colegas pelo incentivo e pelo apoio constantes.Aos meus irmãos e irmãs que com muito carinho estiveram ao meu lado a cada

semestre, sustentando cada uma de minhas decisões.E não deixando de agradecer de forma grata e grandiosa aos meus pais Pedro

Rodrigues dos Santos e Maria Soares dos Santos, a quem eu rogo saudosamente em todasas noites por minha existência.

Enfim, agradeço a todas as pessoas que fizeram parte dessa etapa decisiva daminha vida.

7

O correr da vida embrulha tudo. A vida é assim: esquenta e esfria, aperta edaí afrouxa, sossega e depois desinquieta. O que ela quer da gente é coragem!

João Guimarães Rosa,Grande Sertão: Veredas.

Resumo

Soares Rodrigues, Paulo Marcos. Projeto de Software para Internacionaliza-ção em Línguas de Sinais. Goiânia, 2017. 91p. Dissertação de Mestrado. Insti-tuto de Informática, Universidade Federal de Goiás.

Este trabalho tem como objetivo desenvolver um projeto de software que permita ainternacionalização em relação às diversas línguas de sinais existentes. A Língua deSinais, além de ser um sistema linguístico, é um elemento de constituição do sujeitosurdo, agregando sua identidade e cultura. Por isso é tão importante que os conteúdos dossistema informatizados possam estar disponíveis também em línguas de sinais. A partir deuma revisão sistemática da literatura que evidenciou a ausência de métodos, ferramentasou técnicas que fizessem referências a internacionalização de softwares para línguas desinais, foi elaborado uma arquitetura de alto-nível e um projeto detalhado contemplandoos principais requisitos de qualidade. Os requisitos foram extraídos com a ajuda deprofessores, alunos e interpretes surdos e ouvintes da Faculdade de Letras/Libras daUniversidade Federal de Goiás (UFG). Como estudo de caso foi escolhido uma aplicaçãoWeb do questionário de qualidade de vida, originalmente proposto pela OrganizaçãoMundial da Saúde traduzido para Libras pela Faculdade Letras da Universidade Federal deGoiás (UFG), em parceria com a Universidade Federal do Rio Grande do Sul (UFRGS).Após a adequação da aplicação à internacionalização para língua de sinais, foi realizadouma análise estática de três versões da aplicação. A versão original, uma versão adequadaa internacionalização para línguas de sinais e uma terceira versão com a adição de mais deuma língua de sinal. As análises buscaram determinar os efeitos qualitativos da adequaçãoda aplicação original para a internacionalização para línguas de sinais e da adição de novastraduções a uma aplicação já adequada a arquitetura proposta.

Palavras–chave

<língua de sinais, internacionalização, surdo, arquitetura de software, projeto desoftware.>

9

Abstract

Soares Rodrigues, Paulo Marcos. . Goiânia, 2017. 91p. MSc. Dissertation. Ins-tituto de Informática, Universidade Federal de Goiás.

This work aims to develop a software design that allows internationalization in relation tothe different sign languages. The Sign Language, besides being a linguistic system, is anelement of constitution of the deaf subject, adding its identity and culture. By this reason,it is so important that the contents of the computerized systems can also be available insign languages. From a systematic review of the literature that showed the absence ofmethods, tools or techniques that made references to the internationalization of softwarefor sign languages, a high-level architecture and a detailed design were elaboratedcontemplating the main requirements of quality. The requirements were extracted with thehelp of teachers, students and deaf interpreters and listeners of the Faculdade de Letras /Libras of the Universidade Federal de Goiás (UFG). The case study is a Web applicationof the questionnaire about quality of life, wich was originally proposed by the WorldHealth Organization, translated to Libras by the Letters Faculty of the Federal Universityof Goiás (UFG), in partnership with the Federal University of Rio Grande do Sul UFRGS).After the adaptation of the application to the internationalization for sign language, astatic analysis of three versions of the application was performed. The original version,a version suitable for internationalization for sign languages and a third version with theaddition of more than one sign language. The analyzes sought to determine the qualitativeeffects of the appropriateness of the original application for the internationalization forsign languages and the addition of new translations to an application already suitable tothe proposed architecture.

Keywords

<Sign language, internationalization, deaf, software architecture, software de-sign.>

10

Sumário

Lista de Figuras 13

Lista de Tabelas 15

1 Introdução 161.1 Objetivos Gerais 201.2 Objetivos Específicos 201.3 Metodologia 21

1.3.1 Revisão Sistemática da Literatura 211.3.2 Levantamento de Requisitos 211.3.3 Estudo das Melhores Práticas e Padrões de Projetos de Software 221.3.4 Implementação da Proposta 22

2 Fundamentação Teórica 232.1 A Engenharia de Software 232.2 Arquitetura de Software 242.3 Internacionalização de Software e Localização de Software 252.4 Projeto de Software de Alto Nível 262.5 Estilos arquiteturais 262.6 Catalogo de Padrões de Arquitetura 282.7 Web Presentation Patterns 30

2.7.1 Model View Controller - MVC 302.7.2 Page Controller 312.7.3 Front Controller 322.7.4 Template View 332.7.5 Transform View 332.7.6 Two-Step View 342.7.7 Application Controller 35

2.8 Trabalhos Relacionados 36

3 Trabalho Proposto 383.1 Requisitos Arquiteturais 383.2 Proposta de Arquitetura 383.3 Escolhas Arquiteturais 39

3.3.1 A Arquitetura em Camadas 413.3.2 A Arquitetura MVC em Internacionalização Para Línguas de Sinais 41

3.4 Requisitos de Projeto 433.5 Escolhas de Projeto 443.6 Como Utilizar a Biblioteca signlang.js 45

3.7 Projetos Novos 483.8 Projetos em Produção 48

4 Resultados 504.1 O Questionário de Qualidade de Vida Como Estudo de Caso 514.2 Alterações Realizadas na Aplicação Original 524.3 Ferramentas Para Análises Estáticas 57

4.3.1 A Ferramenta PHPMetrics 574.3.2 A Ferramenta Plato 58

4.4 Metodologia Utilizada nas Análises 594.5 Análise Geral 604.6 Análise Detalhada 64

4.6.1 Análise Biblioteca signlang.js 644.6.2 Análise Códigos PHP 66

4.7 Resumo da Análise 68

5 Conclusão 695.1 Limitações 695.2 Trabalhos Futuros 70

Referências Bibliográficas 71

A Revisão Sistemática da Literatura 76A.1 Planejamento 76A.2 Condução 77

A.2.1 Seleção 78A.2.2 Extração 79A.2.3 Q1 - Como a Engenharia de Software tem apoiado surdos utilizadores de

línguas de sinais? 80A.2.4 Q2 - Quais áreas de conhecimento (knowledge areas - KA) do SWEBoK são

abordadas? 80A.2.5 Q3 - Quais abordagens (por exemplo: ferramentas, processos, metodologias,

etc.) foram usados pelos artigos identificados na RS? 82A.2.6 Q4 - Quais LS (por exemplo: Libras, ASL, etc) foram utilizadas pelos artigos

identificados na RS? 83A.3 Resultados da Revisão (Documentação) 84

B Internationalization I18n, Localization L10n e Multilingual Software 85B.1 Introdução 85B.2 O que é Internacionalização, Localização e Software Multilingual 85B.3 A Internacionalização 86

B.3.1 URI 86B.3.2 Encoding 86

B.4 Unicode 87B.5 Conjunto de Tags para Internacionalização W3C 88

C A Biblioteca signlang.js 89

12

Lista de Figuras

1.1 Representação do alfabeto manua em Libras 171.2 Representação do alfabeto manual em língua grega de sinais 171.3 Representação do alfabeto manual em língua italiana de sinais 181.4 Representação do alfabeto manual em língua japonesa de sinais 18

2.1 Perguntas e respostas acerca da Engenharia de Software segundo IanSommerville 24

2.2 Estilos arquiteturais segundo M. Shaw e D. Garlan 272.3 Estilos arquiteturais segundo Martin Fowler 292.4 Abordagem MVC criada por Glenn E. Krasner Stephen T. Pope para a

linguagem Smalltalk-80 302.5 Padrão arquitetural Page Controller 312.6 Padrão arquitetural Front Controller 322.7 Padrão arquitetural Template View 332.8 Padrão arquitetural Transform View 342.9 Padrão arquitetural Two-Step View 352.10 Padrão arquitetural Application Controller 362.11 Letras do alfabeto romano e do alfabeto cirílico 37

3.1 Arquitetura sugerida 403.2 Representação conceitual do modelo MVC para o projeto de i18n para LS 423.3 Exemplo da estrutura sugerida. 48

4.1 Estrutura de pastas original 524.2 Estrutura de pastas após a criação da pasta i18n 534.3 Estrutura de pastas após a criação da pasta midia 544.4 Estrutura da aplicação com e sem arquivos do módulo de demonstração 564.5 Exemplo da página principal da ferramenta PHPMetrics 584.6 Exemplo da página principal da ferramenta plato 594.7 Quantidade total de linhas de código e a respectiva média por arquivo .js 604.8 Quantidade total de linhas de código para a biblioteca signlang.js 614.9 Quantidade total de linhas de código utilizado na aplicação original (P) e

a respectiva média por arquivo .js 624.10 Métricas gerais da aplicação (P) 634.11 Métricas gerais da aplicação (P’) e (P”) 634.12 Índice de manutenibilidade apresentada pela ferramenta plato para a

biblioteca signlang.js 644.13 Índice de dificuldade de se escrever ou entender o código 65

4.14 Análise comparativa entre complexidade e quantidades de linhas de có-digo da função setSignLang 65

4.15 Estimativa de error avaliada pela ferramenta plato 664.16 Métricas qualitativas referente a aplicação (P) 66

(a) fig:estrutura-demo 66(b) fig:estrutura-semdemo 66

4.17 Métricas qualitativas referente a aplicação (P’) e (P”) 67

B.1 Encodings mais utilizados em websites no ano de 2015 87

14

Lista de Tabelas

2.1 Responsabilidade de cada camada do modelo em 3-camadas 29

4.1 Comparação entre a quantidade total de linhas de código .js da aplicaçãooriginal para as versões alteradas 62

4.2 Tabela comparativa entre as métricas qualitativas das aplicações (P), (P’)e (P”). 67

A.1 Artigos obtidos por biblioteca digital 78A.2 Classificação geral dos trabalhos após a seleção 78A.3 Classificação dos artigos conforme suas prioridades de leituras 79A.4 Resultado da etapa de extração 79A.5 Resultado da etapa de extração por prioridade de leitura 79A.6 Áreas de conhecimento do SWEBoK contempladas pelos artigos da RS 81A.7 Principais abordagens utilizadas nos artigos da RS 82A.8 Principais Línguas de Sinais utilizadas pelos artigos da RS 83

CAPÍTULO 1Introdução

A Organização Mundial da Saúde (OMS) estima que, em todo o mundo, existammais de 360 milhões de pessoas que possuam algum tipo de surdez. Isso representa5% da população mundial [40]. E para a pessoa surda interagir com o mundo se faznecessário a utilização de meios visuais, principalmente as Línguas de Sinais (LS).As LSs não derivam das línguas orais, mas fluíram de uma necessidade natural decomunicação entre pessoas que não utilizam o canal auditivo oral, mas o canal espaçovisual como modalidade linguística [45]. É importante ressaltar que as pessoas surdasnão têm, obrigatoriamente, problemas cognitivos. Essa concepção parte do fato de que osurdo não compreende plenamente as línguas orais, mesmo na forma escrita [15].

A LS, além de ser um sistema linguístico, é um elemento de constituição dosujeito surdo, agregando sua identidade e cultura [15]. Para Quadros [20], as LSs sãoconsideradas línguas naturais e, consequentemente, compartilham uma série de caracte-rísticas que lhe atribuem caráter específico que as distinguem dos demais sistemas decomunicação. Destacando ainda mais o caráter cultural da LS, não existe uma LS uni-versal. Cada país apresenta sua respectiva LS. Dessa forma, quando um surdo aprendeuma segunda LS, ele utiliza sinais com sotaque estrangeiro [14]. Partindo do principiode que uma língua é uma manifestação cultural de um povo, nada mais natural que tam-bém os meios computacionais possam representar essas manifestações na língua nativado usuário surdo.

Para exemplificar as diferenças entre as LSs, citamos a datilologia ou alfabetomanual, um sistema de representação, quer simbólica, quer icônica, das letras dos alfa-betos das línguas orais na sua forma escrita, porém, por meio das mãos [6]. Na Figura1.1 temos o alfabeto manua da LS em Língua Brasileira de Sinais (Libras), na Figura 1.2temos o alfabeto manual da LS grega de sinais, na Figura 1.3 temos o alfabeto manualda língua italiana de sinais, na Figura 1.4 o alfabeto manual da LS japonesa. Lembrandoque a datilologia é usada em muitas LSs, com vários propósitos: representar palavras(especialmente nomes próprios como: nome de pessoas, localidades, etc) que não têmsinal equivalente, ou para ênfase ou clarificação, ou ainda para ensinar ou aprender umadeterminada língua de sinais [6].

17

Figura 1.1: Representação do alfabeto manua em Libras

Extraído de: http://psicopedagogiaeducacao.blogspot.com.br/2010/04/alfabeto-manual.html

Figura 1.2: Representação do alfabeto manual em língua grega desinais

Extraído de: http://www.editora-arara-azul.com.br/imagens/paises/ Grecia.jpg

18

Figura 1.3: Representação do alfabeto manual em língua italianade sinais

Extraído de: http://www.editora-arara-azul.com.br/imagens/paises/ Italia.jpg

Figura 1.4: Representação do alfabeto manual em língua japonesade sinais

Extraído de: http://www.editora-arara-azul.com.br/imagens/paises/ Japao.jpg

19

Todas as línguas possuem diferenças quanto ao seu uso em relação à região, aogrupo social, à faixa etária e ao sexo. O ensino oficial de uma língua sempre trabalha coma norma culta, a norma padrão, que é utilizada na forma escrita e falada e sempre tomaalguma região e um grupo social como padrão. Atribuir às LSs o status de língua é porqueelas, embora sendo de modalidade diferente, possuem também estas características emrelação às diferenças regionais, socioculturais, entre outras [45] [6]. No Brasil, o direito àse comunicar em sua língua natural é garantida por lei. A LEI 13.146 DE 06 DE JULHODE 2015 [12], em seu Art. 63 diz:

“É obrigatória a acessibilidade nos sítios da internet mantidos por empresascom sede ou representação comercial no País ou por órgãos de governo,para uso da pessoa com deficiência, garantindo-lhe acesso às informaçõesdisponíveis, conforme as melhores práticas e diretrizes de acessibilidadeadotadas internacionalmente.”

O fato é que, a Internet tem aumentado o acesso da população a serviçospúblicos, entretenimento e informações em geral, mas o usuário surdo desses serviços,muitas vezes, se veem obrigados a consumir um conteúdo na língua oral escrita por faltade conteúdo em sua língua nativa. E a língua majoritária em sua modalidade escrita nemsempre é plenamente compreendida pelo usuário surdo, por se tratar de uma segundalíngua que não é perfeitamente assimilada [15]. Esse fato demonstra que nem todosos grupos de indivíduos estão integralmente contemplados no que o filósofo canadenseHerbert Marshall McLuhan chama de “Aldeia Global” 1.

Temos como exemplo uma aferição dos níveis da qualidade de vida dos povosao redor do mundo, criado pelo Grupo de Qualidade de Vida (GQV) da OMS. Umquestionário contendo 26 questões, sendo 2 questões gerais,com 7 no “Domínio Físico”,6 no “Domínio Psicológico”, 3 de “Relações Sociais” e 8 de “Meio Ambiente” [41]. AUniversidade Federal de Goias (UFG), em parceria com a OMS e a Universidade Federaldo Rio Grande do Sul (UFRGS), criou dois importantes instrumentos de avaliação deQualidade de Vida da OMS para Libras, o World Health Organization Quality of Life

(WHOQOL-Bref) e o Quality of Care and Quality of Life For People with Intellectual and

Physcal Disabilities: Integrated Living, Social Inclusion and Service User Participation

(WHOQOL-DIS).Parte deste projeto foi desenvolvida com apoio da Fundação de Amparo a Pes-

quisa do Estado de Goiás (FAPEG), no âmbito do projeto FAPEG-PPSUS (Edital 08/2009PPSUS FAPEG/SES/CNPq/MS 2009). Para um perfeito entendimento do questionário

1Herbert Marshall McLuhan, utiliza em seus livros (“A Galáxia de Gutenberg”(1962) e, posteriormente,em “Os Meios de Comunicação como Extensão do homem”(1964)) o termo Aldeia Global para descrevero mundo em mutação provocado pela revolução tecnológica da computação e telecomunicações.

1.1 Objetivos Gerais 20

por parte das pessoas surdas, o material precisou estar em um meio acessível e em umalinguagem que pudesse ser plenamente compreendida, pois é um questionário autoaplica-vel. Assim sendo, o material foi construído utilizando a plataforma web, com o auxílio deum interprete para cada pergunta do questionário. Os questionários foram traduzidos ape-nas para a Libras, mas entendemos que um único projeto de software, com elementos deInternacionalização, poderia facilitar o reaproveitamento da solução implementada para atradução de outras LSs, tais como: American Sign Language (ASL), Spanish Sign Lan-

guage (LSE), Japanese Sign Language (JSL), Chinese Sign Language (CSL) entre outras,tornando o desenvolvimento de aplicações globais mais produtivas para quem desenvolvee mais inclusivas para quem utiliza.

1.1 Objetivos Gerais

Diante do exposto anteriormente, o objetivo principal deste trabalho é elaborarum Projeto de Software que inclua a “Internacionalização” também no tocante àsLSs. Onde, com esforços de implementação reduzidos, seja possível alterar as LSsapresentadas aos usuários. E que seja aplicável também a softwares legados, cuja adificuldade na manutenção e na melhoria são agravados pela ausência de documentaçãoe, geralmente, por ter sido criado em uma tecnologia defasada em relação aos softwaresrecém desenvolvidos.

1.2 Objetivos Específicos

1. Projeto de Software de Alto Nível

(a) Levantamento dos requisitos funcionais e não-funcionais contendo as princi-pais demandas dos usuários surdos utilizadores de LS;

(b) Elaboração do Projeto de Software de Alto Nível;(c) Documentação das decisões de projetos adotadas, bem como as escolhas de

estilo arquitetural utilizado;

2. Projeto de Software Detalhado

(a) Elaboração do Projeto de Software Detalhado enfatizando os aspectos no quala Internacionalização em LS está imersa;

(b) Elaboração da especificação para o Projeto de Software Detalhado;(c) Implementação de uma “Biblioteca” para prover os requisitos de Internacio-

nalização no sentido de alteração das traduções.

1.3 Metodologia 21

1.3 Metodologia

Para o desenvolvimento dos objetivos deste trabalho foi utilizado uma RevisãoSistemática da Literatura, afim de conhecer o cenário atual, compreender o contexto e en-contrar os problemas em aberto. Formulados os objetivos, realizamos uma levantamentocom o grupo de estudo da Faculdade de Letras/Libras. Onde foram elencados os principaisrequisitos para a criação de um meio de internacionalização de software que contemplas-sem as LSs. Após o levantamento dos requisitos foi realizado um estudo sobre as melhorespráticas e padrões de projeto de software, para só então, ser realizado a implementação daproposta.

1.3.1 Revisão Sistemática da Literatura

Foi realizado uma Revisão Sistemática da Literatura (RS) A sobre como aEngenharia de Software tem apoiado o desenvolvimento de software para surdos. EstaRS foi realizada em parceria com outro mestrando, Antônio Carlos de Freitas Silva.

Uma RS pode ser vista como uma revisão da literatura mais ampla dos estudosprimários, com objetivo de identificar a quantidade, as pesquisas e resultados disponíveissobre um determinado assunto. Os resultados da RS podem ser utilizados por outrospesquisadores na realização de novos estudos [7].

Uma RS foi realizada seguindo o processo de condução definido por Kitche-nham [33]. A RS está dividida em 3 (três) fases: Planejamento, Condução e Dissemina-ção.

A fase de condução foi dividida em dois estágios: seleção dos artigos e extraçãode dados. A fase de seleção consiste em aplicar a estratégia de busca definida no protocolopara identificar os artigos disponíveis. Identificado os trabalhos, inicia a seleção aplicandoos critérios de inclusão e exclusão. A fase de extração consiste na leitura dos trabalhos naíntegra com o objetivo de responder as questões de pesquisa.

E por fim, na fase disseminação os dados extraídos são compilados respondendoas questões de pesquisa na forma de artigo científico sobre as áreas de conhecimento daEngenharia de Software segundo o SWEBoK. Nas próximas subseções são apresentadosas fases de planejamento, condução e a conclusão sobre a Engenharia de Requisitos.

1.3.2 Levantamento de Requisitos

Para alcançar os objetivos este trabalho desenvolveu um levantamento de requi-sitos. A eliciação dos requisitos contou com o auxilio de um grupo de pesquisa formadopor pesquisadores do Instituto de Informática (INF/UFG) e da Faculdade de Letras/Li-bras (FL/UFG). Por parte do INF, o grupo foi composto por um professor e dois alunos de

1.3 Metodologia 22

mestrado. Por parte da FL, o grupo foi composto por duas professoras e dois Tradutorese Intérpretes de Língua de Sinais (TILS).

1.3.3 Estudo das Melhores Práticas e Padrões de Projetos de Soft-ware

Durante a fase de estudos sobre as melhores práticas e padrões de Projetosde Software foram analisados trabalhos de autores como: Ian Sommerville [49], RogerPressman [43], Mary Shaw e David Garlan [18], John Yunke [54], Mark Richards [46],Erich Gamma, Richard Helm, Ralph Jonsone John Vlissides [27] e Martin Fowler [25]entre outros. A análise visou encontrar os padrões de Projetos de Software que melhorsolucionava o conjunto de requisitos levantados.

1.3.4 Implementação da Proposta

Para a validação da proposta foi implementado a solução de software sobre aaplicação Questionário de Qualidade de Vida em Libras. Devido as peculiaridades doprojeto original e ao conjunto de requisitos levantados a internacionalização em LS,optou-se por utilizar a linguagem de programação JavaScript para a implementação dabiblioteca utilizada nas traduções das LSs.

CAPÍTULO 2Fundamentação Teórica

2.1 A Engenharia de Software

O SWEBoK [11] entende a Engenharia de Software como sendo a aplicaçãode uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento,operação e manutenção de software. Para Ian Sommerville [49], Engenharia de softwareé uma disciplina de engenharia cujo foco está em todos os aspectos da produção desoftware, desde os estágios iniciais da especificação do sistema até sua manutenção,quando o sistema já está sendo usado. Segundo Ian Sommerville, há duas expressõesimportantes nessa definição:

1. Disciplina de engenharia. Engenheiros fazem as coisas funcionarem. Eles aplicamteorias, métodos e ferramentas onde for apropriado. No entanto, eles os usamseletivamente e sempre tentam descobrir as soluções para os problemas, mesmoquando não há teorias e métodos aplicáveis. Os engenheiros também reconhecemque devem trabalhar de acordo com as restrições organizacionais e financeiras,então buscam soluções dentro dessas restrições.

2. Todos os aspectos da produção de software. A engenharia de software não se preo-cupa apenas com os processos técnicos do desenvolvimento de software. Ela tam-bém inclui atividades como gerenciamento de projeto de software e desenvolvi-mento de ferramentas, métodos e teorias para apoiar a produção de software.

Como forma de ilustrar as definições de termos básicos da Engenharia deSoftware, Ian Sommerville criou uma tabela contendo perguntas e respostas com asdefinições e comparações que mais causam confusões e/ou duvidas em leitores iniciantes.Vide Figura 2.1.

2.2 Arquitetura de Software 24

Figura 2.1: Perguntas e respostas acerca da Engenharia de Soft-ware segundo Ian Sommerville

Extraído de: Software Engineering - International Computer Sci-ence Series. Ian Sommerville

2.2 Arquitetura de Software

O conceito de Arquitetura de Software surgiu nos anos 60 (com Dijkstra), mas setornou popular nos anos 90 [42]. Segundo Alexander L. Wolf [42], Arquitetura é soma dosElementos da Organização e das Decisões. É um conjunto de elementos arquiteturais (dedados, de processamento, de conexão) que possuem alguma organização. Os elementos esua organização são definidos por decisões tomadas para satisfazer objetivos e restrições.

Segundo Bass [8], a Arquitetura de Software é estrutura ou estruturas do sistema,que abrange os componentes de software, as propriedades externamente visíveis dessescomponentes e as relações entre elas. Para M. Shaw, D. Garlan [48], a arquitetura defineo que é o sistema em termos de componentes computacionais e, os relacionamentos entreestes componentes, os padrões que guiam a sua composição e restrições.

2.3 Internacionalização de Software e Localização de Software 25

2.3 Internacionalização de Software e Localização deSoftware

Para entender Internacioanlização é preciso entender o conceito de Localização,que para John Yunker [54], é o processo de modificar um produto para um determinadolocal. Isso inclui fazer modificações técnicas, visuais e textuais. Claro, um local é muitasvezes ligado a muito mais do que um idioma e país. Muitos sites oferecem um alto graude personalização, que requer “funcionalidade de localização”.

Já Internacionalização, John Yunker [54] define como sendo o processo deconstruir (ou reconstruir) um site que pode ser facilmente localizável. Em casos ondese planeja localizar o site para vários idiomas, a internacionalização pode poupar muitotempo e dinheiro porque isso força a criar um modelo que pode ser mais facilmentelocalizado.

Conforme a W3C 1, normalmente, a Internacionalização implica [51]:

• Projetar e desenvolver de forma a eliminar barreiras à localização ouimplantação internacional. Isso inclui coisas como habilitar o uso doUnicode (Vide Apêndice B) ou garantir o bom manejo de codificaçõesde caracteres legados, quando apropriado, cuidando a concatenaçãode strings, evitando a dependência no código de valores de string deinterface do usuário, etc.

• Fornecer suporte para recursos que não podem ser usados até a locali-zação ocorrer. Por exemplo, adicionando marcação em seu DTD 2 paracontemplar o texto bidirecional ou para identificar o idioma, ou adicio-nando suporte CSS3, para texto vertical ou outros recursos tipográficosnão latinos.

• Habilitando o código para permitir preferências locais, regionais, lín-guas ou culturalmente relacionadas. Normalmente, isso envolve a in-corporação de dados de localização predefinidos e recursos derivadosde bibliotecas existentes ou preferências do usuário. Os exemplos in-cluem formatos de data e hora, calendários locais, formatos numéricose sistemas numéricos, classificação e apresentação de listas, tratamentode nomes pessoais e formas de endereço, etc.

• Separando elementos localizáveis do código-fonte ou do conteúdo, demodo que as alternativas localizadas podem ser carregadas ou seleciona-

1Organização para a Padronização da World Wide Web(WWW)2Document Type Definition (Definição de Tipo de Documento - Utilizado para definir os blocos de um

documento XML)3Cascading Style Sheets - linguagem de estilo para a apresentação de um documento HTML

2.4 Projeto de Software de Alto Nível 26

das de acordo com as preferências internacionais do usuário conformenecessário.

Observe que esses itens não incluem necessariamente a localização do conteúdo, aplica-ção ou produto em outro idioma; São práticas de projeto e desenvolvimento de softwaresque permitem que tal migração ocorra facilmente no futuro, mas que pode ter utilidadesignificativa, mesmo que não haja localização alguma [51].

2.4 Projeto de Software de Alto Nível

Para Pressman [43], o projeto de software reside no núcleo técnico da engenhariade software e é aplicado independentemente do modelo de processo de software utilizado.Iniciando assim que os requisitos de software tiverem sido analisados e modelados, oprojeto de software é a última ação da engenharia de software da atividade de modelageme prepara as bases para a construção (geração de código e testes). A importância do projetode software pode ser definida em uma única palavra - qualidade. Projeto é a etapa em que aqualidade é incorporada na engenharia de software. O projeto nos fornece representaçõesde software que podem ser avaliadas em termos de qualidade.

Projeto é a única maneira em que podemos traduzir precisamente os requisitosdos interessados em um produto ou sistema de software finalizado. Sistemas grandessão, comumente, decompostos em subsistemas que fornecem algum conjunto de serviçosrelacionados. O processo inicial de projeto, que consiste em identificar esses subsistemas eestabelecer um framework para o controle e a comunicação de subsistemas, é denominadopor Sommerville [49] como sendo projeto de arquitetura ou projeto de software de altonível.

Por exemplo, linhas de produtos de aplicações são criadas com base em umnúcleo de arquitetura com variações que satisfazem os requisitos específicos do cliente.Ao projetar uma arquitetura, o arquiteto precisa decidir o que o sistema, módulos eentidades têm em comum, e decidir quanto conhecimento dessas arquiteturas de aplicaçãoé possível reusar [49] [25] [43].

2.5 Estilos arquiteturais

Os padrões arquiteturais foram propostos na década de 1990 com o nome de “es-

tilos arquiteturais” por M. Shaw e D. Garlan [48] [49]. Um estilo arquitetural define umafamília de sistemas em termos de um padrão de organização estrutural. Mais especifica-mente, um estilo arquitetural define um vocabulário de componentes e tipos de conectores,e um conjunto de restrições sobre como eles podem ser combinados [48]. De maneira a

2.5 Estilos arquiteturais 27

dirimir eventuais duvidas, citamos uma importante distinção que Sommerville [49] faz en-tre os termos arquitetura e projeto. Projeto é uma instância de uma arquitetura da mesmaforma que um objeto é uma instância de uma classe. Sendo assim, vários projetos podemser criados com base em uma única arquitetura. M. Shaw e D. Garlan divide os estilosarquiteturais em cinco grupos, conforme Figura 2.2.

Figura 2.2: Estilos arquiteturais segundo M. Shaw e D. Garlan

Extraído de: Software Architecture: Perspectives on an EmergingDiscipline - SHAW, M.; GARLAN, D. [48]

Sendo que sete estilos arquiteturais são considerados por M. Shaw e D. Garlancomo os mais comumente utilizados: pipes and filters, Objects, implicit invocartion,layering, repositories, interpreters e process control.

Para Mark Richards[46], é comum desenvolvedores começar a programar umaaplicação sem ter uma arquitetura formal. Sem uma arquitetura clara e bem definida, amaioria dos desenvolvedores e arquitetos vão recorrer ao padrão arquitetural tradicionalem camadas4 (também chamado de arquitetura n-camadas), criando camadas implícitas,separando módulos de código-fonte em pacotes. Infelizmente, o que muitas vezes resultadesta prática é uma coleção de código-fonte desorganizada e módulos que não têmpapéis claros de responsabilidades e relações uns com os outros [46]. Assim, MarkRichards apresenta 5 padrões de arquitetura como sendo os mais comumente utilizadospor desenvolvedores e arquitetos de software. São eles:

1. Layered Architecture ou arquitetura em camadas;2. Event-Driven Architecture, arquitetura orientada a eventos;3. Microkernel Architecture, arquitetura para a implementação de serviços mínimos

para sistemas operacionais;4. Microservices Architecture Pattern, arquitetura baseada em serviços REST -

Representational State Transfer5 para aplicações distribuídas;

4Correspondendo ao que M. Shaw e D. Garlan chamam de Hierarchical Layers ou simplesmenteLayering

5Em português - Transferência de Estado Representacional

2.6 Catalogo de Padrões de Arquitetura 28

5. Space-Based Architecture, padrão arquitetural que visa escalabilidade linear deaplicações stateful 6.

Martin Fowler, com base em seu conhecimento sobre as práticas de mercado,criou um catalogo de padrões arquiteturais para aplicações empresariais. Por ser a divisãoem camadas uma constante em aplicações empresariais, Fowler [25] subdividiu os prin-cipais padrões arquiteturais em 10 grande grupos, sendo a arquitetura em camadas a basepara todos os padrões catalogados. Os grupos de padrões de Fowler são:

1. Domain Logic Patterns2. Data Source Architectural Patterns3. Object-Relational Behavioral Pat-

terns4. Object-Relational Structural Pat-

terns5. Object-Relational Metadata Map-

ping Patterns6. Web Presentation Patterns7. Distribution Patterns8. Offline Concurrency Patterns9. Session State Patterns

10. Base Patterns

Ainda, segundo Martin Fowler, em comum à essas três maneiras de ordenar ospadrões arquiteturais temos a arquitetura em camadas como ponto pacífico. A divisãofacilita a organização lógica e física das responsabilidades e assegura que a manuten-ção ocorra pontualmente em determinada camada. Com a divisão, problemas maiores oude difícil compreensão são quebrados em problemas menores, com soluções mais razoá-veis.A arquitetura em camadas é, na maioria da aplicações empresariais, a base para osdemais padrões arquiteturais [25] [46]. Sendo assim, partimos desse padrão arquiteturalpara podermos elaborar a arquitetura sugerida. Uma arquitetura em camadas na qual ai18n em LSs ocorre na camada de apresentação. O que, seguindo o catalogo de padrõesarquiteturais criado por Martin Fowler, está representado pelo grupo Web Presentation

Patterns através do padrão MVC.

2.6 Catalogo de Padrões de Arquitetura

A essência do projeto de software é tomar decisões sobre a organização lógicado software. Embora cada sistema de software seja único, frequentemente sistemas deum mesmo domínio de aplicação têm arquiteturas similares que refletem os conceitosfundamentais do domínio. Essas arquiteturas de aplicação podem ser bastante genéricasou muito mais específicas [49]. Assim como Erich Gamma, Richard Helm, Ralph Jonson

e John Vlissides - também conhecidos como “A Turma dos Quatro”, ou GoF - do inglês:

6Aplicações que mantêm controle sobre os usuários durante a execução

2.6 Catalogo de Padrões de Arquitetura 29

Gang Of Four - catalogaram os principais padrões de projetos [27], Martin Fowler criouum catalogo de padrões arquiteturais para aplicações empresariais [25].

O catalogo de padrões concentra-se na arquitetura de aplicações empresariais nocontexto de uma arquitetura em 3 camadas: apresentação, domínio e dados. Vide Tabela2.1. A divisão em camadas é uma das técnicas mais comuns que projetistas de softwareutilizam para decompor um sistema de software complicado [25].

Tabela 2.1: Responsabilidade de cada camada do modelo em 3-camadas

Camadas Responsabilidade

ApresentaçãoPrestação de serviços, exibição de informações (por exemplo, no Windows ou HTML,manipulação da solicitação do usuário (cliques do mouse, teclado acessos),solicitações HTTP, invocações de linha de comando, lote API)

Domínio Ponto lógico real do sistema.Dados Comunicação com as bases de dados, sistemas de mensagens, gerenciadores de transações, outros pacotes

Fonte: Tabela criada pelo Autor

Por aplicações empresariais, podemos imaginar aplicações que manipulam umagrande quantidade de dados persistidos, em alguns casos, por vários anos. Normalmenteos dados são acessados concorrentemente por muitas pessoas, precisam integrar comoutras aplicações e os vários sistemas são geralmente construídos em épocas diferentes,com diferentes tecnologias [25]. O catalogo é composto por 10 grupos de padrõesarquiteturais, que estão divididos conforme Figura 2.3:

Figura 2.3: Estilos arquiteturais segundo Martin Fowler

Fonte: Mapa mental criado pelo Autor a partir dos estilos arquite-turais estudados por Martin Fowler

2.7 Web Presentation Patterns 30

2.7 Web Presentation Patterns

Devido as características intrínsecas da i18n para LS que aborda prioritariamentea camada de apresentação, utilizando o padrão MVC, a família de padrões da camada deaplicação para sistemas Web torna-se o foco desse trabalho.

2.7.1 Model View Controller - MVC

O MVC é um dos padrões mais citados (e um dos mais citados erroneamente)entre todos. Ele começou como um framework desenvolvido por Trygve Reenskaug

para a plataforma Smalltalk no final de 1970. Desde então, tem desempenhado umpapel influente na maioria dos frameworks de Interface de Usuários (UI, do inglês UserInterface) e no pensamento sobre o design da interface do usuário [25].

O padrão MVC é composto por três tipos de objetos. O Modelo (Model) é oobjeto de aplicação, a Visão (View) é a apresentação na tela e o Controlador (Controller)é o que define a maneira como a interface do usuário reage às entradas do mesmo. Antesda MVC, os projetos de interface para o usuário tendiam a agrupar esses objetos. O MVCsepara esses objetos para aumentar a flexibilidade e a reutilização [27]. A Figura 2.4,apresenta o padrão MVC como foi definido por Glenn E. Krasner Stephen T. Pope para alinguagem Smalltalk-80 [34].

Figura 2.4: Abordagem MVC criada por Glenn E. KrasnerStephen T. Pope para a linguagem Smalltalk-80

Extraído de: A cookbook for using the model-view controlleruserinterface paradigm in smalltalk-80. KRASNER, G. E.; POPE, S. T.

O padrão MVC também permite mudar a maneira como uma visão respondeàs entradas do usuário sem mudar sua apresentação visual. Por exemplo, pode-se querer


mudar a forma de como ela responde ao teclado ou fazer com que use um menu pop-up emlugar de teclas de comandos. O MVC encapsula o mecanismo de resposta em um objetoControlador. Existe uma hierarquia de classes de Controladores, tornando fácil criar umnovo controlador como uma variante de um existente [27] [34].

O MVC apresenta duas principais separações: separa a apresentação do modeloe separa o controlador da visão. O ponto chave dessa separação está na direção das depen-dências: a apresentação depende do modelo, mas o modelo não depende da apresentação.Sendo que a segunda divisão é menos óbvia, muitas vezes não sendo possível fazer dis-tinção clara entre o que é controlador e o quê é visão. O exemplo clássico do por quesepará-los é apoiar o comportamento editável e não editável, em que os controladores sãoestratégicos para a visão [25] [27] [34] [23].

2.7.2 Page Controller

O Page Controller é um objeto que processa um pedido para uma página ou açãoespecífica em um Web site, Figura 2.5 A ideia básica por trás de um Page Controller éter um módulo atuando sobre o servidor Web como um controlador para cada página nosite. Na prática, ele não funciona exatamente um por página, uma vez que às vezes vocêpode clicar em um link e obter uma página diferente dependendo de alguma informaçãodinâmica. Mais rigorosamente os controladores ligam-se a cada ação no site Web, quandohá uma ação de clicar em um link ou um botão.

Figura 2.5: Padrão arquitetural Page Controller

Extraído de: Padrões de Arquitetura de Aplicações Corporativas.BOOKMANCOMPANHIA ED, 2006. FOWLER, M.

Apesar do Page Controller ser uma solução possível, o padrão funciona particu-larmente bem em um local onde a maior parte da lógica do controlador é bastante sim-ples [25]. Em casos mais complexos, a arquitetura Page Controller pode ser substituídapelo MVC ou pelo padrão arquitetural Front Controller. Como a i18n para LS contém umelaborado controle de acesso às informações em LS, essa solução se apresenta inviabili-zada.


2.7.3 Front Controller

Um controlador que manipula todas as solicitações para um site, Figura 2.6. Emum site complexo, há muitas coisas semelhantes que precisam serem feitas ao manusearum pedido. Estas coisas incluem segurança, internacionalização e proporcionar visõesespecíficas para certos usuários. Se o comportamento do controlador de entrada estáespalhado por vários objetos, grande parte deste comportamento pode acabar duplicado.Além disso, é difícil mudar o comportamento em tempo de execução.

O Front Controller consolida todos os tratamentos das solicitações, canalizandopedidos através de um único objeto manipulador. Esse objeto pode realizar comporta-mento comum, que pode ser modificado em tempo de execução com decoradores. Omanipulador em seguida, envia comandos aos objetos para realizar determinado com-portamento a um pedido.

Figura 2.6: Padrão arquitetural Front Controller


Com apenas um controlador pode-se facilmente aumentar o seu comportamentoem tempo de execução com decoradores (padrão Decorator - GoF [27]). Pode-se terdecoradores para autenticação, encoding de caracteres, internacionalização e assim pordiante. Adicionando-os mesmo quando o servidor está em execução [25].

O Front Controller, em uma aplicação i18n tradicional de línguas orais, seria aescolha natural. Contudo, por se tratar de i18n de LS e também para manter a compati-bilidade com as língua orais, não teremos um único controlador como ponto de entrada.Assim, para i18n em LS, a escolha do padrão Front Controller é uma solução válida, masnão foi a melhor solução identificada para essa proposta.


2.7.4 Template View

Processa informações em HTML, incorporando marcadores em uma páginaHTML, Figura 2.7. Essa é uma forma para compor uma página Web dinâmica comose fosse uma página estática, é acrescentando marcadores que podem ser resolvidos emchamadas para apresentar informações dinâmicas. Desta forma a parte estática da páginaage como um modelo para uma determinada resposta.

Para implementar a visão em MVC a principal escolha é entre Template View eTransform View. O ponto forte de utilizar o Template View é a possibilidade de se compor oconteúdo da página observando a estrutura das páginas. Os pontos fracos são: a facilidadede incorporar lógicas complexas nas páginas e são páginas mais difíceis de serem testadaspor ter suas marcações, geralmente, dentro de um servidor Web.

Figura 2.7: Padrão arquitetural Template View


O requisito de separação de responsabilidade impede a utilização do padrão Tem-plate View na arquitetura para internacionalização de software para LS, por possibilitara incorporação de lógica de negócio na camada de visão. Outros requisitos também sãoviolados pelo padrão, como: portabilidade, flexibilidade e reusabilidade; por inserir lógicade negócio na camada de visão obrigando a uma nova implementação da camada de visãocom as mesmas regras de negócio para cada plataforma que for executada.

2.7.5 Transform View

Uma visão que processa elemento de dados de domínio por elemento etransforma-o em HTML, Figura 2.8. O papel da visão no MVC é a de tornar esses da-dos em uma página da Web. Usando Transform View significa pensar nisso como umatransformação onde você tem os dados do modelo como entrada e suas páginas HTMLcomo saída.


Figura 2.8: Padrão arquitetural Transform View


Com a renderização dos dados do modelo em páginas HTML, o Transform Viewé uma opção para a visão do MVC. Dependendo do estilo da aplicação, o modelo podefornecer arquivos JSON com os dados do modelo e esses dados são renderizados na telacom o auxilio do Transform View.

2.7.6 Two-Step View

Transforma dados de domínio em HTML em duas etapas: primeiro, formandouma espécie de página lógica, então o processamento da página lógica em HTML,Figura 2.9. A chave para este padrão é em fazer a transformação em HTML em umprocesso de duas fases. A primeira etapa reúne as informações em uma estrutura lógica natela sugestivo o suficiente para a exibição dos elementos ainda que não contenham HTML.A segunda etapa leva essa estrutura orientada a apresentação a torná-la em HTML.

Esta forma intermediária é um tipo de tela lógica. Esses elementos devem incluircoisas como: campos, cabeçalhos, roda-pés, tabelas e outros. Como tal, é certamenteorientada a apresentação e certamente obriga as telas a seguir um estilo definido


Figura 2.9: Padrão arquitetural Two-Step View


A utilização do padrão Two-Step View em detrimento ao padrão Transform Viewé uma importante decisão de projeto, não afetando a arquitetura de alto nível.

2.7.7 Application Controller

Um ponto centralizado para lidar com a navegação na tela e o fluxo de umaaplicação, Figura 2.10. Um Application Controller tem duas responsabilidades principais:decidir qual a lógica de domínio a ser executada e decidir a visão para o qual exibir aresposta. Para fazer isso, ele normalmente tem duas classes de referencias para coleçõesestruturadas, uma a execução dos comandos de domínio e uma para a camada de visão.


Figura 2.10: Padrão arquitetural Application Controller


Para o MVC o Application Controller funcionará como um ponto de controledo fluxo da aplicação, tendo duas responsabilidades principais: decidir qual a lógica dedomínio que será executada e decidir a visão com a qual exibir a resposta [25].

2.8 Trabalhos Relacionados

Hoje em dia, aplicações de software precisam sempre ser distribuídas paradiferentes países e regiões do mundo. É comum ver que um software popular tem muitasversões locais, por exemplo, o Windows 7 tem a versão dos EUA, versão em francês,versão em chinês simplificado, etc [52].

Alguns sistemas legados desenvolvidos entre 1980 e 1990 não levou internaci-onalização e localização de software em consideração, e eles ainda oferecem o serviçoem todo o mundo devido as mais variadas razões. A reengenharia de um sistema legadopara oferecer suporte a vários idiomas e fornecendo versões locais exigem modificaçõesde quantidade considerável de código-fonte [52].

Frameworks para internacionalização de aplicações Web permitem que as em-presas forneçam mais facilmente versões personalizadas de seu site para uma dada locali-dade dos usuários finais. Isso pode melhorar a acessibilidade de um site da web e melhorara experiência do usuário. Embora frameworks para internacionalização simplifiquem mui-tas tarefas relacionadas com localização, seu uso pode vir com problemas imprevistos. Assequências de caracteres de traduções podem expandir ou contrair devido a verbosidadeda língua alvo. Isso pode causar a distorção da aparência pretendida de uma página Webou pode tronar mais difícil o acesso de suas interfaces de usuário (UIs) para os usuáriosfinais [4].

Vários tipos de falhas de internacionalização podem ocorrer na web. O impactodessas falhas pode conduzir a distorções na aparência de uma página da Web que podemfazer a sua interface de usuário menos visualmente atraentes, ilegível ou inutilizável. Há


muitos problemas potenciais que podem levar a essas falhas, incluindo: tradução incorretado texto na página Web, não usando as convenções locais adequadas, tais como sistemasde medição e usando imagens culturalmente inadequadas ou cores [4].

Os trabalhos [52], [28], [4], [36] e [32] citam as dificuldades de se implementara internacionalização de software em variadas aplicações. Os trabalhos levantam asdificuldades de realizar a tradução e manter a integridade do layout das páginas. Adificuldade se tornar maior quando a tradução é realizada de uma língua que utiliza oalfabeto romano (também conhecido por alfabeto latino) para línguas que utilizam outrosalfabetos e estruturas linguísticas distintas. Figura 2.11.

Figura 2.11: Letras do alfabeto romano e do alfabeto cirílico

Disponível em: Alfabeto cirílico:https://www.pinterest.com/pin/434104851566212271/ ealfabeto latino:http://www.vidadeturista.com/artigos/alfabeto-internacional-fonetico.html

Algumas soluções são apontadas, como: frameworks ( [36] [52]), técnicas dedesenvolvimento ( [32] [4]) e estratégias de projeto ( [28]) para a melhor implementaçãoda internacionalização em aplicações empresariais. O interesse a respeito do tema decorreda necessidade da introdução de produtos, serviços e conteúdos diversos em locais alémdas fronteiras em que foi concebida a aplicação. E tem sido, recorrentemente, tema deestudo pela engenharia de software.

CAPÍTULO 3Trabalho Proposto

3.1 Requisitos Arquiteturais

A arquitetura de software fornece uma visão holística do sistema a ser cons-truído. Ela representa a estrutura e a organização dos componentes de software, suas pro-priedades e as conexões entre eles [43]. o projeto de arquitetura é o primeiro estágio noprocesso de projeto e representa uma ligação crítica entre os processos de engenharia deprojeto e de requisitos [8]. O estilo e a estrutura específicos escolhidos para uma aplicaçãopodem, portanto, depender dos requisitos de qualidade do sistema [49].

Com o auxílio do grupo de estudos da Faculdade de Letras/Libras da Univer-sidade Federal de Goiás, foram extraídos alguns requisitos de qualidade para uma ar-quitetura de software visando internacionalização em LS. O conjunto de Requisitos deQualidade (RNF) que regem a elaboração dessa arquitetura são:

RNF001 - Necessidade de Internacionalização para diversas línguas incluindo as diversas LSexistentes;

RNF002 - Facilidade de manutenção, a arquitetura deve ser projetada usando componentesde baixa granularidade e auto-contidos de modo que possam ser prontamentealterados [49];

RNF003 - Portabilidade para permitir a utilização da arquitetura em diversos sistemasoperacionais, navegadores Web, servidores de aplicação, etc;

RNF004 - Reusabilidade para permitir o reaproveitamento de códigos, módulos, funções,sempre que possível e

RNF005 - Flexibilidade para permitir a utilização da arquitetura pelo maior número deprojetos Web possível.

3.2 Proposta de Arquitetura

Para desenvolver uma descrição arquitetural como um todo, o arquiteto desistemas considera uma variedade de alternativas e, por fim, decide sobre as características

3.3 Escolhas Arquiteturais 39

de uma arquitetura específica que melhor atendam às necessidades [43]. Devido aoconjunto de requisitos de qualidade apresentados, a escolha foi baseada no fato daimportância que tem a consistência na tradução das informações apresentadas e seusimpactos no desenvolvimento das aplicações.

A apresentação das traduções devem ser íntegras no tocante aos seus padrões vi-suais, mas também quanto ao correto significado das informações apresentadas. Levandoem considerações todo o conjunto de elementos culturais, legais, sociais, etc. Fazendocom que todos esses elementos sejam alterados quando preciso, sem alterações na imple-mentação ou na visualização da informação.

Um meio de alcançar o objetivo que é o de elaborar uma arquitetura que atendaos requisitos propostos da melhor maneira possível foi utilizar dois padrões arquiteturais.Um padrão para a divisão física da estrutura, na qual a nossa sugestão é a arquiteturaem camadas. E o padrão arquitetural Modelo - Visão - Controlador (MVC, do inglês:Model - View - Controller) para tratar a camada de apresentação, intrínseca a i18nde LS. Garantindo à arquitetura todas as qualidades supracitadas, além de uma maiorportabilidade e flexibilidade.

3.3 Escolhas Arquiteturais

A proposta é uma arquitetura em três camadas que desassocia a navegação docomportamento da aplicação. De forma a manter a interface, a aplicação e a navegaçãoseparadas. Simplificando a implementação e aumentando a reutilização [43]. Sobre acamada de apresentação está inserida uma arquitetura MVC, onde o modelo contémtodo o conteúdo e a lógica de processamento específicos à aplicação, a visão contémtodas as funções específicas à interface e possibilita a apresentação do conteúdo e ocontrolador que gerencia o acesso ao modelo e à visão, coordenando o fluxo de dadosentre eles [43] [34] [25].


Figura 3.1: Arquitetura sugerida

Fonte: Figura criada pelo Autor

Segurança A arquitetura em camadas foi escolhida por permitir que os ativosmais críticos fiquem protegidos nas camadas mais internas, com um alto nível de valida-ção de segurança aplicadas a essas camadas [49]. Quanto à flexibilidade, portabilidadee reusabilidade a arquitetura em camadas permite que as manutenções em uma camadanão afete as demais, podendo inclusive ser substituída ou removida sem grandes proble-mas flexibilizando a implementação. A arquitetura MVC torna a aplicação portável, namedida que dá liberdade de implementação da camada de visão para se adequar a váriostipos de telas e dispositivos, além de permitir a reutilização do controlador por diversasaplicações.

Talvez os maiores desafios para a arquitetura sejam: a ausência de normas/pa-drões para a internacionalização em LS e a criação de mecanismos para a localizaçãodos usuários de LS. Quanto a ausência de normas/padrões, a solução foi, a partir da ISO639-3, definir as próprias normas/padrões para utilização das mídias de traduções na apli-cação. Já para solucionar problemas com a localização foi realizada uma pesquisa com oauxílio do grupo de pesquisa da Faculdade de Letras/Libras da UFG sobre a cultura surdae a melhor forma de apresentação do conteúdo.

O estilo adotado para a nomenclatura das siglas das LS, seguem a norma ISO639-3 (ex.: “bzs” - Brazilian Sign Language e “psr” Portuguese Sign Language) por sermais simples que a norma ISO 639-2 (ex.: “sgn-BR” Brazilian Sign Language e “sgn-PT” Portuguese Sign Language), utilizando apenas 3 letras para representar as LS. Já alocalização por ser uma atividade bilíngue-bicultural, ou seja, uma tarefa de tradução por


quem conhece as culturas em questão, conta com a flexibilidade da arquitetura para serimplementada.

A arquitetura foi pensada para que os desenvolvedores tenham a liberdade paraimplementar novas funcionalidades na camada de apresentação, implementando novoscontroladores, novos aspectos do modelo de dados e novas camadas de visão seminterferir na camada de domínio. Dessa forma esperá-se que a implementação de novasalternativas a localização sejam possíveis de serem adicionadas sem alterações no atualobjeto de modelo e sem alterações nas regras de negócio da aplicação.

3.3.1 A Arquitetura em Camadas

A arquitetura em camadas sugerida propõe as seguintes camadas físicas:

1. Camada de Dados ou persistência, responsável por persistir os dados e por geren-ciar os serviços e transações [49];

2. Camada de Domínio ou aplicação, responsável pelo trabalho que a aplicação devefazer para o domínio que se está trabalhando. Trata-se de cálculos baseados ementradas e dados armazenados, validação do conjunto de dados que vem a partir dacamada de apresentação [25].

3. Camada de Apresentação que, tradicionalmente, se encarrega da apresentação deinformações para o usuário e de toda a interação com o usuário [49]; na arquiteturasugerida, está subdividida logicamente em três camadas de representações dasinformações, seguindo a arquitetura MVC.

3.3.2 A Arquitetura MVC em Internacionalização Para Línguas deSinais

Ao projetar uma arquitetura de sistema, o arquiteto tem que decidir o queem seu sistema e quais as classes mais comumente encontradas em suas aplicações, edecidir quanto conhecimento dessas arquiteturas de aplicativos são possíveis reutilizar.Frequentemente uma aplicação incorporará classes de uma ou mais bibliotecas pré-definidas. A biblioteca é um conjunto de classes relacionadas e reutilizáveis, projetadaspara fornecer uma funcionalidade útil e de finalidade geral [27] [49].

O projeto de uma biblioteca é consideravelmente mais difícil que o projeto deaplicações, porque as bibliotecas devem funcionar em muitas aplicações para serem úteis.Além do mais, o autor da biblioteca não está numa posição que lhe permita saber quaisserão essas aplicações ou suas necessidades especiais. Isso torna ainda mais importanteevitar suposições e dependências que possam limitar a flexibilidade da biblioteca econsequentemente sua aplicabilidade e sua efetividade [27].


Para i18n em LS, foi necessário a criação de um controlador que permitisse ogerenciamento das mídias de traduções e a criação de uma camada lógica de modeloque crie as condições para que as mídias de traduções possam ser encontradas. Nainternacionalização em LS, o controlador será responsável por solicitar ao modelo a LSque se deseja a tradução, o modelo encontra a tradução e notifica o controlador para alteraro estado da visão. As responsabilidades do modelo deve ser a de manter a integridade datradução, garantindo a correta apresentação dos padrões visuais pré-definidos e regraspara acesso a camada de aplicação.

A camada de visão, representada por páginas Web, indica onde devem haver asapresentações das mídias de tradução. Informando a qual texto corresponde a determinadatradução LS e em qual local deve ser apresentado o conteúdo da mídia. Essas marcaçõessão importantes para que o controlador possa notificar o modelo sobre a existência deuma solicitação de tradução. E para que a tradução possa ser apresentada no referidolocal informado. Ou seja, sempre que a camada de visão sofrer algum tipo de alteraçãoem tempo de execução, o controlador identifica a alteração e notifica o modelo.

O controlador foi criado na forma de uma biblioteca em JavaScript, denominadode signlang.js, Vide Apêndice C. A biblioteca foi concebida para ser utilizada por qual-quer aplicação Web que utilize HTML+JavaScript+css. No projeto arquitetural propostoa biblioteca signlang.js é o equivalente ao controlador no modelo MVC, cuidando dogerenciamento das mídias de tradução. O modelo é representado por arquivos .json quedetêm o conhecimento sobre quais são as traduções disponíveis e quais as localizaçõesdos arquivos de mídia para tradução LS. Figura 3.2.

Figura 3.2: Representação conceitual do modelo MVC para o pro-jeto de i18n para LS

Fonte: Figura criada pelo Autor

3.4 Requisitos de Projeto 43

Como forma de apoiar a implementação da biblioteca signlang.js para a inter-nacionalização em LS, foram extraídos dois grupos de requisitos com base em levanta-mentos com o grupo de estudo da Faculdade de Letras/Libras da UFG e com base naarquitetura de alto nível elaborada anteriormente. O primeiro grupo de requisitos trata decomo os sistemas devem funcionar, seus relacionamentos com as aplicações e usuáriosdas aplicações. O segundo grupo de requisitos trata como a biblioteca não deve funcionare suas restrições, dirimindo possíveis duvidas a respeito de sua finalidade.

3.4 Requisitos de Projeto

O primeiro grupo de requisitos de Projeto e elaboração da biblioteca signlang.js

são:

RQ01 A biblioteca deve ser independente de tecnologia web utilizada em seu backend1;RQ02 A biblioteca deve permitir a atualização de novas LSs sem a reimplementação da

biblioteca ou de novas funcionalidades para a troca das LSs;RQ03 A biblioteca deve fornecer uma troca de LS independente da língua oral utilizada

na aplicação;RQ04 A biblioteca deve garantir que apenas uma única LS será utilizada por vez, evitando

possíveis confusões provocada por múltiplas traduções em LSs distintas;RQ05 A biblioteca deve ser flexível o suficiente para permitir ao desenvolvedor alterar ou

modificar o layout das mídias de traduções;RQ06 A biblioteca deve permitir que a seleção de uma única LS possa executar uma ou

várias mídias da LS selecionada em uma única página ou em páginas diferentes(Um para Muitos).

O segundo grupo de requisitos, os que contêm as restrições são:

RT01 A biblioteca não deve impor ao desenvolvedor o layout que será utilizado;RT02 A biblioteca não deve interferir nos componentes não relacionados com a interna-

cionalização em LS;RT03 A biblioteca não se compromete com performance ou desempenho das aplicações;

Os requisitos elencados devem ser válidos para sistemas novos que estão emprocessos de desenvolvimento e/ou para sistemas em produção que desejam adaptar-separa atender as demandas por conteúdos acessíveis por utilizadores de LS.

1Backend, em uma aplicação em camadas, diz respeito as tecnologias que dão suporte a camada deapresentação.

3.5 Escolhas de Projeto 44

3.5 Escolhas de Projeto

Durante a implementação da biblioteca signlang.js foram feitas escolhas deprojeto com base nos requisitos levantados. Alguns requisitos resultaram em uma ou maisdecisões, de tal forma que algumas decisões englobam um ou mais requisitos. As decisõesforam tomadas para contemplar sistemas novos e/ou sistemas antigos já em produção.Sendo que, algumas decisões tomadas isoladamente podem não ser as melhores paraum sistema em desenvolvimento ou, então, para um sistema em produção, mas podemser as que melhor atendem aos conjuntos de especificações dos dois tipos de sistemasconcomitantemente.

Para satisfazer a RQ01, a escolha foi implementar a biblioteca na linguagemde programação JavaScript. Essa escolha deve-se ao fato de que as tecnologias paradesenvolvimento Web utiliza, em sua grande maioria, a linguagem de marcação HTMLcom JavaScript e CSS. Tornando a biblioteca passível de ser utilizada em uma grandegama de aplicações Web. Tomando o cuidado de não interferir diretamente nas tecnologiasutilizadas nas demais camadas das aplicações.

Ainda satisfazendo a RQ01, para poder ser utilizada no maior número possívelde aplicações, a biblioteca foi elaborada tendo em vista o princípio de responsabilidadeúnica. Ou seja, a biblioteca se responsabiliza por encapsular a funcionalidade de inter-nacionalização de línguas de sinais, sem a necessidade de implementações adicionais oumodificações na estrutura da aplicação, satisfazendo também a RQ02.

A implementação da RQ02 levou a decisão de tornar a tradução das LSs inde-pendentes das traduções das línguas orais, o que satisfaz a RQ03. Dessa forma, é possívelter traduções de línguas não homologas. Ou seja, texto em inglês e tradução de LS em Li-bras, por exemplo. Além de permitir satisfazer a RT02, evitando que a biblioteca interfiraem outros componentes que não tenham referência com a internacionalização das LSs.

A biblioteca foi elaborada para que apenas uma única LS fosse apresentada aousuário por vez, satisfazendo a RQ04. Essa regra assegura que uma única LS será apre-sentada por escolha do usuário, impedindo que várias traduções simultâneas confundamo utilizador. Mas a biblioteca deve ser capaz de executar uma ou mais mídias de traduçãopor páginas, caso assim seja necessário, satisfazendo a RQ06. Ex. O utilizador seleciona“Libras”, então o sistema deve apresentar uma ou mais mídias de tradução para “Libras”por página até que outra LS seja selecionada.

Como não é possível prever com antecedência quais os layouts de todas aspáginas de todas as aplicações que possam utilizar a biblioteca, optou-se por não utilizarcomponentes CSS ou Frameworks JavaScript que pudessem interferir nos layouts daspáginas. A biblioteca foi criada em JavaScript com algumas poucas funções da bibliotecajQuery. Dessa forma, espera-se satisfazer as RQ01, RQ05. RT01 e RT02.

3.6 Como Utilizar a Biblioteca signlang.js 45

O projeto não se compromete, em momento algum, com a performance dasaplicações novas ou em produção que utilizem a biblioteca, conforme RT03. Não sendoescopo do projeto a elaboração de uma biblioteca performática ou que apresente umdesempenho satisfatório diante todas as possíveis aplicações utilizáveis.

3.6 Como Utilizar a Biblioteca signlang.js

Independente de ser uma aplicação nova ou uma aplicação em produção, a bibli-oteca desenvolvida para a internacionalização para LS requer apenas uma dependência,a biblioteca jQuery. O desenvolvedor deve adicionar o JQuery e a biblioteca para in-ternacionalização de LS, signlang.js, ao arquivo principal do projeto 2 3. Obedecendo aseguinte ordem de precedência: primeiro a biblioteca jQuery, depois a biblioteca sign-

lang.js. O pseudo Código 3.1 apresenta a forma correta de importa as bibliotecas jQuery

e signlang.js para uma página Web denominada index.html.

1 <head>

2 <script src="/PATH_TO_JQUERY/jquery.min.js"></s

cript>

3 <script src="/PATH_TO_SIGNLANG/signlang.js"></s

cript>

4 </head>

Listing 3.1: Como importar a biblioteca signlang.js e jquery.js

para a aplicação

Após a inclusão das bibliotecas supracitadas, o desenvolvedor deve criar a pastai18n na raiz do projeto. Essa pasta deve conter um arquivo obrigatoriamente nominadode config.json e pastas nominadas com os códigos ISO 639-3 das LS que a traduçãosuportará. O Código 3.2 é um exemplo de um arquivo config.json.

1 {

2 "languages": {

3

4 "bzs":{

5 "name": "íLngua Brasileira de Sinais",

6 "idLang": "bzs",

7 "path": "i18n/bzs/bzs.json"

8 },

2Normalmente o arquivo principal se chama index.html3A biblioteca está sob a licença Creative Commons e pode ser realizado o seu download pelo ende-

reço: https://github.com/paulomarcsr/signlang.git


9 "ase":{

10 "name": "American Sing Language",

11 "idLang": "ase",

12 "path": "i18n/ase/ase.json"

13 },

14 "psr":{

15 "name": "íLngua Gestual Portuguesa",

16 "idLang": "psr",

17 "path": "i18n/psr/psr.json"

18 }

19 }

20 }

Listing 3.2: Exemplo de um arquivo config.json

O arquivo config.json deve conter o nome da LS que se desejam traduzir, ocódigo ISO 639-3 da LS e o caminho para o arquivo de traduções. A pasta i18n e oarquivo config.json são obrigatórios, seja para projetos novos ou para projetos que já estãoem produção, mas precisam serem adaptados para receber traduções em LSs.

Dentro da pasta i18n deve conter pastas nomeadas com o código ISO 639-3da LS e dentro desta, deve haver um arquivo .json indicando a mídia de tradução paradeterminado local de tradução, conforme Código 3.3.

1 {

2 "MENU":{

3 "OPTION":"midias/ase/ase0.mp4"

4 },

5 "HOME":{

6 "INTRODUCAO":"midias/ase/ase1.mp4"

7 }

8 }

Listing 3.3: Exemplo de um arquivo indicando a localização da

mídia de traduçãoconfig.json

No arquivo .json podemos perceber que no menu de opções, o arquivo que deveser executado é o vídeo ase0.mp4 que está dentro da pasta ase que por sua vez se encontradentro da pasta midias. Da mesma forma, na página HOME, na parte de INTRODUCAO

temos a execução do vídeo ase1.mp4. Como pode ser verificado no Código 3.4, parainformar qual será o trecho à ser traduzido basta inserir o atributo “signlang=” como valor correspondente ao local para a tradução, ou seja, HOME.INTRODUCAO noexemplo apresentado.


Para apresentar a mídia com a tradução basta informar à tag HTML iframe res-ponsável por apresentar os vídeos, o valor do atributo id= igual a myFrame. Fazendo comquê a biblioteca signlang.js entenda que no local é preciso executar um determinado ví-deo de tradução. Existem ligeiras diferenças entre a utilização da biblioteca signlang.js emprojetos novos e projetos em produção. Essas diferenças se manifestam principalmente nomodo de acesso as mídias. Quem em alguns casos podem estar persistidas em banco dedados ou até mesmo em servidores de vídeos remotos.

1 

2 

3 <div class="container">

4 

5 <header class="jumbotron hero-spacer">

6 <p id='teste' class="show"

7 signlang='HOME.INTRODUCAO'>

8 O conceito de Qualidade de Vida proposto

pela çãOrganizao

9 Mundial de úSade (OMS) é: ``a çãpercepo

do íindivduo de sua çãposio na vida,

no contexto de sua cultura e no

sistema de valores em que vive e em

çãrelao a suas expectativas, seus

õpadres e suas çõpreocupaes''. É um

construto amplo, que abrange a úsade

ífsica e ópsicolgica, ínvel de

êindependncia,çõ

10 relaes sociais, çcrenas pessoais e meio

ambiente. </p>

11 

12 <div class="embed-responsive

embed-responsive-16by9">

13 <iframe class="embed-responsive-item" id="

myFrame"

14 width="500" marginwidth="0" height="500"

marginheight="0"

15 align="middle" scrolling="auto">

16 </iframe>

17 </div>

18

3.7 Projetos Novos 48

19 </header>

20 </div>

Listing 3.4: Exemplo de um arquivo HTML com

internacionalização em línguas de sinais

3.7 Projetos Novos

Para projetos novos sugerimos que além da pasta i18n, o desenvolvedor acres-cente uma pasta nomeada midias onde deve conter todas as mídias de traduções. Dentroda pasta midias o desenvolvedor deve criar uma pasta para cada LS que se deseja traduzir.Preferencialmente, deve-se nomear as pastas com o código ISO 639-3 da LS correspon-dente. A estrutura deve se parecer com algo como o da Figura 3.3.

Figura 3.3: Exemplo da estrutura sugerida.

Extraído de: Questionário de qualidade de vida preparada paraabrigar diversas LSs

3.8 Projetos em Produção

Para projetos que já foram implementados não levando em consideração a inter-nacionalização em LS, a biblioteca signlang.js auxilia na implementação da internaciona-lização sem alteração das funcionalidades implementadas anteriormente. Bastando seguiros passos da Seção 3.6, e no arquivo .json situado no endereço “i18n/[CODIGO_LS]”,informar o caminho para se encontrar a mídia referente a tradução. Esse arquivo podeestar situado em uma pasta no sistema ou em um servidor remoto.

3.8 Projetos em Produção 49

Caso as mídias estejam persistidas em banco de dados, talvez seja necessárioimplementar uma forma de recuperação das mídias para posterior utilização com abiblioteca signlang.js. Bem como, em casos de utilização de tags <iframe> da linguagemHTML, a utilização da biblioteca pode ser dificultada, embora seja possível a utilização depequenos trechos de código em JavaScript para contornar os problemas que por venturapossam ocorrer.

CAPÍTULO 4Resultados

Para validar as teorias apresentadas e dissolver possíveis dúvidas acerca dautilização prática da arquitetura apresentada, bem como a utilização da biblioteca criadapara a internacionalização para LSs, foi realizado um estudo de caso. O estudo de casoconsiste em aplicar as técnicas apresentas em uma aplicação real, o Questionário deQualidade de Vida em Libras (QQVL). Inicialmente a aplicação contendo o QQVLapresentava questões traduzidas para o Português, Inglês e Escrita de Sinais (Elis) eposteriormente foi traduzido para a Língua Brasileira de Sinais (Libras).

O QQVL foi desenvolvido para ser uma plicação Web, escrita na linguagemPHP utilizando um servidor Web HTTP apache 2 e um banco de dados mySQL. Umacaracterística marcante da implementação inicial é a ausência de distinção entre camadaslógicas apesar da clara definição entre as camadas físicas, servidor de aplicação e servidorde banco de dados. Ou seja, não há uma divisão precisa entre as responsabilidades dasclasses, caracterizando uma baixa coesão no código, em alguns casos assemelhando auma programação estruturada. Isso dificulta a manutenção, e em se tratando do estudo decaso, a refatoração da aplicação.

O PHP (um acrônimo recursivo para PHP: Hypertext Preprocessor) é umalinguagem de script open source de uso geral, adequada para o desenvolvimento webe que pode ser embutida dentro do HTML [29]. Essa característica permite agilizaro desenvolvimento Web mesclando trechos de código em linguagem HTML com alinguagem PHP. Uma possível consequência dessa característica é a implementação deaplicações sem um projeto definido ou quando há um projeto definido, as manutençõestendem a desvirtuar o projeto original.

Outro fato digno de nota é que a aplicação foi desenvolvida utilizando tecnolo-gias que atualmente estão em declínio, o que demandou um maior trabalho para adequara aplicação a arquitetura proposta para a internacionalização de software para LSs. Umexemplo são os arquivos de tradução que originalmente foram criados como sendo ví-deos em Adoble Flash, e a maioria dos navegadores de Internet não possuem suportenativo para rodar esse tipo de vídeo. Navegadores como Mozilla FireFox, Google Chrome

e Microsoft Edge utilizam tecnologia HTML 5 o que dispensa a utilização de vídeos no

4.1 O Questionário de Qualidade de Vida Como Estudo de Caso 51

formado Adoble Flash em favor de formatos de vídeos desenvolvidos para HTML5, como:.mp4, .webm e .ogv/.ogg.

4.1 O Questionário de Qualidade de Vida Como Estudode Caso

O QQVL foi escolhido para ser o estudo de caso por ser uma aplicação legadacom as características necessárias para validar as propostas apresentadas. Por exemplo:ser uma aplicação Web, ter um caráter global, já possuir uma quantidade considerávelde vídeos de tradução, não ter uma alta complexidade de configuração e não conterdependências com outras aplicações. Dessa forma os pontos apresentados permitem queo foco se mantenha na internacionalização da aplicação para LSs. A intenção de utilizar oQQVL como caso de estudo é demonstrar que a internacionalização de uma aplicaçãopara LSs é possível mesmo para uma aplicação legada, onde o projeto arquitetural éconfuso, com baixa coesão e alto acoplamento.

A proposta de i18n para LSs se limitou apenas aos aspectos referentes astraduções. A refatoração do código fonte foi aplicada apenas em trechos de código paraque as traduções pudessem ocorrer e na exclusão de arquivos de código PHP duplicados.Dessa forma esperamos podemos avaliar se a arquitetura elaborada é adaptável tambéma sistemas legados, sem interferir nas decisões arquiteturais das aplicações originais.Essa questão é especialmente importante para que a arquitetura i18n em LSs pudesseser utilizada pelo maior número de aplicações possível. Não restringindo à proposta a umdeterminado estilo arquitetural.

Originalmente a aplicação continha 244 arquivos de código fonte PHP, com33.475 linhas de código, dessas linhas de código, 3.438 eram referentes a linhas quecontinha algum tipo de lógica embutida. Para obter as análise do código fonte foi utilizadoa ferramenta de análise estática de código PHP, PHPMetrics [37]. Essa análise se mostrouimportante para apresentar o estado quantitativo e qualitativo da aplicação original epermitir obter conclusões a cerca da qualidade da arquitetura i18n para LS projetada.

Para realizar a troca dos vídeos contendo as traduções em LSs foram adicionadasas bibliotecas javascript signlang.js e jQuery. Para a análise estática dos códigos emlinguagem javascript foi utilizado a ferramenta de código aberto plato que está soba licença MIT. Como a biblioteca jQuery é uma biblioteca amplamente utilizada pordesenvolvedores de aplicações Web no mundo todo e por não fazer parte diretamentedo escopo da arquitetura i18n para LSs, jQuery não será alvo direto da análise estática.

4.2 Alterações Realizadas na Aplicação Original 52

4.2 Alterações Realizadas na Aplicação Original

Algumas mudanças foram realizadas na aplicação original para a adequação ai18n em LSs. A estrutura da aplicação original possuía 14 pastas, sendo que apenas 2pastas continham código PHP. As demais pastas estavam distribuídas da seguinte forma:1 pasta para arquivos css (Cascading Style Sheets), 1 pasta para os arquivos Javascript,1 pasta para os arquivos contendo as fontes necessárias para a escrita de sinais, 1 pastapara as imagens utilizadas na aplicação e 8 pastas contendo arquivos de vídeos com astraduções para Libras. Conforme Figura 4.1.

Figura 4.1: Estrutura de pastas original

Extraído da aplicação "questionário de qualidade de vida - Libras"

Para a adequação à arquitetura elaborada, foi adicionado a pasta js (onde conti-nham os arquivos javascript às bibliotecas javascript signlang.js e jquery.min.js, além deter sido criada uma pasta com o nome de i18n contendo um arquivo denominado obriga-toriamente de config.json em sua raiz. Dentro da pasta i18n foram criadas as pastas comas LSs utilizadas nas traduções, pasta ase, bzs e psr. Dentro das pastas com as siglas dasLSs temos um arquivo com o nome da LS com a extensão .json, como já abordado naSeção 3.6. A estrutura de pastas ficou conforme a Figura 4.2.


Figura 4.2: Estrutura de pastas após a criação da pasta i18n


Foi criada, também, a pasta midia. Com o objetivo de organizar em um únicolocal todas as mídias de tradução da aplicação. Dentro da pasta midia foi criado uma pastapara cada tradução desejada e dentro das pastas das LSs foram criadas pastas contendodivisões lógicas para abrigar as mídias de mesmas características. Por exemplo: as mídiasde traduções contendo as instruções de utilização foram colocadas dentro de uma pastadenominada instrucoes, como na Figura 4.3.


Figura 4.3: Estrutura de pastas após a criação da pasta midia


Outra significante alteração efetuada foi a criação de uma função javascript

na página inicial (index.html) para o carregamento dos vídeos dentro das tags iframe.Para isso, foi criado uma função para aplicar as funcionalidade da biblioteca signlang.js

dentro das tags iframe sempre que o ocorresse uma nova solicitação de carregamento daspáginas. Fazendo com que as mídias fossem apresentadas corretamente e que a bibliotecapudesse manter a integridade das traduções. Código 4.1

1

2 <script type="text/javascript">

3 iframe = document.getElementById("qualidade");

4 function aplicaItemSelecionado() {

5 $.getJSON('i18n/config.json', function

confiJSON (jd) {

6 var itemSelecionado = $("#sl-menu").val

();

7 if (jd.languages[itemSelecionado] !=

undefined) {


8 var p = jd.languages[

itemSelecionado].path;

9 $.getJSON(p, function setSignLang (j

){

10 var r = $(jQuery("#qualidade").

contents().find("iframe"));

11 for (var b = 0; b < r.length; b

++) {

12 var at = r[b];

13 var i18n = at.getAttribute('

signlang');

14 var w = i18n.split(".");

15 var x = null;

16 for (i = 0; i < w.length; i

++) {

17 if(x===null){

18 x = j[w[i]];

19 }else{

20 x = x[w[i]];

21 }

22 }

23 var video = x;

24 at.setAttribute('src', video

);

25 }

26 });

27 } else {

28 $(jQuery("#qualidade").contents().

find("iframe")).hide();

29 $(jQuery("#qualidade").contents().

reload(true));

30 //// hide

31 }

32 });

33 }

34 iframe.onload = function() {

35 aplicaItemSelecionado();

36 }


37 </script>

38 \caption*{Ola Mundo}

Listing 4.1: Função javascript de apoio a implementação da

biblioteca signlang.js

É importante salientar que foram excluídos todos os arquivos PHP utilizadosna criação do módulo de demonstração da aplicação. Como o módulo de demonstraçãonão será utilizado nas versões futuras da maneira que foi concebido originalmente, foisolicitado pelos responsáveis da aplicação que o módulo fosse suprimido, Figura 4.4.Essa decisão ficará evidenciada na quantidade total de arquivos e de linhas de código,mas tem um impacto pequeno na análise qualitativa do código.

Figura 4.4: Estrutura da aplicação com e sem arquivos do módulode demonstração

(a) Estrutura original com os arquivos referentes ao mó-dulo de demonstração

(b) Estrutura alterada sem os arquivos re-ferentes ao módulo de demonstração

Extraído de: Questionário de qualidade de vida preparado paraabrigar diversas LSs

Para a nova versão do questionário de qualidade de vida foi aplicado um novolayout para as páginas, visando melhorar a apresentação visual da aplicação. O novolayout permite que as páginas possam ser renderizadas dentro de um iframe na páginaprincipal (index.html), mantendo o menu principal sempre visível e acessível. Possibili-

4.3 Ferramentas Para Análises Estáticas 57

tando que a aplicação seja apresentada em diferentes tamanhos e formatos de telas, man-tendo a uniformidade e proporcionalidade das informações 1. As alterações proporcionadapelo novo layout tende a auxiliar na organização da arquitetura como um todo, não sendoexclusivamente relevante para a internacionalização de LS.

Apesar das diferenças visuais, o conteúdo das páginas, continuam os mesmo.Alterando apenas a disposição do conteúdo e elementos visuais, como: cor de fundo,fonte utilizada nos textos e posição do logotipo do questionário. As mudanças ocorreramutilizando novos componentes css 2 e javascript.

4.3 Ferramentas Para Análises Estáticas

Analisadores estáticos são ferramentas de software que varrem o código-fontede um programa e detectam possíveis defeitos e anomalias. Eles analisam o texto deprograma e, assim, reconhecem os tipos de declarações no programa. Podem portantodetectar se as declarações estão bem formuladas, fazer inferências sobre o fluxo decontrole do programa e, em muitos casos, computam o conjunto de todos os valorespossíveis para os dados de programa. Eles complementam os recursos de detecção deerros providos pelo compilador da linguagem [49].

As métricas estáticas obtidas através de ferramentas ajudam a avaliar a comple-xidade, a facilidade de compreensão e a facilidade de manutenção de um sistema de soft-ware. As métricas estáticas têm um relacionamento indireto com atributos de qualidade.Um grande número dessas métricas foi proposto e muitos experimentos tentaram derivare validar os relacionamentos entre essas métricas com a complexidade, a facilidade decompreensão e a facilidade de manutenção do sistema [49].

4.3.1 A Ferramenta PHPMetrics

A PHPMetrics é uma ferramenta de código aberto para análise estática decódigo PHP, distribuída sob a licença MIT e criada pelo desenvolvedor Jean-François

Lépine. A ferramenta apresenta um relatório em HTML que pode ser visualizado em umnavegador Web, como pode ser visto na Figura 4.5. A desvantagem da PHPMetrics é quea ferramenta não é capaz de analisar outros tipos de arquivos que não tem a extenção.php. Ou seja, a ferramenta desconsidera arquivos com outras extensões utilizadas nodesenvolvimento Web como arquivos .css, .js, .html e arquivos de mídia como .ogg, .ogv,etc.

1Dentro das limitações de cada dispositivo que acessar a aplicação2Cascading Style Sheets, uma linguagem utilizada para adicionar ou alterar comportamentos e aspectos

visuais em uma página Web

4.3 Ferramentas Para Análises Estáticas 58

Apesar da limitação de só analisar código PHP, a PHPMetrics tem as vantagensde ter o código aberto, ter relatórios amigáveis para o usuário, possuir uma utilizaçãosimples e descomplicada, além de possuir uma grande quantidade de métricas bem dis-tribuídas em um interface clara e bem organizada. Ainda, a ferramenta possui integraçãocom algumas IDE (Integrated Development Environment ou em português, Ambiente deDesenvolvimento Integrado), com a ferramenta de integração contínua Jenkins e com oservidor de qualidade contínua Sonar.

Figura 4.5: Exemplo da página principal da ferramenta PHPMe-trics

Fonte: Ferramenta para análise de código fonte PHPMetrics

Como a ferramenta apresenta uma grande quantidade de métricas e estatísticasreferentes ao código fonte, as principais métricas que usaremos para as nossas análisesserão:

1. loc - Número de linhas de código;2. lloc - Número de linhas que contém algum tipo de lógica;3. cc - Índice de complexidade ciclomática que mede o número de caminhos linear-

mente independentes através do código fonte de um aplicação;4. effort - Esforço para compreender o código fonte;5. MI - Índice de manutenibilidade, baseado nas métricas de Halstead 3 [30], num

número de complexidade de linhas de código e na complexidade ciclomática.

4.3.2 A Ferramenta Plato

A ferramenta plato de análise estática para a linguagem javascript é distribuídasob a licença de código aberto MIT. Tendo como principais contribuidores, no momento,

3Maurice Howard Halstead, Professor da univesidade de Purdue e criador dos conceitos de ciência dacomputação, que levaram ao desenvolvimento de métricas de software.

4.4 Metodologia Utilizada nas Análises 59

Jarrod Overson, Craig Davis e David Linse. A ferramenta apresenta um relatório simplesem HTML que pode ser visualizado em um navegador Web, como podemos ver na Figura4.6.

Figura 4.6: Exemplo da página principal da ferramenta plato

Extraído de: Plato - Ferramenta de análise de código JavaScript

As métricas utilizadas pela ferramenta são:

1. Total de linhas de código;2. Índice de manutenibilidade;3. Estimativa de erros na implementação;4. Dificuldade na compreensão do código e5. Índice de complexidade ciclomática

4.4 Metodologia Utilizada nas Análises

As análises dos dados obtidos com a experiência do estudo de caso só forampossíveis com a ajuda das ferramentas de análise estáticas apresentadas no Capítulo 4. Osdados de cada versão da aplicação serão apresentados da forma como foram obtidos pelasferramentas e a título de comparação, os dados serão apresentados em forma de tabela.

As análises foram obtidas através de três versões da aplicação. A aplicaçãooriginal (P), a aplicação alterada para uma única LS (P’) e uma versão da aplicaçãoalterada para comportar mais de uma LS (P”). Com isso, esperamos obter as diferençasentre adaptar uma aplicação legada para uma arquitetura que comporte a i18n para LS eavaliar o esforço para adicionar mais uma LS a aplicação já adaptada.

Como a biblioteca signlang.js foi única para as duas versões alteradas, seráapresentado apenas uma versão das análises estáticas referentes as suas métricas. Paraos códigos PHP serão apresentados resultados para a versão original (P) e para as duasversões alteradas(P’ e P”). As métricas foram divididas em métricas gerais ou quantitativa,

4.5 Análise Geral 60

que diz respeito aos aspectos quantitativos dos arquivos de códigos-fontes e métricasqualitativas, que permitem avaliar a qualidade dos códigos implementados.

4.5 Análise Geral

Primeiramente foram obtidas as quantidades de linhas de código para todos osarquivos javascript existentes no projeto. Assim, podemos estabelecer uma relação dequantidade de linhas de código entre a biblioteca signlang.js e as demais bibliotecasjavascript utilizadas pela a aplicação. As aplicações alteradas (P’) e (P”) possuem 18arquivos “.js” 4, com um total de 15.300 linhas de código. O que representa uma médiade 850 linhas de código por arquivo javascript. Figura 4.7.

Figura 4.7: Quantidade total de linhas de código e a respectivamédia por arquivo .js


O arquivo signlang.js por sua vez, possui 68 linhas de código, Figura 4.8, oque representa 2,25% da quantidade total de linhas de código javascript utilizada pelaaplicação.

4Extensão de arquivo utilizada pelas bibliotecas javascript


Figura 4.8: Quantidade total de linhas de código para a bibliotecasignlang.js



A aplicação original (P) possui 6 arquivos javascript totalizando 694 linhas decódigo. Uma média de 115 linhas por arquivo. Lembrando que originalmente a aplicaçãonão contava com mecanismos de responsividade e foram alterados elementos gráficos decor, fontes dos textos, etc., o que demandou a utilização de 10 novas bibliotecas javascript

além das 2 novas bibliotecas necessárias para a internacionalização em LS. Figura 4.9.

Figura 4.9: Quantidade total de linhas de código utilizado na apli-cação original (P) e a respectiva média por arquivo .js

link: internet

A Tabela 4.1 apresenta um comparativo entre a quantidade de linhas de códigojavascrip existentes na aplicação (P) e suas versões alteradas (P’) e (P”). E evidencia umgrande incremento na quantidade geral de linhas de código. Esse incremento se deve entreoutras coisas a biblioteca JQuery que corresponde com 11.008 linhas de código. Sendoessa biblioteca parte fundamental para a utilização da biblioteca signlang.js.

Tabela 4.1: Comparação entre a quantidade total de linhas de có-digo .js da aplicação original para as versões altera-das

Aplicação (P) Aplicações (P’) e (P”)

Quantidade de linhas total 694 15300Média por arquivo 115 850

Fonte: Tabela criada pelo Autor com base nas informações extraí-das da ferramenta Plato


Quanto as métricas relacionas as regras de negócio da aplicação, a principal al-teração foi a retirada dos arquivos do módulo de demonstração, como mencionado anteri-ormente. Para a análise das métricas referentes ao código PHP a ferramenta PHPMetrics

disponibiliza: quantidade de arquivos, quantidade de linhas de código, quantidade de li-nhas lógicas em relação ao total de linhas de código, quantidade de classes e a quanti-dade de métodos. Para a aplicação original (P) temos as seguintes métricas: 244 arquivos,33.475 linhas de código, 3.438 linhas com lógica de programação, 0 classes e 0 métodos.Figura 4.10.

Figura 4.10: Métricas gerais da aplicação (P)


A aplicação (P’) possui uma quantidade menor de arquivos PHP, conformeexplicado anteriormente, o que reflete na quantidade total de linhas de código e naquantidade de linhas lógicas de código. Para a aplicação (P’), temos 156 arquivos PHP,31.489 linhas de código, 2.274 linhas lógica de código, 0 classes e 0 métodos. Uma vezadaptada a aplicação para a i18n para LS a adição de novas traduções não interferena programação já realizada, podendo ser adicionadas quantas mais traduções forempossíveis sem novas implementações. Dessa forma, as métricas gerais para as aplicações(P’) e (P”) permanecem inalteradas, conforme Figura 4.11.

Figura 4.11: Métricas gerais da aplicação (P’) e (P”)


4.6 Análise Detalhada 64

4.6 Análise Detalhada

A análise qualitativa aqui apresentada é uma forma de mensurar a qualidadeda implementação da aplicação. Revelando possíveis erros causados por códigos malescritos, fora dos padrões, com uma alta complexidade, etc. Assim como, procurar pordefeitos de programas, a análise estática pode também considerar atributos de qualidademais amplos de um programa como conformidade com padrões, portabilidade e facilidadede manutenção. Podendo procurar por ineficiências, algoritmos inapropriados e estilode programação “pobre” que poderiam tornar difíceis a manutenção e a atualização daaplicação [49].

4.6.1 Análise Biblioteca signlang.js

A primeira das análises qualitativas é referente a biblioteca signlang.js, e diz res-peito ao índice manutenibilidade. A ferramenta plato, defini o índice de manutenibilidadecomo sendo um valor entre 0 e 100 que representa a facilidade de se manter o código-fonte. Sendo que valores mais altos são aplicações melhores manuteníveis. A bibliotecasignlang.js apresenta, segundo a ferramenta, um índice igual a 68.77. Figura 4.12.

Figura 4.12: Índice de manutenibilidade apresentada pela ferra-menta plato para a biblioteca signlang.js


A seguinte métrica diz respeito a dificuldade de entendimento do código-fonte.A ferramenta plato define o índice como sendo a dificuldade de se escrever ou entender oprograma. A biblioteca obteve um índice igual a 10.77. Figura 4.13. Sendo definida como:Dificuldade (D) é igual ao número de operadores distinto η1 dividido por 2, multiplicadopelo número total de operandos N2 dividido pelo número de operandos distintos η2 [30].

D =η1

2N2

η2(4-1)


Figura 4.13: Índice de dificuldade de se escrever ou entender ocódigo


Assim como a quantidade de linhas de código lógico, a ferramenta plato apre-senta o índice de complexidade por função existente na biblioteca. A ferramenta define oíndice de complexidade como sendo a quantidade de caminhos possíveis para um blocode código. Para a ferramenta, quanto menor o valor menos complexo é o bloco. Paraexemplificar a Figura 4.14 apresenta a função com a maior complexidade, que por sinal éa função com a menor quantidade de linhas de código.

Figura 4.14: Análise comparativa entre complexidade e quantida-des de linhas de código da função setSignLang


A ferramenta plato apresenta uma estimativa de potenciais erros na implemen-tação da biblioteca. A estimativa de erros é uma medida criada por Maurice Howard

Halstead em 1977 [30]. Sendo B a estimativa de erro e V o volume da implementação, ouseja, o tamanho de um determinado algoritmo.

B =V

3000(4-2)

Para a biblioteca signlang.js a ferramenta plato estima um valor igual a 0.58.Figura 4.15.


Figura 4.15: Estimativa de error avaliada pela ferramenta plato


4.6.2 Análise Códigos PHP

Como abordado anteriormente, a aplicação alvo foi construída utilizando alinguagem PHP. E não houve uma divisão clara entre os elementos de apresentação,domínio e persistência. Tão pouco houve uma separação de responsabilidades por classesou métodos. As alterações propostas não visaram modificar essas particularidades daaplicação original, ficando responsável apenas por adicionar a funcionalidade de i18npara LS e melhor a identidade visual da aplicação. Por essa razão, alguns indicadores dequalidade podem estar aquém do esperado para uma aplicação PHP do mesmo porte.

A ferramenta PHPMetrics informa que os valores apresentados não são absolu-tos, sendo uma comparação entre a aplicação alvo e uma média representativa de projetosPHP recentes (benchmarks). Cada pontuação é calculada através de vários critérios dototal de arquivos existentes no projeto alvo. A pontuação está entre 0 (pobre) e 100 (ex-celente). Para a aplicação (P), temos um valor de manutenibilidade igual a 12.67, Aces-sibilidade para novos desenvolvedores igual a 30.82, Simplicidade do algoritmo igual 0,Volume igual a 64.88 e probabilidade de redução de bugs igual a 100. Figura 4.16

Figura 4.16: Métricas qualitativas referente a aplicação (P)


A adição de uma nova tradução a uma aplicação já preparada para i18n para LSnão implica na alteração de código-fontes, nem alterações na lógica de negocio. Por tanto,


as aplicações (P’) e (P”) obtiveram os mesmos valores para todas as métricas analisadaspela ferramenta PHPMetrics. Tendo os seguintes valores: 14.56 para Manutenibilidade,30 para a Acessibilidade para novos desenvolvedores, 0 para a Simplicidade do algoritmo,57.78 para o Volume e 98.36 para a Probabilidade de redução de bugs. Figura 4.17.

Figura 4.17: Métricas qualitativas referente a aplicação (P’) e(P”)


A efeito de comparativo, temos a Tabela 4.2 que apresenta as métricas qualita-tivas referente aos códigos PHP das aplicações (P), (P’) e (P”). Podemos notar que nãoexiste diferença mensurável entre as aplicações (P’) e (P”). Confirmando que a adiçãode novas traduções não alteram o código-fonte anteriormente implementado de maneirasignificativa.

Tabela 4.2: Tabela comparativa entre as métricas qualitativas dasaplicações (P), (P’) e (P”).

Métrica Aplicação (P) Aplicação (P’) Aplicação (P”)

Manutenibilidade 12.67 14.56 14.56Acessibilidade para Novos Desenvolvedores 30.82 30 30Simplicidade do Algoritmo 0 0 0Volume 64.88 57.78 57.78Probabilidade de Redução de erros 100 98.36 98.36

Fonte: Tabela criada pelo Autor a partir das informações extraídasda ferramenta PHPMetrics

As diferenças ocorreram em relação a aplicação (P) para a aplicação (P’). Houveuma diferença positiva no caso da “Manutenibilidade” da aplicação com uma variação de1.89, duas variações negativas nos casos da “Acessibilidade para novos desenvolvedores”de 0.82 e na “Probabilidade de redução de erros” de 1.64. Como era de se esperar devidoa remoção do modulo de demonstração que existe na aplicação (P) e não existe nasaplicações (P’) e (P”), o “Volume” apresentou a maior variação absoluta entre as métricasobtidas, 7.1.

4.7 Resumo da Análise 68

4.7 Resumo da Análise

A biblioteca siglang.js apesar de ser crucial para a i18n para LS, possui rela-tivamente poucas linhas de código-fonte. Todavia, apresentou números satisfatórios naanálise qualitativa, obtendo uma nota razoável quanto a manutenibilidade, baixa dificul-dade de compreensão de sua lógica e baixa probabilidade de conter erros. Contudo, afunção setSignLang obteve uma nota alta em sua complexidade relativa. Possíveis melho-ras na função setSignLang poderão futuramente optimizar a performance das transiçõesentre traduções. A análise de código PHP das versões da aplicação alvo, se por um ladonão demonstrou um aumento significativo quanto a qualidade da aplicação, tão poucodemonstrou grandes prejuízo que impossibilitassem o uso da arquitetura i18n para LSpor aplicações legadas. A Tabela 4.2, nos leva a acreditar que a organização promovidapara adequar a aplicação (P) a arquitetura i18n para LS não impactou diretamente na ar-quitetura original, apenas acrescentou a funcionalidade de tradução das LS. Cumprindo,assim, os objetivos gerais do “Projeto de Software para Internacionalização em Línguasde Sinais” 1.1.

CAPÍTULO 5Conclusão

Diante da quantidade de LSs, e da importância que esse sistema linguísticorepresenta para seus utilizadores, sendo um elemento de constituição do sujeito surdo,agregando sua identidade e cultura [15], os meios computacionais não podem se omitir acontemplar esses usuários. Como ficou evidenciado na RS, Apêndice A, muito tem sidofeito para que pessoas surdas e ouvintes possam interagir.

As traduções tem um papel fundamental em encurtar a distância entre os inter-locutores. Muitos trabalhos oferecem mecanismos de traduções automatizados utilizandoavatares, reconhecimento de imagens para auxiliar na tradução da LS para a língua oral,manuais de acessibilidade de aplicações para pessoas surdas, etc. Mas, no geral, são ini-ciativas que visão a compreensão de uma única LS para uma determinada língua oral ouvice-versa.

A importância de todo o estudo realizado neste trabalho é iniciar o debate sobrea apresentação das LSs como protagonistas na propagação das informações. A criaçãode uma arquitetura voltada para a internacionalização para LSs demonstra que é possívelter aplicações voltadas para línguas espaço-visuais. Tendo as línguas orais como um enteauxiliar na compreensão do conteúdo por parte dos usuários surdos.

Fica evidente que a arquitetura proposta não teve a intenção de utilizar meiosinéditos ou inovadores para a concepção da i18n para LSs. O que denota a riqueza dotrabalho. Demonstrando que é possível utilizar o conhecimento consolidado para resolverproblemas conhecidos (a comunicação entre surdos e ouvintes) trazidos a tona por novasdemandas (meios de comunicação cada dia mais onipresente em todas as sociedades).

5.1 Limitações

Entendemos que o presente trabalho não é suficiente para resolver todos osproblemas de internacionalização para LS em todas as tecnologias. A principal limitaçãodo trabalho são as aplicações stand-alone que não utilizam tecnologia Web, apesar queos conceitos gerais sobre a arquitetura em camadas, MVC e toda a estrutura para ainternacionalização em LS pode ser mantida em casos específicos.

5.2 Trabalhos Futuros 70

Outra limitação diz respeito às tecnologias Web que fazem uso de frameworks

próprios para a camada de apresentação. Frameworks como JavaServer Faces (JSF) paraa linguagem Java por exemplo. Nestes casos a solução fica limitada aos modos de funci-onamento do framework em questão. Sendo que variações da arquitetura para internaci-onalização em LS podem ser observadas levando em consideração as especificidades decada caso.

5.2 Trabalhos Futuros

Possíveis novos trabalhos poderiam focar aspectos específicos de Localização

de software. Levando em consideração não apenas a LS utilizada na região, mas tambéma cultura em que o usuário surdo está inserido. Conforme o W3C [51], esses aspectospodem implicar personalizações relacionadas entre outras coisas:

• Formatos numéricos, de data e hora• Uso da moeda• Uso do teclado• Símbolos, ícones e cores• Texto e gráficos contendo referências a objetos, ações ou ideias que, em uma

determinada cultura, podem ser sujeitas a interpretação errada ou vistas comoinsensíveis.

Referências Bibliográficas

[1] Digital Guide To Developing International Software. Elsevier Science, 2014.

[2] Usage statistics of character encodings for websites, december 2015.

http://w3techs.com/technologies/overview/character_encoding/all/, December 2015.

(Visited on 12/22/2015).

[3] AHMED, A. S.; SEONG, D. S. K. Signwriting on mobile phones for the deaf. In:

Proceedings of the 3rd International Conference on Mobile Technology, Applications

& Systems, Mobility ’06, New York, NY, USA, 2006. ACM.

[4] ALAMEER, A.; HALFOND, W. G. J. An empirical study of internationalization fai-

lures in the web. In: 2016 IEEE International Conference on Software Maintenance

and Evolution (ICSME), p. 88–98, Oct 2016.

[5] ALLEN, J.; CONSORTIUM, U. The Unicode® Standard Version 8.0 – Core Specifi-

cation. Unicode Consortium, 2015.

[6] ALMEIDA, W. G. Introdução à língua brasileira de sinais. Letras Vernáculas, 2013.

[7] BARBOSA, W. A.; JÚNIOR, P. A. P. Um mapeamento sistemático sobre ferramen-

tas de apoio ao ensino de algoritmo e estruturas de dados. Anais do Simpósio

Brasileiro de Informática na Educação, 24(1), 2013.

[8] BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. Addison-

Wesley Professional, 3rd edition, 2012.

[9] BOLDYREFF, C.; BURD, E.; DONKIN, J.; MARSHALL, S. The case for the use

of plain english to increase web accessibility. In: Web Site Evolution, 2001.

Proceedings. 3rd International Workshop on, p. 42–48, Nov 2001.

[10] BOULARES, M.; JEMNI, M. Mobile sign language translation system for deaf

community. In: Proceedings of the International Cross-Disciplinary Conference on

Web Accessibility, W4A ’12, p. 37:1–37:4, New York, NY, USA, 2012. ACM.


[11] BOURQUE, P.; FAIRLEY, R. E. Guide to the Software Engineering Body of

Knowledge, Version 3.0. IEEE Computer Society Press, 2014. www.swebok.org.

[12] BRASIL. Lei nº 13.146, de 6 de julho de 2015. http://www.planalto.gov.

br/ccivil_03/_Ato2015-2018/2015/Lei/L13146.htm, 2015. Acessado em:

20/04/2016.

[13] CASTELEYN, S.; DANIEL, F.; DOLOG, P.; MATERA, M. Engineering Web Applicati-

ons. Data-Centric Systems and Applications. Springer, 2009.

[14] CHAVEIRO, N. Qualidade de vida das pessoas surdas que se comunicam pela

língua de sinais: construção da versão em libras dos instrumentos WHOQOL-

BREF e WHOQOL-DIS. PhD thesis, Doutorado em Ciências da Saúde, 2011.

[15] CHAVEIRO, N.; DUARTE, S. B. R.; DE FREITAS, A. R.; BARBOSA, M. A.; PORTO,

C. C.; DE ALMEIDA FLECK, M. P. Instrumentos em língua brasileira de sinais para

avaliação da qualidade de vida da população surda. Revista de Saúde Pública,

47(3):616–623, 2013.

[16] CHUNG, J.-W.; LEE, H.-J.; PARK, J. C. Improving accessibility to web documents

for the aurally challenged with sign language animation. In: Proceedings of the

International Conference on Web Intelligence, Mining and Semantics, WIMS ’11, p.

33:1–33:8, New York, NY, USA, 2011. ACM.

[17] DA SILVA ALVES, A.; FERREIRA, S. B. L.; DE OLIVEIRA, V. S.; DA SILVA, D. S.

Evaluation of potential communication breakdowns in the interaction of the

deaf in corporate information systems on the web. Procedia Computer Science,

14:234 – 244, 2012. Proceedings of the 4th International Conference on Software

Development for Enhancing Accessibility and Fighting Info-exclusion (DSAI 2012).

[18] DAVID GARLAN, M. S. An introduction to software architecture. In: University,

C. M., editor, An Introduction to Software Architecture, Jan. 1994.

[19] DE ARAÚJO, T. M. U.; FERREIRA, F. L.; SILVA, D. A.; OLIVEIRA, L. D.; FALCÃO,

E. L.; DOMINGUES, L. A.; MARTINS, V. F.; PORTELA, I. A.; NÓBREGA, Y. S.; LIMA,

H. R.; FILHO, G. L. S.; TAVARES, T. A.; DUARTE, A. N. An approach to generate

and embed sign language video tracks into multimedia contents. Information

Sciences, 281:762 – 780, 2014. Multimedia Modeling.

[20] DE QUADROS | LODENIR BECKER KARNOPP, R. Língua de Sinais Brasileira:

Estudos Lingüísticos. Artmed Editora, 2009.

www.swebok.org

http://www.planalto.gov.br/ccivil_03/_Ato2015-2018/2015/Lei/L13146.htm

http://www.planalto.gov.br/ccivil_03/_Ato2015-2018/2015/Lei/L13146.htm


[21] DEAN, J. LPI Linux Certification in a Nutshell. O’Reilly & Associates, Inc.,

Sebastopol, CA, USA, 2001.

[22] DOMINGUES, L. A.; FERREIRA, F. L. S.; ARAÚJO, T. M. U.; NETO, M. S.; JÚNIOR,

L. A.; FILHO, G. L. S.; LEMOS, F. H. Cinelibras: A proposal for automatic

generation and distribution of windows of libras on the cinema rooms. In:

Proceedings of the 20th Brazilian Symposium on Multimedia and the Web, WebMedia

’14, p. 83–90, New York, NY, USA, 2014. ACM.

[23] DOUGLAS SCHMIDT, MICHAEL STAL, H. R. F. B. Pattern-Oriented Software Ar-

chitecture - A System Of Patterns, Volume 1, volume 1. John’Wiley & Sons Ltd.,

1996.

[24] FELICE, M.; DI MASCIO, T.; GENNARI, R. A visual ontology-driven interface

for a web sign language dictionary. In: Proceedings of the 2007 International

Conference on Web Information Systems Engineering, WISE’07, p. 429–440, Berlin,

Heidelberg, 2007. Springer-Verlag.

[25] FOWLER, M. Padrões de Arquitetura de Aplicações Corporativas. BOOKMAN

COMPANHIA ED, 2006.

[26] GAMEIRO, J.; CARDOSO, T.; RYBARCZYK, Y. Kinect-sign, teaching sign language

to “listeners” through a game. Procedia Technology, 17:384 – 391, 2014. Confe-

rence on Electronics, Telecommunications and Computers – {CETC} 2013.

[27] GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of

Reusable Object-Oriented Software (Adobe Reader). Pearson Education, 1994.

[28] GOMES, C. M.; KRUGLIANSKAS, I.; KNEIPP, J. M.; BICHUETI, R. S.; GOMES, B. M.

Analysis of the impact of internationalization on management for sustainability

and business performance. In: 2015 Portland International Conference on Mana-

gement of Engineering and Technology (PICMET), p. 1236–1246, Aug 2015.

[29] GROUP, T. P. O que é o php?, 2017.

[30] HALSTEAD, M. H. Elements of Software Science (Operating and Programming

Systems Series). Elsevier Science Inc., New York, NY, USA, 1977.

[31] HARALAMBOUS, Y.; HORNE, P. S. Fonts & Encodings. O’Reilly Media, Inc., 2007.

[32] HAU, E.; APARÍCIO, M. Software internationalization and localization in web

based erp. In: Proceedings of the 26th Annual ACM International Conference on

Design of Communication, SIGDOC ’08, p. 175–180, New York, NY, USA, 2008. ACM.


[33] KITCHENHAM, B.; CHARTERS, S. Guidelines for performing systematic literature

reviews in software engineering. Technical report, Technical report, EBSE Techni-

cal Report EBSE-2007-01, 2007.

[34] KRASNER, G. E.; POPE, S. T. A cookbook for using the model-view controller

user interface paradigm in smalltalk-80. J. Object Oriented Program., 1(3):26–49,

Aug. 1988.

[35] KRNOUL, Z. Web-based sign language synthesis and animation for on-line as-

sistive technologies. In: The Proceedings of the 13th International ACM SIGAC-

CESS Conference on Computers and Accessibility, ASSETS ’11, p. 307–308, New

York, NY, USA, 2011. ACM.

[36] LEIVA, L. A.; ALABAU, V. Automatic internationalization for just in time lo-

calization of web-based user interfaces. ACM Trans. Comput.-Hum. Interact.,

22(3):13:1–13:32, May 2015.

[37] LÉPINE, J.-F. Phpmetrics, static analysis for php - by jean-françois lépine, 2017.

[38] LÓPEZ-LUDEÑA, V.; GONZÁLEZ-MORCILLO, C.; LÓPEZ, J.; BARRA-CHICOTE, R.;

CORDOBA, R.; SAN-SEGUNDO, R. Translating bus information into sign language

for deaf people. Engineering Applications of Artificial Intelligence, 32:258 – 269,

2014.

[39] MATSUMOTO, T.; KATO, M.; IKEDA, T. Jspad: A sign language writing tool using

signwriting. In: Proceedings of the 3rd International Universal Communication

Symposium, IUCS ’09, p. 363–367, New York, NY, USA, 2009. ACM.

[40] OMS. Deafness and hearing loss. http://www.who.int/mediacentre/

factsheets/fs300/en/, 2015. Acessado em: 02/11/2016.

[41] Orley, J.; Kuyken, W., editors. Quality of Life Assessment: International Perspec-

tives: Proceedings of the Joint-Meeting Organized by the World Health Orga-

nization and the Fondation IPSEN in Paris, July 2 – 3, 1993, chapter The Deve-

lopment of the World Health Organization Quality of Life Assessment Instrument (the

WHOQOL), p. 41–57. Springer Berlin Heidelberg, Berlin, Heidelberg, 1994.

[42] PERRY, D. E.; WOLF, A. L. Foundations for the study of software architecture.

SIGSOFT Softw. Eng. Notes, 17(4):40–52, Oct. 1992.

[43] PRESSMAN, R. Engenharia de Software. AMGH, 2011.

http://www.who.int/mediacentre/factsheets/fs300/en/

http://www.who.int/mediacentre/factsheets/fs300/en/


[44] PRINETTO, P.; TIOTTO, G.; DEL PRINCIPE, A. Designing health care applications

for the deaf. In: Pervasive Computing Technologies for Healthcare, 2009. Pervasi-

veHealth 2009. 3rd International Conference on, p. 1–2, April 2009.

[45] QUADROS, R. D. O bi do bilingüismo na educação de surdos. E. Fernandes (org.),

2005.

[46] RICHARDS, M. Software Architecture Patterns: Understanding Common Archi-

tecture Patterns and When to Use Them. O’Reilly Media, Inc., 2015.

[47] SAN-SEGUNDO, R.; PARDO, J.; FERREIROS, J.; SAMA, V.; BARRA-CHICOTE, R.;

LUCAS, J.; SÁNCHEZ, D.; GARCÍA, A. Spoken spanish generation from sign

language. Interacting with Computers, 22(2):123 – 139, 2010.

[48] SHAW, M.; GARLAN, D. Software Architecture: Perspectives on an Emerging

Discipline. An Alan R. Apt book. Prentice Hall, 1996.

[49] SOMMERVILLE, I. Software Engineering. International Computer Science Series.

Pearson, 2011.

[50] "TIM BERNERS-LEE", "ROY T. FIELDING", L. M. Uniform Resource Identifier (URI):

Generic Syntax. RFC 3986, RFC Editor, January 2005.

[51] W3C. Localization vs. internationalization. https://www.w3.org/

International/questions/qa-i18n, 06 2017. (Acessado em 27/06/2017).

[52] XIA, X.; LO, D.; ZHU, F.; WANG, X.; ZHOU, B. Software internationalization and

localization: An industrial experience. In: 2013 18th International Conference on

Engineering of Complex Computer Systems, p. 222–231, July 2013.

[53] YAO, D.; QIU, Y.; HUANG, H. Web-based chinese sign language broadcasting

system. In: Proceedings of the 2009 International Cross-Disciplinary Conference on

Web Accessibililty (W4A), W4A ’09, p. 101–103, New York, NY, USA, 2009. ACM.

[54] YUNKER, J. Beyond Borders: Web Globalization Strategies. Safari tech books

online. New Riders, 2002.

https://www.w3.org/International/questions/qa-i18n

https://www.w3.org/International/questions/qa-i18n

APÊNDICE ARevisão Sistemática da Literatura

Essa Revisão Sistemática da Literatura (RS), tem por objetivo avaliar o cenárioda Engenharia de Software (ES) visando os usuários dependentes da linguagem desinais. A avaliação prevê a caracterização de técnicas, métodos e ferramentas na ESpara o desenvolvimento de softwares que interajam com usuários de línguas de sinais.O protocolo da RS, que se segue, foi elaborado conforme definido por Kitchenham [33].E foi dividida em três fases: Planejamento, Condução e Documentação.

A.1 Planejamento

O planejamento foi concebido após a identificação das necessidades da RS,subsidiando a preparação do protocolo de pesquisa. O protocolo identificou as questõese estratégias de pesquisa, bem como os critérios de inclusão e exclusão dos trabalhosencontrados. O motivador da RS foram as respostas para as seguintes perguntas:

Q1 - Como a Engenharia de Software tem apoiado surdos utilizadores de línguas desinais?

Q2 - Quais áreas de conhecimento (knowledge areas - KA) do SWEBoK são abordadas?Q3 - Quais abordagens (por exemplo: ferramentas, processos, metodologias, etc.) foram

usados pelos artigos identificados na RS?Q4 - Quais LS (por exemplo: Libras, ASL, etc) foram utilizadas pelos artigos identifica-

dos na RS?

As Bibliotecas Digitais (BD) ACM Digital Library (dl.acm.org), IEEE Xplorer

(ieeexplore.ieee.org), Science Direct (www.sciencedirect.com) e Scielo (www.scielo.br)

foram utilizadas por contemplar os seguintes critérios:

(i) Bibliotecas digitais consolidadas entre a comunidade de Ciências da Computação,(ii) Bibliotecas digitais que permitam buscas por strings como palavras chave e

(iii) Bibliotecas digitais que permitam acesso online.

Apêndice A 77

A string de busca foi elaborada utilizando palavras em inglês de modo quepudesse retornar trabalhos relacionados ao tema proposto: “Como a Engenharia deSoftware pode apoiar o desenvolvimento de aplicações para usuários dependentes delínguas de sinais”.

A escolha da string foi o ponto crucial do planejamento da revisão. Optou-sepela escolha de palavras de sentido mais geral para o tema proposto, para não tornar apesquisa orientada a uma ideia pré concebida nem excessivamente abrangente, impos-sibilitando a análise dos trabalhos obtidos. A string então, foi criada tendo a seguinteestrutura:

((deaf* OR “hard of hearing” OR “hearing impaired”)

AND (“sign language”))

AND (software)

O protocolo da RS conta ainda com alguns critérios para a seleção dos trabalhosencontrados. Esses critérios foram elaborados a fim de refinar a busca, avaliando ostrabalhos relevantes para a revisão. Os critérios para a inclusão dos trabalho são:

(i) Artigos em inglês(ii) Artigos em português

(iii) Artigos que se enquadram nos critérios da string de busca(iv) Artigos que não se enquadrem nos critérios anteriores, mas que sejam reconhecida-

mente relevantes pela comunidade cientifica para o tema pesquisado

Além dos critérios de inclusão foram definidos os critérios de exclusão, onde édefinido critérios para a rejeição de trabalhos que não se enquadram no escopo da revisãoou que não tem a devida relevância para a resolução das principais perguntas da revisão.Os critérios de exclusão são:

(i) Artigos que não obedeçam os critérios de inclusão(ii) Artigos que não estejam associados ao tema proposto

(iii) Artigos de baixa relevância acadêmica(iv) Artigos que não apresentam a metodologia sobre algum corpo de conhecimento da

Engenharia de Software

A.2 Condução

Após a criação do protocolo da RS na fase de planejamento, foi realizado aexecução da string nos motores de busca das BDs. Nessa fase foram encontrados um

Apêndice A 78

total de 413 artigos correspondentes aos termos da busca. Desse total, 258 artigos foramoriundos da BD ACM, 117 da BD Science Direct, 37 da IEEE e 1 artigo da Scielo,conforme Tabela A.1.

Tabela A.1: Artigos obtidos por biblioteca digital

Bibliotecas Digitais Totais

ACM Digital Library 258Science Direct 117IEEE Xplorer 37Scielo 1

TOTAL 413

A.2.1 Seleção

A condução do protocolo se deu em duas etapas Seleção e Extração. Ondea etapa de seleção foi a responsável por avaliar a qualidade dos trabalhos medianteaos critérios de seleção proposto no protocolo, visando garantir a qualidade dos artigosencontrados para a pesquisa.

Nessa etapa, a seleção foi realizada por três participantes. Dois alunos demestrado, responsáveis por lê os títulos, abstracts e resultados de todos os 413 artigos eclassificá-los como Aceito, Rejeitado ou Duplicado. O terceiro participante foi o professororientador do mestrado, responsável por avaliar os resultados em conflito, quando osresultados dos alunos avaliadores não chegaram a um consenso.

O resultado geral dessa etapa pode ser visualizado na Tabela A.2.

Tabela A.2: Classificação geral dos trabalhos após a seleção

Classificação geral dos trabalhos

Aceitos 134Rejeitados 278Duplicados 1

Além da classificação geral, foi realizado a priorização dos artigos com base emsuas prioridades de leitura. Ou seja, qual a importância do artigo para a RS que está sendorealizada. A prioridade foi definida como sendo: Baixa, Alta e Muito Alta.

Os resultados obtidos por priorização demonstra a relevância dos artigos para aRS em vista ao tema proposto. Caracterizando o quão relevante são os artigos encontra-dos. Dos 134 artigos selecionados para a etapa de extração, 66 artigos tinha a prioridade

Apêndice A 79

igual a Baixa, 21 artigos tinham a prioridade igual a Alta e 47 artigos tinha a prioridadeigual a Muito Alta. Conforme Tabela A.3.

Tabela A.3: Classificação dos artigos conforme suas prioridadesde leituras

Classificação geral (413 Artigos) Classificação dos 134 AceitosBaixa 345 66Alta 21 21Muito Alta 47 47

A.2.2 Extração

Após a etapa de seleção, tem inicio a etapa da extração que consiste em ler osartigos na integra, extraindo as resposta para a as perguntas que motivaram a pesquisa. Asperguntas foram formuladas e inseridas no protocolo da RS.

Na etapa de extração aplicou-se o mesmo método de avaliação da etapa deseleção, utilizando os mesmos critérios da etapa anterior através de uma leitura detalhadaobservando os parâmetros qualitativos da RS. Dos 134 artigos, resultaram em 47 artigosaceitos e 87 artigos rejeitados após a etapa de extração, conforme Tabela A.4.

Tabela A.4: Resultado da etapa de extração

Resultado após a etapa de extraçãoAceitos 47Rejeitados 87Ignorados 0

Aplicando os mesmos critérios de prioridades da etapa anterior, obtivemos 33artigos com a prioridade de leitura igual a Muito Alta e 14 artigos com a prioridade deleitura igual a Alta. Como pode ser observado na Tabela A.5.

Tabela A.5: Resultado da etapa de extração por prioridade deleitura

Resultado por prioridade de leituraMuito Alta 33Alta 14Baixa 0

Apêndice A 80

A.2.3 Q1 - Como a Engenharia de Software tem apoiado surdosutilizadores de línguas de sinais?

Com base nos 47 artigos podemos afirmar que a Engenharia de Software temauxiliado os surdos, principalmente, no projeto e construção de ferramentas de tradução,métodos de aprimoramento de reconhecimento dos sinais e na melhoria da usabilidadedos utilizadores das mais variadas LS.

Na área de entretenimento temos iniciativas como o CineLibras [22]. Umaproposta de geração automática de janelas com tradução utilizando avatars 2D em LínguaBrasileira de Sinais a partir das legendas dos filmes exibidos em salas de projeção digitalde cinemas. Permitindo uma maior compreensão do conteúdo dos filmes por utilizados daLS em questão.

Para a Educação temos [26], que aborda o aprendizado de LS através de jogosdesenvolvidos para a plataforma de jogos Xbox da empresa Microsoft. Simulando umasala de aula virtual, onde o utilizador surdo pode interagir com ouvintes ou outrosutilizadores surdos através do dispositivo de captura de imagens chamado Kinect, quecaptura os gestos e interpreta os sinais.

Algumas outras propostas de utilizações são abordadas, como a assistência paraidentificação de ônibus do sistema de transporte publico da Espanha [38]. Assistência ainformações do sistema de saúde da Itália [44]. E comunicação entre surdos e ouvintesutilizando reconhecimento de imagens para traduzir os sinais para texto e entre ouvintese surdos utilizando avatars para a representação dos sinais.

A.2.4 Q2 - Quais áreas de conhecimento (knowledge areas - KA) doSWEBoK são abordadas?

De todas as 15 áreas de conhecimentos do SWBoK V3 [11], 7 não foramcontempladas em nenhum dos 47 artigos aceitos na etapa de extração. As demais áreas deconhecimento podem ser visualizados na Tabela A.6. Sendo que as áreas de conhecimentocom a maior quantidade de abordagens são: Projeto de Software (Software Design) com36 abordagens, Construção de Software (Software Construction) com 23 abordagens eRequisitos de Software (Software Requirements) com 9 abordagens1.

1Alguns artigos abordam mais de uma área de conhecimento

Apêndice A 81

Tabela A.6: Áreas de conhecimento do SWEBoK contempladaspelos artigos da RS

SWEBOK - KA Resultado após a extração

SWEBOK : Software requirements 9SWEBOK : Software design 36SWEBOK : Software construction 23SWEBOK : Software testing 11SWEBOK : Software maintenance 0SWEBOK : Software configuration management 1SWEBOK : Software engineering management 0SWEBOK : Software engineering process 0SWEBOK : Software engineering models and methods 0SWEBOK : Software quality 2SWEBOK : Software engineering professional practice 0SWEBOK : Software engineering economics 0SWEBOK : Computing foundations 0SWEBOK : Mathematical foundations 5

Apesar de Projeto de Software ter uma maior quantidade de artigos publicados, amaioria dos artigos tratam de projetos de ferramentas de tradução. Como era de se esperar,a maior parte dos trabalhos analisados tentam criar uma ponte entre uma determinadalíngua oral e sua correspondente em sinais.

Ora, para sistemas globais onde a interação é realizada por falantes de diversaslínguas e culturas, esses mecanismos de tradução são pouco eficientes, pois não permitema tradução de uma língua oral qualquer para uma língua de sinais que não seja suahomóloga.

Além, não foi definido um Projeto de Software que permita a desenvolvedorescriarem softwares com padrões estabelecidos e normas definidas para LS. Um exemplodisso é o fato de normas, como a ISO 639, não definir os códigos das línguas de sinaiscomo faz com as demais línguas orais.

A internacionalização, bem como a localização do software, não leva em con-sideração as línguas de sinais. Relegando o entendimento do conteúdo apresentado aosusuários surdos a uma condição cognitiva. Ou seja, basta apresentar textos simples, comilustrações e sentenças simples para que os usuários surdos tem um melhor entendimentode seus significados [9].

Achamos que, a cima de tudo, a Língua é uma manifestação cultural de umdeterminado grupo de pessoas e como tal, deve ser respeitada em todos os seus aspectos.

Apêndice A 82

As LS representam o modo de pensar, agir e de ser de um grupo expressivo de utilizadoresde sistemas computacionais e por isso deve ser respeita em sua totalidade.

A.2.5 Q3 - Quais abordagens (por exemplo: ferramentas, processos,metodologias, etc.) foram usados pelos artigos identificados naRS?

As duas principais abordagens identificadas nos artigos foram ferramentas com34 citações e metodologias com 10 citações. Vide Tabela A.7.

Tabela A.7: Principais abordagens utilizadas nos artigos da RS

Abordagens Quantidade

Processos 0Ferramentas 34Metodologia 10

Um ponto que chama a atenção é o fato de não ter sido encontrado artigos quetratasse de um processo de desenvolvimento direcionado ao publico utilizador de LS.Sendo que a maior parte dos artigos tratam da criação de ferramentas de tradução deLS para uma determinada língua oral, por meio de metodologias de reconhecimento deimagens.

As metodologias apresentadas, em grande parte, demonstram como determina-das técnicas de reconhecimento de imagens são mais apropriadas para determinados tiposde arquiteturas de tradução que outros. Alguns, ainda, utilizam o reconhecimento de ima-gens para a criação de avatars para a substituição de interpretes reais.

De todos os 47 artigos selecionados, 10 tratam de sistemas Web[19][22][17][10][16][35][44][53][24][9]. Sendo que a utilização de avatars é utilizadoem 9 deles para a tradução de línguas orais para LS. A utilização de avatars empregauma dinâmica na tradução, o que não seria possível com interpretes reais pré-gravados.Porem, diminui a assertividade e a corretude da interpretação.

Dos 10 artigos que tratam de sistemas Web, o artigo [9] chama atenção portratar da acessibilidade de páginas Web que utilizam textos em Inglês Britânico de modoa facilitar a compreensão das informações transmitidas. Utilizando linguagem clara esimples para passar uma ideia completa em um único paragrafo, por exemplo. Porém,o artigo salienta que não existem regras estabelecidas apenas guias de utilização.

Nenhum dos artigos apresentam suporte a tradução de múltiplas LS, nem umameio que auxiliem os desenvolvedores a criarem aplicações para LS que não sejam pormeio da língua oral equivalente. O que nos retorna ao fato de não ter sido encontrado

Apêndice A 83

artigos que contemplem processos de desenvolvimento para a internacionalização de LSou que apoie a Engenharia de Software na implementação de softwares com suporte avárias LS.

A.2.6 Q4 - Quais LS (por exemplo: Libras, ASL, etc) foram utiliza-das pelos artigos identificados na RS?

Os artigos identificados na RS contemplam várias LS, o que desmistifica a crençade que existe uma única LS no mundo todo. Independente da região do globo, todas aslocalidades necessitam de uma forma de interagir com os surdos. As quantidade de LScontempladas por esta RS podem ser observada na Tabela A.8.

Tabela A.8: Principais Línguas de Sinais utilizadas pelos artigosda RS

Línguas de Sinais Quantidade

Sign Language : Brazilian Sign Language (Libras) 5Sign Language : American Sign Language (ASL) 10Sign Language : Spanish Sign Language (LSE) 9Sign Language : Japanese Sign Language (JSL) 2Sign Language : Chinese Sign Language (CSL) 2Sign Language : Malaysian Sign Language (BIM) 1Sign Language : Italian Sign Language (LIS) 3Sign Language : Australian Sign Language (Auslan) 1Sign Language : British Sign Language (BSL) 2Sign Language : Portuguese Sign Language (LGP) 1Sign Language : Thai Sign Language (TSL) 1Sign Language : Czech Sign Language (CSL) 1Sign Language : Não Informado 7

Os artigos selecionados apresentam 12 LS diferentes, sendo que alguns artigosnão mencionam diretamente uma LS específica. Apesar de diferentes, as LS têm emcomum o fato da execução ter as mãos e o rosto como partes mais envolvidas na produçãodos gestos [14]. Talvez por isso, seja tão complicado desenvolver avatars que representemfidedignamente os sinais das LS.

O artigo [35] apresenta um framework para aplicações Web que propõe renderi-zar avatars 3D em tempo-real para a Língua Checa de Sinais. A bordagem utiliza duasformas de animações, uma para os gestos faciais e outra para os gestos manuais, de ma-neira complementar melhorando a identificação dos sinais pelos surdos.

Apêndice A 84

A.3 Resultados da Revisão (Documentação)

A documentação é necessária para que o conhecimento fruto da revisão sejacompartilhado, auxiliando demais pesquisadores na busca por novas respostas. Para tal,este trabalho de dissertação intenta propagar o conhecimento que adquirimos com a RS,mostrando como a Engenharia de Software tem abordado um tema que impacta tantaspessoas.

O cruzamento dos dados referentes as áreas de conhecimento do SWEBoK,Tabela A.6, e dos dados referentes as principais abordagens identificadas nos artigos,Tabela A.7, revela algo interessante. Existe um maior esforço de pesquisa para projetar econstruir ferramentas de tradução.

Variadas técnicas e metodologias são utilizadas para desenvolver ferramentasque interajam com usuários surdos. Onde a maioria adotam o uso de avatars pararepresentar a sinalização e para a interação do usuário surdo com o sistema ou comusuários ouvintes é empregado o reconhecimento de imagens para a captura dos gestossinalizados.

Existem algumas iniciativas que recorrem a construção de ferramentas parainterpretação e tradução de SignWriting, uma escrita de símbolos para a representaçãode LS [39] [3] [47]. E uma abordagem para acessibilidade visando a forma de disposiçãodo conteúdo em texto para ajudar os usuários que tem LS como primeira língua [9], masque não conta com regras claras ou normas bem definidas.

Contudo, não foi encontrado processos próprios da Engenharia de Softwareque permitissem o desenvolvimento de aplicações Web que pudessem ser utilizados porouvintes e surdos da mesma maneira que é feito entre as várias línguas orais ao redor domundo. Representando uma possível oportunidade de pesquisa.

A Internacionalização (i18n) e Localização (l10n), amplamente difundida emdesenvolvimento de softwares comerciais para múltiplos mercados consumidores, nãoobtiveram representações entre os artigos da RS. O que nos leva a acreditar que há muitoo que ser feito nessas áreas. Em especial para o desenvolvimento de softwares de impactoglobal.

APÊNDICE BInternationalization I18n, Localization L10n eMultilingual Software

B.1 Introdução

Com a popularização dos aparelhos Smartphones e demais dispositivos mobile,fez surgir uma necessidade de tornar o uso acessível a todos os tipo de usuário em todosos cantos do planeta. Para que um aplicativo desenvolvido na America do Norte possa sercompreendido por um usuário da Asia é necessário que o aplicativo esteja preparado, nãosó no que se refere a tradução, mas também em aspectos de formatação de data e hora,pontuação, direção da escrita, etc.

Além dos aspectos supracitados, as aplicações não podem inflingir questõeslegais, culturais ou religiosas. Sendo necessário que sejam desenvolvidos levando emconsideração todos os motivos levantados, e mais, que sejam projetados para que odesenvolvimento seja transparente a esses pontos.

Daí surge algumas expressões como Internacionalização, Localização e Soft-

ware Multilingual, entre outras. Todas essas expressões tem por objetivo facilitar o desen-volvimento de aplicações que possam ser utilizados por usuários dos mais variados paísese regiões, culturas, religiões, etnias, etc.

B.2 O que é Internacionalização, Localização e SoftwareMultilingual

A Internacionalização de Software, conforme [21], é o processo de designingde um software para que o mesmo possa ser adaptado a várias línguas e regiões semalterações na sua forma de desenvolvimento. Ainda segundo [21] e também [13], o termoé frequentemente abreviado para I18n (do inglês Internationalization, onde tem-se 18letras entre a letra “I” inicial e a letra “n” final.), tendo sido cunhada no Digital Equipment

Corporation no final da decada de 70, inicio dos anos 80.

Apêndice B 86

O termo Localização, dentro do contexto de desenvolvimento de software, dizrespeito ao desenvolvimento de software levando em consideração a possição geograficaque se encontra o usuário. Comumente abreviada para L10n (Assim como I18n, L10n éa abreviação da palavra em inglês: Localization onde tem-se a primeira letra “L” seguidapor 10 outras letras e terminando com a letra “n”).

O termo software Multilingual é defnido em [1], como sendo um produtode software que permite aos usuários interagir com o software usando mais de umalinguagem.

Pelas definições anteriores podemos concluir que, um software é multilingualquando é capaz de se apresentar ao usuário em mais de uma línguagem. A localicalizaçãoé quando o software é capaz de alterar a línguagem e demais aspectos culturais levandoem consideração a posição geografica do usuário. E a internacionalização é a união doaspecto multilingual do software, levando em consideração outros aspectos relacionadosa localizaçãoe aspectos culturais do grupo ao qual o usuário pertence.

B.3 A Internacionalização

Neste trabalho focaremos na Internacionalização e todos os seus aspectos. Paraentendermos melhor a Internacionalização de software, precisamos entender outros as-pectos que permitem que isso ocorra, tais como: URI e encoding entre outros.

B.3.1 URI

Um Identificador Uniforme de Recursos (URI do ingles, Uniform ResourceIdentifier), é uma sequencia compacta de caracteres que identifica um recurso físico ouabstrato, fornece um meio simples e extensível para identificar um determinado recurso[50].

B.3.2 Encoding

O encoding, codificação ou também chamado bit code, é um conjunto específicode padrões de bits para representação gráfica de caracteres ou de caracteres de controle,[31].

Para que a internacionalização dos softwares sejam consistente o software deveser escrito seguindo um padrão mundial de encoding.

Atualmente existe diversos tipos de padrões de encodings, os mais utilizados emsites da web, conforme [2], podem ser vistas na Figura B.1 1:

1Dados extraídos dia 22 de Dezembro de 2015

Apêndice B 87

Figura B.1: Encodings mais utilizados em websites no ano de 2015

B.4 Unicode

O Padrão Unicode é o padrão universal de codificação 2 de caracteres paraescrever caracteres e textos. O Padrão Unicode e as suas especificações associadas forneceaos programadores uma única codificação universal de caracteres, descrições extensivas,e uma vasta quantidade de dados sobre como os caracteres devem funcionar [5].

O Padrão Unicode especifica um valor numérico (code point) e um nome paracada um de seus caracteres. Em sua versão 8.0, contem 120.672 caracteres de linguagensdo mundo. Esses caracteres são mais que suficientes não apenas para a comunicaçãodas línguas de todo o mundo, mas também para representar a forma clássica de muitaslinguagens. O Padrão Unicode foi projetado para ser:

• Universal. O repertorio deve ser grande o suficiente para abranger todos os caractereque são comumente usados em trocas de textos em geral, incluindo conjuntos decaracteres internacionais, nacionais e industriais.

• Eficiente. Texto puro é simples para analisar: software não tem que manter o estadoou procurar sequências de escape especiais, e sincronização de caracteres a partir

2do inglês encoding

Apêndice B 88

de qualquer ponto em um fluxo de caracteres é rápida e inequívoca. Um código decaracteres fixo permite a triagem eficiente, busca, visualização e edição de texto.

• Inequívoco. Qualquer valor numérico Unicode sempre representa o mesmo carácter.

A especificação dá ao programador uma extensa descrição e uma vasta quanti-dade de dados sobre a manipulação de texto, incluindo:

• dividir palavras e quebra de linhas• tipo de texto em diferentes línguas• formatação numérica, datas, horários e outros elementos apropriados a diferentes

localidades• apresentação de textos em línguas cujo fluxo de escrita é da direta para a esquerda,

como Árabe ou Hebraico• lidar com conceitos de segurança se preocupando com muitos caracteres parecidos

das escritas ao redor do mundo

B.5 Conjunto de Tags para Internacionalização W3C

A recomendação W3C do dia 29 de Outubro de 2013 [51], define o conjunto detags para internacionalização (ITS - do inglês Internationalizartion Tag Set). O conceitochave do ITS é abstrair a noção de categorias de dados. Onde as categorias de dadosdefinem a informação que podem ser convertidos via ITS.

A motivação para a separação das definições de categorias de dados de suaimplementação permite diferentes implementações com as seguintes características:

• Vários tipos de conteúdos (geralmente XML 3 ou HTML).• Para uma única parte do conteúdo, por exemplo um elemento <p>. Esta abordagem

é denominada local.• Por várias partes do conteúdo em um documento, ou mesmo um conjunto de

documentos. Esta abordagem é denominada global.• Para um vocabulário completo de marcação. Isto é feito adicionando marcações de

declarações ITS para o esquema do vocabulário.

3Atualmente, cada vez mais tem se substituíndo o XML por Json. Principalmente em aplicações Web

APÊNDICE CA Biblioteca signlang.js

1 /**

2 * @author Paulo Marcos Soares Rodrigues -

[email protected]

3 * @name Sign Language Translate

4 * @purpose Make possible the sign language

internationalization

5 **/

6

7 /**

8 * @license Este trabalho esta licenciado sob a Licenca

Atribuicao -NaoComercial 4.0 Internacional Creative

Commons.

9 * Para visualizar uma copia desta licenca , visite http

://creativecommons.org/licenses/by-nc/4.0/

10 * ou mande uma carta para Creative Commons , PO Box

1866, Mountain View , CA 94042, USA.

11 **/

12

13 (function signlang (){

14 var sltranslate =

15 $(document).ready(function main (){

16 var $body = document.body;

17 var optionMenu = document.createElement('

select');

18 var optionID = optionMenu.setAttribute('id',

'sl-menu');

19 //$body.appendChild(optionMenu);

20 var $menu = $("#sl-menu");

Apêndice C 90

21 var $option = $(document.

getElementsByTagName("option"));

22 $.getJSON('i18n/config.json', function

confiJSON (jd) {

23 //$menu.append('<option>'+jd.default+'</

option>');

24 $.each(jd.languages, function setMenu (i

, value){

25 var option = $('<option/>').val(

value.idLang).text(value.name);

26 $menu.append(option);

27 var $e = document.getElementById('sl

-menu');

28

29 $e.addEventListener('change',

function setItem (){

30 var selectedItem = $e.options[$e

.selectedIndex].text;

31 var selectedValue= $e.options[$e

.selectedIndex].value;

32

33 if (selectedValue===value.idLang

) {

34

35 var p = value.path;

36

37 $.getJSON(p, function

setSignLang (j){

38 var r = $(jQuery("#

qualidade").contents

().find("iframe"));

39

40 for (var b = 0; b < r.

length; b++) {

41 var at = r[b];

42 var i18n = at.

getAttribute('

signlang');

Apêndice C 91

43 var w = i18n.split("

.");

44 var x = null;

45 for (i = 0; i < w.

length; i++) {

46 if(x===null){

47 x = j[w[i]];

48 }else{

49 x = x[w[i]];

50 }

51 }

52 var video = x;

53 at.setAttribute('src

', video);

54 }

55 });

56 } else {

57 if(selectedItem===jd.default

){

58 // $('iframe').hide();

59 // $(jQuery("#qualidade")

.contents().find("

iframe")).hide().

reload(true);

60 }else{

61 $(jQuery("#qualidade").

contents().find("

iframe")).show();

62 }

63 }

64 });

65 });

66 });

67 });

68 })();

Listing C.1: Biblioteca de classe signlang.js

Documents

Projeto de Software para Internacionalização em Línguas de ... · Mundial da Saúde traduzido para Libras pela Faculdade Letras da Universidade Federal de Goiás (UFG), em parceria