Anda di halaman 1dari 66

FACULDADES ALVES FARIA

SISTEMAS DE INFORMAO

Carlos Henrique Lemos


Sheldon Led Martins de Oliveira

AUTOMAO RESIDENCIAL CONTROLADA POR DISPOSITIVOS


MVEIS POR MEIO DE COMANDO DE VOZ

GOINIA
DEZEMBRO DE 2015

FACULDADES ALVES FARIA


SISTEMAS DE INFORMAO

Carlos Henrique Lemos


Sheldon Led Martins de Oliveira

AUTOMAO RESIDENCIAL CONTROLADA POR DISPOSITIVOS


MVEIS POR MEIO DE COMANDO DE VOZ

Trabalho de concluso de curso


apresentado como parte da avaliao da
aprendizagem, na disciplina TCC II, 8
perodo do Curso de Sistemas da informao
das Faculdades Alves Faria, orientada pelo
Prof. Msc. Thales Baliero Takao.

Linha de pesquisa
Engenharia da Computao, Engenharia de Software,

Professor Orientador
Prof. Msc. Thales Baliero Takao

GOINIA
DEZEMBRO DE 2015

Este trabalho dedicado s nossas esposas, pelo apoio e compreenso, e aos nossos
professores, que contriburam para nosso carter intelectual e profissional.

RESUMO
LEMOS, Carlos Henrique; OLIVEIRA, Sheldon Led Martins. Automao residencial
controlada por dispositivos mveis por meio de comando de voz, 2015. 66 f. - Curso de
Sistemas de Informao - Faculdades Alves Faria. Goinia, 2015.

O avano que as Tecnologias de Informao e Comunicao (TIC) tem passado nos


ltimos 30 anos apenas corrobora a razo essencial do surgimento dessa rea: facilitar a vida
do ser humano. Os valores mais acessveis para acesso internet e s tecnologias mveis tem
tornado tais tecnologias difundidas e populares na sociedade, possibilitando maior integrao
entre o homem e o mundo moderno, alm de aumentar a capacidade do homem, ou auxili-lo
a realizar atividades que sem tais tecnologias seriam impossveis. A tecnologia pode
automatizar diversas atividades antes feitas por fora humana ou animal, e com a
possibilidade de conexo de aparelhos eltricos ou eletrnicos internet, por meio de
plataformas de prototipagem eletrnica como o Arduino, a automao residencial pode ser
elevada a um nvel maior de mobilidade. A composio tecnolgica dos dispositivos mveis
modernos, dotados de internet, microfone, alto-falante, dentre outras caractersticas e a
evoluo da plataforma Android, com seu assistente interpretador de linguagem natural,
Google Now, torna possvel o controle de aparelhos residenciais a qualquer distncia pela
internet por meio de comandos de voz. A integrao entre o Arduino e aparelhos eltricos e
eletrnicos aos dispositivos mveis pela internet d maior conforto ao usurio, ao ponto que a
possibilidade de interpretao de linguagem natural presente na plataforma Android deixa um
sistema de automao residencial mais acessvel s pessoas idosas ou portadoras de
necessidades especiais.

Palavras-chave: Automao residencial, acessibilidade, dispositivos mveis.

ABSTRACT

LEMOS, Carlos Henrique; OLIVEIRA, Sheldon Led Martins. Home automation


controlled by mobile devices with voice command, 2015. 66 f. - Information Systems course Faculdades Alves Faria. Goinia, 2015.

The advance that Information and Communication Technologies (ICT) has spent the
past 30 years only confirms the essential reason for the emergence of this area: to facilitate the
life of the human being. The most affordable value for internet access and mobile
technologies made them widespread and popular in society, allowing greater integration
between man and the modern world, as well as increasing the capacity of men, or help them
carry out activities that without such technologies would be impossible. The technology can
automate several activities previously done by human or animal strength, and through the
possibility of electrical or electronic devices to the internet connection using electronics
prototyping platforms such as Arduino, home automation can be elevated to a higher level of
mobility. Technological composition of modern mobile devices, equipped with internet,
microphone, speakers, and other features and the evolution of the Android platform, with its
natural language interpreter assistant, Google Now, makes it possible to control residential
appliances at any distance by internet via voice commands. The integration between Arduino
and electrical and electronic appliances to mobile devices via the Internet gives greater
comfort to the user, therefore the possibility of interpreting natural language present in
Android platform makes it a more affordable home automation system for the elderly or
people with some special needs.

Keywords: Home automation, accessibility, mobile devices.

SUMRIO

1
2

INTRODUO .......................................................................................................................... 9
FUNDAMENTAO TERICA ........................................................................................... 11

2.1 AUTOMAO RESIDENCIAL .............................................................................. 11


2.2 ARDUINO ................................................................................................................. 15
2.3 ACESSIBILIDADE ................................................................................................... 18
2.4 ANDROID ................................................................................................................. 21
2.4.1 XPOSED ............................................................................................................. 26
2.5 REDES SEM FIO ...................................................................................................... 27
2.5.1 SERVIOS WEB (WEB SERVICES)............................................................... 30
2.5.2 ZIGBEE .............................................................................................................. 31
2.6 ENGENHARIA DE SOFTWARE ............................................................................ 32
2.6.1 CASOS DE USO ................................................................................................ 37
2.6.2 DIAGRAMAS DE CLASSE .............................................................................. 39
2.6.3 DIAGRAMA DE COMPONENTES ................................................................. 41
2.6.4 DIAGRAMA DE IMPLANTAO .................................................................. 42
3

PROJETO DE SOFTWARE................................................................................................... 45

3.1 DESCRIO GERAL DO PRODUTO .................................................................... 46


3.1.1 FUNES DO PRODUTO ............................................................................... 46
3.2 ESPECIFICAO DE REQUISITOS ...................................................................... 46
3.2.1 REQUISITOS FUNCIONAIS ............................................................................ 46
3.2.2 REQUISITOS NO-FUNCIONAIS .................................................................. 46
3.2.3 REGRAS DE NEGCIO ................................................................................... 46
3.3 PROTTIPOS ........................................................................................................... 47
3.3.1 PR001 TELA INICIAL ................................................................................... 47
3.3.2 PR002 TELA DE EXCLUSO ...................................................................... 48
3.3.3 PR003 TELA DE CADASTRO ...................................................................... 48
3.4 MODELAGEM.......................................................................................................... 49
3.4.1 DIAGRAMA DE CASOS DE USO ................................................................... 49
3.4.2 DESCRIO DOS CASOS DE USO ............................................................... 50
3.4.3 DESCRIO DOS ATORES ............................................................................ 51
3.4.4 DIAGRAMA DE CLASSES .............................................................................. 52
4

IMPLEMENTAO E IMPLANTAO ............................................................................ 53

4.1
4.2
4.3
4.4
4.5
5
6

PORQUE ARDUINO? .............................................................................................. 53


CONTROLANDO O ARDUINO .............................................................................. 56
O COMANDO DE VOZ DO ANDROID ................................................................. 57
COMUNICANDO NA REDE ................................................................................... 59
A CONEXO ENTRE O ARDUINO E O ANDROID ............................................ 60

CONSIDERAES FINAIS .................................................................................................. 62


REFERNCIAS ....................................................................................................................... 64

LISTA DE FIGURAS
Figura 1: O Arduino Uno ............................................................................................................. 16
Figura 2: Percentual de usurios por verso Android ..................................................................... 23
Figura 3: Exemplo de utilizao da classe Activity ........................................................................ 24
Figura 4: Exemplo de utilizao da classe Intent ............................................................................ 25
Figura 5: Ciclo de Vida de desenvolvimento de um software .......................................................... 36
Figura 6: Exemplo de caso de uso com relacionamento de comunicao e extenso ......................... 39
Figura 7: Exemplo de modelagem de classes simulando um sistema de controle bancrio ................ 41
Figura 8: Exemplo de diagrama de componentes de um sistema de controle bancrio ...................... 42
Figura 9: Exemplo de diagrama de implantao de um sistema de controle bancrio ........................ 43
Figura 10: PR001 Tela Inicial .................................................................................................... 47
Figura 11: Tela de Excluso ......................................................................................................... 48
Figura 12: Tela de Cadastro ......................................................................................................... 48
Figura 13:Diagrama de Caso de Uso ............................................................................................. 49
Figura 14:Diagrama do aplicativo mvel....................................................................................... 52
Figura 15:Diagrama do servio (web service) ................................................................................ 52
Figura 16:Plataforma de prototipao Arduino .............................................................................. 53
Figura 17: Mdulo Rel em ao com o Arduino ........................................................................... 54
Figura 18:Cdigo adicionado ao Arduno para controle do mdulo rel .......................................... 54
Figura 19: LEDs Emissores e Detectores de infravermelho ............................................................ 55
Figura 20: Implementao com os cdigos decodificados e emisso de infravermelho .................. 55
Figura 21: Cadastro com possibilidade de aliar comando de voz ..................................................... 56
Figura 22: Aplicativo instalado no dispositivo mvel. .................................................................... 56
Figura 23: Mdulo instalado no Xposed Framework e os seus plugins. ........................................... 57
Figura 24: Cdigo responsvel pela interpretao dos comandos de voz .......................................... 58
Figura 25: Xbee USB .................................................................................................................. 59
Figura 26: Shield Xbee acoplado ao Arduino ................................................................................ 59
Figura 27: Representao da estrutura de comunicao do sistema de automao ............................ 60
Figura 28: Cdigo para o Shield XBee acoplado ao Arduino .......................................................... 61

LISTA DE SIGLAS

API

Application Programming Interface (Interface de Programao de

Aplicaes)
APK

Android Package (Pacote Android)

HTML

HyperText Markup Language (Linguagem de Marcao de Hipertexto)

GPS

Global Position System (Sistema Global de Posicionamento)

IDE

Integrated Development Enviroment (Ambiente de Desenvolvimento

Integrado)
IHC

Interface Humano-Computador

IOT

Internet Of Things (Internet das Coisas)

IP

Internet Protocol (Protocolo da Internet).

LAN

Local Access Network (Rede de Acesso Local)

OHA

Open Handset Alliance

PNE

Portador de Necessidades Especiais

REST

REpresentational

State

Transfer

(Transferncia

de

estado

representacional)
SDK

Software Development Kit (Kit de Desenvolvimento de Software)

STT

Speech-to-Text (Voz-para-Texto)

TCP

Transmission Control Protocol (Protocolo de Controle de Transmisso)

TIC

Tecnologia da Informao e Comunicao

TTS

Text-to-Speech (Texto-para-Voz)

UDP

User Datagram Protocol (Protocolo de Datagrama de Usurio)

URL

Uniform Resource Locator (Localizador Uniforme de Recursos)

XML

Extensible Markup Language (Linguagem de Marcao Estendida)

INTRODUO
A evoluo da tecnologia vem mudando a forma como o ser humano vive e se tornando

indispensvel e cada vez mais presente no seu cotidiano. Criada para auxiliar o homem em suas
atividades, hoje a tecnologia no s faz isso com eficincia, mas tambm proporciona lazer e
conforto, e tudo isso alterou a forma como o ser humano vive em sociedade, a forma como feita a
comunicao e, principalmente nos ltimos anos, a forma como o ser humano se interage com o
mundo.
A tecnologia tambm pode substituir o homem em atividades que envolvem esforo fsico, e
atividades que proporcionam maior segurana e conforto ao ser humano, e nesse ponto entra a
Automao Residencial, que a rea da tecnologia que permite a realizao de atividades ou
esforos fsicos por dispositivos eletrnicos, tornando processos automticos, utilizando o que h de
melhor em tecnologia. Os exemplos mais comuns so portes eletrnicos, sistemas de segurana e
lmpadas com detectores de presena.
A automao tambm torna as atividades mais acessveis s pessoas com menor mobilidade,
como portadores de deficincia fsica ou motora, ou idosos, e em alguns casos, d a possibilidade de
realizar atividades antes impossveis a essas pessoas. Com a popularizao da internet, no final da
dcada de 1990 e incio da dcada de 2000, comearam a surgir sistemas de monitoramento e
segurana domiciliar remotos, de forma que uma casa poderia ser vigiada distncia, por meio de
cmeras acessveis via internet. A integrao desses dispositivos internet se tornou interessante a
ponto de criar uma nova rea de interesse, a Internet das coisas (IOT).
Este trabalho visa propor um prottipo de automao residencial na qual o usurio possa
interagir com aparelhos eltricos e eletrnicos utilizando como Interface Humano-Computador
(IHC) um dispositivo mvel com sistema Android, o qual se comunicar com tais aparelhos por
meio de uma rede sem fio e enviar ordens a um sistema de automao com Arduino, sendo este o
responsvel pela traduo das ordens aos aparelhos da residncia. A interao entre humano e
sistema de automao residencial se dar por meio da caracterstica de comando de voz, j
disponvel em dispositivos com Android, possibilitando assim acessibilidade para pessoas idosas ou
portadores de necessidades especiais.
O sistema dividido em quatro partes para ligar o usurio aos aparelhos: O Arduino, um
servidor local, uma conexo com a internet e um dispositivo com Android. O Arduino um sistema
de prototipao de hardware que permite a integrao de software com os aparelhos eltricos ou
eletrnicos, fazendo-os possveis de serem programados. O servidor local um computador comum
que receber as ordens do dispositivo Android pela internet e distribuir essa ordem aos Arduinos

10

que compem o sistema de automao. A internet ser responsvel por fazer a comunicao entre o
servidor local e o dispositivo com Android, podendo funcionar numa rede local (intranet) ou em
uma rede externa (internet). O dispositivo com Android pode ser qualquer smartphone ou tablet que
esteja com uma verso atualizada do Sistema Operacional Android, que vem com a funo de
interpretao de Linguagem Natural, o Google Now.
O objetivo deste trabalho desenvolver o sistema proposto, sendo que, para alcanar tal
objetivo, este ser desmembrado em objetivos especficos, para facilitar a obteno do resultado
esperado. Os objetivos especficos sero uma pesquisa bibliogrfica descritiva das tecnologias
supracitadas, bem como uma pesquisa metodolgica das tcnicas de Engenharia de Software,
programao para Arduino, programao para Android, programao web e conhecimentos de
automao residencial. A metodologia de estudo adotada a pesquisa aplicada, descritiva e
metodolgica, para adquirir um conhecimento mais aprofundado na rea de automao e
programao para realizar a integrao do software com o hardware. Sero abordadas as tcnicas
de investigao de laboratrio, telematizada e bibliogrfica.

11

PARTE I
2
2.1

FUNDAMENTAO TERICA
AUTOMAO RESIDENCIAL
Com o avano da tecnologia, as atividades cotidianas do ser humano esto ficando mais

fceis e simples. No processo de facilitao, as indstrias conseguiram que mquinas fizessem o


trabalho pesado enquanto que o homem somente a operava, de modo a auxiliar o trabalho da
maneira correta. A automao vai alm, dispensando a necessidade do homem com o uso de
sistemas automticos que so muito mais vantajosos que os manuais ou mecnicos. A automao
hoje no presente somente na indstria, mas uma realidade tambm nas residncias, com centenas
de produtos que permitem controle automtico at mesmo por comandos de voz (Kaur, 2010).
Automao residencial um sistema composto por tecnologias integradas de forma a melhor
satisfazer uma ou mais necessidades bsicas de segurana, comunicao, gesto de energia ou
conforto de uma habitao. Essa rea de estudo tambm conhecida como domtica, termo mais
utilizado na Europa, e tambm um termo mais abrangente da rea, j que o termo automao no
engloba a comunicao e a sonorizao (Muratori e Dal B, 2011).
Muratori e Dal B (2011) ainda complementam que esta automatizao e controle
acontecem por meio do uso de equipamentos que possibilitam a interao com capacidade de seguir
as instrues de um programa desenvolvido pelo usurio da residncia e que este programa seja
passvel de alterao, de acordo com os interesses do usurio. Como consequncia, a domtica
realiza maior qualidade de vida, reduzindo o trabalho domstico, podendo fazer o uso mais racional
de energia alm de permitir evoluo contnua.
Segundo Lima et al (2014), domtica uma palavra formada pela juno das palavras
Domus (casa) e Robtica, que a cincia que estuda a criao de robs, que so sistemas
eletrnicos que realizam aes de forma automtica. Somente graas ao avano da micro e
nanoeletrnica que foi possvel gerenciar os processos industriais e residenciais da forma como
so feitos hoje, pois tais estudos possibilitaram a diminuio significativa no tamanho dos
componentes eletrnicos. Dessa forma mais vivel a implantao desses componentes,
principalmente em ambientes residenciais.
A automao residencial uma rea muito nova. Os primeiros trabalhos nesse setor so do
final da dcada de 1970, quando surgiam nos E.U.A os primeiros mdulos "inteligentes", que
recebiam comandos pela rede eltrica da residncia. Eram solues simples e sem integrao, que
resolviam apenas situaes pontuais, como ligar remotamente um equipamento ou iluminao. A

12

aceitao e crescimento desse setor devido ao fato do crescimento da tecnologia como um todo,
com a exploso da telefonia mvel, internet e demais tecnologias presentes na vida das pessoas
(Muratori e Dal B, 2011).
Kaur (2010, p. 60) mostra que a automao benfica ao suprimir o trabalho de fora
humana, outro detalhe que o ser humano pode errar com mais facilidade, ao ponto que uma
mquina opera com praticamente erro zero. As principais utilidades da automao como um todo
so:

Substituir operadores humanos em tarefas que envolvem trabalho fsico ou montono.

Substituir humanos em tarefas feitas em ambientes de perigo, por exemplo: fogo, espao,
vulces, instalaes nucleares, trabalhos debaixo d'gua, etc.

Fazer tarefas que esto alm da capacidade humana, em grandezas de tamanho, peso,
velocidade ou resistncia, etc.
Segundo Muratori e Dal B (2011) a oferta abundante e de baixo custo de servios de

internet e, em consequncia, de contedo digital, desperta o interesse por casas inteligentes.


Destaca-se que, em pesquisa feita nos Estados Unidos, 84% dos construtores entendem a
importncia da incorporao de tecnologia s residncias para o mercado, somado com a
constatao de consumidores que esto entrando no mercado j convivem naturalmente com a
tecnologia, portanto esto mais exigentes em relao sua presena nas residncias que procuram.
Em situaes cada vez mais constantes, novas casas j esto sendo construdas para
comportarem sistemas de automao. Em relao s casas j construdas, comum utilizar sistemas
sem fio, para reduzir a quantidade de fios ou evitar a alterao dos fios j instalados. Devido falta
de padro, resultada da concorrncia entre fornecedores, equipamentos de automao mais
avanados costumam estar presentes apenas em casas com maior poder aquisitivo ou em casas com
moradores que tem a automao como hobby (Kaur, 2010).
Outra caracterstica de novos consumidores o interesse por sistemas que buscam preservar
recursos naturais, ou economia de energia, de forma sustentvel, esto sendo cada vez mais
requisitados. Muratori e Dal B (2011) concluem mostrando que entre as tecnologias emergentes,
destacam-se os media centers, o monitoramento distncia, o controle de iluminao e o home
care. Essa viso ainda um pouco menor aqui no Brasil, haja vista o modo conservador do mercado
imobilirio, porm a concorrncia e a menor disponibilidade de espao territorial esto mudando
este cenrio.
O conforto, a praticidade e facilidades oferecidas pela tecnologia s atividades cotidianas em
uma residncia mudam os hbitos de quem as usa. Dificilmente algum acostumado a operar um
aparelho de TV por controle remoto optar por outra TV sem tal recurso, da mesma forma quem

13

utiliza de computador para redigir textos dificilmente optar por utilizar uma mquina de escrever.
Desta forma, pessoas mais jovens buscam por novidades na tecnologia, e as pessoas mais idosas
buscam conforto e segurana, ou seja, independentemente da idade, os desejos das pessoas podem
ser atingidos com a domtica (Dias e Pizzolato, 2004).
Leitte et al (2013, p.1) afirmam que a automao vem se expandindo rapidamente entre os
grandes empreendimentos residenciais e corporativos, e isso acontece devido s grandes inovaes
tecnolgicas da rea, e tambm devido ao aumento significativo dos grandes centros urbanos e,
consequentemente, da violncia, o que leva a populao a buscar no s por segurana diretamente,
mas tambm, como conseguinte, comunicao, gesto enrgica e conforto, de forma que no seja
necessria a exposio a possveis riscos.
Dias e Pizzolato (2004) ainda complementam que o aumento da expectativa de vida, a
reduo do nmero de filhos, o crescimento do nmero de famlias no convencionais e o aumento
da mo-de-obra feminina no mercado de trabalho, contribuem para o aumento na busca pelo bem
estar e segurana em suas residncias. Outro fator que justifica o aumento do interesse pela
automao residencial o crescimento da populao idosa, geralmente mais debilitada, aspecto em
que a automao promove maior independncia dando suporte s pessoas com maior dificuldade
em realizar tarefas cotidianas.
Segundo Dias e Pizzolato (2004) as residncias convencionais no satisfazem
completamente a expectativa dos moradores, o que no deveria acontecer pois a habitao uma
das necessidades bsicas do ser humano, em conseguinte a necessidade de proteo, segurana e
bem estar. Logo, com a domtica, possvel aumentar o conforto e qualidade de vida esperado
pelas pessoas em suas habitaes.
Muratori e Dal B (2011) destacam como principal fator da automao residencial a
integrao entre sistemas e aparelhos em soma com a capacidade de executar ordens do usurio de
maneira programada. Essa integrao deve possibilitar a capacidade de comunicao interativa
entre os equipamentos que se compe, e tambm deve permitir que tais elementos integrados
possam seguir ordens de um usurio por meio de um programa pr-estabelecido pelo mesmo.
De acordo com Dias e Pizzolato (2004) um sistema de automao residencial necessita de
uma rede de comunicao para que haja interconexo entre uma srie de dispositivos, equipamentos
e outros sistemas, para que haja troca de informaes entre o ambiente residencial e o meio que ele
se insere, e que seja possvel determinadas aes a fim de gerenciar ou monitorar o sistema. Dessa
forma, aplicaes prticas de sistemas de automao incluem: segurana, gesto de energia,
comunicao e monitoramento, alm de automao de tarefas domsticas, facilidades para
escritrios em casa, entre outros.

14

Muratori e Dal B (2011, p.70) listam os tpicos dos quais a integrao em automao deve
abranger:

Instalao eltrica, que compreende: iluminao, persianas e cortinas, gesto de energia e


outros;

Sistema de segurana: alarmes de intruso, alarmes tcnicos (fumaa, vazamento de gs,


inundao), circuito fechado de TV, monitoramento, controle de acesso;

Sistemas multimdia: udio e vdeo, som ambiente, jogos eletrnicos, alm de vdeos,
imagens e sons sob demanda;

Sistemas de comunicaes: telefonia e interfonia, redes domsticas, TV por assinatura;

Utilidades: irrigao, aspirao central, climatizao, aquecimento de gua, bombas e


outros.
Devido complexidade dos projetos, pelo fato do uso de diferentes tecnologias, e

necessidade de instalao e programao, porque ainda no existem solues plug-and-play, o


mercado de automao residencial necessita de um profissional para preencher essa necessidade.
Esse profissional conhecido como "integrador de sistemas residenciais", ou Systems Integrator, ou
ainda Electronic Systems Contractor, e pode ser um profissional liberal ou uma pequena empresa.
s grandes empresas cabe o papel de desenvolver novas tecnologias, que serviro de material base
para os projetos residenciais, executados pelos integradores de sistemas residenciais (Muratori e
Dal B, 2011).
A formao deste profissional abrangente e diversificada, no entanto, na maioria das vezes
de base tecnolgica (engenharia eltrica ou eletrnica, redes e informtica, automao industrial,
mecatrnica e similares). Diversos profissionais provm das reas de udio e vdeo, segurana,
instalaes eltricas ou outras similares, em que possivelmente j atuavam anteriormente e
passaram a incluir automao residencial em sua oferta de servios (Muratori e Dal B, 2011).
Os principais dispositivos para coleta de informaes do ambiente so detectores, sensores,
captadores e estes necessitam de atuadores ou centrais inteligentes capazes de processar os dados
recebidos. Sistemas de automao antigos executavam tarefas pontuais, como ligar ou desligar
luzes, ou sistemas de ventilao, e no tinham integrao. Mesmo sistemas como home theater
apenas serviam de controle remoto para cortinas e luzes, alm do habitual udio e vdeo.
Atualmente sistemas de automao j possuem comunicao de mo dupla, com resposta do estado
do ambiente para que o usurio possa tomar decises personalizadas (Dias e Pizzolato, 2004).
Dias e Pizzolato (2004) sugerem sistemas de automao com tecnologias centralizadas, de
forma que tanto o recebimento dos sinais dos sensores quanto o envio de aes para os atuadores no

15

ambiente sejam feitos por meio de uma central nica. Apesar da falta de padro existente pelo fato
da existncia de diferentes fabricantes, a evoluo dessas tecnologias denota uma convergncia do
mercado para padres, principalmente devido ao fato da evoluo da tecnologia mvel. O que
ressalta a tendncia para que haja uma central de automao mvel.
2.2

ARDUINO
Arduino uma plataforma de prototipao eletrnica open-source, baseada em hardware e

software flexvel e fcil de usar. As placas de Arduinos so capazes de lerem dados de entrada, por
meio de diferentes sensores disponveis no mercado, recebendo sinais digitais ou analgicos, e
transform-los em uma sada desejada conforme um conjunto de instrues programadas no
microcontrolador do Arduino (Arduino, 2015).
O Arduino foi desenvolvido no Instituto de Design e Interao Ivrea, visando estudantes
com pouco conhecimento em eletrnica e programao. Devido caracterstica de ser um hardware
open-source, a quantidade de usurios cresceu pelo mundo, e a placa Arduino teve novas
adaptaes para necessidades especficas, como Internet das Coisas, impresso 3D, ambientes
embutidos etc (Arduino, 2015).
Arduino um sistema que permite interao com um ambiente por hardware e software
embarcados de forma a incorporar-se em um dispositivo com um objetivo pr-definido, facilitando
dessa forma a automao e controle do ambiente, seja a nvel comercial ou domstico. Por ser uma
plataforma livre, como consequncia, fcil ampliar sua capacidade por meio de mdulos externos
facilmente conectveis, conhecidos como Shields. Os Shields podem dar ao Arduino capacidade de,
por exemplo, Visores LCD, Sistema Global de Posicionamento (Global Position System - GPS),
Ethernet para comunicao via rede de computadores etc. (McRoberts, 2010).
Segundo Monk (2011), o Arduino basicamente permite que voc conecte computadores, por
meio de uma conexo Universal Serial Bus USB, e outros circuitos, de forma a controlar
dispositivos, como uma lmpada ou motores, e por isso recebe o atributo de computao fsica. A
parte principal do Arduino o microcontrolador, que um pequeno computador dentro de um chip,
que permite o Arduino ser programvel. O microcontrolador tem uma arquitetura equivalente de
um computador, com processador, memria principal e secundria, e pinos de entrada e sada, que
conectam o microcontrolador a outros componentes.
As demais partes do Arduino so complementares, de forma a dar um funcionamento mais
completo placa e possibilitar seu funcionamento como um todo, por exemplo, fonte de
alimentao, entradas analgicas, entradas digitais, entre outros, como possvel visualizar na
Figura 1, que esboa o Arduino Uno, que uma das placas mais populares de Arduino (Monk,

16

2011). Segundo McRoberts (2010) o fato de o Arduino ser uma plataforma open source permitiu
que vrias verses fossem criadas. A mais conhecida e a ltima verso o Arduino Uno. A verso
anterior, tambm muito popular, a Duemilanove (2009 em italiano). Outras verses bastante
conhecidas so o Arduino Mini, Nano e Bluetooh.

Figura 1: O Arduino Uno


Fonte: Monk (2011, p.8)

Para Oxer e Blemings (2009), Arduino um conjunto de trs elementos: Hardware,


Software e Comunidade. O software e o hardware do qual o Arduino composto completamente
livre, de modo que a comunidade de usurios do Arduino estimula o compartilhamento de seus
projetos, tanto de software quanto de hardware, para que haja mais exemplos disponveis para
estudo pela internet. Este fato somado abstrao do Arduino permite que pessoas com baixo
conhecimento de eletrnica possam desenvolver projetos interessantes.
Pela facilidade de uso, o Arduino tem sido crucial em milhares de projetos, dos mais simples
objetos aos mais complexos instrumentos cientficos. O Arduino possui uma comunidade de
usurios que abrange estudantes em geral, programadores e hobbystas, e isso facilitou o
amadurecimento da plataforma e o processo de aprendizado para iniciantes, com bastante material
disponvel pela internet e fruns de discusso (Arduino, 2015).

17

Arduino uma plataforma simples de ser estudada e usada por iniciantes, e flexvel para
usurios avanados. Sua plataforma de desenvolvimento funciona nos principais Sistemas
Operacionais (Linux, Mac OS e Windows). Devido ao baixo custo, o Arduino bastante utilizado
em cursos, tem se tornado uma porta de entrada para a robtica, alm de ser uma ferramenta til
para profissionais de outras reas, como arquitetos, msicos e artistas (Arduino, 2015).
Segundo Lima et al (2014), utilizando o Arduino pode-se modificar o estado de um
ambiente, seja acionando motores responsveis pela abertura de portes ou modificando a
luminosidade desse ambiente. A interpretao de sinais digitais e analgicos possibilita acionar um
circuito eletrnico especfico responsvel por um determinado dispositivo como, por exemplo, uma
televiso ou ar condicionado.
Oxer e Blemings (2009) afirmam que um projeto bsico de automao residencial consiste
em controlar aparelhos de uma casa, seja uma luz, ar condicionado, enfim, qualquer aparelho que
funcione via energia eltrica. Dependendo do aparelho, pode ser difcil control-lo devido aos
diferentes nveis de tenso ou potncia, porm, qualquer aparelho que tem algum interruptor ou
botes de modificao pode ser facilmente modificado ou controlado pelo Arduino. Isso vale para
Televiso, portes eletrnicos, climatizadores etc.
Segundo McRoberts (2010), para fazer com que o Arduino realize tarefas autnomas,
preciso program-lo utilizando o Ambiente Integrado de Desenvolvimento (Integrated Development
Enviroment) IDE, que um software livre capaz de traduzir o cdigo (instrues em uma
linguagem parecida com a humana) para algo que o Arduino possa entender. A linguagem de
programao utilizada chamada C. Os programas em C escritos para Arduino so conhecidos
como sketches.
Um sistema considerado embarcado ao colocar-se a capacidade computacional dentro de
um circuito integrado. O usurio no tem acesso ao programa embutido, mas o acessa por meio das
interfaces de comunicao. Esse sistema configurado de forma a permitir que o Arduino receba
programas desenvolvidos pelo usurio, e que esse programa possa interagir com os equipamentos, e
a comunicao com dispositivos mveis pode ser feita pela internet, com seu mdulo Shield
Ethernet (Leitte et al, 2013).
O Shield Ethernet, segundo Leitte et al (2013, p.3), permite que a placa Arduino se conecte
a quaisquer dispositivos inseridos em uma rede LAN (Rede Local de Computadores) ou at mesmo
uma WAN (Rede Mundial de Computadores - Internet)". Isso possvel por causa do chip Ethernet
Wizner, que suporta protocolos como TCP e UDP, e possibilita at 4 conexes de soquetes
simultneos, o que permite acoplar outros Shields complementares.

18

Um dos padres mais utilizados para a comunicao sem fio no Arduino o ZigBee, e essa
comunicao feita por meio do Xbee Shield ou Wireless SD Shield. Essa comunicao pode
substituir a comunicao serial/USB ou tambm pode ser configurada como broadcast para uma
rede de Arduinos. Para que a comunicao acontea os mdulos precisam estar na mesma rede,
setada por parmetro de identificao, e no mesmo canal, alm de que os endereos de destinos
(parmetros DH e DL) devem ser conhecidos para que o mdulo a receber o dado transmitido possa
ser reconhecido na rede. (Arduino, 2015).
2.3

ACESSIBILIDADE
Segundo Guedes et al (2012) o princpio de arquitetura inclusiva iniciou-se no perodo da

Segunda Guerra Mundial, onde os veteranos de guerra mutilados tinham dificuldades para exercer
funes usuais de afazeres dirios, evidenciando o fato de que as construes visavam apenas o
visual arquitetnico e no as necessidades pessoais. Surge ento, aps o fim da Segunda Guerra, a
primeira padronizao de acessibilidade nos E.U.A, cuja evoluo derivou o conceito de Design
Universal, ou seja, produtos e ambientes capazes de serem usados por qualquer pessoa.
No Brasil, esse princpio chegou apenas na dcada de 1980, com mudanas em leis e normas
tcnicas. Hoje possvel ver acessibilidade em vias pblicas, locais de convvio social, transporte
coletivo, mobilirio urbano e edifcios. A partir desses princpios, a automao inclusiva
proporciona maior convenincia para pessoas portadoras de necessidades especiais, dando-lhes
possibilidade de acionamento remoto ou automtico de sistemas, o que sugere maior independncia
e autonomia em suas atividades (Guedes et al, 2012).
Segundo Pupo, Melo e Ferrs (2006) h vrias barreiras a serem vencidas nos diversos
ambientes, produtos e servios disponveis populao, visto que a deficincia pode ser, por
exemplo, perceptual, cognitiva, motora ou mltipla, e isso impacta no grau de dificuldade de
convvio da pessoa.
Para o delineamento de uma sociedade mais inclusiva, que reconhece e valoriza as
diferenas entre pessoas, torna-se cada vez mais importante que propostas para a acessibilidade de
pessoas com caractersticas especficas estejam articuladas promoo da qualidade de vida para
todos. Assim, pessoas com habilidades, necessidades e interesses variados, sejam ou no em
decorrncia de envelhecimento ou de deficincias, podero ser beneficiadas por propostas de
ambientes, produtos e servios acessveis, que no as discriminem (Pupo, Melo e Ferrs, 2006,
p.17).
Segundo o IBGE (2012) em Censo de 2010, 45,6 milhes de brasileiros (cerca de 24% da
populao) declararam possuir pelo menos uma das deficincias investigadas: mental, motora,

19

visual ou auditiva. Desses, a maioria so mulheres, e o percentual indica a soma dos trs graus de
severidade das deficincias investigados: alguma dificuldade, grande dificuldade, no consegue de
modo algum. A pesquisa tambm revela que o brasileiro vive 25 anos a mais que em 1960 e que a
populao de 65 anos ou mais saltou de 2,7% para 7,4% em relao mesma poca. Desses idosos,
67,7% possuem alguma deficincia em 2010.
Pupo, Melo e Ferrs (2006) explicam que h algumas dicas bsicas que podem auxiliar em
qualquer situao, em relaes sociais cotidianas, por exemplo, todas as pessoas tm o direito de
participar em todos os nveis da sociedade, dado o fato de que absolutamente ningum perfeito,
ningum igual e cada um tem sua dificuldade. Dessa forma, cordialidade, educao, interesse e
motivao so alguns itens bsicos para o bom convvio em qualquer ambiente.
No h regras fixas e normalizadas para agir em relao pessoa com deficincia, de forma
que sempre haver algo a ser melhorado, e esse processo de melhoria sempre deve iniciar com a
opinio da pessoa, se ela precisa de ajuda e de qual forma possvel ajud-la. A omisso sempre
errada, independentemente da situao (Pupo, Melo e Ferrs, 2006).
Guedes et al (2012) destaca que o arquiteto criador da terminologia Desenho Universal, em
1987, Ron Mace (1941-1998) era cadeirante e respirava com uso de aparelho. Mace destacava a
percepo de aprimoramentos dos projetos, e no a criao de uma nova cincia ou estilo para se
tornar projetos utilizveis por todos. Os principais conceitos destacados por Mace so:

Equitativo/Igualitrio: ambientes, objetos e produtos que podem ser usados por pessoas
com diferentes capacidades, tornando todos os espaos iguais.

Uso flexvel/Adaptvel: planejar produtos que atendam pessoas com habilidades distintas,
sendo adaptveis a diferentes formas de uso.

Uso simples e intuitivo: de simples entendimento, compreensvel para qualquer pessoa


independente de sua idade, conhecimento, habilidade de linguagem ou nvel de
concentrao.

Informao de fcil percepo: quando a informao necessria comunicada de modo


que atenda s necessidades do receptador.

Tolerncia ao erro/Seguro: previsto para minimizar riscos e possveis consequncias de


aes eventuais ou no propositadas.

Esforo fsico mnimo: para ter seu uso eficaz, com comodidade e o mnimo de fadiga.

Dimensionamento de espaos para acesso e uso abrangente: que determina dimenses e


espaos adequados para o acesso, alcance, manipulao e uso, independente das dimenses
de um corpo, da postura ou mobilidade do usurio.

20

Dessa forma, deve-se considerar a oferta de alternativas de acesso por meio de acessrios ou
opes padronizadas, ou por meio de tecnologias assistivas e, em ltimo caso, facilitar a
modificao sob demanda, objetivando promover solues de acessibilidade numa perspectiva de
Design Universal para potencializar a convivncia e participao na sociedade de forma igualitria
e sem discriminao (Pupo, Melo e Ferrs, 2006).
Dias e Pizzolato (2004) afirmam que a domtica pode oferecer ferramentas no s para
fornecer conforto e segurana ao homem, mas para atender s necessidades especficas da
populao idosa, ou com dificuldade de locomoo, ou at mesmo portadores de necessidades
especiais, de forma que essas pessoas possam at mesmo viver sem auxlio de outra pessoa, se
tornando independentes em suas atividades domsticas. Essa caracterstica acentuada com o
advento das tecnologias sem fio, que permitem maior mobilidade aos sistemas de automao.
Guedes et al (2012) tambm complementa que, para a maioria das pessoas a automao
meramente um item de conforto, mas para o Portador de Necessidades Especiais (PNE) a
automao se trata de uma possibilidade de independncia. A utilizao de dispositivos para
controle remoto, como um celular ou tablet pode dar ao usurio a possibilidade de abrir e fechar
portas, ligar e desligar luzes, controlar a inclinao de camas, de forma independente.
Pupo, Melo e Ferrs (2006) citam exemplos de tecnologias assistivas, ou seja, recursos e
servios disponveis para auxiliar as atividades dirias de pessoas com deficincia. So tecnologias
que buscam aumentar as capacidades funcionais e promover autonomia e independncia de quem as
utiliza:

Equipamentos de auxlio mobilidade: Cadeiras de rodas, Stair-Track, Evacu-Trac. O StairTrac pode ser acoplado cadeira de rodas para auxiliar na locomoo pelas escadas,
enquanto que o Evacu-Trac auxilia em locomoes de emergncia, quando o elevador no
recomendado.

Bengalas: auxilia pessoas com deficincia visual, informando obstculos e desnveis no


solo.

Lupas eletrnicas: auxilia pessoas com baixa viso, ampliando textos e imagens.

Assinadores: Peas plsticas ou de metal, que carimba a assinatura de pessoas com


dificuldade para escrita.

Balanas com marcao em alto relevo: mecanismos de pesagem que auxiliam pessoas com
deficincia visual na medio de pesos.

Mquina Perkins: Mquina de datilografar utilizada para produzir textos em Braille.

Reglete: instrumento que auxilia na escrita em Braile.

21

Rotuladora Braille: Mquina mecnica para rotular em Braille.

Trenas de marcao com alto relevo: Fitas mtricas com pista tteis para auxiliar pessoas
com deficincia visual na medio de reas.

Dispositivos apontadores alternativos: solues alternativas para o mouse que podem ser
acionadas, por exemplo, por intermdio dos olhos, ps ou mos.

Teclados alternativos: alternativas fsicas ou de software para o teclado convencional.

Ponteiras de cabea: Ferramentas acopladas cabea para auxiliar, por exemplo, o uso do
teclado ou telas de toque.

Sistemas para entrada de voz (speech recognition): oferecem o uso do computador por meio
de comando de voz, garantindo acessibilidade s pessoas com mobilidade dos membros
superiores comprometida.

Ampliadores de tela: softwares que fazem o aumento da imagem apresentada na tela do


computador para facilitar o uso por pessoas com baixa viso.

Leitores de tela com sntese de voz: Softwares que fazem a leitura de informaes textuais
via sintetizador de voz, garantindo a entrega de informaes s pessoas com deficincia
visual.

Linhas em Braile: Dispositivos que reproduzem informaes codificadas em texto para


Braille, e so utilizadas como alternativa aos leitores de tela por usurios com deficincia
visual que saibam interpretar esse sistema.

Impressoras Braille: Imprimem informaes de texto em sistema Braille no papel.

Software especializado para produo de material em Braille: Programas de computador


para digitalizao de imagens e sua converso para a grafia Braille.

2.4

ANDROID
Android um sistema operacional para dispositivos mveis baseado no Linux. No princpio,

foi desenvolvido por uma empresa de mesmo nome, porm em 2005 a Google comprou a Android,
Inc. e assumiu o desenvolvimento do sistema. O objetivo da Google era que o Android fosse um
sistema gratuito e livre, de forma que a maior parte de seu cdigo foi entregue sob a licena open
source Apache License, o que significa que qualquer pessoa pode fazer o Download do cdigo
fonte. Isso atraiu empresas, visto que estas podiam utilizar do Android em seus aparelhos e ainda
adicionar pedaos de cdigo proprietrio neles para personaliz-los (Lee, 2012, p.2).
Segundo Lee (2012) devido forte concorrncia do IPhone da Apple, empresas como
Motorola e Sony Ericsson tiveram que lutar para revitalizar seus produtos. Essas empresas viram o

22

Android como uma soluo, pois poderiam focar em seu hardware enquanto utilizavam o Android
como seu sistema operacional. Outro benefcio que o Android funcionaria como uma plataforma
de abstrao de hardware, uma vez que os desenvolvedores de aplicativos precisam conhecer
apenas a plataforma Android, desenvolvendo o aplicativo uma vez, e este funcionaria em qualquer
aparelho. Isso muito importante visto que, num mundo mobile, aplicativos so cruciais para o
sucesso de uma plataforma.
As empresas do mercado de telefonia, dentre elas a Motorola, LG, Samsung, Sony Ericsson,
HTC, Toshiba, Huawei, ASUS, Intel, Acer, Dell, Garmin etc., formaram um grupo chamado Open
Handset Alliance (OHA) liderado pela Google, com a inteno de padronizar a plataforma Android
de forma a atender as expectativas e tendncias do mercado. O objetivo do grupo definir uma
plataforma nica e aberta para celulares, que seja moderna e flexvel para o desenvolvimento de
aplicaes corporativas (Lecheta, 2013).
Como o Android uma plataforma aberta, no existe uma configurao fixa para hardware
ou software, porm o Android em si tem suporte a algumas configuraes, e as mais bsicas so
(Lee, 2012, p.3):

Armazenamento - Utiliza-se SQLite, um banco de dados relacional leve.

Conectividade - Suporta os protocolos GSM/EDGE, IDEN, CDMA, EV-DO, UMTS,


Bluetooth (incluindo A2DP e AVRCP), WIFI, LTE e WiMAX.

Mensagem - Suporta tanto SMS quanto MMS.

Navegador de internet - Seu navegador padro baseado no WebKit, juntamente com o


motor de JavaScript do Chrome, V8.

Mdia - Suporta diversos formatos, tais como: H.263, H.264 (3GP OU MP4), MPEG-4-SP,
AMR, AMR-WB (3GP), AAC, HE-AAC (MP4 ou 3GP), MP3, MIDI, Ogg Vorbis, WAV,
JPEG, PNG, GIF e BMP.

Hardware - Sensor de Acelermetro, Cmera, Bssola Digital, Sensor de Proximidade e


GPS

Suporte a mltiplo toque na tela (Multi-Touch screen).

Suporte a mltiplas aplicaes (Multi-Tasks).

Suporte a Flash.

Tethering - Suporte ao compartilhamento de conexes de internet como hotspot, com fio ou


sem fio.
Na medida que as plataformas vo se atualizando, novas interfaces de abstrao vo

agregando ao Android, o que no impede o desenvolvedor de produzir aplicativos visando uma

23

verso mais antiga da plataforma, pois as verses mais novas tem suporte de aplicativos
programados em verses mais antigas, todavia ao descartar as verses mais antigas, possvel
aproveitar de outros recursos mais recentes. Isso no uma grande preocupao, visto que,
conforme o grfico da Figura 2, apenas 8% dos usurios de Android utilizam as verses mais
antigas, de acordo com dados coletados do dia 1 ao dia 7 de setembro de 2015 (Android, 2015).

Figura 2: Percentual de usurios por verso Android


Fonte: Android, 2015

Os aplicativos para Android so desenvolvidos na linguagem de programao Java. Uma


ferramenta conhecida como Kit de Desenvolvimento de Software (Software Development Kit SDK) compila o cdigo Java em um arquivo Android Package (APK). O APK contm todo o
contedo do aplicativo Android e o arquivo utilizado por aparelhos com Android para instalar o
aplicativo. H quatro tipos de componentes de aplicativos: Activities, Services, Content Providers,
Broadcast Receivers (Android, 2015).
O desenvolvimento de uma aplicao Android geralmente se inicia com a utilizao da
classe Activity. Uma activity deve herdar da classe android.app.Activity ou alguma subclasse desta.
Esta classe representa uma tela da aplicao e responsvel por tratar eventos gerados nessas telas
como o pressionar de um boto pelo usurio (Lecheta, 2013). A Figura 3 mostra um exemplo de
activity.

24

Figura 3: Exemplo de utilizao da classe Activity


Fonte: Lecheta (2013, p. 64)

De acordo com Lee (2012, p.429) um service um componente que executado em


segundo plano para executar uma operao de longa durao ou um processo remoto. Um service
no prov uma interface com o usurio. Um service pode, por exemplo, executar uma msica sem
interferir na atual atividade do usurio, ou fazer uma requisio de dados a um servidor, ou
trabalhar com a localizao obtida por GPS, e para isso necessrio criar uma classe
android.app.Service.
Content Provider a maneira recomendada de se compartilhar dados entre aplicativos por
meio da classe android.content.ContentProvider, este recurso muito parecido um banco de
dados, podendo-se fazer consultas, editar, adicionar ou deletar contedo. Porm, diferente de um
banco de dados, um content provider pode usar diferentes maneiras de armazenar dados, seja em
arquivos, banco de dados ou em algum local da rede. Exemplos de content providers so as notas
escritas pelo aplicativo de notas, os links favoritos e histricos de navegadores, histrico de
chamadas, detalhes de contatos, arquivos multimdia e configuraes de usurios (Lee, 2012,
p.293).
Broadcast receiver um componente da classe android.content.BroadcastReceiver que
responde aos anncios de broadcasts do sistema. Anncios como bateria acabando, uma foto tirada,
a luz da tela apagou etc., so capturados por esse componente para que o aplicativo possa reagir
conforme cada ocorrncia. Da mesma forma, um aplicativo pode iniciar um broadcast, por
exemplo, para anunciar os outros aplicativos que algum arquivo foi baixado, e o mesmo est
disponvel. Cada broadcast entregue um objeto Intent (Android, 2015).
Segundo Lecheta (2013) para representar uma interao entre usurio e aplicativo (por
exemplo, um clique em um boto) necessrio criar uma classe android.content.Intent, de forma
que podemos dizer que h uma inteno aplicao de realizar determinada tarefa. Na prtica essa

25

inteno enviada ao sistema operacional como uma mensagem, ao receber o sistema operacional
tomar as decises necessrias, conforme exemplo da Figura 4.

Figura 4: Exemplo de utilizao da classe Intent


Fonte: Lecheta (2013, p. 155)

Nessa arquitetura, um aplicativo pode iniciar o componente de outro aplicativo. Se um


desenvolvedor precisa que seu aplicativo capture fotos, ele no precisa desenvolver uma activity
para isso, basta apenas acionar a activity do aplicativo da cmera e este capturar a foto. Quando a
foto for capturada, o Android retornar primeira aplicao, que poder seguir com o fluxo, como
se a cmera fosse parte do aplicativo. Porm, no Android, cada aplicativo tem seu processo
separado, de forma que um aplicativo no acessa diretamente o outro, ento para acessar a cmera
ser necessrio enviar uma mensagem ao sistema operacional, que far a comunicao entre
aplicativos (Android, 2015).
Em um dispositivo mvel com sistema operacional Android verso 4.3 ou superior,
possvel que uma pessoa envie ordens por meio de comandos de voz. Tais comandos, interpretados
pelo sistema proposto, permite o controle de funcionalidades da residncia pelo comando de voz, e
isso extremamente importante para a autonomia dos portadores de necessidades especiais, em
especial os portadores de deficincias visuais e auditivas ou com dificuldades de locomoo (Lima
et al, 2014).
A API Text-to-Speech (TTS) responsvel por converter texto em voz e fazer o Android
Falar, de modo inverso a Speech-to-Text (STT) permite converter voz em texto e fazer o Android
ouvir. Essas duas funcionalidades so muito teis para, por exemplo, escrever mensagens de texto
em aplicativos de mensagem ou ouvir as direes informadas pelo GPS. Essa tecnologia foi
apresentada em uma palestra da Google em 2009, citando um engenheiro do projeto que era
deficiente visual, e evidenciando assim a importncia dessa tecnologia para mudar a vida de
milhares de pessoas pelo mundo (Lecheta, 2013).
Segundo Lima et al (2014) o reconhecimento de voz uma tecnologia que vem sendo
desenvolvida ao longo dos ltimos anos para tornar acessvel o ato de transmitir informaes via

26

computador. Os primeiros sistemas de reconhecimento de voz no obtiveram xito por utilizar de


conjuntos de regras para determinar quais palavras foram utilizadas, sendo assim, as variaes
culturais como sotaques, dialetos e regionalismos alteravam os resultados finais do programa.
Os sistemas atuais utilizam modelos estatsticos complexos, com funes de probabilidade e
redes neurais para determinar o resultado mais prximo. Os modelos ocultos de Markov tambm
so utilizados como mtodo de reconhecimento de voz, tendo incio na transcrio das ondas
analgicas da voz para sinais digitais Lima et al (2014).
2.4.1 XPOSED
De acordo com Vollmer (2015), Xposed uma plataforma para mdulos que muda o
comportamento do Android e seus aplicativos sem alterar os APKs. Isso importante para garantir
que os mdulos funcionaro em diferentes verses do Android, desde que seja uma verso igual ou
superior a 4.0.3, e que o aparelho esteja com o acesso de super-usurio.
Existe um processo chamado "Zygote" que o ncleo de execuo do Android, ou seja, todo
aplicativo inicia-se como uma cpia desse processo. Este processo iniciado pelo script /init.rc
assim que o dispositivo ligado. A inicializao do processo est concluda quando todas as classes
invocam seus mtodos iniciais. Nesse momento entra o Xposed, que quando instalado, cria uma
verso estendida do app_process dentro da pasta /system/bin. Este processo estendido adiciona um
executvel depois da criao da mquina virtual e antes do mtodo main do Zygote ser executado,
dessa forma possvel atuar no contexto do Zygote (Vollmer, 2015).
Vollmer (2015) complementa explicando que este cdigo localiza-se no arquivo
/data/data/de.robv.android.xposed.installer/bin/XposedBridge.jar

e permite fazer uma tcnica

conhecida como hooking, que consiste em um conjunto de tcnicas utilizadas para modificar ou
melhorar o comportamento de um sistema operacional, aplicativos ou outros componentes de
software fazendo uma interceptao de chamadas de funes, e esse processo possvel fazendo a
decompilao de um APK, para ento inserir ou modificar os comandos, e ento este APK
recompilado. No possvel modificar os mtodos do sistema operacional, mas possvel inserir
chamadas de mtodos do Xposed antes ou depois das chamadas dos mtodos do Android.
O Xposed uma plataforma que permite o desenvolvedor criar seus prprios mdulos.
Existem vrios mdulos Xposed disponveis pela internet que permitem ao usurio Android, por
exemplo, habilitar gravao de chamadas, instalar aplicativos que s estavam disponveis para
outros aparelhos, alterar funes da tela de bloqueio, barra de status, volume, e permite tambm que

27

desenvolvedores possam habilitar chamadas do Google Now para seus aplicativos, podendo realizar
comandos de voz (Vollmer, 2015).
2.5

REDES SEM FIO


Kurose (2010) afirma que atualmente existem vrios aparelhos diferentes interligados pela

Internet, e que a internet dos primrdios, conhecida como Rede Mundial de Computadores, um
termo ultrapassado. Existem milhes de sistemas conectados internet, e isso pode acontecer via
meios fsicos, como cabos coaxiais, fios de cobre, fibras ticas, ou que constituem ligaes que
utilizam fios, ou ligaes sem fio, como as ondas de rdio.
Dentro de uma rea geogrfica especfica, como uma universidade, residncia ou empresa,
formada uma rede local, conhecida como LAN (Local Access Network), que usada para conectar
sistemas finais. Dentre os tipos de LAN existentes, a Ethernet a mais utilizada, e esta composta
por pares de fios de cobre tranados para se conectarem a um computador Ethernet. Por outro lado,
possvel conectar-se a uma rede LAN sem fio estando h alguns metros de um ponto de acesso.
(Kurose, 2010, p.337).
Segundo Coulouris et al (2012) as redes locais (tanto Ethernet quanto sem fio) utilizam do
mtodo de difuso, tambm conhecido como broadcast como esquema de comunicao entre os
computadores a ela conectados. O broadcast uma tcnica de transmisso onde tudo transmitido
para cada n, e fica por conta dos receptores recuperar as transmisses a eles endereadas.
Para Kurose (2010, p.377) Independente do crescimento futuro de equipamentos sem fio
para Internet, j ficou claro que redes sem fio e os servios mveis relacionados que elas
possibilitam vieram para ficar. H uma diferena entre rede sem fio e rede mvel, perceptvel na
prtica de seu uso, onde na primeira, voc precisa de desconectar-se para se locomover de uma rea
geogrfica para outra (por exemplo, de casa para o trabalho) e na segunda voc pode, por exemplo,
manter uma chamada de voz sobre IP, ou qualquer outra conexo TCP dentro de um carro em
movimento.
Kurose (2010) explica que o acesso LAN sem fio est presente em qualquer lugar,
universidades, empresas, comrcio, residncias, etc. Este acesso baseado na tecnologia IEEE
802.11, conhecida popularmente como WIFI, e uma das tecnologias mais importantes para o
acesso Internet atualmente. H basicamente trs principais padres da tecnologia 802.11, so eles
o 802.11b, 802.11a, 802.11g.
Coulouris et al (2012) explica que h uma heterogeneidade no ambiente tecnolgico, no que
se refere arquitetura de redes, hardware de computador, sistemas operacionais, linguagens de

28

programao e mtodos de implementao de diferentes desenvolvedores. Essa heterogeneidade


mascarada com utilizao de protocolos de comunicao.
Protocolos so padres pr-estabelecidos para comunicao entre entidades, preciso que
duas (ou mais) entidades comunicantes executem o mesmo protocolo para que uma tarefa seja
realizada (Kurose, 2010, p.6). Qualquer atividade pela rede que envolva duas ou mais entidades
remotas so governadas por um protocolo. Segundo Kurose (2010, p.7) Um protocolo define o
formato e a ordem das mensagens trocadas entre duas ou mais entidades comunicantes, bem como
as aes realizadas na transmisso e/ou no recebimento de uma mensagem ou outro evento.
Para envio e recebimento de dados pela internet, h trs protocolos muito conhecidos o UDP
(User Datagram Protocol - Protocolo de Datagrama de Usurio), o TCP (Transmission Control
Protocol - Protocolo de Controle de Transmisso) e IP (Internet Protocol - Protocolo da Internet). O
UDP e o TCP cumprem a mesma funo na camada de transporte, porm o primeiro oferece um
servio no confivel e no orientado para conexo, enquanto que o segundo oferece um servio
confivel e orientado para conexo (Kurose, 2010).
De acordo com Kurose (2010, p. 143) o protocolo IP, prov comunicao lgica entre
hospedeiros, oferecendo um servio de entrega de melhor esforo, no qual no h garantia de
entrega de segmentos, tampouco uma entrega ordenada de segmentos, nem mesmo a integridade
dos dados, caracterizando-se assim como um servio no confivel. O protocolo IP pertence
camada de rede e utilizado em conjunto com o protocolo TCP, para envio e recebimento de dados
via Web.
Kurose (2010) explica que diferente do rdio e da televiso, a web funciona por demanda,
ou seja, o usurio que escolhe o contedo a ser consumido. A web tambm permite uma
comunicao de mo dupla, na qual o mesmo usurio pode tanto consumir quanto enviar contedo.
Na camada de aplicao o protocolo HTTP (HyperText Transfer Protocol - Protocolo de
Transferncia de Hipertexto) o responsvel pela comunicao entre cliente (computador que
requisita algum contedo web) e servidor (computador que disponibiliza algum contedo na web).
O protocolo HTTP do tipo requisio-resposta. O cliente envia uma mensagem de
requisio para o servidor, contendo o URL do recurso solicitado. O servidor pesquisa o nome de
caminho e, se ele existir, envia de volta para o cliente o contedo do recurso em uma mensagem de
resposta. Caso contrrio ele envia de volta uma resposta de erro, como a conhecida mensagem 404
Not Found (Coulouris et al, 2012, p.30).
Usualmente, os navegadores de internet implementam o protocolo HTTP no lado do cliente,
e os servidores implementam o lado servidor do HTTP e abrigam objetos Web, cada um com seu
endereo nico. De acordo com Kurose (2010, p.73) so servidores Web populares o Apache e o

29

Microsoft Internet Information Server (sic). O cliente HTTP inicia uma conexo TCP com o
servidor, e assim que estabelecida, o navegador acessa o TCP por meio de seus sockets, envia as
requisies HTTP ao servidor, que processar uma resposta HTTP a ser recebida pelo cliente
(Kurose, 2010).
Segundo Kurose (2010) um objeto simplesmente um arquivo, por exemplo, uma imagem,
um vdeo, ou um texto, que acessvel por meio de uma URL (Uniform Resource Locator Localizador Uniforme de Recursos) que o endereo eletrnico nico necessrio para acess-lo.
Textos geralmente so entregue utilizando o padro HTML (HyperText Markup Language Linguagem de Marcao de Hipertexto) que, segundo Coulouris et al (2012, p.30) usada para
especificar o texto e as imagens que compem o contedo de uma pgina Web e para especificar
como eles so dispostos e formatados para apresentao ao usurio.
Como o TCP um protocolo confivel, o HTTP no se preocupa com dados perdidos, uma
vez que estes so gerenciados pelo TCP. O HTTP um protocolo sem estado, o que significa que ao
requisitar um objeto vrias vezes, em vez de o servidor guardar o estado da primeira requisio e
enviar uma mensagem ao cliente, o servidor envia o mesmo objeto vrias vezes ao cliente como se
fosse a primeira vez. Um servidor web sempre est em funcionamento, tem um endereo de IP fixo
e pode atender inmeros navegadores diferentes (Kurose, 2010).
Quando componentes de hardware ou software, estando localizados em computadores
distintos interligados em rede, comunicam-se e coordenam suas aes trocando mensagens entre si,
formam o que chamado de sistemas distribudos. Essa definio abrange inmeros tipos de
sistemas nos quais computadores interligados em rede podem ser distribudos de maneira til. Essa
separao entre hardware no tem limite de distncia, podendo estarem separados entre continentes,
no mesmo prdio ou na mesma sala. Como tpicos dessa definio, tem-se (Coulouris et al, 2012):

Concorrncia: A capacidade do sistema de manipular recursos compartilhados entre


computadores pela rede, de maneira que um usurio no possa interferir no outro.

Inexistncia de relgio global: A cooperao entre aes distribudas se d por troca de


mensagens, e frequentemente depende de uma noo compartilhada do tempo, entretanto
verifica-se a existncia de limites para a preciso com o qual computadores podem
sincronizar seus relgios em uma rede.

Falhas independentes: necessrio atentar-se para a possibilidade de falhas nos sistemas


distribudos, pois elas podem acontecer de formas diferentes. Um computador pode no
identificar se a rede est lenta ou se falhou, de forma que pode desencadear falhas nos
programas, pois o computador fica isolado do restante do sistema, podendo tambm afetar
outros componentes.

30

Segundo Coulouris et al (2012, p.10) os avanos tecnolgicos na miniaturizao de


dispositivos e interligao em rede sem fio tm levado cada vez mais integrao de equipamentos
de computao pequenos e portteis com sistemas distribudos. Esses equipamentos vo desde a
notebooks e aparelhos portteis (smartphones, equipamentos com GPS, cmeras de vdeo digitais)
at aparelhos acoplados ao corpo (wereables) e dispositivos incorporados em aparelhos como
mquinas de lavar, aparelhos de som, carros, geladeiras etc.
A portabilidade de muitos desses dispositivos, em complemento capacidade de se conectar
a diferentes redes em diferentes lugares, tornam real a computao mvel, de forma a possibilitar
usurios a acessarem aparelhos que esto em suas residncias mesmo estando em lugares
completamente diferentes sendo possvel, por exemplo, receber uma mensagem da mquina de
lavar quando ela terminar a lavagem (Coulouris et al, 2012).
2.5.1 SERVIOS WEB (WEB SERVICES)
No s usurios utilizam a Web, mas tambm outros programas, alm dos navegadores,
podem se comportar como clientes Web e isso muito comum, no entanto, necessrio um padro
mais completo para essa comunicao, pois o HTML limitado. A linguagem XML (Extensible
Markup Language - Linguagem de Marcao Estendida) foi projetada de modo a representar dados
padronizados, estruturados e especficos para cada aplicativo. Na Web, ela utiliza os mtodos POST
e GET do protocolo HTTP para fornecer e recuperar dados do servidor (Coulouris et al, 2012).
Coulouris et al (2012, p.32) explica que h a possibilidade de atualizar e deletar dados no
servidor por meio do protocolo HTTP com os mtodos PUT e DELETE, e essa estratgia pode ser
implementada em servios Web por meio da arquitetura REST (REpresentational State Transfer Transferncia de estado representacional). Dessa forma, todo recurso tem um URL e responde ao
mesmo conjunto de operaes.
Um Web Service um modelo de comunicao entre servidor e cliente no qual fornecido
uma interface da qual os clientes interagem com servidores de uma maneira mais geral da que
acontece nos navegadores. Os clientes acessam operaes de um servio Web por meio de
requisies e respostas HTTP, e utilizam de uma linguagem padro para comunicao como, por
exemplo, o XML e podem ser montados em cima de outros servios Web (Coulouris et al, 2012).
Os servios web se comportam como interfaces de comunicao entre sistemas diferentes,
pois independente da linguagem de programao e dos paradigmas especficos de cada programa, a
comunicao pode acontecer de maneira padronizada com o uso do Web service. Isso interessante
para garantir o baixo acoplamento entre sistemas distribudos, ou seja, a dependncias entre

31

servios minimizada, tornando a arquitetura mais flexvel e reduzindo o risco de alterao de um


servio desencadear uma reao em cadeia em outros servios (Coulouris, 2012).
Segundo Coulouris (2012) h uma tendncia em usar interfaces simples e genricas em
sistemas distribudos, e isso resulta em um grande aceite da estratgia REST nos servios Web. A
estratgia REST segue a filosofia adotada aos servios Web de serem de baixo acoplamento, pois a
nfase est na manipulao de recursos de dados, em vez de interfaces. Os clientes recebem o
estado inteiro de um recurso, em vez de chamar uma operao para fornecer alguma parte dele.
2.5.2 ZIGBEE
De acordo com Farahani (2008), ZigBee um padro que define um conjunto de protocolos
de comunicao para redes sem fio de curto alcance e de baixa transferncia de dados. Uma rede
sem fio ZigBee transporta no mximo 250 kilobits por segundo, e geralmente usada para sistemas
de baixo custo, normalmente a base de pilhas ou baterias, e geralmente funcionam em modo de
economia de bateria, conhecido como sleep mode.
Exemplos de aplicaes do ZigBee so sistemas de medio de presso arterial ou batimento
cardaco feitos por dispositivos acoplados ao corpo, conhecido como wearables. Estes dispositivos
enviam informaes para outro dispositivo local, como um computador ou smartphone que far o
envio dessas informaes para servidores na internet. Os receptores ZigBee tm a capacidade de
replicar os dados, e isso faz com que a informao tenha alcance maior e, consequentemente,
abrangendo mais possibilidades de implantao como, por exemplo, a instalao de sensores
interligados por um prdio inteiro (Farahani, 2008).
Farahani (2008) explica que o ZigBee baseado na tecnologia IEEE 802.15.4, que mais
vantajosa que o IEEE 802.11 por ter custo e complexidade reduzidos na implantao de seus
transceptores, assim como o ZigBee tem o menor gasto de energia, e isso o faz mais vantajoso que a
tecnologia Bluetooth tambm. A tecnologia Bluetooth tem maior capacidade de transferncia de
dados, isso a torna mais vantajosa que o ZigBee em outras finalidades, como headphones sem fio
por exemplo, nesse caso essa implementao provavelmente no funcionaria com ZigBee.
Existem dois tipos de dispositivos em uma rede sem fio padro IEEE 802.15.4, um com
capacidades limitadas (reduced-function devices (RFD) e outro capaz de realizar todos os processos
descritos no padro IEEE 802.15.4, o full-function devices (FFD). Um FFD, por exemplo, pode
comunicar com qualquer outro dispositivo na rede, ao passo que um RFD pode comunicar-se
apenas com um dispositivo FFD (Farahani, 2008).

32

2.6

ENGENHARIA DE SOFTWARE
Para Booch, Rumbaugh e Jacobson (2005, p.3) A modelagem uma parte central de todas

as atividades que levam implantao de um bom software. Utilizando os modelos, possvel


expressar a estrutura e o comportamento desejados do sistema, visualizar e controlar a arquitetura
do sistema, compreend-lo melhor ao ponto de enxergar oportunidades de simplificao e
reaproveitamento, facilitando tambm o gerenciamento de riscos. Apesar de ser possvel
desenvolver sistemas sem modelagem, faz-la torna a execuo dos projetos muito mais fceis e
menos suscetveis a erro.
Para Bezerra (2002) a modelagem til para o gerenciamento de complexidade, devido
dimenso dos projetos de software, comunicao entre pessoas envolvidas, pois devido ao nmero
de envolvidos no projeto, necessita-se de uma linguagem comum para troca de informaes do
projeto, reduo no custo do desenvolvimento, visto que erros de desenvolvimento causam bastante
custo, que pode ser evitado se detectado em fase de projeto, e por fim, modelos funcionam como
laboratrio, onde diferentes solues podem ser analisadas.
Booch, Rumbaugh e Jacobson (2005) e Bezerra (2002) explicam que a UML (Unified
Modeling Language - Linguagem de Modelagem Unificada) uma linguagem visual padro para
modelar e estruturar projetos de software. Ela pode ser utilizada para visualizao, especificao,
construo e documentao de diversas perspectivas do sistema. A UML somente uma parte de
um mtodo de desenvolvimento de software, e no depende de linguagem de programao nem do
processo, apesar de ser utilizada em processo orientado a casos de uso, iterativo e incremental,
centrado na arquitetura.
A UML uma linguagem expressiva e de grande abrangncia, apesar de no ser difcil de se
compreender. Para entender sua aplicao necessrio compreender seus trs principais elementos:
os blocos bsicos de construo da UML, as regras de combinao desses blocos, e alguns
mecanismos que se aplicam a toda a linguagem. Existem trs tipos de blocos de construo, os
Itens, que so entidades abstradas como cidados de primeira classe em um modelo; os
Relacionamentos, que renem esses itens; e os Diagramas, que agrupam colees interessantes de
itens (Booch, Rumbaugh e Jacobson, 2005).
Segundo Booch, Rumbaugh e Jacobson (2005, p.36), para obter o maior proveito da UML,
ser preciso levar em considerao um processo que seja: orientado a caso de uso, de forma a usar
este artefato como base principal para estabelecimento do comportamento desejado do sistema;
centrado na arquitetura, utilizando assim a arquitetura do sistema como principal artefato para a
conceituao, construo e o gerenciamento da evoluo do sistema; interativo, ou seja, que

33

envolva o gerenciamento de sequncias de verses executveis; e incremental, para que haja


integrao contnua da arquitetura do sistema para a produo dessas veres, de maneira que a cada
nova verso, seja incrementado aprimoramentos do sistema.
Bezerra (2002) enfatiza a possibilidade de examinar sistemas a partir de diversas
perspectivas, focando aspectos diferentes do sistema. As vises propostas so as seguintes:

Viso de Casos de Uso: descreve o sistema de um ponto de vista externo, mostrando os


agentes externos e suas interaes entre o sistema.

Viso de Projeto: descreve as caractersticas estruturais e comportamentais do sistema e as


funcionalidades externamente visveis.

Viso de Implementao: foca no gerenciamento de verses do sistema, constitudas de


agrupamento de componentes e sub-sistemas.

Viso de Implantao: abrange a distribuio fsica do sistema em subsistemas e a relao


entre eles.

Viso de Processo: corresponde s caractersticas de concorrncia, sincronizao e


desempenho do sistema.
Booch, Rumbaugh e Jacobson (2005) e Bezerra (2002) explicam que nem sempre ser

necessrio construir todas as vises, e estas podem ser ordenadas por relevncia. Cada viso pode
ser considerada isoladamente, de forma que diferentes participantes foquem nos aspectos da
arquitetura do sistema que mais lhe interessam.
A modelagem UML envolve a criao de diversos documentos, podendo ser textuais ou
grficos. Tais documentos so denominados artefatos de software, ou somente artefatos, e estes
compem as vises do sistema. Os artefatos grficos so definidos utilizando-se diagramas da
UML. Cada diagrama fornece uma perspectiva parcial sobre o sistema a ser modelado, de forma
que um mesmo elemento pode aparecer em vrios diagramas (Bezerra, 2002).
Booch, Rumbaugh e Jacobson (2005) citam 13 diagramas de UML, o que no uma lista
completa dos diagramas contemplados na linguagem, apesar de que esses tipos sero os mais
encontrados na prtica. So eles:

Diagrama de Classes: descreve visualmente um conjunto de classes, interfaces e


colaboraes, bem como seus relacionamentos, representando a estrutura do sistema de
forma esttica.

Diagrama de Objetos: exibe um conjunto de instncias de elementos encontrados em


diagramas de classes e seus relacionamentos, sob a perspectiva de casos reais ou de
prottipos.

34

Diagrama de Componentes: corresponde a uma classe encapsulada e suas interfaces, portas


e estrutura interna, constituda de componentes aninhados e conectores.

Diagrama de estruturas compostas: ligeiramente diferente do diagrama de componentes,


visto que a distino entre um componente e uma classe estruturada sutil.

Diagrama de casos de uso: denota um conjunto de casos de uso e atores e seus


relacionamentos. So importantes para a organizao e modelagem de comportamentos do
sistema.

Diagrama de sequncias: um diagrama de interao cuja nfase est na ordenao


temporal das mensagens.

Diagrama de comunicaes: consiste em um diagrama de interao que enfatiza a


organizao estrutural dos objetos e seus papis, e como enviam e recebem mensagens.

Diagrama de grficos de estados: exibem uma mquina de estados, transies, eventos e


atividades, abrangendo uma viso dinmica de um objeto.

Diagrama de atividades: contempla a estrutura de um processo ou, por exemplo fluxo de


controle, dados de cada etapa de uma computao, dando foco ao fluxo de controle entre
objetos.

Diagrama de implantao: mostra a configurao dos ns de processamento em tempo de


execuo e os componentes neles existentes.

Diagrama de pacote: descreve o modelo em unidades organizacionais e suas dependncias.

Diagrama de temporizao: exibe tempos reais em diferentes objetos ou papis, em vez de


sequncias de mensagens relativas.

Diagrama de viso geral da interao: um hbrido de um diagrama de atividades e um


diagrama de sequncias.
Segundo Bezerra (2002) um processo de desenvolvimento de software classifica as tarefas

realizadas durante a construo de um sistema de software. H vrios processos de


desenvolvimentos propostos, cada qual com sua particularidade, de forma que no h um processo
especfico que seja reconhecidamente o melhor. Entretanto h algumas atividades que so comuns
maioria dos processos existentes. So elas:

Levantamento dos requisitos: a etapa de compreenso do problema aplicada ao


desenvolvimento do software, estabelecendo a mesma viso entre usurios e
desenvolvedores, de forma a compreender as necessidades a serem atendidas. s
necessidades, denomina-se requisitos, que so as condies ou capacidades que devem ser
aladas por um sistema ou componente. Os requisitos so divididos entre funcionais, que

35

definem as funcionalidades do sistema, e os no-funcionais, que exploram as caractersticas


de qualidade que o sistema deve possuir. Nesta fase tambm so definidas as restries do
sistema.

Anlise de requisitos: a etapa que detalha os requisitos levantados na atividade anterior


para construir modelos de representao do sistema a ser construdo. Esta atividade foca na
estratgia de soluo sem relevar a maneira (tecnolgica) como essa estratgia ser
realizada. Os modelos construdos so cuidadosamente validados e verificados, assegurando
que as necessidades do cliente esto sendo atendidas e que os modelos construdos esto em
conformidade com os requisitos definidos.

Projeto: nesta fase determina-se como o sistema funcionar para atender os requisitos, de
acordo com os recursos tecnolgicos existentes. So definidos: arquitetura do sistema,
padro de interface grfica, linguagem de programao, gerenciador de banco de dados, etc.
Tambm so definidas as restries tecnolgicas, consequentes ou no das restries
levantadas na fase de levantamento de requisitos.

Implementao: a fase de execuo do projeto, ou seja, a etapa em que o sistema


codificado. Ocorre ento uma traduo da descrio computacional feita na fase de projeto
em um cdigo executvel utilizando-se de uma ou mais linguagens de programao. Em um
processo de desenvolvimento de software orientado a objetos, a implementao envolve a
definio de classes de objetos do sistema utilizando linguagens que tem suporte a tal
paradigma, como C++, Java etc. A codificao quase sempre utiliza-se de componentes de
software e bibliotecas preexistente para agilizar a atividade.

Testes: Nessa etapa so realizadas diversas atividades de testes, para verificao do sistema,
levando-se em considerao a especificao feita na fase de projeto. Existem vrios tipos de
testes com diferentes focos, sendo que o principal produto final dessa fase o relatrio
desses testes, contendo informaes de erros e no-conformidades detectados no software.
Aps essa fase de testes, diversos mdulos do sistema so integrados de maneira a formar o
produto final de software.

Implantao: nesta etapa o sistema empacotado, distribudo e instalado no ambiente do


usurio. Tambm devem ser escritos manuais do sistema, para que se realize treinamentos
com os usurios para que utilizem o sistema corretamente. Em alguns casos, nessa fase
tambm ocorre a migrao de sistemas de software preexistente, havendo uma transferncia
de dados entre bases de dados dos sistemas antigos e atuais.

36

Booch, Rumbaugh e Jacobson (2005) caracteriza o ciclo de vida de um projeto em quatro


fases, que resultam no intervalo de tempo entre dois marcos do projeto, de forma que quando um
conjunto bem definido de objetivos alcanado, decises so tomadas para se passar prxima
fase. A Figura 5 descreve as quatro fases e desenha o nvel de esforo para cada etapa do projeto.
As quatro fases so:

Concepo (Inception): a fase inicial do processo, em que a ideia para o desenvolvimento


levada at o ponto de ser suficientemente fundamentada para que seja elaborada.

Elaborao (Elaboration): a segunda fase do processo, que define a viso e arquitetura do


produto de software. So levantados os requisitos do sistema e definidas as prioridades.

Construo (Construction): a fase em que o software chega em uma arquitetura executvel


de forma que possa haver a transferncia para a comunidade de usurios.

Transio (Transition): a fase em que o software entregue aos usurios. Essa fase no
define o fim do processo de desenvolvimento, pois eventualmente o sistema ser
aprimorado, corrigido e incrementado com novas caractersticas.

Figura 5: Ciclo de Vida de desenvolvimento de um software


Fonte: Booch, Rumbaugh e Jacobson (2005, p.37)

Bezerra (2002) afirma que o desenvolvimento de software uma tarefa altamente


cooperativa. Uma equipe de desenvolvimento de software pode envolver vrios especialistas.

37

possvel identificar sete papeis distintos entre os participantes do processo de desenvolvimento, dos
quais uma pessoa pode ou no executar mais de um papel ou um papel pode ser desempenhado por
vrias pessoas. A descrio de cada papel listada a seguir:

Gerente de projeto: o responsvel pela coordenao das atividades de construo do


sistema. Cabe tambm a este profissional o oramento do projeto em relao ao tempo de
desenvolvimento, definir qual o processo de desenvolvimento, o cronograma, a mo-de-obra
especializada e os recursos de hardware e software. O gerente tambm acompanha a
realizao das atividades e verifica a utilizao dos recursos alocados.

Analista: cabe a esse profissional conhecer o domnio do negcio, para que possa definir os
requisitos do sistema, atuando como um intermediador entre o usurio final e o especialista.

Projetista: o componente da equipe que avalia as alternativas de soluo do problema


resultante da anlise e gera a especificao de uma soluo computacional detalhada.

Arquiteto de software: a necessidade desse profissional aumenta proporcionalmente


complexidade do sistema a ser construdo. Seu papel consiste em elaborar a arquitetura do
sistema como um todo, alm de atuar na tomada de decises tcnicas como detalhes que
influenciam no desempenho do sistema.

Programador: o profissional responsvel pela implementao do sistema, traduzindo os


modelos resultantes do trabalho do projetista em cdigo de computador. muito comum
que a mesma pessoa realize o papel tanto do analista quanto do programador, mas mesmo
que isso no acontea, importante que o profissional conhea as duas reas para que a
implementao do produto de software seja mais condizente com sua anlise.

Cliente: a entidade para qual o sistema construdo. Essa entidade pode ser o cliente
usurio, que a pessoa que efetivamente utilizar o sistema, e o cliente contratante, que a
pessoa que solicita o desenvolvimento.

Grupos de avaliao de qualidade: so pessoas responsveis pela avaliao do sistema em


termos de desempenho e confiabilidade, os quais devem se encaixar nos padres de
qualidade estabelecidos pela organizao.

2.6.1 CASOS DE USO


De acordo com Bezerra (2002) os casos de uso moldam os requisitos funcionais do sistema.
Sua notao grfica simples e descrio em linguagem natural facilita a comunicao entre
desenvolvedores e usurios. Este modelo bastante importante pois direciona diversas tarefas
posteriores no ciclo de vida do sistema de software, alm de forar os desenvolvedores a moldarem

38

o sistema ao usurio, e no o usurio ao sistema. A representao grfica do caso de uso feita pelo
diagrama de casos de uso.
Os diagramas de caso de uso so importantes pois apresentam uma viso externa sobre
como os elementos podem ser utilizados no contexto, visualizando especificando e documentando o
comportamento de um elemento. Um diagrama de casos de uso um diagrama que mostra um
conjunto de casos de uso e atores e seus relacionamentos (Booch, Rumbaugh e Jacobson, 2005,
p.243) descrevendo uma funcionalidade especfica do sistema, representando uma sequncia de
interaes entre atores e o sistema.
O caso de uso definido por meio de uma descrio narrativa (contnua, numerada ou
particionada) das interaes entre o(s) elemento(s) externo(s) e o sistema. H quatro
relacionamentos possveis em um caso de uso ou entre casos de uso (Bezerra, 2002):

Relacionamento de Comunicao: representa uma informao de quais atores esto


associados a que casos de uso, indicando que esse ator interage (troca informaes) com o
sistema. Um ator pode se relacionar com mais de um caso de uso do sistema.

Relacionamento de incluso: quando dois ou mais casos de uso incluem uma mesma
sequncia de interaes, essa sequncia comum pode ser descrita em um outro caso de uso,
que ser includo de forma a reutilizar a sequncia de interaes, tornando a descrio dos
casos de uso como um todo mais simples.

Relacionamento de extenso: um relacionamento em que um caso de uso inclui o


comportamento especificado em outro, nesse caso o primeiro estende o segundo, e o
segundo chamado de estendido e o primeiro chamado de extensor. Imaginando a
modelagem de um sistema de edio de textos, os casos de uso Corrigir Ortografia e
Substituir Texto podem ser definidos como extenses de Editar Documento.

Relacionamento de generalizao: um relacionamento que permite que um caso de uso ou


um ator herde caractersticas de outro caso de uso ou ator mais genrico, em que o primeiro
elemento chamado de base. A diferena bsica entre extenso e generalizao que no
segundo, os elementos so semelhantes porm um mais especfico que o outro, e no
primeiro os elementos podem ser distintos porm compartilham de uma ou mais sequncias
opcionais.
Segundo Bezerra (2002) a notao utilizada para ilustrar atores em um Diagrama de Casos

de Uso a figura de um boneco de palito com o nome do ator em baixo. Visto que um ator nem
sempre corresponde a seres humanos, essa notao no compreende o ator em sua completude.
Cada caso de uso representado por uma elipse, com o nome escrito abaixo ou dentro da elipse.
Um relacionamento de comunicao representado por um segmento de reta entre os elementos.

39

Pode-se tambm representar uma fronteira do sistema utilizando um retngulo no qual so inseridos
os casos de uso. Os atores so posicionados do lado de fora do retngulo, enfatizando a diviso
entre o interior e o exterior do sistema.
Os relacionamentos de incluso e extenso so representados por uma seta direcionada entre
elementos na direo do elemento incluso ou do elemento estendido, com um rtulo que intitula o
relacionamento. Da mesma forma o relacionamento de generalizao representado por uma seta,
porm geralmente utiliza-se de uma reta contnua, ligando o elemento especfico ao elemento base.
A Figura 6 representa um exemplo de caso de uso com relacionamento de comunicao e extenso
(Bezerra, 2002).

Figura 6: Exemplo de caso de uso com relacionamento de comunicao e extenso


Fonte: Bezerra (2002, p.59)

2.6.2 DIAGRAMAS DE CLASSE


Uma classe descreve um conjunto de objetos com os mesmos atributos, operaes,
relacionamentos e semntica, o bloco de construo mais importante em um sistema orientado a
objetos, pois incluem abstraes que so partes do domnio do problema de forma que, quando bem
estruturadas, formam uma distribuio equilibrada de responsabilidades em um sistema. Uma classe
representada graficamente com um retngulo (Booch, Rumbaugh e Jacobson, 2005).
Segundo Bezerra (2002) a representao grfica de uma classe dividida em trs elementos,
o nome, que identifica a classe no sistema, os atributos, que correspondem s informaes que um
objeto armazena, e as operaes, que correspondem s aes que um objeto sabe realizar. Os
atributos tm valores especficos que so atribudos intrinsecamente a cada objeto, ao contrrio das
operaes, que so as mesmas para qualquer objeto de uma classe.
Booch, Rumbaugh e Jacobson (2005) explicam que cada classe deve ter um nome que a
diferencie de outras classes, e esse nome uma sequncia de caracteres, sem espaos, tipicamente

40

com a primeira letra maiscula, e pode ser simples, contendo apenas o nome da classe em si, ou
qualificado, que o nome da classe tendo como prefixo o nome do pacote a qual pertence. Um
atributo representa alguma propriedade do item que est sendo modelado, compartilhado por todos
os objetos dessa classe, por exemplo, uma classe que representa uma parede teria como atributos:
largura, espessura e altura. Uma classe pode ter qualquer nmero de atributos ou nenhum atributo.
Para Guedes (2011) a regra para nomes de atributos praticamente a mesma dos nomes de
classes, porm normalmente inicia-se com letra minscula. A representao no diagrama seguida
do tipo de dados, que indica o formato que os dados devem ter para serem armazenados em um
determinado atributo.
Uma operao representa um comportamento de um objeto de uma classe, por exemplo, em
uma classe que representa graficamente as janelas de um programa, existe uma operao de
redimensionamento que altera a altura e a largura do objeto janela. Da mesma forma que os
atributos, uma classe pode ter qualquer quantidade de operaes ou nenhuma operao. A
especificao de uma operao contm o nome, o tipo e o valor-padro de todos os parmetros e o
tipo a ser retornado (Booch, Rumbaugh e Jacobson, 2005).
Bezerra (2012) afirma que o diagrama de classe tambm pode apresentar associaes entre
classes, formadas entre objetos durante a execuo do sistema. Uma associao representada por
um segmento de reta ligando as classes s que se relacionam. Cada associao possui duas
multiplicidades, uma em cada extremo da linha, que corresponde quantidade de objetos que
podem estar associados a outro. Tais multiplicidades podem ser de Apenas um, Zero ou Muitos, Um
ou Muitos, Zero ou Um, ou um intervalo especfico.
Uma associao, segundo Bezerra (2012), consiste de trs recursos de notao: nome de
associao, que uma representao semntica da associao, direo de leitura, representada por
uma seta que indica como a associao deve ser lida, e papel, que indica a relao do objeto na
associao. Existe tambm um caso especial de associao: a agregao. Uma agregao representa
conexes entre objetos que guardam uma relao todo-parte entre si. Graficamente, desenhado
um losango na extremidade ligada classe que incorpora a outra, por exemplo, uma classe Equipe
contm uma ou vrias classes Jogador.
Segundo Guedes (2011, p.132) "apesar de haver recursos j descritos como agregao,
composio, generalizao/especializao ou mesmo classes associativas, no obrigatria sua
utilizao em todo o diagrama de classes". A Figura 7 apresenta um modelo conceitual de um
sistema de controle bancrio.

41

Figura 7: Exemplo de modelagem de classes simulando um sistema de controle bancrio


Fonte: Guedes (2011, p.132)

2.6.3 DIAGRAMA DE COMPONENTES


Para Guedes (2011, p.320) um componente pode sempre ser considerado uma unidade
autnoma dentro de um sistema ou subsistema. Um componente encapsulado de forma que ele
possa ser tratado o mais independente possvel. Bezerra (2002) explica que um componente uma
unidade de software que pode ser utilizada na construo de vrios sistemas, e que pode ser
substituda por outra unidade que faa o mesmo servio e que os clientes possam configurar de
maneira a modificar seu funcionamento.
Um diagrama de componentes representa os componentes do sistema em termos de mdulos
de cdigo, bibliotecas, arquivos de ajuda, ou seja, identifica os componentes que fazem parte de um
sistema. Um componente pode ser de natureza lgica, como um processo, ou fsica, como arquivos
de cdigo-fonte, de ajuda, ou executveis. Este diagrama determina como tais componentes estaro
estruturados e como iro interagir entre si, permitindo uma melhor compreenso do ecossistema
tecnolgico (Guedes, 2011).

42

Segundo Guedes (2011) um componente representado por um retngulo, com um smbolo


na parte superior direita, que na verdade era seu antigo smbolo, um retngulo com dois retngulos
menores sobressaindo esquerda. Seus relacionamentos so representados por segmentos de reta, e
dentro de cada retngulo fica o nome do componente e um esteretipo, que indica sua semntica em
relao ao sistema. A Figura 8 representa um exemplo de diagrama de componentes.

Figura 8: Exemplo de diagrama de componentes de um sistema de controle


bancrio
Fonte: Guedes (2011, p.324)

2.6.4 DIAGRAMA DE IMPLANTAO


Segundo Guedes (2011) diagrama de implantao determina as necessidades de hardware do
sistema e caractersticas fsicas, como servidores, arquitetura de redes e comunicao, infraestrutura
fsica, e tambm informa como ser a distribuio de mdulos do sistema, em situaes nas quais
estes forem executados em mais de um servidor, bem como os protocolos de comunicao e
transmisso dos dados. Um diagrama de implantao s til quando h uma situao de sistemas
distribudos, de forma que quando o sistema executado somente em uma mquina e no se
comunica com outro hardware este diagrama se torna desnecessrio.

43

Os componentes bsicos de um diagrama de implantao so os ns. Estes podem


representar um item de hardware, ou um servidor, ou um ambiente de execuo. Ns podem conter
outros ns, e representado por um cubo que recebe um esteretipo identificando o tipo de n (por
exemplo: <<dispositivo>>) e o nome do n em si, que reflete a uma identificao mais especfica,
ainda sendo possvel adicionar tags que denotam uma especificao mais detalhada.
Os ns podem ter ligaes fsicas entre si para que seja possvel a troca de informaes, e
so representadas por segmentos de reta. Essas linhas so chamadas associaes, que podem
determinar tanto uma ligao fsica entre ns quanto uma relao lgica descrita na forma como
eles se comunicam, ou seja, um protocolo de comunicao utilizado, e essa representao pode ser
feita com rtulos de esteretipos (Guedes, 2011).
De acordo com Guedes (2011), num diagrama de implantao tambm possvel expressar
artefatos, que representam uma entidade real (mesmo que virtual) que est implementada em um n.
A Figura 9 esboa um exemplo de diagrama de implantao contendo ns, associaes e artefatos,
que so os retngulos internos aos ns, como o artefato Interface Caixa Eletrnico, que que est
implementado no n Caixa Eletrnico e cuja funo repassar os eventos ocorridos ao sistema de
controle bancrio.

Figura 9: Exemplo de diagrama de implantao de um sistema de controle bancrio


Fonte: Guedes (2011, p.341)

Guedes (2011) ainda cita que os ns so apenas abstraes, como o n Caixa eletrnico no
exemplo da Figura 9, que representa todos os Caixas eletrnicos do sistema em apenas um nico n.

44

Os ns tambm podem ser organizados por pacotes, caso haja necessidade, para representar, por
exemplo, subsistemas, ou mdulos com muitos ns.

45

PARTE II
3

PROJETO DE SOFTWARE

O sistema proposto descreve um ambiente de automao residencial na qual o usurio


interage com aparelhos eltricos e eletrnicos utilizando como Interface Humano-Computador
(IHC) um dispositivo mvel com sistema Android. Este dispositivo ser responsvel por
comunicar-se com os aparelhos de uma residncia por meio de uma rede sem fio e enviar ordens a
um servidor local, e este distribuir a ordem ao sistema com Arduino, que recebe os comandos pelo
seu mdulo Xbee Shield, e traduz as ordens aos aparelhos da residncia.
Dessa forma, o ambiente de automao dividido em quatro partes, caracterizando-se como
um sistema distribudo, sendo a primeira parte o Arduino, que permite que os aparelhos sejam
programados; A segunda parte o servidor local, que pode ser qualquer computador que tenha um
Xbee Shield conectado via USB, sendo este o intermedirio entre o sistema de automao e a
internet; A rede sem fio (WAN ou LAN) que far a comunicao de dados entre usurio e
aparelhos; e O dispositivo com Android, que se comportar como interface para que o usurio se
comunique com o sistema, utilizando-se da funo de interpretao de Linguagem Natural, o
Google Now, presente nas verses mais atuais.
Exemplos de uso prtico desse ambiente podem ser considerados: Automao de Porto
Eletrnico; Ligar e Desligar luzes; Ligar, Desligar e Trocar canais de uma Televiso; Controle de
Ar Condicionado; e demais atividades semelhantes.
Para que o sistema seja implantado em uma residncia, necessrio que um profissional
com conhecimento da rea, geralmente conhecido como integrador de sistemas residenciais
(Muratori e Dal B, 2011), faa a instalao do Arduino e demais mdulos nos respectivos
aparelhos da residncia, a configurao da Rede Sem Fio, e a configurao do aplicativo no
dispositivo Android do usurio. Uma vez que tais configuraes so feitas, e o sistema esteja em
pleno funcionamento, bastar que o celular esteja ligado e conectado Internet, para que o usurio
envie comandos de voz para os aparelhos.
de extrema importncia a presena de um integrador de sistemas residenciais atuando
como implantador do projeto, visto que sua implantao pode no ser to simples para usurios
leigos, ou com algum tipo de necessidade especial, da mesma forma que de extrema importncia
que este profissional configure corretamente o aplicativo no dispositivo mvel do usurio, pois esta
configurao s necessria nesta fase de implantao, ou caso o usurio troque de dispositivo.
Dependendo da necessidade do usurio, por exemplo, um usurio com deficincia visual ou de

46

membros, este no ser capaz de configurar o dispositivo Android sozinho, necessitando da ao do


integrador de sistemas residenciais.
Dessa forma, depois de implantado, configurado e testado, o ambiente de automao atende
a alguns conceitos, dos definidos pelo Desenho Universal em 1987, tais como ambiente
Equitativo/Igualitrio, de uso Flexvel/Adaptvel, com informao de fcil percepo e de esforo
fsico mnimo. Tais aspectos garantem certo nvel de independncia Portadores de Necessidades
Especiais, pessoas idosas ou com dificuldade de locomoo (Guedes et al, 2012).
Dos itens citados por Pupo, Melo e Ferrs (2006), o ambiente de automao proposto possui
as caractersticas de algumas tecnologias assistivas, como Teclado Alternativo e Sistema para
entrada de voz, ambos inseridos na funo de interpretao de Linguagem Natural oferecida pelo
Google Now do Android, e Leitores de tela com sntese de voz, uma vez que o resultado de algumas
aes ou estados de aparelhos so informados usando a tecnologia Text-to-Speech, tambm presente
no Android.
3.1

DESCRIO GERAL DO PRODUTO

3.1.1 FUNES DO PRODUTO


Disponibilizar a usurios comuns ou portadores de necessidades especiais uma forma
automatizada e acessvel de controlar Utenslios Domstico de maneira a automatiz-los, por meio
de dispositivos mveis aliados a recursos de Voz.
3.2

ESPECIFICAO DE REQUISITOS

3.2.1 REQUISITOS FUNCIONAIS


RF001: O sistema deve permitir que o Usurio cadastre os ambientes que deseja.
RF002: O sistema deve permitir que o Usurio cadastre os utenslios.
RF003: O sistema deve permitir que o Usurio cadastre as aes realizadas pelos utenslios.
RF004: O sistema deve permitir que o Usurio relacione o comando de voz de sua preferncia
ao e o utenslio.
RF005: O sistema deve permitir que o Usurio informe o endereo o caminho pelo qual se
comunica com o utenslio.
3.2.2 REQUISITOS NO-FUNCIONAIS
RNF001: O sistema deve ser implementado em ambiente mvel.
RNF002: O sistema deve ter acesso Internet devido necessidade de processamento por voz,
utilizar a API do Google Now.
3.2.3 REGRAS DE NEGCIO
RN001: Ao iniciar (ligar) o dispositivo mvel, o aplicativo dever ser carregado em segundo plano,
ou seja, sem a necessidade de iterao com o usurio.

47

RN002: Na primeira inicializao do aplicativo o mesmo dever verificar a existncia do Utenslio


e aes de modelo, caso no as encontre, o mesmo realiza a RN003.
2.1: Lembrando que o cadastro baseado nas Aes. A cada ao cadastrada, o sistema
agrupar por Utenslio suas respectivas aes, como descrito no PR001.
RN003: Na primeira execuo do aplicativo, aps sua instalao, se realizar um prvio cadastro de
Utenslios e Aes, servindo de modelo para o usurio.
RN004: O usurio poder alterar ou remover o cadastro prvio gerado.
4.1: Ao pressionar o boto + (incluir) no topo da tela, o usurio poder realizar um novo
cadastro de utenslio e suas aes, aliando a ele o seu comando de voz, descrito no PR003.
4.2: Ao selecionar o registro, o aplicativo habilitar a barra de tarefas (ActionBar), exibindo
as possibilidades de, alterao ou excluso por meio de botes localizados na parte superior da tela
do dispositivo mvel, descrito no PR002.
4.3: Ao solicitar a realizao da excluso, o aplicativo dever solicitar a confirmao desta
Ao, descrito no PR002.
RN005: O aplicativo dever permanecer em execuo, mesmo se o usurio solicitar o encerramento
(o aplicativo continuar sua execuo em segundo plano).
3.3

PROTTIPOS

3.3.1 PR001 TELA INICIAL

Figura 10: PR001 Tela Inicial


Fonte: Autor

48

3.3.2 PR002 TELA DE EXCLUSO

Figura 11: Tela de Excluso


Fonte: Autor

3.3.3 PR003 TELA DE CADASTRO

Figura 12: Tela de Cadastro


Fonte: Autor

49

3.4

MODELAGEM

3.4.1 DIAGRAMA DE CASOS DE USO

Figura 13:Diagrama de Caso de Uso


Fonte: Autor

50

3.4.2 DESCRIO DOS CASOS DE USO


Nome do Caso de Uso: Manter Utenslio.
Objetivos: Realizar as operaes de incluso, alterao, excluso e
consulta sobre Utenslio e suas aes.
Ator: Usurio.
Pr-Condio:
Ps-Condio: Dados do Utenslio e suas aes sero persistidos.
Caminho de Execuo: Devido s operaes relacionadas nos objetivos, o
caminho primrio de cada operao ser:
Incluso: o usurio pressiona o boto novo, informa os
dados do Utenslio. Estes so validados no ato do cadastro,
em seguida o usurio pressiona o boto salvar e os dados
so
persistidos.
Edio: o usurio seleciona o registro no grid/listView da
tela de listagem e pressiona o boto Editar. O usurio
realiza as alteraes desejadas, os dados so validados. Em
seguida o usurio pressiona o boto salvar e os dados so
persistidos.
Excluso: o usurio seleciona o registro no grid/listView
da tela de listagem e pressiona o boto Excluir, o
aplicativo solicita confirmao desta excluso e em
afirmao positiva, realiza a excluso daquela Ao
relacionado quele Utenslio.
Selecionar Utenslio.
Realizar as Aes desejadas.
Usurio.
Todos os dados cadastrais de Utenslio, devero existir e
serem vlidos.
Ps-Condio: O aplicativo enviar a Ao selecionada.
Caminho de Execuo: Devido s operaes relacionadas nos objetivos, o
caminho
primrio
de
cada
operao
ser:
Nome do Caso de Uso:
Objetivos:
Ator:
Pr-Condio:

Seleo: o usurio seleciona um Utenslio dentre a lista


exibida, e seleciona a Ao desejada para o envio. Ex.:
Ligar, Desligar etc.
Nome do Caso de Uso: Solicitar a Execuo da Ao.
Objetivos: Realizar a solicitao da execuo da ao selecionada
pelo usurio no aplicativo do dispositivo mvel.
Ator: Web Service.
Pr-Condio: O servio dever estar disponvel.
Ps-Condio: Ao ser enviada.

51

Caminho de Execuo: Devido s operaes relacionadas nos objetivos, o


caminho
primrio
de
cada
operao
ser:
O servio (Web Service) recebe a Ao selecionada pelo
usurio no aplicativo mvel (ver Caso de Uso: Solicitar a
Execuo da Ao), essa mesma ao, reflete um cdigo
(inteiro ou hexadecimal), que ser processado
posteriormente. (Ver Caso de Uso: Processar Ao)
Processar Ao.
Transformar a ao em informao Serial.
Web Service.
O servio (Web Service) estar de posse da Ao enviada
pelo usurio pelo aplicativo mvel.
Ps-Condio: Envio da informa serializada pela rede 802.15.4 para os
dispositivos embarcados.
Caminho de Execuo: Devido s operaes relacionadas nos objetivos, o
caminho
primrio
de
cada
operao
ser:
Nome do Caso de Uso:
Objetivos:
Ator:
Pr-Condio:

A Ao recebida pelo servio (Web Service) refletir em


um cdigo (inteiro ou hexadecimal), e o mesmo ser
enviado, de forma serial, por meio da rede (802.15.4), aos
dispositivos embarcados presentes mesma rede do
servio (Web Service).
Executar Ao.
Distribuir o comando aos dispositivos embarcados.
Arduino.
Os dispositivos embarcados deveram estar aptos a receber
os comandos serializados.
Ps-Condio: Executa a ao selecionada para o Utenslio selecionado.
Caminho de Execuo: O dispositivo recebe por meio da rede (via broadcast) o
cdigo serializado (inteiro ou hexadecimal), julga se suas
regras embarcas acatam tal cdigo e a executa ou no.
Nome do Caso de Uso:
Objetivos:
Ator:
Pr-Condio:

3.4.3 DESCRIO DOS ATORES


Nome do Ator: Usurio.
Descrio: Pessoa de posse de dispositivo mvel, com conexo
alguma rede (WIFI, 3G etc.) com conexo Internet.
Nome do Ator: Web Service.
Descrio: Servio presente em mesma rede (WIFI, 3G etc.) dos
dispositivos mveis e dispositivos embarcados.
Nome do Ator: Arduino.
Descrio: Dispositivo embarcado com suas atribuies prconfiguradas, aliadas a mesma rede.

52

3.4.4 DIAGRAMA DE CLASSES

Figura 14:Diagrama do aplicativo mvel


Fonte: Autor

Figura 15:Diagrama do servio (web service)


Fonte: Autor

53

PARTE III
4

IMPLEMENTAO E IMPLANTAO

Em posse do referencial terico descrito, iniciou-se a investigao seguida de testes, visando


apontar tecnologias adequadas para a implementao de um prottipo, buscando atingir o objetivo
proposto no trabalho.
4.1

PORQUE ARDUINO?

O trabalho prope a automao de utenslios domsticos, tais como: lmpadas, televisores,


climatizadores, portes, sistema de irrigao etc., utilizando a plataforma de prototipao Arduino,
demonstrado na Figura 16. Utilizado em larga escala em projetos de automao, o Arduino a
melhor opo devidos a alguns fatores como: baixo custo de aquisio, vasta comunidade de
usurios, vasto portflio, disponibilidade de documentao, fruns etc.
A ideia ao utilizar o Arduino justamente automatizar a interao entre usurios e qualquer
tipo de utenslio domstico, ou seja, permitir que o manuseio destes aparelhos seja de forma
descomplicada, sem muito esforo e o principal, de forma acessvel.
Alguns componentes sero integrados ao Arduino, justamente por auxiliarem-no em funes
no qual no lhe compete. Provido de portas digitais e analgicas, o Arduino possibilita a
comunicao/controle de vrios componentes eltricos ou eletrnicos.

Figura 16:Plataforma de prototipao Arduino


Fonte: Autor

Um destes componentes, o mdulo rel, representado na Figura 17, foi utilizado para
implementar a primeira parte do prottipo. O mdulo substitui os tradicionais interruptores de
liga/desliga muito utilizado nas residncias, este recebe uma fonte de energia eltrica, pois o
Arduino no possui energia suficiente para alimentar utenslios domsticos. O mdulo rel funciona
como uma chave que controlada pelos sinais emitidos pelo Arduino. Quando um sinal emitido
para fechar a chave a fonte de alimentao de energia passa a conduzir corrente eltrica para o
utenslio domstico.

54

Figura 17: Mdulo Rel em ao com o Arduino


Fonte: Autor

Para que o mdulo receba ordens advindas do Arduino, um software precisa ser
desenvolvido e adicionado ao microcontrolador, isso que faz com que o Arduino seja capaz de
automatizar determinadas aes. A linguagem de programao, utilizada pelo Arduino, baseada
no ANSI C, no significa que seja a linguagem C, mas que se assemelha. O software, esboado na
Figura 18, ao ser compilado e carregado no microcontrolador, diz ao Arduino que execute leituras
seriais, esperando receber os cdigos inteiros 1 e 2, ento executa as respectivas aes de ligar ou
desligar, informando a porta 13, que est ligada ao mdulo rel, para acionar e liberar o fluxo de
energia, alimentando o mdulo e ligando assim o utenslio.

Figura 18: Cdigo adicionado ao Arduino para controle do mdulo rel


Fonte: Autor

55

Existem diversas maneiras para automatizar qualquer tipo de eletrodomstico utilizando o


Arduino em conjunto com algum de seus mdulos. Utenslios que utilizam controles remotos, por
exemplo, no esto limitados a um interruptor liga e desliga, e possuem LEDs (emissores de luz)
em seus controles que transmitem sinal infravermelho com comandos ao aparelho e este, por meio
de seu receptor, interpreta e responde ao comando com determinada funcionalidade. O Arduino
utilizando desses mesmos LEDs de infravermelho, demonstrados na Figura 19, que substituem o
controle remoto.

Figura 18: LEDs Emissores e Detectores de infravermelho


Fonte: Autor

Para implementar esse tipo de automao, foi necessria a implementao de um


decodificador, que um software que utiliza um LED detector de infravermelho ligado ao
Arduino, e o mesmo traduz os comandos presentes nos controles remotos e suas teclas. Cada
fabricante possui seu prprios cdigos e controles remotos, por isso a necessidade de decodificlos. Aps a identificao destes comandos um software foi implementado aliado aos LEDs
infravermelho ligados ao Arduino, possibilitando o envio de comandos semelhantes ao do controle
remoto. A Figura 20 representa um software para se comunicar com um Ar Condicionado.

Figura 19: Implementao com os cdigos decodificados e emisso de infravermelho


Fonte: Autor

56

4.2

CONTROLANDO O ARDUINO

Com a definio da plataforma de prottipo e os componentes, foi viabilizada uma forma para
que o usurio pudesse interagir com o Arduino, dizendo a ele o que realizar o que ligar, desligar,
ascender, apagar etc. Foi proposto, alm de automatizar a utilizao de utenslios domsticos, se
pudesse atender pessoas portadoras de necessidades especiais. Para isso, optou-se pelo recurso de
comando de voz, presentes nos smarthphones da atualidade.
Seguiu-se pela adoo do sistema operacional Android, justamente pelo mesmo ter
adicionado, a partir da verso 4.x, o recurso de comando de voz conhecido como Google Now.
Realizou-se o desenvolvimento de um aplicativo, representado na Figura 21, centralizando todos
utenslios e suas funcionalidades. O aplicativo permite ao usurio tanto remover utenslios e aes,
quanto adicionar novos, inclusive aliar o respectivo comando de voz, como visto na Figura 22.

Figura 21: Aplicativo instalado no dispositivo mvel.


Fonte: autor

Figura 20: Cadastro com possibilidade de aliar comando de voz


Fonte: Autor

57

4.3

O COMANDO DE VOZ DO ANDROID

O recurso de voz do Android, adicionado por meio do aplicativo Google Search, comumente
chamado de Google Now, surgiu a partir da verso 4.x do Android. A Google, desenvolvedora e
mantenedora do Android, revolucionou a forma de utilizar o sistema operacional, possibilitando
dizer ao sistema operacional o que fazer, e aliou tal recurso com o seu principal negcio, a pesquisa
na internet.
O Google Now responsvel por automatizar uma srie de recursos e aplicativos que antes s
eram acessveis via touch screen (toque na tela), podendo agora ser invocados por meio de voz.
Para utiliz-lo necessrio fazer uma chamada padro, o comando Ok Google, o aplicativo
reconhece o que voc diz ao aparelho e inicia o processo de escuta, na medida que o comando
ditado, o software transforma em texto, seguido de uma chamada a algum comando de recurso, ou
uma pesquisa.
A Google no disponibilizou este recurso para que aplicativos de terceiros utilizassem, e
nesse ponto que entra o framework chamado Xposed. O Xposed um framework, ou seja, um
conjunto de mdulos que podem mudar o comportamento do sistema operacional Android e seus
aplicativos, isso sem alterar nenhuma de suas configuraes. Como todas as alteraes so feitas em
memria, s necessrio ativar o mdulo e reiniciar o aparelho, caso desejar retomar o sistema
original de volta, basta realizar o processo inverso.
O mdulo Xposed utilizado no trabalho o Google Search API, este mdulo adiciona uma
API para o aplicativo. Isso permite que os desenvolvedores possam construir plugins que reagem s
buscas feitas no Google Search, e com isso h a possibilidade de utilizar o recurso de voz. O
aplicativo descrito na Figura 22 foi desenvolvido justamente utilizando esta API, tornando assim
um plugin do mdulo, como possvel ver na Figura 23.

Figura 22: Mdulo instalado no Xposed Framework e os seus plugins.


Fonte: Autor

O aplicativo desenvolvido, utiliza alm dos recursos do mdulo Google Search API, um
recurso chamado de BroadcastReceiver, esse presente no prprio Android. Sobre o sistema
operacional so executados diversos eventos e as aplicaes registradas para receberem uma

58

resposta referente a estes so avisadas, e podem responder a essas aes, isso feito por meio dos
BroadcastReceiver. Portanto aliando o mdulo e o recurso de BroadcastReceiver, o aplicativo
consegue capturar os comandos de voz, que so passados para o Google Search, transformando-os
em eventos direcionados e enviando enfim a requisio, aliada a tal comando de voz, para o servio
(Web Service). A Figura 24 exibe parte desse cdigo responsvel por escutar os eventos,
identific-los, e direcion-los ao servio.

Figura 23: Cdigo responsvel pela interpretao dos comandos de voz


Fonte: Autor

59

4.4

COMUNICANDO NA REDE

Com vasta rea de aplicao como controle industrial e automao residencial, o padro
ZigBee se difere de forma absolutamente distinta de outros padres utilizados no mesmo
seguimento. As vantagens do padro sustentaram o motivo de sua utilizao, dentre elas esto:
Consumo reduzido de energia;
Suporte, em uma mesma rede, de at 65535 ns por centralizador (XBee USB, Figura 25);
Suporte a diversas topologias de rede (malha, estrela, rvore etc.);
Recurso standby. Em caso da rede se tornar ociosa, o patro determina a hibernao dos
dispositivos (sleep), economizando energia;
Segurana com recurso de 128-bit de encriptao e elevada fiabilidade, resultando em baixa
ou quase nula perda de pacotes.

Figura 24: Xbee USB


Fonte: Autor

A comunicao realizada utilizando dois componentes ligados a um Arduino, um Xbee


Shield e um mdulo Xbee, representados na Figura 26, e isso torna o Arduino um n disponvel na
rede. A rede de dados seriais geralmente transmite seus dados a uma taxa de 9600 bps, e contm um
centralizador ligado a um computador via conexo USB, que recebe os dados seriais e os propaga
pelos ns da rede, o Arduino um com Xbee Shield acoplado recebe a informao e, se o cdigo
armazenado no seu microcontrolador reconhece tais dados, executa o fim proposto.

Figura 25: Shield Xbee acoplado ao Arduino


Fonte: Autor

60

O Xbee no se comunica com a Internet diretamente, por utilizar protocolos diferentes, isto
explica a necessidade de um Xbee USB ligado a um computador, que receber os comandos vindos
da internet ou rede local via WIFI ou Ethernet, e os enviar ao Xbee USB, que os propagar para os
Xbee Shields interconectados no sistema. Um dispositivo com Android pode enviar comandos a
esse computador, que se comporta como o servidor do sistema, via Internet utilizando um plano de
dados da operadora telefnica ou WIFI, ou via WIFI pela rede local, utilizando o endereo de IP
local do computador, caso ambos estejam conectados na mesma rede. Este ltimo caso dispensa
acesso internet, pois tanto o aparelho Android quanto o computador esto conectados mesma
LAN, o que um benefcio para momentos em que existe algum problema de conexo com a
Internet. Essa estrutura de comunicao representada na Figura 27.

Figura 26: Representao da estrutura de comunicao do sistema de automao


Fonte: Autor

4.5

A CONEXO ENTRE O ARDUINO E O ANDROID

Para que as solicitaes do usurio, realizadas no dispositivo mvel por meio do aplicativo,
sejam de fato recebidas pelo o Arduino, uma tecnologia chamada de Web Services, utilizando o
padro RestFul, foi utilizada para fazer esta intermediao. O servio implementado utilizando a
linguagem Java executado sob um servidor de aplicao chamado JBoss AS. Para que o Web
Service consiga enviar os dados seriais por meio do Xbee USB, foi necessria a utilizao de uma
API que auxilia o Java na leitura e escrita em portas seriais, o Web Service prov um caminho
(URL) para que o Android, por meio do aplicativo, envie as solicitaes ao servidor e esse processe
e envie rede.

61

Na Figura 20 a parte do cdigo descrita como Serial.read(9600); diz ao Arduino que fique em
modo de espera por esses dados, o comando Serial.read() fica responsvel por receber os dados
capturados, e o processa pelo bloco condicional que se segue. A Figura 27 mostra parte da
implementao do servio, responsvel por encaminhar o pedido rede.

Figura 27: Cdigo para o Shield XBee acoplado ao Arduino


Fonte: Autor

62

PARTE IV
5

CONSIDERAES FINAIS

O baixo custo e fcil acesso s tecnologias utilizadas nesse trabalho, bem como na
automao de uma forma geral, tem tornado essa rea uma realidade presente na sociedade, seja em
ambiente industrial ou residencial, sendo cada vez mais uma rea de interesse por estudantes e
profissionais. Esse fato contribui para o aumento de novos adeptos em busca de conhecimento e
desenvolvimento nesse setor. Dessa forma verifica-se que a automao residencial uma rea com
desafio de evoluir na proviso de interfaces amigveis, confortveis e flexveis de controle de uma
residncia, e como inovao a possibilidade de mobilidade desse sistema.
Inicialmente, buscou-se com este trabalho, combinar o uso de tecnologias mveis com
dispositivos de automao residencial pela internet. Ao longo do estudo da plataforma Android,
observou-se a possibilidade, com a utilizao da plataforma Xposed, de utilizar o recurso de
comando de voz para dar acessibilidade ao projeto. O uso de dispositivos mveis est cada vez mais
comum e tais dispositivos esto cada vez mais sofisticados, com mais recursos nativos.
A combinao de recursos de automao, dos dispositivos mveis e internet pode tornar
lares mais confortveis e seguros alm de contribuir para a acessibilidade em casas com pessoas
idosas ou portadoras de necessidades especiais. A garantia de acessibilidade automao
residencial, inserida nesse projeto por meio da possibilidade de envio de comandos por voz,
permitir a incluso da diversidade humana aos dispositivos e inovao tecnolgica, permitindo
que a sociedade evolua de forma igualitria.
Como demonstrado no sistema proposto, percebe-se que os avanos tecnolgicos tm
melhorado, seja intencionalmente ou no, a forma como os portadores de necessidades especiais,
pessoas idosas ou com dificuldades de locomoo interagem com o mundo. Porm tal facilidade
no s contribui para essa necessidade mas tambm para a possibilidade de integrao entre
diversos aparelhos de uma casa numa nica central de comando.
Por se tratar de tecnologias livres, os recursos utilizados por este trabalho propiciam
trabalhos futuros, podendo ser includas outras tecnologias assistivas ao projeto de automao
residencial, como a cmera frontal e o sensor de luminosidade, presente na maioria dos
smartphones e tablets modernos, e que podem ser combinados em pesquisas futuras para se
comportarem como sensores de movimentos e de iluminao do ambiente.
Conclui-se que a utilizao dos materiais descritos no trabalho, o Arduino e seus mdulos
adjacentes, um computador pessoal para servidor local, acesso Internet, um dispositivo mvel e os

63

aparelhos residenciais a serem automatizados, representam baixo custo de aquisio, portanto o


sistema proposto se torna vivel e de fcil acesso e implementao. O que aumentou o valor do
projeto foi, basicamente, o mdulo de comunicao sem fio do Arduino, visto que o custo dos
aparelhos da casa e do dispositivo mvel, seja smartphone ou tablet, so considerados custos
latentes ao projeto.
Como custos correntes tem-se a energia eltrica, para manter o sistema em funcionamento, o
servio de internet para manter a comunicao, e a manuteno dos aparelhos utilizados, incluindo a
necessidade eventual dos servios do Integrador de Sistemas Residenciais. Os dois primeiros so
custos que normalmente j se enquadram no oramento da maioria dos usurios, portanto mesmo a
manuteno do sistema de automao residencial entrando como novidade no oramento, o sistema
como um todo no prejudicar a vida financeira de quem o usufrui.

64

REFERNCIAS

ANDROID, Disponvel em <http://developer.android.com/guide/index.html>. Acesso em 01 de


outubro de 2015

ARDUINO, Disponvel em <https://www.arduino.cc/en/Guide>. Acesso em 26 de setembro de


2015.

BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML. So Paulo: Campus.
2002.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modeling Language user
guide. 2 ed. Pearson Education, Inc. 2005.

COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim; BLAIR, Gordon. Distributed


Systems: Concepts and Design. 5 edio. Pearson Education, Inc. 2012.

DIAS, Csar Luiz de Azevedo; PIZZOLATO, Nlio Domingues. Domtica: Aplicabilidade e


Sistemas de Automao Residencial. Revista Vrtices, Rio de Janeiro, v. 6, n. 3, 2004.

FARAHANI, Shahin. Zigbee Wireless Networks and Transceivers. Burlington, MA, 2008.

GUEDES, Gilleanes T. A. UML 2: uma abordagem prtica. 2 ed. So Paulo, 2011.

GUEDES, Lucas; ALVARENGA, Luiz; ROMANINI, Anicoli; MARTINS, Marcele Salles;


FOLLE, Daiane. O Papel Social Da Automao: Automao Inclusiva e Mais Sustentvel. Passo
Fundo, Rio Grande do Sul. 2012.

INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATSTICA - IBGE. Censo 2010: nmero de


catlicos cai e aumenta o de evanglicos, espritas e sem religio. Disponvel em:
<http://saladeimprensa.ibge.gov.br/noticias?view=noticia&idnoticia=2170>. Acesso em 28 de
setembro de 2015.

65

KAUR, Inderpreet. Microcontroller Based Home Automation System With Security. Mohali, India,
2010.

KUROSE, James F. Redes de computadores e a internet: uma abordagem top-down. 5 ed. So


Paulo: Person, 2010.

LECHETA, Ricardo R. Google Android: aprenda a criar aplicaes para dispositivos mveis com
o Android SDK. Novatec Editora 3 ed. So Paulo, 2013.

LEE, Wei-Meng. Beginning Android 4 Application Development. Indianapolis, 2012.

LEITTE, Jamielson da P.; SILVA, Leonardo O. da; MOREIRA, Marcos M.; SILVA, Roger R.
Automadroid: Automao Residencial com Dispositivos Mveis. Instituto de Estudos Superior da
Amaznia, Belm, Par, Brasil. 2013

LIMA, Luiz Eduardo Ruisch Horta; SILVA, Csar Alberto; JUBILEU, Andrea Padovan, RUIZ,
Linnyer Beatrys. Um sistema de Automao Residencial para Auxiliar Portadores de Necessidades
Especiais. Instituto Federal de Educao, Cincia e Tecnologia de So Paulo. Presidente Epitcio,
So Paulo, Brasil. Universidade Estadual de Maring, Paran, Brasil. 2014.

MCROBERTS, Michael. Beggining Arduino. Apress. Nova Iorque: 2010.

MONK, Simon. Programao com Arduino: Comeando com Sketches. Editora: AMGH. 2013.

MURATORI, Jos Roberto; DAL B, Paulo Henrique. Automao residencial: histrico,


definies e conceitos. Revista O setor Eltrico. 2011.

OXER, Jonathan; BLEMINGS, Hugh. Practical Arduino: cool projects for open source hardware.
New York: Apress, 2009.

PUPO, Deise Tallarico; Melo, Amanda Meincke; Ferrs, Sofia Prez. Acessibilidade: Discurso e
Prtica no Cotidiano das Bibliotecas. Campinas, SP: UNICAMP/Biblioteca. Central Cesar Lattes,
2006.

66

VOLLMER,

Robert.

Xposed

framework.

Disponvel

em

<https://github.com/rovo89/XposedBridge/wiki/Development-tutorial> Acessado em 02 de outubro


de 2015

Anda mungkin juga menyukai