Você está na página 1de 180

UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO CIN - CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

PRTICAS PARA A ESPECIFICAO DE ARQUITETURAS DE SOFTWARES NO CONTEXTO DE MQUINAS SOCIAIS PARA A WEB 3.0

POR

ELAINE GLEYCE MIRA DE FIGUEIREDO DISSERTAO DE MESTRADO

RECIFE
AGOSTO DE 2012

UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO CIN - CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

Elaine Gleyce Mira de Figueiredo

PRTICAS PARA A ESPECIFICAO DE ARQUITETURAS DE SOFTWARES NO CONTEXTO DE MQUINAS SOCIAIS PARA A WEB 3.0
Dissertao apresentada como requisito parcial para a obteno do ttulo de Mestre em Cincias da Computao, rea de concentrao em Engenharia de Software pelo Programa de Ps-Graduao em Cincias da Computao do Centro de Informtica da Universidade Federal de Pernambuco

Orientador: Silvio Romero de Lemos Meira, PhD Co-Orientador: Vinicius Cardoso Garcia, PhD

RECIFE
AGOSTO DE 2012

Laysa

AGRADECIMENTOS

Primeiramente agradeo a Deus e Nossa Senhora de Nazar por estarem presentes em nossas vidas nos dando sade e luz. Muitos no sabem o que concretizar um trabalho desta natureza, e talvez por este motivo no vejam com admirao pessoas que, como eu, dedicaram dois anos de sua vida a um mestrado. Entretanto, existem outras pessoas que valorizam o estudo e o amor a uma rea da cincia por acreditarem justamente que trabalhos como este podem agregar na vida, no ensino, na indstria, e no saber; so para estas pessoas que deixo meus sinceros agradecimentos. Aos meus amados pais pelo cuidado e apoio de sempre. Ao meu admirado orientador Silvio Meira, por me contagiar com a inquietao de sua mente, e por se fazer sempre presente mesmo que ausente. Ao meu tambm orientador Vinicius Garcia, pela exigncia de sempre, por me direcionar e ensinar. Aos amigos verdadeiros pelo forte incentivo. Universidade Federal de Pernambuco UFPE, que fez a minha caminhada neste mestrado ser extremamente promissora, pelas condies de ensino oferecidas. Aos inteligentssimos Prof. Leandro Marques, Prof. Paulo Borba, Prof. Sergio Soares, Vanilson Burgio, Misael Neto, e Thiago Vieira; pessoas que sempre estiveram dispostas a me ajudar, e que de forma direta, contribuiram para a realizao deste trabalho. empresa MV Informtica Nordeste pela confiana.

Lack of time is excuse for who loses time due to lack of methods (Albert Einstein)

No acredito em uma arquitetura ideal, insubstituvel; somente em boa e m arquitetura. Gosto de Le Corbusier como gosto de Mies, de Picasso como de Matisse, de Machado como de Ea. (Oscar Niemeyer)

"Ns raciocinamos hoje apenas em termos do que tornaria mais fcil para as pessoas a utilizao do computador. Pode ser que tenha chegado a hora de perguntar o que tornaria mais fcil para o computadore lidar com seres humanos. Por exemplo: como possvel conversar com pessoas quando nem sequer se sabe que esto presentes? Voc no pode v-las, e nem sabe quantas so. Ser que esto sorrindo? Falamos desejosos sobre interaes humano-mquina, sistemas dialgicos e, no entanto, estamos dispostos a deixar no escuro total um dos participantes deste dilogo. Est na hora de fazer com que os computadores vejam e ouam."

Traduo de trecho do livro A vida digital do ano 1995 (Nicholas Negroponte)

RESUMO
A Internet se modifica a uma velocidade considervel, e os responsveis por tal transformao so, em grande parte, as aplicaes que a compem. O que conduz ao seguinte questionamento: os profissionais e pesquisadores de TI estariam suficientemente preparados para garantir solues prticas e pertinentes ao desenvolvimento de tais aplicaes? Esta dissertao consiste na recomendao de um conjunto de prticas para se desenhar arquiteturas de software no contexto de Social Machines, ou Mquinas Sociais (SMs). SMs so aplicaes que se relacionam em rede para disponibilizar determinado servio. O produto desta dissertao foi fruto de uma extensa pesquisa que se empenhou em fortalecer os conceitos de SMs, bem como em desenvolver um estudo de reviso de literatura que serviu de alicerce para a proposta de uma arquitetura de referncia para as SMs. Isto posto, prticas foram lanadas afim de auxiliar na customizao desta arquitetura e, principalmente, orientar sobre a construo de SMs. Todos os conceitos abordados e resultantes foram fortemente baseados na realidade da Web 3.0, internet que traz alteraes significativas ao modo de se fazer negcio em rede. O que caracteriza a Web 3.0 a facilidade em reprogramar suas aplicaes e fazer com que elas interajam de forma a interligar negcios, servios e pessoas. No contexto da Web 3.0 as SM so protagonistas, tudo neste ambiente funciona por meio destas. Assim, o desenvolvimento desta pesquisa explora diversos conceitos dentro da engenharia de software, alm de exibir duas avaliaes dos artefatos de software gerados pelo trabalho, a primeira executada por meio de um mtodo de inspeo, e a segunda por meio de um estudo de caso.

Palavras-Chave: Cloud Computing; Web 3.0; Mquinas Sociais; Arquitetura de Referncia; Tecnologias; Aplicaes Web; Prticas, Avaliaes. VI

ABSTRACT
The Internet is changing at a considerable speed, and the applications that comprise it are the most responsible for that, what leads us to the following question: would professionals and researchers in IT be sufficiently prepared to ensure practical and relevant solutions to the development of such applications? The current dissertation consists on a set of recommended practices for designing software architectures in the context of Social Machines (SM's). SMs are applications that connect in network to provide a determined service. The dissertation's product is the result of an extensive research that endeavoured to reinforce the SM concept and to develop a study of literature review that laid the foundations for the proposal of a reference architecture for the SM's. In this sense, the practices have been launched to provide support to the customization of this architecture, and particularly to conduct the construction of SM's. All adressed and resultant concepts were strongly based on the Web 3.0 reality, an internet that brings significant changes in network business ways. The mainly web 3.0 feature is the facility to reprogram its applications and make them interact to connect business, services and people. The SMs are the main element considering the Web 3.0 context; the entire environment works trough it. Therefore, this research explores different concepts in software engineering, also showing two software artifacts evaluations: the first through an inspection method, and the other through a case study.

Keywords: Cloud Computing; Web 3.0; Social Machines; Architecture of reference; Technologies; Web Aplications; Guidelines, Reviews.

VII

LISTA DE ILUSTRAES

FIGURA 1. REPRESENTAO DA ESTRUTURA DE CLOUD COMPUTING .................................. 16 FIGURA 2. REPRESENTAO DA MQUINA SOCIAL .................................................................... 17 FIGURA 3. ESTILO ARQUITETURAL CAMADAS .............................................................................. 28 FIGURA 4. NUMERO DE ESTUDOS POR QUESTO DE PESQUISA ................................................ 35 FIGURA 5. ARQUITETURA MASHUP POR DUANE MERRIL ........................................................... 37 FIGURA 6. ARQUITETURA CLOUD COMPUTING POR VECCHIOLA ............................................ 42 FIGURA 7. ARQUITETURA DE REFERNCIA PARA CLOUD COMPUTING POR KOSSMANN, KRASKA E LOESING, 2010. ................................................................................................................ 42 FIGURA 8. ARQUITETURA DE REFERNCIA CLOUD COMPUTING PROPOSTA PELA IBM ..... 44 FIGURA 9. ESBOO DA ARQUITETURA MULTITENANT ............................................................... 48 FIGURA 10. ARQUITETURA DO TWITTER......................................................................................... 50 FIGURA 11. ESBOO DE ARQUITETURA PARA SISTEMAS AUTNOMOS ................................. 54 FIGURA 12. ARQUITETURA DE REFERNCIA PROPOSTA PELA EMPRESA IBM PARA COMPUTAO AUTNOMA ............................................................................................................ 55 FIGURA 13. ARQUITETURA DE REFERNCIA PARA APLICAES WEB 2.0 .............................. 57 FIGURA 14. RELAO ENTRE MODELO DE REFERNCIA, PADRES ARQUITETURAIS E ARQUITETURA DE REFERNCIA..................................................................................................... 65 FIGURA 15. ARQUITETURA DE REFERNCIA PARA SMS ............................................................ 69 FIGURA 16. VISO DE IMPLANTAO .............................................................................................. 73 FIGURA 17. DIAGRAMA DE CLASSE (VISO DE MDULOS_WRAPPER E PROCESSING UNIT) ................................................................................................................................................................ 74 FIGURA 18. DIAGRAMA DE COMPONENTES: VISO DE COMPONENTES E CONECTORES ... 76 FIGURA 19. DIAGRAMA DE SEQUNCIA: VISO EM TEMPO DE EXECUO ........................... 77 FIGURA 20. RESULTADO DA AVALIAO (1 E 2 RODADA) ........................................................ 86 FIGURA 21. EXEMPLO DE MODELAGEM DE UM PROCESSO ........................................................ 95 FIGURA 22. REPRESENTAO DO FRAMEWORK DE COMUNICAO PARA AS SMS ......... 104 FIGURA 23. ABSTRAO DA ARQUITETURA DE REFERNCIA (TECNOLOGIAS) ................. 124 FIGURA 24. EDITOR NO MODO DE CRIAO DE DOCUMENTOS NO MVPEP (VERSO 1.5) . 135 FIGURA 25. DOCUMENTO/TELA DO EDITOR SENDO UTILIZADO POR UM USURIO FINAL NO MVPEP (VERSO 1.5) ................................................................................................................. 135

VIII

LISTA DE TABELAS

TABELA 1. CARACTERSTICAS E NECESSIDADES DAS SMS ...................................................... 21 TABELA 2. MATERIAIS SELECIONADOS PARA O ESTUDO ........................................................... 36 TABELA 3. PONTOS OU ASPECTOS MAIS TRABALHADOS PELAS ARQUITETURAS ............... 62 TABELA 4. ATENDIMENTO AOS REQUISITOS PELA ARQUITETURA CONFORME AS CARACTERSTICAS E NECESSIDADES DA SM. ............................................................................. 68 TABELA 5. QUESTES ANALISADAS PELO CHECKLIST E RESPOSTAS ESPERADAS ............. 85 TABELA 6. PADRES ESTRUTURAIS RELEVANTES PARA AS SMS ......................................... 117 TABELA 7. PADRES COMPORTAMENTAIS RELEVANTES PARA AS SMS ............................ 118 TABELA 8. RELAO ENTRE OS PADRES DE PROJETO E OS REQUISITOS NO FUNCIONAIS DAS SMS ................................................................................................................... 118 TABELA 9. RELAO ENTRE AS PRTICAS E OS REQUISITOS NO FUNCIONAIS ............... 123

IX

LISTA DE ABREVIATURAS E SIGLAS

SMs AR AS PaaS SaaS IaaS MVPEP SOA WEB CC TI BPMN Apps BD Fb WSDL PMEs SLAs

Social Machines Arquitetura de Referncia Arquitetura de Software Plataform as a Service Software as a Service Infrastructure as a Service Pronturio Eletrnico do Paciente Service-oriented Architecture World Wide Web Cloud Computing Tecnologia da Informao Business Process Modeling Notation Aplicativos WEB Base de Dados Facebook
Web Service Definition Language

Pequenas e Mdias Empresas Service Level Agreement

SUMRIO
RESUMO.................... ............................................................................................................. VI ABSTRACT.. .................................................................................................................. VII LISTA DE ILUSTRAES ...................................................................................................... VIII LISTA DE TABELAS................................................................................................................. IX LISTA DE ABREVIATURAS E SIGLAS ........................................................................................

SUMRIO................................................................................................................................ XI

1. INTRODUO ....................................................................................................................... 1
1.1 APRESENTAO E CONTEXTO ................................................................................................................. 2 1.2. JUSTIFICATIVA E MOTIVAO DO TRABALHO ......................................................................................... 3 1.3 PROBLEMTICA ...................................................................................................................................... 5 1.4. OBJETIVOS: ............................................................................................................................................ 8 1.4.1. GERAL .............................................................................................................................................. 8 1.4.2. ESPECFICO ....................................................................................................................................... 9 1.5. TRABALHOS RELACIONADOS.................................................................................................................. 9 1.6. CONTRIBUIO E RESULTADOS ESPERADOS ......................................................................................... 11 1.7. ESTRUTURA DO TRABALHO .................................................................................................................. 11

2. MQUINAS SOCIAIS............................................................................................................ 13
2.1. O CONTEXTO DAS MQUINAS SOCIAIS .................................................................................................. 14 2.2. CONCEITO DE MQUINAS SOCIAIS ........................................................................................................ 17 2.3. CARACTERSTICAS DAS MQUINAS SOCIAIS ......................................................................................... 19 2.4. TAXONOMIA DAS MQUINAS SOCIAIS .................................................................................................. 21 2.5. EXEMPLOS DE MQUINAS SOCIAIS ....................................................................................................... 22 2.5.1. EUCALYPTUS: ................................................................................................................................. 22 2.5.2. CLOUD AV: ..................................................................................................................................... 22 2.5.3. MAP REDUCE: ................................................................................................................................. 23 2.5.4. WEB SEMNTICA: ........................................................................................................................... 24 2.6. CONSIDERAES FINAIS DO CAPTULO ................................................................................................. 25

3. REVISO DA LITERATURA DE

ARQUITETURAS DE SOFTWARE PARA MQUINAS SOCIAIS 26

3.1. INTRODUO ....................................................................................................................................... 27 3.2. ARQUITETURA DE SOFTWARE............................................................................................................... 27 3.3. PROCESSO DE REVISO......................................................................................................................... 30 3.3.1. QUESTO A SER INVESTIGADA: ...................................................................................................... 30

XI

3.3.2. QUESTES DE PESQUISA: ................................................................................................................ 31 3.3.3. REPOSITRIOS DE BUSCA................................................................................................................ 33 3.3.4. IDENTIFICAO DO MATERIAL ....................................................................................................... 33 3.3.5. CRITRIOS DE CLASSIFICAO - INCLUSO:................................................................................... 33 3.3.6. CRITRIOS DE CLASSIFICAO - EXCLUSO: .................................................................................. 34 3.3.7. REGISTRO DO MATERIAL ................................................................................................................ 34 3.3.8. RESULTADO.................................................................................................................................... 34 3.4. DEMONSTRAO DOS RESULTADOS DAS ARQUITETURAS DE REFERNCIA INVESTIGADAS ................... 36 3.4.1. ARQUITETURA DE REFERNCIA PARA MASHUPS QP1 .................................................................... 36 3.4.1.1. ARQUITETURA MASHUP PROPOSTA POR MERRIL EM 2006 ......................................................... 37 3.4.1.2. ARQUITETURA MASHUP PROPOSTA POR LIU EM 2009 ............................................................... 38 3.4.2. ARQUITETURA DE REFERNCIA PARA CLOUD COMPUTING QP2 ..................................................... 39 3.4.2.1. ARQUITETURA CLOUD COMPUTING PROPOSTA POR VECCHIOLA ............................................... 40 3.4.2.2. ARQUITETURA CLOUD COMPUTING PROPOSTA POR KOSSMANN, KRASKA E LOESING. ............. 42 3.4.2.3. ARQUITETURA CLOUD COMPUTING PROPOSTA PELA EMPRESA IBM ....................................... 43 3.4.3. ARQUITETURA MULTITENANT DE REFERNCIA PARA SOFTWARE AS A SERVICE QP2 .................... 47 3.4.4. ARQUITETURA PARA REDES SOCIAIS QP3 .................................................................................... 49 3.4.5. ARQUITETURA DE REFERNCIA PARA SISTEMAS AUTNOMOS QP4.............................................. 52 3.4.5.1. ARQUITETURA AUTNOMA PROPOSTA POR MCCANN, HUEBSCHER E WHITE ET AL .................... 53 3.4.5.2. ARQUITETURA AUTNOMA PROPOSTA PELA EMPRESA IBM ....................................................... 55 3.4.6. ARQUITETURA DE REFERNCIA PARA APLICAES WEB 2.0 QP5 ................................................. 56 3.5. CONSIDERAES FINAIS DO CAPTULO CRTICAS ............................................................................... 59

4. PROPOSTA DE ARQUITETURA DE REFERNCIA PARA MQUINAS SOCIAIS .................... 63


4.1. INTRODUO ....................................................................................................................................... 64 4.2. ARQUITETURA DE REFERNCIA ............................................................................................................ 64 4.3. ARQUITETURA DE REFERNCIA PARA MQUINAS SOCIAIS .................................................................... 66 4.4. VISES DA ARQUITETURA DE REFERNCIA ........................................................................................... 72 4.5. AVALIAO DA ARQUITETURA DE REFERNCIA E DE SUAS VISES ...................................................... 78 4.5.1. TCNICA DE INSPEO ................................................................................................................... 79 4.5.1.1. PERFIL DOS AVALIADORES (INSPETORES) ................................................................................ 80 4.5.1.2. TAXONOMIA DOS DEFEITOS A SEREM ENCONTRADOS ............................................................. 80 4.5.1.3. PROCESSO DE INSPEO (AVALIAO) .................................................................................... 81 4.5.1.4. CORREO DOS ERROS ENCONTRADOS ................................................................................... 81 4.5.2. RESULTADOS............... ................................................................................................................... 82 4.6. CONSIDERAES FINAIS DO CAPTULO ................................................................................................. 88

5. RECOMENDAO

DE

PRTICAS PARA DESENVOLVER ARQUITETURAS

DE

MQUINAS

SOCIAIS...................................................................................................................... 90
5.1. INTRODUO ....................................................................................................................................... 91

XII

5.2. PRTICAS NA METODOLOGIA PARA CONCEPO DE ARQUITETURAS E EM TRABALHOS RELACIONADOS ................................................................................................................................................................ 91 5.3. PRTICAS RECOMENDADAS.................................................................................................................. 93 5.3.1. PRTICA 1: MODELAR PROCESSOS E SUB-PROCESSOS DE NEGCIO DE SERVIO ............................. 94 5.3.2. PRTICA 2: RECONHECER OS SERVIOS PROVIDOS E REQUERIDOS PARA O FUNCIONAMENTO DA
MQUINA SOCIAL........ ............................................................................................................................. 95

5.3.3. PRTICA 3: CONHECER OS PROVEDORES E REQUISITANTES DOS SERVIO DA APLICAO .............. 97 5.3.4. PRTICA 4: VERIFICAR A NECESSIDADE DE RECURSOS QUE TORNEM A APLICAO AUTO
GERENCIVEL E COMO ESSES RECURSOS PODEM SER IMPLEMENTADOS. .................................................. 99

5.3.5. PRTICA 5: DETERMINAR OS RECURSOS QUE IMPLEMENTARO OS ELEMENTOS COMMUNICATIONS ,


CONSTRAINTS E REQUESTS ..................................................................................................................... 101

5.3.6. PRTICA 6: ADOTAR ESTRATGIAS PARA SANAR AS FRAQUEZAS DO ESTILO ARQUITETURAL


CAMADAS................................................................................................................................................104

5.3.7.

PRTICA

7:

DETERMINAR

RECURSO

QUE

PROVER

COMUNICAO

INTEROPERABILIDADE......... .................................................................................................................. 106

5.3.8. PRTICA 8: SELECIONAR O RECURSO CLOUD COMPUTING A SER ADOTADO NA SM.................... 109 5.3.9. PRTICA 9: SELECIONAR OS PADRES DE PROJETO MAIS ADEQUADOS PARA A ARQUITETURA DA
MQUINA SOCIAL................ ................................................................................................................... 115

5.3.10. PRTICA 10: SELECIONAR O BANCO DE DADOS NO RELACIONAL ............................................. 119 5.4. CONSIDERAES FINAIS DO CAPTULO ............................................................................................... 120

6. EXPERIMENTAO DAS PRTICAS ................................................................................. 125


6.1. INTRODUO ..................................................................................................................................... 126 6.2. DEFINIO DOS OBJETIVOS ................................................................................................................ 126 6.3. PLANEJAMENTO ................................................................................................................................. 128 6.3.1. OBJETO DE CONTROLE .................................................................................................................. 128 6.3.2. UNIDADE EXPERIMENTAL ............................................................................................................. 128 6.3.4. VARIVEIS INDEPENDENTES E DEPENDENTES ............................................................................... 129 6.3.5. RUDOS......................................................................................................................................... 130 6.3.6. CONTEXTO....... ............................................................................................................................ 130 6.3.7. SELEO DOS INDIVDUOS ........................................................................................................... 130 6.3.8. VALIDADE........ ............................................................................................................................ 131 6.4. EXECUO ......................................................................................................................................... 132 6.4.1. PROJETO PILOTO........................................................................................................................... 132 6.4.2. ESTUDO DE CASO EDITOR DE FORMULRIOS/TELAS MVPEP ....................................................... 133 6.4.2.1. PREPARAO. ......................................................................................................................... 133 6.4.2.2. EXECUO..... ........................................................................................................................ 136 6.4.2.3. RESULTADOS OBTIDOS ........................................................................................................... 137 6.5. CONSIDERAES FINAIS DO CAPTULO ............................................................................................... 141

7. CONCLUSES E TRABALHOS FUTUROS .......................................................................... 143 XIII

REFERNCIAS BIBLIOGRFICAS ......................................................................................... 141 ANEXOS......... ...................................................................................................................... 152


ANEXO 1. PRTICAS DO PROJETO EDITOR MVPEP ...................................................................................... 152 ANEXO 2. PRTICAS DO PROJETO PILOTO HOBNOB .................................................................................... 155

APNDICES............................................................................................................................157
APNDICE A. CHECKLIST DE AVALIAO ARQUITETURAL VERSO 1 ...................................................... 157 APNDICE B. CHECKLIST DE AVALIAO ARQUITETURAL VERSO 2 ...................................................... 159 APNDICE C. VALORES MONITORADOS NO EXPERIMENTO ......................................................................... 161 APNDICE D. ARQUITETURA DE REFERNCIA ANTES DAS AVALIAES ..................................................... 162

XIV

Captulo

1
1. Introduo
Este captulo apresenta a dissertao com todos os seus elementos motivadores, e problemtica envolvida, cada objetivo deste trabalho tambm apresentado neste captulo em conjunto a justificativa de se escolher a Web 3.0 como cenrio para a pesquisa.

Captulo 1. Introduo

1.1 APRESENTAO E CONTEXTO

A Internet vem alcanando nmeros gigantescos, como exemplo, a quantidade de usurios apenas na Amrica Latina chegar a aproximadamente 143 (cento e quarenta e trs) milhes1. Os meios de acesso so variados, desde conexo banda larga at telefones celulares com tecnologia 3G. Os servios tambm so diversos: ferramentas de buscas, blogs, sites empresariais, email, ferramentas de comunicao instantnea, comrcio eletrnico, abreviadores de URL, ferramentas de programao e etc. Empresas pblicas, privadas e governamentais trocam informaes importantes pela Internet, vrios paradigmas e tecnologias surgem em prol da mesma, alm das transaes bilionrias, como, por exemplo, a compra no valor de 1,65 bilho de dlares do maior site de compartilhamento de vdeo, o YouTube, por uma das maiores empresas desenvolvedoras de servios na rede que a Google, fato ocorrido em 2006 (OFFICIAL GOOGLE BLOG, 2006). A Internet se caracteriza como um rico instrumento de comunicao, negcios, transaes, propagandas e ensino. Sobre o aspecto tecnolgico, o grande feito da Internet foi sua evoluo, segundo o principal CEO da Force.com2, Marc Benioff, a Internet evoluiu de uma rede anteriormente classificada como Web 1.0, onde as informaes somente poderiam ser visualizadas; para a rede programvel, a Web 3.0. A Web 3.0 classificada por meio de dois conceitos distintos, um deles classifica a Web 3.0 como uma plataforma de desenvolvimento de softwares independentes de infraestrutura fsica local, conceito aplicado por Marc Benioff. Enquanto a outra idia classifica a Web 3.0 como a Web Semntica (BERNERS-LEE; HENDLER; e LASSILA, 2001). Independe da conceituao, a Web 3.0 mudou definitivamente o aspecto da Internet, transformando a mesma em algo mais interativo, inteligente e independente. dentro desta temtica da Internet programvel, ou Web 3.0, que este trabalho estabelecer suas bases. Trata-se de uma pesquisa que deseja ofertar solues inteligentes para

Segundo dados do site INTERNET WORLD STATS especializado em pesquisas estatsticas sobre a internet. Em: http://www.internetworldstats.com/stats.htm. Acesso: 01 ago. 2010.
2

Force.com uma empresa de servio Cloud Computing (Salesforce, 2010).

Captulo 1. Introduo

problemas emergentes situados no modelo atual de negcios de TI, e principalmente da Web 3.0. No estudo sero propostas prticas para a construo da clula vital a todos os sistemas: a arquitetura. Por meio da mesma veremos porque necessrio pensar em Mquinas Sociais e no em meras aplicaes Web.

1.2. JUSTIFICATIVA E MOTIVAO DO TRABALHO

Existe uma nova gerao de aplicativos, isto fica evidente quando pensamos que os mesmos servios disponibilizados pela rede mundial h 10 (dez) anos, agora so disponibilizados pela mesma rede com mais completitude e eficincia; um exemplo disto se v na comparao da maior rede social do mundo, o Facebook - Fb, tendo mais de 700 (setecentos) milhes de usurios3, com o Sixdegrees, a primeira rede social do mundo, criada em 1997 que atingiu o mximo de 1 (um) milho de usurios (BOYD, e ELLISON, 2007). O Sixdegrees foi descontinuado no ano de 2000, pois o projeto apresentou srios problemas financeiros que foram causados pelos poucos acessos feitos pelos usurios. Tais usurios no se sentiram atrados pela rede, no havia muito o que fazer aps adicionar amigos, apenas trocar mensagens simples com os mesmos. Ou seja, o Sixdegrees no possuia bons recursos tecnolgicos para se gerar e utilizar apps na rede, para assim, dispor funcionalidades interessantes aos usurios. Apesar dos pontos negativos, o Sixdegrees foi a primeira rede social a possibilitar a criao de um perfil virtual combinado com o registro e publicao de contatos, o que viabilizou a criao e navegao dos usurios por outras redes sociais que surgiram posteriormente, como o: Friendster, Ryze e Fotolog (BOYD, e ELLISON, 2007). Em contrapartida, o Fb um servio de alta disponibilidade que oferta desde ferramenta de conversao imediata at API Java4 para a reutilizao de seus componentes por outras aplicaes, ou seja, ele uma rede social programvel onde qualquer instituio, ou grupo de pessoas, pode formar sua prpria rede semelhante ao Fb, fazendo uso apenas da API da prpria rede social. O Fb fortaleceu consideravelmente a popularizao das redes sociais.

Por Por Zuckerberg em Facebook Thanks. Disponvel http://www.facebook.com/facebook?v=app_10467688569&. Acesso em 11 de jan. 2011.
4

em:

Informao disponvel em: http://developers.facebook.com/. Acesso em 19 de jan. 2011.

Captulo 1. Introduo

O trabalho dos usurios com estas redes to forte que uma pesquisa estatstica feita pelo ConScore, Inc.5, mostrou um aumento de 4% nos acessos das mesmas somento nos primeiros seis meses do ano de 2010. A facilidade em se reprogramar as redes sociais, contextualiza as mesmas a WEB 3.0, entretanto, nesta Internet ainda ocorre a proliferao dos Mashups, que so aplicaes Web constitudas de outras aplicaes. Com os Mashups possvel ter uma combinao de servios em um nico aplicativo (BENSLIMANE, DUSTDAR, e SHETH, 2008). Um bom exemplo de Mashups so os sites de imobilirias que inserem o servio do Google MAP para que o usurio possa fazer a localizao do imvel nas ruas da cidade. Vale ressaltar que os Mashups personificam muito bem a comunicao e interao entre as aplicaes Web. As aplicaes contextualizadas a Web 3.0 adicionam mais funcionalidade a mesma, inovaes ao seu desenvolvimento e facilidade aos negcios, tudo isto, a fim de atender aos modelos de negcio cada vez mais exigentes, com regras mais complexas. Dentro deste contexto a Internet desempenha um papel fundamental, ela alm de instrumento, passa a ser provocadora de negcios, de inovaes, e de junes empresariais. Relacionado aos negcios e as novas tecnologias da WEB 3.0 est o conceito de Computao nas Nuvens ou Cloud Computing - CC. A Web 3.0 apresenta o advento da CC, bem como, os servios, plataformas de infraestrutura, e software sob demanda (WEISSMAN, 2010). Em se tratando de CC o Forrester Research Group6 publicou em Outubro de 2011 um relatrio de anlise das tecnologias emergentes que sero tendncia na TI, especificamente nas arquiteturas de software, para os prximos anos at 2014. No relatrio algumas das tendncias so CC e Business Process Modeling Notation - BPMN, este ltimo tema ser tratado mais adiante por este trabalho. CC um tema de grande pesquisa na atualidade, entretanto muito ainda deve ser visto e avaliado antes de contextualizar os recursos de CC ao desenvolvimento de um software, pois muitas questes ainda so desconhecidas, ou duvidosas, questes como:

Empresa que faz a mediao de vrios aspectos da Internet, mostrando o comportamento de utilizadores da Web.
6

Disponvel em: http://www.forrester.com/rb/Research/top_10_business_technology_trends_e a_should/q/id/60920/t/2. A Forrester Group uma empresa especializada em pesquisas direcionadas a Tecnologia de Informao. Acesso em: 20 de mai. 2011

Captulo 1. Introduo

segurana, compartilhamento de recursos, performance dos aplicativos, e a prpria aplicabilidade dos servios CC, ou seja, o que usar de CC? Na verdade este paradigma traz novidades a todos os seguimentos da engenharia de software, novidades que na prtica ainda no foram totalmente desmistificadas. At este ponto a motivao pela elaborao desta pesquisa foi apresentada, o que essencialmente impulsiona as pesquisas desta natureza o fato de trabalhar com novas possibilidades dentro do desenvolvimento de software, descobrir ou adaptar teorias importantes dentro da engenharia de software. Portanto, os pargrafos acima evidenciaram alguns jovens paradigmas que ainda carecem de pesquisas. As pesquisas devem partir do pressuposto de que aplicaes Web so sistemas que se comunicam em rede, que exercem suas funes por meio desta e por meio da interveno de outras aplicaes. Isto faz estas aplicaes serem Social Machines - SMs, e trabalhando acima deste conceito que ser possvel entender a Internet como um conglomerado de Mquinas Socias que precisa ser investigado para que ocorra uma melhoria no alinhamento de seus servios ou relacionamentos. O trabalho por fim se justifica na necessidade de se explorar de forma cientfica a Internet no sentido de tentar explic-la por um novo aspecto, o aspecto dos sistemas que so Mquinas Sociais que interagem na Web 3.0. Tal estgio da Internet vem vendo investigado e trabalhado justamente por ele possibilitar transaes, interaes e programao de aplicativos diretamente na plataforma Web, com o auxlio de uma infra-estrutura que disponibilizada pela prpria Web. Assim, aplicativos que esto sujeitos a trabalhar nessa realidade da Web devem ser concebidos de forma diferenciada.

1.3 PROBLEMTICA

A justificativa por si j sinaliza a existncia de alguns problemas relacionados s aplicaes que compem a Web. Nesta seo os problemas sero pontuados mais fortemente. Em nossa atualidade existe uma tendncia cada vez maior em se fazer negcios em escala global impulsionados por novas tecnologias, regras e relaes de trabalho; isto traz um maior grau de complexidade aos negcios (REZENDE, 2006) e, sobretudo, aos sistemas computacionais que tendem a crescer em tamanho e complexidade vertiginosamente, sempre 5

Captulo 1. Introduo

na tentativa de atender as demandas dos negcios (REZENDE, 2006). Entretanto, tal evoluo no se limita aos sistemas Web e aos negcios. Tecnologias, processos, arquiteturas, servios e padres de desenvolvimento evoluram com a Web e ajudaram a construir novos negcios. Ao passo que isto positivo tambm preocupante, pois a Web catica em diversos aspectos tecnolgicos. Na verdade, ela passa a ser um emaranhado de cdigos, padres e protocolos que por vezes atrapalham o desenvolvimento das aplicaes (HOFMEISTER, 2000) necessitando assim, de novas idias e iniciativas que organizem, estruturem, e expliquem melhor o desenvolvimento de aplicaes Web. A construo de sistemas est cada vez mais imersa na complexidade das inovaes tecnolgicas causadas pelo surgimento de novos frameworks, novas linguagens, e novos protocolos que surgem em um intervalo cada vez menor de tempo. A tendncia tambm em projetar sistemas que so cada vez mais dependentes da rede (BEHRENDT. et al, 2001). Neste aspecto, deve-se ter ateno a todos os detalhes dos sistemas a serem construdos. Assim, este trabalho se dedica a resolver problemas e questes delicadas Web 3.0 programvel, que pode ser caracterizada como uma moderna rede de computadores sociveis e interoperveis. As questes que sero resolvidas so: Desenvolvimento de aplicaes interoperveis que esto cada vez mais entrelaadas e dependentes dos servios umas das outras. Desenvolvimento de software sob demanda, pois estes necessitam de uma arquitetura diferenciada, haja vista, muitos deles so desligados de um repositrio fsico para armazenamento; compartilhando tal repositrio com outro software (AZEEZ et al., 2010). O auto gerenciamento de sistemas Web que compartilham atividades com outros sistemas distribudos na rede.

Alm das questes pontuadas acima, esse trabalho tambm visa resolver problemas clssicos na construo de sistemas, que segundo estudiosos7, podem gravar o desenvolvimento de aplicaes para a Web. Os problemas resolvidos sero:

Ian Sommerville; Roger Pressman; Mark Harman; Denis A. Resende; Paul Clements, David Garlan.

Captulo 1. Introduo

Manutenes demoradas e crticas dos sistemas; Requisitos mal trabalhados; Ausncia da arquitetura; Ausncia de uma estratgia de negcio que adeque aplicaes Web resoluo dos problemas.

Projetos de aplicaes Web esto suscetveis aos problemas pontuados, uma vez que eles aconteam, as iniciativas para san-los devem ser precisas e rpidas. Dependendo da natureza do problema o projeto pode at ser descontinuado, apenas para exemplificar, este foi o caso de algumas ferramentas que desenvolvem Mashups, construdas por duas grandes corporaes, a Google e a Microsoft. A Google no ano de 2009 precisou cortar gastos, assim resolveu paralisar o desenvolvimento de alguns de seus produtos8, entre eles estava o Google Mashups Editor, o mesmo ocorreu com o Microsoft Popfly no mesmo ano9. Este caso poderia ocorrer a qualquer aplicao Web que contivesse alguns dos problemas pontuados acima. Alguns dos maiores problemas relacionados ao desenvolvimento de aplicaes Web, que podem inclusive causar o fim de um projeto, so os oriundos da arquitetura (PRESSMAN, 2008). A arquitetura de software uma ferramenta que auxilia na descoberta precoce de problemas que s se manifestam geralmente na codificao da aplicao (PRESSMAN, 2011) ou quando a mesma est desenvolvida. O processo de concepo de uma arquitetura por vezes mal executado ou no executado (BASS, CLEMENTS e KAZMAN, 2003). Um exemplo clssico de problemas com arquitetura, ou projeto arquitetural, foi o caso do Twitter. O micro blog trocou seu banco de dados MySQL pelo Cassandra em virtude do alto crescimento da taxa de dados transitados (AFRAM, 2006). No momento das decises arquiteturais do Twitter no houve um raciocnio sobre o crescimento exarcebado do mesmo, com isto optou-se pelo banco de dados errado. O problema inerente a este estudo reside na dificuldade de se especificar e desenvolver aplicaes Web distribudas e conectveis, ou seja, Mquina Social; isto ocorre no somente, mas principalmente, porque estas SMs no so submetidas aos mtodos ou

Informao disponvel no OFFICIAL GOOGLE BLOG. Em: http://www.google.com/intl/pt-BR/press/. Acesso 16 out de 2010.
9

Informao disponvel na MICROSOFT COMMUNITY BLOGS. http://blogs.msdn.com/b/nick_wong/archive/tags/event+announcements/. Acesso em: 30 ago. 2010.

Em:

Captulo 1. Introduo

tecnologias que tratem corretamente suas particularidades, deixando-as vulnerveis aos problemas. Os problemas podem ser mensurados ainda na concepo da arquitetura, deste modo, o tratamento destes problemas poderia se iniciar na arquitetura da SM. O ponto de partida da adversidade deste estudo consiste na arquitetura de software. Tal problemtica nasceu em razo das aplicaes Web, como j tratado, no terem sido concebidas como Mquinas Sociais. Desta forma as arquiteturas das aplicaes tambm no foram pensadas para estruturar SMs, no tiveram o devido tratamento e ateno quanto as particularidades de uma SM, de modo que, elas possam se articular e se expressar na rede em conformidade s inovaes pertencentes mesma, otimizando assim a prpria rede. Esta pesquisa se preocupa, sobretudo, em resolver o problema explicitado neste pargrafo. Desta maneira a problemtica focada se relaciona seriamente com a necessidade de se especificar arquiteturas de SMs, pois muitas das aplicaes WEB que devem ser vistas como SMs no so, neste sentido, a arquitetura que o arcabouo de qualquer software faria total diferena. Com isto o objetivo do trabalho ser apresentado.

1.4. OBJETIVOS:

1.4.1. GERAL

Recomendar prticas para auxiliar na especificao, e mesmo concepo, de arquiteturas de Mquinas Sociais. O objetivo mostrar a forma menos burocrtica e mais coerente de se montar uma arquitetura de qualidade para Mquinas Sociais. Deste modo, as aplicaes Web 3.0 seriam SMs prontas para atender as demandas do contexto atual de negcios e de inovaes tecnolgicas, sobretudo da Internet. Tais prticas podero atuar nas decises arquiteturais, e no projeto arquitetural. Por consequncia atuaro no processo de desenvolvimento, haja vista que a arquitetura mobilize muitas fases do projeto de software, (KRUCHTEN, 1995) integrando profissionais com aptides distintas, como: analistas de requisitos, engenheiros de software, programadores e gerentes. A misso dessas prticas minimizar os problemas no desenvolvimento das SMs, problemas estes que j foram explorados em uma seo anterior.

Captulo 1. Introduo

As prticas tambm visam customizar a arquitetura de referncia que ser proposta, esta arquitetura tambm caracteriza o objetivo do trabalho a partir do momento em que tornase um instrumento para a criao de novas arquiteturas de SMs.

1.4.2. ESPECFICO

Tratando-se do objetivo deste trabalho, deve ficar claro que talvez essa pesquisa no resolva todos os problemas causados pela complexidade das inovaes tecnolgicas, o que foi comentando ainda na problemtica. Mas, certamente organizar o desenvolvimento das Mquinas Sociais, ao passo que poder padronizar as tecnologias adotadas. Esta seo

fortalece o objetivo principal, pois expem os resultados que sero alcanados com a formalizao da metodologia. Na verdade, so subprodutos do objetivo geral, ou metas estabelecidas para serem obtidas ao longo do trabalho. 1. Estudar as tecnologias emergentes ao desenvolvimento de aplicaes Web 3.0; 2. Exemplificar Mquinas Sociais j implementadas e aplicadas indstria de software; 3. Verificar a existncia de uma arquitetura de referncia para sistemas Web 3.0; 4. Sugerir uma arquitetura de referncia para Mquinas Sociais no intuito de guiar a elaborao das demais arquiteturas. 5. Estudar prticas, mtodos ou procedimentos dedicados a especificao de arquitetura. 6. Montar um raciocnio sobre o desenvolvimento de Mquinas Socias de modo que os desenvolvedores trabalhem sobre o conceito de aplicaes interoperveis na Web e no sistemas isolados; 7. Contribuir para o amadurecimento de um framework ou padres de projeto para Mquinas Sociais; 8. Disseminar as prticas em um ambiente real de desenvolvimento para verificar a aplicabilidade das mesmas.

1.5. TRABALHOS RELACIONADOS 9

Captulo 1. Introduo

As pesquisas sobre Mquinas Sociais so oriundas dos estudos de um grupo da Universidade Federal de Pernambuco dedicado a SMs fundado pelo professor Silvio Meira, cientista do C.E.S.A.R Centro de Estudos Avanados do Recife, o qual tambm dissemina pesquisas sobre Mquinas Sociais. Os trabalhos que exploram as SMs relacionam as mesmas s pesquisas direcionadas Internet, sobretudo a Web 3.0. Algumas destas pesquisas foram feitas por grandes estudiosos, como Mark Benioff em 2010, Tim Berners-Lee em 2001, e por Robert Bryant em 2007. Todos estes estudiosos relatam como a Web 3.0 muda definitivamente o aspecto da Internet, transformando a mesma em algo mais interativo, inteligente e independente, injetando foras em conceitos como Cloud Computing e Redes Sociais. Esta pesquisa tambm est totalmente relacionada a arquitetura de software. Arquitetura de Software (AS) pode ser classificada como um conjunto de decises dedicadas a resolver um problema (PRESSMAN, 2011), ou ainda uma coleo de componentes e conectores (ligaes) que ir compor o sistema (GORTON, 2006). A AS pode ser ainda a abstrao de um sistema computacional, seu arcabouo (PRESSMAN, 2009). Todos os conceitos levantados sobre AS so de obras que estudam arquitetura e que tambm esto entrelaadas a esta pesquisa, outros estudos sobre AS esto da mesma forma entrelaados como o de ERL em 2005, Gamma em 2000, Bass e Clements em 2003. So diversos os conceitos para a AS, e todos eles defendem a relevncia de se definir corretamente a mesma, pois os reflexos dessa definio podem ser pressentidos de forma intensa ao longo da implementao do software, seja este modesto ou no (BASS, CLEMENTS e KAZMAN, 2003). Neste sentido, vale dedicar esforos s questes que envolvem a pea fundamental para qualquer sistema e aplicao computacional. Com isto trabalhos que se empenham em facilitar a especificao da arquitetura esto interligados a esta pesquisa. Assim, a IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems, e a IEEE Recommended Practice for Software Requirements Specifications, so trabalhos fortemente relacionados.

10

Captulo 1. Introduo

1.6. CONTRIBUIO E RESULTADOS ESPERADOS

Esta pesquisa visa contribuir para o cenrio dos estudos e do desenvolvimento de aplicaes do tipo Mquina Social, ao passo que amadurece o pensamento acerca das decises de projeto dessas aplicaes, deste modo, elas sofrero o mnimo de problemas em seu desenvolvimento e manuteno. Os seguintes resultados so esperados: Amadurecimento e disseminao do conceito de Mquinas Sociais; Facilidade na adoo de padres arquiteturais e tecnologias que constituem uma Mquina Social; Contribuir para o amadurecimento dos conhecimentos sobre o atual cenrio de desenvolvimento de aplicaes Web 3.0; Impulsionar novas pesquisas em Mquinas Sociais; Demonstrar mtodos avaliativos sobre artefatos de software e sobre SMs. Propor solues que possam facilitar em algum aspecto a interao entre as SMs.

Finalmente uma potencial contribuio deste trabalho reside em agregar ao mundo acadmico um estudo consistente sobre SMs a ponto de orientar pesquisadores e profissionais para as particularidades das mesmas, e tambm para trabalharem com os conceitos emergentes do universo da engenharia de software, como: Redes Sociais, Internet 3.0, Cloud Computing entre outros.

1.7. ESTRUTURA DO TRABALHO

Este trabalho um estudo recente que busca solues adequadas para a construo de Mquinas Sociais. Sendo assim, a pesquisa do tipo Exploratria, a qual bastante utilizada em trabalhos com temtica inovadora (SEVERINO, 2008). A dissertao tambm ser uma pesquisa do tipo Acadmica, pois sistematiza um processo para construo de um novo conhecimento (SEVERINO, 2008). A pesquisa est organizada conforme disposio abaixo: No captulo 2 ser esclarecido o conceito de SMs com suas caractersticas e taxonomia. Este captulo se fez necessrio pelo fato das SMs serem peas fundamentais pesquisa, trata-se de um trabalho dedicado s SMs.

11

Captulo 1. Introduo

O captulo 3 ser um estudo sobre arquitetura de SMs, ou seja, sobre a arquitetura de aplicaes emergentes e contextualizadas a Web 3.0. Tal captulo ser til para a descoberta de problemas em AS de SMs, para identificar o estado da arte em arquitetura de aplicaes Web 3.0, verificar um padro entre as arquiteturas dessas aplicaes, e tambm para a consolidao da arquitetura de referncia para as SMs O captulo 4 constitudo por alguns conceitos sobre arquitetura de software, uma vez que, os esforos foram em propor uma arquitetura de referncia para as SMs. Tal captulo aborda a arquitetura de referncia por meio de vises arquiteturais, alm de empregar uma avaliao baseada em checklist sobre a arquitetura. O captulo 5 formalizar as prticas de especificao de arquitetura, estas nortearo a customizao da arquitetura de referncia para qualquer arquitetura de SMs, e principalmente guiaram a uma correta especificao da arquitetura. No captulo 6 a viabilidade da adoo das prticas e da arquitetura de referncia ser constatada atravs da experimentao por caso de uso. O experimento ser aplicado diretamente na indstria de desenvolvimento de software. O captulo 7 concentrar as consideraes finais e os trabalhos futuros.

12

Captulo

2
2. Mquinas Sociais
Neste captulo vamos situar a pesquisa dentro do seu principal objeto de estudo que so as Mquinas Sociais ou Social Machines SMs. Examinaremos o contexto no qual as SMs esto imersas, assim como, suas caractersticas e classificao.

13

Captulo 2. Mquinas Sociais

2.1. O CONTEXTO DAS MQUINAS SOCIAIS

O que mais motivou as pesquisas em Mquinas Sociais o contexto atual no qual est imerso a engenharia de software e os modelos de negcio que esto sendo impulsionados pela Internet. A engenharia de software, inclusive, tem sido cada vez mais direcionada para atuar na Internet, este argumento cada vez mais irrefutvel ao passo que a Web 3.0 evolui e consolida conceitos de Redes Socias, Cloud Computing CC e outros. CC um novo paradigma dentro da engenharia de software que agrega mais rapidez e sistematicidade ao processo de desenvolvimento, alm de ofertar boas solues para a reutilizao de recursos. As principais caractersticas que tm atrado ateno de pesquisadores, estudantes, clientes, fornecedores e investidores de TI sobre CC, alm do modelo de negcio, e das inovaes dentro da engenharia de software, so as ofertas econmicas de recursos fsicos (infraestrutura), recursos para escalabilidade e flexibilidade de manutenes. CC um termo genrico para um conjunto de recursos computacionais, como: unidades de armazenamento distribudas. CC provido na rede e tem emergido a partir da evoluo e integrao natural de muitas reas, incluindo Utility Computing, Grid Computing, Web Services e Arquitetura Orientada a Servios (SOA) (Motahari-Nezhad, 2009). CC est estruturada da seguinte forma: Software as a Service SaaS, Plataform as a Service PaaS, e Infrastructure as a Service IaaS. O primeiro conceito de SaaS na verdade um modelo de distribuio de software no qual o fornecedor disponibiliza o software em ambiente Web, inviabilizando a replicao de cpias do programa em diversas mquinas do usurio final. Os SaaS ficam depositados na Nvem e os clientes normalmente desconhecem a localizao fsica desta. Com SaaS o cliente paga pelo software conforme a quantidade de pessoas que iro utiliz-lo, ou seja, o servio e a cobrana pelo servio se d sob demanda, isto se caracteriza como o seu maior diferencial (JACOBS, 2005).

14

Captulo 2. Mquinas Sociais

Para o desenvolvimento de SaaS so utilizadas plataformas10 online dotadas de recursos que segundo Motahari-Nezhad (2009) apiam todo o ciclo de desenvolvimento de programas computacionais, incluindo design, implementao, depurao para encontrar defeitos, testes, cpias de segurana, gerncia de configurao, rpida instalao (ou deployment), alm das vrias operaes de suporte aos servios ofertados. Estas plataformas foram denominadas Plataform as a Service - PaaS, das quais, a Force.com11, se caracteriza como uma das mais acessveis e popularizadas, uma vez que totalmente centrada na aplicao e abstrada de qualquer conceito de servidores locais (WEINHARDT, 2009). O alicerce para o conceito de Cloud Computing a Infrastructure as a Service IaaS, que por sua vez, trata da infraestrutura de servidores (MCPHERRON, 2008). Isto elimina as preocupaes das empresas em salvaguardarem um parque tecnolgico para manter as aplicaes, pois agora os recursos de hardware so servios remotos (MCPHERRON, 2008) onde ocorrem os aluguis de Data Centers que fazem a hospedagem das aplicaes. IaaS um servio oferecido por empresas como Amazon AWS12, por exemplo. Assim, em Cloud Computing, uma das preocupaes seria a de adaptar os programadores e as aplicaes a esse novo paradigma e a forma em que ele trata as tradicionais prticas e conceitos de desenvolvimento de software. A Figura 1 ilustra a estrutura da CC.

10

Exemplo de plataformas: Em: www.microsoft.com/windowsazure. Acesso em: 20 de mai. 2010. Em: www.code.google.com/appengine. Acesso em: 1 de mai. 2010. Em: www.bungeeconnect.com. Acesso em: 30 de jun. 2011.
11

Force.com uma plataforma de desenvolvimento em Cloud Computing, nela tambm possvel comprar aplicativos, ou partes deste. A Force.com ficou conhecida pelo servio de Customer Relationship Management CRM vendido as empresas, recentemente, a plataforma divulgou sua rede social personalizada para desenvolvedores, cujo nome Chatter (Salesforce.com, 2010).
12

Amazon AWS uma empresa que trabalha com Cloud Computing, oferta servios de hospedagem e IaaS. Disponvel em: http://aws.amazon.com. Acesso em 02 de jul. 2010.

15

Captulo 2. Mquinas Sociais

Figura 1. Representao da Estrutura de Cloud Computing

Dentro de cada camada representada na Figura 1, existem modelos de negcios que so baseados na funo de cada camada. Na camada de IaaS, por exemplo, surge, segundo Weinhardt, Blau e Stober (2009) o chamado Infrastructure Business Models que trabalha com capacidades de armazenamento e suprimento de poder computacional. Uma poderosa empresa que trabalha nesta camada a Amazon. A Amazon oferece uma srie de servios, e um deles o Elastic Compute Cloud2 EC213 que prov segurana, balanceamento de carga, e aumento de recurso computacional automaticamente conforme o crescimento da aplicao. O pagamento para este servio baseado no modelo chamado sob demanda onde se paga apenas a quantidade de servio utilizado (WEINHARDT, BLAU e STOBER, 2009). Ainda dentro dos novos negcios que surgem em Cloud Computing - CC esto os servios da Google Apps, esta possui um enorme conjunto de aplicaes na CC, tais como: aplicativos para processamento de textos e planilhas, emails, calendrios e outros. Vale ressaltar que o crescimento de novos modelos de negcios em CC est relacionado principalmente segurana de dados e informaes, garantia de integridade, disponibilidade de servios, confiabilidade e rapidez de desenvolvimento (WEINHARDT, BLAU e STOBER, 2009). Assim, notvel a alterao que CC causou no cenrio da engenharia de software, nas formas de pensar, de fazer, e de negociar programas computacionais. Entretanto, este no

13

Disponvel em: http://aws.amazon.com/ec2. Acesso em 17 de dez. 2011.

16

Captulo 2. Mquinas Sociais

um privilgio da Cloud Computing. As Redes Sociais tambm contriburam para as inovaes em engenharia de software, pois algumas dessas redes so ferramentas de programao da prpria rede social, o que pode influenciar em requisitos, teste e arquitetura. Tanto as Redes Sociais quanto a CC esto inseridas no contexto da Web 3.0, portanto, esto no contexto do novo conceito de SMs. A implementao de uma SM pode ser feita por meio de Cloud Computing, ou mesmo, uma SM pode ser um servio oferecido pela nuvem j dentro do panorama dos novos negcios. As SMs so uma nova abordagem dentro deste contexto, uma abordagem simplificada para as aplicaes Web que compem este cenrio inovador.

2.2. CONCEITO DE MQUINAS SOCIAIS

Mquinas Sociais so sistemas, ou aplicaes Web, conectveis, que possuem uma unidade de processamento interno e so capazes de interagir com outras mquinas, a fim de, executar um servio (MEIRA. et al, 2011). A Figura 2 mostra a representao bsica da SM.

Figura 2. Representao da Mquina Social

Fonte: The Emerging Web of Social Machines

A Mquina Social constituda pelos elementos representados na Figura 2, descritos como se segue, segundo Meira et, al. 2011:

17

Captulo 2. Mquinas Sociais

Request: trata-se de uma chamada de procedimento remoto feito aos servios prestados pela SM por meio da sua interface (Wrapper). O Request classificado em: SMs functionality request, e SMs meta-information request. o SMs functionality request: a requisio de um servio ou de uma chamada de mtodo que pode ser feito para outra SM. o SMs meta-information request: trata-se de uma requisio de consulta para uma determinada SM, a fim de, ter conhecimento sobre o seu estado, ou mesmo sobre os seus parmetros de custo e tempo de resposta dos seus servios, disponibilidade e outras meta-informaes associadas SM. Response: a resposta remota da SM ao solicitante, novamente por meio da Interface Wrapper. Seus tipos so: SMs functionality response, SMs metainformation response, e Notification response. o SMs functionality response: trata-se da resposta direta ofertada a uma SMs functionality request. Pode haver vrias ou nenhuma SMs functionality response para uma SMs functionality request. o SMs meta-information response: a resposta direta ofertada a uma SMs meta-information request. o Notification response: so notificaes de uma mquina a respeito de algum evento ocorrido. Pode ser uma notificao de erro de execuo, de erro de envio de mensagem, mensagens de sucesso, de disponibilidade e outros. Wrapper Interface: a Interface Wrapper uma camada de comunicao na qual uma SM exterioriza os seus servios e permite interao com outros SMs. Esta Interface pode tambm ser entendida como a API14 da SM. Input: a entrada de dados que de fato ser processada pela unidade e que s ocorre aps a requisio de procedimentos, assim, os objetos a serem manipulados

14

API o conjunto de funcionalidades de um software disponibilizado por meio de seus cdigos e rotinas, assim uma aplicao pode utilizar o servio de outra sem ter que necessariamente codificar (Tanembaum 2006). Informaes sobre a API do Twitter em: http://apiwiki.twitter.com/.

18

Captulo 2. Mquinas Sociais

pela SM so introduzidos objetivando o processamento e retorno do servio solicitado. O Input pode ser comparado a um parmetro de uma linguagem de programa. Output: o resultado do processamento dos dados de entrada, no entanto, possvel que a SM no consiga resultados em alguns de seus processamentos. Communications: so as ligaes que uma SM tem com outra, seguindo um protocolo bem definido. Tais ligaes podem ser vistas como relacionamentos, intermitentes, ou no, entre as mquinas. As ligaes devem ter restries para a interao entre SMs. Processing Unit: este elemento representa os processos, a unidade interna computacional, como algoritmos que fornecem as funcionalidades principais da Mquina Social. States: a condio dos servios da SM, o estado atual da SM, que exibe qual a

disponibilidade dos servios e conexes.

Constraints: as restries que a SM pode ter so descritas por esse elemento. Ele

pode ser comparado com os requisitos no-funcionais de um sistema, ou seja, nele podem ser declarados, por exemplo: o nmero mximo de acessos aceitos pela mquina, os critrios de segurana, bem como, o seu desempenho. Assim, as restries podem ser usadas como regras a serem consideradas durante o vnculo entre as diferentes SMs.

2.3. CARACTERSTICAS DAS MQUINAS SOCIAIS

Esta abordagem de SMs relevante justamente por atribuir caractersticas s aplicaes, caractersticas que as tornam diferenciadas, que as tornam SMs. Os traos mais relevantes de uma SM esto relacionados no prximo pargrafo. A SM deve ser um elemento absolutamente socivel, deve interagir com o ambiente e os outros elementos ao seu redor e tambm deve ser independente de qualquer plataforma ou tecnologia, devendo saber encontrar os servios que lhe possam ser teis. Outra importante 19

Captulo 2. Mquinas Sociais

caracterstica de uma SM a capacidade de oferecer seus servios de modo que outras mquinas no necessitem saber, ou se preocupar com a forma como, quando e onde os servios foram implementados (MEIRA. et al, 2011). A SM deve deixar evidente os servios que podem ofertar, e sobretudo deve se autoreconhecer, ou seja, ter conhecimento do seu estado ou propriedades. Por fim, outra caracterstica, a capacidade de se conectar com outras SMs dinamicamente, a fim de, trocar ou apenas consumir servios dessas mquinas. interessante pontuar essas caractersticas, fazendo algumas relaes, como por exemplo, com os requisitos que uma Mquina Social deve saciar. Os requisitos prprios de um SMs surgem de um estudo exploratrio sobre as mesmas. Eles despontam conforme as caractersticas destas Mquinas Sociais. A priori requisitos como: Performance15, Disponibilidade16, Modificabilidade17, e Interoperabilidade18, so os mais importantes para as SMs, eles atuam na satisfao das necessidades e caractersticas das Mquinas Sociais. O quadro abaixo pode auxiliar neste entendimento, de modo que, deixa evidente e prtico a identificao das caractersticas e necessidades das SMs a serem atendidas. Dentre estes requisitos no funcionais, o de escalabilidade no foi pontuado como sendo comum as SMs, pois este tipo de requisito est muito relacionado faculdade da Mquina Social em crescer para atender uma demanda contnua de uso da SM (TAURION, 2009). Ainda assim, nem todas as SMs possuem necessidade de expanso em sua

infraestrutura devido ao excesso de dados transitados ou acesso de usurios. Neste ponto, o requisito de escalabilidade est relacionado ao requisito performance.

15

Performance: Relacionado a confiabilidade, em manter um nvel aceitvel de funcionamento sobre situaes extremas, tem relao direta com: maturidade, tolerncia a falhas, e recuperabilidade (ISO/IEC 9126-1);
16 17

Disponibilidade: Capacidade de estar pronto pra uso no tempo esperado ou desejado (ISO/IEC 9126-1);

Modificabilidade: Qualidade de mudar, de se alterar, sem no entanto, atingir outros componentes relacionados (ISO/IEC 9126-1);
18

Interoperabilidade: Comunicao de forma transparente com outras entidades, de forma que possa ocorrer a troca de dados ou informaes independentemente da plataforma ou tecnologia (SOMMERVILLE, 2011).

20

Captulo 2. Mquinas Sociais

Tm Autonomia Sociabilidade

Necessitam Servios Comunicao facilitada Manuteno facilitada Infraestrutura Reatividade Conectividade Expanso ou Confiabilidade

Mquinas Sociais

Constncia Colaborao Servios

Tabela 1. Caractersticas e necessidades das SMs

2.4. TAXONOMIA DAS MQUINAS SOCIAIS

As Mquinas Sociais possuem sua prpria classificao. Existem 4 grupos de SMs: Isoladas, Consumidoras, Fornecedoras e Prosumer. Tal classificao tem como parmetro a interao entre as SMs (MEIRA. et al, 2011 ). SMs Isoladas: so SMs que no interagem com outras SMs por no SMs Consumidoras: SMs que apenas consomem um ou mais servios para, a

possuirem meios de comunicao. partir disto, ofertar um novo servio. Um exemplo dessas SMs so as ferramentas Mashups. SMs Fornecedoras: so SMs que apenas fornecem servios, pois possuem os

recursos necessrios ao seu completo funcionamento. O Google Maps um exemplo de SM deste tipo. SMs Prosumers: como o prprio termo em ingls significa, so SMs que

possuem a capacidade de serem fornecedoras e consumidoras, como algumas ferramentas de Cloud Computing.

21

Captulo 2. Mquinas Sociais

2.5. EXEMPLOS DE MQUINAS SOCIAIS

Para consolidar mais os conceitos deste captulo interessante exibir alguns modelos de SMs. Abaixo descrevemos o nome da tecnologia e o porqu ela pode ser considerada uma SM. Ao final dos exemplos ser possvel notar que os conceitos de SMs no se limitam apenas s aplicaes Web, apesar deste trabalho focar nas SMs que so aplicaes para Internet. Tais mquinas podem tambm ser explicadas, ou visualizadas, como diferentes sistemas conectados em rede, ou ainda, como diversificadas tecnologias Web.

2.5.1. EUCALYPTUS:

O Eucalyptus uma IaaS de cdigo aberto que fornece suporte para a integrao com outras IaaS como a Amazon AWS. Com o Eucalyptus o usurio tambm pode gerenciar sua nuvem criada em outras ferramentas. Esta IaaS permite aos usurios acesso e gerncia a todas as mquinas virtuais existentes (LIU et al., 2007). O Eucalyptus trabalha essencialmente com virtualizao, alm de utilizar o protocolo SOAP19 para consultas. Essa IaaS pode ser considerada uma SM pelo gerenciamento e reconhecimento do estado de outras mquinas, o que sobressai a caracterstica socivel do Eucalyptus. Neste ponto o Eucalyptus possui muitos dos elementos das SMs, sendo que os elementos mais importantes para esta IaaS so as solicitaes. Assim, o Eucalyptus envia Request e recebe Response a todo o momento, alm de possuir uma robusta Wrapper Interface chamada de Cluster Controller (LIU et al., 2007) que possibilita uma interao imediata a eficaz com todas as mquinas virtuais, que podem tambm ser SMs.

2.5.2. CLOUD AV:

O Cloud AV uma ferramenta antivrus ofertada como um servio de Cloud Computing. Tal servio identifica arquivos maliciosos por mltiplos mecanismos de deteco em paralelo que se comunicam entre si exatamente como SMs. O Cloud AV utiliza tcnicas baseadas em cache para melhorar o desempenho durante o envio de arquivos, alm disto, para

19

SOAP um protocolo que viabiliza a troca de mensagem entre os sistemas (TITTEL, 2003)

22

Captulo 2. Mquinas Sociais

prover escalabilidade, a ferramenta executada em mquinas virtuais (OBERHEIDE, et al., 2008). O Cloud AV possui os seguintes elementos (OBERHEIDE, et al., 2008) de uma SM: Input: recebe arquivos para a anlise e o seu mecanismo de deteco composto por diversos aplicativos antivrus que fazem Request e Response entre si at que a deteco seja possvel. Output: Envia o resultado da anlise dos arquivos apontando quais esto infectados ou no. Evidentemente o Cloud AV possui o elemento Processing Unit para possibilitar tantas anlises, alm da caracterstica de sociabilidade da SM, o que torna possvel a interao com os vrios antivrus at que o resultado seja encontrado.

2.5.3. MAP REDUCE:

O MapReduce um framework para processamento de grande volume de dados. Esse aplicativo ainda facilita outras atividades como: mecanismo de tolerncia a falhas, distribuio dos dados e balanceamento de carga. O MapReduce trabalha com funes que se comportam como SMs; Jimmy Lin e Chris Dyer (2010) definem bem o funcionamento do aplicativo no pargrafo abaixo:
No MapReduce cada operao composta por duas funes. A primeira, chamada de funo de Mapeamento, recebe uma poro do arquivo de entrada, e de acordo com a especificao do usurio, emite um conjunto de tuplas intermedirias no formato chave-valor. A segunda funo, chamada Reduo, recebe um conjunto de valores associados a cada chave, chamados de blocos. O processamento, definido pelo usurio, realizado sobre cada bloco; por fim, cada funo de reduo emite um conjunto de tuplas que so armazenadas em arquivos de sada.

Por reduo se entende: uma funo que "recolhe" os itens em listas e realiza alguma computao em todos eles, reduzindo-os a um nico valor (LIN e DYER, 2010). por isso que o sistema MapReduce consegue trabalhar com grandes volumes de dados. Tal reduo pode ser vista com os elementos Input e Output da SM. Alm de possuir os elementos da SM, como os j citados, alm de outros como o State; o MapReduce possui a caracterstica da SM de se auto-reconhecer e reconhecer o volume de dados entregue (LIN e DYER, 2010). 23

Captulo 2. Mquinas Sociais

Outra caracterstica que aproxima o MapReduce de ser uma SM o fato das camadas que compem sua arquitetura se conectarem e interagirem livremente, ou seja, a arquitetura MapReduce do estilo Relaxed Layered System (LIN e DYER, 2010), o qual permite que as camadas interajam com camadas que no so adjacentes, ou seja, o sentido de comunicao e o tipo de comunicao pode ser alterado (GAMMA et al, 1995).

2.5.4. WEB SEMNTICA:

Para finalizar a exibio das Mquinas Sociais, ser exibido uma aplicao em um nvel maior, ou melhor, ser exibido uma plataforma como Mquinas Sociais, pois assim ser possvel notar como este conceito pode ser aplicado a diversos nveis de tecnologia. Atualmente quando uma pgina Web procurada com o auxlio de uma mquina de busca, esta mquina vai investigar as pginas que contm palavras declaradas pelo usurio. Contudo, nem sempre essas palavras so adequadas e relevantes para o contexto em que o usurio est inserido. A Web Semntica vem para sanar esse problema, pois ela a Web dos significados (BERNERS-LEE; HENDLER; e LASSILA, 2001). Ela atribui significado claro e especfico aos dados por meio da interpretao e da contextualizao dos mesmos; isto facilita o entendimento das mquinas (MORAES E SOARES, 2002), deixando a resposta para qualquer tipo de pesquisa na Web mais precisa, satisfazendo a necessidade do usurio. A Web Semntica tambm classificao como Web 3.0 e foi idealizada por Tim Berners-Lee. Tim projetou uma Internet inteligente, o que se deve principalmente organizao das informaes. Tais informaes so consequncias de dados oriundos de repositrios completamente heterogneos. Tim ainda afirma que o grande diferencial desta Web 3.0 ser o aprendizado das mquinas, pois estas organizaro e daro contexto aos dados (BERNERS-LEE; HENDLER; e LASSILA, 2001). No texto abaixo, traduzido da obra de Lee, Hendler e Lassila (2001), possvel observar forte relao entre o conceito de Internet Semntica e o conceito de Mquinas Sociais.
Os agentes na Web Semntica so sistemas computacionais capazes de interagir autonomamente para atingir os objetivos almejados pelo usurio. Os agentes possuem algumas caractersticas como autonomia, reatividade (percebem o ambiente e tomam as decises), tem comportamento colaborativo, possuem objetivos, so

24

Captulo 2. Mquinas Sociais

flexveis, sociveis e tm a capacidade de aprender. A Web Semntica possui vrios agentes interagindo entre si, compreendendo, trocando ontologias, adquirindo novas capacidades racionais ao passo que adquirirem novas ontologias para formar cadeias que facilitam a comunicao e a ao humana.

Pela citao direta nota-se claramente as caractersticas de uma SM na Web Semntica, entre elas: sociabilidade, interao, colaborao, e comunicao. Tais caractersticas necessitam de todos os elementos das Mquinas Sociais. Deste modo, essa seo se encerra na esperana de ter contribudo para a fixao dos conceitos de SMs e de como tais SMs podem ser identificadas.

2.6. CONSIDERAES FINAIS DO CAPTULO

Este captulo apresentou as Mquinas Sociais. Vale salientar que existem outros materiais que explicam minuciosamente o conceito das SMs os quais esto referenciados na bibliografia deste trabalho. Outro ponto importante a ser declarado o fato deste captulo fornecer conceitos que devem ser considerados durante a execuo desta pesquisa quanto consolidao do objetivo geral da mesma. O prximo captulo tratar com igual propsito no que concerne arquitetura das SMs.

25

Captulo

3
3. Reviso da Arquiteturas de Mquinas Sociais Literatura de Software Para

Esse captulo objetiva descobrir evidncias de pesquisa sobre arquiteturas de softwares que so Mquinas Sociais. necessrio investigar essas arquiteturas para ter entendimento de como elas realmente so. Com isto, ser possvel sugerir uma arquitetura de referncia dedicada s Mquinas Sociais; e futuramente, sugerir prticas de engenharia de software coerentes ao maior objetivo do trabalho, que facilitar a construo de arquiteturas, e assim das prprias aplicaes que so SMs.

26

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

3.1. INTRODUO

No somente, mas sobretudo, pesquisas de Harman e Jones (2001); Freitas et al, (2008); Pressman (2005); e Kruchten (1995), direcionadas a rea da engenharia de software, impulsionaram o surgimento de novos padres, mtodos, representaes e tcnicas relacionados arquitetura de software, o que ocasionou uma evoluo nessa rea de estudo da engenharia. Em tempos longnquos, a arquitetura de software era basicamente voltada para os sistemas cliente-servidor, onde uma mquina exercia o papel de cliente requisitante e a outra mquina, o papel de servidor com a responsabilidade de atender as requisies. Deste modo, a arquitetura cliente-servidor tornou-se padro na engenharia de software, sendo em nossa atualidade ainda explorada e, sobretudo, mesclada a outras arquiteturas para atender ao objetivo de um software. Hoje parece ser este o cenrio: arquiteturas cada vez mais heterogneas, onde estilos e tecnologias diferenciadas se misturam para formar novas verses de representaes arquiteturais.

3.2. ARQUITETURA DE SOFTWARE

Arquitetura de Software (AS) a definio da estrutura e dos elementos que compem um sistema, como esses elementos esto inter-relacionados, e quais as suas caractersticas (BASS, CLEMENTS, KAZMAN, 2003). A AS est intimamente ligada aos requisitos de software, mais fortemente aos requisitos no funcionais (RNF) (BASS, CLEMENTS, KAZMAN, 2003). Sendo assim, a definio de uma arquitetura se inicia com o levantamento e anlise dos requisitos seguido pelas decises de projeto. Estas so escolhas em relao s tecnologias utilizadas para desenvolver a aplicao (PRESSMAN, 2011). Ao longo da histria a AS foi vrias vezes explorada, conduzindo a um universo de descobertas que, por sua vez, gerou solues teis ao desenvolvimento de software. Na evoluo dos estudos da rea, descobriu-se que o estilo arquitetural Camadas facilitava enormemente o desenvolvimento de softwares para a Web. As principais caractersticas do estilo Camadas so, segundo Erich Gamma, 2000: Camadas superiores so especficas da aplicao; 27

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Camadas inferiores so mais responsveis pela infraestrutura, oferecendo

suporte s camadas superiores; As camadas s interagem com camadas contguas, ou seja, com as camadas

que esto imediatamente acima ou abaixo; O contedo das camadas pode ser varivel, assim como o nome de cada

camada. A comunicao entre as camadas pode ser por meio de protocolos de comunicao ou mesmo atravs de um sistema operacional. Tradicionalmente, elas se dividem em 3 camadas e mais o repositrio de dados ilustrados na Figura 3 (HOFMEISTER, 2000).

Figura 3. Estilo arquitetural Camadas

1 Camada, Apresentao: camada onde o usurio interage diretamente, ela valida os dados fornecidos pelo usurio e o conecta aos servios da camada inferior;

2 Camada, Negcio: contm todos os componentes e objetos que podem ser utilizados e reutilizados para implementar a lgica de negcio da aplicao; 3 Camada, Persistncia: a camada responsvel pelo acesso aos meios de armazenamento como: memria, banco de dados e sistemas legados.

O estilo Camadas se popularizou e passou por evolues, uma vez que inicialmente era constitudo por duas camadas e atualmente j pode ser constitudo por at quatro ou mais, 28

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

consoante Christine Hofmeister (2000), no qual existe uma quarta camada de Middleware ou mesmo um servidor Web para fazer a gerncia da aplicao. Alm das caractersticas expostas acima, sua popularizao se deve, mormente, pelas caractersticas expostas a seguir (KLEIN, KAZMAN, 1999):

As camadas podem resolver problemas complexos de forma sequencial e incremental (SOMMERVILE, 2011);

As camadas podem ser reutilizadas, visto que elas suportam alteraes, o que afetaria apenas a interao com as camadas adjacentes. Logo, as camadas podero ser reutilizadas, desde que mantenham interfaces de comunicao adequadas s suas camadas adjacentes (GARLAN, SHAW, 1994);

Suportam outros estilos associados, ou seja, dentro de uma camada pode existir outro estilo arquitetural (LARMAN, 2007);

o estilo arquitetural com o maior nmero de variaes, j explicado anteriormente, o Relaxed Layered System; alm do estilo Layering Through Inheritance, outra derivao do Camadas (KLEIN, KAZMAN, 1999), com caractersticas semelhantes e algumas melhorias, como: permitir que camadas superiores modifiquem os servios das classes das camadas inferiores;

As camadas favorecem o baixo acoplamento e a alta coeso (LARMAN, 2007);

Podem ser facilmente empregados padres de projetos, como o padro Observer, fortemente utilizado na interao entre as camadas (LARMAN, 2007);

Apesar dos benefcios agregados pelo estilo em Camadas, assim como todos os estilos, ele deve ser analisado antes de ser adotado para a arquitetura do software, pois sua utilizao no vivel para todos os sistemas (BUSCHMANN et al, 1996). Assim, para sistemas que necessitem de timo desempenho as camadas no so aconselhveis, porquanto o tempo de processamento e a prpria comunicao entre as camadas pode ser elevado (BUSCHMANN et al., 1996). Outro critrio de qualidade a tolerncia falhas. Se uma

29

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

camada ficar indisponvel, o sistema na sua integralidade poder ficar indisponvel, haja visto, que uma camada depende de outra para funcionar (HOFMEISTER, 2000). Para finalizar a exposio dos conceitos relacionados a arquitetura de software, vale mais uma vez enfatizar que uma arquitetura de referncia ser esboada, e que ela, assim como toda arquitetura de referncia, precisa de um estilo arquitetural. A partir do ponto em que se estabelece uma arquitetura de referncia, j se disponibiliza um parmetro inicial para a construo da arquitetura correta de SMs, e que pode ser perfeitamente guiado pelas prticas que daro forma s arquiteturas. Faz-se necessrio esta seo sobre arquitetura de software, uma vez que esse captulo trata de um estudo sobre arquitetura. Torna-se relevante ter um estudo dessa categoria compondo a pesquisa, porquanto dar subsdio para a formulao da AR e das prticas ao passo que revelar o estado da arte das arquiteturas de aplicaes que fazem partem da Web 3.0. O desenvolvimento deste estudo foi baseado, entre outros, nas orientaes das obras de Brbara Kitchenham e David Budgen (2008 - 2009), e de Pertersen (2008), assim est estruturado como se segue.

3.3. PROCESSO DE REVISO

3.3.1. QUESTO A SER INVESTIGADA:

A questo investigada neste trabalho trata da existncia de uma arquitetura de referncia para Mquinas Socias, uma arquitetura que facilite o desenvolvimento de SMs por ser uma arquitetura padro a todas as SMs. Portanto a questo de pesquisa : what are architecture of reference for Social Machines?. Traduzindo: existem arquiteturas de referncia para Mquinas Sociais. Seguindo alguns critrios de Petticrew e Roberts (2005) a questo selecionada se baseia em: Interveno: Estudos sobre arquiteturas e Mquinas Sociais que faam algum tipo de experimento ou anlise utilizando alguma tcnica ou modelo.

30

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Populao: Trabalhos cientficos publicados sobre arquiteturas de aplicaes WEB 3.0 ou para sistemas que possam ser classificados como Mquinas Sociais.

Publicao: Materiais tcnicos que tratem das arquiteturas, ou sistemas, e prticas relacionadas s Mquinas Sociais.

O que se almeja descobrir neste estudo o estado da arte de arquiteturas de aplicaes Web, bem como, a existncia de um padro entre tais arquiteturas. Como o escopo deste trabalho est centrado no contexto inovador da Web 3.0, o estudo foi direcionado aos sistemas que estejam imersos e preparados para trabalhar dentro dos princpios da Web 3.0. Assim, as questes de pesquisa foram selecionadas.

3.3.2. QUESTES DE PESQUISA:

Seria mais fcil encontrar materiais que fossem dedicados aos sistemas, aplicaes ou tecnologias que possam ser classificados como Mquinas Socias, visto que o quantitativo das pesquisas que tratam as aplicaes propriamente como Mquinas Sociais, com arquiteturas de Mquinas Sociais, inexpressivo. Sendo assim, optou-se em utilizar questes que abordem arquiteturas das tecnologias: Mashups, Computao nas Nuvens, Redes Sociais, Sistemas Autnomos e aplicaes Web. Estes possuem caractersticas marcantes das SM's por interagirem com outros elementos em rede, alm de utilizarem servios e recursos destes elementos e tambm da prpria rede para funcionar, se desenvolver, e auto gerenciar. Complementando a motivao acima, existe o fato das Mquinas Sociais selecionadas para as questes serem mais difundidas, possibilitando dessa forma, maior nmero de pesquisas e experimentos sobre elas, o que pode facilitar o desenvolvimento do estudo em questo. Do mesmo modo, o estudo pode ser facilitado com a insero de uma questo de pesquisa dedicada s aplicaes Web em geral, ou seja, uma das questes investigar a existncia de uma arquitetura de referncia para aplicaes web. As 5 (cinco) questes para a busca da pesquisa foram definidas e so expostas abaixo: QP1: What are the reference architectures for Mashups? 31

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

QP2: Which are reference architectures of Cloud Computing? QP3: What is the architecture of Social Networks? QP4: There is a model of architecture for Autonomous Systems? QP5: What are the reference architectures of Web Applications? As cinco questes propostas acima buscam descobrir tendncias inovadoras sobre arquitetura de Mquinas Sociais. Elas foram escritas na linguam inglesa apenas para facilitar a obteo de resultados, pois acreditasse que os resultados de estudos sero em maior quantidade na lngua inglesa. No entanto, necessrio utilizar palavras que complementassem a busca pelas respostas das questes de pesquisa, neste caso, os termos ou strings a seguir, orientam a idia de melhorar os filtros de busca. Por conseguinte, foram utilizados na investigao por vezes mesclados s questes acima, os strings so: Web 3.0; Networking; Social Networking; Style; Social; Web 2.0; Architecture; Architectural; Computer; Machine; Tendency; Tred; SaaS; Cloud; Patterns; Internert; Applications; Systems; Social Machine; Web Applications; Software Engineering; Multitenancy; Multitenant; Scalability; Software as a Service; Twitter; Facebook; Mashup Architecture; Semantic Web; Platform as a Service; PaaS; Architectural Innovations; Autonomous Systems; Map Reduce; Reference; Which. No objetivo de encontrar o maior nmero de resultados que atendessem a questo de pesquisa, as questes de busca foram por vezes alteradas com o auxlio das strings, como exposto abaixo: What are the architectures of Cloud Computing OR Multitenant OR OR Multitenancy. What are architecture of Social Networks OR Social Networking. What are the architectures of Cloud Computing OR Platform as a Service OR PaaS.

32

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

3.3.3. REPOSITRIOS DE BUSCA

Os repositrios e base de dados utilizados para encontrar as questes e palavras investigadas foram as bibliotecas digitais: CiteSeerX; IEEE Xplore; Mendeley; e ACM Digital Library. Foram tambm empregados captulos de livros e revistas digitais especializadas para subsidiar a investigao (KITCHENHAM, 2009). Este trabalho possui natureza cientfica, entretanto, seu resultado visa alcanar tambm profissionais e empreendedores na rea de TI no intuito de facilitar a criao de aplicaes Web. Sendo assim, houve a necessidade de empregar ferramentas que ofertassem um resultado mais direcionado ao mercado tecnolgico, bem como revelassem materiais que no pertencessem aos repositrios mencionados, e que por sua vez, fossem mais tcnicos e menos cientficos, agregando valores pesquisa em comento. Deste modo, foram aplicados em uma investigao secundria, mquinas de busca como: Google Scolar e Google Books.

3.3.4. IDENTIFICAO DO MATERIAL

Todo material revelado pela busca foi precedido de leitura do ttulo. Por sua vez aqueles que mais se aproximavam das questes investigadas tinham seu contedo selecionado para posterior leitura do resumo ou introduo. Aps essa leitura, uma relevncia era atribuda ao material conforme alguns critrios de classificao.

3.3.5. CRITRIOS DE CLASSIFICAO - INCLUSO:

A incluso de pesquisas a serem consideradas para o referido estudo se baseou na relevncia declinada. Atribuir maior relevncia para materiais que se caracterizem como: o Arquiteturas j testadas e empregadas em Mquinas Sociais; o Solues de projeto ou decises de projeto de aplicaes vistas como Mquinas Sociais. Atribuir relevncia mediana para materiais que:

33

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

o Faam referncia as tecnologias emergentes e adequadamente empregadas na construo de Mquinas Sociais; o Sejam projetos piloto de arquitetura de referncia para aplicaes ou sistemas WEB. 3.3.6. CRITRIOS DE CLASSIFICAO - EXCLUSO: Foram descartados materiais que apresentam menor contribuio por no tratarem de assuntos relacionados s arquiteturas de sistemas ou aplicaes Web 3.0, bem como, estudos com abordagens insuficientes, que comprometam o entendimento do material, e ainda estudos duplicados. Foram descartados ainda materiais que ofertassem um contedo muito conceitual sobre arquitetura, sem nenhuma proposta evidente de tal, sem definio de elementos ou recursos que possam prover a arquitetura.

3.3.7. REGISTRO DO MATERIAL

Foram elaboradas fichas de leituras, as quais foram analisadas e classificadas, construindo a base de conhecimento de forma textual, formando um resumo significativo, cujo contedo integrava materiais de acentuada relevncia que contribuiram para a pesquisa. As fichas esto disponveis no repositrio pblico: http://dl.dropbox.com/u/8309962 /Fichas%20de%20Leitura.docx. As fichas foram organizadas pela ordem de classificao, tal organizao observou tambm a extrao de evidncias que satisfizessem as questes de pesquisa, validando assim este estudo (PERTERSEN et al. 2008). Por meio do registro do material foi ainda possvel extrair conhecimento a respeito do grau de relevncia de cada material relacionado a alguma questo de pesquisa, mostrando assim a adoo, ou no, das strings.

3.3.8. RESULTADO

Os materiais mapeados compem-se na sua totalidade 21 (vinte e um) textos entre artigos, peridicos e captulo de livro; 11 (onze) destes materiais mostraram maior contribuio para as questes de pesquisa. O resultado de cada uma das questes exibido na 34

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

tabela a seguir que engloba os 11 (onze) estudos contribuintes. Vale ressaltar que a questo de pesquisa que trata de Cloud Computing foi a que retornou mais estudos, 12 (doze) no total, entre propostas arquiteturais e estudos com abordagens duplicadas. O grfico abaixo (figura 4) mostra a disperso do quantitativo de estudos por questo de pesquisa; nele possvel observar que a questo das aplicaes Web resultou em menos estudos, apenas 2 (dois) onde 1 (um) foi considerado.

QP 5. Web Applications QP 4. Autonomous Systems QP 3. Social Networks QP 2. Cloud Computing QP 1. Mashups

10

12

14

Figura 4. Numero de estudos por questo de pesquisa

Fonte Mendeley IEEE

Referncia (MERRIL, 2006) (LIU e LIANG, et al. 2009)

Descrio

Mashups: The new breed of web app Using Architecture Integration Patterns to Compose Enterprise Mashups Aneka: A Software Platform for .NET-based Cloud Computing

CiteSeerX

(VECCHIOLA; CHU; BUYYA, 2009)

Google Scolar

(BEHRENDT et al. IBM Cloud Computing Reference Architecture 2.0 2011)

Google Scolar

(WEISSMAN, 2010)

The Force.com Multitenant Architecture Understanding the Design of Salesforce.coms Internet Application Development Platform

CiteSeerX

(KOSSMANN, KRASKA, LOESING, 2010)

An Avaluation of Alternative Architectures for Transaction Processing in the Cloud.

35

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Google Scolar

(HOFF, 2011)

Facebook: An Example Canonical Architecture for Scaling Billions of Messages

Google Scolar Mendeley

(AVRAM, 2009) (MCCANN e HUEBSCHER, 2004)

Twitter, uma arquitetura Evoluindo Evaluation Issues in Autonomic Computing

IEEE Google Books

(IBM, 2006) (GOVERNOR, et al. 2009)

An Architectural Bluepoint for Autonomic Computing


Web 2.0 Architectures

Tabela 2. Materiais selecionados para o estudo

3.4 DEMONSTRAO DOS RESULTADOS DAS ARQUITETURAS DE REFERNCIA INVESTIGADAS

Nessa seo as arquiteturas averiguadas nos materiais sero relatadas. O objetivo do relato auxiliar na compreenso dos resultados encontrados.

3.4.1. ARQUITETURA DE REFERNCIA PARA MASHUPS QP1

O Mashup uma aplicao Web que faz uso de dados de variadas fontes objetivando criar um novo servio. Na verdade essa aplicao emprega cdigos de outras aplicaes por meio de uma API (OREILLY, T, 2008). Um exemplo de Mashup o site Wikicrimes que mapeia nas regies o ndice de criminalidade com a ajuda do Google Map. O Mashup tem a sua plataforma de programao sustentada pela prpria Internet, ou seja, uma caracterstica de aplicaes da Web 3.0; todavia, no apenas esta particularidade notada, mas tambm a prpria definio de Mashup o posiciona como uma Mquina Social. Atualmente existem duas definies para a arquitetura de Mashups, ambas utilizam como referncia a arquitetura em camadas e sero exposta a seguir.

36

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

3.4.1.1. Arquitetura Mashup Proposta por Merril em 2006

A primeira definio a mais disseminada e apresenta a arquitetura com grau de abstrao maior em um nvel menor de detalhamento, tal definio de Duane Merril, 2006; prope que a arquitetura do Mashups seja composta de (ver figura 5): Web Browser: interface de comunicao entre o usurio e o Mashup; Site Mashup: camada lgica onde o Mashup est implementado pode ser um servidor, ou mesmo o prprio browser do cliente com Applet20,, por exemplo; API: so os provedores de contedo que disponibilizam seus dados por meio de protocolos.

Figura 5. Arquitetura Mashup por Duane Merril

O principal questionamento acima desta proposta, alm dela no demonstrar muita riqueza de detalhes, sobre a arquitetura no prever a integrao dos dados, tais dados podem

Applet um pequeno programa que includo nas pginas web, o navegador executa esse programa na pgina para complementar o contedo da mesma (LOPES, ET AL. 2010).
20

37

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

estar em diferentes formatos como XML ou HTML, e tambm em diferentes semnticas, enfim, so fontes heterogneas que por vezes no trabalham atravs de uma API, dificultando assim o trabalho com os dados.

3.4.1.2.

Arquitetura Mashup Proposta por Liu em 2009

A segunda definio de Yan Liu (2009), cujos padres utilizados so os seguintes: Piper and Filter: padro responsvel pela gerao e pelo fluxo dos dados, este padro possui componentes interligados onde cada um executa uma funo especfica. Data Federation: responsvel pela integrao de dados, este padro til quando se deseja integrar dados provenientes de muitas fontes diferentes. Diversas empresas armazenam seus dados em repositrios diferentes, como: bancos de dados transacionais, sistemas de business intelligence, sistemas legados e outros; cada um desses sistemas de armazenamento tem sua prpria maneira de acessar os dados, o que traz problemas no momento da busca. O padro Data Federation ajuda a obter e agregar esses dados, alm de facilitar a consulta aos mesmos. MVC: O padro Model-view-controller tem um papel importante, uma vez que o model acessa a camada de dados da aplicao, por sua vez, o controlador se comunica com o model para localizar a view requisitada pelo usurio. Neste padro as tecnologias HTML, XML e JavaScript podem ser utilizadas. O model ainda implementa o padro Data Federation, enquanto os controladores implementam o padro Piper and Filter. Diante da soluo apresentada, possvel fazer algumas anlises. O padro Piper and Filter traz simplicidade arquitetura, assim como facilidade de manuteno e escalabilidade, pois novos filters podem ser inseridos na composio da arquitetura sem prejudic-la. A manuteno destes filtros tambm facilitada devido a sua reusabilidade. Na verdade, esse padro favorece o processamento concorrente. Os filtros, em particular, fazem o processamento, pois cada filtro tem uma funo definida. Aps o processamento ocorre a gerao dos dados. Estes so repassados para o Piper (conector), que,

38

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

por conseguinte, os lem e repassam para os prximos filtros. Esse ciclo contnuo at que haja demanda de processamento. Vale ressaltar que, para o padro Piper and Filter, os conectores podem assumir um comportamento variado no processo. Eles podem ser um protocolo de comunicao ou uma cache. O importante que eles realizem a leitura dos dados e os repassem para o filtro mais adequado (BUSCHMANN, MEUNIER, ROHNERT, SOMMERLAD e STAL, 1996). Em contrapartida, no estilo Pipers and Filters os componentes no conhecem o estado um do outro, sendo assim, quando ocorre um erro em um dos componentes o sistema todo deve ser reiniciado, pois no se tem conhecimento da funo que o filtro estava executando no momento do erro, tal disfuncionalidade ocasiona perda de informaes (GARLAN e SHAW, 1994). Por fim, o estilo em questo, por ser orientado atravs de funo no se mostra apropriado representao dos dados. O grande desafio dos Mashups reunir dados de diversas fontes para criar um nico servio, logo, sua arquitetura deve assegurar a correta integrao, gerenciamento, transformao e organizao dos dados. Neste sentido, a adoo do estilo Piper and Filter pode no agregar tantas vantagens justamente pela possibilidade das fontes de dados sofrerem algum tipo de problema e falharem, deixando o Mashup vulnervel. Este problema no solucionado pelas arquiteturas propostas.

3.4.2. ARQUITETURA DE REFERNCIA PARA CLOUD COMPUTING QP2

Atualmente existem algumas propostas de Arquitetura de Referncia para Cloud Computing, dentre as quais, aquelas que consideram as camadas de servio: IaaS, PaaS, e SaaS como sendo a arquitetura da computao nas nuvens. Contudo, tais camadas so modelos de servios oferecidos pela Computao nas Nuvens, e no modelo de arquitetura, conforme explicado. Apesar das propostas existentes, o Instituto Nacional de Cincia e Tecnologia NIST21, situado nos USA, afirma que de fato no existe para Cloud Computing uma

21

Disponvel: http://www.nist.gov/index.html. Acesso em: 01 de ago. 2011

39

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

arquitetura de referncia. O NIST afirma que um dos seus objetivos formular tal arquitetura em conjunto com outros institutos e com empresas do mercado americano. Ainda consoante o instituto, a arquitetura a ser formulada deve facilitar a comunicao, ilustrar os vrios servios da nuvem e proporcionar o desenvolvimento de aplicaes com alta escalabilidade, segurana e portabilidade. O instituto prev uma arquitetura de referncia que seja adequada tambm aos modelos de implantao de Cloud Computing, os quais so, segundo Peter Mell e Tim Grance (2009): Nuvem Pblica: A infraestrutura das nuvens disponibilizada para o pblico. Qualquer usurio que conhea a localizao do servio poder acess-la. Nuvem Privada: A infraestrutura de nuvem utilizada exclusivamente por uma organizao, sendo administrada pela prpria organizao, ou por terceiros, especializados em administrao e manuteno de Cloud Computing. Nuvem Comunidade: A infraestrutura de uma nuvem compartilhada por diversas empresas. Nuvem Hbrida: A infraestrutura composta de duas ou mais nuvens que podem ser pblicas, privadas e comunitrias, todas devem estar interligadas por uma tecnologia padro, permitindo total portabilidade. Nesta seo vamos descrever trs arquiteturas de referncia para Cloud Computing, a primeira baseada nos estudos de Christian Vecchiola de 2009, a segunda proposta por KOSSMANN, KRASKA e LOESING em 2010, e a terceira determinada pela empresa IBM no ano de 2011.

3.4.2.1. Arquitetura Cloud Computing proposta por Vecchiola A Figura 6 retrata uma das arquiteturas mapeadas neste estudo. Em seguida esto as explicaes para cada parte que compem a arquitetura. A camada Cloud Applications a mais bsica, uma camada de aplicao onde os usurios finais podem manter seus programas na nuvem. Nesta camada tambm esto os aplicativos e os SaaS, todas as aplicaes podem ser adquiridas pelos usurio de forma dinmica conforme a necessidade do mesmo. Abaixo desta camada est a camada Cloud 40

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Programming. A relao entra elas reside no fato da camada inferior dar suporte camada superior, sendo assim, a camada mais abaixa Cloud Programming disponibiliza os servios e os recursos para se implementar o software sob demanda. A Cloud Programming tambm pode ser chamada de Middleware User-Level, nela podem ser desenvolvidos os aplicativos e regulado o suporte ao desenvolvimento, so basicamente ferramentas e ambientes que podem possuir interface Web 2.0, recursos de programao distribuda, bibliotecas e linguagens de programao, alm de ferramentas para o desenvolvimento de sistemas Mashups. Esta camada similar a uma PaaS. A penltima camada de Middleware Core responsvel pelo gerenciamento da infraestrutura fsica, tal camada oferta servios para a manuteno de QoS22 e SLAs23, servios de virtualizao e outros. Todos os recursos dispostos nesta camada so acessados pela camada diretamente acima dela, pois somente assim, o usurio poder usufruir dos recursos, haja vista o acesso camada Middleware Core seja negado. Por fim, a camada de mais baixo nvel a de infraestrutura fsica que contm Data Centers e conjuntos de CPUs, alm de outros recursos de hardware, os quais podem ser agregados ou subtrados com liberdade, oferecendo assim, bastante flexibilidade arquitetura. Estas duas ltimas camadas inferiores se comportam como IaaS.

22 23

QoS Quality of Service (TANANBAUM, 2003) SLAs Nveis de servios definidos em um contrato (MELL e GRANCE 2009)

41

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Figura 6. Arquitetura Cloud Computing por Vecchiola

Fonte: Aneka. A software plataform for.NETbased Cloud Computing (Vecchiola et al. 2009)

Uma crtica construtiva que pode ser feita a respeito desta arquitetura sobre o seu estilo, sendo tipicamente em Camadas, toda camada tem uma responsabilidade distinta, alm disto, os recursos de cada camada podem ser reorganizados, pois a prpria vai se readaptando. Deste modo, quando houver necessidade de economia no investimento, aquela estar preparada. Enquanto isso, o gerenciamento de cada camada pode ser feito independentemente. No contexto deste trabalho, esse modelo de arquitetura pode ofertar solues para a manuteno da aplicao e independncia entre as partes que a compem.

3.4.2.2. Arquitetura Cloud Computing proposta por KOSSMANN, KRASKA e LOESING. A arquitetura mais utilizada por PaaS e IaaS (KOSSMANN, KRASKA e LOESING, 2010) tradicionalmente em camadas. A Figura 7 representa a arquitetura.

Figura 7. Arquitetura de referncia para Cloud Computing por KOSSMANN, KRASKA e LOESING, 2010.

Fonte: An Evaluation of Alternative Architectures for Transaction Processing in the Cloud

Segundo os autores, essa arquitetura composta por uma camada de interface de usurio, essa faz uso de balanceadores de carga para distribuir os pedidos de clientes, e ofertar assim, um tempo de resposta melhor a cada solicitao. O balanceador repassa as solicitaes para mquinas disponveis em uma camada inferior. Estas processam as solicitaes (HTTP) 42

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

de clientes e repassa ao servidor de aplicao que executa a lgica do aplicativo especificado. Tal execuo pode ser nas linguagens Java ou C++ com SQL embutido, por exemplo. Todas essas tarefas ocorrem na mesma camada central. Ainda na mesma camada residem os servidores de banco de dados que controlam as aes de leitura e escrita no banco. Tal banco, por sua vez, logicamente particionado em uma camada dedicada a ele; cada partio controlada por um servidor. Essa abordagem conhecida na literatura como Esquemas de Particionamento (STONEBRAKER e HELLERSTEIN, 2005), esse conceito foi aplicado no s na camada de banco de dados, como tambm, na camada dos servidores de aplicao, servidores web e servidores banco de dados. Para Cloud Computing essa arquitetura oferece escalabilidade total e elasticidade em todos os nveis de camada, pois cada solicitao HTTP pode ser encaminhada para qualquer servidor, seja de aplicao, web ou banco de dados; isto se revela como um diferencial que agrega muitos benefcios. Apesar do diferencial a arquitetura foi especificada de forma relativamente superficial. Todavia a arquitetura em questo sacrifica a consistncia dos dados devido ao particionamento e a necessidade de se conseguir disponibilidade. Consistncia e disponibilidade no so obtidas ao mesmo tempo em nenhum sistema particionado em rede (BREWER, 2000). Com isto necessrio criticar a falta de solues alternativas que garantam a consistncia total aos dados e servios. Disponibilidade um requisito importante para qualquer sistema disperso na Web. Deixar este requisito negligenciado uma falha potencial da arquitetura.

3.4.2.3. Arquitetura Cloud Computing proposta pela empresa IBM A IBM em seu centro de pesquisa no ano de 2011 props uma arquitetura de referncia para Cloud Compunting. O objetivo seria definir uma arquitetura nica que permitisse aos ambientes de programao nas nuvens: economia no investimento dos recursos necessrios, boa qualidade na prestao de servios e otimizao de recursos. A Figura 8 define a IBM Cloud Computing Reference Architecture - CCRA, proposta por Michael Behrendt, 2011. 43

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Figura 8. Arquitetura de Referncia Cloud Computing proposta pela IBM

Fonte: IBM Cloud Computing Reference Architecture 2.0

A arquitetura de referncia proposta pela IBM rica em detalhes e abrange um nvel maior de complexidade em relao aos servios; novamente baseada no conceito de Camadas e, como se pode notar atravs da Figura 8, existem 02 (duas) grandes camadas externas voltadas Governana de TI e requisitos de qualidade. A arquitetura foca nos servios e recursos que a nuvem oferta e necessita, desse modo, os detalhes tecnolgicos foram subtrados na descrio da responsabilidade de cada camada. Tais responsabilidades sero expostas no decorrer desta subseo. Enquanto a camada de Governana trata dos recursos tecnolgicos bem como os processos de TI que devem sustentar e melhorar as estratgias e os objetivos organizacionais. A camada de qualidade trata de aspectos voltados a manuteno da segurana, da recuperabilidade do sistema diante s falhas, de desempenho e da Consumibility. Consumibility um termo bastante utilizado pela IBM para expor qual o nvel de adequao do produto ao cliente. Seria um requisito de qualidade que vai alm dos requisitos de usabilidade, adequao e acurcia, pois alm de avaliar se o produto de software est satisfazendo o cliente, visa ainda avaliar se o produto foi bem instalado, se o cliente est usufruindo do produto e, se a aplicao deve ser atualizada a fim de corrigir erros e agregar melhorias. 44

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Ainda nesse contexto, as trs camadas centrais sero elucidadas: Cloud Service Consumer, Cloud Service Provider e Cloud Service Creator. Observando inicialmente essas camadas, alguns conceitos devem ser resgatados, como: os conceitos de arquitetura de software; e desenvolvimento modular de software, em que cada mdulo a ser desenvolvido deve disponibilizar uma interface provida que ofertar servios, alm de uma interface requerida que exibe quais os servios necessrios (BASS, CLEMENTS, KAZMAN, 2003). A camada de Cloud Service Consumer tem a responsabilidade de alocar os recursos que consomem servios da nuvem e, ainda alocar as pessoas que sero oneradas pelo uso dos servios, na qual todos os consumidores podero interagir com os pacotes de servios oferecidos pela prpria camada. A Cloud Service Consumer possui diversos elementos, dentre eles, o Cloud Service Integration Tools. Esse elemento faz a integrao dos servios da nuvem aos servios e recursos locais da organizao consumidora, como por exemplo, um sistema legado. Como ltimo elemento dessa camada temos o Consumer In-house IT, este componente pode estar presente em qualquer camada da arquitetura, visto que concentra as tecnologias que proporcionaro a integrao dos recursos de TI da empresa aos recursos da nuvem, podendo conter infraestrutura, Middleware, aplicaes de negcios e gesto de servios. A camada de Cloud Service Provider a camada da nuvem responsvel pela prestao de servio, onde os componentes tm a liberdade de exibir seus servios, criar outros servios, e solicitar servios a outros componentes. a camada mais rica em elementos, que so: Cloud Services: Este elemento alm de manter todos os modelos de servio de

Cloud Computing j conhecidos (SaaS, IaaS, PaaS); contm ainda o Business Process as a Service BpaaS responsvel pela modelagem dos processos de negcio de quaisquer servios entregues pela nuvem, desde os tradicionais servios de hospedagem de aplicao, at negociao de compra e venda em Web Commerce. Completando o elemento Cloud Services, est o Cloud Service Creation & Ecosystem Aspects, cuja relao ocorre entre o servio ofertado pela nuvem e os produtos que podem ser obtidos por meio desses servios. Por exemplo, o Cloud Service Creation & Ecosystem Aspects que faz a seguinte correspondncia na nuvem:

45

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

O servio da Amazon EC2 um eco-sistema voltado para a IaaS em que seus produtos podero auxiliar na alocao de uma PaaS. Common Cloud Management Platform (CCMAP): Esta camada ao lado da

Cloud Services se divide em dois componentes principais: Operational Support Services - OSS e Business Suport Services - BSS. Ambos os componentes trabalham para dar suporte aos servios da nuvem e aos clientes que consomem servios da nuvem. Infrastructure: representa todos os elementos de infraestrutura necessrios para

que os provedores forneam os servios para nuvem. Isso engloba todas as instalaes necessrias, desde Data Centers e demais recursos de rede, vale mencionar que no existe qualquer tipo de software rodando sobre esta camada. Por fim a camada Cloud Service Creator com o seu elemento Service Creation Tools, possui todas as ferramentas que iro gerar os servios da nuvem. Tais ferramentas incluem ambientes da programao de software, ferramentas de layout de interface grfica, ferramentas para virtualizao, e outras. Nesse sentido, aps a elucidao de mais uma proposta sobre arquitetura para Cloud, possvel a formulao das seguintes concluses. Na abordagem da arquitetura, a IBM afirma que Cloud Computing bastante semelhante Arquitetura Orientada a Servios SOA, pois a Computao nas nuvens trabalhada em termos de criao, distribuio e consumo de servios. Portanto, Cloud Computing suporta orientao a servios, uma vez que as empresas podem oferecer a infraestrutura e a plataforma de desenvolvimento agregadas ao software como um servio sob demanda. Como considerao sobre esta abordagem vlido observar que a arquitetura mais orientada aos papis e funes que so desempenhados em Cloud Computing, explora adequadamente o estilo em camadas, busca flexibilidade e modularidade na manuteno de cada camada, o que fornece maior rapidez no desenvolvimento. Tanto esta arquitetura quanto a arquiteturas apresentada em 2009 so mais conceituais, no exploram em demasia o nvel tcnico, e trabalham com um nvel maior de abstrao, sendo que o ltimo modelo exibe mais os aspectos dos servios que so ofertados pela nuvem e como eles devem ser organizados.

46

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Nas pesquisas de Mquinas Sociais sempre vlido explorar Cloud Computing, pois este um conceito que visa desenvolver e manter aplicaes para WEB 3.0, (TSAI et al, 2011) e consequentemente est repleto de tecnologias que materializam o conceito de Mquinas Sociais. Portanto, na prxima seo, uma arquitetura dedicada a essas tecnologias ser exposta, aproveitando o ensejo de que ela surgiu por meio de uma das questes de pesquisa.

3.4.3.

ARQUITETURA

MULTITENANT

DE

REFERNCIA

PARA

SOFTWARE AS A SERVICE QP2

A arquitetura homologada para as aplicaes da Force.com, uma das maiores plataformas de desenvolvimento na Computao nas Nuvens, a Multitenant ou multiinquilino. Essa prev o compartilhamento da unidade interna computacional, dos dados e da instncia fsica de armazenamento, propiciando assim, a cada desenvolvedor, to-somente, a preocupao em montar o fluxo de sua aplicao com as regras de negcio. A arquitetura disponibiliza as funes da Force.com compartilhando objetos. Todavia ela executa a distribuio das parties virtuais na plataforma para que outras aplicaes ou mdulos de sistemas sejam agregados (AZEEZ et al, 2010). O que se faz atravs da Multitenant personalizar os objetos disponveis para que eles atendam a finalidade do negcio (software) reduzindo drasticamente o tempo de desenvolvimento. Na Figura 9 se ilustra a Multitenant. Nela, cada camada desenvolve uma funo bem definida. Para isto, elas contam com o auxlio de recursos, como por exemplo: a customizao de objetos ou funcionalidades por meio de controladores e de implementaes no cdigo Apex (linguagem de programao da Salesforce que compe a camada Configuration) (BEZEMER e ZAIDMAN, 2010). Nesta camada ainda existe a utilizao da linguagem de codificao de interface grfica, a Visualforce (WEISSMAN, 2010).

47

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Figura 9. Esboo da arquitetura Multitenant

Fonte: The Force.com Multitenant Architecture Understanding the Design of Salesforce.coms Internet Application Development Platform

O estilo Camadas fundamental para a Multitenant, pois tal estilo proporciona a separao das camadas deixando a lgica da aplicao (camada Configuration) livre para implementar diferentes cdigos conforme a aplicao do inquilino. Quanto as demais camadas, a Authentication faz apenas o acesso do usurio, ou inquilino. Para cada novo usurio criado um novo acesso de modo que o inquilino tenha a sensao de que a aplicao totalmente dedicada (BEZEMER e ZAIDMAN, 2010). A ltima camada funcional chamada Database Pool responsvel por criar registros nicos nos bancos de dados, pois como as aplicaes so compartilhadas, existe a necessidade de consultas e inseres individuais nas bases de dados para cada inquilino, o objetivo garantir que um determinado usurio acesse apenas os seus dados. Neste sentido, para melhorar o desempenho da arquitetura, so utilizados balanceadores de cargas que distribuem os acessos (BEZEMER e ZAIDMAN, 2010). A especificao da arquitetura Multitenant bem clara, onde cada camada possui uma responsabilidade bem definida tratando de aspectos essenciais a uma aplicao, como o 48

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

cuidado com os dados e bases de dados. Em relao a este aspecto cabe uma crtica; o armazenamento e tratamento dos dados pode ser crtico para algumas aplicaes multiinquilino que no utilizem sistemas de banco de dados preparados para lidar com o tipo de arquitetura exposta nesta seo. Diante disto, seria interessante que a arquitetura Multitenant ofertasse uma camada que abstrasse o tratamento dos dados, e que fosse mais especfica quanto a este tratamento. Muitos pontos em relao aos dados so delicados, e exigem que a arquitetura trabalhe melhor o isolamento, algo que compem muitas das exigncias de alguns clientes.

3.4.4. ARQUITETURA PARA REDES SOCIAIS QP3

As arquiteturas investigadas para esse tipo de SM so baseadas no estilo Camadas. Entretanto, essa arquitetura ostenta formatos diferenciados que dependem das caractersticas e no apenas dos requisitos de cada rede. A mesma arquitetura de referncia explorada tanto pelo microblog Twitter quanto pela poderosa rede Facebook. No entanto, so abordagens diferentes da mesma arquitetura, explorando tecnologias diferentes. Vale salientar que as redes sociais exploradas nessa seo so plataformas programveis. Com elas, possvel criar novas aplicaes utilizando-se apenas a Internet (APIWIKI, 2010). Tal caracterstica as transformam em Mquinas Socias. A seguir, exploremos uma breve sinopse sobre cada rede, com as respectivas tecnologias adotadas e sua arquitetura. O Twitter iniciar a seo. O Twitter foi aberto ao pblico em meados do ano de 2006, alm de ser um microblog ele uma rede social propriamente dita e ainda uma ferramenta de Broadcast. A rede em abril do ano de 2010, segundo seu cofundador Biz Stones, conquistou a cifra de 105 (cento e cinco) milhes de usurios. Abaixo, delineamos algumas caractersticas importantes dessa rede. O Twitter pode ser acessado via dispositivos mveis. Atualmente o micro-blog possui integrao com outras redes sociais. No ano de 2008, foi incorporado um mecanismo de busca ao micro-blog. Outra caracterstica importante do Twitter a sua API. Ela oferece, entre outros, a busca de servios que possam ser indexados em aplicaes terceiras (AFRAM, 2009). A arquitetura do micro-blog ilustrada na Figura 10. 49

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Na arquitetura Twitter a camada de apresentao labora com os servios dos clientes, algumas tecnologias so empregadas como: Json24 e Rails25, a camada realiza ainda renderizao e caching. Logo abaixo est a camada de negcio, trabalhada por meio das linguagens C, Java e Scala, esta ltima favorece a escalabilidade em relao ao crescimento do nmero de seguidores. Por ltimo encontra-se a camada de dados suportada por bancos de dados no relacionais, os chamados NoSQL, que oferecem resilincia e escalabilidade (LAI, 2009); como exemplo desses bancos encontra-se o Cassandra26 e o Hbase. Em seguida examinaremos a arquitetura do Facebook.

Figura 10. Arquitetura do Twitter

A arquitetura do Facebook contm uma camada a mais em relao ao Twitter, uma camada dedicada comunicao, pois o Facebook trabalha com recursos de mdia mais complexos, como fotos e vdeos; nesta questo somente as visualizaes das fotos podem ultrapassar o montante de 3 (trs) milhes27. Esta rede ainda possui um chat para conversao

24 JSON uma notao JavaScript que faz a troca de dados entre mquinas. Informaes sobre JSON em: http://www.json.org/. 25 Rails tambm chamado de Ruby on Rails ou apenas RoR ele um framework de cdigo aberto escrito na linguagem Ruby. Seu objetivo aumentar a velocidade e a facilidade de desenvolvimento dos sites. Rails j gera as aplicaes no estilo camadas. Informaes em: http://www.rubyonrails.pro.br/ 26 Cassandra um sistema de armazenamento distribudo para gerenciamento de dados estruturados que projetado para escalar uma grande quantidade de dados entre muitos servidores sem falhar (LAI, 2009) 27 Disponvel em: Facebook Developers. Disponvel em: http://developers.facebook.com/. Acesso em: 23 de set. 2010.

50

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

entre as pessoas conectadas e registradas como amigos. Por essas caractersticas e outras, o Facebook, que hoje a maior rede social do mundo, tornou-se tambm um desafio para a escalabilidade. Para prover a escalabilidade, os arquitetos do Facebook usam uma combinao de tecnologias, principalmente softwares para escalar, como o Map Reduce para processar e analisar grande volume de dados. Utiliza ainda o Varnish como balanceador de carga e o Haystack para a recuperao de fotos (HOFF, 2011). O Facebook alm de ser a rede social mais notvel da atualidade, se caracteriza fortemente por ser uma plataforma para gerao de aplicativos e servios, que disponibiliza uma API e possui integrao com plataformas diferenciadas (FACEBOOK DEVELOPERS, 2010). Apesar disto, as arquiteturas das duas redes possuem particularidades como a seguir. O servio de Cloud Computing auxiliou as redes sociais no armazenamento de dados e na disponibilidade de recursos, o que facilitou a escalabilidade. Tanto Facebook quanto Twitter utilizam banco de dados NoSQL. O software Memcached28, por sua vez foi

implementado dentro da camada de negcio de ambas as redes para melhorar o desempenho, visto que o Memcached armazena a informao em memrias distribudas, recuperando-a mais rapidamente, evitando assim, tarefas repetitivas e demoradas de recuperao de informao em banco de dados (GALBRAITH, 2009). Concluindo esta sesso, vale registrar que a arquitetura do Facebook no foi ilustrada neste captulo, pois no foram encontrados materiais que explicassem em detalhes maiores como as camadas de tal arquitetura interagem. Os materiais capturados faziam referncia apenas s decises de projeto e tecnologias adotadas. Alis, as arquiteturas das redes sociais exploradas trabalham mais com questes tecnolgicas. Neste aspecto foi possvel notar que estas arquiteturas se diferem mais em relao s decises de projeto, ou seja, de quais tecnologias utilizar. Para a definio de qualquer arquitetura fundamental declarar as decises de projetos. Estas esto diretamente ligadas ao design da arquitetura. Assim, os resultados da questo sobre as arquiteturas de redes sociais se adaptam mais as decises de projeto, o que

28

Memcache um sistema de cach de objetos em memria concebido para aumentar a velocidade de aplicaes dinmicas aliviando a carga do banco de dados (GALBRAITH, 2009).

51

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

apesar de ser relevante para este estudo, deixa uma lacuna sobre a consolidao de uma modelo arquitetural para estes tipos de SMs.

3.4.5. ARQUITETURA DE REFERNCIA PARA SISTEMAS AUTNOMOS QP4 Um sistema autnomo aquele que tem mecanismos para se autogerenciar por meio de autocontrole e monitoramento, assim, ele tem a capacidade de adaptar-se aos padres esperados e especificados; um sistema desta categoria formado pela colaborao de elementos autogerenciveis. Segundo Paul Horn (2001) um sistema s autnomo se ele for flexvel para se adaptar s mudanas do ambiente. E, ainda, define como principais propriedades de um sistema autnomo: 1. Autocura: propriedade do sistema que assegura sua recuperao automtica aps a ocorrncia de uma falha; 2. Auto-otimizao: ajuste automtico dos parmetros de recurso para otimizar a utilizao dos mesmos; 3. Autoproteo: capacidade de se auto defender de ataques ou invases maliciosas; 4. Autoconfigurao: ajustar a configurao do sistema conforme as variaes do ambiente, de modo que, o sistema funcione corretamente satisfazendo a necessidade do usurio (IBM, 2003).

Ademais, definindo as caractersticas de um sistema autnomo, o mesmo deve manter relacionamento com outros elementos, em especial, seus provedores e consumidores de servio (IBM, 2006). Esses relacionamentos iro possibilitar que os sistemas autnomos conheam o estado uns dos outros e o seu prprio estado, facilitando, desta maneira, a obteno de dados sobre o estado dos recursos, memrias, volume de dados e tambm vulnerabilidade (STERRITT e BUSTARD, 2003). Tais dados so obtidos por meio de operaes em sensores, como: Request-Response: operaes que so de solicitao ou resposta de sobre o estado de um elemento. 52

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

A comunicao tambm necessria para que o sistema altere seu estado ou comportamento conforme necessrio. Para esta comunicao, necessrio (IBM, 2003): Solicit-Response: a requisio de informaes do sistema para sua unidade de controle. Conforme explicado em relao aos sistemas autnomos, nota-se que eles so Mquinas Socias legtimas, sobretudo no aspecto dos relacionamentos. Esses relacionamentos entre sistemas so fundamentais para o prprio aprendizado da mquina. deste modo que um sistema autnomo consegue se auto gerenciar e tomar decises. O sistema deve saber qual o seu nvel aceitvel de funcionamento, as condies que ele poder ser submetido, e como manter a qualidade dos seus servios mesmo sobre condies adversas (MCCANN, e HUEBSCHER, 2004). Nota-se aqui que sistemas autnomos tambm esto fortemente relacionados a inteligncia artificial, sistemas especialistas e sistemas baseados em conhecimento; de sorte que podem ser utilizados em sistemas de computao em grade ou computao ubqua (IBM, 2003). A seguir uma das arquiteturas de referncia proposta para esses sistemas autnomos ser explorada. A arquitetura foi proposta por Mccann, e Huebscher em 2004; e tambm por White et al., em 2004. As explicaes sobre esta arquitetura foram baseadas nos trabalhos destes estudiosos.

3.4.5.1.

Arquitetura Autnoma Proposta por Mccann, Huebscher e White et al

A Figura 11 representa o esboo da arquitetura de referncia para um sistema autnomo em que sondas so inseridas na arquitetura para monitorar o sistema. Essas sondas ou sensores captam informaes do ambiente externo e repassam para outros tipos de sensores, estes iro comparar os dados capturados s variveis especificadas para o sistema, ou seja, aos requisitos desejados em desempenho, tolerncia falha e outros.

53

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Figura 11. Esboo de arquitetura para sistemas autnomos

Aps a captura e anlise dos parmetros, o elemento responsvel pelo controle do sistema, chamado de gerenciador ou calibrador, faz uso das informaes analisadas para controlar e adaptar a operao do sistema, a fim de atingir o comportamento desejado. Esse calibrador deve interagir diretamente com a camada de negcio do sistema, ou ainda, compor esta camada. A arquitetura de um sistema autnomo deve ser dividida, como observado na Figura 11. Enquanto a primeira parte comporta os sensores e calibradores, a segunda parte composta pelas partes relacionadas a lgica de negcio e ao acesso a dados. Isso possibilita que sistemas desse tipo possam ter sua arquitetura composta por diversos estilos arquiteturais, dependendo do tipo, requisitos e limitaes do sistema. O estilo arquitetural Peer-to-peer29 geralmente uma excelente escolha para a segunda parte da arquitetura de um sistema autnomo, pois esse modelo de sistema tem como forte caracterstica a distribuio. Tal caracterstica forte porque comumente todos os elementos da arquitetura do sistema so tambm autnomos, onde cada camada pode ter sua prpria arquitetura autnoma. Isto se revela como uma crtica positiva a esta arquitetura.

29

Arquitetura distribuda onde cada par, ou nodo, possui uma funo distinta (STERRITT, e BUSTARD, 2003)

54

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Outra interpretao que se pode ter que a arquitetura de um sistema autnomo pode ser dupla. Uma arquitetura assegura a infraestrutura que permite o monitoramento e anlise dos componentes, enquanto a outra a prpria arquitetura do sistema que garante o correto funcionamento dos requisitos. Ambas esto entrelaadas. Esta interpretao no definitiva, a prpria arquitetura no foi exibida desta maneira, nem ao menos existiram suposies a respeito disto, o que pode se revelar como um fator negativo na especificao desta arquitetura. No obstante ao modelo apresentado, ele no o nico. Existem outras abordagens, inclusive defendidas por grandes empresas como a IBM (IBM, 2003).

3.4.5.2.

Arquitetura Autnoma Proposta Pela Empresa IBM

Segundo a IBM uma arquitetura de referncia para computao autonmica deve realizar trs objetivos fundamentais. Primeiramente, deve descrever as interfaces externas e comportamentos necessrios de componentes do sistema. Em segundo plano, deve descrever como compor esses componentes para que eles possam cooperar para as metas de todo o sistema. Finalmente, deve descrever como compor as propriedades de autogesto do sistema. A arquitetura IBM explicada em seguida:

Figura 12. Arquitetura de referncia proposta pela empresa IBM para computao autnoma

Fonte: IBM, 2003

55

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Como ilustrado na Figura 12 a arquitetura composta por duas camadas mais inferiores que exercem, respectivamente, as funes, de conter recursos fsicos de infraestrutura de TI ou mesmo softwares de gesto; e prover interfaces de gerenciamento para controlar os recursos gerenciados. Essas interfaces padro so entregues atravs de um terminal de gerenciamento. A terceira camada chamada Touchpoint Autonomic Managers contm gerentes autnomos de quatro categorias de autogesto, a auto configurvel, autocura, auto- otimizao e autoproteo). A camada acima desta, contm gestores autnomos que orquestram outros gestores de cada categoria. Essa camada oferece a capacidade autnoma ao sistema, incorporando maior controle sobre a infra-estrutura geral de TI.

A camada mais superior fornece interfaces de comunicao entre os usurios e o sistemas, e entre estes sistemas e outros, facilitando a integrao dos mesmos. A explicao desta arquitetura no ser rica em detalhes, pois a IBM, apesar de afirmar que a mesma pode ser aplicada aos sistemas autnomos, classifica a arquitetura como sendo de referncia para computao autnoma em si. Contudo, seria interessante expor a arquitetura neste trabalho, uma vez que, a diferena entre os conceitos de sistema e computao sejam muito sutis, os sistemas se prevalecem dos conceitos da computao, e ambos abordam as premissas da autogesto. Cabe uma singela crtica a esta arquitetura; ela no demonstrou como o objetivo de cada camada pode ser alcanado, mesmo que em alto nvel, por ser uma arquitetura de referncia. Em todo o trabalho publicado no ano de 2003, a arquitetura apenas elegeu o uso de Web Services para viabilizar a comunicao entre as interfaces de comunicao, bem como, a adoo de Enterprise Service Bus - ESB para servir de barramento de integrao entre as camadas da arquitetura. Contudo a IBM deixou evidente em sua proposta, que o mais importante em uma arquitetura para este tipo de SMs definir precisamente o comportamento dos componentes arquiteturais e de suas interfaces de comunicao.

3.4.6. ARQUITETURA DE REFERNCIA PARA APLICAES WEB 2.0 QP5 O livro Web 2.0 Architectures de James Governor, et al. (2009), sugere uma arquitetura de referncia para aplicaes originais da WEB 2.0 nestas estariam aplicaes 56

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

como Mashups e alguns tipos de redes sociais como o Flickr30. A arquitetura proposta ilustrada na prxima imagem.

Figura 13. Arquitetura de referncia para aplicaes WEB 2.0 Fonte: Adaptada de James Governor, livro: Web 2.0 Architectures; ano 2009

Os componentes desta arquitetura possuem a seguinte definio: Resource Tier a base, ou infraestrutura que armazena todos os recursos que capacitam os servios da aplicao. Nesta camada residem os banco de dados, interfaces com sistemas, diretrios, e outros. Esta camada pode ter subdivises que a tornam capaz de fazer a persistncia de banco de dados; Service Tier Camada de servios responsvel pela conexo destes servios ofertando controle sobre o fluxo de informaes que transitam por entre a aplicao. Conectivity (setas entre as camadas centrais) Podem ser protocolos e padres que permitem o acesso aos servios. Tais conexes devem exibir os servios deixando clara a responsabilidade de cada um; Client Application Tier a camada em que o usurio acessa para consumir os servios da aplicao, nesta camada podem residir ferramentas que melhorem a interaao do usurio com a aplicao;

30

Rede de compartilhamento de fotos. Disponvel em: www.flickr .com

57

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Design, Development, and Governance Tools Esta camada de suporte ao desenvolvimento, pois contm um conjunto de ferramentas que auxilia os desenvolvedores. As ferramentas podem ser ainda utilizadas no desenvolvimento dos componentes das camadas de servio e cliente. Esta camada interessante para customizar outras camadas e assim expandir e modificar as arquiteturas de aplicaes que usem esta arquitetura de referncia. Esta arquitetura de referncia interessante por ofertar uma diviso inteligente das

responsabilidades de cada camada. O seguinte exerccio pode auxiliar em uma maior compreenso. Supondo que seja necessrio construir uma aplicao Web 2.0 que possa fazer conexo com alguma API de outra aplicao. Neste caso, seria necessiro contruir uma interface na camada Resource Tier. Entretanto, se a aplicao em questo necessitar ter usa prpria API a camada Service Tier ser a responsvel. Tal camada ir definir protocolos de acesso aos servios e esses protocolos so os elementos arquiteturais Conectivity. Essa arquitetura um modelo para aplicaes da segunda gerao da Internet. Tal modelo til por mostrar o objetivo de uma arquitetura de referncia dedicada a Web, em que algumas dessas aplicaes, como os Mashups, so tambm da Web 3.0, e assim, Mquinas Sociais. Fica ntido que a arquitetura bem genrica, ficando sucetvel implantao de tecnologias diversas, como: framework e Web services. Vale lembrar que essa capacidade de implantao de tecnologias diversas foi classificada como um problema nesta pesquisa, haja vista, a heterogeneidade excessiva de tecnologias agregue potencialmente retrabalho ao desenvolvimento. Alm deste ponto de heterogeneidade a arquitetura nem ao menos sugeriu alguma tecnologia, ou padro, para auxiliar na responsabilidade das camadas. Durante a pesquisa, todas as arquiteturas de referncia para a Web que se sucederam foram estudos replicados deste. No verificou-se nenhuma evoluo significativa nem mesmo outras abordagens que refutassem esta proposta. Com isto, para este trabalho de mestrado, fica evidente que a proposta de arquitetura a ser sugerida no prximo captulo, pode vir a ser uma substituta moderna da arquitetura Web 2.0, uma substituta que s ocorreu devido ao novo paradigma de Mquinas Sociais, que traduzem de outra forma as aplicaes Web e a prpria web.

58

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

3.5. CONSIDERAES FINAIS DO CAPTULO CRTICAS Ao longo do estudo, vrias pesquisas foram analisadas, algumas corresponderam perfeitamente s questes investigadas, outras mostraram pouca contribuio. Neste sentido, foi interessante verificar que a arquitetura de referncia para aplicaes Web foi to pouco abordada, apenas o estudo de James Governor considerou o assunto de maneira mais clara e objetiva. O fato das aplicaes Web serem desiguais em termos de funcionalidade e de tecnologia pode ter motivado um relativa falta de classificao, o que talvez tenha dificultado a criao de uma arquitetura de referncia. Classificando as aplicaes Web 3.0 como Mquinas Sociais, possvel visualizar uma melhor soluo em arquiteturas de referncias, pois que se conhece, e se define melhor, os aspectos e particularidades das aplicaes. O mesmo ocorre com os conceitos de Cloud Computing, ao passo que, quando se definiu melhor os conceitos de CC, foi possvel encontrar muitos materiais que tratem do assunto por aspectos diferenciados. Ao finalizar o estudo possvel mapear certas tendncias sobre algumas tecnologias, as quais foram utilizadas e relatadas repetidamente entre as arquiteturas. Essas tendncias apontam para: Construo de APIs prprias; As APIs podem contribuir diretamente para a extensibilidade da Mquina Social; Utilizao de APIs: API Java; API Twitter 4J, e API Facebook; Utilizao de balanceadores de carga para prover desempenho; Utilizao de Web Services; Aplicao dos protocolos REST e SOAP; Definio de arquiteturas com a camada de infraestrutura suportada por Computao nas Nuvens; Utilizao de linguagens de programao que facilitem a rapidez na codificao alm de contribuir para o desempenho e escalabilidade do sistema, como por exemplo: a adoo da linguagem Rails que j suporta PHP e REST; Aplicao do estilo arquitetural Camadas.

Ao fim desta seo, vale observar o intensivo uso do estilo arquitetural em Camadas, o qual organiza o sistema em unidades hierrquicas, se comportando como a evoluo do 59

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

estilo cliente servidor, visto que as camadas solicitam servios uma das outras, interagindo entre elas como cliente e servido (GAMMA, et al 2000). Alguns autores defendem a adoo do estilo arquitetural Camadas; Christine Hofmeister (2000), por exemplo, considera que o estilo em camadas organiza a arquitetura do sistema por separar a parte funcional da parte de apresentao, proporcionando assim, uma viso de mdulos31 essencial para a documentao do sistema. As tendncias pontuadas acima do indcios que podem auxiliar no desenvolvimento de SMs, pois as solues que se repetiram ao longo dos estudos foram empregadas em grandes projetos dentro da indstria de software. Alm deste ponto, as solues mapeadas contribuem, a priori, para a escalabilidade, proteo contra falhas, distribuio e comunicao. Todos estes fatores esto ligados as caractersticas das SMs, enquanto outros fatores provocam controvrsias na aplicao das arquiteturas estudadas, o que ser relatado a seguir. Materiais publicados e investigados para esta pesquisa revelam que algumas das Mquinas Sociais exploradas se mantiveram eficientes, enquanto outras simplesmente saram do mercado. Como, por exemplo, as ferramentas online para desenvolvimento de Mashups. Outro ponto questionvel a falta de mecanismos que previnam a interrupo de alguns servios Cloud Computing, como exemplo, o problema da Amazon (IaaS) no ano de 2011. Segundo publicao da prpria Amazon, no dia 21 de abril de 2011 o servio EC2 foi desabilitado devido a um problema tcnico que causou falha no fornecimento do servio de uma das zonas de disponibilidade da Amazon. Esta zona trabalhava para os Estados Unidos e deixou usurios do leste do pas sem o servio por mais de 24 (vinte e quatro) horas, alguns gigabytes de dados foram perdidos. Muitos dos casos semelhantes ao exibido acima se deve ao fato de que no modelo arquitetural Camadas basta que o componente de uma camada entre em colapso para afetar outros servios e camadas dependentes. No modelo Camadas ocorre forte dependncia entre as camadas, se fazendo necessrio alguns artifcios que previnam a falha de uma camada ou que sustentem o servio mesmo que sobre um problema.

31 Perspectiva que mapeia os mdulos do sistema. Mdulos so entidades que implementam um conjunto de funcionalidades para o sistema (SHAW, GARLAN, 1996)

60

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

Entre controvrsias e conformidades a tecnologia empregada faz total diferena. A falha da Amazon s um exemplo dos fatores negativos que a arquitetura de uma SM deve estar preparada para enfrentar. Outra crtica a heterogeneidade de plataformas, como as Mquinas Socias so sistemas distribudos por natureza, deve-se notar que existem algumas diferenas tecnolgicas, sejam em linguagens, sistemas operacionais ou paradigmas de desenvolvimento em SM que hora so fornecedoras de servios, hora so consumidoras de servios. Portanto, todas as decises em projeto de SMs devem ser bem analisadas e empregadas na arquitetura. A interoperabilidade outro ponto preocupante na anlise deste estudo, os elementos arquiteturais devem trabalhar bem sobre este ponto, arquiteturas orientadas a servios, e adoo de protocolos como REST e SOAP, so iniciativas inteligentes que vem gerando resultados produtivos nas aplicaes mapeadas, mas que de fato, podem no ser to eficientes para algumas Mquinas Sociais. Neste aspecto, a Computao nas Nuvens um ponto de grande desafio, por isso o quantitativo de pesquisas e experincias tem sido to significativo, impulsionando os padres que facilitam a comunicao e interoperabilidade em plataformas e aplicativos nas nuvens (DMTF, 2011), bem como a criao de pacotes de desenvolvimento SDK que algumas linguagens de programao como Java e PHP possuem. Ainda entre estes questionamentos interessante observar outros fatores, a arquitetura Multitenant, por exemplo, ela constitui um modelo que compartilha recursos fsicos, o que poder ser um fator de insegurana para alguns sistemas, apesar de favorecer fortemente o crescimento da aplicao, em virtude da facilidade dos recursos. O resultado deste estudo mostra boas direes para se atingir o objetivo deste trabalho, entretanto, no contexto de desenvolvimento de software, to importante quanto o aspecto tecnolgico, o processo de concepo arquitetural. extremamente relevante conhecer o que se deseja construir, quais servios so necessrios, onde podem ser encontrados, como ser feita a comunicao e servios e como elas iro impactar no comportamento do software ou aplicao. Assim, o prximo captulo trar um material til para se obter tais conhecimentos e fundamentar uma boa arquitetura para as SMs. Tecer crticas, sejam elas positivas ou negativas, a respeito de arquiteturas algo delicado, haja vista a arquitetura seja muito particular ao software. Arquiteturas que podem no parecer muito inteligentes fazem um software funcionar por anos. O que se pode 61

Captulo 3. Reviso da Literatura de Arquiteturas de Software Para Mquinas Sociais

certamente afirmar que toda arquitetura deve ser coerente aos requisitos no funcionais. Com isto, na exibio de uma arquitetura, importante deixar claro quais os requisitos atendidos por ela. Isto no foi verificado para os estudos mapeados neste captulo. Alm do problema acima relatado, existe tambm a ausncia de um modelo de referncia em conjunto ao estilo arquitetural adotado para as arquiteturas que so de referncia. Como ser visto no prximo captulo, isto fundamental para criao da arquitetura, por serem informaes que influenciaro nas decises de projeto da mesma. Para finalizar este captulo, a tabela 3 sumariza, para as Mquinas Sociais, todos os pontos relevantes que foram tratados, ou no, pelas arquiteturas. Os pontos so importantes para as SMs e ofertaro subsidio para a formulao da arquitetura de referncia. Com a tabela, possvel notar que o atendimento as necessidades materializa os requisitos mais tratados pelas arquiteturas. So eles: performance por meio da expanso da arquitetura e modificabilidade por meio da manuteno.
Computing_Kossmann et al, Arquitetura Mashup_Merril Computing_Vecchiola 2009 Huebscher, White et al,IBM Arquitetura Autnoma 2004 2003 Necessidades atendidas

Arquitetura Redes Sociais

Arquitetura Mashup_Liu

Servios Comunicao Facilitada Manuteno Facilitada Infraestrutura Reatividade Conectividade Expanso

X X X

X X

X X

X X X X X X X X

Tabela 3. Pontos ou aspectos mais trabalhados pelas arquiteturas

Arquitetura para Web 2.0

Arquitetura Multitenant

Computing_IBM, 2011

Autnomos_Mccann,

Arquitetura Sistemas

Arquitetura Cloud

Arquitetura Cloud

2010 Arquitetura Cloud

(Hoof ; Aurin)

2006

2009

62

Captulo

4
4. Proposta de Arquitetura de Referncia Para Mquinas Sociais
Este captulo prope uma arquitetura de referncia para Mquinas Sociais. Nele sero abordados alguns conceitos sobre arquitetura de referncia, a respeito das suas teorias e concepo. A arquitetura de referncia de Mquinas Sociais ser exibida em vises. A avaliao na qual essa arquitetura foi submetida tambm ser exposta neste captulo, mostrando assim, como esta proposta pode ser adequada para as Mquinas Sociais.

63

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

4.1. INTRODUO

O estudo no captulo anterior um recurso que tambm objetiva mostrar o estado da arte das arquiteturas de aplicaes Web contextualizadas como Mquinas Socias. Apesar de tais aplicaes no deixarem evidente todas as particularidades e detalhes de suas arquiteturas, foi possvel entender a organizao e concepo das mesmas, alm ter um estudo de referncia para SMs. Atravs desde estudo possvel dispor de um prottipo de arquitetura de referncia para Mquinas Sociais. Trata-se de um modelo experimental que deve servir de precedente aos exemplares de arquiteturas de SMs. Como visto no captulo 2, as SMs podem ser classificadas desde aplicaes Web simples at frameworks e IaaS, com isto, a formulao de uma arquitetura padro para essas SMs demandaria um tempo de pesquisa consideravelmente maior, da a inteno de sugerir um prottipo apenas para Mquinas Sociais que sejam aplicaes Web e que sejam do tipo Prossumers. O objetivo de ofertar esse modelo ter uma arquitetura que possa orientar no processo de definio das arquiteturas de SMs a serem construdas. Ou seja, essa arquitetura seria um exemplo de como deve ser a arquitetura de uma SM, e deve ser entendida como o arcabouo bsico que ser customizado conforme os requisitos da Mquina Social. Vale frisar que tal modelo mais adequado s SMs que so aplicaes WEB, assim, o trabalho focado em sistemas WEB, ou ainda Software as a Service. Tratando-se de uma pesquisa que envolve fortemente arquitetura de software, cabe aqui esclarecer melhor alguns pontos, principalmente os relacionados a arquitetura de referncia. Para se construir uma arquitetura de SM necessrio entender o software como uma Mquina Social, e assim poder agir assertivamente sobre as anlises e decises de projeto e consequentemente sobre a arquitetura. Deste modo tal arquitetura de referncia parece ser ideal justamente por ser um ponto de incio para as arquiteturas de sistemas que resolvem problemas de um mesmo domnio.

4.2. ARQUITETURA DE REFERNCIA

A inteno de originar uma arquitetura de referncia parte do conceito de que a arquitetura divide as funcionalidades e os fluxos de cada parte do software, demonstrando 64

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

como pode ocorrer a cooperao entre elas (BASS, CLEMENTS, e KAZMAN, 2003). A arquitetura de referncia facilitar o desenvolvimento modular do software que for projetado acima dela. Esse desenvolvimento traz benefcios, como: reduo do tempo de desenvolvimento, pois j um modelo que pode ser adaptado para a arquitetura; aumento do reuso de software; auxlio para a equipe de desenvolvimento evitar erros j cometidos. Por fim, arquiteturas de referncia sugerem a implementao de mdulos que tenham interfaces bem definidas, tanto as Interfaces Providas, que disponibilizam servios, como as Interfaces Requeridas, que expem as necessidades dos servios, ou seja, a quem o mdulo precisa se conectar (GARLAN e SHAW, 1994). Uma arquitetura de referncia se origina de um ou mais padres arquiteturais, e de um modelo de referncia32. A Figura 14 esquematiza esse raciocnio.

Modelo de Referncia
Padro ou Estilo Arquitetural

Arquitetura de Referncia

Arquitetura de Software

Figura 14. Relao entre modelo de referncia, padres arquiteturais e arquitetura de referncia

Fonte: Adaptao do livro Software Architecture in Practice, 2003. 2ed. Addison Wesley.

Modelos de referncia so solues a nvel de negcio que tratam de problemas de um mesmo domnio; os estilos ou padres arquiteturais so os modelos que agrupam os componentes arquiteturais de modo que os mesmos possam interagir sempre da mesma forma, auxiliando assim na resoluo de um problema (GOVERNOR, 2009). Seguindo tais conceitos atingiram-se as arquiteturas de referncia, que apresentam solues tcnicas s arquiteturas de uma famlia de software (MULLER, 2011). Para se compor uma arquitetura de referncia necessrio trabalhar veementemente no processo de formao com os requisitos no funcionais (qualidade); necessrio ainda interagir com pessoas que faam parte do modelo de negcio para se obter informaes sobre o contexto de negcio e requisitos inerentes ao mesmo. Por fim, no processo de formalizao

32

Modelo de referncia um padro de decomposio de um domnio de negcio ou problema conhecido (GARLAN SHAW, 1993].

65

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

de uma arquitetura de referncia necessrio considerar fatores tecnolgicos, conceitos, requisitos de clientes, padres e abordagens de desenvolvimento de software. A tarefa de identificao dos clientes, para extrao de requisitos, a mais crtica, haja vista que a extrao dos conhecimentos exija fontes mais abrangentes, como: documentos, pesquisas, ferramentas e profissionais, pois se trata de uma arquitetura muita genrica. O que deve ser considerado para compor o processo de definio de uma arquitetura de referncia exaltado nos estudos de Muller em 2011 e Nakagawa em 2006. Ambos foram referncia para este captulo. As exigncias em projetos de arquitetura de referncia so grandes por necessitarem de observaes em domnios ou famlias de softwares de modo que se possa definir uma arquitetura genrica na qual desenvolvedores possam se basear para montar a arquitetura do sistema (BASS, CLEMENTS, e KAZMAN, 2003) a ser desenvolvido. Arquiteturas de referncia so instanciadas em um projeto de software, e podem existir ou serem utilizadas em diferentes nveis de abstrao a partir de diversas perspectivas (BASS, CLEMENTS, e KAZMAN, 2003). O processo de formalizao da arquitetura de referncia ainda pode ser facilitado quando se conhece experincias de arquiteturas j existentes para o domnio. Em uma anlise dessas arquiteturas possvel detectar a eficincia, ou no, das mesmas para a soluo do problema, isto possibilita uma viso mais objetiva das solues que podem ser empregadas para o domnio.

4.3. ARQUITETURA DE REFERNCIA PARA MQUINAS SOCIAIS

A arquitetura de referncia que ser formalizada dever atuar como ponto inicial para o desenvolvimento das arquiteturas de aplicaes que fazem parte do modelo de referncia no qual as Mquinas Sociais esto inseridas. O estudo do captulo 3 dirigido arquitetura de Mquinas Sociais ser muito til para absolver as experincias com arquiteturas direcionadas as Mquinas Sociais. Enquanto isto todos os estudos feitos pela Universidade Federal de Pernambuco e por organizaes como o C.E.S.A.R (Centro de Estudos Avanados do Recife) que resultaram na criao de um grupo direcionado ao estudo de SMs, contribui fortemente para a identificao das fontes de informao (clientes) e para o amadurecimentos do Modelo de Referncia.

66

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

A arquitetura de referncia deve trabalhar bem os requisitos performance, disponibilidade, modificabilidade, e interoperabilidade, o que na realidade no ocorreu em todas as arquiteturas mapeadas no estudo do captulo anterior. Assim, nem todas as arquiteturas trataram as necessidades e requisitos fundamentais da Mquina Social. Apenas os requisitos performance e modificabilidade foram mais trabalhados. A tabela 4 pretende evidenciar as caractersticas e necessidades das SMs e como estas esto relacionadas aos requisitos no funcionais. A mesma tabela contribui para a compreenso de como os requisitos podem ser satisfeitos pela arquitetura. Aqui se deve entender que os requisitos no funcionais visam agregar benefcios e recursos que so exigidos pelas caractersticas da Mquina Social. Outra compreenso correta, a de que as solues propostas para atender os requisitos na arquitetura no so nicas, existem outras que podem ser trabalhadas conforme a caracterstica da requisio. O mais importante projetar a arquitetura de referncia para que ela seja capaz de atender todos os requisitos e caractersticas/necessidades exibidas na tabela abaixo.

Requisitos

Caractersticas e Necessidades das SMs

Soluo de Atendimento

Performance

Reatividade, Infraestrutura, Autonomia, expanso e Servios

1 Controle sobre a gerao de eventos; 2 Diminuir os elementos intermedirios comunicao; 3 Trabalhar bem com a infraestrutura conectividade. e com a de

Disponibilidade

Constncia, Sociabilidade, Reatividade, Infraestrutura, Servios, Colaborao e Comunicao facilitada

1 Redundncia: caso um elemento fique indisponvel, a redundncia (outro

elemento igual) deve ocupar o seu lugar. 2 Mecanismos que

verifiquem e alertem sobre 67

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

possveis falhas. Modificabilidade Sociabilidade, Manuteno facilitada, e Autonomia 1 Elementos arquiteturais33 que facilitem a manuteno da SM. 2 Separar responsabilidades em camadas; 3 Manter a coerncia

semntica para facilitar a identificao arquitetural. 4 Isolar funcionalidades que possam alteradas. 5 Inserir elementos ser facilmente do elemento

intermedirios que diminuam a dependncia. Interoperabilidade Colaborao, Infraestrutura, Sociabilidade e Conectividade. 1 Identificar e trabalhar com as interfaces providas e

requeridas; 2 Trabalhar com padres de interoperabilidade.

Tabela 4. Atendimento aos requisitos pela arquitetura conforme as caractersticas e necessidades da SM.

Aps visualizar e entender ainda mais a questo dos requisitos no funcionais, importante dar foco as outras questes arquiteturais como o estilo arquitetural. O estilo arquitetural a ser adotado o estilo em Camadas, o mesmo que foi a grande tendncia do estudo mapeado, o que poderia ser esperado, pois tal estilo extensamente utilizado para desenvolver aplicaes Web. vista disso a arquitetura de referncia para Mquinas Socias est ilustrada na Figura 15. Seus pontos sero explicados em seguida, bem como demais vises da mesma.

33

Casos de uso, classes, camadas e demais componentes que constituem as vises arquiteturais.

68

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

importante colocar que a descrio arquitetural documentada nesta pesquisa est de acordo com a norma IEEE 1471 (IEEE, 2000) que recomenda a especificao da arquitetura ou os documentos arquiteturais: Com os elementos arquiteturais identificados, organizados, e com suas responsabilidades bem definidas; Com os requisitos relevantes a nvel arquitetural, atendidos pela arquitetura definida; Com a representao de diferentes vises arquiteturais.

A Figura 15 exposta abaixo retrata a arquitetura por uma viso de mdulos, exibindo as camadas e suas interaes. O objetivo desta viso expor a Mquina Social em unidades, mostrando a dependncia entre tais unidades. Por meio da viso possvel exibir mais facilmente o tratamento a alguns requisitos, como: portabilidade, reuso e interoperabilidade; alm disto, possvel representar a arquitetura da Mquina Social em tempo de desenvolvimento, ou seja, de mdulos a serem realmente estruturados e alinhados (KRUCHTEN, 1995).

Figura 15. Arquitetura de Referncia para SMs

69

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

A primeira camada a Presentation. Esta uma camada bsica de interao com o usurio. Esta camada pode ser implementada de diversas maneiras, ou seja, para algumas SMs ela pode ser apenas uma camada onde as SMs requisitantes (clientes) estejo alojadas. Este seria o caso de Mquina Sociais como o MapReduce e outras PaaS e IaaS. Essa camada pode ser ainda a uma camada capaz de produzir qualquer interface de apresentao e exibio de dados. Tal camada pode ainda, porventura, nem existir na SM, mas sim, ser concebida por outra Mquina Social, como no caso dos sites Mashups. Deste modo, a Presentation no ser especificada neste trabalho, sua criao depender fortemente do tipo de SM a ser construda. Entre a primeira camada, seja ela de qualquer natureza, e a segunda camada, existem os balanceadores de carga que vo distribuir as solicitaes de acesso (requests), estes atendem ao requisito desempenho. Os balanceadores so apenas um exemplo, pois o que se propem na verdade so mecanismos que faam o tratamento em blocos das solicitaes. Isto melhorar o desempenho consideravelmente se comparado ao tratamento e processamento individual das requisies. A camada Wrapper sem dvida uma das mais relevantes para a Mquina Social, ela uma camada dedicada comunicao e interoperabilidade. Alm de viabilizar a conexo entre as SMs, esta camada a implementao do elemento Wrapper citado no captulo 2. inteligente pensar que ela poderia ser concebida como a API da Mquina Social, sendo que uma API um conjunto de requests e responses (KALIN, 2010). Assim, os mtodos vlidos para criar uma API poderiam ser utilizados. Com a API na camada Wrapper possvel expor os servios da aplicao de modo que outras aplicaes usufruam destes servios, ou funcionalidades, sem se preocupar com alguma implementao adicional. Nesta parte da arquitetura o surgimento dos formatos XML ou JSON fato, bem como, a implantao de Web Services para apresentar os servios disponveis. As linguagens XML e JSON facilitam o cumprimento do requisito de interoperabilidade. Trata-se, na verdade, de linguagens de grande flexibilidade e poder semntico (TITTEL, 2003) com troca de informaes independente de plataforma ou tecnologia. A camada seguinte a camada Processing Unit, uma camada voltada ao negcio e responsvel por bastante processamento; nela que devem existir mecanismos para verificar e divulgar informaes da SM, como o status do funcionamento da mesma. Este mecanismo a 70

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

implementao do elemento State. A camada Processing Unit tambm um elemento da SM que alm de monitorar, deve ainda satisfazer as funcionalidades da mesma. Tal camada deve ter componentes que atendam as funcionalidades e satisfao dos requisitos funcionais da Mquina Social (Controllers e Services). A Processing Unit , em conjunto camada Wrapper, a mais importante para a SM, e tambm pode ser a mais complexa de se conceber. A Processing Unit implementa o elemento Constraints. Nele ser possvel obter as limitaes, a carga de trabalho e o tempo de resposta aceitvel de uma Mquina Social. Outra caracterstica importante da camada Processing Unit a comunicao perfeita com a camada anterior a ela, a camada Wrapper, haja vista todos os produtos gerados pelo componente State devem ser refletidos tambm na camada Wrapper para que a mesma saiba o status de cada servio. No trecho acima a camada de negcio foi elucidada. importante citar que esta camada pode dar suporte a todos os requisitos de qualidade da SM, principalmente o requisito de modificabilidade, sendo que, a alterao das Constraints no compromete outros componentes da Mquina Social. O produto desta camada insumo para o funcionamento da camada de repositrio de dados. A prxima apresentao justamente sobre a camada de infraestrutura e acesso a dados. A camada Persistence/Infrastruture a camada de suporte da Mquina Social. Ela responsvel por servios de hospedagem para o desenvolvimento da aplicao; servios de capacidade computacional, ofertando recursos necessrios ao desenvolvimento; e servios de armazenamento de dados. Nesta camada possvel verificar, analisar e direcionar as demandas de acesso aos dados. Por tratar as solicitaes de registro e consulta, tal camada pode monitorar o tempo e a adequabilidade das respostas, trabalhando iniciativas de correo caso algo esteja fora do padro aceitvel pelas Constraints. Os bancos de dados e a infraestruutra computacional so uma parte ligada arquitetura, e no necessariamente contida nesta. Deve-se ter esse entendimento uma vez que, a camada de banco de dados no necessita ser implementada pela equipe desenvolvedora da Mquina Social. Assim, entende-se que tal camada pode ser disponibilizada por meio de um servio Cloud Computing, o que facilitaria a rplica destas camadas auxiliando na satisfao do requisito disponibilidade. Para atingir esse requisito necessrio que os componentes

71

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

estejam sincronizados. O artifcio de possuir rplicas pode, inclusive, ser utilizado para outras camadas arquiteturais. A deciso por obter um servio Cloud Computing algo muito particular de cada aplicao, devem-se analisar as necessidades da SM, os custos, a segurana, e os recursos de replicao. Em um projeto de Mquina Social os servios de Cloud Computing podem ser muito teis equipe de desenvolvimento, sendo que, esta no teria preocupao com a manuteno ou preparao de mquinas servidoras (ZHANG e ZHOU, 2009). Para finalizar importante esclarecer que esta arquitetura de referncia deve ser customizada levando em considerao a finalidade da Mquina Social e todos os seus requisitos funcionais, e principalmente sua taxonomia. Como por exemplo: a camada Wrapper pode se comportar tambm como uma camada de aplicao em casos onde uma Mquina Social possa estar conectada com muitas outras SMs que sejam clientes dela.

4.4. VISES DA ARQUITETURA DE REFERNCIA

Aps descrever a arquitetura, a viso de implantao ser ilustrada. Por meio dela, ser possvel visualizar todas as Mquinas Sociais que compem a arquitetura de referncia e como as mesmas distribuem o processamento da aplicao. Essas SMs interagem umas com as outras executando funes diferentes e assim se completando (GORTON, 2006). Por meio desta viso, possvel avaliar ainda os requisitos no funcionais de desempenho e disponibilidade (KRUTCHEN, 1995). Ela dividir a arquitetura em ns processadores e componentes executveis, o que dar a visibilidade de que uma Mquina Social composta por outras Mquinas Sociais.

72

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

Figura 16. Viso de Implantao

Em um diagrama de implantao, geralmente exibido a especificao de cada n, ou seja, qual o tipo de sistema operacional, a especificao da mquina, ou ainda o sistema de banco de dados a ser implantado no n. Todavia, no deve-se em uma arquitetura de referncia fixar especificao de tecnologias ou mquinas (MULLER, 2011). Deste modo, fica ilustrado apenas a localizao dos ns com as especificaes: device e Database - DB. Por meio do diagrama na figura 16, possvel notar a ditribuio fsica de cada componente, ou como representado anteriormente, de cada camada da Mquina Social. A distribuio em ns diferentes no algo obrigatrio, isto depender muito do tipo de Mquina Social. Por exemplo: em SMs mais simples que faam rotineiramente atividades de consulta e insero de dados, seria interessante ter um n maior constitudo pelas camadas Presentation e Wrapper. Isto traria um aumento de desempenho da SM. Ento, a alocao das camadas aos ns computacionais para todos os tipos de Mquinas Sociais pode variar entre 1 n ou 3 ns. Aproveitando o ensejo, importante novamente frisar que o n Persistence/Infrastruture satisfeito por uma Mquina Social com servios Cloud Computing. Sero exibidas outras vises de partes da arquitetura. Estas partes correspondem s duas camadas mais importantes para a SM, a camada Wrapper e Processing Unit.

73

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

Figura 17. Diagrama de Classe (Viso de mdulos_Wrapper e Processing Unit)

O diagrama na figura 17 exibe as camadas Wrapper e Processing Unit como subsistemas; dentro de cada existem as classes que a compem. Nota-se que um terceiro componente do Processing Unit (Controllers/Services) no est presente na viso. Sua excluso foi proposital, visto que o mesmo um elemento que deve agregar muitas outras classes funcionais da SM que iro contemplar as funcionalidades da Mquina Social e que tero comportamentos e relaes muito particulares e relativos aos requisitos funcionais. Nesta viso, o entendimento deve ser de que o primeiro subsistema se relaciona com o segundo por intermdio de uma classe abstrata que diminuir o acoplamento entre as classes. Essa reduo importante para possibilitar o atendimento ao requisito de modificabilidade. Uma classe abstrata age como uma interface mais robusta, capaz de ofertar independncia (GAMMA et al, 2000) entre as classes no sentido que elas possam sofrer alteraes sem atingir fortemente as classes relacionadas a ela. Para otimizar o acoplamento baixo, o padro de projeto Facade deve ser incorporado, pois o mesmo especialista em unificar interface facilitando o acesso aos subsistemas e independncia entre as classes. A insero de mecanismos contra o acoplamento alto no prejudicar o relacionamento dos subsistemas, pois a classe

74

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

LearningStatus possui apenas a funo de capturar os dados da classe States para assim montar o estado dos servios, com isto o acoplamento existir, mais ser fraco. O segundo subsistema composto, a priori, pelas classes Constraints e States. Nele, a classe States depende da classe Constraints para alterar a situao dos servios da Mquina Social. Neste aspecto, existe um acoplamento de controle entre essas duas classes, sendo que uma exerce controle sobre o comportamento da outra. Apesar de o acoplamento ser ruim qualidade de qualquer sistema, neste caso, e em muitos outros, ele se faz necessrio (LARMAN, 2007) pelos objetos necessitarem interagir com outros objetos e na troca de mensagem; esse o caso entre Constraints e States. Para enteder melhor o diagrama de classe e a relao entre estes dois subsistemas, ser ilustrado, para a camada Wrapper, um diagrama de componentes com portas e interfaces. Atravs desta viso, possvel verificar a colaborao entre os componentes ou classes, (BOOCH, RUMBAUGN, JACOBSON, 2005) bem como os servios que cada componente pode prover ou requerer para a SMs. A Wrapper a interface da SM que exibe todos os servios providos e requeridos pela mesma. Neste ponto, a Wrapper pode ser visualizada como um conjunto de rotinas que pode evidenciar a utilizao das funcionalidades da SMs. Para possibilitar o trabalho da Wrapper necessrio que a mesma esteja sempre ciente do estado dos servios da SM, assim, necessrio um componente que leia o estado da Mquina Social disponvel pelo componente State na camada de Processing Unit. A Figura 18 ilustra esta viso de componentes e conectores. Aps obter os dados da Mquina Social e determinar a situao dos servios, necessrio disponibilizar essa situao para o componente responsvel pela mediao entre a Mquina Social e as demais aplicaes interligadas. Esse componente pode ser um Web Service ou ainda um Middleware flexvel que facilite a integrao e comunicao entre as aplicaes. O que interessa possuir um elemento que seja na verdade um programa computacional que faa o transporte das informaes e dados entre as aplicaes de forma independente de protocolos e plataformas, e que satisfaa o requisito interoperabilidade. O componente intermedirio representado na viso seguinte com o nome: Social APIMiddleware Machine. necessrio ter cuidado na adoo desses elementos intermedirios que faam a comunicao entre os demais elementos arquiteturais, pois esses elementos 75

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

mediadores podem aumentar o processamento de um fluxo de evento ocassionando a perda de desempenho.

Figura 18. Diagrama de Componentes: Viso de Componentes e Conectores

Tratando-se de vises arquiteturais, as mesmas podem detalhar algum elemento especfico da arquitetura (KRUCHTEN, 2010), deste modo a prxima viso para a arquitetura de referncia de Mquinas Sociais ir contemplar dois elementos importantssimos para as SMs, os elementos States e Constraints. Como j exposto eles so responsveis pelo monitoramento e pelos requisitos no funcionais da Mquina Social, respectivamente; tais elementos devem interagir de forma facilitada, pois que, informaes geradas por um interferem no funcionamento do outro. Os elementos States e Constraints sero abordados por meio de uma viso que exalta o tempo de execuo da SM, por intermdio de um diagrama de sequncia. Essa viso capaz de representar a arquitetura em tempo de execuo. uma viso que foca mais no comportamento do componente arquitetural perante as interaes e exibe bem os protocolos de relacionamento e confiabilidade (GORTON 2006).

76

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

Figura 19. Diagrama de sequncia: Viso em tempo de execuo

O diagrama de sequncia na figura 19, a seguinte interpretao deve ser obtida. Um requisitante exige um acesso, o elemento State deve enviar uma mensagem que avalie se o acesso do requisitante permitido, ou seja, se possvel ainda dar o tipo de acesso que requerido, o elemento Constraints avalia a permisso de acesso e retorna ao elemento anterior que, por sua vez, permite o acesso ao tipo de transao que o requerente desejar. Por fim, o requisitante, j com livre acesso, envia dados para algum tipo de transao e aguarda o seu retorno, que deve se originado por algum componente que implementa as regras de negcios e funcionalidades da Mquina Social. A interpretao acima baseada em um exemplo simples de funcionamento dos elementos citados. O funcionamento ilustrado pelo diagrama de sequncia pode ser implementado de outra forma, o importante manter a comunicao entre os elementos do diagrama. A arquitetura de referncia apenas um modelo. evidente que outros detalhes sejam pertinentes a esta arquitetura. Entretanto, so detalhes mais especficos de cada Mquina Social a ser desenvolvida. O importante adotar as camadas e os componentes que as compem bem como o estilo arquitetural que o Relaxed Layered System, como j explicado, uma variao do estilo Camadas. 77

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

A adoo de tal arquitetura seria interessante para padronizar os projetos de Mquinas Sociais. Deste modo, cabe nesta pesquisa, avaliar a arquitetura proposta para que a adoo da mesma possa ser viabilizada com mais segurana.

4.5. AVALIAO DA ARQUITETURA DE REFERNCIA E DE SUAS VISES

A arquitetura de referncia aqui proposta deve ser avaliada para verificar a adequao e consistncia da mesma aos requisitos no funcionais de uma Mquina Social. O que deve ser avaliado so as representaes arquiteturais, ou seja, as vises arquiteturais que so oriundas da arquitetura de referncia e a prpria arquitetura. A partir dos dados extrados de tais avaliaes, ser possvel identificar pontos de fraqueza na arquitetura de referncia e nas vises da mesma. Pontos de fraqueza so defeitos encontrados nessas representaes arquiteturais. Para avaliar uma arquitetura, existem vrios mtodos, entre eles: Architecture Tradeoff Analysis Method - ATAM e Software Architecture Analysis Method - SAAM, estes so mtodos que avaliam as arquiteturas por meio de cenrios que devem representar o comportamento esperado de um sistema perante um requisito de qualidade, estes mtodos basicamente avaliam se a arquitetura proposta contempla os requisitos no funcionais, ou de qualidade, exigidos para o software (KAZMAN et al. 2000). As abordagens citadas como exemplo de avaliao arquitetural possuem limitaes quanto ao emprego das mesmas na arquitetura proposta neste trabalho. As limitaes so reais devido a arquitetura proposta ser uma arquitetura de referncia (NAKAGAWA, 2006). Como j exposto, este tipo de arquitetura muito genrica e representa todo um domnio de software. Assim, avaliar atributos mais especficos para este caso um tarefa invivel. Alm da limitao citada, existem outras que tambm poderiam afetar uma avaliao prtica e correta da arquitetura de referncia pelos mtodos citados acima, entre elas: Avaliaes por meio dos mtodos ATAM e SAAM podem se tornar muito subjetivas por dependerem fortemente do conhecimento dos avaliadores (CORANDI et al. 2003); ATAM e SAAM so avaliaes que necessitam de um nmero maior de pessoas envolvidas (CORANDI et al. 2003). 78

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

ATAM e SAAM avaliam cenrios especficos para a arquitetura, de modo que seja necessrio construir uma situao na qual a arquitetura ser submetida, neste cenrio a arquitetura deve se manter estvel possibilitando o software a executar sua funcionalidade.

Levando em considerao as limitaes abordadas, ser aplicada neste estudo a tcnica de inspeo sobre os documentos ou vises arquiteturais. Tcnicas de inspeo de software so mtodos rigorosos para se avaliar um artefato de software (BOEHM e BASILI. 2001). Para este trabalho, a tcnica de inspeo a ser utilizada ser o Checklist.

4.5.1. TCNICA DE INSPEO

O Checklist utilizado na avaliao da arquitetura proposta nesta pesquisa baseado nos trabalhos do programa de engenharia de software da Universidade Federal do Rio de Janeiro no ano de 2002 e 2006 (TRAVASSOS et al. 2002), e nos trabalhos de Laitenberger e DeBaund (1998). Tais trabalhos foram direcionados confeco e customizao de Checklists de documentos arquiteturais que pudessem ser utilizado largamente, inclusive em arquiteturas de referncia. Segundo os autores citados, o sucesso de tal tcnica de inspeo em documentos arquiteturais se deve ao fato de: A aplicao do Checklist no envolver atividades complexas e demoradas, nem to pouco a elaborao de cenrios de qualidade. Deste modo, a avaliao de baixo custo e menos subjetiva por no depender de cenrios. O Checklist formado por itens de questionamento que podem ser personalizados conforme a arquitetura documentada, pois tais itens devem avaliar a forma com que a arquitetura pode atender aos requisitos e no a forma com que essa documentao foi feita ou a que tipo de arquitetura direcionada. Os itens de questionamento devem avaliar principalmente discrepncias em relao aos requisitos funcionais e no funcionais. Com isto, vrias caractersticas podem ser avaliadas e no somente as referenciadas em cenrios.

79

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

possvel definir um processo de configurao dos itens de questionamento para que os mesmos possam adaptar o Checklist s caractersticas do documento arquitetural e ao objetivo da avaliao.

4.5.1.1. Perfil dos Avaliadores (inspetores)

Sero quatro avaliadores: um professor, arquitetos de software e estudantes de mestrado em cincias da computao. Existir ainda, para intermediar tal inspeo, o autor dos documentos de viso arquitetural. importante registrar que no existem estudos que afirmem qual o nmero ideal de participantes em um processo de avaliao deste tipo (KALINOWSKI, 2004) (TRAVASSOS, 2002).

4.5.1.2. Taxonomia dos Defeitos a Serem Encontrados

As abordagens avaliativas baseadas em Checklist visam identificar defeitos. Para este trabalho, os defeitos devem ser identificados nos documentos arquiteturais. Os defeitos que se pretende encontrar esto baseados nas definies e estudos de Shull (1998) e esto pontuados como se segue: Defeitos por omisso: ocorre quando um elemento arquitetural necessrio para o atendimento a um requisito no foi atendido ou mensurado. Defeitos por ambigidade: quando um elemento arquitetural dificulta o atendimento a um requisito. Defeitos por inconsistncia: quando o mesmo elemento arquitetural representado com nomes diferentes em vises distintas. Ou quando o mesmo elemento arquitetural tem responsabilidades distintas em uma ou mais vises. Defeitos por fato incorreto: ocorre quando um elemento arquitetural no descrito de forma correta. Defeitos por informao estranha: defeito acometido quando no se consegue entender a atribuio ou responsabilidade do elemento arquitetural.

80

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

4.5.1.3. Processo de Inspeo (Avaliao)

O processo de inspeo com o Checklist de avaliao arquitetural prtico e constitudo por duas grandes atividades: Atividades de Planejamento e Configurao: o Configurar o Checklist selecionando os itens de questionamento que podem ser aplicados ao documento arquitetural a ser avaliado; o Adaptar os itens de questionamentos que podem ser aplicados somente quando os mesmos necessitarem de alguma alterao para melhor adequao ao objeto avaliado; o Identificar os avaliadores; o Distribuir os documentos necessrios avaliao (documento arquitetural e Checklist); Atividades de Deteco (avaliao): o Leitura de documentos de especificao para melhor entendimento da arquitetura a ser avaliada e dos requisitos a serem contemplados pela mesma; o Inspetores revistam individualmente os artefatos do documento arquitetural a procura de defeitos; o Inspetores respondem aos itens de questionamento do Checklist. 4.5.1.4. Correo dos Erros Encontrados

Aps a avaliao necessrio corrigir os pontos negativados no documento arquitetural. A correo deve ser conduzida pelos itens que foram negativos no Checklist. Aps correo, uma nova avaliao deve ser efetuada no documento arquitetural; neste ponto as atividades de planejamento e configurao do processo de avaliao podem ser postergadas.

81

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

4.5.2. RESULTADOS Os resultados que sero aqui pontuados foram extrados dos itens de questionamento respondidos na fase de deteco. Para o registro deste resultado importante mapear algumas questes daqui em diante. O Checklist foi respondido por cinco pessoas ao final das rodadas avaliativas, sendo que, na primeira rodada houveram trs pessoas que respnderam o Checklist. Enquanto que em uma segunda avaliao, o Checklist foi respondido por duas pessoas. Apenas uma pessoa participou respondendo o Checklist em ambas as rodadas, ou seja, houve a repetio de apenas um participante entre as avaliaes. Acredita-se que a no repetio de todos os participantes entre as rodadas acarretar um resultado mais preciso, pois que, novos avaliadores sero inseridos e estaro despreparados a qualquer julgamento e avaliao preliminares ou imaturos dos artefatos arquiteturais. Em contrapartida, a repetio de apenas um participante pode ser til para que tal avaliador verifique a real evoluo dos artefatos e consiga ser mais crtico e preciso em sua avaliao. Foi imprescindvel executar duas rodadas de avaliao pelo de fato de buscar sempre a melhoria contnua dos artefatos. Se houvesse mais tempo de pesquisa, e mais disponibilidade de outros avaliadores, seria interessante executar uma terceira ou quarta avaliao. Quanto a estas, os documentos arquiteturais estavam bem mais consistentes e coesos na segunda avaliao, do mesmo modo que o prprio Checklist. Para o Checklist foi verificado que alguns termos, ou mesmo, itens de questionamento, deveriam ser melhorados ou retirados. Foi o caso do item 4 (quatro) que avaliaria a dependncica entre classes. Existiram dvidas acerca deste item, de modo que, em 2 (dois) Checklists, de um total de 5 (cinco), ele no foi respondido, e em 1 (um) ele foi taxado como: no se aplica. Portanto, o item 4 (quatro) foi descartado de qualquer contabilidade dos itens de questionamento atendidos ou no atendidos. Seu descarte no foi prejudicial, sendo que outro item tambm tinha a funo de avaliar o mesmo critrio (dependncia). Ainda quanto aos itens, as palavras que atribuiam muita generalidade, como por exemplo: para todos ou todos; foram subtradas para a segunda rodada; verificou-se que 82

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

estas palavras estavam trazendo muitas respostas negativas na documentao. Sendo assim, se tratanto de uma arquitetura de referncia, no h necessidade de explorar todas as vises ou todos os diagramas e classes que so potenciais s SMs. As duas verses de Checklists utilizadas esto nos apndices (apndice A e apndice B). Os itens de questionamento objetivaram avaliar alguns critrios de suma importncia para qualquer arquitetura bem como detectar a presena dos defeitos seguindo a taxonomia proposta. Alguns itens avaliaram isto de forma mais direta. A tabela 5 ilustra o que cada item do Checklist pretendia investigar e qual a resposta esperada.
ITENS DE QUESTIONAMENTO RESPOSTA ESPERADA QUESTES AVALIADAS

1 - Ao analisar todos os No diagramas, foi identificado

Avaliar os relacionamentos e coerncia entre os componentes da arquitetura de forma que nenhum componente desponte

algum elemento arquitetural que no possua ficando

repentinamente.

relacionamentos, isolado dos demais?

2 - A descrio textual que Sim compem o documento est de acordo com o nos que foi

Coerncia entre a representao textual e grfica, e principalmente os defeitos por incosistncia.

representado

diferentes

diagramas grficos? 3 - Para os componentes, em Sim algum diagrama, foram Defeitos por omisso.

identificadas as classes ou subcomponentes que o compem? 4 Os relacionamentos Indiferente RETIRADO DO CHECKLIST. Pretendia avaliar a depedncia e o acoplamento.

realizados entre classes/subcomponentes alocados em componentes pais distintos foi definido como uma

83

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

dependncia

entre

esses

componentes pais em algum outro diagrama? 5 As interfaces so Sim Representao das interfaces e comunicao entre os componentes.

disponibilizadas por um nico componente/classe, ou

representadas de uma forma mais simples no expandida? Ou seja, ocorre uma

representao por meio de diagrama de classes ou de componentes e conectores com interfaces providas. 6 - Ao analisar as seqncias Sim de execuo descritas em uma viso de interao, pode-se dizer que as Analisar a coerncia entre as vises. Verificar se os componentes arquiteturais possuam os mesmos nomes entre as vises. requeridas e

classes/componentes definidas em uma viso modular foram alocadas em ao menos uma das seqncias? 7 - Os elementos arquiteturais Sim tm a sua presena na Analisar o atendimento aos requisitos funcionais e no funcionais, e se os mesmos foram trabalhados e justificados na

arquitetura justificada por um conjunto de requisitos no funcionais ou funcionais? 8 - As responsabilidades dos Sim elementos arquiteturais esto condizentes com os requisitos no funcionais que eles

arquitetura.

Analisar se a arquitetura atende de forma adequada (propem solues adequadas) os requisitos no funcionais.

84

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

atendem? 9 - Tticas arquiteturais foram Sim empregadas para satisfazer os requisitos no funcionais? Verificar se existem solues propostas pela arquitetura para o atendimento aos

requisitos, e se as solues esto corretas e claras.

10 - Elementos relacionados No possuem responsabilidades

Analisar a coeso da arquitetura. Coeso neste caso deve ser entendido como o princpio fundamental da orientao a objetos. Analisar se existem elementos que podem prejudicar o requisito desempenho.

iguais que possam ser alocadas em um nico elemento? 11 - Elementos intermedirios No como: mquinas de e virtuais, nomes, APIs; so

servidores repositrios

Elementos que viabilizam a comunicao entre os componentes arquiteturais podem prejudicar o desempenho.

utilizados como mediadores de comunicao entre os

elementos arquiteturais. 12 - Foi verificado algum Indiferente componente controle comportamento elemento?
Tabela 5. Questes analisadas pelo Checklist e respostas esperadas

Analisar a existncia de acoplamento ou

dependncias. que exera sobre de o outro

Existem trs itens de questionamento que visam avaliar a aderncia da arquitetura aos requisitos Isto ocorre pelo fato da maior responsabilidade da arquitetura ser o atendimento aos requisitos, sobretudo os no funcionais. Desta forma os 3 (trs) itens objetivam investigar o tratamento aos requisitos por questes escritas de forma diferente, mas que possuem o fim de captar no conformidades entre as solues, inclusive na incompatibilidade entre tais solues, como por exemplo: a solues para o requisito desempenho ser prejudicial a soluo do requisito disponibilidade. 85

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

Diante as respostas de cada item foi possvel extrair o seguinte percentual das duas avaliaes (figura 20).

Percentual das respostas


Respostas negativas (em desacordo com o esperado) 32%

Respostas s questes no aplicveis ("no se aplica") 6%

Respostas possitivas (de acordo com o esperado) 62%


Figura 20. Resultado da Avaliao (1 e 2 rodada)

O Checklist foi composto de 12 itens, cada avaliador respondeu ao menos uma vez um Checklist, e apenas um avaliador respondeu a dois Checklist em momentos diferentes. Sendo assim, a quantidade de respostas derivadas dos itens e da quantidade de Checklists oriundos de cada avaliador 60 (sessenta). Entretanto, o item 4 (quatro) foi anulado; ademais, o item 12 (doze) tambm um item neutro. Ou seja, suas respostas podem ser descartadas para a estatstica, tendo em vista que, o acoplamento algo presente em alguns sistemas (FERREIRA, BIGONHA e BIGONHA, 2008) inclusive recomendado que exista acoplamento, desde que ele seja controlado (LARMAN, 2007). Com isto o percentual de 100 (cem) referente as 50 (cinquenta) respostas que de fato foram calculadas para averiguar a qualidade da arquitetura. Os valores acima so a totalidade das duas rodadas avaliativas. Se este resultado for mais detalhista, possvel obter valores separados das duas rodadas como exibido a seguir: Tendo em vista que a quarta e a dcima segunda questo no entram no quantitativo, para a 1 rodada avaliativa houve 30 (trinta) respostas vlidas, onde nenhuma foi do tipo no se aplica. Desta quantidade, 15 (quinze) respostas foram de acordo com o valor esperado, e 15 (quinze) em desacordo, o que ofertou uma percetual de 50% (cinquenta porcento) de aprovao para a arquitetura. Foi o pior resultado. O que contribuiu fortemente para isto foi a escrita dos itens de questionamento, pois eles obrigavam o avaliador a verificar, por exemplo, se para todos os componentes foram especificadas as classes.

86

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

Retirando a quarta e a dcima segunda questo, para a 2 rodada avaliativa houve 20 (vinte) questes respondidas, 3 (trs) destas avaliadas como no se aplica; apenas uma questo foi respondida como em desacordo com o valor esperado. Estes quantitativos implicam em um percetual de 80 (oitenta) em aprovao e corretitude da arquitetura. Este o percentual vlido para este trabalho. Esses valores pontuados em cada Checklist podem ser verificados no repositrio pblico:

https://www.dropbox.com/sh/sc6bv62petuczdm/ocjs_kklFH. As vises ou diagramas arquiteturais expostos ao decorrer do captulo foram os avaliados corretamente, ou seja, alguns foram inseridos enquanto outros foram corrigidos, tudo conforme a avaliao negativa dos questionamentos. Neste entrecho, aps apurao dos itens respondidos e contabilizados para os clculos, obtiveram-se os seguintes resultados e melhorias conforme os defeitos encontrados por tipo. Defeito por Fato Incorreto:

Esses defeitos so referentes aos elementos arquiteturais que foram descritos ou mesmo desenhados de forma errada. Algumas camadas ou classes no foram corretamente especificadas. Um exemplo deste erro foi encontrado na viso que dividia a arquitetura em camadas. Nesta representao s havia duas camadas formando a arquitetura. Demais camadas estavam na parte interna das duas grandes camadas, deste modo, poderia se supor que as demais camadas, ou ainda, uma classe necessria, s poderiam ser inserida nas duas camadas representadas. O grande problema dentro desta abordagem o fato de no se dividir devidamente as responsabilidades; sendo assim, a representao em camadas foi refeita, com as atribuies de cada um devidamente inseridas. O resultado pode ser visto na Figura 15. Para encontrar este defeito nenhum item de questionamento foi decisivo. A escolha por no especificar a camada de interao com o usurio surgiu atravs do apontamento deste tipo de defeito tambm, pois na avaliao, foi citado por um dos avaliadores, a necessidad de uma reflexo sobre a real necessidade de uma camada de apresentao em toda SM, sendo que muitas dessas poderiam se utilizar outras SMs como apresentao.

87

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

Defeito por Omisso:

Durante a avaliao os itens que foram negativados tiveram como motivo a omisso de outros elementos arquiteturais que no foram representados. Ou seja, as vises arquiteturais ainda foram em um pequeno nmero. Sendo assim, os diagramas de componente e de classe foram acrescentados e avaliados positivamente em uma segunda oportunidade. O item de questionamento nmero 3 foi determinante para a averiguao deste defeito. Ao final desta seo importante reafirmar que todas as vises exibidas neste capitulo foram corrigidas conforme as avaliaes. Uma verso anterior da avaliao de referncia foi inserida no apndice D, isto para se notar como a mesma era antes de ser especificada como na figura 15. importante tambm concluir que o Checklist tambm foi avaliado na primeira rodada, como se esta fosse um projeto piloto para os itens de questionamento.

4.6. CONSIDERAES FINAIS DO CAPTULO

Neste captulo a arquitetura de referncia para Mquinas Sociais foi proposta. Essa arquitetura um modelo que deve ser customizado para cada SM a ser modelada. Mesmo assim, essa arquitetura deve ser expandida. Pontos que fazem referncia implantao das SMs e ao prprio ciclo de vida de uma SM devem ser melhor trabalhados. Como exemplos de questes que podem ser mais bem estudadas na arquitetura de referncia so: estratgias que proporcionassem um maior tempo de vida ou utilizao da SM. O maior nmero de vises retratadas para a arquitetura de referncia visa auxiliar no entendimento de tal arquitetura, assim como, mostra o controle e as estratgias sobre os princpios de acoplamento e coeso. Em se tratando destes princpios, a avaliao procurou dar nfase aos mesmos, entre outros. A avaliao foi importante no s para corrigir os artefatos arquiteturais como tambm para corrigir o prprio processo avaliativo. Itens foram refeitos e novas vises foram inseridas neste processo. Os avaliadores ainda puderam interagir com o autor dos artefatos e algumas solicitaes foram colocadas, como: inserir uma rea para comentrios no prprio Checklist, e uma rea de ajuda, em que cada item poderia ser melhor explicado, isto ainda no prprio Checklist. A avaliao foi um processo que no teve alto valor financeiro e foi extremamente proveitosa, tanto no sentido de melhoria da arquitetura, quanto no sentido de 88

Captulo 4. Proposta de Arquitetura de Referncia Para Mquinas Sociais

amadurecer e disseminar melhor as prticas que visam avaliar a qualidade de documentos arquiteturais. Durante a exibio da arquitetura os requisitos a serem atendidos foram bem enfatizados, inclusive por meio de uma tabela. Isto facilitou a avaliao, pois alguns participantes tambm necessitaram perceber o atendimento aos requisitos de forma mais direta. Outro artifcio que possibilitou uma avaliao positiva de mais de 50% (cinquenta porcento) de aprovao e aceitao da arquitetura, foi a insero dos poucos elementos mediadores, na verdade existi apenas um elementos, o Social APIMiddleware Machine na figura 17, este poderia ser um Middleware o que prejudicaria o requisito desempenho (GAMMA, et al 2000). O prximo captulo tambm pretende, entre outros objetivos, fortalecer e facilitar o uso da arquitetura proposta, pois que, ao passo que conduz boas decises de projeto, se descobre maneiras de alcanar ou implementar as solues propostas neste arcabouo de referncia.

89

Captulo

5
5. Recomendao de Prticas Desenvolver Arquiteturas Mquinas Sociais Para de

Neste captulo ser proposto um conjunto de boas prticas que nortearo a uma definio ou especificao apropriada de arquitetura de Mquinas Sociais. Neste captulo, as prticas constituiro novos mtodos para projetar, e singularmente, conceber SMs.

90

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

5.1. INTRODUO

Foi elaborado um conjunto de boas prticas, esse conjunto dever responder algumas questes que so de elevada importncia para a customizao ou criao de arquiteturas. Ele ir conceber um padro para construo de SMs. Esse padro, aliado arquitetura de referncia, constituir o contedo necessrio que facilitar a adequada construo de arquiteturas de SM. Na verdade, essas prticas tambm devem ajudar na personalizao da arquitetura de referncia. Os assuntos levantados nesta parte introdutria sero tratados minuciosamente nas prximas sees.

5.2.

PRTICAS

NA

METODOLOGIA

PARA

CONCEPO

DE

ARQUITETURAS E EM TRABALHOS RELACIONADOS

O procedimento para se implementar a arquitetura de qualquer sistema j foi amplamente difundido por estudiosos como Roger Pressman, Craig Larmam, Paul Clements, David Garlan e Mary Shaw. Segundo essas literaturas a metodologia, com os passos ou atividades, para se elaborar a arquitetura de um sistema so: 1. Elicitar requisitos funcionais e no funcionais; 2. Especificar e analisar requisitos no funcionais; 3. Fazer uma listagem de todas as decises de projeto incluindo as justificativas que influenciaram cada deciso34. 4. Estruturar a arquitetura por meio de alguma modelagem; 5. Documentar a arquitetura utilizando vises que podem ser: viso de mdulo, viso de componentes e conectores, viso de implantao (BASS, CLEMENTS, e KAZMAN, 2003);

Executar os passos acima no assegura a definio de uma arquitetura de qualidade para SMs, ou seja, uma arquitetura que possibilite o correto funcionamento da aplicao, satisfazendo os requisitos (HOFMEISTER, NORD, e SONI, 2000). Para os sistemas Web que

34

Por deciso de projeto deve-se entender que so as escolhas sobre as tecnologias e mtodos que iro compor o projeto de software e influenciar diretamente na arquitetura (BASS, CLEMENTS, e KAZMAN, 2003).

91

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

so Mquinas Sociais, necessrio ter conhecimento sobre outros fatores que influenciam na definio da arquitetura e que no esto explcitos nos procedimentos pontuados acima. Os fatores crticos que devem ser seriamente levados em considerao na definio da arquitetura de SMs sero demonstrados por meio de boas prticas. Essas so orientaes que faro o projetista ou arquiteto de software notar os fatores relevantes para as Mquinas Sociais para assim implementar com mais exatido a arquitetura. As prticas esto ligadas diretamente ao desenvolvimento das SMs: servios relacionados SM, padres de projeto dedicados as SMs, relacionamentos, autogerenciamento, e tecnologias. O intuito possibilitar a construo de sistemas Web como Mquinas Sociais. importante frisar que as prticas propostas neste trabalho no visam substituir os pontos citados acima, estes fazem parte de mtodos j tradicionais e amplamente validadas pela indstria e pela academia para elaborar arquiteturas. A inteno deste trabalho agregar valor forma de conceber arquiteturas de modo que as atividades que compem os procedimentos de elaborao arquitetural possam ser mais objetivas para SMs, ofertando resultados mais eficientes ao projeto de arquitetura. As prticas foram costrudas por meio de: Experincia de mais de 5 anos da autora desta dissertao em anlise, projeto e arquitetura de software; Leituras e investigaes sobre tecnologias para a Web inclusive com a participao do grupo de SMs da UFPE/C.E.S.A.R; Padres IEEE. A idia de se originar boas prticas para o projeto arquitetual de Mquinas Sociais pode ser comparada aos padres IEEE Std 830-1998, que contm boas prticas sobre a especificao de requisitos de software, e principalmente ao padro IEEE Std 1471-2000 que contm boas prticas para a descrio arquitetural. A diferena primordial entre este captulo em especfico e os padres sugeridos que as boas prticas aqui propostas so mais ricas em detalhes, pois, elas no s recomendam uma ao, como tambm ilustram o problema a ser resolvido, a motivao pela qual a prtica sugerida, e a forma ou o exemplo de como ela poder ser adotada. Com esta comparao,

92

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

possvel notar uma iniciativa em se padronizar a construo de SMs; sendo que, o objetivo de um padro IEEE tambm seria em padronizar procedimentos, computadores e dispositivos35.

5.3. PRTICAS RECOMENDADAS Antes de conhecer as prticas de construo, e depois de visualizar a arquitetura de referncia, necessrio reforar alguns pontos que fazem parte de qualquer processo de desenvolvimento. Para qualquer projeto de desenvolvimento de aplicaes Web importante centrar na idia de Mquinas Sociais. O projetista de software deve ser remetido aos conceitos inerentes s SMs como: a taxonomia, os tipos de relaes, e a prpria arquitetura. Uma das metas desta pesquisa reforar a idia de que a anlise dos sistemas conectados em rede deve ser feita sobre o paradigma de Mquinas Sociais. Para que a anlise de uma SM seja constituda, as atividades inerentes a um projeto de software no devem ser ignoradas. Sendo assim, seria interessante: analisar o problema a ser resolvido pela Mquina Social; analisar o escopo do sistema, suas fronteiras; as premissas que ele estar submetido; e a especificao do produto de software. Com essas anlises, possvel verificar ainda que tipo de Mquina Social a aplicao a ser desenvolvida. Isto faz diferena no momento das definies do projeto arquitetural e dos requisitos de qualidade. Quanto aos requisitos de qualidade, necessrio averiguar os mesmos, o que ajudar nas decises de projeto. Estas, por sua vez, iro influenciar diretamente na definio da arquitetura. Requisitos como: desempenho, confiabilidade, disponibilidade, compatibilidade, segurana, modificabilidade, usabilidade, e interoperabilidade podem ser trabalhados na arquitetura; sendo que alguns, como j elucidado, so mais relevantes que outros para as Mquinas Sociais. Aps tratar brevemente de alguns assuntos relevantes para as SMs, as prticas sero exibidas. Estas geram informaes e artefatos teis para a construo adequada da arquitetura da SMs. Algumas prticas vo propor solues tecnolgicas, como frameworks ou padres de projeto.

35

Segundo as infromaes do site oficial do IEEE - Instituto de Engenheiros Eletricistas e Eletrnicos. Em http://www.ieee.org/index.html. Acesso em: 22 de maro de 2012.

93

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

5.3.1. PRTICA 1: Modelar processos e sub-processos de negcio de servio A modelagem dos processos de negcio vai capturar o problema a ser resolvido e mapear melhor os servios providos e requeridos. Ademais, mostrar quais as necessidades e atribuies da aplicao. A modelagem dos processos um fluxo com a sequncia das atividades que so efetuadas para se atingir um objetivo, (LAZZERI, 2009) alm de descrever o comportamento de um modelo de negcio. Problema: O problema reside em no saber como os componentes da Mquina Social iro interagir uns com os outros. difcil mapear um servio sem conhecer os elementos que o compem (OSTENWALDER, 2005), qual o fluxo de atividades envolvidas, quais os servios e subservios relacionados ao negcio ou a uma funcionalidade em especfico. Pensar em servios pensar em modelagem de negcio (LAZZERI, 2009). Motivao: Esta prtica constitui um fluxo que o alicerce da modelagem do sistema, ou da Mquina Social. Assim, possvel visualizar mais claramente a SM e agir decisivamente nas escolhas tecnolgicas e arquiteturais. Ainda assim, a motivao para construir as Mquinas Sociais a relevncia em se conhecer os elementos que iro subsidiar suas operaes. No s conhecer, mas verificar como tais servios esto entrelaados. Assim, a aferio desses servios ou operaes feita por meio do mapeamento dos processos que existem em cada operao. Cabe aqui mais uma referncia direta, segundo Jos Carlos Lazzeri (2009):

O fluxo do processo d ao modelador a representao visual de como o modelo de negcio ser executado, podendo ser a base para a validao das muitas exigncias requeridas, entre elas: suporte a governana, estrutura do software, priorizao estratgica, apurao dos custos e eficincia operacional.

Outra questo que impulsiona o exerccio desta prtica a integrao entre as aplicaes de modo que uma possa utilizar o servio da outra. A anlise e descrio do negcio contribuiro diretamente para a comunicao e integrao (ABINADER e LINS, 2006), pois existe hoje uma srie de padres, ferramentas e arquiteturas, que vo desde as Arquiteturas Orientadas a Servios at as Plataformas Corporativas de Servios, que se

94

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

propem a ajudar na integrao. Mas para isto necessrio conhecer o negcio e as regras que envolvem o mesmo.

Exemplo e Soluo: Para modelar processos, o uso de Business Process Modeling Notation - BPMN extremamente recomendado (OSTENWALDER, 2005). Os fluxos dos processos de negcio que surgem da linguagem BPMN modelam perfeitamente o processo. Deste modo, a Figura 21 um exemplo dessa prtica. Vale ressaltar que os fluxos de processo devem ser expandidos quando ocorre a necessidade de detalhar melhor uma atividade.

Figura 21. Exemplo de modelagem de um processo

A Figura 21 a descrio de um processo simples de um sistema de compra e reserva de passagem. Todos os servios so descritos possibilitando uma compreenso de como os mesmos esto entrelaados, por exemplo, o servio de fazer check-in depende do servio de compra de passagem, qualquer alterao nesta compra poder alterar o check-in. 5.3.2. PRTICA 2: Reconhecer os servios providos e requeridos para o funcionamento da Mquina Social.

Um servio uma tarefa, trabalho, ou ainda operao que ser produzida por um componente de software a fim de edificar algo de interesse e necessidade de outro componente requisitante (ERL, 2005). Os servios podem ser identificados em diversificados nveis de abstrao, desde servios ofertados por uma aplicao a outra, at servios ofertados 95

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

por um objeto a outro. Trata-se de uma orientao voltada para o autoconhecimento. Quanto mais se conhece a aplicao, mais se descobre o tipo de Mquina Social que ela , e como deve ser sua arquitetura.

Problema: O problema identificado para SMs que pode ser resolvido por esta prtica a nvel arquitetural em relao identificao das operaes efetuadas pela Mquina Social. Outro problema a ser resolvido est relacionado identificao dos provedores de servio. Algumas decises arquiteturais so baseadas nas caractersticas dos servios requeridos e, por conseqncia, o que, ou quem, pode prover tal servio. Muitas vezes as operaes requeridas so executadas por provedores distintos, provocando exigncias em conexes (LAZZERI, 2009).

Motivao: Neste caso, os servios providos e requeridos auxiliaro na definio das interfaces de comunicao que ocorre entre as aplicaes e tambm entre as partes das aplicaes. Ou seja, entre os elementos que constituem uma aplicao. O benefcio desta prtica descobrir os servios envolvidos com a Mquina Social, prever os servios necessrios, verificando o ciclo de vida do servio, e tambm prever possveis reusos dos mesmos. Uma conseqncia desta prtica, que caracteriza outra motivao, seria a identificao da necessidade de Web Services, ou mesmo adaptao da arquitetura para suportar a conexo com provedores de servios.

Exemplo e Soluo: O seguinte exemplo pode auxiliar na execuo da prtica: Aplicao: Aplicativo de rede social; Servio provido: agrupar pessoas com a mesma profisso; Servio requerido: mecanismo de autenticao de usurio da rede social;

Existem algumas estratgias para se descobrir um servio, sobretudo os servios providos. Algumas das estratgias so: 1. Tipificao: estudar um componente de software e descobrir o servio que o mesmo pode prover separando-os por categorias (BELL, 2008); 96

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

2.

Abordagem Bottom-Up: analisar o sistema de software verificando os produtos derivados da operao desse sistema. Se os produtos estiverem contextualizados ao negcio ao qual a aplicao est direcionada, ento tais produtos podem ser vistos como servios (LAZZERI, 2009);

3.

Abordagem Top-Down: parte da anlise do problema que o software deve resolver. Nesta abordagem, o domnio do software poder ser estudado, bem como a anlise das regras de negcio para identificao dos servios (LAZZERI, 2009);

Para finalizar esta prtica e partir para a prxima, que tambm esta relacionada aos servios, vale expor que ambas foram baseadas em estudos direcionados a SOA. Alguns estudos, como o de Michael Rosen em 2008 exploram prticas de design para arquiteturas orientadas a servio. Algumas destas prticas so, por exemplo: o estudo dos servios; a separao de responsabilidades entre componentes da arquitetura; as atribuies de cada pessoa envolvida no projeto; e ainda a anlise do ambiente organizacional e tecnolgico no qual a aplicao ser envolvida. Estas prticas so prximas das prticas lanadas at este ponto.

5.3.3. PRTICA 3: Conhecer os provedores e requisitantes dos servio da aplicao A anlise dos servios conveniente pela descoberta das interfaces, e para identificar os componentes de software que iro prover e requisitar servio. Entender e projetar um componente de software como requisitante ou provedor de servio evidenciar a responsabilidade do componente e o que preciso para se conectar a ele. Assim, outros softwares podem utilizar esse componente tendo apenas a interface necessria para se comunicar.

Problema: O problema a ser resolvido por esta prtica j foi levantado na prtica 1: ele provoca a ausncia de informaes que auxiliariam um projetista, ou arquiteto, a lanar mo de boas decises arquiteturais que envolvam os provedores de servio.

97

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Motivao: Aps mapear os servios requeridos mais fcil descobrir quais tecnologias podem atender cada servio. Este conhecimento til para definir na arquitetura solues que possibilitem uma comunicao hbil entre provedores e requisitantes, evitando assim, incompatibilidade entre as tecnologias ou aplicaes (JOSUTTIS, 2007). Esta orientao pode ser extremamente til para os Mashups que trabalham sobre a mescla de servios de duas ou mais aplicaes. Para enriquecer o entendimento sobre esta prtica, vale examinar o exemplo abaixo.

Exemplo e Soluo: O exemplo no pargrafo abaixo no baseado em um caso real, mas ilustra as informaes que devem ser adquiridas.

O Twilio ir fornecer o servio de telefonia Web necessrio na aplicao a ser construda. Aps pesquisa entende-se que ele uma aplicao que utiliza a infraestrutura da nuvem (Cloud Computing), enquanto sua API usa como interface de comunicao o padro RESTful, alm de aceitar os formatos XML ou CSV em suas mensagens.

A metodologia para se adquirir as informaes nos moldes do exemplo acima simples: 1. Fazer uma listagem das operaes necessrias; 2. Separar as operaes/servios, separar os servios que podem ser atendidos pela prpria aplicao, e separar servios que podem ser atendidos por entidades externas, como outra SM; 3. Para os provedores internos Mquina Social, verificar como esses provedores devem ser componentizados, se algum ser reutilizado, e como dever ser a interface de comunicao desses componentes (CHEESEMAN e DANIELS, 2001). Quais mtodos a mesma deve ter para manter os servios; 4. Para os provedores externos, analisar cada provedor usando mtodos de pesquisa em materias prprios dos provedores, como sites, tutoriais, estudos de caso, guias e outros.

98

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Esta prtica faz referncia a componentizao de software, outro importante conceito para o desenvolvimento de aplicaes Web. Entretanto, a prtica ainda est corelacionada aos conceitos de SOA, bem como a prtica 2. At agora os conhecimentos lanados exploram questo mais voltadas anlise e modelagem de negcio, mas que, influenciam na arquitetura. A partir da prxima prtica recomendada os conhecimentos sero mais voltados para as questes tcnicas das Mquinas Sociais.

5.3.4. PRTICA 4: Verificar a necessidade de recursos que tornem a aplicao auto gerencivel e como esses recursos podem ser implementados. Este conhecimento est intensamente relacionado aos conceitos de computao autnoma. Neste momento importante apontar para a necessidade das funcionalidades autnomas, pois elas sugerem os mecanismos de auto gerenciamento de uma SM.

Problema: O problema reside em no saber que determinado componente da Mquina Social tem a necessidade de se auto gerenciar. Ainda existe outro problema agregado, onde alguns recursos que promovem a autonomia dos sistemas ainda so parcialmente desconhecidos, como exemplo: as IaaSs. Tais aspectos relacionados autonomia das Mquinas Sociais fazem total diferena na arquitetura da mesma.

Motivao: Com este conhecimento, possvel descobrir o recurso que poder ser utilizado para prover a autonomia dos elementos, quais so esses elementos da SM, e se necessitam realmente de autonomia. Tal nvel est relacionado s propriedades de auto cura, configurao, otimizao, e por fim, auto proteo. Assim, atravs desta prtica, pode-se descobrir, por exemplo, que um sistema tem alguns requisitos que, ao serem implementados, geraro funcionalidades independentes. Ou seja, funcionalidades que necessitem se reconfigurar, otimizar seu desempenho em conformidade ao ambiente externo, ou ainda se proteger deste ambiente.

99

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Exemplo e Soluo: Para descobrir aspectos funcionais que devem ser autnomos na Mquina Social deve-se observar: O ambiente no qual a SM est inserida, se fortemente distribudo, se heterogneo, ou seja, composto por SMs distintas (STERRITT; e BUSTARD, 2003); A carga de trabalho da SM, se a mesma varivel; Se os recursos da Mquina Social so compartilhados.

O auto gerenciamento de um sistema garantido pela comunicao entre os elementos desse sistema. Para isto, o uso de interfaces variadas a soluo. Tais interfaces podem agir por meio de APIs, arquivos de configurao, controle de logs, utilizao de frameworks e outros (HORN, 2001). O framework MapReduce uma ferramenta que age bem neste aspecto de autonomia. Para monitorar a carga de trabalho, processando sempre grandes volumes de dados, o framework deve lidar com falhas de forma habilidosa, garantindo assim a auto cura. O MapReduce segundo Jeffrey Ghemawat, 2004; atende a auto cura da seguinte forma. A arquitetura em camadas do MapReduce possui um componente que envia tarefas s mquinas executantes das operaes de mapeamento de dados e reduo dos mesmos. Deve-se lembrar que o framework trabalha de forma distribuda em vrias mquinas, ou clusters. Pois bem, uma vez que um componente envie tarefas, o mesmo envia pings para cada mquina. Se uma delas no responder em um perodo pr-determinado de tempo, o componente entender que ocorreu uma falha e imediatamente reiniciar a tarefa enviando-a para outra mquina. Por fim, a tarefa necessitar ser re-executada para que o processo no fique comprometido ou apresente resultados de redues incompletos. O pargrafo acima mostra como o MapReduce trabalha em um mecanismo que satisfaz uma propriedade autnoma. Para esta prtica muto importante sinalizar equipe de software de que algum mecanismo do tipo deve ser planejado. O exemplo fictcio do pargrafo seguinte exibe o resultado da execuo desta prtica: Exemplo: Baseado em dados mapeados nas experincias anteriores e no perfil do pblico alvo da aplicao, estima-se que os registros e acessos de usurios tendem a crescer 42% a cada 30 dias. Assim, dentro de meses, o recurso consumido pelas mquinas ser grande. Para este problema, seria interessante ter um recurso que monitorasse a quantidade de recursos existentes nas mquinas, como: memria e capacidade de armazenamento. 100

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Cabe inscrever neste registro o uso de balanceadores de carga para distribuir a carga de dados ao passo que se nota o crescimento da mesma. O uso de balanceador muito comum aos sistemas distribudos em rede, afinal, o balanceamento de carga promove a escalabilidade, performance, e disponibilidade. Para se utilizar o recurso de balanceamento de carfa necessrio, acima de tudo saber o que se deseja balancear (BOURKE, 2001). Aps ter tais conhecimentos, vivel preferir por alguma soluo. bem mais prtico adotar uma tecnologia de mercado do que construir o prprio balanceador, principalmente no contexto de Mquina Social que prega a praticidade na manuteno e evoluo do software (BOURKE, 2001). O Netcraft.com36, inclusive, publicou uma estimativa que aponta o Apache como o servio de balanceamento de carga mais explorado, onde mais de 50% das aplicaes Web o utilizam; em segundo lugar ficou colocada uma ferramenta da Microsoft. Finalmente outra opo para esta prtica seria contratar um servio de infraestrutura Cloud Computing. O conceito de CC j foi tantas vezes tratado neste trabalho. Pois bem, o uso de IaaS pode ser til para o monitoramento do crescimento da aplicao onde a infraestrutura pode prover a elasticidade do sistema sem interveno de pessoas que tratem da manuteno da aplicao.

5.3.5. PRTICA 5: Determinar os recursos que implementaro os elementos Communications , Constraints e Requests: Os elementos chamados States e Constraints so partes da Mquina Social. Eles concentram informaes capazes de tornar vivel a sociabilidade e a colaborao entre as SMs. Sem eles, complicado saber a disponibilidade de uma SM, ou mesmo a disponibilidade dos seus recursos. Estes dois elementos comportam e fornecem informaes tanto para auxiliar o processamento interno da SM, como para auxiliar na interao com o ambiente externo.

Problema: Determinar quais recursos tecnolgicos podem implementar um componente que dar suporte ao armazenamento e divulgao da situao da SM: se a mesma est bloqueada,

36

Disponvel em: http://news.netcraft.com/. Site que monta pesquisas e exibe estatsticas sobre ferramentas e sobre a Internet em geral. Acesso em: 27 de nov. 2011.

101

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

inativa, com muitas requisies e etc. Faz-se necessrio ainda implementar um recurso que distribua informaes de como a Mquina Social trabalha, o que ela requer para se comunicar com outras SMs, qual a sua capacidade de processamento, armazenamento, os servios aos quais elas se dedicam e outras informaes relevantes. Existe uma complexidade em implementar recursos que atendam s necessidades expostas nos pargrafos acima. Para solucionar o problema de detectar o estado das SMs, por exemplo, poderia ser utilizado o recurso de scripts de monitoramento. Esses scripts podem ser usados para identificar uma ampla variedade de problemas em tempos de resposta, em tempos de processos e aes, e at mesmo no trabalho de APIs. Contudo, os scripts de monitoramento devem ser executados por meio de uma boa infraestrutura onde mquinas estejam preparadas para monitorar. Alm disto, nem todos os scripts esto aptos para lidar com as particularidades de Web Services e linguagens de programao. Na linguagem PHP, por exemplo, todos os scripts que possurem o comando exec podero ser bloqueados pela maioria dos servidores. Atualmente existem tambm alguns servios Cloud Computig que fazem o monitoramento do estado de sistemas e de redes, como o servio: CA APM Cloud Monitor. Ainda que existam alternativas, nenhuma delas uma soluo que atenda a necessidade dos elementos States e Constraints e igualmente possa ser reutilizada na diversidade das aplicaes Web 3.0. Sendo assim, outras vicissitudes devem ser buscadas.

Motivao: Priorizar uma soluo nica que possa atender aos requisitos dos elementos States e Constraints, contribuindo assim, para o fortalecimento destes dois elementos na SM, de modo que toda aplicao Web possa ter implementado esses componentes. O intuito disponibilizar de forma prtica na rede as informaes importantes para a conectividade e a troca de servios entre as SMs.

Exemplo e Soluo: Uma das solues mais interessantes para essa questo seria o desenvolvimento de um framework que possa atender os States e Constraints de forma diferenciada, pois o framework ofertaria praticidade na comunicao e na obteno de conhecimentos sobre a prpria SM e sobre outras SMs. Assim a execuo das operaes por cada componente seria maximizada. 102

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

O framework se preocuparia em ter as informaes da SM, sendo que uma boa comunicao necessita de informaes, sobretudo, informaes do status da Mquina Social. O framework composto por 3 (trs) classes como exibido a seguir. Veremos a definio de cada classe e posteriormente o relacionamento entre elas: Class SMs Configuration: trata-se da classe onde as informaes e caractersticas da Mquina Social so armazenadas. So informaes como: a quantidade de requisies que a SM pode suportar e o tempo de resposta entre estas requisies. Qualquer alterao na SM refletida nesta classe, evitando assim, que cdigos e mtodos sejam alterados em diferentes pontos da Mquina Social. Class Relationships Manager: faz a gesto dos relacionamentos entre as SMs. um elemento importantssimo para o framework justamente por executar o monitoramento das conexes entre as Mquinas Sociais. Neste elemento, possvel definir o tempo de conexo, o tipo de conexo, quais SMs, ou elementos em uma SM, iro se conectar, e como iro se conectar. Conexo neste sentido so de fato as Connections, ou seja, as relaes fortes da SM. Por fim, pode existir uma instncia desta classe para cada SM conectada. Class SMs Interface: uma classe de interface que se responsabiliza por construir Request apenas lendo parmetros, proporcionando uma criao mais objetiva sem envolvimento de diversos cdigos fontes ou outras tecnologias.

Essas classes esto inter-relacionadas, sendo que o produto de uma classe pode ser o artefato de entrada para outra classe. Deste modo, a SMs Configuration pode configurar uma poltica de acesso Mquina Social, deixando evidente, por exemplo, as portas que podem receber solicitaes e o tempo em que essas solicitaes podero ser atendidas. Isso servir de insumo para que a classe Manager Relationships avalie se o tempo de resposta de uma solicitao est em um nvel bom; os valores bons, ruins, ou timos, para esses nveis seriam definidos nesta classe. Outra relao de fundamental importncia entre as classes citadas no pargrafo anterior a disponibilidade de informaes. Baseado no ltimo exemplo, a Manager Relationships verifica que o tempo de resposta est prejudicado, mas no consegue descobrir o motivo, pois esta justificativa uma informao registrada como no pblica na SMs Configuration. Sendo assim, a Manager Relationships apenas enviaria uma mensagem ao 103

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

mtodo da arquitetura que seria responsvel por sanar essa queda de performance do tempo de resposta, sem necessariamente ter a garantia de que o mtodo resolveria o problema. Enquanto vrias interaes ocorrem, uma delas fundamental: a Class SMs Interface que utiliza as informaes da SMs Configuration para montar corretamente as Requests e assim poder receber dentro dos parmetros registrados as solicitaes de outras SMs. Por fim, a Class Manager age diretamente sobre essa interface conforme os resultados obtidos no controle das conexes. Vale ressaltar que todos os atributos dessas classes so repassados no formato chave valor, o que agrega mais simplicidade na configurao do framework. Finalmente possvel notar que muitas das informaes relevantes SM so trabalhadas em um s lugar por meio do framework; esse poderia ser uns dos elementos principais de suporte camada central de processamento da Mquina Social. Fica como sugesto para as arquiteturas que resolverem adotar esse framework, que um importante incremento para o mesmo seria implementar uma classe que tenha a inteligncia de sugerir aes corretivas para as no conformidades encontradas. Isto saciaria a necessidade de incluir uma propriedade autnoma relacionada a auto cura.

Figura 22. Representao do framework de comunicao para as SMs

5.3.6. PRTICA 6: Adotar estratgias para sanar as fraquezas do estilo arquitetural camadas.

A adoo de um estilo arquitetural depende do contexto no qual a aplicao est inserida, e sobretudo, depende dos seus requisitos de qualidade. Todo estilo arquitetural

104

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

possui vantagens e consequncias em sua adoo. O estilo camadas fortemente utilizado em sistemas Web e estava fortemente presente no mapeamento do estudo da literatura.

Problema: O estilo camadas se mostrar frgil quanto ao provimento da comunicao. Esta realmente importante para as SMs. Outras fragilidades desse estilo j foram elencadas anteriormente, como a tolerncia a falhas e a queda de desempenho; tais fragilidades podem comprometer a qualidade da arquitetura da Mquina Social. Motivao: possvel repensar no estilo camadas para as SMs, onde todas as fragilidades de tal estilo poderiam ser amenizadas. Isto vlido, visto que o estilo se mostra eficiente para a implementao de aplicaes Web.

Exemplo e Soluo: Nada impede que outros estilos sejam mesclados ao estilo camada (HOFMEISTER, 2000); mesmo porque, tecnologias emergentes podem ser incorporadas ao estilo para reduzir a intensidade das conseqncias. A insero do framework citado na ltima prtica em conjunto ao MapReduce poderia ser uma idia proveitosa, sendo que, enquanto o primeiro traria rapidez ao processo de comunicao, tanto na montagem dos Requests, quando na obteno facilitada do estado das SMs; o segundo auxiliaria na tolerncia a falhas. Outra alternativa seria implementar uma rplica de segurana para cada camada. Deste modo, quando uma camada falhasse, sua camada rplica estaria pronta para prover os servios; nas camadas de acesso a dados j possvel usufruir do artifcio da replicao de dados. Nessa alternativa, caso a SM use um recurso CC, como uma IaaS ou mesmo PaaS, possvel negociar mais mquinas virtuais ao mesmo fornecedor de servidos de IaaS, ou em outro fornecedor; alm de programar o sistema de infraestrutura de modo que todo o contedo seja replicado no novo ambiente negociado. As alternativas para se adequar ainda mais o estilo camadas as SMs so numerosas, todavia, deve-se analisar novamente os servios providos pela aplicao, o escopo da mesma, qual ser sua dimenso, e o ambiente no qual ela estar. A execuo das 3 (trs) primeiras prticas vai auxiliar fortemente a prtica aqui tratada. J o exemplo a seguir pode auxiliar no entendimento.

105

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Exemplo: o servidor precisar notificar todos os clientes ativos diariamente. Assim, seria interessante utilizar o estilo arquitetural Publisher-subscribers na camada de comunicao, pois ele viabilizaria o registro apenas dos clientes ativos (BUSCHMANN. et al, 1996) notificando os mesmos a cada alterao sem esforo da aplicao servidora. 5.3.7. PRTICA 7: Determinar o recurso que prover a comunicao e a interoperabilidade. A comunicao uma caracterstica que sobressai na Mquina Social, e a interoperabilidade um requisito importantssimo a ser considerado na arquitetura da mesma. Portanto, dependendo do tipo de relao existente entre as aplicaes, pode ser adotado um padro de comunicao entre elas, ou pode haver um consenso quanto aos tipos de mensagens trocadas e o tempo em que elas sero trocadas. Quando se trabalha com comunicao entre Mquinas Sociais trabalha-se mais do que tudo nas integraes requeridas entre esses SMs; o detalhe neste caso que tais SMs podem apenas manter uma comunicao interna entre os componentes que a compem, ou entre as SMs ditribudas. Ainda deve-se considerar que a integrao ocorrer tambm entre SMs heterogneas envolvendo Mquinas Sociais de clientes, de fornecedores e demais parceiros do negcio.

Problema: Determinar como ser feita a comunicao entre as Mquinas Sociais para que a continuidade na conexo destas SMs seja garantida algo que pode ser provido por meio de diversificadas solues. Deste modo, o problema se origina novamente da heterogeneidade de recursos que so utilizados e que por vezes no agregam um bom resultado SM, adicionando complexidade ao seu desenvolvimento. Contudo, prover a comunicao um problema gerado principalmente pela falta de anlise nas ferramentas e recursos que podem prover a integrao e interoperabilidade das SMs. Neste aspecto, o contedo trocado entre elas de total relevncia, assim como, o ambiente no qual a Mquina Social est envolta.

Motivao: A motivao desta prtica est em utilizar algum recurso j explorado por outras SMs como REST e SOAP. Ou ainda, analisar algum padro utilizado pelo paradigma Cloud 106

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Computing ou SOA capaz de prover a comunicao por meio de troca de mensagens bem sucedidas. Contudo, ainda existe a possibilidade de explorar novas idias que ofertem mais praticidade na integrao entre as SMs. A integrao pode reduzir significativamente os custos e melhorar a eficincia dos processos organizacionais ao passo que aumenta a longevidade das aplicaes (ABINADER e LINS, 2006). Segundo Rezende (2005) (2006); alguns fatores impulsionam a comunicao, integrao e interoperabilidade flexvel entre os sistemas. So eles: a expectativa de se obter retorno financeiro mais rpido; o aumento da demanda no compartilhamento de dados em tempo real; a necessidade contnua de conter custos; e a necessidade de entregar sistemas de qualidade que agreguem valor ao negcio.

Exemplo e Soluo: Baseado no que foi visto at este ponto, as solues mais prximas da realidade das SMs so exibidas em seguida.

1. Web Services: Web sevices podem ser geridos por frameworks como: Axis 1.0 e 2.0; Jax-WS, SAAJ; e ainda tecnologias poderosas como REST e SOAP. Enquanto o framework Jax-WS oferta praticidade com gerao de cdigo e automao na criao do Web Service por utilizar recursos da ferramenta NetBeans, a arquitetura REST oferta interfaces de servio preparadas para integrar aplicaes que manipulem grande quantidade de dados (WEBBER, PARASTATIDIS e ROBINSON, 2010) e tambm aplicaes mveis. Vale ressaltar que o metadado WSDL descreve Web Services com muita proeza, sendo que ele ainda descreve o servio, especifica como acessar o Web Service e quais as operaes que o mesmo dispem. O WSDL uma ferramenta muito poderosa para a obteno de interoperabilidade. Na indstria de desenvolvimento para a Web existem dois grupos de profissionais que se dividem em utilizar REST ou em utilizar SOAP. Ambos sustentam argumentos fortes. Por um lado, as caractersticas do REST do mais praticidade ao desenvolvimento, por outro lado a completude de recursos que o SOAP possui (KALIN, 2010). A questo por se definir entre REST ou SOAP algo que depende de muita prtica em desenvolvimento de software, justamente para que os profissionais possam optar pela tecnologia mais adequada. 107

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

importante lembrar que toda e qualquer escolha possui forte dependncia com as caractersticas da Mquina Social, a taxonomia, as interaes, e a natureza dos servios. Apesar dos benefcios de SOAP, REST seria a soluo mais adequada para as SMs. O que aproxima REST das Mquinas Sociais a facilidade com que esta soluo pode auxiliar na identificao dos servios (WEBBER, PARASTATIDIS e ROBINSON, 2010) e, sobretudo, na utilizao das mesmas pelo paradigma Cloud Computing. Vale lembrar que a identificao dos servios facilita a execuo das primeiras prticas propostas por esse trabalho. Em se tratando de CC, a Salesforce utiliza REST para prover a integrao entre Web Services que podem ser necessrios para a Mquina Social a ser construda sobre a plataforma Force.com, no caso dos componentes disponibilizados por tal plataforma no atenderem as funcionalidades exigidas pelo escopo da Mquina Social. O conhecimento deste pargrafo e do seguinte esto disponveis no Guia do Programador da API de Servios Web da Force.com37. Com isto possvel ver que CC tambm adere ao uso de SOAP. A Force.com ainda fornece suporte a utilizao do protocolo de acesso SOAP. Ela sugere que as aplicaes Web que exijam um tempo de resposta curto, que manipulem poucos dados, e que sero construdas sobre a arquitetura Multitenancy, faam uso de SOAP. Tal protocolo tambm ganha notoriedade quando as aplicaes so construdas sobre o paradigma de Arquitetura Orientada a Servios. Em SOA, solicitantes e provedores de servios trocam mensagens do tipo SOAP para encontrar e disponibilizar servios respectivamente (GOMES, 2010).

2. Enterprise Service Bus - ESBs: Outro recurso que ganhou fora com SOA e que tambm prov integrao e comunicao so os ESBs (CRAGGS, 2004). O modelo ESB utiliza uma plataforma de servio na qual as aplicaes recm-criadas e as aplicaes legadas podem se conectar facilmente utilizando XML. A grande vantagem do ESB que o formato da mensagem j conhecido pelas duas aplicaes (CRAGGS, 2004), o que proporciona maior velocidade nas transaes.

37

Guia do Programador da API de Servios Web da Force.com. Est http://www.salesforce.com/us/developer/docs/api/index.htm. Acesso em 01 de abr. 2011.

disponvel

em:

108

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

O ESB um servidor de aplicao que trabalha com middlewares que podem integrar os componentes das camadas de processamento da aplicao, alm de garantir a integrao de diversas Mquinas Sociais distribudas utilizando adaptadores e conectores (LINTHICUM, 2004). Desta forma, o uso de um ESB na camada Wrapper da SM uma soluo inteligente e ideal para as SMs, sobretudo, pela padronizao de mensagens, o que facilita o reconhecimento das mesmas por diversas SMs amenizando assim o problema de integrao. 3. Remote Method Invocation - RMI: Aplicaes que sejam desenvolvidas em Java, por exemplo, podem utilizar o padro de comunicao RMI, ou a ferramenta Jini, que, por meio de um conjunto de APIs, pode conectar diversas aplicaes distribudas em rede (ARNOLD et al, 2009), inclusive dispositivos mveis. O Jini faz a localizao dos servios sem necessitar consultar nenhum repositrio de servio (ARNOLD et al, 2009), como SOAP faria. Apesar de ser uma boa soluo, a mesma traria muita dependncia com a tecnologia Java, o que contradiz os princpios da SM de ser independente. Finalmente a comunicao entre as aplicaes ou parte delas pode ser alcanada de forma prtica por meio das tecnologias aqui expostas. Conceitos que so relevantes como anlise do negcio e aviso de entrega de mensagens, esto implcitos nesta abordagem e devem ser considerados para a adoo de alguma tecnologia.

5.3.8. PRTICA 8: Selecionar o recurso Cloud Computing a ser adotado na SM.

A arquitetura de referncia sugere que os recursos disponibilizados pelo paradigma Cloud Computing sejam inseridos na arquitetura de Mquinas Sociais. Na verdade Cloud Computing, sobretudo os SaaS, trabalham como SMs, e esto inseridos no universo da Web 3.0. Por isso, e tambm pelas vantagens que os servios Cloud podem trazer, que deve-se buscar a insero de tais recursos no desenvolvimento de aplicaes Web. Os ganhos que so conseguidos por meio da Cloud Computing so refletidos na disponibilidade de recursos, na manuteno, e na produtividade do desenvolvimento da aplicao. Deste modo, esta prtica ir explorar algumas questes da adoo da Computao nas Nuvens em alguma parte da arquitetura da Mquina Social. 109

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Problema: A indstria de desenvolvimento de software vem inserindo os recursos da Cloud Computing no cotidiano das fbricas de software. O novo paradigma, a priori, parece no trazer muitas novidades que resolvam de forma diferenciada os j conhecidos problemas do desenvolvimento de software. necessrio mais ateno e pesquisa para notar os benefcios que podem ser agregados com a adoo de Cloud Computing. Este talvez seja um ponto problemtico para as empresas, que, por vezes no tentam desenvolver projetos experimentais a ponto de confrontar os resultados da adoo de Cloud Computing. Um problema relevante nesta questo o fato de no se ter um parmetro de como ou onde usar Cloud Computing. Este paradigma estaria apto a suprir todas as necessidades das Mquinas Sociais? Abdicar totalmente de uma infraestrutura de processamento e armazenamento seria uma idia radical? Ou ideal, para o desenvolvimento de aplicaes Web? Afinal muitas solues no CC ofertam benefcios que so promessas da Cloud Computing. Outro problema inerente s prprias caractersticas de Cloud Computing a velocidade na taxa de leitura e escrita em disco (KE et al. 2010). Tendo em vista que CC usufrui de muitas mquinas virtuais para se fazer leitura e escrita, principalmente quando se trata de sistemas WEB, essas funes de leitura e escrita podem ser desaceleradas conforme a quantidade de mquinas existentes (MOTAHARI-NEZHAD, 2009). Assim, toda aplicao que precisar manipular muitos arquivos em disco no vai conseguir taxas altas de leitura e escrita. Nesta categoria esto os servidores de email e de banco de dados. Sendo assim, ainda seria interessante deixar o repositrio de dados em CC? Motivao: A disseminao dos servios e das ofertas em Cloud Computing pode promover a criao e proliferao de negcios em setores nos quais os recursos e custos de TI so impeditivos ao desenvolvimento do negcio. Assim, extremamente motivador analisar como o advento de Cloud Computing pode ser atrelado s Mquinas Sociais, e como a integrao entre duas SMs pode ocorrer (Cloud Computing uma SM que serve a outras SMs). A definio de uma arquitetura deve levar em considerao aspectos inovadores e que possam ofertar solues prticas e flexveis para antigos e novos problemas da engenharia 110

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

de software. CC capaz de ofertar essas solues, alm de ofertar possibilidades de reuso em recursos computacionais. O prximo pargrafo evidencia ainda mais a motivao por se analisar a utilizao de Computao nas Nuvens. Cloud Computing pode agregar mais poder de processamento ao desenvolvimento de software visto que ela oferta alta disponibilidade de recursos para as aplicaes e flexibilidade nas manutenes (WEINHARDT, 2009). Essas manutenes so responsabilidades dos provedores de servios Cloud Computing e no da equipe que desenvolve a SM que utilizar CC. (WEISSMAN, 2010). Exemplo ou Soluo: Tudo em Cloud Computing feito mediante as questes firmadas no acordo do nvel de servio (SLAs) (WEINHARDT, 2009). Portanto, o cuidado e a anlise com o SLA considervel. Deste modo, possvel verificar a eficincia do modelo de implantao da CC, se pblico ou privado, bem como o esforo da equipe de implementao da Mquina Social, este deve ser o menor possvel. Todavia antes de verificar a adoo de qualquer servio CC devem-se analisar anteriormente todas as SLAs referentes ao servio. Estas formalizam um contrato de acordo de servio, ou seja, o que ser prestado como servio e como deve ser o desempenho do fornecedor de servio. Tais SLAs devem ter a transparncia necessria para deixar evidente o que ser fornecido como servio, como ser fornecido, a que custo ser fornecido, os prazos necessrios e etc. Enquanto as SLAs so protagonistas no assunto, outros servios e tecnologias ganham destaque, entre eles: Cloud Brokers: Trata-se de um sevio de corretagem em CC, empresas especialistas no assunto ofertam esse servio que visa indicar qual o melhor provedor, e quais os servios Cloud mais adequados ao negcio que pretende adotar Cloud Computing (GARTNER Inc, 2009). Os Brokers ainda so capazes de analisar as SLAs existentes em um contrato de pretao de servio Cloud, indicar melhorias nesse contrato, e ainda viabilizar a implantao do

111

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

servio, caso a empresa no tenha recursos humanos totalmente capacitados38. Windows Azure: Segundo experimentos de Kossmann, Kraska e Loesing (2010) a IaaS Windows Azure a plataforma que oferta maior performance e escalabilidade aos sistemas de mdio e grande porte. Ou seja, aos sistemas com lgicas mais complexas, ou, que devem suportar grande volume de dados e de acessos. Tal plataforma ainda oferta servios de criptografia RSA e segurana de dados com firewall. A estratgia para se decidir como usar CC na arquitetura da Mquina Social realmente estudar o escopo e a necessidade da aplicao para confrontar com o que Cloud Computing pode ofertar. importante compreender as tecnologias que os provedores de Cloud Computing usam para prestao de servio assim como as implicaes dessas tecnologias sobre os recursos computacionais, sobre a economia e a segurana. Tal compreenso relevante, pois a arquitetura da Mquina Social vai se entrelaar a alguma camada da arquitetura do provedor de servio Cloud Computing. Esta prtica ajudar nas decises relacionas a Cloud Computing e no entendimento de alguns de seus recursos relacionados abaixo: 1. Recursos Computacionais:

Ao utilizar um recurso Cloud Computing como IaaS, por exemplo, possvel dispor de recurso computacional automaticamente conforme a necessidade e crescimento da aplicao, isto sem esforo da equipe de desenvolvimento da Mquina Social. Alm disto, com esta soluo possvel usufruir de alta segurana e disponibilidade dos dados. Para um servio de IaaS a empresa Amazon pode ser considerada. A organizao, ou a pessoa, que adquirir os servio Cloud da Amazon, consegue implantar um software Oracle, por exemplo, ou fazer backup de um banco de dados, em muito pouco tempo39 e sem problemas. A Amazon ainda disponibiliza o servio Amazon Elastic Compute Cloud (EC2). Com ele possvel montar um ambiente que pode ser usado para as implantaes de banco de

38

Disponvel na pgina do intituto Gartner, Inc. (NYSE: IT). Fundado em 1979 em Connecticut, U.S.A. Em:

http://www.gartner.com/technology/about.jsp. Acesso em: 31 de nov. 2011


39

Informao disponvel em: http://aws.amazon.com/ec2/. Acesso em 15 de out. 2010.

112

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

dados. Por fim, esses servios IaaS so capazes de ofertar balanceamento de carga, segurana por meio de firewall, e replicao de instncias de bancos de dados. Algumas recomendaes sobre os servios e recursos Cloud Computing prosseguem abaixo: Guardar rplicas de segurana em outros repositrio, sejam eles locais ou na

nuvem. Tais cpias devem ser, sobretudo, dos dados. Isto necessrio porque os recursos Cloud Computing so susceptveis de falhas. Usufruir sempre da garantia de disponibilidade e analisar outros mtodos que

contribuam para a aquisio de desempenho da aplicao. Pesquisas recentes feitas pela empresa Compuware40 apontam que 72% das empresas avaliadas em uma pesquisa alegam que no houve ganhos em desempenho (mal desempenho) ofertados pelos servios Cloud Computing. Trabalhar fortemente com XML para a integrao entre as camadas da

arquitetura na aplicao e na nuvem. Utilizar caractersticas de arquiteturas ou redes P2P para amenizar os

problemas da desacelerao das atividades de leitura e escrita em disco (KE et al. 2009).

2.

Economia:

O preo do servio deve estar claro em uma SLA de CC. Alguns planos do Amazon EC 2, por exemplo, custam apenas 600 (seiscentos) dlares por ano41. Para algumas empresas, isto pode significar uma reduo de custos, segundo a Forrester Research, de at 80% nos gastos com infraestrutura. Cloud Computing pode trazer reduo de custos para empresa de pequeno e mdio (PMEs) porte que no possuem um forte parque tecnolgico. Logo, o nvel de maturidade da TI em empresas desses portes, principalmente no Brasil, relativamente baixo (REZENDE, 2006). Para as PMEs, o preo das boas ferramentas tecnolgicas sempre foi elevado. Neste

40

Disponvel em: http://computerworld.uol.com.br/negocios/2010/09/10/desempenho-e-maior-problemapara-usuarios-de-cloud-computing/. Acesso em 30 de jul. 2011.


41

Informao disponvel em: http://aws.amazon.com/ec2/. Acesso em 19 de ag. 2011.

113

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

aspecto, as ofertas de Cloud Computing podem ser vantajosas, mostrando um cenrio mais promissor para a TI das PMEs. Cloud Computing pode ser uma soluo econmica em situaes onde se requer poder computacional. O exemplo seguinte explora muito bem essas situaes. Segundo Taurion (2009), o jornal New York Times no ano de 2008 necessitou digitalizar todas as suas edies desde 1851 at o ano 1989. Entretanto, os recursos computacionais do jornal ficariam sobrecarragados, o que levaria a aquisio de novos recursos. Nesta situao a equipe de TI decidiu por adquirir os servios Cloud Computing EC2 da Amazon, o que possibilitou o processamento de 3 (trs) terabytes de dados, em 24 (vinte e quatro) horas, utilizando 100 (cem) instncias virtuais a um custou de 240 (duzentos e quarenta) dlares. Por fim, o uso de SMs depender muito do contexto econmico da empresa, apesar das aparentes vantagens h de se analisar todas as despesas decorrentes de treinamento, contratos, marketing e outras vertentes naturais do negcio. Somente assim ser possvel verificar se as vantagens sero refletidas por meio de economia financeira. A adoo de Cloud Computing para reduo de custos algo muito relativo, e no deve ser o fator preponderante para a adoo.

3.

Segurana:

A segurana um requisito importantssimo para qualquer sistema computacional. E a falta de segurana um perigo presente no s para os usurios de Cloud Computing. Mas, se tratando de CC, existem receios em sua adoo que so oriundos da falta de segurana. O fato que existem realmente riscos, mas, em oposio a eles, existem excelentes solues que objetivam garantir a segurana. A grande preocupao reside em no saber se os dados estariam to seguros em Cloud Computing quanto estariam seguros localmente. Pois bem, a privacidade nos dados, sobretudo quando se utiliza os servios de uma Public Cloud, ou nvem pblica, pode ser algo delicado, Os dados de uma empresa, ou cliente, que so armazenados em uma nuvem pblica, normalmente residem em um ambiente compartilhado com dados de outros clientes e empresas. Assim necessrio trabalhar bem com o controle aos meios de acesso aos dados. Controle de acesso via senha uma soluo bem madura em Cloud Computing, uma vez que, por meio da senha os clientes e as empresas respondem a um conjunto de questes de segurana para ter acesso conta. Neste contexto, a criptografia por meio do algoritmo RSA 114

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

muito bem trabalhada. Existem ainda os certificados de chaves pblicas. Eles permitem transferncias de dados sempre protegidos usando novamente a criptografia. Geralmente isto pode ser implementado em SaaS, PaaS e IaaS diversificadas. Tais chaves rotineiramente so geradas fora da nuvem, o que oferta mais segurana e confiabilidade ao cliente ou empresa que so os nicos a terem conhecimento da chave. Todas as solues de segurana contempladas nos pargrafos acima foram lanadas pelo NIST em um documento42 do ms de dezembro do ano de 2011. O mesmo possui prticas e orientaes sobre segurana e privacidade em Cloud Computing. O documento orienta que a adoo da nuvem privada mais adequada aos negcios de qualquer natureza, ou seja, a escolha por uma nuvem pblica ou privada depender muito da natureza dos dados trafegados. Entretanto, o mesmo documento encoraja experincias com o modelo pblico de Cloud Computing. A segurana tem sido bastante trabalhada em Cloud Computing. Vale reforar que novamente as SLAs devem tratar claramente das questes de proteo, privacidade dos dados, e garantia de integridade das aplicaes. A prxima prtica deixa a parte as questes de Cloud Compunting e aborda uma questo de elevada importncia para um sistema distribudo em rede: a questo dos Padres de Projeto.

5.3.9. PRTICA 9: Selecionar os padres de projeto mais adequados para a arquitetura da Mquina Social.

Padres de projeto so solues de cdigo que podem ser reutilizadas para resolver um determinado problema (GAMMA, et al. 2000). Estes padres substituem implementaes de cdigos e projetos de componentes de software. So produtos preparados para interagir com implementao e agregar recursos que dem suporte a alguma funcionalidade a ser desenvolvida. Problema: Os padres de projeto podem ser utilizados com qualquer linguagem de programao desde que os conceitos de orientao a objetos sejam vigentes na aplicao. Entretanto, necessrio guiar esses padres para o contexto de Mquinas Socias enquanto aplicaes Web,

42

Disponvel em: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909494.

115

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

limitando os mesmos. O quantitativo de problemas a serem resolvidos por Mquina Sociais vasto, assim, a probabilidade de usar padres diversificados grande. Deste modo, deve-se fechar o escopo dos padres para Mquinas Sociais a partir das caractersticas, conceito, e particularidades de uma SMs. Ao todo existe um universo de 23 padres de projeto. Quais destes ofertariam melhor suporte as SMs? Alm deste questionamento, existem tambm alguns problemas que so inerentes s Mquinas Sociais e que podem ser solucionados por padres de projeto especficos. Alguns destes problemas so: No ter fcil acesso s informaes sobe o estado dos componentes; No ter conexes eficientes entre as Mquinas Sociais e entre os componentes que constituem as mesmas; No ter ao necessria de forma imediata aps conhecer o estado dos componentes. Motivao: desejvel que existam solues reutilizveis em algum nvel de abstrao e que sejam voltadas s Mquinas Sociais. Na verdade esse conhecimento poder motivar o estudo de novos padres para SMs. Ainda assim, os padres j existentes demonstram muita riqueza quanto capacidade de resolver problemas naturais das Mquinas Sociais. Exemplo ou Soluo: A execuo desta prtica deve levar em considerao que alguns padres so fortemente utilizados no estilo arquitetural camadas, So eles: Observer, Composite e o Strategy (LARMAM, 2005). Alm disto, os padres so divididos em 3 (trs) grupos: padres de criao, padres estruturais, e padres comportamentais. Os padres comportamentais e os padres estruturais constituem os maiores grupos, e tambm so os mais relevantes para as Mquinas Sociais. Isto se deve ao fato do primeiro grupo de padres ser o nico a se preocupar com a conexo entre os objetos e classes. Estes padres tambm priorizam a cooperao entre os elementos e ainda viabilizam o baixo acoplamento, o que fundamental para a arquitetura em Camadas, segundo Craig Larmam, 2005. 116

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Larman tambm afirma que o outro grupo de padres estruturais visa a composio das classes que formam os sistemas de modo que essas classes sempre tenham interfaces compatveis no intuito de se unirem para formar uma unidade maior, como um componente que constituir o sistema, ou o prprio sistema em si. Vale ressaltar que, se houver necessidade, os padres do grupo de criao podem tambm ser empregados; principalmente os padres que criam interfaces, como o Factory Method (GAMMA et al, 2000). Neste ponto veremos a definio de alguns dos padres de projeto (GAMMA et al, 2000) mais preparados para atender a maioria das Mquinas Sociais enquanto sistemas Web.

Padres de Projetos Estruturais Nome Adapter Definio / Problema a ser resolvido Faz a adaptao de interfaces em momento que uma classe no tem a interface que corresponde ao domnio esperado pela aplicao. Composite Compem classes para formar um componente maior, deixando transparente ao usurio ao qual est fornecendo o servio, se um componente ou se o conjunto destes. Previlegia o baixo acoplamento. Decorator Usa de forma flexvel a extenso de subclasses para acrescentar operaes acionais s classes ou objetos. Isto quando se fizer necessrio a adaptao da funo de um componente para uma funcionalidade especfica.
Tabela 6. Padres Estruturais relevantes para as SMs

Padres de Projetos Comportamentais Nome Mediator Definio / Problema a ser resolvido Armazena em um objeto a forma pela qual todos os outros objetos iro interagir; ele aplicado para reduzir a duplicao de cdigo, pois as classes, ao serem criadas podem ser customizadas para ter sua comunicao e funo viabilizadas por este padro. Observer Gera uma ligao entre os objetos de modo que, no momento em que um objeto alterar seu estado, todos os objetos sejam automaticamente notificados da alterao. 117

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

State

Permite que um componente altere suas funes conforme a alterao do seu estado.

Strategy

um conjunto de algoritmos distintos que pode ser executado para alterar o comportamento de uma classe conforme as variaes do ambiente ou conforme a necessidade dos requisitos.
Tabela 7. Padres Comportamentais relevantes para as SMs

A aplicabilidade dos padres comportamentais sobre as SMs maior do que a aplicabilidade dos padres estruturais. Outros padres, fora ou no desses grupos, podem ser de grande valia s SMs, mas isto ir depender unicamente das caractersticas da aplicao e do ambiente onde a mesma est inserida, ou ainda dos requisitos impostos mesma. O seguinte exemplo pode ocorrer de forma natural no emprego dos padres s SMs. Imaginemos que a camada de negcio poder ter em seus componentes a insero do padro Strategy, que ser til no caso de uma camada superior da arquitetura ofertar uma resposta negativa, ou fora do esperado, neste caso, graas ao padro, a camada inferior no responderia as solicitaes, anulando assim, suas operaes. O exemplo acima um caso que retrata a contribuio de um padro na satisfao de um requisito no funcional para a Mquina Social. Quando se observa melhor a prioridade desses requisitos, possvel empregar melhor os padres. A tabela 8 mostra o relacionamento entre os padres indicados para as Mquinas Sociais e os requisitos no funcionais das mesmas.
Padres RNF

Adapter Composite Decorator Mediator Observer State Strategy X X X X X X X X X X X X X X X X X X

Performance Disponibilidade Modificabilidade Interoperabilidade

Tabela 8. Relao entre os padres de projeto e os requisitos no funcionais das SMs

Esta prtica, assim como todas as outras, tende a orientar os desenvolvedores quanto s melhores decises de projeto para a Mquina Social a ser implementada. A deciso mais assertiva em relao a banco de dados de Mquinas Sociais ser exposta a seguir: 118

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

5.3.10. PRTICA 10: Selecionar o banco de dados no relacional

Bancos de dados no relacionais, ou NoSQL, surgiram em 1998. O propsito deste tipo de banco de dados suprir as carncias que esto presentes nos bancos relacionais, entre elas, a escalabilidade e a flexibilidade em mudar estruturas. A abordagem NoSQL tem sido a mais explorada entre grandes coorporaes da Web 3.0, como: Facebook, Twitter, Google e Amazon (LEAVITT, 2010). Problema: O problema reside no fato das Mquinas Sociais serem, em grande parte, aplicaes que necessitam de bom gerenciamento dos acessos aos dados, acessos que passam a ser crescentes ao passo que cresce a quantidade de usurios da aplicao, necessitando assim de escalabilidade para a performance. Tal requisito deficitrio em banco de dados relacionais (LEAVITT, 2010). Motivao: Explorar uma abordagem mais moderna e que propicie a escalabilidade de forma mais simples e mais barata que os modelos relacionais uma grande motivao para as SMs. No necessrio que a SM a ser desenvolvida tenha milhes de usurios em acessos simultneos. Basta que a mesma trabalhe com objetos complexos, ou que tenham entidades espalhadas em muitas tabelas normalizadas (TIWARI, 2011), isto seria suficiente para trabalhar com NoSQL. Os bancos no relacionais atendem de forma mais eficiente os requisitos das Mquinas Sociais, sobretudo, desempenho (TIWARI, 2011). Exemplo ou Soluo: Para seguir tal prtica necessrio avaliar algum banco NoSQL, entre elas se destacam: Amazon Dynamo e MemcachedDB: trabalham com armazenamento de dados baseados no modelo chave-valor (TIWARI, 2011). CouchDB e MongoDb: trabalham com armazenamento de dados baseado no modelo orientado a documentos (CHODOROW e DIROLF, 2010).

119

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

BigTable, SimpleDB, Hbase e Cassandra: trabalham com armazenamento de dados baseado no modelo orientado a colunas. Neo4j e InfoGrid: trabalham com armazenamento de dados baseado em grafos.

Todas essas solues so distribudas e executam o chamado processo de sharding. Esse processo faz o escalonamento paralelizado (TIWARI, 2011), ou seja, os dados so distribudos por vrios servidores que trabalham de forma paralela. Isto possibilita a escalabilidade. J o desempenho da SM sensivelmente melhorado devido diminuio do volume de dados processados pelos servidores de BD NoSQL. Finalmente, um requisito fortemente atendido e extremamente relevante SM, a disponibilidade (LEAVITT, 2010). Esta pode ser atendida, pois, uma ou duas BDs podem ficar indiponveis sem causar a interrupo de toda a SM. Com NoSQL, disponibilidade, desempenho/performance e flexibilidade so agregados a arquitetura. Isto contribui ainda mais para o bom funcionamento da SM. At mesmo a consistncia dos dados pode ser garantida, haja vista que o sistema de banco de dados possui mecanismos que detectam quando os objetos forem atualizados (CHODOROW e DIROLF, 2010), retornando sempre o ltimo valor atualizado dos mesmos. Depois da devida anlise da SM a ser construda, necessrio selecionar como ser o sistema de armazenamento. Nesta anlise, caso seja detectado que a SM a ser desenvolvida possa trabalhar com a base de dados relacional, a mesma pode ser adotada, j que ocorrem diversos benefcios em sua aplicao, principalmente na questo da consistncia dos dados. As concluses deste captulo vo em seguida abordando as prticas para SM, sintetizando as idias, amadurecendo alguns possveis trabalhos futuros, alm de preparar o prximo captulo.

5.4. CONSIDERAES FINAIS DO CAPTULO

Algumas prticas recomendadas aqui do novas idias que podem ser amadurecidas perfeitamente em trabalhos futuros, como: os padres de projeto que podem ser adaptados para as SMs, fazendo surgir assim um novo padro; bem como, o framework de Mquinas Sociais exposto neste trabalho, e ainda, possveis padres de processo de SMs. Os padres de 120

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

processo fazem parte das disciplinas ligadas a negcio e administrao de empresas, todavia, existe uma proposta de padro de processo chamada Business Pattern, autoria de Mark Endrei e mais 7 (sete) autores pela empresa IBM no ano de 2004. Os padres de processo exibem vrios padres de TI. Estes padres guiam o desenvolvimento de aplicaes especficas, como por exemplo, ferramentas Web que viabilizam o trabalho colaborativo. Uma das recomendaes para esse tipo de sistema seria implementar a ferramenta por meio do Collaboration (User-to-User). Este uma padro que teria os conhecimentos mais adequados sobre as tecnologias de implementao, arquitetura e reuso de componentes do trabalho colaborativo. Logo assim, as prticas aqui tratadas poderiam formar um padro de construo de SMs, fazendo parte do catlogo do Business Pattern. Em vista de justificar alguns conceitos importante evidenci-los ao final do catlogo de boas prticas. Na verdade as prticas constituem sim um padro para construo de Mquinas Sociais, e, para isto, adota estratgias que deixam evidente o uso de alguns conceitos e tecnologias, como componentizao de software. A criao de componentes de software exalta a criao de pequenas partes do software com funes bem definidas e interfaces adaptveis para a conexo com uma variedade de aplicaes. A implementao de componentes particiona a aplicao, facilitando a adoo do estilo camadas e promovendo a independncia de tecnologias (CHEESEMAN e DANIELS, 2001). A manuteno e evoluo do software tambm so facilitadas, podendo a arquitetura da aplicao ser estendida sem muita dificuldade de modo que seus componentes possam ser distribudos (TANENBAUM, 2002), integrados e reutilizados. Em praticamente todas as prticas existe uma meno componentizao de software, especialmente as prticas 5 (cinco) e 2 (dois), alis, a 2 e 3 prtica tratam dos assuntos relacionados a SOA inclusive. As primeiras prticas remetem aos princpios que so trabalhados no paradigma da Arquitetura Orientada a Servios SOA; a adoo desse paradigma j trouxe diversos benefcios s mdias e grandes empresas (ERL, 2008). SOA ou Arquitetura Orientada a Servio baseada em computao distribuda e seu conceito est voltado para a utilizao de software como servio. SOA, assim como a componentizao, contribui para a reutilizao de software favorecendo a comunicao entre os sistemas (JOSUTTIS, 2007). 121

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Para adotar SOA, necessrio fazer um catlogo de todos os processos que apiam a TI e que sejam parte do nicho de negcio dos softwares implementados (JOSUTTIS, 2007). Estudos recentes efetuados pelo instituto de pesquisa Gartner revelam que SOA promove uma maior eficincia na execuo dos processos de negcio, facilitando o surgimento de outros processos, reduzindo gastos, melhorando a escalabilidade do sistema, a qualidade e o tempo de entrega dos servios. SOA tambm estaria apta a trabalhar dentro do paradigma de Cloud Computing, segundo o instituto. Tal paradigma est bem maduro e propenso a auxiliar o desenvolvimento de SMs. No propsito adotar SOA definitivamente em SMs, mas sim adotar alguns princpios e conceitos de SOA e que podem auxiliar no desenvolvimento facilitado de SMs, como por exemplo: o tratamento aos servios e o cuidado com a modelagem de processos. Assim, a modelagem de processo que tratada na primeira prtica pode dar suporte para demais prticas. Os servios s so bem mensurados quando se conhece o negcio. Neste trecho notvel uma relao de dependncia entre as prticas. As prticas 7 (sete) e 9 (nove) esto tambm bem entrelaadas s demais prticas. Neste caso, a prtica sete, por exemplo, ajudar a encontrar a melhor soluo em comunicao e interoperabilidade mediante o auxlio de outras prticas, como: as prticas de anlise dos servios, de implementao dos elementos States e Constraints, dos estilos arquiteturais que compem a arquitetura da SM e os padres de projeto utilizados. Outra relao que pode ser ainda traada entre as prticas e os requisitos no funcionais que devem ser priorizados para as SMs. Dentro deste contexto deve-se observar que a alterao na metodologia proposta deve ajudar a arquitetura a satisfazer os requisitos no funcionais crticos para a Mquina Social. Deste modo, a tabela 9 relaciona os requisitos s prticas.

122

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

RNF Prticas 1.Modelar Processos 2.Reconhecer os Servios 3.Reconhecer os Provedores 4.Recursos para Autonomia 5.States e Constraints 6.Extratgia Estilo Arquit. 7.Comunicao e Interoper. 8.Cloud Computing 9.Padres de Projeto 10. NoSQL

Desempenho / Performance

Disponibilidade

Modificabilidade

Interoperabilidade

X X X X X X X X X X X X X X X X X X X X X X X X

X X

Tabela 9. Relao entre as prticas e os requisitos no funcionais

Aproveitando o ensejo da exibio da tabela 9, inteligente reforar mais uma vez que as prticas podem se comportar como decises de projeto que vo compor a arquitetura. Ou seja, que vo auxiliar a estruturar a Mquina Social. Sendo assim, as prticas propem a adoo de certas tecnologias, tecnologias que fazem parte da arquitetura de referncia e que podem ser ilustradas na Figura 23. Tal Figura verdadeiramente mais uma abstrao da arquitetura de referncia para SMs. Por meio da Figura 23 possvel notar que tcnicas de SOA e BPMN podem ser empregadas no incio do projeto, fase de concepo, uma das primeiras fases no processo de definio arquitetural (primeira camada do processo/arquitetura). Em um segundo plano, algumas das tecnologias j referenciadas pela metodologia so aplicadas em camadas mais centrais da SMs; por fim, a alocao de algum modelo no relacional de base de dados. Todas essas camadas so divididas e envoltas aos padres de projeto citados na prtica.

123

Captulo 5. Recomendao de Prticas Para Desenvolver Arquiteturas de Mquinas Sociais

Figura 23. Abstrao da arquitetura de referncia (tecnologias)

A fim de comprovar a eficincia das prticas recomendadas, sera desenvolvido um estudo de caso, o prximo captulo tratar deste estudo, onde uma Mquina Social ir ser desenvolvida mediante a metodologia proposta.

124

Captulo

6
6. Experimentao das Prticas
Este captulo foi concebido para mostrar a aplicao das prticas propostas para o desenvolvimento de arquiteturas de Mquinas Sociais. O objetivo guiar as decises de projetos e a prpria modelagem da arquitetura. Assim, ao final da implementao, ser verificado como o produto desta pesquisa foi til ao desenvolvimento de SMs.

125

Captulo 6. Experimentao das Prticas

6.1. INTRODUO

O experimento efetuado do tipo estudo de caso, ou caso de uso, ou ainda In vivo, (JURISTO e MORENO, 2001). Trata-se de um caso real de pessoas em seu ambiente prprio de trabalho. No entanto, antes de exibir o estudo, haver uma seo para expor brevemente um projeto piloto, o qual foi utilizado para por em prova o planejamento do estudo de caso e o prprio objeto de controle, ou seja, a abordagem a ser experimentada. Nem todos os detalhes sobre o desenvolvimento sero expostos, pois os projetos so reais de empresas e profissionais fixadas no mercado, onde os produtos, ou SMs resultantes, ainda no esto disponveis aos clientes ou usurios. Os responsveis pelo desenvolvimento das SMs que sero exibidas neste captulo autorizaram a exposio das mesmas. No entanto, como j explicitado, por questes de confidencialidade exigidas pelos proprietrios das SMs, e tambm por causa de concorrncia da indstria de software local, algumas informaes sero subtradas da exibio do desenvolvimento. Todavia acredita-se que a ausncia de tais informaes no deixar pontos duvidosos ou falsos no estudo.

6.2. DEFINIO DOS OBJETIVOS 1. Objetivo Global: Determinar o efeito do uso das prticas e da arquitetura de referncia na definio de arquiteturas de Mquinas Sociais na qualidade dessas arquiteturas. 2. Objetivo da Medio Baseado nas Caractersticas das SMs e na Comparao em no Usar as Prticas e a Arquitetura de Referncia - AR: verificar as vantagens oferecidas pela AR e prticas de SMs na definio da arquitetura sobre os aspectos: adequao das prticas, preciso nas escolhas arquiteturais, usabilidade da arquitetura de referncia, agilidade na fase de projeto de arquitetura, ou simplesmente projeto; e por fim, a qualidade dos componentes codificados na fase de implementao. 3. Objetivo do Estudo: Analisar a adequabilidade da arquitetura de referncia e das prticas propostas em projetos de Mquinas Sociais quando comparado ao desuso das mesmas, isto no contexto de empresas que desenvolvem SMs. 126

Captulo 6. Experimentao das Prticas

4. Questes: a. Os pontos tratados pelos mtodos propostos para SMs, ou seja, prticas mais AR, so suficientes para a arquitetura da SM ser desenvolvida em todos os seus aspectos ou ao menos aos aspectos mais importantes como os requisitos no funcionais? i. Mtrica: Quantidade de pontos ou requisitos trabalhados pela arquitetura com auxlio dos mtodos propostos. b. As prticas e arquiteturas de referncia para SMs auxiliaram na definio adequada dos componentes arquiteturais, ofertando assim maior qualidade do produto de software e consequentemente da arquitetura? i. Mtrica: Quantidade de no conformidades encontradas por meio de testes funcionais e tambm por meio da aceitao do cliente. A questo e mtrica relacionada as no conformidades so difceis de serem controladas. Se este experimento fosse feito em laboratrio, onde todas as variveis fossem controladas, a dificuldade poderia ser menor (JURISTO e MORENO, 2001). Isto ocorre porque a quantidade de defeitos encontrados nos produtos de software muito relativa aos requisitos, s pessoas envolvidas, e claro, s decises de projeto e arquitetura. Com isto complicado saber qual a causa dos defeitos. No entanto, vlido incluir essa questo e mtrica, pois as prticas trabalham na concepo dos processos de negcio e servios, o que faz elas enrriqueam os requsitos, e melhorem a arquitetura. Averiguar a quantidade de defeitos encontrados nos artefatos testados aps o uso das prticas na arquitetura de referncia dar indicius de que as mesmas auxiliaram em algum aspecto, ou mesmo em conjunto a outros fatores, na diminiuo dos defeitos.

127

Captulo 6. Experimentao das Prticas

6.3. PLANEJAMENTO 6.3.1. OBJETO DE CONTROLE O objeto de controle a abordagem a ser experimentada (WOHLIN. et al, 2002). Para este estudo, o objeto so as prticas e arquitetura de referncia propostas para conceber arquiteturas de Mquinas Sociais. 6.3.2. UNIDADE EXPERIMENTAL A unidade experimental o objeto que receber o tratamento (JURISTO e MORENO, 2001). Para este estudo o objeto que ser submetido experimentao a fase de projeto, ou modelagem de sistema. Nesta ser verificado a utilidade da metodologia de SM e se a mesma adequada para a formulao da arquitetura de Mquinas Sociais. 6.3.3. DEFINIO DAS HIPTESES

Sero divididas em hiptese nula, que representa o que o estudo quer negar (WOHLIN. et al, 2002); e hiptese alternativa, que representa o contrrio da hiptese nula (TRAVASSOS, GUROV e AMARAL, 2002). HIPTESE NULA: O uso das prticas e da arquitetura de referncia no demostrou diferena nos parmetro abaixo em relao ao no uso das mesmas pela empresa para a definio de arquitetura. NPOR: nmero de requisitos da SM trabalhados pela arquitetura. AD: adequao da arquitetura concebida por meio do objeto de controle. Deste modo o que a hiptese nula afirma : NPORsemprticas+AR=NPORprticas+AR ADsemprticas+AR=ADprticas+AR

HIPTESE ALTERNATIVA: O uso das prticas e AR revelou ganhos em relao aos parmetros, de modo que, a qualidade do produto foi atestada como satisfatria, assim: NPORsemprticas+AR<NPORprticas+AR 128

Captulo 6. Experimentao das Prticas

ADsemprticas+AR<ADprticas+AR

Dentre estas variveis o fator tempo no foi controlado. Entende-se que o mesmo no agregaria resultados significativos, uma vez que possvel que o tempo da fase de projeto seja maior com a utilizao das prticas. Isto, em equipes que j faam uso de uma metodologia de concepo da arquitetura. O objetivo tambm no viabilizar uma arquitetura em pouco tempo, mas sim, disponibilizar uma arquitetura correta e de qualidade Mquina Social.

6.3.4. VARIVEIS INDEPENDENTES E DEPENDENTES

VARIVEIS INDEPENDENTES:

1. Tipo de Mquina Social a ser construida: necessrio que sejam desenvolvimentos interessantes de Mquinas Sociais do tipo Prosumers, pois essas SMs so mais completas e complexas. Sendo assim, o resultado pode ser verificado para o caso mais extremo de SMs. Com isto, se o resultado for satisfatrio, entende-se que o objeto de controle poder ser aplicado sem maiores problemas para os projetos de SMs mais simples. 2. Habilidade da equipe em desenvolver e entender as aplicaes WEB como Mquinas Sociais: em equipes que j entendem as apliaes como SMs, as novidades nas prticas e AR podero no agregar benefcios de grandes dimenses. 3. Fase do processo de desenvolvimento: a fase um fator relevante porque necessrio trabalhar o objeto de controle em um momento que possibilite o acompanhamento do projeto e a instanciao das prticas e arquitetura de referncia. Ou seja, os desenvolvimentos no devem estar na fase de codificao da aplicao ou mesmo documentao de arquitetura. VARIVEIS DEPENDENTES: 1. Maior quantidade de pontos ou requisitos trabalhados pela arquitetura para satisfazer a Mquina Social; 129

Captulo 6. Experimentao das Prticas

2. Adequabilidade maior da arquitetura Mquina Social, com poucas, ou nenhuma no conformidade (defeitos encontrados).

6.3.5. RUDOS

Os rudos podem contaminar as variveis durante o experimento. Estes rudos so erros que ocorrem de forma no intencional e sim inesperada durante o estudo (TRAVASSOS, GUROV e AMARAL, 2002). Um rudo provvel seria a no execuo de alguma prtica proposta devido a um acontecimento que exija menos tempo de desenvolvimento, provocando assim, uma m execuo da fase de (projeto) modelagem. Outro rudo seria a ausncia de algum integrante da equipe, ausncia provocada por um problema ou por alguma determinao da empresa.

6.3.6. CONTEXTO

O contexto caracterizado como sendo In vivo, como j indicado anteriormente. Ademais, trata-se de um experimento contextualizado como um problema real de produo de software que utiliza profissionais da rea de Cincias da Computao como participantes. Os resultados deste experimnto podem ser teis a problemas especficos da modelagem arquitetural de Mquinas Sociais.

6.3.7. SELEO DOS INDIVDUOS Os indivduos que estiveram contidos neste estudo de caso faziam parte da equipe de desenvolvimento e foram selecionados mediante determinao da prpria empresa, antes mesmo que esta obtivesse conhecimento do planejamento do estudo. A unidade experimental selecionada estava no momento ideal de ser submetida, ou seja, as fases de projeto e codificao ainda no haviam iniciado. Alm disto, a empresa se colocou disposio do experimento. Quanto empresa, importante citar que o estudo de caso foi sobre uma Mquina Social criada pela empresa MV Informtica Nordeste. A MV uma empresa com mais de 25 anos no mercado de desenvolvimento de software para gesto hospitalar. A linha de produo da MV responsvel por sistemas que automatizam todos os processos de instituies ligadas sade no Brasil, entre elas: planos de sade, clnicas, hospitais pblicos e privados, e 130

Captulo 6. Experimentao das Prticas

tambm unidades de pronto atendimento, as UPAs. Assim, os sistemas possuem funcionalidades que fazem desde o controle financeiro at o controle de fichas anestsicas de pacientes, incluindo o pronturio eletrnico do mesmo. A MV autorizou a documentao e exposio deste experimento. 6.3.8. VALIDADE Nesta seo as possveis ameaas validade do experimento (JURISTO e MORENO, 2001) sero listadas. Trs ameaas validade foram detectadas, a primeira foi a Validade Externa. Validade Externa pode limitar o resultado obtido no experimento de modo que as prticas e AR para SMs tenham uma adoo duvidosa por parte da indstria de software. Nesta categoria, uma ameaa a insero de requisitos durante a fase de projeto ou mesmo aps tal fase. possvel que o cliente solicite um requisito fora da fase de anlise. Tais requisitos podem impactar na arquitetura, modificando ou estendendo a mesma. Desta forma, existiria o risco de dar tratamento acima de uma arquitetura com requisitos diferentes, afetando assim as variveis. Dentre as ameaas a validade houve a imposio da empresa em comear o desenvolvimento. Havia datas predefinidas e improrrogveis para o incio de cada fase do processo. O desenvolvimento do produto da MV teve acompanhamento constante, com exigncias de diversos gestores e um diretor. Este fato impulsionou outra ameaa, desta vez Validade de Concluso. Uma vez que houvesse a presso para o incio do projeto, no haveria tempo hbil para comear o experimento com o emprego das prticas e da AR de Mquinas Sociais. Deste modo, o experimento deveria iniciar sem o objeto de controle, apenas por meio da metodologia tradicional j utilizada anteriormente pela empresa. Esta ameaa prpria da Validade de Concluso imposibilitaria concluir com convico o real resultado do tratamento, ou seja, o real resultado do experimento. Assim, a equipe desenvolvedora e participante do estudo j teria certo conhecimento de como fazer a modelagem e tambm de quais problemas deveriam ser resolvidos, alm das necessidades arquiteturais, haja vista que j haveriam projetado em um momento primrio a arquitetura sem o uso das prticas e da AR.

131

Captulo 6. Experimentao das Prticas

O preparo acima mencionado, tanto em relao equipe quanto ao produto de software a ser modelado e implementado pode caracterizar outra ameaa para o tipo Validade Interna. Esta validade se refere ao cansao mental, fsico, preocupao ou estresse dos participantes durante o experimento, pois que, todos os envolvidos poderiam participar de outros projetos concomitantemente ao experimento.

6.4. EXECUO

6.4.1. PROJETO PILOTO O projeto piloto a execuo da experimentao em outro ambiente, com outras pessoas e com outra unidade experimental (JURISTO e MORENO, 2001). Ele ser til para corrigir possveis erros no planejamento do experimento e verificar se existem melhorias que possam ser feitas no prprio objeto de controle. O projeto piloto foi executado sobre uma App de mercado que no foi desenvolvida por uma fbrica de software, mas trata-se de um projeto realizado por um profissional da rea de TI. Sua implementao e desenvolvimento podem ser atestados na ntegra no trabalho de Misael Neto, 2012. Tal App chama-se HobNob, este um aplicativo com escopo bem delimitado, pois sua funo sugerir acontecimentos sociais (festas) aos usurios conforme a localizao dos mesmo. O HobNob precisa de informaes bsicas de uma pessoa, precisa saber sua localidade e os gostos pessoais em relao msica, a artista favorito, e s festas frequentadas. Essa App uma aplicao dedica ao Facebook. A aplicao tratada neste experimento utiliza o Facebook de forma inteligente, haja vista ela mapeia at as ligaes de amizade entre os usurios da rede, ou seja, ele captura o grafo de amizade codificando os relacionamentos entre os objetos deste grafo. Deste modo, possvel revelar e indicar festas que amigos de um determinado usurio foram, ou vo, e que possivelmente este usurio possa querer ir. A formao do conhecimento para poder sugerir festas a uma pessoa conforme sua localizao tambm parte da utilizao dos servios do Google Maps. Por este pargrafo possvel observar que o HobNob uma Mquina Social Prosumers por natureza. Os principais resultados e efeitos deste projeto piloto sero detalhados em seguida.

132

Captulo 6. Experimentao das Prticas

Neste projeto inicial, o conjunto de prticas foi seguido, e elas foram plenamente compreendidas na ordem em que foram documentadas no captulo 5. Entretanto, nem todas foram lidas em sua completude, pois, neste experimento o responsvel pelo desenvolvimento j compreendia bem os conceitos de SMs e de muitas das tecnologias que podem ser empregadas no contexto da Web 3.0. Desta forma, o desenvolvedor se sentiu seguro o suficiente para uma leitura superficial das prticas. Para o projeto piloto, as primeiras prticas no tiveram muita contribuio pelo fato da aplicao j ser direcionada unicamente ao Facebook e ter um escopo bem limitado. Apesar deste fato, o conhecimento sobre servios, que a proposta das prticas, foi algo novo no desenvolvimento, logo que, os conceitos relacionados servio sempre estavam atrelados aos fatores mais tcnicos da codificao em si, como por exemplo, o emprego de ESBs. Os relatos acima foram observados e registrados durante o projeto. Este trouxe como maior resultado a deteco de uma falha no planejamento, falha que resultou na criao da varivel independente nmero 2 (dois) sobre a habilidade da equipe em desenvovler e entender as aplciaes WEB como SMs. Ainda sobre os ajustes efetuados aps este projeto piloto, deve-se relatar que todas as prticas foram seguidas, mas, houve a percepo da ausncia de uma recomendao. Assim, uma prtica foi adicionada, a mesma identificada como prtica 10 e faz referncia ao uso de NoSQL. Ao final da execuo deste projeto, foi possvel notar que o uso de prticas como a de SMs foi algo indito para o desenvolvimento, entretanto, a adoo da AR foi mais proveitosa em relao s prticas, pois estas no agregaram um ganho significativo para a modelagem da SM. Isto pode ser explicado pelo fato do desenvolvedor ter um grande conhecimento sobre as tecnologias que podem ser empregadas sobre as SMs.

6.4.2. ESTUDO DE CASO EDITOR DE FORMULRIOS/TELAS MVPEP

6.4.2.1. Preparao No sistema de pronturio eletrnico de um paciente, ou simplesmente MVPEP, se encontra o Editor de formulrio/telas. O Editor responsvel por criar ou desenvolver funcionalidades que no so supridas pelo MVPEP, ou seja, o Editor desenvolve telas, ou

133

Captulo 6. Experimentao das Prticas

pequenos programas de software que aceitam entrada de dados, fazem um determinado processamento, e apresentam um resultado satisfatrio ao usurio. A equipe responsvel pela implementao do Editor composta por 4 (quatro) pessoas, um analista de sistemas, um arquiteto, e 2 (dois) programadores. A MV determinou um perodo de tempo pequeno para desenvolver o Editor, sendo que o incio do projeto foi em setembro de 2011. As entregas do Editor deveriam ser mensais, mesmo porque a equipe de testes da empresa recebe uma build a cada ms, montando um o relatrio de erros encontrados nos componentes entregues. O mesmo repassado aos gestores. Dentro deste prazo, a primeira fase do projeto deveria ser entregue em dezembro de 2011. Neste momento, os parmentros eleitos na varivel alternativa foram registrados em um formulrio prprio para que os valores fossem pontuados nos mesmos. Para melhor entendimento dos motivos pelos quais o Editor considerado uma Mquina Social, fator relevante para a seleo do projeto como estudo de caso, ser apresentado a seguir algumas poucas funcionalidades do Editor. Com o Editor, possvel que os profissionais de TI do hospital, clnica ou UPA possam construir uma tela com vrios recursos, desde clculos, comparaes de dados, respostas automticas de questionamentos, tabelas e marcao de imagem (onde se marca na prpria imagem a parte afetada em um trauma corporal). Alm disto, o Editor pode apenas montar layout de formulrios, trazendo para uma pgina todos os componentes j criados por outras funcionalidades do sistema que abriga o Editor. O Editor altamente interopervel, pois no apenas ao MVPEP que o Editor precisa estar interligado, ele ainda necessita ser inserido em outro grande sistema da MV, o MVSOUL. Neste, o Editor formata os relatrios e formulrios que exibem os dados de exames de imagem e de laboratrio. A figura 24 demonstra a rea de trabalho do Editor. Nele o usurio desempenha todas as funes necessrias para criar documentos ou telas.

134

Captulo 6. Experimentao das Prticas

Figura 24. Editor no modo de criao de documentos no MVPEP (VERSO 1.5)

A Figura 25 o Editor exibido na sua forma de utilizao final, ela representa uma tela com formulrio a ser preenchido pelo usuiro final na utilizao do Editor pelo MVPEP.

Figura 25. Documento/tela do Editor sendo utilizado por um usurio final no MVPEP (VERSO 1.5)

135

Captulo 6. Experimentao das Prticas

6.4.2.2. Execuo A MV iniciou o desenvolvimento do Editor com a anlise do negcio e desenvolvimento dos requisitos. Aps o trmino da fase de requisitos, coube ao arquiteto desenvolver o projeto arquitetural seguindo um processo para definio da arquitetura que consistia em analisar os requisitos e propor solues que satisfizessem os mesmos. O diagrama de casos de uso e o diagrama de classes foram modelados. Todas as tecnologias selecionadas nesta fase j haviam sido empregradas em outros projetos da empresa. Ao final da fase de projeto, com o uso da metodologia tradicional da empresa foi registrado os valores dos parmetros avaliados nas hipteses alternativas. Aps a finalizao das etapas iniciais do projeto de desenvolvimento, levou-se algum tempo at que a confeco de alguns mdulos do Editor comeasse. Trs grandes funcionalidades foram implementadas: a funcionalidade de integrao do editor com os demais sistemas, a funcionalidade de escrita e edio de texto, e a funcionalidade de criao de perguntas. Essas 3 (trs) funcionalidades fazem com que o Editor seja utilizado pelo seu usurio final perfeitamente, claro que as demais funcionalidades que so recursos adicionais, como por exemplo criao de tabela, devem ser futuramente inseridas. Todos os resultados deste momento do estudo, com a primeira rodade de experimentao sem o uso das prticas e AR foram registrados. No apndice C possvel verificar o formulrio onde os valores dos parmetros foram apontados. O desenvolvimento do editor foi paralisado logo na primeira avaliao do cliente, pois verificou-se no conformidades aos requisitos, principalmente no requisito no funcional desempenho. Os desenvolvedores da equipe passaram a se empenhar em outras demandas de desenvolvimento e o arquiteto do Editor iniciou novamente seu trabalho de projeto arquitetural, desta vez seguindo as orientaes das prticas e AR proposta. Exatamente as mesmas funcionalidades foram desenvolvidas tanto na definio arquitetural sem uso das prticas e AR, como com o uso destas. A equipe tambm prevaleceu a mesma, bem como, os prazos. Na verdade, como houve desaprovao de funcionalidades, de performance e interoperabilidade, o cliente aproveitou o ensejo e solicitou pequenas alteraes nos requsitos. Foi solicitada nova anlise dos problemas e modelagem, o que possibilitou a experimentao do objeto proposta neste trabalho sem demais problemas. A experimentao executada com o uso das prticas e AR teve todos os resultados expostos em um documento em anexo. Nesta seo, ser inserido apenas a forma pela qual houve a adoo da metodologia e os resultados obtidos. Desta maneira, na fase de projeto 136

Captulo 6. Experimentao das Prticas

arquitetural, a arquitetura de referncia foi visualizada e compreendida. Em seguida, houve um esboo da arquitetura Editor_Core, a arquitetura do Editor, que foi amadurecendo ao passo que as prticas e AR foram compreendidas e atendidas. importante frisar que alteraes em requisitos no caracterizaram uma alterao brusca do que j havia sido analisado anteriormente, as alteraes foram sutis, mas poderiam estender a arquitetura.

6.4.2.3. Resultados Obtidos

Tanto o arquiteto quanto a equipe responsvel pelo desenvolvimento do Editor estavam mais estressados no momento de refazer a arquitetura e experimentar as prticas e AR de SMs. A preocupao foi uma ameaa prevista, pois poderia atrapalhar a averiguao das variveis, uma vez que conduziria a equipe a um cuidado maior na segunda rodada de experimentao com a metodologia de SMs, fazendo os resultados da mesma sofrerem influncia. De fato todos estavam mais seguros quanto aos requisitos e aos problemas da aplicao; isto pode ser uma desvantagem para o objeto de controle; mas pode tambm ser um forte indcio de sua feliz aplicabilidade, sendo que, mesmo a equipe estando com um nvel de estresse mais elevado, foi possvel que uma arquitetura mais adequada fosse definida. O Editor uma Mquina Social completa e repleta de particularidades que podem no se repetir em outras SMs. Mesmo assim, ele uma SM por ser uma palicao Web que pode ser incorporada outra aplicao com a finalidade de suprir alguma funcionalidade no existente na mesma. Por exemplo: o Editor se incorpora ao sistema de Pronturio de Pacientes com a finalidade de produzir telas com entrada, processamento, e sada de dados. Ou seja, funcionalidades no existentes no PEP, como o clculo e armazenamento da massa corporal de um paciente. Mais importante do que construir uma SM por meio das prticas e da arquitetura de referncia foi a experincia e o entendimento dos conceitos das Mquinas Sociais. Os participantes demonstraram a necessidade de conhecer esses conceitos para que as prticas fossem aceitas e fizessem sentido. Foi possvel registrar que o entendimento da arquitetura de referncia fez a equipe do Editor notar a forte necessidade de se ter uma camada Wrapper dedicada apenas aos servios providos e requeridos. Tal camada deveria ter componentes dedicados a cada sistema no qual o Editor deveria interagir. Alem disto, na MV no existia a prtica de formular um documento de deciso arquitetural no qual a arquitetura seria baseada, isto certamente ocasionava alguns 137

Captulo 6. Experimentao das Prticas

retrabalhos em determinada fase do desenvolvimento, o que no houve com a adoo das prticas e da arquitetura de referncia. Ainda por meio do acompanhamento direto do projeto Editor e tambm do conhecimento a respeito de outros desenvolvimentos na MV, foi possvel fazer uma anlise e notar o que foi obtido por meio da adoo das propostas para concepo de arquiteturas para SMs: Visualizar facilmente a importncia de se escrever as decises de projeto. Na verdade, as decises do projeto Editor foram geradas pelas prticas das SMs em si; Verificar a necessidade da modelagem de negcio, pois esta fase geralmente omitida em alguns projetos de software da MV. Deste modo, a definio de como alguns servios seriam providos foi deficitria, obrigando a equipe a modelar alguns processos de negcio; Os problemas de integrao entre Editor, MVPEP e o MVSOUL foram descobertos no momento da anlise arquitetural, e no no momento da integrao, como ocorreu quando no foram utilizadas as prticas e AR; as prticas 343, 544 e 745 contriburam fortemente para isto; Os padres de projeto mais adequados s SMs foram estudados. Apesar da equipe responsvel ter grande experincia com Design Pattern, os padres foram classificados com a prtica 9, proporcionando uma adoo mais rpida, e demonstrando muita eficincia para o Editor, como o caso do padro Adapter; A fase de definio de arquitetura foi desenvolvida resultando em uma documentao til manuteno do Editor, sem, no entanto, ter levado muito tempo para ser completada; As facilidades que Cloud Computing poderiam trazer ao desenvolvimento do Editor foram notadas. Entretanto, para a MV, os recursos de CC ainda algo fora da

43 44

Prtica 3: Conhecer os provedores de servio da aplicao. Prtica 5: Determinar os recursos que implementaro os elementos States e Constraints. Prtica 7: Determinar o recurso que prover a comunicao e interoperabilidade.

45

138

Captulo 6. Experimentao das Prticas

realidade. No entanto, houve o entusiasmo por parte da equipe e mesmo de alguns gestores em conhecer mais os benefcios dos recursos Cloud; A equipe de desenvolvimento pde conhecer mais dois produtos da MV de extrema relevncia que o MVSOUL e o MVPEP. Alm disto, puderam verificar que questes relevantes para as SMs no so devidamente tratadas nesses sistemas, como exemplo: a disponibilidade. Isto j preparou melhor a equipe para futuros problemas. As primeiras prticas, sobre servio, ajudaram fortemente neste avano; O trabalho de definio de interface e design grfico para o Editor foi preciso, pois as informaes adquiridas dos servios providos e da integrao com os sistemas puderam contribuir para que os designers descobrissem os problemas de usabilidade que poderiam surgir; As demais ameaas previstas infelizmente ocoreram. Como explorado na execuo, as prticas e AR de SMs foram experimentadas em desenvolvimentos que ocorreram aps o desenvolvimento dos mdulos sem as prticas e AR (sem alteraes). Com isto, por falta de tempo, de pessoas, e at mesmo por uma evoluo do conhecimento a respeito de como proceder o estudo, no foi possvel dividir a equipe e executar simultaneamente a modelagem da arquitetura com o objeto de controle e sem o objeto de controle. Assim, a equipe j estaria mais preparada para o problema de software a enfrentar; mas, isso no inviabilizou o estudo, uma vez que as exigncias foram maiores em virtude do descontentamento da primeira arquitetura, alm disto, alguns requisitos foram alterados e eram desconhecidos pela equipe. Devido s ameaas, infelizmente algumas prticas no puderam ser aproveitadas. A adoo do Framework de SMs, por exemplo, no foi possvel por no haver tempo hbil para desenvolv-lo. No entanto, houve a percepo por parte de toda equipe, que tal recurso seria interessante. Inclusive as prticas construram um roteiro no qual a equipe de desenvolvimento no tinha visibilidade, pois as demandas de desenvolvimento so muitas, alm de serem complexas e de curto prazo, prejudicando por vezes o desenvolvimento organizado. Apesar das ameaas, as prticas guiaram a equipe a focar em pontos chaves para o desenvolvimento eficaz da Mquina Social, pontos que nem sempre foram tratados pela prpria empresa. As prticas 5 e 7 so exemplos disto. Por meio da aplicao do objeto de controle foi possvel que a equipe visualizasse o projeto Editor como de fato um projeto de 139

Captulo 6. Experimentao das Prticas

Mquina Social por todos os aspectos da aplicao, sobretudo, a comunicao e adaptabilidade aos sistemas da MV. Outro ponto que tambm negligenciado e que foi visualizado e compreendido pela equipe foram as regras de negcio, em que a primeira prtica solicita a modelagem de alguns processos que atenderam aos servios. A MV no pensa em servios na hora de construir suas aplicaes, assim, a modelagem do negcio geralmente era afetada e gerava retrabalho. Para o projeto Editor este erro no ocorreu. Entretanto, a MV ainda precisa estar atenta a todos os outros projetos de desenvolvimento espalhados pelas equipes que compem a fbrica. Sendo assim, no ltimo perodo do ano de 2011, a empresa constituiu uma equipe de analistas de negcios e gerentes de produtos justamente pensando em melhorar a concepo de seus servios. O experimento contribuiu fortemente para este pensamento. Duas outras aes que podem ofertar grande potencial ao desenvolvimento da MV surgiram por meio deste experimento com o Editor: a melhoria no processo de gerncia de configurao com a adoo da ferramenta Maven46; e o estudo de plataformas como o Open Services Gateway Initiative - OSGi que contribui para o desenvolvimento de aplicativos modulares e orientados a servios (OSGi ALLIANCE, 2005 ). Muitas aes ainda podem ser geridas para ajudar o trabalho da MV. A utilizao das prticas e da AR auxiliou a equipe do Editor e motivou a MV a utilizar mais vezes tal objeto em Mquinas Sociais que possam fazer parte do nicho de negcio da empresa. Alm disto, este estudo mostrou a este trabalho de arquitetura e SMs, como alguns assuntos ainda so pouco explorados na realidade da indstria de software local. Uma evidncia disto foi revelada pela prtica 8. A prtica 8 sobre Cloud Computing mostrou a realidade no s da MV, mas talvez de muitas outras empresas e fbricas de software em relao CC. Na MV, so poucos os profissionais habilitados a trabalhar com Cloud Computing. Alm disto, a empresa no tem nenhuma ao ou planejamento para empregar tal paradigma nos projetos atuais e futuros do portflio da empresa.

46

Maven uma ferramenta que controla a entrega de cdigos funcionais, com isto ele proporciona o gerenciamento e a automao de projetos de software [SONATYPE, 2008].

140

Captulo 6. Experimentao das Prticas

Por fim, o caso Editor agregou muito conhecimento equipe responsvel, mostrando indcios de que o projeto longo e muito ainda deve ser feito para que o Editor seja uma Mquina Social excelente; os problemas apresentados ao final do experimento com as prticas e AR de SMs foram no requisito de usabilidade. No entanto, tal SM se saiu bem nas etapas de teste de software e validao do produto entre os clientes. Uma primeira verso do produto j ser homologada em meados de maio de 2012.

6.5. CONSIDERAES FINAIS DO CAPTULO A real contribuio e utilidade da proposta deste trabalho para SMs proporcional ao nvel de conhecimento que um desenvolvedor de software tem sobre o conceito de SMs. Neste momento, no basta conhecer a teoria e compreender as caractersticas de SMs, mas sim, amadurecer tal paradigma de forma que seja possvel entender aplicaes Web como Mquina Social para proceder a sua construo acima dos conceitos de SMs. O estudo de caso foi sobre uma equipe atrelada a mtodos j tradicionais de desenvolvimento e tecnologias impostas pela prpria empresa, onde esses profissionais esto familiarizados aos recursos disponveis. O projeto piloto foi aplicado sobre o desenvolvimento de um s profissional repleto de novas idias que circulam o conceito de Mquina Social, conceito ao qual esse profissional j est habituado. Ficou ntida a contribuio das prticas no estudo de caso, dos 7 (sete) problemas detalhadamente pontuados na problemtica desta pesquisa, foram resolvidos 5 (cinco) para o Editor da MV. Alm disto, atravs do experimento um nmero significativo de idias surgiram dentro da empresa. Os seguintes problemas dentro do projeto Editor foram resolvidos por meio do uso das prticas e da arquitetura: Interoperabilidade e depedncia entre os servios das SM; Manutenes demoradas; Requisitos mal trabalhados; Ausncia da arquitetura; Falta de adequao da SM na resoluo de problemas.

141

Captulo 6. Experimentao das Prticas

Esta experimentao fez com que a equipe da MV enxergasse o produto Editor de formulrios/telas como uma verdadeira plataforma de servios pronta para ser transplantada entre os grandes e complexos sistemas da empresa, neste contexto, as prticas e arquitetura de referncia, em seu conjunto de conceitos, revelou sua real contribuio. Demais consideraes sobre este experimento sero publicadas na concluso do trabalho que vem em seguida.

142

Captulo

7. Concluses e Trabalhos Futuros


O objetivo de tal captulo apresentar um desfecho sobre a dissertao como um todo. Vale ressaltar que muitas consideraes j foram abordadas nos tpicos conclusivos de cada captulo. Aqui estaro algumas reflexes finais sobre o trabalho, especialmente a sua contribuio, e as indicaes dos futuros trabalhos.

143

Captulo 7. Concluses e Trabalhos Futuros

Ao fim dessa pesquisa, muitas questes se destacam e sero pontuadas no decorrer desta considerao final. Primeiramente a abordagem de conceber aplicaes WEB como SM se mostrou adequada por dois motivos: primeiro, possibilitar que dois desenvolvimentos de SMs focassem em pontos fundamentais para as SMs, pontos que nem sempre possuam a devida ateno. Segundo por esclarecer que, atravs de SMs, seja possvel reinventar projetos em rede, possibilitando que outros servios sejam criados e problemas antigos sejam tratados. Para exemplificar esta idia, vale tomar nota do web site chamado Empresa Teia47, um projeto puramente brasileiro coordenado por Oswaldo Oliveira, o qual classifica a Empresa Teia48 como:
A empresa teia uma infraestrutura completa para quem quer desenvolver um projeto em rede. Tem como misso oferecer solues que viabilizem a evoluo sustentvel de quem quer articular, fazer negcios ou trabalhar em rede. Conecta pessoas, instituies e empresas que querem se integrar nos fluxos da sociedade em rede independentemente do nvel de maturidade em que esto. Faz isto utilizando ferramentas, servios, processos, ambientes e conexes disponveis na nuvem computacional da internet.

A Empresa Teia conecta as pessoas de modo que elas possam prestar servios concomitantemente utilizando a Web 2.0 e 3.0 para isto. Este projeto j mostrou a sua fora, principalmente no momento em que o Estado de Minas Gerais resolveu contratar49 a Empresa Teia para estruturar um ambiente em rede que pudesse auxiliar o desenvolvimento sustentvel do Estado, levando, por meio da Internet, servios s reas remotas da circunscrio. Neste ponto, o projeto Teia, alm de inovador, materializa o negcio que envolve as Mquinas Sociais; a prpria pgina online do projeto Teia uma SM. Atravs dela possvel disponibilizar Apps teis pessoas ou empresas que faam parte da rede Teia. Isto , promover o negcio de SM. Portanto, cabe aqui concluirmos que as abordagens tecnolgicas de SMs talvez no sejam to inovadoras, o que moderno a forma de se pensar e usar tal

47 48 49

http://empresateia.com.br/ http://smeira.blog.terra.com.br/2010/12/08/empresa-teia-como-assim-final/ http://teiamg.com.br/

141

Captulo 7. Concluses e Trabalhos Futuros

aparato tecnolgico para servios que podem ser distribudos em rede. A partir desse ngulo, esta dissertao se mostra totalmente relevante, especialmente por focar em adaptaes no modo de usar a tecnologia para se construir Mquinas Sociais para assim poder promover negcios modernos e lucratios. clarividente que h muito para se evoluir no conceito de SMs, sobretudo, nos aspectos voltados Cloud Computing e nas questes de segurana, tanto das SM, quanto das informaes geradas por elas. Outro ponto importante a manuteno das SMs, que no deve ser burocratizada. Para atender a este requisito o uso de Cloud Computing fortemente indicado na concepo das SMs. Porm todos os profissionais envolvidos devem entender melhor o que CC. Quanto segurana, Mquinas Sociais so aplicaes distribudas em rede. O acesso a elas deve ser facilitado. Por esse motivo e outros, a segurana continua sendo um ponto a ser vigorosamente pesquisado e trabalhado. Um exemplo disto pode ser detectado no estudo de caso da empresa MV, onde surge a preocupao no compartilhamento de documentos e, mormente no contedo que leva cada documento, vez que alguns trabalham com informaes confidenciais e delicadas a um paciente. O pargrafo supra remete aos trabalhos futuros; nestas concepes futuras h espao para experimentar em mais projetos as solues propostas. Vale salientar que, para esta pesquisa, houve certa dificuldade em se encontrar projetos de SM que se pudesse acompanhar a evoluo. Com mais estudos de caso ser possvel verificar pontos que possam ser amadurecidos na metodologia e no prprio conceito de SM, mais do que isto, ser possvel divulgar e empregar fortemente o Framework de SM. Realisticamente o framework requer um trabalho forte de implementao e documentao, possibilitando assim, a disseminao do uso do mesmo. Disseminar as prticas em trabalhos futuros poder tambm revelar outros benefcios em desenvolvimento de SM. Nesta dissertao as prticas se revelaram como forte contribuio para a resoluo de alguns problemas j citados, e principalmente para agregar qualidade ao processo de desenvolvimento. Neste ponto os valores revelados pelo experimento no so to importantes quanto os benefcios qualitativos que comearam a ser pontuados na pgina 136. A viabilidade desta idia pode inclusive consolidar a proposta da arquitetura de referncia. 142

Captulo 7. Concluses e Trabalhos Futuros

Para a construo da arquitetura, os conceitos e exemplos de Mquina Sociais foram detalhadamente enunciados em um captulo. Houve certa dificuldade em se detalhar a arquitetura, pois, o escopo de Mquinas Sociais teria que ser bem mais delimitado. Para a arquitetura de referncia, cabem outras pesquisas com mais tempo de desenvolvimento e amadurecimento de conceitos de modo que seja possvel vislumbrar um tipo de arquitetura para cada tipo de Mquina Social, mediante, se possvel, a taxonomia das mesmas. Apesar desta necessidade, vale enfatizar que o estudo de caso deste trabalho aplicou bem a arquitetura de referncia proposta, adaptando a mesma. Para tal arquitetura, a avaliao por meio de Checklist se mostrou eficiente e apta a ter seu modelo replicado em outros estudos. A arquitetura de referncia foi testada e concebida para atuar em SMs que sejam aplicaes WEB. Foi possvel acompanhar por meio da execuo da avaliao da arquitetura de SMs como o mtodo foi incrementado com a insero de rodadas avaliativas, e com a estratgia de repetir apenas um avaliador entre as rodadas. O Checklist com os itens de questionamento que avaliaram diferentes aspectos da arquitetura tambm foi customizado. Sua alterao foi necessria para que cada item estivesse mais adequado ao que se desejaria avaliar da arquitetura. Deste modo, houve muito enfoque nas questes de requisitos no funcionais por tratar-se de uma arquitetura de referncia. Entretanto, a customizao do checklist j era algo tratado nas pesquisas utilizadas como referncia para este trabalho. A interpretao dos itens de questionamento tambm foi uma novidade ao mtodo, a tabela 4 foi um instrumento para evitar as dvidas dos avaliadores. claro que a resposta esperada para cada item no foi revelada, mais sim, o que cada item pretendia avaliar. Vale esclarecer que a excluso da contabilidade do item 4 (quatro) algo absolutamente particular do caso de uso exibido para o mtodo. O item 4 (quatro) pode ser reescrito em outros checklists, ou pode ser desconsiderado a partir do momento em outro item investigue a mesma problemtica ou aspecto na arquitetura A outra avaliao ao qual esse trabalho foi submetido foi o estudo de caso. Ele mostrou que mais fcil pensar em SM quando se est vinculado totalmente ao conceito de SM. A empresa que cedeu a unidade experimental percebeu o novo desenvolvimento de aplicaes que estava se instalando em sua fbrica. Contudo, cabe aqui mais uma vez enfatizar que o processo de evoluo dos negcios em rede est em uma interao ainda 143

Captulo 7. Concluses e Trabalhos Futuros

primria para empresas tradicionais de TI extremamente amarradas a fatores, como: presso organizacional e poltica empresarial. A experimentao auxiliou na identificao de problemas no conjunto de prticas, problemas voltados ausncia de questes de banco de dados. Aproximar esse conjunto de prticas aos padres IEEE citados outro trabalho que poder ser amadurecido futuramente e que no demanda muitos esforos. O estudo experimental foi muito proveitoso, apesar de ser exploratrio, onde no se conhecia exatamente os efeitos do experimento, e tambm apesar das ameaas a validade terem sido reais. O mais importante, e o que de fato valida o estudo, foi o mesmo ter tido um planejamento e ser documentado no formato adequado; e principalmente pelo motivo da empresa ter acreditado no experimento, e enxergar ganhos qualitativos com as prticas e arquitetura propostas. O experimento possibilitou a resoluo de alguns problemas a partir do momento em que auxiliou na identificao dos servios, proporcionando melhorias na interoperabilidade, e na manuteno das aplicaes que deveriam ser interligadas. Entretanto fica a necessidade de se replicar o experimento como trabalho futuro. Com isto, possvel aproveitar o planejamento e formato do estudo, com todas as suas sees, em outros trabalhos. Por fim, este trabalho amadurece todos os conceitos relacionados a SM, particularmente os relacionados ao modelo de desenvolvimento de Mquinas Sociais. Sendo assim, o objetivo foi alcanado ao passo que contribui para o desenvolvimento de ao menos uma Mquina Social real, com idias modernas, capazes de manter a evoluo dos negcios, proporcionando o amadurecimento na concepo de sistemas Web 3.0.

144

Referncias Bilbiogrficas

REFERNCIAS BIBLIOGRFICAS
ABINADER, Jorge; LINS, Rafael. Web Services em Java. 1.ed. So Paulo: Brasport, 2006. 316.p. AFRAM, Abel. Twitter, uma arquitetura evoluindo. 2009. http://www.infoq.com/br/news/2009/07/Twitter-Architecture. Acesso em: 20. ago. 2010. Disponvel em:

AMAZON PRODUCTS & SERVICES. Informaes especializadas sobre o servico EC 2 da Amazon. Disponvel em: http://aws.amazon.com/ec2/. Acesso em: 21 nov. 2011. ARNOLD, Ken; O'SULLIVAN, Bryan; SCHEIFLER, Robert; WALDO, Jim; Wollrath, Ann. The Jini Specification. 1 ed. Addison-Wesley, 2009. APIWIKI. Apresenta informaes especializadas sobre o desenvolvimento de aplicativos por meio da plataforma Twitter. Disponvel em: http://apiwiki.twitter.com/. Acesso em: 20. ago. 2010. AZEEZ, Afkham; PERERA, Srinath; GAMAGE, Dimuthu; LINTON, Ruwan; SIRIWARDANA, Prabath; LEELARATNE, Dimuthu; WEERAWARANA, Sanjiva; FREMANTLE, Paul. Multi-Tenant SOA Middleware for Cloud Computing. 2010. In IEEE 3rd International Conference on Cloud Computing. Disponvel em: http://www.computer.org/portal/web/csdl/doi/10.1109/CLOUD.2010.50. Acesso em: 12 dez. 2010. BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 2 ed. USA: AddisonWesley, 2003. BERNERS-LEE, Tim; HENDLER, James; LASSILA, Ora. The semantic Web. 2001. Scienti_c American, pages 35{43. Disponvel em: < http://www.sims.monash.edu.au/subjects/ims2603/resources/week9/9.1.pdf>. Acesso em 10 jul. 2011. BENSLIMANE, Djamal; DUSTDAR, Schahram; SHETH, Amit. Services Mashups: The New Generation of Web Applications. 2008. In Internet Computing, IEEE. Disponvel em: < http://dl.acm.org/citation.cfm?id=1439253>. Acesso em: 01 mai. 2011. BOEHM, Barry; BASILI, Vic. Software Defect Reduction Top 10 List, IEEE Computer , v. 34, n.1, pp. 135-137, 2001 BOYD, Danah; ELLISON, Nicole. Social Network Sites: Definition, History, and Scholarship. 2007. In Journal of Computer-Mediated Communication. Disponvel em: < http://onlinelibrary.wiley.com/doi/10.1111/j.1083-6101.2007.00393.x/full> Acesso em: 01 mai. 2011. BEHRENDT, Michael; GLASNER, Bernard; KOPP, Petra; DIECKMANN, Robert; BREITER; Stefan; KREGER, Heather; ARSANJANI; Ali. IBM Cloud Computing Reference Architecture 2.0, 2011. In: IBM 2011. Disponvel em: < https://www.ibm.com/developerworks/mydeveloperworks/blogs/CLLotusLive/entry/ibm_cloud_computing_refer ence_architecture_what_is_in_for_me29?lang=pt_br>. Acesso em: 10 fev. 2011. BEZEMER, Paul; ZAIDMAN, Andy. Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare?, 2010. In IWPSE EVOL. Disponvel em: < http://www.st.ewi.tudelft.nl/~zaidman/publications/bezemerIWPSE2010.pdf> Acesso em: 09 jan. 2011. BELL, M. Modelagem Orientada ao Servio. 1. ed. Rio de Janeiro: Alta Books, 2008. 384 p.

141

Referncias Bilbiogrficas

BUDGEN, David; TURNER, Mark; BRERETON, Pearl; KITCHENHAM, Barbara.Using Mapping Studies in Software Engineering, 2008. In Proceedings of PPIG 2008, Lancaster University, pp. 195-204. Disponvel em: < http://www.ppig.org/papers/20th-budgen.pdf>. Acesso em: 11 nov. 2010. BUSCHMANN, Frank; MEUNIER, Regine; ROHNERT Hans; SOMMERLAD, Peter; STAL, Michael. Pattern Oriented Software Architecture. 1 ed. USA: John Wiley & Sons Ltda, 1996. BOURKE, Tony. Server Load Balancing, 1 ed: OReilly, 2001. 192 p. BEGINNING, Anderson. Flash, Flex, And Air Development For Mobile Devices. 1ed: Wrox Press, 2011. 336 p. BOOCH, Grady; RUMBAUGN, James; JACOBSON, Ivar. UML Guia do Usurio. 2 ed. Rio de Janeiro: Editora Campus, 2005. 474p. BREWER, Eric. Towards Robust Distributed Systems, 2000. In: Proc. of PODC, page 7. COMSCORE. Apresenta pesquisas especializadas em assuntos tecnolgicos. Disponvel em: <http://www.comscore.com/por/.acesso> Acesso em: 28 set. 2010. CRAGGS, Steve. Best-of Breed ESBS, 2004. In: GLOBAL EAI SUMMIT, Disponvel em: <http://www.sonicsoftware.com/products/whitepapers/docs/best_of_breed_esbs.pdf>. Acesso em: 12 nov. 2010 CHEESEMAN, John; DANIELS, John. UML Components: A Simple Process for Specifying ComponentBased Software. 2 ed: Addison-Wesley, 2001. COMPUTERWORLD. Site com informaes sobre o mercado de TI e comunicao. Disponvel em: http://computerworld.uol.com.br. Acesso em: 21 nov. 2011. CHODOROW, Kristina; DIROLF, Michael. Mongo DB: The Definitive Guide. 1 ed. Rio de Janeiro: OReilly, 2010. DISTRIBUTED MANAGEMENT TASK FORCE DMTF. Informaes especializadas sobre padres de interoperabilidade. Disponvel em:< www.dmtf.org>. Acesso em 14 set. 2010. ERL, Thomas. Service-Oriented Architecture: Concepts, Technology & Design. 2 ed: Prentice Hall, 2005. p. 792. EMPRESA TEIA. Possui informaes sobre o projeto TEIA. Disponvel em: http://empresateia.com.br/. Acesso em 01 set. 2011. ENDREI, Mark; ANG, Jenny; ARSANJANi, Ali; CHUA, Sook; COMTE, Philippe; KROGDAHL, Pl; LOU, Min; NEWLING, Tony. Patterns: Service-Oriented Architecture and Web Services, 2004. In RedbooksIBM.com. Disponvel em:< http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf> Acesso em: 05 mar. 2010. FACEBOOK DEVELOPERS. Apresenta informaes sobre o desenvolvimento de Aplicaes por meio do Facebook. Disponvel em: <http://developers.facebook.com/>. Acesso em: 23 set. 2010. FERREIRA, Kecia; BIGONHA, Mariza; BIGONHa, Roberto. Reestruturao de Software Dirigida por Conectividade para Reduo de Custo de Manuteno. In: RITA, Volume XV, numero 2, 2008. FORCE.COM. Guia do Programador da API de Servios Web da Force.com. Possui informaes sobre o desenvolvimento de aplicaes na Force.com. Disponvel em: http://www.salesforce.com/us/developer/docs/api/index.htm. Acesso em: 20 nov. 2011. FORRESTER RESEARCH, INC. Empresa americana especializada em fazer pesquisas sobre Tecnologia da Informao, novas tendncias ou descobertas. Disponvel em: <http://www.forrester.com/rb/research/>. Acesso: 1 nov. 2011. FREITAS, Fabricio; MAIA, Camila; COUTINHO, Daniel; CAMPOS, Gustavo; SOUZA, Jefferson. Aplicao de Metaheursticas em Problemas da Engenharia de Software: Reviso de Literatura, 2009. No II Congresso

142

Referncias Bilbiogrficas

Tecnolgico Infobrasil. Disponvel em: http://issuu.com/fabriciogf/docs/otimizacaoemengenhariadesoftware_surveypt> Acesso em: 11 abr. 2011.

<

GALBRAITH, Patrick. Developing Web Applications With Apache, Mysql, Memcached. 1ed: John wiley and Sons ltd. 2009. GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padres de Projeto: Solues reutilizveis de software orientado a objetos. 5 ed. So Paulo: Bookman, 2000. GORTON, Ian. Essential Software Architecture. 1ed. USA: Springe, 2006. 305 p. GOVERNOR, James; HINCH, Cliffe; DION, Nickeull; DUANNE Nickull. Web 2.0 Architectures. 1 ed. OReilly. 2009. 274 p. GARLAN, David; SHAW, Mary. An Introduction to Software Architecture, 1994. In CMU Software Engineering Institute Technical Report CMU/SEI-94-TR-21. Disponvel em: < http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf>. Acesso em: 02 nov. 2010. GARTNER, INC. (NYSE: IT). Web Site da empresa especializada em servios de tecnologia e pesquisa. Disponvel em: http://www.gartner.com/technology/about.jsp. Acesso em: 09 out. 2011. GOMES, Daniel. Web Services Soap em Java: guia pratico para o desenvolvimento de Web services em Java. 1.ed. S Paulo: NOVATEC, 2010. 184 p. HARMAN, Mark; JONES, Bryan. Search-based software engineering, 2001. In Information and Software Technology 43, pp. 833-839. Disponvel em: < http://www.inf.utfsm.cl/~mcriff/Paper-OR-SW/search-basedsw.pdf> Acesso em: 28 mar. 2011. HOFF. Facebook: an example canonical architecture for scalang billions of messages. Disponvel em: http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html. Acesso em 12 jun. 2011. HOFMEISTER, Christine: NORD, Robert: SONI, Dilip. Applied Software Architecture. 2ed. USA: Addison Wesley, 2000. HORN, Paul. Autonomic Computing: IBM Perspective on the State of Information Technology, 2001. Disponvel em <http://www.research.ibm.com/ autonomic/manifesto/ autonomic_computing.pdf>. Acesso em: 22 abr. 2011. IBM. An Architectural Blueprint for Autonomic Computing, 2003. Technical report IBM. Disponvel em: <http://www.research.ibm.com/ autonomic>. Acesso em 22 abr. 2011. IEEE STD 1471-2000. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. Sixth Edition. INTERNET WORLD STATS. Apresenta informaes especializadas sobre estatsticas e pesquisas feitas sobre a internet. Em: http://www.internetworldstats.com/stats.htm. Acesso: 01 ago. 2010 ISO/IEC 9126-1: 2000. Software engineering: Software product quality- Part 1: Quality Model. ISO/IEC 9126-2: 2000. Software engineering: Software product quality - Part 2: External Metrics. JACOBS, Dean. Enterprise software as service, 2005. In Queue, vol. 3, issue 6, p. 36. Disponvel em: http://dl.acm.org/citation.cfm?id=1080875. Acesso em: 30 mar. 2011.

143

Referncias Bilbiogrficas

JSON. Informaes especializadas sobre a ferramenta JSON. Disponvel em: <http://www.json.org>/. Acesso em: 13 abr. 2011. JOSUTTIS, Nicolai. SOA na Prtica: A Arte da Modelagem de Sistemas Distribudos. 1ed. Rio de Janeiro: Jacar, 2007. JURISTO. Natalia; MORENO, Ana. Basics of Software Engineering Experimentation. 2 Ed. USA: Kluweer Academic Publishers, 2001. JIANHONG, Z.; HUA, Chen (2010). Secuirty Storage in the Cloud Computing : A RSA-based Assumption Data Integrity Check without Original Data. In Conference ICEIT 2010.

LAITENBERGER, O; DEBAUD, Jean. Scenarios, Quality Attributes, and Patterns: Capturing and Using their Synergistic Relationships for Product Line Architectures. 1998. Kaiserslautern, Germany, Fraunhofer Institute Experimental Software Engineering.
LARMAN, Craig. Utilizando UML e padres: Uma introduo a anlise e ao projeto orientados a objetos. 3.ed. Rio Grande do Sul: Bookman, 2007. 696 p. LEAVITT, Ne. Will NoSQL Databases Live Up to Their Promise?. Computer, vol. 43, no. 2, pp. 12-14, Feb. 2010. LOPES, Christian; FRANS, Max; KAZI, Farzana; DONALDSON, Sylva; MORRIS, Quaid; BADER, Gary. Cytoscape Web: an interactive web-based network browser. 2010. In Bioinformatics (2010). Volume: 26, Issue: 18, Publisher: Oxford University Press, Pages: 2347-2348. Disponvel em: < http://bioinformatics.oxfordjournals.org/content/26/18/2347.short> Acesso em: 13 set. 2011. LIU, Yan; LIANG, Xin; XU, Lingzhi; STAPLES, M; ZHU, Liming. Using Architecture Integration Patterns to Compose Enterprise Mashups, 2009. In:WICSA/ECSA. Disponvel em:<http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F5275158 %2F5290660%2F05290797.pdf%3Farnumber%3D5290797&authDecision=-203> Acesso em: 03 mar. 2011. LIU, Sandy; LIANG, Yong; BROOKS, Martin. Eucalyptus: a Web service-enabled e infrastructure. 2007. In CASCON 07: Proceedings of the 2007 conference of the center for advanced studies on Collaborative research. Disponvel em: http://dl.acm.org/citation.cfm?doid=1321211.1321213. Acesso em: 10 jun. 2011. LIN, Jimmy; DYER, Chris. Data-Intensive Text Processing with MapReduce, 2010. In Morgan & Claypool Publishers. Disponvel em:< http://www.umiacs.umd.edu/~jimmylin/MapReduce-book-final.pdf>. Acesso em 09 jan. 2011. LAI, Eric. No to SQL? Anti-database movement gains team, 2009. In Computerworld. Disponvel em:<http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam>. Acesso em: 22 ago. 2011.

LAZZERI, Joo Carlos. Arquitetura Orientada a Servios. 1. ed. Rio de Janeiro: Editora Moderna, 2009. 229 p. LINTHICUM, David. Next Generation Application Integration: From Simple Information to Web Services.1 ed.USA: Pearson Education, 2004 MCPHERRON, Kate. Software-as-a-Service (SaaS): The New Paradigm for the Software Industry, 2008. Disponvel em: <www1.sao.org/Resource_Center/newsletter_articles/200802 /Kat_e_McPherron_Software_as_a_Service.php.> Acesso em: 01 jul. 2010. MERRIL, Duane. Mashups: The new breed of web app, 2003. Disponvel em:< http://www.ibm.com/developerworks/web/library/x-mashups.html> Acesso em: 07 mai. 2011.

144

Referncias Bilbiogrficas

MEIRA, Silvio. Empresa Teia? Como assim?. Dia a dia. Bit a bit. Blog do professor Silvio Romero de Lemos Meira, 8 dez. 2010. Disponvel em: http://smeira.blog.terra.com.br/2010/12/08/empresa-teia-como-assimfinal/. Acesso em 07 dez. 2011. MEIRA, S. R. L.; BUREGIO, V.; NASCIMENTO, L. M.; FIGUEIREDO, E. G. M.; NETO, M.; ENCARNAO, B.; GARCIA. The Emerging Web of Social Machines, 2011. IEEE 35th Annual Computer Software and Applications Conference (pp. 26-27). . Disponvel em: < http://goo.gl/YcIB6>. Acesso em: 01 mar. 2011. MELL, Peter; GRANCE, Tim. Draft NIST Working Definition of Cloud Computing. 2009. In National Institute of Standards and Technology. Disponvel em:< http://csrc.nist.gov/groups/SNS/cloud-computing>. Acesso em: 17 ago. 2011. MORAIS, EF; SOARES, MB. Web semntica para mquinas de busca. Disponvel em:<http://homepages.dcc.ufmg.br/~nivio/cursos/pa03/seminarios/seminario7/seminario7.pdf>. Acesso em: 04 out. 2010. MICROSOFT COMMUNITY BLOGS. Apresenta informaes especializadas sobre a Microsoft. Em: http://blogs.msdn.com/b/nick_wong/archive/tags/event+announcements/. Acesso em: 30 ago. 2010. MOTAHARI-NEZHAD, Hamid; STEPHENSON, Bryan; SINGHAL, Sharad. Outsourcing Business to Cloud Computing Services: Opportunities and Challenges, 2009. In HP Laboratories, HPL 23. Disponvel em: < http://www.hpl.hp.com/techreports/2009/> Acesso em: 21 fev. 2011. MCCANN, Julie; HUEBSCHER, Markus. Evaluation Issues in Autonomic Computing, 2004. In: Proceedings of Grid and Cooperative Computing Workshop, p. 597608. Disponvel em:< http://www.netlab.tkk.fi/opetus/s384030/k06/papers/EvaluationIssues.pdf> Acesso em: 27 jun. 2011. MULLER, Gerrit. Systems Architecting: A Business Perspective. 2011. 1 ed. 243 p. NAKAGAWA, E. Y. Uma Contribuio ao Projeto Arquitetural de Ambientes de Engenharia de Software. Tese de Doutorado, Instituto de Cincias Matemticas e de Computao, ICMC-USP/SoCarlos, 2006. NIST. Pgina da Agncia governamental de administrao da tecnologia. Disponvel em:< http:// http://www.nist.gov/index.html>. Acesso em 19 set. 2011. NETCRAFT.COM. Site que monta pesquisas e exibe estatsticas sobre a Internet e sobre aplicaes em geral. Disponvel em: <http://news.netcraft.com/> Acesso em: 14 nov. 2011 OBERHEIDE, Jon; COOKE, Evan; JAHANIAN, Farnam. (2008). Cloudav: N-version antivirus in the network cloud. 2008. In SS08: Proceedings of the 17th conference on Security symposium. Disponvel em <http://www.eecs.umich.edu/fjgroup/pubs/usenix08-cloudav.pdf>. Acesso em: 04 abr. 2011. OFFICIAL GOOGLE BLOG. Contm informaes especializadas sobre a Google Corporate em: http://www.google.com/intl/pt-BR/press/. Acesso 16 out de 2010. OREILLY, Tim. What is web 2.0, 2005. Disponvel em:<http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html> Acesso em: 15 jun. 2010. OSTENWALDER, Alexander; PIGNEUR, Yves; TUCCI, Christopher. Clarifying business models: origins, present, and future of the concept, 2005. In Communications of AIS, Volume 15, Article 1. Diponvel em: http://www.softwarepublico.gov.br/5cqualibr/6-publicacoes-e-artigos/view/vetor-ecossistema/sobre-modelo-deneg-cios/Claryfing-Busines-Model.pdf Acesso em 05 set. 2010. OSGI ALLIANCE. OSGi Service Platform Release http://www.osgi.org/Main/HomePage. Acesso em: 06 mai. 2011. 4. 2005. Disponvel em:

PERTERSEN, K. 2008. Systematic Mapping Studies in Software Engineering. In Proceedings of the 12 th Internacional Conference on Evalution and Assessment in Software engineering.

145

Referncias Bilbiogrficas

PETTICREW, M; ROBERTS, H. Systematic Reviews in the Social Sciences: A Practical Guide.


Blackwell Publishing, 2005.

2 ed.

PRESSMAN, Roger. Engenharia de Software: uma abordagem professional. 7 ed. So Paulo: Bookman, 2011. 780 p. PRESSMAN, Roger; LOWE, David. Web Engineering: A Practitioner's Approach. 1 ed. So Paulo: McGrawHill, 2008. PASCOE, Geoffrey. Encapsulators: A new software paradigm in Smalltalk-80, 1986. In Object-Oriented Programming Systems, languages, and Applications Conference Proceedings, pagina 341-346. Disponvel em: < http://dl.acm.org/citation.cfm?id=28731> Acesso em: 04 jun. 2011. RAILS. Informaes especializadas sobre a linguagem Rails. Disponvel em: <http://www.rubyonrails.pro.br/> . Acesso em: 14 abr. 2011 REZENDE, Denis Alcides. Engenharia de software e sistemas de informao. 3 ed. Rio de Janeiro: Brasport, 2005. REZENDE, Denis. Tecnologia da Informao Aplicada a Sistemas de Informao Enpresariais: O Papel Estratgico da Informao e dos Sistemas de Informao nas Empresas. 4 ed. So Paulo: Editora Atlas, 2006. 327.p ROSEN, Micael; LUBLINSKY, Boris; SMITH, Kevin; BALCER, Marc. Applied SOA: service-oriented architecture and design strategies. 1ed: Wiley Publishing, Inc. Canada, 2008. SHAW, Mary; GARLAN, David. Software Architecture Perspectives on an Emerging Discipline. 1 ed. So Paulo: Prentice-Hall, 1996. SOMMERVILLE, Ian. Engenharia de Software. 9 ed. So Paulo: Pearson, 2011. 568 p. SEVERINO. Antnio Joaquim. Metodologia do Trabalho Cientfico. 23 Ed. So Paulo: Editora CORTEZ, 2008. SONATYPE, Company. Maven: The definitive Guide. 1.ed: O Reilly, 2008.480 p. STERRITT, Roy; BUSTARD, David. Autonomic Computing- A Means of Achieving Dependability?, 2003. In: Proceedings OF IEEE International Conference ON THE Engineering Of Computer Based Systems (ECBS03), p. 247251. Disponvel em: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1194805. Acesso em: 21 abr. 2011. STONEBRAKER , Michael; Joseph, HELLERSTEIN. Readings in Database Systems. 4 ed: Morgan Kaufmann, 2005. SARATHY Vijay; NARAYAN, Purnendu; MIKKILINENI, Rao. Next generation Cloud Computing Architecture: Enabling real-time dynamism for shared distributed physical infrastructure, 2010. In WETICE '10 Proceedings of the 2010 19th IEEE International. TANENBAUM, Andrew. Distributed Systems: Principles and Paradigms. 1 ed. Prentice Hall, 2002. TANENBAUM, Andrew. Redes de Computadores. 4 Ed. Rio de Janeiro: Editora Campus, 2003. TAURION, Cesar. Cloud Computing: Coud Computing - Computaao em Nuvem: Transformando o Mundo da Tecnologia. 1. Ed. Rio de Janeiro: Editora Brasport, 2009. 228 pg. TRAVASOS, Guilherme; GUROV, Dmytro; AMARAL, Edgar. Engenharia de Software Experimental. Relatrio Tcnico, Universidade Federal do Rio de Janeiro, 2002.

146

Referncias Bilbiogrficas

TITTEL, Ed. Xml. 1ed. So Paulo: Bookman Editora, 2003. TIWARI, Shashank. Professional NoSQL. 1 ed. John Wiley & Sons, 2011. VECCHIOLA, Cristian; CHU, Xingchen; BUYYA, Rajkumar. Aneka: A Software Platform for .NET-based Cloud Computing, 2009. In: W. Gentzsch, L. Grandinetti, G. Joubert (Eds.). High Speed and Large Scale Scientific Computing. IOS Press. Disponvel em:< http://www.buyya.com/gridbus/reports/AnekaCloudPlatform2009.pdf> Acesso em: 22 mar. 2011. ZHANG, Liang-Jie; ZHOU, Qun. CCOA: Cloud Computing Open Architecture, 2009. In IEEE International Conference on Web Services. Disponvel em: http://www.cse.iitb.ac.in/~ashishpardhi/Papers/Cloud_computing/05175875.pdf. Acesso em: 01 set. 2010. Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises. Disponvel em: <http://www.kawaobjects.com/resources/PID1258479.pdf>. Acesso em: 09 mai. 2011. WEISSMAN. Craig. The Force.com Multitenant Architecture Understanding the Design of Salesforce.coms Internet Application Development Platform. In Salesforce com. 2010. Disponvel em: <http://www.salesforce.com/au/assets/pdf/Force.com_Multitenancy_WP_101508.pdf?fmSearch=true>. Acesso em: 20 jun. 2010. WEINHARDT, Christof; ANANDASIVAM, Arun; BLAU, Benjamin; BORISSOV, Nikolay; MEINL, Thomas; MICHALK, Wibke; STOBER, Jochen. Cloud Computing- a Classification, Business Models, and Research Directions, 2009. In Spring, 5 edition. Disponvel em:< http://www.springerlink.com/content/w3h62858jpkw56kh/>. Acesso em: 20 dez. 2010. WEI-TEK; Tsai; SUN, Xin; BALASOORIYA, Janaka. Service-Oriented Cloud Computing Architecture, 2010. In Seventh International Conference on Information Technology. Disponvel em:< http://xml.ice.ntnu.edu.tw/JSPWiki/attach/Focusardi/ServiceOriented%20Cloud%20Computing%20Architecture.pdf>. Acesso em: 09 jan. 2011. WAYNE, Jansen; TIMOTHY, Grance. Guidelines on Security and Privacy in Public Cloud Computing. NIST. Pgina da Agncia governamental de administrao da tecnologia. 11 de dezembro de 2011. Disponvel em:< http:// http://www.nist.gov/index.html>. Acesso em 19 fev. 2012. WHITE, Steve; HANSON, James; WHALLEY, Ian; CHESS, David; KEPHART, Jeffrey. Architectural Approach to Autonomic Computing, 2004. In: ICAC '04 Proceedings of the First International Conference on Autonomic Computing, p. 29, IEEE Computer Society. Disponvel em: <http://www.netlab.tkk.fi/opetus/s384030/k06/papers/AnArchitectureApproachToAutonomicComputing.pdf> Acesso: 20 set. 2011. KRUCHTEN, Philippe. The 4+1 View Model of architecture, 1995. In Software IEEE 12(6) 4250. Disponvel em: < http://dl.acm.org/citation.cfm?id=625529>. Acesso em: 20 out. 2010. KITCHENHAM, Barbara; BRERETON, Pearl; BUDGEN, David; TURNER, Mark; BAILEY, John; LINKMAN, Stephen. Systematic literature reviews in software engineering a systematic literature review, 2009. In Information & Software Technology 51(1), 715. Disponvel em:< http://dl.acm.org/citation.cfm?id=1466091> Acesso em: 18 abr. 2011. KOSSMANN, Donald; KRASKA, Tim; LOESING, Simon. An Avaluation of Alternative Architectures for Transaction Processing in the Cloud (2010). In Conference SIGMOD 2010. KLEIN, Mark; KAZMAN, Rick. Attribute-Based Architectural Styles, 1999. In CMU/SEI-99-TR-022 ESCTR-99-022 Software engineering institute. Disponvel em: <http://sophia.javeriana.edu.co/~cbustaca/DSBP/lecturas/AttributeBased%20Architectural%20Styles.pdf>. Acesso em: 06 mar. 2010.

147

Referncias Bilbiogrficas

KALIN, Martin. Java Web Services: Implementando. 1ed. Rio de Janeiro: OReilly. 2010. 312 p. KE, Xu; MEINA, Song; XIAOQI, Zhang; JUNDE, Song (2009). A cloud computing platform based on P2P. In conference ITIME 2009. WOHLIN. Claes; RUNESON, Per; HOST, Martin; OHLSSON, Magnus; REGNELL, Bjorn; WESSLEN, Anders. Experimentatio in Software Engineering an Introduction. 2 Ed. USA: Kluweer Academic Publishers, 2002. WEBBER, Jin; PARASTATIDIS, Savas; ROBINSON, Ian. REST in Practice: Hypermedia and Systems Architecture. 1 ed. Rio de Janeiro: OReilly, 2010. 448p.

148

Anexos

ANEXOS

ANEXO 1. PRTICAS DO PROJETO EDITOR MVPEP

Prtica 1: Modelar processos e sub-processos de negcio de servio

Prtica 2: Reconhecer os servios providos e requeridos para o funcionamento da Mquina Social 1. Servios Providos: a. Ajustar a aparncia de documentos e telas; b. Disponibilizar modelos de documento e telas formatados para os clientes; c. Processar dados especficos de um segmento hospitalar. 2. Servios Requeridos: a. Provimento de informaes especficas para se utilizar um documento, assim, necessrio saber se existe, e qual , a prescrio mdica que utilizar o documento; b. Registro de laudos de exames.

152

Anexos

Prtica 3: Conhecer os provedores de servio da aplicao Banco de dados Oracle que fornece os dados a serem processados pelo Editor, os dados esto registrados em tabelas diversas; Sistema MVSOUL (tecnologia Java/Flex/Web Service) onde os laudos so registrados; Sistema MVPEP por necessitar das informaes da prescrio mdica; Sistema MV2000, mdulo PAGU, para resgatar informaes de perguntas.

Prtica 4: Verificar a necessidade de recursos que tornem a aplicao auto-gerencivel e como esses recursos podem ser implementados A MV para este projeto no desenvolveu nenhum recurso que possa prover o autogerenciamento.

Prtica 5: Determinar os recursos que implementaro os elementos States e Constraints: No projeto Editor no ocorre a preocupao direta com tais elementos, mas algumas aes contribuem diretamente para a visualizao do estado do SM, bem como, a visualizao das caractersticas do mesmo, auxiliando na disponibilidade, e na comunicao. Tais iniciativas so: Utilizar Cluster de alta disponibilidade, viabilizados por meio de mecanismos de deteco e recuperao de falhas; Construir uma segunda camada intermediria (core_flex_service) para prover a interoperabilidade, tal camada possui mtodos (classes) especficas para customizar a aplicao no momento requerido, conforme o sistema que for utiliz-la; Uso do padro de projeto State; Implementar sensores na camada de persistncia que dispara um time a toda solicitao base de dados, caso a resposta demore, indcio de que algo aconteceu aos repositrios, e o Editor se prepara para acessar possveis backups.

Prtica 6: Analisar se apenas o estilo arquitetural Camadas suficiente para atender a Mquina Social: O estilo arquitetural Camadas ser aplicado na arquitetura em conjunto a outros estilos tambm empregados, entretanto, essa mescla s ocorreu na primeira camada da aplicao. Os estilos adicionais so: Pipes and Filters e Publisher-subscriber.

153

Anexos

Prtica 7: Determinar o recurso que prover a comunicao e interoperabilidade Web Services com REST para a comunicao com dispositivos mveis; Utilizar o recurso nativo do Adobe Flex, o AMF com auxlio do BlazeDS. O BlazeDS um servidor baseado em Java Remoting and Web Messaging, uma tecnologia que viabiliza a comunicao com o back-end distribudo de dados da aplicao. O BlazeDS pode ser utilizado com outras plataformas de cliente, como JavaScript e AJAX, ambas tecnologias exploradas pela MV. Inserir duas camadas de comunicao na arquitetura, estas iro prover a interoperabilidade entre o Editor os sistemas;

Prtica 8: Selecionar o recurso Cloud Computing a ser adotado na SM A MV ainda no utiliza o paradigma Cloud Computing em seus projetos, pois falta uma pesquisa adequada para verificar a viabilidade do uso deste novo paradigma na MV, bem como, do custo de adotar Cloud.

Prtica 9: Selecionar os padres de projeto mais adequados para a arquitetura da Mquina Social Padres mais utilizados: 1. Adapter: para adequar as interfaces de comunicao entre os sistemas; 2. Observer: para a gerncia dos estados entre os objetos; 3. State e Singleton.

Prtica 10: Selecionar o banco de dados no relacional No foi seguida ou executada

154

Anexos

ANEXO 2. PRTICAS DO PROJETO PILOTO HOBNOB

Prtica 1: Modelar processos e sub-processos de negcio de servio Tal diretriz no foi satisfeita para este projeto, o fluxo de negcio no foi algo tratado na concepo e anlise do HobNob, apesar de trabalhar com o conceito de servio o responsvel pelo desenvolvimento desta SM optou por trabalhar questes mais tcnica e no tanto de negcio.

Prtica 2: Reconhecer os servios providos e requeridos para o funcionamento da Mquina Social 1.Servios Providos: c. Sugerir festas e eventos musicais pela cidade de recife; d. Classificar os eventos: classificar os mais procurados, e os mais freqentados. 2.Servios Requeridos: e. Lista de amigos de rede social; f. Dados ou informaes das pessoas; g. Links: o que foi acessado, procurado ou visualizado nas redes sociais, e no Google Map.

Prtica 3: Conhecer os provedores de servio da aplicao 1. 2. 3. 4. Facebook; Google Map; Servidor de chat; Servidor de banco de dados.

Prtica 4: Verificar a necessidade de recursos que tornem a aplicao auto-gerencivel e como esses recursos podem ser implementados Usar de forma inteligente alguns recursos e tcnicas j populares na engenharia de software, afim de, prover o autogerenciamento: Usar o Framework de SM para obter tolerncia a falhas; Aplicar boas prticas de programao; Configurar bem o Apache para obter controle de log, e controle de sesso em banco de dados (segurana).

155

Anexos

Prtica 5: Determinar os recursos que implementaro os elementos States e Constraints: Usar o Framework para Mquinas Sociais, com o uso ser estabelecido nveis de qualidade e estabilidade para os servios, existem 5 nveis de estabilidade, estes se baseiam no tempo de resposta de cada solicitao, entre outros parmetros.

Prtica 6: Analisar se apenas o estilo arquitetural Camadas suficiente para atender a Mquina Social: Sim, apesar a arquitetura em camadas foi utilizada, houve uma customizao desta, alm da insero do Framework para Mquinas Sociais.

Prtica 7: Determinar o recurso que prover a comunicao e interoperabilidade WebServices com REST.; Adoo de Json.

Prtica 8: Selecionar o recurso Cloud Computing a ser adotado na SM Utilizar os servios da PaaS Rackspace, como: backup, SO Linux, balanceamento de carga, e armazenamento. Esta ofertou melhores opes em relao

ao valor cobrado, neste aspecto houve uma anlise dos provedores de servios CC para detectar qual o de melhor relao custo/benefcio.

Prtica 9: Selecionar os padres de projeto mais adequados para a arquitetura da Mquina Social Padres mais utilizados: State; Singleton; Facade.

156

Apndices

APNDICES

APNDICE A. CHECKLIST DE AVALIAO ARQUITETURAL VERSO 1

IDENTIFICAO Arquitetura a ser avaliada: Inspetor: Vises a serem avaliadas: mdulos, componentes e conectores, implantao Arquitetura de referncia para Mquinas Sociais

Item de Questionamento

SIM

NO

NO SE APLICA

Ao analisar todos os diagramas, foi identificado algum elemento arquitetural que no possua

relacionamentos, ficando isolado dos demais? 2 A descrio textual que compe o documento est de acordo com o que foi representado nos diferentes diagramas grficos? 3 Para todos os componentes, em algum diagrama, foram identificadas as classes ou sub-componentes que o compem? 4 Os relacionamentos realizados entre classes/subcomponentes alocados em componentes pais distintos foi definido como uma dependncia entre esses componentes pais em algum outro diagrama? 5 As interfaces so disponibilizadas por um nico componente/classe, ou representadas de uma forma

157

Apndices

mais simples no expandida? 6 Ao analisar todas as seqncias de execuo descritas em uma viso de interao, pode-se dizer que as classes/componentes definidas em uma viso

modular foram alocadas em ao menos uma das seqncias? 7 Todos os elementos arquiteturais tm a sua presena na arquitetura justificada por um conjunto de requisitos no funcionais ou funcionais? 8 As responsabilidades dos elementos arquiteturais esto condizentes com os requisitos no funcionais que eles atendem? 9 Tticas arquiteturais foram empregadas para

satisfazer os requisitos no funcionais? 10 Elementos relacionados possuem responsabilidades iguais que possam ser alocadas em um nico elemento? 11 Elementos intermedirios (ex: mquina virtual, servidor de nomes, repositrios, APIs) so utilizados como mediadores de comunicao entre os elementos arquiteturais, diminuindo o impacto das alteraes realizadas em elementos que podem ser

modificveis? 12 Foi verificado algum componente que exerca controle sobre o comportamento de outro elemento?

158

Apndices

APNDICE B. CHECKLIST DE AVALIAO ARQUITETURAL VERSO 2

IDENTIFICAO Arquitetura a ser avaliada: Inspetor: Vises a serem avaliadas: Observaes consideraes ou mdulos, componentes e conectores, implantao Arquitetura de referncia para Mquinas Sociais

Item de Questionamento

SIM

NO

NO SE APLICA

Ao analisar todos os diagramas, foi identificado algum elemento arquitetural que no possua

relacionamentos, ficando isolado dos demais? 2 A descrio textual que compe o documento est de acordo com o que foi representado nos diferentes diagramas grficos? 3 Para os componentes, em algum diagrama, foram identificadas as classes ou sub-componentes que o compem? 4 Os relacionamentos realizados entre classes/subcomponentes alocados em componentes pais distintos foi definido como uma dependncia entre esses componentes pais em algum outro diagrama? 5 As interfaces so disponibilizadas por um nico componente/classe, ou representadas de uma forma mais simples no expandida? Ou seja, ocorre uma representao por meio de diagrama de classes ou de componentes e conectores com interfaces requeridas

159

Apndices

e providas. 6 Ao analisar as seqncias de execuo descritas em uma viso de interao, pode-se dizer que as classes/componentes definidas em uma viso

modular foram alocadas em ao menos uma das seqncias? 7 Os elementos arquiteturais tm a sua presena na arquitetura justificada por um conjunto de requisitos no funcionais ou funcionais? 8 As responsabilidades dos elementos arquiteturais esto condizentes com os requisitos no funcionais que eles atendem? 9 Tticas arquiteturais foram empregadas para

satisfazer os requisitos no funcionais? 10 Elementos relacionados possuem responsabilidades iguais que possam ser alocadas em um nico elemento? 11 Elementos intermedirios como: mquinas virtuais, servidores de nomes, repositrios e APIs; so utilizados como mediadores de comunicao entre os elementos arquiteturais. 12 Foi verificado algum componente que exerca controle sobre o comportamento de outro elemento? COMENTRIOS:

DICAS:
Elementos arquiteturais devem ser entendidos como: Casos de uso, classes, camadas e demais componentes que constituem as vises arquiteturais.

160

Apndices

APNDICE C. VALORES MONITORADOS NO EXPERIMENTO

PARMENTROS

COM METODOLOGIA TRADICIONAL

COM METODOLOGIA DE SM 7

Nmero de requisitos da SM trabalhados pela arquitetura. Adequao concebida metodologia Social. da por arquitetura meio na

Mquina

OBS. O quantitativo de 4 (quatro) referente a todos os casos de testes que foram contemplados, ou seja, foram feitos 4 (quatro) casos de teste, para todos os quatro o resultado desejado foi atendido, assim, no houveram defeitos encontrados.

161

Apndices

APNDICE D. ARQUITETURA DE REFERNCIA ANTES DAS AVALIAES

162

Você também pode gostar