ARQUI TETURA ORI ENTADA A SERVI ÇO APLI CADA NA AUTOMAÇÃO

Transcrição

1 UNI VERSI DADE DO PLANALTO CATARI NENSE CURS O DE SISTEMAS DE I NFORMAÇÃO ( BACHARELADO) MAURÍ CI O DA SI LVA COELHO ARQUI TETURA ORI ENTADA A SERVI ÇO APLI CADA NA AUTOMAÇÃO LAGES ( SC) ANO ( 2013)

2 MAURÍ CI O DA SI LVA COELHO ARQUI TETURA ORI ENTADA A SERVI ÇO APLI CADA NA AUTOMAÇÃO Trabal ho de Concl usão de Curso submeti do à Uni versi dade do Pl analto Cat ari nense para obtenção dos créditos de disci pli na co m nome equi val ente no curso de Siste mas de Infor mação - Bacharel ado. Ori ent ação: Pr of Hugo Esteva m Longo, Esp. LAGES ( SC) 2013

3 MAURÍ CI O DA SI LVA COELHO ARQUI TETURA ORI ENTADA A SERVI ÇO APLI CADA NA AUTOMAÇÃO ESTE RELATÓRI O, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI J ULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDI TOS DA DI SCI PLI NA DE TRABALHO DE CONCLUSÃO DE CURSO, DO 8º. SE MESTRE, OBRI GATÓRI A PARA OBTENÇÃO DO TÍ TULO DE: BACHAREL EM SISTE MAS DE I NFORMAÇÃO Lages (SC), 06 de Deze mbr o de 2012 Pr of. Hugo Esteva m R. Longo, Esp. Ori ent ador BANCA EXAMI NADORA: Pr of. Al exandre Rech, Esp. UNI PLAC Pr of. Crist hian Heck, M. Sc. UNI PLAC Cl ait on Ca mar go de Souza, Esp / Madal ena Pereira da Sil va, M. Sc Coordenador de Curso / Professor de TCC

4 Dedi co este trabal ho a mi nha fa mília, que e m mo ment o al gumdeixou de estar ao meu lado durant e toda a ca mi nhada, não medi ndo esforços para que eu pudesse al cançar meus obj eti vos.

5 Agr adeço aos meus a mi gos, seja m el es reais ou virt uais que esti vera m se mpre dispost os a me apoi ar, incenti var e descontrair. Agr adeço ao meu orientador Hugo Est eva m Ro meu Longo, pela paci ênci a e por se mpre apont ar as direções a sere msegui das. Agr adeço a mi nha fa mília, pel o incondi ci onal apoi o.

6 O sucesso é uma consequênci a e não um obj eti vo. ( Gust ave Fl aubert)

7 LI STA DE I LUSTRAÇÕES FI GURA 1 - Ar quitet ura descentralizada FI GURA 2 - Ar quitet ura centralizada FI GURA 3 - Ci cl o Scrum FI GURA 4 - Board Spri nt I FI GURA 5 - Pl ant a bai xa maquet e FI GURA 6 - Board Spri nt II FI GURA 7 - LEDs FI GURA 8 - Cabos FI GURA 9 - Requisição acender lâmpada FI GURA 10 - Lâ mpada conect ada ao PI N0 acesa FI GURA 11 - Requisição apagar lâ mpada FI GURA 12 - Lâ mpada conect ada ao PI N0 desli gada FI GURA 13 - Di agra ma de fl uxo API FI GURA 14 - Model o das classes do web server FI GURA 15 - Net dui no FI GURA 16 - Fase concepção FI GURA 17 - Mont age m FI GURA 18 - Ma quet e FI GURA 19 - Instalação LED FI GURA 20 - Estrut uração do proj et o no I DE Visual St udi o FI GURA 21 - Tel a gerenci a ment o web FI GURA 22 - Li gando LED na maquet e QUADRO 1 - Pr oduct Backl og da Aplicação QUADRO 2 - Hi st ória de usuári o macro Spri nt I QUADRO 3 - Hi st órias de usuári o Spri nt I QUADRO 4 - Hi st ória de usuári o macro Spri nt II QUADRO 5 - Hi st órias de usuári o Spri nt II QUADRO 6 - Hi st ória de usuári o magr o Spri nt III QUADRO 7 - Docu ment ação API QUADRO 8 - Tecnol ogi as utilizadas QUADRO 9 - Códi go mani pul ando LED QUADRO 10 - Requisição GET QUADRO 11 - Resposta GET... 63

8 QUADRO 12 - Requisição GET com parâ metro QUADRO 13 - Resposta GET com parâ metro QUADRO 14 - Requisição POST QUADRO 15 - Resposta POST QUADRO 16 - Represent ati va da classe Progra m QUADRO 17 - Represent ati va da classe OnCo mmand QUADRO 18 - Mét odos que busca ma referênci a e faze ma ação QUADRO 19 - Mét odo que espera de dados QUADRO 20 - Mét odo que i dentifica a solicitação QUADRO 21 - Mét odo processar solicitação POST QUADRO 22 - Represent ação JSON de umobj et o do tipo Pi nrecei vebody QUADRO 23 - Mét odo gerar resposta POST QUADRO 24 - Mét odo processar solicitação GET QUADRO 25 - Represent ação JSON de resposta GET... 70

9 LI STA DE ABREVI ATURAS E SI GLAS API HTTP JSON LED NET MF SOA SOAP UDDI UP WS DL WS-I XML - Interf ace de Progra mação de Aplicati vos - Hypertext Transfer Prot ocol - JavaScri pt Obj ect Notati on - Li ght Emmiti ng Di ode - Net Mi cro Frame work - Ar quitet ura Orient ada a Serviços - Si mpl e Obj ect Access Prot ocol - Uni versal Descri pti on Di scovery and Integrati on - Unified Process - Web Service Descri ption Language - Web Services Interoperability - Ext ensi ble Markup Language

10 RESUMO A hu mani dade busca cada vez mais segurança, comodi dade e sofisticação. Afalta de u ma ferra ment a que int egre diferent es apli cações, cri a uma l acuna no mer cado. À medi da que surge m novos dispositivos existe u ma dificul dade e mestender siste mas de aut omação. Assi msurge a necessi dade de i ntegração e m diferent es aplicações, sendo assi m, é indispensável u msoft ware específico per miti ndo a comuni cação i ndependent e do dispositi vo. A auto mação resi denci al pode ser vista cada vez mais e m casas e apart a ment os moder nos, per miti ndo a adoção generali zada da Int ernet das Coi sas. A medi da que as tecnol ogi as a madurece mestão abri ndo novas front eiras para a mel horia de processos, assi m per miti ndo mai or redução de desperdí ci os, custos de ener gi a e de intervenção humana. Do pont o de vista do consumi dor, a aut omação resi denci al é um diferenci al que irá se tornar uma oferta necessária. Uma das tendênci as mais fasci nant es hoj e é o surgi ment o de bai xo cust o de mi cro controladores, eles são a chave para a Internet das Coisas. Feliz ment e, al guns mi cro controladores agora são capazes de suportar platafor mas de soft ware moderno, isso per mite a utilização da mes ma linguage m de progra mação e a mbi ent e de desenvol vi ment o. Apresent a-se uma oferta diferenci al no mercado, que reforça as vant agens de i ntegração, disponi bilizando uma API onde faz-se possível a comuni cação com o mi cro controlador para aut omação resi denci al, utilizando os pri nci pais conceitos de domótica agregados aos servi ços personalizados, confiáveis, escaláveis e elásticos da Ar quitet ura Orient ada a Servi ço. Pal avras-chave: Do mótica, Net dui no, Mi cro controlador, Scrum, Automação.

11 ABSTRACT Ma nki nd seeks ever more safet y, comf ort and sophisticati on. The lack of a tool t hat integrates different applicati ons, creates a gap i n the mar ket. As new devi ces appear there is a difficult y i n ext endi ng aut omati on syste ms. Thus arises the need for i ntegrati on in different applicati ons, so it is essential specific soft ware all owi ng communi cati on devi ce i ndependent. The home aut omati on can be seen i ncreasi ngly i n moder n homes and apart ments, enabling t he wi despread adopti on of the Internet of Thi ngs. As mat ure technol ogi es are opening ne wfrontiers for process i mpr ove ment, thus all owi ng great er wast e reducti on, energy costs and human i nterventi on. Fromt he point of view of t he consumer, home aut omati on is a differential that will become a necessary suppl y. One of t he most fasci nati ng trends t oday is the e mergence of low-cost mi cro controllers, they are t he key t o the Internet of Thi ngs. Fort unat el y, some mi cro controllers are now capabl e of supporti ng modern soft ware platfor ms, it all ows you to use t he sa me pr ogra mmi ng language and devel opment environment. We present a suppl y gap i n t he mar ket, whi ch rei nforces t he advant ages of integrati on, provi di ng an API whi ch makes it possi ble to communi cat e wit h t he mi cro controller for home aut omati on, usi ng t he mai n concepts of aut omati on aggregat es personalized services, reliabl e, scal abl e and el astic Servi ce Orient ed Architect ure. Key words: Ho me Auto mati on, Net dui no, Mi cro controller, Scrum, Aut omati on.

12 SUMÁRI O 1 I NTRODUÇÃO Apresent ação Descrição do proble ma Justificati va Obj eti vo geral Obj eti vos específicos Met odol ogi a Cr onogra ma.... Erro! Indi cador não defi ni do. 2 FUNDAMENTAÇÃO TEÓRI CA Conceit o de domótica El e ment os Básicos Ti pos de Ar quitet ura Descentralizada Centralizada Internet das Coisas Concl usão MÉTODOLOGI A SOA - Ar quitet ura Ori ent ada a Serviço Benefíci o ao se i mpl ant ar SOA Pont os de atenção ao se i mpl ant ar SOA Pri ncí pi os de Desi gn de Servi ços Serviços reutilizáveis Serviços que compartilham um contrat o formal Serviços com bai xo acopl ament o Serviços que abstrae m a l ógi ca Reusabilidade Aut onomi a Independênci a de Est ado Visi bilidade Concl usão PROCESS O DE PLANEJ AMENTO DO PROJ ETO UTI LI ZANDO MÉTODO AGI L Mét odos ágeis de desenvol vi ment o de software O Processo de desenvol vi ment o comaplicação do Scrum

13 Product Owner Spri nt Backl og Product Backl og Hist óri a de usuári o Escopo do proj et o Iteração I Mont ar um ambi ent e de si mul ação resi denci al Iteração II Aut omatizar os element os básicos do ambi ent e de si mul ação Iteração III Cri ar API de comuni cação com o mi cro control ador Concl usão DESENVOLVI MENTO Introdução Tecnol ogi as utilizadas Mi cro Frame work Net dui no JSON Ferra ment as utilizadas Visual St udi o Team Foundati on Service I mpl e ment ação do siste ma Iteração I Mont ar um ambi ent e de si mul ação Iteração II - Aut omatizar os element os básicos do ambi ent e de si mul ação Iteração III - Cri ar API de comuni cação com o mi cro control ador Apresent ação do siste ma Concl usão CONSI DERAÇÕES FI NAIS REFERÊNCI AS BI BLI OGRÁFI CAS... 75

14 18 1 I NTRODUÇÃO 1. 1 Apresentação Este trabal ho de conclusão de curso aborda o uso de um padrão de desi gn aplicado na aut omação de mi cro controladores, levando e mconsi deração que este ti po de siste ma te m como pri nci pal função garantir a integração de di versos ti pos de infor mações e serviços. A Tecnol ogi a disse mi nou-se a tal pont o que hoj e está ao alcance de todos, é difícil citar umra mo ao qual a infor mática não está present e: da medici na, engenhari a, escol as, entre outros. O ho me m busca cada vez mais a segurança, co modi dade e sofisticação, com o auxílio dos comput adores e siste mas i nteligent es, trazendo assi m a tecnol ogi a para seus lares como font e contí nua de vi gília e confort o dos afazeres domésticos. A base para o trabal ho foi a busca por uma sol ução que atendesse a al guns requisitos adici onais verificados ao longo do pr oj et o com uma pl atafor ma e mbarcada, e m um mi cro controlador. A Ar quitet ura Orient ada a Servi ço (SOA) na aut omação foi usado para reagir rapi da ment e a mudanças, resol ver tecni ca mente probl e mas de mudanças na i ntegração, facilitar o desenvol viment o de novas aplicações, di mi nui ndo o cust o e o esforço de desenvol vi ment o dando suporte as crescent es e di versificadas de mandas por novos ti pos de aplicações. Segundo BELL (2011), ao contrári o do desenvol vi ment o dos siste mas tradi ci onais, a met odologi a do serviço-orient ado ao cicl o de vi da facilita os processos de desenvol vi ment o e das operações do serviço ao fornecer os padrões e as mel hores

15 19 práticas que se adapta m às tecnol ogi as e mergent es da i ndústria da arquitet ura do servi ço-orient ado. Al é m deste capít ul o de apresent ação, o trabalho está di vi di do e m mai s três capít ul os. O capít ul o dois aborda a funda ment ação teórica; o capítul o três trata da met odol ogi a utilizada; o capít ul o quatro o processo de planej ament o do proj et o utilizando mét odo ágil; e o capit ul o ci nco o desenvol vi ment o e apresent ação do siste ma e capit ul o seis as considerações fi nais Descri ção do probl e ma A aut omação resi dencial está cada dia facilitando mais a vi da dos moradores. Co m essa de manda sur ge à necessi dade de ter uma arquitet ura de i ntegração para di versos serviços expost os e m diferent es aplicações, sendo assi m, é indispensável que todos os serviços sejam criados com um mét odo de desenvol vi ment o de soft ware específico, per miti ndo que diferent es aplicações troque m dados independent es do siste ma operaci onal ou linguage m de progra mação utilizada para sua i mpl e ment ação Justificati va Co m a chegada de novas tecnol ogi as a nosso alcance uma ga ma de possi bilidades práticas e econô mi cas que utiliza m a aut omação, desde a básica at é a mai s abrangent e. O resultado é um a mbi ente prático, confortável, agradável, mais bonit o, val orizado e segur o, de acordo com o interesse do usuári o. A i ndústria de construção ci vil é umi mportante set or da econo mi a brasileira, e m especi al o ra mo i mobiliári o, o qual cont empl a e mpresas e prestadores de servi ços ligados à comercialização de i móveis. Segui ndo a forte tendênci a de casas inteli gent es, a aut omação resi dencial pode ser vista cada vez mais emcasas e aparta mentos modernos. Seja através da i ntegração entre áudi o e ví deo, medi das de segurança ou opções que preza m pel o conf ort o ( TECMUNDO, 2011).

16 20 Do pont o de vista do consumi dor, a aut omação resi denci al é um diferenci al que irá se tornar uma oferta necessária. Cada vez mais o mercado vai exi gir que os i móveis possua mtecnologi a. Apesar de ser umsi nal de stat us, a aut omação resi denci al está cada vez mais disponí vel às pessoas co muns que tenha m algum di nheiro sobrando e busque m u ma casa i nteli gent e e tecnologi ca ment e pront a para morar ( TECMUNDO, 2011). Sendo assi m, coma plat afor ma eletrôni ca Netdui no, segundo Wal ker (2012), hobbistas e progra madores pode m criar projet os de eletrôni ca com facilidade, esse fra me wor k de programação da Mi crosoft é fácil de ser utilizado, o. NET Mi cr o Fra me wor k fornece um conj unt o i ncri vel ment e poderoso de recursos, tornando muit o fácil o surgi ment o de projet os de aut omação resi denci al. Sur ge ent ão, a carência de uma ferra ment a que i ntegre di versos servi ços e m diferent es aplicações no mercado. Os serviços que existe mat ual mente li mita m-se para u ma det er mi nada função. À medi da que surge novos dispositi vos existe uma dificul dade e m modificar ou estender siste mas de aut omação resi denci al. Faz-se i mpresci ndí vel, uma abordage m de arquitet ura para a concepção de siste mas criados a partir de serviços aut ôno mos, apont ada a SOA, com el a a i ntegração é uma previsão. Pr opõe-se, portant o, o desenvol vi ment o de uma API orientada a servi ço, o qual represent a uma i novação na for ma de i ntegrar diferent es sist emas e mrelação às alternati vas at uais. Com a utilização dele, pode ser consumi do por diferent es aplicações havendo i nteroperabilidade entre platafor mas Obj eti vo geral O obj eti vo geral é desenvol ver uma API orientada a serviço para auto mação resi denci al via Net dui no.

17 Obj eti vos específicos Os obj eti vos específicos do present e trabal ho são: a) Realizar umlevant a ment o sobre o hardware open-source Net dui no. b) Cri ar uma API orientada a serviço para integração comsiste mas ext ernos. c) Aut omatizar luzes de uma maquet e Met odol ogi a O passo i nicial foi a concretização de umlevant a ment o bi bli ográfico sobre os temas associ ados à pesquisa, que servi u de base para a elaboração do projet o. Levando e mconsi deração o est udo das met odol ogi as e técni cas utilizadas no desenvol vi ment o de um siste ma de aut omação, fez-se necessári o, através da leit ura de arti gos, livros, entre outros document os que abor da m o te ma. Após a fase de est udo do te ma propost o a respeit o dos assunt os tratados nesse trabal ho, como SOA: análise, desi gn e arquitetura de serviços, pri meiros passos com o Net dui no. Esse levanta ment o deu subsí di os para escrever o projeto do Trabal ho de Concl usão de Curso (TCC), be m como defi nir os recursos que as aplicações disponi biliza me as tecnol ogi as necessárias para sua i mpl e ment ação. Funda ment ado nessas font es foi possí vel dar abert ura ao processo de model age m e construção da aplicação. De tal maneira, foi empregado o mét odo ágil SCRUM. Das iterações deste processo, result ou o quart o capít ul o da pesquisa. Por fi m, durant e este perí odo foi realizado o det al ha ment o do sistema, be m co mo a i mpl e ment ação. Foi ent ão constituí dos testes como produt o final desenvol vi do, para que se pudesse deter mi nar os resultados adquiri dos no proj et o e enfi m, redi gir as consi derações fi nais do trabal ho.

18 22 2 FUNDAMENTAÇÃO TEÓRI CA Nest e capít ul o são apresent ados os assunt os para a mel hor compr eensão da especificação e i mpl e ment ação do projet o, será apresent ado o te ma domóti ca j unt a ment e co msuas pri nci pais caract erísticas Conceito de do móti ca A pal avra Do mótica é a junção da palavra lati na Do mus (casa) e do ter mo Robótica. Osi gnificado está relaci onado à instalação de tecnol ogi a em resi dênci as, com o obj eti vo de mel horar a quali dade de vi da e o uso raci onal dos recursos para seus habitantes. Segundo Bol zani (2004), a domótica pode ser defi ni da como um conjunt o de tecnol ogi as que aj udam na gestão e execução de tarefas domésticas coti dianas. A sua utilização te m por obj etivo fornecer um mai or confort o, comodi dade, segurança, alé m de proporci onar menor e mais raci onal consumo energético. Quando a domótica surgi u, nos anos 80, pretendi a-se controlar a ilumi nação, condi ções cli máticas e a i nterligação entre os pri nci pais ele ment os. At ual ment e, a i dei a base é a mes ma, o diferenci al é o cont ext o para o qual o siste ma é proj etado: não um cont ext o militar ou i ndustrial, mas doméstico. Defi ne-se ent ão que a Do mótica é uma tecnologi a que per mit e a gestão de todos os recursos habitaci onais si mplificando a vi da diária das pessoas e satisfazendo as suas necessi dades. É o uso da tecnol ogi a para facilitar e tornar auto máticas al gumas tarefas habit uais que em u ma casa convenci onal ficaria a cargo de seus moradores. Co m sensores de presença, te mporizadores ou até um si mpl es t oque e m um bot ão é possí vel aci onar cenas ou tarefas pré-progra madas. A do mótica utiliza vários ele ment os, que normal ment e são i ndependent es, de

19 23 u ma for ma sistê mi ca. At ual ment e umsiste ma domótico é di vi do e mvári os subsiste mas, cada qual at ua especifica ment e e mumca mpo de controle segui ndo sua arquitet ura. Uma das mai ores aplicações da domótica é pr ot eger as pessoas e bens e m diferent es situações que pode macont ecer nas habitações. Aconcepção dos siste mas de segurança no â mbit o da aut omação resi dencial se confi gura na i mple ment ação de um monit ora ment o e vi gilânci a eletrôni ca no a mbi ent e. Co misso, obj eti va-se proporci onar segurança e conveni ênci a à resi dênci a e seus mor adores. Entre os grandes atrati vos da aut omatização, o grande destaque é o confort o, at ual ment e é um dos pri nci pais fat ores na construção ou compra de uma resi dênci a El e ment os Bási cos Em qual quer aut omação existe m ele ment os envol vi dos como sensores e centrais que supre m desej os e condi ções de cada usuári o. Dificil mente se encontrará a dó motica se mal gumdos el e ment os: at uadores, barra ment os, controladores, interfaces e sensores descritos a seguir. At uadores são dispositivos eletromecâni cos, que recebe m os comandos do siste ma de aut omação e ati va m os equi pa ment os aut omatizados. São os módul os de aci ona ment o ligados entre a rede elétrica e os equi pa ment os ( ALMEI DA, 2009). O Barra ment o é o meio físico responsável pel o transporte das infor mações (rede elétrica, telefôni ca etc.) ( CASADOMO, 2010). Controladores controla m os dispositivos aut omatizados (sensores e at uadores). Monit ora as i nfor mações dos sensores, podendo envi ar co mandos para que u m at uador ati ve ou desati ve al gum equi pament o. De maneira geral pode m possuir interfaces independentes, na for ma de um controle re mot o, ou sere m sofisticadas centrais de aut omação ( ALMEI DA, 2009). Interfaces são os dispositivos ou mecanis mos (navegador de i nternet, cel ul ar, pai néis, controles re mot os, interrupt ores etc.) que per mite m ao usuári o visualizar as infor mações e interagir como siste ma de aut omação ( CASADOMO, 2010). Os Sensores são os dispositivos que detecta mestí mul os, mede me monit ora m

20 24 grandezas físicas e event os (te mperat ura, umi dades etc.), convertendo-as e m um val or passí vel de mani pul ação por siste mas comput aci onais. São eles que enca mi nha m as infor mações aos control adores sobre al gum event o, para que estes possa m envi ar os co mandos adequados para os at uadores ( ALMEI DA, 2009) Ti pos de Arquitet ura A arquitet ura está relaci onada na for ma de co muni cação de seus ele ment os básicos, como qual quer siste ma de controle, especifica a for ma que vão se l ocalizar. Em umsiste ma domótico existe mduas arquitet uras básicas, descentralizada e centralizada Descentralizada Na arquitet ura descentralizada apresent ada na Fi gura 1, existe m vári os controladores interconect ados por umbarra ment o, que faz comuni cação entre at uadores e i nterfaces. FI GURA 1 - Ar quitet ura descentralizada. FONTE: (PRÓPRI O AUTOR, 2013). A vant age m dessa arquitet ura é um siste ma robust o a fal has com grande facilidade de uso e fácil desenho das i nstalações. Poré mpode haver uma má relação do pont o control ado e m relação ao cust o de int egração mais elevado e m função de tecnol ogi as e mpregadas Centralizada

21 25 Nest a arquitet ura existe um controlador central que trans mit e informações para ele ment os básicos. Este deve ser dot ado de i nteli gênci a e desempenho suficient e para receber e tratar as i nfor mações. Na Figura 2 é possí vel observar arquitet ura centralizada. FI GURA 2 - Ar quitet ura centralizada. FONTE: (PRÓPRI O AUTOR, 2013). A pri nci pal vant age m desta arquitet ura é aquisição com o menor cust o. Entretant o a centralização de funções e a grande quanti dade de cabea ment o não corresponde mà filosofia dos siste mas domóticos Internet das Coisas Essa é uma área que tem si do a responsável por col ocar dispositivos na Internet. Basica ment e, são obj et os interagi ndo com outros obj et os, ou com seres hu manos, via Internet. Para isso é necessári o que eles tenha m al guma capaci dade de interação, seja ativa por mei o de sensores e controladores, ou passi va como cart ões de reconheci ment o e interação. Um dos pri nci pais exe mpl os é o uso do mi cro control ador Net dui no, por profissi onais se m profundos conheci ment os de eletrônica, para construir

22 26 os mais di versos obj et os i nteli gent es. Mai s obj et os estão adquiri ndo a capaci dade de se comuni car resultando e m u ma rede de coisas que promet e m mel horar pr ocessos de negóci os, reduzir cust os e riscos. O mundo físico está se tornando umtipo de siste ma de i nformação, e m que é cha mado a Internet das Coisas, sensores atuadores e mbuti dos em obj et os físicos conect ados à i nternet despej ando um enor me vol ume de dados para comput adores pr ocessare m. A adoção generalizada da Internet das Coisas está a avançar, junt a ment e com tecnol ogi as e a padronização de prot ocol os de comuni cação t ornando possí vel col etar dados desses sensores e m qual quer lugar a qual quer mo ment o. A medi da que as tecnologi as a madurece mestão abri ndo novas front eiras para a mel horia de processos, assi m per miti ndo mai or redução de desperdí ci os, cust os de energi a e de i ntervenção humana. Segundo Pfister (2011), uma das tendências mais fasci nant es hoj e é o surgi ment o de bai xo cust o de mi cro controladores, que são suficientement e poder osos para se conect ar à internet. El es são a chave para a Internet das Coisas, di versos ti pos de dispositivos são disponi bilizados para o mundo físico. Tradi cional ment e, para dispositivos e mbarcados era mnecessári os emdiferent es platafor mas e ferra ment as para sua progra mação. Felizment e, al guns mi cros controladores agora são capazes de suportar platafor mas de soft ware moderno, isso per mite que você use a mes ma linguage m de progra mação e o mes mo a mbi ent e de desenvol vi mento Concl usão Fora m apresent ados nesse segundo capít ul o, o conceit o de Do mót ica e os el e ment os básicos para a i mpl ant ação de recursos aut omatizados. Por fi m, mostrou-se u mapanhado sobre i nternet das coisas. Est e capít ul o mostrou-se de vital i mportânci a para o fut uro desenvolvi ment o do present e trabal ho, pois a partir dele, tornou-se possí vel conhecer a grande mai oria dos requisit os para dar iníci o a construção do pr oj et o que se busca a concl usão deste.

23 27 3 MÉTODOLOGI A Nest e capít ul o são apresent ados a met odol ogi a do processo de elaboração conti dos no relat óri o do trabal ho de concl usão de curso SOA - Arquitet ura Ori entada a Servi ço Al guns equi pa ment os para aut omação são i nstalados, co mo que al eat oria ment e, i mpulsi onados pela onda mer cadol ógi ca do mo ment o e acaba m resol vendo al guns probl e mas l ocalizados, mas se m nenhu ma i ntegração entre si. Ist o acaba resultando e mfrustrações para os usuários, que acaba mconvi vendo comsiste mas aut ôno mos e muitas vezes de difícil operaci onali dade. O conceit o do SOA, de i ntegração, já existe há muit o te mpo, mas agora ele vei o à tona devi do à necessi dade e mer genci al de i ntegração das tecnol ogi as at uais. O SOA é uma met odol ogia que visa maxi mi zar a reutilização de serviços existent es e a integração com novos serviços para aumentar a eficiênci a e produti vi dade de uma e mpresa. SOA é um model o de arquitet ura voltado ao desenvol vi ment o de sol uções co mput aci onais. Dentro desta met odol ogia, funci onali dades de negóci o são i mpl e ment adas por estrut uras conheci das como serviços, sendo que esta abor dage m possui como um de seus pri nci pais obj eti vos, per mitir a integração entre siste mas construí dos nas mais diversas platafor mas ( DEVMEDI A, 2011). Segundo Nogueira (2012), projetar component es reutilizáveis não é al go tão si mpl es, é preciso realizar umest udo cui dadoso do projet o para assegurar o uso eficient e de recursos de rede e mi ni mi zar as dependênci as entre os serviços e as aplicações que os usa m. É pratica ment e cert o que e m det er mi nado mo ment o, se fará necessári o o

24 28 estabel eci ment o de algu m mei o de i ntegração entre diferent es sistemas, quer seja interna ment e dentro de uma organi zação, ou ainda, entre aplicações da mes ma Benefíci o ao se i mpl ant ar SOA Pode m ser enumerados al guns dos pri nci pais benefíci os da i mpl antação de sol uções orientadas a servi ços: A possi bli dade de integração (i nteroperabili dade) entre siste mas desenvol vi dos nas mais diferent es platafor mas. Uma mel hor compreensão, assi m como uma mai or organi zação dos pr ocessos de negóci o de uma organi zação, graças à ênfase na análise e na model age m da sol ução a ser construí da. O reuso de funci onalidades criadas ant eri orment e, através do uso de servi ços quando da i mpl e ment ação de novas sol uções de soft ware. Redução de te mpo e cust os e mnovos projet os, graças ao foco no reuso de funci onali dades criadas anteri or ment e. É i mportant e ressaltar que alcançar as vant agens envol ve umtrabalho árduo de análise, model age me desenvol vi ment o de soft ware Pont os de atenção ao se i mpl ant ar SOA Al guns aspect os devem ser analisados cui dadosa ment e ao se opt ar por esta arquitet ura e mproj et os de soft ware, esses aspect os são: Deve-se cont ar com u ma equi pe capacitada e fa miliarizada com os conceit os de orientação a serviços. Mudanças drásticas no contrat o de um serviço pode m prej udi car a operação nor mal de aplicações que consuma m o mes mo. Pel o fat o de serviços envol vere ma trans mi ssão de dados a partir de redes, a segurança é um pont o que se mpre irá requerer atenção especi al, sobret udo quando envolver a mani pul ação de inf or mações confi denciais.

25 Pri ncí pi os de Desi gn de Servi ços Exi ste mpri ncí pi os de desi gn de serviços que são úteis para defi nir o ambi ent e teórico no qual a SOA deve ser i mpl e ment ada. Aseguir pri ncí pi os básicos de SOA Serviços reutilizáveis É aquel e que não cont émt écni cas de uma i mple ment ação ou regra de negóci o específica e é genérico o suficient e para atender projet os. O aspect o positivo de um servi ço reutilizável abrange di versos cenári os de uso por consistir e muma l ógi ca mais genérica. Isso é mais si mpl es quando a construção dos servi ços é feita de for ma corporati va. Al gu mas dificul dades pode m ser encontradas segundo Josuttis (2008), descreve que a criação de umserviço de caráter reutilizável necessita de mai or esforço já que a sua necessi dade só surge quando os usuári os do serviço se depara mcomel a e, al é m disso, a i mpl ant ação e os testes são tarefas não-tri viais a serem execut adas por tere m uma especificação abrangent e. As modificações e m um serviço tende m a afetar di versas áreas de negóci os, o que pode ser um e mpecil ho, já que não é possí vel indisponi bilizar o acesso ao client e, para que as alterações que o transfor me me mservi ço generalizado seja mfeitas Serviços que compartilham um contrat o f or mal Contrat os são docu mentos que especifica mo funci ona ment o do serviço. Al guns padrões como Web Servi ce Descri pti on Language ( WSDL), Si mpl e Obj ect Access Prot ocol (SOAP) e Uni versal Descri pti on Di scovery and Integrati on ( UDDI ) são utilizados diaria ment e. O padrão SOAP é utilizado pel os Web Services e é responsável por defi nir o model o da troca de mensagens. Para isso utiliza umarqui vo XML que defi ne envel opes e os nós i nter medi ári os da comuni cação (J OSUTTI S, 2008). O padrão WSDL é responsável por identificar o prot ocol o e o endereço no qual

26 30 u mservi ço está publicado, assi mcomo seus parâ metros de entrada e saí da (J OSUTTI S, 2008). O padrão UDDI permi t e que os serviços seja m categori zados, poré m se m fornecer uma ri queza de text os para que buscas por umserviço específico seja mfeitas (J OSUTTI S, 2008). Os contrat os são capazes de traduzir as funci onali dades dos servi ços especificados para que client es possa m mani pul a-l os confor me a necessi dade. Segundo J OSUTTI S (2008), para que t odos os det al hes de i mpl e ment ação de um ser vi ço sej a m especificados, são necessári os di versos padr ões de contrat os a sere m utilizados por toda a cor poração. Isso pode se tornar uma tarefa compl exa caso haj a a necessi dade de mi gração de document os (já criados) para o conjunt o de padr ões escol hi dos Serviços com bai xo acopl ament o O bai xo acopl a ment o de um servi ço deve-se a capaci dade de ser independent e para realizar a sua tarefa. Portant o é funda mental que umserviço tenha alta coesão, ou seja, ativi dade be m defini da e coerent e. A i nteroperabilidade per mite que siste mas com arquitet uras diferentes troque m infor mações e acesse os servi ços de for ma transparent e. Co m esse i nt uit o, al guns padrões fora mcriados pel a WS-I para as interfaces dos serviços. Segundo Josuttis (2008), os a mbi ent es de desenvol vi ment o são cada vez mais het erogêneos. Muitas tecnol ogi as são utilizadas paralela ment e e isso não deve infl uenci ar na utilização dos serviços, que são tratados pela i mpl e ment ação de maneira idêntica. A adoção de u ma boa prática de desacopl a ment o faz com que as estrut uras respeite m um padrão utilizado dentro do ambi ent e corporati vo, o desacopl a ment o au ment a o pot enci al de reuso do conj unt o de servi ços. Entretant o existe m algumas dificul dades co mo i dentificar os pont os de acopl a ment o pot enci alment e eli mi náveis e criar serviços t otal ment e desacopl ados de qual quer estrut ura, já que não existe mpadrões defi ni dos para deter mi nadas sol uções.

27 Serviços que abstrae ma l ógi ca Mudanças pode m ocorrer a qual quer mo ment o, se m afetar aqueles que o consome m. Essa abstração deve existir na linguage m utilizada e na tecnol ogi a, ou sej a, os serviços deve mtratar todas as linguagens e tecnol ogi as que o conso me m da mes ma for ma, ignorando distinções. O conceit o de abstração dentro da orientação a serviços é deri vado de outro pri ncí pi o muit o conheci do na área de desenvol vi ment o de soft ware: a ocultação de infor mações. Oobj eti vo da abstração é disponibilizar aos consumi dores de umservi ço, apenas o que é essenci al no uso do mes mo, comist o acont ecendo no contrat o que defi ne o component e. Det al hes específicos relati vos à i nfraestrut ura e mpregada são ocultados das aplicações-clientes, com o servi ço funci onando como uma cai xa-pret a ( DEVMEDI A, 2011). Esse pri ncí pi o é diaria ment e aplicado, não possui dificul dades e m sua i mpl e ment ação, per mite que agent es humanos interaja m com sistemas compl exos de for ma fácil, já que a suas i nterfaces são de si mpl es entendi ment o. A dificul dade existe nas linguagens mais antigas, como Cobol. Ofato de sere m menos compl exas poder exi gir cert o esforço para converter os dados de modo a dei xar as cha madas transparentes a qual quer consumi dor Reusabili dade O model o SOA dá uma grande ênfase ao reuso de component es de soft ware. O reaproveita ment o de funci onali dades construídas anteri or ment e pode, via de regra, traduzir-se e m um mai or ret orno sobre o investi ment o i nicial foi e mpregado na concepção das mes mas. Al é m di sso, novas sol uções pode m ser desenvol vi das co m mai or agilidade, consu mi ndo recursos já impl e ment ados ant eri orment e, be m co mo econo mi zando te mpo e recursos que seria mempr egados e mtais projet os. A reusabilidade te ma característica de os servi ços sere mcapazes de se compor, consiste e mcriar serviços que seja mcapazes de se junt ar e sere macessados de for ma a engl obar e atender umpr obl e ma mai or.

28 32 Quando existe à troca de mensagens entre umconj unt o de serviços a co mposi ção pode ser pri miti va e co mpl exa quando um conj unt o oferece uma sol ução l ógi ca sofisticada, ou seja, várias trocas de mensagens entre umconj unt o que são execut ados paralela ment e. Para Josuttis (2008), o pri ncí pi o de di vi dir para conquistar é muit o conheci do há anos e te mcomo pri ncipal obj eti vo si mplificar os probl e mas encontrados no dia-a-di a. Co m possi bilidade de criar composi ções de servi ços, eles torna m-se capazes de resol ver grandes probl e mas com a compl exi dade de um si mpl es serviço. A conversação entre os serviços pode ser co mpl exa e o pri ncí pio de bai xo acopl a ment o não deve ser desrespeitado. Os servi ços deve m trocar infor mações para tornare m-se mais complet os, e não i nterdependent es Aut onomi a A i dei a por trás do princí pi o de aut ono mi a está relaci onada, funda ment al ment e, a quão independent e um servi ço é de i nfl uênci as externas quando a lógica i nerent e ao mes mo é execut ada. Como u mserviço aut ônomo capaz de aut ogovernar-se. Uma mai or aut ono mi a se traduz no aument o da confiabilidade de um serviço, assi m co mo nu ma mai or previsi bilidade do comporta ment o deste. Cont udo, ne mt odos os tipos de serviço contarão com graus mais elevados de aut ono mi a. Existe m dois tipos pri nci pais de aut ono mi a que pode m est ar associ ados a servi ços. Aut ono mi a e m run-time que represent a, em t er mos gerais, o nível de controle que umservi ço possui sobre o seu ambi ent e de execução. Logo, dentro desta classificação estão cont e mpl ados aspect os como possí veis dependênci as do serviço para com outros component es de soft ware, al é m de outras quest ões co mo segurança, desempenho, previsi bili dade e confiabilidade. Aut ono mi a na etapa de desi gn está ligada às dependênci as que se estabel ece mentre umservi ço e seus consumi dores. Neste caso, o grau de aut ono mi a do serviço consi derado deter mi nará se este poderá ou não

29 33 modificar suas defi nições de contrat o, alterar o a mbi ent e de hospedage m utilizando, opt ar pela substituição de recursos e mpregados, ou mes mo introduzir o uso de novas tecnol ogi as Independênci a de Est ado Um siste ma é dit o escal ável quando é capaz de se adequar a uma de manda crescent e no seu uso, se m que com ist o deixe de corresponder ao que se esperava inicial ment e do mes mo ( DEVMEDI A, 2011). O conceit o de estado refere-se à manut enção de infor mações compartil hadas entre uma aplicação-client e e o servi ço do qual está depende, com ist o acont ecendo durant e umperí odo de te mpo que engl oba di versas trocas de mensagens entre estes dois el e ment os. Ma nt er ou não dados rel ati vos a estados e m me móri a dependerá sempr e do cont ext o e das pre mi ssas esperadas para um det er mi nado serviço. O pri ncí pi o da independênci a de estado procura oferecer alternati vas para maxi mi zar a escal abili dade de um servi ço, delegando a outros mei os o gerenci a ment o te mporári o de al gu mas infor mações. Em di versos bancos de dados é comu m ser e mpregado mecanis mos para o controle de i nfor mações de estado, obt endo o gerenci a ment o de dados de estado oti mi zado. Obenefíci o advi ndo de umcontrol e de estado eficaz está na possi bili dade de se aument ar o pot enci al de reuso de umservi ço Vi si bilidade O conceit o de visi bilidade diz respeit o à capacidade umserviço ser descobert o, e a partir dist o, ter as inf or mações que defi nem sua estrut ura interpret ada por pot enci as utilizadores do mes mo. Tais infor mações envol ve m ele ment os do contrat o do servi ço que se está consi derando, assi m como outros itens de met adados que esti pul a m o co mporta ment o das di versas operações disponibilizadas. Para que a descoberta tor ne-se possí vel, foi empr egada a especificação UDDI,

30 34 a qual represent a umpadrão para registro de localização de Web Servi ces. A fi nali dade do pri ncí pio de visi bilidade está em f ornecer um mecanismo que per mit a que umser vi ço sej a encontrado, e uma vez caract erísticas i nt erpret adas. Buscase comisso deter mi nar se o serviço atende a uma det er mi nada necessi dade, para e m caso afir mati vo, prosseguir coma utilização do mes mo e muma aplicação-cliente Concl usão Co mo te ma abordado neste terceiro capít ul o, destaca-se a apresentação do conceit o de SOA que visa maxi mi zar a reutilização de serviços existent es. Ta mbé m se de monstra i mportant e os benefíci os que se obtémao i mpl ant ar uma sol ução orient ada a servi ço. Tal paradi gma vei o a direci onar o processo de desenvol vi ment o, somando aos conheci ment os adquiridos acerca da SOA, u ma vez que o fat o de conhecê-la é indispensável quando se deseja i mpl e ment ar este tipo de siste ma de inf or mação.

31 35 4 PROCESS O DE PLANEJ AMENTO DO PROJ ETO UTI LI ZANDO MÉTODO AGI L Est e capít ul o, consisti emconceit os que aborda a model age m ágil sobre o pr ocesso de desenvolvi ment o de soft ware empregando Scrum. Em segui da, é de monstrada a etapa de planej a ment o Mét odos ágeis de desenvol vi ment o de soft ware Segundo Ambl er (2004), as organi zações não estão cient e que o soft ware deve inicial ment e, atender ao usuári o, sendo concebido se mpre de modo eficaz. Emvez disso, na mai or parte das ocorrênci as, é construí do com o menor envol vi mento do client e. Al é m disso, a adoção de procedi ment os prescritivos de desenvolvi ment o, ligado ao conj unt o de ati vi dades pré-defi ni das, provoca o acumul o de docu ment ação, frequent e ment e desnecessária. Processo Unificado é umexe mpl o deste mét odo. Sendo assi m, consiste e m ati vi dades estrut uradas que são execut adas para a alteração do conj unt o de requisitos do cliente no siste ma. Faz uso extensi vo da UML e temcomo fi nali dade fornecer aos envol vi dos em u mprocesso de desenvol vi ment o, uma visão do siste ma, citando sua estrut ura e comporta ment o de modo geral. Empregado co m a fi nali dade de construir o soft ware e docu ment ar as deter mi nações durant e o pr ocesso (SCOTT, 2003). Di versa ment e dos padrões, o mét odo de Model age m Ágil não det er mi na pr ocedi ment os det al hados da maneira que se deve criar cert o modelo. Em vez disso, pr ovê recomendações de como trabal har de modo eficient e, abonando enfoque na co muni cação verbal e social entre os me mbros da equi pe. De acordo com Ambl er, (2004): A Model age m Ágil (MA) é uma met odologi a baseada na prática para

32 36 model age me documentação eficazes de sistemas baseados e msoft ware. A met odol ogi a MA é um conj unt o de práticas gui ado por pri ncí pi os e val ores para profissi onais de soft ware aplicare me mseu dia-a-dia. De acordo com Ambl er (2004), a conj unt ura at ual do desenvol viment o de soft ware se encontra abai xo do i deal. De moras na entrega, probl e mas de orça ment o e insucesso na produção do siste ma, são eni gmas not óri os na área de desenvol vi ment o de soft ware quant o pel os clientes que frequente ment e encontra m-se descont ent es, uma ocasião que rara ment e têmsuas necessi dades at endi das com o que l he é ofereci do. Marti n (2011) cita os pri ncí pi os e val ores consoli dados no Manifest o da Ali ança Ágil ( BECK, et al, 2001), que admi t e m ant eci par o desenvol vi ment o de soft ware e rapi dez na resposta de alterações, que distingue ma val orização de pessoas e iterações alé m de métodos e ferra ment as, soft ware e m funci onament o mai s que docu ment ação abrangent e. Invol unt aria ment e, encontrar-se trabal hando especifica ment e comsoft ware ou mes mo realizando uma ocupação qual quer, necessita-se de determi nado ní vel de pr ocesso. De acordo co m Ast els (2002), metodol ogi as são i mportant es para aquel es ca mpos quais umconj unt o be mdefi ni do de ativi dades nos levará até nosso obj eti vo. Cont udo, é evi dent e que existe mili mitados obj eti vos, e que estes est ão e m constant e progresso. Frent e a isso, pode-se menci onar a confor mação como uma das mel hores práticas para o mét odo de desenvol vi ment o de soft ware. Modul ari dade, iteração, incre ment o, ligação ao tempo, parci môni a, adapt ação, convergênci a, orientação a pessoas, colaboração e compl e ment ação apresent a m-se co mo as dez mel hores práticas adot adas para defi nir os processos Ágeis de desenvol vi ment o de soft ware ( ASTELS, 2002). Conf or me ressalta Ambl er (2004), é i mportante que se compreenda que a MA não se trata de um processo compl et o de soft ware. Seu enfoque alcança soment e a model age me a document ação eficaz. Para que possa ser aplicada, ela deve ser utilizada e mconj unt o comoutros processos, tais como o XP e o SCRUM, o qual será adot ado no desenvol vi ment o da aplicação e mel hor apresent ado no decorrer do trabal ho.

33 O Processo de desenvol vi ment o co maplicação do Scrum O Scr umé um model o acessí vel e de for ma algu ma é previsí vel (Schwaber K., 2004). Oferece um conj unt o de práticas que te m como objeti vo sust ent ar o gerenci a ment o do projeto aparent e aos usuári os do model o. Oprocediment o não det al ha o que necessita ser feito e não deci de os proble mas da companhi a, o obj eti vo do Scrum é dar visi bilidade a estas dificul dades e convir co mo direção na resol ução dos mes mos. Os ca mi nhos a adot ar e táticas a e mpregar fica a cargo de que mo i mplant a. Sendo assi m, é uma prática ágil para gerenci a ment o de proj et os de desenvol vi ment o de soft ware. Apesar disso, de acordo com a teoria, pode ser aplicado e m qual quer ocasião no qual u m grupo de pessoas co m noções multi discipli nares necessite mtrabal har junt as para al cançar umobj eti vo co mu m. Por se tratar de um mét odo ágil de desenvolvi ment o de soft ware, o Scrum concentra-se na i deia de que o projet o e a impl e ment ação são ati vidades centrais do pr ocesso. Élicitação de requisitos e testes de projet o fica maliados ao desenvol vi ment o (SOMMERVI LLE, 2011). O Scrumte m o avanço de desenvol vi ment o funda ment ado e miterações com per manênci a entre duas e seis se manas, cha madas de Spri nts. A primeira etapa dentro do Spri nt é a reuni ão de planej a ment o, onde o ti me ligado ao cliente defi ne o que será praticado na iteração, sendo responsabili dade do cliente concretizar a pri orização do trabal ho a ser feito. No Scrum são feitas apenas descrições acerca dos requisit os, que são docu ment adas no product backl og do proj et o, que consiste na lista de funci onali dades desejadas que ai nda não i ntegra m o produto. Tal lista fica organi zada e m or de m pri oritária, sendo que a descrição de seus itens tende a ser refi nada à medi da que o pr oj et o avança ( COHN, 2011). Di aria ment e a equi pe faz uma breve reuni ão, cha mada Daily Scrum. O f oco é disse mi nar infor mação a propósit o do que foi deter mi nado no dia prévi o, identificar bl oquei os e pri orizar o trabal ho do dia que se ini cia. Segundo MARTI NS (2007), é uma reuni ão infor mal de quatro horas de

34 38 duração, que aj uda a equi pe de for ma col aborati va, a obt er umfeedback e deter mi nar quais os obj eti vos da próxi ma iteração, assi m como a quali dade e as capaci dades das funci onali dades produzidas. Ao fi nal de um Spri nt, é apresent ado as funcionali dades i mpl e mentadas e m u ma Spri nt Revi ew Meeting. Após, faz-se uma Spri nt Retrospective e a equi pe parte para o planej a ment o do próxi mo Spri nt. Assi m, rei ni cia-se o cicl o. Como a ilustração na Fi gura 3. FI GURA 3 - Ci cl o Scrum. FONTE: ( Desenvol vi ment o Ágil, 2012). Sendo assi m, confere-se que o Scrumé alta ment e esti mável para e mpresas que tenha m no seu cicl o de concepções produt os que possua m alta taxa de alteração de requisitos. Present e ment e va mos ent ender mel hor o Scrum, conhecendo seus papéis, passos e itens Product Owner Responsável pel o gerenci a ment o do Product Backl og e por garantir o val or do trabal ho realizado pel o ti me. Esta pessoa mantéme garant e que está visí vel para todos. Assi m, t odos sabe mquais itens te m mai or pri ori dade, de for ma que t odos sabe me mque se irá trabal har.

35 39 Para que o Product Owner obt enha sucesso, todos precisa mrespeitar decisões. As decisões são visí veis no cont eúdo e na pri orização do Product Backl og Spri nt Backl og É uma lista de tarefas a fazer e m um Spri nt. Estes itens são extraídos do Product Backl og, pela equi pe, com base nas pri ori dades defi ni das e a percepção da equi pe sobre o te mpo esti mado para compl etar as funci onali dades ( Ágil, 2012). No decorrer de umsprint, o responsável manté m o Spri nt Backl og atualizado para refletir as tarefas co mpl etadas e quant o tempo a equi pe acredita que será necessári o para compl etar aquel as que ai nda não estão pront as. Aesti mati va do trabal ho que ai nda resta a ser feit o no Sprint é calcul ada diaria ment e e col ocada e mumgráfico Product Backl og O Product Backl og é uma lista cont endo t odas as funci onali dades desej adas para um produt o. O cont eúdo desta lista é defi ni do pel o Product Owner. O Product Backl og não precisa estar compl et o no i níci o de umproj et o. Pode-se co meçar comt udo aquil o que é mais óbvio e m um pri meiro moment o. Co m o te mpo, o Product Backl og cresce e muda à medi da que se aprende mais sobre o produt o e seus usuári os ( ÁGI L, 2012) O Product Owner pri oriza os itens do Product Backl og e os descreve para a equi pe. Aequi pe ent ão det er mi na que itens será capaz de compl etar durant e a Spri nt que está por começar. Tais itens serão, então, transferi dos do Product Backl og para o Spri nt Backl og. Ao fazer isso, a equi pe quebra cada ite mdo Product Backl og emuma ou mais tarefas do Spri nt Backlog. Isso aj uda a di vi dir o trabal ho entre os membr os da equi pe. Pode m fazer parte do Product Backl og tarefas técni cas ou ati vidades direta ment e relaci onadas às funci onali dades solicitadas (ÁGI L, 2012) Hi st óri a de usuári o A hist ória é o mei o que apresent a uma funci onali dade, uma mel horia ou uma

36 40 correção a ser i mpl e ment ada dentro do sistema. El a sugere o que será desenvol vi do e não como será feito. De acordo com Cost a (2011), a pri nci pal ferra ment a utilizada para licitação são os cart ões de hist ória e mque os usuári os escreve msuas hist órias de usuári o, que é u ma descrição de umrecurso que fornece o val or de negóci o para o client e. A utilização de hist órias de usuári o se resulta e m um menor volu me de docu ment ação comparando a procedi ment os tradici onais. É i mportant e dest acar que durant e o desenvol vi ment o, essa defi nição serve como gui a para a equi pe. Cada hist ória existente no Product Backl og deve ter uma orde massoci ada. O pri meiro é de cargo do Product Owner e o segundo do ti me, que deve ser se mpre solicitado a reavaliar as esti mati vas constant es no Product Backl og Escopo do projeto Para obt er as pri meiras hist órias de usuári o foi necessária uma reunião com umclient e (PO) solicitando uma alternati va de soft ware para aut omação resi denci al. Nest a reuni ão fora m levant adas al gumas hist órias de usuári os macro, como est á ilustrado no Quadro 1 logo abai xo. Apresent a-se o product backlog da aplicação, consi derando os três Spri nts pri nci pais para o co mpl et o desenvol vi ment o do siste ma. QUADRO 1 - Pr oduct Backl og da Aplicação No me I mport ânci a Esti mati va (di as) Co mo de monstrar Mont ar uma mbi ent e de si mul ação resi dencial Ma quet e para a de monstração de um a mbi ent e resi dencial. Aut omatizar os el e ment os básicos do a mbi ent e de si mul ação Cri ar API de comuni cação com o mi cro controlador Ma ni pul ar luzes e mot ores Docu ment ação para pr over infor mações sobre funções e ret ornos Font e: ( Adapt ado de Kni berg, 2007). A ati vi dade realizada no Spri nt I, foi defi ni da a construção de uma maquet e

37 41 para a de monstração do siste ma, tendo e mvista que a aut omação de uma resi dênci a não seria viável para o projet o. O Spri nt II constit ui em fiação e ele ment os utilizados para a concretização da aut omação ilustrando os eletrôni cos e a elétrica de uma resi dênci a. Por fi mno Spri nt III é apresent ado o modo pelo qual o siste ma é concebi do, apresent ando a funda ment ação necessária e os model os de comuni cação suportados Iteração I Mont ar um ambi ent e de si mul ação resi denci al A seguir está apresent ada a docu ment ação do pri meiro Spri nt de desenvol vi ment o do siste ma. Consiste no desenvol vi ment o de uma maquet e para si mul ar uma mbi ent e resi denci al Hi st ória de Usuári o Uma hist ória de usuário é uma descrição rápida na visão do client e de uma funci onali dade, para a tal foi solicitada a construção de uma maquet e com o fi m de de monstrar o soft ware e mfunci ona ment o, levando e mconsi deração que a de monstração e m uma construção civil não seria viável. No Quadro 2, consta a hist ória de usuári o macr o do pri meiro Sprint. QUADRO 2 - Hi st ória de usuári o macro Spri nt I Co mo um habitante resi denci al, eu quero ter umespaço físico para instalar equi pa ment os de aut omação, de modo que tal espaço esteja pront o para se comuni car comdet er mi nada tecnol ogi a. (FONTE: PRÓPRI O AUTOR, 2013) Conf or me descrito no pri meiro capít ul o a confecção de umespaço físico é de grande i mportânci a para a de monstração do proj et o. Sendo assi m, o Spri nt I ficou di vi di a e mtrês sub hist órias defi ni das como criação do projet o arquitet ôni co, concepção e a fase de corte e mont age m. I mportant e destacar que os itens salientados abai xo deve m ser visualizados co mo sub hist ória de usuári o que dão corpo a hist ória pri nci pal apresent ado no quadr o três. O Quadro 3 ilustra como ficou di vi di da as sub hist órias de usuários.

38 42 QUADRO 3 - Hi st órias de usuári o Spri nt I Co mo um client e, eu quero ter um proj et o arquitet ôni co de modo que tal possa dar iníci o a de monstração do projet o. Co mo um cliente, eu quero fazer a concepção do a mbi ent e de modo que tal seja m feitas no isopor e madeira. Co mo um client e, eu quero fazer a mont agem do a mbi ent e de modo que tal esteja pr ont o para ser aut omatizado. (FONTE: PRÓPRI O AUTOR, 2013) Todas estas quest ões, devi da ment e ponderadas leva ma Fi gura 4 que apresent a o Board do Spri nt I, utilizando um quadro usado para mant er a organização do proj et o, obt endo a visualização do fl uxo de trabal ho e monit orando o mes mo. FI GURA 4 - Board Spri nt I. (FONTE: PRÓPRI O AUTOR, 2013) Emarquitet ura, o desenho é a pri nci pal for ma de expressão. Éatravés del e que o arquitet o exteri oriza as suas criações e sol uções, represent ando o seu proj et o, seja ele de um móvel, umespaço, uma casa ou uma cidade. Portant o, é essenci al que exista o projet o arquitet ôni co para dar iníci o a execução do proj et o, desta for ma seu ent endiment o envol ve cert o nível de trei na ment o. Por este moti vo, foi solicitado o auxílio de um especialista para dar conti nui dade.

39 St oryboard Para atender a estrut ura identificada coma i nterpretação da hist ória de usuári o descrita anteri or ment e fora m proj etadas três tel as, que são apresent adas e descritas na i mpl e ment ação do sistema. Os prot óti pos podem ser utilizados em qual quer met odologi a de desenvol vi ment o de soft ware como apoi o ao ent endi ment o dos requisitos de siste ma. Na met odol ogi a ágil o pr ot óti po é ai nda mais útil. Quando se al mej a arquitetar umi móvel, ou mes mo execut ar uma refor ma e m al gumjá concl uí do, é cert o não começar se m antes se ter uma defi nição de como irá ficar a construção. Para que o client e obt enha uma i deia de como ficara a sua obra, os engenheiros e arquitet os utiliza m pl ant as e maquet es. Co m base nestas, o client e ent ão passa a conhecer e ter a capaci dade de solicitar modificações no planej a ment o da obra. De maneira equi valente o uso de prot óti pos no desenvol vi ment o de soft wares per mit e fi gurar desde o ant es do i níci o do desenvol viment o como o siste ma deverá ficar quando co mpl eta ment e desenvol vi do Segundo Mills (2007), a maquet e te m gr ande i mportânci a no processo de co muni cação e compreensão da arquitet ura. Ai nda que o aument o e a evol ução das novas tecnol ogi as tenha m proporci onado que o proj et o assistido pel o comput ador (tecnol ogi as CAD) tenha se converti do e m u ma i mportant e ferrament a de desenho arquitet ôni co, a utilização de maquet es físicas conti nua sendo funda ment al no processo de de monstração da arquitet ura. Sendo assi m, é proj etada a estrut ura, a tela de monstrada na Fi gura 5 é a pri meira a ser desenhada represent ando a plant a bai xa do térreo da maquet e e assi m podendo dar iníci o ao desenvol vi ment o físico.

40 44 FI GURA 5 - Pl anta bai xa maquet e (FONTE: PRÓPRI O AUTOR, 2013) Iteração II Aut omatizar os element os básicos do ambi ent e de si mulação A seguir está apresent ada a document ação do segundo Spri nt de desenvol vi ment o do siste ma. Consiste na automatização dos ele ment os bási cos no a mbi ent e de si mul ação Hi st ória de Usuári o Para a obt enção da história de usuári o o cliente solicit ou a aut omação de seus el etrôni cos, sendo assim f oi desi gnada a de monstração do mes mo na maquet e proj etada ant eri or ment e. No quadr o 4 const a a hist ória de usuári o macro do Spri nt II.

41 45 QUADRO 4 - Hi st ória de usuári o macro Spri nt II Co mo um habitante resi denci al, eu quero ter a instal ação elétrica adequada, de modo que tal suporte os equi pa ment os de aut omação. (FONTE: PRÓPRI O AUTOR, 2013) É de grande i mportância que forneça local físico adequado para o mes mo, a partir do a mbi ent e é defi ni do de acordo com as necessi dades quais ele ment os serão aut omatizados. Sendo assi m, o Spri nt II ficou di vi di do e mtrês sub hist órias de usuári o ilustradas no Quadr o 5 a seguir. QUADRO 5 - Hi st órias de usuári o Spri nt II Co mo um cliente, eu quero gerenci ar as luzes do a mbi ent e, de modo que tal se co muni que via web Co mo um cliente, eu quero gerenci ar o ar condi ci onado, de modo que tal se co muni que via web Co mo um client e, eu quero gerenci ar o portão do a mbi ent e, de modo que tal se co muni que via web (FONTE: PRÓPRI O AUTOR, 2013) A fi m organi zaci onal é de monstrada na Fi gura 6 o Board do Sprint II, foi gerado a partir das histórias de usuári o citadas anteri or ment e. FI GURA 6 - Board Spri nt II Font e: (PRÓPRI O AUTOR, 2013)

42 46 As diferenças mais i mportant es entre uma i nstalação elétrica convenci onal e u ma i nstalação de domótica se concentra mem al guns aspect os como a dificul dade e m fazer qual quer alteração na cabl age mjá existent e. Portant o, e m uma i nstal ação de domótica, a alteração nas necessidades do utilizador pode ser ultrapassada através da simpl es reprogra mação tendo assi m mai or flexi bilidade St oryboard Uma vez que exista o ambi ent e para ser feita a instalação, é feita a i mplant ação dos ele ment os tais como sensores e at uadores. A Fi gura 7 mostra os LEDs a sere m i nstalados no a mbi ent e residenci al descrito anteri or ment e, afi m de si mul ar as luzes da sala, cozi nha, banheiro, portão el etrôni co e exteri or da maquet e. FI GURA 7 - LEDs (FONTE: PRÓPRI O AUTOR, 2013) A Fi gura 8 mostra o cabea ment o que será utilizado para fazer a ligação dos el e ment os como mi cro controlador.

43 47 FI GURA 8 - Cabos (FONTE: PRÓPRI O AUTOR, 2013) Após a aquisição dos equi pa ment os é feita a instalação da parte elétrica na maquet e de acordo com a necessi dade, a seguir no capít ul o de desenvol vi ment o, é apresent ado o a mbi ent e pront o a ser i mpl ant ado o mi cro controlador junt o ao soft ware Iteração III Cri ar API de comuni cação como mi cro control ador A seguir está apresent ada a document ação do Spri nt III de desenvol vi ment o do siste ma. Consiste na i mpl e ment ação de uma API para o mi cro fra me wor k net dui no para a comuni cação de dados com o dispositivo Hi st ória de Usuári o No Quadro 6 consta a hist ória de usuári o macro do Spri nt III retirada através da reuni ão com o PO, onde o mes mo necessita de umsoft ware que receba e int erpret e requisições da i nternet ou i ntranet. QUADRO 6 - Hi st ória de usuári o magro Spri nt III. Co mo habitante resi dencial, eu quero mandar comandos pela web para ummi cro controlador, de modo que tal sai ba interpretar e execut ar. (FONTE: PRÓPRI O AUTOR, 2013) Uma vez que o pesquisador te mo conheci mento das funci onali dades possí veis

44 48 referent e ao mi cro controlador, é necessári o for necê-l o um mei o de co muni cação das infor mações. O obj eti vo é desenvol ver umpadrão de comunicação para a utilização de suas funci onali dades por aplicati vos que não pretende m envol ver-se em det al hes de i mpl e ment ação do software, apenas consu mir seus serviços St oryboard Inicial ment e, é de monstrada a visualização baseada na document ação feita a seguir. A API é acessada utilizando o prot ocol o HTTP, para tirar proveit o da funci onali dade deverá realizar uma cha mada HTTP para deter mi nado recurso expost os na i nterface. Aresposta virá no códi go de status e no corpo da requisição. Os det al hes para uso serão descrit os no capit ul o de desenvol vi ment o. O Quadr o 7, desti na-se a desenvol vedores de websites e dispositivos móveis que deseja m usar as funci onali dades disponí veis nesta versão. A seguir será de monstrada os mét odos disponí veis de requisição para a API. QUADRO 7 - Request Type Descri pti on Docu ment ação API /api /pi n GET Esta URL deve ser usado para obter o status de todos os pi nos di sponí vei s. /api /pi n/0 GET Esta URL deve ser usado para obter o status do pi no passado por parâ metr o, o mes mo pode ser de 0 a 13. /api /pi n POST Esta URL deve ser usado para alterar o status, deve ser segui da de u m dado que i dentifi que o pi no e o status a ser alterado. (FONTE: PRÓPRI O AUTOR, 2013) Para exe mplificar a funci onali dade será de monstrado o uso da requisição e m u m prot óti po web, a Figura 9 concebe um client e utilizando a funcionali dade da API. Ao clicar no bot ão ligar é feita a requisição HTTP onde htt p://x. x. x. x/pi N0/ ON constit ui emacender a lâ mpada que está conect ado ao PI N0 do mi cro controlador.

45 49 FI GURA 9 - Requisição acender lâ mpada (FONTE: PRÓPRI O AUTOR, 2013) A seguir na fi gura 10, é de monstrada a lâ mpada conect ada ao PI N0 do mi cro controlador acesa após a i nterpretação da requisição. FI GURA 10 - Lâ mpada conectada ao PI N0 acesa (FONTE: PRÓPRI O AUTOR, 2013) A Fi gura 11 de monstra o prot óti po do cliente utilizando a funci onalidade da API. Ao clicar no bot ão desli gar é feita a requisição HTTP onde htt p://x. x. x. x/ PI N0/ OFF constitui emdesli gar a lâmpada conect ada ao PI N0 do mi cro controlador.

46 50 FI GURA 11 - Requisição apagar lâ mpada (FONTE: PRÓPRI O AUTOR, 2013) A seguir, na Fi gura 12 de monstra a lâ mpada conect ada PI N0 do mi cro controlador desli gada após a interpretação da requisição. FI GURA 12 - Lâ mpada conectada ao PI N0 desligada (FONTE: PRÓPRI O AUTOR, 2013) Fl uxo API Co m base na hist ória de usuári o previ a ment e apresent ada, realizou-se a model age m de um di agra ma de fl uxo para mel hor compreensão do funci ona ment o do

47 51 siste ma. O curso pri ncipal de funci ona ment o da entrada de dados para o siste ma foi construí do através da ferra ment a Mi crosoft Visi o 2013, e está exposto na Fi gura 13. FI GURA 13 - Di agra ma de fluxo API (FONTE: PRÓPRI O AUTOR, 2013) Observa-se que, a requisição do cliente é de essenci al i mportância para a co muni cação do fl uxo de funci ona ment o da aplicação. Portant o a orde m é dada a partir do cliente e assi mi nterpret ada pela API do netdui no. A t endênci a a segui nte da aplicação é identificar qual foi o comando solicitado e disparar a ação para o mei o físico. Se o co mando for execut ado deverá ret ornar a confir mação Model age m das classes Pel o diagnóstico da hist ória de usuári o proporci onada e e m segui da da el aboração do diagrama de fl uxo, foi plausí vel deter mi nar a rel ação de classes

48 52 necessárias para conceber as enti dades que farão parte do escopo do projet o do mi cro controlador. Estas estão represent adas no diagra ma da Fi gura 14, que foi construí do com a ferra ment a Visual St udi o. FI GURA 14 - Model o das classes do web server (FONTE: PRÓPRI O AUTOR, 2013) 4. 4 Concl usão Est e capit ul o consisti na ilustração da de como o siste ma deve se comport ar de acordo com a solicitação do PO, comisso é obti do o conheci mento necessári o para o desenvol vi ment o do siste ma. No ent ant o, é funda ment al ressaltar a i mportânci a da criação da maquet e para a de monstração e concretização do siste ma, assi mpodendo ser de monstrado o mes mo.

49 53 5 DESENVOLVI MENTO 5. 1 Introdução Est e capít ul o irá exi bir as aplicações e ferra ment as e mpregadas para o desenvol vi ment o do present e trabal ho. Ta mbém serão apresent ado os fat ores essenci ais que per mita mo compl et o funci ona ment o da aplicação Tecnol ogi as utilizadas O quadro abai xo deve consistir nas tecnol ogias das aplicações e ferra ment as utilizadas comsuas versões e nomes especificados. QUADRO 8 - Tecnol ogias utilizadas Tecnol ogi a Versão Apli cação Mi cr o Fra me wor k 4. 3 Apoi o ao desenvol vi ment o de códi go. Net dui no Pl us Mi cr o controlador utilizado co mo pl atafor ma do siste ma Vi sual St udi o 2012 I DE utilizada para o desenvol vi ment o da aplicação Tea m Foundati on Servi ce Previ ew Soft ware utilizado para gerência do proj et o JSON 2. 2 For mat ação leve de troca de dados Mi cro Frame work 4. 3 O Mi cro Fra me wor k co mbi na a confiabili dade e a eficiênci a do códi go gerenci ado com as ferra ment as de desenvol vi ment o do pre mi er de Mi cr osoft Visual St udi o para oferecer u ma produti vi dade excepci onal para o desenvol vi ment o de aplicações e mbarcadas e m dispositi vos pequenos. A Mi crosoft NET Mi cr o Fra me wor k SDK. Apoi a o desenvolvi ment o de códi go, incl ui ndo dispositivo de Input / Out put, na linguage m C # usando u m subconj unt o das bibli otecas. NET, e é total ment e i ntegrado

50 54 com o a mbi ent e de desenvol vi ment o Mi crosoft Visual St udi o. A bi blioteca de classes. NET Mi cro suporta todos os pri nci pais na mespaces e tipos de estrut ura deskt op Net dui no O Net dui no consiste e m uma pl atafor ma que comporta desenvolvedores criare m proj et os eletrôni cos com mai or facilidade, onde os aplicativos do Net dui no utiliza m Mi cro Fra mewor k citado ant eri or ment e. A fa mília do Net dui no consiste e m 3 placas eletrôni cas: Net dui no, Net dui no Pl us, Net dui no Pl us 2 e Net dui no Mi ni ( WALKER, 2012). A Fi gura 15 i dentifica as pri nci pais peças que mont a mo Net dui no Plus. FI GURA 15 - Net dui no (FONTE: NETDUI NO, 2013) Nest a sessão va mos coment ar sobre o Net duino Pl us utilizada para constit uir o proj et o. Abai xo serão descritos os component es pri nci pais do Net dui no Pl us Conect ores de ali ment ação A ali ment ação de energia do Net dui no pode ser uma font e AC para DC co m o pl ugue ta manho 5, 5 mm co mt ensões per mitidas entre 7, 5v e 12v. Vi sando o control e de prot eção, caso ocorra al guma alteração de voltage m, a placa possui umfusí vel de pr ot eção de tensão i nversa. Esse fusí vel rei nicia aut omatica ment e assim que resfriar.

51 Mi cr ousb É a conexão entre o Net dui no e a porta USB do comput ador. Ta mbé m é utilizada para a ali mentação de energi a da placa e para i mpl ant ar os aplicati vos dentro do Net dui no e depurar esses aplicati vos i nterativa ment e. A conexão Mi crousb ta mbé mtransfor ma o Net dui no e mumdispositivo USB co mo teclado, mouse, dispositivo de comuni cação bi direci onal etc Mi cr osd O sl ot Mi crosd per mite que seja agregado ao Net dui no uma memóri a de ar mazena ment o onde é possí vel ar mazenar dados do a mbi ent e, pági nas web entre outras aplicações. Co m umconheci ment o avançado, é possí vel ar mazenar no cartão Mi crosd códi gos compilados para a execução direta no Net dui no Conect or Et hernet O conect or et hernet permi t e que o Net dui no Plus tenha conexão coma internet através de uma rede. Co m o dispositi vo conect ado na i nternet, é possí vel realizar a co muni cação de dados capt urados por sensores direta ment e para pági nas de i nternet, per miti ndo a interação web e pri nci pal ment e, se comuni car com Netdui nos a distância Mi cr ocontrolador ARM At mel É o processador pri ncipal, e ele per mite o armazena ment o do códi go e possui a me móri a RAM que será utilizada pel o aplicati vo Net dui no. Oas conexões do mi cro controlador estão conect ados com os pi nos azuis de cabeçal ho, possi bilitando que o Net dui no se conect e com os component es externos e aos Shi el ds de expansão Anal ógi cas

52 56 Exi ste mseis cabeçal hos anal ógi cas nas quais pode mser conect ados sensores co mo por exe mpl o, sensores de l uz, temperat ura, movi ment o, pressão entre outros. Esses cabeçal hos ta mbé m poderão operar e mmodo de I/ O(entrada e saí da) di gital Di gitais Est es cat orze cabeçalhos são utilizados para conect ar as entradas de ligado/ desli gado como interrupt ores, bot ões de pressão e sensores de ligado/ desli gado. Ta mbé m pode mser ligadas saí das de ligado/ desli gado como LEDs, int errupt or de relé. Os cabeçal hos di gitais de I/ Ote ma capaci dade de se comuni car através dos prot ocol os de comuni cação I2C, SPI e UART (serial) e pode m envi ar pulsos elétricos para alterar a vel oci dade de mot ores, controlar a intensi dade de LEDs e mais JSON Segundo JSON. ORG É um for mat o leve de i ntercâ mbi os de dados co mput aci onais. É umconj unt o de not ações de obj et o de JavaScri pt, mas seu não requer JavaScri pt. JSON é um for mat o si mpl es no compartilha ment o de i nfor mações e não depende da linguage mde progra mação Ri chardson (2007). O JSON é umfor mato de troca de dados que ta mbé m serve para serializar obj et os. Um obj et o na me móri a poder ser transfor mado e m umformat o i ndependent e da linguage m e ser transportado por qual quer mei o até os seu desti no, de maneira se mel hant e ao SOAP (SAMP AI O, 2007) Ferra ment as utilizadas Vi sual St udi o Co m a utilização da IDE Visual St udi o, é possí vel a criação dos pr oj et os conti dos no SDK do Net dui no, sendo t otalment e i ntegrado com o mi cro controlador. Apr esent a-se um pacot e de frame works reduzi dos especifica ment e para proj et os

53 57 e mbarcados. O Vi sual St udi o é umpacot e de ferra ment as de desenvol vi ment o de soft ware baseadas e mcomponent es e outras tecnol ogias para a criação de aplicati vos avançados de alt o dese mpenho. Al é m disso, o Visual St udi o é oti mi zado para projet o, desenvol vi ment o e i mplant ação e mequi pe usando Tea m Foundati on Ser vi ce ou Tea m Foundati on Server ( MSDN, 2013). Para este proj et o é de grande i mportânci a a utilização da I DE Visual St udi o, torna-se viável pela afini dade com o soft ware Team Foundati on Service De modo recent e a Mi cr osoft li ber ou o acesso a ferra ment a do Tea m Foundati on Servi ce. Nesse serviço pode mos utilizar até 5 usuári o, al é m de poder mos criar projet os grat uita ment e. A Mi crosoft oferece a opção de usar o Tea mfoundati on Servi ce, onde t odos os aspect os do lado do servi dor da i mpl ant ação estão hospedados para você. Seu códi gofont e, itens de trabal ho, confi gurações de compilação e recursos da equi pe estão t odos hospedados na nuve m. Do pont o de vista arquitet ôni co, isso si mplifica muit o a sua i mpl ant ação, como os úni cos aspect os da arquitet ura que você precisa para consi derar são os component es do cliente e seu acesso à Int ernet ( MSDN, 2013). Em segui da é apont ado al guns recursos que a ferra ment a possui para o gerenci a ment o de código: Conexão com Vi sual Studi o e Ecli pse, alé mda capaci dade desenvol ver e m C#, Java, HTML, C++, etc. Revisões de códi go e gerenci a ment o de conflitos durant e o check-i n. Of erece apoi o a avaliações de uni dade e integração contí nua, t olerando det er mi nar testes de uni dades que serão execut ados após o check-in, e receber o alerta de código que quebre o buil d. Para a colaboração e mequi pe e desenvol vi ment o ágil a ferra ment a oferece os segui ntes recursos:

54 58 Gerenci ar equi pes usando ferra ment as de desenvol vi ment o ágil a partir de qual quer navegador. For nece umquadro de tarefas onli ne para gerenci a ment o do Spri nt I mpl e ment ação do siste ma Dest a maneira, é apresent ada na Iteração I e II a fase de preparação do a mbi ent e propost o, para assi m ser possí vel obt er o resultado fi nal do soft ware. Na iteração III é apresent ado o conheci ment o necessári o para i nteragir co m o siste ma Iteração I Mont ar um ambi ent e de si mul ação Após a elaboração do pr oj et o de monstrada pel a Fi gura 16 a fase em que as partes component es da maquet e são desenhadas ou riscadas no mat erial base, for mando a estrut ura. Ou seja, são marcadas no isopor e madeira, as paredes com suas abert uras, as aguas do tel hado, as lajes do piso, de entrepiso e forro. FI GURA 16 - Fase concepção (FONTE: PRÓPRI O AUTOR, 2013) Após a planificação é feit o o corte das partes, é i mportant e verificar a precisão das medi das ant es de cortar, para não desperdiçar te mpo e mat erial. Na Fi gura 17 apresent a-se a mont agem, e esta é col ocada sobre uma base.

55 59 FI GURA 17 - Mont age m (FONTE: PRÓPRI O AUTOR, 2013) resi denci al. A Fi gura 18 de monstra a maquet e pront a de onde será si mul ado o ambi ent e FI GURA 18 - Ma quet e (FONTE: PRÓPRI O AUTOR, 2013) Est a fase do projet o garant e a contri bui ção das met as propost as para a concl usão e apresent ação do siste ma Iteração II - Aut omatizar os element os básicos do ambi ent e de si mulação A seguir é feita a fase da i nstalação física dos ele ment os que deve m ser mani pul ados pel o mi cro controlador, sendo assi mé compost o por cabos, podendo ser

56 60 consi derado e muma mbi ent e real como o projet o elétrico de uma residênci a. A Fi gura 19 mostra um exe mpl o de um LED pront o para receber co mandos do siste ma. FI GURA 19 - Instalação LED (FONTE: PRÓPRI O AUTOR, 2013) A partir desta etapa é possí vel envi ar comandos do mi cro controlador ao el etrôni co, sendo assi m é possí vel gerenci á-l o, a seguir será de monstrado um exe mpl o de como fazer o mes mo Ma ni pul ando um LED. A seguir é de monstrado como utilizar o. NET Mi cro Fra me wor k, uma versão muit o reduzi da do.net Fra me wor k projetada para utilização em dispositi vos e mbarcados. É utilizado e m conj unt o o Netdui no, um mi cro controlador si mpl es e expansí vel. Para fazer acont ecer a luz no LED, precisa mos escrever a lógi ca do circuit o. O SDK do Net dui no disponi biliza di versas classes para o controle das saí das di gitais. Tal vez a classe mais import ant e que ire mos trabal har é a Out put Port. Esta classe possui u m construt or com dois parâ metros: um enumer ador cha mado Cpu. Pi n, que cont é m referênci as para t odas as saí das do Net dui no e um bool eano, que cont é m o val or do

57 namespacemanipulandoled {publiclasprogram {publicstaticvoidmain() {OutputPortoutPort=newOutputPort(Pins.ONBOARD_LED,false); while(true) {outport.write(true); } }}} outport.write(false); Thread.Slep(250); 61 estado i nicial da saí da. Esta classe ta mbé m cont é m um mét odo chamado Write para escrever umdado bool eano na saí da. Assi m, quando cria mos uma inst ânci a da classe Out put Port e execut a mos seu mét odo Write passando o parâ metro true, o circuit o li bera energi a para a respectiva saí da di gital ( mais conheci da como pi no). Ao contrári o, se execut a mos o mes mo mét odo passando o parâ metro false, o circuit o bl oquei a a energi a no respecti vo pi no, que passa a cont er zero volts. Dest a for ma, é possí vel liberar tensões para os pi nos positivos e li berar passage m de corrent e elétrica dos pi nos do Net dui no, A seguir no Quadr o 9 é de monstrado o códi go para ligar e desli gar um LED QUADRO 9 - Códi go mani pul ando LED (FONTE: PRÓPRI O AUTOR, 2013) A li nha 7 do mét odo Mai n é criado uma inst anci a da classe Output Port atri bui ndo o enumerador Pi ns. ONBOARD_LED que cont é ma referênci a do LED que se encontra na placa do Net dui no. Emsegui da na linha 10, o siste ma entra e mu ml aço de repetição while, então é execut ado o mét odo Write passando como parâ metro o bool eano verdadeiro e então é aci onado o LED, após u m t e mpo de espera det er mi nado pel o co mando Thread. Sleep é execut ado nova ment e o mét odo, agora det er mi nando que deverá ser falso e assim desli gar o LED Iteração III - Cri ar API de comuni cação como mi cro control ador Co meça mos este tópi co coma i ntrodução dos tipos para represent ar o conceit o funda ment al do HTTP, desi gnada ment e de pedi do e respost a. Depois, va mos mostrar co mo a mbos cabeçal hos e cont eúdo são represent ados e processados através de um conj unt o de classes específicas. Por fi m, acabamos mostrando como produzir e consu mi r o cont eúdo da mensagem. Tendo e m vista que o espaço para de monstração do siste ma está preparado é dado sequênci a a comuni cação do mi cro controlador. Aci ma de t udo, é funda ment al ressaltar que o model o corret o de comuni cação é o prot ocol o de comuni cação HTTP,

58 GEThtp:/ :8080/api/pinHTP/1.1 Host: :8080 User-Agent:Mozila/5.0(X1;U;Linuxi686;en-US;rv: )Gecko/ Ubuntu/8.10(intrepid)Firefox/3.0.3 Acept:text/html,aplication/xhtml+xml,aplication/xml;q=0.9,*/*;q= segui do de uma estrut ura de dados desi gnada JSON. Este trabal ho é focalizado no bási co do prot ocol o HTTP, estando disponí veis apenas mét odos de GET e POST de monstrados nos t ópi cos a seguir. Sendo assi m, existe mtrês possi bilidades de pergunt as e respostas. O HTTP é o prot ocol o para a troca ou transferênci a de hi pertext o, do mes mo modo é essenci al ter conheci ment o de como funci ona o mes mo. El e é responsável pel a co muni cação entre o client e e o servi dor web, esta comuni cação consisti e m u m conj unt o de solicitações e respostas deno mi nadas request e response. Os clientes são cha mados de user agent, do mes mo modo, faze mrequisições ao servi dor. Éi mportante salientar que o cliente pode ser umnavegador de i nt ernet, um robô, umsoft ware ou um scri pt entre outros. O servi dor web é aonde se encontra a lógi ca do siste ma, responde as mensagens dos clientes, o mes mo pode responder várias solicitações ao mes mo te mpo Me nsagens O prot ocol o HTTP opera através da troca de mensagens, pedi do e respost a entre clientes e servi dores. Ambas as mensagens são compost as por uma linha de parti da onde existe uma sequênci a de ca mpos no cabeçal ho e umcorpo de mensage mopci onal Mét odo GET Nest e t ópi co é de monstrada a comuni cação baseada e m requisições e respostas. Sendo assi m, a mes ma necessita começar com uma solicitação, o model o de requisição utilizado no mi cro controlador é apresent ado no Quadro 10. QUADRO 10 - Requisição GET (FONTE: PRÓPRI O AUTOR, 2013) Tendo e mvista que a linha númer o 1 cont é ma pal avra GET comsi gnificado de adquirir um cont eúdo que se encontra no l ocal indi cado por htt p:// :8080/ api/ pi n. Do mes mo modo na linha númer o 2, é identificado o host indi cado pel o text o Host: :8080, este te mcomo si gnificado uma solicitação do client e ao

59 HTP/1.020OK Content-Type:aplication/js;charset=utf-8 Content-Length:19 Conection:close {"Pin10":"False","Pin9":"False","Pin1":"False","Pin1":"False","Pin8":"False","Pin0":"False","Pin12":"False","Pin3":"False","Pin6":"False","Pin5":"False","Pin4":"False","Pin7":"False","Pin2":"False"} GEThtp:/ :8080/api/pin/4HTP/1.1 Host: :8080 User-Agent:Mozila/5.0(X1;U;Linuxi686;en-US;rv: )Gecko/ Ubuntu/8.10(intrepid)Firefox/3.0.3 Acept:text/html,aplication/xhtml+xml,aplication/xml;q=0.9,*/*;q= servi dor que se encontra e m / api/ pi n no host. Nest e senti do, a linha nú mer o 3 mostra quem está fazendo a solicitação ao servi dor defi ni do pelo user agent e no exe mpl o aci ma é o navegador Mozilla. Evi dent e ment e, a linha 4 mostra os recursos aceit os pel o cliente de maneira correta. Todas as solicitações feitas é segui da de uma resposta devi da ment e ponderada o Quadr o 11 apresent a a resposta adequada do servi dor quando a mesma é devi da ment e pr ocessada. QUADRO 11 - Resposta GET (FONTE: PRÓPRI O AUTOR, 2013) Est a é uma resposta do mi cro controlador trabalhando como umservi dor web, a pri meira linha corresponde a resposta da requisição be msucedi da (200 OK), o client e deverá receber o que estava aguardando. A li nha númer o 2 mostra o tipo do document o que será envi ado ao client e, no exe mpl o aci ma i ndi ca u m arqui vo JSON segui do da codificação que o arqui vo está utilizando. Por segui nte, é de monstrada na linha númer o 3 o Cont ent-lengt h o mes mo constitui na quanti dade de caracteres present es na resposta para o client e. Sendo assi m, na quarta linha é i ndi cado que a conexão com o servi dor foi fi nalizada, acompanhado do cont eúdo do arquivo ou recurso requisitado pel o client e, no caso est udado umarquivo JSONi nfor mando se os pi nos estão ligados ou desli gados. Assi m mes mo, existe a possi bilidade de requisitar uma consulta especifica para det er mi nado parâmetro, deve ser infor mado no host da solicitação. No Quadr o 12 é de monstrado o modelo de requisição. QUADRO 12 - Requisição GET comparâmetro (FONTE: PRÓPRI O AUTOR, 2013) Tendo e m vista o model o de requisição GET de monstrado ant eri orment e no Quadr o 10, é possí vel enfatizar que a solicitação com parâ metro te m a mes ma funci onali dade poré m co m resposta se mel hant e. A pri nci pal diferença entre eles é defi ni da no host como parâ metro / 4 i nfor mado. Este val or pode ser alternado de zero at é o númer o treze.

60 12346 HTP/1.020OK Content-Type:aplication/js;charset=utf-8 Content-Length:15 Conection:close {"Pin4":"True"} POSThtp:/ :8080/api/pinHTP/1.1 User-Agent:Fidler Host: :8080 Content-Length:26 {"Pin":"4","Status":true} 64 A seguir no Quadro 13 é de mostrado a resposta do servi dor, é possí vel observar que o corpo da mensage m cont é m a situação at ual do pino envi ado como parâ metro de acordo com o recurso requisitado no for mat o JSON. QUADRO 13 - Resposta GET comparâ metro (FONTE: PRÓPRI O AUTOR, 2013) Percebe mos, que a utilização do mét odo GET pode resultar e m dois tipos diferent es, o pri meiro co ma situação at ual de todos os pi nos, e o segundo coma sit uação do pi no especifico Mét odo POST Não obst ant e, é de monstrada a comuni cação proposta para envi o de dados ao pr ogra ma situado no host especificado. Sendo assi m, a mes ma necessita começar com u ma solicitação do ti po POST acompanhado de dados no for mat o JSON que deverá cont er a infor mação do pi no e sit uação desejada. O model o de requisição POST utilizado no mi cro controlador é apresent ado no Quadro 14. QUADRO 14 - Requisição POST (FONTE: PRÓPRI O AUTOR, 2013) Tendo e m vista que a linha númer o 1 cont é m a pal avra POST co m si gnificado de envi ar dados ao l ocal indi cado por htt p:// : 8080/ api/ pi n. Nest e senti do, a linha nú mer o 2 constitui no host indi cado pel o texto Host: :8080, este te m como si gnificado envi ar dados do client e ao servi dor que se encontra e m / api/ pi n. Do mes mo modo, a linha númer o 3 apresent a que m encontra-se comet endo a solicitação ao servi dor deter mi nado pel o user agent e. No exe mpl o aci ma equi val e ao soft ware Fi ddl er. Evi dent e ment e, a quarta linha mostra a quanti dade de dados a ser envi ados, acompanhado dos dados. A seguir no Quadro 15 é de mostrado a resposta do servi dor, é possí vel observar que o corpo da mensage m cont é ma sit uação do processa ment o dos dados de

61 HTP/1.020OK Content-Type:aplication/json;charset=utf-8 Content-Length:15 Conection:close {"Suces":true} 65 acordo com o recurso requisitado no for mat o JSON. QUADRO 15 - Resposta POST (FONTE: PRÓPRI O AUTOR, 2013) Sendo assi m, a utilização do mét odo POST pode resultar e m dois ti pos diferent es, podendo ser como ca mpo Sucess verdadeiro ou falso Estrut uração do proj et o Net dui no Após a escol ha da platafor ma e do a mbi ent e de desenvol vi ment o da aplicação, foi possí vel iniciar a estrut uração do projet o dentro da I DE, paralela ment e à i dealização da arquitet ura do aplicati vo. A Fi gura 19 de monstra essa composição por mei o de separação de pastas. FI GURA 20 - Estrut uração do projet o no I DE Visual St udi o (FONTE: PRÓPRI O AUTOR, 2013) Cabe salientar que apesar do projet o ser desenvol vi do no Visual St udio, se faz necessári o t omar al guns cui dados na estrut uração, vist o que está sendo desenvol vi do um

62 publiclasprogram {privatestaticaplicationaplication; publicstaticvoidmain() {aplication=newaplication(); try{aplication.init(); }catch(exceptione) }} {Debug.Print(e.Mesage); } 66 pr ogra ma que será embarcado e m um mi cro controlador, dispondo muit o menos recursos e mcomparação comservi dores e comput adores pessoais. Dentro de uma aplicação padrão do Net dui no, o projet o desti nado às classes desenvol vi das é deno minado Net dui no. Server. Apartir deste, são criados as past as para mel hor organi zação estrut ural do siste ma. O pr oj et o do Net dui no.server, foi separado nas segui ntes pastas: Applicati on: Cont é mclasses de i nicialização do mi cro controlador na rede e trata ment o de erros; Co mmand: Cont é mas cl asses responsáveis por liberar ou bl oquear energi a de respecti vo pi no. Infrastruct ure: Cont ém cl asses com a defini ção, controle de status e referênci as para as saí das do Net dui no. Val ue Obj ect: Cont é m classes i mpl e ment adas para mani pul ação dos obj et os e interação com do da API comas portas do Net dui no. We bserver: Cont é mclasses que represent a ma troca de mensagens HTTP pr ocessados e consumi das através de umconjunt o de classes específicas I mpl e ment ação Em segui da da estrut uração do projet o dentro da I DE, e com base na análise da hist ória de usuári o da terceira iteração, foi possí vel dar iníci o à codificação do aplicati vo Applicati on A i mpl e ment ação se deu i níci o pela pasta Applicati on, que cont é mas classes e mét odos de i nicialização da aplicação. Aconcepção de i níci o ocorre a partir da classe Program. cs. Aseguir uma represent ati va é demonstrado no Quadro QUADRO 16 - Representativa da classe Progra m. (FONTE: PRÓPRI O AUTOR, 2013)

63 publiclasoncomand:icomand {publicvoidexecute(intportcomand) {OutputPortport=Ports.Instance.GetOutputPort(portComand); }}port.write(true); publicoutputportgetoutputport(int32index) publicvoidsetport(pinreceivebodypinreceivebody) {return_outputports[index]; {IComandcomand=ComandFactory.CreateComand(pinReceiveBody.Status); } comand.execute(pinreceivebody.pin); SetPortState(pinReceiveBody.Pin,pinReceiveBody.Status); 67 A li nha númer o 9 faz uma nova i nstanci a da classe Applicati on, que e m segui da na linha número 12 é aci onada para dar iníci o a aplicação. Est e mét odo est á conti do e mumtrata ment o de exceções represent ado pel o try na linha nú mer o 10, afi m de evitar erros não esperados Co mmand Na pasta Command, encontra m-se as classes de i mpl e ment ações dos mét odos responsáveis por liberar ou bl oquear a energia dos pi nos, realizando as operações de acordo com o que foi solicitado. A seguir no Quadro 17 é apresent ado uma represent ati va para liberar a energia a al gum pino. QUADRO 17 - Representativa da classe OnCo mmand. (FONTE: PRÓPRI O AUTOR, 2013) Est e mét odo espera co mo parâ metro um i nteiro, para que este busque a referênci a de saí da do pi no do net dui no, e assi mli berar a energia para o mes mo Infrastruct ure Para este projet o a pasta Infrasctrut ure, encontra-se a classe de i mpl ement ação dos mét odos responsáveis por mandar a ação para liberar a energia de acordo com a referênci a do pi no, realizando as operações de acordo como que foi solicitado. Ocódi go do mét odo responsável é apresent ado no Quadro QUADRO 18 - Mét odos que busca ma referência e faze ma ação (FONTE: PRÓPRI O AUTOR, 2013) O mét odo Get Out put Port espera como parâ metro um nú mer o do tipo i nteiro, para que este através da funci onali dade de outro mét odo i mpl ement ado busque a referênci a do pi no, este mét odo ret orna um obj et o do tipo Out put Port present e na bi bli oteca padrão do micro fra me wor k. A seguir o mét odo Set Port espera como parâ metro um obj et o do ti po Pi nrecei vebody, e cont é m as i nfor mações necessárias para cha mar o mét odo i mpl e ment ado Creat ecommand, através das funci onali dades do mesmo é adquiri do a

64 publicvoidstartlistening() {while(true) {try{using(socketclientsocket=_listeningsocket.acept() {clientsocket.receivetimeout=20; clientsocket.sendtimeout=10; }}catch(socketexceptione) ResponseRequest(clientSocket); {Debug.Print(e.Mesage+"ErorCode:"+e.ErorCode.ToString(); }catch(exceptione) }} {Debug.Print(e.Mesage); }Thread.Slep(10); publichtpstatuscodeproces(stringpath) {switch(context.method) {casehtprequestmethod.get: casehtprequestmethod.post: ProcesGetMethod(path); break; }}returnhtpstatuscode.ok; ProcesPostMethod(); break; 68 ação de ligar ou desli gar a energi a, emseguida é sal vo na me móri a o estado at ual do pi no Val ue Obj ect Em di versas aplicações orient adas a obj et os, muit os obj et os possue m u ma Identi dade. O val or desse atri but os é que diferenci a m diferent es objet os de sua classe. Portant o, umobj et o com u ma Identi dade, persiste, ou seja, existe durant e t oda aplicação. Nest e projet o as mudanças dos obj et os conti dos nestas classes durará durant e toda execução da aplicação We bserver Na pasta WebServer, encontra m-se as classes de i mpl e ment ação dos mét odos responsáveis por processar as requisições HTTP que fore m recebidas pel o servi dor, realizando as operações de acordo com o que foi solicitado ao serviço. As requisições padrão i mpl e ment adas são: GET (lista e por parâmet ro) e POST. Estas são realizadas a partir de uma aplicação at uando como cliente, o códi go responsável por esperar até que seja recebi do algum dado encontra-se no Quadro QUADRO 19 - Mét odo que espera de dados. (FONTE: PRÓPRI O AUTOR, 2013) Est e mét odo i nstanci a um obj et o do tipo Socket para que este fique aguardando at é que seja feita uma comuni cação, ao receber al go é disparado o mét odo ResponseRequest como vist o na linha 13. Omét odo é responsável por fazer al gu mas vali dações de recebi ment o de pacot es e identifica qual tipo de solicitação se refere GET ou POST que serão demonstrados a seguir, como apresent ado no Quadro QUADRO 20 - Mét odo que i dentifica a solicitação (FONTE: PRÓPRI O AUTOR, 2013) Est e mét odo espera como parâ metro uma string comas i nfor mações da URL envi ada, assi m é feita a i dentificação e disparado o mét odo correspondent e GET ou POST. Est a últi ma é realizada para a alteração de stat us dos pi nos disponí veis no

65 1 {"Pin":"0","Status":true} privatevoidgenerateresponse(pinreceivebodypinreceivebody) {Hashtablesuces; if(pinreceivebody.pin>=0&pinreceivebody.pin<=13) {Ports.Instance.SetPort(pinReceiveBody); }elsesuces=newhashtable{"suces",false}; suces=newhashtable{"suces",true}; } varesponse=newhtpresponsemesage(context); response.sendresponsejson(suces); privatevoidprocespostmethod() {vardata=context.receivedata(); } if(data=nul)return; PinReceiveBodypinReceiveBody=MounthPinReceiveBody(Hashtable)JsonSerializer.DeserializeString(data); GenerateResponse(pinReceiveBody); privatevoidprocesgetmethod(stringpath) {stringjson=string.empty; if(context.url.length-1>path.length) elseif(string.equals(context.url.length,path.length) json=alpinsresponsebody.instance.mounthresponsepinjson(context.url.substring(path.length+1); } varesponse=newhtpresponsemesage(context); response.proces(json,"aplication/js"); json=alpinsresponsebody.instance.mounthresponsepinsjson(); 69 dispositivo. Ocódi go do mét odo responsável para i nterpretar a solicitação encontra-se no Quadro QUADRO 21 - Mét odo processar solicitação POST (FONTE: PRÓPRI O AUTOR, 2013) Est e mét odo i dentifica o que foi envi ado na sequênci a do cabeçal ho HTTP, convertendo de umobjet o do tipo JSON para u mti po especifico Pi nrecei vebody. Para fazer o processo de serialização dentro do aplicati vo, é feit o uso de uma bi bli ot eca cha mada Json. Net MF, responsável por converter obj et os e msuas represent ações JSON e vice-versa. Para o context o da aplicação, a função utilizada desta bi bliot eca recebe um obj et o e ret orna uma stri ng com seu val or JSON equi val ent e. No quadr o 22 é apresent ado o exe mpl o da represent ação de um obj et o do tipo Pi nrecei vebody. QUADRO 22 - Representação JSON de um obj et o do tipo Pi nrecei vebody (FONTE: PRÓPRI O AUTOR, 2013) Em segui da é aci onado o mét odo GenareteResponse, responsável por criar, envi ar uma resposta ao client e como apresent ado no Quadro QUADRO 23 - Mét odo gerar resposta POST (FONTE: PRÓPRI O AUTOR, 2013) Est e mét odo espera como parâ metro um obj eto do tipo Pi nrecei vebody, este cont é m as infor mações de referênci a do pino e estado a ser alterado, através das funci onali dades dos mét odos i mpl e ment ados é envi ado o comando para que o mes mo seja alterado como visto na linha 8. De acordo como resultado da operação é criado um obj et o JSON para confir mar o sucesso da operação e assi menvi ado o mes mo. O mét odo responsável por processar solicitação do tipo GET é apresent ado no Quadr o 24, ele identifica se a requisição deve fornecer uma resposta emjson co m o st at us de umou vári os pi nos QUADRO 24 - Mét odo processar solicitação GET (FONTE: PRÓPRI O AUTOR, 2013)

66 1 {"Pin0":"True"} 70 Est e mét odo espera como parâ metro uma string com i nfor mações da URL infor mada, esta entende como api/ pi n/0 a solicitação de estado do pi no especificado igual a zero e, através do mét odo Mount hresponsepi njson ret orna dados do ti po JSON co m seu val or JSON equi valent e envi ado co mo resposta, como vist o na li nha 6 do Quadr o 22. No Quadr o 25 é apresent ado o exe mpl o da represent ação de uma respost a paralela. QUADRO 25 - Representação JSON de resposta GET (FONTE: PRÓPRI O AUTOR, 2013) Ao receber como parâmetro a infor mação referent e a api/ pi n, fica ent endi do que a resposta deve i ndicar o estado at ual de todos os pi nos Apresentação do sistema Já com model os de entidade e persistências defi ni dos, foi possí vel iniciar a apresent ação do aplicativo at uando como umcliente. Co m a utilização da IDE Visual St udi o, é possí vel a mont age m dos arqui vos ht ml l ayout, empregando recursos para fazer a comuni cação utilizando o prot ocol o HTTP para si mul ar um cliente utilizando os serviços do aplicati vo desenvol vi do no mi cro controlador. Cabe salientar que o pr oj et o de monstrado a seguir, se faz necessári o para apresent ar a utilização de um aplicati vo at uando como cliente comuni cando com o soft ware desenvol vi do at uando como servi dor, vist o que está sendo desenvol vi do um pr ogra ma que será e mbarcado e m um mi cro controlador, foi o meio desi gnado para utilização. Execut ando-se a aplicação e mumnavegador no dispositivo móvel, a tel a a ser mostrada é a tela gerenci a ment o web do soft ware, mostrada na Fi gura 21. FI GURA 21 - Tel a gerencia ment o web

67 71 (FONTE: PRÓPRI O AUTOR, 2013) Nest a tel a, apresent ada na Fi gura 20, é possí vel fazer co muni cação co m servi dor, utilizando o pr ot ocol o HTTP da maneira desejada, tendo em vista que o mét odo utilizado é o POST. E assi mobt endo a resposta da solicitação. Ao envi ar uma requisição do tipo POST o mi cro controlador deverá receber a mensage me i nterpreta-la, caso a comuni cação esteja dentro do padrão esperado deverá ret ornar uma mensagem de resposta obt endo sucesso. Sendo assi m, é possível salientar que o mi cro controlador processa a requisição HTTP e realiza as operações de acordo com o que foi solicitado. Utilizando o recurso POST, é então aci onado o mét odo para mani pul ação do circuit o, alterando o estado do pi no i ndi cado, e ent ão é per mitido a energi a da respecti va saí da di gital de monstrado na Fi gura 22. FI GURA 22 - Li gando LED na maquet e

68 72 (FONTE: PRÓPRI O AUTOR, 2013) Feit o isso o mi cro controlador cha ma a função que realiza a respost a HTTP, apresent ando que a requisição obt eve sucesso e assi mret ornando mensage mde respost a co mo ao cliente. Co misso, é possí vel demonstrar ao PO, a iteração do soft ware de acordo com suas defi nições reais, possi bilitando uma maneira eficient e de mani pul ar e obt er resultados de um mi cro controlador, obt endo uma maneira alternativa de aut omação resi denci al Concl usão Nest e qui nt o capit ul o foi expost o o processo de desenvol vi ment o do siste ma, separados pelas três iterações defi ni das no capít ul o 4, be m como as ferra ment as e tecnol ogi as e mpregadas no procedi ment o de impl e ment ação. At ravés de i magens das telas da maquet e e do prot óti po web, foi possí vel escl arecer mel hor as hist órias de usuári o, e logo o funci ona ment o do soft ware. Por mei o de trechos de códi go, foi plausí vel també m proporci onar ferra ment as e tecnol ogi as que fora me mpregadas no desenvol vi ment o.

69 73 6 CONSI DERAÇÕES FI NAI S Ao decorrer do levant ament o teórico deste proj et o, fez-se possí vel defi nir as funda ment ais regras de negóci o que servira m de base para a model age m e desenvol vi ment o do siste ma. Pri nci pal ment e no que diz respeit o ao cont eúdo de um livro para iniciant es co m o mi cro controlador. Este fat or foi ta mbé m a grande dificul dade desta fase do projet o, dada a carênci a de mat erial respecti vo a esta tecnol ogi a. Referent e ao mét odo de desenvol vi ment o ágil e mpregado, foi um fat or de a mpl a i mportânci a na pr odução do trabal ho por compl et o. De começo, porque se trata de um mét odo pouco e mpreendi do e mtrabalhos da i nstituição, contudo, por ser uma for ma mais eficaz de se gerenci ar umproj et o, u ma vez que a document ação do soft ware é desenvol vi da de acordo com sua i mpl e ment ação, be m quant o seus requisit os são també m be mexplicados no decorrer do te mpo. O desenvol vi ment o da maquet e se deu de for ma a possi bilitar aos interessados u m mei o si mpl es de demonstrar o soft ware em f unci ona ment o, ficando preparado para adapt ar-se a fut uras expansões nas necessi dades do usuári o. A utilização do prot óti po foi alé mda vali dação dos requisitos, ele pode, també mser utilizada na etapa de testes e experi ment os, que possibilitara m o est udo da vi abilidade do proj et o pr opost o. No caso da utilização para testes, o prot óti po auxiliou na resol ução de umdos mai ores probl e mas destes, vali dar os resultados e respostas envi adas pel o siste ma. A aplicação funci ona de modo dependent e de rede de comuni cação, ou sej a, co m qual quer tipo de conexão de rede com seus devi dos acessos. Funda ment ado nos padrões HTTP, o web server foi arquitetado ponderando t ornar-se voltado aos di versos tipos de clientes disponíveis emse tratando de co muni cação web. Est e fat or dá mar ge m ao post eri or desenvolvi ment o do aplicati vo para outras plataformas existent es no mer cado. Co mpreender os conceit os e padrões das arquitet uras consideradas HTTP se

70 74 deu como a mai or dificul dade ao l ongo do trabal ho. Fi nal ment e, quant o ao prot óti po do portal de gerenci a ment o pretende-se a expansão do mes mo, como sugestão de pesquisa fut ura, a fi m de t orná-l o uma ferra ment a mais di nâ mica e interati va, apresent ando as i nfor mações por outros mei os, aplicando por fi mos conceit os de aut omação no siste ma web.

71 75 REFERÊNCI AS BI BLI OGRÁFI CAS ÁGI L, Desenvol vi mento. Scrum. Disponí vel em: <htt p://desenvol vi mentoagil.com. br/scrum>. Acesso e m: 03 nov AL MEI DA. Atecnol ogi a por trás da mági ca. Disponí vel e m: <htt p://qui caze. com/ 126/ a- tecnol ogi a-por-tras-da- magi ca/ >. Acesso em: 1 nov AMBLER, S. W. Model age m Ágil: Práticas Efi cazes para a Programação Extre ma e o Pr ocesso Unificado. Port o Al egre: Book man, ASTELS, D. Extre me Progra mmi ng: Gui a Prático. Ri o de Janeiro: Ca mpus, BECK, K., et al. Manifesto for Agile Soft ware Devel opment, Di sponí vel e m: < htt p:// www. agile manifest o. org/ >. Acesso em: 04 Nov BELL, Mi chael. SOA: análise, desi gn e arquitet ura de servi ços. Ri o de Janeiro: Alta Books, BOLZANI, Cai o August us Morais. Resi dências i nteli gentes. São Paul o, 2004, Edit ora Física, 1º Edi ção. CASADOMO. Do mótica - Introducci ón. Agost o Disponí vel e m: <htt p:// www. casado mo.com/ >. COHN, M. Desenvol vime nt o de Soft ware com Scrum: Aplicando Mét odos Ágeis co m Sucesso. Port o Alegre: Book man, COSTA, Gust avo Henrique de Carval ho. Engenhari a de Requisitos no Desenvol vi ment o de Soft ware Ágil. Uni versidade Federal de Pernambuco, Centro de Infor mática, DEVMEDI A. Apli que os conceitos de SOA. São Paul o:. net Magazine, J OSUTTI S, Ni col ai M. SOA na Prática: Aarte da model age mde sistemas distri buí dos. Ri o de Janeiro: Alta Books, JSON. Aplicações de co muni cações REST. Di sponí vel e m < htt p://json. org/jsonpt. ht ml >. Acessado e m 6 de sete mbr o de KNI BERG, H. Scrume XP Di reto das Tri nchei ras: Co mo faze mos Scr um Di sponí vel e m < htt p://infoq. com/ br/ mi ni books/scrum- xp-fromt he-trenches>. Acesso

72 76 e m: 05 Mar MARTI N, R. C., MARTI N, M. Pri ncí pi os, Padrões e Práticas ágeis e m C#. Port o Al egre: Book man, MARTI NS, José Carl os Cordeiro. Técni cas para gerenci a ment o de projetos de soft ware. Ri o de janeiro, Edit ora Brasport, 1º Edi ção, MI LLS, Criss B. Projetando co m Maquetes: umgui a para a construção e o uso de maquetes co mo ferrame nt a de projeto. 2. ed. Port o Al egre: Bookman, p. VI. MS DN. Tea m Foundati on Server Architecture. Disponí vel em: <htt p:// msdn. mi crosoft.com/ en-us/library/ vst udi o/ ms aspx#host ed>. Acesso e m 09 nov MS DN. Vi sual St udi o. Disponí vel e m: htt p://ms dn. mi crosoft.com/ ptbr/ vst udi o/ cc Acesso e m11 de nov NETDUI NO. Hardware. Disponí vel e m: < dui no. com/ hardware/ >. Acesso e m: 18 nov NOGUEI RA, André Carreri Nogueira. Servi ce- Ori ented Architect ure (SOA). Disponí vel e m: <: htt p:// nhadecodi go. com. br/artigo/ 434/serviceorient ed-architect ure-soa. aspx>. Acesso e m: 19 nov PFI STER, Cuno. Getting Started wit h the Internet of Thi ngs. São Paul o: Sebast opol, SCHWABER, K.; BEEDLE, M. Agile Soft ware Devel opment wit h Scrum. Ne w Jersey: Prentice Hall, 2002 SCOTT, K. O Processo Unificado Explicado. Port o Al egre: Book man, SOMMERVI LLE, I. Engenhari a de Soft ware. 9 ed. São Paul o: Pearson Prentice Hall, TECMUNDO. Aut o mação resi denci al: a tecnol ogi a i nvade a sua casa. Disponí vel e m: <htt p:// mundo. com. br/casas/ 9907-aut omacao-resi dencial-a-tecnol ogi a- invade-a-sua-casa. ht m>. Acesso e m: 04 mai o WALKER. Pri mei ros passos co mo Net dui no. São Paul o: Novat ec, WAZLAWI CK, R. S. Análise e projeto de siste mas de i nfor mação orientados a objetos. Ri o de Janeiro: Elsevi er, p. WI KI PÉDI A. Mi crosoft Visual St udi o- Wi kipédi a, a Enci cl opédi a Livre. 2012c. Di sponí vel e m: < htt p://pt. wi ki pedi a. org/ wi ki/mi cr osoft _Vi sual _St udio>. Acesso e m 02 Nov

73 APÊNDI CE A ARTI GO ARQUI TETURA ORI ENTADA A SERVI ÇO APLI CADA NA AUTOMAÇÃO Ma urí ci o da Sil va Coelho, Hugo Esteva m Ro meu Longo Siste mas de Infor mação Uni versi dade do Planalto Cat ari nense ( UNI PLAC) Lages SC Brasil Departa ment o de Tecnologi a da Infor mação - Universi dade do Planalt o Catari nense mci maurici o. coel mail.com, hugoesteva mrl@g mail.com Abstract. As new devi ces e merge aut omati on t here is a difficulty in extendi ng systems. There is a need f or integrati on, thus it is essenti al a specific met hod of communi cati on in different devices. The home aut omati on can be seen i ncreasi ngl y in modern buil di ngs, enabli ng t he widespread adopti on of the Internet of Thi ngs. From the poi nt of view of the consumer, home aut omati on is a differenti al that will become a necessary suppl y. The emergence of low-cost micro controllers are the key t o t he Internet of Thi ngs. Fortunat ely, some mi cro controllers allow t o use the same programmi ng l anguage and devel opment environment. Presents a differenti al that enhances the advant ages of integrati on, provi di ng an API whi ch makes it possi bl e t o communi cat e usi ng t he key concepts of the concept of home aut omati on aggregat es Service Ori ent ed Architect ure. Res umo. À medi da que surge m novos dispositivos de aut omação existe uma dificul dade emestender sistemas. Surge ent ão a necessi dade de i ntegração, assi m, é indispensável um mét odo específico de comuni cação em diferent es dispositivos. A aut omação resi denci al pode ser vist a cada vez mais emi móveis modernos, per miti ndo a adoção generalizada da Internet das Coisas. Do pont o de vist a do consumi dor, a aut omação resi denci al é um diferenci al que irá se t ornar uma of ert a necessári a. O surgi ment o de bai xo custo de mi cro control adores são a chave para a Internet das Coi sas. Feliz ment e, al guns mi cro control adores per mitem a utilização da mes ma li nguage m de programação e ambi ent e de desenvol vi ment o. Apresent a-se um diferenci al que ref orça as vant agens de i ntegração, disponi bilizando uma API onde faz-se possível a comuni cação, utilizando os pri nci pais conceit os de domóti ca agregados ao conceit o da Arquitet ura Ori ent ada a Serviço.

74 1. Apresent ação A Tecnol ogi a disse mi nou-se a tal pont o que hoj e está ao alcance de todos, é difícil citar um ra mo ao qual a infor mática não está present e: da medi ci na, engenharia, escol as, entre outros. O ho me m busca cada vez mais a segurança, comodi dade e sofisticação, co m o auxíli o dos comput adores e siste mas i nteligent es, trazendo assi m a tecnol ogi a para seus lares como fonte contí nua de vi gília e confort o dos afazeres do mésticos. A base para o trabal ho foi a busca por uma sol ução que atendesse a al guns requisit os adi ci onais verificados ao l ongo do projet o com uma platafor ma e mbarcada, e m um mi cro controlador. A Ar quitet ura Orient ada a Serviço (SOA) na aut omação foi usado para reagir rapi da ment e a mudanças, resol ver tecni ca ment e probl e mas de mudanças na integração, facilitar o desenvol vi ment o de novas aplicações, di mi nuindo o cust o e o esforço de desenvol vi ment o dando suporte as crescentes e di versificadas de mandas por novos tipos de aplicações. Segundo Mi chael (2011), ao contrári o do desenvolvi ment o dos siste mas tradi ci onais, a met odol ogi a do serviço-orient ado ao cicl o de vi da facilita os pr ocessos de desenvol vi ment o e das operações do serviço ao fornecer os padrões e as mel hores práticas que se adapt a m às tecnol ogi as e mer gent es da i ndústria da arquitet ura do serviço-orientado. 2. Funda ment ação teóri ca Nest e capít ul o são apresent ados os assunt os para a mel hor compreensão da especificação e i mpl e ment ação do projeto, será apresent ado o tema domótica junta ment e comsuas pri nci pais características Conceito de do mótica Segundo Bol zani (2004), a domótica pode ser defini da como um conj unt o de tecnol ogi as que aj uda mna gestão e execução de tarefas domésticas coti dianas. Asua utilização te mpor obj eti vo fornecer um mai or confort o, comodi dade, segurança, alé m de proporci onar menor e mais raci onal consumo ener gético. Defi ne-se ent ão que a Do mótica é uma tecnol ogia que per mite a gestão de t odos os recursos habitaci onais si mplificando a vi da diária das pessoas e satisfazendo as suas necessi dades. É o uso da tecnol ogi a para facilitar e tornar aut omáticas al gumas tarefas habit uais que e m uma casa convenci onal ficaria a cargo de seus moradores. Co msensores de presença, temporizadores ou até um si mpl es toque e mumbot ão é possí vel aci onar cenas ou tarefas prépr ogra madas 2. 2 El e ment os básicos Em qual quer aut omação existe m ele ment os envolvi dos como sensores e centrais que supre m desej os e condi ções de cada usuári o. Dificil mente se encontrará a dómotica se m al gu m dos el e ment os: at uadores, barra ment os, controladores, interfaces e sensores Ti pos de arquitet ura A arquitet ura está relacionada na for ma de comuni cação de seus ele ment os básicos, como qual quer siste ma de control e, especifica a for ma que vão se localizar. Emum siste ma do móti co existe mduas arquitet uras básicas, descentralizada e centralizada.

75 Na arquitet ura descentralizada existe m vári os controladores interconect ados por um barra ment o, comuni ca-se entre at uadores e interfaces. A vant age m dessa arquitet ura é um siste ma robust o a fal has com grande facilidade de uso e fácil desenho das instalações. Poré m pode haver uma má relação do pont o controlado emrelação ao cust o de integração mais elevado e mfunção de tecnol ogi as empregadas. Nest a arquitet ura existe um controlador central que trans mite infor mações para el e ment os básicos. Este deve ser dot ado de i nt eligênci a e dese mpenho suficient e para receber e tratar as infor mações. Apri nci pal vant age m desta arquitet ura é aquisição co m o menor cust o. Entretant o a centralização de funções e a grande quanti dade de cabea ment o não corresponde m à filosofia dos siste mas do móticos Internet das coisas Mai s obj et os estão adquirindo a capaci dade de se co muni car resultando e mu ma rede de coisas que promet e m mel horar pr ocessos de negóci os, reduzir cust os e riscos. Omundo físico está se tornando umti po de sistema de i nfor mação, e mque é cha mado a Internet das Coisas, sensores at uadores e mbuti dos e mobj et os físicos conectados à internet despejando um enor me vol ume de dados para comput adores processare m A adoção generali zada da Int ernet das Coi sas est á a avançar, j unt ame nt e co m tecnol ogi as e a padroni zação de prot ocol os de co muni cação t ornando possí vel coletar dados desses sensores e mqual quer lugar a qual quer moment o. A medi da que as tecnologias a madurece m estão abri ndo novas front eiras para a mel horia de processos, assi mper miti ndo mai or redução de desperdíci os, custos de energi a e de intervenção humana.. 3. SOA - Arquitet ura Ori ent ada a Servi ço O conceit o do SOA, de int egração, já existe há muit o tempo, mas agora ele vei o à tona devi do à necessi dade e mer gencial de integração das tecnologias at uais. OSOA é uma met odol ogi a que visa maxi mi zar a reutilização de serviços existentes e a integração com novos serviços para aument ar a eficiência e produti vi dade de uma e mpresa. SOA é um model o de arquitet ura voltado ao desenvol vi ment o de sol uções comput aci onais. Dentro desta met odol ogi a, funcionali dades de negóci o são i mpl e ment adas por estrut uras conheci das como serviços, sendo que esta abordage m possui como um de seus pri nci pais obj etivos, per mitir a integração entre siste mas construí dos nas mais di versas pl atafor mas ( DEVMEDI A, 2011). É pratica ment e cert o que e m det er mi nado mo ment o, se fará necessári o o estabeleci ment o de al gum mei o de i ntegração entre diferentes siste mas, quer seja interna ment e dentro de uma organi zação, ou ai nda, entre aplicações da mes ma Benefíci o ao se i mpl ant ar SOA Pode mser enumerados alguns dos pri nci pais benefíci os da i mpl ant ação de sol uções orient adas a serviços: Apossi bli dade de i ntegração (i nteroperabilidade) entre siste mas desenvol vi dos nas mai s diferentes plataformas; Uma mel hor compreensão, assi mcomo uma mai or organi zação dos processos de negócio de uma organi zação, graças à ênfase na análise e na model age m da sol ução a ser construí da; Oreuso de funci onali dades criadas anteri or mente, através do uso de

76 serviços quando da i mpl ement ação de novas sol uções de soft ware; Redução de te mpo e cust os e mnovos projet os, graças ao foco no reuso de funci onali dades criadas ant erior ment e; 3. 2 Pont os de atenção ao se i mpl ant ar SOA Al guns aspect os deve m ser analisados cui dadosament e ao se optar por esta arquitet ura e m pr ojet os de soft ware, esses aspect os são: Deve-se cont ar com uma equi pe capacitada e fa miliarizada comos conceit os de orientação a servi ços; Mudanças drásticas no contrat o de um serviço pode m prej udi car a operação nor mal de aplicações que consuma m o mes mo; Pel o fat o de serviços envol vere ma trans mi ssão de dados a partir de redes, a segurança é um pont o que se mpre irá requerer atenção especial, sobret udo quando envol ver a mani pul ação de infor mações confi denciais. 4. Processo de pl anejame nt o do projeto utilizando mét odo ágil Consisti emconceit os que aborda a model age m ágil sobre o processo de desenvol vi ment o de soft ware e mpregando Scrum. Emsegui da, é de monstrada a etapa de planeja ment o Mét odos ágeis de desenvol vi ment o de soft ware Conf or me ressalta Ambl er (2004), é i mportante que se compreenda que a MA não se trata de u m processo compl et o de soft ware. Seu enfoque alcança soment e a model age m e a docu ment ação eficaz. Para que possa ser aplicada, ela deve ser utilizada em conj unt o com outros processos, tais como o XP e o SCRUM, o qual será adot ado no desenvol vi ment o da aplicação e mel hor apresent ado no decorrer do trabal ho O Processo de desenvol vi ment o co maplicação do Scrum O Scrum é um model o acessí vel e de for ma al guma é previsí vel (Schwaber K., 2004). Oferece u mconj unt o de práticas que te mcomo obj eti vo sustentar o gerencia ment o do projet o aparent e aos usuári os do model o. O pr ocedi ment o não detalha o que necessita ser feito e não deci de os pr obl e mas da companhi a, o objeti vo do Scrum é dar visi bilidade a estas dificul dades e convir como direção na resol ução dos mes mos. Os ca mi nhos a adot ar e táticas a empr egar fica a cargo de que m o i mpl ant a. Sendo assi m, é uma prática ágil para gerencia ment o de proj et os de desenvol vi ment o de software. Apesar disso, de acordo com a teoria, pode ser aplicado e m qual quer ocasi ão no qual um gr upo de pessoas com noções multi discipli nares necessit e m trabal har juntas para alcançar umobj eti vo comu m. O Scrum te m o avanço de desenvol vi ment o funda ment ado e m iterações com per manênci a entre duas e seis se manas, cha madas de Spri nts. Apri meira etapa dentro do Spri nt é a reuni ão de planeja ment o, onde o ti me ligado ao cliente defi ne o que será praticado na iteração, sendo responsabilidade do cliente concretizar a pri orização do trabal ho a ser feito.

77 4. 3 Escopo do projeto Para obt er as pri meiras hist órias de usuári o foi necessária uma reuni ão co m um client e (PO) soli cit ando uma alt ernati va de soft ware para aut omação resi denci al. Nest a reuni ão fora m levant adas al gumas hist órias de usuári os macro. A ati vi dade realizada no Spri nt I, foi defi ni da a construção de uma maquet e para a de monstração do siste ma, tendo e m vista que a automação de uma resi dência não seria viável para o projet o. O Spri nt II constitui emfiação e ele ment os utilizados para a concretização da aut omação ilustrando os eletrôni cos e a elétrica de uma resi dênci a. Por fi m no Spri nt III é o modo pel o qual o siste ma é concebi do, apresent ando a funda ment ação necessária e os model os de comunicação suportados. 5. Desenvol vi ment o do siste ma Est e capít ul o irá exi bir as aplicações e mpregadas para o desenvol vi ment o do present e trabal ho. Ta mbé m serão apresent ado os fat ores essenciais que per mita m o compl eto funci ona ment o da aplicação Ambi ente de si mul ação Após a elaboração do projet o a fase e mque as partes component es da maquet e são desenhadas ou riscadas no mat erial base, for mando a estrut ura. Ou seja, são marcadas no isopor e madeira, as paredes comsuas aberturas, as aguas do tel hado, as lajes do piso, de entrepiso e forro. Após a planificação é feito o corte das partes, é i mportante verificar a precisão das medi das antes de cortar, para não desperdi çar tempo e mat erial. Est a fase do projet o garant e a contri bui ção das met as propostas para a concl usão e apresent ação do siste ma Aut o matizar os eleme nt os básicos do a mbi ente de si mul ação A seguir é feita a fase da instalação física dos ele ment os que deve mser manipul ados pel o mi cro controlador, sendo assi mé compost o por cabos, podendo ser consi derado em u ma mbi ent e real como o projet o elétrico de uma resi dênci a. Apartir desta etapa é possí vel envi ar comandos do mi cro controlador ao eletrônico, sendo assi mé possí vel gerenciá-lo API de co muni cação co mo mi cro control ador Tendo e mvista que o espaço para de monstração do siste ma está preparado é dado sequênci a a comuni cação do mi cro controlador. Aci ma de tudo, é funda ment al ressaltar que o model o corret o de comuni cação é o prot ocol o de comunicação HTTP, segui do de uma estrut ura de dados desi gnada JSON. Est e trabal ho é focalizado no básico do prot ocol o HTTP, estando disponí veis apenas mét odos de GET e POST de monstrados nos tópi cos a seguir. Sendo assi m, existe mtrês possi bilidades de pergunt as e respostas. O pr ot ocol o HTTP opera através da troca de mensagens, pedi do e resposta entre client es e servi dores. Ambas as mensagens são compostas por uma linha de partida onde existe uma sequênci a de ca mpos no cabeçal ho e umcorpo de mensage m opci onal.

78 GEThtp:/ :8080/api/pinHTP/1.1 Host: :8080 User-Agent:Mozila/5.0(X1;U;Linuxi686;en-US;rv: )Gecko/ Ubuntu/8.10(intrepid)Firefox/3.0.3 Acept:text/html,aplication/xhtml+xml,aplication/xml;q=0.9,*/*;q=0.8 HTP/1.020OK Content-Type:aplication/js;charset=utf-8 Content-Length:19 Conection:close {"Pin10":"False","Pin9":"False","Pin1":"False","Pin1":"False","Pin8":"False","Pin0":"False","Pin12":"False","Pin3":"False","Pin6":"False","Pin5":"False","Pin4":"False","Pin7":"False","Pin2":"False"} POSThtp:/ :8080/api/pinHTP/1.1 User-Agent:Fidler Host: :8080 Content-Length:26 {"Pin":"4","Status":true} Nest e tópico é de monstrada a comuni cação baseada e mrequisições e respostas. Sendo assi m, a mes ma necessita começar com uma solicitação, o model o de requisição utilizado no mi cro controlador é apresentado no Quadr o abai xo. Requisição GET Tendo e m vista que a linha númer o 1 cont é m a palavra GET com si gnificado de adquirir um cont eúdo que se encontra no l ocal indi cado por htt p:// :8080/ api/ pi n. Do mes mo modo na linha númer o 2, é identificado o host indicado pel o text o Host: :8080, este te mcomo si gnificado uma solicitação do cliente ao servi dor que se encontra e m / api/ pi n no host. Nest e senti do, a linha nú mer o 3 mostra que m está fazendo a solicitação ao servi dor defi ni do pel o user agente no exe mpl o aci ma é o navegador Mozilla. Evi dent e ment e, a linha 4 mostra os recursos aceit os pel o cliente de maneira correta. Todas as solicitações feitas é segui da de uma resposta devi da ment e ponderada o quadr o a seguir apresent a a resposta adequada do servi dor quando a mes ma é devi da ment e processada. Resposta GET Est a é uma resposta do mi cro controlador trabal hando como umservi dor web, a pri meira linha corresponde a resposta da requisição be msucedi da (200 OK), o client e deverá receber o que estava aguardando. A li nha númer o 2 mostra o tipo do document o que será envi ado ao cliente, no exe mpl o aci ma i ndica um arqui vo JSON segui do da codificação que o arqui vo está utilizando. Por segui nte, é de monstrada na linha númer o 3 o Content- Lengt h o mes mo constitui na quanti dade de caracteres present es na resposta para o cliente. Sendo assi m, na quarta linha é indi cado que a conexão com o servi dor foi finalizada, acompanhado do cont eúdo do arqui vo ou recurso requisitado pel o cliente, no caso est udado um arqui vo JSONi nfor mando se os pi nos estão ligados ou desli gados. Assi m mes mo, existe a possi bilidade de requisitar uma consulta especifica para det er mi nado parâ metro, deve ser infor mado no host da solicitação co mo por exe mpl o api/ pi n/ 0 e e msegui da deverá ret ornar uma resposta como pi no especificado e o seu estado. Não obstant e, é de monstrada a comuni cação proposta para envi o de dados ao progra ma situado no host especificado. Sendo assi m, a mesma necessita começar com u ma solicitação do tipo POST acompanhado de dados no for mat o JSON que deverá cont er a inf or mação do pi no e situação desejada. O model o de requisição POST utilizado no mi cro controlador é apresent ado no quadro a seguir. Requisição POST Tendo e m vista que a linha númer o 1 cont é m a pal avra POST com si gnificado de envi ar dados ao local indicado por htt p:// :8080/ api/ pi n. Nest e senti do, a linha númer o 2 constitui no host indicado pel o text o Host: :8080, este tem como si gnificado envi ar dados do cliente ao servi dor que se encontra e m / api/ pi n. Do mes mo modo, a linha nú mer o 3 apresent a que m encontra-se comet endo a solicitação ao servi dor deter mi nado pel o user agent e. No exe mpl o aci ma equi vale ao soft ware Fi ddl er.

79 HTP/1.020OK Content-Type:aplication/json;charset=utf-8 Content-Length:15 Conection:close {"Suces":true} Evi dent e ment e, a quarta linha mostra a quanti dade de dados a ser envi ados, acompanhado dos dados. A seguir é de mostrado a resposta do servi dor, é possí vel observar que o corpo da mensage mcont é ma situação do processa ment o dos dados de acordo como recurso requisitado no for mat o JSON. Resposta POST Sendo assi m, a utilização do mét odo POST pode resultar e m dois tipos diferentes, podendo ser como ca mpo Sucess verdadeiro ou falso Estrut uração do projeto Após a escol ha da platafor ma e do a mbi ent e de desenvol vi ment o da aplicação, foi possí vel iniciar a estrut uração do pr ojet o dentro da I DE, paralela ment e à idealização da arquitet ura do aplicativo. Afi gura a seguir de monstra essa composição por mei o de separação de pastas. Cabe salientar que apesar do projet o ser desenvol vido no Visual St udi o, se faz necessári o tomar al guns cui dados na estrut uração, vist o que está sendo desenvol vi do um pr ogra ma que será e mbarcado e mum micro controlador, dispondo muit o menos recursos em co mparação com servi dores e comput adores pessoais. Dentro de uma aplicação padrão do Net dui no, o projet o desti nado às classes desenvol vi das é deno mi nado Net dui no. Server. Apartir deste, são criados as pastas para mel hor or gani zação estrut ural do siste ma. O pr oj et o do Net dui no. Server, foi separado nas segui ntes pastas: Applicati on: Cont é m classes de inicialização do mi cro controlador na rede e trata ment o de erros; Co mmand: Cont é mas classes responsáveis por liberar ou bl oquear energia de respecti vo pi no.

80 namespacenetduino {publiclasprogram {privatestaticaplicationaplication; publicstaticvoidmain() {aplication=newaplication(); try{aplication.init(); }catch(exceptione) } }}} {Debug.Print(e.Mesage); namespacenetduino.server.comand {publiclasoncomand:icomand {publicvoidexecute(intportcomand) {OutputPortport=Ports.Instance.GetOutputPort(portComand); } }}port.write(true); publicoutputportgetoutputport(int32index) publicvoidsetport(pinreceivebodypinreceivebody) {return_outputports[index]; {IComandcomand=ComandFactory.CreateComand(pinReceiveBody.Status); } comand.execute(pinreceivebody.pin); SetPortState(pinReceiveBody.Pin,pinReceiveBody.Status); Infrastruct ure: Cont é mcl asses coma defi nição, controle de stat us e referênci as para as saí das do Net dui no. Val ue Obj ect: Cont é mclasses i mpl e ment adas para mani pul ação dos objetos e i nteração com do da API comas portas do Net dui no. WebSer ver: Cont é m classes que represent a m a troca de mensagens HTTP processados e consumi das através de um conj unt o de classes específicas I mpl e ment ação Em segui da da estrut uração do projet o dentro da I DE, e com base na análise da hist ória de usuári o da terceira iteração, foi possí vel dar iníci o à codificação do aplicativo A i mpl e ment ação se deu iníci o pela pasta Application, que cont é mas classes e mét odos de i nicialização da aplicação. A concepção de iníci o ocorre a partir da classe Program. cs. A seguir uma represent ati va é de monstrado no quadro abai xo A li nha númer o 9 faz uma nova i nstancia da classe Applicati on, que e msegui da na li nha nú mer o 12 é aci onada para dar iníci o a aplicação. Est e mét odo está conti do emumtrata ment o de exceções represent ado pel o try na linha número 10, afi mde evitar erros não esperados. Na pasta Co mmand, encontra m-se as classes de i mpl e ment ações dos mét odos responsáveis por liberar ou bl oquear a energia dos pi nos, realizando as operações de acor do com o que foi solicitado. Aseguir no Quadr o a seguir é apresent ado uma represent ati va para liberar a energi a a al gumpi no Est e mét odo espera como parâ metro umi nteiro, para que este busque a referênci a de saí da do pi no do net dui no, e assi mli berar a energia para o mes mo. Para este projet o a pasta Infrasctrut ure, encontra-se a classe de i mpl e ment ação dos mét odos responsáveis por mandar a ação para liberar a energia de acordo co m a referênci a do pi no, realizando as operações de acordo com o que foi solicitado. O códi go do mét odo responsável é apresent ado no quadro abai xo O mét odo Get Out put Port espera como parâ metro u m númer o do tipo i nteiro, para que este através da funci onalidade de outro mét odo i mpl e ment ado busque a referência do pi no, este mét odo ret orna um objet o do tipo Out put Port present e na bi bli oteca padrão do mi cr o frame work. A seguir o mét odo Set Port espera como parâ metro um obj et o do tipo Pi nreceivebody, e cont é m as infor mações necessárias para cha mar o mét odo i mpl e ment ado Creat ecommand, através das funci onali dades do mes mo é adquirido a ação de ligar ou desligar a energi a, e m segui da é sal vo na me mória o estado at ual do pi no. Em di versas aplicações orientadas a objet os, muitos obj et os possue m uma Identi dade. O val or desse atribut os é que diferencia mdiferentes obj et os de sua classe. Portant o, umobj et o com uma Identi dade, persiste, ou seja, existe durant e toda aplicação. Nest e projet o as mudanças dos objet os conti dos nestas classes durará durant e t oda execução da aplicação.

81 1 {"Pin":"0","Status":true} publicvoidstartlistening() {while(true) {try{using(socketclientsocket=_listeningsocket.acept() {clientsocket.receivetimeout=20; clientsocket.sendtimeout=10; {Debug.Print(e.Mesage+"ErorCode:"+e.ErorCode.ToString(); }}catch(socketexceptione) ResponseRequest(clientSocket); }catch(exceptione) }} {Debug.Print(e.Mesage); }Thread.Slep(10); publichtpstatuscodeproces(stringpath) {switch(context.method) {casehtprequestmethod.get: casehtprequestmethod.post: ProcesGetMethod(path); }}returnhtpstatuscode.ok; ProcesPostMethod(); break; privatevoidgenerateresponse(pinreceivebodypinreceivebody) {Hashtablesuces; if(pinreceivebody.pin>=0&pinreceivebody.pin<=13) {Ports.Instance.SetPort(pinReceiveBody); }elsesuces=newhashtable{"suces",false}; varesponse=newhtpresponsemesage(context); suces=newhashtable{"suces",true}; } response.sendresponsejson(suces); privatevoidprocespostmethod() {vardata=context.receivedata(); } if(data=nul)return; PinReceiveBodypinReceiveBody=MounthPinReceiveBody(Hashtable)JsonSerializer.DeserializeString(data); GenerateResponse(pinReceiveBody); privatevoidprocesgetmethod(stringpath) {stringjson=string.empty; if(context.url.length-1>path.length) elseif(string.equals(context.url.length,path.length) varesponse=newhtpresponsemesage(context); json=alpinsresponsebody.instance.mounthresponsepinjson(context.url.substring(path.length+1); response.proces(json,"aplication/js"); json=alpinsresponsebody.instance.mounthresponsepinsjson(); } Na pasta WebServer, encontra m-se as classes de i mpl e ment ação dos mét odos responsáveis por processar as requisições HTTP que fore mrecebi das pel o servi dor, realizando as operações de acordo co m o que foi solicitado ao serviço. As requisições padrão impl e ment adas são: GET (lista e por parâ metro) e POST. Est as são realizadas a partir de u ma aplicação at uando co mo cliente, o códi go responsável por esperar at é que seja recebi do al gu m dado encontra-se no quadr o abai xo Est e mét odo i nstancia um obj et o do tipo Socket para que este fique aguardando até que seja feita uma comuni cação, ao receber al go é disparado o mét odo ResponseRequest como vist o na linha 13. O mét odo é responsável por fazer al gumas vali dações de recebiment o de pacot es e identifica qual tipo de solicitação se refere GET ou POST que serão demonstrados a seguir, como apresent ado no quadr o a seguir Est e mét odo espera como parâ metro uma stri ng co m as infor mações da URL envi ada, assi mé feita a identificação e disparado o mét odo correspondent e GET ou POST. Est a últi ma é realizada para a alteração de stat us dos pi nos disponí veis no dispositivo. O códi go do mét odo responsável para interpretar a solicitação encontra-se no quadro a seguir Est e mét odo i dentifica o que foi envi ado na sequênci a do cabeçal ho HTTP, convertendo de um obj et o do tipo JSON para umti po especifico Pi nreceivebody. Para fazer o processo de serialização dentro do aplicativo, é feito uso de uma bi bli oteca chamada Json. Net MF, responsável por converter objet os e msuas represent ações JSON e vice-versa. Para o cont ext o da aplicação, a função utilizada desta bi bli oteca recebe umobj et o e ret orna u ma stri ng comseu val or JSON equi val ent e. No quadr o 22 é apresent ado o exe mpl o da representação de umobj et o do tipo Pi nreceivebody. Emsegui da é aci onado o mét odo Genaret eresponse, responsável por criar, envi ar uma resposta ao cliente como apresent ado no quadro abai xo Est e mét odo espera como parâ metro umobj et o do tipo Pi nreceivebody, este cont é mas infor mações de referência do pi no e estado a ser alterado, através das funci onali dades dos mét odos i mpl e ment ados é envi ado o comando para que o mes mo seja alterado como vist o na linha 8. De acordo com o resultado da operação é criado um obj et o JSON para confir mar o sucesso da operação e assi menvi ado o mes mo. O mét odo responsável por processar solicitação do tipo GET é apresent ado no quadr o a seguir, ele identifica se a requisição deve fornecer u ma resposta e mjson co m o stat us de um ou vári os pi nos

82 1 {"Pin0":"True"} Est e mét odo espera como parâ metro uma stri ng co mi nfor mações da URL infor mada, esta entende como api/pi n/ 0 a solicitação de estado do pi no especificado i gual a zero e, através do mét odo MounthResponsePi njson ret orna dados do tipo JSON co m seu val or JSON equi valente envi ado como resposta. No quadro a bai xo é apresent ado o exe mpl o da represent ação de uma resposta paralela. Ao receber como parâ metro a infor mação referent e a api/ pi n, fica ent endi do que a resposta deve i ndicar o estado at ual de todos os pinos Apresent ação do Siste ma Em Já com model os de enti dade e persistênci as defi ni dos, foi possí vel iniciar a apresent ação do aplicativo at uando como umcliente. Co ma utilização da I DE Vi sual St udi o, é possí vel a mont age mdos arqui vos ht ml layout, e mpregando recursos para fazer a comuni cação utilizando o prot ocol o HTTP para si mul ar um client e utilizando os serviços do aplicativo desenvol vi do no mi cro controlador. Cabe salientar que o projet o de monstrado a seguir, se faz necessári o para apresent ar a utilização de um aplicativo at uando como cliente comuni cando com o soft ware desenvol vi do at uando como servi dor, vist o que está sendo desenvol vi do um progra ma que será e mbarcado e mum mi cro controlador, foi o mei o desi gnado para utilização. Execut ando-se a aplicação e mumnavegador no dispositivo móvel, a tela a ser mostrada é a tela gerenci a ment o web do soft ware, mostrada na figura abai xo. Nest a tela, apresent ada, é possí vel fazer comuni cação com servi dor, utilizando o pr ot ocol o HTTP da maneira desejada, tendo e mvista que o mét odo utilizado é o POST. E assi m obt endo a resposta da solicitação. Ao envi ar uma requisição do tipo POST o mi cro controlador deverá receber a mensage m e i nterpreta-la, caso a co muni cação esteja dentro do padrão esperado deverá ret ornar uma mensage m de resposta obt endo sucesso. Sendo assi m, é possí vel salient ar que o mi cro controlador processa a requisição HTTP e realiza as operações de acordo com o que foi solicitado. Utilizando o recurso POST, é ent ão