UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO CIN - CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

PRÁTICAS PARA A ESPECIFICAÇÃO DE ARQUITETURAS DE SOFTWARES NO CONTEXTO DE MÁQUINAS SOCIAIS PARA A WEB 3.0

POR

ELAINE GLEYCE MIRA DE FIGUEIREDO DISSERTAÇÃO DE MESTRADO

RECIFE
AGOSTO DE 2012

UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCO CIN - CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Elaine Gleyce Mira de Figueiredo

PRÁTICAS PARA A ESPECIFICAÇÃO DE ARQUITETURAS DE SOFTWARES NO CONTEXTO DE MÁQUINAS SOCIAIS PARA A WEB 3.0
Dissertação apresentada como requisito parcial para a obtenção do título de Mestre em Ciências da Computação, área de concentração em Engenharia de Software pelo Programa de Pós-Graduação em Ciências da Computação do Centro de Informática 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 agradeço a Deus e à Nossa Senhora de Nazaré por estarem presentes em nossas vidas nos dando saúde e luz. Muitos não sabem o que é concretizar um trabalho desta natureza, e talvez por este motivo não vejam com admiração 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 ciência por acreditarem justamente que trabalhos como este podem agregar na vida, no ensino, na indústria, e no saber; são 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 inquietação de sua mente, e por se fazer sempre presente mesmo que ausente. Ao meu também orientador Vinicius Garcia, pela exigência 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 condições de ensino oferecidas. Aos inteligentíssimos Prof. Leandro Marques, Prof. Paulo Borba, Prof. Sergio Soares, Vanilson Burégio, Misael Neto, e Thiago Vieira; pessoas que sempre estiveram dispostas a me ajudar, e que de forma direta, contribuiram para a realização deste trabalho. À empresa MV Informática Nordeste pela confiança.

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

“Não acredito em uma arquitetura ideal, insubstituível; somente em boa e má arquitetura. Gosto de Le Corbusier como gosto de Mies, de Picasso como de Matisse, de Machado como de Eça.” (Oscar Niemeyer)

"Nós raciocinamos hoje apenas em termos do que tornaria mais fácil para as pessoas a utilização do computador. Pode ser que tenha chegado a hora de perguntar o que tornaria mais fácil para o computadore lidar com seres humanos. Por exemplo: como é possível conversar com pessoas quando nem sequer se sabe que estão presentes? Você não pode vê-las, e nem sabe quantas são. Será que estão sorrindo? Falamos desejosos sobre interações humano-máquina, sistemas dialógicos e, no entanto, estamos dispostos a deixar no escuro total um dos participantes deste diálogo. Está na hora de fazer com que os computadores vejam e ouçam."

Tradução de trecho do livro “A vida digital” do ano 1995 (Nicholas Negroponte)

RESUMO
A Internet se modifica a uma velocidade considerável, e os responsáveis por tal transformação são, em grande parte, as aplicações que a compõem. O que conduz ao seguinte questionamento: os profissionais e pesquisadores de TI estariam suficientemente preparados para garantir soluções práticas e pertinentes ao desenvolvimento de tais aplicações? Esta dissertação consiste na recomendação de um conjunto de práticas para se desenhar arquiteturas de software no contexto de Social Machines, ou Máquinas Sociais (SM’s). SM’s são aplicações que se relacionam em rede para disponibilizar determinado serviço. O produto desta dissertação foi fruto de uma extensa pesquisa que se empenhou em fortalecer os conceitos de SM’s, bem como em desenvolver um estudo de revisão de literatura que serviu de alicerce para a proposta de uma arquitetura de referência para as SM’s. Isto posto, práticas foram lançadas afim de auxiliar na customização desta arquitetura e, principalmente, orientar sobre a construção de SM’s. Todos os conceitos abordados e resultantes foram fortemente baseados na realidade da Web 3.0, internet que traz alterações significativas ao modo de se fazer negócio em rede. O que caracteriza a Web 3.0 é a facilidade em reprogramar suas aplicações e fazer com que elas interajam de forma a interligar negócios, serviços e pessoas. No contexto da Web 3.0 as SM’ são protagonistas, tudo neste ambiente funciona por meio destas. Assim, o desenvolvimento desta pesquisa explora diversos conceitos dentro da engenharia de software, além de exibir duas avaliações dos artefatos de software gerados pelo trabalho, a primeira executada por meio de um método de inspeção, e a segunda por meio de um estudo de caso.

Palavras-Chave: Cloud Computing; Web 3.0; Máquinas Sociais; Arquitetura de Referência; Tecnologias; Aplicações Web; Práticas, Avaliações. 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). SM’s 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 SM’s 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 ILUSTRAÇÕES

FIGURA 1. REPRESENTAÇÃO DA ESTRUTURA DE CLOUD COMPUTING .................................. 16 FIGURA 2. REPRESENTAÇÃO DA MÁQUINA SOCIAL .................................................................... 17 FIGURA 3. ESTILO ARQUITETURAL CAMADAS .............................................................................. 28 FIGURA 4. NUMERO DE ESTUDOS POR QUESTÃO DE PESQUISA ................................................ 35 FIGURA 5. ARQUITETURA MASHUP POR DUANE MERRIL ........................................................... 37 FIGURA 6. ARQUITETURA CLOUD COMPUTING POR VECCHIOLA ............................................ 42 FIGURA 7. ARQUITETURA DE REFERÊNCIA PARA CLOUD COMPUTING POR KOSSMANN, KRASKA E LOESING, 2010. ................................................................................................................ 42 FIGURA 8. ARQUITETURA DE REFERÊNCIA CLOUD COMPUTING PROPOSTA PELA IBM ..... 44 FIGURA 9. ESBOÇO DA ARQUITETURA MULTITENANT ............................................................... 48 FIGURA 10. ARQUITETURA DO TWITTER......................................................................................... 50 FIGURA 11. ESBOÇO DE ARQUITETURA PARA SISTEMAS AUTÔNOMOS ................................. 54 FIGURA 12. ARQUITETURA DE REFERÊNCIA PROPOSTA PELA EMPRESA IBM PARA COMPUTAÇÃO AUTÔNOMA ............................................................................................................ 55 FIGURA 13. ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2.0 .............................. 57 FIGURA 14. RELAÇÃO ENTRE MODELO DE REFERÊNCIA, PADRÕES ARQUITETURAIS E ARQUITETURA DE REFERÊNCIA..................................................................................................... 65 FIGURA 15. ARQUITETURA DE REFERÊNCIA PARA SM’S ............................................................ 69 FIGURA 16. VISÃO DE IMPLANTAÇÃO .............................................................................................. 73 FIGURA 17. DIAGRAMA DE CLASSE (VISÃO DE MÓDULOS_WRAPPER E PROCESSING UNIT) ................................................................................................................................................................ 74 FIGURA 18. DIAGRAMA DE COMPONENTES: VISÃO DE COMPONENTES E CONECTORES ... 76 FIGURA 19. DIAGRAMA DE SEQUÊNCIA: VISÃO EM TEMPO DE EXECUÇÃO ........................... 77 FIGURA 20. RESULTADO DA AVALIAÇÃO (1ª E 2ª RODADA) ........................................................ 86 FIGURA 21. EXEMPLO DE MODELAGEM DE UM PROCESSO ........................................................ 95 FIGURA 22. REPRESENTAÇÃO DO FRAMEWORK DE COMUNICAÇÃO PARA AS SM’S ......... 104 FIGURA 23. ABSTRAÇÃO DA ARQUITETURA DE REFERÊNCIA (TECNOLOGIAS) ................. 124 FIGURA 24. EDITOR NO MODO DE CRIAÇÃO DE DOCUMENTOS NO MVPEP (VERSÃO 1.5) . 135 FIGURA 25. DOCUMENTO/TELA DO EDITOR SENDO UTILIZADO POR UM USUÁRIO FINAL NO MVPEP (VERSÃO 1.5) ................................................................................................................. 135

VIII

LISTA DE TABELAS

TABELA 1. CARACTERÍSTICAS E NECESSIDADES DAS SM’S ...................................................... 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 CARACTERÍSTICAS E NECESSIDADES DA SM. ............................................................................. 68 TABELA 5. QUESTÕES ANALISADAS PELO CHECKLIST E RESPOSTAS ESPERADAS ............. 85 TABELA 6. PADRÕES ESTRUTURAIS RELEVANTES PARA AS SM’S ......................................... 117 TABELA 7. PADRÕES COMPORTAMENTAIS RELEVANTES PARA AS SM’S ............................ 118 TABELA 8. RELAÇÃO ENTRE OS PADRÕES DE PROJETO E OS REQUISITOS NÃO FUNCIONAIS DAS SM’S ................................................................................................................... 118 TABELA 9. RELAÇÃO ENTRE AS PRÁTICAS E OS REQUISITOS NÃO FUNCIONAIS ............... 123

IX

LISTA DE ABREVIATURAS E SIGLAS

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

Social Machines Arquitetura de Referência Arquitetura de Software Plataform as a Service Software as a Service Infrastructure as a Service Prontuário Eletrônico do Paciente Service-oriented Architecture World Wide Web Cloud Computing Tecnologia da Informação Business Process Modeling Notation Aplicativos WEB Base de Dados Facebook
Web Service Definition Language

Pequenas e Médias Empresas Service Level Agreement

X

SUMÁRIO
RESUMO.................... ............................................................................................................. VI ABSTRACT…….. .................................................................................................................. VII LISTA DE ILUSTRAÇÕES ...................................................................................................... VIII LISTA DE TABELAS................................................................................................................. IX LISTA DE ABREVIATURAS E SIGLAS ........................................................................................

X

SUMÁRIO................................................................................................................................ XI

1. INTRODUÇÃO ....................................................................................................................... 1
1.1 APRESENTAÇÃO E CONTEXTO ................................................................................................................. 2 1.2. JUSTIFICATIVA E MOTIVAÇÃO DO TRABALHO ......................................................................................... 3 1.3 PROBLEMÁTICA ...................................................................................................................................... 5 1.4. OBJETIVOS: ............................................................................................................................................ 8 1.4.1. GERAL .............................................................................................................................................. 8 1.4.2. ESPECÍFICO ....................................................................................................................................... 9 1.5. TRABALHOS RELACIONADOS.................................................................................................................. 9 1.6. CONTRIBUIÇÃO E RESULTADOS ESPERADOS ......................................................................................... 11 1.7. ESTRUTURA DO TRABALHO .................................................................................................................. 11

2. MÁQUINAS SOCIAIS............................................................................................................ 13
2.1. O CONTEXTO DAS MÁQUINAS SOCIAIS .................................................................................................. 14 2.2. CONCEITO DE MÁQUINAS SOCIAIS ........................................................................................................ 17 2.3. CARACTERÍSTICAS DAS MÁQUINAS SOCIAIS ......................................................................................... 19 2.4. TAXONOMIA DAS MÁQUINAS SOCIAIS .................................................................................................. 21 2.5. EXEMPLOS DE MÁQUINAS SOCIAIS ....................................................................................................... 22 2.5.1. EUCALYPTUS: ................................................................................................................................. 22 2.5.2. CLOUD AV: ..................................................................................................................................... 22 2.5.3. MAP REDUCE: ................................................................................................................................. 23 2.5.4. WEB SEMÂNTICA: ........................................................................................................................... 24 2.6. CONSIDERAÇÕES FINAIS DO CAPÍTULO ................................................................................................. 25

3. REVISÃO DA LITERATURA DE

ARQUITETURAS DE SOFTWARE PARA MÁQUINAS SOCIAIS 26

3.1. INTRODUÇÃO ....................................................................................................................................... 27 3.2. ARQUITETURA DE SOFTWARE............................................................................................................... 27 3.3. PROCESSO DE REVISÃO......................................................................................................................... 30 3.3.1. QUESTÃO A SER INVESTIGADA: ...................................................................................................... 30

XI

3.3.2. QUESTÕES DE PESQUISA: ................................................................................................................ 31 3.3.3. REPOSITÓRIOS DE BUSCA................................................................................................................ 33 3.3.4. IDENTIFICAÇÃO DO MATERIAL ....................................................................................................... 33 3.3.5. CRITÉRIOS DE CLASSIFICAÇÃO - INCLUSÃO:................................................................................... 33 3.3.6. CRITÉRIOS DE CLASSIFICAÇÃO - EXCLUSÃO: .................................................................................. 34 3.3.7. REGISTRO DO MATERIAL ................................................................................................................ 34 3.3.8. RESULTADO.................................................................................................................................... 34 3.4. DEMONSTRAÇÃO DOS RESULTADOS DAS ARQUITETURAS DE REFERÊNCIA INVESTIGADAS ................... 36 3.4.1. ARQUITETURA DE REFERÊNCIA 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 REFERÊNCIA 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 REFERÊNCIA PARA SOFTWARE AS A SERVICE – QP2 .................... 47 3.4.4. ARQUITETURA PARA REDES SOCIAIS – QP3 .................................................................................... 49 3.4.5. ARQUITETURA DE REFERÊNCIA PARA SISTEMAS AUTÔNOMOS – QP4.............................................. 52 3.4.5.1. ARQUITETURA AUTÔNOMA PROPOSTA POR MCCANN, HUEBSCHER E WHITE ET AL .................... 53 3.4.5.2. ARQUITETURA AUTÔNOMA PROPOSTA PELA EMPRESA IBM ....................................................... 55 3.4.6. ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2.0 – QP5 ................................................. 56 3.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO – CRÍTICAS ............................................................................... 59

4. PROPOSTA DE ARQUITETURA DE REFERÊNCIA PARA MÁQUINAS SOCIAIS .................... 63
4.1. INTRODUÇÃO ....................................................................................................................................... 64 4.2. ARQUITETURA DE REFERÊNCIA ............................................................................................................ 64 4.3. ARQUITETURA DE REFERÊNCIA PARA MÁQUINAS SOCIAIS .................................................................... 66 4.4. VISÕES DA ARQUITETURA DE REFERÊNCIA ........................................................................................... 72 4.5. AVALIAÇÃO DA ARQUITETURA DE REFERÊNCIA E DE SUAS VISÕES ...................................................... 78 4.5.1. TÉCNICA DE INSPEÇÃO ................................................................................................................... 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 INSPEÇÃO (AVALIAÇÃO) .................................................................................... 81 4.5.1.4. CORREÇÃO DOS ERROS ENCONTRADOS ................................................................................... 81 4.5.2. RESULTADOS............... ................................................................................................................... 82 4.6. CONSIDERAÇÕES FINAIS DO CAPÍTULO ................................................................................................. 88

5. RECOMENDAÇÃO

DE

PRÁTICAS PARA DESENVOLVER ARQUITETURAS

DE

MÁQUINAS

SOCIAIS...................................................................................................................... 90
5.1. INTRODUÇÃO ....................................................................................................................................... 91

XII

5.2. PRÁTICAS NA METODOLOGIA PARA CONCEPÇÃO DE ARQUITETURAS E EM TRABALHOS RELACIONADOS ................................................................................................................................................................ 91 5.3. PRÁTICAS RECOMENDADAS.................................................................................................................. 93 5.3.1. PRÁTICA 1: MODELAR PROCESSOS E SUB-PROCESSOS DE NEGÓCIO DE SERVIÇO ............................. 94 5.3.2. PRÁTICA 2: RECONHECER OS SERVIÇOS PROVIDOS E REQUERIDOS PARA O FUNCIONAMENTO DA
MÁQUINA SOCIAL........ ............................................................................................................................. 95

5.3.3. PRÁTICA 3: CONHECER OS PROVEDORES E REQUISITANTES DOS SERVIÇO DA APLICAÇÃO .............. 97 5.3.4. PRÁTICA 4: VERIFICAR A NECESSIDADE DE RECURSOS QUE TORNEM A APLICAÇÃO AUTO
GERENCIÁVEL E COMO ESSES RECURSOS PODEM SER IMPLEMENTADOS. .................................................. 99

5.3.5. PRÁTICA 5: DETERMINAR OS RECURSOS QUE IMPLEMENTARÃO OS ELEMENTOS COMMUNICATIONS ,
CONSTRAINTS E REQUESTS ..................................................................................................................... 101

5.3.6. PRÁTICA 6: ADOTAR ESTRATÉGIAS PARA SANAR AS FRAQUEZAS DO ESTILO ARQUITETURAL
CAMADAS................................................................................................................................................104

5.3.7.

PRÁTICA

7:

DETERMINAR

O

RECURSO

QUE

PROVERÁ

A

COMUNICAÇÃO

E

A

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

5.3.8. PRÁTICA 8: SELECIONAR O RECURSO CLOUD COMPUTING A SER ADOTADO NA SM.................... 109 5.3.9. PRÁTICA 9: SELECIONAR OS PADRÕES DE PROJETO MAIS ADEQUADOS PARA A ARQUITETURA DA
MÁQUINA SOCIAL................ ................................................................................................................... 115

5.3.10. PRÁTICA 10: SELECIONAR O BANCO DE DADOS NÃO RELACIONAL ............................................. 119 5.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO ............................................................................................... 120

6. EXPERIMENTAÇÃO DAS PRÁTICAS ................................................................................. 125
6.1. INTRODUÇÃO ..................................................................................................................................... 126 6.2. DEFINIÇÃO DOS OBJETIVOS ................................................................................................................ 126 6.3. PLANEJAMENTO ................................................................................................................................. 128 6.3.1. OBJETO DE CONTROLE .................................................................................................................. 128 6.3.2. UNIDADE EXPERIMENTAL ............................................................................................................. 128 6.3.4. VARIÁVEIS INDEPENDENTES E DEPENDENTES ............................................................................... 129 6.3.5. RUÍDOS......................................................................................................................................... 130 6.3.6. CONTEXTO....... ............................................................................................................................ 130 6.3.7. SELEÇÃO DOS INDIVÍDUOS ........................................................................................................... 130 6.3.8. VALIDADE........ ............................................................................................................................ 131 6.4. EXECUÇÃO ......................................................................................................................................... 132 6.4.1. PROJETO PILOTO........................................................................................................................... 132 6.4.2. ESTUDO DE CASO EDITOR DE FORMULÁRIOS/TELAS – MVPEP ....................................................... 133 6.4.2.1. PREPARAÇÃO. ......................................................................................................................... 133 6.4.2.2. EXECUÇÃO..... ........................................................................................................................ 136 6.4.2.3. RESULTADOS OBTIDOS ........................................................................................................... 137 6.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO ............................................................................................... 141

7. CONCLUSÕES E TRABALHOS FUTUROS .......................................................................... 143 XIII

REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................................... 141 ANEXOS......... ...................................................................................................................... 152
ANEXO 1. PRÁTICAS DO PROJETO EDITOR MVPEP ...................................................................................... 152 ANEXO 2. PRÁTICAS DO PROJETO PILOTO HOBNOB .................................................................................... 155

APÊNDICES............................................................................................................................157
APÊNDICE A. CHECKLIST DE AVALIAÇÃO ARQUITETURAL – VERSÃO 1 ...................................................... 157 APÊNDICE B. CHECKLIST DE AVALIAÇÃO ARQUITETURAL – VERSÃO 2 ...................................................... 159 APÊNDICE C. VALORES MONITORADOS NO EXPERIMENTO ......................................................................... 161 APÊNDICE D. ARQUITETURA DE REFERÊNCIA ANTES DAS AVALIAÇÕES ..................................................... 162

XIV

Capítulo

1
1. Introdução
Este capítulo apresenta a dissertação com todos os seus elementos motivadores, e problemática envolvida, cada objetivo deste trabalho também é apresentado neste capítulo em conjunto a justificativa de se escolher a Web 3.0 como cenário para a pesquisa.

1

Capítulo 1. Introdução

1.1 APRESENTAÇÃO E CONTEXTO

A Internet vem alcançando números gigantescos, como exemplo, a quantidade de usuários apenas na América Latina chegar a aproximadamente 143 (cento e quarenta e três) milhões1. Os meios de acesso são variados, desde conexão banda larga até telefones celulares com tecnologia 3G. Os serviços também são diversos: ferramentas de buscas, blogs, sites empresariais, email, ferramentas de comunicação instantânea, comércio eletrônico, abreviadores de URL, ferramentas de programação e etc. Empresas públicas, privadas e governamentais trocam informações importantes pela Internet, vários paradigmas e tecnologias surgem em prol da mesma, além das transações bilionárias, como, por exemplo, a compra no valor de 1,65 bilhão de dólares do maior site de compartilhamento de vídeo, o YouTube, por uma das maiores empresas desenvolvedoras de serviços na rede que é a Google, fato ocorrido em 2006 (OFFICIAL GOOGLE BLOG, 2006). A Internet se caracteriza como um rico instrumento de comunicação, negócios, transações, propagandas e ensino. Sobre o aspecto tecnológico, o grande feito da Internet foi sua evolução, segundo o principal CEO da Force.com2, Marc Benioff, a Internet evoluiu de uma rede anteriormente classificada como Web 1.0, onde as informações somente poderiam ser visualizadas; para a rede programável, 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 física local, conceito aplicado por Marc Benioff. Enquanto a outra idéia classifica a Web 3.0 como a Web Semântica (BERNERS-LEE; HENDLER; e LASSILA, 2001). Independe da conceituação, a Web 3.0 mudou definitivamente o aspecto da Internet, transformando a mesma em algo mais interativo, inteligente e independente. É dentro desta temática da Internet programável, ou Web 3.0, que este trabalho estabelecerá suas bases. Trata-se de uma pesquisa que deseja ofertar soluções inteligentes para

1

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

Force.com é uma empresa de serviço Cloud Computing (Salesforce, 2010).

2

Capítulo 1. Introdução

problemas emergentes situados no modelo atual de negócios de TI, e principalmente da Web 3.0. No estudo serão propostas práticas para a construção da “célula” vital a todos os sistemas: a arquitetura. Por meio da mesma veremos porque é necessário pensar em Máquinas Sociais e não em meras aplicações Web.

1.2. JUSTIFICATIVA E MOTIVAÇÃO DO TRABALHO

Existe uma nova geração de aplicativos, isto fica evidente quando pensamos que os mesmos serviços disponibilizados pela rede mundial há 10 (dez) anos, agora são disponibilizados pela mesma rede com mais completitude e eficiência; um exemplo disto se vê na comparação da maior rede social do mundo, o Facebook - Fb, tendo mais de 700 (setecentos) milhões de usuários3, com o Sixdegrees, a primeira rede social do mundo, criada em 1997 que atingiu o máximo de 1 (um) milhão de usuários (BOYD, e ELLISON, 2007). O Sixdegrees foi descontinuado no ano de 2000, pois o projeto apresentou sérios problemas financeiros que foram causados pelos poucos acessos feitos pelos usuários. Tais usuários não se sentiram atraídos pela rede, não havia muito o que fazer após adicionar amigos, apenas trocar mensagens simples com os mesmos. Ou seja, o Sixdegrees não possuia bons recursos tecnológicos para se gerar e utilizar apps na rede, para assim, dispor funcionalidades interessantes aos usuários. Apesar dos pontos negativos, o Sixdegrees foi a primeira rede social a possibilitar a criação de um perfil virtual combinado com o registro e publicação de contatos, o que viabilizou a criação e navegação dos usuários por outras redes sociais que surgiram posteriormente, como o: Friendster, Ryze e Fotolog (BOYD, e ELLISON, 2007). Em contrapartida, o Fb é um serviço de alta disponibilidade que oferta desde ferramenta de conversação imediata até API Java4 para a reutilização de seus componentes por outras aplicações, ou seja, ele é uma rede social programável onde qualquer instituição, ou grupo de pessoas, pode formar sua própria rede semelhante ao Fb, fazendo uso apenas da API da própria rede social. O Fb fortaleceu consideravelmente a popularização das redes sociais.

3

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

em:

Informação disponível em: http://developers.facebook.com/. Acesso em 19 de jan. 2011.

3

Capítulo 1. Introdução

O trabalho dos usuários com estas redes é tão forte que uma pesquisa estatística 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 proliferação dos Mashups, que são aplicações Web constituídas de outras aplicações. Com os Mashups é possível ter uma combinação de serviços em um único aplicativo (BENSLIMANE, DUSTDAR, e SHETH, 2008). Um bom exemplo de Mashups são os sites de imobiliárias que inserem o serviço do Google MAP para que o usuário possa fazer a localização do imóvel nas ruas da cidade. Vale ressaltar que os Mashups personificam muito bem a comunicação e interação entre as aplicações Web. As aplicações contextualizadas a Web 3.0 adicionam mais funcionalidade a mesma, inovações ao seu desenvolvimento e facilidade aos negócios, tudo isto, a fim de atender aos modelos de negócio cada vez mais exigentes, com regras mais complexas. Dentro deste contexto a Internet desempenha um papel fundamental, ela além de instrumento, passa a ser provocadora de negócios, de inovações, e de junções empresariais. Relacionado aos negócios e as novas tecnologias da WEB 3.0 está o conceito de Computação nas Nuvens ou Cloud Computing - CC. A Web 3.0 apresenta o advento da CC, bem como, os serviços, plataformas de infraestrutura, e software sob demanda (WEISSMAN, 2010). Em se tratando de CC o Forrester Research Group6 publicou em Outubro de 2011 um relatório de análise das tecnologias emergentes que serão tendência na TI, especificamente nas arquiteturas de software, para os próximos anos até 2014. No relatório algumas das tendências são 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 questões ainda são desconhecidas, ou duvidosas, questões como:

5

Empresa que faz a mediação de vários aspectos da Internet, mostrando o comportamento de utilizadores da Web.
6

Disponível 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 Informação. Acesso em: 20 de mai. 2011

4

Capítulo 1. Introdução

segurança, compartilhamento de recursos, performance dos aplicativos, e a própria aplicabilidade dos serviços 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 prática ainda não foram totalmente desmistificadas. Até este ponto a motivação pela elaboração 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 parágrafos acima evidenciaram alguns jovens paradigmas que ainda carecem de pesquisas. As pesquisas devem partir do pressuposto de que aplicações Web são sistemas que se comunicam em rede, que exercem suas funções por meio desta e por meio da intervenção de outras aplicações. Isto faz estas aplicações serem Social Machines - SM’s, e é trabalhando acima deste conceito que será possível entender a Internet como um conglomerado de Máquinas Socias que precisa ser investigado para que ocorra uma melhoria no alinhamento de seus serviços ou relacionamentos. O trabalho por fim se justifica na necessidade de se explorar de forma científica a Internet no sentido de tentar explicá-la por um novo aspecto, o aspecto dos sistemas que são Máquinas Sociais que interagem na Web 3.0. Tal estágio da Internet vem vendo investigado e trabalhado justamente por ele possibilitar transações, interações e programação de aplicativos diretamente na plataforma Web, com o auxílio de uma infra-estrutura que é disponibilizada pela própria Web. Assim, aplicativos que estão sujeitos a trabalhar nessa realidade da Web devem ser concebidos de forma diferenciada.

1.3 PROBLEMÁTICA

A justificativa por si já sinaliza a existência de alguns problemas relacionados às aplicações que compõem a Web. Nesta seção os problemas serão pontuados mais fortemente. Em nossa atualidade existe uma tendência cada vez maior em se fazer negócios em escala global impulsionados por novas tecnologias, regras e relações de trabalho; isto traz um maior grau de complexidade aos negócios (REZENDE, 2006) e, sobretudo, aos sistemas computacionais que tendem a crescer em tamanho e complexidade vertiginosamente, sempre 5

Capítulo 1. Introdução

na tentativa de atender as demandas dos negócios (REZENDE, 2006). Entretanto, tal evolução não se limita aos sistemas Web e aos negócios. Tecnologias, processos, arquiteturas, serviços e padrões de desenvolvimento evoluíram com a Web e ajudaram a construir novos negócios. Ao passo que isto é positivo também é preocupante, pois a Web é caótica em diversos aspectos tecnológicos. Na verdade, ela passa a ser um emaranhado de códigos, padrões e protocolos que por vezes atrapalham o desenvolvimento das aplicações (HOFMEISTER, 2000) necessitando assim, de novas idéias e iniciativas que organizem, estruturem, e expliquem melhor o desenvolvimento de aplicações Web. A construção de sistemas está cada vez mais imersa na complexidade das inovações tecnológicas causadas pelo surgimento de novos frameworks, novas linguagens, e novos protocolos que surgem em um intervalo cada vez menor de tempo. A tendência também é em projetar sistemas que são cada vez mais dependentes da rede (BEHRENDT. et al, 2001). Neste aspecto, deve-se ter atenção a todos os detalhes dos sistemas a serem construídos. Assim, este trabalho se dedica a resolver problemas e questões delicadas à Web 3.0 programável, que pode ser caracterizada como uma moderna rede de computadores sociáveis e interoperáveis. As questões que serão resolvidas são:   Desenvolvimento de aplicações interoperáveis que estão cada vez mais entrelaçadas e dependentes dos serviços umas das outras. Desenvolvimento de software sob demanda, pois estes necessitam de uma arquitetura diferenciada, haja vista, muitos deles são desligados de um repositório físico para armazenamento; compartilhando tal repositório com outro software (AZEEZ et al., 2010).  O auto gerenciamento de sistemas Web que compartilham atividades com outros sistemas distribuídos na rede.

Além das questões pontuadas acima, esse trabalho também visa resolver problemas clássicos na construção de sistemas, que segundo estudiosos7, podem gravar o desenvolvimento de aplicações para a Web. Os problemas resolvidos serão:

7

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

6

Capítulo 1. Introdução

   

Manutenções demoradas e críticas dos sistemas; Requisitos mal trabalhados; Ausência da arquitetura; Ausência de uma estratégia de negócio que adeque aplicações Web à resolução dos problemas.

Projetos de aplicações Web estão suscetíveis aos problemas pontuados, uma vez que eles aconteçam, as iniciativas para saná-los devem ser precisas e rápidas. Dependendo da natureza do problema o projeto pode até ser descontinuado, apenas para exemplificar, este foi o caso de algumas ferramentas que desenvolvem Mashups, construídas por duas grandes corporações, 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 aplicação Web que contivesse alguns dos problemas pontuados acima. Alguns dos maiores problemas relacionados ao desenvolvimento de aplicações Web, que podem inclusive causar o fim de um projeto, são 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 codificação da aplicação (PRESSMAN, 2011) ou quando a mesma está desenvolvida. O processo de concepção de uma arquitetura é por vezes mal executado ou não executado (BASS, CLEMENTS e KAZMAN, 2003). Um exemplo clássico 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 decisões arquiteturais do Twitter não houve um raciocínio 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 aplicações Web distribuídas e conectáveis, ou seja, Máquina Social; isto ocorre não somente, mas principalmente, porque estas SM’s não são submetidas aos métodos ou

8

Informação disponível no OFFICIAL GOOGLE BLOG. Em: http://www.google.com/intl/pt-BR/press/. Acesso 16 out de 2010.
9

Informação disponível na MICROSOFT COMMUNITY BLOGS. http://blogs.msdn.com/b/nick_wong/archive/tags/event+announcements/. Acesso em: 30 ago. 2010.

Em:

7

Capítulo 1. Introdução

tecnologias que tratem corretamente suas particularidades, deixando-as vulneráveis aos problemas. Os problemas podem ser mensurados ainda na concepção 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 problemática nasceu em razão das aplicações Web, como já tratado, não terem sido concebidas como Máquinas Sociais. Desta forma as arquiteturas das aplicações também não foram pensadas para estruturar SM’s, não tiveram o devido tratamento e atenção quanto as particularidades de uma SM, de modo que, elas possam se articular e se expressar na rede em conformidade às inovações pertencentes à mesma, otimizando assim a própria rede. Esta pesquisa se preocupa, sobretudo, em resolver o problema explicitado neste parágrafo. Desta maneira a problemática focada se relaciona seriamente com a necessidade de se especificar arquiteturas de SM’s, pois muitas das aplicações WEB que devem ser vistas como SM’s não são, neste sentido, a arquitetura que é o arcabouço de qualquer software faria total diferença. Com isto o objetivo do trabalho será apresentado.

1.4. OBJETIVOS:

1.4.1. GERAL

Recomendar práticas para auxiliar na especificação, e mesmo concepção, de arquiteturas de Máquinas Sociais. O objetivo é mostrar a forma menos burocrática e mais coerente de se montar uma arquitetura de qualidade para Máquinas Sociais. Deste modo, as aplicações Web 3.0 seriam SM’s prontas para atender as demandas do contexto atual de negócios e de inovações tecnológicas, sobretudo da Internet. Tais práticas poderão atuar nas decisões arquiteturais, e no projeto arquitetural. Por consequência atuarão no processo de desenvolvimento, haja vista que a arquitetura mobilize muitas fases do projeto de software, (KRUCHTEN, 1995) integrando profissionais com aptidões distintas, como: analistas de requisitos, engenheiros de software, programadores e gerentes. A missão dessas práticas é minimizar os problemas no desenvolvimento das SM’s, problemas estes que já foram explorados em uma seção anterior.

8

Capítulo 1. Introdução

As práticas também visam customizar a arquitetura de referência que será proposta, esta arquitetura também caracteriza o objetivo do trabalho a partir do momento em que tornase um instrumento para a criação de novas arquiteturas de SM’s.

1.4.2. ESPECÍFICO

Tratando-se do objetivo deste trabalho, deve ficar claro que talvez essa pesquisa não resolva todos os problemas causados pela complexidade das inovações tecnológicas, o que foi comentando ainda na problemática. Mas, certamente organizará o desenvolvimento das Máquinas Sociais, ao passo que poderá padronizar as tecnologias adotadas. Esta seção

fortalece o objetivo principal, pois expõem os resultados que serão alcançados com a formalização da metodologia. Na verdade, são subprodutos do objetivo geral, ou metas estabelecidas para serem obtidas ao longo do trabalho. 1. Estudar as tecnologias emergentes ao desenvolvimento de aplicações Web 3.0; 2. Exemplificar Máquinas Sociais já implementadas e aplicadas à indústria de software; 3. Verificar a existência de uma arquitetura de referência para sistemas Web 3.0; 4. Sugerir uma arquitetura de referência para Máquinas Sociais no intuito de guiar a elaboração das demais arquiteturas. 5. Estudar práticas, métodos ou procedimentos dedicados a especificação de arquitetura. 6. Montar um raciocínio sobre o desenvolvimento de Máquinas Socias de modo que os desenvolvedores trabalhem sobre o conceito de aplicações interoperáveis na Web e não sistemas isolados; 7. Contribuir para o amadurecimento de um framework ou padrões de projeto para Máquinas Sociais; 8. Disseminar as práticas em um ambiente real de desenvolvimento para verificar a aplicabilidade das mesmas.

1.5. TRABALHOS RELACIONADOS 9

Capítulo 1. Introdução

As pesquisas sobre Máquinas Sociais são oriundas dos estudos de um grupo da Universidade Federal de Pernambuco dedicado a SM’s fundado pelo professor Silvio Meira, cientista do C.E.S.A.R – Centro de Estudos Avançados do Recife, o qual também dissemina pesquisas sobre Máquinas Sociais. Os trabalhos que exploram as SM’s 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 forças em conceitos como Cloud Computing e Redes Sociais. Esta pesquisa também está totalmente relacionada a arquitetura de software. Arquitetura de Software (AS) pode ser classificada como um conjunto de decisões dedicadas a resolver um problema (PRESSMAN, 2011), ou ainda uma coleção de componentes e conectores (ligações) que irá compor o sistema (GORTON, 2006). A AS pode ser ainda a abstração de um sistema computacional, seu arcabouço (PRESSMAN, 2009). Todos os conceitos levantados sobre AS são de obras que estudam arquitetura e que também estão entrelaçadas a esta pesquisa, outros estudos sobre AS estão da mesma forma entrelaçados como o de ERL em 2005, Gamma em 2000, Bass e Clements em 2003. São diversos os conceitos para a AS, e todos eles defendem a relevância de se definir corretamente a mesma, pois os reflexos dessa definição podem ser pressentidos de forma intensa ao longo da implementação do software, seja este modesto ou não (BASS, CLEMENTS e KAZMAN, 2003). Neste sentido, vale dedicar esforços às questões que envolvem a peça fundamental para qualquer sistema e aplicação computacional. Com isto trabalhos que se empenham em facilitar a especificação da arquitetura estão interligados a esta pesquisa. Assim, a IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems, e a IEEE Recommended Practice for Software Requirements Specifications, são trabalhos fortemente relacionados.

10

Capítulo 1. Introdução

1.6. CONTRIBUIÇÃO E RESULTADOS ESPERADOS

Esta pesquisa visa contribuir para o cenário dos estudos e do desenvolvimento de aplicações do tipo Máquina Social, ao passo que amadurece o pensamento acerca das decisões de projeto dessas aplicações, deste modo, elas sofrerão o mínimo de problemas em seu desenvolvimento e manutenção. Os seguintes resultados são esperados:  Amadurecimento e disseminação do conceito de Máquinas Sociais;  Facilidade na adoção de padrões arquiteturais e tecnologias que constituem uma Máquina Social;  Contribuir para o amadurecimento dos conhecimentos sobre o atual cenário de desenvolvimento de aplicações Web 3.0;  Impulsionar novas pesquisas em Máquinas Sociais;  Demonstrar métodos avaliativos sobre artefatos de software e sobre SM’s.  Propor soluções que possam facilitar em algum aspecto a interação entre as SM’s.

Finalmente uma potencial contribuição deste trabalho reside em agregar ao mundo acadêmico um estudo consistente sobre SM’s a ponto de orientar pesquisadores e profissionais para as particularidades das mesmas, e também 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 soluções adequadas para a construção de Máquinas Sociais. Sendo assim, a pesquisa é do tipo Exploratória, a qual é bastante utilizada em trabalhos com temática inovadora (SEVERINO, 2008). A dissertação também será uma pesquisa do tipo Acadêmica, pois sistematiza um processo para construção de um novo conhecimento (SEVERINO, 2008). A pesquisa está organizada conforme disposição abaixo: No capítulo 2 será esclarecido o conceito de SM’s com suas características e taxonomia. Este capítulo se fez necessário pelo fato das SM’s serem peças fundamentais à pesquisa, trata-se de um trabalho dedicado às SM’s.

11

Capítulo 1. Introdução

O capítulo 3 será um estudo sobre arquitetura de SM’s, ou seja, sobre a arquitetura de aplicações emergentes e contextualizadas a Web 3.0. Tal capítulo será útil para a descoberta de problemas em AS de SM’s, para identificar o estado da arte em arquitetura de aplicações Web 3.0, verificar um padrão entre as arquiteturas dessas aplicações, e também para a consolidação da arquitetura de referência para as SM’s O capítulo 4 é constituído por alguns conceitos sobre arquitetura de software, uma vez que, os esforços foram em propor uma arquitetura de referência para as SM’s. Tal capítulo aborda a arquitetura de referência por meio de visões arquiteturais, além de empregar uma avaliação baseada em checklist sobre a arquitetura. O capítulo 5 formalizará as práticas de especificação de arquitetura, estas nortearão a customização da arquitetura de referência para qualquer arquitetura de SM’s, e principalmente guiaram a uma correta especificação da arquitetura. No capítulo 6 a viabilidade da adoção das práticas e da arquitetura de referência será constatada através da experimentação por caso de uso. O experimento será aplicado diretamente na indústria de desenvolvimento de software. O capítulo 7 concentrará as considerações finais e os trabalhos futuros.

12

Capítulo

2
2. Máquinas Sociais
Neste capítulo vamos situar a pesquisa dentro do seu principal objeto de estudo que são as Máquinas Sociais ou Social Machines – SM’s. Examinaremos o contexto no qual as SM’s estão imersas, assim como, suas características e classificação.

13

Capítulo 2. Máquinas Sociais

2.1. O CONTEXTO DAS MÁQUINAS SOCIAIS

O que mais motivou as pesquisas em Máquinas Sociais é o contexto atual no qual está imerso a engenharia de software e os modelos de negócio que estão sendo impulsionados pela Internet. A engenharia de software, inclusive, tem sido cada vez mais direcionada para atuar na Internet, este argumento é cada vez mais irrefutável 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, além de ofertar boas soluções para a reutilização de recursos. As principais características que têm atraído atenção de pesquisadores, estudantes, clientes, fornecedores e investidores de TI sobre CC, além do modelo de negócio, e das inovações dentro da engenharia de software, são as ofertas econômicas de recursos físicos (infraestrutura), recursos para escalabilidade e flexibilidade de manutenções. CC é um termo genérico para um conjunto de recursos computacionais, como: unidades de armazenamento distribuídas. CC é provido na rede e tem emergido a partir da evolução e integração natural de muitas áreas, incluindo Utility Computing, Grid Computing, Web Services e Arquitetura Orientada a Serviços (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 distribuição de software no qual o fornecedor disponibiliza o software em ambiente Web, inviabilizando a replicação de cópias do programa em diversas máquinas do usuário final. Os SaaS ficam depositados na Núvem e os clientes normalmente desconhecem a localização física desta. Com SaaS o cliente paga pelo software conforme a quantidade de pessoas que irão utilizá-lo, ou seja, o serviço e a cobrança pelo serviço se dá sob demanda, isto se caracteriza como o seu maior diferencial (JACOBS, 2005).

14

Capítulo 2. Máquinas Sociais

Para o desenvolvimento de SaaS são utilizadas plataformas10 online dotadas de recursos que segundo Motahari-Nezhad (2009) apóiam todo o ciclo de desenvolvimento de programas computacionais, incluindo design, implementação, depuração para encontrar defeitos, testes, cópias de segurança, gerência de configuração, rápida instalação (ou deployment), além das várias operações de suporte aos serviços ofertados. Estas plataformas foram denominadas Plataform as a Service - PaaS, das quais, a Force.com11, se caracteriza como uma das mais acessíveis e popularizadas, uma vez que é totalmente centrada na aplicação e abstraída 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 preocupações das empresas em salvaguardarem um parque tecnológico para manter as aplicações, pois agora os recursos de hardware são serviços remotos (MCPHERRON, 2008) onde ocorrem os aluguéis de Data Centers que fazem a hospedagem das aplicações. IaaS é um serviço oferecido por empresas como Amazon AWS12, por exemplo. Assim, em Cloud Computing, uma das preocupações seria a de adaptar os programadores e as aplicações a esse novo paradigma e a forma em que ele trata as tradicionais práticas 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 também é possível comprar aplicativos, ou partes deste. A Force.com ficou conhecida pelo serviço 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 serviços de hospedagem e IaaS. Disponível em: http://aws.amazon.com. Acesso em 02 de jul. 2010.

15

Capítulo 2. Máquinas Sociais

Figura 1. Representação da Estrutura de Cloud Computing

Dentro de cada camada representada na Figura 1, existem modelos de negócios que são baseados na função 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 série de serviços, e um deles é o Elastic Compute Cloud2 EC213 que provê segurança, balanceamento de carga, e aumento de recurso computacional automaticamente conforme o crescimento da aplicação. O pagamento para este serviço é baseado no modelo chamado “sob demanda” onde se paga apenas a quantidade de serviço utilizado (WEINHARDT, BLAU e STOBER, 2009). Ainda dentro dos novos negócios que surgem em Cloud Computing - CC estão os serviços da Google Apps, esta possui um enorme conjunto de aplicações na CC, tais como: aplicativos para processamento de textos e planilhas, emails, calendários e outros. Vale ressaltar que o crescimento de novos modelos de negócios em CC está relacionado principalmente à segurança de dados e informações, garantia de integridade, disponibilidade de serviços, confiabilidade e rapidez de desenvolvimento (WEINHARDT, BLAU e STOBER, 2009). Assim, é notável a alteração que CC causou no cenário da engenharia de software, nas formas de pensar, de fazer, e de negociar programas computacionais. Entretanto, este não

13

Disponível em: http://aws.amazon.com/ec2. Acesso em 17 de dez. 2011.

16

Capítulo 2. Máquinas Sociais

é um privilégio da Cloud Computing. As Redes Sociais também contribuíram para as inovações em engenharia de software, pois algumas dessas redes são ferramentas de programação da própria rede social, o que pode influenciar em requisitos, teste e arquitetura. Tanto as Redes Sociais quanto a CC estão inseridas no contexto da Web 3.0, portanto, estão no contexto do novo conceito de SM’s. A implementação de uma SM pode ser feita por meio de Cloud Computing, ou mesmo, uma SM pode ser um serviço oferecido pela nuvem já dentro do panorama dos novos negócios. As SM’s são uma nova abordagem dentro deste contexto, uma abordagem simplificada para as aplicações Web que compõem este cenário inovador.

2.2. CONCEITO DE MÁQUINAS SOCIAIS

Máquinas Sociais são sistemas, ou aplicações Web, conectáveis, que possuem uma unidade de processamento interno e são capazes de interagir com outras máquinas, a fim de, executar um serviço (MEIRA. et al, 2011). A Figura 2 mostra a representação básica da SM.

Figura 2. Representação da Máquina Social

Fonte: The Emerging Web of Social Machines

A Máquina Social é constituída pelos elementos representados na Figura 2, descritos como se segue, segundo Meira et, al. 2011:

17

Capítulo 2. Máquinas Sociais

Request: trata-se de uma chamada de procedimento remoto feito aos serviços prestados pela SM por meio da sua interface (Wrapper). O Request é classificado em: SM’s functionality request, e SM’s meta-information request. o SM’s functionality request: é a requisição de um serviço ou de uma chamada de método que pode ser feito para outra SM. o SM’s meta-information request: trata-se de uma requisição de consulta para uma determinada SM, a fim de, ter conhecimento sobre o seu estado, ou mesmo sobre os seus parâmetros de custo e tempo de resposta dos seus serviços, disponibilidade e outras meta-informações associadas à SM.  Response: é a resposta remota da SM ao solicitante, novamente por meio da Interface Wrapper. Seus tipos são: SM’s functionality response, SM’s metainformation response, e Notification response. o SM’s functionality response: trata-se da resposta direta ofertada a uma SM’s functionality request. Pode haver várias ou nenhuma SM’s functionality response para uma SM’s functionality request. o SM’s meta-information response: é a resposta direta ofertada a uma SM’s meta-information request. o Notification response: são notificações de uma máquina a respeito de algum evento ocorrido. Pode ser uma notificação de erro de execução, de erro de envio de mensagem, mensagens de sucesso, de disponibilidade e outros.  Wrapper Interface: a Interface Wrapper é uma camada de comunicação na qual uma SM exterioriza os seus serviços e permite interação com outros SM’s. Esta Interface pode também ser entendida como a API14 da SM.  Input: é a entrada de dados que de fato será processada pela unidade e que só ocorre após a requisição de procedimentos, assim, os objetos a serem manipulados

14

API é o conjunto de funcionalidades de um software disponibilizado por meio de seus códigos e rotinas, assim uma aplicação pode utilizar o serviço de outra sem ter que necessariamente codificar (Tanembaum 2006). Informações sobre a API do Twitter em: http://apiwiki.twitter.com/.

18

Capítulo 2. Máquinas Sociais

pela SM são introduzidos objetivando o processamento e retorno do serviço solicitado. O Input pode ser comparado a um parâmetro de uma linguagem de programa.  Output: é o resultado do processamento dos dados de entrada, no entanto, é possível que a SM não consiga resultados em alguns de seus processamentos.  Communications: são as ligações que uma SM tem com outra, seguindo um protocolo bem definido. Tais ligações podem ser vistas como relacionamentos, intermitentes, ou não, entre as máquinas. As ligações devem ter restrições para a interação entre SM’s.  Processing Unit: este elemento representa os processos, é a unidade interna computacional, como algoritmos que fornecem as funcionalidades principais da Máquina Social.  States: é a condição dos serviços da SM, o estado atual da SM, que exibe qual a

disponibilidade dos serviços e conexões. 

Constraints: as restrições que a SM pode ter são descritas por esse elemento. Ele

pode ser comparado com os requisitos não-funcionais de um sistema, ou seja, nele podem ser declarados, por exemplo: o número máximo de acessos aceitos pela máquina, os critérios de segurança, bem como, o seu desempenho. Assim, as restrições podem ser usadas como regras a serem consideradas durante o vínculo entre as diferentes SM’s.

2.3. CARACTERÍSTICAS DAS MÁQUINAS SOCIAIS

Esta abordagem de SM’s é relevante justamente por atribuir características às aplicações, características que as tornam diferenciadas, que as tornam SM’s. Os traços mais relevantes de uma SM estão relacionados no próximo parágrafo. A SM deve ser um elemento absolutamente sociável, deve interagir com o ambiente e os outros elementos ao seu redor e também deve ser independente de qualquer plataforma ou tecnologia, devendo saber encontrar os serviços que lhe possam ser úteis. Outra importante 19

Capítulo 2. Máquinas Sociais

característica de uma SM é a capacidade de oferecer seus serviços de modo que outras máquinas não necessitem saber, ou se preocupar com a forma como, quando e onde os serviços foram implementados (MEIRA. et al, 2011). A SM deve deixar evidente os serviços que podem ofertar, e sobretudo deve se autoreconhecer, ou seja, ter conhecimento do seu estado ou propriedades. Por fim, outra característica, é a capacidade de se conectar com outras SM’s dinamicamente, a fim de, trocar ou apenas consumir serviços dessas máquinas. É interessante pontuar essas características, fazendo algumas relações, como por exemplo, com os requisitos que uma Máquina Social deve saciar. Os requisitos próprios de um SM’s surgem de um estudo exploratório sobre as mesmas. Eles despontam conforme as características destas Máquinas Sociais. A priori requisitos como: Performance15, Disponibilidade16, Modificabilidade17, e Interoperabilidade18, são os mais importantes para as SM’s, eles atuam na satisfação das necessidades e características das Máquinas Sociais. O quadro abaixo pode auxiliar neste entendimento, de modo que, deixa evidente e prático a identificação das características e necessidades das SM’s a serem atendidas. Dentre estes requisitos não funcionais, o de escalabilidade não foi pontuado como sendo comum as SM’s, pois este tipo de requisito está muito relacionado à faculdade da Máquina Social em crescer para atender uma demanda contínua de uso da SM (TAURION, 2009). Ainda assim, nem todas as SM’s possuem necessidade de expansão em sua

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

15

Performance: Relacionado a confiabilidade, em manter um nível aceitável de funcionamento sobre situações extremas, tem relação direta com: maturidade, tolerância 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: Comunicação de forma transparente com outras entidades, de forma que possa ocorrer a troca de dados ou informações independentemente da plataforma ou tecnologia (SOMMERVILLE, 2011).

20

Capítulo 2. Máquinas Sociais

Têm Autonomia Sociabilidade

Necessitam Serviços Comunicação facilitada Manutenção facilitada Infraestrutura Reatividade Conectividade Expansão ou Confiabilidade

Máquinas Sociais

Constância Colaboração Serviços

Tabela 1. Características e necessidades das SM’s

2.4. TAXONOMIA DAS MÁQUINAS SOCIAIS

As Máquinas Sociais possuem sua própria classificação. Existem 4 grupos de SM’s: Isoladas, Consumidoras, Fornecedoras e Prosumer. Tal classificação tem como parâmetro a interação entre as SM’s (MEIRA. et al, 2011 ).   SM’s Isoladas: são SM’s que não interagem com outras SM’s por não SM’s Consumidoras: SM’s que apenas consomem um ou mais serviços para, a

possuirem meios de comunicação. partir disto, ofertar um novo serviço. Um exemplo dessas SM’s são as ferramentas Mashups.  SM’s Fornecedoras: são SM’s que apenas fornecem serviços, pois possuem os

recursos necessários ao seu completo funcionamento. O Google Maps é um exemplo de SM deste tipo.  SM’s Prosumers: como o próprio termo em inglês significa, são SM’s que

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

21

Capítulo 2. Máquinas Sociais

2.5. EXEMPLOS DE MÁQUINAS SOCIAIS

Para consolidar mais os conceitos deste capítulo é interessante exibir alguns modelos de SM’s. Abaixo descrevemos o nome da tecnologia e o porquê ela pode ser considerada uma SM. Ao final dos exemplos será possível notar que os conceitos de SM’s não se limitam apenas às aplicações Web, apesar deste trabalho focar nas SM’s que são aplicações para Internet. Tais máquinas podem também 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 código aberto que fornece suporte para a integração com outras IaaS como a Amazon AWS. Com o Eucalyptus o usuário também pode gerenciar sua nuvem criada em outras ferramentas. Esta IaaS permite aos usuários acesso e gerência a todas as máquinas virtuais existentes (LIU et al., 2007). O Eucalyptus trabalha essencialmente com virtualização, além de utilizar o protocolo SOAP19 para consultas. Essa IaaS pode ser considerada uma SM pelo gerenciamento e reconhecimento do estado de outras máquinas, o que sobressai a característica sociável do Eucalyptus. Neste ponto o Eucalyptus possui muitos dos elementos das SM’s, sendo que os elementos mais importantes para esta IaaS são as solicitações. Assim, o Eucalyptus envia Request e recebe Response a todo o momento, além de possuir uma robusta Wrapper Interface chamada de Cluster Controller (LIU et al., 2007) que possibilita uma interação imediata a eficaz com todas as máquinas virtuais, que podem também ser SM’s.

2.5.2. CLOUD AV:

O Cloud AV é uma ferramenta antivírus ofertada como um serviço de Cloud Computing. Tal serviço identifica arquivos maliciosos por múltiplos mecanismos de detecção em paralelo que se comunicam entre si exatamente como SM’s. O Cloud AV utiliza técnicas baseadas em cache para melhorar o desempenho durante o envio de arquivos, além disto, para

19

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

22

Capítulo 2. Máquinas Sociais

prover escalabilidade, a ferramenta é executada em máquinas virtuais (OBERHEIDE, et al., 2008). O Cloud AV possui os seguintes elementos (OBERHEIDE, et al., 2008) de uma SM:  Input: recebe arquivos para a análise e o seu mecanismo de detecção é composto por diversos aplicativos antivírus que fazem Request e Response entre si até que a detecção seja possível.  Output: Envia o resultado da análise dos arquivos apontando quais estão infectados ou não. Evidentemente o Cloud AV possui o elemento Processing Unit para possibilitar tantas análises, além da característica de sociabilidade da SM, o que torna possível a interação com os vários antivírus 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 tolerância a falhas, distribuição dos dados e balanceamento de carga. O MapReduce trabalha com funções que se comportam como SM’s; Jimmy Lin e Chris Dyer (2010) definem bem o funcionamento do aplicativo no parágrafo abaixo:
No MapReduce cada operação é composta por duas funções. A primeira, chamada de função de Mapeamento, recebe uma porção do arquivo de entrada, e de acordo com a especificação do usuário, emite um conjunto de tuplas intermediárias no formato chave-valor. A segunda função, chamada Redução, recebe um conjunto de valores associados a cada chave, chamados de blocos. O processamento, definido pelo usuário, é realizado sobre cada bloco; por fim, cada função de redução emite um conjunto de tuplas que são armazenadas em arquivos de saída.

Por redução se entende: uma função que "recolhe" os itens em listas e realiza alguma computação 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 redução pode ser vista com os elementos Input e Output da SM. Além de possuir os elementos da SM, como os já citados, além de outros como o State; o MapReduce possui a característica da SM de se auto-reconhecer e reconhecer o volume de dados entregue (LIN e DYER, 2010). 23

Capítulo 2. Máquinas Sociais

Outra característica que aproxima o MapReduce de ser uma SM é o fato das camadas que compõem 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 não são adjacentes, ou seja, o sentido de comunicação e o tipo de comunicação pode ser alterado (GAMMA et al, 1995).

2.5.4. WEB SEMÂNTICA:

Para finalizar a exibição das Máquinas Sociais, será exibido uma aplicação em um nível maior, ou melhor, será exibido uma plataforma como Máquinas Sociais, pois assim será possível notar como este conceito pode ser aplicado a diversos níveis de tecnologia. Atualmente quando uma página Web é procurada com o auxílio de uma máquina de busca, esta máquina vai investigar as páginas que contém palavras declaradas pelo usuário. Contudo, nem sempre essas palavras são adequadas e relevantes para o contexto em que o usuário está inserido. A Web Semântica vem para sanar esse problema, pois ela é a Web dos significados (BERNERS-LEE; HENDLER; e LASSILA, 2001). Ela atribui significado claro e específico aos dados por meio da interpretação e da contextualização dos mesmos; isto facilita o entendimento das máquinas (MORAES E SOARES, 2002), deixando a resposta para qualquer tipo de pesquisa na Web mais precisa, satisfazendo a necessidade do usuário. A Web Semântica também é classificação como Web 3.0 e foi idealizada por Tim Berners-Lee. Tim projetou uma Internet inteligente, o que se deve principalmente à organização das informações. Tais informações são consequências de dados oriundos de repositórios completamente heterogêneos. Tim ainda afirma que o grande diferencial desta Web 3.0 será o aprendizado das máquinas, pois estas organizarão e darão contexto aos dados (BERNERS-LEE; HENDLER; e LASSILA, 2001). No texto abaixo, traduzido da obra de Lee, Hendler e Lassila (2001), é possível observar forte relação entre o conceito de Internet Semântica e o conceito de Máquinas Sociais.
Os agentes na Web Semântica são sistemas computacionais capazes de interagir autonomamente para atingir os objetivos almejados pelo usuário. Os agentes possuem algumas características como autonomia, reatividade (percebem o ambiente e tomam as decisões), tem comportamento colaborativo, possuem objetivos, são

24

Capítulo 2. Máquinas Sociais

flexíveis, sociáveis e têm a capacidade de aprender. A Web Semântica possui vários agentes interagindo entre si, compreendendo, trocando ontologias, adquirindo novas capacidades racionais ao passo que adquirirem novas ontologias para formar cadeias que facilitam a comunicação e a ação humana.

Pela citação direta nota-se claramente as características de uma SM na Web Semântica, entre elas: sociabilidade, interação, colaboração, e comunicação. Tais características necessitam de todos os elementos das Máquinas Sociais. Deste modo, essa seção se encerra na esperança de ter contribuído para a fixação dos conceitos de SM’s e de como tais SM’s podem ser identificadas.

2.6. CONSIDERAÇÕES FINAIS DO CAPÍTULO

Este capítulo apresentou as Máquinas Sociais. Vale salientar que existem outros materiais que explicam minuciosamente o conceito das SM’s os quais estão referenciados na bibliografia deste trabalho. Outro ponto importante a ser declarado é o fato deste capítulo fornecer conceitos que devem ser considerados durante a execução desta pesquisa quanto à consolidação do objetivo geral da mesma. O próximo capítulo tratará com igual propósito no que concerne à arquitetura das SM’s.

25

Capítulo

3
3. Revisão da Arquiteturas de Máquinas Sociais Literatura de Software Para

Esse capítulo objetiva descobrir evidências de pesquisa sobre arquiteturas de softwares que são Máquinas Sociais. É necessário investigar essas arquiteturas para ter entendimento de como elas realmente são. Com isto, será possível sugerir uma arquitetura de referência dedicada às Máquinas Sociais; e futuramente, sugerir práticas de engenharia de software coerentes ao maior objetivo do trabalho, que é facilitar a construção de arquiteturas, e assim das próprias aplicações que são SM’s.

26

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

3.1. INTRODUÇÃO

Não 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 padrões, métodos, representações e técnicas relacionados à arquitetura de software, o que ocasionou uma evolução nessa área de estudo da engenharia. Em tempos longínquos, a arquitetura de software era basicamente voltada para os sistemas cliente-servidor, onde uma máquina exercia o papel de cliente requisitante e a outra máquina, o papel de servidor com a responsabilidade de atender as requisições. Deste modo, a arquitetura cliente-servidor tornou-se padrão 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 cenário: arquiteturas cada vez mais heterogêneas, onde estilos e tecnologias diferenciadas se misturam para formar novas versões de representações arquiteturais.

3.2. ARQUITETURA DE SOFTWARE

Arquitetura de Software (AS) é a definição da estrutura e dos elementos que compõem um sistema, como esses elementos estão inter-relacionados, e quais as suas características (BASS, CLEMENTS, KAZMAN, 2003). A AS está intimamente ligada aos requisitos de software, mais fortemente aos requisitos não funcionais (RNF) (BASS, CLEMENTS, KAZMAN, 2003). Sendo assim, a definição de uma arquitetura se inicia com o levantamento e análise dos requisitos seguido pelas decisões de projeto. Estas são escolhas em relação às tecnologias utilizadas para desenvolver a aplicação (PRESSMAN, 2011). Ao longo da história a AS foi várias vezes explorada, conduzindo a um universo de descobertas que, por sua vez, gerou soluções úteis ao desenvolvimento de software. Na evolução dos estudos da área, descobriu-se que o estilo arquitetural Camadas facilitava enormemente o desenvolvimento de softwares para a Web. As principais características do estilo Camadas são, segundo Erich Gamma, 2000:  Camadas superiores são específicas da aplicação; 27

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Camadas inferiores são mais responsáveis pela infraestrutura, oferecendo

suporte às camadas superiores;  As camadas só interagem com camadas contíguas, ou seja, com as camadas

que estão imediatamente acima ou abaixo;  O conteúdo das camadas pode ser variável, assim como o nome de cada

camada. A comunicação entre as camadas pode ser por meio de protocolos de comunicação ou mesmo através de um sistema operacional. Tradicionalmente, elas se dividem em 3 camadas e mais o repositório de dados ilustrados na Figura 3 (HOFMEISTER, 2000).

Figura 3. Estilo arquitetural Camadas

1ª Camada, Apresentação: camada onde o usuário interage diretamente, ela valida os dados fornecidos pelo usuário e o conecta aos serviços da camada inferior;

 

2ª Camada, Negócio: contém todos os componentes e objetos que podem ser utilizados e reutilizados para implementar a lógica de negócio da aplicação; 3ª Camada, Persistência: é a camada responsável pelo acesso aos meios de armazenamento como: memória, banco de dados e sistemas legados.

O estilo Camadas se popularizou e passou por evoluções, uma vez que inicialmente era constituído por duas camadas e atualmente já pode ser constituído por até quatro ou mais, 28

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

consoante Christine Hofmeister (2000), no qual existe uma quarta camada de Middleware ou mesmo um servidor Web para fazer a gerência da aplicação. Além das características expostas acima, sua popularização se deve, mormente, pelas características 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 alterações, o que afetaria apenas a interação com as camadas adjacentes. Logo, as camadas poderão ser reutilizadas, desde que mantenham interfaces de comunicação 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 número de variações, já explicado anteriormente, o Relaxed Layered System; além do estilo Layering Through Inheritance, outra derivação do Camadas (KLEIN, KAZMAN, 1999), com características semelhantes e algumas melhorias, como: permitir que camadas superiores modifiquem os serviços das classes das camadas inferiores;

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

Podem ser facilmente empregados padrões de projetos, como o padrão Observer, fortemente utilizado na interação entre as camadas (LARMAN, 2007);

Apesar dos benefícios 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 utilização não é viável para todos os sistemas (BUSCHMANN et al, 1996). Assim, para sistemas que necessitem de ótimo desempenho as camadas não são aconselháveis, porquanto o tempo de processamento e a própria comunicação entre as camadas pode ser elevado (BUSCHMANN et al., 1996). Outro critério de qualidade é a tolerância à falhas. Se uma

29

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

camada ficar indisponível, o sistema na sua integralidade poderá ficar indisponível, haja visto, que uma camada depende de outra para funcionar (HOFMEISTER, 2000). Para finalizar a exposição dos conceitos relacionados a arquitetura de software, vale mais uma vez enfatizar que uma arquitetura de referência será esboçada, e que ela, assim como toda arquitetura de referência, precisa de um estilo arquitetural. A partir do ponto em que se estabelece uma arquitetura de referência, já se disponibiliza um parâmetro inicial para a construção da arquitetura correta de SM’s, e que pode ser perfeitamente guiado pelas práticas que darão forma ás arquiteturas. Faz-se necessário esta seção sobre arquitetura de software, uma vez que esse capítulo trata de um estudo sobre arquitetura. Torna-se relevante ter um estudo dessa categoria compondo a pesquisa, porquanto dará subsídio para a formulação da AR e das práticas ao passo que revelará o estado da arte das arquiteturas de aplicações que fazem partem da Web 3.0. O desenvolvimento deste estudo foi baseado, entre outros, nas orientações das obras de Bárbara Kitchenham e David Budgen (2008 - 2009), e de Pertersen (2008), assim está estruturado como se segue.

3.3. PROCESSO DE REVISÃO

3.3.1. QUESTÃO A SER INVESTIGADA:

A questão investigada neste trabalho trata da existência de uma arquitetura de referência para Máquinas Socias, uma arquitetura que facilite o desenvolvimento de SM’s por ser uma arquitetura padrão a todas as SM’s. Portanto a questão de pesquisa é: “what are architecture of reference for Social Machines?”. Traduzindo: existem arquiteturas de referência para Máquinas Sociais. Seguindo alguns critérios de Petticrew e Roberts (2005) a questão selecionada se baseia em:  Intervenção: Estudos sobre arquiteturas e Máquinas Sociais que façam algum tipo de experimento ou análise utilizando alguma técnica ou modelo.

30

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

População: Trabalhos científicos publicados sobre arquiteturas de aplicações WEB 3.0 ou para sistemas que possam ser classificados como Máquinas Sociais.

Publicação: Materiais técnicos que tratem das arquiteturas, ou sistemas, e práticas relacionadas às Máquinas Sociais.

O que se almeja descobrir neste estudo é o estado da arte de arquiteturas de aplicações Web, bem como, a existência de um padrão 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 princípios da Web 3.0. Assim, as questões de pesquisa foram selecionadas.

3.3.2. QUESTÕES DE PESQUISA:

Seria mais fácil encontrar materiais que fossem dedicados aos sistemas, aplicações ou tecnologias que possam ser classificados como Máquinas Socias, visto que o quantitativo das pesquisas que tratam as aplicações propriamente como Máquinas Sociais, com arquiteturas de Máquinas Sociais, é inexpressivo. Sendo assim, optou-se em utilizar questões que abordem arquiteturas das tecnologias: Mashups, Computação nas Nuvens, Redes Sociais, Sistemas Autônomos e aplicações Web. Estes possuem características marcantes das SM's por interagirem com outros elementos em rede, além de utilizarem serviços e recursos destes elementos e também da própria rede para funcionar, se desenvolver, e auto gerenciar. Complementando a motivação acima, existe o fato das Máquinas Sociais selecionadas para as questões serem mais difundidas, possibilitando dessa forma, maior número de pesquisas e experimentos sobre elas, o que pode facilitar o desenvolvimento do estudo em questão. Do mesmo modo, o estudo pode ser facilitado com a inserção de uma questão de pesquisa dedicada às aplicações Web em geral, ou seja, uma das questões investigará a existência de uma arquitetura de referência para aplicações web. As 5 (cinco) questões para a busca da pesquisa foram definidas e são expostas abaixo: QP1: What are the reference architectures for Mashups? 31

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas 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 questões propostas acima buscam descobrir tendências inovadoras sobre arquitetura de Máquinas Sociais. Elas foram escritas na linguam inglesa apenas para facilitar a obteção de resultados, pois acreditasse que os resultados de estudos serão em maior quantidade na língua inglesa. No entanto, é necessário utilizar palavras que complementassem a busca pelas respostas das questões de pesquisa, neste caso, os termos ou “strings” a seguir, orientam a idéia de melhorar os filtros de busca. Por conseguinte, foram utilizados na investigação por vezes mesclados às questões acima, os strings são: 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 número de resultados que atendessem a questão de pesquisa, as questões de busca foram por vezes alteradas com o auxílio 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

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

3.3.3. REPOSITÓRIOS DE BUSCA

Os repositórios e base de dados utilizados para encontrar as questões e palavras investigadas foram as bibliotecas digitais: CiteSeerX; IEEE Xplore; Mendeley; e ACM Digital Library. Foram também empregados capítulos de livros e revistas digitais especializadas para subsidiar a investigação (KITCHENHAM, 2009). Este trabalho possui natureza científica, entretanto, seu resultado visa alcançar também profissionais e empreendedores na área de TI no intuito de facilitar a criação de aplicações Web. Sendo assim, houve a necessidade de empregar ferramentas que ofertassem um resultado mais direcionado ao mercado tecnológico, bem como revelassem materiais que não pertencessem aos repositórios mencionados, e que por sua vez, fossem mais técnicos e menos científicos, agregando valores à pesquisa em comento. Deste modo, foram aplicados em uma investigação secundária, máquinas de busca como: Google Scolar e Google Books.

3.3.4. IDENTIFICAÇÃO DO MATERIAL

Todo material revelado pela busca foi precedido de leitura do título. Por sua vez aqueles que mais se aproximavam das questões investigadas tinham seu conteúdo selecionado para posterior leitura do resumo ou introdução. Após essa leitura, uma relevância era atribuída ao material conforme alguns critérios de classificação.

3.3.5. CRITÉRIOS DE CLASSIFICAÇÃO - INCLUSÃO:

A inclusão de pesquisas a serem consideradas para o referido estudo se baseou na relevância declinada.  Atribuir maior relevância para materiais que se caracterizem como: o Arquiteturas já testadas e empregadas em Máquinas Sociais; o Soluções de projeto ou decisões de projeto de aplicações vistas como Máquinas Sociais.  Atribuir relevância mediana para materiais que:

33

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

o Façam referência as tecnologias emergentes e adequadamente empregadas na construção de Máquinas Sociais; o Sejam projetos “piloto” de arquitetura de referência para aplicações ou sistemas WEB. 3.3.6. CRITÉRIOS DE CLASSIFICAÇÃO - EXCLUSÃO: Foram descartados materiais que apresentam menor contribuição por não tratarem de assuntos relacionados às arquiteturas de sistemas ou aplicações 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 conteúdo muito conceitual sobre arquitetura, sem nenhuma proposta evidente de tal, sem definição 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 conteúdo integrava materiais de acentuada relevância que contribuiram para a pesquisa. As fichas estão disponíveis no repositório público: http://dl.dropbox.com/u/8309962 /Fichas%20de%20Leitura.docx. As fichas foram organizadas pela ordem de classificação, tal organização observou também a extração de evidências que satisfizessem as questões de pesquisa, validando assim este estudo (PERTERSEN et al. 2008). Por meio do registro do material foi ainda possível extrair conhecimento a respeito do grau de relevância de cada material relacionado a alguma questão de pesquisa, mostrando assim a adoção, ou não, das strings.

3.3.8. RESULTADO

Os materiais mapeados compõem-se na sua totalidade 21 (vinte e um) textos entre artigos, periódicos e capítulo de livro; 11 (onze) destes materiais mostraram maior contribuição para as questões de pesquisa. O resultado de cada uma das questões é exibido na 34

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

tabela a seguir que engloba os 11 (onze) estudos contribuintes. Vale ressaltar que a questão 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 gráfico abaixo (figura 4) mostra a dispersão do quantitativo de estudos por questão de pesquisa; nele é possível observar que a questão das aplicações 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

0

2

4

6

8

10

12

14

Figura 4. Numero de estudos por questão de pesquisa

Fonte Mendeley IEEE

Referência (MERRIL, 2006) (LIU e LIANG, et al. 2009)

Descrição

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.com’s Internet Application Development Platform

CiteSeerX

(KOSSMANN, KRASKA, LOESING, 2010)

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

35

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas 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 DEMONSTRAÇÃO DOS RESULTADOS DAS ARQUITETURAS DE REFERÊNCIA INVESTIGADAS

Nessa seção as arquiteturas averiguadas nos materiais serão relatadas. O objetivo do relato é auxiliar na compreensão dos resultados encontrados.

3.4.1. ARQUITETURA DE REFERÊNCIA PARA MASHUPS – QP1

O Mashup é uma aplicação Web que faz uso de dados de variadas fontes objetivando criar um novo serviço. Na verdade essa aplicação emprega códigos de outras aplicações por meio de uma API (O’REILLY, T, 2008). Um exemplo de Mashup é o site Wikicrimes que mapeia nas regiões o índice de criminalidade com a ajuda do Google Map. O Mashup tem a sua plataforma de programação sustentada pela própria Internet, ou seja, uma característica de aplicações da Web 3.0; todavia, não apenas esta particularidade é notada, mas também a própria definição de Mashup o posiciona como uma Máquina Social. Atualmente existem duas definições para a arquitetura de Mashups, ambas utilizam como referência a arquitetura em camadas e serão exposta a seguir.

36

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

3.4.1.1. Arquitetura Mashup Proposta por Merril em 2006

A primeira definição é a mais disseminada e apresenta a arquitetura com grau de abstração maior em um nível menor de detalhamento, tal definição é de Duane Merril, 2006; propõe que a arquitetura do Mashups seja composta de (ver figura 5):   Web Browser: interface de comunicação entre o usuário e o Mashup; Site Mashup: camada lógica onde o Mashup está implementado pode ser um servidor, ou mesmo o próprio browser do cliente com Applet20,, por exemplo;  API: são os provedores de conteúdo que disponibilizam seus dados por meio de protocolos.

Figura 5. Arquitetura Mashup por Duane Merril

O principal questionamento acima desta proposta, além dela não demonstrar muita riqueza de detalhes, é sobre a arquitetura não prever a integração dos dados, tais dados podem

Applet é um pequeno programa que é incluído nas páginas web, o navegador executa esse programa na página para complementar o conteúdo da mesma (LOPES, ET AL. 2010).
20

37

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

estar em diferentes formatos como XML ou HTML, e também em diferentes semânticas, enfim, são fontes heterogêneas que por vezes não trabalham através de uma API, dificultando assim o trabalho com os dados.

3.4.1.2.

Arquitetura Mashup Proposta por Liu em 2009

A segunda definição é de Yan Liu (2009), cujos padrões utilizados são os seguintes:  Piper and Filter: padrão responsável pela geração e pelo fluxo dos dados, este padrão possui componentes interligados onde cada um executa uma função específica.  Data Federation: responsável pela integração de dados, este padrão é útil quando se deseja integrar dados provenientes de muitas fontes diferentes. Diversas empresas armazenam seus dados em repositórios diferentes, como: bancos de dados transacionais, sistemas de business intelligence, sistemas legados e outros; cada um desses sistemas de armazenamento tem sua própria maneira de acessar os dados, o que traz problemas no momento da busca. O padrão Data Federation ajuda a obter e agregar esses dados, além de facilitar a consulta aos mesmos.  MVC: O padrão Model-view-controller tem um papel importante, uma vez que o model acessa a camada de dados da aplicação, por sua vez, o controlador se comunica com o model para localizar a view requisitada pelo usuário. Neste padrão as tecnologias HTML, XML e JavaScript podem ser utilizadas. O model ainda implementa o padrão Data Federation, enquanto os controladores implementam o padrão Piper and Filter. Diante da solução apresentada, é possível fazer algumas análises. O padrão Piper and Filter traz simplicidade à arquitetura, assim como facilidade de manutenção e escalabilidade, pois novos filters podem ser inseridos na composição da arquitetura sem prejudicá-la. A manutenção destes filtros também é facilitada devido a sua reusabilidade. Na verdade, esse padrão favorece o processamento concorrente. Os filtros, em particular, fazem o processamento, pois cada filtro tem uma função definida. Após o processamento ocorre a geração dos dados. Estes são repassados para o Piper (conector), que,

38

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

por conseguinte, os lêem e repassam para os próximos filtros. Esse ciclo é contínuo até que haja demanda de processamento. Vale ressaltar que, para o padrão Piper and Filter, os conectores podem assumir um comportamento variado no processo. Eles podem ser um protocolo de comunicação 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 não conhecem o estado um do outro, sendo assim, quando ocorre um erro em um dos componentes o sistema todo deve ser reiniciado, pois não se tem conhecimento da função que o filtro estava executando no momento do erro, tal disfuncionalidade ocasiona perda de informações (GARLAN e SHAW, 1994). Por fim, o estilo em questão, por ser orientado através de função não se mostra apropriado à representação dos dados. O grande desafio dos Mashups é reunir dados de diversas fontes para criar um único serviço, logo, sua arquitetura deve assegurar a correta integração, gerenciamento, transformação e organização dos dados. Neste sentido, a adoção do estilo Piper and Filter pode não agregar tantas vantagens justamente pela possibilidade das fontes de dados sofrerem algum tipo de problema e falharem, deixando o Mashup vulnerável. Este problema não é solucionado pelas arquiteturas propostas.

3.4.2. ARQUITETURA DE REFERÊNCIA PARA CLOUD COMPUTING – QP2

Atualmente existem algumas propostas de Arquitetura de Referência para Cloud Computing, dentre as quais, aquelas que consideram as camadas de serviço: IaaS, PaaS, e SaaS como sendo a arquitetura da computação nas nuvens. Contudo, tais camadas são modelos de serviços oferecidos pela Computação nas Nuvens, e não modelo de arquitetura, conforme explicado. Apesar das propostas existentes, o Instituto Nacional de Ciência e Tecnologia – NIST21, situado nos USA, afirma que de fato não existe para Cloud Computing uma

21

Disponível: http://www.nist.gov/index.html. Acesso em: 01 de ago. 2011

39

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

arquitetura de referência. 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 comunicação, ilustrar os vários serviços da nuvem e proporcionar o desenvolvimento de aplicações com alta escalabilidade, segurança e portabilidade. O instituto prevê uma arquitetura de referência que seja adequada também aos modelos de implantação de Cloud Computing, os quais são, segundo Peter Mell e Tim Grance (2009):  Nuvem Pública: A infraestrutura das nuvens é disponibilizada para o público. Qualquer usuário que conheça a localização do serviço poderá acessá-la.  Nuvem Privada: A infraestrutura de nuvem é utilizada exclusivamente por uma organização, sendo administrada pela própria organização, ou por terceiros, especializados em administração e manutenção de Cloud Computing.  Nuvem Comunidade: A infraestrutura de uma nuvem é compartilhada por diversas empresas.  Nuvem Híbrida: A infraestrutura é composta de duas ou mais nuvens que podem ser públicas, privadas e comunitárias, todas devem estar interligadas por uma tecnologia padrão, permitindo total portabilidade. Nesta seção vamos descrever três arquiteturas de referência 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 estão as explicações para cada parte que compõem a arquitetura. A camada Cloud Applications é a mais básica, uma camada de aplicação onde os usuários finais podem manter seus programas na nuvem. Nesta camada também estão os aplicativos e os SaaS, todas as aplicações podem ser adquiridas pelos usuário de forma dinâmica conforme a necessidade do mesmo. Abaixo desta camada está a camada Cloud 40

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Programming. A relação entra elas reside no fato da camada inferior dar suporte à camada superior, sendo assim, a camada mais abaixa Cloud Programming disponibiliza os serviços e os recursos para se implementar o software sob demanda. A Cloud Programming também pode ser chamada de Middleware User-Level, nela podem ser desenvolvidos os aplicativos e regulado o suporte ao desenvolvimento, são basicamente ferramentas e ambientes que podem possuir interface Web 2.0, recursos de programação distribuída, bibliotecas e linguagens de programação, além de ferramentas para o desenvolvimento de sistemas Mashups. Esta camada é similar a uma PaaS. A penúltima camada de Middleware Core é responsável pelo gerenciamento da infraestrutura física, tal camada oferta serviços para a manutenção de QoS22 e SLAs23, serviços de virtualização e outros. Todos os recursos dispostos nesta camada são acessados pela camada diretamente acima dela, pois somente assim, o usuário poderá usufruir dos recursos, haja vista o acesso à camada Middleware Core seja negado. Por fim, a camada de mais baixo nível é a de infraestrutura física que contém Data Centers e conjuntos de CPU’s, além de outros recursos de hardware, os quais podem ser agregados ou subtraídos 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 – Níveis de serviços definidos em um contrato (MELL e GRANCE 2009)

41

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Figura 6. Arquitetura Cloud Computing por Vecchiola

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

Uma crítica construtiva que pode ser feita a respeito desta arquitetura é sobre o seu estilo, sendo tipicamente em Camadas, toda camada tem uma responsabilidade distinta, além disto, os recursos de cada camada podem ser reorganizados, pois a própria 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 soluções para a manutenção da aplicação e independência entre as partes que a compõem.

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 referência 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 usuário, essa faz uso de balanceadores de carga para distribuir os pedidos de clientes, e ofertar assim, um tempo de resposta melhor a cada solicitação. O balanceador repassa as solicitações para máquinas disponíveis em uma camada inferior. Estas processam as solicitações (HTTP) 42

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

de clientes e repassa ao servidor de aplicação que executa a lógica do aplicativo especificado. Tal execução 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 ações de leitura e escrita no banco. Tal banco, por sua vez, é logicamente particionado em uma camada dedicada a ele; cada partição é controlada por um servidor. Essa abordagem é conhecida na literatura como Esquemas de Particionamento (STONEBRAKER e HELLERSTEIN, 2005), esse conceito foi aplicado não só na camada de banco de dados, como também, na camada dos servidores de aplicação, servidores web e servidores banco de dados. Para Cloud Computing essa arquitetura oferece escalabilidade total e elasticidade em todos os níveis de camada, pois cada solicitação HTTP pode ser encaminhada para qualquer servidor, seja de aplicação, web ou banco de dados; isto se revela como um diferencial que agrega muitos benefícios. Apesar do diferencial a arquitetura foi especificada de forma relativamente superficial. Todavia a arquitetura em questão sacrifica a consistência dos dados devido ao particionamento e a necessidade de se conseguir disponibilidade. Consistência e disponibilidade não são obtidas ao mesmo tempo em nenhum sistema particionado em rede (BREWER, 2000). Com isto é necessário criticar a falta de soluções alternativas que garantam a consistência total aos dados e serviços. 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 propôs uma arquitetura de referência para Cloud Compunting. O objetivo seria definir uma arquitetura única que permitisse aos ambientes de programação nas nuvens: economia no investimento dos recursos necessários, boa qualidade na prestação de serviços e otimização de recursos. A Figura 8 define a IBM Cloud Computing Reference Architecture - CCRA, proposta por Michael Behrendt, 2011. 43

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Figura 8. Arquitetura de Referência Cloud Computing proposta pela IBM

Fonte: IBM Cloud Computing Reference Architecture 2.0

A arquitetura de referência proposta pela IBM é rica em detalhes e abrange um nível maior de complexidade em relação aos serviços; é novamente baseada no conceito de Camadas e, como se pode notar através da Figura 8, existem 02 (duas) grandes camadas externas voltadas à Governança de TI e requisitos de qualidade. A arquitetura foca nos serviços e recursos que a nuvem oferta e necessita, desse modo, os detalhes tecnológicos foram subtraídos na descrição da responsabilidade de cada camada. Tais responsabilidades serão expostas no decorrer desta subseção. Enquanto a camada de Governança trata dos recursos tecnológicos bem como os processos de TI que devem sustentar e melhorar as estratégias e os objetivos organizacionais. A camada de qualidade trata de aspectos voltados a manutenção da segurança, da recuperabilidade do sistema diante às falhas, de desempenho e da “Consumibility”. Consumibility é um termo bastante utilizado pela IBM para expor qual o nível de adequação do produto ao cliente. Seria um requisito de qualidade que vai além dos requisitos de usabilidade, adequação e acurácia, pois além 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 aplicação deve ser atualizada a fim de corrigir erros e agregar melhorias. 44

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Ainda nesse contexto, as três camadas centrais serão 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 módulo a ser desenvolvido deve disponibilizar uma interface provida que ofertará serviços, além de uma interface requerida que exibe quais os serviços necessários (BASS, CLEMENTS, KAZMAN, 2003). A camada de Cloud Service Consumer tem a responsabilidade de alocar os recursos que consomem serviços da nuvem e, ainda alocar as pessoas que serão oneradas pelo uso dos serviços, na qual todos os consumidores poderão interagir com os pacotes de serviços oferecidos pela própria camada. A Cloud Service Consumer possui diversos elementos, dentre eles, o Cloud Service Integration Tools. Esse elemento faz a integração dos serviços da nuvem aos serviços e recursos locais da organização 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 proporcionarão a integração dos recursos de TI da empresa aos recursos da nuvem, podendo conter infraestrutura, Middleware, aplicações de negócios e gestão de serviços. A camada de Cloud Service Provider é a camada da nuvem responsável pela prestação de serviço, onde os componentes têm a liberdade de exibir seus serviços, criar outros serviços, e solicitar serviços a outros componentes. É a camada mais rica em elementos, que são:  Cloud Services: Este elemento além de manter todos os modelos de serviço de

Cloud Computing já conhecidos (SaaS, IaaS, PaaS); contém ainda o Business Process as a Service – BpaaS responsável pela modelagem dos processos de negócio de quaisquer serviços entregues pela nuvem, desde os tradicionais serviços de hospedagem de aplicação, até negociação de compra e venda em Web Commerce. Completando o elemento Cloud Services, está o Cloud Service Creation & Ecosystem Aspects, cuja relação ocorre entre o serviço ofertado pela nuvem e os produtos que podem ser obtidos por meio desses serviços. Por exemplo, é o Cloud Service Creation & Ecosystem Aspects que faz a seguinte correspondência na nuvem:

45

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

O serviço da Amazon EC2 é um eco-sistema voltado para a IaaS em que seus produtos poderão auxiliar na alocação 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 serviços da nuvem e aos clientes que consomem serviços da nuvem.  Infrastructure: representa todos os elementos de infraestrutura necessários para

que os provedores forneçam os serviços para nuvem. Isso engloba todas as instalações necessárias, desde Data Centers e demais recursos de rede, vale mencionar que não 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 irão gerar os serviços da nuvem. Tais ferramentas incluem ambientes da programação de software, ferramentas de layout de interface gráfica, ferramentas para virtualização, e outras. Nesse sentido, após a elucidação de mais uma proposta sobre arquitetura para Cloud, é possível a formulação das seguintes conclusões. Na abordagem da arquitetura, a IBM afirma que Cloud Computing é bastante semelhante à Arquitetura Orientada a Serviços – SOA, pois a Computação nas nuvens é trabalhada em termos de criação, distribuição e consumo de serviços. Portanto, Cloud Computing suporta orientação a serviços, uma vez que as empresas podem oferecer a infraestrutura e a plataforma de desenvolvimento agregadas ao software como um serviço sob demanda. Como consideração sobre esta abordagem é válido observar que a arquitetura é mais orientada aos papéis e funções que são desempenhados em Cloud Computing, explora adequadamente o estilo em camadas, busca flexibilidade e modularidade na manutenção de cada camada, o que fornece maior rapidez no desenvolvimento. Tanto esta arquitetura quanto a arquiteturas apresentada em 2009 são mais conceituais, não exploram em demasia o nível técnico, e trabalham com um nível maior de abstração, sendo que o último modelo exibe mais os aspectos dos serviços que são ofertados pela nuvem e como eles devem ser organizados.

46

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Nas pesquisas de Máquinas Sociais é sempre válido explorar Cloud Computing, pois este é um conceito que visa desenvolver e manter aplicações para WEB 3.0, (TSAI et al, 2011) e consequentemente está repleto de tecnologias que materializam o conceito de Máquinas Sociais. Portanto, na próxima seção, uma arquitetura dedicada a essas tecnologias será exposta, aproveitando o ensejo de que ela surgiu por meio de uma das questões de pesquisa.

3.4.3.

ARQUITETURA

MULTITENANT

DE

REFERÊNCIA

PARA

SOFTWARE AS A SERVICE – QP2

A arquitetura homologada para as aplicações da Force.com, uma das maiores plataformas de desenvolvimento na Computação nas Nuvens, é a Multitenant ou multiinquilino. Essa prevê o compartilhamento da unidade interna computacional, dos dados e da instância física de armazenamento, propiciando assim, a cada desenvolvedor, tão-somente, a preocupação em montar o fluxo de sua aplicação com as regras de negócio. A arquitetura disponibiliza as funções da Force.com compartilhando objetos. Todavia ela executa a distribuição das partições virtuais na plataforma para que outras aplicações ou módulos de sistemas sejam agregados (AZEEZ et al, 2010). O que se faz através da Multitenant é personalizar os objetos disponíveis para que eles atendam a finalidade do negócio (software) reduzindo drasticamente o tempo de desenvolvimento. Na Figura 9 se ilustra a Multitenant. Nela, cada camada desenvolve uma função bem definida. Para isto, elas contam com o auxílio de recursos, como por exemplo: a customização de objetos ou funcionalidades por meio de controladores e de implementações no código Apex (linguagem de programação da Salesforce que compõe a camada “Configuration”) (BEZEMER e ZAIDMAN, 2010). Nesta camada ainda existe a utilização da linguagem de codificação de interface gráfica, a Visualforce (WEISSMAN, 2010).

47

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Figura 9. Esboço da arquitetura Multitenant

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

O estilo Camadas é fundamental para a Multitenant, pois tal estilo proporciona a separação das camadas deixando a lógica da aplicação (camada Configuration) livre para implementar diferentes códigos conforme a aplicação do inquilino. Quanto as demais camadas, a “Authentication” faz apenas o acesso do usuário, ou inquilino. Para cada novo usuário é criado um novo acesso de modo que o inquilino tenha a sensação de que a aplicação é totalmente dedicada (BEZEMER e ZAIDMAN, 2010). A última camada funcional chamada “Database Pool” é responsável por criar registros únicos nos bancos de dados, pois como as aplicações são compartilhadas, existe a necessidade de consultas e inserções individuais nas bases de dados para cada inquilino, o objetivo é garantir que um determinado usuário acesse apenas os seus dados. Neste sentido, para melhorar o desempenho da arquitetura, são utilizados balanceadores de cargas que distribuem os acessos (BEZEMER e ZAIDMAN, 2010). A especificação da arquitetura Multitenant é bem clara, onde cada camada possui uma responsabilidade bem definida tratando de aspectos essenciais a uma aplicação, como o 48

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

cuidado com os dados e bases de dados. Em relação a este aspecto cabe uma crítica; o armazenamento e tratamento dos dados pode ser crítico para algumas aplicações multiinquilino que não utilizem sistemas de banco de dados preparados para lidar com o tipo de arquitetura exposta nesta seção. Diante disto, seria interessante que a arquitetura Multitenant ofertasse uma camada que abstraísse o tratamento dos dados, e que fosse mais específica quanto a este tratamento. Muitos pontos em relação aos dados são delicados, e exigem que a arquitetura trabalhe melhor o isolamento, algo que compõem muitas das exigências de alguns clientes.

3.4.4. ARQUITETURA PARA REDES SOCIAIS – QP3

As arquiteturas investigadas para esse tipo de SM são baseadas no estilo Camadas. Entretanto, essa arquitetura ostenta “formatos” diferenciados que dependem das características e não apenas dos requisitos de cada rede. A mesma arquitetura de referência é explorada tanto pelo microblog Twitter quanto pela poderosa rede Facebook. No entanto, são abordagens diferentes da mesma arquitetura, explorando tecnologias diferentes. Vale salientar que as redes sociais exploradas nessa seção são plataformas programáveis. Com elas, é possível criar novas aplicações utilizando-se apenas a Internet (APIWIKI, 2010). Tal característica as transformam em Máquinas Socias. A seguir, exploremos uma breve sinopse sobre cada rede, com as respectivas tecnologias adotadas e sua arquitetura. O Twitter iniciará a seção. O Twitter foi aberto ao público em meados do ano de 2006, além 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) milhões de usuários. Abaixo, delineamos algumas características importantes dessa rede. O Twitter pode ser acessado via dispositivos móveis. Atualmente o micro-blog possui integração com outras redes sociais. No ano de 2008, foi incorporado um mecanismo de busca ao micro-blog. Outra característica importante do Twitter é a sua API. Ela oferece, entre outros, a busca de serviços que possam ser indexados em aplicações terceiras (AFRAM, 2009). A arquitetura do micro-blog é ilustrada na Figura 10. 49

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Na arquitetura Twitter a camada de apresentação labora com os serviços dos clientes, algumas tecnologias são empregadas como: Json24 e Rails25, a camada realiza ainda renderização e caching. Logo abaixo está a camada de negócio, trabalhada por meio das linguagens C, Java e Scala, esta última favorece a escalabilidade em relação ao crescimento do número de seguidores. Por último encontra-se a camada de dados suportada por bancos de dados não relacionais, os chamados NoSQL, que oferecem resiliência 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 contém uma camada a mais em relação ao Twitter, uma camada dedicada à comunicação, pois o Facebook trabalha com recursos de mídia mais complexos, como fotos e vídeos; nesta questão somente as visualizações das fotos podem ultrapassar o montante de 3 (três) milhões27. Esta rede ainda possui um chat para conversação

24 JSON é uma notação JavaScript que faz a troca de dados entre máquinas. Informações sobre JSON em: http://www.json.org/. 25 Rails é também chamado de Ruby on Rails ou apenas RoR ele é um framework de código aberto escrito na linguagem Ruby. Seu objetivo é aumentar a velocidade e a facilidade de desenvolvimento dos sites. Rails já gera as aplicações no estilo camadas. Informações em: http://www.rubyonrails.pro.br/ 26 Cassandra é um sistema de armazenamento distribuído para gerenciamento de dados estruturados que é projetado para escalar uma grande quantidade de dados entre muitos servidores sem falhar (LAI, 2009) 27 Disponível em: Facebook Developers. Disponível em: http://developers.facebook.com/. Acesso em: 23 de set. 2010.

50

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

entre as pessoas conectadas e registradas como amigos. Por essas características e outras, o Facebook, que hoje é a maior rede social do mundo, tornou-se também um desafio para a escalabilidade. Para prover a escalabilidade, os arquitetos do Facebook usam uma combinação 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 recuperação de fotos (HOFF, 2011). O Facebook além de ser a rede social mais notável da atualidade, se caracteriza fortemente por ser uma plataforma para geração de aplicativos e serviços, que disponibiliza uma API e possui integração com plataformas diferenciadas (FACEBOOK DEVELOPERS, 2010). Apesar disto, as arquiteturas das duas redes possuem particularidades como a seguir. O serviço 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 negócio de ambas as redes para melhorar o desempenho, visto que o Memcached armazena a informação em memórias distribuídas, recuperando-a mais rapidamente, evitando assim, tarefas repetitivas e demoradas de recuperação de informação em banco de dados (GALBRAITH, 2009). Concluindo esta sessão, vale registrar que a arquitetura do Facebook não foi ilustrada neste capítulo, pois não foram encontrados materiais que explicassem em detalhes maiores como as camadas de tal arquitetura interagem. Os materiais capturados faziam referência apenas às decisões de projeto e tecnologias adotadas. Aliás, as arquiteturas das redes sociais exploradas trabalham mais com questões tecnológicas. Neste aspecto foi possível notar que estas arquiteturas se diferem mais em relação às decisões de projeto, ou seja, de quais tecnologias utilizar. Para a definição de qualquer arquitetura é fundamental declarar as decisões de projetos. Estas estão diretamente ligadas ao design da arquitetura. Assim, os resultados da questão sobre as arquiteturas de redes sociais se adaptam mais as decisões de projeto, o que

28

Memcache é um sistema de cachê de objetos em memória concebido para aumentar a velocidade de aplicações dinâmicas aliviando a carga do banco de dados (GALBRAITH, 2009).

51

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

apesar de ser relevante para este estudo, deixa uma lacuna sobre a consolidação de uma modelo arquitetural para estes tipos de SM’s.

3.4.5. ARQUITETURA DE REFERÊNCIA PARA SISTEMAS AUTÔNOMOS – QP4 Um sistema autônomo é aquele que tem mecanismos para se autogerenciar por meio de autocontrole e monitoramento, assim, ele tem a capacidade de adaptar-se aos padrões esperados e especificados; um sistema desta categoria é formado pela colaboração de elementos autogerenciáveis. Segundo Paul Horn (2001) um sistema só é autônomo se ele for flexível para se adaptar às mudanças do ambiente. E, ainda, define como principais propriedades de um sistema autônomo: 1. Autocura: propriedade do sistema que assegura sua recuperação automática após a ocorrência de uma falha; 2. Auto-otimização: ajuste automático dos parâmetros de recurso para otimizar a utilização dos mesmos; 3. Autoproteção: capacidade de se auto defender de ataques ou invasões maliciosas; 4. Autoconfiguração: ajustar a configuração do sistema conforme as variações do ambiente, de modo que, o sistema funcione corretamente satisfazendo a necessidade do usuário (IBM, 2003).

Ademais, definindo as características de um sistema autônomo, o mesmo deve manter relacionamento com outros elementos, em especial, seus provedores e consumidores de serviço (IBM, 2006). Esses relacionamentos irão possibilitar que os sistemas autônomos conheçam o estado uns dos outros e o seu próprio estado, facilitando, desta maneira, a obtenção de dados sobre o estado dos recursos, memórias, volume de dados e também vulnerabilidade (STERRITT e BUSTARD, 2003). Tais dados são obtidos por meio de operações em sensores, como:  Request-Response: operações que são de solicitação ou resposta de sobre o estado de um elemento. 52

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

A comunicação também é necessária para que o sistema altere seu estado ou comportamento conforme necessário. Para esta comunicação, é necessário (IBM, 2003):  Solicit-Response: é a requisição de informações do sistema para sua unidade de controle. Conforme explicado em relação aos sistemas autônomos, nota-se que eles são Máquinas Socias legítimas, sobretudo no aspecto dos relacionamentos. Esses relacionamentos entre sistemas são fundamentais para o próprio aprendizado da máquina. É deste modo que um sistema autônomo consegue se auto gerenciar e tomar decisões. O sistema deve saber qual o seu nível aceitável de funcionamento, as condições que ele poderá ser submetido, e como manter a qualidade dos seus serviços mesmo sobre condições adversas (MCCANN, e HUEBSCHER, 2004). Nota-se aqui que sistemas autônomos também estão fortemente relacionados a inteligência artificial, sistemas especialistas e sistemas baseados em conhecimento; de sorte que podem ser utilizados em sistemas de computação em grade ou computação ubíqua (IBM, 2003). A seguir uma das arquiteturas de referência proposta para esses sistemas autônomos será explorada. A arquitetura foi proposta por Mccann, e Huebscher em 2004; e também por White et al., em 2004. As explicações sobre esta arquitetura foram baseadas nos trabalhos destes estudiosos.

3.4.5.1.

Arquitetura Autônoma Proposta por Mccann, Huebscher e White et al

A Figura 11 representa o esboço da arquitetura de referência para um sistema autônomo em que sondas são inseridas na arquitetura para monitorar o sistema. Essas sondas ou sensores captam informações do ambiente externo e repassam para outros tipos de sensores, estes irão comparar os dados capturados às variáveis especificadas para o sistema, ou seja, aos requisitos desejados em desempenho, tolerância à falha e outros.

53

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Figura 11. Esboço de arquitetura para sistemas autônomos

Após a captura e análise dos parâmetros, o elemento responsável pelo controle do sistema, chamado de gerenciador ou calibrador, faz uso das informações analisadas para controlar e adaptar a operação do sistema, a fim de atingir o comportamento desejado. Esse calibrador deve interagir diretamente com a camada de negócio do sistema, ou ainda, compor esta camada. A arquitetura de um sistema autônomo 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 lógica de negócio 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 limitações do sistema. O estilo arquitetural Peer-to-peer29 geralmente é uma excelente escolha para a segunda parte da arquitetura de um sistema autônomo, pois esse modelo de sistema tem como forte característica a distribuição. Tal característica é forte porque comumente todos os elementos da arquitetura do sistema são também autônomos, onde cada camada pode ter sua própria arquitetura autônoma. Isto se revela como uma crítica positiva a esta arquitetura.

29

Arquitetura distribuída onde cada par, ou nodo, possui uma função distinta (STERRITT, e BUSTARD, 2003)

54

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Outra interpretação que se pode ter é que a arquitetura de um sistema autônomo pode ser dupla. Uma arquitetura assegura a infraestrutura que permite o monitoramento e análise dos componentes, enquanto a outra é a própria arquitetura do sistema que garante o correto funcionamento dos requisitos. Ambas estão entrelaçadas. Esta interpretação não é definitiva, a própria arquitetura não foi exibida desta maneira, nem ao menos existiram suposições a respeito disto, o que pode se revelar como um fator negativo na especificação desta arquitetura. Não obstante ao modelo apresentado, ele não é o único. Existem outras abordagens, inclusive defendidas por grandes empresas como a IBM (IBM, 2003).

3.4.5.2.

Arquitetura Autônoma Proposta Pela Empresa IBM

Segundo a IBM uma arquitetura de referência para computação autonômica deve realizar três objetivos fundamentais. Primeiramente, deve descrever as interfaces externas e comportamentos necessários 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 autogestão do sistema. A arquitetura IBM é explicada em seguida:

Figura 12. Arquitetura de referência proposta pela empresa IBM para computação autônoma

Fonte: IBM, 2003

55

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Como ilustrado na Figura 12 a arquitetura é composta por duas camadas mais inferiores que exercem, respectivamente, as funções, de conter recursos físicos de infraestrutura de TI ou mesmo softwares de gestão; e prover interfaces de gerenciamento para controlar os recursos gerenciados. Essas interfaces padrão são entregues através de um terminal de gerenciamento. A terceira camada chamada Touchpoint Autonomic Managers contém gerentes autônomos de quatro categorias de autogestão, a auto configurável, autocura, auto- otimização e autoproteção). A camada acima desta, contém gestores autônomos que orquestram outros gestores de cada categoria. Essa camada oferece a capacidade autônoma ao sistema, incorporando maior controle sobre a infra-estrutura geral de TI.

A camada mais superior fornece interfaces de comunicação entre os usuários e o sistemas, e entre estes sistemas e outros, facilitando a integração dos mesmos. A explicação desta arquitetura não será rica em detalhes, pois a IBM, apesar de afirmar que a mesma pode ser aplicada aos sistemas autônomos, classifica a arquitetura como sendo de referência para computação autônoma em si. Contudo, seria interessante expor a arquitetura neste trabalho, uma vez que, a diferença entre os conceitos de sistema e computação sejam muito sutis, os sistemas se prevalecem dos conceitos da computação, e ambos abordam as premissas da autogestão. Cabe uma singela crítica a esta arquitetura; ela não demonstrou como o objetivo de cada camada pode ser alcançado, mesmo que em alto nível, por ser uma arquitetura de referência. Em todo o trabalho publicado no ano de 2003, a arquitetura apenas elegeu o uso de Web Services para viabilizar a comunicação entre as interfaces de comunicação, bem como, a adoção de Enterprise Service Bus - ESB para servir de barramento de integração entre as camadas da arquitetura. Contudo a IBM deixou evidente em sua proposta, que o mais importante em uma arquitetura para este tipo de SM’s é definir precisamente o comportamento dos componentes arquiteturais e de suas interfaces de comunicação.

3.4.6. ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2.0 – QP5 O livro Web 2.0 Architectures de James Governor, et al. (2009), sugere uma arquitetura de referência para aplicações originais da WEB 2.0 nestas estariam aplicações 56

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

como Mashups e alguns tipos de redes sociais como o Flickr30. A arquitetura proposta é ilustrada na próxima imagem.

Figura 13. Arquitetura de referência para aplicações WEB 2.0 Fonte: Adaptada de James Governor, livro: Web 2.0 Architectures; ano 2009

Os componentes desta arquitetura possuem a seguinte definição:  Resource Tier – É a base, ou infraestrutura que armazena todos os recursos que capacitam os serviços da aplicação. Nesta camada residem os banco de dados, interfaces com sistemas, diretórios, e outros. Esta camada pode ter subdivisões que a tornam capaz de fazer a persistência de banco de dados;   Service Tier – Camada de serviços é responsável pela conexão destes serviços ofertando controle sobre o fluxo de informações que transitam por entre a aplicação. Conectivity (setas entre as camadas centrais) – Podem ser protocolos e padrões que permitem o acesso aos serviços. Tais conexões devem exibir os serviços deixando clara a responsabilidade de cada um;  Client Application Tier – É a camada em que o usuário acessa para consumir os serviços da aplicação, nesta camada podem residir ferramentas que melhorem a interaçao do usuário com a aplicação;

30

Rede de compartilhamento de fotos. Disponível em: www.flickr .com

57

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Design, Development, and Governance Tools – Esta camada é de suporte ao desenvolvimento, pois contém um conjunto de ferramentas que auxilia os desenvolvedores. As ferramentas podem ser ainda utilizadas no desenvolvimento dos componentes das camadas de serviço e cliente. Esta camada é interessante para customizar outras camadas e assim expandir e modificar as arquiteturas de aplicações que usem esta arquitetura de referência. Esta arquitetura de referência é interessante por ofertar uma divisão inteligente das

responsabilidades de cada camada. O seguinte exercício pode auxiliar em uma maior compreensão. Supondo que seja necessário construir uma aplicação Web 2.0 que possa fazer conexão com alguma API de outra aplicação. Neste caso, seria necessáiro contruir uma interface na camada Resource Tier. Entretanto, se a aplicação em questão necessitar ter usa própria API a camada Service Tier será a responsável. Tal camada irá definir protocolos de acesso aos serviços e esses protocolos são os elementos arquiteturais Conectivity. Essa arquitetura é um modelo para aplicações da segunda geração da Internet. Tal modelo é útil por mostrar o objetivo de uma arquitetura de referência dedicada a Web, em que algumas dessas aplicações, como os Mashups, são também da Web 3.0, e assim, Máquinas Sociais. Fica nítido que a arquitetura é bem genérica, ficando sucetível à implantação de tecnologias diversas, como: framework e Web services. Vale lembrar que essa capacidade de implantação de tecnologias diversas foi classificada como um problema nesta pesquisa, haja vista, a heterogeneidade excessiva de tecnologias agregue potencialmente retrabalho ao desenvolvimento. Além deste ponto de heterogeneidade a arquitetura nem ao menos sugeriu alguma tecnologia, ou padrão, para auxiliar na responsabilidade das camadas. Durante a pesquisa, todas as arquiteturas de referência para a Web que se sucederam foram estudos replicados deste. Não verificou-se nenhuma evolução 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 próximo capítulo, pode vir a ser uma substituta moderna da arquitetura Web 2.0, uma substituta que só ocorreu devido ao novo paradigma de Máquinas Sociais, que traduzem de outra forma as aplicações Web e a própria web.

58

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

3.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO – CRÍTICAS Ao longo do estudo, várias pesquisas foram analisadas, algumas corresponderam perfeitamente às questões investigadas, outras mostraram pouca contribuição. Neste sentido, foi interessante verificar que a arquitetura de referência para aplicações Web foi tão pouco abordada, apenas o estudo de James Governor considerou o assunto de maneira mais clara e objetiva. O fato das aplicações Web serem desiguais em termos de funcionalidade e de tecnologia pode ter motivado um relativa falta de classificação, o que talvez tenha dificultado a criação de uma arquitetura de referência. Classificando as aplicações Web 3.0 como Máquinas Sociais, é possível visualizar uma melhor solução em arquiteturas de referências, pois que se conhece, e se define melhor, os aspectos e particularidades das aplicações. O mesmo ocorre com os conceitos de Cloud Computing, ao passo que, quando se definiu melhor os conceitos de CC, foi possível encontrar muitos materiais que tratem do assunto por aspectos diferenciados. Ao finalizar o estudo é possível mapear certas tendências sobre algumas tecnologias, as quais foram utilizadas e relatadas repetidamente entre as arquiteturas. Essas tendências apontam para:        Construção de API’s próprias; As API’s podem contribuir diretamente para a extensibilidade da Máquina Social; Utilização de API’s: API Java; API Twitter 4J, e API Facebook; Utilização de balanceadores de carga para prover desempenho; Utilização de Web Services; Aplicação dos protocolos REST e SOAP; Definição de arquiteturas com a camada de infraestrutura suportada por Computação nas Nuvens; Utilização de linguagens de programação que facilitem a rapidez na codificação além de contribuir para o desempenho e escalabilidade do sistema, como por exemplo: a adoção da linguagem Rails que já suporta PHP e REST;  Aplicação do estilo arquitetural Camadas.

Ao fim desta seção, vale observar o intensivo uso do estilo arquitetural em Camadas, o qual organiza o sistema em unidades hierárquicas, se comportando como a evolução do 59

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

estilo cliente servidor, visto que as camadas solicitam serviços uma das outras, interagindo entre elas como cliente e servido (GAMMA, et al 2000). Alguns autores defendem a adoção 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 apresentação, proporcionando assim, uma visão de módulos31 essencial para a documentação do sistema. As tendências pontuadas acima dão indícios que podem auxiliar no desenvolvimento de SM’s, pois as soluções que se repetiram ao longo dos estudos foram empregadas em grandes projetos dentro da indústria de software. Além deste ponto, as soluções mapeadas contribuem, a priori, para a escalabilidade, proteção contra falhas, distribuição e comunicação. Todos estes fatores estão ligados as características das SM’s, enquanto outros fatores provocam controvérsias na aplicação das arquiteturas estudadas, o que será relatado a seguir. Materiais publicados e investigados para esta pesquisa revelam que algumas das Máquinas Sociais exploradas se mantiveram eficientes, enquanto outras simplesmente saíram do mercado. Como, por exemplo, as ferramentas online para desenvolvimento de Mashups. Outro ponto questionável é a falta de mecanismos que previnam a interrupção de alguns serviços Cloud Computing, como exemplo, o problema da Amazon (IaaS) no ano de 2011. Segundo publicação da própria Amazon, no dia 21 de abril de 2011 o serviço EC2 foi desabilitado devido a um problema técnico que causou falha no fornecimento do serviço de uma das zonas de disponibilidade da Amazon. Esta zona trabalhava para os Estados Unidos e deixou usuários do leste do país sem o serviço 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 serviços e camadas dependentes. No modelo Camadas ocorre forte dependência entre as camadas, se fazendo necessário alguns artifícios que previnam a falha de uma camada ou que sustentem o serviço mesmo que sobre um problema.

31 Perspectiva que mapeia os módulos do sistema. Módulos são entidades que implementam um conjunto de funcionalidades para o sistema (SHAW, GARLAN, 1996)

60

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

Entre controvérsias e conformidades a tecnologia empregada faz total diferença. A falha da Amazon é só um exemplo dos fatores negativos que a arquitetura de uma SM deve estar preparada para enfrentar. Outra crítica é a heterogeneidade de plataformas, como as Máquinas Socias são sistemas distribuídos por natureza, deve-se notar que existem algumas diferenças tecnológicas, sejam em linguagens, sistemas operacionais ou paradigmas de desenvolvimento em SM que hora são fornecedoras de serviços, hora são consumidoras de serviços. Portanto, todas as decisões em projeto de SM’s devem ser bem analisadas e empregadas na arquitetura. A interoperabilidade é outro ponto preocupante na análise deste estudo, os elementos arquiteturais devem trabalhar bem sobre este ponto, arquiteturas orientadas a serviços, e adoção de protocolos como REST e SOAP, são iniciativas inteligentes que vem gerando resultados produtivos nas aplicações mapeadas, mas que de fato, podem não ser tão eficientes para algumas Máquinas Sociais. Neste aspecto, a Computação nas Nuvens é um ponto de grande desafio, por isso o quantitativo de pesquisas e experiências tem sido tão significativo, impulsionando os padrões que facilitam a comunicação e interoperabilidade em plataformas e aplicativos nas nuvens (DMTF, 2011), bem como a criação de pacotes de desenvolvimento SDK que algumas linguagens de programação 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 físicos, o que poderá ser um fator de insegurança para alguns sistemas, apesar de favorecer fortemente o crescimento da aplicação, em virtude da facilidade dos recursos. O resultado deste estudo mostra boas direções para se atingir o objetivo deste trabalho, entretanto, no contexto de desenvolvimento de software, tão importante quanto o aspecto tecnológico, é o processo de concepção arquitetural. É extremamente relevante conhecer o que se deseja construir, quais serviços são necessários, onde podem ser encontrados, como será feita a comunicação e serviços e como elas irão impactar no comportamento do software ou aplicação. Assim, o próximo capítulo trará um material útil para se obter tais conhecimentos e fundamentar uma boa arquitetura para as SM’s. Tecer críticas, sejam elas positivas ou negativas, a respeito de arquiteturas é algo delicado, haja vista a arquitetura seja muito particular ao software. Arquiteturas que podem não parecer muito inteligentes fazem um software funcionar por anos. O que se pode 61

Capítulo 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais

certamente afirmar é que toda arquitetura deve ser coerente aos requisitos não funcionais. Com isto, na exibição de uma arquitetura, é importante deixar claro quais os requisitos atendidos por ela. Isto não foi verificado para os estudos mapeados neste capítulo. Além do problema acima relatado, existe também a ausência de um modelo de referência em conjunto ao estilo arquitetural adotado para as arquiteturas que são de referência. Como será visto no próximo capítulo, isto é fundamental para criação da arquitetura, por serem informações que influenciarão nas decisões de projeto da mesma. Para finalizar este capítulo, a tabela 3 sumariza, para as Máquinas Sociais, todos os pontos relevantes que foram tratados, ou não, pelas arquiteturas. Os pontos são importantes para as SM’s e ofertarão subsidio para a formulação da arquitetura de referência. Com a tabela, é possível notar que o atendimento as necessidades materializa os requisitos mais tratados pelas arquiteturas. São eles: performance por meio da expansão da arquitetura e modificabilidade por meio da manutenção.
Computing_Kossmann et al, Arquitetura Mashup_Merril Computing_Vecchiola 2009 Huebscher, White et al,IBM Arquitetura Autônoma 2004 2003 Necessidades atendidas

Arquitetura Redes Sociais

Arquitetura Mashup_Liu

Serviços Comunicação Facilitada Manutenção Facilitada Infraestrutura Reatividade Conectividade Expansão

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

X

X

Tabela 3. Pontos ou aspectos mais trabalhados pelas arquiteturas

Arquitetura para Web 2.0

Arquitetura Multitenant

Computing_IBM, 2011

Autônomos_Mccann,

Arquitetura Sistemas

Arquitetura Cloud

Arquitetura Cloud

2010 Arquitetura Cloud

(Hoof ; Aurin)

2006

2009

62

Capítulo

4
4. Proposta de Arquitetura de Referência Para Máquinas Sociais
Este capítulo propõe uma arquitetura de referência para Máquinas Sociais. Nele serão abordados alguns conceitos sobre arquitetura de referência, a respeito das suas teorias e concepção. A arquitetura de referência de Máquinas Sociais será exibida em visões. A avaliação na qual essa arquitetura foi submetida também será exposta neste capítulo, mostrando assim, como esta proposta pode ser adequada para as Máquinas Sociais.

63

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

4.1. INTRODUÇÃO

O estudo no capítulo anterior é um recurso que também objetiva mostrar o estado da arte das arquiteturas de aplicações Web contextualizadas como Máquinas Socias. Apesar de tais aplicações não deixarem evidente todas as particularidades e detalhes de suas arquiteturas, foi possível entender a organização e concepção das mesmas, além ter um estudo de referência para SM’s. Através desde estudo é possível dispor de um protótipo de arquitetura de referência para Máquinas Sociais. Trata-se de um modelo experimental que deve servir de precedente aos exemplares de arquiteturas de SM’s. Como visto no capítulo 2, as SM’s podem ser classificadas desde aplicações Web simples até frameworks e IaaS, com isto, a formulação de uma arquitetura padrão para essas SM’s demandaria um tempo de pesquisa consideravelmente maior, daí a intenção de sugerir um protótipo apenas para Máquinas Sociais que sejam aplicações Web e que sejam do tipo Prossumers. O objetivo de ofertar esse modelo é ter uma arquitetura que possa orientar no processo de definição das arquiteturas de SM’s a serem construídas. Ou seja, essa arquitetura seria um exemplo de como deve ser a arquitetura de uma SM, e deve ser entendida como o arcabouço básico que será customizado conforme os requisitos da Máquina Social. Vale frisar que tal modelo é mais adequado às SM’s que são aplicações 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 referência. Para se construir uma arquitetura de SM é necessário entender o software como uma Máquina Social, e assim poder agir assertivamente sobre as análises e decisões de projeto e consequentemente sobre a arquitetura. Deste modo tal arquitetura de referência parece ser ideal justamente por ser um ponto de início para as arquiteturas de sistemas que resolvem problemas de um mesmo domínio.

4.2. ARQUITETURA DE REFERÊNCIA

A intenção de originar uma arquitetura de referência parte do conceito de que a arquitetura divide as funcionalidades e os fluxos de cada parte do software, demonstrando 64

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

como pode ocorrer a cooperação entre elas (BASS, CLEMENTS, e KAZMAN, 2003). A arquitetura de referência facilitará o desenvolvimento modular do software que for projetado acima dela. Esse desenvolvimento traz benefícios, como: redução do tempo de desenvolvimento, pois já é um modelo que pode ser adaptado para a arquitetura; aumento do reuso de software; auxílio para a equipe de desenvolvimento evitar erros já cometidos. Por fim, arquiteturas de referência sugerem a implementação de módulos que tenham interfaces bem definidas, tanto as Interfaces Providas, que disponibilizam serviços, como as Interfaces Requeridas, que expõem as necessidades dos serviços, ou seja, a quem o módulo precisa se conectar (GARLAN e SHAW, 1994). Uma arquitetura de referência se origina de um ou mais padrões arquiteturais, e de um modelo de referência32. A Figura 14 esquematiza esse raciocínio.

Modelo de Referência
Padrão ou Estilo Arquitetural

Arquitetura de Referência

Arquitetura de Software

Figura 14. Relação entre modelo de referência, padrões arquiteturais e arquitetura de referência

Fonte: Adaptação do livro Software Architecture in Practice, 2003. 2ed. Addison Wesley.

Modelos de referência são soluções a nível de negócio que tratam de problemas de um mesmo domínio; os estilos ou padrões arquiteturais são os modelos que agrupam os componentes arquiteturais de modo que os mesmos possam interagir sempre da mesma forma, auxiliando assim na resolução de um problema (GOVERNOR, 2009). Seguindo tais conceitos atingiram-se as arquiteturas de referência, que apresentam soluções técnicas às arquiteturas de uma família de software (MULLER, 2011). Para se compor uma arquitetura de referência é necessário trabalhar veementemente no processo de formação com os requisitos não funcionais (qualidade); é necessário ainda interagir com pessoas que façam parte do modelo de negócio para se obter informações sobre o contexto de negócio e requisitos inerentes ao mesmo. Por fim, no processo de formalização

32

Modelo de referência é um padrão de decomposição de um domínio de negócio ou problema conhecido (GARLAN SHAW, 1993].

65

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

de uma arquitetura de referência é necessário considerar fatores tecnológicos, conceitos, requisitos de clientes, padrões e abordagens de desenvolvimento de software. A tarefa de identificação dos clientes, para extração de requisitos, é a mais crítica, haja vista que a extração dos conhecimentos exija fontes mais abrangentes, como: documentos, pesquisas, ferramentas e profissionais, pois se trata de uma arquitetura muita genérica. O que deve ser considerado para compor o processo de definição de uma arquitetura de referência é exaltado nos estudos de Muller em 2011 e Nakagawa em 2006. Ambos foram referência para este capítulo. As exigências em projetos de arquitetura de referência são grandes por necessitarem de observações em domínios ou famílias de softwares de modo que se possa definir uma arquitetura genérica na qual desenvolvedores possam se basear para montar a arquitetura do sistema (BASS, CLEMENTS, e KAZMAN, 2003) a ser desenvolvido. Arquiteturas de referência são instanciadas em um projeto de software, e podem existir ou serem utilizadas em diferentes níveis de abstração a partir de diversas perspectivas (BASS, CLEMENTS, e KAZMAN, 2003). O processo de formalização da arquitetura de referência ainda pode ser facilitado quando se conhece experiências de arquiteturas já existentes para o domínio. Em uma análise dessas arquiteturas é possível detectar a eficiência, ou não, das mesmas para a solução do problema, isto possibilita uma visão mais objetiva das soluções que podem ser empregadas para o domínio.

4.3. ARQUITETURA DE REFERÊNCIA PARA MÁQUINAS SOCIAIS

A arquitetura de referência que será formalizada deverá atuar como ponto inicial para o desenvolvimento das arquiteturas de aplicações que fazem parte do modelo de referência no qual as Máquinas Sociais estão inseridas. O estudo do capítulo 3 dirigido à arquitetura de Máquinas Sociais será muito útil para absolver as experiências com arquiteturas direcionadas as Máquinas Sociais. Enquanto isto todos os estudos feitos pela Universidade Federal de Pernambuco e por organizações como o C.E.S.A.R (Centro de Estudos Avançados do Recife) que resultaram na criação de um grupo direcionado ao estudo de SM’s, contribui fortemente para a identificação das fontes de informação (clientes) e para o amadurecimentos do Modelo de Referência.

66

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

A arquitetura de referência deve trabalhar bem os requisitos performance, disponibilidade, modificabilidade, e interoperabilidade, o que na realidade não ocorreu em todas as arquiteturas mapeadas no estudo do capítulo anterior. Assim, nem todas as arquiteturas trataram as necessidades e requisitos fundamentais da Máquina Social. Apenas os requisitos performance e modificabilidade foram mais trabalhados. A tabela 4 pretende evidenciar as características e necessidades das SM’s e como estas estão relacionadas aos requisitos não funcionais. A mesma tabela contribui para a compreensão de como os requisitos podem ser satisfeitos pela arquitetura. Aqui se deve entender que os requisitos não funcionais visam agregar benefícios e recursos que são exigidos pelas características da Máquina Social. Outra compreensão correta, é a de que as soluções propostas para atender os requisitos na arquitetura não são únicas, existem outras que podem ser trabalhadas conforme a característica da requisição. O mais importante é projetar a arquitetura de referência para que ela seja capaz de atender todos os requisitos e características/necessidades exibidas na tabela abaixo.

Requisitos

Características e Necessidades das SM’s

Solução de Atendimento

Performance

Reatividade, Infraestrutura, Autonomia, expansão e Serviços

1ª Controle sobre a geração de eventos; 2ª Diminuir os elementos intermediários comunicação; 3ª Trabalhar bem com a infraestrutura conectividade. e com a de

Disponibilidade

Constância, Sociabilidade, Reatividade, Infraestrutura, Serviços, Colaboração e Comunicação facilitada

1ª Redundância: caso um elemento fique indisponível, a redundância (outro

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

verifiquem e alertem sobre 67

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

possíveis falhas. Modificabilidade Sociabilidade, Manutenção facilitada, e Autonomia 1ª Elementos arquiteturais33 que facilitem a manutenção da SM. 2ª Separar responsabilidades em camadas; 3ª Manter a coerência

semântica para facilitar a identificação arquitetural. 4ª Isolar funcionalidades que possam alteradas. 5ª Inserir elementos ser facilmente do elemento

intermediários que diminuam a dependência. Interoperabilidade Colaboração, Infraestrutura, Sociabilidade e Conectividade. 1ª Identificar e trabalhar com as interfaces providas e

requeridas; 2ª Trabalhar com padrões de interoperabilidade.

Tabela 4. Atendimento aos requisitos pela arquitetura conforme as características e necessidades da SM.

Após visualizar e entender ainda mais a questão dos requisitos não funcionais, é importante dar foco as outras questões arquiteturais como o estilo arquitetural. O estilo arquitetural a ser adotado é o estilo em Camadas, o mesmo que foi a grande tendência do estudo mapeado, o que poderia ser esperado, pois tal estilo é extensamente utilizado para desenvolver aplicações Web. À vista disso a arquitetura de referência para Máquinas Socias está ilustrada na Figura 15. Seus pontos serão explicados em seguida, bem como demais visões da mesma.

33

Casos de uso, classes, camadas e demais componentes que constituem as visões arquiteturais.

68

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

É importante colocar que a descrição arquitetural documentada nesta pesquisa está de acordo com a norma IEEE 1471 (IEEE, 2000) que recomenda a especificação da arquitetura ou os documentos arquiteturais:    Com os elementos arquiteturais identificados, organizados, e com suas responsabilidades bem definidas; Com os requisitos relevantes a nível arquitetural, atendidos pela arquitetura definida; Com a representação de diferentes visões arquiteturais.

A Figura 15 exposta abaixo retrata a arquitetura por uma visão de módulos, exibindo as camadas e suas interações. O objetivo desta visão é expor a Máquina Social em unidades, mostrando a dependência entre tais unidades. Por meio da visão é possível exibir mais facilmente o tratamento a alguns requisitos, como: portabilidade, reuso e interoperabilidade; além disto, é possível representar a arquitetura da Máquina Social em tempo de desenvolvimento, ou seja, de módulos a serem realmente estruturados e alinhados (KRUCHTEN, 1995).

Figura 15. Arquitetura de Referência para SM’s

69

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

A primeira camada é a Presentation. Esta é uma camada básica de interação com o usuário. Esta camada pode ser implementada de diversas maneiras, ou seja, para algumas SM’s ela pode ser apenas uma camada onde as SM’s requisitantes (clientes) estejão alojadas. Este seria o caso de Máquina Sociais como o MapReduce e outras PaaS e IaaS. Essa camada pode ser ainda a uma camada capaz de produzir qualquer interface de apresentação e exibição de dados. Tal camada pode ainda, porventura, nem existir na SM, mas sim, ser concebida por outra Máquina Social, como no caso dos sites Mashups. Deste modo, a Presentation não será especificada neste trabalho, sua criação dependerá fortemente do tipo de SM a ser construída. Entre a primeira camada, seja ela de qualquer natureza, e a segunda camada, existem os balanceadores de carga que vão distribuir as solicitações de acesso (requests), estes atendem ao requisito desempenho. Os balanceadores são apenas um exemplo, pois o que se propõem na verdade são mecanismos que façam o tratamento em blocos das solicitações. Isto melhorará o desempenho consideravelmente se comparado ao tratamento e processamento individual das requisições. A camada Wrapper é sem dúvida uma das mais relevantes para a Máquina Social, ela é uma camada dedicada à comunicação e interoperabilidade. Além de viabilizar a conexão entre as SM’s, esta camada é a implementação do elemento Wrapper citado no capítulo 2. É inteligente pensar que ela poderia ser concebida como a API da Máquina Social, sendo que uma API é um conjunto de requests e responses (KALIN, 2010). Assim, os métodos válidos para criar uma API poderiam ser utilizados. Com a API na camada Wrapper é possível expor os serviços da aplicação de modo que outras aplicações usufruam destes serviços, ou funcionalidades, sem se preocupar com alguma implementação adicional. Nesta parte da arquitetura o surgimento dos formatos XML ou JSON é fato, bem como, a implantação de Web Services para apresentar os serviços disponíveis. As linguagens XML e JSON facilitam o cumprimento do requisito de interoperabilidade. Trata-se, na verdade, de linguagens de grande flexibilidade e poder semântico (TITTEL, 2003) com troca de informações independente de plataforma ou tecnologia. A camada seguinte é a camada Processing Unit, uma camada voltada ao negócio e responsável por bastante processamento; é nela que devem existir mecanismos para verificar e divulgar informações da SM, como o status do funcionamento da mesma. Este mecanismo é a 70

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

implementação do elemento State. A camada Processing Unit é também um elemento da SM que além de monitorar, deve ainda satisfazer as funcionalidades da mesma. Tal camada deve ter componentes que atendam as funcionalidades e satisfação dos requisitos funcionais da Máquina Social (Controllers e Services). A Processing Unit é, em conjunto à camada Wrapper, a mais importante para a SM, e também pode ser a mais complexa de se conceber. A Processing Unit implementa o elemento Constraints. Nele será possível obter as limitações, a carga de trabalho e o tempo de resposta aceitável de uma Máquina Social. Outra característica importante da camada Processing Unit é a comunicação perfeita com a camada anterior a ela, a camada Wrapper, haja vista todos os produtos gerados pelo componente State devem ser refletidos também na camada Wrapper para que a mesma saiba o “status” de cada serviço. No trecho acima a camada de negócio 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 alteração das Constraints não compromete outros componentes da Máquina Social. O produto desta camada é insumo para o funcionamento da camada de repositório de dados. A próxima apresentação é justamente sobre a camada de infraestrutura e acesso a dados. A camada Persistence/Infrastruture é a camada de suporte da Máquina Social. Ela é responsável por serviços de hospedagem para o desenvolvimento da aplicação; serviços de capacidade computacional, ofertando recursos necessários ao desenvolvimento; e serviços de armazenamento de dados. Nesta camada é possível verificar, analisar e direcionar as demandas de acesso aos dados. Por tratar as solicitações de registro e consulta, tal camada pode monitorar o tempo e a adequabilidade das respostas, trabalhando iniciativas de correção caso algo esteja fora do padrão aceitável pelas Constraints. Os bancos de dados e a infraestruutra computacional são uma parte ligada à arquitetura, e não necessariamente contida nesta. Deve-se ter esse entendimento uma vez que, a camada de banco de dados não necessita ser implementada pela equipe desenvolvedora da Máquina Social. Assim, entende-se que tal camada pode ser disponibilizada por meio de um serviço Cloud Computing, o que facilitaria a réplica destas camadas auxiliando na satisfação do requisito disponibilidade. Para atingir esse requisito é necessário que os componentes

71

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

estejam sincronizados. O artifício de possuir réplicas pode, inclusive, ser utilizado para outras camadas arquiteturais. A decisão por obter um serviço Cloud Computing é algo muito particular de cada aplicação, devem-se analisar as necessidades da SM, os custos, a segurança, e os recursos de replicação. Em um projeto de Máquina Social os serviços de Cloud Computing podem ser muito úteis à equipe de desenvolvimento, sendo que, esta não teria preocupação com a manutenção ou preparação de máquinas servidoras (ZHANG e ZHOU, 2009). Para finalizar é importante esclarecer que esta arquitetura de referência deve ser customizada levando em consideração a finalidade da Máquina Social e todos os seus requisitos funcionais, e principalmente sua taxonomia. Como por exemplo: a camada Wrapper pode se comportar também como uma camada de aplicação em casos onde uma Máquina Social possa estar conectada com muitas outras SM’s que sejam clientes dela.

4.4. VISÕES DA ARQUITETURA DE REFERÊNCIA

Após descrever a arquitetura, a visão de implantação será ilustrada. Por meio dela, será possível visualizar todas as Máquinas Sociais que compõem a arquitetura de referência e como as mesmas distribuem o processamento da aplicação. Essas SM’s interagem umas com as outras executando funções diferentes e assim se completando (GORTON, 2006). Por meio desta visão, é possível avaliar ainda os requisitos não funcionais de desempenho e disponibilidade (KRUTCHEN, 1995). Ela dividirá a arquitetura em nós processadores e componentes executáveis, o que dará a visibilidade de que uma Máquina Social é composta por outras Máquinas Sociais.

72

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

Figura 16. Visão de Implantação

Em um diagrama de implantação, geralmente é exibido a especificação de cada nó, ou seja, qual o tipo de sistema operacional, a especificação da máquina, ou ainda o sistema de banco de dados a ser implantado no nó. Todavia, não deve-se em uma arquitetura de referência fixar especificação de tecnologias ou máquinas (MULLER, 2011). Deste modo, fica ilustrado apenas a localização dos nós com as especificações: device e Database - DB. Por meio do diagrama na figura 16, é possível notar a ditribuição física de cada componente, ou como representado anteriormente, de cada camada da Máquina Social. A distribuição em nós diferentes não é algo obrigatório, isto dependerá muito do tipo de Máquina Social. Por exemplo: em SM’s mais simples que façam rotineiramente atividades de consulta e inserção de dados, seria interessante ter um nó maior constituído pelas camadas Presentation e Wrapper. Isto traria um aumento de desempenho da SM. Então, a alocação das camadas aos nós computacionais para todos os tipos de Máquinas Sociais pode variar entre 1 nó ou 3 nós. Aproveitando o ensejo, é importante novamente frisar que o nó Persistence/Infrastruture é satisfeito por uma Máquina Social com serviços Cloud Computing. Serão exibidas outras visões de partes da arquitetura. Estas partes correspondem às duas camadas mais importantes para a SM, a camada Wrapper e Processing Unit.

73

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

Figura 17. Diagrama de Classe (Visão de módulos_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 compõem. Nota-se que um terceiro componente do Processing Unit (Controllers/Services) não está presente na visão. Sua exclusão foi proposital, visto que o mesmo é um elemento que deve agregar muitas outras classes funcionais da SM que irão contemplar as funcionalidades da Máquina Social e que terão comportamentos e relações muito particulares e relativos aos requisitos funcionais. Nesta visão, o entendimento deve ser de que o primeiro subsistema se relaciona com o segundo por intermédio de uma classe abstrata que diminuirá o acoplamento entre as classes. Essa redução é importante para possibilitar o atendimento ao requisito de modificabilidade. Uma classe abstrata age como uma interface mais robusta, capaz de ofertar independência (GAMMA et al, 2000) entre as classes no sentido que elas possam sofrer alterações sem atingir fortemente as classes relacionadas a ela. Para otimizar o acoplamento baixo, o padrão de projeto Facade deve ser incorporado, pois o mesmo é especialista em unificar interface facilitando o acesso aos subsistemas e independência entre as classes. A inserção de mecanismos contra o acoplamento alto não prejudicará o relacionamento dos subsistemas, pois a classe

74

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

LearningStatus possui apenas a função de capturar os dados da classe States para assim montar o estado dos serviços, 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 situação dos serviços da Máquina 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 necessário (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 relação entre estes dois subsistemas, será ilustrado, para a camada Wrapper, um diagrama de componentes com portas e interfaces. Através desta visão, é possível verificar a colaboração entre os componentes ou classes, (BOOCH, RUMBAUGN, JACOBSON, 2005) bem como os serviços que cada componente pode prover ou requerer para a SM’s. A Wrapper é a interface da SM que exibe todos os serviços providos e requeridos pela mesma. Neste ponto, a Wrapper pode ser visualizada como um conjunto de rotinas que pode evidenciar a utilização das funcionalidades da SM’s. Para possibilitar o trabalho da Wrapper é necessário que a mesma esteja sempre ciente do estado dos serviços da SM, assim, é necessário um componente que leia o estado da Máquina Social disponível pelo componente State na camada de Processing Unit. A Figura 18 ilustra esta visão de componentes e conectores. Após obter os dados da Máquina Social e determinar a situação dos serviços, é necessário disponibilizar essa situação para o componente responsável pela mediação entre a Máquina Social e as demais aplicações interligadas. Esse componente pode ser um Web Service ou ainda um Middleware flexível que facilite a integração e comunicação entre as aplicações. O que interessa é possuir um elemento que seja na verdade um programa computacional que faça o transporte das informações e dados entre as aplicações de forma independente de protocolos e plataformas, e que satisfaça o requisito interoperabilidade. O componente intermediário é representado na visão seguinte com o nome: Social APIMiddleware Machine. É necessário ter cuidado na adoção desses elementos intermediários que façam a comunicação entre os demais elementos arquiteturais, pois esses elementos 75

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

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

Figura 18. Diagrama de Componentes: Visão de Componentes e Conectores

Tratando-se de visões arquiteturais, as mesmas podem detalhar algum elemento específico da arquitetura (KRUCHTEN, 2010), deste modo a próxima visão para a arquitetura de referência de Máquinas Sociais irá contemplar dois elementos importantíssimos para as SM’s, os elementos States e Constraints. Como já exposto eles são responsáveis pelo monitoramento e pelos requisitos não funcionais da Máquina Social, respectivamente; tais elementos devem interagir de forma facilitada, pois que, informações geradas por um interferem no funcionamento do outro. Os elementos States e Constraints serão abordados por meio de uma visão que exalta o tempo de execução da SM, por intermédio de um diagrama de sequência. Essa visão é capaz de representar a arquitetura em tempo de execução. É uma visão que foca mais no comportamento do componente arquitetural perante as interações e exibe bem os protocolos de relacionamento e confiabilidade (GORTON 2006).

76

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

Figura 19. Diagrama de sequência: Visão em tempo de execução

O diagrama de sequência na figura 19, a seguinte interpretação 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 é possível ainda dar o tipo de acesso que é requerido, o elemento Constraints avalia a permissão de acesso e retorna ao elemento anterior que, por sua vez, permite o acesso ao tipo de transação que o requerente desejar. Por fim, o requisitante, já com livre acesso, envia dados para algum tipo de transação e aguarda o seu retorno, que deve se originado por algum componente que implementa as regras de negócios e funcionalidades da Máquina Social. A interpretação acima é baseada em um exemplo simples de funcionamento dos elementos citados. O funcionamento ilustrado pelo diagrama de sequência pode ser implementado de outra forma, o importante é manter a comunicação entre os elementos do diagrama. A arquitetura de referência é apenas um modelo. É evidente que outros detalhes sejam pertinentes a esta arquitetura. Entretanto, são detalhes mais específicos de cada Máquina Social a ser desenvolvida. O importante é adotar as camadas e os componentes que as compõem bem como o estilo arquitetural que é o Relaxed Layered System, como já explicado, uma variação do estilo Camadas. 77

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

A adoção de tal arquitetura seria interessante para padronizar os projetos de Máquinas Sociais. Deste modo, cabe nesta pesquisa, avaliar a arquitetura proposta para que a adoção da mesma possa ser viabilizada com mais segurança.

4.5. AVALIAÇÃO DA ARQUITETURA DE REFERÊNCIA E DE SUAS VISÕES

A arquitetura de referência aqui proposta deve ser avaliada para verificar a adequação e consistência da mesma aos requisitos não funcionais de uma Máquina Social. O que deve ser avaliado são as representações arquiteturais, ou seja, as visões arquiteturais que são oriundas da arquitetura de referência e a própria arquitetura. A partir dos dados extraídos de tais avaliações, será possível identificar pontos de fraqueza na arquitetura de referência e nas visões da mesma. Pontos de fraqueza são defeitos encontrados nessas representações arquiteturais. Para avaliar uma arquitetura, existem vários métodos, entre eles: Architecture Tradeoff Analysis Method - ATAM e Software Architecture Analysis Method - SAAM, estes são métodos que avaliam as arquiteturas por meio de cenários que devem representar o comportamento esperado de um sistema perante um requisito de qualidade, estes métodos basicamente avaliam se a arquitetura proposta contempla os requisitos não funcionais, ou de qualidade, exigidos para o software (KAZMAN et al. 2000). As abordagens citadas como exemplo de avaliação arquitetural possuem limitações quanto ao emprego das mesmas na arquitetura proposta neste trabalho. As limitações são reais devido a arquitetura proposta ser uma arquitetura de referência (NAKAGAWA, 2006). Como já exposto, este tipo de arquitetura é muito genérica e representa todo um domínio de software. Assim, avaliar atributos mais específicos para este caso é um tarefa inviável. Além da limitação citada, existem outras que também poderiam afetar uma avaliação prática e correta da arquitetura de referência pelos métodos citados acima, entre elas:  Avaliações por meio dos métodos ATAM e SAAM podem se tornar muito subjetivas por dependerem fortemente do conhecimento dos avaliadores (CORANDI et al. 2003);  ATAM e SAAM são avaliações que necessitam de um número maior de pessoas envolvidas (CORANDI et al. 2003). 78

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

ATAM e SAAM avaliam cenários específicos para a arquitetura, de modo que seja necessário construir uma situação na qual a arquitetura será submetida, neste cenário a arquitetura deve se manter estável possibilitando o software a executar sua funcionalidade.

Levando em consideração as limitações abordadas, será aplicada neste estudo a técnica de inspeção sobre os documentos ou visões arquiteturais. Técnicas de inspeção de software são métodos rigorosos para se avaliar um artefato de software (BOEHM e BASILI. 2001). Para este trabalho, a técnica de inspeção a ser utilizada será o Checklist.

4.5.1. TÉCNICA DE INSPEÇÃO

O Checklist utilizado na avaliação 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 à confecção e customização de Checklists de documentos arquiteturais que pudessem ser utilizado largamente, inclusive em arquiteturas de referência. Segundo os autores citados, o sucesso de tal técnica de inspeção em documentos arquiteturais se deve ao fato de:  A aplicação do Checklist não envolver atividades complexas e demoradas, nem tão pouco a elaboração de cenários de qualidade. Deste modo, a avaliação é de baixo custo e menos subjetiva por não depender de cenários.  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 não a forma com que essa documentação foi feita ou a que tipo de arquitetura é direcionada.  Os itens de questionamento devem avaliar principalmente discrepâncias em relação aos requisitos funcionais e não funcionais. Com isto, várias características podem ser avaliadas e não somente as referenciadas em cenários.

79

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

É possível definir um processo de configuração dos itens de questionamento para que os mesmos possam adaptar o Checklist às características do documento arquitetural e ao objetivo da avaliação.

4.5.1.1. Perfil dos Avaliadores (inspetores)

Serão quatro avaliadores: um professor, arquitetos de software e estudantes de mestrado em ciências da computação. Existirá ainda, para intermediar tal inspeção, o autor dos documentos de visão arquitetural. É importante registrar que não existem estudos que afirmem qual o número ideal de participantes em um processo de avaliação 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 estão baseados nas definições e estudos de Shull (1998) e estão pontuados como se segue:    Defeitos por omissão: ocorre quando um elemento arquitetural necessário para o atendimento a um requisito não foi atendido ou mensurado. Defeitos por ambigüidade: quando um elemento arquitetural dificulta o atendimento a um requisito. Defeitos por inconsistência: quando o mesmo elemento arquitetural é representado com nomes diferentes em visões distintas. Ou quando o mesmo elemento arquitetural tem responsabilidades distintas em uma ou mais visões.   Defeitos por fato incorreto: ocorre quando um elemento arquitetural não é descrito de forma correta. Defeitos por informação estranha: defeito acometido quando não se consegue entender a atribuição ou responsabilidade do elemento arquitetural.

80

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

4.5.1.3. Processo de Inspeção (Avaliação)

O processo de inspeção com o Checklist de avaliação arquitetural é prático e constituído por duas grandes atividades:  Atividades de Planejamento e Configuração: 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 alteração para melhor adequação ao objeto avaliado; o Identificar os avaliadores; o Distribuir os documentos necessários à avaliação (documento arquitetural e Checklist);  Atividades de Detecção (avaliação): o Leitura de documentos de especificação 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. Correção dos Erros Encontrados

Após a avaliação é necessário corrigir os pontos negativados no documento arquitetural. A correção deve ser conduzida pelos itens que foram negativos no Checklist. Após correção, uma nova avaliação deve ser efetuada no documento arquitetural; neste ponto as atividades de planejamento e configuração do processo de avaliação podem ser postergadas.

81

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

4.5.2. RESULTADOS Os resultados que serão aqui pontuados foram extraídos dos itens de questionamento respondidos na fase de detecção. Para o registro deste resultado é importante mapear algumas questões daqui em diante. O Checklist foi respondido por cinco pessoas ao final das rodadas avaliativas, sendo que, na primeira rodada houveram três pessoas que respnderam o Checklist. Enquanto que em uma segunda avaliação, o Checklist foi respondido por duas pessoas. Apenas uma pessoa participou respondendo o Checklist em ambas as rodadas, ou seja, houve a repetição de apenas um participante entre as avaliações. Acredita-se que a não repetição de todos os participantes entre as rodadas acarretará um resultado mais preciso, pois que, novos avaliadores serão inseridos e estarão despreparados a qualquer julgamento e avaliação preliminares ou imaturos dos artefatos arquiteturais. Em contrapartida, a repetição de apenas um participante pode ser útil para que tal avaliador verifique a real evolução dos artefatos e consiga ser mais crítico e preciso em sua avaliação. Foi imprescindível executar duas rodadas de avaliação pelo de fato de buscar sempre a melhoria contínua dos artefatos. Se houvesse mais tempo de pesquisa, e mais disponibilidade de outros avaliadores, seria interessante executar uma terceira ou quarta avaliação. Quanto a estas, os documentos arquiteturais estavam bem mais consistentes e coesos na segunda avaliação, do mesmo modo que o próprio 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 dependêncica entre classes. Existiram dúvidas acerca deste item, de modo que, em 2 (dois) Checklists, de um total de 5 (cinco), ele não foi respondido, e em 1 (um) ele foi taxado como: “não se aplica”. Portanto, o item 4 (quatro) foi descartado de qualquer contabilidade dos itens de questionamento atendidos ou não atendidos. Seu descarte não foi prejudicial, sendo que outro item também tinha a função de avaliar o mesmo critério (dependência). Ainda quanto aos itens, as palavras que atribuiam muita generalidade, como por exemplo: “para todos” ou “todos”; foram subtraídas para a segunda rodada; verificou-se que 82

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

estas palavras estavam trazendo muitas respostas negativas na documentação. Sendo assim, se tratanto de uma arquitetura de referência, não há necessidade de explorar todas as visões ou todos os diagramas e classes que são potenciais às SM’s. As duas versões de Checklists utilizadas estão nos apêndices (apêndice A e apêndice B). Os itens de questionamento objetivaram avaliar alguns critérios de suma importância para qualquer arquitetura bem como detectar a presença 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 QUESTÕES AVALIADAS

1 - Ao analisar todos os Não diagramas, foi identificado

Avaliar os relacionamentos e coerência entre os componentes da arquitetura de forma que nenhum componente desponte

algum elemento arquitetural que não possua ficando

repentinamente.

relacionamentos, isolado dos demais?

2 - A descrição textual que Sim compõem o documento está de acordo com o nos que foi

Coerência entre a representação textual e gráfica, e principalmente os defeitos por incosistência.

representado

diferentes

diagramas gráficos? 3 - Para os componentes, em Sim algum diagrama, foram Defeitos por omissão.

identificadas as classes ou subcomponentes que o compõem? 4 Os relacionamentos Indiferente RETIRADO DO CHECKLIST. Pretendia avaliar a depedência e o acoplamento.

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

83

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

dependência

entre

esses

“componentes pais” em algum outro diagrama? 5 As interfaces são Sim Representação das interfaces e comunicação entre os componentes.

disponibilizadas por um único componente/classe, ou

representadas de uma forma mais simples não expandida? Ou seja, ocorre uma

representação por meio de diagrama de classes ou de componentes e conectores com interfaces providas. 6 - Ao analisar as seqüências Sim de execução descritas em uma visão de interação, pode-se dizer que as Analisar a coerência entre as visões. Verificar se os componentes arquiteturais possuíam os mesmos nomes entre as visões. requeridas e

classes/componentes definidas em uma visão modular foram alocadas em ao menos uma das seqüências? 7 - Os elementos arquiteturais Sim têm a sua presença na Analisar o atendimento aos requisitos funcionais e não funcionais, e se os mesmos foram trabalhados e justificados na

arquitetura justificada por um conjunto de requisitos não funcionais ou funcionais? 8 - As responsabilidades dos Sim elementos arquiteturais estão condizentes com os requisitos não funcionais que eles

arquitetura.

Analisar se a arquitetura atende de forma adequada (propõem soluções adequadas) os requisitos não funcionais.

84

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

atendem? 9 - Táticas arquiteturais foram Sim empregadas para satisfazer os requisitos não funcionais? Verificar se existem soluções propostas pela arquitetura para o atendimento aos

requisitos, e se as soluções estão corretas e claras.

10 - Elementos relacionados Não possuem responsabilidades

Analisar a coesão da arquitetura. Coesão neste caso deve ser entendido como o princípio fundamental da orientação a objetos. Analisar se existem elementos que podem prejudicar o requisito desempenho.

iguais que possam ser alocadas em um único elemento? 11 - Elementos intermediários Não como: máquinas de e virtuais, nomes, API’s; são

servidores repositórios

Elementos que viabilizam a comunicação entre os componentes arquiteturais podem prejudicar o desempenho.

utilizados como mediadores de comunicação entre os

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

Analisar a existência de acoplamento ou

dependências. que exerça sobre de o outro

Existem três itens de questionamento que visam avaliar a aderência da arquitetura aos requisitos Isto ocorre pelo fato da maior responsabilidade da arquitetura ser o atendimento aos requisitos, sobretudo os não funcionais. Desta forma os 3 (três) itens objetivam investigar o tratamento aos requisitos por questões escritas de forma diferente, mas que possuem o fim de captar não conformidades entre as soluções, inclusive na incompatibilidade entre tais soluções, como por exemplo: a soluções para o requisito desempenho ser prejudicial a solução do requisito disponibilidade. 85

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

Diante as respostas de cada item foi possível extrair o seguinte percentual das duas avaliações (figura 20).

Percentual das respostas
Respostas negativas (em desacordo com o esperado) 32%

Respostas às questões não aplicáveis ("não se aplica") 6%

Respostas possitivas (de acordo com o esperado) 62%
Figura 20. Resultado da Avaliação (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) também é um item neutro. Ou seja, suas respostas podem ser descartadas para a estatística, 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 são a totalidade das duas rodadas avaliativas. Se este resultado for mais detalhista, é possível obter valores separados das duas rodadas como exibido a seguir: Tendo em vista que a quarta e a décima segunda questão não entram no quantitativo, para a 1ª rodada avaliativa houve 30 (trinta) respostas válidas, onde nenhuma foi do tipo “não 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 aprovação 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

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

Retirando a quarta e a décima segunda questão, para a 2ª rodada avaliativa houve 20 (vinte) questões respondidas, 3 (três) destas avaliadas como “não se aplica”; apenas uma questão foi respondida como em desacordo com o valor esperado. Estes quantitativos implicam em um percetual de 80 (oitenta) em aprovação e corretitude da arquitetura. Este é o percentual válido para este trabalho. Esses valores pontuados em cada Checklist podem ser verificados no repositório público:

https://www.dropbox.com/sh/sc6bv62petuczdm/ocjs_kklFH. As visões ou diagramas arquiteturais expostos ao decorrer do capítulo foram os avaliados corretamente, ou seja, alguns foram inseridos enquanto outros foram corrigidos, tudo conforme a avaliação negativa dos questionamentos. Neste entrecho, após apuração dos itens respondidos e contabilizados para os cálculos, obtiveram-se os seguintes resultados e melhorias conforme os defeitos encontrados por tipo.  Defeito por Fato Incorreto:

Esses defeitos são referentes aos elementos arquiteturais que foram descritos ou mesmo desenhados de forma errada. Algumas camadas ou classes não foram corretamente especificadas. Um exemplo deste erro foi encontrado na visão que dividia a arquitetura em camadas. Nesta representação 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 necessária, só poderiam ser inserida nas duas camadas representadas. O grande problema dentro desta abordagem é o fato de não se dividir devidamente as responsabilidades; sendo assim, a representação em camadas foi refeita, com as atribuições 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 não especificar a camada de interação com o usuário surgiu através do apontamento deste tipo de defeito também, pois na avaliação, foi citado por um dos avaliadores, a necessidad de uma reflexão sobre a real necessidade de uma camada de apresentação em toda SM, sendo que muitas dessas poderiam se utilizar outras SM’s como apresentação.

87

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

Defeito por Omissão:

Durante a avaliação os itens que foram negativados tiveram como motivo a omissão de outros elementos arquiteturais que não foram representados. Ou seja, as visões arquiteturais ainda foram em um pequeno número. Sendo assim, os diagramas de componente e de classe foram acrescentados e avaliados positivamente em uma segunda oportunidade. O item de questionamento número 3 foi determinante para a averiguação deste defeito. Ao final desta seção é importante reafirmar que todas as visões exibidas neste capitulo foram corrigidas conforme as avaliações. Uma versão anterior da avaliação de referência foi inserida no apêndice D, isto para se notar como a mesma era antes de ser especificada como na figura 15. É importante também concluir que o Checklist também foi avaliado na primeira rodada, como se esta fosse um projeto piloto para os itens de questionamento.

4.6. CONSIDERAÇÕES FINAIS DO CAPÍTULO

Neste capítulo a arquitetura de referência para Máquinas 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 referência à implantação das SM’s e ao próprio ciclo de vida de uma SM devem ser melhor trabalhados. Como exemplos de questões que podem ser mais bem estudadas na arquitetura de referência são: estratégias que proporcionassem um maior tempo de “vida” ou utilização da SM. O maior número de visões retratadas para a arquitetura de referência visa auxiliar no entendimento de tal arquitetura, assim como, mostra o controle e as estratégias sobre os princípios de acoplamento e coesão. Em se tratando destes princípios, a avaliação procurou dar ênfase aos mesmos, entre outros. A avaliação foi importante não só para corrigir os artefatos arquiteturais como também para corrigir o próprio processo avaliativo. Itens foram refeitos e novas visões foram inseridas neste processo. Os avaliadores ainda puderam interagir com o autor dos artefatos e algumas solicitações foram colocadas, como: inserir uma área para comentários no próprio Checklist, e uma área de ajuda, em que cada item poderia ser melhor explicado, isto ainda no próprio Checklist. A avaliação foi um processo que não teve alto valor financeiro e foi extremamente proveitosa, tanto no sentido de melhoria da arquitetura, quanto no sentido de 88

Capítulo 4. Proposta de Arquitetura de Referência Para Máquinas Sociais

amadurecer e disseminar melhor as práticas que visam avaliar a qualidade de documentos arquiteturais. Durante a exibição da arquitetura os requisitos a serem atendidos foram bem enfatizados, inclusive por meio de uma tabela. Isto facilitou a avaliação, pois alguns participantes também necessitaram perceber o atendimento aos requisitos de forma mais direta. Outro artifício que possibilitou uma avaliação positiva de mais de 50% (cinquenta porcento) de aprovação e aceitação da arquitetura, foi a inserção 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 próximo capítulo também pretende, entre outros objetivos, fortalecer e facilitar o uso da arquitetura proposta, pois que, ao passo que conduz boas decisões de projeto, se descobre maneiras de alcançar ou implementar as soluções propostas neste arcabouço de referência.

89

Capítulo

5
5. Recomendação de Práticas Desenvolver Arquiteturas Máquinas Sociais Para de

Neste capítulo será proposto um conjunto de boas práticas que nortearão a uma definição ou especificação apropriada de arquitetura de Máquinas Sociais. Neste capítulo, as práticas constituirão novos métodos para projetar, e singularmente, conceber SM’s.

90

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

5.1. INTRODUÇÃO

Foi elaborado um conjunto de boas práticas, esse conjunto deverá responder algumas questões que são de elevada importância para a customização ou criação de arquiteturas. Ele irá conceber um padrão para construção de SM’s. Esse padrão, aliado à arquitetura de referência, constituirá o conteúdo necessário que facilitará a adequada construção de arquiteturas de SM. Na verdade, essas práticas também devem ajudar na personalização da arquitetura de referência. Os assuntos levantados nesta parte introdutória serão tratados minuciosamente nas próximas seções.

5.2.

PRÁTICAS

NA

METODOLOGIA

PARA

CONCEPÇÃO

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 são: 1. Elicitar requisitos funcionais e não funcionais; 2. Especificar e analisar requisitos não funcionais; 3. Fazer uma listagem de todas as decisões de projeto incluindo as justificativas que influenciaram cada decisão34. 4. Estruturar a arquitetura por meio de alguma modelagem; 5. Documentar a arquitetura utilizando visões que podem ser: visão de módulo, visão de componentes e conectores, visão de implantação (BASS, CLEMENTS, e KAZMAN, 2003);

Executar os passos acima não assegura a definição de uma arquitetura de qualidade para SM’s, ou seja, uma arquitetura que possibilite o correto funcionamento da aplicação, satisfazendo os requisitos (HOFMEISTER, NORD, e SONI, 2000). Para os sistemas Web que

34

Por decisão de projeto deve-se entender que são as escolhas sobre as tecnologias e métodos que irão compor o projeto de software e influenciar diretamente na arquitetura (BASS, CLEMENTS, e KAZMAN, 2003).

91

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

são Máquinas Sociais, é necessário ter conhecimento sobre outros fatores que influenciam na definição da arquitetura e que não estão explícitos nos procedimentos pontuados acima. Os fatores críticos que devem ser seriamente levados em consideração na definição da arquitetura de SM’s serão demonstrados por meio de boas práticas. Essas são orientações que farão o projetista ou arquiteto de software notar os fatores relevantes para as Máquinas Sociais para assim implementar com mais exatidão a arquitetura. As práticas estão ligadas diretamente ao desenvolvimento das SM’s: serviços relacionados à SM, padrões de projeto dedicados as SM’s, relacionamentos, autogerenciamento, e tecnologias. O intuito é possibilitar a construção de sistemas Web como Máquinas Sociais. É importante frisar que as práticas propostas neste trabalho não visam substituir os pontos citados acima, estes fazem parte de métodos já tradicionais e amplamente validadas pela indústria e pela academia para elaborar arquiteturas. A intenção deste trabalho é agregar valor à forma de conceber arquiteturas de modo que as atividades que compõem os procedimentos de elaboração arquitetural possam ser mais objetivas para SM’s, ofertando resultados mais eficientes ao projeto de arquitetura. As práticas foram costruídas por meio de:  Experiência de mais de 5 anos da autora desta dissertação em análise, projeto e arquitetura de software;  Leituras e investigações sobre tecnologias para a Web inclusive com a participação do grupo de SM’s da UFPE/C.E.S.A.R;  Padrões IEEE. A idéia de se originar boas práticas para o projeto arquitetual de Máquinas Sociais pode ser comparada aos padrões IEEE Std 830-1998, que contém boas práticas sobre a especificação de requisitos de software, e principalmente ao padrão IEEE Std 1471-2000 que contém boas práticas para a descrição arquitetural. A diferença primordial entre este capítulo em específico e os padrões sugeridos é que as boas práticas aqui propostas são mais ricas em detalhes, pois, elas não só recomendam uma ação, como também ilustram o problema a ser resolvido, a motivação pela qual a prática é sugerida, e a forma ou o exemplo de como ela poderá ser adotada. Com esta comparação, é

92

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

possível notar uma iniciativa em se padronizar a construção de SM’s; sendo que, o objetivo de um padrão IEEE também seria em padronizar procedimentos, computadores e dispositivos35.

5.3. PRÁTICAS RECOMENDADAS Antes de conhecer as práticas de construção, e depois de visualizar a arquitetura de referência, é necessário reforçar alguns pontos que fazem parte de qualquer processo de desenvolvimento. Para qualquer projeto de desenvolvimento de aplicações Web é importante centrar na idéia de Máquinas Sociais. O projetista de software deve ser remetido aos conceitos inerentes às SM’s como: a taxonomia, os tipos de relações, e a própria arquitetura. Uma das metas desta pesquisa é reforçar a idéia de que a análise dos sistemas conectados em rede deve ser feita sobre o paradigma de Máquinas Sociais. Para que a análise de uma SM seja constituída, as atividades inerentes a um projeto de software não devem ser ignoradas. Sendo assim, seria interessante: analisar o problema a ser resolvido pela Máquina Social; analisar o escopo do sistema, suas fronteiras; as premissas que ele estará submetido; e a especificação do produto de software. Com essas análises, é possível verificar ainda que tipo de Máquina Social é a aplicação a ser desenvolvida. Isto faz diferença no momento das definições do projeto arquitetural e dos requisitos de qualidade. Quanto aos requisitos de qualidade, é necessário averiguar os mesmos, o que ajudará nas decisões de projeto. Estas, por sua vez, irão influenciar diretamente na definição da arquitetura. Requisitos como: desempenho, confiabilidade, disponibilidade, compatibilidade, segurança, modificabilidade, usabilidade, e interoperabilidade podem ser trabalhados na arquitetura; sendo que alguns, como já elucidado, são mais relevantes que outros para as Máquinas Sociais. Após tratar brevemente de alguns assuntos relevantes para as SM’s, as práticas serão exibidas. Estas geram informações e artefatos úteis para a construção adequada da arquitetura da SM’s. Algumas práticas vão propor soluções tecnológicas, como frameworks ou padrões de projeto.

35

Segundo as infromações do site oficial do IEEE - Instituto de Engenheiros Eletricistas e Eletrônicos. Em http://www.ieee.org/index.html. Acesso em: 22 de março de 2012.

93

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

5.3.1. PRÁTICA 1: Modelar processos e sub-processos de negócio de serviço A modelagem dos processos de negócio vai capturar o problema a ser resolvido e mapear melhor os serviços providos e requeridos. Ademais, mostrará quais as necessidades e atribuições da aplicação. A modelagem dos processos é um fluxo com a sequência das atividades que são efetuadas para se atingir um objetivo, (LAZZERI, 2009) além de descrever o comportamento de um modelo de negócio. Problema: O problema reside em não saber como os componentes da Máquina Social irão interagir uns com os outros. É difícil mapear um serviço sem conhecer os elementos que o compõem (OSTENWALDER, 2005), qual o fluxo de atividades envolvidas, quais os serviços e subserviços relacionados ao negócio ou a uma funcionalidade em específico. Pensar em serviços é pensar em modelagem de negócio (LAZZERI, 2009). Motivação: Esta prática constitui um fluxo que é o alicerce da modelagem do sistema, ou da Máquina Social. Assim, é possível visualizar mais claramente a SM e agir decisivamente nas escolhas tecnológicas e arquiteturais. Ainda assim, a motivação para construir as Máquinas Sociais é a relevância em se conhecer os elementos que irão subsidiar suas operações. Não só conhecer, mas verificar como tais serviços estão entrelaçados. Assim, a aferição desses serviços ou operações é feita por meio do mapeamento dos processos que existem em cada operação. Cabe aqui mais uma referência direta, segundo José Carlos Lazzeri (2009):

O fluxo do processo dá ao modelador a representação visual de como o modelo de negócio será executado, podendo ser a base para a validação das muitas exigências requeridas, entre elas: suporte a governança, estrutura do software, priorização estratégica, apuração dos custos e eficiência operacional.

Outra questão que impulsiona o exercício desta prática é a integração entre as aplicações de modo que uma possa utilizar o serviço da outra. A análise e descrição do negócio contribuirão diretamente para a comunicação e integração (ABINADER e LINS, 2006), pois existe hoje uma série de padrões, ferramentas e arquiteturas, que vão desde as Arquiteturas Orientadas a Serviços até as Plataformas Corporativas de Serviços, que se

94

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

propõem a ajudar na integração. Mas para isto é necessário conhecer o negócio e as regras que envolvem o mesmo.

Exemplo e Solução: Para modelar processos, o uso de Business Process Modeling Notation - BPMN é extremamente recomendado (OSTENWALDER, 2005). Os fluxos dos processos de negócio que surgem da linguagem BPMN modelam perfeitamente o processo. Deste modo, a Figura 21 é um exemplo dessa prática. 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 descrição de um processo simples de um sistema de compra e reserva de passagem. Todos os serviços são descritos possibilitando uma compreensão de como os mesmos estão entrelaçados, por exemplo, o serviço de fazer check-in depende do serviço de compra de passagem, qualquer alteração nesta compra poderá alterar o check-in. 5.3.2. PRÁTICA 2: Reconhecer os serviços providos e requeridos para o funcionamento da Máquina Social.

Um serviço é uma tarefa, trabalho, ou ainda operação que será produzida por um componente de software a fim de edificar algo de interesse e necessidade de outro componente requisitante (ERL, 2005). Os serviços podem ser identificados em diversificados níveis de abstração, desde serviços ofertados por uma aplicação a outra, até serviços ofertados 95

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

por um objeto a outro. Trata-se de uma orientação voltada para o autoconhecimento. Quanto mais se conhece a aplicação, mais se descobre o tipo de Máquina Social que ela é, e como deve ser sua arquitetura.

Problema: O problema identificado para SM’s que pode ser resolvido por esta prática a nível arquitetural é em relação à identificação das operações efetuadas pela Máquina Social. Outro problema a ser resolvido está relacionado à identificação dos provedores de serviço. Algumas decisões arquiteturais são baseadas nas características dos serviços requeridos e, por conseqüência, o que, ou quem, pode prover tal serviço. Muitas vezes as operações requeridas são executadas por provedores distintos, provocando exigências em conexões (LAZZERI, 2009).

Motivação: Neste caso, os serviços providos e requeridos auxiliarão na definição das interfaces de comunicação que ocorre entre as aplicações e também entre as “partes” das aplicações. Ou seja, entre os elementos que constituem uma aplicação. O benefício desta prática é descobrir os serviços envolvidos com a Máquina Social, prever os serviços necessários, verificando o ciclo de vida do serviço, e também prever possíveis reusos dos mesmos. Uma conseqüência desta prática, que caracteriza outra motivação, seria a identificação da necessidade de Web Services, ou mesmo adaptação da arquitetura para suportar a conexão com provedores de serviços.

Exemplo e Solução: O seguinte exemplo pode auxiliar na execução da prática: Aplicação: Aplicativo de rede social; Serviço provido: agrupar pessoas com a mesma profissão; Serviço requerido: mecanismo de autenticação de usuário da rede social;

Existem algumas estratégias para se descobrir um serviço, sobretudo os serviços providos. Algumas das estratégias são: 1. Tipificação: estudar um componente de software e descobrir o serviço que o mesmo pode prover separando-os por categorias (BELL, 2008); 96

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

2.

Abordagem Bottom-Up: analisar o sistema de software verificando os produtos derivados da operação desse sistema. Se os produtos estiverem contextualizados ao negócio ao qual a aplicação está direcionada, então tais produtos podem ser vistos como serviços (LAZZERI, 2009);

3.

Abordagem Top-Down: parte da análise do problema que o software deve resolver. Nesta abordagem, o domínio do software poderá ser estudado, bem como a análise das regras de negócio para identificação dos serviços (LAZZERI, 2009);

Para finalizar esta prática e partir para a próxima, que também esta relacionada aos serviços, vale expor que ambas foram baseadas em estudos direcionados a SOA. Alguns estudos, como o de Michael Rosen em 2008 exploram práticas de design para arquiteturas orientadas a serviço. Algumas destas práticas são, por exemplo: o estudo dos serviços; a separação de responsabilidades entre componentes da arquitetura; as atribuições de cada pessoa envolvida no projeto; e ainda a análise do ambiente organizacional e tecnológico no qual a aplicação será envolvida. Estas práticas são próximas das práticas lançadas até este ponto.

5.3.3. PRÁTICA 3: Conhecer os provedores e requisitantes dos serviço da aplicação A análise dos serviços é conveniente pela descoberta das interfaces, e para identificar os componentes de software que irão prover e requisitar serviço. Entender e projetar um componente de software como requisitante ou provedor de serviço é 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 necessária para se comunicar.

Problema: O problema a ser resolvido por esta prática já foi levantado na prática 1: ele provoca a ausência de informações que auxiliariam um projetista, ou arquiteto, a lançar mão de boas decisões arquiteturais que envolvam os provedores de serviço.

97

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Motivação: Após mapear os serviços requeridos é mais fácil descobrir quais tecnologias podem atender cada serviço. Este conhecimento é útil para definir na arquitetura soluções que possibilitem uma comunicação hábil entre provedores e requisitantes, evitando assim, incompatibilidade entre as tecnologias ou aplicações (JOSUTTIS, 2007). Esta orientação pode ser extremamente útil para os Mashups que trabalham sobre a mescla de serviços de duas ou mais aplicações. Para enriquecer o entendimento sobre esta prática, vale examinar o exemplo abaixo.

Exemplo e Solução: O exemplo no parágrafo abaixo não é baseado em um caso real, mas ilustra as informações que devem ser adquiridas.

O Twilio irá fornecer o serviço de telefonia Web necessário na aplicação a ser construída. Após pesquisa entende-se que ele é uma aplicação que utiliza a infraestrutura da nuvem (Cloud Computing), enquanto sua API usa como interface de comunicação o padrão “RESTful”, além de aceitar os formatos XML ou CSV em suas mensagens.

A metodologia para se adquirir as informações nos moldes do exemplo acima é simples: 1. Fazer uma listagem das operações necessárias; 2. Separar as operações/serviços, separar os serviços que podem ser atendidos pela própria aplicação, e separar serviços que podem ser atendidos por entidades externas, como outra SM; 3. Para os provedores internos à Máquina Social, verificar como esses provedores devem ser componentizados, se algum será reutilizado, e como deverá ser a interface de comunicação desses componentes (CHEESEMAN e DANIELS, 2001). Quais métodos a mesma deve ter para manter os serviços; 4. Para os provedores externos, analisar cada provedor usando métodos de pesquisa em materias próprios dos provedores, como sites, tutoriais, estudos de caso, guias e outros.

98

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Esta prática faz referência a componentização de software, outro importante conceito para o desenvolvimento de aplicações Web. Entretanto, a prática ainda está corelacionada aos conceitos de SOA, bem como a prática 2. Até agora os conhecimentos lançados exploram questão mais voltadas à análise e modelagem de negócio, mas que, influenciam na arquitetura. A partir da próxima prática recomendada os conhecimentos serão mais voltados para as questões técnicas das Máquinas Sociais.

5.3.4. PRÁTICA 4: Verificar a necessidade de recursos que tornem a aplicação auto gerenciável e como esses recursos podem ser implementados. Este conhecimento está intensamente relacionado aos conceitos de computação autônoma. Neste momento é importante apontar para a necessidade das funcionalidades autônomas, pois elas sugerem os mecanismos de auto gerenciamento de uma SM.

Problema: O problema reside em não saber que determinado componente da Máquina Social tem a necessidade de se auto gerenciar. Ainda existe outro problema agregado, onde alguns recursos que promovem a autonomia dos sistemas ainda são parcialmente desconhecidos, como exemplo: as IaaS’s. Tais aspectos relacionados à autonomia das Máquinas Sociais fazem total diferença na arquitetura da mesma.

Motivação: Com este conhecimento, é possível descobrir o recurso que poderá ser utilizado para prover a autonomia dos elementos, quais são esses elementos da SM, e se necessitam realmente de autonomia. Tal nível está relacionado às propriedades de auto cura, configuração, otimização, e por fim, auto proteção. Assim, através desta prática, pode-se descobrir, por exemplo, que um sistema tem alguns requisitos que, ao serem implementados, gerarão funcionalidades independentes. Ou seja, funcionalidades que necessitem se reconfigurar, otimizar seu desempenho em conformidade ao ambiente externo, ou ainda se proteger deste ambiente.

99

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Exemplo e Solução: Para descobrir aspectos funcionais que devem ser autônomos na Máquina Social deve-se observar:  O ambiente no qual a SM está inserida, se é fortemente distribuído, se é heterogêneo, ou seja, composto por SM’s distintas (STERRITT; e BUSTARD, 2003);   A carga de trabalho da SM, se a mesma é variável; Se os recursos da Máquina Social são compartilhados.

O auto gerenciamento de um sistema é garantido pela comunicação entre os elementos desse sistema. Para isto, o uso de interfaces variadas é a solução. Tais interfaces podem agir por meio de APIs, arquivos de configuração, controle de logs, utilização 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 máquinas executantes das operações de mapeamento de dados e redução dos mesmos. Deve-se lembrar que o framework trabalha de forma distribuída em várias máquinas, ou clusters. Pois bem, uma vez que um componente envie tarefas, o mesmo envia “ping’s” para cada máquina. Se uma delas não responder em um período pré-determinado de tempo, o componente entenderá que ocorreu uma falha e imediatamente reiniciará a tarefa enviando-a para outra máquina. Por fim, a tarefa necessitará ser re-executada para que o processo não fique comprometido ou apresente resultados de reduções incompletos. O parágrafo acima mostra como o MapReduce trabalha em um mecanismo que satisfaz uma propriedade autônoma. Para esta prática é muto importante sinalizar à equipe de software de que algum mecanismo do tipo deve ser planejado. O exemplo fictício do parágrafo seguinte exibe o resultado da execução desta prática: Exemplo: Baseado em dados mapeados nas experiências anteriores e no perfil do público alvo da aplicação, estima-se que os registros e acessos de usuários tendem a crescer 42% a cada 30 dias. Assim, dentro de meses, o recurso consumido pelas máquinas será grande. Para este problema, seria interessante ter um recurso que monitorasse a quantidade de recursos existentes nas máquinas, como: memória e capacidade de armazenamento. 100

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas 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 distribuídos em rede, afinal, o balanceamento de carga promove a escalabilidade, performance, e disponibilidade. Para se utilizar o recurso de balanceamento de carfa é necessário, acima de tudo saber o que se deseja balancear (BOURKE, 2001). Após ter tais conhecimentos, é viável preferir por alguma solução. É bem mais prático adotar uma tecnologia de mercado do que construir o próprio balanceador, principalmente no contexto de Máquina Social que prega a praticidade na manutenção e evolução do software (BOURKE, 2001). O Netcraft.com36, inclusive, publicou uma estimativa que aponta o Apache como o serviço de balanceamento de carga mais explorado, onde mais de 50% das aplicações Web o utilizam; em segundo lugar ficou colocada uma ferramenta da Microsoft. Finalmente outra opção para esta prática seria contratar um serviço 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 aplicação onde a infraestrutura pode prover a elasticidade do sistema sem intervenção de pessoas que tratem da manutenção da aplicação.

5.3.5. PRÁTICA 5: Determinar os recursos que implementarão os elementos Communications , Constraints e Requests: Os elementos chamados States e Constraints são partes da Máquina Social. Eles concentram informações capazes de tornar viável a sociabilidade e a colaboração entre as SM’s. Sem eles, é complicado saber a disponibilidade de uma SM, ou mesmo a disponibilidade dos seus recursos. Estes dois elementos comportam e fornecem informações tanto para auxiliar o processamento interno da SM, como para auxiliar na interação com o ambiente externo.

Problema: Determinar quais recursos tecnológicos podem implementar um componente que dará suporte ao armazenamento e divulgação da situação da SM: se a mesma está bloqueada,

36

Disponível em: http://news.netcraft.com/. Site que monta pesquisas e exibe estatísticas sobre ferramentas e sobre a Internet em geral. Acesso em: 27 de nov. 2011.

101

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

inativa, com muitas requisições e etc. Faz-se necessário ainda implementar um recurso que distribua informações de como a Máquina Social trabalha, o que ela requer para se comunicar com outras SM’s, qual a sua capacidade de processamento, armazenamento, os serviços aos quais elas se dedicam e outras informações relevantes. Existe uma complexidade em implementar recursos que atendam às necessidades expostas nos parágrafos acima. Para solucionar o problema de detectar o estado das SM’s, 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 ações, e até mesmo no trabalho de API’s. Contudo, os scripts de monitoramento devem ser executados por meio de uma boa infraestrutura onde máquinas estejam preparadas para monitorar. Além disto, nem todos os scripts estão aptos para lidar com as particularidades de Web Services e linguagens de programação. Na linguagem PHP, por exemplo, todos os scripts que possuírem o comando “exec” poderão ser bloqueados pela maioria dos servidores. Atualmente existem também alguns serviços Cloud Computig que fazem o monitoramento do estado de sistemas e de redes, como o serviço: CA APM Cloud Monitor. Ainda que existam alternativas, nenhuma delas é uma solução que atenda a necessidade dos elementos States e Constraints e igualmente possa ser reutilizada na diversidade das aplicações Web 3.0. Sendo assim, outras vicissitudes devem ser buscadas.

Motivação: Priorizar uma solução ú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 aplicação Web possa ter implementado esses componentes. O intuito é disponibilizar de forma prática na rede as informações importantes para a conectividade e a troca de serviços entre as SM’s.

Exemplo e Solução: Uma das soluções mais interessantes para essa questão seria o desenvolvimento de um framework que possa atender os States e Constraints de forma diferenciada, pois o framework ofertaria praticidade na comunicação e na obtenção de conhecimentos sobre a própria SM e sobre outras SM’s. Assim a execução das operações por cada componente seria maximizada. 102

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

O framework se preocuparia em ter as informações da SM, sendo que uma boa comunicação necessita de informações, sobretudo, informações do status da Máquina Social. O framework é composto por 3 (três) classes como exibido a seguir. Veremos a definição de cada classe e posteriormente o relacionamento entre elas:  Class SM’s Configuration: trata-se da classe onde as informações e características da Máquina Social são armazenadas. São informações como: a quantidade de requisições que a SM pode suportar e o tempo de resposta entre estas requisições. Qualquer alteração na SM é refletida nesta classe, evitando assim, que códigos e métodos sejam alterados em diferentes pontos da Máquina Social.  Class Relationships Manager: faz a gestão dos relacionamentos entre as SM’s. É um elemento importantíssimo para o framework justamente por executar o monitoramento das conexões entre as Máquinas Sociais. Neste elemento, é possível definir o tempo de conexão, o tipo de conexão, quais SM’s, ou elementos em uma SM, irão se conectar, e como irão se conectar. Conexão neste sentido são de fato as Connections, ou seja, as relações fortes da SM. Por fim, pode existir uma instância desta classe para cada SM conectada.  Class SM’s Interface: é uma classe de interface que se responsabiliza por construir Request apenas lendo parâmetros, proporcionando uma criação mais objetiva sem envolvimento de diversos códigos fontes ou outras tecnologias.

Essas classes estão inter-relacionadas, sendo que o produto de uma classe pode ser o artefato de entrada para outra classe. Deste modo, a SM’s Configuration pode configurar uma política de acesso à Máquina Social, deixando evidente, por exemplo, as portas que podem receber solicitações e o tempo em que essas solicitações poderão ser atendidas. Isso servirá de insumo para que a classe Manager Relationships avalie se o tempo de resposta de uma solicitação está em um nível bom; os valores bons, ruins, ou ótimos, para esses níveis seriam definidos nesta classe. Outra relação de fundamental importância entre as classes citadas no parágrafo anterior é a disponibilidade de informações. Baseado no último exemplo, a Manager Relationships verifica que o tempo de resposta está prejudicado, mas não consegue descobrir o motivo, pois esta justificativa é uma informação registrada como não pública na SM’s Configuration. Sendo assim, a Manager Relationships apenas enviaria uma mensagem ao 103

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

método da arquitetura que seria responsável por sanar essa queda de performance do tempo de resposta, sem necessariamente ter a garantia de que o método resolveria o problema. Enquanto várias interações ocorrem, uma delas é fundamental: a Class SM’s Interface que utiliza as informações da SM’s Configuration para montar corretamente as Requests e assim poder receber dentro dos parâmetros registrados as solicitações de outras SM’s. Por fim, a Class Manager age diretamente sobre essa interface conforme os resultados obtidos no controle das conexões. Vale ressaltar que todos os atributos dessas classes são repassados no formato “chave ⁄ valor”, o que agrega mais simplicidade na configuração do framework. Finalmente é possível notar que muitas das informações relevantes à SM são trabalhadas em um só lugar por meio do framework; esse poderia ser uns dos elementos principais de suporte à camada central de processamento da Máquina Social. Fica como sugestão para as arquiteturas que resolverem adotar esse framework, que um importante incremento para o mesmo seria implementar uma classe que tenha a inteligência de sugerir ações corretivas para as não conformidades encontradas. Isto saciaria a necessidade de incluir uma propriedade autônoma relacionada a auto cura.

Figura 22. Representação do framework de comunicação para as SM’s

5.3.6. PRÁTICA 6: Adotar estratégias para sanar as fraquezas do estilo arquitetural camadas.

A adoção de um estilo arquitetural depende do contexto no qual a aplicação está inserida, e sobretudo, depende dos seus requisitos de qualidade. Todo estilo arquitetural

104

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

possui vantagens e consequências em sua adoção. O estilo camadas é fortemente utilizado em sistemas Web e estava fortemente presente no mapeamento do estudo da literatura.

Problema: O estilo camadas se mostrar frágil quanto ao provimento da comunicação. Esta é realmente importante para as SM’s. Outras fragilidades desse estilo já foram elencadas anteriormente, como a tolerância a falhas e a queda de desempenho; tais fragilidades podem comprometer a qualidade da arquitetura da Máquina Social. Motivação: É possível repensar no estilo camadas para as SM’s, onde todas as fragilidades de tal estilo poderiam ser amenizadas. Isto é válido, visto que o estilo se mostra eficiente para a implementação de aplicações Web.

Exemplo e Solução: 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 conseqüências. A inserção do framework citado na última prática em conjunto ao MapReduce poderia ser uma idéia proveitosa, sendo que, enquanto o primeiro traria rapidez ao processo de comunicação, tanto na montagem dos Requests, quando na obtenção facilitada do estado das SM’s; o segundo auxiliaria na tolerância a falhas. Outra alternativa seria implementar uma réplica de segurança para cada camada. Deste modo, quando uma camada falhasse, sua camada réplica estaria pronta para prover os serviços; nas camadas de acesso a dados já é possível usufruir do artifício da replicação de dados. Nessa alternativa, caso a SM use um recurso CC, como uma IaaS ou mesmo PaaS, é possível negociar mais máquinas virtuais ao mesmo fornecedor de servidos de IaaS, ou em outro fornecedor; além de programar o sistema de infraestrutura de modo que todo o conteúdo seja replicado no novo ambiente negociado. As alternativas para se adequar ainda mais o estilo camadas as SM’s são numerosas, todavia, deve-se analisar novamente os serviços providos pela aplicação, o escopo da mesma, qual será sua dimensão, e o ambiente no qual ela estará. A execução das 3 (três) primeiras práticas vai auxiliar fortemente a prática aqui tratada. Já o exemplo a seguir pode auxiliar no entendimento.

105

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Exemplo: o servidor precisará notificar todos os clientes ativos diariamente. Assim, seria interessante utilizar o estilo arquitetural Publisher-subscribers na camada de comunicação, pois ele viabilizaria o registro apenas dos clientes ativos (BUSCHMANN. et al, 1996) notificando os mesmos a cada alteração sem esforço da aplicação servidora. 5.3.7. PRÁTICA 7: Determinar o recurso que proverá a comunicação e a interoperabilidade. A comunicação é uma característica que sobressai na Máquina Social, e a interoperabilidade é um requisito importantíssimo a ser considerado na arquitetura da mesma. Portanto, dependendo do tipo de relação existente entre as aplicações, pode ser adotado um padrão de comunicação entre elas, ou pode haver um consenso quanto aos tipos de mensagens trocadas e o tempo em que elas serão trocadas. Quando se trabalha com comunicação entre Máquinas Sociais trabalha-se mais do que tudo nas integrações requeridas entre esses SM’s; o detalhe neste caso é que tais SM’s podem apenas manter uma comunicação interna entre os componentes que a compõem, ou entre as SM’s ditribuídas. Ainda deve-se considerar que a integração ocorrerá também entre SM’s heterogêneas envolvendo Máquinas Sociais de clientes, de fornecedores e demais parceiros do negócio.

Problema: Determinar como será feita a comunicação entre as Máquinas Sociais para que a continuidade na conexão destas SM’s seja garantida é algo que pode ser provido por meio de diversificadas soluções. Deste modo, o problema se origina novamente da heterogeneidade de recursos que são utilizados e que por vezes não agregam um bom resultado à SM, adicionando complexidade ao seu desenvolvimento. Contudo, prover a comunicação é um problema gerado principalmente pela falta de análise nas ferramentas e recursos que podem prover a integração e interoperabilidade das SM’s. Neste aspecto, o conteúdo trocado entre elas é de total relevância, assim como, o ambiente no qual a Máquina Social está envolta.

Motivação: A motivação desta prática está em utilizar algum recurso já explorado por outras SM’s como REST e SOAP. Ou ainda, analisar algum padrão utilizado pelo paradigma Cloud 106

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Computing ou SOA capaz de prover a comunicação por meio de troca de mensagens bem sucedidas. Contudo, ainda existe a possibilidade de explorar novas idéias que ofertem mais praticidade na integração entre as SM’s. A integração pode reduzir significativamente os custos e melhorar a eficiência dos processos organizacionais ao passo que aumenta a “longevidade” das aplicações (ABINADER e LINS, 2006). Segundo Rezende (2005) (2006); alguns fatores impulsionam a comunicação, integração e interoperabilidade flexível entre os sistemas. São eles: a expectativa de se obter retorno financeiro mais rápido; o aumento da demanda no compartilhamento de dados em tempo real; a necessidade contínua de conter custos; e a necessidade de entregar sistemas de qualidade que agreguem valor ao negócio.

Exemplo e Solução: Baseado no que foi visto até este ponto, as soluções mais próximas da realidade das SM’s são 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 geração de código e automação na criação do Web Service por utilizar recursos da ferramenta NetBeans, a arquitetura REST oferta interfaces de serviço preparadas para integrar aplicações que manipulem grande quantidade de dados (WEBBER, PARASTATIDIS e ROBINSON, 2010) e também aplicações móveis. Vale ressaltar que o metadado WSDL descreve Web Services com muita proeza, sendo que ele ainda descreve o serviço, especifica como acessar o Web Service e quais as operações que o mesmo dispõem. O WSDL é uma ferramenta muito poderosa para a obtenção de interoperabilidade. Na indústria 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 características do REST dão mais praticidade ao desenvolvimento, por outro lado a completude de recursos que o SOAP possui (KALIN, 2010). A questão por se definir entre REST ou SOAP é algo que depende de muita prática em desenvolvimento de software, justamente para que os profissionais possam optar pela tecnologia mais adequada. É 107

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

importante lembrar que toda e qualquer escolha possui forte dependência com as características da Máquina Social, a taxonomia, as interações, e a natureza dos serviços. Apesar dos benefícios de SOAP, REST seria a solução mais adequada para as SM’s. O que aproxima REST das Máquinas Sociais é a facilidade com que esta solução pode auxiliar na identificação dos serviços (WEBBER, PARASTATIDIS e ROBINSON, 2010) e, sobretudo, na utilização das mesmas pelo paradigma Cloud Computing. Vale lembrar que a identificação dos serviços facilita a execução das primeiras práticas propostas por esse trabalho. Em se tratando de CC, a Salesforce utiliza REST para prover a integração entre Web Services que podem ser necessários para a Máquina Social a ser construída sobre a plataforma Force.com, no caso dos componentes disponibilizados por tal plataforma não atenderem as funcionalidades exigidas pelo escopo da Máquina Social. O conhecimento deste parágrafo e do seguinte estão disponíveis no Guia do Programador da API de Serviços Web da Force.com37. Com isto é possível ver que CC também adere ao uso de SOAP. A Force.com ainda fornece suporte a utilização do protocolo de acesso SOAP. Ela sugere que as aplicações Web que exijam um tempo de resposta curto, que manipulem poucos dados, e que serão construídas sobre a arquitetura Multitenancy, façam uso de SOAP. Tal protocolo também ganha notoriedade quando as aplicações são construídas sobre o paradigma de Arquitetura Orientada a Serviços. Em SOA, solicitantes e provedores de serviços trocam mensagens do tipo SOAP para encontrar e disponibilizar serviços respectivamente (GOMES, 2010).

2. Enterprise Service Bus - ESBs: Outro recurso que ganhou força com SOA e que também provê integração e comunicação são os ESBs (CRAGGS, 2004). O modelo ESB utiliza uma plataforma de serviço na qual as aplicações recém-criadas e as aplicações legadas podem se conectar facilmente utilizando XML. A grande vantagem do ESB é que o formato da mensagem já é conhecido pelas duas aplicações (CRAGGS, 2004), o que proporciona maior velocidade nas transações.

37

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

disponível

em:

108

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

O ESB é um servidor de aplicação que trabalha com middlewares que podem integrar os componentes das camadas de processamento da aplicação, além de garantir a integração de diversas Máquinas Sociais distribuídas utilizando adaptadores e conectores (LINTHICUM, 2004). Desta forma, o uso de um ESB na camada Wrapper da SM é uma solução inteligente e ideal para as SM’s, sobretudo, pela padronização de mensagens, o que facilita o reconhecimento das mesmas por diversas SM’s amenizando assim o problema de integração. 3. Remote Method Invocation - RMI: Aplicações que sejam desenvolvidas em Java, por exemplo, podem utilizar o padrão de comunicação RMI, ou a ferramenta Jini, que, por meio de um conjunto de API’s, pode conectar diversas aplicações distribuídas em rede (ARNOLD et al, 2009), inclusive dispositivos móveis. O Jini faz a localização dos serviços sem necessitar consultar nenhum repositório de serviço (ARNOLD et al, 2009), como SOAP faria. Apesar de ser uma boa solução, a mesma traria muita dependência com a tecnologia Java, o que contradiz os princípios da SM de ser independente. Finalmente a comunicação entre as aplicações ou parte delas pode ser alcançada de forma prática por meio das tecnologias aqui expostas. Conceitos que são relevantes como análise do negócio e aviso de entrega de mensagens, estão implícitos nesta abordagem e devem ser considerados para a adoção de alguma tecnologia.

5.3.8. PRÁTICA 8: Selecionar o recurso Cloud Computing a ser adotado na SM.

A arquitetura de referência sugere que os recursos disponibilizados pelo paradigma Cloud Computing sejam inseridos na arquitetura de Máquinas Sociais. Na verdade Cloud Computing, sobretudo os SaaS, trabalham como SM’s, e estão inseridos no universo da Web 3.0. Por isso, e também pelas vantagens que os serviços Cloud podem trazer, é que deve-se buscar a inserção de tais recursos no desenvolvimento de aplicações Web. Os ganhos que são conseguidos por meio da Cloud Computing são refletidos na disponibilidade de recursos, na manutenção, e na produtividade do desenvolvimento da aplicação. Deste modo, esta prática irá explorar algumas questões da adoção da Computação nas Nuvens em alguma parte da arquitetura da Máquina Social. 109

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Problema: A indústria de desenvolvimento de software vem inserindo os recursos da Cloud Computing no cotidiano das fábricas de software. O novo paradigma, a priori, parece não trazer muitas novidades que resolvam de forma diferenciada os já conhecidos problemas do desenvolvimento de software. É necessário mais atenção e pesquisa para notar os benefícios que podem ser agregados com a adoção de Cloud Computing. Este talvez seja um ponto problemático para as empresas, que, por vezes não tentam desenvolver projetos experimentais a ponto de confrontar os resultados da adoção de Cloud Computing. Um problema relevante nesta questão é o fato de não se ter um parâmetro de como ou onde usar Cloud Computing. Este paradigma estaria apto a suprir todas as necessidades das Máquinas Sociais? Abdicar totalmente de uma infraestrutura de processamento e armazenamento seria uma idéia radical? Ou ideal, para o desenvolvimento de aplicações Web? Afinal muitas soluções não CC ofertam benefícios que são promessas da Cloud Computing. Outro problema inerente às próprias características 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 máquinas virtuais para se fazer leitura e escrita, principalmente quando se trata de sistemas WEB, essas funções de leitura e escrita podem ser desaceleradas conforme a quantidade de máquinas existentes (MOTAHARI-NEZHAD, 2009). Assim, toda aplicação que precisar manipular muitos arquivos em disco não vai conseguir taxas altas de leitura e escrita. Nesta categoria estão os servidores de email e de banco de dados. Sendo assim, ainda seria interessante deixar o repositório de dados em CC? Motivação: A disseminação dos serviços e das ofertas em Cloud Computing pode promover a criação e proliferação de negócios em setores nos quais os recursos e custos de TI são impeditivos ao desenvolvimento do negócio. Assim, é extremamente motivador analisar como o advento de Cloud Computing pode ser atrelado às Máquinas Sociais, e como a integração entre duas SM’s pode ocorrer (Cloud Computing é uma SM que serve a outras SM’s). A definição de uma arquitetura deve levar em consideração aspectos inovadores e que possam ofertar soluções práticas e flexíveis para antigos e novos problemas da engenharia 110

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

de software. CC é capaz de ofertar essas soluções, além de ofertar possibilidades de reuso em recursos computacionais. O próximo parágrafo evidencia ainda mais a motivação por se analisar a utilização de Computação nas Nuvens. Cloud Computing pode agregar mais poder de processamento ao desenvolvimento de software visto que ela oferta alta disponibilidade de recursos para as aplicações e flexibilidade nas manutenções (WEINHARDT, 2009). Essas manutenções são responsabilidades dos provedores de serviços Cloud Computing e não da equipe que desenvolve a SM que utilizará CC. (WEISSMAN, 2010). Exemplo ou Solução: Tudo em Cloud Computing é feito mediante as questões firmadas no acordo do nível de serviço (SLA’s) (WEINHARDT, 2009). Portanto, o cuidado e a análise com o SLA é considerável. Deste modo, é possível verificar a eficiência do modelo de implantação da CC, se público ou privado, bem como o esforço da equipe de implementação da Máquina Social, este deve ser o menor possível. Todavia antes de verificar a adoção de qualquer serviço CC devem-se analisar anteriormente todas as SLAs referentes ao serviço. Estas formalizam um contrato de acordo de serviço, ou seja, o que será prestado como serviço e como deve ser o desempenho do fornecedor de serviço. Tais SLAs devem ter a transparência necessária para deixar evidente o que será fornecido como serviço, como será fornecido, a que custo será fornecido, os prazos necessários e etc. Enquanto as SLAs são protagonistas no assunto, outros serviços e tecnologias ganham destaque, entre eles:  Cloud Brokers: Trata-se de um seviço de corretagem em CC, empresas especialistas no assunto ofertam esse serviço que visa indicar qual o melhor provedor, e quais os serviços Cloud mais adequados ao negócio que pretende adotar Cloud Computing (GARTNER Inc, 2009). Os Brokers ainda são capazes de analisar as SLAs existentes em um contrato de pretação de serviço Cloud, indicar melhorias nesse contrato, e ainda viabilizar a implantação do

111

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

serviço, caso a empresa não 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 médio e grande porte. Ou seja, aos sistemas com lógicas mais complexas, ou, que devem suportar grande volume de dados e de acessos. Tal plataforma ainda oferta serviços de criptografia RSA e segurança de dados com firewall. A estratégia para se decidir como usar CC na arquitetura da Máquina Social é realmente estudar o escopo e a necessidade da aplicação para confrontar com o que Cloud Computing pode ofertar. É importante compreender as tecnologias que os provedores de Cloud Computing usam para prestação de serviço assim como as implicações dessas tecnologias sobre os recursos computacionais, sobre a economia e a segurança. Tal compreensão é relevante, pois a arquitetura da Máquina Social vai se entrelaçar a alguma camada da arquitetura do provedor de serviço Cloud Computing. Esta prática ajudará nas decisões 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, é possível dispor de recurso computacional automaticamente conforme a necessidade e crescimento da aplicação, isto sem esforço da equipe de desenvolvimento da Máquina Social. Além disto, com esta solução é possível usufruir de alta segurança e disponibilidade dos dados. Para um serviço de IaaS a empresa Amazon pode ser considerada. A organização, ou a pessoa, que adquirir os serviço 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 serviço “Amazon Elastic Compute Cloud (EC2)”. Com ele é possível montar um ambiente que pode ser usado para as implantações de banco de

38

Disponível na página 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

Informação disponível em: http://aws.amazon.com/ec2/. Acesso em 15 de out. 2010.

112

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

dados. Por fim, esses serviços IaaS são capazes de ofertar balanceamento de carga, segurança por meio de firewall, e replicação de instâncias de bancos de dados. Algumas recomendações sobre os serviços e recursos Cloud Computing prosseguem abaixo:  Guardar réplicas de segurança em outros repositório, sejam eles locais ou na

nuvem. Tais cópias devem ser, sobretudo, dos dados. Isto é necessário porque os recursos Cloud Computing são susceptíveis de falhas.  Usufruir sempre da garantia de disponibilidade e analisar outros métodos que

contribuam para a aquisição de desempenho da aplicação. Pesquisas recentes feitas pela empresa Compuware40 apontam que 72% das empresas avaliadas em uma pesquisa alegam que não houve ganhos em desempenho (mal desempenho) ofertados pelos serviços Cloud Computing.   Trabalhar fortemente com XML para a integração entre as camadas da

arquitetura na aplicação e na nuvem. Utilizar características de arquiteturas ou redes P2P para amenizar os

problemas da desaceleração das atividades de leitura e escrita em disco (KE et al. 2009).

2.

Economia:

O preço do serviço deve estar claro em uma SLA de CC. Alguns planos do Amazon EC 2, por exemplo, custam apenas 600 (seiscentos) dólares por ano41. Para algumas empresas, isto pode significar uma redução de custos, segundo a Forrester Research, de até 80% nos gastos com infraestrutura. Cloud Computing pode trazer redução de custos para empresa de pequeno e médio (PMEs) porte que não possuem um forte parque tecnológico. Logo, o nível de maturidade da TI em empresas desses portes, principalmente no Brasil, é relativamente baixo (REZENDE, 2006). Para as PMEs, o preço das boas ferramentas tecnológicas sempre foi elevado. Neste

40

Disponível 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

Informação disponível em: http://aws.amazon.com/ec2/. Acesso em 19 de ag. 2011.

113

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

aspecto, as ofertas de Cloud Computing podem ser vantajosas, mostrando um cenário mais promissor para a TI das PMEs. Cloud Computing pode ser uma solução econômica em situações onde se requer poder computacional. O exemplo seguinte explora muito bem essas situações. Segundo Taurion (2009), o jornal New York Times no ano de 2008 necessitou digitalizar todas as suas edições desde 1851 até o ano 1989. Entretanto, os recursos computacionais do jornal ficariam sobrecarragados, o que levaria a aquisição de novos recursos. Nesta situação a equipe de TI decidiu por adquirir os serviços Cloud Computing EC2 da Amazon, o que possibilitou o processamento de 3 (três) terabytes de dados, em 24 (vinte e quatro) horas, utilizando 100 (cem) instâncias virtuais a um custou de 240 (duzentos e quarenta) dólares. Por fim, o uso de SM’s dependerá muito do contexto econômico da empresa, apesar das aparentes vantagens há de se analisar todas as despesas decorrentes de treinamento, contratos, marketing e outras vertentes naturais do negócio. Somente assim será possível verificar se as vantagens serão refletidas por meio de economia financeira. A adoção de Cloud Computing para redução de custos é algo muito relativo, e não deve ser o fator preponderante para a adoção.

3.

Segurança:

A segurança é um requisito importantíssimo para qualquer sistema computacional. E a falta de segurança é um perigo presente não só para os usuários de Cloud Computing. Mas, se tratando de CC, existem receios em sua adoção que são oriundos da falta de segurança. O fato é que existem realmente riscos, mas, em oposição a eles, existem excelentes soluções que objetivam garantir a segurança. A grande preocupação reside em não saber se os dados estariam tão seguros em Cloud Computing quanto estariam seguros localmente. Pois bem, a privacidade nos dados, sobretudo quando se utiliza os serviços de uma Public Cloud, ou núvem pública, pode ser algo delicado, Os dados de uma empresa, ou cliente, que são armazenados em uma nuvem pública, normalmente residem em um ambiente compartilhado com dados de outros clientes e empresas. Assim é necessário trabalhar bem com o controle aos meios de acesso aos dados. Controle de acesso via senha é uma solução bem madura em Cloud Computing, uma vez que, por meio da senha os clientes e as empresas respondem a um conjunto de questões de segurança para ter acesso à conta. Neste contexto, a criptografia por meio do algoritmo RSA é 114

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

muito bem trabalhada. Existem ainda os certificados de chaves públicas. Eles permitem transferências de dados sempre protegidos usando novamente a criptografia. Geralmente isto pode ser implementado em SaaS, PaaS e IaaS diversificadas. Tais chaves rotineiramente são geradas fora da nuvem, o que oferta mais segurança e confiabilidade ao cliente ou empresa que são os únicos a terem conhecimento da chave. Todas as soluções de segurança contempladas nos parágrafos acima foram lançadas pelo NIST em um documento42 do mês de dezembro do ano de 2011. O mesmo possui práticas e orientações sobre segurança e privacidade em Cloud Computing. O documento orienta que a adoção da nuvem privada é mais adequada aos negócios de qualquer natureza, ou seja, a escolha por uma nuvem pública ou privada dependerá muito da natureza dos dados trafegados. Entretanto, o mesmo documento encoraja experiências com o modelo público de Cloud Computing. A segurança tem sido bastante trabalhada em Cloud Computing. Vale reforçar que novamente as SLAs devem tratar claramente das questões de proteção, privacidade dos dados, e garantia de integridade das aplicações. A próxima prática deixa a parte as questões de Cloud Compunting e aborda uma questão de elevada importância para um sistema distribuído em rede: a questão dos Padrões de Projeto.

5.3.9. PRÁTICA 9: Selecionar os padrões de projeto mais adequados para a arquitetura da Máquina Social.

Padrões de projeto são soluções de código que podem ser reutilizadas para resolver um determinado problema (GAMMA, et al. 2000). Estes padrões substituem implementações de códigos e projetos de componentes de software. São produtos preparados para interagir com implementação e agregar recursos que dêem suporte a alguma funcionalidade a ser desenvolvida. Problema: Os padrões de projeto podem ser utilizados com qualquer linguagem de programação desde que os conceitos de orientação a objetos sejam vigentes na aplicação. Entretanto, é necessário guiar esses padrões para o contexto de Máquinas Socias enquanto aplicações Web,

42

Disponível em: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909494.

115

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

limitando os mesmos. O quantitativo de problemas a serem resolvidos por Máquina Sociais é vasto, assim, a probabilidade de usar padrões diversificados é grande. Deste modo, deve-se fechar o escopo dos padrões para Máquinas Sociais a partir das características, conceito, e particularidades de uma SM’s. Ao todo existe um universo de 23 padrões de projeto. Quais destes ofertariam melhor suporte as SM’s? Além deste questionamento, existem também alguns problemas que são inerentes às Máquinas Sociais e que podem ser solucionados por padrões de projeto específicos. Alguns destes problemas são:    Não ter fácil acesso às informações sobe o estado dos componentes; Não ter conexões eficientes entre as Máquinas Sociais e entre os componentes que constituem as mesmas; Não ter ação necessária de forma imediata após conhecer o estado dos componentes. Motivação: É desejável que existam soluções reutilizáveis em algum nível de abstração e que sejam voltadas às Máquinas Sociais. Na verdade esse conhecimento poderá motivar o estudo de novos padrões para SM’s. Ainda assim, os padrões já existentes demonstram muita riqueza quanto à capacidade de resolver problemas naturais das Máquinas Sociais. Exemplo ou Solução: A execução desta prática deve levar em consideração que alguns padrões são fortemente utilizados no estilo arquitetural camadas, São eles: Observer, Composite e o Strategy (LARMAM, 2005). Além disto, os padrões são divididos em 3 (três) grupos: padrões de criação, padrões estruturais, e padrões comportamentais. Os padrões comportamentais e os padrões estruturais constituem os maiores grupos, e também são os mais relevantes para as Máquinas Sociais. Isto se deve ao fato do primeiro grupo de padrões ser o único a se preocupar com a conexão entre os objetos e classes. Estes padrões também priorizam a cooperação entre os elementos e ainda viabilizam o baixo acoplamento, o que é fundamental para a arquitetura em Camadas, segundo Craig Larmam, 2005. 116

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Larman também afirma que o outro grupo de padrões estruturais visa a composição das classes que formam os sistemas de modo que essas classes sempre tenham interfaces compatíveis no intuito de se unirem para formar uma unidade maior, como um componente que constituirá o sistema, ou o próprio sistema em si. Vale ressaltar que, se houver necessidade, os padrões do grupo de criação podem também ser empregados; principalmente os padrões que criam interfaces, como o Factory Method (GAMMA et al, 2000). Neste ponto veremos a definição de alguns dos padrões de projeto (GAMMA et al, 2000) mais preparados para atender a maioria das Máquinas Sociais enquanto sistemas Web.

Padrões de Projetos Estruturais Nome Adapter Definição / Problema a ser resolvido Faz a adaptação de interfaces em momento que uma classe não tem a interface que corresponde ao domínio esperado pela aplicação. Composite Compõem classes para formar um componente maior, deixando transparente ao usuário ao qual está fornecendo o serviço, se um componente ou se o conjunto destes. Previlegia o baixo acoplamento. Decorator Usa de forma flexível a extensão de subclasses para acrescentar operações acionais às classes ou objetos. Isto quando se fizer necessário a adaptação da função de um componente para uma funcionalidade específica.
Tabela 6. Padrões Estruturais relevantes para as SM’s

Padrões de Projetos Comportamentais Nome Mediator Definição / Problema a ser resolvido Armazena em um objeto a forma pela qual todos os outros objetos irão interagir; ele é aplicado para reduzir a duplicação de código, pois as classes, ao serem criadas podem ser customizadas para ter sua comunicação e função viabilizadas por este padrão. Observer Gera uma ligação entre os objetos de modo que, no momento em que um objeto alterar seu estado, todos os objetos sejam automaticamente notificados da alteração. 117

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

State

Permite que um componente altere suas funções conforme a alteração do seu estado.

Strategy

É um conjunto de algoritmos distintos que pode ser executado para alterar o comportamento de uma classe conforme as variações do ambiente ou conforme a necessidade dos requisitos.
Tabela 7. Padrões Comportamentais relevantes para as SM’s

A aplicabilidade dos padrões comportamentais sobre as SM’s é maior do que a aplicabilidade dos padrões estruturais. Outros padrões, fora ou não desses grupos, podem ser de grande valia às SM’s, mas isto irá depender unicamente das características da aplicação 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 padrões às SM’s. Imaginemos que a camada de negócio poderá ter em seus componentes a inserção do padrão Strategy, que será útil no caso de uma camada superior da arquitetura ofertar uma resposta negativa, ou fora do esperado, neste caso, graças ao padrão, a camada inferior não responderia as solicitações, anulando assim, suas operações. O exemplo acima é um caso que retrata a contribuição de um padrão na satisfação de um requisito não funcional para a Máquina Social. Quando se observa melhor a prioridade desses requisitos, é possível empregar melhor os padrões. A tabela 8 mostra o relacionamento entre os padrões indicados para as Máquinas Sociais e os requisitos não funcionais das mesmas.
Padrões 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. Relação entre os padrões de projeto e os requisitos não funcionais das SM’s

Esta prática, assim como todas as outras, tende a orientar os desenvolvedores quanto às melhores decisões de projeto para a Máquina Social a ser implementada. A decisão mais assertiva em relação a banco de dados de Máquinas Sociais será exposta a seguir: 118

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

5.3.10. PRÁTICA 10: Selecionar o banco de dados não relacional

Bancos de dados não relacionais, ou NoSQL, surgiram em 1998. O propósito deste tipo de banco de dados é suprir as carências que estão presentes nos bancos relacionais, entre elas, a escalabilidade e a flexibilidade em mudar estruturas. A abordagem NoSQL tem sido a mais explorada entre grandes coorporações da Web 3.0, como: Facebook, Twitter, Google e Amazon (LEAVITT, 2010). Problema: O problema reside no fato das Máquinas Sociais serem, em grande parte, aplicações que necessitam de bom gerenciamento dos acessos aos dados, acessos que passam a ser crescentes ao passo que cresce a quantidade de usuários da aplicação, necessitando assim de escalabilidade para a performance. Tal requisito é deficitário em banco de dados relacionais (LEAVITT, 2010). Motivação: Explorar uma abordagem mais moderna e que propicie a escalabilidade de forma mais simples e mais barata que os modelos relacionais é uma grande motivação para as SM’s. Não é necessário que a SM a ser desenvolvida tenha milhões de usuários em acessos simultâneos. 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 não relacionais atendem de forma mais eficiente os requisitos das Máquinas Sociais, sobretudo, desempenho (TIWARI, 2011). Exemplo ou Solução: Para seguir tal prática é necessário 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

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas 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 soluções são distribuídas e executam o chamado “processo de sharding”. Esse processo faz o escalonamento paralelizado (TIWARI, 2011), ou seja, os dados são distribuídos por vários servidores que trabalham de forma paralela. Isto possibilita a escalabilidade. Já o desempenho da SM é sensivelmente melhorado devido à diminuição 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 BD’s podem ficar indiponíveis sem causar a interrupção de toda a SM. Com NoSQL, disponibilidade, desempenho/performance e flexibilidade são agregados a arquitetura. Isto contribui ainda mais para o bom funcionamento da SM. Até mesmo a consistência 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 análise da SM a ser construída, é necessário selecionar como será o sistema de armazenamento. Nesta análise, 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 benefícios em sua aplicação, principalmente na questão da consistência dos dados. As conclusões deste capítulo vão em seguida abordando as práticas para SM, sintetizando as idéias, amadurecendo alguns possíveis trabalhos futuros, além de preparar o próximo capítulo.

5.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO

Algumas práticas recomendadas aqui dão novas idéias que podem ser amadurecidas perfeitamente em trabalhos futuros, como: os padrões de projeto que podem ser adaptados para as SM’s, fazendo surgir assim um novo padrão; bem como, o framework de Máquinas Sociais exposto neste trabalho, e ainda, possíveis padrões de processo de SM’s. Os padrões de 120

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

processo fazem parte das disciplinas ligadas a negócio e administração de empresas, todavia, existe uma proposta de padrão de processo chamada Business Pattern, autoria de Mark Endrei e mais 7 (sete) autores pela empresa IBM no ano de 2004. Os padrões de processo exibem vários padrões de TI. Estes padrões guiam o desenvolvimento de aplicações específicas, como por exemplo, ferramentas Web que viabilizam o trabalho colaborativo. Uma das recomendações para esse tipo de sistema seria implementar a ferramenta por meio do Collaboration (User-to-User). Este é uma padrão que teria os conhecimentos mais adequados sobre as tecnologias de implementação, arquitetura e reuso de componentes do trabalho colaborativo. Logo assim, as práticas aqui tratadas poderiam formar um padrão de construção de SM’s, fazendo parte do catálogo do “Business Pattern”. Em vista de justificar alguns conceitos é importante evidenciá-los ao final do catálogo de boas práticas. Na verdade as práticas constituem sim um padrão para construção de Máquinas Sociais, e, para isto, adota estratégias que deixam evidente o uso de alguns conceitos e tecnologias, como componentização de software. A criação de componentes de software exalta a criação de pequenas partes do software com funções bem definidas e interfaces adaptáveis para a conexão com uma variedade de aplicações. A implementação de componentes particiona a aplicação, facilitando a adoção do estilo camadas e promovendo a independência de tecnologias (CHEESEMAN e DANIELS, 2001). A manutenção e evolução do software também são facilitadas, podendo a arquitetura da aplicação ser estendida sem muita dificuldade de modo que seus componentes possam ser distribuídos (TANENBAUM, 2002), integrados e reutilizados. Em praticamente todas as práticas existe uma menção à componentização de software, especialmente as práticas 5 (cinco) e 2 (dois), aliás, a 2ª e 3ª prática tratam dos assuntos relacionados a SOA inclusive. As primeiras práticas remetem aos princípios que são trabalhados no paradigma da Arquitetura Orientada a Serviços – SOA; a adoção desse paradigma já trouxe diversos benefícios às médias e grandes empresas (ERL, 2008). SOA ou Arquitetura Orientada a Serviço é baseada em computação distribuída e seu conceito está voltado para a utilização de software como serviço. SOA, assim como a componentização, contribui para a reutilização de software favorecendo a comunicação entre os sistemas (JOSUTTIS, 2007). 121

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Para adotar SOA, é necessário fazer um catálogo de todos os processos que apóiam a TI e que sejam parte do nicho de negócio dos softwares implementados (JOSUTTIS, 2007). Estudos recentes efetuados pelo instituto de pesquisa Gartner revelam que SOA promove uma maior eficiência na execução dos processos de negócio, facilitando o surgimento de outros processos, reduzindo gastos, melhorando a escalabilidade do sistema, a qualidade e o tempo de entrega dos serviços. SOA também 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 SM’s. Não é propósito adotar SOA definitivamente em SM’s, mas sim adotar alguns princípios e conceitos de SOA e que podem auxiliar no desenvolvimento facilitado de SM’s, como por exemplo: o tratamento aos serviços e o cuidado com a modelagem de processos. Assim, a modelagem de processo que é tratada na primeira prática pode dar suporte para demais práticas. Os serviços só são bem mensurados quando se conhece o negócio. Neste trecho é notável uma relação de dependência entre as práticas. As práticas 7 (sete) e 9 (nove) estão também bem entrelaçadas às demais práticas. Neste caso, a prática sete, por exemplo, ajudará a encontrar a melhor solução em comunicação e interoperabilidade mediante o auxílio de outras práticas, como: as práticas de análise dos serviços, de implementação dos elementos States e Constraints, dos estilos arquiteturais que compõem a arquitetura da SM e os padrões de projeto utilizados. Outra relação que pode ser ainda traçada é entre as práticas e os requisitos não funcionais que devem ser priorizados para as SM’s. Dentro deste contexto deve-se observar que a alteração na metodologia proposta deve ajudar a arquitetura a satisfazer os requisitos não funcionais críticos para a Máquina Social. Deste modo, a tabela 9 relaciona os requisitos às práticas.

122

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

RNF Práticas 1.Modelar Processos 2.Reconhecer os Serviços 3.Reconhecer os Provedores 4.Recursos para Autonomia 5.States e Constraints 6.Extratégia Estilo Arquit. 7.Comunicação e Interoper. 8.Cloud Computing 9.Padrões 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

X X

X

Tabela 9. Relação entre as práticas e os requisitos não funcionais

Aproveitando o ensejo da exibição da tabela 9, é inteligente reforçar mais uma vez que as práticas podem se comportar como decisões de projeto que vão compor a arquitetura. Ou seja, que vão auxiliar a estruturar a Máquina Social. Sendo assim, as práticas propõem a adoção de certas tecnologias, tecnologias que fazem parte da arquitetura de referência e que podem ser ilustradas na Figura 23. Tal Figura verdadeiramente é mais uma abstração da arquitetura de referência para SM’s. Por meio da Figura 23 é possível notar que técnicas de SOA e BPMN podem ser empregadas no início do projeto, fase de concepção, uma das primeiras fases no processo de definição arquitetural (primeira camada do processo/arquitetura). Em um segundo plano, algumas das tecnologias já referenciadas pela metodologia são aplicadas em camadas mais centrais da SM’s; por fim, a alocação de algum modelo não relacional de base de dados. Todas essas camadas são divididas e envoltas aos padrões de projeto citados na prática.

123

Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais

Figura 23. Abstração da arquitetura de referência (tecnologias)

A fim de comprovar a eficiência das práticas recomendadas, sera desenvolvido um estudo de caso, o próximo capítulo tratará deste estudo, onde uma Máquina Social irá ser desenvolvida mediante a metodologia proposta.

124

Capítulo

6
6. Experimentação das Práticas
Este capítulo foi concebido para mostrar a aplicação das práticas propostas para o desenvolvimento de arquiteturas de Máquinas Sociais. O objetivo é guiar as decisões de projetos e a própria modelagem da arquitetura. Assim, ao final da implementação, será verificado como o produto desta pesquisa foi útil ao desenvolvimento de SM’s.

125

Capítulo 6. Experimentação das Práticas

6.1. INTRODUÇÃO

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 próprio de trabalho. No entanto, antes de exibir o estudo, haverá uma seção para expor brevemente um projeto piloto, o qual foi utilizado para por em prova o planejamento do estudo de caso e o próprio objeto de controle, ou seja, a abordagem a ser experimentada. Nem todos os detalhes sobre o desenvolvimento serão expostos, pois os projetos são reais de empresas e profissionais fixadas no mercado, onde os produtos, ou SM’s resultantes, ainda não estão disponíveis aos clientes ou usuários. Os responsáveis pelo desenvolvimento das SM’s que serão exibidas neste capítulo autorizaram a exposição das mesmas. No entanto, como já explicitado, por questões de confidencialidade exigidas pelos proprietários das SM’s, e também por causa de concorrência da indústria de software local, algumas informações serão subtraídas da exibição do desenvolvimento. Todavia acredita-se que a ausência de tais informações não deixará pontos duvidosos ou falsos no estudo.

6.2. DEFINIÇÃO DOS OBJETIVOS 1. Objetivo Global: Determinar o efeito do uso das práticas e da arquitetura de referência na definição de arquiteturas de Máquinas Sociais na qualidade dessas arquiteturas. 2. Objetivo da Medição Baseado nas Características das SM’s e na Comparação em não Usar as Práticas e a Arquitetura de Referência - AR: verificar as vantagens oferecidas pela AR e práticas de SM’s na definição da arquitetura sobre os aspectos: adequação das práticas, precisão nas escolhas arquiteturais, usabilidade da arquitetura de referência, agilidade na fase de projeto de arquitetura, ou simplesmente projeto; e por fim, a qualidade dos componentes codificados na fase de implementação. 3. Objetivo do Estudo: Analisar a adequabilidade da arquitetura de referência e das práticas propostas em projetos de Máquinas Sociais quando comparado ao desuso das mesmas, isto no contexto de empresas que desenvolvem SM’s. 126

Capítulo 6. Experimentação das Práticas

4. Questões: a. Os pontos tratados pelos métodos propostos para SM’s, ou seja, práticas mais AR, são suficientes para a arquitetura da SM ser desenvolvida em todos os seus aspectos ou ao menos aos aspectos mais importantes como os requisitos não funcionais? i. Métrica: Quantidade de pontos ou requisitos trabalhados pela arquitetura com auxílio dos métodos propostos. b. As práticas e arquiteturas de referência para SM’s auxiliaram na definição adequada dos componentes arquiteturais, ofertando assim maior qualidade do produto de software e consequentemente da arquitetura? i. Métrica: Quantidade de não conformidades encontradas por meio de testes funcionais e também por meio da aceitação do cliente. A questão e métrica relacionada as não conformidades são difíceis de serem controladas. Se este experimento fosse feito em laboratório, onde todas as variáveis 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 decisões de projeto e arquitetura. Com isto é complicado saber qual a causa dos defeitos. No entanto, é válido incluir essa questão e métrica, pois as práticas trabalham na concepção dos processos de negócio e serviços, o que faz elas enrriqueçam os requsitos, e melhorem a arquitetura. Averiguar a quantidade de defeitos encontrados nos artefatos testados após o uso das práticas na arquitetura de referência dará indiícius de que as mesmas auxiliaram em algum aspecto, ou mesmo em conjunto a outros fatores, na diminiução dos defeitos.

127

Capítulo 6. Experimentação das Práticas

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 são as práticas e arquitetura de referência propostas para conceber arquiteturas de Máquinas 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 à experimentação é a fase de projeto, ou modelagem de sistema. Nesta será verificado a utilidade da metodologia de SM e se a mesma é adequada para a formulação da arquitetura de Máquinas Sociais. 6.3.3. DEFINIÇÃO DAS HIPÓTESES

Serão divididas em hipótese nula, que representa o que o estudo quer negar (WOHLIN. et al, 2002); e hipótese alternativa, que representa o contrário da hipótese nula (TRAVASSOS, GUROV e AMARAL, 2002).  HIPÓTESE NULA: O uso das práticas e da arquitetura de referência não demostrou diferença nos parâmetro abaixo em relação ao não uso das mesmas pela empresa para a definição de arquitetura. NºPOR: número de requisitos da SM trabalhados pela arquitetura. AD: adequação da arquitetura concebida por meio do objeto de controle. Deste modo o que a hipótese nula afirma é: NºPORsempráticas+AR=NºPORpráticas+AR ADsempráticas+AR=ADpráticas+AR 

HIPÓTESE ALTERNATIVA: O uso das práticas e AR revelou ganhos em relação aos parâmetros, de modo que, a qualidade do produto foi atestada como satisfatória, assim: NºPORsempráticas+AR<NºPORpráticas+AR 128

Capítulo 6. Experimentação das Práticas

ADsempráticas+AR<ADpráticas+AR

Dentre estas variáveis o fator tempo não foi controlado. Entende-se que o mesmo não agregaria resultados significativos, uma vez que é possível que o tempo da fase de projeto seja maior com a utilização das práticas. Isto, em equipes que já façam uso de uma metodologia de concepção da arquitetura. O objetivo também não é viabilizar uma arquitetura em pouco tempo, mas sim, disponibilizar uma arquitetura correta e de qualidade à Máquina Social.

6.3.4. VARIÁVEIS INDEPENDENTES E DEPENDENTES 

VARIÁVEIS INDEPENDENTES:

1. Tipo de Máquina Social a ser construida: é necessário que sejam desenvolvimentos interessantes de Máquinas Sociais do tipo Prosumers, pois essas SM’s são mais completas e complexas. Sendo assim, o resultado pode ser verificado para o caso mais extremo de SM’s. Com isto, se o resultado for satisfatório, entende-se que o objeto de controle poderá ser aplicado sem maiores problemas para os projetos de SM’s mais simples. 2. Habilidade da equipe em desenvolver e entender as aplicações WEB como Máquinas Sociais: em equipes que já entendem as apliações como SM’s, as novidades nas práticas e AR poderão não agregar benefícios de grandes dimensões. 3. Fase do processo de desenvolvimento: a fase é um fator relevante porque é necessário trabalhar o objeto de controle em um momento que possibilite o acompanhamento do projeto e a instanciação das práticas e arquitetura de referência. Ou seja, os desenvolvimentos não devem estar na fase de codificação da aplicação ou mesmo documentação de arquitetura.  VARIÁVEIS DEPENDENTES: 1. Maior quantidade de pontos ou requisitos trabalhados pela arquitetura para satisfazer a Máquina Social; 129

Capítulo 6. Experimentação das Práticas

2. Adequabilidade maior da arquitetura à Máquina Social, com poucas, ou nenhuma não conformidade (defeitos encontrados).

6.3.5. RUÍDOS

Os ruídos podem contaminar as variáveis durante o experimento. Estes ruídos são erros que ocorrem de forma não intencional e sim inesperada durante o estudo (TRAVASSOS, GUROV e AMARAL, 2002). Um ruído provável seria a não execução de alguma prática proposta devido a um acontecimento que exija menos tempo de desenvolvimento, provocando assim, uma má execução da fase de (projeto) modelagem. Outro ruído seria a ausência de algum integrante da equipe, ausência provocada por um problema ou por alguma determinação 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 produção de software que utiliza profissionais da área de Ciências da Computação como participantes. Os resultados deste experimnto podem ser úteis a problemas específicos da modelagem arquitetural de Máquinas Sociais.

6.3.7. SELEÇÃO DOS INDIVÍDUOS Os indivíduos que estiveram contidos neste estudo de caso faziam parte da equipe de desenvolvimento e foram selecionados mediante determinação da própria 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 codificação ainda não haviam iniciado. Além disto, a empresa se colocou à disposição do experimento. Quanto à empresa, é importante citar que o estudo de caso foi sobre uma Máquina Social criada pela empresa MV Informática Nordeste. A MV é uma empresa com mais de 25 anos no mercado de desenvolvimento de software para gestão hospitalar. A linha de produção da MV é responsável por sistemas que automatizam todos os processos de instituições ligadas à saúde no Brasil, entre elas: planos de saúde, clínicas, hospitais públicos e privados, e 130

Capítulo 6. Experimentação das Práticas

também unidades de pronto atendimento, as UPA’s. Assim, os sistemas possuem funcionalidades que fazem desde o controle financeiro até o controle de fichas anestésicas de pacientes, incluindo o prontuário eletrônico do mesmo. A MV autorizou a documentação e exposição deste experimento. 6.3.8. VALIDADE Nesta seção as possíveis ameaças à validade do experimento (JURISTO e MORENO, 2001) serão listadas. Três ameaças à validade foram detectadas, a primeira foi a Validade Externa. Validade Externa pode limitar o resultado obtido no experimento de modo que as práticas e AR para SM’s tenham uma adoção duvidosa por parte da indústria de software. Nesta categoria, uma ameaça é a inserção de requisitos durante a fase de projeto ou mesmo após tal fase. É possível que o cliente solicite um requisito fora da fase de análise. 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 variáveis. Dentre as ameaças a validade houve a imposição da empresa em começar o desenvolvimento. Havia datas predefinidas e improrrogáveis para o início de cada fase do processo. O desenvolvimento do produto da MV teve acompanhamento constante, com exigências de diversos gestores e um diretor. Este fato impulsionou outra ameaça, desta vez à Validade de Conclusão. Uma vez que houvesse a pressão para o início do projeto, não haveria tempo hábil para começar o experimento com o emprego das práticas e da AR de Máquinas Sociais. Deste modo, o experimento deveria iniciar sem o objeto de controle, apenas por meio da metodologia tradicional já utilizada anteriormente pela empresa. Esta ameaça própria da Validade de Conclusão imposibilitaria concluir com convicção 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 também de quais problemas deveriam ser resolvidos, além das necessidades arquiteturais, haja vista que já haveriam projetado em um momento primário a arquitetura sem o uso das práticas e da AR.

131

Capítulo 6. Experimentação das Práticas

O preparo acima mencionado, tanto em relação à equipe quanto ao produto de software a ser modelado e implementado pode caracterizar outra ameaça para o tipo Validade Interna. Esta validade se refere ao cansaço mental, físico, preocupação ou estresse dos participantes durante o experimento, pois que, todos os envolvidos poderiam participar de outros projetos concomitantemente ao experimento.

6.4. EXECUÇÃO

6.4.1. PROJETO PILOTO O projeto piloto é a execução da experimentação em outro ambiente, com outras pessoas e com outra unidade experimental (JURISTO e MORENO, 2001). Ele será útil para corrigir possíveis erros no planejamento do experimento e verificar se existem melhorias que possam ser feitas no próprio objeto de controle. O projeto piloto foi executado sobre uma App de mercado que não foi desenvolvida por uma fábrica de software, mas trata-se de um projeto realizado por um profissional da área de TI. Sua implementação 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 função é sugerir acontecimentos sociais (festas) aos usuários conforme a localização dos mesmo. O HobNob precisa de informações básicas de uma pessoa, precisa saber sua localidade e os gostos pessoais em relação à música, a artista favorito, e às festas frequentadas. Essa App é uma aplicação dedica ao Facebook. A aplicação tratada neste experimento utiliza o Facebook de forma inteligente, haja vista ela mapeia até as ligações de amizade entre os usuários da rede, ou seja, ele captura o grafo de amizade codificando os relacionamentos entre os objetos deste grafo. Deste modo, é possível revelar e indicar festas que amigos de um determinado usuário foram, ou vão, e que possivelmente este usuário possa querer ir. A formação do conhecimento para poder sugerir festas a uma pessoa conforme sua localização também parte da utilização dos serviços do Google Maps. Por este parágrafo é possível observar que o HobNob é uma Máquina Social Prosumers por natureza. Os principais resultados e efeitos deste projeto piloto serão detalhados em seguida.

132

Capítulo 6. Experimentação das Práticas

Neste projeto inicial, o conjunto de práticas foi seguido, e elas foram plenamente compreendidas na ordem em que foram documentadas no capítulo 5. Entretanto, nem todas foram lidas em sua completude, pois, neste experimento o responsável pelo desenvolvimento já compreendia bem os conceitos de SM’s 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 práticas. Para o projeto piloto, as primeiras práticas não tiveram muita contribuição pelo fato da aplicação já ser direcionada unicamente ao Facebook e ter um escopo bem limitado. Apesar deste fato, o conhecimento sobre serviços, que é a proposta das práticas, foi algo novo no desenvolvimento, logo que, os conceitos relacionados à serviço sempre estavam atrelados aos fatores mais técnicos da codificação 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 detecção de uma falha no planejamento, falha que resultou na criação da variável independente número 2 (dois) sobre a habilidade da equipe em desenvovler e entender as aplciações WEB como SM’s. Ainda sobre os ajustes efetuados após este projeto piloto, deve-se relatar que todas as práticas foram seguidas, mas, houve a percepção da ausência de uma recomendação. Assim, uma prática foi adicionada, a mesma é identificada como prática 10 e faz referência ao uso de NoSQL. Ao final da execução deste projeto, foi possível notar que o uso de práticas como a de SM’s foi algo inédito para o desenvolvimento, entretanto, a adoção da AR foi mais proveitosa em relação às práticas, pois estas não 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 SM’s.

6.4.2. ESTUDO DE CASO EDITOR DE FORMULÁRIOS/TELAS – MVPEP

6.4.2.1. Preparação No sistema de prontuário eletrônico de um paciente, ou simplesmente MVPEP, se encontra o Editor de formulário/telas. O Editor é responsável por criar ou desenvolver funcionalidades que não são supridas pelo MVPEP, ou seja, o Editor desenvolve telas, ou

133

Capítulo 6. Experimentação das Práticas

pequenos programas de software que aceitam entrada de dados, fazem um determinado processamento, e apresentam um resultado satisfatório ao usuário. A equipe responsável pela implementação do Editor é composta por 4 (quatro) pessoas, um analista de sistemas, um arquiteto, e 2 (dois) programadores. A MV determinou um período de tempo pequeno para desenvolver o Editor, sendo que o início 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 mês, montando um o relatório 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 parâmentros eleitos na variável alternativa foram registrados em um formulário próprio para que os valores fossem pontuados nos mesmos. Para melhor entendimento dos motivos pelos quais o Editor é considerado uma Máquina Social, fator relevante para a seleção do projeto como estudo de caso, será apresentado a seguir algumas poucas funcionalidades do Editor. Com o Editor, é possível que os profissionais de TI do hospital, clínica ou UPA possam construir uma tela com vários recursos, desde cálculos, comparações de dados, respostas automáticas de questionamentos, tabelas e marcação de imagem (onde se marca na própria imagem a parte afetada em um trauma corporal). Além disto, o Editor pode apenas montar layout de formulários, trazendo para uma página todos os componentes já criados por outras funcionalidades do sistema que abriga o Editor. O Editor é altamente interoperável, pois não é 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 relatórios e formulários que exibem os dados de exames de imagem e de laboratório. A figura 24 demonstra a área de trabalho do Editor. Nele o usuário desempenha todas as funções necessárias para criar documentos ou telas.

134

Capítulo 6. Experimentação das Práticas

Figura 24. Editor no modo de criação de documentos no MVPEP (VERSÃO 1.5)

A Figura 25 o Editor é exibido na sua forma de utilização final, ela representa uma tela com formulário a ser preenchido pelo usuáiro final na utilização do Editor pelo MVPEP.

Figura 25. Documento/tela do Editor sendo utilizado por um usuário final no MVPEP (VERSÃO 1.5)

135

Capítulo 6. Experimentação das Práticas

6.4.2.2. Execução A MV iniciou o desenvolvimento do Editor com a análise do negócio e desenvolvimento dos requisitos. Após o término da fase de requisitos, coube ao arquiteto desenvolver o projeto arquitetural seguindo um processo para definição da arquitetura que consistia em analisar os requisitos e propor soluções 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 parâmetros avaliados nas hipóteses alternativas. Após a finalização das etapas iniciais do projeto de desenvolvimento, levou-se algum tempo até que a confecção de alguns módulos do Editor começasse. Três grandes funcionalidades foram implementadas: a funcionalidade de integração do editor com os demais sistemas, a funcionalidade de escrita e edição de texto, e a funcionalidade de criação de perguntas. Essas 3 (três) funcionalidades fazem com que o Editor seja utilizado pelo seu usuário final perfeitamente, É claro que as demais funcionalidades que são recursos adicionais, como por exemplo criação de tabela, devem ser futuramente inseridas. Todos os resultados deste momento do estudo, com a primeira rodade de experimentação sem o uso das práticas e AR foram registrados. No apêndice C é possível verificar o formulário onde os valores dos parâmetros foram apontados. O desenvolvimento do editor foi paralisado logo na primeira avaliação do cliente, pois verificou-se não conformidades aos requisitos, principalmente no requisito não 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 orientações das práticas e AR proposta. Exatamente as mesmas funcionalidades foram desenvolvidas tanto na definição arquitetural sem uso das práticas e AR, como com o uso destas. A equipe também prevaleceu a mesma, bem como, os prazos. Na verdade, como houve desaprovação de funcionalidades, de performance e interoperabilidade, o cliente aproveitou o ensejo e solicitou pequenas alterações nos requsitos. Foi solicitada nova análise dos problemas e modelagem, o que possibilitou a experimentação do objeto proposta neste trabalho sem demais problemas. A experimentação executada com o uso das práticas e AR teve todos os resultados expostos em um documento em anexo. Nesta seção, será inserido apenas a forma pela qual houve a adoção da metodologia e os resultados obtidos. Desta maneira, na fase de projeto 136

Capítulo 6. Experimentação das Práticas

arquitetural, a arquitetura de referência foi visualizada e compreendida. Em seguida, houve um esboço da arquitetura Editor_Core, a arquitetura do Editor, que foi amadurecendo ao passo que as práticas e AR foram compreendidas e atendidas. É importante frisar que alterações em requisitos não caracterizaram uma alteração brusca do que já havia sido analisado anteriormente, as alterações foram sutis, mas poderiam estender a arquitetura.

6.4.2.3. Resultados Obtidos

Tanto o arquiteto quanto a equipe responsável pelo desenvolvimento do Editor estavam mais estressados no momento de refazer a arquitetura e experimentar as práticas e AR de SM’s. A preocupação foi uma ameaça prevista, pois poderia atrapalhar a averiguação das variáveis, uma vez que conduziria a equipe a um cuidado maior na segunda rodada de experimentação com a metodologia de SM’s, fazendo os resultados da mesma sofrerem influência. De fato todos estavam mais seguros quanto aos requisitos e aos problemas da aplicação; isto pode ser uma desvantagem para o objeto de controle; mas pode também ser um forte indício de sua feliz aplicabilidade, sendo que, mesmo a equipe estando com um nível de estresse mais elevado, foi possível que uma arquitetura mais adequada fosse definida. O Editor é uma Máquina Social completa e repleta de particularidades que podem não se repetir em outras SM’s. Mesmo assim, ele é uma SM por ser uma palicação Web que pode ser incorporada à outra aplicação com a finalidade de suprir alguma funcionalidade não existente na mesma. Por exemplo: o Editor se incorpora ao sistema de Prontuário de Pacientes com a finalidade de produzir telas com entrada, processamento, e saída de dados. Ou seja, funcionalidades não existentes no PEP, como o cálculo e armazenamento da massa corporal de um paciente. Mais importante do que construir uma SM por meio das práticas e da arquitetura de referência foi a experiência e o entendimento dos conceitos das Máquinas Sociais. Os participantes demonstraram a necessidade de conhecer esses conceitos para que as práticas fossem aceitas e fizessem sentido. Foi possível registrar que o entendimento da arquitetura de referência fez a equipe do Editor notar a forte necessidade de se ter uma camada Wrapper dedicada apenas aos serviços providos e requeridos. Tal camada deveria ter componentes dedicados a cada sistema no qual o Editor deveria interagir. Alem disto, na MV não existia a prática de formular um documento de decisão arquitetural no qual a arquitetura seria baseada, isto certamente ocasionava alguns 137

Capítulo 6. Experimentação das Práticas

retrabalhos em determinada fase do desenvolvimento, o que não houve com a adoção das práticas e da arquitetura de referência. Ainda por meio do acompanhamento direto do projeto Editor e também do conhecimento a respeito de outros desenvolvimentos na MV, foi possível fazer uma análise e notar o que foi obtido por meio da adoção das propostas para concepção de arquiteturas para SM’s:  Visualizar facilmente a importância de se escrever as decisões de projeto. Na verdade, as decisões do projeto Editor foram geradas pelas práticas das SM’s em si;  Verificar a necessidade da modelagem de negócio, pois esta fase é geralmente omitida em alguns projetos de software da MV. Deste modo, a definição de como alguns serviços seriam providos foi deficitária, obrigando a equipe a modelar alguns processos de negócio;  Os problemas de integração entre Editor, MVPEP e o MVSOUL foram descobertos no momento da análise arquitetural, e não no momento da integração, como ocorreu quando não foram utilizadas as práticas e AR; as práticas 343, 544 e 745 contribuíram fortemente para isto;  Os padrões de projeto mais adequados às SM’s foram estudados. Apesar da equipe responsável ter grande experiência com Design Pattern, os padrões foram classificados com a prática 9, proporcionando uma adoção mais rápida, e demonstrando muita eficiência para o Editor, como o caso do padrão Adapter;  A fase de definição de arquitetura foi desenvolvida resultando em uma documentação útil à manutenção 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

Prática 3: Conhecer os provedores de serviço da aplicação. Prática 5: Determinar os recursos que implementarão os elementos States e Constraints. Prática 7: Determinar o recurso que proverá a comunicação e interoperabilidade.

45

138

Capítulo 6. Experimentação das Práticas

realidade. No entanto, houve o entusiasmo por parte da equipe e mesmo de alguns gestores em conhecer mais os benefícios dos recursos Cloud;  A equipe de desenvolvimento pôde conhecer mais dois produtos da MV de extrema relevância que é o MVSOUL e o MVPEP. Além disto, puderam verificar que questões relevantes para as SM’s não são devidamente tratadas nesses sistemas, como exemplo: a disponibilidade. Isto já preparou melhor a equipe para futuros problemas. As primeiras práticas, sobre serviço, ajudaram fortemente neste avanço;  O trabalho de definição de interface e design gráfico para o Editor foi preciso, pois as informações adquiridas dos serviços providos e da integração com os sistemas puderam contribuir para que os designers descobrissem os problemas de usabilidade que poderiam surgir; As demais ameaças previstas infelizmente ocoreram. Como explorado na execução, as práticas e AR de SM’s foram experimentadas em desenvolvimentos que ocorreram após o desenvolvimento dos módulos sem as práticas e AR (sem alterações). Com isto, por falta de tempo, de pessoas, e até mesmo por uma evolução do conhecimento a respeito de como proceder o estudo, não foi possível 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 não inviabilizou o estudo, uma vez que as exigências foram maiores em virtude do descontentamento da primeira arquitetura, além disto, alguns requisitos foram alterados e eram desconhecidos pela equipe. Devido às ameaças, infelizmente algumas práticas não puderam ser aproveitadas. A adoção do Framework de SM’s, por exemplo, não foi possível por não haver tempo hábil para desenvolvê-lo. No entanto, houve a percepção por parte de toda equipe, que tal recurso seria interessante. Inclusive as práticas construíram um roteiro no qual a equipe de desenvolvimento não tinha visibilidade, pois as demandas de desenvolvimento são muitas, além de serem complexas e de curto prazo, prejudicando por vezes o desenvolvimento organizado. Apesar das ameaças, as práticas guiaram a equipe a focar em pontos chaves para o desenvolvimento eficaz da Máquina Social, pontos que nem sempre foram tratados pela própria empresa. As práticas 5 e 7 são exemplos disto. Por meio da aplicação do objeto de controle foi possível que a equipe visualizasse o projeto Editor como de fato um projeto de 139

Capítulo 6. Experimentação das Práticas

Máquina Social por todos os aspectos da aplicação, sobretudo, a comunicação e adaptabilidade aos sistemas da MV. Outro ponto que também é negligenciado e que foi visualizado e compreendido pela equipe foram as regras de negócio, em que a primeira prática solicita a modelagem de alguns processos que atenderam aos serviços. A MV não pensa em serviços na hora de construir suas aplicações, assim, a modelagem do negócio geralmente era afetada e gerava retrabalho. Para o projeto Editor este erro não ocorreu. Entretanto, a MV ainda precisa estar atenta a todos os outros projetos de desenvolvimento espalhados pelas equipes que compõem a fábrica. Sendo assim, no último período do ano de 2011, a empresa constituiu uma equipe de analistas de negócios e gerentes de produtos justamente pensando em melhorar a concepção de seus serviços. O experimento contribuiu fortemente para este pensamento. Duas outras ações que podem ofertar grande potencial ao desenvolvimento da MV surgiram por meio deste experimento com o Editor: a melhoria no processo de gerência de configuração com a adoção 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 serviços (OSGi ALLIANCE, 2005 ). Muitas ações ainda podem ser geridas para ajudar o trabalho da MV. A utilização das práticas e da AR auxiliou a equipe do Editor e motivou a MV a utilizar mais vezes tal objeto em Máquinas Sociais que possam fazer parte do nicho de negócio da empresa. Além disto, este estudo mostrou a este trabalho de arquitetura e SM’s, como alguns assuntos ainda são pouco explorados na realidade da indústria de software local. Uma evidência disto foi revelada pela prática 8. A prática 8 sobre Cloud Computing mostrou a realidade não só da MV, mas talvez de muitas outras empresas e fábricas de software em relação à CC. Na MV, são poucos os profissionais habilitados a trabalhar com Cloud Computing. Além disto, a empresa não tem nenhuma ação ou planejamento para empregar tal paradigma nos projetos atuais e futuros do portfólio da empresa.

46

Maven é uma ferramenta que controla a entrega de códigos funcionais, com isto ele proporciona o gerenciamento e a automação de projetos de software [SONATYPE, 2008].

140

Capítulo 6. Experimentação das Práticas

Por fim, o caso Editor agregou muito conhecimento à equipe responsável, mostrando indícios de que o projeto é longo e muito ainda deve ser feito para que o Editor seja uma Máquina Social excelente; os problemas apresentados ao final do experimento com as práticas e AR de SM’s foram no requisito de usabilidade. No entanto, tal SM se saiu bem nas etapas de teste de software e validação do produto entre os clientes. Uma primeira versão do produto já será homologada em meados de maio de 2012.

6.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO A real contribuição e utilidade da proposta deste trabalho para SM’s é proporcional ao nível de conhecimento que um desenvolvedor de software tem sobre o conceito de SM’s. Neste momento, não basta conhecer a teoria e compreender as características de SM’s, mas sim, amadurecer tal paradigma de forma que seja possível entender aplicações Web como Máquina Social para proceder a sua construção acima dos conceitos de SM’s. O estudo de caso foi sobre uma equipe atrelada a métodos já tradicionais de desenvolvimento e tecnologias impostas pela própria empresa, onde esses profissionais estão familiarizados aos recursos disponíveis. O projeto piloto foi aplicado sobre o desenvolvimento de um só profissional repleto de novas idéias que circulam o conceito de Máquina Social, conceito ao qual esse profissional já está habituado. Ficou nítida a contribuição das práticas no estudo de caso, dos 7 (sete) problemas detalhadamente pontuados na problemática desta pesquisa, foram resolvidos 5 (cinco) para o Editor da MV. Além disto, através do experimento um número significativo de idéias surgiram dentro da empresa. Os seguintes problemas dentro do projeto Editor foram resolvidos por meio do uso das práticas e da arquitetura:      Interoperabilidade e depedência entre os serviços das SM; Manutenções demoradas; Requisitos mal trabalhados; Ausência da arquitetura; Falta de adequação da SM na resolução de problemas.

141

Capítulo 6. Experimentação das Práticas

Esta experimentação fez com que a equipe da MV enxergasse o produto Editor de formulários/telas como uma verdadeira plataforma de serviços pronta para ser transplantada entre os grandes e complexos sistemas da empresa, neste contexto, as práticas e arquitetura de referência, em seu conjunto de conceitos, revelou sua real contribuição. Demais considerações sobre este experimento serão publicadas na conclusão do trabalho que vem em seguida.

142

Capítulo

7

7. Conclusões e Trabalhos Futuros
O objetivo de tal capítulo é apresentar um desfecho sobre a dissertação como um todo. Vale ressaltar que muitas considerações já foram abordadas nos tópicos conclusivos de cada capítulo. Aqui estarão algumas reflexões finais sobre o trabalho, especialmente a sua contribuição, e as indicações dos futuros trabalhos.

143

Capítulo 7. Conclusões e Trabalhos Futuros

Ao fim dessa pesquisa, muitas questões se destacam e serão pontuadas no decorrer desta consideração final. Primeiramente a abordagem de conceber aplicações WEB como SM se mostrou adequada por dois motivos: primeiro, possibilitar que dois desenvolvimentos de SM’s focassem em pontos fundamentais para as SM’s, pontos que nem sempre possuíam a devida atenção. Segundo por esclarecer que, através de SM’s, seja possível reinventar projetos em rede, possibilitando que outros serviços sejam criados e problemas antigos sejam tratados. Para exemplificar esta idéia, 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 missão oferecer soluções que viabilizem a evolução sustentável de quem quer articular, fazer negócios ou trabalhar em rede. Conecta pessoas, instituições e empresas que querem se integrar nos fluxos da sociedade em rede independentemente do nível de maturidade em que estão. Faz isto utilizando ferramentas, serviços, processos, ambientes e conexões disponíveis na nuvem computacional da internet.

A Empresa Teia conecta as pessoas de modo que elas possam prestar serviços concomitantemente utilizando a Web 2.0 e 3.0 para isto. Este projeto já mostrou a sua força, 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 sustentável do Estado, levando, por meio da Internet, serviços às áreas remotas da circunscrição. Neste ponto, o projeto Teia, além de inovador, materializa o negócio que envolve as Máquinas Sociais; a própria página online do projeto Teia é uma SM. Através dela é possível disponibilizar App’s úteis à pessoas ou empresas que façam parte da rede Teia. Isto é, promover o negócio de SM. Portanto, cabe aqui concluirmos que as abordagens tecnológicas de SM’s talvez não sejam tão 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

Capítulo 7. Conclusões e Trabalhos Futuros

aparato tecnológico para serviços que podem ser distribuídos em rede. A partir desse ângulo, esta dissertação se mostra totalmente relevante, especialmente por focar em adaptações no modo de usar a tecnologia para se construir Máquinas Sociais para assim poder promover negócios modernos e lucratios. É clarividente que há muito para se evoluir no conceito de SM’s, sobretudo, nos aspectos voltados à Cloud Computing e nas questões de segurança, tanto das SM, quanto das informações geradas por elas. Outro ponto importante é a manutenção das SM’s, que não deve ser burocratizada. Para atender a este requisito o uso de Cloud Computing é fortemente indicado na concepção das SM’s. Porém todos os profissionais envolvidos devem entender melhor o que é CC. Quanto à segurança, Máquinas Sociais são aplicações distribuídas em rede. O acesso a elas deve ser facilitado. Por esse motivo e outros, a segurança 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 preocupação no compartilhamento de documentos e, mormente no conteúdo que leva cada documento, vez que alguns trabalham com informações confidenciais e delicadas a um paciente. O parágrafo supra remete aos trabalhos futuros; nestas concepções futuras há espaço para experimentar em mais projetos as soluções propostas. Vale salientar que, para esta pesquisa, houve certa dificuldade em se encontrar projetos de SM que se pudesse acompanhar a evolução. Com mais estudos de caso será possível verificar pontos que possam ser amadurecidos na metodologia e no próprio conceito de SM, mais do que isto, será possível divulgar e empregar fortemente o Framework de SM. Realisticamente o framework requer um trabalho forte de implementação e documentação, possibilitando assim, a disseminação do uso do mesmo. Disseminar as práticas em trabalhos futuros poderá também revelar outros benefícios em desenvolvimento de SM. Nesta dissertação as práticas se revelaram como forte contribuição para a resolução de alguns problemas já citados, e principalmente para agregar qualidade ao processo de desenvolvimento. Neste ponto os valores revelados pelo experimento não são tão importantes quanto os benefícios qualitativos que começaram a ser pontuados na página 136. A viabilidade desta idéia pode inclusive consolidar a proposta da arquitetura de referência. 142

Capítulo 7. Conclusões e Trabalhos Futuros

Para a construção da arquitetura, os conceitos e exemplos de Máquina Sociais foram detalhadamente enunciados em um capítulo. Houve certa dificuldade em se detalhar a arquitetura, pois, o escopo de Máquinas Sociais teria que ser bem mais delimitado. Para a arquitetura de referência, cabem outras pesquisas com mais tempo de desenvolvimento e amadurecimento de conceitos de modo que seja possível vislumbrar um tipo de arquitetura para cada tipo de Máquina Social, mediante, se possível, a taxonomia das mesmas. Apesar desta necessidade, vale enfatizar que o estudo de caso deste trabalho aplicou bem a arquitetura de referência proposta, adaptando a mesma. Para tal arquitetura, a avaliação por meio de Checklist se mostrou eficiente e apta a ter seu modelo replicado em outros estudos. A arquitetura de referência foi testada e concebida para atuar em SM’s que sejam aplicações WEB. Foi possível acompanhar por meio da execução da avaliação da arquitetura de SM’s como o método foi incrementado com a inserção de rodadas avaliativas, e com a estratégia de repetir apenas um avaliador entre as rodadas. O Checklist com os itens de questionamento que avaliaram diferentes aspectos da arquitetura também foi customizado. Sua alteração foi necessária para que cada item estivesse mais adequado ao que se desejaria avaliar da arquitetura. Deste modo, houve muito enfoque nas questões de requisitos não funcionais por tratar-se de uma arquitetura de referência. Entretanto, a customização do checklist já era algo tratado nas pesquisas utilizadas como referência para este trabalho. A interpretação dos itens de questionamento também foi uma novidade ao método, a tabela 4 foi um instrumento para evitar as dúvidas dos avaliadores. É claro que a resposta esperada para cada item não foi revelada, mais sim, o que cada item pretendia avaliar. Vale esclarecer que a exclusão da contabilidade do item 4 (quatro) é algo absolutamente particular do caso de uso exibido para o método. O item 4 (quatro) pode ser reescrito em outros checklists, ou pode ser desconsiderado a partir do momento em outro item investigue a mesma problemática ou aspecto na arquitetura A outra avaliação ao qual esse trabalho foi submetido foi o estudo de caso. Ele mostrou que é mais fácil pensar em SM quando se está vinculado totalmente ao conceito de SM. A empresa que cedeu a unidade experimental percebeu o novo desenvolvimento de aplicações que estava se instalando em sua fábrica. Contudo, cabe aqui mais uma vez enfatizar que o processo de evolução dos negócios em rede está em uma interação ainda 143

Capítulo 7. Conclusões e Trabalhos Futuros

primária para empresas tradicionais de TI extremamente amarradas a fatores, como: pressão organizacional e política empresarial. A experimentação auxiliou na identificação de problemas no conjunto de práticas, problemas voltados à ausência de questões de banco de dados. Aproximar esse conjunto de práticas aos padrões IEEE citados é outro trabalho que poderá ser amadurecido futuramente e que não demanda muitos esforços. O estudo experimental foi muito proveitoso, apesar de ser exploratório, onde não se conhecia exatamente os efeitos do experimento, e também apesar das ameaças 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 práticas e arquitetura propostas. O experimento possibilitou a resolução de alguns problemas a partir do momento em que auxiliou na identificação dos serviços, proporcionando melhorias na interoperabilidade, e na manutenção das aplicações que deveriam ser interligadas. Entretanto fica a necessidade de se replicar o experimento como trabalho futuro. Com isto, é possível aproveitar o planejamento e formato do estudo, com todas as suas seções, em outros trabalhos. Por fim, este trabalho amadurece todos os conceitos relacionados a SM, particularmente os relacionados ao modelo de desenvolvimento de Máquinas Sociais. Sendo assim, o objetivo foi alcançado ao passo que contribui para o desenvolvimento de ao menos uma Máquina Social real, com idéias modernas, capazes de manter a evolução dos negócios, proporcionando o amadurecimento na concepção de sistemas Web 3.0.

144

Referências Bilbiográficas

REFERÊNCIAS BIBLIOGRÁFICAS
ABINADER, Jorge; LINS, Rafael. Web Services em Java. 1.ed. São 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. Disponível em:

AMAZON PRODUCTS & SERVICES. Informações especializadas sobre o servico EC 2 da Amazon. Disponível 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 informações especializadas sobre o desenvolvimento de aplicativos por meio da plataforma Twitter. Disponível 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. Disponível 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. Disponível 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. Disponível 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. Disponível 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. Disponível 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. Disponível em: < http://www.st.ewi.tudelft.nl/~zaidman/publications/bezemerIWPSE2010.pdf> Acesso em: 09 jan. 2011. BELL, M. Modelagem Orientada ao Serviço. 1. ed. Rio de Janeiro: Alta Books, 2008. 384 p.

141

Referências Bilbiográficas

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. Disponível 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: O’Reilly, 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 Usuário. 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 tecnológicos. Disponível em: <http://www.comscore.com/por/.acesso> Acesso em: 28 set. 2010. CRAGGS, Steve. Best-of Breed ESBS, 2004. In: GLOBAL EAI SUMMIT, Disponível 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 informações sobre o mercado de TI e comunicação. Disponível 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: O’Reilly, 2010. DISTRIBUTED MANAGEMENT TASK FORCE – DMTF. Informações especializadas sobre padrões de interoperabilidade. Disponível 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 informações sobre o projeto TEIA. Disponível em: http://empresateia.com.br/. Acesso em 01 set. 2011. ENDREI, Mark; ANG, Jenny; ARSANJANi, Ali; CHUA, Sook; COMTE, Philippe; KROGDAHL, Pål; LOU, Min; NEWLING, Tony. Patterns: Service-Oriented Architecture and Web Services, 2004. In RedbooksIBM.com. Disponível em:< http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf> Acesso em: 05 mar. 2010. FACEBOOK DEVELOPERS. Apresenta informações sobre o desenvolvimento de Aplicações por meio do Facebook. Disponível em: <http://developers.facebook.com/>. Acesso em: 23 set. 2010. FERREIRA, Kecia; BIGONHA, Mariza; BIGONHa, Roberto. Reestruturação de Software Dirigida por Conectividade para Redução de Custo de Manutenção. In: RITA, Volume XV, numero 2, 2008. FORCE.COM. Guia do Programador da API de Serviços Web da Force.com. Possui informações sobre o desenvolvimento de aplicações na Force.com. Disponível 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 Informação, novas tendências ou descobertas. Disponível em: <http://www.forrester.com/rb/research/>. Acesso: 1 nov. 2011. FREITAS, Fabricio; MAIA, Camila; COUTINHO, Daniel; CAMPOS, Gustavo; SOUZA, Jefferson. Aplicação de Metaheurísticas em Problemas da Engenharia de Software: Revisão de Literatura, 2009. No II Congresso

142

Referências Bilbiográficas

Tecnológico Infobrasil. Disponível 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. Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos. 5ª ed. São 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. O’Reilly. 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. Disponível 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 serviços de tecnologia e pesquisa. Disponível 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. Disponível 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. Disponível 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. 2ªed. USA: Addison Wesley, 2000. HORN, Paul. Autonomic Computing: IBM Perspective on the State of Information Technology, 2001. Disponível 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. Disponível 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 informações especializadas sobre estatísticas 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. Disponível em: http://dl.acm.org/citation.cfm?id=1080875. Acesso em: 30 mar. 2011.

143

Referências Bilbiográficas

JSON. Informações especializadas sobre a ferramenta JSON. Disponível em: <http://www.json.org>/. Acesso em: 13 abr. 2011. JOSUTTIS, Nicolai. SOA na Prática: A Arte da Modelagem de Sistemas Distribuídos. 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 padrões: Uma introdução a análise 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. Disponível 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. Disponível 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. Disponível 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. Disponível 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. Disponível em:<http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam>. Acesso em: 22 ago. 2011.

LAZZERI, João Carlos. Arquitetura Orientada a Serviços. 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. Disponível 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. Disponível em:< http://www.ibm.com/developerworks/web/library/x-mashups.html> Acesso em: 07 mai. 2011.

144

Referências Bilbiográficas

MEIRA, Silvio. Empresa ―Teia‖? Como assim?. Dia a dia. Bit a bit. Blog do professor Silvio Romero de Lemos Meira, 8 dez. 2010. Disponível 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.; ENCARNAÇÃO, B.; GARCIA. The Emerging Web of Social Machines, 2011. IEEE 35th Annual Computer Software and Applications Conference (pp. 26-27). . Disponível 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. Disponível em:< http://csrc.nist.gov/groups/SNS/cloud-computing>. Acesso em: 17 ago. 2011. MORAIS, EF; SOARES, MB. Web semântica para máquinas de busca. Disponível em:<http://homepages.dcc.ufmg.br/~nivio/cursos/pa03/seminarios/seminario7/seminario7.pdf>. Acesso em: 04 out. 2010. MICROSOFT COMMUNITY BLOGS. Apresenta informações 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. Disponível 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. 597–608. Disponível 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 Contribuição ao Projeto Arquitetural de Ambientes de Engenharia de Software. Tese de Doutorado, Instituto de Ciências Matemáticas e de Computação, ICMC-USP/SãoCarlos, 2006. NIST. Página da Agência governamental de administração da tecnologia. Disponível em:< http:// http://www.nist.gov/index.html>. Acesso em 19 set. 2011. NETCRAFT.COM. Site que monta pesquisas e exibe estatísticas sobre a Internet e sobre aplicações em geral. Disponível 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 SS’08: Proceedings of the 17th conference on Security symposium. Disponível em <http://www.eecs.umich.edu/fjgroup/pubs/usenix08-cloudav.pdf>. Acesso em: 04 abr. 2011. OFFICIAL GOOGLE BLOG. Contém informações especializadas sobre a Google Corporate em: http://www.google.com/intl/pt-BR/press/. Acesso 16 out de 2010. O’REILLY, Tim. What is web 2.0, 2005. Disponível 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. Diponível 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. Disponível 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

Referências Bilbiográficas

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. São Paulo: Bookman, 2011. 780 p. PRESSMAN, Roger; LOWE, David. Web Engineering: A Practitioner's Approach. 1 ed. São 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. Disponível em: < http://dl.acm.org/citation.cfm?id=28731> Acesso em: 04 jun. 2011. RAILS. Informações especializadas sobre a linguagem Rails. Disponível em: <http://www.rubyonrails.pro.br/> . Acesso em: 14 abr. 2011 REZENDE, Denis Alcides. Engenharia de software e sistemas de informação. 3ª ed. Rio de Janeiro: Brasport, 2005. REZENDE, Denis. Tecnologia da Informação Aplicada a Sistemas de Informação Enpresariais: O Papel Estratégico da Informação e dos Sistemas de Informação nas Empresas. 4ª ed. São 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. São Paulo: Prentice-Hall, 1996. SOMMERVILLE, Ian. Engenharia de Software. 9ª ed. São Paulo: Pearson, 2011. 568 p. SEVERINO. Antônio Joaquim. Metodologia do Trabalho Científico. 23ª Ed. São 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 (ECBS’03), p. 247–251. Disponível 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 - Computaçao 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. Relatório Técnico, Universidade Federal do Rio de Janeiro, 2002.

146

Referências Bilbiográficas

TITTEL, Ed. Xml. 1ed. São 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. Disponível 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. Disponível 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. Disponível 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.com’s Internet Application Development Platform. In Salesforce com. 2010. Disponível 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. Disponível 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. Disponível 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. Página da Agência governamental de administração da tecnologia. 11 de dezembro de 2011. Disponível 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. 2–9, IEEE Computer Society. Disponível 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) 42–50. Disponível 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), 7–15. Disponível 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. Disponível em: <http://sophia.javeriana.edu.co/~cbustaca/DSBP/lecturas/AttributeBased%20Architectural%20Styles.pdf>. Acesso em: 06 mar. 2010.

147

Referências Bilbiográficas

KALIN, Martin. Java Web Services: Implementando. 1ed. Rio de Janeiro: O’Reilly. 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: O’Reilly, 2010. 448p.

148

Anexos

ANEXOS

ANEXO 1. PRÁTICAS DO PROJETO EDITOR MVPEP

Prática 1: Modelar processos e sub-processos de negócio de serviço

Prática 2: Reconhecer os serviços providos e requeridos para o funcionamento da Máquina Social 1. Serviços Providos: a. Ajustar a aparência de documentos e telas; b. Disponibilizar modelos de documento e telas formatados para os clientes; c. Processar dados específicos de um segmento hospitalar. 2. Serviços Requeridos: a. Provimento de informações específicas para se utilizar um documento, assim, é necessário saber se existe, e qual é, a prescrição médica que utilizará o documento; b. Registro de laudos de exames.

152

Anexos

Prática 3: Conhecer os provedores de serviço da aplicação  Banco de dados Oracle que fornece os dados a serem processados pelo Editor, os dados estão registrados em tabelas diversas;  Sistema MVSOUL (tecnologia Java/Flex/Web Service) onde os laudos são registrados;  Sistema MVPEP por necessitar das informações da prescrição médica;  Sistema MV2000, módulo PAGU, para resgatar informações de perguntas.

Prática 4: Verificar a necessidade de recursos que tornem a aplicação auto-gerenciável e como esses recursos podem ser implementados A MV para este projeto não desenvolveu nenhum recurso que possa prover o autogerenciamento.

Prática 5: Determinar os recursos que implementarão os elementos States e Constraints: No projeto Editor não ocorre a preocupação direta com tais elementos, mas algumas ações contribuem diretamente para a visualização do estado do SM, bem como, a visualização das características do mesmo, auxiliando na disponibilidade, e na comunicação. Tais iniciativas são:  Utilizar Cluster de alta disponibilidade, viabilizados por meio de mecanismos de detecção e recuperação de falhas;  Construir uma segunda camada intermediária (core_flex_service) para prover a interoperabilidade, tal camada possui métodos (classes) específicas para customizar a aplicação no momento requerido, conforme o sistema que for utilizá-la;  Uso do padrão de projeto State;  Implementar sensores na camada de persistência que dispara um time a toda solicitação à base de dados, caso a resposta demore, é indício de que algo aconteceu aos repositórios, e o Editor se prepara para acessar possíveis backups.

Prática 6: Analisar se apenas o estilo arquitetural Camadas é suficiente para atender a Máquina Social: O estilo arquitetural Camadas será aplicado na arquitetura em conjunto a outros estilos também empregados, entretanto, essa mescla só ocorreu na primeira camada da aplicação. Os estilos adicionais são: Pipes and Filters e Publisher-subscriber.

153

Anexos

Prática 7: Determinar o recurso que proverá a comunicação e interoperabilidade  Web Services com REST para a comunicação com dispositivos móveis;  Utilizar o recurso nativo do Adobe Flex, o AMF com auxílio do BlazeDS. O BlazeDS é um servidor baseado em Java Remoting and Web Messaging, uma tecnologia que viabiliza a comunicação com o back-end distribuído de dados da aplicação. O BlazeDS pode ser utilizado com outras plataformas de cliente, como JavaScript e AJAX, ambas tecnologias exploradas pela MV.  Inserir duas camadas de comunicação na arquitetura, estas irão prover a interoperabilidade entre o Editor os sistemas;

Prática 8: Selecionar o recurso Cloud Computing a ser adotado na SM A MV ainda não 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.

Prática 9: Selecionar os padrões de projeto mais adequados para a arquitetura da Máquina Social Padrões mais utilizados: 1. Adapter: para adequar as interfaces de comunicação entre os sistemas; 2. Observer: para a gerência dos estados entre os objetos; 3. State e Singleton.

Prática 10: Selecionar o banco de dados não relacional Não foi seguida ou executada

154

Anexos

ANEXO 2. PRÁTICAS DO PROJETO PILOTO HOBNOB

Prática 1: Modelar processos e sub-processos de negócio de serviço Tal diretriz não foi satisfeita para este projeto, o fluxo de negócio não foi algo tratado na concepção e análise do HobNob, apesar de trabalhar com o conceito de serviço o responsável pelo desenvolvimento desta SM optou por trabalhar questões mais técnica e não tanto de negócio.

Prática 2: Reconhecer os serviços providos e requeridos para o funcionamento da Máquina Social 1.Serviços Providos: c. Sugerir festas e eventos musicais pela cidade de recife; d. Classificar os eventos: classificar os mais procurados, e os mais freqüentados. 2.Serviços Requeridos: e. Lista de amigos de rede social; f. Dados ou informações das pessoas; g. Links: o que foi acessado, procurado ou visualizado nas redes sociais, e no Google Map.

Prática 3: Conhecer os provedores de serviço da aplicação 1. 2. 3. 4. Facebook; Google Map; Servidor de chat; Servidor de banco de dados.

Prática 4: Verificar a necessidade de recursos que tornem a aplicação auto-gerenciável e como esses recursos podem ser implementados Usar de forma inteligente alguns recursos e técnicas já populares na engenharia de software, afim de, prover o autogerenciamento:  Usar o Framework de SM para obter tolerância a falhas;  Aplicar boas práticas de programação;  Configurar bem o Apache para obter controle de log, e controle de sessão em banco de dados (segurança).

155

Anexos

Prática 5: Determinar os recursos que implementarão os elementos States e Constraints: Usar o Framework para Máquinas Sociais, com o uso será estabelecido níveis de qualidade e estabilidade para os serviços, existem 5 níveis de estabilidade, estes se baseiam no tempo de resposta de cada solicitação, entre outros parâmetros.

Prática 6: Analisar se apenas o estilo arquitetural Camadas é suficiente para atender a Máquina Social: Sim, apesar a arquitetura em camadas foi utilizada, houve uma customização desta, além da inserção do Framework para Máquinas Sociais.

Prática 7: Determinar o recurso que proverá a comunicação e interoperabilidade  WebServices com REST.;  Adoção de Json.

Prática 8: Selecionar o recurso Cloud Computing a ser adotado na SM Utilizar os serviços da PaaS Rackspace, como: backup, SO Linux, balanceamento de carga, e armazenamento. Esta ofertou melhores opções em relação

ao valor cobrado, neste aspecto houve uma análise dos provedores de serviços CC para detectar qual o de melhor relação custo/benefício.

Prática 9: Selecionar os padrões de projeto mais adequados para a arquitetura da Máquina Social Padrões mais utilizados:  State;  Singleton;  Facade.

156

Apêndices

APÊNDICES

APÊNDICE A. CHECKLIST DE AVALIAÇÃO ARQUITETURAL – VERSÃO 1

IDENTIFICAÇÂO Arquitetura a ser avaliada: Inspetor: Visões a serem avaliadas: módulos, componentes e conectores, implantação Arquitetura de referência para Máquinas Sociais

Item de Questionamento

SIM

NÃO

NÃO SE APLICA

1

Ao analisar todos os diagramas, foi identificado algum elemento arquitetural que não possua

relacionamentos, ficando isolado dos demais? 2 A descrição textual que compõe o documento está de acordo com o que foi representado nos diferentes diagramas gráficos? 3 Para todos os componentes, em algum diagrama, foram identificadas as classes ou sub-componentes que o compõem? 4 Os relacionamentos realizados entre classes/subcomponentes alocados em “componentes pais” distintos foi definido como uma dependência entre esses “componentes pais” em algum outro diagrama? 5 As interfaces são disponibilizadas por um único componente/classe, ou representadas de uma forma

157

Apêndices

mais simples não expandida? 6 Ao analisar todas as seqüências de execução descritas em uma visão de interação, pode-se dizer que as classes/componentes definidas em uma visão

modular foram alocadas em ao menos uma das seqüências? 7 Todos os elementos arquiteturais têm a sua presença na arquitetura justificada por um conjunto de requisitos não funcionais ou funcionais? 8 As responsabilidades dos elementos arquiteturais estão condizentes com os requisitos não funcionais que eles atendem? 9 Táticas arquiteturais foram empregadas para

satisfazer os requisitos não funcionais? 10 Elementos relacionados possuem responsabilidades iguais que possam ser alocadas em um único elemento? 11 Elementos intermediários (ex: máquina virtual, servidor de nomes, repositórios, API’s) são utilizados como mediadores de comunicação entre os elementos arquiteturais, diminuindo o impacto das alterações realizadas em elementos que podem ser

modificáveis? 12 Foi verificado algum componente que exerca controle sobre o comportamento de outro elemento?

158

Apêndices

APÊNDICE B. CHECKLIST DE AVALIAÇÃO ARQUITETURAL – VERSÃO 2

IDENTIFICAÇÂO Arquitetura a ser avaliada: Inspetor: Visões a serem avaliadas: Observações considerações ou módulos, componentes e conectores, implantação Arquitetura de referência para Máquinas Sociais

Item de Questionamento

SIM

NÃO

NÃO SE APLICA

1

Ao analisar todos os diagramas, foi identificado algum elemento arquitetural que não possua

relacionamentos, ficando isolado dos demais? 2 A descrição textual que compõe o documento está de acordo com o que foi representado nos diferentes diagramas gráficos? 3 Para os componentes, em algum diagrama, foram identificadas as classes ou sub-componentes que o compõem? 4 Os relacionamentos realizados entre classes/subcomponentes alocados em “componentes pais” distintos foi definido como uma dependência entre esses “componentes pais” em algum outro diagrama? 5 As interfaces são disponibilizadas por um único componente/classe, ou representadas de uma forma mais simples não expandida? Ou seja, ocorre uma representação por meio de diagrama de classes ou de componentes e conectores com interfaces requeridas

159

Apêndices

e providas. 6 Ao analisar as seqüências de execução descritas em uma visão de interação, pode-se dizer que as classes/componentes definidas em uma visão

modular foram alocadas em ao menos uma das seqüências? 7 Os elementos arquiteturais têm a sua presença na arquitetura justificada por um conjunto de requisitos não funcionais ou funcionais? 8 As responsabilidades dos elementos arquiteturais estão condizentes com os requisitos não funcionais que eles atendem? 9 Táticas arquiteturais foram empregadas para

satisfazer os requisitos não funcionais? 10 Elementos relacionados possuem responsabilidades iguais que possam ser alocadas em um único elemento? 11 Elementos intermediários como: máquinas virtuais, servidores de nomes, repositórios e API’s; são utilizados como mediadores de comunicação entre os elementos arquiteturais. 12 Foi verificado algum componente que exerca controle sobre o comportamento de outro elemento? COMENTÁRIOS:

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

160

Apêndices

APÊNDICE C. VALORES MONITORADOS NO EXPERIMENTO

PARÂMENTROS

COM METODOLOGIA TRADICIONAL

COM METODOLOGIA DE SM 7

Número de requisitos da SM trabalhados pela arquitetura. Adequação concebida metodologia Social. da por à arquitetura meio na

4

2

4

Máquina

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, não houveram defeitos encontrados.

161

Apêndices

APÊNDICE D. ARQUITETURA DE REFERÊNCIA ANTES DAS AVALIAÇÕES

162