Você está na página 1de 180

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

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. por me direcionar e ensinar. Aos amigos verdadeiros pelo forte incentivo. contribuiram para a realização deste trabalho. pela exigência de sempre. na indústria. que fez a minha caminhada neste mestrado ser extremamente promissora. Paulo Borba.AGRADECIMENTOS Primeiramente agradeço a Deus e à Nossa Senhora de Nazaré por estarem presentes em nossas vidas nos dando saúde e luz. Misael Neto. Prof. Prof. Sergio Soares. Vanilson Burégio. e por se fazer sempre presente mesmo que ausente. dedicaram dois anos de sua vida a um mestrado. . e que de forma direta. e Thiago Vieira. por me contagiar com a inquietação de sua mente. Aos inteligentíssimos Prof. e talvez por este motivo não vejam com admiração pessoas que. Ao meu também orientador Vinicius Garcia. À empresa MV Informática Nordeste pela confiança. Aos meus amados pais pelo cuidado e apoio de sempre. À Universidade Federal de Pernambuco – UFPE. Entretanto. Leandro Marques. como eu. pelas condições de ensino oferecidas. Muitos não sabem o que é concretizar um trabalho desta natureza. são para estas pessoas que deixo meus sinceros agradecimentos. e no saber. pessoas que sempre estiveram dispostas a me ajudar. Ao meu admirado orientador Silvio Meira. no ensino.

de Machado como de Eça. Pode ser que tenha chegado a hora de perguntar o que tornaria mais fácil para o computadore lidar com seres humanos. Será que estão sorrindo? Falamos desejosos sobre interações humano-máquina." Tradução de trecho do livro “A vida digital” do ano 1995 (Nicholas Negroponte) . Gosto de Le Corbusier como gosto de Mies.“Lack of time is excuse for who loses time due to lack of methods” (Albert Einstein) “Não acredito em uma arquitetura ideal.” (Oscar Niemeyer) "Nós raciocinamos hoje apenas em termos do que tornaria mais fácil para as pessoas a utilização do computador. de Picasso como de Matisse. e nem sabe quantas são. insubstituível. somente em boa e má arquitetura. Está na hora de fazer com que os computadores vejam e ouçam. Por exemplo: como é possível conversar com pessoas quando nem sequer se sabe que estão presentes? Você não pode vê-las. sistemas dialógicos e. estamos dispostos a deixar no escuro total um dos participantes deste diálogo. no entanto.

Web 3. Práticas. SM’s são aplicações que se relacionam em rede para disponibilizar determinado serviço. 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. e os responsáveis por tal transformação são.0 as SM’ são protagonistas. orientar sobre a construção de SM’s.RESUMO A Internet se modifica a uma velocidade considerável. as aplicações que a compõem. O produto desta dissertação foi fruto de uma extensa pesquisa que se empenhou em fortalecer os conceitos de SM’s. Arquitetura de Referência. VI . Palavras-Chave: Cloud Computing. tudo neste ambiente funciona por meio destas. Todos os conceitos abordados e resultantes foram fortemente baseados na realidade da Web 3.0 é a facilidade em reprogramar suas aplicações e fazer com que elas interajam de forma a interligar negócios. principalmente. Tecnologias. ou Máquinas Sociais (SM’s). No contexto da Web 3. Aplicações Web. o desenvolvimento desta pesquisa explora diversos conceitos dentro da engenharia de software.0. O que caracteriza a Web 3.0. e a segunda por meio de um estudo de caso. práticas foram lançadas afim de auxiliar na customização desta arquitetura e. internet que traz alterações significativas ao modo de se fazer negócio em rede. serviços e pessoas. 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. Isto posto. a primeira executada por meio de um método de inspeção. em grande parte. Avaliações. Máquinas Sociais. além de exibir duas avaliações dos artefatos de software gerados pelo trabalho. Assim.

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). Web 3. Web Aplications. and the applications that comprise it are the most responsible for that. 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. and the other through a case study. In this sense. Therefore.0 feature is the facility to reprogram its applications and make them interact to connect business. All adressed and resultant concepts were strongly based on the Web 3. and particularly to conduct the construction of SM's. this research explores different concepts in software engineering. Keywords: Cloud Computing. services and people. The SM’s are the main element considering the Web 3.0 reality. the practices have been launched to provide support to the customization of this architecture. an internet that brings significant changes in network business ways. Architecture of reference. Guidelines. Social Machines. SM’s are applications that connect in network to provide a determined service.0. Reviews. the entire environment works trough it. also showing two software artifacts evaluations: the first through an inspection method.ABSTRACT The Internet is changing at a considerable speed.0 context. VII . The mainly web 3. Technologies.

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

.................................... RELAÇÃO ENTRE AS PRÁTICAS E OS REQUISITOS NÃO FUNCIONAIS ........... 85 TABELA 6................. 118 TABELA 8...... PADRÕES COMPORTAMENTAIS RELEVANTES PARA AS SM’S . ................... 68 TABELA 5............................................. CARACTERÍSTICAS E NECESSIDADES DAS SM’S ...... 21 TABELA 2................... 117 TABELA 7...... RELAÇÃO ENTRE OS PADRÕES DE PROJETO E OS REQUISITOS NÃO FUNCIONAIS DAS SM’S ... ATENDIMENTO AOS REQUISITOS PELA ARQUITETURA CONFORME AS CARACTERÍSTICAS E NECESSIDADES DA SM............................... 123 IX .... QUESTÕES ANALISADAS PELO CHECKLIST E RESPOSTAS ESPERADAS ........................................................................................................................................... 36 TABELA 3. 62 TABELA 4........LISTA DE TABELAS TABELA 1.............. 118 TABELA 9... PADRÕES ESTRUTURAIS RELEVANTES PARA AS SM’S ........ MATERIAIS SELECIONADOS PARA O ESTUDO ................................................ PONTOS OU ASPECTOS MAIS TRABALHADOS PELAS ARQUITETURAS ...

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......................................1........................................................................ ......... PROCESSO DE REVISÃO...............3 PROBLEMÁTICA ............................................................................................................................................................................4......... 9 1................. 2 1......................... 9 1............5...............6.4.....2...................................4............................................................... 14 2............................... CONTRIBUIÇÃO E RESULTADOS ESPERADOS ... 22 2.......................................................... 24 2........................................................ 11 2........................................ 3 1....... 11 1................................................................................1............... 23 2.....................................................................................................1 APRESENTAÇÃO E CONTEXTO ....... WEB SEMÂNTICA: .............................................. 30 3......................... INTRODUÇÃO ..................................................................................................................................................... VI ABSTRACT……............................................................ 1 1..........................................................2........................................................3...........................................2................................................................................................................... O CONTEXTO DAS MÁQUINAS SOCIAIS ..................................... CONCEITO DE MÁQUINAS SOCIAIS ............ 5 1..... CLOUD AV: ............. GERAL ....... ......................................................................................................... 8 1.................................................................................................................................................... 25 3.................................................... EXEMPLOS DE MÁQUINAS SOCIAIS .................................................1............... MAP REDUCE: ..... 27 3.......................................................... 30 XI ................................................... CONSIDERAÇÕES FINAIS DO CAPÍTULO ..............................................................................3........................ X SUMÁRIO........................................... IX LISTA DE ABREVIATURAS E SIGLAS ...................................3................................................................ 13 2......................................................................................................................................................5. 21 2................. 17 2.2......................... 19 2........................................6.......................... MÁQUINAS SOCIAIS................... VIII LISTA DE TABELAS...............................................4................................. OBJETIVOS: ......... TRABALHOS RELACIONADOS......................................................................5..1.................. CARACTERÍSTICAS DAS MÁQUINAS SOCIAIS .........7...........................2............................ ESTRUTURA DO TRABALHO ..................5............. JUSTIFICATIVA E MOTIVAÇÃO DO TRABALHO ..... EUCALYPTUS: . QUESTÃO A SER INVESTIGADA: ................3...... INTRODUÇÃO ..................................................................................................................................................................... 8 1......................................................................... 22 2... ARQUITETURA DE SOFTWARE.............. XI 1.................................................. ESPECÍFICO ............................................................................................................................................................5....... 22 2............................... VII LISTA DE ILUSTRAÇÕES .................. TAXONOMIA DAS MÁQUINAS SOCIAIS ...1........ REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE PARA MÁQUINAS SOCIAIS 26 3..... 27 3............................................................................................................................4...................................5................

.4......................................INCLUSÃO:......5..................1................ CRITÉRIOS DE CLASSIFICAÇÃO ...................3. 31 3.....4............................. 49 3............................................................ ARQUITETURA CLOUD COMPUTING PROPOSTA PELA EMPRESA IBM .. .......................... 81 4........................... 33 3.....................................5.................6................... 66 4......... 80 4.................... ARQUITETURA PARA REDES SOCIAIS – QP3 ....................................................................................2.....7........................................................................ CONSIDERAÇÕES FINAIS DO CAPÍTULO ...........1........... 42 3.......................... 36 3. 39 3............ 37 3.................................1......................................................5..................... ARQUITETURA DE REFERÊNCIA PARA CLOUD COMPUTING – QP2 ..............................................3........5.................................4............ PROCESSO DE INSPEÇÃO (AVALIAÇÃO) ...............1........................................................ ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2..........................4......................... TÉCNICA DE INSPEÇÃO .............................4....................2................... ARQUITETURA CLOUD COMPUTING PROPOSTA POR KOSSMANN..................3.............................. TAXONOMIA DOS DEFEITOS A SEREM ENCONTRADOS ..............4.5................. CONSIDERAÇÕES FINAIS DO CAPÍTULO – CRÍTICAS ...................................................................................4.............. 52 3...............................0 – QP5 .....................1................................... PROPOSTA DE ARQUITETURA DE REFERÊNCIA PARA MÁQUINAS SOCIAIS .... 33 3............................... ARQUITETURA DE REFERÊNCIA PARA MASHUPS – QP1 ... 78 4...................2.................3...... 81 4..... PERFIL DOS AVALIADORES (INSPETORES) ...........1........ ........4...................................................5......................................... INTRODUÇÃO . CRITÉRIOS DE CLASSIFICAÇÃO ...... ARQUITETURA DE REFERÊNCIA PARA SISTEMAS AUTÔNOMOS – QP4....EXCLUSÃO: .......... ARQUITETURA AUTÔNOMA PROPOSTA PELA EMPRESA IBM ..................3.................................................................. IDENTIFICAÇÃO DO MATERIAL .........................2........................1................... 64 4.... REPOSITÓRIOS DE BUSCA............... DEMONSTRAÇÃO DOS RESULTADOS DAS ARQUITETURAS DE REFERÊNCIA INVESTIGADAS .. QUESTÕES DE PESQUISA: .2......1....... 36 3....4........... 82 4.............. ARQUITETURA MASHUP PROPOSTA POR LIU EM 2009 ................. ARQUITETURA CLOUD COMPUTING PROPOSTA POR VECCHIOLA ....................... REGISTRO DO MATERIAL ............. RESULTADO..................1........ 79 4......................................................3.................................. RECOMENDAÇÃO DE PRÁTICAS PARA DESENVOLVER ARQUITETURAS DE MÁQUINAS SOCIAIS............. 59 4...........1............................... 34 3............................... 47 3........... AVALIAÇÃO DA ARQUITETURA DE REFERÊNCIA E DE SUAS VISÕES .......... 56 3...........................................4..................... 91 XII ............................ 34 3..........2......... ARQUITETURA MULTITENANT DE REFERÊNCIA PARA SOFTWARE AS A SERVICE – QP2 ......................5.................. INTRODUÇÃO . ARQUITETURA MASHUP PROPOSTA POR MERRIL EM 2006 . 53 3... 55 3....6...... 64 4....1...... 34 3.......................3..... 33 3. 40 3.......... 88 5.........4............1..........4..................6.... ARQUITETURA DE REFERÊNCIA ..... 63 4............................8.......... 38 3.............................. ARQUITETURA AUTÔNOMA PROPOSTA POR MCCANN.........4.....................................5............5.....................1................................ 90 5......3..5.........................4.. VISÕES DA ARQUITETURA DE REFERÊNCIA .......2.........3.................. RESULTADOS.4.3........3............3............................... CORREÇÃO DOS ERROS ENCONTRADOS ......1...............4.......5...............................................................4..4.....5..........................2.............................. 80 4............................ 43 3.................2. HUEBSCHER E WHITE ET AL ........2...................................................................................... KRASKA E LOESING..... ARQUITETURA DE REFERÊNCIA PARA MÁQUINAS SOCIAIS .......................... 72 4........................2........................................3................................

.......3.. PLANEJAMENTO ........................................................ 128 6... PRÁTICA 2: RECONHECER OS SERVIÇOS PROVIDOS E REQUERIDOS PARA O FUNCIONAMENTO DA MÁQUINA SOCIAL...............8........ 119 5....................................3...........3........... 95 5.................4................................ 93 5...................4.. CONCLUSÕES E TRABALHOS FUTUROS .................................................2.................................................3....3......................................................................................... .......................3....................................................................... PRÁTICA 10: SELECIONAR O BANCO DE DADOS NÃO RELACIONAL ....................... 136 6..3.......... VARIÁVEIS INDEPENDENTES E DEPENDENTES ......................................................... 129 6.......................... PROJETO PILOTO............... RUÍDOS............................. CONSIDERAÇÕES FINAIS DO CAPÍTULO .............................. 130 6. PRÁTICAS NA METODOLOGIA PARA CONCEPÇÃO DE ARQUITETURAS E EM TRABALHOS RELACIONADOS .....2................. 130 6............................1...................3...................... 94 5....................................... PRÁTICA 3: CONHECER OS PROVEDORES E REQUISITANTES DOS SERVIÇO DA APLICAÇÃO ... PRÁTICA 8: SELECIONAR O RECURSO CLOUD COMPUTING A SER ADOTADO NA SM....................2.............................................. EXECUÇÃO ........................ INTRODUÇÃO ......................................... PRÁTICA 6: ADOTAR ESTRATÉGIAS PARA SANAR AS FRAQUEZAS DO ESTILO ARQUITETURAL CAMADAS..........3. EXPERIMENTAÇÃO DAS PRÁTICAS .............................3.....................................3.....................................................................................4................ PRÁTICAS RECOMENDADAS........ ................... .... PREPARAÇÃO...................2....... 97 5................................................................. PRÁTICA 1: MODELAR PROCESSOS E SUB-PROCESSOS DE NEGÓCIO DE SERVIÇO .......................... 133 6................ 126 6............................................................. CONSTRAINTS E REQUESTS ................................................. 141 7....................................................................4............ ESTUDO DE CASO EDITOR DE FORMULÁRIOS/TELAS – MVPEP .2..... 132 6........................................2...3...........3.....7.......3..1.................. UNIDADE EXPERIMENTAL . RESULTADOS OBTIDOS ........................................ OBJETO DE CONTROLE ............................................... 132 6....................................................................................1........................ 143 XIII .....1.........3.......................4...................................... PRÁTICA 5: DETERMINAR OS RECURSOS QUE IMPLEMENTARÃO OS ELEMENTOS COMMUNICATIONS ......................................... 133 6..................... 128 6.......... 137 6................... ................ 115 5......4............................................7. DEFINIÇÃO DOS OBJETIVOS ................................6.. PRÁTICA 9: SELECIONAR OS PADRÕES DE PROJETO MAIS ADEQUADOS PARA A ARQUITETURA DA MÁQUINA SOCIAL...... ................. 106 5.............5.............................5.......3........................................................................... EXECUÇÃO......................4................... 131 6.... CONTEXTO.................................................... 128 6....................................................6..................................................................................................................................................1....................... ............................................................................................................................................................4................... SELEÇÃO DOS INDIVÍDUOS .....3. CONSIDERAÇÕES FINAIS DO CAPÍTULO ......... ........................8................................................ 120 6.3........................................................................... 109 5...................... 125 6..............5...................................................................... 101 5.............................5.. 91 5........................ VALIDADE..................... 126 6..3.......................................................3. 99 5.............3..................... ................................2....................... PRÁTICA 7: DETERMINAR O RECURSO QUE PROVERÁ A COMUNICAÇÃO E A INTEROPERABILIDADE......2...104 5...... PRÁTICA 4: VERIFICAR A NECESSIDADE DE RECURSOS QUE TORNEM A APLICAÇÃO AUTO GERENCIÁVEL E COMO ESSES RECURSOS PODEM SER IMPLEMENTADOS.............................................10........................................................4...................................................9............. 130 6..2.....

................................... 162 XIV ..................................... 152 ANEXO 1............. 159 APÊNDICE C.................. PRÁTICAS DO PROJETO EDITOR MVPEP ...................................................................................................................................................................... ARQUITETURA DE REFERÊNCIA ANTES DAS AVALIAÇÕES ........................... PRÁTICAS DO PROJETO PILOTO HOBNOB ................................................................................... CHECKLIST DE AVALIAÇÃO ARQUITETURAL – VERSÃO 1 .........................................................157 APÊNDICE A........ 157 APÊNDICE B.......................... CHECKLIST DE AVALIAÇÃO ARQUITETURAL – VERSÃO 2 ......... 155 APÊNDICES........................................................................................ 161 APÊNDICE D..................................... 141 ANEXOS. VALORES MONITORADOS NO EXPERIMENTO .... 152 ANEXO 2... .....................................................................................................................................REFERÊNCIAS BIBLIOGRÁFICAS ......

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

pois muitas questões ainda são desconhecidas.CC. No relatório algumas das tendências são CC e Business Process Modeling Notation .com/rb/Research/top_10_business_technology_trends_e a_should/q/id/60920/t/2.Capítulo 1. CC é um tema de grande pesquisa na atualidade. questões como: 5 Empresa que faz a mediação de vários aspectos da Internet. Acesso em: 20 de mai. de inovações. A Forrester Group é uma empresa especializada em pesquisas direcionadas a Tecnologia de Informação. Dentro deste contexto a Internet desempenha um papel fundamental. tudo isto. 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. entretanto. ou duvidosas. mostrou um aumento de 4% nos acessos das mesmas somento nos primeiros seis meses do ano de 2010. mostrando o comportamento de utilizadores da Web. e SHETH. As aplicações contextualizadas a Web 3. contextualiza as mesmas a WEB 3. 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. que são aplicações Web constituídas de outras aplicações. Introdução O trabalho dos usuários com estas redes é tão forte que uma pesquisa estatística feita pelo ConScore. Vale ressaltar que os Mashups personificam muito bem a comunicação e interação entre as aplicações Web. 2010).5. plataformas de infraestrutura. para os próximos anos até 2014.0 apresenta o advento da CC. especificamente nas arquiteturas de software. nesta Internet ainda ocorre a proliferação dos Mashups. os serviços. este último tema será tratado mais adiante por este trabalho. e software sob demanda (WEISSMAN. 6 Disponível em: http://www. A facilidade em se reprogramar as redes sociais. bem como. ela além de instrumento.forrester. e de junções empresariais.0 adicionam mais funcionalidade a mesma. 2011 4 . A Web 3. Inc. DUSTDAR. Com os Mashups é possível ter uma combinação de serviços em um único aplicativo (BENSLIMANE. com regras mais complexas.0 está o conceito de Computação nas Nuvens ou Cloud Computing . Relacionado aos negócios e as novas tecnologias da WEB 3. inovações ao seu desenvolvimento e facilidade aos negócios.BPMN. a fim de atender aos modelos de negócio cada vez mais exigentes.0. passa a ser provocadora de negócios. entretanto muito ainda deve ser visto e avaliado antes de contextualizar os recursos de CC ao desenvolvimento de um software.

Até este ponto a motivação pela elaboração desta pesquisa foi apresentada. novidades que na prática ainda não foram totalmente desmistificadas. os parágrafos acima evidenciaram alguns jovens paradigmas que ainda carecem de pesquisas. Isto faz estas aplicações serem Social Machines .SM’s. o que usar de CC? Na verdade este paradigma traz novidades a todos os seguimentos da engenharia de software. regras e relações de trabalho.3 PROBLEMÁTICA A justificativa por si já sinaliza a existência de alguns problemas relacionados às aplicações que compõem a Web. Assim. o aspecto dos sistemas que são Máquinas Sociais que interagem na Web 3.Capítulo 1.0. Introdução segurança. Portanto. descobrir ou adaptar teorias importantes dentro da engenharia de software. aos sistemas computacionais que tendem a crescer em tamanho e complexidade vertiginosamente. 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. que exercem suas funções por meio desta e por meio da intervenção de outras aplicações. ou seja. 1. sempre 5 . e a própria aplicabilidade dos serviços CC. Em nossa atualidade existe uma tendência cada vez maior em se fazer negócios em escala global impulsionados por novas tecnologias. compartilhamento de recursos. o que essencialmente impulsiona as pesquisas desta natureza é o fato de trabalhar com novas possibilidades dentro do desenvolvimento de software. performance dos aplicativos. aplicativos que estão sujeitos a trabalhar nessa realidade da Web devem ser concebidos de forma diferenciada. isto traz um maior grau de complexidade aos negócios (REZENDE. Tal estágio da Internet vem vendo investigado e trabalhado justamente por ele possibilitar transações. As pesquisas devem partir do pressuposto de que aplicações Web são sistemas que se comunicam em rede. Nesta seção os problemas serão pontuados mais fortemente. sobretudo. 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. interações e programação de aplicativos diretamente na plataforma Web. 2006) e. com o auxílio de uma infra-estrutura que é disponibilizada pela própria Web.

Capítulo 1. Mark Harman. 2001). novas linguagens. e expliquem melhor o desenvolvimento de aplicações Web. ela passa a ser um emaranhado de códigos. haja vista. que pode ser caracterizada como uma moderna rede de computadores sociáveis e interoperáveis. A tendência também é em projetar sistemas que são cada vez mais dependentes da rede (BEHRENDT. tal evolução não se limita aos sistemas Web e aos negócios. A construção de sistemas está cada vez mais imersa na complexidade das inovações tecnológicas causadas pelo surgimento de novos frameworks. 2010).  O auto gerenciamento de sistemas Web que compartilham atividades com outros sistemas distribuídos na rede. este trabalho se dedica a resolver problemas e questões delicadas à Web 3. Denis A. Os problemas resolvidos serão: 7 Ian Sommerville.. pois estes necessitam de uma arquitetura diferenciada. Desenvolvimento de software sob demanda. Além das questões pontuadas acima. Paul Clements. Introdução na tentativa de atender as demandas dos negócios (REZENDE. et al. Ao passo que isto é positivo também é preocupante. pois a Web é caótica em diversos aspectos tecnológicos. David Garlan. esse trabalho também visa resolver problemas clássicos na construção de sistemas. Roger Pressman. Assim. padrões e protocolos que por vezes atrapalham o desenvolvimento das aplicações (HOFMEISTER. Entretanto. 2006). de novas idéias e iniciativas que organizem. estruturem. que segundo estudiosos7. muitos deles são desligados de um repositório físico para armazenamento. deve-se ter atenção a todos os detalhes dos sistemas a serem construídos. serviços e padrões de desenvolvimento evoluíram com a Web e ajudaram a construir novos negócios. compartilhando tal repositório com outro software (AZEEZ et al. processos.0 programável. 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. Resende. Na verdade. arquiteturas. 2000) necessitando assim. podem gravar o desenvolvimento de aplicações para a Web. 6 . Tecnologias. Neste aspecto. e novos protocolos que surgem em um intervalo cada vez menor de tempo.

ou projeto arquitetural. Dependendo da natureza do problema o projeto pode até ser descontinuado. 2003). são os oriundos da arquitetura (PRESSMAN. A Google no ano de 2009 precisou cortar gastos. 2006). O micro blog trocou seu banco de dados MySQL pelo Cassandra em virtude do alto crescimento da taxa de dados transitados (AFRAM.com/intl/pt-BR/press/. http://blogs. Um exemplo clássico de problemas com arquitetura. Em: 7 . construídas por duas grandes corporações. o mesmo ocorreu com o Microsoft Popfly no mesmo ano9. 9 Informação disponível na MICROSOFT COMMUNITY BLOGS. 2010. uma vez que eles aconteçam. Introdução     Manutenções demoradas e críticas dos sistemas. Máquina Social. 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. Ausência da arquitetura.msdn. a Google e a Microsoft. O processo de concepção de uma arquitetura é por vezes mal executado ou não executado (BASS. Acesso 16 out de 2010. No momento das decisões arquiteturais do Twitter não houve um raciocínio sobre o crescimento exarcebado do mesmo. isto ocorre não somente. mas principalmente. este foi o caso de algumas ferramentas que desenvolvem Mashups.com/b/nick_wong/archive/tags/event+announcements/. assim resolveu paralisar o desenvolvimento de alguns de seus produtos8. 2011) ou quando a mesma está desenvolvida. CLEMENTS e KAZMAN.Capítulo 1. as iniciativas para saná-los devem ser precisas e rápidas. Requisitos mal trabalhados. com isto optou-se pelo banco de dados errado. Este caso poderia ocorrer a qualquer aplicação Web que contivesse alguns dos problemas pontuados acima. foi o caso do Twitter. O problema inerente a este estudo reside na dificuldade de se especificar e desenvolver aplicações Web distribuídas e conectáveis.google. Em: http://www. que podem inclusive causar o fim de um projeto. porque estas SM’s não são submetidas aos métodos ou 8 Informação disponível no OFFICIAL GOOGLE BLOG. 2008). Projetos de aplicações Web estão suscetíveis aos problemas pontuados. ou seja. entre eles estava o Google Mashups Editor. Acesso em: 30 ago. Alguns dos maiores problemas relacionados ao desenvolvimento de aplicações Web. Ausência de uma estratégia de negócio que adeque aplicações Web à resolução dos problemas. apenas para exemplificar.

elas possam se articular e se expressar na rede em conformidade às inovações pertencentes à mesma. sobretudo da Internet. Os problemas podem ser mensurados ainda na concepção da arquitetura. de arquiteturas de Máquinas Sociais. de modo que.0 seriam SM’s prontas para atender as demandas do contexto atual de negócios e de inovações tecnológicas. 1.4. neste sentido. o tratamento destes problemas poderia se iniciar na arquitetura da SM. como já tratado. sobretudo. Tais práticas poderão atuar nas decisões arquiteturais. deixando-as vulneráveis aos problemas. O objetivo é mostrar a forma menos burocrática e mais coerente de se montar uma arquitetura de qualidade para Máquinas Sociais. deste modo. Introdução tecnologias que tratem corretamente suas particularidades. Desta maneira a problemática focada se relaciona seriamente com a necessidade de se especificar arquiteturas de SM’s. problemas estes que já foram explorados em uma seção anterior.1. engenheiros de software.4. otimizando assim a própria rede. Tal problemática nasceu em razão das aplicações Web. as aplicações Web 3. a arquitetura que é o arcabouço de qualquer software faria total diferença. pois muitas das aplicações WEB que devem ser vistas como SM’s não são. programadores e gerentes. não tiveram o devido tratamento e atenção quanto as particularidades de uma SM. como: analistas de requisitos. O ponto de partida da adversidade deste estudo consiste na arquitetura de software. GERAL Recomendar práticas para auxiliar na especificação. Por consequência atuarão no processo de desenvolvimento. (KRUCHTEN. não terem sido concebidas como Máquinas Sociais. e mesmo concepção. OBJETIVOS: 1. Desta forma as arquiteturas das aplicações também não foram pensadas para estruturar SM’s. 8 .Capítulo 1. A missão dessas práticas é minimizar os problemas no desenvolvimento das SM’s. e no projeto arquitetural. Deste modo. Esta pesquisa se preocupa. 1995) integrando profissionais com aptidões distintas. haja vista que a arquitetura mobilize muitas fases do projeto de software. em resolver o problema explicitado neste parágrafo. Com isto o objetivo do trabalho será apresentado.

1.4. 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.0.2. 1.0. são subprodutos do objetivo geral. 4. 2. Verificar a existência de uma arquitetura de referência para sistemas Web 3.5. ao passo que poderá padronizar as tecnologias adotadas. Introdução As práticas também visam customizar a arquitetura de referência que será proposta. métodos ou procedimentos dedicados a especificação de arquitetura. deve ficar claro que talvez essa pesquisa não resolva todos os problemas causados pela complexidade das inovações tecnológicas. 5. Disseminar as práticas em um ambiente real de desenvolvimento para verificar a aplicabilidade das mesmas. Na verdade. Mas. Esta seção fortalece o objetivo principal. ESPECÍFICO Tratando-se do objetivo deste trabalho. pois expõem os resultados que serão alcançados com a formalização da metodologia. Sugerir uma arquitetura de referência para Máquinas Sociais no intuito de guiar a elaboração das demais arquiteturas. o que foi comentando ainda na problemática. Estudar práticas.Capítulo 1. Exemplificar Máquinas Sociais já implementadas e aplicadas à indústria de software. 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. 3. 7. certamente organizará o desenvolvimento das Máquinas Sociais. 6. Contribuir para o amadurecimento de um framework ou padrões de projeto para Máquinas Sociais. 8. ou metas estabelecidas para serem obtidas ao longo do trabalho. Estudar as tecnologias emergentes ao desenvolvimento de aplicações Web 3. TRABALHOS RELACIONADOS 9 .

vale dedicar esforços às questões que envolvem a peça fundamental para qualquer sistema e aplicação computacional. Arquitetura de Software (AS) pode ser classificada como um conjunto de decisões dedicadas a resolver um problema (PRESSMAN. Tim Berners-Lee em 2001. São diversos os conceitos para a AS. 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.0. e todos eles defendem a relevância de se definir corretamente a mesma. Algumas destas pesquisas foram feitas por grandes estudiosos. pois os reflexos dessa definição podem ser pressentidos de forma intensa ao longo da implementação do software. Com isto trabalhos que se empenham em facilitar a especificação da arquitetura estão interligados a esta pesquisa. Todos estes estudiosos relatam como a Web 3.R – Centro de Estudos Avançados do Recife.E. Bass e Clements em 2003.0 muda definitivamente o aspecto da Internet. inteligente e independente. e a IEEE Recommended Practice for Software Requirements Specifications. ou ainda uma coleção de componentes e conectores (ligações) que irá compor o sistema (GORTON. seja este modesto ou não (BASS. 2006). Esta pesquisa também está totalmente relacionada a arquitetura de software. são trabalhos fortemente relacionados. seu arcabouço (PRESSMAN. 10 . 2009). transformando a mesma em algo mais interativo. 2003). Gamma em 2000. A AS pode ser ainda a abstração de um sistema computacional. 2011). a IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems. injetando forças em conceitos como Cloud Computing e Redes Sociais. como Mark Benioff em 2010. o qual também dissemina pesquisas sobre Máquinas Sociais. sobretudo a Web 3. e por Robert Bryant em 2007.Capítulo 1. Os trabalhos que exploram as SM’s relacionam as mesmas às pesquisas direcionadas à Internet. cientista do C.S.A. Neste sentido. Assim. CLEMENTS e KAZMAN. outros estudos sobre AS estão da mesma forma entrelaçados como o de ERL em 2005. Todos os conceitos levantados sobre AS são de obras que estudam arquitetura e que também estão entrelaçadas a esta pesquisa.

7. como: Redes Sociais. e também para trabalharem com os conceitos emergentes do universo da engenharia de software. Introdução 1.  Demonstrar métodos avaliativos sobre artefatos de software e sobre SM’s. deste modo. elas sofrerão o mínimo de problemas em seu desenvolvimento e manutenção. 2008). A dissertação também será uma pesquisa do tipo Acadêmica. 11 . Este capítulo se fez necessário pelo fato das SM’s serem peças fundamentais à pesquisa.  Facilidade na adoção de padrões arquiteturais e tecnologias que constituem uma Máquina Social. Sendo assim. a qual é bastante utilizada em trabalhos com temática inovadora (SEVERINO.  Propor soluções que possam facilitar em algum aspecto a interação entre as SM’s.0. Os seguintes resultados são esperados:  Amadurecimento e disseminação do conceito de Máquinas Sociais. a pesquisa é do tipo Exploratória. ao passo que amadurece o pensamento acerca das decisões de projeto dessas aplicações. 1. pois sistematiza um processo para construção de um novo conhecimento (SEVERINO.Capítulo 1. Internet 3. Cloud Computing entre outros.6. 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. trata-se de um trabalho dedicado às SM’s. ESTRUTURA DO TRABALHO Este trabalho é um estudo recente que busca soluções adequadas para a construção de Máquinas Sociais. 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.0. 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.  Impulsionar novas pesquisas em Máquinas Sociais. 2008).  Contribuir para o amadurecimento dos conhecimentos sobre o atual cenário de desenvolvimento de aplicações Web 3.

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

além das várias operações de suporte aos serviços ofertados. recentemente. 2010.microsoft. incluindo design. testes. a Force.com é uma plataforma de desenvolvimento em Cloud Computing. Assim. 15 . 2008) onde ocorrem os aluguéis de Data Centers que fazem a hospedagem das aplicações. 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.com ficou conhecida pelo serviço de Customer Relationship Management CRM vendido as empresas. Acesso em 02 de jul. por exemplo. Estas plataformas foram denominadas Plataform as a Service .PaaS. cujo nome é Chatter (Salesforce. Em: www. que por sua vez. depuração para encontrar defeitos. 2010. 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. Disponível em: http://aws.bungeeconnect. uma vez que é totalmente centrada na aplicação e abstraída de qualquer conceito de servidores locais (WEINHARDT.amazon. 12 Amazon AWS é uma empresa que trabalha com Cloud Computing.com.com11. cópias de segurança. gerência de configuração. 2011.com.Capítulo 2. Acesso em: 1 de mai. A Force. A Figura 1 ilustra a estrutura da CC. 11 Force. trata da infraestrutura de servidores (MCPHERRON.code. 2010). 2008).com/appengine. pois agora os recursos de hardware são serviços remotos (MCPHERRON. oferta serviços de hospedagem e IaaS. Em: www.com/windowsazure. 2009). nela também é possível comprar aplicativos. das quais. se caracteriza como uma das mais acessíveis e popularizadas. Isto elimina as preocupações das empresas em salvaguardarem um parque tecnológico para manter as aplicações. O alicerce para o conceito de Cloud Computing é a Infrastructure as a Service – IaaS. 2010. Acesso em: 30 de jun. Acesso em: 20 de mai. a plataforma divulgou sua rede social personalizada para desenvolvedores.com. ou partes deste. implementação. IaaS é um serviço oferecido por empresas como Amazon AWS12. em Cloud Computing. 10 Exemplo de plataformas: Em: www. rápida instalação (ou deployment).google.

por exemplo. 2009). Uma poderosa empresa que trabalha nesta camada é a Amazon. Representação da Estrutura de Cloud Computing Dentro de cada camada representada na Figura 1. de fazer. tais como: aplicativos para processamento de textos e planilhas. garantia de integridade. balanceamento de carga. Entretanto. Ainda dentro dos novos negócios que surgem em Cloud Computing .CC estão os serviços da Google Apps. surge. BLAU e STOBER. calendários e outros.com/ec2. confiabilidade e rapidez de desenvolvimento (WEINHARDT. Na camada de IaaS. 16 .Capítulo 2. O pagamento para este serviço é baseado no modelo chamado “sob demanda” onde se paga apenas a quantidade de serviço utilizado (WEINHARDT. Acesso em 17 de dez. 2011. segundo Weinhardt. existem modelos de negócios que são baseados na função de cada camada. e aumento de recurso computacional automaticamente conforme o crescimento da aplicação. emails. e de negociar programas computacionais. disponibilidade de serviços.amazon. Vale ressaltar que o crescimento de novos modelos de negócios em CC está relacionado principalmente à segurança de dados e informações. é notável a alteração que CC causou no cenário da engenharia de software. Blau e Stober (2009) o chamado Infrastructure Business Models que trabalha com capacidades de armazenamento e suprimento de poder computacional. e um deles é o Elastic Compute Cloud2 EC213 que provê segurança. nas formas de pensar. esta possui um enorme conjunto de aplicações na CC. Máquinas Sociais Figura 1. BLAU e STOBER. Assim. A Amazon oferece uma série de serviços. este não 13 Disponível em: http://aws. 2009).

a fim de. A implementação de uma SM pode ser feita por meio de Cloud Computing. 2011: 17 . Figura 2. o que pode influenciar em requisitos.Capítulo 2. CONCEITO DE MÁQUINAS SOCIAIS Máquinas Sociais são sistemas. As Redes Sociais também contribuíram para as inovações em engenharia de software. Máquinas Sociais é um privilégio da Cloud Computing. et al. 2011). que possuem uma unidade de processamento interno e são capazes de interagir com outras máquinas. teste e arquitetura. 2.2. uma SM pode ser um serviço oferecido pela nuvem já dentro do panorama dos novos negócios. A Figura 2 mostra a representação básica da SM. segundo Meira et. descritos como se segue. portanto. 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. ou mesmo. al.0. ou aplicações Web. 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. conectáveis. estão no contexto do novo conceito de SM’s. pois algumas dessas redes são ferramentas de programação da própria rede social. Tanto as Redes Sociais quanto a CC estão inseridas no contexto da Web 3. executar um serviço (MEIRA.

SM’s metainformation response. assim uma aplicação pode utilizar o serviço de outra sem ter que necessariamente codificar (Tanembaum 2006). ter conhecimento sobre o seu estado. assim. de disponibilidade e outros. a fim de. e Notification response.  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.  Response: é a resposta remota da SM ao solicitante.  Input: é a entrada de dados que de fato será processada pela unidade e que só ocorre após a requisição de procedimentos. e SM’s meta-information request. 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 SM’s meta-information request: trata-se de uma requisição de consulta para uma determinada SM. os objetos a serem manipulados 14 API é o conjunto de funcionalidades de um software disponibilizado por meio de seus códigos e rotinas. 18 . Esta Interface pode também ser entendida como a API14 da SM. 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. mensagens de sucesso. o Notification response: são notificações de uma máquina a respeito de algum evento ocorrido. novamente por meio da Interface Wrapper. ou mesmo sobre os seus parâmetros de custo e tempo de resposta dos seus serviços. Informações sobre a API do Twitter em: http://apiwiki. disponibilidade e outras meta-informações associadas à SM. o SM’s meta-information response: é a resposta direta ofertada a uma SM’s meta-information request. O Request é classificado em: SM’s functionality request. o SM’s functionality response: trata-se da resposta direta ofertada a uma SM’s functionality request. Seus tipos são: SM’s functionality response.Capítulo 2. Pode haver várias ou nenhuma SM’s functionality response para uma SM’s functionality request.com/.twitter. de erro de envio de mensagem. Pode ser uma notificação de erro de execução.

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

o que sobressai a característica sociável do Eucalyptus. além disto. ou visualizadas.2. Esta IaaS permite aos usuários acesso e gerência a todas as máquinas virtuais existentes (LIU et al. 2003) 22 .1. como diferentes sistemas conectados em rede. Assim. além de possuir uma robusta Wrapper Interface chamada de Cluster Controller (LIU et al. ou ainda. sendo que os elementos mais importantes para esta IaaS são as solicitações. EUCALYPTUS: O Eucalyptus é uma IaaS de código aberto que fornece suporte para a integração com outras IaaS como a Amazon AWS.5. O Cloud AV utiliza técnicas baseadas em cache para melhorar o desempenho durante o envio de arquivos. como diversificadas tecnologias Web. CLOUD AV: O Cloud AV é uma ferramenta antivírus ofertada como um serviço de Cloud Computing. o Eucalyptus envia Request e recebe Response a todo o momento.5. 2007). Ao final dos exemplos será possível notar que os conceitos de SM’s não se limitam apenas às aplicações Web.. 2. que podem também ser SM’s. Tal serviço identifica arquivos maliciosos por múltiplos mecanismos de detecção em paralelo que se comunicam entre si exatamente como SM’s. 2007) que possibilita uma interação imediata a eficaz com todas as máquinas virtuais. para 19 SOAP é um protocolo que viabiliza a troca de mensagem entre os sistemas (TITTEL. Neste ponto o Eucalyptus possui muitos dos elementos das SM’s. Tais máquinas podem também ser explicadas. Abaixo descrevemos o nome da tecnologia e o porquê ela pode ser considerada uma SM. 2. O Eucalyptus trabalha essencialmente com virtualização. apesar deste trabalho focar nas SM’s que são aplicações para Internet..5. EXEMPLOS DE MÁQUINAS SOCIAIS Para consolidar mais os conceitos deste capítulo é interessante exibir alguns modelos de SM’s. além de utilizar o protocolo SOAP19 para consultas. Com o Eucalyptus o usuário também pode gerenciar sua nuvem criada em outras ferramentas. Essa IaaS pode ser considerada uma SM pelo gerenciamento e reconhecimento do estado de outras máquinas.Capítulo 2. Máquinas Sociais 2.

2010). reduzindo-os a um único valor (LIN e DYER. O processamento. et al.5. é realizado sobre cada bloco.3.  Output: Envia o resultado da análise dos arquivos apontando quais estão infectados ou não. 23 . 2. a ferramenta é executada em máquinas virtuais (OBERHEIDE. Esse aplicativo ainda facilita outras atividades como: mecanismo de tolerância a falhas. MAP REDUCE: O MapReduce é um framework para processamento de grande volume de dados. 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. 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. chamados de blocos. além da característica de sociabilidade da SM. distribuição dos dados e balanceamento de carga. A primeira. além de outros como o State. Além de possuir os elementos da SM.. A segunda função. chamada Redução. Máquinas Sociais prover escalabilidade.Capítulo 2. recebe uma porção do arquivo de entrada. e de acordo com a especificação do usuário. recebe um conjunto de valores associados a cada chave. Evidentemente o Cloud AV possui o elemento Processing Unit para possibilitar tantas análises. cada função de redução emite um conjunto de tuplas que são armazenadas em arquivos de saída.. chamada de função de Mapeamento. o MapReduce possui a característica da SM de se auto-reconhecer e reconhecer o volume de dados entregue (LIN e DYER. como os já citados. emite um conjunto de tuplas intermediárias no formato chave-valor. et al. o que torna possível a interação com os vários antivírus até que o resultado seja encontrado. definido pelo usuário. por fim. Tal redução pode ser vista com os elementos Input e Output da SM. O MapReduce trabalha com funções que se comportam como SM’s. 2010). O Cloud AV possui os seguintes elementos (OBERHEIDE. Por redução se entende: uma função que "recolhe" os itens em listas e realiza alguma computação em todos eles. 2008). É por isso que o sistema MapReduce consegue trabalhar com grandes volumes de dados.

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

CONSIDERAÇÕES FINAIS DO CAPÍTULO Este capítulo apresentou as Máquinas Sociais. 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. interação. trocando ontologias.Capítulo 2. Vale salientar que existem outros materiais que explicam minuciosamente o conceito das SM’s os quais estão referenciados na bibliografia deste trabalho. 2. A Web Semântica possui vários agentes interagindo entre si. compreendendo. O próximo capítulo tratará com igual propósito no que concerne à arquitetura das SM’s. 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. entre elas: sociabilidade. adquirindo novas capacidades racionais ao passo que adquirirem novas ontologias para formar cadeias que facilitam a comunicação e a ação humana. sociáveis e têm a capacidade de aprender. 25 . Tais características necessitam de todos os elementos das Máquinas Sociais. e comunicação. Pela citação direta nota-se claramente as características de uma SM na Web Semântica. Máquinas Sociais flexíveis.6. Deste modo. colaboração.

que é facilitar a construção de arquiteturas. e futuramente. 26 .Capítulo 3 3. Com isto. 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. e assim das próprias aplicações que são SM’s. será possível sugerir uma arquitetura de referência dedicada às Máquinas Sociais. sugerir práticas de engenharia de software coerentes ao maior objetivo do trabalho.

A AS está intimamente ligada aos requisitos de software. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais 3. onde uma máquina exercia o papel de cliente requisitante e a outra máquina. CLEMENTS. KAZMAN. KAZMAN. Estas são escolhas em relação às tecnologias utilizadas para desenvolver a aplicação (PRESSMAN. o que ocasionou uma evolução nessa área de estudo da engenharia. pesquisas de Harman e Jones (2001). 2011). mesclada a outras arquiteturas para atender ao objetivo de um software. INTRODUÇÃO Não somente. o papel de servidor com a responsabilidade de atender as requisições.2. por sua vez.Capítulo 3. (2008). e Kruchten (1995). ARQUITETURA DE SOFTWARE Arquitetura de Software (AS) é a definição da estrutura e dos elementos que compõem um sistema. impulsionaram o surgimento de novos padrões. 2003). Pressman (2005). 27 . sobretudo. a arquitetura cliente-servidor tornou-se padrão na engenharia de software. métodos. como esses elementos estão inter-relacionados. 3. Freitas et al. representações e técnicas relacionados à arquitetura de software. sendo em nossa atualidade ainda explorada e. CLEMENTS. mais fortemente aos requisitos não funcionais (RNF) (BASS. Ao longo da história a AS foi várias vezes explorada. gerou soluções úteis ao desenvolvimento de software. Na evolução dos estudos da área. Sendo assim. a definição de uma arquitetura se inicia com o levantamento e análise dos requisitos seguido pelas decisões de projeto. As principais características do estilo Camadas são. 2003). Hoje parece ser este o cenário: arquiteturas cada vez mais heterogêneas. mas sobretudo. 2000:  Camadas superiores são específicas da aplicação.1. e quais as suas características (BASS. a arquitetura de software era basicamente voltada para os sistemas cliente-servidor. direcionadas a área da engenharia de software. segundo Erich Gamma. descobriu-se que o estilo arquitetural Camadas facilitava enormemente o desenvolvimento de softwares para a Web. Em tempos longínquos. onde estilos e tecnologias diferenciadas se misturam para formar novas versões de representações arquiteturais. Deste modo. conduzindo a um universo de descobertas que.

com as camadas que estão imediatamente acima ou abaixo. uma vez que inicialmente era constituído por duas camadas e atualmente já pode ser constituído por até quatro ou mais. ela valida os dados fornecidos pelo usuário e o conecta aos serviços da camada inferior. Figura 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais  Camadas inferiores são mais responsáveis pela infraestrutura. Estilo arquitetural Camadas  1ª Camada. 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.Capítulo 3. 28 . Persistência: é a camada responsável pelo acesso aos meios de armazenamento como: memória. 3ª Camada.  As camadas só interagem com camadas contíguas. ou seja. 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. 2000).   2ª Camada. oferecendo suporte às camadas superiores. Apresentação: camada onde o usuário interage diretamente. elas se dividem em 3 camadas e mais o repositório de dados ilustrados na Figura 3 (HOFMEISTER. O estilo Camadas se popularizou e passou por evoluções.  O conteúdo das camadas pode ser variável. banco de dados e sistemas legados.

 As camadas podem ser reutilizadas. ou seja. mormente. dentro de uma camada pode existir outro estilo arquitetural (LARMAN. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais consoante Christine Hofmeister (2000). para sistemas que necessitem de ótimo desempenho as camadas não são aconselháveis. as camadas poderão ser reutilizadas. pelas características expostas a seguir (KLEIN. 1994). KAZMAN. Logo. pois sua utilização não é viável para todos os sistemas (BUSCHMANN et al. ele deve ser analisado antes de ser adotado para a arquitetura do software. sua popularização se deve. com características semelhantes e algumas melhorias. o que afetaria apenas a interação com as camadas adjacentes. Assim. KAZMAN. Apesar dos benefícios agregados pelo estilo em Camadas. 2007). 2011).  Suportam outros estilos associados. SHAW. além do estilo Layering Through Inheritance. como o padrão Observer. 1999).  É o estilo arquitetural com o maior número de variações.. 2007). já explicado anteriormente. visto que elas suportam alterações. como: permitir que camadas superiores modifiquem os serviços das classes das camadas inferiores. outra derivação do Camadas (KLEIN. porquanto o tempo de processamento e a própria comunicação entre as camadas pode ser elevado (BUSCHMANN et al. Outro critério de qualidade é a tolerância à falhas.  As camadas favorecem o baixo acoplamento e a alta coesão (LARMAN. 1996). 1999):  As camadas podem resolver problemas complexos de forma sequencial e incremental (SOMMERVILE. 2007). desde que mantenham interfaces de comunicação adequadas às suas camadas adjacentes (GARLAN. assim como todos os estilos. Além das características expostas acima.  Podem ser facilmente empregados padrões de projetos. o Relaxed Layered System. no qual existe uma quarta camada de Middleware ou mesmo um servidor Web para fazer a gerência da aplicação.Capítulo 3. 1996). Se uma 29 . fortemente utilizado na interação entre as camadas (LARMAN.

nas orientações das obras de Bárbara Kitchenham e David Budgen (2008 . 30 . já se disponibiliza um parâmetro inicial para a construção da arquitetura correta de SM’s.3. O desenvolvimento deste estudo foi baseado. 3. Para finalizar a exposição dos conceitos relacionados a arquitetura de software.0. e que ela. Portanto a questão de pesquisa é: “what are architecture of reference for Social Machines?”. assim está estruturado como se segue. A partir do ponto em que se estabelece uma arquitetura de referência. vale mais uma vez enfatizar que uma arquitetura de referência será esboçada. 2000). uma arquitetura que facilite o desenvolvimento de SM’s por ser uma arquitetura padrão a todas as SM’s.Capítulo 3.2009). e de Pertersen (2008). Traduzindo: existem arquiteturas de referência para Máquinas Sociais. uma vez que esse capítulo trata de um estudo sobre arquitetura. 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. 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.1. e que pode ser perfeitamente guiado pelas práticas que darão forma ás arquiteturas. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais camada ficar indisponível. que uma camada depende de outra para funcionar (HOFMEISTER. PROCESSO DE REVISÃO 3. o sistema na sua integralidade poderá ficar indisponível. entre outros. Torna-se relevante ter um estudo dessa categoria compondo a pesquisa. precisa de um estilo arquitetural. assim como toda arquitetura de referência. haja visto. 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.3. Faz-se necessário esta seção sobre arquitetura de software.

3.  Publicação: Materiais técnicos que tratem das arquiteturas. QUESTÕES DE PESQUISA: Seria mais fácil encontrar materiais que fossem dedicados aos sistemas. Complementando a motivação acima. 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. uma das questões investigará a existência de uma arquitetura de referência para aplicações web. possibilitando dessa forma. Assim. além de utilizarem serviços e recursos destes elementos e também da própria rede para funcionar. visto que o quantitativo das pesquisas que tratam as aplicações propriamente como Máquinas Sociais.2. o estudo foi direcionado aos sistemas que estejam imersos e preparados para trabalhar dentro dos princípios da Web 3. a existência de um padrão entre tais arquiteturas. e auto gerenciar. as questões de pesquisa foram selecionadas. Sistemas Autônomos e aplicações Web. O que se almeja descobrir neste estudo é o estado da arte de arquiteturas de aplicações Web. Estes possuem características marcantes das SM's por interagirem com outros elementos em rede. ou seja. com arquiteturas de Máquinas Sociais. maior número de pesquisas e experimentos sobre elas. Computação nas Nuvens. o que pode facilitar o desenvolvimento do estudo em questão.3. existe o fato das Máquinas Sociais selecionadas para as questões serem mais difundidas. Sendo assim. e práticas relacionadas às Máquinas Sociais. se desenvolver.0. Como o escopo deste trabalho está centrado no contexto inovador da Web 3. Do mesmo modo.0. 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 . bem como. ou sistemas. aplicações ou tecnologias que possam ser classificados como Máquinas Socias.0 ou para sistemas que possam ser classificados como Máquinas Sociais.Capítulo 3. o estudo pode ser facilitado com a inserção de uma questão de pesquisa dedicada às aplicações Web em geral. é inexpressivo. Redes Sociais. optou-se em utilizar questões que abordem arquiteturas das tecnologias: Mashups.

orientam a idéia de melhorar os filtros de busca. as questões de busca foram por vezes alteradas com o auxílio das strings. foram utilizados na investigação por vezes mesclados às questões acima. Which. SaaS. Software as a Service. Social Networking. Internert. Social Machine. 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. Facebook. Social. Elas foram escritas na linguam inglesa apenas para facilitar a obteção de resultados. os strings são: Web 3. Tendency. No objetivo de encontrar o maior número de resultados que atendessem a questão de pesquisa. Multitenancy. “What are the architectures of “Cloud Computing” OR “Platform as a Service” OR “PaaS”. Tred. PaaS. Mashup Architecture. Systems. Applications.0.0. Multitenant. Platform as a Service. Reference. os termos ou “strings” a seguir. Map Reduce. Machine. Software Engineering. Scalability. Architecture. como exposto abaixo:    “What are the architectures of “Cloud Computing” OR “Multitenant” OR OR “Multitenancy”. pois acreditasse que os resultados de estudos serão em maior quantidade na língua inglesa. “What are architecture of “Social Networks” OR “Social Networking”. Web 2. Cloud. Networking. No entanto. Architectural Innovations. Web Applications. Computer. Semantic Web. Autonomous Systems.Capítulo 3. Patterns. Por conseguinte. Style. neste caso. Twitter. é necessário utilizar palavras que complementassem a busca pelas respostas das questões de pesquisa. 32 . Architectural.

3. e que por sua vez. bem como revelassem materiais que não pertencessem aos repositórios mencionados. foram aplicados em uma investigação secundária. 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. Sendo assim. IDENTIFICAÇÃO DO MATERIAL Todo material revelado pela busca foi precedido de leitura do título. Deste modo. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais 3. entretanto. máquinas de busca como: Google Scolar e Google Books. Mendeley. Este trabalho possui natureza científica.3.Capítulo 3.4. CRITÉRIOS DE CLASSIFICAÇÃO . 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. 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.  Atribuir relevância mediana para materiais que: 33 . uma relevância era atribuída ao material conforme alguns critérios de classificação.  Atribuir maior relevância para materiais que se caracterizem como: o Arquiteturas já testadas e empregadas em Máquinas Sociais.5. 3. Após essa leitura. agregando valores à pesquisa em comento. houve a necessidade de empregar ferramentas que ofertassem um resultado mais direcionado ao mercado tecnológico. IEEE Xplore.INCLUSÃO: A inclusão de pesquisas a serem consideradas para o referido estudo se baseou na relevância declinada. o Soluções de projeto ou decisões de projeto de aplicações vistas como Máquinas Sociais. 3. e ACM Digital Library. Foram também empregados capítulos de livros e revistas digitais especializadas para subsidiar a investigação (KITCHENHAM. fossem mais técnicos e menos científicos. 2009).3.3.

as quais foram analisadas e classificadas.docx. construindo a base de conhecimento de forma textual. tal organização observou também a extração de evidências que satisfizessem as questões de pesquisa. periódicos e capítulo de livro. 2008). das strings.8.7. 11 (onze) destes materiais mostraram maior contribuição para as questões de pesquisa.3.3. 3.3.Capítulo 3. sem nenhuma proposta evidente de tal. 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. formando um resumo significativo.6. e ainda estudos duplicados. 3. o Sejam projetos “piloto” de arquitetura de referência para aplicações ou sistemas WEB. ou não. RESULTADO Os materiais mapeados compõem-se na sua totalidade 21 (vinte e um) textos entre artigos. REGISTRO DO MATERIAL Foram elaboradas fichas de leituras.dropbox. validando assim este estudo (PERTERSEN et al. Foram descartados ainda materiais que ofertassem um conteúdo muito conceitual sobre arquitetura. 3. sem definição de elementos ou recursos que possam prover a arquitetura. O resultado de cada uma das questões é exibido na 34 . CRITÉRIOS DE CLASSIFICAÇÃO . mostrando assim a adoção. 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. que comprometam o entendimento do material.0.com/u/8309962 /Fichas%20de%20Leitura.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. cujo conteúdo integrava materiais de acentuada relevância que contribuiram para a pesquisa. estudos com abordagens insuficientes. As fichas estão disponíveis no repositório público: http://dl. As fichas foram organizadas pela ordem de classificação. bem como.

2009) Descrição Mashups: The new breed of web app Using Architecture Integration Patterns to Compose Enterprise Mashups Aneka: A Software Platform for . Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais tabela a seguir que engloba os 11 (onze) estudos contribuintes. Mashups 0 2 4 6 8 10 12 14 Figura 4.Capítulo 3. nele é possível observar que a questão das aplicações Web resultou em menos estudos.com’s Internet Application Development Platform CiteSeerX (KOSSMANN. apenas 2 (dois) onde 1 (um) foi considerado. Social Networks QP 2. entre propostas arquiteturais e estudos com abordagens duplicadas.com Multitenant Architecture Understanding the Design of Salesforce. LOESING. Vale ressaltar que a questão de pesquisa que trata de Cloud Computing foi a que retornou mais estudos. 2010) The Force. KRASKA. 2006) (LIU e LIANG. Web Applications QP 4. Cloud Computing QP 1. Numero de estudos por questão de pesquisa Fonte Mendeley IEEE Referência (MERRIL.0 2011) Google Scolar (WEISSMAN. O gráfico abaixo (figura 4) mostra a dispersão do quantitativo de estudos por questão de pesquisa. 35 . 2009) Google Scolar (BEHRENDT et al. CHU. 2010) An Avaluation of Alternative Architectures for Transaction Processing in the Cloud. IBM Cloud Computing Reference Architecture 2. BUYYA. QP 5.NET-based Cloud Computing CiteSeerX (VECCHIOLA. 12 (doze) no total. et al. Autonomous Systems QP 3.

uma característica de aplicações da Web 3. todavia. et al. 2011) Facebook: An Example Canonical Architecture for Scaling Billions of Messages Google Scolar Mendeley (AVRAM.0 Architectures Tabela 2. 2004) Twitter.Capítulo 3.1. 2009) An Architectural Bluepoint for Autonomic Computing Web 2. 2009) (MCCANN e HUEBSCHER. 2006) (GOVERNOR. ou seja.4 DEMONSTRAÇÃO DOS RESULTADOS DAS ARQUITETURAS DE REFERÊNCIA INVESTIGADAS Nessa seção as arquiteturas averiguadas nos materiais serão relatadas. T. 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.0. Na verdade essa aplicação emprega códigos de outras aplicações por meio de uma API (O’REILLY. 2008). ambas utilizam como referência a arquitetura em camadas e serão exposta a seguir. O Mashup tem a sua plataforma de programação sustentada pela própria Internet. O objetivo do relato é auxiliar na compreensão dos resultados encontrados.4. uma arquitetura Evoluindo Evaluation Issues in Autonomic Computing IEEE Google Books (IBM. não apenas esta particularidade é notada. Um exemplo de Mashup é o site Wikicrimes que mapeia nas regiões o índice de criminalidade com a ajuda do Google Map. 3. 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. 36 . Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Google Scolar (HOFF. Materiais selecionados para o estudo 3.

ou mesmo o próprio browser do cliente com Applet20. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais 3.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.  API: são os provedores de conteúdo que disponibilizam seus dados por meio de protocolos. Site Mashup: camada lógica onde o Mashup está implementado pode ser um servidor. 20 37 . 2006. além dela não demonstrar muita riqueza de detalhes. 2010). por exemplo. ET AL.4. Arquitetura Mashup por Duane Merril O principal questionamento acima desta proposta. é sobre a arquitetura não prever a integração dos dados. tal definição é de Duane Merril.Capítulo 3..1. Figura 5. o navegador executa esse programa na página para complementar o conteúdo da mesma (LOPES. tais dados podem Applet é um pequeno programa que é incluído nas páginas web. 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.

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

pois não se tem conhecimento da função que o filtro estava executando no momento do erro. MEUNIER. logo. conforme explicado. tais camadas são modelos de serviços oferecidos pela Computação nas Nuvens. para o padrão Piper and Filter. sua arquitetura deve assegurar a correta integração. gerenciamento. tal disfuncionalidade ocasiona perda de informações (GARLAN e SHAW. os conectores podem assumir um comportamento variado no processo. Por fim. ROHNERT. Neste sentido.Capítulo 3. Esse ciclo é contínuo até que haja demanda de processamento. SOMMERLAD e STAL. 3. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais por conseguinte. O grande desafio dos Mashups é reunir dados de diversas fontes para criar um único serviço. Eles podem ser um protocolo de comunicação ou uma cache.2. quando ocorre um erro em um dos componentes o sistema todo deve ser reiniciado. 1994).4. no estilo Pipers and Filters os componentes não conhecem o estado um do outro. dentre as quais. O importante é que eles realizem a leitura dos dados e os repassem para o filtro mais adequado (BUSCHMANN. deixando o Mashup vulnerável. ARQUITETURA DE REFERÊNCIA PARA CLOUD COMPUTING – QP2 Atualmente existem algumas propostas de Arquitetura de Referência para Cloud Computing. por ser orientado através de função não se mostra apropriado à representação dos dados.gov/index. aquelas que consideram as camadas de serviço: IaaS. os lêem e repassam para os próximos filtros.html.nist. PaaS. o estilo em questão. Este problema não é solucionado pelas arquiteturas propostas. Contudo. sendo assim. 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. 2011 39 . situado nos USA. Vale ressaltar que. Em contrapartida. 1996). o Instituto Nacional de Ciência e Tecnologia – NIST21. e SaaS como sendo a arquitetura da computação nas nuvens. transformação e organização dos dados. e não modelo de arquitetura. afirma que de fato não existe para Cloud Computing uma 21 Disponível: http://www. Apesar das propostas existentes. Acesso em: 01 de ago.

 Nuvem Comunidade: A infraestrutura de uma nuvem é compartilhada por diversas empresas. Nesta camada também estão os aplicativos e os SaaS. O instituto prevê uma arquitetura de referência que seja adequada também aos modelos de implantação de Cloud Computing. Abaixo desta camada está a camada Cloud 40 . a segunda proposta por KOSSMANN. Arquitetura Cloud Computing proposta por Vecchiola A Figura 6 retrata uma das arquiteturas mapeadas neste estudo.2. os quais são.4. Nesta seção vamos descrever três arquiteturas de referência para Cloud Computing. O NIST afirma que um dos seus objetivos é formular tal arquitetura em conjunto com outros institutos e com empresas do mercado americano. Qualquer usuário que conheça a localização do serviço poderá acessá-la. especializados em administração e manutenção de Cloud Computing. 3.  Nuvem Híbrida: A infraestrutura é composta de duas ou mais nuvens que podem ser públicas. segurança e portabilidade. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais arquitetura de referência. A camada Cloud Applications é a mais básica. a primeira baseada nos estudos de Christian Vecchiola de 2009. segundo Peter Mell e Tim Grance (2009):  Nuvem Pública: A infraestrutura das nuvens é disponibilizada para o público. a arquitetura a ser formulada deve facilitar a comunicação.  Nuvem Privada: A infraestrutura de nuvem é utilizada exclusivamente por uma organização. uma camada de aplicação onde os usuários finais podem manter seus programas na nuvem.1.Capítulo 3. ilustrar os vários serviços da nuvem e proporcionar o desenvolvimento de aplicações com alta escalabilidade. ou por terceiros. KRASKA e LOESING em 2010. Ainda consoante o instituto. privadas e comunitárias. permitindo total portabilidade. todas as aplicações podem ser adquiridas pelos usuário de forma dinâmica conforme a necessidade do mesmo. todas devem estar interligadas por uma tecnologia padrão. Em seguida estão as explicações para cada parte que compõem a arquitetura. sendo administrada pela própria organização. e a terceira determinada pela empresa IBM no ano de 2011.

22 23 QoS – Quality of Service (TANANBAUM. a camada mais abaixa Cloud Programming disponibiliza os serviços e os recursos para se implementar o software sob demanda. bastante flexibilidade à arquitetura.0. 2003) SLAs – Níveis de serviços definidos em um contrato (MELL e GRANCE 2009) 41 . Estas duas últimas camadas inferiores se comportam como IaaS.Capítulo 3. nela podem ser desenvolvidos os aplicativos e regulado o suporte ao desenvolvimento. a camada de mais baixo nível é a de infraestrutura física que contém Data Centers e conjuntos de CPU’s. Por fim. Todos os recursos dispostos nesta camada são acessados pela camada diretamente acima dela. oferecendo assim. o usuário poderá usufruir dos recursos. bibliotecas e linguagens de programação. os quais podem ser agregados ou subtraídos com liberdade. além de outros recursos de hardware. são basicamente ferramentas e ambientes que podem possuir interface Web 2. A Cloud Programming também pode ser chamada de Middleware User-Level. A relação entra elas reside no fato da camada inferior dar suporte à camada superior. A penúltima camada de Middleware Core é responsável pelo gerenciamento da infraestrutura física. serviços de virtualização e outros. haja vista o acesso à camada Middleware Core seja negado. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Programming. sendo assim. além de ferramentas para o desenvolvimento de sistemas Mashups. tal camada oferta serviços para a manutenção de QoS22 e SLAs23. recursos de programação distribuída. pois somente assim. Esta camada é similar a uma PaaS.

KRASKA e LOESING. os recursos de cada camada podem ser reorganizados. O balanceador repassa as solicitações para máquinas disponíveis em uma camada inferior. A arquitetura mais utilizada por PaaS e IaaS (KOSSMANN. 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.2.2. 2009) Uma crítica construtiva que pode ser feita a respeito desta arquitetura é sobre o seu estilo. Arquitetura de referência para Cloud Computing por KOSSMANN. além disto.Capítulo 3. o gerenciamento de cada camada pode ser feito independentemente. Figura 7.4. sendo tipicamente em Camadas. Estas processam as solicitações (HTTP) 42 . Arquitetura Cloud Computing proposta por KOSSMANN.NETbased Cloud Computing (Vecchiola et al. Fonte: An Evaluation of Alternative Architectures for Transaction Processing in the Cloud Segundo os autores. No contexto deste trabalho. quando houver necessidade de economia no investimento. pois a própria vai se readaptando. 2010. Arquitetura Cloud Computing por Vecchiola Fonte: Aneka. Deste modo. A Figura 7 representa a arquitetura. 2010) é tradicionalmente em camadas. e ofertar assim. toda camada tem uma responsabilidade distinta. 3. A software plataform for. KRASKA e LOESING. Enquanto isso. essa arquitetura é composta por uma camada de interface de usuário. essa faz uso de balanceadores de carga para distribuir os pedidos de clientes. um tempo de resposta melhor a cada solicitação. aquela estará preparada. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Figura 6. KRASKA e LOESING.

Consistência e disponibilidade não são obtidas ao mesmo tempo em nenhum sistema particionado em rede (BREWER. Tal execução pode ser nas linguagens Java ou C++ com SQL embutido. seja de aplicação. por sua vez.3. 2011. 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. 2000). 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. isto se revela como um diferencial que agrega muitos benefícios.2. pois cada solicitação HTTP pode ser encaminhada para qualquer servidor. cada partição é controlada por um servidor. Essa abordagem é conhecida na literatura como Esquemas de Particionamento (STONEBRAKER e HELLERSTEIN.4. como também. por exemplo. Tal banco. servidores web e servidores banco de dados. boa qualidade na prestação de serviços e otimização de recursos. 3. web ou banco de dados. Todavia a arquitetura em questão sacrifica a consistência dos dados devido ao particionamento e a necessidade de se conseguir disponibilidade. 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. 2005). O objetivo seria definir uma arquitetura única que permitisse aos ambientes de programação nas nuvens: economia no investimento dos recursos necessários. esse conceito foi aplicado não só na camada de banco de dados. Deixar este requisito negligenciado é uma falha potencial da arquitetura. Para Cloud Computing essa arquitetura oferece escalabilidade total e elasticidade em todos os níveis de camada. A Figura 8 define a IBM Cloud Computing Reference Architecture . é logicamente particionado em uma camada dedicada a ele.CCRA. na camada dos servidores de aplicação. Apesar do diferencial a arquitetura foi especificada de forma relativamente superficial. proposta por Michael Behrendt. 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.Capítulo 3. 43 .

Arquitetura de Referência Cloud Computing proposta pela IBM Fonte: IBM Cloud Computing Reference Architecture 2. 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. Tais responsabilidades serão expostas no decorrer desta subseção. se a aplicação deve ser atualizada a fim de corrigir erros e agregar melhorias. Seria um requisito de qualidade que vai além dos requisitos de usabilidade. existem 02 (duas) grandes camadas externas voltadas à Governança de TI e requisitos de qualidade. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Figura 8. Consumibility é um termo bastante utilizado pela IBM para expor qual o nível de adequação do produto ao cliente. A arquitetura foca nos serviços e recursos que a nuvem oferta e necessita. se o cliente está usufruindo do produto e. 44 . os detalhes tecnológicos foram subtraídos na descrição da responsabilidade de cada camada.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. de desempenho e da “Consumibility”. A camada de qualidade trata de aspectos voltados a manutenção da segurança. é novamente baseada no conceito de Camadas e. visa ainda avaliar se o produto foi bem instalado. desse modo. adequação e acurácia. da recuperabilidade do sistema diante às falhas. como se pode notar através da Figura 8.Capítulo 3. pois além de avaliar se o produto de software está satisfazendo o cliente.

um sistema legado. e solicitar serviços a outros componentes. PaaS). na qual todos os consumidores poderão interagir com os pacotes de serviços oferecidos pela própria camada. e desenvolvimento modular de software. Middleware. A Cloud Service Consumer possui diversos elementos. A camada de Cloud Service Provider é a camada da nuvem responsável pela prestação de serviço. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Ainda nesse contexto. CLEMENTS. IaaS. Como último elemento dessa camada temos o Consumer In-house IT. o Cloud Service Integration Tools. como: os conceitos de arquitetura de software. aplicações de negócios e gestão de serviços. criar outros serviços. A camada de Cloud Service Consumer tem a responsabilidade de alocar os recursos que consomem serviços da nuvem e. alguns conceitos devem ser resgatados. as três camadas centrais serão elucidadas: Cloud Service Consumer. Completando o elemento Cloud Services. onde os componentes têm a liberdade de exibir seus serviços. até negociação de compra e venda em Web Commerce. 2003). podendo conter infraestrutura. além de uma interface requerida que exibe quais os serviços necessários (BASS. visto que concentra as tecnologias que proporcionarão a integração dos recursos de TI da empresa aos recursos da nuvem. este componente pode estar presente em qualquer camada da arquitetura. é o Cloud Service Creation & Ecosystem Aspects que faz a seguinte correspondência na nuvem: 45 . está o Cloud Service Creation & Ecosystem Aspects. em que cada módulo a ser desenvolvido deve disponibilizar uma interface provida que ofertará serviços. 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. ainda alocar as pessoas que serão oneradas pelo uso dos serviços.Capítulo 3. KAZMAN. Observando inicialmente essas camadas. Por exemplo. que são:  Cloud Services: Este elemento além de manter todos os modelos de serviço de Cloud Computing já conhecidos (SaaS. cuja relação ocorre entre o serviço ofertado pela nuvem e os produtos que podem ser obtidos por meio desses serviços. Esse elemento faz a integração dos serviços da nuvem aos serviços e recursos locais da organização consumidora. Cloud Service Provider e Cloud Service Creator. como por exemplo. É a camada mais rica em elementos. desde os tradicionais serviços de hospedagem de aplicação. dentre eles.

Capítulo 3. é possível a formulação das seguintes conclusões. Ambos os componentes trabalham para dar suporte aos serviços da nuvem e aos clientes que consomem serviços da nuvem. Isso engloba todas as instalações necessárias. a IBM afirma que Cloud Computing é bastante semelhante à Arquitetura Orientada a Serviços – SOA. 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. ferramentas para virtualizaçã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. Por fim a camada Cloud Service Creator com o seu elemento Service Creation Tools. após a elucidação de mais uma proposta sobre arquitetura para Cloud. busca flexibilidade e modularidade na manutenção de cada camada.BSS. uma vez que as empresas podem oferecer a infraestrutura e a plataforma de desenvolvimento agregadas ao software como um serviço sob demanda. não exploram em demasia o nível técnico. Na abordagem da arquitetura.  Infrastructure: representa todos os elementos de infraestrutura necessários para que os provedores forneçam os serviços para nuvem. pois a Computação nas nuvens é trabalhada em termos de criação. Portanto. 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. ferramentas de layout de interface gráfica. Tanto esta arquitetura quanto a arquiteturas apresentada em 2009 são mais conceituais.OSS e Business Suport Services . e trabalham com um nível maior de abstração. vale mencionar que não existe qualquer tipo de software rodando sobre esta camada.  Common Cloud Management Platform (CCMAP): Esta camada ao lado da Cloud Services se divide em dois componentes principais: Operational Support Services . Tais ferramentas incluem ambientes da programação de software. o que fornece maior rapidez no desenvolvimento. Cloud Computing suporta orientação a serviços. distribuição e consumo de serviços. Nesse sentido. desde Data Centers e demais recursos de rede. 46 . explora adequadamente o estilo em camadas. possui todas as ferramentas que irão gerar os serviços da nuvem. e outras.

com compartilhando objetos. 2010). 3. é a Multitenant ou multiinquilino. uma das maiores plataformas de desenvolvimento na Computação nas Nuvens. 2010). (TSAI et al. A arquitetura disponibiliza as funções da Force. elas contam com o auxílio de recursos. na próxima seção. dos dados e da instância física de armazenamento. Portanto. 2010). a Visualforce (WEISSMAN. a cada desenvolvedor. Nela. pois este é um conceito que visa desenvolver e manter aplicações para WEB 3. 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. 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.com. a preocupação em montar o fluxo de sua aplicação com as regras de negócio. Nesta camada ainda existe a utilização da linguagem de codificação de interface gráfica. 2011) e consequentemente está repleto de tecnologias que materializam o conceito de Máquinas Sociais. Para isto. propiciando assim. ARQUITETURA MULTITENANT DE REFERÊNCIA PARA SOFTWARE AS A SERVICE – QP2 A arquitetura homologada para as aplicações da Force. 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.4. uma arquitetura dedicada a essas tecnologias será exposta. Essa prevê o compartilhamento da unidade interna computacional.Capítulo 3. tão-somente. aproveitando o ensejo de que ela surgiu por meio de uma das questões de pesquisa. 47 . cada camada desenvolve uma função bem definida. Na Figura 9 se ilustra a Multitenant. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Nas pesquisas de Máquinas Sociais é sempre válido explorar Cloud Computing.0.3.

onde cada camada possui uma responsabilidade bem definida tratando de aspectos essenciais a uma aplicação.com’s Internet Application Development Platform O estilo Camadas é fundamental para a Multitenant. A especificação da arquitetura Multitenant é bem clara. ou inquilino. 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. 2010). A última camada funcional chamada “Database Pool” é responsável por criar registros únicos nos bancos de dados. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Figura 9.Capítulo 3. são utilizados balanceadores de cargas que distribuem os acessos (BEZEMER e ZAIDMAN. Quanto as demais camadas. Neste sentido. como o 48 . 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. pois como as aplicações são compartilhadas. para melhorar o desempenho da arquitetura. o objetivo é garantir que um determinado usuário acesse apenas os seus dados. a “Authentication” faz apenas o acesso do usuário. existe a necessidade de consultas e inserções individuais nas bases de dados para cada inquilino. Esboço da arquitetura Multitenant Fonte: The Force.com Multitenant Architecture Understanding the Design of Salesforce. 2010).

Ela oferece. conquistou a cifra de 105 (cento e cinco) milhões de usuários. e que fosse mais específica quanto a este tratamento. A seguir. entre outros. 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. A mesma arquitetura de referência é explorada tanto pelo microblog Twitter quanto pela poderosa rede Facebook. exploremos uma breve sinopse sobre cada rede. O Twitter iniciará a seção. além de ser um microblog ele é uma rede social propriamente dita e ainda uma ferramenta de Broadcast. explorando tecnologias diferentes. Entretanto. O Twitter pode ser acessado via dispositivos móveis. A rede em abril do ano de 2010. é possível criar novas aplicações utilizando-se apenas a Internet (APIWIKI.4. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais cuidado com os dados e bases de dados. 2009). 2010). essa arquitetura ostenta “formatos” diferenciados que dependem das características e não apenas dos requisitos de cada rede.4. Tal característica as transformam em Máquinas Socias. Muitos pontos em relação aos dados são delicados. algo que compõem muitas das exigências de alguns clientes. 49 . Abaixo. são abordagens diferentes da mesma arquitetura. Com elas. Outra característica importante do Twitter é a sua API. ARQUITETURA PARA REDES SOCIAIS – QP3 As arquiteturas investigadas para esse tipo de SM são baseadas no estilo Camadas. a busca de serviços que possam ser indexados em aplicações terceiras (AFRAM. com as respectivas tecnologias adotadas e sua arquitetura. Atualmente o micro-blog possui integração com outras redes sociais. foi incorporado um mecanismo de busca ao micro-blog. segundo seu cofundador Biz Stones. 3. delineamos algumas características importantes dessa rede. Vale salientar que as redes sociais exploradas nessa seção são plataformas programáveis. No ano de 2008. e exigem que a arquitetura trabalhe melhor o isolamento.Capítulo 3. Em relação a este aspecto cabe uma crítica. Diante disto. A arquitetura do micro-blog é ilustrada na Figura 10. No entanto. seria interessante que a arquitetura Multitenant ofertasse uma camada que abstraísse o tratamento dos dados. O Twitter foi aberto ao público em meados do ano de 2006.

os chamados NoSQL.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.facebook. 2010. trabalhada por meio das linguagens C. Java e Scala. 2009). a camada realiza ainda renderização e caching.json. como exemplo desses bancos encontra-se o Cassandra26 e o Hbase. nesta questão somente as visualizações das fotos podem ultrapassar o montante de 3 (três) milhões27. pois o Facebook trabalha com recursos de mídia mais complexos. uma camada dedicada à comunicação. algumas tecnologias são empregadas como: Json24 e Rails25. Por último encontra-se a camada de dados suportada por bancos de dados não relacionais. que oferecem resiliência e escalabilidade (LAI. 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. 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. Rails já gera as aplicações no estilo camadas. Figura 10. Informações em: http://www. Arquitetura do Twitter A arquitetura do Facebook contém uma camada a mais em relação ao Twitter.pro.com/.org/. Seu objetivo é aumentar a velocidade e a facilidade de desenvolvimento dos sites. Logo abaixo está a camada de negócio. 25 Rails é também chamado de Ruby on Rails ou apenas RoR ele é um framework de código aberto escrito na linguagem Ruby. 50 . Disponível em: http://developers. como fotos e vídeos.Capítulo 3. 2009) 27 Disponível em: Facebook Developers.rubyonrails. Acesso em: 23 de set. Em seguida examinaremos a arquitetura do Facebook. esta última favorece a escalabilidade em relação ao crescimento do número de seguidores.

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

3. 2003). Tais dados são obtidos por meio de operações em sensores.4. o sistema funcione corretamente satisfazendo a necessidade do usuário (IBM. Auto-otimização: ajuste automático dos parâmetros de recurso para otimizar a utilização dos mesmos. define como principais propriedades de um sistema autônomo: 1. em especial. 2003). Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais apesar de ser relevante para este estudo. ainda. memórias. Ademais. 4. seus provedores e consumidores de serviço (IBM. 52 . volume de dados e também vulnerabilidade (STERRITT e BUSTARD. Autoproteção: capacidade de se auto defender de ataques ou invasões maliciosas.5.Capítulo 3. deixa uma lacuna sobre a consolidação de uma modelo arquitetural para estes tipos de SM’s. 2006). de modo que. assim. 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. ele tem a capacidade de adaptar-se aos padrões esperados e especificados. Autocura: propriedade do sistema que assegura sua recuperação automática após a ocorrência de uma falha. 3. o mesmo deve manter relacionamento com outros elementos. 2. a obtenção de dados sobre o estado dos recursos. E. desta maneira. como:  Request-Response: operações que são de solicitação ou resposta de sobre o estado de um elemento. Esses relacionamentos irão possibilitar que os sistemas autônomos conheçam o estado uns dos outros e o seu próprio estado. facilitando. Autoconfiguração: ajustar a configuração do sistema conforme as variações do ambiente. Segundo Paul Horn (2001) um sistema só é autônomo se ele for flexível para se adaptar às mudanças do ambiente. um sistema desta categoria é formado pela colaboração de elementos autogerenciáveis. definindo as características de um sistema autônomo.

Arquitetura Autônoma Proposta por Mccann. e também por White et al. e como manter a qualidade dos seus serviços mesmo sobre condições adversas (MCCANN. de sorte que podem ser utilizados em sistemas de computação em grade ou computação ubíqua (IBM. e HUEBSCHER.5. ou seja. sistemas especialistas e sistemas baseados em conhecimento.. A seguir uma das arquiteturas de referência proposta para esses sistemas autônomos será explorada. As explicações sobre esta arquitetura foram baseadas nos trabalhos destes estudiosos. e Huebscher em 2004.Capítulo 3. 53 . estes irão comparar os dados capturados às variáveis especificadas para o sistema. sobretudo no aspecto dos relacionamentos. as condições que ele poderá ser submetido. 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. 3. tolerância à falha e outros. é necessário (IBM. 2003). A arquitetura foi proposta por Mccann. É deste modo que um sistema autônomo consegue se auto gerenciar e tomar decisões. Para esta comunicação. O sistema deve saber qual o seu nível aceitável de funcionamento. 2004). 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. Nota-se aqui que sistemas autônomos também estão fortemente relacionados a inteligência artificial. 2003):  Solicit-Response: é a requisição de informações do sistema para sua unidade de controle. aos requisitos desejados em desempenho.1. Essas sondas ou sensores captam informações do ambiente externo e repassam para outros tipos de sensores. nota-se que eles são Máquinas Socias legítimas.4. em 2004. Conforme explicado em relação aos sistemas autônomos. Esses relacionamentos entre sistemas são fundamentais para o próprio aprendizado da máquina.

pois esse modelo de sistema tem como forte característica a distribuição. Isto se revela como uma crítica positiva a esta arquitetura. Isso possibilita que sistemas desse tipo possam ter sua arquitetura composta por diversos estilos arquiteturais. chamado de gerenciador ou calibrador. Esse calibrador deve interagir diretamente com a camada de negócio do sistema. requisitos e limitações do sistema. 2003) 54 . faz uso das informações analisadas para controlar e adaptar a operação do sistema.Capítulo 3. o elemento responsável pelo controle do sistema. compor esta camada. dependendo do tipo. onde cada camada pode ter sua própria arquitetura autônoma. como observado na Figura 11. a segunda parte é composta pelas partes relacionadas a lógica de negócio e ao acesso a dados. 29 Arquitetura distribuída onde cada par. Esboço de arquitetura para sistemas autônomos Após a captura e análise dos parâmetros. e BUSTARD. ou ainda. possui uma função distinta (STERRITT. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais Figura 11. O estilo arquitetural Peer-to-peer29 geralmente é uma excelente escolha para a segunda parte da arquitetura de um sistema autônomo. ou nodo. Tal característica é forte porque comumente todos os elementos da arquitetura do sistema são também autônomos. A arquitetura de um sistema autônomo deve ser dividida. Enquanto a primeira parte comporta os sensores e calibradores. a fim de atingir o comportamento desejado.

Esta interpretação não é definitiva. Arquitetura de referência proposta pela empresa IBM para computação autônoma Fonte: IBM. nem ao menos existiram suposições a respeito disto. deve descrever como compor as propriedades de autogestão do sistema. ele não é o único. Não obstante ao modelo apresentado.2. 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. 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. 2003). Primeiramente. a própria arquitetura não foi exibida desta maneira.4. Existem outras abordagens. Em segundo plano. Uma arquitetura assegura a infraestrutura que permite o monitoramento e análise dos componentes.5. enquanto a outra é a própria arquitetura do sistema que garante o correto funcionamento dos requisitos. 2003 55 . 3. inclusive defendidas por grandes empresas como a IBM (IBM. Finalmente.Capítulo 3. o que pode se revelar como um fator negativo na especificação desta arquitetura. A arquitetura IBM é explicada em seguida: Figura 12. deve descrever como compor esses componentes para que eles possam cooperar para as metas de todo o sistema. Ambas estão entrelaçadas. deve descrever as interfaces externas e comportamentos necessários de componentes do sistema.

respectivamente. (2009). classifica a arquitetura como sendo de referência para computação autônoma em si. Em todo o trabalho publicado no ano de 2003. a diferença entre os conceitos de sistema e computação sejam muito sutis. apesar de afirmar que a mesma pode ser aplicada aos sistemas autônomos.0 – QP5 O livro Web 2. e entre estes sistemas e outros.Capítulo 3. autocura. A camada acima desta. 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. bem como.4. e ambos abordam as premissas da autogestão. mesmo que em alto nível. os sistemas se prevalecem dos conceitos da computação. por ser uma arquitetura de referência. seria interessante expor a arquitetura neste trabalho. A camada mais superior fornece interfaces de comunicação entre os usuários e o sistemas.0 Architectures de James Governor. as funções. Essa camada oferece a capacidade autônoma ao sistema. A explicação desta arquitetura não será rica em detalhes. incorporando maior controle sobre a infra-estrutura geral de TI.0 nestas estariam aplicações 56 . a adoção de Enterprise Service Bus . ela não demonstrou como o objetivo de cada camada pode ser alcançado.ESB para servir de barramento de integração entre as camadas da arquitetura. de conter recursos físicos de infraestrutura de TI ou mesmo softwares de gestão. Contudo. Cabe uma singela crítica a esta arquitetura. uma vez que. sugere uma arquitetura de referência para aplicações originais da WEB 2. a auto configurável.otimização e autoproteção). 3. contém gestores autônomos que orquestram outros gestores de cada categoria. pois a IBM. Contudo a IBM deixou evidente em sua proposta. e prover interfaces de gerenciamento para controlar os recursos gerenciados. A terceira camada chamada Touchpoint Autonomic Managers contém gerentes autônomos de quatro categorias de autogestão. a arquitetura apenas elegeu o uso de Web Services para viabilizar a comunicação entre as interfaces de comunicação. Essas interfaces padrão são entregues através de um terminal de gerenciamento.6. 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. auto. facilitando a integração dos mesmos. ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2. et al.

Esta camada pode ter subdivisões que a tornam capaz de fazer a persistência de banco de dados. diretórios. ano 2009 Os componentes desta arquitetura possuem a seguinte definição:  Resource Tier – É a base.   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.  Client Application Tier – É a camada em que o usuário acessa para consumir os serviços da aplicação. Arquitetura de referência para aplicações WEB 2. Nesta camada residem os banco de dados. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais como Mashups e alguns tipos de redes sociais como o Flickr30. Figura 13. 30 Rede de compartilhamento de fotos.flickr . Disponível em: www. Conectivity (setas entre as camadas centrais) – Podem ser protocolos e padrões que permitem o acesso aos serviços.0 Architectures.Capítulo 3. e outros.0 Fonte: Adaptada de James Governor. livro: Web 2. nesta camada podem residir ferramentas que melhorem a interaçao do usuário com a aplicação. ou infraestrutura que armazena todos os recursos que capacitam os serviços da aplicação. interfaces com sistemas.com 57 . A arquitetura proposta é ilustrada na próxima imagem. Tais conexões devem exibir os serviços deixando clara a responsabilidade de cada um.

Tal modelo é útil por mostrar o objetivo de uma arquitetura de referência dedicada a Web. uma substituta que só ocorreu devido ao novo paradigma de Máquinas Sociais. As ferramentas podem ser ainda utilizadas no desenvolvimento dos componentes das camadas de serviço e cliente. para este trabalho de mestrado. Esta camada é interessante para customizar outras camadas e assim expandir e modificar as arquiteturas de aplicações que usem esta arquitetura de referência. Máquinas Sociais. como os Mashups. ou padrão. Neste caso. Não verificou-se nenhuma evolução significativa nem mesmo outras abordagens que refutassem esta proposta. Durante a pesquisa. Supondo que seja necessário construir uma aplicação Web 2. and Governance Tools – Esta camada é de suporte ao desenvolvimento.0. pode vir a ser uma substituta moderna da arquitetura Web 2. como: framework e Web services. Fica nítido que a arquitetura é bem genérica. a heterogeneidade excessiva de tecnologias agregue potencialmente retrabalho ao desenvolvimento. em que algumas dessas aplicações. Development. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais  Design. pois contém um conjunto de ferramentas que auxilia os desenvolvedores. e assim. são também da Web 3. Esta arquitetura de referência é interessante por ofertar uma divisão inteligente das responsabilidades de cada camada. ficando sucetível à implantação de tecnologias diversas.0.Capítulo 3. haja vista. para auxiliar na responsabilidade das camadas. 58 . Tal camada irá definir protocolos de acesso aos serviços e esses protocolos são os elementos arquiteturais Conectivity. O seguinte exercício pode auxiliar em uma maior compreensão. Essa arquitetura é um modelo para aplicações da segunda geração da Internet. seria necessáiro contruir uma interface na camada Resource Tier. todas as arquiteturas de referência para a Web que se sucederam foram estudos replicados deste. fica evidente que a proposta de arquitetura a ser sugerida no próximo capítulo. Além deste ponto de heterogeneidade a arquitetura nem ao menos sugeriu alguma tecnologia. Entretanto. se a aplicação em questão necessitar ter usa própria API a camada Service Tier será a responsável. Vale lembrar que essa capacidade de implantação de tecnologias diversas foi classificada como um problema nesta pesquisa.0 que possa fazer conexão com alguma API de outra aplicação. Com isto. que traduzem de outra forma as aplicações Web e a própria web.

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

Materiais publicados e investigados para esta pesquisa revelam que algumas das Máquinas Sociais exploradas se mantiveram eficientes. Segundo publicação da própria Amazon. Como. 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. GARLAN. Alguns autores defendem a adoção do estilo arquitetural Camadas. visto que as camadas solicitam serviços uma das outras. Todos estes fatores estão ligados as características das SM’s. o que será relatado a seguir. as ferramentas online para desenvolvimento de Mashups. Módulos são entidades que implementam um conjunto de funcionalidades para o sistema (SHAW. pois as soluções que se repetiram ao longo dos estudos foram empregadas em grandes projetos dentro da indústria de software. uma visão de módulos31 essencial para a documentação do sistema. por exemplo. por exemplo. proteção contra falhas. 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. como exemplo. as soluções mapeadas contribuem. As tendências pontuadas acima dão indícios que podem auxiliar no desenvolvimento de SM’s. Revisão da Literatura de Arquiteturas de Software Para Máquinas Sociais estilo cliente servidor. 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. et al 2000). distribuição e comunicação. 1996) 60 . interagindo entre elas como cliente e servido (GAMMA. alguns gigabytes de dados foram perdidos. Outro ponto questionável é a falta de mecanismos que previnam a interrupção de alguns serviços Cloud Computing.Capítulo 3. 31 Perspectiva que mapeia os módulos do sistema. considera que o estilo em camadas organiza a arquitetura do sistema por separar a parte funcional da parte de apresentação. o problema da Amazon (IaaS) no ano de 2011. enquanto outros fatores provocam controvérsias na aplicação das arquiteturas estudadas. a priori. No modelo Camadas ocorre forte dependência entre as camadas. Além deste ponto. Christine Hofmeister (2000). proporcionando assim. 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. para a escalabilidade. enquanto outras simplesmente saíram do mercado.

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

Além do problema acima relatado. Como será visto no próximo capítulo.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. Computing_Kossmann et al.0 Arquitetura Multitenant Computing_IBM.Capítulo 3. todos os pontos relevantes que foram tratados. é importante deixar claro quais os requisitos atendidos por ela. na exibição de uma arquitetura. Os pontos são importantes para as SM’s e ofertarão subsidio para a formulação da arquitetura de referência. isto é fundamental para criação da arquitetura. Pontos ou aspectos mais trabalhados pelas arquiteturas Arquitetura para Web 2. ou não. Arquitetura Mashup_Merril Computing_Vecchiola 2009 Huebscher. Aurin) 2006 2009 62 . para as Máquinas Sociais. Para finalizar este capítulo. 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. é possível notar que o atendimento as necessidades materializa os requisitos mais tratados pelas arquiteturas. Com a tabela. São eles: performance por meio da expansão da arquitetura e modificabilidade por meio da manutenção. 2011 Autônomos_Mccann. Arquitetura Sistemas Arquitetura Cloud Arquitetura Cloud 2010 Arquitetura Cloud (Hoof . Isto não foi verificado para os estudos mapeados neste capítulo. 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. pelas arquiteturas. a tabela 3 sumariza. por serem informações que influenciarão nas decisões de projeto da mesma. White et al. Com isto.

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

Trata-se de um modelo experimental que deve servir de precedente aos exemplares de arquiteturas de SM’s. 4. ou ainda Software as a Service. o trabalho é focado em sistemas WEB. foi possível entender a organização e concepção das mesmas. além ter um estudo de referência para SM’s. Tratando-se de uma pesquisa que envolve fortemente arquitetura de software. com isto.2. e deve ser entendida como o arcabouço básico que será customizado conforme os requisitos da Máquina Social. 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. Para se construir uma arquitetura de SM é necessário entender o software como uma Máquina Social. Proposta de Arquitetura de Referência Para Máquinas Sociais 4. Ou seja. Através desde estudo é possível dispor de um protótipo de arquitetura de referência para Máquinas Sociais.Capítulo 4. cabe aqui esclarecer melhor alguns pontos. essa arquitetura seria um exemplo de como deve ser a arquitetura de uma SM. principalmente os relacionados a arquitetura de referência. a formulação de uma arquitetura padrão para essas SM’s demandaria um tempo de pesquisa consideravelmente maior. 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. assim. as SM’s podem ser classificadas desde aplicações Web simples até frameworks e IaaS. Apesar de tais aplicações não deixarem evidente todas as particularidades e detalhes de suas arquiteturas. e assim poder agir assertivamente sobre as análises e decisões de projeto e consequentemente sobre a arquitetura. 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. Como visto no capítulo 2. demonstrando 64 . 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. Vale frisar que tal modelo é mais adequado às SM’s que são aplicações WEB.1. 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.

2003). 2ed. A arquitetura de referência facilitará o desenvolvimento modular do software que for projetado acima dela. aumento do reuso de software. é 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. que apresentam soluções técnicas às arquiteturas de uma família de software (MULLER. tanto as Interfaces Providas. Modelo de Referência Padrão ou Estilo Arquitetural Arquitetura de Referência Arquitetura de Software Figura 14. 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. Uma arquitetura de referência se origina de um ou mais padrões arquiteturais. que disponibilizam serviços. 2003. Relação entre modelo de referência. Esse desenvolvimento traz benefícios. Addison Wesley. 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. auxílio para a equipe de desenvolvimento evitar erros já cometidos. 1994). ou seja. a quem o módulo precisa se conectar (GARLAN e SHAW. Modelos de referência são soluções a nível de negócio que tratam de problemas de um mesmo domínio.Capítulo 4. arquiteturas de referência sugerem a implementação de módulos que tenham interfaces bem definidas. como as Interfaces Requeridas. 2009). 65 . Por fim. CLEMENTS. e de um modelo de referência32. que expõem as necessidades dos serviços. como: redução do tempo de desenvolvimento. 2011). 1993]. Para se compor uma arquitetura de referência é necessário trabalhar veementemente no processo de formação com os requisitos não funcionais (qualidade). auxiliando assim na resolução de um problema (GOVERNOR. padrões arquiteturais e arquitetura de referência Fonte: Adaptação do livro Software Architecture in Practice. pois já é um modelo que pode ser adaptado para a arquitetura. e KAZMAN. Seguindo tais conceitos atingiram-se as arquiteturas de referência. Proposta de Arquitetura de Referência Para Máquinas Sociais como pode ocorrer a cooperação entre elas (BASS. A Figura 14 esquematiza esse raciocínio. Por fim.

S. A tarefa de identificação dos clientes. conceitos. contribui fortemente para a identificação das fontes de informação (clientes) e para o amadurecimentos do Modelo de Referência. 4.Capítulo 4. 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. isto possibilita uma visão mais objetiva das soluções que podem ser empregadas para o domínio. ferramentas e profissionais.3. pois se trata de uma arquitetura muita genérica. 66 . para extração de requisitos. 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. Proposta de Arquitetura de Referência Para Máquinas Sociais de uma arquitetura de referência é necessário considerar fatores tecnológicos. Arquiteturas de referência são instanciadas em um projeto de software. Enquanto isto todos os estudos feitos pela Universidade Federal de Pernambuco e por organizações como o C.R (Centro de Estudos Avançados do Recife) que resultaram na criação de um grupo direcionado ao estudo de SM’s. das mesmas para a solução do problema. 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. Ambos foram referência para este capítulo. ou não. 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. é a mais crítica. e KAZMAN. 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. 2003). 2003) a ser desenvolvido. e KAZMAN. CLEMENTS. e podem existir ou serem utilizadas em diferentes níveis de abstração a partir de diversas perspectivas (BASS.A. Em uma análise dessas arquiteturas é possível detectar a eficiência.E. como: documentos. requisitos de clientes. haja vista que a extração dos conhecimentos exija fontes mais abrangentes. pesquisas. CLEMENTS. padrões e abordagens de desenvolvimento de software.

e interoperabilidade. Outra compreensão correta. Proposta de Arquitetura de Referência Para Máquinas Sociais A arquitetura de referência deve trabalhar bem os requisitos performance. Colaboração e Comunicação facilitada 1ª Redundância: caso um elemento fique indisponível. 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. disponibilidade. 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. 3ª Trabalhar bem com a infraestrutura conectividade. existem outras que podem ser trabalhadas conforme a característica da requisição. a redundância (outro elemento igual) deve ocupar o seu lugar. Assim. Requisitos Características e Necessidades das SM’s Solução de Atendimento Performance Reatividade. expansão e Serviços 1ª Controle sobre a geração de eventos. Infraestrutura. o que na realidade não ocorreu em todas as arquiteturas mapeadas no estudo do capítulo anterior. A mesma tabela contribui para a compreensão de como os requisitos podem ser satisfeitos pela arquitetura. Serviços. e com a de Disponibilidade Constância. Sociabilidade. 2ª Diminuir os elementos intermediários comunicação. é a de que as soluções propostas para atender os requisitos na arquitetura não são únicas. Infraestrutura. Autonomia. nem todas as arquiteturas trataram as necessidades e requisitos fundamentais da Máquina Social. Reatividade. modificabilidade. 2ª Mecanismos que verifiquem e alertem sobre 67 . Apenas os requisitos performance e modificabilidade foram mais trabalhados.Capítulo 4. A tabela 4 pretende evidenciar as características e necessidades das SM’s e como estas estão relacionadas aos requisitos não funcionais.

Manutenção facilitada.Capítulo 4. Modificabilidade Sociabilidade. Infraestrutura. e Autonomia 1ª Elementos arquiteturais33 que facilitem a manutenção da SM. 4ª Isolar funcionalidades que possam alteradas. 5ª Inserir elementos ser facilmente do elemento intermediários que diminuam a dependência. é importante dar foco as outras questões arquiteturais como o estilo arquitetural. Seus pontos serão explicados em seguida. Após visualizar e entender ainda mais a questão dos requisitos não funcionais. O estilo arquitetural a ser adotado é o estilo em Camadas. À vista disso a arquitetura de referência para Máquinas Socias está ilustrada na Figura 15. 68 . o que poderia ser esperado. Tabela 4. Atendimento aos requisitos pela arquitetura conforme as características e necessidades da SM. 2ª Separar responsabilidades em camadas. 33 Casos de uso. Interoperabilidade Colaboração. Proposta de Arquitetura de Referência Para Máquinas Sociais possíveis falhas. camadas e demais componentes que constituem as visões arquiteturais. bem como demais visões da mesma. pois tal estilo é extensamente utilizado para desenvolver aplicações Web. o mesmo que foi a grande tendência do estudo mapeado. 3ª Manter a coerência semântica para facilitar a identificação arquitetural. 2ª Trabalhar com padrões de interoperabilidade. 1ª Identificar e trabalhar com as interfaces providas e requeridas. Sociabilidade e Conectividade. classes.

Com os requisitos relevantes a nível arquitetural. como: portabilidade. e com suas responsabilidades bem definidas. mostrando a dependência entre tais unidades. 1995). além disto. ou seja. organizados. é possível representar a arquitetura da Máquina Social em tempo de desenvolvimento. A Figura 15 exposta abaixo retrata a arquitetura por uma visão de módulos. 2000) que recomenda a especificação da arquitetura ou os documentos arquiteturais:    Com os elementos arquiteturais identificados. O objetivo desta visão é expor a Máquina Social em unidades. Com a representação de diferentes visões arquiteturais. Figura 15.Capítulo 4. exibindo as camadas e suas interações. 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. Por meio da visão é possível exibir mais facilmente o tratamento a alguns requisitos. de módulos a serem realmente estruturados e alinhados (KRUCHTEN. Arquitetura de Referência para SM’s 69 . reuso e interoperabilidade. atendidos pela arquitetura definida.

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

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

Proposta de Arquitetura de Referência Para Máquinas Sociais estejam sincronizados. o que dará a visibilidade de que uma Máquina Social é composta por outras Máquinas Sociais. a visão de implantação será ilustrada. sendo que. e os recursos de replicação. ser utilizado para outras camadas arquiteturais. inclusive. Essas SM’s interagem umas com as outras executando funções diferentes e assim se completando (GORTON. 1995). 2009). 72 . 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. 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. é possível avaliar ainda os requisitos não funcionais de desempenho e disponibilidade (KRUTCHEN. Ela dividirá a arquitetura em nós processadores e componentes executáveis.Capítulo 4. VISÕES DA ARQUITETURA DE REFERÊNCIA Após descrever a arquitetura. os custos.4. esta não teria preocupação com a manutenção ou preparação de máquinas servidoras (ZHANG e ZHOU. e principalmente sua taxonomia. devem-se analisar as necessidades da SM. 2006). A decisão por obter um serviço Cloud Computing é algo muito particular de cada aplicação. a segurança. 4. 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. Por meio dela. Em um projeto de Máquina Social os serviços de Cloud Computing podem ser muito úteis à equipe de desenvolvimento. O artifício de possuir réplicas pode. Por meio desta visão.

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

Nota-se que um terceiro componente do Processing Unit (Controllers/Services) não está presente na visão. Uma classe abstrata age como uma interface mais robusta. 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. o padrão de projeto Facade deve ser incorporado. Para otimizar o acoplamento baixo. 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. Essa redução é importante para possibilitar o atendimento ao requisito de modificabilidade. Sua exclusão foi proposital.Capítulo 4. A inserção de mecanismos contra o acoplamento alto não prejudicará o relacionamento dos subsistemas. pois a classe 74 . dentro de cada existem as classes que a compõem. 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. Proposta de Arquitetura de Referência Para Máquinas Sociais Figura 17. Nesta visão. pois o mesmo é especialista em unificar interface facilitando o acesso aos subsistemas e independência entre as classes. 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.

a priori. pois esses elementos 75 . JACOBSON. 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. A Figura 18 ilustra esta visão de componentes e conectores. A Wrapper é a interface da SM que exibe todos os serviços providos e requeridos pela mesma. será ilustrado. ele se faz necessário (LARMAN. com isto o acoplamento existirá. pelas classes Constraints e States. para a camada Wrapper. esse é o caso entre Constraints e States. um diagrama de componentes com portas e interfaces. Apesar de o acoplamento ser ruim à qualidade de qualquer sistema. é 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. RUMBAUGN. 2005) bem como os serviços que cada componente pode prover ou requerer para a SM’s. 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. mais será fraco. Nele. Neste ponto. sendo que uma exerce controle sobre o comportamento da outra. é possível verificar a colaboração entre os componentes ou classes. e que satisfaça o requisito interoperabilidade. (BOOCH. O segundo subsistema é composto. O componente intermediário é representado na visão seguinte com o nome: Social APIMiddleware Machine.Capítulo 4. Após obter os dados da Máquina Social e determinar a situação dos serviços. assim. Através desta visão. existe um acoplamento de controle entre essas duas classes. Para enteder melhor o diagrama de classe e a relação entre estes dois subsistemas. é necessário um componente que leia o estado da Máquina Social disponível pelo componente State na camada de Processing Unit. Neste aspecto. a classe States depende da classe Constraints para alterar a situação dos serviços da Máquina Social. 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. É necessário ter cuidado na adoção desses elementos intermediários que façam a comunicação entre os demais elementos arquiteturais. neste caso. a Wrapper pode ser visualizada como um conjunto de rotinas que pode evidenciar a utilização das funcionalidades da SM’s. 2007) pelos objetos necessitarem interagir com outros objetos e na troca de mensagem. Para possibilitar o trabalho da Wrapper é necessário que a mesma esteja sempre ciente do estado dos serviços da SM. e em muitos outros.

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. Diagrama de Componentes: Visão de Componentes e Conectores Tratando-se de visões arquiteturais. 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. os elementos States e Constraints. Os elementos States e Constraints serão abordados por meio de uma visão que exalta o tempo de execução da SM. as mesmas podem detalhar algum elemento específico da arquitetura (KRUCHTEN. Figura 18. 76 . É 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). tais elementos devem interagir de forma facilitada. Como já exposto eles são responsáveis pelo monitoramento e pelos requisitos não funcionais da Máquina Social.Capítulo 4. respectivamente. pois que. por intermédio de um diagrama de sequência. 2010). Essa visão é capaz de representar a arquitetura em tempo de execução. informações geradas por um interferem no funcionamento do outro.

Entretanto. A arquitetura de referência é apenas um modelo. o requisitante. se é possível ainda dar o tipo de acesso que é requerido. são detalhes mais específicos de cada Máquina Social a ser desenvolvida. Proposta de Arquitetura de Referência Para Máquinas Sociais Figura 19. o elemento State deve enviar uma mensagem que avalie se o acesso do requisitante é permitido. 77 . A interpretação acima é baseada em um exemplo simples de funcionamento dos elementos citados. uma variação do estilo Camadas.Capítulo 4. já com livre acesso. ou seja. Por fim. por sua vez. O importante é adotar as camadas e os componentes que as compõem bem como o estilo arquitetural que é o Relaxed Layered System. permite o acesso ao tipo de transação que o requerente desejar. O funcionamento ilustrado pelo diagrama de sequência pode ser implementado de outra forma. que deve se originado por algum componente que implementa as regras de negócios e funcionalidades da Máquina Social. como já explicado. envia dados para algum tipo de transação e aguarda o seu retorno. Um requisitante exige um acesso. a seguinte interpretação deve ser obtida. É evidente que outros detalhes sejam pertinentes a esta arquitetura. o importante é manter a comunicação entre os elementos do diagrama. o elemento Constraints avalia a permissão de acesso e retorna ao elemento anterior que. Diagrama de sequência: Visão em tempo de execução O diagrama de sequência na figura 19.

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. 78 . entre eles: Architecture Tradeoff Analysis Method . estes métodos basicamente avaliam se a arquitetura proposta contempla os requisitos não funcionais.5. 2006). Como já exposto. As abordagens citadas como exemplo de avaliação arquitetural possuem limitações quanto ao emprego das mesmas na arquitetura proposta neste trabalho. 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. avaliar atributos mais específicos para este caso é um tarefa inviável. 2000). existem outras que também poderiam afetar uma avaliação prática e correta da arquitetura de referência pelos métodos citados acima.ATAM e Software Architecture Analysis Method . ou seja. exigidos para o software (KAZMAN et al. 2003). Deste modo. Assim. O que deve ser avaliado são as representações arquiteturais. A partir dos dados extraídos de tais avaliações.Capítulo 4.SAAM. existem vários métodos. Além da limitação citada. 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. ou de qualidade. cabe nesta pesquisa. este tipo de arquitetura é muito genérica e representa todo um domínio de software. 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. Para avaliar uma arquitetura. As limitações são reais devido a arquitetura proposta ser uma arquitetura de referência (NAKAGAWA. as visões arquiteturais que são oriundas da arquitetura de referência e a própria arquitetura. 4. 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. avaliar a arquitetura proposta para que a adoção da mesma possa ser viabilizada com mais segurança.

Com isto. Segundo os autores citados. 4.  O Checklist é formado por itens de questionamento que podem ser personalizados conforme a arquitetura documentada. 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. Deste modo. de modo que seja necessário construir uma situação na qual a arquitetura será submetida. a técnica de inspeção a ser utilizada será o Checklist. várias características podem ser avaliadas e não somente as referenciadas em cenários. nem tão pouco a elaboração de cenários de qualidade. 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. Para este trabalho. 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. neste cenário a arquitetura deve se manter estável possibilitando o software a executar sua funcionalidade.Capítulo 4. Técnicas de inspeção de software são métodos rigorosos para se avaliar um artefato de software (BOEHM e BASILI. a avaliação é de baixo custo e menos subjetiva por não depender de cenários.1. 2002). será aplicada neste estudo a técnica de inspeção sobre os documentos ou visões arquiteturais. 2001). 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. 79 . e nos trabalhos de Laitenberger e DeBaund (1998).5. Proposta de Arquitetura de Referência Para Máquinas Sociais  ATAM e SAAM avaliam cenários específicos para a arquitetura. Levando em consideração as limitações abordadas.

É 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.1. Taxonomia dos Defeitos a Serem Encontrados As abordagens avaliativas baseadas em Checklist visam identificar defeitos. 4.2. arquitetos de software e estudantes de mestrado em ciências da computação. Defeitos por inconsistência: quando o mesmo elemento arquitetural é representado com nomes diferentes em visões distintas. 2002).5. 80 . 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.   Defeitos por fato incorreto: ocorre quando um elemento arquitetural não é descrito de forma correta. Perfil dos Avaliadores (inspetores) Serão quatro avaliadores: um professor.5. Ou quando o mesmo elemento arquitetural tem responsabilidades distintas em uma ou mais visões.1. os defeitos devem ser identificados nos documentos arquiteturais. Existirá ainda.1. 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 informação estranha: defeito acometido quando não se consegue entender a atribuição ou responsabilidade do elemento arquitetural. o autor dos documentos de visão arquitetural.Capítulo 4. para intermediar tal inspeção. Para este trabalho. 2004) (TRAVASSOS. 4.

5.5.3. Após correção. 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. 4.Capítulo 4. o Distribuir os documentos necessários à avaliação (documento arquitetural e Checklist). 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. neste ponto as atividades de planejamento e configuração do processo de avaliação podem ser postergadas. 81 . o Identificar os avaliadores. 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.  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.4. Proposta de Arquitetura de Referência Para Máquinas Sociais 4. o Inspetores revistam individualmente os artefatos do documento arquitetural a procura de defeitos.1. o Inspetores respondem aos itens de questionamento do Checklist.1. uma nova avaliação deve ser efetuada no documento arquitetural.

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

A tabela 5 ilustra o que cada item do Checklist pretendia investigar e qual a resposta esperada. As duas versões de Checklists utilizadas estão nos apêndices (apêndice A e apêndice B). isolado dos demais? 2 . 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. Sendo assim. Alguns itens avaliaram isto de forma mais direta.Capítulo 4. e principalmente os defeitos por incosistência. em Sim algum diagrama. não há necessidade de explorar todas as visões ou todos os diagramas e classes que são potenciais às SM’s.Para os componentes. representado diferentes diagramas gráficos? 3 . Proposta de Arquitetura de Referência Para Máquinas Sociais estas palavras estavam trazendo muitas respostas negativas na documentação. Pretendia avaliar a depedência e o acoplamento.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. ITENS DE QUESTIONAMENTO RESPOSTA ESPERADA QUESTÕES AVALIADAS 1 . realizados entre classes/subcomponentes alocados em “componentes pais” distintos foi definido como uma 83 . se tratanto de uma arquitetura de referência. foram Defeitos por omissão. relacionamentos.Ao analisar todos os Não diagramas. identificadas as classes ou subcomponentes que o compõem? 4 Os relacionamentos Indiferente RETIRADO DO CHECKLIST. 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.

6 . e se os mesmos foram trabalhados e justificados na arquitetura justificada por um conjunto de requisitos não funcionais ou funcionais? 8 .Os elementos arquiteturais Sim têm a sua presença na Analisar o atendimento aos requisitos funcionais e não funcionais. requeridas e classes/componentes definidas em uma visão modular foram alocadas em ao menos uma das seqüências? 7 . ocorre uma representação por meio de diagrama de classes ou de componentes e conectores com interfaces providas. disponibilizadas por um único componente/classe. 84 . Verificar se os componentes arquiteturais possuíam os mesmos nomes entre as visões.As responsabilidades dos Sim elementos arquiteturais estão condizentes com os requisitos não funcionais que eles arquitetura.Ao analisar as seqüências Sim de execução descritas em uma visão de interação.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. ou representadas de uma forma mais simples não expandida? Ou seja. pode-se dizer que as Analisar a coerência entre as visões. Analisar se a arquitetura atende de forma adequada (propõem soluções adequadas) os requisitos não funcionais.

Questões analisadas pelo Checklist e respostas esperadas Analisar a existência de acoplamento ou dependências. utilizados como mediadores de comunicação entre os elementos arquiteturais. Proposta de Arquitetura de Referência Para Máquinas Sociais atendem? 9 . 10 . inclusive na incompatibilidade entre tais soluções. sobretudo os não funcionais.Capítulo 4. como por exemplo: a soluções para o requisito desempenho ser prejudicial a solução do requisito disponibilidade. Coesão neste caso deve ser entendido como o princípio fundamental da orientação a objetos. mas que possuem o fim de captar não conformidades entre as soluções.Elementos relacionados Não possuem responsabilidades Analisar a coesão da arquitetura. Analisar se existem elementos que podem prejudicar o requisito desempenho. nomes. API’s. 12 . e se as soluções estão corretas e claras. 85 . 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. Desta forma os 3 (três) itens objetivam investigar o tratamento aos requisitos por questões escritas de forma diferente.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. iguais que possam ser alocadas em um único elemento? 11 .Foi verificado algum Indiferente componente controle comportamento elemento? Tabela 5.Elementos intermediários Não como: máquinas de e virtuais. são servidores repositórios Elementos que viabilizam a comunicação entre os componentes arquiteturais podem prejudicar o desempenho.

pois eles obrigavam o avaliador a verificar. e apenas um avaliador respondeu a dois Checklist em momentos diferentes. 86 . desde que ele seja controlado (LARMAN. ademais. Desta quantidade. por exemplo. Resultado da Avaliação (1ª e 2ª rodada) O Checklist foi composto de 12 itens. Se este resultado for mais detalhista. 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. Sendo assim. Foi o pior resultado. BIGONHA e BIGONHA. onde nenhuma foi do tipo “não se aplica”.Capítulo 4. Entretanto. o acoplamento é algo presente em alguns sistemas (FERREIRA. O que contribuiu fortemente para isto foi a escrita dos itens de questionamento. se para todos os componentes foram especificadas as classes. é 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. suas respostas podem ser descartadas para a estatística. tendo em vista que. para a 1ª rodada avaliativa houve 30 (trinta) respostas válidas. Com isto o percentual de 100 (cem) é referente as 50 (cinquenta) respostas que de fato foram calculadas para averiguar a qualidade da arquitetura. 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). 15 (quinze) respostas foram de acordo com o valor esperado. 2007). a quantidade de respostas derivadas dos itens e da quantidade de Checklists oriundos de cada avaliador é 60 (sessenta). 2008) é inclusive recomendado que exista acoplamento. o item 4 (quatro) foi anulado. o que ofertou uma percetual de 50% (cinquenta porcento) de aprovação para a arquitetura. cada avaliador respondeu ao menos uma vez um Checklist. o item 12 (doze) também é um item neutro. Os valores acima são a totalidade das duas rodadas avaliativas. Ou seja. e 15 (quinze) em desacordo.

obtiveram-se os seguintes resultados e melhorias conforme os defeitos encontrados por tipo. Para encontrar este defeito nenhum item de questionamento foi decisivo. com as atribuições de cada um devidamente inseridas. Neste entrecho. Um exemplo deste erro foi encontrado na visão que dividia a arquitetura em camadas. para a 2ª rodada avaliativa houve 20 (vinte) questões respondidas. 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. ou seja. O grande problema dentro desta abordagem é o fato de não se dividir devidamente as responsabilidades.com/sh/sc6bv62petuczdm/ocjs_kklFH. tudo conforme a avaliação negativa dos questionamentos. 87 .dropbox. Proposta de Arquitetura de Referência Para Máquinas Sociais Retirando a quarta e a décima segunda questão. Demais camadas estavam na parte interna das duas grandes camadas. pois na avaliação. Estes quantitativos implicam em um percetual de 80 (oitenta) em aprovação e corretitude da arquitetura. sendo que muitas dessas poderiam se utilizar outras SM’s como apresentação. a necessidad de uma reflexão sobre a real necessidade de uma camada de apresentação em toda SM. ou ainda. foi citado por um dos avaliadores. Algumas camadas ou classes não foram corretamente especificadas. O resultado pode ser visto na Figura 15. poderia se supor que as demais camadas. só poderiam ser inserida nas duas camadas representadas. Este é o percentual válido para este trabalho. após apuração dos itens respondidos e contabilizados para os cálculos.  Defeito por Fato Incorreto: Esses defeitos são referentes aos elementos arquiteturais que foram descritos ou mesmo desenhados de forma errada.Capítulo 4. 3 (três) destas avaliadas como “não se aplica”. apenas uma questão foi respondida como em desacordo com o valor esperado. sendo assim. Nesta representação só havia duas camadas formando a arquitetura. As visões ou diagramas arquiteturais expostos ao decorrer do capítulo foram os avaliados corretamente. alguns foram inseridos enquanto outros foram corrigidos. deste modo. uma classe necessária. a representação em camadas foi refeita. Esses valores pontuados em cada Checklist podem ser verificados no repositório público: https://www.

entre outros. Ao final desta seção é importante reafirmar que todas as visões exibidas neste capitulo foram corrigidas conforme as avaliações. quanto no sentido de 88 . essa arquitetura deve ser expandida. A avaliação foi importante não só para corrigir os artefatos arquiteturais como também para corrigir o próprio processo avaliativo. a avaliação procurou dar ênfase aos mesmos. Essa arquitetura é um modelo que deve ser customizado para cada SM a ser modelada.6. tanto no sentido de melhoria da arquitetura. isto ainda no próprio Checklist. 4. as visões arquiteturais ainda foram em um pequeno número. Em se tratando destes princípios. assim como. os diagramas de componente e de classe foram acrescentados e avaliados positivamente em uma segunda oportunidade. Ou seja. como: inserir uma área para comentários no próprio Checklist. 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. mostra o controle e as estratégias sobre os princípios de acoplamento e coesão. Itens foram refeitos e novas visões foram inseridas neste processo. O maior número de visões retratadas para a arquitetura de referência visa auxiliar no entendimento de tal arquitetura. como se esta fosse um projeto piloto para os itens de questionamento. em que cada item poderia ser melhor explicado.Capítulo 4. CONSIDERAÇÕES FINAIS DO CAPÍTULO Neste capítulo a arquitetura de referência para Máquinas Sociais foi proposta. A avaliação foi um processo que não teve alto valor financeiro e foi extremamente proveitosa. O item de questionamento número 3 foi determinante para a averiguação deste defeito. Mesmo assim. isto para se notar como a mesma era antes de ser especificada como na figura 15. e uma área de ajuda. Sendo assim. Uma versão anterior da avaliação de referência foi inserida no apêndice D. É importante também concluir que o Checklist também foi avaliado na primeira rodada. 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. Os avaliadores ainda puderam interagir com o autor dos artefatos e algumas solicitações foram colocadas.

O próximo capítulo também pretende. inclusive por meio de uma tabela.Capítulo 4. et al 2000). foi a inserção dos poucos elementos mediadores. Isto facilitou a avaliação. fortalecer e facilitar o uso da arquitetura proposta. pois alguns participantes também necessitaram perceber o atendimento aos requisitos de forma mais direta. 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. 89 . se descobre maneiras de alcançar ou implementar as soluções propostas neste arcabouço de referência. Durante a exibição da arquitetura os requisitos a serem atendidos foram bem enfatizados. na verdade existi apenas um elementos. pois que. ao passo que conduz boas decisões de projeto. Outro artifício que possibilitou uma avaliação positiva de mais de 50% (cinquenta porcento) de aprovação e aceitação da arquitetura. o Social APIMiddleware Machine na figura 17. este poderia ser um Middleware o que prejudicaria o requisito desempenho (GAMMA. entre outros objetivos.

as práticas constituirão novos métodos para projetar. 90 . e singularmente. Neste capítulo. 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. conceber SM’s.Capítulo 5 5.

2. Segundo essas literaturas a metodologia. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais 5. Ele irá conceber um padrão para construção de SM’s. INTRODUÇÃO Foi elaborado um conjunto de boas práticas. e KAZMAN. e KAZMAN. essas práticas também devem ajudar na personalização da arquitetura de referência. 4. 2003).Capítulo 5. 2003). 5. Na verdade. Esse padrão. constituirá o conteúdo necessário que facilitará a adequada construção de arquiteturas de SM. Fazer uma listagem de todas as decisões de projeto incluindo as justificativas que influenciaram cada decisão34. uma arquitetura que possibilite o correto funcionamento da aplicação. e SONI. visão de implantação (BASS. 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. Executar os passos acima não assegura a definição de uma arquitetura de qualidade para SM’s. esse conjunto deverá responder algumas questões que são de elevada importância para a customização ou criação de arquiteturas. para se elaborar a arquitetura de um sistema são: 1. com os passos ou atividades. visão de componentes e conectores. David Garlan e Mary Shaw. 91 . Documentar a arquitetura utilizando visões que podem ser: visão de módulo. CLEMENTS. NORD. satisfazendo os requisitos (HOFMEISTER. Paul Clements. Estruturar a arquitetura por meio de alguma modelagem. ou seja. 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. 2000). Craig Larmam. 3.1. Elicitar requisitos funcionais e não funcionais. Os assuntos levantados nesta parte introdutória serão tratados minuciosamente nas próximas seções.2. Especificar e analisar requisitos não funcionais. CLEMENTS. 5. aliado à arquitetura de referência.

ofertando resultados mais eficientes ao projeto de arquitetura. 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.S. autogerenciamento. e tecnologias. que contém boas práticas sobre a especificação de requisitos de software.Capítulo 5. estes fazem parte de métodos já tradicionais e amplamente validadas pela indústria e pela academia para elaborar arquiteturas. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais são Máquinas Sociais. 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.A. Com esta comparação. As práticas estão ligadas diretamente ao desenvolvimento das SM’s: serviços relacionados à SM. 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. O intuito é possibilitar a construção de sistemas Web como Máquinas Sociais. projeto e arquitetura de software. é 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. padrões de projeto dedicados as SM’s. 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. e a forma ou o exemplo de como ela poderá ser adotada.R. É importante frisar que as práticas propostas neste trabalho não visam substituir os pontos citados acima. elas não só recomendam uma ação.  Leituras e investigações sobre tecnologias para a Web inclusive com a participação do grupo de SM’s da UFPE/C. pois.E.  Padrões IEEE. relacionamentos. a motivação pela qual a prática é sugerida. 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. As práticas foram costruídas por meio de:  Experiência de mais de 5 anos da autora desta dissertação em análise. como também ilustram o problema a ser resolvido. é 92 . e principalmente ao padrão IEEE Std 1471-2000 que contém boas práticas para a descrição arquitetural.

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. Após tratar brevemente de alguns assuntos relevantes para as SM’s.org/index. O projetista de software deve ser remetido aos conceitos inerentes às SM’s como: a taxonomia. é necessário reforçar alguns pontos que fazem parte de qualquer processo de desenvolvimento. Sendo assim. disponibilidade. o objetivo de um padrão IEEE também seria em padronizar procedimentos. Isto faz diferença no momento das definições do projeto arquitetural e dos requisitos de qualidade. e interoperabilidade podem ser trabalhados na arquitetura. suas fronteiras. as premissas que ele estará submetido. confiabilidade. Estas. computadores e dispositivos35.3. segurança. Acesso em: 22 de março de 2012. é possível verificar ainda que tipo de Máquina Social é a aplicação a ser desenvolvida. como já elucidado. as atividades inerentes a um projeto de software não devem ser ignoradas. 5.ieee.Capítulo 5. como frameworks ou padrões de projeto. usabilidade. seria interessante: analisar o problema a ser resolvido pela Máquina Social.Instituto de Engenheiros Eletricistas e Eletrônicos. e depois de visualizar a arquitetura de referência. Quanto aos requisitos de qualidade. Algumas práticas vão propor soluções tecnológicas. 35 Segundo as infromações do site oficial do IEEE . modificabilidade. PRÁTICAS RECOMENDADAS Antes de conhecer as práticas de construção. e a própria arquitetura. Em http://www. e a especificação do produto de software. irão influenciar diretamente na definição da arquitetura. o que ajudará nas decisões de projeto. os tipos de relações. sendo que alguns. as práticas serão exibidas. Com essas análises. são mais relevantes que outros para as Máquinas Sociais. 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. Para qualquer projeto de desenvolvimento de aplicações Web é importante centrar na idéia de Máquinas Sociais. analisar o escopo do sistema. Requisitos como: desempenho. compatibilidade. 93 . sendo que. por sua vez. Estas geram informações e artefatos úteis para a construção adequada da arquitetura da SM’s.html. é necessário averiguar os mesmos. Para que a análise de uma SM seja constituída.

mas verificar como tais serviços estão entrelaçados. qual o fluxo de atividades envolvidas. Assim. Problema: O problema reside em não saber como os componentes da Máquina Social irão interagir uns com os outros. Ainda assim. priorização estratégica. Cabe aqui mais uma referência direta. A modelagem dos processos é um fluxo com a sequência das atividades que são efetuadas para se atingir um objetivo. apuração dos custos e eficiência operacional. estrutura do software. 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. a aferição desses serviços ou operações é feita por meio do mapeamento dos processos que existem em cada operação. Não só conhecer. 2005). 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. 2009) além de descrever o comportamento de um modelo de negócio. ferramentas e arquiteturas. 2009). entre elas: suporte a governança. Assim. 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. quais os serviços e subserviços relacionados ao negócio ou a uma funcionalidade em específico. é possível visualizar mais claramente a SM e agir decisivamente nas escolhas tecnológicas e arquiteturais. mostrará quais as necessidades e atribuições da aplicação. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais 5. (LAZZERI. pois existe hoje uma série de padrões. 2006). É difícil mapear um serviço sem conhecer os elementos que o compõem (OSTENWALDER. Ademais.1. ou da Máquina Social. que vão desde as Arquiteturas Orientadas a Serviços até as Plataformas Corporativas de Serviços. podendo ser a base para a validação das muitas exigências requeridas.3. Pensar em serviços é pensar em modelagem de negócio (LAZZERI. A análise e descrição do negócio contribuirão diretamente para a comunicação e integração (ABINADER e LINS.Capítulo 5. que se 94 . Motivação: Esta prática constitui um fluxo que é o alicerce da modelagem do sistema. a motivação para construir as Máquinas Sociais é a relevância em se conhecer os elementos que irão subsidiar suas operações.

Os serviços podem ser identificados em diversificados níveis de abstração. por exemplo. 2005). Figura 21.2. 5. o serviço de fazer check-in depende do serviço de compra de passagem. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais propõem a ajudar na integração.BPMN é extremamente recomendado (OSTENWALDER. Mas para isto é necessário conhecer o negócio e as regras que envolvem o mesmo. trabalho. Um serviço é uma tarefa. PRÁTICA 2: Reconhecer os serviços providos e requeridos para o funcionamento da Máquina Social. qualquer alteração nesta compra poderá alterar o check-in. 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.3. desde serviços ofertados por uma aplicação a outra. até serviços ofertados 95 . Todos os serviços são descritos possibilitando uma compreensão de como os mesmos estão entrelaçados. 2005). Deste modo. Vale ressaltar que os fluxos de processo devem ser expandidos quando ocorre a necessidade de detalhar melhor uma atividade. Os fluxos dos processos de negócio que surgem da linguagem BPMN modelam perfeitamente o processo. 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. a Figura 21 é um exemplo dessa prática. o uso de Business Process Modeling Notation .Capítulo 5. Exemplo e Solução: Para modelar processos.

96 . Muitas vezes as operações requeridas são executadas por provedores distintos. Exemplo e Solução: O seguinte exemplo pode auxiliar na execução da prática: Aplicação: Aplicativo de rede social. prever os serviços necessários. 2008). Algumas das estratégias são: 1. O benefício desta prática é descobrir os serviços envolvidos com a Máquina Social.Capítulo 5. provocando exigências em conexões (LAZZERI. Motivação: Neste caso. 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. por conseqüência. Existem algumas estratégias para se descobrir um serviço. sobretudo os serviços providos. 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. Serviço requerido: mecanismo de autenticação de usuário da rede social. Outro problema a ser resolvido está relacionado à identificação dos provedores de serviço. entre os elementos que constituem uma aplicação. e como deve ser sua arquitetura. pode prover tal serviço. mais se descobre o tipo de Máquina Social que ela é. Uma conseqüência desta prática. que caracteriza outra motivação. o que. Algumas decisões arquiteturais são baseadas nas características dos serviços requeridos e. seria a identificação da necessidade de Web Services. ou quem. ou mesmo adaptação da arquitetura para suportar a conexão com provedores de serviços. Tipificação: estudar um componente de software e descobrir o serviço que o mesmo pode prover separando-os por categorias (BELL. e também prever possíveis reusos dos mesmos. 2009). Serviço provido: agrupar pessoas com a mesma profissão. verificando o ciclo de vida do serviço. Trata-se de uma orientação voltada para o autoconhecimento. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais por um objeto a outro. Ou seja. Quanto mais se conhece a aplicação.

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. 97 .3. ou arquiteto. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais 2. Estas práticas são próximas das práticas lançadas até este ponto. como o de Michael Rosen em 2008 exploram práticas de design para arquiteturas orientadas a serviço.3. 2009). a separação de responsabilidades entre componentes da arquitetura. e ainda a análise do ambiente organizacional e tecnológico no qual a aplicação será envolvida. 2009). 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. Nesta abordagem. Se os produtos estiverem contextualizados ao negócio ao qual a aplicação está direcionada.Capítulo 5. 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. Abordagem Bottom-Up: analisar o sistema de software verificando os produtos derivados da operação desse sistema. as atribuições de cada pessoa envolvida no projeto. vale expor que ambas foram baseadas em estudos direcionados a SOA. bem como a análise das regras de negócio para identificação dos serviços (LAZZERI. o domínio do software poderá ser estudado. a lançar mão de boas decisões arquiteturais que envolvam os provedores de serviço. por exemplo: o estudo dos serviços. Abordagem Top-Down: parte da análise do problema que o software deve resolver. Algumas destas práticas são. outros softwares podem utilizar esse componente tendo apenas a interface necessária para se comunicar. então tais produtos podem ser vistos como serviços (LAZZERI. 3. Para finalizar esta prática e partir para a próxima. e para identificar os componentes de software que irão prover e requisitar serviço. 5. que também esta relacionada aos serviços. Assim. Alguns estudos.

se algum será reutilizado. Após pesquisa entende-se que ele é uma aplicação que utiliza a infraestrutura da nuvem (Cloud Computing). além de aceitar os formatos XML ou CSV em suas mensagens. Fazer uma listagem das operações necessárias. mas ilustra as informações que devem ser adquiridas. Para enriquecer o entendimento sobre esta prática. analisar cada provedor usando métodos de pesquisa em materias próprios dos provedores. verificar como esses provedores devem ser componentizados. como outra SM. e separar serviços que podem ser atendidos por entidades externas. Separar as operações/serviços. Esta orientação pode ser extremamente útil para os Mashups que trabalham sobre a mescla de serviços de duas ou mais aplicações. 98 . 2001). incompatibilidade entre as tecnologias ou aplicações (JOSUTTIS. Quais métodos a mesma deve ter para manter os serviços. separar os serviços que podem ser atendidos pela própria aplicação. 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. vale examinar o exemplo abaixo. A metodologia para se adquirir as informações nos moldes do exemplo acima é simples: 1. 2. 4. Exemplo e Solução: O exemplo no parágrafo abaixo não é baseado em um caso real. evitando assim. como sites. guias e outros. e como deverá ser a interface de comunicação desses componentes (CHEESEMAN e DANIELS.Capítulo 5. 3. Para os provedores internos à Máquina Social. tutoriais. estudos de caso. Este conhecimento é útil para definir na arquitetura soluções que possibilitem uma comunicação hábil entre provedores e requisitantes. enquanto sua API usa como interface de comunicação o padrão “RESTful”. O Twilio irá fornecer o serviço de telefonia Web necessário na aplicação a ser construída. 2007). Para os provedores externos.

3. auto proteção. mas que. por exemplo. otimizar seu desempenho em conformidade ao ambiente externo. Entretanto.Capítulo 5. otimização. Até agora os conhecimentos lançados exploram questão mais voltadas à análise e modelagem de negócio. Neste momento é importante apontar para a necessidade das funcionalidades autônomas. como exemplo: as IaaS’s. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais Esta prática faz referência a componentização de software. influenciam na arquitetura. ao serem implementados. Ou seja. A partir da próxima prática recomendada os conhecimentos serão mais voltados para as questões técnicas das Máquinas Sociais. 99 .4. e por fim. outro importante conceito para o desenvolvimento de aplicações Web. onde alguns recursos que promovem a autonomia dos sistemas ainda são parcialmente desconhecidos. Ainda existe outro problema agregado. a prática ainda está corelacionada aos conceitos de SOA. através desta prática. PRÁTICA 4: Verificar a necessidade de recursos que tornem a aplicação auto gerenciável e como esses recursos podem ser implementados. configuração. Problema: O problema reside em não saber que determinado componente da Máquina Social tem a necessidade de se auto gerenciar. e se necessitam realmente de autonomia. gerarão funcionalidades independentes. Tal nível está relacionado às propriedades de auto cura. ou ainda se proteger deste ambiente. bem como a prática 2. Assim. pois elas sugerem os mecanismos de auto gerenciamento de uma SM. Motivação: Com este conhecimento. funcionalidades que necessitem se reconfigurar. que um sistema tem alguns requisitos que. quais são esses elementos da SM. pode-se descobrir. Tais aspectos relacionados à autonomia das Máquinas Sociais fazem total diferença na arquitetura da mesma. Este conhecimento está intensamente relacionado aos conceitos de computação autônoma. é possível descobrir o recurso que poderá ser utilizado para prover a autonomia dos elementos. 5.

O parágrafo acima mostra como o MapReduce trabalha em um mecanismo que satisfaz uma propriedade autônoma. Para este problema. se a mesma é variável. o uso de interfaces variadas é a solução. o mesmo envia “ping’s” para cada máquina. estima-se que os registros e acessos de usuários tendem a crescer 42% a cada 30 dias. Pois bem. 100 . Por fim. o componente entenderá que ocorreu uma falha e imediatamente reiniciará a tarefa enviando-a para outra máquina. Para monitorar a carga de trabalho. a tarefa necessitará ser re-executada para que o processo não fique comprometido ou apresente resultados de reduções incompletos. Para isto. 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. ou seja. composto por SM’s distintas (STERRITT. se é fortemente distribuído.Capítulo 5.   A carga de trabalho da SM. uma vez que um componente envie tarefas. Se os recursos da Máquina Social são compartilhados. se é heterogêneo. O auto gerenciamento de um sistema é garantido pela comunicação entre os elementos desse sistema. 2003). controle de logs. o recurso consumido pelas máquinas será grande. processando sempre grandes volumes de dados. garantindo assim a auto cura. seria interessante ter um recurso que monitorasse a quantidade de recursos existentes nas máquinas. 2004. o framework deve lidar com falhas de forma habilidosa. Para esta prática é muto importante sinalizar à equipe de software de que algum mecanismo do tipo deve ser planejado. 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. Se uma delas não responder em um período pré-determinado de tempo. Deve-se lembrar que o framework trabalha de forma distribuída em várias máquinas. O framework MapReduce é uma ferramenta que age bem neste aspecto de autonomia. ou clusters. como: memória e capacidade de armazenamento. Tais interfaces podem agir por meio de APIs. utilização de frameworks e outros (HORN. 2001). O MapReduce segundo Jeffrey Ghemawat. dentro de meses. Assim. e BUSTARD. arquivos de configuração. 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.

É bem mais prático adotar uma tecnologia de mercado do que construir o próprio balanceador. Para se utilizar o recurso de balanceamento de carfa é necessário. O uso de balanceador é muito comum aos sistemas distribuídos em rede. publicou uma estimativa que aponta o Apache como o serviço de balanceamento de carga mais explorado. 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 conceito de CC já foi tantas vezes tratado neste trabalho. como para auxiliar na interação com o ambiente externo. Acesso em: 27 de nov. acima de tudo saber o que se deseja balancear (BOURKE. 5. 101 .3. Eles concentram informações capazes de tornar viável a sociabilidade e a colaboração entre as SM’s. Pois bem. 2011.Capítulo 5.com36. Constraints e Requests: Os elementos chamados States e Constraints são partes da Máquina Social. 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. Site que monta pesquisas e exibe estatísticas sobre ferramentas e sobre a Internet em geral. 2001). 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. em segundo lugar ficou colocada uma ferramenta da Microsoft. performance. O Netcraft. inclusive. ou mesmo a disponibilidade dos seus recursos. onde mais de 50% das aplicações Web o utilizam. Após ter tais conhecimentos. principalmente no contexto de Máquina Social que prega a praticidade na manutenção e evolução do software (BOURKE. é viável preferir por alguma solução. afinal.5. PRÁTICA 5: Determinar os recursos que implementarão os elementos Communications . Finalmente outra opção para esta prática seria contratar um serviço de infraestrutura Cloud Computing. 2001).com/. é complicado saber a disponibilidade de uma SM. e disponibilidade. Sem eles. 36 Disponível em: http://news. Estes dois elementos comportam e fornecem informações tanto para auxiliar o processamento interno da SM.netcraft. o balanceamento de carga promove a escalabilidade.

Na linguagem PHP. os serviços aos quais elas se dedicam e outras informações relevantes. Ainda que existam alternativas. Além disto. os scripts de monitoramento devem ser executados por meio de uma boa infraestrutura onde máquinas estejam preparadas para monitorar. por exemplo. com muitas requisições e etc. Esses scripts podem ser usados para identificar uma ampla variedade de problemas em tempos de resposta. como o serviço: CA APM Cloud Monitor. pois o framework ofertaria praticidade na comunicação e na obtenção de conhecimentos sobre a própria SM e sobre outras SM’s. 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. de modo que toda aplicação Web possa ter implementado esses componentes. Faz-se necessário ainda implementar um recurso que distribua informações de como a Máquina Social trabalha.0. por exemplo. Atualmente existem também alguns serviços Cloud Computig que fazem o monitoramento do estado de sistemas e de redes. todos os scripts que possuírem o comando “exec” poderão ser bloqueados pela maioria dos servidores. Sendo assim. qual a sua capacidade de processamento. Contudo.Capítulo 5. 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. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais inativa. Para solucionar o problema de detectar o estado das 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. 102 . e até mesmo no trabalho de API’s. contribuindo assim. nem todos os scripts estão aptos para lidar com as particularidades de Web Services e linguagens de programação. Motivação: Priorizar uma solução única que possa atender aos requisitos dos elementos States e Constraints. poderia ser utilizado o recurso de scripts de monitoramento. para o fortalecimento destes dois elementos na SM. outras vicissitudes devem ser buscadas. Assim a execução das operações por cada componente seria maximizada. em tempos de processos e ações. o que ela requer para se comunicar com outras SM’s. Existe uma complexidade em implementar recursos que atendam às necessidades expostas nos parágrafos acima. armazenamento.

as relações fortes da SM. Neste elemento. a Manager Relationships apenas enviaria uma mensagem ao 103 . Conexão neste sentido são de fato as Connections. Por fim. 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. que códigos e métodos sejam alterados em diferentes pontos da Máquina Social. ou elementos em uma SM. ruins. sendo que o produto de uma classe pode ser o artefato de entrada para outra classe. para esses níveis seriam definidos nesta classe. São informações como: a quantidade de requisições que a SM pode suportar e o tempo de resposta entre estas requisições. quais SM’s. Sendo assim. a Manager Relationships verifica que o tempo de resposta está prejudicado. ou seja.  Class SM’s Interface: é uma classe de interface que se responsabiliza por construir Request apenas lendo parâmetros. 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. o tipo de conexão. ou ótimos. e como irão se conectar. Essas classes estão inter-relacionadas. sobretudo. informações do status da Máquina Social. sendo que uma boa comunicação necessita de informações. pois esta justificativa é uma informação registrada como não pública na SM’s Configuration. Outra relação de fundamental importância entre as classes citadas no parágrafo anterior é a disponibilidade de informações.Capítulo 5. mas não consegue descobrir o motivo. Qualquer alteração na SM é refletida nesta classe. as portas que podem receber solicitações e o tempo em que essas solicitações poderão ser atendidas. O framework é composto por 3 (três) classes como exibido a seguir. a SM’s Configuration pode configurar uma política de acesso à Máquina Social. por exemplo. os valores bons.  Class Relationships Manager: faz a gestão dos relacionamentos entre as SM’s. Deste modo. evitando assim. Baseado no último exemplo. É um elemento importantíssimo para o framework justamente por executar o monitoramento das conexões entre as Máquinas Sociais. proporcionando uma criação mais objetiva sem envolvimento de diversos códigos fontes ou outras tecnologias. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais O framework se preocuparia em ter as informações da SM. irão se conectar. deixando evidente. é possível definir o tempo de conexão. pode existir uma instância desta classe para cada SM conectada.

3. a Class Manager age diretamente sobre essa interface conforme os resultados obtidos no controle das conexões. Enquanto várias interações ocorrem. Fica como sugestão para as arquiteturas que resolverem adotar esse framework. esse poderia ser uns dos elementos principais de suporte à camada central de processamento da Máquina Social. o que agrega mais simplicidade na configuração do framework. Representação do framework de comunicação para as SM’s 5. Todo estilo arquitetural 104 . PRÁTICA 6: Adotar estratégias para sanar as fraquezas do estilo arquitetural camadas. Isto saciaria a necessidade de incluir uma propriedade autônoma relacionada a auto cura. Finalmente é possível notar que muitas das informações relevantes à SM são trabalhadas em um só lugar por meio do framework. depende dos seus requisitos de qualidade. 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. 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. Vale ressaltar que todos os atributos dessas classes são repassados no formato “chave ⁄ valor”. A adoção de um estilo arquitetural depende do contexto no qual a aplicação está inserida.6. sem necessariamente ter a garantia de que o método resolveria o problema. e sobretudo.Capítulo 5. 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. Por fim. Figura 22.

quando uma camada falhasse. sua camada réplica estaria pronta para prover os serviços. ou em outro fornecedor. visto que o estilo se mostra eficiente para a implementação de aplicações Web. tanto na montagem dos Requests. tecnologias emergentes podem ser incorporadas ao estilo para reduzir a intensidade das conseqüências. o escopo da mesma. como uma IaaS ou mesmo PaaS. Exemplo e Solução: Nada impede que outros estilos sejam mesclados ao estilo camada (HOFMEISTER. Motivação: É possível repensar no estilo camadas para as SM’s. onde todas as fragilidades de tal estilo poderiam ser amenizadas. A execução das 3 (três) primeiras práticas vai auxiliar fortemente a prática aqui tratada. tais fragilidades podem comprometer a qualidade da arquitetura da Máquina Social. o segundo auxiliaria na tolerância a falhas. qual será sua dimensão. 105 . Isto é válido. além de programar o sistema de infraestrutura de modo que todo o conteúdo seja replicado no novo ambiente negociado. todavia. Já o exemplo a seguir pode auxiliar no entendimento. mesmo porque. quando na obtenção facilitada do estado das SM’s. é possível negociar mais máquinas virtuais ao mesmo fornecedor de servidos de IaaS. caso a SM use um recurso CC. O estilo camadas é fortemente utilizado em sistemas Web e estava fortemente presente no mapeamento do estudo da literatura. A inserção do framework citado na última prática em conjunto ao MapReduce poderia ser uma idéia proveitosa. Outra alternativa seria implementar uma réplica de segurança para cada camada. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais possui vantagens e consequências em sua adoção. deve-se analisar novamente os serviços providos pela aplicação. 2000). nas camadas de acesso a dados já é possível usufruir do artifício da replicação de dados. sendo que.Capítulo 5. Outras fragilidades desse estilo já foram elencadas anteriormente. As alternativas para se adequar ainda mais o estilo camadas as SM’s são numerosas. como a tolerância a falhas e a queda de desempenho. Esta é realmente importante para as SM’s. Problema: O estilo camadas se mostrar frágil quanto ao provimento da comunicação. enquanto o primeiro traria rapidez ao processo de comunicação. Deste modo. Nessa alternativa. e o ambiente no qual ela estará.

o conteúdo trocado entre elas é de total relevância. Motivação: A motivação desta prática está em utilizar algum recurso já explorado por outras SM’s como REST e SOAP. dependendo do tipo de relação existente entre as aplicações. Contudo. adicionando complexidade ao seu desenvolvimento. pois ele viabilizaria o registro apenas dos clientes ativos (BUSCHMANN.Capítulo 5. Ou ainda. et al. o ambiente no qual a Máquina Social está envolta. Quando se trabalha com comunicação entre Máquinas Sociais trabalha-se mais do que tudo nas integrações requeridas entre esses SM’s. PRÁTICA 7: Determinar o recurso que proverá a comunicação e a interoperabilidade. o problema se origina novamente da heterogeneidade de recursos que são utilizados e que por vezes não agregam um bom resultado à SM. A comunicação é uma característica que sobressai na Máquina Social. pode ser adotado um padrão de comunicação entre elas. Portanto. de fornecedores e demais parceiros do negócio. Deste modo. Neste aspecto. 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.3.7. 1996) notificando os mesmos a cada alteração sem esforço da aplicação servidora. e a interoperabilidade é um requisito importantíssimo a ser considerado na arquitetura da mesma. Assim. 5. ou pode haver um consenso quanto aos tipos de mensagens trocadas e o tempo em que elas serão trocadas. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais Exemplo: o servidor precisará notificar todos os clientes ativos diariamente. analisar algum padrão utilizado pelo paradigma Cloud 106 . ou entre as SM’s ditribuídas. seria interessante utilizar o estilo arquitetural Publisher-subscribers na camada de comunicação. assim como. Ainda deve-se considerar que a integração ocorrerá também entre SM’s heterogêneas envolvendo Máquinas Sociais de clientes. 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. o detalhe neste caso é que tais SM’s podem apenas manter uma comunicação interna entre os componentes que a compõem.

alguns fatores impulsionam a comunicação. integração e interoperabilidade flexível entre os sistemas. por outro lado a completude de recursos que o SOAP possui (KALIN. SAAJ. Vale ressaltar que o metadado WSDL descreve Web Services com muita proeza.Capítulo 5. 1. 2010) e também aplicações móveis. Na indústria de desenvolvimento para a Web existem dois grupos de profissionais que se dividem em utilizar REST ou em utilizar SOAP. a arquitetura REST oferta interfaces de serviço preparadas para integrar aplicações que manipulem grande quantidade de dados (WEBBER. a necessidade contínua de conter custos. Web Services: Web sevices podem ser geridos por frameworks como: Axis 1. 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. 2010). especifica como acessar o Web Service e quais as operações que o mesmo dispõem. Ambos sustentam argumentos fortes. as características do REST dão mais praticidade ao desenvolvimento. 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. São eles: a expectativa de se obter retorno financeiro mais rápido. as soluções mais próximas da realidade das SM’s são exibidas em seguida.0. o aumento da demanda no compartilhamento de dados em tempo real. sendo que ele ainda descreve o serviço. 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. Por um lado. justamente para que os profissionais possam optar pela tecnologia mais adequada.0 e 2. A questão por se definir entre REST ou SOAP é algo que depende de muita prática em desenvolvimento de software. Contudo. ainda existe a possibilidade de explorar novas idéias que ofertem mais praticidade na integração entre as SM’s. É 107 . Segundo Rezende (2005) (2006). PARASTATIDIS e ROBINSON. Jax-WS. 2006). 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. O WSDL é uma ferramenta muito poderosa para a obtenção de interoperabilidade.

2004). 2. o que proporciona maior velocidade nas transações. PARASTATIDIS e ROBINSON. Está http://www. no caso dos componentes disponibilizados por tal plataforma não atenderem as funcionalidades exigidas pelo escopo da Máquina Social. 2004).htm. solicitantes e provedores de serviços trocam mensagens do tipo SOAP para encontrar e disponibilizar serviços respectivamente (GOMES. Com isto é possível ver que CC também adere ao uso de SOAP. Enterprise Service Bus . na utilização das mesmas pelo paradigma Cloud Computing. sobretudo. Vale lembrar que a identificação dos serviços facilita a execução das primeiras práticas propostas por esse trabalho.com. 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. e que serão construídas sobre a arquitetura Multitenancy. O que aproxima REST das Máquinas Sociais é a facilidade com que esta solução pode auxiliar na identificação dos serviços (WEBBER.com.ESBs: Outro recurso que ganhou força com SOA e que também provê integração e comunicação são os ESBs (CRAGGS. Tal protocolo também ganha notoriedade quando as aplicações são construídas sobre o paradigma de Arquitetura Orientada a Serviços. 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. REST seria a solução mais adequada para as SM’s. 37 Guia do Programador da API de Serviços Web da Force. Em se tratando de CC. disponível em: 108 . Em SOA. A Force. 2011.Capítulo 5.com37. A grande vantagem do ESB é que o formato da mensagem já é conhecido pelas duas aplicações (CRAGGS. 2010). a taxonomia. 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.com/us/developer/docs/api/index.salesforce. O conhecimento deste parágrafo e do seguinte estão disponíveis no Guia do Programador da API de Serviços Web da Force. Acesso em 01 de abr. que manipulem poucos dados. Ela sugere que as aplicações Web que exijam um tempo de resposta curto. façam uso de SOAP.com ainda fornece suporte a utilização do protocolo de acesso SOAP. Apesar dos benefícios de SOAP. as interações. 2010) e. e a natureza dos serviços.

na manutenção. 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. Apesar de ser uma boa solução. Os ganhos que são conseguidos por meio da Cloud Computing são refletidos na disponibilidade de recursos. podem utilizar o padrão de comunicação RMI. 2004). o que facilita o reconhecimento das mesmas por diversas SM’s amenizando assim o problema de integração. PRÁTICA 8: Selecionar o recurso Cloud Computing a ser adotado na SM. 2009). 3. inclusive dispositivos móveis. Conceitos que são relevantes como análise do negócio e aviso de entrega de mensagens. que. e estão inseridos no universo da Web 3. pela padronização de mensagens.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. o que contradiz os princípios da SM de ser independente. O Jini faz a localização dos serviços sem necessitar consultar nenhum repositório de serviço (ARNOLD et al. além de garantir a integração de diversas Máquinas Sociais distribuídas utilizando adaptadores e conectores (LINTHICUM. é que deve-se buscar a inserção de tais recursos no desenvolvimento de aplicações Web. 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. e também pelas vantagens que os serviços Cloud podem trazer. sobretudo. trabalham como SM’s. A arquitetura de referência sugere que os recursos disponibilizados pelo paradigma Cloud Computing sejam inseridos na arquitetura de Máquinas Sociais. ou a ferramenta Jini. 109 . Deste modo. Remote Method Invocation .0.8. Por isso. por exemplo. pode conectar diversas aplicações distribuídas em rede (ARNOLD et al.3. por meio de um conjunto de API’s. como SOAP faria. Desta forma.RMI: Aplicações que sejam desenvolvidas em Java. 2009). Na verdade Cloud Computing. e na produtividade do desenvolvimento da aplicação. a mesma traria muita dependência com a tecnologia Java. o uso de um ESB na camada Wrapper da SM é uma solução inteligente e ideal para as SM’s. sobretudo os SaaS. estão implícitos nesta abordagem e devem ser considerados para a adoção de alguma tecnologia. 5.

a priori. 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 . essas funções de leitura e escrita podem ser desaceleradas conforme a quantidade de máquinas existentes (MOTAHARI-NEZHAD. parece não trazer muitas novidades que resolvam de forma diferenciada os já conhecidos problemas do desenvolvimento de software. 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. Outro problema inerente às próprias características de Cloud Computing é a velocidade na taxa de leitura e escrita em disco (KE et al. É necessário mais atenção e pesquisa para notar os benefícios que podem ser agregados com a adoção de Cloud Computing. Assim. 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. 2010). Sendo assim. Um problema relevante nesta questão é o fato de não se ter um parâmetro de como ou onde usar Cloud Computing.Capítulo 5. é extremamente motivador analisar como o advento de Cloud Computing pode ser atrelado às Máquinas Sociais. 2009). Tendo em vista que CC usufrui de muitas máquinas virtuais para se fazer leitura e escrita. que. O novo paradigma. Nesta categoria estão os servidores de email e de banco de dados. toda aplicação que precisar manipular muitos arquivos em disco não vai conseguir taxas altas de leitura e escrita. 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. e como a integração entre duas SM’s pode ocorrer (Cloud Computing é uma SM que serve a outras SM’s). por vezes não tentam desenvolver projetos experimentais a ponto de confrontar os resultados da adoção de Cloud Computing. principalmente quando se trata de sistemas WEB. para o desenvolvimento de aplicações Web? Afinal muitas soluções não CC ofertam benefícios que são promessas da Cloud Computing. Este talvez seja um ponto problemático para as empresas.

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. ou seja. entre eles:  Cloud Brokers: Trata-se de um seviço de corretagem em CC. outros serviços e tecnologias ganham destaque. Estas formalizam um contrato de acordo de serviço. 2010). 2009). como será fornecido. (WEISSMAN. os prazos necessários e etc. este deve ser o menor possível. a que custo será fornecido. 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. Todavia antes de verificar a adoção de qualquer serviço CC devem-se analisar anteriormente todas as SLAs referentes ao serviço. além de ofertar possibilidades de reuso em recursos computacionais. empresas especialistas no assunto ofertam esse serviço que visa indicar qual o melhor provedor. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais de software. bem como o esforço da equipe de implementação da Máquina Social. e ainda viabilizar a implantação do 111 .Capítulo 5. 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. e quais os serviços Cloud mais adequados ao negócio que pretende adotar Cloud Computing (GARTNER Inc. Deste modo. o cuidado e a análise com o SLA é considerável. Os Brokers ainda são capazes de analisar as SLAs existentes em um contrato de pretação de serviço Cloud. o que será prestado como serviço e como deve ser o desempenho do fornecedor de serviço. Enquanto as SLAs são protagonistas no assunto. Portanto. O próximo parágrafo evidencia ainda mais a motivação por se analisar a utilização de Computação nas Nuvens. 2009). é possível verificar a eficiência do modelo de implantação da CC. CC é capaz de ofertar essas soluções. Tais SLAs devem ter a transparência necessária para deixar evidente o que será fornecido como serviço. 2009). se público ou privado. indicar melhorias nesse contrato.

(NYSE: IT). Para um serviço de IaaS a empresa Amazon pode ser considerada.Capítulo 5.gartner. que devem suportar grande volume de dados e de acessos. 112 . Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais serviço.S. isto sem esforço da equipe de desenvolvimento da Máquina Social. Recursos Computacionais: Ao utilizar um recurso Cloud Computing como IaaS.A.jsp. aos sistemas com lógicas mais complexas.  Windows Azure: Segundo experimentos de Kossmann. 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. caso a empresa não tenha recursos humanos totalmente capacitados38. É 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. Em: http://www. Kraska e Loesing (2010) a IaaS Windows Azure é a plataforma que oferta maior performance e escalabilidade aos sistemas de médio e grande porte. 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. Além disto. por exemplo.com/ec2/. ou a pessoa. A Amazon ainda disponibiliza o serviço “Amazon Elastic Compute Cloud (EC2)”. que adquirir os serviço Cloud da Amazon. ou. 2010. Acesso em: 31 de nov. por exemplo. Tal plataforma ainda oferta serviços de criptografia RSA e segurança de dados com firewall. é possível dispor de recurso computacional automaticamente conforme a necessidade e crescimento da aplicação. A organização. consegue implantar um software Oracle.amazon. Acesso em 15 de out. com esta solução é possível usufruir de alta segurança e disponibilidade dos dados. Ou seja.com/technology/about. ou fazer backup de um banco de dados. sobre a economia e a segurança. Esta prática ajudará nas decisões relacionas a Cloud Computing e no entendimento de alguns de seus recursos relacionados abaixo: 1. em muito pouco tempo39 e sem problemas. Tal compreensão é relevante. 2011 39 Informação disponível em: http://aws. pois a arquitetura da Máquina Social vai se entrelaçar a alguma camada da arquitetura do provedor de serviço Cloud Computing. Fundado em 1979 em Connecticut. Inc. U.

com.uol. Por fim. 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. 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. 2011.  Usufruir sempre da garantia de disponibilidade e analisar outros métodos que contribuam para a aquisição de desempenho da aplicação.br/negocios/2010/09/10/desempenho-e-maior-problemapara-usuarios-de-cloud-computing/. 2009). Alguns planos do Amazon EC 2.amazon. Para algumas empresas.   Trabalhar fortemente com XML para a integração entre as camadas da arquitetura na aplicação e na nuvem.com/ec2/. o nível de maturidade da TI em empresas desses portes. 41 Informação disponível em: http://aws. e replicação de instâncias de bancos de dados. segurança por meio de firewall. custam apenas 600 (seiscentos) dólares por ano41. isto pode significar uma redução de custos. Acesso em 19 de ag. o preço das boas ferramentas tecnológicas sempre foi elevado. sobretudo. Tais cópias devem ser. principalmente no Brasil. 2006). Neste 40 Disponível em: http://computerworld. 113 . por exemplo. esses serviços IaaS são capazes de ofertar balanceamento de carga. 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. Para as PMEs.Capítulo 5. Acesso em 30 de jul. 2. de até 80% nos gastos com infraestrutura. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais dados. 2011. é relativamente baixo (REZENDE. Algumas recomendações sobre os serviços e recursos Cloud Computing prosseguem abaixo:  Guardar réplicas de segurança em outros repositório. Logo. dos dados. Isto é necessário porque os recursos Cloud Computing são susceptíveis de falhas. Economia: O preço do serviço deve estar claro em uma SLA de CC. sejam eles locais ou na nuvem. segundo a Forrester Research.

o uso de SM’s dependerá muito do contexto econômico da empresa. O exemplo seguinte explora muito bem essas situações. apesar das aparentes vantagens há de se analisar todas as despesas decorrentes de treinamento. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais aspecto. a criptografia por meio do algoritmo RSA é 114 . A adoção de Cloud Computing para redução de custos é algo muito relativo. ou cliente. Assim é necessário trabalhar bem com o controle aos meios de acesso aos dados. se tratando de CC. que são armazenados em uma nuvem pública. O fato é que existem realmente riscos. contratos. E a falta de segurança é um perigo presente não só para os usuários de Cloud Computing. Pois bem. o que levaria a aquisição de novos recursos. A grande preocupação reside em não saber se os dados estariam tão seguros em Cloud Computing quanto estariam seguros localmente. normalmente residem em um ambiente compartilhado com dados de outros clientes e empresas. em 24 (vinte e quatro) horas. e não deve ser o fator preponderante para a adoção. 3. Somente assim será possível verificar se as vantagens serão refletidas por meio de economia financeira. ou núvem pública. sobretudo quando se utiliza os serviços de uma Public Cloud. Segundo Taurion (2009). por meio da senha os clientes e as empresas respondem a um conjunto de questões de segurança para ter acesso à conta. o que possibilitou o processamento de 3 (três) terabytes de dados. os recursos computacionais do jornal ficariam sobrecarragados. marketing e outras vertentes naturais do negócio. Por fim. as ofertas de Cloud Computing podem ser vantajosas. Mas. pode ser algo delicado. mas. Entretanto. uma vez que. Cloud Computing pode ser uma solução econômica em situações onde se requer poder computacional. Nesta situação a equipe de TI decidiu por adquirir os serviços Cloud Computing EC2 da Amazon. em oposição a eles. Segurança: A segurança é um requisito importantíssimo para qualquer sistema computacional. existem excelentes soluções que objetivam garantir a segurança. existem receios em sua adoção que são oriundos da falta de segurança. a privacidade nos dados. Os dados de uma empresa. utilizando 100 (cem) instâncias virtuais a um custou de 240 (duzentos e quarenta) dólares.Capítulo 5. Controle de acesso via senha é uma solução bem madura em Cloud Computing. o jornal New York Times no ano de 2008 necessitou digitalizar todas as suas edições desde 1851 até o ano 1989. mostrando um cenário mais promissor para a TI das PMEs. Neste contexto.

5. Entretanto. et al. Geralmente isto pode ser implementado em SaaS. O documento orienta que a adoção da nuvem privada é mais adequada aos negócios de qualquer natureza. ou seja. o mesmo documento encoraja experiências com o modelo público de Cloud Computing. São produtos preparados para interagir com implementação e agregar recursos que dêem suporte a alguma funcionalidade a ser desenvolvida. privacidade dos dados. PRÁTICA 9: Selecionar os padrões de projeto mais adequados para a arquitetura da Máquina Social. Eles permitem transferências de dados sempre protegidos usando novamente a criptografia. a escolha por uma nuvem pública ou privada dependerá muito da natureza dos dados trafegados. 115 . Vale reforçar que novamente as SLAs devem tratar claramente das questões de proteção. Padrões de projeto são soluções de código que podem ser reutilizadas para resolver um determinado problema (GAMMA. 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. 2000). 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. PaaS e IaaS diversificadas.nist. o que oferta mais segurança e confiabilidade ao cliente ou empresa que são os únicos a terem conhecimento da chave. O mesmo possui práticas e orientações sobre segurança e privacidade em Cloud Computing. Entretanto. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais muito bem trabalhada.gov/customcf/get_pdf.Capítulo 5. Tais chaves rotineiramente são geradas fora da nuvem.3. é necessário guiar esses padrões para o contexto de Máquinas Socias enquanto aplicações Web. e garantia de integridade das aplicações. A segurança tem sido bastante trabalhada em Cloud Computing. 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. 42 Disponível em: http://www.cfm?pub_id=909494. Estes padrões substituem implementações de códigos e projetos de componentes de software. Existem ainda os certificados de chaves públicas.9.

os padrões são divididos em 3 (três) grupos: padrões de criação. o que é fundamental para a arquitetura em Camadas. conceito. e também são os mais relevantes para as Máquinas Sociais. Ainda assim. 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. Quais destes ofertariam melhor suporte as SM’s? Além deste questionamento. assim. 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. a probabilidade de usar padrões diversificados é grande. deve-se fechar o escopo dos padrões para Máquinas Sociais a partir das características. Os padrões comportamentais e os padrões estruturais constituem os maiores grupos.Capítulo 5. Na verdade esse conhecimento poderá motivar o estudo de novos padrões para SM’s. Não ter conexões eficientes entre as Máquinas Sociais e entre os componentes que constituem as mesmas. 2005. O quantitativo de problemas a serem resolvidos por Máquina Sociais é vasto. Não ter ação necessária de forma imediata após conhecer o estado dos componentes. Composite e o Strategy (LARMAM. Ao todo existe um universo de 23 padrões de projeto. Alguns destes problemas são:    Não ter fácil acesso às informações sobe o estado dos componentes. e particularidades de uma SM’s. os padrões já existentes demonstram muita riqueza quanto à capacidade de resolver problemas naturais das Máquinas Sociais. São eles: Observer. 116 . Deste modo. Estes padrões também priorizam a cooperação entre os elementos e ainda viabilizam o baixo acoplamento. 2005). 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. padrões estruturais. segundo Craig Larmam. 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. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais limitando os mesmos. Além disto. e padrões comportamentais.

2000) mais preparados para atender a maioria das Máquinas Sociais enquanto sistemas Web. 2000). como o Factory Method (GAMMA et al. Composite Compõem classes para formar um componente maior. se um componente ou se o conjunto destes. principalmente os padrões que criam interfaces. deixando transparente ao usuário ao qual está fornecendo o serviço.Capítulo 5. pois as classes. 117 . Decorator Usa de forma flexível a extensão de subclasses para acrescentar operações acionais às classes ou objetos. Observer Gera uma ligação entre os objetos de modo que. ele é aplicado para reduzir a duplicação de código. todos os objetos sejam automaticamente notificados da alteração. ou o próprio sistema em si. 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. ao serem criadas podem ser customizadas para ter sua comunicação e função viabilizadas por este padrão. como um componente que constituirá o sistema. os padrões do grupo de criação podem também ser empregados. no momento em que um objeto alterar seu estado. Tabela 6. Isto quando se fizer necessário a adaptação da função de um componente para uma funcionalidade específica. 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. Previlegia o baixo acoplamento. Neste ponto veremos a definição de alguns dos padrões de projeto (GAMMA et al. 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. se houver necessidade. Vale ressaltar que.

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. 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. Outros padrões. a camada inferior não responderia as solicitações. fora ou não desses grupos. Relação entre os padrões de projeto e os requisitos não funcionais das SM’s Esta prática. tende a orientar os desenvolvedores quanto às melhores decisões de projeto para a Máquina Social a ser implementada. mas isto irá depender unicamente das características da aplicação e do ambiente onde a mesma está inserida. 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. 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. A tabela 8 mostra o relacionamento entre os padrões indicados para as Máquinas Sociais e os requisitos não funcionais das mesmas. ou ainda dos requisitos impostos à mesma. 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. O seguinte exemplo pode ocorrer de forma natural no emprego dos padrões às SM’s. 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. assim como todas as outras. suas operações. neste caso. podem ser de grande valia às SM’s. é possível empregar melhor os padrões. graças ao padrão. Quando se observa melhor a prioridade desses requisitos. A decisão mais assertiva em relação a banco de dados de Máquinas Sociais será exposta a seguir: 118 . ou fora do esperado. Tabela 7.Capítulo 5. anulando assim.

2011). a escalabilidade e a flexibilidade em mudar estruturas. Os bancos não relacionais atendem de forma mais eficiente os requisitos das Máquinas Sociais.3. Twitter. 119 . Não é necessário que a SM a ser desenvolvida tenha milhões de usuários em acessos simultâneos. entre elas. Basta que a mesma trabalhe com objetos complexos. sobretudo. 2011). 2010). ou que tenham entidades espalhadas em muitas tabelas normalizadas (TIWARI. entre elas se destacam:   Amazon Dynamo e MemcachedDB: trabalham com armazenamento de dados baseados no modelo chave-valor (TIWARI. O propósito deste tipo de banco de dados é suprir as carências que estão presentes nos bancos relacionais.10. 2010). Google e Amazon (LEAVITT. A abordagem NoSQL tem sido a mais explorada entre grandes coorporações da Web 3. como: Facebook. isto seria suficiente para trabalhar com NoSQL. acessos que passam a ser crescentes ao passo que cresce a quantidade de usuários da aplicação. CouchDB e MongoDb: trabalham com armazenamento de dados baseado no modelo orientado a documentos (CHODOROW e DIROLF. 2010). Problema: O problema reside no fato das Máquinas Sociais serem.0. Exemplo ou Solução: Para seguir tal prática é necessário avaliar algum banco NoSQL. Tal requisito é deficitário em banco de dados relacionais (LEAVITT. aplicações que necessitam de bom gerenciamento dos acessos aos dados. 2011). ou NoSQL. 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. em grande parte. necessitando assim de escalabilidade para a performance.Capítulo 5. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais 5. surgiram em 1998. desempenho (TIWARI. PRÁTICA 10: Selecionar o banco de dados não relacional Bancos de dados não relacionais.

4. é necessário selecionar como será o sistema de armazenamento. a mesma pode ser adotada. já que ocorrem diversos benefícios em sua aplicação. CONSIDERAÇÕES FINAIS DO CAPÍTULO Algumas práticas recomendadas aqui dão novas idéias que podem ser amadurecidas perfeitamente em trabalhos futuros. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais   BigTable. amadurecendo alguns possíveis trabalhos futuros. disponibilidade.Capítulo 5. bem como. desempenho/performance e flexibilidade são agregados a arquitetura. os dados são distribuídos por vários servidores que trabalham de forma paralela. além de preparar o próximo capítulo. 2010). 2010). As conclusões deste capítulo vão em seguida abordando as práticas para SM. Isto contribui ainda mais para o bom funcionamento da SM. sintetizando as idéias. o framework de Máquinas Sociais exposto neste trabalho. Neo4j e InfoGrid: trabalham com armazenamento de dados baseado em grafos. principalmente na questão da consistência dos dados. Finalmente. Os padrões de 120 . Com NoSQL. como: os padrões de projeto que podem ser adaptados para as SM’s. haja vista que o sistema de banco de dados possui mecanismos que detectam quando os objetos forem atualizados (CHODOROW e DIROLF. Já o desempenho da SM é sensivelmente melhorado devido à diminuição do volume de dados processados pelos servidores de BD NoSQL. uma ou duas BD’s podem ficar indiponíveis sem causar a interrupção de toda a SM. Hbase e Cassandra: trabalham com armazenamento de dados baseado no modelo orientado a colunas. Depois da devida análise da SM a ser construída. Esse processo faz o escalonamento paralelizado (TIWARI. possíveis padrões de processo de SM’s. Todas essas soluções são distribuídas e executam o chamado “processo de sharding”. é a disponibilidade (LEAVITT. Esta pode ser atendida. Isto possibilita a escalabilidade. um requisito fortemente atendido e extremamente relevante à SM. 5. Até mesmo a consistência dos dados pode ser garantida. caso seja detectado que a SM a ser desenvolvida possa trabalhar com a base de dados relacional. Nesta análise. fazendo surgir assim um novo padrão. ou seja. 2011). e ainda. pois. retornando sempre o último valor atualizado dos mesmos. SimpleDB.

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

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. a qualidade e o tempo de entrega dos serviços. a prática sete. Recomendação de Práticas Para Desenvolver Arquiteturas de Máquinas Sociais Para adotar SOA. Neste trecho é notável uma relação de dependência entre as práticas. Os serviços só são bem mensurados quando se conhece o negócio. melhorando a escalabilidade do sistema. dos estilos arquiteturais que compõem a arquitetura da SM e os padrões de projeto utilizados. Não é propósito adotar SOA definitivamente em SM’s.Capítulo 5. Neste caso. Deste modo. reduzindo gastos. segundo o instituto. 122 . por exemplo. de implementação dos elementos States e Constraints. ajudará a encontrar a melhor solução em comunicação e interoperabilidade mediante o auxílio de outras práticas. 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. 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. SOA também estaria apta a trabalhar dentro do paradigma de Cloud Computing. As práticas 7 (sete) e 9 (nove) estão também bem entrelaçadas às demais práticas. como: as práticas de análise dos serviços. Tal paradigma está bem maduro e propenso a auxiliar o desenvolvimento de SM’s. mas sim adotar alguns princípios e conceitos de SOA e que podem auxiliar no desenvolvimento facilitado de SM’s. a tabela 9 relaciona os requisitos às práticas. Assim. é 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). a modelagem de processo que é tratada na primeira prática pode dar suporte para demais práticas. como por exemplo: o tratamento aos serviços e o cuidado com a modelagem de processos.

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

1. pois os projetos são reais de empresas e profissionais fixadas no mercado. onde os produtos. 3. algumas informações serão subtraídas da exibição do desenvolvimento. ou simplesmente projeto. No entanto. Todavia acredita-se que a ausência de tais informações não deixará pontos duvidosos ou falsos no estudo.Capítulo 6. ou SM’s resultantes. ou seja. por questões de confidencialidade exigidas pelos proprietários das SM’s. 2001). ainda não estão disponíveis aos clientes ou usuários. 6. Nem todos os detalhes sobre o desenvolvimento serão expostos. a abordagem a ser experimentada. 126 .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. ou caso de uso. Os responsáveis pelo desenvolvimento das SM’s que serão exibidas neste capítulo autorizaram a exposição das mesmas. No entanto. antes de exibir o estudo. DEFINIÇÃO DOS OBJETIVOS 1. agilidade na fase de projeto de arquitetura. (JURISTO e MORENO. isto no contexto de empresas que desenvolvem SM’s. 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 . 2. como já explicitado. INTRODUÇÃO O experimento efetuado é do tipo estudo de caso. haverá uma seção para expor brevemente um projeto piloto. a qualidade dos componentes codificados na fase de implementação. usabilidade da arquitetura de referência. e por fim. precisão nas escolhas arquiteturais. ou ainda In vivo.2. o qual foi utilizado para por em prova o planejamento do estudo de caso e o próprio objeto de controle. Experimentação das Práticas 6. Trata-se de um caso real de pessoas em seu ambiente próprio de trabalho. e também por causa de concorrência da indústria de software local. 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. 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.

ou mesmo em conjunto a outros fatores. é válido incluir essa questão e métrica. às decisões de projeto e arquitetura.Capítulo 6. Os pontos tratados pelos métodos propostos para SM’s. No entanto. o que faz elas enrriqueçam os requsitos. Com isto é complicado saber qual a causa dos defeitos. 2001). na diminiução dos defeitos. Métrica: Quantidade de pontos ou requisitos trabalhados pela arquitetura com auxílio dos métodos propostos. 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. As práticas e arquiteturas de referência para SM’s auxiliaram na definição adequada dos componentes arquiteturais. A questão e métrica relacionada as não conformidades são difíceis de serem controladas. pois as práticas trabalham na concepção dos processos de negócio e serviços. Isto ocorre porque a quantidade de defeitos encontrados nos produtos de software é muito relativa aos requisitos. práticas mais AR. às pessoas envolvidas. ou seja. Experimentação das Práticas 4. a dificuldade poderia ser menor (JURISTO e MORENO. Se este experimento fosse feito em laboratório. b. onde todas as variáveis fossem controladas. 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 não conformidades encontradas por meio de testes funcionais e também por meio da aceitação do cliente. ofertando assim maior qualidade do produto de software e consequentemente da arquitetura? i. e melhorem a arquitetura. Questões: a. 127 . e claro.

PLANEJAMENTO 6.3. ou modelagem de sistema.  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.3.3. AD: adequação da arquitetura concebida por meio do objeto de controle. assim: NºPORsempráticas+AR<NºPORpráticas+AR 128 . 2002). 2002). que representa o contrário da hipótese nula (TRAVASSOS. Nesta será verificado a utilidade da metodologia de SM e se a mesma é adequada para a formulação da arquitetura de Máquinas Sociais. NºPOR: número de requisitos da SM trabalhados pela arquitetura. que representa o que o estudo quer negar (WOHLIN. et al.1. a qualidade do produto foi atestada como satisfatória. UNIDADE EXPERIMENTAL A unidade experimental é o objeto que receberá o tratamento (JURISTO e MORENO. 6. o objeto são as práticas e arquitetura de referência propostas para conceber arquiteturas de Máquinas Sociais. 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. OBJETO DE CONTROLE O objeto de controle é a abordagem a ser experimentada (WOHLIN. de modo que. 2002). Para este estudo. DEFINIÇÃO DAS HIPÓTESES Serão divididas em hipótese nula. 6.3. Para este estudo o objeto que será submetido à experimentação é a fase de projeto. et al.3. GUROV e AMARAL. e hipótese alternativa.Capítulo 6. 2001). Experimentação das Práticas 6.2.

se o resultado for satisfatório. 129 . Isto. as novidades nas práticas e AR poderão não agregar benefícios de grandes dimensões. Com isto. o resultado pode ser verificado para o caso mais extremo de SM’s. em equipes que já façam uso de uma metodologia de concepção da arquitetura. 6.4.3. entende-se que o objeto de controle poderá ser aplicado sem maiores problemas para os projetos de SM’s mais simples. Experimentação das Práticas ADsempráticas+AR<ADpráticas+AR Dentre estas variáveis o fator tempo não foi controlado. Ou seja.  VARIÁVEIS DEPENDENTES: 1. 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. Sendo assim. mas sim. 3. Tipo de Máquina Social a ser construida: é necessário que sejam desenvolvimentos interessantes de Máquinas Sociais do tipo Prosumers. 2. Maior quantidade de pontos ou requisitos trabalhados pela arquitetura para satisfazer a Máquina Social. disponibilizar uma arquitetura correta e de qualidade à Máquina Social. 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. 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. VARIÁVEIS INDEPENDENTES E DEPENDENTES  VARIÁVEIS INDEPENDENTES: 1. os desenvolvimentos não devem estar na fase de codificação da aplicação ou mesmo documentação de arquitetura.Capítulo 6. pois essas SM’s são mais completas e complexas. O objetivo também não é viabilizar uma arquitetura em pouco tempo.

Quanto à empresa. 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. 6. ausência provocada por um problema ou por alguma determinação da empresa.5. ou nenhuma não conformidade (defeitos encontrados). hospitais públicos e privados. provocando assim. A linha de produção da MV é responsável por sistemas que automatizam todos os processos de instituições ligadas à saúde no Brasil. Outro ruído seria a ausência de algum integrante da equipe. A unidade experimental selecionada estava no momento ideal de ser submetida. Experimentação das Práticas 2. uma má execução da fase de (projeto) modelagem.6. CONTEXTO O contexto é caracterizado como sendo In vivo.7.3. GUROV e AMARAL.Capítulo 6. Os resultados deste experimnto podem ser úteis a problemas específicos da modelagem arquitetural de Máquinas Sociais. Adequabilidade maior da arquitetura à Máquina Social.3. entre elas: planos de saúde. Além disto. 6. 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. é importante citar que o estudo de caso foi sobre uma Máquina Social criada pela empresa MV Informática Nordeste. 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. Ademais. 6. com poucas.3. RUÍDOS Os ruídos podem contaminar as variáveis durante o experimento. as fases de projeto e codificação ainda não haviam iniciado. ou seja. clínicas. a empresa se colocou à disposição do experimento. e 130 . antes mesmo que esta obtivesse conhecimento do planejamento do estudo. A MV é uma empresa com mais de 25 anos no mercado de desenvolvimento de software para gestão hospitalar. 2002). como já indicado anteriormente. Estes ruídos são erros que ocorrem de forma não intencional e sim inesperada durante o estudo (TRAVASSOS.

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

pois sua função é sugerir acontecimentos sociais (festas) aos usuários conforme a localização dos mesmo. Os principais resultados e efeitos deste projeto piloto serão detalhados em seguida. pois que. ele captura o grafo de amizade codificando os relacionamentos entre os objetos deste grafo.4. O projeto piloto foi executado sobre uma App de mercado que não foi desenvolvida por uma fábrica de software. EXECUÇÃO 6. a artista favorito.4. 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. haja vista ela mapeia até as ligações de amizade entre os usuários da rede.1. é possível revelar e indicar festas que amigos de um determinado usuário foram. 6. 2001). PROJETO PILOTO O projeto piloto é a execução da experimentação em outro ambiente. A aplicação tratada neste experimento utiliza o Facebook de forma inteligente. 2012. e às festas frequentadas. e que possivelmente este usuário possa querer ir. 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. preocupação ou estresse dos participantes durante o experimento. físico. 132 . Tal App chama-se HobNob. Experimentação das Práticas O preparo acima mencionado.Capítulo 6. precisa saber sua localidade e os gostos pessoais em relação à música. Esta validade se refere ao cansaço mental. Essa App é uma aplicação dedica ao Facebook. ou seja. Sua implementação e desenvolvimento podem ser atestados na íntegra no trabalho de Misael Neto. O HobNob precisa de informações básicas de uma pessoa. este é um aplicativo com escopo bem delimitado. 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. com outras pessoas e com outra unidade experimental (JURISTO e MORENO. Por este parágrafo é possível observar que o HobNob é uma Máquina Social Prosumers por natureza. Deste modo. ou vão. mas trata-se de um projeto realizado por um profissional da área de TI. todos os envolvidos poderiam participar de outros projetos concomitantemente ao experimento.

se encontra o Editor de formulário/telas.0. Ao final da execução deste projeto.1. ou simplesmente MVPEP. uma prática foi adicionada.2. foi possível notar que o uso de práticas como a de SM’s foi algo inédito para o desenvolvimento. pois. deve-se relatar que todas as práticas foram seguidas. Desta forma. mas. o Editor desenvolve telas. como por exemplo. logo que. a adoção da AR foi mais proveitosa em relação às práticas. ou seja. Ainda sobre os ajustes efetuados após este projeto piloto. ou 133 . ESTUDO DE CASO EDITOR DE FORMULÁRIOS/TELAS – MVPEP 6. 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. Isto pode ser explicado pelo fato do desenvolvedor ter um grande conhecimento sobre as tecnologias que podem ser empregadas sobre as SM’s. 6. Os relatos acima foram observados e registrados durante o projeto. Apesar deste fato. a mesma é identificada como prática 10 e faz referência ao uso de NoSQL. o emprego de ESBs. Este trouxe como maior resultado a detecção de uma falha no planejamento.Capítulo 6. 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. 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.4. Assim. o conhecimento sobre serviços.4. foi algo novo no desenvolvimento. que é a proposta das práticas. Entretanto. o conjunto de práticas foi seguido. o desenvolvedor se sentiu seguro o suficiente para uma leitura superficial das práticas. Para o projeto piloto. houve a percepção da ausência de uma recomendação.2. entretanto. Experimentação das Práticas Neste projeto inicial. nem todas foram lidas em sua completude. e elas foram plenamente compreendidas na ordem em que foram documentadas no capítulo 5. os conceitos relacionados à serviço sempre estavam atrelados aos fatores mais técnicos da codificação em si. Preparação No sistema de prontuário eletrônico de um paciente. O Editor é responsável por criar ou desenvolver funcionalidades que não são supridas pelo MVPEP. pois estas não agregaram um ganho significativo para a modelagem da SM.

é possível que os profissionais de TI do hospital. montando um o relatório de erros encontrados nos componentes entregues. Além disto. Dentro deste prazo. e apresentam um resultado satisfatório ao usuário. Para melhor entendimento dos motivos pelos quais o Editor é considerado uma Máquina Social. a primeira fase do projeto deveria ser entregue em dezembro de 2011. O Editor é altamente interoperável. o MVSOUL. pois não é apenas ao MVPEP que o Editor precisa estar interligado. Neste. Nele o usuário desempenha todas as funções necessárias para criar documentos ou telas. Com o Editor. um analista de sistemas. A MV determinou um período de tempo pequeno para desenvolver o Editor. comparações de dados. um arquiteto. sendo que o início do projeto foi em setembro de 2011. fazem um determinado processamento. clínica ou UPA possam construir uma tela com vários recursos. e 2 (dois) programadores. mesmo porque a equipe de testes da empresa recebe uma build a cada mês. tabelas e marcação de imagem (onde se marca na própria imagem a parte afetada em um trauma corporal). os parâmentros eleitos na variável alternativa foram registrados em um formulário próprio para que os valores fossem pontuados nos mesmos. desde cálculos.Capítulo 6. As entregas do Editor deveriam ser mensais. o Editor formata os relatórios e formulários que exibem os dados de exames de imagem e de laboratório. o Editor pode apenas montar layout de formulários. 134 . será apresentado a seguir algumas poucas funcionalidades do Editor. Experimentação das Práticas pequenos programas de software que aceitam entrada de dados. A figura 24 demonstra a área de trabalho do Editor. fator relevante para a seleção do projeto como estudo de caso. A equipe responsável pela implementação do Editor é composta por 4 (quatro) pessoas. respostas automáticas de questionamentos. trazendo para uma página todos os componentes já criados por outras funcionalidades do sistema que abriga o Editor. O mesmo é repassado aos gestores. ele ainda necessita ser inserido em outro grande sistema da MV. Neste momento.

5) A Figura 25 o Editor é exibido na sua forma de utilização final. Documento/tela do Editor sendo utilizado por um usuário final no MVPEP (VERSÃO 1. ela representa uma tela com formulário a ser preenchido pelo usuáiro final na utilização do Editor pelo MVPEP. Figura 25. Experimentação das Práticas Figura 24.5) 135 . Editor no modo de criação de documentos no MVPEP (VERSÃO 1.Capítulo 6.

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

na MV não existia a prática de formular um documento de decisão arquitetural no qual a arquitetura seria baseada. Ou seja. as alterações foram sutis. Os participantes demonstraram a necessidade de conhecer esses conceitos para que as práticas fossem aceitas e fizessem sentido. mas pode também ser um forte indício de sua feliz aplicabilidade.2. O Editor é uma Máquina Social completa e repleta de particularidades que podem não se repetir em outras SM’s. mas poderiam estender a arquitetura. processamento. Por exemplo: o Editor se incorpora ao sistema de Prontuário de Pacientes com a finalidade de produzir telas com entrada. Tal camada deveria ter componentes dedicados a cada sistema no qual o Editor deveria interagir.Capítulo 6.3. 6. Alem disto. fazendo os resultados da mesma sofrerem influência. houve um esboço da arquitetura Editor_Core. funcionalidades não existentes no PEP. mesmo a equipe estando com um nível de estresse mais elevado. como o cálculo e armazenamento da massa corporal de um paciente. a arquitetura do Editor. isto certamente ocasionava alguns 137 . que foi amadurecendo ao passo que as práticas e AR foram compreendidas e atendidas. 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. De fato todos estavam mais seguros quanto aos requisitos e aos problemas da aplicação.4. 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. Experimentação das Práticas arquitetural. 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. sendo que. pois poderia atrapalhar a averiguação das variáveis. Em seguida. uma vez que conduziria a equipe a um cuidado maior na segunda rodada de experimentação com a metodologia de SM’s. 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. A preocupação foi uma ameaça prevista. foi possível que uma arquitetura mais adequada fosse definida. a arquitetura de referência foi visualizada e compreendida. e saída de dados. É importante frisar que alterações em requisitos não caracterizaram uma alteração brusca do que já havia sido analisado anteriormente. isto pode ser uma desvantagem para o objeto de controle. Mesmo assim.

Capítulo 6.  A fase de definição de arquitetura foi desenvolvida resultando em uma documentação útil à manutenção do Editor. MVPEP e o MVSOUL foram descobertos no momento da análise arquitetural.  Verificar a necessidade da modelagem de negócio. obrigando a equipe a modelar alguns processos de negócio.  Os problemas de integração entre Editor. Entretanto. as decisões do projeto Editor foram geradas pelas práticas das SM’s em si. sem. Prática 5: Determinar os recursos que implementarão os elementos States e Constraints. 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. como ocorreu quando não foram utilizadas as práticas e AR. Deste modo. e não no momento da integração. ter levado muito tempo para ser completada. as práticas 343. a definição de como alguns serviços seriam providos foi deficitária. Experimentação das Práticas retrabalhos em determinada fase do desenvolvimento. pois esta fase é geralmente omitida em alguns projetos de software da MV. Prática 7: Determinar o recurso que proverá a comunicação e interoperabilidade. no entanto. 544 e 745 contribuíram fortemente para isto. Apesar da equipe responsável ter grande experiência com Design Pattern. 45 138 . proporcionando uma adoção mais rápida. e demonstrando muita eficiência para o Editor. os padrões foram classificados com a prática 9.  Os padrões de projeto mais adequados às SM’s foram estudados.  As facilidades que Cloud Computing poderiam trazer ao desenvolvimento do Editor foram notadas. os recursos de CC ainda é algo fora da 43 44 Prática 3: Conhecer os provedores de serviço da aplicação. como o caso do padrão Adapter. Na verdade. Ainda por meio do acompanhamento direto do projeto Editor e também do conhecimento a respeito de outros desenvolvimentos na MV. o que não houve com a adoção das práticas e da arquitetura de referência. para a MV.

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

assim. Na MV. a comunicação e adaptabilidade aos sistemas da MV. a empresa não tem nenhuma ação ou planejamento para empregar tal paradigma nos projetos atuais e futuros do portfólio da empresa.OSGi que contribui para o desenvolvimento de aplicativos modulares e orientados a serviços (OSGi ALLIANCE. 46 Maven é uma ferramenta que controla a entrega de códigos funcionais. Muitas ações ainda podem ser geridas para ajudar o trabalho da MV. e o estudo de plataformas como o Open Services Gateway Initiative . 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. 2005 ). 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. 140 . são poucos os profissionais habilitados a trabalhar com Cloud Computing. Experimentação das Práticas Máquina Social por todos os aspectos da aplicação. Para o projeto Editor este erro não ocorreu. Sendo assim. este estudo mostrou a este trabalho de arquitetura e SM’s. A MV não pensa em serviços na hora de construir suas aplicações. Outro ponto que também é negligenciado e que foi visualizado e compreendido pela equipe foram as regras de negócio. a MV ainda precisa estar atenta a todos os outros projetos de desenvolvimento espalhados pelas equipes que compõem a fábrica. Uma evidência disto foi revelada pela prática 8. como alguns assuntos ainda são pouco explorados na realidade da indústria de software local. Além disto. O experimento contribuiu fortemente para este pensamento. em que a primeira prática solicita a modelagem de alguns processos que atenderam aos serviços.Capítulo 6. sobretudo. 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. a modelagem do negócio geralmente era afetada e gerava retrabalho. 2008]. com isto ele proporciona o gerenciamento e a automação de projetos de software [SONATYPE. Além disto. 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. Entretanto. no último período do ano de 2011.

Manutenções demoradas. 6. 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. 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. Requisitos mal trabalhados. mas sim. No entanto. foram resolvidos 5 (cinco) para o Editor da MV. O estudo de caso foi sobre uma equipe atrelada a métodos já tradicionais de desenvolvimento e tecnologias impostas pela própria empresa. Neste momento. tal SM se saiu bem nas etapas de teste de software e validação do produto entre os clientes. não basta conhecer a teoria e compreender as características de SM’s. o caso Editor agregou muito conhecimento à equipe responsável. Experimentação das Práticas Por fim.5. conceito ao qual esse profissional já está habituado. 141 . Uma primeira versão do produto já será homologada em meados de maio de 2012. Ficou nítida a contribuição das práticas no estudo de caso. dos 7 (sete) problemas detalhadamente pontuados na problemática desta pesquisa. onde esses profissionais estão familiarizados aos recursos disponíveis.Capítulo 6. os problemas apresentados ao final do experimento com as práticas e AR de SM’s foram no requisito de usabilidade. Ausência da arquitetura. mostrando indícios de que o projeto é longo e muito ainda deve ser feito para que o Editor seja uma Máquina Social excelente. Falta de adequação da SM na resolução de problemas. 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. 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. Além disto. através do experimento um número significativo de idéias surgiram dentro da empresa.

142 . revelou sua real contribuição. 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. em seu conjunto de conceitos. as práticas e arquitetura de referência. Demais considerações sobre este experimento serão publicadas na conclusão do trabalho que vem em seguida. neste contexto.Capítulo 6.

especialmente a sua contribuição. Aqui estarão algumas reflexões finais sobre o trabalho.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. 143 . e as indicações dos futuros trabalhos. Vale ressaltar que muitas considerações já foram abordadas nos tópicos conclusivos de cada capítulo.

Para exemplificar esta idéia. Conclusões e Trabalhos Futuros Ao fim dessa pesquisa. Segundo por esclarecer que. Primeiramente a abordagem de conceber aplicações WEB como SM se mostrou adequada por dois motivos: primeiro. serviços às áreas remotas da circunscrição. um projeto puramente brasileiro coordenado por Oswaldo Oliveira.br/ http://smeira.0 e 3. Neste ponto. através de SM’s.com. ambientes e conexões disponíveis na nuvem computacional da internet. Conecta pessoas. por meio da Internet. pontos que nem sempre possuíam a devida atenção. cabe aqui concluirmos que as abordagens tecnológicas de SM’s talvez não sejam tão inovadoras. Tem como missão oferecer soluções que viabilizem a evolução sustentável de quem quer articular. o qual classifica a Empresa Teia48 como: A empresa teia é uma infraestrutura completa para quem quer desenvolver um projeto em rede. muitas questões se destacam e serão pontuadas no decorrer desta consideração final. possibilitando que outros serviços sejam criados e problemas antigos sejam tratados. A Empresa Teia conecta as pessoas de modo que elas possam prestar serviços concomitantemente utilizando a Web 2.br/ 141 . fazer negócios ou trabalhar em rede.0 para isto. a própria página online do projeto Teia é uma SM. o projeto Teia. seja possível reinventar projetos em rede. vale tomar nota do web site chamado “Empresa Teia47”. o que é moderno é a forma de se pensar e usar tal 47 48 49 http://empresateia.com. levando. Isto é. serviços. 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.Capítulo 7. promover o negócio de SM. processos. possibilitar que dois desenvolvimentos de SM’s focassem em pontos fundamentais para as SM’s. materializa o negócio que envolve as Máquinas Sociais.terra. além de inovador. Através dela é possível disponibilizar App’s úteis à pessoas ou empresas que façam parte da rede Teia.blog. Faz isto utilizando ferramentas. instituições e empresas que querem se integrar nos fluxos da sociedade em rede independentemente do nível de maturidade em que estão.br/2010/12/08/empresa-teia-como-assim-final/ http://teiamg. Este projeto já mostrou a sua força. Portanto.com.

É clarividente que há muito para se evoluir no conceito de SM’s. Nesta dissertação as práticas se revelaram como forte contribuição para a resolução de alguns problemas já citados. Disseminar as práticas em trabalhos futuros poderá também revelar outros benefícios em desenvolvimento de SM. Com mais estudos de caso será possível verificar pontos que possam ser amadurecidos na metodologia e no próprio conceito de SM. que não deve ser burocratizada. Porém todos os profissionais envolvidos devem entender melhor o que é CC. A partir desse ângulo. O parágrafo supra remete aos trabalhos futuros. Máquinas Sociais são aplicações distribuídas em rede. 142 . possibilitando assim. Outro ponto importante é a manutenção das SM’s. a segurança continua sendo um ponto a ser vigorosamente pesquisado e trabalhado. onde surge a preocupação no compartilhamento de documentos e. mais do que isto. será possível divulgar e empregar fortemente o Framework de SM. sobretudo. Quanto à segurança. esta dissertação se mostra totalmente relevante. Vale salientar que. tanto das SM. Para atender a este requisito o uso de Cloud Computing é fortemente indicado na concepção das SM’s. Por esse motivo e outros. Realisticamente o framework requer um trabalho forte de implementação e documentação. houve certa dificuldade em se encontrar projetos de SM que se pudesse acompanhar a evolução. a disseminação do uso do mesmo.Capítulo 7. 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. Um exemplo disto pode ser detectado no estudo de caso da empresa MV. 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. quanto das informações geradas por elas. nos aspectos voltados à Cloud Computing e nas questões de segurança. para esta pesquisa. vez que alguns trabalham com informações confidenciais e delicadas a um paciente. O acesso a elas deve ser facilitado. mormente no conteúdo que leva cada documento. Conclusões e Trabalhos Futuros aparato tecnológico para serviços que podem ser distribuídos em rede. nestas concepções futuras há espaço para experimentar em mais projetos as soluções propostas.

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

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. Entretanto fica a necessidade de se replicar o experimento como trabalho futuro. capazes de manter a evolução dos negócios.Capítulo 7. onde não se conhecia exatamente os efeitos do experimento. Conclusões e Trabalhos Futuros primária para empresas tradicionais de TI extremamente amarradas a fatores. e na manutenção das aplicações que deveriam ser interligadas. Sendo assim.0. O experimento possibilitou a resolução de alguns problemas a partir do momento em que auxiliou na identificação dos serviços. Por fim. proporcionando o amadurecimento na concepção de sistemas Web 3. em outros trabalhos. problemas voltados à ausência de questões de banco de dados. proporcionando melhorias na interoperabilidade. O estudo experimental foi muito proveitoso. Com isto. 144 . foi o mesmo ter tido um planejamento e ser documentado no formato adequado. com todas as suas seções. e também apesar das ameaças a validade terem sido reais. o objetivo foi alcançado ao passo que contribui para o desenvolvimento de ao menos uma Máquina Social real. apesar de ser exploratório. A experimentação auxiliou na identificação de problemas no conjunto de práticas. este trabalho amadurece todos os conceitos relacionados a SM. é possível aproveitar o planejamento e formato do estudo. O mais importante. como: pressão organizacional e política empresarial. e o que de fato valida o estudo. particularmente os relacionados ao modelo de desenvolvimento de Máquinas Sociais. e principalmente pelo motivo da empresa ter acreditado no experimento. com idéias modernas. e enxergar ganhos qualitativos com as práticas e arquitetura propostas.

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

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

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

1998. 696 p. 2009. LEAVITT. Max. Volume: 26. Rio Grande do Sul: Bookman. 2007. 2009. Eric.org>/. ZHU. Chen (2010). Lingzhi.> Acesso em: 01 jul.org/citation. Disponível em: <http://www. 2011. 2010.org/Xplore/login. No to SQL? Anti-database movement gains team. 2007. In Computerworld. Farzana. 2010. Martin. 144 . Informações especializadas sobre a ferramenta JSON. Eucalyptus: a Web service-enabled e infrastructure. Disponível em:<http://www. 1ed. Germany. João Carlos. LAITENBERGER. Ne.json. Yong. Ana. David. 43. 2011.org/Resource_Center/newsletter_articles/200802 /Kat_e_McPherron_Software_as_a_Service. Natalia. DEBAUD. MERRIL.computerworld.edu/~jimmylin/MapReduce-book-final.pdf%3Farnumber%3D5290797&authDecision=-203> Acesso em: 03 mar.cfm?doid=1321211. LARMAN.short> Acesso em: 13 set.acm. 12-14.ieee. Mashups: The new breed of web app.oxfordjournals. LAI.ieee.Referências Bilbiográficas JSON. Cytoscape Web: an interactive web-based network browser. In:WICSA/ECSA. Secuirty Storage in the Cloud Computing : A RSA-based Assumption Data Integrity Check without Original Data. In Morgan & Claypool Publishers. XU. LIANG. LIANG. 2011. Feb. Disponível em: <www1. 1. Yan. and Patterns: Capturing and Using their Synergistic Relationships for Product Line Architectures.1 ed. Chris. LIU. Software-as-a-Service (SaaS): The New Paradigm for the Software Industry. Kaiserslautern. JIANHONG. Disponível em:<http://ieeexplore. LIN. MORENO. Z. ed.umd. Fraunhofer Institute Experimental Software Engineering. Acesso em 09 jan. 2008. Sandy. Next Generation Application Integration: From Simple Information to Web Services. Kate. MORRIS.umiacs. 229 p. 2004 MCPHERRON. Jean. Using Architecture Integration Patterns to Compose Enterprise Mashups.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam>. Data-Intensive Text Processing with MapReduce. Disponível em:< http://www. LIU. In Conference ICEIT 2010. STAPLES. 2010.org/content/26/18/2347.com/developerworks/web/library/x-mashups. Acesso em: 13 abr.jsp?url=http%3A%2F%2Fieeexplore. JOSUTTIS. LINTHICUM. no.ed. Sylva. Disponível em:< http://www. DONALDSON. SOA na Prática: A Arte da Modelagem de Sistemas Distribuídos. Disponível em: http://dl.1321213. Publisher: Oxford University Press. 2011. Gary. 2003. 2011. Basics of Software Engineering Experimentation. Nicolai. Acesso em: 22 ago. Pages: 2347-2348. LOPES. JURISTO. 2. HUA. Duane. DYER. Christian. 2011. 2011. Arquitetura Orientada a Serviços. Quality Attributes. Quaid..sao.USA: Pearson Education.php. 2001.org%2Fiel5%2F5275158 %2F5290660%2F05290797. Will NoSQL Databases Live Up to Their Promise?. Rio de Janeiro: Editora Moderna. vol.pdf>.html> Acesso em: 07 mai. Xin. FRANS. KAZI. 2ª Ed. Utilizando UML e padrões: Uma introdução a análise e ao projeto orientados a objetos. 3ª. USA: Kluweer Academic Publishers. Rio de Janeiro: Jacaré. BROOKS. Acesso em: 10 jun. 2010. Disponível em: < http://bioinformatics. Computer. In CASCON ’07: Proceedings of the 2007 conference of the center for advanced studies on Collaborative research. pp. O. Craig. BADER.ibm. Liming. Jimmy. In Bioinformatics (2010). 2009. LAZZERI. Scenarios. 2007. M. Issue: 18.

JAHANIAN.hp. 597–608.gov/groups/SNS/cloud-computing>. In National Institute of Standards and Technology. 2005. FIGUEIREDO.pdf> Acesso em: 27 jun. Disponível em:<http://www.com/b/nick_wong/archive/tags/event+announcements/. MORAIS. 243 p. EF. Disponível em:< http:// http://www. Peter. Empresa ―Teia‖? Como assim?.com/intl/pt-BR/press/. Acesso em: 01 mar. Uma Contribuição ao Projeto Arquitetural de Ambientes de Engenharia de Software. 2011. SINGHAL. 2005. PIGNEUR. Disponível em: http://smeira. 26-27). SOARES. B. BUREGIO.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20. NETO. ENCARNAÇÃO. M.com/techreports/2009/> Acesso em: 21 fev. 2005. Tese de Doutorado. Acesso 16 out de 2010.Referências Bilbiográficas MEIRA. MULLER.. Acesso em: 30 ago. K.blog. GRANCE. R.msdn. In: Proceedings of Grid and Cooperative Computing Workshop.br/~nivio/cursos/pa03/seminarios/seminario7/seminario7. G.netlab. Sharad.html>. 2010.pdf>. Dia a dia. OSGI ALLIANCE. Acesso em: 17 ago. Outsourcing Business to Cloud Computing Services: Opportunities and Challenges. Y. 2011. 2011.gov/index. Instituto de Ciências Matemáticas e de Computação. M. 2011. E. HPL 23. In SS’08: Proceedings of the 17th conference on Security symposium.pdf>.com/> Acesso em: 14 nov. Apresenta informações especializadas sobre a Microsoft. 145 . 2009. NAKAGAWA.google. MELL. Site que monta pesquisas e exibe estatísticas sobre a Internet e sobre aplicações em geral. 2008. Cloudav: N-version antivirus in the network cloud. Disponível em:< http://csrc. Alexander. NASCIMENTO. Disponível em:<http://homepages. Bit a bit. Acesso em: 06 mai. Acesso em 07 dez. Em: http://blogs. In Communications of AIS. 2009. L. Article 1. Draft NIST Working Definition of Cloud Computing. 2010. ICMC-USP/SãoCarlos. Christopher.. MOTAHARI-NEZHAD. Disponível em:< http://www. Systems Architecting: A Business Perspective. OSGi Service Platform Release http://www.edu/fjgroup/pubs/usenix08-cloudav. IEEE 35th Annual Computer Software and Applications Conference (pp. Evaluation Issues in Autonomic Computing. Acesso em: 04 abr.COM. Disponível em: < http://www.. (2008).netcraft. 2011. Blog do professor Silvio Romero de Lemos Meira.softwarepublico. Página da Agência governamental de administração da tecnologia. Gerrit. GARCIA. . 2011. Acesso em: 04 out. M.hpl. L. Diponível em: http://www. 2006.. 1 ed.terra.nist. 2011. MEIRA. What is web 2. Disponível em: PERTERSEN.br/5cqualibr/6-publicacoes-e-artigos/view/vetor-ecossistema/sobre-modelo-deneg-cios/Claryfing-Busines-Model. 2008. O’REILLY. V. Tim. Acesso em 19 set.eecs. 8 dez.0. S. 2010.. MCCANN. Evan.gl/YcIB6>.br/2010/12/08/empresa-teia-como-assimfinal/. 2011 OBERHEIDE. and future of the concept. Julie.ufmg. MICROSOFT COMMUNITY BLOGS. HUEBSCHER.fi/opetus/s384030/k06/papers/EvaluationIssues.. Clarifying business models: origins. NIST. p. Disponível em: <http://news. Web semântica para máquinas de busca. 4. 2010.oreillynet. In HP Laboratories. In Proceedings of the 12 th Internacional Conference on Evalution and Assessment in Software engineering.org/Main/HomePage. OFFICIAL GOOGLE BLOG. OSTENWALDER. MB. Jon.html> Acesso em: 15 jun. Markus.dcc. 2011.tkk. Volume 15. 2010. Farnam.osgi. The Emerging Web of Social Machines. 2011. COOKE. Disponível em <http://www. Disponível em: < http://goo. Hamid.com. TUCCI. Contém informações especializadas sobre a Google Corporate em: http://www. Systematic Mapping Studies in Software Engineering. Yves.gov. 2011. STEPHENSON. E. 2004. Tim. NETCRAFT.nist.pdf Acesso em 05 set. Bryan.umich. present. Silvio.

2009. SEVERINO. Distributed Systems: Principles and Paradigms. 2011.480 p. HELLERSTEIN. 1 ed. Readings in Database Systems. SONATYPE. 146 . Engenharia de software e sistemas de informação. 4ª ed. Encapsulators: A new software paradigm in Smalltalk-80. 1 ed. Denis Alcides. Boris. 1986. TAURION. Disponível em: <http://www. 1 ed. Canada. 2005. 1ed: Wiley Publishing. Inc. Prentice Hall. GUROV. 327. 568 p.ieee. 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. 1. Systematic Reviews in the Social Sciences: A Practical Guide. Michael. REZENDE. 780 p. Redes de Computadores. Informações especializadas sobre a linguagem Rails. Web Engineering: A Practitioner's Approach. pagina 341-346. São Paulo: Prentice-Hall. GARLAN. 7ª ed. Metodologia do Trabalho Científico.pro.Referências Bilbiográficas PETTICREW. Disponível em: http://ieeexplore. PRESSMAN. 2011. 2002. 23ª Ed. Cloud Computing: Coud Computing . 1996. Roger.acm. Roy. 228 pg. 247–251. H. Purnendu. São Paulo: Editora Atlas. 1.p ROSEN. Antônio Joaquim. Micael. Engenharia de Software: uma abordagem professional. 2ª ed. Acesso em: 21 abr. Edgar. Ed. São Paulo: Bookman. Acesso em: 14 abr. David. TANENBAUM. PASCOE. Autonomic Computing. 9ª ed. São Paulo: Pearson. Dmytro. In WETICE '10 Proceedings of the 2010 19th IEEE International. 2008. 2008.jsp?arnumber=1194805. LUBLINSKY. Rio de Janeiro: Brasport.org/citation. Blackwell Publishing.rubyonrails. TRAVASOS. Andrew. RAILS. Universidade Federal do Rio de Janeiro. 2008. LOWE. SARATHY Vijay. STONEBRAKER .org/xpl/freeabs_all. SOMMERVILLE. Kevin. São Paulo: Editora CORTEZ. Relatório Técnico. In Object-Oriented Programming Systems. David. MIKKILINENI. p. Geoffrey.ed: O’ Reilly. 2006. Roger. Next generation Cloud Computing Architecture: Enabling real-time dynamism for shared distributed physical infrastructure. Denis.Computaçao em Nuvem: Transformando o Mundo da Tecnologia. SMITH. languages. NARAYAN. Ian. Mary.A Means of Achieving Dependability?. 4ª Ed. 4ª ed: Morgan Kaufmann. 2011.cfm?id=28731> Acesso em: 04 jun. 2003. BUSTARD. BALCER. Applied SOA: service-oriented architecture and design strategies. 3ª ed. Engenharia de Software. 2011 REZENDE. M. David. STERRITT. TANENBAUM. Disponível em: < http://dl. Marc. Rio de Janeiro: Editora Campus. 2005. SHAW. AMARAL. ROBERTS. Maven: The definitive Guide. Joseph. Engenharia de Software Experimental. and Applications Conference Proceedings. 2011. Rio de Janeiro: Editora Brasport. São Paulo: McGrawHill. 2003. 2010. 2005. PRESSMAN. Company. Andrew. Cesar. Rao. In: Proceedings OF IEEE International Conference ON THE Engineering Of Computer Based Systems (ECBS’03). 2008. Guilherme. Software Architecture – Perspectives on an Emerging Discipline. 2002.br/> .

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

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

assim. 152 . a prescrição médica que utilizará o documento. b. Disponibilizar modelos de documento e telas formatados para os clientes. Ajustar a aparência de documentos e telas. 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. c. 2. Serviços Requeridos: a. Registro de laudos de exames. Provimento de informações específicas para se utilizar um documento. Processar dados específicos de um segmento hospitalar.Anexos ANEXOS ANEXO 1. Serviços Providos: a. b. é necessário saber se existe. e qual é.

essa mescla só ocorreu na primeira camada da aplicação.  Sistema MVPEP por necessitar das informações da prescrição médica. 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. módulo PAGU. 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.  Sistema MV2000. é indício de que algo aconteceu aos repositórios.  Implementar sensores na camada de persistência que dispara um time a toda solicitação à base de dados. caso a resposta demore. mas algumas ações contribuem diretamente para a visualização do estado do SM. 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. bem como. e o Editor se prepara para acessar possíveis backups. a visualização das características do mesmo. 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.  Sistema MVSOUL (tecnologia Java/Flex/Web Service) onde os laudos são registrados. para resgatar informações de perguntas.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. 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. 153 . os dados estão registrados em tabelas diversas. auxiliando na disponibilidade. Os estilos adicionais são: Pipes and Filters e Publisher-subscriber. Tais iniciativas são:  Utilizar Cluster de alta disponibilidade. entretanto. e na comunicação.

Prática 9: Selecionar os padrões de projeto mais adequados para a arquitetura da Máquina Social Padrões mais utilizados: 1.  Utilizar o recurso nativo do Adobe Flex. pois falta uma pesquisa adequada para verificar a viabilidade do uso deste novo paradigma na MV. ambas tecnologias exploradas pela MV. 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. Prática 10: Selecionar o banco de dados não relacional Não foi seguida ou executada 154 . o AMF com auxílio do BlazeDS. uma tecnologia que viabiliza a comunicação com o back-end distribuído de dados da aplicação. 2. O BlazeDS é um servidor baseado em Java Remoting and Web Messaging. como JavaScript e AJAX. bem como. O BlazeDS pode ser utilizado com outras plataformas de cliente. 3.  Inserir duas camadas de comunicação na arquitetura. Observer: para a gerência dos estados entre os objetos. estas irão prover a interoperabilidade entre o Editor os sistemas.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. Adapter: para adequar as interfaces de comunicação entre os sistemas. do custo de adotar Cloud. State e Singleton.

e no Google Map. Dados ou informações das pessoas. d. Servidor de chat.  Configurar bem o Apache para obter controle de log. o fluxo de negócio não foi algo tratado na concepção e análise do HobNob. 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.Serviços Requeridos: e. 3. afim de. e os mais freqüentados. g. Lista de amigos de rede social. e controle de sessão em banco de dados (segurança). Sugerir festas e eventos musicais pela cidade de recife. prover o autogerenciamento:  Usar o Framework de SM para obter tolerância a falhas. Prática 2: Reconhecer os serviços providos e requeridos para o funcionamento da Máquina Social 1. Classificar os eventos: classificar os mais procurados.Serviços Providos: c.Anexos ANEXO 2. f. procurado ou visualizado nas redes sociais. 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. Links: o que foi acessado. 4. 2. Google Map. 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.  Aplicar boas práticas de programação. 2. Facebook. Servidor de banco de dados. 155 . Prática 3: Conhecer os provedores de serviço da aplicação 1.

balanceamento de carga. 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 8: Selecionar o recurso Cloud Computing a ser adotado na SM Utilizar os serviços da PaaS Rackspace. além da inserção do Framework para Máquinas Sociais. existem 5 níveis de estabilidade.. 156 . e armazenamento. com o uso será estabelecido níveis de qualidade e estabilidade para os serviços. Prática 7: Determinar o recurso que proverá a comunicação e interoperabilidade  WebServices com REST. estes se baseiam no tempo de resposta de cada solicitação. Prática 6: Analisar se apenas o estilo arquitetural Camadas é suficiente para atender a Máquina Social: Sim. SO Linux.Anexos Prática 5: Determinar os recursos que implementarão os elementos States e Constraints: Usar o Framework para Máquinas Sociais. como: backup.  Adoção de Json. Esta ofertou melhores opções em relação ao valor cobrado. apesar a arquitetura em camadas foi utilizada. entre outros parâmetros.  Facade. Prática 9: Selecionar os padrões de projeto mais adequados para a arquitetura da Máquina Social Padrões mais utilizados:  State. houve uma customização desta.  Singleton.

componentes e conectores. 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. implantação Arquitetura de referência para Máquinas Sociais Nº Item de Questionamento SIM NÃO NÃO SE APLICA 1 Ao analisar todos os diagramas. 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.Apêndices APÊNDICES APÊNDICE A. ou representadas de uma forma 157 . foi identificado algum elemento arquitetural que não possua relacionamentos. CHECKLIST DE AVALIAÇÃO ARQUITETURAL – VERSÃO 1 IDENTIFICAÇÂO Arquitetura a ser avaliada: Inspetor: Visões a serem avaliadas: módulos.

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. repositórios. 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 . API’s) são utilizados como mediadores de comunicação entre os elementos arquiteturais. 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.

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. 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. 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. componentes e conectores. implantação Arquitetura de referência para Máquinas Sociais Nº Item de Questionamento SIM NÃO NÃO SE APLICA 1 Ao analisar todos os diagramas. ou representadas de uma forma mais simples não expandida? Ou seja. foi identificado algum elemento arquitetural que não possua relacionamentos.Apêndices APÊNDICE B. ocorre uma representação por meio de diagrama de classes ou de componentes e conectores com interfaces requeridas 159 . em algum diagrama.

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. servidores de nomes. 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. são utilizados como mediadores de comunicação entre os elementos arquiteturais. repositórios e API’s. 6 Ao analisar as seqüências de execução descritas em uma visão de interação.Apêndices e providas. camadas e demais componentes que constituem as visões arquiteturais. classes. 160 .

foram feitos 4 (quatro) casos de teste.Apêndices APÊNDICE C. Adequação concebida metodologia Social. 161 . assim. ou seja. O quantitativo de 4 (quatro) é referente a todos os casos de testes que foram contemplados. para todos os quatro o resultado desejado foi atendido. VALORES MONITORADOS NO EXPERIMENTO PARÂMENTROS COM METODOLOGIA TRADICIONAL COM METODOLOGIA DE SM 7 Número de requisitos da SM trabalhados pela arquitetura. não houveram defeitos encontrados. da por à arquitetura meio na 4 2 4 Máquina OBS.

ARQUITETURA DE REFERÊNCIA ANTES DAS AVALIAÇÕES 162 .Apêndices APÊNDICE D.