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

UFPE - UNIVERSIDADE FEDERAL DE PERNAMBUCOCIN - 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 PERNAMBUCOCIN - CENTRO DE INFORMÁTICA

PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Elaine Gleyce Mira de Figueiredo

PRÁTICAS PARA A ESPECIFICAÇÃO DE ARQUITETURAS DE SOFTWARES NO CONTEXTO

DE MÁQUINAS SOCIAIS PARA A WEB 3.0

Dissertação apresentada como requisito parcial para a obtenção do título de Mestre em Ciências da Computação, área de concentração em Engenharia de Software pelo Programa de Pós-Graduação em Ciências da Computação do Centro de Informática da Universidade Federal de Pernambuco

Orientador: Silvio Romero de Lemos Meira,

PhD

Co-Orientador: Vinicius Cardoso Garcia,

PhD

RECIFE

AGOSTO DE 2012

À Laysa

AGRADECIMENTOS

Primeiramente agradeço a Deus e à Nossa Senhora de Nazaré por estarem presentes

em nossas vidas nos dando saúde e luz.

Muitos não sabem o que é concretizar um trabalho desta natureza, e talvez por este

motivo não vejam com admiração pessoas que, como eu, dedicaram dois anos de sua vida a

um mestrado. Entretanto, existem outras pessoas que valorizam o estudo e o amor a uma área

da ciência por acreditarem justamente que trabalhos como este podem agregar na vida, no

ensino, na indústria, e no saber; são para estas pessoas que deixo meus sinceros

agradecimentos.

Aos meus amados pais pelo cuidado e apoio de sempre.

Ao meu admirado orientador Silvio Meira, por me contagiar com a inquietação de

sua mente, e por se fazer sempre presente mesmo que ausente.

Ao meu também orientador Vinicius Garcia, pela exigência de sempre, por me

direcionar e ensinar.

Aos amigos verdadeiros pelo forte incentivo.

À Universidade Federal de Pernambuco – UFPE, que fez a minha caminhada neste

mestrado ser extremamente promissora, pelas condições de ensino oferecidas.

Aos inteligentíssimos Prof. Leandro Marques, Prof. Paulo Borba, Prof. Sergio

Soares, Vanilson Burégio, Misael Neto, e Thiago Vieira; pessoas que sempre estiveram

dispostas a me ajudar, e que de forma direta, contribuiram para a realização deste trabalho.

À empresa MV Informática Nordeste pela confiança.

“Lack of time is excuse for who loses time due to lack of methods”

(Albert Einstein)

“Não acredito em uma arquitetura ideal, insubstituível; somente em boa e má

arquitetura. Gosto de Le Corbusier como gosto de Mies, de Picasso como de Matisse, de

Machado como de Eça.”

(Oscar Niemeyer)

"Nós raciocinamos hoje apenas em termos do que tornaria mais fácil para as

pessoas a utilização do computador. Pode ser que tenha chegado a hora de perguntar o que

tornaria mais fácil para o computadore lidar com seres humanos. Por exemplo: como é

possível conversar com pessoas quando nem sequer se sabe que estão presentes? Você não

pode vê-las, e nem sabe quantas são. Será que estão sorrindo? Falamos desejosos sobre

interações humano-máquina, sistemas dialógicos e, no entanto, estamos dispostos a deixar no

escuro total um dos participantes deste diálogo. Está na hora de fazer com que os

computadores vejam e ouçam."

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

http://pt.wikipedia.org/wiki/Nicholas_Negroponte

RESUMO

A Internet se modifica a uma velocidade considerável, e os responsáveis por tal

transformação são, em grande parte, as aplicações que a compõem. O que conduz ao

seguinte questionamento: os profissionais e pesquisadores de TI estariam suficientemente

preparados para garantir soluções práticas e pertinentes ao desenvolvimento de tais

aplicações? Esta dissertação consiste na recomendação de um conjunto de práticas para se

desenhar arquiteturas de software no contexto de Social Machines, ou Máquinas Sociais

(SM’s). SM’s são aplicações que se relacionam em rede para disponibilizar determinado

serviço. O produto desta dissertação foi fruto de uma extensa pesquisa que se empenhou em

fortalecer os conceitos de SM’s, bem como em desenvolver um estudo de revisão de

literatura que serviu de alicerce para a proposta de uma arquitetura de referência para as

SM’s. Isto posto, práticas foram lançadas afim de auxiliar na customização desta arquitetura

e, principalmente, orientar sobre a construção de SM’s. Todos os conceitos abordados e

resultantes foram fortemente baseados na realidade da Web 3.0, internet que traz alterações

significativas ao modo de se fazer negócio em rede. O que caracteriza a Web 3.0 é a

facilidade em reprogramar suas aplicações e fazer com que elas interajam de forma a

interligar negócios, serviços e pessoas. No contexto da Web 3.0 as SM’ são protagonistas,

tudo neste ambiente funciona por meio destas. Assim, o desenvolvimento desta pesquisa

explora diversos conceitos dentro da engenharia de software, além de exibir duas avaliações

dos artefatos de software gerados pelo trabalho, a primeira executada por meio de um

método de inspeção, e a segunda por meio de um estudo de caso.

Palavras-Chave: Cloud Computing; Web 3.0; Máquinas Sociais; Arquitetura de

Referência; Tecnologias; Aplicações Web; Práticas, Avaliações.

VI

ABSTRACT

The Internet is changing at a considerable speed, and the applications that comprise

it are the most responsible for that, what leads us to the following question: would

professionals and researchers in IT be sufficiently prepared to ensure practical and relevant

solutions to the development of such applications? The current dissertation consists on a set

of recommended practices for designing software architectures in the context of Social

Machines (SM's). SM’s are applications that connect in network to provide a determined

service. The dissertation's product is the result of an extensive research that endeavoured to

reinforce the SM concept and to develop a study of literature review that laid the

foundations for the proposal of a reference architecture for the SM's. In this sense, the

practices have been launched to provide support to the customization of this architecture,

and particularly to conduct the construction of SM's. All adressed and resultant concepts

were strongly based on the Web 3.0 reality, an internet that brings significant changes in

network business ways. The mainly web 3.0 feature is the facility to reprogram its

applications and make them interact to connect business, services and people. The SM’s are

the main element considering the Web 3.0 context; the entire environment works trough it.

Therefore, this research explores different concepts in software engineering, also showing

two software artifacts evaluations: the first through an inspection method, and the other

through a case study.

Keywords: Cloud Computing; Web 3.0; Social Machines; Architecture of

reference; Technologies; Web Aplications; Guidelines, Reviews.

VII

LISTA DE ILUSTRAÇÕES

FIGURA 1. REPRESENTAÇÃO DA ESTRUTURA DE CLOUD COMPUTING..................................16

FIGURA 2. REPRESENTAÇÃO DA MÁQUINA SOCIAL.....................................................................17

FIGURA 3. ESTILO ARQUITETURAL CAMADAS..............................................................................28

FIGURA 4. NUMERO DE ESTUDOS POR QUESTÃO DE PESQUISA...............................................35

FIGURA 5. ARQUITETURA MASHUP POR DUANE MERRIL...........................................................37

FIGURA 6. ARQUITETURA CLOUD COMPUTING POR VECCHIOLA............................................42

FIGURA 7. ARQUITETURA DE REFERÊNCIA PARA CLOUD COMPUTING POR KOSSMANN,

KRASKA E LOESING, 2010..................................................................................................................42

FIGURA 8. ARQUITETURA DE REFERÊNCIA CLOUD COMPUTING PROPOSTA PELA IBM....44

FIGURA 9. ESBOÇO DA ARQUITETURA MULTITENANT...............................................................48

FIGURA 10. ARQUITETURA DO TWITTER.........................................................................................50

FIGURA 11. ESBOÇO DE ARQUITETURA PARA SISTEMAS AUTÔNOMOS.................................54

FIGURA 12. ARQUITETURA DE REFERÊNCIA PROPOSTA PELA EMPRESA IBM PARA

COMPUTAÇÃO AUTÔNOMA..............................................................................................................55

FIGURA 13. ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2.0.............................57

FIGURA 14. RELAÇÃO ENTRE MODELO DE REFERÊNCIA, PADRÕES ARQUITETURAIS E

ARQUITETURA DE REFERÊNCIA......................................................................................................65

FIGURA 15. ARQUITETURA DE REFERÊNCIA PARA SM’S...........................................................69

FIGURA 16. VISÃO DE IMPLANTAÇÃO..............................................................................................73

FIGURA 17. DIAGRAMA DE CLASSE (VISÃO DE MÓDULOS_WRAPPER E PROCESSING

UNIT).......................................................................................................................................................74

FIGURA 18. DIAGRAMA DE COMPONENTES: VISÃO DE COMPONENTES E CONECTORES. .76

FIGURA 19. DIAGRAMA DE SEQUÊNCIA: VISÃO EM TEMPO DE EXECUÇÃO..........................77

FIGURA 20. RESULTADO DA AVALIAÇÃO (1ª E 2ª RODADA).......................................................86

FIGURA 21. EXEMPLO DE MODELAGEM DE UM PROCESSO........................................................95

FIGURA 22. REPRESENTAÇÃO DO FRAMEWORK DE COMUNICAÇÃO PARA AS SM’S........104

FIGURA 23. ABSTRAÇÃO DA ARQUITETURA DE REFERÊNCIA (TECNOLOGIAS).................124

FIGURA 24. EDITOR NO MODO DE CRIAÇÃO DE DOCUMENTOS NO MVPEP (VERSÃO 1.5)

................................................................................................................................................................135

FIGURA 25. DOCUMENTO/TELA DO EDITOR SENDO UTILIZADO POR UM USUÁRIO FINAL

NO MVPEP (VERSÃO 1.5)..................................................................................................................135

VIII

LISTA DE TABELAS

TABELA 1. CARACTERÍSTICAS E NECESSIDADES DAS SM’S......................................................21

TABELA 2. MATERIAIS SELECIONADOS PARA O ESTUDO...........................................................36

TABELA 3. PONTOS OU ASPECTOS MAIS TRABALHADOS PELAS ARQUITETURAS..............62

TABELA 4. ATENDIMENTO AOS REQUISITOS PELA ARQUITETURA CONFORME AS

CARACTERÍSTICAS E NECESSIDADES DA SM..............................................................................68

TABELA 5. QUESTÕES ANALISADAS PELO CHECKLIST E RESPOSTAS ESPERADAS............85

TABELA 6. PADRÕES ESTRUTURAIS RELEVANTES PARA AS SM’S.........................................117

TABELA 7. PADRÕES COMPORTAMENTAIS RELEVANTES PARA AS SM’S............................118

TABELA 8. RELAÇÃO ENTRE OS PADRÕES DE PROJETO E OS REQUISITOS NÃO

FUNCIONAIS DAS SM’S....................................................................................................................118

TABELA 9. RELAÇÃO ENTRE AS PRÁTICAS E OS REQUISITOS NÃO FUNCIONAIS..............123

IX

LISTA DE ABREVIATURAS E SIGLAS

SM’s Social Machines

AR Arquitetura de Referência

AS Arquitetura de Software

PaaS Plataform as a Service

SaaS Software as a Service

IaaS Infrastructure as a Service

MVPEP Prontuário Eletrônico do Paciente

SOA Service-oriented Architecture

WEB World Wide Web

CC Cloud Computing

TI Tecnologia da Informação

BPMN Business Process Modeling Notation

Apps Aplicativos WEB

BD Base de Dados

Fb Facebook

WSDL Web Service Definition Language

PMEs Pequenas e Médias Empresas

SLAs Service Level Agreement

X

SUMÁRIO

RESUMO.................................................................................................................................VI

ABSTRACT……....................................................................................................................VII

LISTA DE ILUSTRAÇÕES.....................................................................................................VIII

LISTA DE TABELAS................................................................................................................IX

LISTA DE ABREVIATURAS E SIGLAS.......................................................................................X

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

1. INTRODUÇÃO........................................................................................................................1

1.1 APRESENTAÇÃO E CONTEXTO..................................................................................................................2

1.2. JUSTIFICATIVA E MOTIVAÇÃO DO TRABALHO.........................................................................................3

1.3 PROBLEMÁTICA........................................................................................................................................5

1.4. OBJETIVOS:..............................................................................................................................................8

1.4.1. GERAL...............................................................................................................................................8

1.4.2. ESPECÍFICO........................................................................................................................................9

1.5. TRABALHOS RELACIONADOS...................................................................................................................9

1.6. CONTRIBUIÇÃO E RESULTADOS ESPERADOS..........................................................................................11

1.7. ESTRUTURA DO TRABALHO...................................................................................................................11

2. MÁQUINAS SOCIAIS............................................................................................................13

2.1. O CONTEXTO DAS MÁQUINAS SOCIAIS..................................................................................................14

2.2. CONCEITO DE MÁQUINAS SOCIAIS.........................................................................................................17

2.3. CARACTERÍSTICAS DAS MÁQUINAS SOCIAIS..........................................................................................19

2.4. TAXONOMIA DAS MÁQUINAS SOCIAIS...................................................................................................21

2.5. EXEMPLOS DE MÁQUINAS SOCIAIS........................................................................................................22

2.5.1. EUCALYPTUS:..................................................................................................................................22

2.5.2. CLOUD AV:......................................................................................................................................22

2.5.3. MAP REDUCE:..................................................................................................................................23

2.5.4. WEB SEMÂNTICA:............................................................................................................................24

2.6. CONSIDERAÇÕES FINAIS DO CAPÍTULO..................................................................................................25

3. REVISÃO DA LITERATURA DE ARQUITETURAS DE SOFTWARE PARA MÁQUINAS SOCIAIS

26

3.1. INTRODUÇÃO.........................................................................................................................................27

3.2. ARQUITETURA DE SOFTWARE................................................................................................................27

3.3. PROCESSO DE REVISÃO..........................................................................................................................30

XI

3.3.1. QUESTÃO A SER INVESTIGADA:.......................................................................................................30

3.3.2. QUESTÕES DE PESQUISA:.................................................................................................................31

3.3.3. REPOSITÓRIOS DE BUSCA................................................................................................................33

3.3.4. IDENTIFICAÇÃO DO MATERIAL........................................................................................................33

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

3.3.6. CRITÉRIOS DE CLASSIFICAÇÃO - EXCLUSÃO:...................................................................................34

3.3.7. REGISTRO DO MATERIAL.................................................................................................................34

3.3.8. RESULTADO.....................................................................................................................................34

3.4. DEMONSTRAÇÃO DOS RESULTADOS DAS ARQUITETURAS DE REFERÊNCIA INVESTIGADAS...................36

3.4.1. ARQUITETURA DE REFERÊNCIA PARA MASHUPS – QP1....................................................................36

3.4.1.1. ARQUITETURA MASHUP PROPOSTA POR MERRIL EM 2006.........................................................37

3.4.1.2. ARQUITETURA MASHUP PROPOSTA POR LIU EM 2009...............................................................38

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

3.4.2.1. ARQUITETURA CLOUD COMPUTING PROPOSTA POR VECCHIOLA...............................................40

3.4.2.2. ARQUITETURA CLOUD COMPUTING PROPOSTA POR KOSSMANN, KRASKA E LOESING.............42

3.4.2.3. ARQUITETURA CLOUD COMPUTING PROPOSTA PELA EMPRESA IBM.......................................43

3.4.3. ARQUITETURA MULTITENANT DE REFERÊNCIA PARA SOFTWARE AS A SERVICE – QP2..................47

3.4.4. ARQUITETURA PARA REDES SOCIAIS – QP3.....................................................................................49

3.4.5. ARQUITETURA DE REFERÊNCIA PARA SISTEMAS AUTÔNOMOS – QP4.............................................52

3.4.5.1. ARQUITETURA AUTÔNOMA PROPOSTA POR MCCANN, HUEBSCHER E WHITE ET AL...................53

3.4.5.2. ARQUITETURA AUTÔNOMA PROPOSTA PELA EMPRESA IBM.......................................................55

3.4.6. ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2.0 – QP5.................................................56

3.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO – CRÍTICAS...............................................................................59

4. PROPOSTA DE ARQUITETURA DE REFERÊNCIA PARA MÁQUINAS SOCIAIS..................63

4.1. INTRODUÇÃO.........................................................................................................................................64

4.2. ARQUITETURA DE REFERÊNCIA.............................................................................................................64

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

4.4. VISÕES DA ARQUITETURA DE REFERÊNCIA...........................................................................................72

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

4.5.1. TÉCNICA DE INSPEÇÃO....................................................................................................................79

4.5.1.1. PERFIL DOS AVALIADORES (INSPETORES).................................................................................80

4.5.1.2. TAXONOMIA DOS DEFEITOS A SEREM ENCONTRADOS.............................................................80

4.5.1.3. PROCESSO DE INSPEÇÃO (AVALIAÇÃO)....................................................................................81

4.5.1.4. CORREÇÃO DOS ERROS ENCONTRADOS....................................................................................81

4.5.2. RESULTADOS...................................................................................................................................82

4.6. CONSIDERAÇÕES FINAIS DO CAPÍTULO..................................................................................................88

5. RECOMENDAÇÃO DE PRÁTICAS PARA DESENVOLVER ARQUITETURAS DE MÁQUINAS

SOCIAIS......................................................................................................................90

XII

5.1. INTRODUÇÃO.........................................................................................................................................91

5.2. PRÁTICAS NA METODOLOGIA PARA CONCEPÇÃO DE ARQUITETURAS E EM TRABALHOS RELACIONADOS

..................................................................................................................................................................91

5.3. PRÁTICAS RECOMENDADAS...................................................................................................................93

5.3.1. PRÁTICA 1: MODELAR PROCESSOS E SUB-PROCESSOS DE NEGÓCIO DE SERVIÇO............................94

5.3.2. PRÁTICA 2: RECONHECER OS SERVIÇOS PROVIDOS E REQUERIDOS PARA O FUNCIONAMENTO DA

MÁQUINA SOCIAL........ .............................................................................................................................95

5.3.3. PRÁTICA 3: CONHECER OS PROVEDORES E REQUISITANTES DOS SERVIÇO DA APLICAÇÃO............97

5.3.4. PRÁTICA 4: VERIFICAR A NECESSIDADE DE RECURSOS QUE TORNEM A APLICAÇÃO AUTO

GERENCIÁVEL E COMO ESSES RECURSOS PODEM SER IMPLEMENTADOS...................................................99

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

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

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

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

5.3.7. PRÁTICA 7: DETERMINAR O RECURSO QUE PROVERÁ A COMUNICAÇÃO E A

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

5.3.8. PRÁTICA 8: SELECIONAR O RECURSO CLOUD COMPUTING A SER ADOTADO NA SM..................109

5.3.9. PRÁTICA 9: SELECIONAR OS PADRÕES DE PROJETO MAIS ADEQUADOS PARA A ARQUITETURA DA

MÁQUINA SOCIAL....................................................................................................................................115

5.3.10. PRÁTICA 10: SELECIONAR O BANCO DE DADOS NÃO RELACIONAL.............................................119

5.4. CONSIDERAÇÕES FINAIS DO CAPÍTULO................................................................................................120

6. EXPERIMENTAÇÃO DAS PRÁTICAS.................................................................................125

6.1. INTRODUÇÃO.......................................................................................................................................126

6.2. DEFINIÇÃO DOS OBJETIVOS.................................................................................................................126

6.3. PLANEJAMENTO...................................................................................................................................128

6.3.1. OBJETO DE CONTROLE...................................................................................................................128

6.3.2. UNIDADE EXPERIMENTAL..............................................................................................................128

6.3.4. VARIÁVEIS INDEPENDENTES E DEPENDENTES...............................................................................129

6.3.5. RUÍDOS..........................................................................................................................................130

6.3.6. CONTEXTO.....................................................................................................................................130

6.3.7. SELEÇÃO DOS INDIVÍDUOS............................................................................................................130

6.3.8. VALIDADE....................................................................................................................................131

6.4. EXECUÇÃO..........................................................................................................................................132

6.4.1. PROJETO PILOTO............................................................................................................................132

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

6.4.2.1. PREPARAÇÃO...........................................................................................................................133

6.4.2.2. EXECUÇÃO...............................................................................................................................136

6.4.2.3. RESULTADOS OBTIDOS............................................................................................................137

6.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO................................................................................................141

XIII

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

REFERÊNCIAS BIBLIOGRÁFICAS.........................................................................................141

ANEXOS................................................................................................................................152

ANEXO 1. PRÁTICAS DO PROJETO EDITOR MVPEP......................................................................................152

ANEXO 2. PRÁTICAS DO PROJETO PILOTO HOBNOB....................................................................................155

APÊNDICE

S............................................................................................................................157

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

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

APÊNDICE C. VALORES MONITORADOS NO EXPERIMENTO.........................................................................161

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

XIV

Capítulo

1

1. Introdução

Este capítulo apresenta a dissertação com todos os seus elementos motivadores, e

problemática envolvida, cada objetivo deste trabalho também é apresentado neste capítulo em

conjunto a justificativa de se escolher a Web 3.0 como cenário para a pesquisa.

1

Capítulo 1. Introdução

1.1 APRESENTAÇÃO E CONTEXTO

A Internet vem alcançando números gigantescos, como exemplo, a quantidade de

usuários apenas na América Latina chegar a aproximadamente 143 (cento e quarenta e três)

milhões1. Os meios de acesso são variados, desde conexão banda larga até telefones celulares

com tecnologia 3G. Os serviços também são diversos: ferramentas de buscas, blogs, sites

empresariais, email, ferramentas de comunicação instantânea, comércio eletrônico,

abreviadores de URL, ferramentas de programação e etc.

Empresas públicas, privadas e governamentais trocam informações importantes pela

Internet, vários paradigmas e tecnologias surgem em prol da mesma, além das transações

bilionárias, como, por exemplo, a compra no valor de 1,65 bilhão de dólares do maior site de

compartilhamento de vídeo, o YouTube, por uma das maiores empresas desenvolvedoras de

serviços na rede que é a Google, fato ocorrido em 2006 (OFFICIAL GOOGLE BLOG, 2006).

A Internet se caracteriza como um rico instrumento de comunicação, negócios,

transações, propagandas e ensino. Sobre o aspecto tecnológico, o grande feito da Internet foi

sua evolução, segundo o principal CEO da Force.com2, Marc Benioff, a Internet evoluiu de

uma rede anteriormente classificada como Web 1.0, onde as informações somente poderiam

ser visualizadas; para a rede programável, a Web 3.0.

A Web 3.0 é classificada por meio de dois conceitos distintos, um deles classifica a

Web 3.0 como uma plataforma de desenvolvimento de softwares independentes de

infraestrutura física local, conceito aplicado por Marc Benioff. Enquanto a outra idéia

classifica a Web 3.0 como a Web Semântica (BERNERS-LEE; HENDLER; e LASSILA,

2001). Independe da conceituação, a Web 3.0 mudou definitivamente o aspecto da Internet,

transformando a mesma em algo mais interativo, inteligente e independente.

É dentro desta temática da Internet programável, ou Web 3.0, que este trabalho

estabelecerá suas bases. Trata-se de uma pesquisa que deseja ofertar soluções inteligentes para

problemas emergentes situados no modelo atual de negócios de TI, e principalmente da Web

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

http://pt.wikipedia.org/wiki/3G

http://pt.wikipedia.org/wiki/Telefone_celular

http://pt.wikipedia.org/wiki/Banda_larga

http://www.internetworldstats.com/stats.htm


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.

O trabalho dos usuários com estas redes é tão forte que uma pesquisa estatística feita pelo

3 Por Por Zuckerberg em Facebook Thanks. Disponível em: http://www.facebook.com/facebook?v=app_10467688569&. Acesso em 11 de jan. 2011.4 Informação disponível em: http://developers.facebook.com/. Acesso em 19 de jan. 2011.

3

http://developers.facebook.com/

http://www.facebook.com/facebook?v=app_10467688569&

http://www.facebook.com/facebook?v=app_10467688569&


ConScore, Inc.5, mostrou um aumento de 4% nos acessos das mesmas somento nos primeiros

seis meses do ano de 2010.

A facilidade em se reprogramar as redes sociais, contextualiza as mesmas a WEB

3.0, entretanto, nesta Internet ainda ocorre a proliferação dos Mashups, que são aplicações

Web constituídas de outras aplicações. Com os Mashups é possível ter uma combinação de

serviços em um único aplicativo (BENSLIMANE, DUSTDAR, e SHETH, 2008). Um bom

exemplo de Mashups são os sites de imobiliárias que inserem o serviço do Google MAP para

que o usuário possa fazer a localização do imóvel nas ruas da cidade. Vale ressaltar que os

Mashups personificam muito bem a comunicação e interação entre as aplicações Web.

As aplicações contextualizadas a Web 3.0 adicionam mais funcionalidade a mesma,

inovações ao seu desenvolvimento e facilidade aos negócios, tudo isto, a fim de atender aos

modelos de negócio cada vez mais exigentes, com regras mais complexas. Dentro deste

contexto a Internet desempenha um papel fundamental, ela além de instrumento, passa a ser

provocadora de negócios, de inovações, e de junções empresariais. Relacionado aos negócios

e as novas tecnologias da WEB 3.0 está o conceito de Computação nas Nuvens ou Cloud

Computing - CC.

A Web 3.0 apresenta o advento da CC, bem como, os serviços, plataformas de

infraestrutura, e software sob demanda (WEISSMAN, 2010). Em se tratando de CC o

Forrester Research Group6 publicou em Outubro de 2011 um relatório de análise das

tecnologias emergentes que serão tendência na TI, especificamente nas arquiteturas de

software, para os próximos anos até 2014. No relatório algumas das tendências são CC e

Business Process Modeling Notation - BPMN, este último tema será tratado mais adiante por

este trabalho.

CC é um tema de grande pesquisa na atualidade, entretanto muito ainda deve ser

visto e avaliado antes de contextualizar os recursos de CC ao desenvolvimento de um

software, pois muitas questões ainda são desconhecidas, ou duvidosas, questões como:

segurança, compartilhamento de recursos, performance dos aplicativos, e a própria

aplicabilidade dos serviços CC, ou seja, o que usar de CC? Na verdade este paradigma traz

5 Empresa que faz a mediação de vários aspectos da Internet, mostrando o comportamento de utilizadores da Web.6 Disponível em: http://www.forrester.com/rb/Research/top_10_business_technology_trends_e a_should/q/id/60920/t/2. A Forrester Group é uma empresa especializada em pesquisas direcionadas a Tecnologia de Informação. Acesso em: 20 de mai. 2011

4

http://www.forrester.com/rb/Research/top_10_business_technology_trends_e%20a_should/q/id/60920/t/2

http://www.forrester.com/rb/Research/top_10_business_technology_trends_e%20a_should/q/id/60920/t/2


novidades a todos os seguimentos da engenharia de software, novidades que na prática ainda

não foram totalmente desmistificadas.

Até este ponto a motivação pela elaboração desta pesquisa foi apresentada, o que

essencialmente impulsiona as pesquisas desta natureza é o fato de trabalhar com novas

possibilidades dentro do desenvolvimento de software, descobrir ou adaptar teorias

importantes dentro da engenharia de software. Portanto, os parágrafos acima evidenciaram

alguns jovens paradigmas que ainda carecem de pesquisas.

As pesquisas devem partir do pressuposto de que aplicações Web são sistemas que se

comunicam em rede, que exercem suas funções por meio desta e por meio da intervenção de

outras aplicações. Isto faz estas aplicações serem Social Machines - SM’s, e é trabalhando

acima deste conceito que será possível entender a Internet como um conglomerado de

Máquinas Socias que precisa ser investigado para que ocorra uma melhoria no alinhamento de

seus serviços ou relacionamentos.

O trabalho por fim se justifica na necessidade de se explorar de forma científica a

Internet no sentido de tentar explicá-la por um novo aspecto, o aspecto dos sistemas que são

Máquinas Sociais que interagem na Web 3.0. Tal estágio da Internet vem vendo investigado e

trabalhado justamente por ele possibilitar transações, interações e programação de aplicativos

diretamente na plataforma Web, com o auxílio de uma infra-estrutura que é disponibilizada

pela própria Web. Assim, aplicativos que estão sujeitos a trabalhar nessa realidade da Web

devem ser concebidos de forma diferenciada.

1.3 PROBLEMÁTICA

A justificativa por si já sinaliza a existência de alguns problemas relacionados às

aplicações que compõem a Web. Nesta seção os problemas serão pontuados mais fortemente.

Em nossa atualidade existe uma tendência cada vez maior em se fazer negócios em

escala global impulsionados por novas tecnologias, regras e relações de trabalho; isto traz um

maior grau de complexidade aos negócios (REZENDE, 2006) e, sobretudo, aos sistemas

computacionais que tendem a crescer em tamanho e complexidade vertiginosamente, sempre

na tentativa de atender as demandas dos negócios (REZENDE, 2006). Entretanto, tal evolução

não se limita aos sistemas Web e aos negócios.

5


Tecnologias, processos, arquiteturas, serviços e padrões de desenvolvimento

evoluíram com a Web e ajudaram a construir novos negócios. Ao passo que isto é positivo

também é preocupante, pois a Web é caótica em diversos aspectos tecnológicos. Na verdade,

ela passa a ser um emaranhado de códigos, padrões e protocolos que por vezes atrapalham o

desenvolvimento das aplicações (HOFMEISTER, 2000) necessitando assim, de novas idéias e

iniciativas que organizem, estruturem, e expliquem melhor o desenvolvimento de aplicações

Web.

A construção de sistemas está cada vez mais imersa na complexidade das inovações

tecnológicas causadas pelo surgimento de novos frameworks, novas linguagens, e novos

protocolos que surgem em um intervalo cada vez menor de tempo. A tendência também é em

projetar sistemas que são cada vez mais dependentes da rede (BEHRENDT. et al, 2001).

Neste aspecto, deve-se ter atenção a todos os detalhes dos sistemas a serem construídos.

Assim, este trabalho se dedica a resolver problemas e questões delicadas à Web 3.0

programável, que pode ser caracterizada como uma moderna rede de computadores sociáveis

e interoperáveis. As questões que serão resolvidas são:

Desenvolvimento de aplicações interoperáveis que estão cada vez mais

entrelaçadas e dependentes dos serviços umas das outras.

Desenvolvimento de software sob demanda, pois estes necessitam de uma

arquitetura diferenciada, haja vista, muitos deles são desligados de um

repositório físico para armazenamento; compartilhando tal repositório com outro

software (AZEEZ et al., 2010).

O auto gerenciamento de sistemas Web que compartilham atividades com outros

sistemas distribuídos na rede.

Além das questões pontuadas acima, esse trabalho também visa resolver problemas

clássicos na construção de sistemas, que segundo estudiosos7, podem gravar o

desenvolvimento de aplicações para a Web. Os problemas resolvidos serão:

Manutenções demoradas e críticas dos sistemas;

Requisitos mal trabalhados;

Ausência da arquitetura;

Ausência de uma estratégia de negócio que adeque aplicações Web à

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


resolução dos problemas.

Projetos de aplicações Web estão suscetíveis aos problemas pontuados, uma vez que

eles aconteçam, as iniciativas para saná-los devem ser precisas e rápidas. Dependendo da

natureza do problema o projeto pode até ser descontinuado, apenas para exemplificar, este foi

o caso de algumas ferramentas que desenvolvem Mashups, construídas por duas grandes

corporações, a Google e a Microsoft. A Google no ano de 2009 precisou cortar gastos, assim

resolveu paralisar o desenvolvimento de alguns de seus produtos8, entre eles estava o Google

Mashups Editor, o mesmo ocorreu com o Microsoft Popfly no mesmo ano9. Este caso poderia

ocorrer a qualquer aplicação Web que contivesse alguns dos problemas pontuados acima.

Alguns dos maiores problemas relacionados ao desenvolvimento de aplicações Web,

que podem inclusive causar o fim de um projeto, são os oriundos da arquitetura

(PRESSMAN, 2008). A arquitetura de software é uma ferramenta que auxilia na descoberta

precoce de problemas que só se manifestam geralmente na codificação da aplicação

(PRESSMAN, 2011) ou quando a mesma está desenvolvida.

O processo de concepção de uma arquitetura é por vezes mal executado ou não

executado (BASS, CLEMENTS e KAZMAN, 2003). Um exemplo clássico de problemas com

arquitetura, ou projeto arquitetural, foi o caso do Twitter. O micro blog trocou seu banco de

dados MySQL pelo Cassandra em virtude do alto crescimento da taxa de dados transitados

(AFRAM, 2006). No momento das decisões arquiteturais do Twitter não houve um raciocínio

sobre o crescimento exarcebado do mesmo, com isto optou-se pelo banco de dados errado.

O problema inerente a este estudo reside na dificuldade de se especificar e

desenvolver aplicações Web distribuídas e conectáveis, ou seja, Máquina Social; isto ocorre

não somente, mas principalmente, porque estas SM’s não são submetidas aos métodos ou

tecnologias que tratem corretamente suas particularidades, deixando-as vulneráveis aos

problemas. Os problemas podem ser mensurados ainda na concepção da arquitetura, deste

modo, o tratamento destes problemas poderia se iniciar na arquitetura da SM.

O ponto de partida da adversidade deste estudo consiste na arquitetura de software.

Tal problemática nasceu em razão das aplicações Web, como já tratado, não terem sido

8 Informação disponível no OFFICIAL GOOGLE BLOG. Em: http://www.google.com/intl/pt-BR/press/. Acesso 16 out de 2010.9Informação disponível na MICROSOFT COMMUNITY BLOGS. Em: http://blogs.msdn.com/b/nick_wong/archive/tags/event+announcements/. Acesso em: 30 ago. 2010.

7


concebidas como Máquinas Sociais. Desta forma as arquiteturas das aplicações também não

foram pensadas para estruturar SM’s, não tiveram o devido tratamento e atenção quanto as

particularidades de uma SM, de modo que, elas possam se articular e se expressar na rede em

conformidade às inovações pertencentes à mesma, otimizando assim a própria rede. Esta

pesquisa se preocupa, sobretudo, em resolver o problema explicitado neste parágrafo.

Desta maneira a problemática focada se relaciona seriamente com a necessidade de

se especificar arquiteturas de SM’s, pois muitas das aplicações WEB que devem ser vistas

como SM’s não são, neste sentido, a arquitetura que é o arcabouço de qualquer software faria

total diferença. Com isto o objetivo do trabalho será apresentado.

1.4. OBJETIVOS:

1.4.1. GERAL

Recomendar práticas para auxiliar na especificação, e mesmo concepção, de

arquiteturas de Máquinas Sociais. O objetivo é mostrar a forma menos burocrática e mais

coerente de se montar uma arquitetura de qualidade para Máquinas Sociais. Deste modo, as

aplicações Web 3.0 seriam SM’s prontas para atender as demandas do contexto atual de

negócios e de inovações tecnológicas, sobretudo da Internet.

Tais práticas poderão atuar nas decisões arquiteturais, e no projeto arquitetural. Por

consequência atuarão no processo de desenvolvimento, haja vista que a arquitetura mobilize

muitas fases do projeto de software, (KRUCHTEN, 1995) integrando profissionais com

aptidões distintas, como: analistas de requisitos, engenheiros de software, programadores e

gerentes. A missão dessas práticas é minimizar os problemas no desenvolvimento das SM’s,

problemas estes que já foram explorados em uma seção anterior.

As práticas também visam customizar a arquitetura de referência que será proposta,

esta arquitetura também caracteriza o objetivo do trabalho a partir do momento em que torna-

se um instrumento para a criação de novas arquiteturas de SM’s.

1.4.2. ESPECÍFICO

8


Tratando-se do objetivo deste trabalho, deve ficar claro que talvez essa pesquisa não

resolva todos os problemas causados pela complexidade das inovações tecnológicas, o que foi

comentando ainda na problemática. Mas, certamente organizará o desenvolvimento das

Máquinas Sociais, ao passo que poderá padronizar as tecnologias adotadas. Esta seção

fortalece o objetivo principal, pois expõem os resultados que serão alcançados com a

formalização da metodologia. Na verdade, são subprodutos do objetivo geral, ou metas

estabelecidas para serem obtidas ao longo do trabalho.

1. Estudar as tecnologias emergentes ao desenvolvimento de aplicações Web 3.0;

2. Exemplificar Máquinas Sociais já implementadas e aplicadas à indústria de

software;

3. Verificar a existência de uma arquitetura de referência para sistemas Web 3.0;

4. Sugerir uma arquitetura de referência para Máquinas Sociais no intuito de guiar a

elaboração das demais arquiteturas.

5. Estudar práticas, métodos ou procedimentos dedicados a especificação de

arquitetura.

6. Montar um raciocínio sobre o desenvolvimento de Máquinas Socias de modo que

os desenvolvedores trabalhem sobre o conceito de aplicações interoperáveis na

Web e não sistemas isolados;

7. Contribuir para o amadurecimento de um framework ou padrões de projeto para

Máquinas Sociais;

8. Disseminar as práticas em um ambiente real de desenvolvimento para verificar a

aplicabilidade das mesmas.

1.5. TRABALHOS RELACIONADOS

As pesquisas sobre Máquinas Sociais são oriundas dos estudos de um grupo da

Universidade Federal de Pernambuco dedicado a SM’s fundado pelo professor Silvio Meira,

cientista do C.E.S.A.R – Centro de Estudos Avançados do Recife, o qual também dissemina

pesquisas sobre Máquinas Sociais.

9


Os trabalhos que exploram as SM’s relacionam as mesmas às pesquisas direcionadas

à Internet, sobretudo a Web 3.0. Algumas destas pesquisas foram feitas por grandes

estudiosos, como Mark Benioff em 2010, Tim Berners-Lee em 2001, e por Robert Bryant em

2007. Todos estes estudiosos relatam como a Web 3.0 muda definitivamente o aspecto da

Internet, transformando a mesma em algo mais interativo, inteligente e independente,

injetando forças em conceitos como Cloud Computing e Redes Sociais.

Esta pesquisa também está totalmente relacionada a arquitetura de software.

Arquitetura de Software (AS) pode ser classificada como um conjunto de decisões dedicadas a

resolver um problema (PRESSMAN, 2011), ou ainda uma coleção de componentes e

conectores (ligações) que irá compor o sistema (GORTON, 2006). A AS pode ser ainda a

abstração de um sistema computacional, seu arcabouço (PRESSMAN, 2009). Todos os

conceitos levantados sobre AS são de obras que estudam arquitetura e que também estão

entrelaçadas a esta pesquisa, outros estudos sobre AS estão da mesma forma entrelaçados

como o de ERL em 2005, Gamma em 2000, Bass e Clements em 2003.

São diversos os conceitos para a AS, e todos eles defendem a relevância de se definir

corretamente a mesma, pois os reflexos dessa definição podem ser pressentidos de forma

intensa ao longo da implementação do software, seja este modesto ou não (BASS,

CLEMENTS e KAZMAN, 2003). Neste sentido, vale dedicar esforços às questões que

envolvem a peça fundamental para qualquer sistema e aplicação computacional. Com isto

trabalhos que se empenham em facilitar a especificação da arquitetura estão interligados a esta

pesquisa. Assim, a IEEE Recommended Practice for Architectural Description of Software-

Intensive Systems, e a IEEE Recommended Practice for Software Requirements

Specifications, são trabalhos fortemente relacionados.

1.6. CONTRIBUIÇÃO E RESULTADOS ESPERADOS

Esta pesquisa visa contribuir para o cenário dos estudos e do desenvolvimento de

aplicações do tipo Máquina Social, ao passo que amadurece o pensamento acerca das decisões

10


de projeto dessas aplicações, deste modo, elas sofrerão o mínimo de problemas em seu

desenvolvimento e manutenção. Os seguintes resultados são esperados:

Amadurecimento e disseminação do conceito de Máquinas Sociais;

Facilidade na adoção de padrões arquiteturais e tecnologias que constituem uma

Máquina Social;

Contribuir para o amadurecimento dos conhecimentos sobre o atual cenário de

desenvolvimento de aplicações Web 3.0;

Impulsionar novas pesquisas em Máquinas Sociais;

Demonstrar métodos avaliativos sobre artefatos de software e sobre SM’s.

Propor soluções que possam facilitar em algum aspecto a interação entre as SM’s.

Finalmente uma potencial contribuição deste trabalho reside em agregar ao mundo

acadêmico um estudo consistente sobre SM’s a ponto de orientar pesquisadores e

profissionais para as particularidades das mesmas, e também para trabalharem com os

conceitos emergentes do universo da engenharia de software, como: Redes Sociais, Internet

3.0, Cloud Computing entre outros.

1.7. ESTRUTURA DO TRABALHO

Este trabalho é um estudo recente que busca soluções adequadas para a construção de

Máquinas Sociais. Sendo assim, a pesquisa é do tipo Exploratória, a qual é bastante utilizada

em trabalhos com temática inovadora (SEVERINO, 2008). A dissertação também será uma

pesquisa do tipo Acadêmica, pois sistematiza um processo para construção de um novo

conhecimento (SEVERINO, 2008). A pesquisa está organizada conforme disposição abaixo:

No capítulo 2 será esclarecido o conceito de SM’s com suas características e

taxonomia. Este capítulo se fez necessário pelo fato das SM’s serem peças fundamentais à

pesquisa, trata-se de um trabalho dedicado às SM’s.

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

11


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).

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

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

14


programas computacionais, incluindo design, implementação, depuração para encontrar

defeitos, testes, cópias de segurança, gerência de configuração, rápida instalação (ou

deployment), além das várias operações de suporte aos serviços ofertados. Estas plataformas

foram denominadas Plataform as a Service - PaaS, das quais, a Force.com11, se caracteriza

como uma das mais acessíveis e popularizadas, uma vez que é totalmente centrada na

aplicação e abstraída de qualquer conceito de servidores locais (WEINHARDT, 2009).

O alicerce para o conceito de Cloud Computing é a Infrastructure as a Service –

IaaS, que por sua vez, trata da infraestrutura de servidores (MCPHERRON, 2008). Isto

elimina as preocupações das empresas em salvaguardarem um parque tecnológico para manter

as aplicações, pois agora os recursos de hardware são serviços remotos (MCPHERRON,

2008) onde ocorrem os aluguéis de Data Centers que fazem a hospedagem das aplicações.

IaaS é um serviço oferecido por empresas como Amazon AWS12, por exemplo.

Assim, em Cloud Computing, uma das preocupações seria a de adaptar os

programadores e as aplicações a esse novo paradigma e a forma em que ele trata as

tradicionais práticas e conceitos de desenvolvimento de software. A Figura 1 ilustra a

estrutura da CC.

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

11 Force.com é uma plataforma de desenvolvimento em Cloud Computing, nela também é possível comprar aplicativos, ou partes deste. A Force.com ficou conhecida pelo serviço de Customer Relationship Management -CRM vendido as empresas, recentemente, a plataforma divulgou sua rede social personalizada para desenvolvedores, cujo nome é Chatter (Salesforce.com, 2010).12 Amazon AWS é uma empresa que trabalha com Cloud Computing, oferta serviços de hospedagem e IaaS. Disponível em: http://aws.amazon.com. Acesso em 02 de jul. 2010.

15

http://aws.amazon.com/


Dentro de cada camada representada na Figura 1, existem modelos de negócios que

são baseados na função de cada camada. Na camada de IaaS, por exemplo, surge, segundo

Weinhardt, Blau e Stober (2009) o chamado Infrastructure Business Models que trabalha com

capacidades de armazenamento e suprimento de poder computacional. Uma poderosa empresa

que trabalha nesta camada é a Amazon.

A Amazon oferece uma série de serviços, e um deles é o Elastic Compute Cloud2 -

EC213 que provê segurança, balanceamento de carga, e aumento de recurso computacional

automaticamente conforme o crescimento da aplicação. O pagamento para este serviço é

baseado no modelo chamado “sob demanda” onde se paga apenas a quantidade de serviço

utilizado (WEINHARDT, BLAU e STOBER, 2009).

Ainda dentro dos novos negócios que surgem em Cloud Computing - CC estão os

serviços da Google Apps, esta possui um enorme conjunto de aplicações na CC, tais como:

aplicativos para processamento de textos e planilhas, emails, calendários e outros. Vale

ressaltar que o crescimento de novos modelos de negócios em CC está relacionado

principalmente à segurança de dados e informações, garantia de integridade, disponibilidade

de serviços, confiabilidade e rapidez de desenvolvimento (WEINHARDT, BLAU e STOBER,

2009).

Assim, é notável a alteração que CC causou no cenário da engenharia de software,

nas formas de pensar, de fazer, e de negociar programas computacionais. Entretanto, este não

é um privilégio da Cloud Computing. As Redes Sociais também contribuíram para as

inovações em engenharia de software, pois algumas dessas redes são ferramentas de

programação da própria rede social, o que pode influenciar em requisitos, teste e arquitetura.

Tanto as Redes Sociais quanto a CC estão inseridas no contexto da Web 3.0,

portanto, estão no contexto do novo conceito de SM’s. A implementação de uma SM pode ser

feita por meio de Cloud Computing, ou mesmo, uma SM pode ser um serviço oferecido pela

nuvem já dentro do panorama dos novos negócios. As SM’s são uma nova abordagem dentro

deste contexto, uma abordagem simplificada para as aplicações Web que compõem este

cenário inovador.

2.2. CONCEITO DE MÁQUINAS SOCIAIS

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

http://aws.amazon.com/ec2


Máquinas Sociais são sistemas, ou aplicações Web, conectáveis, que possuem uma

unidade de processamento interno e são capazes de interagir com outras máquinas, a fim de,

executar um serviço (MEIRA. et al, 2011). A Figura 2 mostra a representação básica da SM.

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

Fonte: The Emerging Web of Social Machines

A Máquina Social é constituída pelos elementos representados na Figura 2, descritos

como se segue, segundo Meira et, al. 2011:

Request: trata-se de uma chamada de procedimento remoto feito aos serviços

prestados pela SM por meio da sua interface (Wrapper). O Request é classificado em: SM’s

functionality request, e SM’s meta-information request.

o SM’s functionality request: é a requisição de um serviço ou de uma

chamada de método que pode ser feito para outra SM.

o SM’s meta-information request: trata-se de uma requisição de

consulta para uma determinada SM, a fim de, ter conhecimento sobre

o seu estado, ou mesmo sobre os seus parâmetros de custo e tempo de

resposta dos seus serviços, disponibilidade e outras meta-informações

associadas à SM.

Response: é a resposta remota da SM ao solicitante, novamente por meio da

Interface Wrapper. Seus tipos são: SM’s functionality response, SM’s meta-

information response, e Notification response.

17


o SM’s functionality response: trata-se da resposta direta ofertada a uma

SM’s functionality request. Pode haver várias ou nenhuma SM’s

functionality response para uma SM’s functionality request.

o SM’s meta-information response: é a resposta direta ofertada a uma

SM’s meta-information request.

o Notification response: são notificações de uma máquina a respeito de

algum evento ocorrido. Pode ser uma notificação de erro de execução,

de erro de envio de mensagem, mensagens de sucesso, de

disponibilidade e outros.

Wrapper Interface: a Interface Wrapper é uma camada de comunicação na qual

uma SM exterioriza os seus serviços e permite interação com outros SM’s. Esta

Interface pode também ser entendida como a API14 da SM.

Input: é a entrada de dados que de fato será processada pela unidade e que só

ocorre após a requisição de procedimentos, assim, os objetos a serem manipulados

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.

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

18


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

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 auto-

reconhecer, 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.

19


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.

Máquinas Sociais

Têm Necessitam

Autonomia Serviços

Sociabilidade Comunicação facilitada

Constância Manutenção facilitada

Colaboração Infraestrutura

Serviços Reatividade

Conectividade

Expansão ou

Confiabilidade

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

2.4. TAXONOMIA DAS MÁQUINAS SOCIAIS

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 Disponibilidade: Capacidade de estar pronto pra uso no tempo esperado ou desejado (ISO/IEC 9126-1);17 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


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

possuirem meios de comunicação.

SM’s Consumidoras: SM’s que apenas consomem um ou mais serviços para, a

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.

2.5. EXEMPLOS DE MÁQUINAS SOCIAIS

Para consolidar mais os conceitos deste capítulo é interessante exibir alguns modelos

de SM’s. Abaixo descrevemos o nome da tecnologia e o porquê ela pode ser considerada uma

SM. Ao final dos exemplos será possível notar que os conceitos de SM’s não se limitam

apenas às aplicações Web, apesar deste trabalho focar nas SM’s que são aplicações para

Internet. Tais máquinas podem também ser explicadas, ou visualizadas, como diferentes

sistemas conectados em rede, ou ainda, como diversificadas tecnologias Web.

2.5.1. EUCALYPTUS:

O Eucalyptus é uma IaaS de código aberto que fornece suporte para a integração

com outras IaaS como a Amazon AWS. Com o Eucalyptus o usuário também pode gerenciar

21


sua nuvem criada em outras ferramentas. Esta IaaS permite aos usuários acesso e gerência a

todas as máquinas virtuais existentes (LIU et al., 2007). O Eucalyptus trabalha essencialmente

com virtualização, além de utilizar o protocolo SOAP19 para consultas.

Essa IaaS pode ser considerada uma SM pelo gerenciamento e reconhecimento do

estado de outras máquinas, o que sobressai a característica sociável do Eucalyptus. Neste

ponto o Eucalyptus possui muitos dos elementos das SM’s, sendo que os elementos mais

importantes para esta IaaS são as solicitações. Assim, o Eucalyptus envia Request e recebe

Response a todo o momento, além de possuir uma robusta Wrapper Interface chamada de

Cluster Controller (LIU et al., 2007) que possibilita uma interação imediata a eficaz com

todas as máquinas virtuais, que podem também ser SM’s.

2.5.2. CLOUD AV:

O Cloud AV é uma ferramenta antivírus ofertada como um serviço de Cloud

Computing. Tal serviço identifica arquivos maliciosos por múltiplos mecanismos de detecção

em paralelo que se comunicam entre si exatamente como SM’s. O Cloud AV utiliza técnicas

baseadas em cache para melhorar o desempenho durante o envio de arquivos, além disto, para

prover escalabilidade, a ferramenta é executada em máquinas virtuais (OBERHEIDE, et al.,

2008).

O Cloud AV possui os seguintes elementos (OBERHEIDE, et al., 2008) de uma SM:

Input: recebe arquivos para a análise e o seu mecanismo de detecção é

composto por diversos aplicativos antivírus que fazem Request e Response

entre si até que a detecção seja possível.

Output: Envia o resultado da análise dos arquivos apontando quais estão

infectados ou não.

Evidentemente o Cloud AV possui o elemento Processing Unit para possibilitar

tantas análises, além da característica de sociabilidade da SM, o que torna possível a interação

com os vários antivírus até que o resultado seja encontrado.

2.5.3. MAP REDUCE:

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


O MapReduce é um framework para processamento de grande volume de dados. Esse

aplicativo ainda facilita outras atividades como: mecanismo de tolerância a falhas,

distribuição dos dados e balanceamento de carga. O MapReduce trabalha com funções que se

comportam como SM’s; Jimmy Lin e Chris Dyer (2010) definem bem o funcionamento do

aplicativo no parágrafo abaixo:

No MapReduce cada operação é composta por duas funções. A primeira, chamada

de função de Mapeamento, recebe uma porção do arquivo de entrada, e de acordo

com a especificação do usuário, emite um conjunto de tuplas intermediárias no

formato chave-valor. A segunda função, chamada Redução, recebe um conjunto de

valores associados a cada chave, chamados de blocos. O processamento, definido

pelo usuário, é realizado sobre cada bloco; por fim, cada função de redução emite

um conjunto de tuplas que são armazenadas em arquivos de saída.

Por redução se entende: uma função que "recolhe" os itens em listas e realiza alguma

computação em todos eles, reduzindo-os a um único valor (LIN e DYER, 2010). É por isso

que o sistema MapReduce consegue trabalhar com grandes volumes de dados. Tal redução

pode ser vista com os elementos Input e Output da SM. Além de possuir os elementos da SM,

como os já citados, além de outros como o State; o MapReduce possui a característica da SM

de se auto-reconhecer e reconhecer o volume de dados entregue (LIN e DYER, 2010).

Outra característica que aproxima o MapReduce de ser uma SM é o fato das camadas

que compõem sua arquitetura se conectarem e interagirem livremente, ou seja, a arquitetura

MapReduce é do estilo Relaxed Layered System (LIN e DYER, 2010), o qual permite que as

camadas interajam com camadas que não são adjacentes, ou seja, o sentido de comunicação e

o tipo de comunicação pode ser alterado (GAMMA et al, 1995).

2.5.4. WEB SEMÂNTICA:

Para finalizar a exibição das Máquinas Sociais, será exibido uma aplicação em um

nível maior, ou melhor, será exibido uma plataforma como Máquinas Sociais, pois assim será

possível notar como este conceito pode ser aplicado a diversos níveis de tecnologia.

Atualmente quando uma página Web é procurada com o auxílio de uma máquina de

busca, esta máquina vai investigar as páginas que contém palavras declaradas pelo usuário.

Contudo, nem sempre essas palavras são adequadas e relevantes para o contexto em que o

23


usuário está inserido. A Web Semântica vem para sanar esse problema, pois ela é a Web dos

significados (BERNERS-LEE; HENDLER; e LASSILA, 2001). Ela atribui significado claro e

específico aos dados por meio da interpretação e da contextualização dos mesmos; isto facilita

o entendimento das máquinas (MORAES E SOARES, 2002), deixando a resposta para

qualquer tipo de pesquisa na Web mais precisa, satisfazendo a necessidade do usuário.

A Web Semântica também é classificação como Web 3.0 e foi idealizada por Tim

Berners-Lee. Tim projetou uma Internet inteligente, o que se deve principalmente à

organização das informações. Tais informações são consequências de dados oriundos de

repositórios completamente heterogêneos. Tim ainda afirma que o grande diferencial desta

Web 3.0 será o aprendizado das máquinas, pois estas organizarão e darão contexto aos dados

(BERNERS-LEE; HENDLER; e LASSILA, 2001).

No texto abaixo, traduzido da obra de Lee, Hendler e Lassila (2001), é possível

observar forte relação entre o conceito de Internet Semântica e o conceito de Máquinas

Sociais.

Os agentes na Web Semântica são sistemas computacionais capazes de interagir

autonomamente para atingir os objetivos almejados pelo usuário. Os agentes

possuem algumas características como autonomia, reatividade (percebem o

ambiente e tomam as decisões), tem comportamento colaborativo, possuem

objetivos, são flexíveis, sociáveis e têm a capacidade de aprender. A Web Semântica

possui vários agentes interagindo entre si, compreendendo, trocando ontologias,

adquirindo novas capacidades racionais ao passo que adquirirem novas ontologias

para formar cadeias que facilitam a comunicação e a ação humana.

Pela citação direta nota-se claramente as características de uma SM na Web

Semântica, entre elas: sociabilidade, interação, colaboração, e comunicação. Tais

características necessitam de todos os elementos das Máquinas Sociais. Deste modo, essa

seção se encerra na esperança de ter contribuído para a fixação dos conceitos de SM’s e de

como tais SM’s podem ser identificadas.

2.6. CONSIDERAÇÕES FINAIS DO CAPÍTULO

Este capítulo apresentou as Máquinas Sociais. Vale salientar que existem outros

materiais que explicam minuciosamente o conceito das SM’s os quais estão referenciados na

24


bibliografia deste trabalho. Outro ponto importante a ser declarado é o fato deste capítulo

fornecer conceitos que devem ser considerados durante a execução desta pesquisa quanto à

consolidação do objetivo geral da mesma. O próximo capítulo tratará com igual propósito no

que concerne à arquitetura das SM’s.

25

Capítulo

3

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

Esse capítulo objetiva descobrir evidências de pesquisa sobre arquiteturas de

softwares que são Máquinas Sociais. É necessário investigar essas arquiteturas para ter

entendimento de como elas realmente são. Com isto, será possível sugerir uma arquitetura de

referência dedicada às Máquinas Sociais; e futuramente, sugerir práticas de engenharia de

software coerentes ao maior objetivo do trabalho, que é facilitar a construção de arquiteturas,

e assim das próprias aplicações que são SM’s.

26

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

3.1. INTRODUÇÃO

Não somente, mas sobretudo, pesquisas de Harman e Jones (2001); Freitas et al,

(2008); Pressman (2005); e Kruchten (1995), direcionadas a área da engenharia de software,

impulsionaram o surgimento de novos padrões, métodos, representações e técnicas

relacionados à arquitetura de software, o que ocasionou uma evolução nessa área de estudo da

engenharia.

Em tempos longínquos, a arquitetura de software era basicamente voltada para os

sistemas cliente-servidor, onde uma máquina exercia o papel de cliente requisitante e a outra

máquina, o papel de servidor com a responsabilidade de atender as requisições. Deste modo, a

arquitetura cliente-servidor tornou-se padrão na engenharia de software, sendo em nossa

atualidade ainda explorada e, sobretudo, mesclada a outras arquiteturas para atender ao

objetivo de um software. Hoje parece ser este o cenário: arquiteturas cada vez mais

heterogêneas, onde estilos e tecnologias diferenciadas se misturam para formar novas versões

de representações arquiteturais.

3.2. ARQUITETURA DE SOFTWARE

Arquitetura de Software (AS) é a definição da estrutura e dos elementos que

compõem um sistema, como esses elementos estão inter-relacionados, e quais as suas

características (BASS, CLEMENTS, KAZMAN, 2003). A AS está intimamente ligada aos

requisitos de software, mais fortemente aos requisitos não funcionais (RNF) (BASS,

CLEMENTS, KAZMAN, 2003). Sendo assim, a definição de uma arquitetura se inicia com o

levantamento e análise dos requisitos seguido pelas decisões de projeto. Estas são escolhas em

relação às tecnologias utilizadas para desenvolver a aplicação (PRESSMAN, 2011).

Ao longo da história a AS foi várias vezes explorada, conduzindo a um universo de

descobertas que, por sua vez, gerou soluções úteis ao desenvolvimento de software. Na

evolução dos estudos da área, descobriu-se que o estilo arquitetural Camadas facilitava

enormemente o desenvolvimento de softwares para a Web. As principais características do

estilo Camadas são, segundo Erich Gamma, 2000:

27


Camadas superiores são específicas da aplicação;

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

oferecendo suporte às camadas superiores;

As camadas só interagem com camadas contíguas, ou seja, com as

camadas que estão imediatamente acima ou abaixo;

O conteúdo das camadas pode ser variável, assim como o nome de cada

camada. A comunicação entre as camadas pode ser por meio de protocolos de

comunicação ou mesmo através de um sistema operacional. Tradicionalmente, elas

se dividem em 3 camadas e mais o repositório de dados ilustrados na Figura 3

(HOFMEISTER, 2000).

Figura 3. Estilo arquitetural Camadas

1ª Camada, Apresentação: camada onde o usuário interage diretamente, ela

valida os dados fornecidos pelo usuário e o conecta aos serviços da camada

inferior;

2ª Camada, Negócio: contém todos os componentes e objetos que podem ser

utilizados e reutilizados para implementar a lógica de negócio da aplicação;

3ª Camada, Persistência: é a camada responsável pelo acesso aos meios de

armazenamento como: memória, banco de dados e sistemas legados.

28


O estilo Camadas se popularizou e passou por evoluções, uma vez que inicialmente

era constituído por duas camadas e atualmente já pode ser constituído por até quatro ou mais,

consoante Christine Hofmeister (2000), no qual existe uma quarta camada de Middleware ou

mesmo um servidor Web para fazer a gerência da aplicação. Além das características expostas

acima, sua popularização se deve, mormente, pelas características expostas a seguir (KLEIN,

KAZMAN, 1999):

As camadas podem resolver problemas complexos de forma sequencial e

incremental (SOMMERVILE, 2011);

As camadas podem ser reutilizadas, visto que elas suportam alterações, o que

afetaria apenas a interação com as camadas adjacentes. Logo, as camadas

poderão ser reutilizadas, desde que mantenham interfaces de comunicação

adequadas às suas camadas adjacentes (GARLAN, SHAW, 1994);

Suportam outros estilos associados, ou seja, dentro de uma camada pode

existir outro estilo arquitetural (LARMAN, 2007);

É o estilo arquitetural com o maior número de variações, já explicado

anteriormente, o Relaxed Layered System; além do estilo Layering Through

Inheritance, outra derivação do Camadas (KLEIN, KAZMAN, 1999), com

características semelhantes e algumas melhorias, como: permitir que camadas

superiores modifiquem os serviços das classes das camadas inferiores;

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

2007);

Podem ser facilmente empregados padrões de projetos, como o padrão

Observer, fortemente utilizado na interação entre as camadas (LARMAN,

2007);

Apesar dos benefícios agregados pelo estilo em Camadas, assim como todos os

estilos, ele deve ser analisado antes de ser adotado para a arquitetura do software, pois sua

utilização não é viável para todos os sistemas (BUSCHMANN et al, 1996). Assim, para

sistemas que necessitem de ótimo desempenho as camadas não são aconselháveis, porquanto

o tempo de processamento e a própria comunicação entre as camadas pode ser elevado

29


(BUSCHMANN et al., 1996). Outro critério de qualidade é a tolerância à falhas. Se uma

camada ficar indisponível, o sistema na sua integralidade poderá ficar indisponível, haja visto,

que uma camada depende de outra para funcionar (HOFMEISTER, 2000).

Para finalizar a exposição dos conceitos relacionados a arquitetura de software, vale

mais uma vez enfatizar que uma arquitetura de referência será esboçada, e que ela, assim

como toda arquitetura de referência, precisa de um estilo arquitetural. A partir do ponto em

que se estabelece uma arquitetura de referência, já se disponibiliza um parâmetro inicial para

a construção da arquitetura correta de SM’s, e que pode ser perfeitamente guiado pelas

práticas que darão forma ás arquiteturas.

Faz-se necessário esta seção sobre arquitetura de software, uma vez que esse capítulo

trata de um estudo sobre arquitetura. Torna-se relevante ter um estudo dessa categoria

compondo a pesquisa, porquanto dará subsídio para a formulação da AR e das práticas ao

passo que revelará o estado da arte das arquiteturas de aplicações que fazem partem da Web

3.0. O desenvolvimento deste estudo foi baseado, entre outros, nas orientações das obras de

Bárbara Kitchenham e David Budgen (2008 - 2009), e de Pertersen (2008), assim está

estruturado como se segue.

3.3. PROCESSO DE REVISÃO

3.3.1. QUESTÃO A SER INVESTIGADA:

A questão investigada neste trabalho trata da existência de uma arquitetura de

referência para Máquinas Socias, uma arquitetura que facilite o desenvolvimento de SM’s por

ser uma arquitetura padrão a todas as SM’s. Portanto a questão de pesquisa é: “what are

architecture of reference for Social Machines?”. Traduzindo: existem arquiteturas de

referência para Máquinas Sociais.

Seguindo alguns critérios de Petticrew e Roberts (2005) a questão selecionada se

baseia em:

Intervenção: Estudos sobre arquiteturas e Máquinas Sociais que façam algum

tipo de experimento ou análise utilizando alguma técnica ou modelo.

30


População: Trabalhos científicos publicados sobre arquiteturas de aplicações

WEB 3.0 ou para sistemas que possam ser classificados como Máquinas

Sociais.

Publicação: Materiais técnicos que tratem das arquiteturas, ou sistemas, e

práticas relacionadas às Máquinas Sociais.

O que se almeja descobrir neste estudo é o estado da arte de arquiteturas de

aplicações Web, bem como, a existência de um padrão entre tais arquiteturas. Como o escopo

deste trabalho está centrado no contexto inovador da Web 3.0, o estudo foi direcionado aos

sistemas que estejam imersos e preparados para trabalhar dentro dos princípios da Web 3.0.

Assim, as questões de pesquisa foram selecionadas.

3.3.2. QUESTÕES DE PESQUISA:

Seria mais fácil encontrar materiais que fossem dedicados aos sistemas, aplicações

ou tecnologias que possam ser classificados como Máquinas Socias, visto que o quantitativo

das pesquisas que tratam as aplicações propriamente como Máquinas Sociais, com

arquiteturas de Máquinas Sociais, é inexpressivo. Sendo assim, optou-se em utilizar questões

que abordem arquiteturas das tecnologias: Mashups, Computação nas Nuvens, Redes Sociais,

Sistemas Autônomos e aplicações Web. Estes possuem características marcantes das SM's por

interagirem com outros elementos em rede, além de utilizarem serviços e recursos destes

elementos e também da própria rede para funcionar, se desenvolver, e auto gerenciar.

Complementando a motivação acima, existe o fato das Máquinas Sociais

selecionadas para as questões serem mais difundidas, possibilitando dessa forma, maior

número de pesquisas e experimentos sobre elas, o que pode facilitar o desenvolvimento do

estudo em questão. Do mesmo modo, o estudo pode ser facilitado com a inserção de uma

questão de pesquisa dedicada às aplicações Web em geral, ou seja, uma das questões

investigará a existência de uma arquitetura de referência para aplicações web.

As 5 (cinco) questões para a busca da pesquisa foram definidas e são expostas

abaixo:

QP1: What are the reference architectures for Mashups?

31


QP2: Which are reference architectures of Cloud Computing?

QP3: What is the architecture of Social Networks?

QP4: There is a model of architecture for Autonomous Systems?

QP5: What are the reference architectures of Web Applications?

As cinco questões propostas acima buscam descobrir tendências inovadoras sobre

arquitetura de Máquinas Sociais. Elas foram escritas na linguam inglesa apenas para facilitar a

obteção de resultados, pois acreditasse que os resultados de estudos serão em maior

quantidade na língua inglesa. No entanto, é necessário utilizar palavras que complementassem

a busca pelas respostas das questões de pesquisa, neste caso, os termos ou “strings” a seguir,

orientam a idéia de melhorar os filtros de busca. Por conseguinte, foram utilizados na

investigação por vezes mesclados às questões acima, os strings são:

Web 3.0; Networking; Social Networking; Style; Social; Web 2.0; Architecture;

Architectural; Computer; Machine; Tendency; Tred; SaaS; Cloud; Patterns; Internert;

Applications; Systems; Social Machine; Web Applications; Software Engineering;

Multitenancy; Multitenant; Scalability; Software as a Service; Twitter; Facebook; Mashup

Architecture; Semantic Web; Platform as a Service; PaaS; Architectural Innovations;

Autonomous Systems; Map Reduce; Reference; Which.

No objetivo de encontrar o maior número de resultados que atendessem a questão de

pesquisa, as questões de busca foram por vezes alteradas com o auxílio das strings, como

exposto abaixo:

“What are the architectures of “Cloud Computing” OR “Multitenant” OR

OR “Multitenancy”.

“What are architecture of “Social Networks” OR “Social Networking”.

“What are the architectures of “Cloud Computing” OR “Platform as a

Service” OR “PaaS”.

32


3.3.3. REPOSITÓRIOS DE BUSCA

Os repositórios e base de dados utilizados para encontrar as questões e palavras

investigadas foram as bibliotecas digitais: CiteSeerX; IEEE Xplore; Mendeley; e ACM Digital

Library. Foram também empregados capítulos de livros e revistas digitais especializadas para

subsidiar a investigação (KITCHENHAM, 2009).

Este trabalho possui natureza científica, entretanto, seu resultado visa alcançar

também profissionais e empreendedores na área de TI no intuito de facilitar a criação de

aplicações Web. Sendo assim, houve a necessidade de empregar ferramentas que ofertassem

um resultado mais direcionado ao mercado tecnológico, bem como revelassem materiais que

não pertencessem aos repositórios mencionados, e que por sua vez, fossem mais técnicos e

menos científicos, agregando valores à pesquisa em comento. Deste modo, foram aplicados

em uma investigação secundária, máquinas de busca como: Google Scolar e Google Books.

3.3.4. IDENTIFICAÇÃO DO MATERIAL

Todo material revelado pela busca foi precedido de leitura do título. Por sua vez

aqueles que mais se aproximavam das questões investigadas tinham seu conteúdo selecionado

para posterior leitura do resumo ou introdução. Após essa leitura, uma relevância era atribuída

ao material conforme alguns critérios de classificação.

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

A inclusão de pesquisas a serem consideradas para o referido estudo se baseou na

relevância declinada.

Atribuir maior relevância para materiais que se caracterizem como:

o Arquiteturas já testadas e empregadas em Máquinas Sociais;

o Soluções de projeto ou decisões de projeto de aplicações vistas como

Máquinas Sociais.

Atribuir relevância mediana para materiais que:

33


o Façam referência as tecnologias emergentes e adequadamente empregadas na

construção de Máquinas Sociais;

o Sejam projetos “piloto” de arquitetura de referência para aplicações ou

sistemas WEB.

3.3.6. CRITÉRIOS DE CLASSIFICAÇÃO - EXCLUSÃO:

Foram descartados materiais que apresentam menor contribuição por não tratarem de

assuntos relacionados às arquiteturas de sistemas ou aplicações Web 3.0, bem como, estudos

com abordagens insuficientes, que comprometam o entendimento do material, e ainda estudos

duplicados. Foram descartados ainda materiais que ofertassem um conteúdo muito conceitual

sobre arquitetura, sem nenhuma proposta evidente de tal, sem definição de elementos ou

recursos que possam prover a arquitetura.

3.3.7. REGISTRO DO MATERIAL

Foram elaboradas fichas de leituras, as quais foram analisadas e classificadas,

construindo a base de conhecimento de forma textual, formando um resumo significativo,

cujo conteúdo integrava materiais de acentuada relevância que contribuiram para a pesquisa.

As fichas estão disponíveis no repositório público: http://dl.dropbox.com/u/8309962

/Fichas%20de%20Leitura.docx.

As fichas foram organizadas pela ordem de classificação, tal organização observou

também a extração de evidências que satisfizessem as questões de pesquisa, validando assim

este estudo (PERTERSEN et al. 2008). Por meio do registro do material foi ainda possível

extrair conhecimento a respeito do grau de relevância de cada material relacionado a alguma

questão de pesquisa, mostrando assim a adoção, ou não, das strings.

3.3.8. RESULTADO

Os materiais mapeados compõem-se na sua totalidade 21 (vinte e um) textos entre

artigos, periódicos e capítulo de livro; 11 (onze) destes materiais mostraram maior

contribuição para as questões de pesquisa. O resultado de cada uma das questões é exibido na

34


tabela a seguir que engloba os 11 (onze) estudos contribuintes. Vale ressaltar que a questão de

pesquisa que trata de Cloud Computing foi a que retornou mais estudos, 12 (doze) no total,

entre propostas arquiteturais e estudos com abordagens duplicadas.

O gráfico abaixo (figura 4) mostra a dispersão do quantitativo de estudos por questão

de pesquisa; nele é possível observar que a questão das aplicações Web resultou em menos

estudos, apenas 2 (dois) onde 1 (um) foi considerado.

QP 1. Mashups

QP 2. Cloud Computing

QP 3. Social Networks

QP 4. Autonomous Systems

QP 5. Web Applications

0 2 4 6 8 10 12 14

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

Fonte Referência Descrição

Mendeley (MERRIL, 2006) Mashups: The new breed of web app

IEEE (LIU e LIANG, et

al. 2009)

Using Architecture Integration Patterns to Compose

Enterprise Mashups

CiteSeerX (VECCHIOLA;

CHU; BUYYA,

2009)

Aneka: A Software Platform for .NET-based Cloud

Computing

Google Scolar (BEHRENDT et al.

2011)

IBM Cloud Computing Reference Architecture 2.0

Google Scolar (WEISSMAN,

2010)

The Force.com Multitenant Architecture

Understanding the Design of Salesforce.com’s

Internet Application Development Platform

CiteSeerX (KOSSMANN,

KRASKA,

LOESING, 2010)

An Avaluation of Alternative Architectures for

Transaction Processing in the Cloud.

Google Scolar (HOFF, 2011) Facebook: An Example Canonical Architecture for

35


Scaling Billions of Messages

Google Scolar (AVRAM, 2009) Twitter, uma arquitetura Evoluindo

Mendeley (MCCANN e

HUEBSCHER,

2004)

Evaluation Issues in Autonomic Computing

IEEE (IBM, 2006) An Architectural Bluepoint for Autonomic Computing

Google Books (GOVERNOR, et

al. 2009)

Web 2.0 Architectures

Tabela 2. Materiais selecionados para o estudo

3.4 DEMONSTRAÇÃO DOS RESULTADOS DAS ARQUITETURAS DE

REFERÊNCIA INVESTIGADAS

Nessa seção as arquiteturas averiguadas nos materiais serão relatadas. O objetivo do

relato é auxiliar na compreensão dos resultados encontrados.

3.4.1. ARQUITETURA DE REFERÊNCIA PARA MASHUPS – QP1

O Mashup é uma aplicação Web que faz uso de dados de variadas fontes

objetivando criar um novo serviço. Na verdade essa aplicação emprega códigos de outras

aplicações por meio de uma API (O’REILLY, T, 2008). Um exemplo de Mashup é o site

Wikicrimes que mapeia nas regiões o índice de criminalidade com a ajuda do Google Map.

O Mashup tem a sua plataforma de programação sustentada pela própria Internet, ou

seja, uma característica de aplicações da Web 3.0; todavia, não apenas esta particularidade é

notada, mas também a própria definição de Mashup o posiciona como uma Máquina Social.

Atualmente existem duas definições para a arquitetura de Mashups, ambas utilizam como

referência a arquitetura em camadas e serão exposta a seguir.

36


3.4.1.1. Arquitetura Mashup Proposta por Merril em 2006

A primeira definição é a mais disseminada e apresenta a arquitetura com grau de

abstração maior em um nível menor de detalhamento, tal definição é de Duane Merril, 2006;

propõe que a arquitetura do Mashups seja composta de (ver figura 5):

Web Browser: interface de comunicação entre o usuário e o Mashup;

Site Mashup: camada lógica onde o Mashup está implementado pode ser um

servidor, ou mesmo o próprio browser do cliente com Applet20,, por exemplo;

API: são os provedores de conteúdo que disponibilizam seus dados por meio de

protocolos.

Figura 5. Arquitetura Mashup por Duane Merril

O principal questionamento acima desta proposta, além dela não demonstrar muita

riqueza de detalhes, é sobre a arquitetura não prever a integração dos dados, tais dados podem

estar em diferentes formatos como XML ou HTML, e também em diferentes semânticas,

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

37


enfim, são fontes heterogêneas que por vezes não trabalham através de uma API, dificultando

assim o trabalho com os dados.

3.4.1.2. Arquitetura Mashup Proposta por Liu em 2009

A segunda definição é de Yan Liu (2009), cujos padrões utilizados são os seguintes:

Piper and Filter: padrão responsável pela geração e pelo fluxo dos dados, este

padrão possui componentes interligados onde cada um executa uma função

específica.

Data Federation: responsável pela integração de dados, este padrão é útil quando

se deseja integrar dados provenientes de muitas fontes diferentes. Diversas

empresas armazenam seus dados em repositórios diferentes, como: bancos de

dados transacionais, sistemas de business intelligence, sistemas legados e outros;

cada um desses sistemas de armazenamento tem sua própria maneira de acessar os

dados, o que traz problemas no momento da busca. O padrão Data Federation

ajuda a obter e agregar esses dados, além de facilitar a consulta aos mesmos.

MVC: O padrão Model-view-controller tem um papel importante, uma vez que o

model acessa a camada de dados da aplicação, por sua vez, o controlador se

comunica com o model para localizar a view requisitada pelo usuário. Neste

padrão as tecnologias HTML, XML e JavaScript podem ser utilizadas. O model

ainda implementa o padrão Data Federation, enquanto os controladores

implementam o padrão Piper and Filter. Diante da solução apresentada, é possível

fazer algumas análises.

O padrão Piper and Filter traz simplicidade à arquitetura, assim como facilidade de

manutenção e escalabilidade, pois novos filters podem ser inseridos na composição da

arquitetura sem prejudicá-la. A manutenção destes filtros também é facilitada devido a sua

reusabilidade. Na verdade, esse padrão favorece o processamento concorrente. Os filtros, em

particular, fazem o processamento, pois cada filtro tem uma função definida. Após o

processamento ocorre a geração dos dados. Estes são repassados para o Piper (conector), que,

por conseguinte, os lêem e repassam para os próximos filtros. Esse ciclo é contínuo até que

haja demanda de processamento.

38


Vale ressaltar que, para o padrão Piper and Filter, os conectores podem assumir um

comportamento variado no processo. Eles podem ser um protocolo de comunicação ou uma

cache. O importante é que eles realizem a leitura dos dados e os repassem para o filtro mais

adequado (BUSCHMANN, MEUNIER, ROHNERT, SOMMERLAD e STAL, 1996).

Em contrapartida, no estilo Pipers and Filters os componentes não conhecem o

estado um do outro, sendo assim, quando ocorre um erro em um dos componentes o sistema

todo deve ser reiniciado, pois não se tem conhecimento da função que o filtro estava

executando no momento do erro, tal disfuncionalidade ocasiona perda de informações

(GARLAN e SHAW, 1994). Por fim, o estilo em questão, por ser orientado através de função

não se mostra apropriado à representação dos dados.

O grande desafio dos Mashups é reunir dados de diversas fontes para criar um único

serviço, logo, sua arquitetura deve assegurar a correta integração, gerenciamento,

transformação e organização dos dados. Neste sentido, a adoção do estilo Piper and Filter

pode não agregar tantas vantagens justamente pela possibilidade das fontes de dados sofrerem

algum tipo de problema e falharem, deixando o Mashup vulnerável. Este problema não é

solucionado pelas arquiteturas propostas.

3.4.2. ARQUITETURA DE REFERÊNCIA PARA CLOUD COMPUTING –

QP2

Atualmente existem algumas propostas de Arquitetura de Referência para Cloud

Computing, dentre as quais, aquelas que consideram as camadas de serviço: IaaS, PaaS, e

SaaS como sendo a arquitetura da computação nas nuvens. Contudo, tais camadas são

modelos de serviços oferecidos pela Computação nas Nuvens, e não modelo de arquitetura,

conforme explicado.

Apesar das propostas existentes, o Instituto Nacional de Ciência e Tecnologia –

NIST21, situado nos USA, afirma que de fato não existe para Cloud Computing uma

arquitetura de referência. O NIST afirma que um dos seus objetivos é formular tal arquitetura

em conjunto com outros institutos e com empresas do mercado americano.

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

http://www.nist.gov/index.html.%20Acesso%20em:%2001


Ainda consoante o instituto, a arquitetura a ser formulada deve facilitar a

comunicação, ilustrar os vários serviços da nuvem e proporcionar o desenvolvimento de

aplicações com alta escalabilidade, segurança e portabilidade. O instituto prevê uma

arquitetura de referência que seja adequada também aos modelos de implantação de Cloud

Computing, os quais são, segundo Peter Mell e Tim Grance (2009):

Nuvem Pública: A infraestrutura das nuvens é disponibilizada para o público.

Qualquer usuário que conheça a localização do serviço poderá acessá-la.

Nuvem Privada: A infraestrutura de nuvem é utilizada exclusivamente por uma

organização, sendo administrada pela própria organização, ou por terceiros,

especializados em administração e manutenção de Cloud Computing.

Nuvem Comunidade: A infraestrutura de uma nuvem é compartilhada por

diversas empresas.

Nuvem Híbrida: A infraestrutura é composta de duas ou mais nuvens que podem

ser públicas, privadas e comunitárias, todas devem estar interligadas por uma

tecnologia padrão, permitindo total portabilidade.

Nesta seção vamos descrever três arquiteturas de referência para Cloud Computing, a

primeira baseada nos estudos de Christian Vecchiola de 2009, a segunda proposta por

KOSSMANN, KRASKA e LOESING em 2010, e a terceira determinada pela empresa IBM

no ano de 2011.

3.4.2.1. Arquitetura Cloud Computing proposta por Vecchiola

A Figura 6 retrata uma das arquiteturas mapeadas neste estudo. Em seguida estão as

explicações para cada parte que compõem a arquitetura.

A camada Cloud Applications é a mais básica, uma camada de aplicação onde os

usuários finais podem manter seus programas na nuvem. Nesta camada também estão os

aplicativos e os SaaS, todas as aplicações podem ser adquiridas pelos usuário de forma

dinâmica conforme a necessidade do mesmo. Abaixo desta camada está a camada Cloud

Programming. A relação entra elas reside no fato da camada inferior dar suporte à camada

40


superior, sendo assim, a camada mais abaixa Cloud Programming disponibiliza os serviços e

os recursos para se implementar o software sob demanda.

A Cloud Programming também pode ser chamada de Middleware User-Level, nela

podem ser desenvolvidos os aplicativos e regulado o suporte ao desenvolvimento, são

basicamente ferramentas e ambientes que podem possuir interface Web 2.0, recursos de

programação distribuída, bibliotecas e linguagens de programação, além de ferramentas para

o desenvolvimento de sistemas Mashups. Esta camada é similar a uma PaaS.

A penúltima camada de Middleware Core é responsável pelo gerenciamento da

infraestrutura física, tal camada oferta serviços para a manutenção de QoS22 e SLAs23, serviços

de virtualização e outros. Todos os recursos dispostos nesta camada são acessados pela

camada diretamente acima dela, pois somente assim, o usuário poderá usufruir dos recursos,

haja vista o acesso à camada Middleware Core seja negado. Por fim, a camada de mais baixo

nível é a de infraestrutura física que contém Data Centers e conjuntos de CPU’s, além de

outros recursos de hardware, os quais podem ser agregados ou subtraídos com liberdade,

oferecendo assim, bastante flexibilidade à arquitetura. Estas duas últimas camadas inferiores

se comportam como IaaS.

Figura 6. Arquitetura Cloud Computing por Vecchiola

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

22 QoS – Quality of Service (TANANBAUM, 2003)23 SLAs – Níveis de serviços definidos em um contrato (MELL e GRANCE 2009)

41


Uma crítica construtiva que pode ser feita a respeito desta arquitetura é sobre o seu

estilo, sendo tipicamente em Camadas, toda camada tem uma responsabilidade distinta, além

disto, os recursos de cada camada podem ser reorganizados, pois a própria vai se readaptando.

Deste modo, quando houver necessidade de economia no investimento, aquela estará

preparada. Enquanto isso, o gerenciamento de cada camada pode ser feito independentemente.

No contexto deste trabalho, esse modelo de arquitetura pode ofertar soluções para a

manutenção da aplicação e independência entre as partes que a compõem.

3.4.2.2. Arquitetura Cloud Computing proposta por KOSSMANN, KRASKA e LOESING.

A arquitetura mais utilizada por PaaS e IaaS (KOSSMANN, KRASKA e LOESING,

2010) é tradicionalmente em camadas. A Figura 7 representa a arquitetura.

Figura 7. Arquitetura de referência para Cloud Computing por KOSSMANN, KRASKA e LOESING, 2010.

Fonte: An Evaluation of Alternative Architectures for TransactionProcessing in the Cloud

Segundo os autores, essa arquitetura é composta por uma camada de interface de

usuário, essa faz uso de balanceadores de carga para distribuir os pedidos de clientes, e ofertar

assim, um tempo de resposta melhor a cada solicitação. O balanceador repassa as solicitações

para máquinas disponíveis em uma camada inferior. Estas processam as solicitações (HTTP)

de clientes e repassa ao servidor de aplicação que executa a lógica do aplicativo especificado.

Tal execução pode ser nas linguagens Java ou C++ com SQL embutido, por exemplo. Todas

essas tarefas ocorrem na mesma camada central.

42


Ainda na mesma camada residem os servidores de banco de dados que controlam as

ações de leitura e escrita no banco. Tal banco, por sua vez, é logicamente particionado em

uma camada dedicada a ele; cada partição é controlada por um servidor. Essa abordagem é

conhecida na literatura como Esquemas de Particionamento (STONEBRAKER e

HELLERSTEIN, 2005), esse conceito foi aplicado não só na camada de banco de dados,

como também, na camada dos servidores de aplicação, servidores web e servidores banco de

dados.

Para Cloud Computing essa arquitetura oferece escalabilidade total e elasticidade em

todos os níveis de camada, pois cada solicitação HTTP pode ser encaminhada para qualquer

servidor, seja de aplicação, web ou banco de dados; isto se revela como um diferencial que

agrega muitos benefícios. Apesar do diferencial a arquitetura foi especificada de forma

relativamente superficial.

Todavia a arquitetura em questão sacrifica a consistência dos dados devido ao

particionamento e a necessidade de se conseguir disponibilidade. Consistência e

disponibilidade não são obtidas ao mesmo tempo em nenhum sistema particionado em rede

(BREWER, 2000). Com isto é necessário criticar a falta de soluções alternativas que

garantam a consistência total aos dados e serviços. Disponibilidade é um requisito importante

para qualquer sistema disperso na Web. Deixar este requisito negligenciado é uma falha

potencial da arquitetura.

3.4.2.3. Arquitetura Cloud Computing proposta pela empresa IBM

A IBM em seu centro de pesquisa no ano de 2011 propôs uma arquitetura de

referência para Cloud Compunting. O objetivo seria definir uma arquitetura única que

permitisse aos ambientes de programação nas nuvens: economia no investimento dos recursos

necessários, boa qualidade na prestação de serviços e otimização de recursos. A Figura 8

define a IBM Cloud Computing Reference Architecture - CCRA, proposta por Michael

Behrendt, 2011.

43


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

Fonte: IBM Cloud Computing Reference Architecture 2.0

A arquitetura de referência proposta pela IBM é rica em detalhes e abrange um nível

maior de complexidade em relação aos serviços; é novamente baseada no conceito de

Camadas e, como se pode notar através da Figura 8, existem 02 (duas) grandes camadas

externas voltadas à Governança de TI e requisitos de qualidade. A arquitetura foca nos

serviços e recursos que a nuvem oferta e necessita, desse modo, os detalhes tecnológicos

foram subtraídos na descrição da responsabilidade de cada camada. Tais responsabilidades

serão expostas no decorrer desta subseção.

Enquanto a camada de Governança trata dos recursos tecnológicos bem como os

processos de TI que devem sustentar e melhorar as estratégias e os objetivos organizacionais.

A camada de qualidade trata de aspectos voltados a manutenção da segurança, da

recuperabilidade do sistema diante às falhas, de desempenho e da “Consumibility”.

Consumibility é um termo bastante utilizado pela IBM para expor qual o nível de adequação

do produto ao cliente. Seria um requisito de qualidade que vai além dos requisitos de

usabilidade, adequação e acurácia, pois além de avaliar se o produto de software está

satisfazendo o cliente, visa ainda avaliar se o produto foi bem instalado, se o cliente está

usufruindo do produto e, se a aplicação deve ser atualizada a fim de corrigir erros e agregar

melhorias.

44


Ainda nesse contexto, as três camadas centrais serão elucidadas: Cloud Service

Consumer, Cloud Service Provider e Cloud Service Creator. Observando inicialmente essas

camadas, alguns conceitos devem ser resgatados, como: os conceitos de arquitetura de

software; e desenvolvimento modular de software, em que cada módulo a ser desenvolvido

deve disponibilizar uma interface provida que ofertará serviços, além de uma interface

requerida que exibe quais os serviços necessários (BASS, CLEMENTS, KAZMAN, 2003).

A camada de Cloud Service Consumer tem a responsabilidade de alocar os recursos

que consomem serviços da nuvem e, ainda alocar as pessoas que serão oneradas pelo uso dos

serviços, na qual todos os consumidores poderão interagir com os pacotes de serviços

oferecidos pela própria camada.

A Cloud Service Consumer possui diversos elementos, dentre eles, o Cloud Service

Integration Tools. Esse elemento faz a integração dos serviços da nuvem aos serviços e

recursos locais da organização consumidora, como por exemplo, um sistema legado. Como

último elemento dessa camada temos o Consumer In-house IT, este componente pode estar

presente em qualquer camada da arquitetura, visto que concentra as tecnologias que

proporcionarão a integração dos recursos de TI da empresa aos recursos da nuvem, podendo

conter infraestrutura, Middleware, aplicações de negócios e gestão de serviços.

A camada de Cloud Service Provider é a camada da nuvem responsável pela

prestação de serviço, onde os componentes têm a liberdade de exibir seus serviços, criar

outros serviços, e solicitar serviços a outros componentes. É a camada mais rica em

elementos, que são:

Cloud Services: Este elemento além de manter todos os modelos de serviço de

Cloud Computing já conhecidos (SaaS, IaaS, PaaS); contém ainda o Business

Process as a Service – BpaaS responsável pela modelagem dos processos de negócio

de quaisquer serviços entregues pela nuvem, desde os tradicionais serviços de

hospedagem de aplicação, até negociação de compra e venda em Web Commerce.

Completando o elemento Cloud Services, está o Cloud Service Creation &

Ecosystem Aspects, cuja relação ocorre entre o serviço ofertado pela nuvem e os

produtos que podem ser obtidos por meio desses serviços. Por exemplo, é o Cloud

Service Creation & Ecosystem Aspects que faz a seguinte correspondência na nuvem:

45


O serviço da Amazon EC2 é um eco-sistema voltado para a IaaS em que seus

produtos poderão auxiliar na alocação de uma PaaS.

Common Cloud Management Platform (CCMAP): Esta camada ao lado da

Cloud Services se divide em dois componentes principais: Operational Support

Services - OSS e Business Suport Services - BSS. Ambos os componentes trabalham

para dar suporte aos serviços da nuvem e aos clientes que consomem serviços da

nuvem.

Infrastructure: representa todos os elementos de infraestrutura necessários para

que os provedores forneçam os serviços para nuvem. Isso engloba todas as

instalações necessárias, desde Data Centers e demais recursos de rede, vale

mencionar que não existe qualquer tipo de software rodando sobre esta camada.

Por fim a camada Cloud Service Creator com o seu elemento Service Creation

Tools, possui todas as ferramentas que irão gerar os serviços da nuvem. Tais ferramentas

incluem ambientes da programação de software, ferramentas de layout de interface gráfica,

ferramentas para virtualização, e outras. Nesse sentido, após a elucidação de mais uma

proposta sobre arquitetura para Cloud, é possível a formulação das seguintes conclusões.

Na abordagem da arquitetura, a IBM afirma que Cloud Computing é bastante

semelhante à Arquitetura Orientada a Serviços – SOA, pois a Computação nas nuvens é

trabalhada em termos de criação, distribuição e consumo de serviços. Portanto, Cloud

Computing suporta orientação a serviços, uma vez que as empresas podem oferecer a

infraestrutura e a plataforma de desenvolvimento agregadas ao software como um serviço sob

demanda.

Como consideração sobre esta abordagem é válido observar que a arquitetura é mais

orientada aos papéis e funções que são desempenhados em Cloud Computing, explora

adequadamente o estilo em camadas, busca flexibilidade e modularidade na manutenção de

cada camada, o que fornece maior rapidez no desenvolvimento. Tanto esta arquitetura quanto

a arquiteturas apresentada em 2009 são mais conceituais, não exploram em demasia o nível

técnico, e trabalham com um nível maior de abstração, sendo que o último modelo exibe mais

os aspectos dos serviços que são ofertados pela nuvem e como eles devem ser organizados.

46


Nas pesquisas de Máquinas Sociais é sempre válido explorar Cloud Computing, pois

este é um conceito que visa desenvolver e manter aplicações para WEB 3.0, (TSAI et al,

2011) e consequentemente está repleto de tecnologias que materializam o conceito de

Máquinas Sociais. Portanto, na próxima seção, uma arquitetura dedicada a essas tecnologias

será exposta, aproveitando o ensejo de que ela surgiu por meio de uma das questões de

pesquisa.

3.4.3. ARQUITETURA MULTITENANT DE REFERÊNCIA PARA

SOFTWARE AS A SERVICE – QP2

A arquitetura homologada para as aplicações da Force.com, uma das maiores

plataformas de desenvolvimento na Computação nas Nuvens, é a Multitenant ou multi-

inquilino. Essa prevê o compartilhamento da unidade interna computacional, dos dados e da

instância física de armazenamento, propiciando assim, a cada desenvolvedor, tão-somente, a

preocupação em montar o fluxo de sua aplicação com as regras de negócio.

A arquitetura disponibiliza as funções da Force.com compartilhando objetos.

Todavia ela executa a distribuição das partições virtuais na plataforma para que outras

aplicações ou módulos de sistemas sejam agregados (AZEEZ et al, 2010). O que se faz

através da Multitenant é personalizar os objetos disponíveis para que eles atendam a

finalidade do negócio (software) reduzindo drasticamente o tempo de desenvolvimento.

Na Figura 9 se ilustra a Multitenant. Nela, cada camada desenvolve uma função bem

definida. Para isto, elas contam com o auxílio de recursos, como por exemplo: a customização

de objetos ou funcionalidades por meio de controladores e de implementações no código Apex

(linguagem de programação da Salesforce que compõe a camada “Configuration”)

(BEZEMER e ZAIDMAN, 2010). Nesta camada ainda existe a utilização da linguagem de

codificação de interface gráfica, a Visualforce (WEISSMAN, 2010).

47


Figura 9. Esboço da arquitetura Multitenant

Fonte: The Force.com Multitenant Architecture

Understanding the Design of Salesforce.com’s Internet Application Development Platform

O estilo Camadas é fundamental para a Multitenant, pois tal estilo proporciona a

separação das camadas deixando a lógica da aplicação (camada Configuration) livre para

implementar diferentes códigos conforme a aplicação do inquilino. Quanto as demais

camadas, a “Authentication” faz apenas o acesso do usuário, ou inquilino. Para cada novo

usuário é criado um novo acesso de modo que o inquilino tenha a sensação de que a aplicação

é totalmente dedicada (BEZEMER e ZAIDMAN, 2010).

A última camada funcional chamada “Database Pool” é responsável por criar

registros únicos nos bancos de dados, pois como as aplicações são compartilhadas, existe a

necessidade de consultas e inserções individuais nas bases de dados para cada inquilino, o

objetivo é garantir que um determinado usuário acesse apenas os seus dados. Neste sentido,

para melhorar o desempenho da arquitetura, são utilizados balanceadores de cargas que

distribuem os acessos (BEZEMER e ZAIDMAN, 2010).

A especificação da arquitetura Multitenant é bem clara, onde cada camada possui

uma responsabilidade bem definida tratando de aspectos essenciais a uma aplicação, como o

48


cuidado com os dados e bases de dados. Em relação a este aspecto cabe uma crítica; o

armazenamento e tratamento dos dados pode ser crítico para algumas aplicações multi-

inquilino que não utilizem sistemas de banco de dados preparados para lidar com o tipo de

arquitetura exposta nesta seção. Diante disto, seria interessante que a arquitetura Multitenant

ofertasse uma camada que abstraísse o tratamento dos dados, e que fosse mais específica

quanto a este tratamento. Muitos pontos em relação aos dados são delicados, e exigem que a

arquitetura trabalhe melhor o isolamento, algo que compõem muitas das exigências de alguns

clientes.

3.4.4. ARQUITETURA PARA REDES SOCIAIS – QP3

As arquiteturas investigadas para esse tipo de SM são baseadas no estilo Camadas.

Entretanto, essa arquitetura ostenta “formatos” diferenciados que dependem das

características e não apenas dos requisitos de cada rede. A mesma arquitetura de referência é

explorada tanto pelo microblog Twitter quanto pela poderosa rede Facebook. No entanto, são

abordagens diferentes da mesma arquitetura, explorando tecnologias diferentes.

Vale salientar que as redes sociais exploradas nessa seção são plataformas

programáveis. Com elas, é possível criar novas aplicações utilizando-se apenas a Internet

(APIWIKI, 2010). Tal característica as transformam em Máquinas Socias. A seguir,

exploremos uma breve sinopse sobre cada rede, com as respectivas tecnologias adotadas e sua

arquitetura. O Twitter iniciará a seção.

O Twitter foi aberto ao público em meados do ano de 2006, além de ser um micro-

blog ele é uma rede social propriamente dita e ainda uma ferramenta de Broadcast. A rede em

abril do ano de 2010, segundo seu cofundador Biz Stones, conquistou a cifra de 105 (cento e

cinco) milhões de usuários. Abaixo, delineamos algumas características importantes dessa

rede.

O Twitter pode ser acessado via dispositivos móveis. Atualmente o micro-blog

possui integração com outras redes sociais. No ano de 2008, foi incorporado um mecanismo

de busca ao micro-blog. Outra característica importante do Twitter é a sua API. Ela oferece,

entre outros, a busca de serviços que possam ser indexados em aplicações terceiras (AFRAM,

2009). A arquitetura do micro-blog é ilustrada na Figura 10.

49


Na arquitetura Twitter a camada de apresentação labora com os serviços dos clientes,

algumas tecnologias são empregadas como: Json24 e Rails25, a camada realiza ainda

renderização e caching. Logo abaixo está a camada de negócio, trabalhada por meio das

linguagens C, Java e Scala, esta última favorece a escalabilidade em relação ao crescimento

do número de seguidores. Por último encontra-se a camada de dados suportada por bancos de

dados não relacionais, os chamados NoSQL, que oferecem resiliência e escalabilidade (LAI,

2009); como exemplo desses bancos encontra-se o Cassandra26 e o Hbase. Em seguida

examinaremos a arquitetura do Facebook.

Figura 10. Arquitetura do Twitter

A arquitetura do Facebook contém uma camada a mais em relação ao Twitter, uma

camada dedicada à comunicação, pois o Facebook trabalha com recursos de mídia mais

complexos, como fotos e vídeos; nesta questão somente as visualizações das fotos podem

ultrapassar o montante de 3 (três) milhões27. Esta rede ainda possui um chat para conversação

entre as pessoas conectadas e registradas como amigos. Por essas características e outras, o

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

50


Facebook, que hoje é a maior rede social do mundo, tornou-se também um desafio para a

escalabilidade.

Para prover a escalabilidade, os arquitetos do Facebook usam uma combinação de

tecnologias, principalmente softwares para escalar, como o Map Reduce para processar e

analisar grande volume de dados. Utiliza ainda o Varnish como balanceador de carga e o

Haystack para a recuperação de fotos (HOFF, 2011).

O Facebook além de ser a rede social mais notável da atualidade, se caracteriza

fortemente por ser uma plataforma para geração de aplicativos e serviços, que disponibiliza

uma API e possui integração com plataformas diferenciadas (FACEBOOK DEVELOPERS,

2010). Apesar disto, as arquiteturas das duas redes possuem particularidades como a seguir.

O serviço de Cloud Computing auxiliou as redes sociais no armazenamento de dados

e na disponibilidade de recursos, o que facilitou a escalabilidade. Tanto Facebook quanto

Twitter utilizam banco de dados NoSQL. O software Memcached28, por sua vez foi

implementado dentro da camada de negócio de ambas as redes para melhorar o desempenho,

visto que o Memcached armazena a informação em memórias distribuídas, recuperando-a

mais rapidamente, evitando assim, tarefas repetitivas e demoradas de recuperação de

informação em banco de dados (GALBRAITH, 2009).

Concluindo esta sessão, vale registrar que a arquitetura do Facebook não foi ilustrada

neste capítulo, pois não foram encontrados materiais que explicassem em detalhes maiores

como as camadas de tal arquitetura interagem. Os materiais capturados faziam referência

apenas às decisões de projeto e tecnologias adotadas. Aliás, as arquiteturas das redes sociais

exploradas trabalham mais com questões tecnológicas. Neste aspecto foi possível notar que

estas arquiteturas se diferem mais em relação às decisões de projeto, ou seja, de quais

tecnologias utilizar.

Para a definição de qualquer arquitetura é fundamental declarar as decisões de

projetos. Estas estão diretamente ligadas ao design da arquitetura. Assim, os resultados da

questão sobre as arquiteturas de redes sociais se adaptam mais as decisões de projeto, o que

apesar de ser relevante para este estudo, deixa uma lacuna sobre a consolidação de uma

modelo arquitetural para estes tipos de SM’s.

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

51


3.4.5. ARQUITETURA DE REFERÊNCIA PARA SISTEMAS AUTÔNOMOS – QP4

Um sistema autônomo é aquele que tem mecanismos para se autogerenciar por meio

de autocontrole e monitoramento, assim, ele tem a capacidade de adaptar-se aos padrões

esperados e especificados; um sistema desta categoria é formado pela colaboração de

elementos autogerenciáveis.

Segundo Paul Horn (2001) um sistema só é autônomo se ele for flexível para se

adaptar às mudanças do ambiente. E, ainda, define como principais propriedades de um

sistema autônomo:

1. Autocura: propriedade do sistema que assegura sua recuperação automática

após a ocorrência de uma falha;

2. Auto-otimização: ajuste automático dos parâmetros de recurso para otimizar a

utilização dos mesmos;

3. Autoproteção: capacidade de se auto defender de ataques ou invasões

maliciosas;

4. Autoconfiguração: ajustar a configuração do sistema conforme as variações do

ambiente, de modo que, o sistema funcione corretamente satisfazendo a

necessidade do usuário (IBM, 2003).

Ademais, definindo as características de um sistema autônomo, o mesmo deve

manter relacionamento com outros elementos, em especial, seus provedores e consumidores

de serviço (IBM, 2006). Esses relacionamentos irão possibilitar que os sistemas autônomos

conheçam o estado uns dos outros e o seu próprio estado, facilitando, desta maneira, a

obtenção de dados sobre o estado dos recursos, memórias, volume de dados e também

vulnerabilidade (STERRITT e BUSTARD, 2003). Tais dados são obtidos por meio de

operações em sensores, como:

Request-Response: operações que são de solicitação ou resposta de sobre o

estado de um elemento.

A comunicação também é necessária para que o sistema altere seu estado ou

comportamento conforme necessário. Para esta comunicação, é necessário (IBM, 2003):

52


Solicit-Response: é a requisição de informações do sistema para sua unidade de

controle.

Conforme explicado em relação aos sistemas autônomos, nota-se que eles são

Máquinas Socias legítimas, sobretudo no aspecto dos relacionamentos. Esses relacionamentos

entre sistemas são fundamentais para o próprio aprendizado da máquina. É deste modo que

um sistema autônomo consegue se auto gerenciar e tomar decisões. O sistema deve saber qual

o seu nível aceitável de funcionamento, as condições que ele poderá ser submetido, e como

manter a qualidade dos seus serviços mesmo sobre condições adversas (MCCANN, e

HUEBSCHER, 2004).

Nota-se aqui que sistemas autônomos também estão fortemente relacionados a

inteligência artificial, sistemas especialistas e sistemas baseados em conhecimento; de sorte

que podem ser utilizados em sistemas de computação em grade ou computação ubíqua (IBM,

2003). A seguir uma das arquiteturas de referência proposta para esses sistemas autônomos

será explorada. A arquitetura foi proposta por Mccann, e Huebscher em 2004; e também por

White et al., em 2004. As explicações sobre esta arquitetura foram baseadas nos trabalhos

destes estudiosos.

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

A Figura 11 representa o esboço da arquitetura de referência para um sistema

autônomo em que sondas são inseridas na arquitetura para monitorar o sistema. Essas sondas

ou sensores captam informações do ambiente externo e repassam para outros tipos de

sensores, estes irão comparar os dados capturados às variáveis especificadas para o sistema,

ou seja, aos requisitos desejados em desempenho, tolerância à falha e outros.

53


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

Após a captura e análise dos parâmetros, o elemento responsável pelo controle do

sistema, chamado de gerenciador ou calibrador, faz uso das informações analisadas para

controlar e adaptar a operação do sistema, a fim de atingir o comportamento desejado. Esse

calibrador deve interagir diretamente com a camada de negócio do sistema, ou ainda, compor

esta camada.

A arquitetura de um sistema autônomo deve ser dividida, como observado na Figura

11. Enquanto a primeira parte comporta os sensores e calibradores, a segunda parte é

composta pelas partes relacionadas a lógica de negócio e ao acesso a dados. Isso possibilita

que sistemas desse tipo possam ter sua arquitetura composta por diversos estilos arquiteturais,

dependendo do tipo, requisitos e limitações do sistema.

O estilo arquitetural Peer-to-peer29 geralmente é uma excelente escolha para a

segunda parte da arquitetura de um sistema autônomo, pois esse modelo de sistema tem como

forte característica a distribuição. Tal característica é forte porque comumente todos os

elementos da arquitetura do sistema são também autônomos, onde cada camada pode ter sua

própria arquitetura autônoma. Isto se revela como uma crítica positiva a esta arquitetura.

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


Outra interpretação que se pode ter é que a arquitetura de um sistema autônomo pode

ser dupla. Uma arquitetura assegura a infraestrutura que permite o monitoramento e análise

dos componentes, enquanto a outra é a própria arquitetura do sistema que garante o correto

funcionamento dos requisitos. Ambas estão entrelaçadas. Esta interpretação não é definitiva, a

própria arquitetura não foi exibida desta maneira, nem ao menos existiram suposições a

respeito disto, o que pode se revelar como um fator negativo na especificação desta

arquitetura. Não obstante ao modelo apresentado, ele não é o único. Existem outras

abordagens, inclusive defendidas por grandes empresas como a IBM (IBM, 2003).

3.4.5.2. Arquitetura Autônoma Proposta Pela Empresa IBM

Segundo a IBM uma arquitetura de referência para computação autonômica deve

realizar três objetivos fundamentais. Primeiramente, deve descrever as interfaces externas e

comportamentos necessários de componentes do sistema. Em segundo plano, deve descrever

como compor esses componentes para que eles possam cooperar para as metas de todo o

sistema. Finalmente, deve descrever como compor as propriedades de autogestão do sistema.

A arquitetura IBM é explicada em seguida:

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

Fonte: IBM, 2003

55


Como ilustrado na Figura 12 a arquitetura é composta por duas camadas mais

inferiores que exercem, respectivamente, as funções, de conter recursos físicos de infra-

estrutura de TI ou mesmo softwares de gestão; e prover interfaces de gerenciamento para

controlar os recursos gerenciados. Essas interfaces padrão são entregues através de um

terminal de gerenciamento.

A terceira camada chamada Touchpoint Autonomic Managers contém gerentes

autônomos de quatro categorias de autogestão, a auto configurável, autocura, auto- otimização

e autoproteção). A camada acima desta, contém gestores autônomos que orquestram outros

gestores de cada categoria. Essa camada oferece a capacidade autônoma ao sistema,

incorporando maior controle sobre a infra-estrutura geral de TI.

A camada mais superior fornece interfaces de comunicação entre os usuários e o

sistemas, e entre estes sistemas e outros, facilitando a integração dos mesmos. A explicação

desta arquitetura não será rica em detalhes, pois a IBM, apesar de afirmar que a mesma pode

ser aplicada aos sistemas autônomos, classifica a arquitetura como sendo de referência para

computação autônoma em si. Contudo, seria interessante expor a arquitetura neste trabalho,

uma vez que, a diferença entre os conceitos de sistema e computação sejam muito sutis, os

sistemas se prevalecem dos conceitos da computação, e ambos abordam as premissas da

autogestão.

Cabe uma singela crítica a esta arquitetura; ela não demonstrou como o objetivo de

cada camada pode ser alcançado, mesmo que em alto nível, por ser uma arquitetura de

referência. Em todo o trabalho publicado no ano de 2003, a arquitetura apenas elegeu o uso de

Web Services para viabilizar a comunicação entre as interfaces de comunicação, bem como, a

adoção de Enterprise Service Bus - ESB para servir de barramento de integração entre as

camadas da arquitetura. Contudo a IBM deixou evidente em sua proposta, que o mais

importante em uma arquitetura para este tipo de SM’s é definir precisamente o

comportamento dos componentes arquiteturais e de suas interfaces de comunicação.

3.4.6. ARQUITETURA DE REFERÊNCIA PARA APLICAÇÕES WEB 2.0 – QP5

O livro Web 2.0 Architectures de James Governor, et al. (2009), sugere uma

arquitetura de referência para aplicações originais da WEB 2.0 nestas estariam aplicações

56


como Mashups e alguns tipos de redes sociais como o Flickr30. A arquitetura proposta é

ilustrada na próxima imagem.

Figura 13. Arquitetura de referência para aplicações WEB 2.0

Fonte: Adaptada de James Governor, livro: Web 2.0 Architectures; ano 2009

Os componentes desta arquitetura possuem a seguinte definição:

Resource Tier – É a base, ou infraestrutura que armazena todos os recursos que

capacitam os serviços da aplicação. Nesta camada residem os banco de dados,

interfaces com sistemas, diretórios, e outros. Esta camada pode ter subdivisões que a

tornam capaz de fazer a persistência de banco de dados;

Service Tier – Camada de serviços é responsável pela conexão destes serviços

ofertando controle sobre o fluxo de informações que transitam por entre a aplicação.

Conectivity (setas entre as camadas centrais) – Podem ser protocolos e padrões que

permitem o acesso aos serviços. Tais conexões devem exibir os serviços deixando

clara a responsabilidade de cada um;

Client Application Tier – É a camada em que o usuário acessa para consumir os

serviços da aplicação, nesta camada podem residir ferramentas que melhorem a

interaçao do usuário com a aplicação;

Design, Development, and Governance Tools – Esta camada é de suporte ao

desenvolvimento, pois contém um conjunto de ferramentas que auxilia os

desenvolvedores. As ferramentas podem ser ainda utilizadas no desenvolvimento dos

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


componentes das camadas de serviço e cliente. Esta camada é interessante para

customizar outras camadas e assim expandir e modificar as arquiteturas de aplicações

que usem esta arquitetura de referência.

Esta arquitetura de referência é interessante por ofertar uma divisão inteligente das

responsabilidades de cada camada. O seguinte exercício pode auxiliar em uma maior

compreensão. Supondo que seja necessário construir uma aplicação Web 2.0 que possa fazer

conexão com alguma API de outra aplicação. Neste caso, seria necessáiro contruir uma

interface na camada Resource Tier. Entretanto, se a aplicação em questão necessitar ter usa

própria API a camada Service Tier será a responsável. Tal camada irá definir protocolos de

acesso aos serviços e esses protocolos são os elementos arquiteturais Conectivity.

Essa arquitetura é um modelo para aplicações da segunda geração da Internet. Tal

modelo é útil por mostrar o objetivo de uma arquitetura de referência dedicada a Web, em que

algumas dessas aplicações, como os Mashups, são também da Web 3.0, e assim, Máquinas

Sociais. Fica nítido que a arquitetura é bem genérica, ficando sucetível à implantação de

tecnologias diversas, como: framework e Web services. Vale lembrar que essa capacidade de

implantação de tecnologias diversas foi classificada como um problema nesta pesquisa, haja

vista, a heterogeneidade excessiva de tecnologias agregue potencialmente retrabalho ao

desenvolvimento. Além deste ponto de heterogeneidade a arquitetura nem ao menos sugeriu

alguma tecnologia, ou padrão, para auxiliar na responsabilidade das camadas.

Durante a pesquisa, todas as arquiteturas de referência para a Web que se sucederam

foram estudos replicados deste. Não verificou-se nenhuma evolução significativa nem mesmo

outras abordagens que refutassem esta proposta. Com isto, para este trabalho de mestrado,

fica evidente que a proposta de arquitetura a ser sugerida no próximo capítulo, pode vir a ser

uma substituta moderna da arquitetura Web 2.0, uma substituta que só ocorreu devido ao

novo paradigma de Máquinas Sociais, que traduzem de outra forma as aplicações Web e a

própria web.

3.5. CONSIDERAÇÕES FINAIS DO CAPÍTULO – CRÍTICAS

58


Ao longo do estudo, várias pesquisas foram analisadas, algumas corresponderam

perfeitamente às questões investigadas, outras mostraram pouca contribuição. Neste sentido,

foi interessante verificar que a arquitetura de referência para aplicações Web foi tão pouco

abordada, apenas o estudo de James Governor considerou o assunto de maneira mais clara e

objetiva. O fato das aplicações Web serem desiguais em termos de funcionalidade e de

tecnologia pode ter motivado um relativa falta de classificação, o que talvez tenha dificultado

a criação de uma arquitetura de referência.

Classificando as aplicações Web 3.0 como Máquinas Sociais, é possível visualizar

uma melhor solução em arquiteturas de referências, pois que se conhece, e se define melhor,

os aspectos e particularidades das aplicações. O mesmo ocorre com os conceitos de Cloud

Computing, ao passo que, quando se definiu melhor os conceitos de CC, foi possível

encontrar muitos materiais que tratem do assunto por aspectos diferenciados.

Ao finalizar o estudo é possível mapear certas tendências sobre algumas tecnologias,

as quais foram utilizadas e relatadas repetidamente entre as arquiteturas. Essas tendências

apontam para:

Construção de API’s próprias; As API’s podem contribuir diretamente para a

extensibilidade da Máquina Social;

Utilização de API’s: API Java; API Twitter 4J, e API Facebook;

Utilização de balanceadores de carga para prover desempenho;

Utilização de Web Services;

Aplicação dos protocolos REST e SOAP;

Definição de arquiteturas com a camada de infraestrutura suportada por

Computação nas Nuvens;

Utilização de linguagens de programação que facilitem a rapidez na

codificação além de contribuir para o desempenho e escalabilidade do sistema,

como por exemplo: a adoção da linguagem Rails que já suporta PHP e REST;

Aplicação do estilo arquitetural Camadas.

Ao fim desta seção, vale observar o intensivo uso do estilo arquitetural em Camadas,

o qual organiza o sistema em unidades hierárquicas, se comportando como a evolução do

estilo cliente servidor, visto que as camadas solicitam serviços uma das outras, interagindo

entre elas como cliente e servido (GAMMA, et al 2000). Alguns autores defendem a adoção

59


do estilo arquitetural Camadas; Christine Hofmeister (2000), por exemplo, considera que o

estilo em camadas organiza a arquitetura do sistema por separar a parte funcional da parte de

apresentação, proporcionando assim, uma visão de módulos31 essencial para a documentação

do sistema.

As tendências pontuadas acima dão indícios que podem auxiliar no desenvolvimento

de SM’s, pois as soluções que se repetiram ao longo dos estudos foram empregadas em

grandes projetos dentro da indústria de software. Além deste ponto, as soluções mapeadas

contribuem, a priori, para a escalabilidade, proteção contra falhas, distribuição e

comunicação. Todos estes fatores estão ligados as características das SM’s, enquanto outros

fatores provocam controvérsias na aplicação das arquiteturas estudadas, o que será relatado a

seguir.

Materiais publicados e investigados para esta pesquisa revelam que algumas das

Máquinas Sociais exploradas se mantiveram eficientes, enquanto outras simplesmente saíram

do mercado. Como, por exemplo, as ferramentas online para desenvolvimento de Mashups.

Outro ponto questionável é a falta de mecanismos que previnam a interrupção de alguns

serviços Cloud Computing, como exemplo, o problema da Amazon (IaaS) no ano de 2011.

Segundo publicação da própria Amazon, no dia 21 de abril de 2011 o serviço EC2 foi

desabilitado devido a um problema técnico que causou falha no fornecimento do serviço de

uma das zonas de disponibilidade da Amazon. Esta zona trabalhava para os Estados Unidos e

deixou usuários do leste do país sem o serviço por mais de 24 (vinte e quatro) horas, alguns

gigabytes de dados foram perdidos.

Muitos dos casos semelhantes ao exibido acima se deve ao fato de que no modelo

arquitetural Camadas basta que o componente de uma camada entre em colapso para afetar

outros serviços e camadas dependentes. No modelo Camadas ocorre forte dependência entre

as camadas, se fazendo necessário alguns artifícios que previnam a falha de uma camada ou

que sustentem o serviço mesmo que sobre um problema.

Entre controvérsias e conformidades a tecnologia empregada faz total diferença. A

falha da Amazon é só um exemplo dos fatores negativos que a arquitetura de uma SM deve

estar preparada para enfrentar. Outra crítica é a heterogeneidade de plataformas, como as

Máquinas Socias são sistemas distribuídos por natureza, deve-se notar que existem algumas

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

60


diferenças tecnológicas, sejam em linguagens, sistemas operacionais ou paradigmas de

desenvolvimento em SM que hora são fornecedoras de serviços, hora são consumidoras de

serviços. Portanto, todas as decisões em projeto de SM’s devem ser bem analisadas e

empregadas na arquitetura.

A interoperabilidade é outro ponto preocupante na análise deste estudo, os

elementos arquiteturais devem trabalhar bem sobre este ponto, arquiteturas orientadas a

serviços, e adoção de protocolos como REST e SOAP, são iniciativas inteligentes que vem

gerando resultados produtivos nas aplicações mapeadas, mas que de fato, podem não ser tão

eficientes para algumas Máquinas Sociais. Neste aspecto, a Computação nas Nuvens é um

ponto de grande desafio, por isso o quantitativo de pesquisas e experiências tem sido tão

significativo, impulsionando os padrões que facilitam a comunicação e interoperabilidade em

plataformas e aplicativos nas nuvens (DMTF, 2011), bem como a criação de pacotes de

desenvolvimento SDK que algumas linguagens de programação como Java e PHP possuem.

Ainda entre estes questionamentos é interessante observar outros fatores, a

arquitetura Multitenant, por exemplo, ela constitui um modelo que compartilha recursos

físicos, o que poderá ser um fator de insegurança para alguns sistemas, apesar de favorecer

fortemente o crescimento da aplicação, em virtude da facilidade dos recursos.

O resultado deste estudo mostra boas direções para se atingir o objetivo deste

trabalho, entretanto, no contexto de desenvolvimento de software, tão importante quanto o

aspecto tecnológico, é o processo de concepção arquitetural. É extremamente relevante

conhecer o que se deseja construir, quais serviços são necessários, onde podem ser

encontrados, como será feita a comunicação e serviços e como elas irão impactar no

comportamento do software ou aplicação. Assim, o próximo capítulo trará um material útil

para se obter tais conhecimentos e fundamentar uma boa arquitetura para as SM’s.

Tecer críticas, sejam elas positivas ou negativas, a respeito de arquiteturas é algo

delicado, haja vista a arquitetura seja muito particular ao software. Arquiteturas que podem

não parecer muito inteligentes fazem um software funcionar por anos. O que se pode

certamente afirmar é que toda arquitetura deve ser coerente aos requisitos não funcionais.

Com isto, na exibição de uma arquitetura, é importante deixar claro quais os requisitos

atendidos por ela. Isto não foi verificado para os estudos mapeados neste capítulo.

61


Além do problema acima relatado, existe também a ausência de um modelo de

referência em conjunto ao estilo arquitetural adotado para as arquiteturas que são de

referência. Como será visto no próximo capítulo, isto é fundamental para criação da

arquitetura, por serem informações que influenciarão nas decisões de projeto da mesma.

Para finalizar este capítulo, a tabela 3 sumariza, para as Máquinas Sociais, todos os

pontos relevantes que foram tratados, ou não, pelas arquiteturas. Os pontos são importantes

para as SM’s e ofertarão subsidio para a formulação da arquitetura de referência. Com a

tabela, é possível notar que o atendimento as necessidades materializa os requisitos mais

tratados pelas arquiteturas. São eles: performance por meio da expansão da arquitetura e

modificabilidade por meio da manutenção.

Necessidades

atendidas

Arq

uite

tura

Mas

hup_

Mer

ril

Arq

uite

tura

Mas

hup_

Liu

Arq

uite

tura

Clo

ud

Arq

uite

tura

Clo

ud

Arq

uite

tura

Clo

ud

Arq

uite

tura

Mul

tite

nant

Arq

uite

tura

Red

es S

ocia

is

Arq

uite

tura

Sis

tem

as

Arq

uite

tura

Aut

ônom

a IB

M

Arq

uite

tura

par

a W

eb 2

.0

Serviços X X X X

Comunicação

Facilitada

X X X X

Manutenção

Facilitada

X X X X X X

Infraestrutura X X X

Reatividade X X

Conectividade X X X X

Expansão X X X X X

Tabela 3. Pontos ou aspectos mais trabalhados pelas arquiteturas

62

Capítulo 4

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

Este capítulo propõe uma arquitetura de referência para Máquinas Sociais. Nele

serão abordados alguns conceitos sobre arquitetura de referência, a respeito das suas teorias e

concepção. A arquitetura de referência de Máquinas Sociais será exibida em visões. A

avaliação na qual essa arquitetura foi submetida também será exposta neste capítulo,

mostrando assim, como esta proposta pode ser adequada para as Máquinas Sociais.

63

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

4.1. INTRODUÇÃO

O estudo no capítulo anterior é um recurso que também objetiva mostrar o estado da

arte das arquiteturas de aplicações Web contextualizadas como Máquinas Socias. Apesar de

tais aplicações não deixarem evidente todas as particularidades e detalhes de suas arquiteturas,

foi possível entender a organização e concepção das mesmas, além ter um estudo de

referência para SM’s.

Através desde estudo é possível dispor de um protótipo de arquitetura de referência

para Máquinas Sociais. Trata-se de um modelo experimental que deve servir de precedente

aos exemplares de arquiteturas de SM’s. Como visto no capítulo 2, as SM’s podem ser

classificadas desde aplicações Web simples até frameworks e IaaS, com isto, a formulação de

uma arquitetura padrão para essas SM’s demandaria um tempo de pesquisa consideravelmente

maior, daí a intenção de sugerir um protótipo apenas para Máquinas Sociais que sejam

aplicações Web e que sejam do tipo Prossumers.

O objetivo de ofertar esse modelo é ter uma arquitetura que possa orientar no

processo de definição das arquiteturas de SM’s a serem construídas. Ou seja, essa arquitetura

seria um exemplo de como deve ser a arquitetura de uma SM, e deve ser entendida como o

arcabouço básico que será customizado conforme os requisitos da Máquina Social. Vale frisar

que tal modelo é mais adequado às SM’s que são aplicações WEB, assim, o trabalho é focado

em sistemas WEB, ou ainda Software as a Service.

Tratando-se de uma pesquisa que envolve fortemente arquitetura de software, cabe

aqui esclarecer melhor alguns pontos, principalmente os relacionados a arquitetura de

referência. Para se construir uma arquitetura de SM é necessário entender o software como

uma Máquina Social, e assim poder agir assertivamente sobre as análises e decisões de projeto

e consequentemente sobre a arquitetura. Deste modo tal arquitetura de referência parece ser

ideal justamente por ser um ponto de início para as arquiteturas de sistemas que resolvem

problemas de um mesmo domínio.

4.2. ARQUITETURA DE REFERÊNCIA

A intenção de originar uma arquitetura de referência parte do conceito de que a

arquitetura divide as funcionalidades e os fluxos de cada parte do software, demonstrando

64


como pode ocorrer a cooperação entre elas (BASS, CLEMENTS, e KAZMAN, 2003). A

arquitetura de referência facilitará o desenvolvimento modular do software que for projetado

acima dela. Esse desenvolvimento traz benefícios, como: redução do tempo de

desenvolvimento, pois já é um modelo que pode ser adaptado para a arquitetura; aumento do

reuso de software; auxílio para a equipe de desenvolvimento evitar erros já cometidos.

Por fim, arquiteturas de referência sugerem a implementação de módulos que tenham

interfaces bem definidas, tanto as Interfaces Providas, que disponibilizam serviços, como as

Interfaces Requeridas, que expõem as necessidades dos serviços, ou seja, a quem o módulo

precisa se conectar (GARLAN e SHAW, 1994).

Uma arquitetura de referência se origina de um ou mais padrões arquiteturais, e de

um modelo de referência32. A Figura 14 esquematiza esse raciocínio.

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

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

Modelos de referência são soluções a nível de negócio que tratam de problemas de

um mesmo domínio; os estilos ou padrões arquiteturais são os modelos que agrupam os

componentes arquiteturais de modo que os mesmos possam interagir sempre da mesma

forma, auxiliando assim na resolução de um problema (GOVERNOR, 2009). Seguindo tais

conceitos atingiram-se as arquiteturas de referência, que apresentam soluções técnicas às

arquiteturas de uma família de software (MULLER, 2011).

Para se compor uma arquitetura de referência é necessário trabalhar veementemente

no processo de formação com os requisitos não funcionais (qualidade); é necessário ainda

interagir com pessoas que façam parte do modelo de negócio para se obter informações sobre

o contexto de negócio e requisitos inerentes ao mesmo. Por fim, no processo de formalização

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

65

Modelo de Referência

Padrão ou Estilo

Arquitetural

Arquitetura de

Referência

Arquitetura de Software


de uma arquitetura de referência é necessário considerar fatores tecnológicos, conceitos,

requisitos de clientes, padrões e abordagens de desenvolvimento de software.

A tarefa de identificação dos clientes, para extração de requisitos, é a mais crítica,

haja vista que a extração dos conhecimentos exija fontes mais abrangentes, como:

documentos, pesquisas, ferramentas e profissionais, pois se trata de uma arquitetura muita

genérica. O que deve ser considerado para compor o processo de definição de uma arquitetura

de referência é exaltado nos estudos de Muller em 2011 e Nakagawa em 2006. Ambos foram

referência para este capítulo.

As exigências em projetos de arquitetura de referência são grandes por necessitarem

de observações em domínios ou famílias de softwares de modo que se possa definir uma

arquitetura genérica na qual desenvolvedores possam se basear para montar a arquitetura do

sistema (BASS, CLEMENTS, e KAZMAN, 2003) a ser desenvolvido. Arquiteturas de

referência são instanciadas em um projeto de software, e podem existir ou serem utilizadas em

diferentes níveis de abstração a partir de diversas perspectivas (BASS, CLEMENTS, e

KAZMAN, 2003).

O processo de formalização da arquitetura de referência ainda pode ser facilitado

quando se conhece experiências de arquiteturas já existentes para o domínio. Em uma análise

dessas arquiteturas é possível detectar a eficiência, ou não, das mesmas para a solução do

problema, isto possibilita uma visão mais objetiva das soluções que podem ser empregadas

para o domínio.

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

A arquitetura de referência que será formalizada deverá atuar como ponto inicial para

o desenvolvimento das arquiteturas de aplicações que fazem parte do modelo de referência no

qual as Máquinas Sociais estão inseridas. O estudo do capítulo 3 dirigido à arquitetura de

Máquinas Sociais será muito útil para absolver as experiências com arquiteturas direcionadas

as Máquinas Sociais. Enquanto isto todos os estudos feitos pela Universidade Federal de

Pernambuco e por organizações como o C.E.S.A.R (Centro de Estudos Avançados do Recife)

que resultaram na criação de um grupo direcionado ao estudo de SM’s, contribui fortemente

para a identificação das fontes de informação (clientes) e para o amadurecimentos do Modelo

de Referência.

66


A arquitetura de referência deve trabalhar bem os requisitos performance,

disponibilidade, modificabilidade, e interoperabilidade, o que na realidade não ocorreu em

todas as arquiteturas mapeadas no estudo do capítulo anterior. Assim, nem todas as

arquiteturas trataram as necessidades e requisitos fundamentais da Máquina Social. Apenas os

requisitos performance e modificabilidade foram mais trabalhados.

A tabela 4 pretende evidenciar as características e necessidades das SM’s e como

estas estão relacionadas aos requisitos não funcionais. A mesma tabela contribui para a

compreensão de como os requisitos podem ser satisfeitos pela arquitetura. Aqui se deve

entender que os requisitos não funcionais visam agregar benefícios e recursos que são

exigidos pelas características da Máquina Social. Outra compreensão correta, é a de que as

soluções propostas para atender os requisitos na arquitetura não são únicas, existem outras

que podem ser trabalhadas conforme a característica da requisição. O mais importante é

projetar a arquitetura de referência para que ela seja capaz de atender todos os requisitos e

características/necessidades exibidas na tabela abaixo.

Requisitos Características e Necessidades

das SM’s

Solução de Atendimento

Performance Reatividade, Infraestrutura,

Autonomia, expansão e

Serviços

1ª Controle sobre a geração

de eventos;

2ª Diminuir os elementos

intermediários de

comunicação;

3ª Trabalhar bem com a

infraestrutura e com a

conectividade.

Disponibilidade Constância, Sociabilidade,

Reatividade, Infraestrutura,

Serviços, Colaboração e

Comunicação facilitada

1ª Redundância: caso um

elemento fique indisponível,

a redundância (outro

elemento igual) deve ocupar

o seu lugar.

2ª Mecanismos que

verifiquem e alertem sobre

67


possíveis falhas.

Modificabilidade Sociabilidade,

Manutenção facilitada, e

Autonomia

1ª Elementos arquiteturais33

que facilitem a manutenção

da SM.

2ª Separar responsabilidades

em camadas;

3ª Manter a coerência

semântica para facilitar a

identificação do elemento

arquitetural.

4ª Isolar funcionalidades que

possam ser facilmente

alteradas.

5ª Inserir elementos

intermediários que diminuam

a dependência.

Interoperabilidade Colaboração, Infraestrutura,

Sociabilidade e

Conectividade.

1ª Identificar e trabalhar com

as interfaces providas e

requeridas;

2ª Trabalhar com padrões de

interoperabilidade.

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

Após visualizar e entender ainda mais a questão dos requisitos não funcionais, é

importante dar foco as outras questões arquiteturais como o estilo arquitetural. O estilo

arquitetural a ser adotado é o estilo em Camadas, o mesmo que foi a grande tendência do

estudo mapeado, o que poderia ser esperado, pois tal estilo é extensamente utilizado para

desenvolver aplicações Web. À vista disso a arquitetura de referência para Máquinas Socias

está ilustrada na Figura 15. Seus pontos serão explicados em seguida, bem como demais

visões da mesma.

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


É importante colocar que a descrição arquitetural documentada nesta pesquisa está de

acordo com a norma IEEE 1471 (IEEE, 2000) que recomenda a especificação da arquitetura

ou os documentos arquiteturais:

Com os elementos arquiteturais identificados, organizados, e com suas

responsabilidades bem definidas;

Com os requisitos relevantes a nível arquitetural, atendidos pela arquitetura

definida;

Com a representação de diferentes visões arquiteturais.

A Figura 15 exposta abaixo retrata a arquitetura por uma visão de módulos, exibindo

as camadas e suas interações. O objetivo desta visão é expor a Máquina Social em unidades,

mostrando a dependência entre tais unidades. Por meio da visão é possível exibir mais

facilmente o tratamento a alguns requisitos, como: portabilidade, reuso e interoperabilidade;

além disto, é possível representar a arquitetura da Máquina Social em tempo de

desenvolvimento, ou seja, de módulos a serem realmente estruturados e alinhados

(KRUCHTEN, 1995).

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

69


A primeira camada é a Presentation. Esta é uma camada básica de interação com o

usuário. Esta camada pode ser implementada de diversas maneiras, ou seja, para algumas

SM’s ela pode ser apenas uma camada onde as SM’s requisitantes (clientes) estejão alojadas.

Este seria o caso de Máquina Sociais como o MapReduce e outras PaaS e IaaS. Essa camada

pode ser ainda a uma camada capaz de produzir qualquer interface de apresentação e exibição

de dados. Tal camada pode ainda, porventura, nem existir na SM, mas sim, ser concebida por

outra Máquina Social, como no caso dos sites Mashups. Deste modo, a Presentation não será

especificada neste trabalho, sua criação dependerá fortemente do tipo de SM a ser construída.

Entre a primeira camada, seja ela de qualquer natureza, e a segunda camada, existem

os balanceadores de carga que vão distribuir as solicitações de acesso (requests), estes

atendem ao requisito desempenho. Os balanceadores são apenas um exemplo, pois o que se

propõem na verdade são mecanismos que façam o tratamento em blocos das solicitações. Isto

melhorará o desempenho consideravelmente se comparado ao tratamento e processamento

individual das requisições.

A camada Wrapper é sem dúvida uma das mais relevantes para a Máquina Social, ela

é uma camada dedicada à comunicação e interoperabilidade. Além de viabilizar a conexão

entre as SM’s, esta camada é a implementação do elemento Wrapper citado no capítulo 2. É

inteligente pensar que ela poderia ser concebida como a API da Máquina Social, sendo que

uma API é um conjunto de requests e responses (KALIN, 2010). Assim, os métodos válidos

para criar uma API poderiam ser utilizados.

Com a API na camada Wrapper é possível expor os serviços da aplicação de modo

que outras aplicações usufruam destes serviços, ou funcionalidades, sem se preocupar com

alguma implementação adicional. Nesta parte da arquitetura o surgimento dos formatos XML

ou JSON é fato, bem como, a implantação de Web Services para apresentar os serviços

disponíveis. As linguagens XML e JSON facilitam o cumprimento do requisito de

interoperabilidade. Trata-se, na verdade, de linguagens de grande flexibilidade e poder

semântico (TITTEL, 2003) com troca de informações independente de plataforma ou

tecnologia.

A camada seguinte é a camada Processing Unit, uma camada voltada ao negócio e

responsável por bastante processamento; é nela que devem existir mecanismos para verificar e

divulgar informações da SM, como o status do funcionamento da mesma. Este mecanismo é a

70


implementação do elemento State. A camada Processing Unit é também um elemento da SM

que além de monitorar, deve ainda satisfazer as funcionalidades da mesma. Tal camada deve

ter componentes que atendam as funcionalidades e satisfação dos requisitos funcionais da

Máquina Social (Controllers e Services). A Processing Unit é, em conjunto à camada

Wrapper, a mais importante para a SM, e também pode ser a mais complexa de se conceber.

A Processing Unit implementa o elemento Constraints. Nele será possível obter as

limitações, a carga de trabalho e o tempo de resposta aceitável de uma Máquina Social. Outra

característica importante da camada Processing Unit é a comunicação perfeita com a camada

anterior a ela, a camada Wrapper, haja vista todos os produtos gerados pelo componente State

devem ser refletidos também na camada Wrapper para que a mesma saiba o “status” de cada

serviço.

No trecho acima a camada de negócio foi elucidada. É importante citar que esta

camada pode dar suporte a todos os requisitos de qualidade da SM, principalmente o requisito

de modificabilidade, sendo que, a alteração das Constraints não compromete outros

componentes da Máquina Social. O produto desta camada é insumo para o funcionamento da

camada de repositório de dados. A próxima apresentação é justamente sobre a camada de

infraestrutura e acesso a dados.

A camada Persistence/Infrastruture é a camada de suporte da Máquina Social. Ela é

responsável por serviços de hospedagem para o desenvolvimento da aplicação; serviços de

capacidade computacional, ofertando recursos necessários ao desenvolvimento; e serviços de

armazenamento de dados. Nesta camada é possível verificar, analisar e direcionar as

demandas de acesso aos dados. Por tratar as solicitações de registro e consulta, tal camada

pode monitorar o tempo e a adequabilidade das respostas, trabalhando iniciativas de correção

caso algo esteja fora do padrão aceitável pelas Constraints.

Os bancos de dados e a infraestruutra computacional são uma parte ligada à

arquitetura, e não necessariamente contida nesta. Deve-se ter esse entendimento uma vez que,

a camada de banco de dados não necessita ser implementada pela equipe desenvolvedora da

Máquina Social. Assim, entende-se que tal camada pode ser disponibilizada por meio de um

serviço Cloud Computing, o que facilitaria a réplica destas camadas auxiliando na satisfação

do requisito disponibilidade. Para atingir esse requisito é necessário que os componentes

71


estejam sincronizados. O artifício de possuir réplicas pode, inclusive, ser utilizado para outras

camadas arquiteturais.

A decisão por obter um serviço Cloud Computing é algo muito particular de cada

aplicação, devem-se analisar as necessidades da SM, os custos, a segurança, e os recursos de

replicação. Em um projeto de Máquina Social os serviços de Cloud Computing podem ser

muito úteis à equipe de desenvolvimento, sendo que, esta não teria preocupação com a

manutenção ou preparação de máquinas servidoras (ZHANG e ZHOU, 2009).

Para finalizar é importante esclarecer que esta arquitetura de referência deve ser

customizada levando em consideração a finalidade da Máquina Social e todos os seus

requisitos funcionais, e principalmente sua taxonomia. Como por exemplo: a camada

Wrapper pode se comportar também como uma camada de aplicação em casos onde uma

Máquina Social possa estar conectada com muitas outras SM’s que sejam clientes dela.

4.4. VISÕES DA ARQUITETURA DE REFERÊNCIA

Após descrever a arquitetura, a visão de implantação será ilustrada. Por meio dela,

será possível visualizar todas as Máquinas Sociais que compõem a arquitetura de referência e

como as mesmas distribuem o processamento da aplicação. Essas SM’s interagem umas com

as outras executando funções diferentes e assim se completando (GORTON, 2006). Por meio

desta visão, é possível avaliar ainda os requisitos não funcionais de desempenho e

disponibilidade (KRUTCHEN, 1995). Ela dividirá a arquitetura em nós processadores e

componentes executáveis, o que dará a visibilidade de que uma Máquina Social é composta

por outras Máquinas Sociais.

72


Figura 16. Visão de Implantação

Em um diagrama de implantação, geralmente é exibido a especificação de cada nó, ou

seja, qual o tipo de sistema operacional, a especificação da máquina, ou ainda o sistema de

banco de dados a ser implantado no nó. Todavia, não deve-se em uma arquitetura de

referência fixar especificação de tecnologias ou máquinas (MULLER, 2011). Deste modo,

fica ilustrado apenas a localização dos nós com as especificações: device e Database - DB.

Por meio do diagrama na figura 16, é possível notar a ditribuição física de cada

componente, ou como representado anteriormente, de cada camada da Máquina Social. A

distribuição em nós diferentes não é algo obrigatório, isto dependerá muito do tipo de

Máquina Social. Por exemplo: em SM’s mais simples que façam rotineiramente atividades de

consulta e inserção de dados, seria interessante ter um nó maior constituído pelas camadas

Presentation e Wrapper. Isto traria um aumento de desempenho da SM. Então, a alocação das

camadas aos nós computacionais para todos os tipos de Máquinas Sociais pode variar entre 1

nó ou 3 nós. Aproveitando o ensejo, é importante novamente frisar que o nó

Persistence/Infrastruture é satisfeito por uma Máquina Social com serviços Cloud

Computing.

Serão exibidas outras visões de partes da arquitetura. Estas partes correspondem às

duas camadas mais importantes para a SM, a camada Wrapper e Processing Unit.

73


Figura 17. Diagrama de Classe (Visão de módulos_Wrapper e Processing Unit)

O diagrama na figura 17 exibe as camadas Wrapper e Processing Unit como

subsistemas; dentro de cada existem as classes que a compõem. Nota-se que um terceiro

componente do Processing Unit (Controllers/Services) não está presente na visão. Sua

exclusão foi proposital, visto que o mesmo é um elemento que deve agregar muitas outras

classes funcionais da SM que irão contemplar as funcionalidades da Máquina Social e que

terão comportamentos e relações muito particulares e relativos aos requisitos funcionais.

Nesta visão, o entendimento deve ser de que o primeiro subsistema se relaciona com

o segundo por intermédio de uma classe abstrata que diminuirá o acoplamento entre as

classes. Essa redução é importante para possibilitar o atendimento ao requisito de

modificabilidade. Uma classe abstrata age como uma interface mais robusta, capaz de ofertar

independência (GAMMA et al, 2000) entre as classes no sentido que elas possam sofrer

alterações sem atingir fortemente as classes relacionadas a ela.

Para otimizar o acoplamento baixo, o padrão de projeto Facade deve ser

incorporado, pois o mesmo é especialista em unificar interface facilitando o acesso aos

subsistemas e independência entre as classes. A inserção de mecanismos contra o

acoplamento alto não prejudicará o relacionamento dos subsistemas, pois a classe

74


LearningStatus possui apenas a função de capturar os dados da classe States para assim

montar o estado dos serviços, com isto o acoplamento existirá, mais será fraco.

O segundo subsistema é composto, a priori, pelas classes Constraints e States. Nele, a

classe States depende da classe Constraints para alterar a situação dos serviços da Máquina

Social. Neste aspecto, existe um acoplamento de controle entre essas duas classes, sendo que

uma exerce controle sobre o comportamento da outra. Apesar de o acoplamento ser ruim à

qualidade de qualquer sistema, neste caso, e em muitos outros, ele se faz necessário

(LARMAN, 2007) pelos objetos necessitarem interagir com outros objetos e na troca de

mensagem; esse é o caso entre Constraints e States.

Para enteder melhor o diagrama de classe e a relação entre estes dois subsistemas,

será ilustrado, para a camada Wrapper, um diagrama de componentes com portas e interfaces.

Através desta visão, é possível verificar a colaboração entre os componentes ou classes,

(BOOCH, RUMBAUGN, JACOBSON, 2005) bem como os serviços que cada componente

pode prover ou requerer para a SM’s.

A Wrapper é a interface da SM que exibe todos os serviços providos e requeridos

pela mesma. Neste ponto, a Wrapper pode ser visualizada como um conjunto de rotinas que

pode evidenciar a utilização das funcionalidades da SM’s. Para possibilitar o trabalho da

Wrapper é necessário que a mesma esteja sempre ciente do estado dos serviços da SM, assim,

é necessário um componente que leia o estado da Máquina Social disponível pelo componente

State na camada de Processing Unit. A Figura 18 ilustra esta visão de componentes e

conectores.

Após obter os dados da Máquina Social e determinar a situação dos serviços, é

necessário disponibilizar essa situação para o componente responsável pela mediação entre a

Máquina Social e as demais aplicações interligadas. Esse componente pode ser um Web

Service ou ainda um Middleware flexível que facilite a integração e comunicação entre as

aplicações. O que interessa é possuir um elemento que seja na verdade um programa

computacional que faça o transporte das informações e dados entre as aplicações de forma

independente de protocolos e plataformas, e que satisfaça o requisito interoperabilidade.

O componente intermediário é representado na visão seguinte com o nome: Social

APIMiddleware Machine. É necessário ter cuidado na adoção desses elementos intermediários

que façam a comunicação entre os demais elementos arquiteturais, pois esses elementos

75


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

desempenho.

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

Tratando-se de visões arquiteturais, as mesmas podem detalhar algum elemento

específico da arquitetura (KRUCHTEN, 2010), deste modo a próxima visão para a arquitetura

de referência de Máquinas Sociais irá contemplar dois elementos importantíssimos para as

SM’s, os elementos States e Constraints. Como já exposto eles são responsáveis pelo

monitoramento e pelos requisitos não funcionais da Máquina Social, respectivamente; tais

elementos devem interagir de forma facilitada, pois que, informações geradas por um

interferem no funcionamento do outro.

Os elementos States e Constraints serão abordados por meio de uma visão que

exalta o tempo de execução da SM, por intermédio de um diagrama de sequência. Essa visão

é capaz de representar a arquitetura em tempo de execução. É uma visão que foca mais no

comportamento do componente arquitetural perante as interações e exibe bem os protocolos

de relacionamento e confiabilidade (GORTON 2006).

76


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

O diagrama de sequência na figura 19, a seguinte interpretação deve ser obtida. Um

requisitante exige um acesso, o elemento State deve enviar uma mensagem que avalie se o

acesso do requisitante é permitido, ou seja, se é possível ainda dar o tipo de acesso que é

requerido, o elemento Constraints avalia a permissão de acesso e retorna ao elemento anterior

que, por sua vez, permite o acesso ao tipo de transação que o requerente desejar. Por fim, o

requisitante, já com livre acesso, envia dados para algum tipo de transação e aguarda o seu

retorno, que deve se originado por algum componente que implementa as regras de negócios e

funcionalidades da Máquina Social.

A interpretação acima é baseada em um exemplo simples de funcionamento dos

elementos citados. O funcionamento ilustrado pelo diagrama de sequência pode ser

implementado de outra forma, o importante é manter a comunicação entre os elementos do

diagrama. A arquitetura de referência é apenas um modelo. É evidente que outros detalhes

sejam pertinentes a esta arquitetura. Entretanto, são detalhes mais específicos de cada

Máquina Social a ser desenvolvida. O importante é adotar as camadas e os componentes que

as compõem bem como o estilo arquitetural que é o Relaxed Layered System, como já

explicado, uma variação do estilo Camadas.

77


A adoção de tal arquitetura seria interessante para padronizar os projetos de

Máquinas Sociais. Deste modo, cabe nesta pesquisa, avaliar a arquitetura proposta para que a

adoção da mesma possa ser viabilizada com mais segurança.

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

VISÕES

A arquitetura de referência aqui proposta deve ser avaliada para verificar a

adequação e consistência da mesma aos requisitos não funcionais de uma Máquina Social. O

que deve ser avaliado são as representações arquiteturais, ou seja, as visões arquiteturais que

são oriundas da arquitetura de referência e a própria arquitetura. A partir dos dados extraídos

de tais avaliações, será possível identificar pontos de fraqueza na arquitetura de referência e

nas visões da mesma. Pontos de fraqueza são defeitos encontrados nessas representações

arquiteturais.

Para avaliar uma arquitetura, existem vários métodos, entre eles: Architecture

Tradeoff Analysis Method - ATAM e Software Architecture Analysis Method - SAAM, estes

são métodos que avaliam as arquiteturas por meio de cenários que devem representar o

comportamento esperado de um sistema perante um requisito de qualidade, estes métodos

basicamente avaliam se a arquitetura proposta contempla os requisitos não funcionais, ou de

qualidade, exigidos para o software (KAZMAN et al. 2000).

As abordagens citadas como exemplo de avaliação arquitetural possuem limitações

quanto ao emprego das mesmas na arquitetura proposta neste trabalho. As limitações são reais

devido a arquitetura proposta ser uma arquitetura de referência (NAKAGAWA, 2006). Como

já exposto, este tipo de arquitetura é muito genérica e representa todo um domínio de

software. Assim, avaliar atributos mais específicos para este caso é um tarefa inviável. Além

da limitação citada, existem outras que também poderiam afetar uma avaliação prática e

correta da arquitetura de referência pelos métodos citados acima, entre elas:

Avaliações por meio dos métodos ATAM e SAAM podem se tornar muito

subjetivas por dependerem fortemente do conhecimento dos avaliadores

(CORANDI et al. 2003);

ATAM e SAAM são avaliações que necessitam de um número maior de

pessoas envolvidas (CORANDI et al. 2003).78


ATAM e SAAM avaliam cenários específicos para a arquitetura, de modo

que seja necessário construir uma situação na qual a arquitetura será

submetida, neste cenário a arquitetura deve se manter estável possibilitando

o software a executar sua funcionalidade.

Levando em consideração as limitações abordadas, será aplicada neste estudo a

técnica de inspeção sobre os documentos ou visões arquiteturais. Técnicas de inspeção de

software são métodos rigorosos para se avaliar um artefato de software (BOEHM e BASILI.

2001). Para este trabalho, a técnica de inspeção a ser utilizada será o Checklist.

4.5.1. TÉCNICA DE INSPEÇÃO

O Checklist utilizado na avaliação da arquitetura proposta nesta pesquisa é baseado

nos trabalhos do programa de engenharia de software da Universidade Federal do Rio de

Janeiro no ano de 2002 e 2006 (TRAVASSOS et al. 2002), e nos trabalhos de Laitenberger e

DeBaund (1998). Tais trabalhos foram direcionados à confecção e customização de Checklists

de documentos arquiteturais que pudessem ser utilizado largamente, inclusive em arquiteturas

de referência. Segundo os autores citados, o sucesso de tal técnica de inspeção em

documentos arquiteturais se deve ao fato de:

A aplicação do Checklist não envolver atividades complexas e demoradas, nem

tão pouco a elaboração de cenários de qualidade. Deste modo, a avaliação é de

baixo custo e menos subjetiva por não depender de cenários.

O Checklist é formado por itens de questionamento que podem ser

personalizados conforme a arquitetura documentada, pois tais itens devem

avaliar a forma com que a arquitetura pode atender aos requisitos e não a

forma com que essa documentação foi feita ou a que tipo de arquitetura é

direcionada.

Os itens de questionamento devem avaliar principalmente discrepâncias em

relação aos requisitos funcionais e não funcionais. Com isto, várias

características podem ser avaliadas e não somente as referenciadas em

cenários.

79


É possível definir um processo de configuração dos itens de questionamento

para que os mesmos possam adaptar o Checklist às características do

documento arquitetural e ao objetivo da avaliação.

4.5.1.1. Perfil dos Avaliadores (inspetores)

Serão quatro avaliadores: um professor, arquitetos de software e estudantes de

mestrado em ciências da computação. Existirá ainda, para intermediar tal inspeção, o autor

dos documentos de visão arquitetural. É importante registrar que não existem estudos que

afirmem qual o número ideal de participantes em um processo de avaliação deste tipo

(KALINOWSKI, 2004) (TRAVASSOS, 2002).

4.5.1.2. Taxonomia dos Defeitos a Serem Encontrados

As abordagens avaliativas baseadas em Checklist visam identificar defeitos. Para este

trabalho, os defeitos devem ser identificados nos documentos arquiteturais. Os defeitos que se

pretende encontrar estão baseados nas definições e estudos de Shull (1998) e estão pontuados

como se segue:

Defeitos por omissão: ocorre quando um elemento arquitetural necessário

para o atendimento a um requisito não foi atendido ou mensurado.

Defeitos por ambigüidade: quando um elemento arquitetural dificulta o

atendimento a um requisito.

Defeitos por inconsistência: quando o mesmo elemento arquitetural é

representado com nomes diferentes em visões distintas. Ou quando o mesmo

elemento arquitetural tem responsabilidades distintas em uma ou mais visões.

Defeitos por fato incorreto: ocorre quando um elemento arquitetural não é

descrito de forma correta.

Defeitos por informação estranha: defeito acometido quando não se consegue

entender a atribuição ou responsabilidade do elemento arquitetural.

80


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

O processo de inspeção com o Checklist de avaliação arquitetural é prático e

constituído por duas grandes atividades:

Atividades de Planejamento e Configuração:

o Configurar o Checklist selecionando os itens de questionamento que

podem ser aplicados ao documento arquitetural a ser avaliado;

o Adaptar os itens de questionamentos que podem ser aplicados

somente quando os mesmos necessitarem de alguma alteração para

melhor adequação ao objeto avaliado;

o Identificar os avaliadores;

o Distribuir os documentos necessários à avaliação (documento

arquitetural e Checklist);

Atividades de Detecção (avaliação):

o Leitura de documentos de especificação para melhor entendimento da

arquitetura a ser avaliada e dos requisitos a serem contemplados pela

mesma;

o Inspetores revistam individualmente os artefatos do documento

arquitetural a procura de defeitos;

o Inspetores respondem aos itens de questionamento do Checklist.

4.5.1.4. Correção dos Erros Encontrados

Após a avaliação é necessário corrigir os pontos negativados no documento

arquitetural. A correção deve ser conduzida pelos itens que foram negativos no Checklist.

Após correção, uma nova avaliação deve ser efetuada no documento arquitetural; neste ponto

as atividades de planejamento e configuração do processo de avaliação podem ser

postergadas.

81


4.5.2. RESULTADOS

Os resultados que serão aqui pontuados foram extraídos dos itens de questionamento

respondidos na fase de detecção. Para o registro deste resultado é importante mapear algumas

questões daqui em diante.

O Checklist foi respondido por cinco pessoas ao final das rodadas avaliativas, sendo

que, na primeira rodada houveram três pessoas que respnderam o Checklist. Enquanto que em

uma segunda avaliação, o Checklist foi respondido por duas pessoas. Apenas uma pessoa

participou respondendo o Checklist em ambas as rodadas, ou seja, houve a repetição de

apenas um participante entre as avaliações.

Acredita-se que a não repetição de todos os participantes entre as rodadas acarretará

um resultado mais preciso, pois que, novos avaliadores serão inseridos e estarão

despreparados a qualquer julgamento e avaliação preliminares ou imaturos dos artefatos

arquiteturais. Em contrapartida, a repetição de apenas um participante pode ser útil para que

tal avaliador verifique a real evolução dos artefatos e consiga ser mais crítico e preciso em sua

avaliação.

Foi imprescindível executar duas rodadas de avaliação pelo de fato de buscar sempre

a melhoria contínua dos artefatos. Se houvesse mais tempo de pesquisa, e mais

disponibilidade de outros avaliadores, seria interessante executar uma terceira ou quarta

avaliação. Quanto a estas, os documentos arquiteturais estavam bem mais consistentes e

coesos na segunda avaliação, do mesmo modo que o próprio Checklist.

Para o Checklist foi verificado que alguns termos, ou mesmo, itens de

questionamento, deveriam ser melhorados ou retirados. Foi o caso do item 4 (quatro) que

avaliaria a dependêncica entre classes. Existiram dúvidas acerca deste item, de modo que, em

2 (dois) Checklists, de um total de 5 (cinco), ele não foi respondido, e em 1 (um) ele foi

taxado como: “não se aplica”. Portanto, o item 4 (quatro) foi descartado de qualquer

contabilidade dos itens de questionamento atendidos ou não atendidos. Seu descarte não foi

prejudicial, sendo que outro item também tinha a função de avaliar o mesmo critério

(dependência).

Ainda quanto aos itens, as palavras que atribuiam muita generalidade, como por

exemplo: “para todos” ou “todos”; foram subtraídas para a segunda rodada; verificou-se que

82


estas palavras estavam trazendo muitas respostas negativas na documentação. Sendo assim, se

tratanto de uma arquitetura de referência, não há necessidade de explorar todas as visões ou

todos os diagramas e classes que são potenciais às SM’s. As duas versões de Checklists

utilizadas estão nos apêndices (apêndice A e apêndice B).

Os itens de questionamento objetivaram avaliar alguns critérios de suma importância

para qualquer arquitetura bem como detectar a presença dos defeitos seguindo a taxonomia

proposta. Alguns itens avaliaram isto de forma mais direta. A tabela 5 ilustra o que cada item

do Checklist pretendia investigar e qual a resposta esperada.

ITENS DE QUESTIONAMENTO RESPOSTA

ESPERADA

QUESTÕES AVALIADAS

1 - Ao analisar todos os diagramas,

foi identificado algum elemento

arquitetural que não possua

relacionamentos, ficando isolado dos

demais?

Não Avaliar os relacionamentos e coerência entre os

componentes da arquitetura de forma que nenhum

componente desponte repentinamente.

2 - A descrição textual que

compõem o documento está de

acordo com o que foi representado

nos diferentes diagramas gráficos?

Sim Coerência entre a representação textual e gráfica, e

principalmente os defeitos por incosistência.

3 - Para os componentes, em algum

diagrama, foram identificadas as

classes ou sub-componentes que o

compõem?

Sim Defeitos por omissão.

4 - Os relacionamentos realizados

entre classes/sub-componentes

alocados em “componentes pais”

distintos foi definido como uma

dependência entre esses

“componentes pais” em algum

outro diagrama?

Indiferente RETIRADO DO CHECKLIST. Pretendia avaliar a

depedência e o acoplamento.

5 - As interfaces são

disponibilizadas por um único

componente/classe, ou

representadas de uma forma mais

Sim Representação das interfaces e comunicação entre os

componentes.

83


simples não expandida? Ou seja,

ocorre uma representação por

meio de diagrama de classes ou de

componentes e conectores com

interfaces requeridas e providas.

6 - Ao analisar as seqüências de

execução descritas em uma visão

de interação, pode-se dizer que as

classes/componentes definidas em

uma visão modular foram alocadas

em ao menos uma das seqüências?

Sim Analisar a coerência entre as visões. Verificar se os

componentes arquiteturais possuíam os mesmos

nomes entre as visões.

7 - Os elementos arquiteturais têm

a sua presença na arquitetura

justificada por um conjunto de

requisitos não funcionais ou

funcionais?

Sim Analisar o atendimento aos requisitos funcionais e

não funcionais, e se os mesmos foram trabalhados e

justificados na arquitetura.

8 - As responsabilidades dos

elementos arquiteturais estão

condizentes com os requisitos não

funcionais que eles atendem?

Sim Analisar se a arquitetura atende de forma adequada

(propõem soluções adequadas) os requisitos não

funcionais.

9 - Táticas arquiteturais foram

empregadas para satisfazer os

requisitos não funcionais?

Sim Verificar se existem soluções propostas pela

arquitetura para o atendimento aos requisitos, e se as

soluções estão corretas e claras.

10 - Elementos relacionados

possuem responsabilidades iguais

que possam ser alocadas em um

único elemento?

Não Analisar a coesão da arquitetura. Coesão neste caso

deve ser entendido como o princípio fundamental da

orientação a objetos.

11 - Elementos intermediários

como: máquinas virtuais,

servidores de nomes, repositórios e

API’s; são utilizados como

mediadores de comunicação entre

os elementos arquiteturais.

Não Analisar se existem elementos que podem prejudicar

o requisito desempenho. Elementos que viabilizam a

comunicação entre os componentes arquiteturais

podem prejudicar o desempenho.

12 - Foi verificado algum

componente que exerça controle

Indiferente Analisar a existência de acoplamento ou dependências.

84


sobre o comportamento de outro

elemento?

Tabela 5. Questões analisadas pelo Checklist e respostas esperadas

Existem três itens de questionamento que visam avaliar a aderência da arquitetura

aos requisitos Isto ocorre pelo fato da maior responsabilidade da arquitetura ser o atendimento

aos requisitos, sobretudo os não funcionais. Desta forma os 3 (três) itens objetivam investigar

o tratamento aos requisitos por questões escritas de forma diferente, mas que possuem o fim

de captar não conformidades entre as soluções, inclusive na incompatibilidade entre tais

soluções, como por exemplo: a soluções para o requisito desempenho ser prejudicial a solução

do requisito disponibilidade.

Diante as respostas de cada item foi possível extrair o seguinte percentual das duas

avaliações (figura 20).

Respostas possitivas (de acordo com o esperado)

62%

Respostas negativas (em desacordo com o esperado)

32%

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

6%

Percentual das respostas

Figura 20. Resultado da Avaliação (1ª e 2ª rodada)

O Checklist foi composto de 12 itens, cada avaliador respondeu ao menos uma vez

um Checklist, e apenas um avaliador respondeu a dois Checklist em momentos diferentes.

Sendo assim, a quantidade de respostas derivadas dos itens e da quantidade de Checklists

oriundos de cada avaliador é 60 (sessenta). Entretanto, o item 4 (quatro) foi anulado; ademais,

o item 12 (doze) também é um item neutro. Ou seja, suas respostas podem ser descartadas

para a estatística, tendo em vista que, o acoplamento é algo presente em alguns sistemas

(FERREIRA, BIGONHA e BIGONHA, 2008) é inclusive recomendado que exista

acoplamento, desde que ele seja controlado (LARMAN, 2007). Com isto o percentual de 100

(cem) é referente as 50 (cinquenta) respostas que de fato foram calculadas para averiguar a

qualidade da arquitetura.

85


Os valores acima são a totalidade das duas rodadas avaliativas. Se este resultado for

mais detalhista, é possível obter valores separados das duas rodadas como exibido a seguir:

Tendo em vista que a quarta e a décima segunda questão não entram no quantitativo,

para a 1ª rodada avaliativa houve 30 (trinta) respostas válidas, onde nenhuma foi do tipo “não

se aplica”. Desta quantidade, 15 (quinze) respostas foram de acordo com o valor esperado, e

15 (quinze) em desacordo, o que ofertou uma percetual de 50% (cinquenta porcento) de

aprovação para a arquitetura. Foi o pior resultado. O que contribuiu fortemente para isto foi a

escrita dos itens de questionamento, pois eles obrigavam o avaliador a verificar, por exemplo,

se para todos os componentes foram especificadas as classes.

Retirando a quarta e a décima segunda questão, para a 2ª rodada avaliativa houve 20

(vinte) questões respondidas, 3 (três) destas avaliadas como “não se aplica”; apenas uma

questão foi respondida como em desacordo com o valor esperado. Estes quantitativos

implicam em um percetual de 80 (oitenta) em aprovação e corretitude da arquitetura. Este é o

percentual válido para este trabalho. Esses valores pontuados em cada Checklist podem ser

verificados no repositório público:

https://www.dropbox.com/sh/sc6bv62petuczdm/ocjs_kklFH.

As visões ou diagramas arquiteturais expostos ao decorrer do capítulo foram os

avaliados corretamente, ou seja, alguns foram inseridos enquanto outros foram corrigidos,

tudo conforme a avaliação negativa dos questionamentos. Neste entrecho, após apuração dos

itens respondidos e contabilizados para os cálculos, obtiveram-se os seguintes resultados e

melhorias conforme os defeitos encontrados por tipo.

Defeito por Fato Incorreto:

Esses defeitos são referentes aos elementos arquiteturais que foram descritos ou

mesmo desenhados de forma errada. Algumas camadas ou classes não foram corretamente

especificadas. Um exemplo deste erro foi encontrado na visão que dividia a arquitetura em

camadas.

Nesta representação só havia duas camadas formando a arquitetura. Demais camadas

estavam na parte interna das duas grandes camadas, deste modo, poderia se supor que as

demais camadas, ou ainda, uma classe necessária, só poderiam ser inserida nas duas camadas

representadas. O grande problema dentro desta abordagem é o fato de não se dividir

86


devidamente as responsabilidades; sendo assim, a representação em camadas foi refeita, com

as atribuições de cada um devidamente inseridas. O resultado pode ser visto na Figura 15.

Para encontrar este defeito nenhum item de questionamento foi decisivo.

A escolha por não especificar a camada de interação com o usuário surgiu através do

apontamento deste tipo de defeito também, pois na avaliação, foi citado por um dos

avaliadores, a necessidad de uma reflexão sobre a real necessidade de uma camada de

apresentação em toda SM, sendo que muitas dessas poderiam se utilizar outras SM’s como

apresentação.

Defeito por Omissão:

Durante a avaliação os itens que foram negativados tiveram como motivo a omissão

de outros elementos arquiteturais que não foram representados. Ou seja, as visões

arquiteturais ainda foram em um pequeno número. Sendo assim, os diagramas de componente

e de classe foram acrescentados e avaliados positivamente em uma segunda oportunidade. O

item de questionamento número 3 foi determinante para a averiguação deste defeito.

Ao final desta seção é importante reafirmar que todas as visões exibidas neste

capitulo foram corrigidas conforme as avaliações. Uma versão anterior da avaliação de

referência foi inserida no apêndice D, isto para se notar como a mesma era antes de ser

especificada como na figura 15. É importante também concluir que o Checklist também foi

avaliado na primeira rodada, como se esta fosse um projeto piloto para os itens de

questionamento.


Neste capítulo a arquitetura de referência para Máquinas Sociais foi proposta. Essa

arquitetura é um modelo que deve ser customizado para cada SM a ser modelada. Mesmo

assim, essa arquitetura deve ser expandida. Pontos que fazem referência à implantação das

SM’s e ao próprio ciclo de vida de uma SM devem ser melhor trabalhados. Como exemplos

de questões que podem ser mais bem estudadas na arquitetura de referência são: estratégias

que proporcionassem um maior tempo de “vida” ou utilização da SM.

87


O maior número de visões retratadas para a arquitetura de referência visa auxiliar no

entendimento de tal arquitetura, assim como, mostra o controle e as estratégias sobre os

princípios de acoplamento e coesão. Em se tratando destes princípios, a avaliação procurou

dar ênfase aos mesmos, entre outros.

A avaliação foi importante não só para corrigir os artefatos arquiteturais como

também para corrigir o próprio processo avaliativo. Itens foram refeitos e novas visões foram

inseridas neste processo. Os avaliadores ainda puderam interagir com o autor dos artefatos e

algumas solicitações foram colocadas, como: inserir uma área para comentários no próprio

Checklist, e uma área de ajuda, em que cada item poderia ser melhor explicado, isto ainda no

próprio Checklist. A avaliação foi um processo que não teve alto valor financeiro e foi

extremamente proveitosa, tanto no sentido de melhoria da arquitetura, quanto no sentido de

amadurecer e disseminar melhor as práticas que visam avaliar a qualidade de documentos

arquiteturais.

Durante a exibição da arquitetura os requisitos a serem atendidos foram bem

enfatizados, inclusive por meio de uma tabela. Isto facilitou a avaliação, pois alguns

participantes também necessitaram perceber o atendimento aos requisitos de forma mais

direta. Outro artifício que possibilitou uma avaliação positiva de mais de 50% (cinquenta

porcento) de aprovação e aceitação da arquitetura, foi a inserção dos poucos elementos

mediadores, na verdade existi apenas um elementos, o Social APIMiddleware Machine na

figura 17, este poderia ser um Middleware o que prejudicaria o requisito desempenho

(GAMMA, et al 2000).

O próximo capítulo também pretende, entre outros objetivos, fortalecer e facilitar o

uso da arquitetura proposta, pois que, ao passo que conduz boas decisões de projeto, se

descobre maneiras de alcançar ou implementar as soluções propostas neste arcabouço de

referência.

88

Capítulo

5

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

Neste capítulo será proposto um conjunto de boas práticas que nortearão a uma

definição ou especificação apropriada de arquitetura de Máquinas Sociais. Neste capítulo, as

práticas constituirão novos métodos para projetar, e singularmente, conceber SM’s.

90

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

5.1. INTRODUÇÃO

Foi elaborado um conjunto de boas práticas, esse conjunto deverá responder

algumas questões que são de elevada importância para a customização ou criação de

arquiteturas. Ele irá conceber um padrão para construção de SM’s. Esse padrão, aliado à

arquitetura de referência, constituirá o conteúdo necessário que facilitará a adequada

construção de arquiteturas de SM. Na verdade, essas práticas também devem ajudar na

personalização da arquitetura de referência. Os assuntos levantados nesta parte introdutória

serão tratados minuciosamente nas próximas seções.

5.2. PRÁTICAS NA METODOLOGIA PARA CONCEPÇÃO DE

ARQUITETURAS E EM TRABALHOS RELACIONADOS

O procedimento para se implementar a arquitetura de qualquer sistema já foi

amplamente difundido por estudiosos como Roger Pressman, Craig Larmam, Paul Clements,

David Garlan e Mary Shaw. Segundo essas literaturas a metodologia, com os passos ou

atividades, para se elaborar a arquitetura de um sistema são:

1. Elicitar requisitos funcionais e não funcionais;

2. Especificar e analisar requisitos não funcionais;

3. Fazer uma listagem de todas as decisões de projeto incluindo as justificativas que

influenciaram cada decisão34.

4. Estruturar a arquitetura por meio de alguma modelagem;

5. Documentar a arquitetura utilizando visões que podem ser: visão de módulo, visão

de componentes e conectores, visão de implantação (BASS, CLEMENTS, e

KAZMAN, 2003);

Executar os passos acima não assegura a definição de uma arquitetura de qualidade

para SM’s, ou seja, uma arquitetura que possibilite o correto funcionamento da aplicação,

satisfazendo os requisitos (HOFMEISTER, NORD, e SONI, 2000). Para os sistemas Web que

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

91


são Máquinas Sociais, é necessário ter conhecimento sobre outros fatores que influenciam na

definição da arquitetura e que não estão explícitos nos procedimentos pontuados acima.

Os fatores críticos que devem ser seriamente levados em consideração na definição

da arquitetura de SM’s serão demonstrados por meio de boas práticas. Essas são orientações

que farão o projetista ou arquiteto de software notar os fatores relevantes para as Máquinas

Sociais para assim implementar com mais exatidão a arquitetura. As práticas estão ligadas

diretamente ao desenvolvimento das SM’s: serviços relacionados à SM, padrões de projeto

dedicados as SM’s, relacionamentos, autogerenciamento, e tecnologias. O intuito é

possibilitar a construção de sistemas Web como Máquinas Sociais.

É importante frisar que as práticas propostas neste trabalho não visam substituir os

pontos citados acima, estes fazem parte de métodos já tradicionais e amplamente validadas

pela indústria e pela academia para elaborar arquiteturas. A intenção deste trabalho é agregar

valor à forma de conceber arquiteturas de modo que as atividades que compõem os

procedimentos de elaboração arquitetural possam ser mais objetivas para SM’s, ofertando

resultados mais eficientes ao projeto de arquitetura.

As práticas foram costruídas por meio de:

Experiência de mais de 5 anos da autora desta dissertação em análise, projeto e

arquitetura de software;

Leituras e investigações sobre tecnologias para a Web inclusive com a

participação do grupo de SM’s da UFPE/C.E.S.A.R;

Padrões IEEE.

A idéia de se originar boas práticas para o projeto arquitetual de Máquinas Sociais

pode ser comparada aos padrões IEEE Std 830-1998, que contém boas práticas sobre a

especificação de requisitos de software, e principalmente ao padrão IEEE Std 1471-2000 que

contém boas práticas para a descrição arquitetural.

A diferença primordial entre este capítulo em específico e os padrões sugeridos é que

as boas práticas aqui propostas são mais ricas em detalhes, pois, elas não só recomendam uma

ação, como também ilustram o problema a ser resolvido, a motivação pela qual a prática é

sugerida, e a forma ou o exemplo de como ela poderá ser adotada. Com esta comparação, é

92


possível notar uma iniciativa em se padronizar a construção de SM’s; sendo que, o objetivo de

um padrão IEEE também seria em padronizar procedimentos, computadores e dispositivos35.

5.3. PRÁTICAS RECOMENDADAS

Antes de conhecer as práticas de construção, e depois de visualizar a arquitetura de

referência, é necessário reforçar alguns pontos que fazem parte de qualquer processo de

desenvolvimento.

Para qualquer projeto de desenvolvimento de aplicações Web é importante centrar na

idéia de Máquinas Sociais. O projetista de software deve ser remetido aos conceitos inerentes

às SM’s como: a taxonomia, os tipos de relações, e a própria arquitetura. Uma das metas desta

pesquisa é reforçar a idéia de que a análise dos sistemas conectados em rede deve ser feita

sobre o paradigma de Máquinas Sociais.

Para que a análise de uma SM seja constituída, as atividades inerentes a um projeto

de software não devem ser ignoradas. Sendo assim, seria interessante: analisar o problema a

ser resolvido pela Máquina Social; analisar o escopo do sistema, suas fronteiras; as premissas

que ele estará submetido; e a especificação do produto de software. Com essas análises, é

possível verificar ainda que tipo de Máquina Social é a aplicação a ser desenvolvida. Isto faz

diferença no momento das definições do projeto arquitetural e dos requisitos de qualidade.

Quanto aos requisitos de qualidade, é necessário averiguar os mesmos, o que ajudará

nas decisões de projeto. Estas, por sua vez, irão influenciar diretamente na definição da

arquitetura. Requisitos como: desempenho, confiabilidade, disponibilidade, compatibilidade,

segurança, modificabilidade, usabilidade, e interoperabilidade podem ser trabalhados na

arquitetura; sendo que alguns, como já elucidado, são mais relevantes que outros para as

Máquinas Sociais.

Após tratar brevemente de alguns assuntos relevantes para as SM’s, as práticas serão

exibidas. Estas geram informações e artefatos úteis para a construção adequada da arquitetura

da SM’s. Algumas práticas vão propor soluções tecnológicas, como frameworks ou padrões de

projeto.

5.3.1. PRÁTICA 1: Modelar processos e sub-processos de negócio de serviço

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

93


A modelagem dos processos de negócio vai capturar o problema a ser resolvido e

mapear melhor os serviços providos e requeridos. Ademais, mostrará quais as necessidades e

atribuições da aplicação. A modelagem dos processos é um fluxo com a sequência das

atividades que são efetuadas para se atingir um objetivo, (LAZZERI, 2009) além de descrever

o comportamento de um modelo de negócio.

Problema:

O problema reside em não saber como os componentes da Máquina Social irão

interagir uns com os outros. É difícil mapear um serviço sem conhecer os elementos que o

compõem (OSTENWALDER, 2005), qual o fluxo de atividades envolvidas, quais os serviços

e subserviços relacionados ao negócio ou a uma funcionalidade em específico. Pensar em

serviços é pensar em modelagem de negócio (LAZZERI, 2009).

Motivação:

Esta prática constitui um fluxo que é o alicerce da modelagem do sistema, ou da

Máquina Social. Assim, é possível visualizar mais claramente a SM e agir decisivamente nas

escolhas tecnológicas e arquiteturais.

Ainda assim, a motivação para construir as Máquinas Sociais é a relevância em se

conhecer os elementos que irão subsidiar suas operações. Não só conhecer, mas verificar

como tais serviços estão entrelaçados. Assim, a aferição desses serviços ou operações é feita

por meio do mapeamento dos processos que existem em cada operação. Cabe aqui mais uma

referência direta, segundo José Carlos Lazzeri (2009):

O fluxo do processo dá ao modelador a representação visual de como o

modelo de negócio será executado, podendo ser a base para a validação das muitas

exigências requeridas, entre elas: suporte a governança, estrutura do software,

priorização estratégica, apuração dos custos e eficiência operacional.

Outra questão que impulsiona o exercício desta prática é a integração entre as

aplicações de modo que uma possa utilizar o serviço da outra. A análise e descrição do

negócio contribuirão diretamente para a comunicação e integração (ABINADER e LINS,

2006), pois existe hoje uma série de padrões, ferramentas e arquiteturas, que vão desde as

Arquiteturas Orientadas a Serviços até as Plataformas Corporativas de Serviços, que se

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

envolvem o mesmo.

94


Exemplo e Solução:

Para modelar processos, o uso de Business Process Modeling Notation - BPMN é

extremamente recomendado (OSTENWALDER, 2005). Os fluxos dos processos de negócio

que surgem da linguagem BPMN modelam perfeitamente o processo. Deste modo, a Figura

21 é um exemplo dessa prática. Vale ressaltar que os fluxos de processo devem ser

expandidos quando ocorre a necessidade de detalhar melhor uma atividade.

Figura 21. Exemplo de modelagem de um processo

A Figura 21 é a descrição de um processo simples de um sistema de compra e

reserva de passagem. Todos os serviços são descritos possibilitando uma compreensão de

como os mesmos estão entrelaçados, por exemplo, o serviço de fazer check-in depende do

serviço de compra de passagem, qualquer alteração nesta compra poderá alterar o check-in.

5.3.2. PRÁTICA 2: Reconhecer os serviços providos e requeridos para o

funcionamento da Máquina Social.

Um serviço é uma tarefa, trabalho, ou ainda operação que será produzida por um

componente de software a fim de edificar algo de interesse e necessidade de outro

componente requisitante (ERL, 2005). Os serviços podem ser identificados em diversificados

níveis de abstração, desde serviços ofertados por uma aplicação a outra, até serviços ofertados

por um objeto a outro. Trata-se de uma orientação voltada para o autoconhecimento. Quanto

mais se conhece a aplicação, mais se descobre o tipo de Máquina Social que ela é, e como

deve ser sua arquitetura.

95


Problema:

O problema identificado para SM’s que pode ser resolvido por esta prática a nível

arquitetural é em relação à identificação das operações efetuadas pela Máquina Social. Outro

problema a ser resolvido está relacionado à identificação dos provedores de serviço. Algumas

decisões arquiteturais são baseadas nas características dos serviços requeridos e, por

conseqüência, o que, ou quem, pode prover tal serviço. Muitas vezes as operações requeridas

são executadas por provedores distintos, provocando exigências em conexões (LAZZERI,

2009).

Motivação:

Neste caso, os serviços providos e requeridos auxiliarão na definição das interfaces

de comunicação que ocorre entre as aplicações e também entre as “partes” das aplicações. Ou

seja, entre os elementos que constituem uma aplicação. O benefício desta prática é descobrir

os serviços envolvidos com a Máquina Social, prever os serviços necessários, verificando o

ciclo de vida do serviço, e também prever possíveis reusos dos mesmos. Uma conseqüência

desta prática, que caracteriza outra motivação, seria a identificação da necessidade de Web

Services, ou mesmo adaptação da arquitetura para suportar a conexão com provedores de

serviços.


O seguinte exemplo pode auxiliar na execução da prática:

Aplicação: Aplicativo de rede social;

Serviço provido: agrupar pessoas com a mesma profissão;

Serviço requerido: mecanismo de autenticação de usuário da rede social;

Existem algumas estratégias para se descobrir um serviço, sobretudo os serviços

providos. Algumas das estratégias são:

1. Tipificação: estudar um componente de software e descobrir o serviço que o

mesmo pode prover separando-os por categorias (BELL, 2008);

2. Abordagem Bottom-Up: analisar o sistema de software verificando os produtos

derivados da operação desse sistema. Se os produtos estiverem contextualizados

ao negócio ao qual a aplicação está direcionada, então tais produtos podem ser

vistos como serviços (LAZZERI, 2009);

96


3. Abordagem Top-Down: parte da análise do problema que o software deve

resolver. Nesta abordagem, o domínio do software poderá ser estudado, bem

como a análise das regras de negócio para identificação dos serviços (LAZZERI,

2009);

Para finalizar esta prática e partir para a próxima, que também esta relacionada aos

serviços, vale expor que ambas foram baseadas em estudos direcionados a SOA. Alguns

estudos, como o de Michael Rosen em 2008 exploram práticas de design para arquiteturas

orientadas a serviço. Algumas destas práticas são, por exemplo: o estudo dos serviços; a

separação de responsabilidades entre componentes da arquitetura; as atribuições de cada

pessoa envolvida no projeto; e ainda a análise do ambiente organizacional e tecnológico no

qual a aplicação será envolvida. Estas práticas são próximas das práticas lançadas até este

ponto.

5.3.3. PRÁTICA 3: Conhecer os provedores e requisitantes dos serviço da aplicação

A análise dos serviços é conveniente pela descoberta das interfaces, e para identificar

os componentes de software que irão prover e requisitar serviço. Entender e projetar um

componente de software como requisitante ou provedor de serviço é evidenciar a

responsabilidade do componente e o que é preciso para se conectar a ele. Assim, outros

softwares podem utilizar esse componente tendo apenas a interface necessária para se

comunicar.

Problema:

O problema a ser resolvido por esta prática já foi levantado na prática 1: ele provoca

a ausência de informações que auxiliariam um projetista, ou arquiteto, a lançar mão de boas

decisões arquiteturais que envolvam os provedores de serviço.

Motivação:

Após mapear os serviços requeridos é mais fácil descobrir quais tecnologias podem

atender cada serviço. Este conhecimento é útil para definir na arquitetura soluções que

possibilitem uma comunicação hábil entre provedores e requisitantes, evitando assim,

97


incompatibilidade entre as tecnologias ou aplicações (JOSUTTIS, 2007). Esta orientação pode

ser extremamente útil para os Mashups que trabalham sobre a mescla de serviços de duas ou

mais aplicações. Para enriquecer o entendimento sobre esta prática, vale examinar o exemplo

abaixo.


O exemplo no parágrafo abaixo não é baseado em um caso real, mas ilustra as

informações que devem ser adquiridas.

O Twilio irá fornecer o serviço de telefonia Web necessário na aplicação a ser

construída. Após pesquisa entende-se que ele é uma aplicação que utiliza a infraestrutura da

nuvem (Cloud Computing), enquanto sua API usa como interface de comunicação o padrão

“RESTful”, além de aceitar os formatos XML ou CSV em suas mensagens.

A metodologia para se adquirir as informações nos moldes do exemplo acima é

simples:

1. Fazer uma listagem das operações necessárias;

2. Separar as operações/serviços, separar os serviços que podem ser atendidos pela

própria aplicação, e separar serviços que podem ser atendidos por entidades

externas, como outra SM;

3. Para os provedores internos à Máquina Social, verificar como esses provedores

devem ser componentizados, se algum será reutilizado, e como deverá ser a

interface de comunicação desses componentes (CHEESEMAN e DANIELS,

2001). Quais métodos a mesma deve ter para manter os serviços;

4. Para os provedores externos, analisar cada provedor usando métodos de pesquisa

em materias próprios dos provedores, como sites, tutoriais, estudos de caso, guias

e outros.

Esta prática faz referência a componentização de software, outro importante

conceito para o desenvolvimento de aplicações Web. Entretanto, a prática ainda está co-

relacionada aos conceitos de SOA, bem como a prática 2.

Até agora os conhecimentos lançados exploram questão mais voltadas à análise e

modelagem de negócio, mas que, influenciam na arquitetura. A partir da próxima prática

98


recomendada os conhecimentos serão mais voltados para as questões técnicas das Máquinas

Sociais.

5.3.4. PRÁTICA 4: Verificar a necessidade de recursos que tornem a aplicação auto gerenciável e como esses recursos podem ser implementados.

Este conhecimento está intensamente relacionado aos conceitos de computação

autônoma. Neste momento é importante apontar para a necessidade das funcionalidades

autônomas, pois elas sugerem os mecanismos de auto gerenciamento de uma SM.

Problema:

O problema reside em não saber que determinado componente da Máquina Social

tem a necessidade de se auto gerenciar. Ainda existe outro problema agregado, onde alguns

recursos que promovem a autonomia dos sistemas ainda são parcialmente desconhecidos,

como exemplo: as IaaS’s. Tais aspectos relacionados à autonomia das Máquinas Sociais

fazem total diferença na arquitetura da mesma.

Motivação:

Com este conhecimento, é possível descobrir o recurso que poderá ser utilizado para

prover a autonomia dos elementos, quais são esses elementos da SM, e se necessitam

realmente de autonomia. Tal nível está relacionado às propriedades de auto cura,

configuração, otimização, e por fim, auto proteção. Assim, através desta prática, pode-se

descobrir, por exemplo, que um sistema tem alguns requisitos que, ao serem implementados,

gerarão funcionalidades independentes. Ou seja, funcionalidades que necessitem se

reconfigurar, otimizar seu desempenho em conformidade ao ambiente externo, ou ainda se

proteger deste ambiente.


Para descobrir aspectos funcionais que devem ser autônomos na Máquina Social

deve-se observar:

99


O ambiente no qual a SM está inserida, se é fortemente distribuído, se é

heterogêneo, ou seja, composto por SM’s distintas (STERRITT; e BUSTARD,

2003);

A carga de trabalho da SM, se a mesma é variável;

Se os recursos da Máquina Social são compartilhados.

O auto gerenciamento de um sistema é garantido pela comunicação entre os

elementos desse sistema. Para isto, o uso de interfaces variadas é a solução. Tais interfaces

podem agir por meio de APIs, arquivos de configuração, controle de logs,

utilização de frameworks e outros (HORN, 2001).

O framework MapReduce é uma ferramenta que age bem neste aspecto de

autonomia. Para monitorar a carga de trabalho, processando sempre grandes volumes de

dados, o framework deve lidar com falhas de forma habilidosa, garantindo assim a auto cura.

O MapReduce segundo Jeffrey Ghemawat, 2004; atende a auto cura da seguinte forma.

A arquitetura em camadas do MapReduce possui um componente que envia tarefas

às máquinas executantes das operações de mapeamento de dados e redução dos mesmos.

Deve-se lembrar que o framework trabalha de forma distribuída em várias máquinas, ou

clusters. Pois bem, uma vez que um componente envie tarefas, o mesmo envia “ping’s” para

cada máquina. Se uma delas não responder em um período pré-determinado de tempo, o

componente entenderá que ocorreu uma falha e imediatamente reiniciará a tarefa enviando-a

para outra máquina. Por fim, a tarefa necessitará ser re-executada para que o processo não

fique comprometido ou apresente resultados de reduções incompletos.

O parágrafo acima mostra como o MapReduce trabalha em um mecanismo que

satisfaz uma propriedade autônoma. Para esta prática é muto importante sinalizar à equipe de

software de que algum mecanismo do tipo deve ser planejado. O exemplo fictício do

parágrafo seguinte exibe o resultado da execução desta prática:

Exemplo: Baseado em dados mapeados nas experiências anteriores e no perfil do

público alvo da aplicação, estima-se que os registros e acessos de usuários tendem a crescer

42% a cada 30 dias. Assim, dentro de meses, o recurso consumido pelas máquinas será

grande. Para este problema, seria interessante ter um recurso que monitorasse a quantidade de

recursos existentes nas máquinas, como: memória e capacidade de armazenamento.

Cabe inscrever neste registro o uso de balanceadores de carga para distribuir a carga

de dados ao passo que se nota o crescimento da mesma. O uso de balanceador é muito comum

100


aos sistemas distribuídos em rede, afinal, o balanceamento de carga promove a escalabilidade,

performance, e disponibilidade.

Para se utilizar o recurso de balanceamento de carfa é necessário, acima de tudo

saber o que se deseja balancear (BOURKE, 2001). Após ter tais conhecimentos, é viável

preferir por alguma solução. É bem mais prático adotar uma tecnologia de mercado do que

construir o próprio balanceador, principalmente no contexto de Máquina Social que prega a

praticidade na manutenção e evolução do software (BOURKE, 2001). O Netcraft.com36,

inclusive, publicou uma estimativa que aponta o Apache como o serviço de balanceamento de

carga mais explorado, onde mais de 50% das aplicações Web o utilizam; em segundo lugar

ficou colocada uma ferramenta da Microsoft.

Finalmente outra opção para esta prática seria contratar um serviço de infraestrutura

Cloud Computing. O conceito de CC já foi tantas vezes tratado neste trabalho. Pois bem, o

uso de IaaS pode ser útil para o monitoramento do crescimento da aplicação onde a

infraestrutura pode prover a elasticidade do sistema sem intervenção de pessoas que tratem da

manutenção da aplicação.

5.3.5. PRÁTICA 5: Determinar os recursos que implementarão os elementos Communications , Constraints e Requests:

Os elementos chamados States e Constraints são partes da Máquina Social. Eles

concentram informações capazes de tornar viável a sociabilidade e a colaboração entre as

SM’s. Sem eles, é complicado saber a disponibilidade de uma SM, ou mesmo a

disponibilidade dos seus recursos. Estes dois elementos comportam e fornecem informações

tanto para auxiliar o processamento interno da SM, como para auxiliar na interação com o

ambiente externo.

Problema:

Determinar quais recursos tecnológicos podem implementar um componente que

dará suporte ao armazenamento e divulgação da situação da SM: se a mesma está bloqueada,

inativa, com muitas requisições e etc. Faz-se necessário ainda implementar um recurso que

distribua informações de como a Máquina Social trabalha, o que ela requer para se comunicar

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

101

http://news.netcraft.com/


com outras SM’s, qual a sua capacidade de processamento, armazenamento, os serviços aos

quais elas se dedicam e outras informações relevantes.

Existe uma complexidade em implementar recursos que atendam às necessidades

expostas nos parágrafos acima. Para solucionar o problema de detectar o estado das SM’s, por

exemplo, poderia ser utilizado o recurso de scripts de monitoramento. Esses scripts podem ser

usados para identificar uma ampla variedade de problemas em tempos de resposta, em tempos

de processos e ações, e até mesmo no trabalho de API’s.

Contudo, os scripts de monitoramento devem ser executados por meio de uma boa

infraestrutura onde máquinas estejam preparadas para monitorar. Além disto, nem todos os

scripts estão aptos para lidar com as particularidades de Web Services e linguagens de

programação. Na linguagem PHP, por exemplo, todos os scripts que possuírem o comando

“exec” poderão ser bloqueados pela maioria dos servidores. Atualmente existem também

alguns serviços Cloud Computig que fazem o monitoramento do estado de sistemas e de

redes, como o serviço: CA APM Cloud Monitor.

Ainda que existam alternativas, nenhuma delas é uma solução que atenda a

necessidade dos elementos States e Constraints e igualmente possa ser reutilizada na

diversidade das aplicações Web 3.0. Sendo assim, outras vicissitudes devem ser buscadas.

Motivação:

Priorizar uma solução única que possa atender aos requisitos dos elementos States e

Constraints, contribuindo assim, para o fortalecimento destes dois elementos na SM, de modo

que toda aplicação Web possa ter implementado esses componentes. O intuito é disponibilizar

de forma prática na rede as informações importantes para a conectividade e a troca de serviços

entre as SM’s.


Uma das soluções mais interessantes para essa questão seria o desenvolvimento de

um framework que possa atender os States e Constraints de forma diferenciada, pois o

framework ofertaria praticidade na comunicação e na obtenção de conhecimentos sobre a

própria SM e sobre outras SM’s. Assim a execução das operações por cada componente seria

maximizada.

O framework se preocuparia em ter as informações da SM, sendo que uma boa

comunicação necessita de informações, sobretudo, informações do status da Máquina Social.

102


O framework é composto por 3 (três) classes como exibido a seguir. Veremos a definição de

cada classe e posteriormente o relacionamento entre elas:

Class SM’s Configuration: trata-se da classe onde as informações e

características da Máquina Social são armazenadas. São informações como: a

quantidade de requisições que a SM pode suportar e o tempo de resposta entre

estas requisições. Qualquer alteração na SM é refletida nesta classe, evitando

assim, que códigos e métodos sejam alterados em diferentes pontos da Máquina

Social.

Class Relationships Manager: faz a gestão dos relacionamentos entre as SM’s. É

um elemento importantíssimo para o framework justamente por executar o

monitoramento das conexões entre as Máquinas Sociais. Neste elemento, é

possível definir o tempo de conexão, o tipo de conexão, quais SM’s, ou elementos

em uma SM, irão se conectar, e como irão se conectar. Conexão neste sentido são

de fato as Connections, ou seja, as relações fortes da SM. Por fim, pode existir

uma instância desta classe para cada SM conectada.

Class SM’s Interface: é uma classe de interface que se responsabiliza por

construir Request apenas lendo parâmetros, proporcionando uma criação mais

objetiva sem envolvimento de diversos códigos fontes ou outras tecnologias.

Essas classes estão inter-relacionadas, sendo que o produto de uma classe pode ser o

artefato de entrada para outra classe. Deste modo, a SM’s Configuration pode configurar uma

política de acesso à Máquina Social, deixando evidente, por exemplo, as portas que podem

receber solicitações e o tempo em que essas solicitações poderão ser atendidas. Isso servirá de

insumo para que a classe Manager Relationships avalie se o tempo de resposta de uma

solicitação está em um nível bom; os valores bons, ruins, ou ótimos, para esses níveis seriam

definidos nesta classe.

Outra relação de fundamental importância entre as classes citadas no parágrafo

anterior é a disponibilidade de informações. Baseado no último exemplo, a Manager

Relationships verifica que o tempo de resposta está prejudicado, mas não consegue descobrir

o motivo, pois esta justificativa é uma informação registrada como não pública na SM’s

Configuration. Sendo assim, a Manager Relationships apenas enviaria uma mensagem ao

método da arquitetura que seria responsável por sanar essa queda de performance do tempo de

resposta, sem necessariamente ter a garantia de que o método resolveria o problema.

103


Enquanto várias interações ocorrem, uma delas é fundamental: a Class SM’s

Interface que utiliza as informações da SM’s Configuration para montar corretamente as

Requests e assim poder receber dentro dos parâmetros registrados as solicitações de outras

SM’s. Por fim, a Class Manager age diretamente sobre essa interface conforme os resultados

obtidos no controle das conexões. Vale ressaltar que todos os atributos dessas classes são

repassados no formato “chave ⁄ valor”, o que agrega mais simplicidade na configuração do

framework.

Finalmente é possível notar que muitas das informações relevantes à SM são

trabalhadas em um só lugar por meio do framework; esse poderia ser uns dos elementos

principais de suporte à camada central de processamento da Máquina Social. Fica como

sugestão para as arquiteturas que resolverem adotar esse framework, que um importante

incremento para o mesmo seria implementar uma classe que tenha a inteligência de sugerir

ações corretivas para as não conformidades encontradas. Isto saciaria a necessidade de incluir

uma propriedade autônoma relacionada a auto cura.

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

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

A adoção de um estilo arquitetural depende do contexto no qual a aplicação está

inserida, e sobretudo, depende dos seus requisitos de qualidade. Todo estilo arquitetural

possui vantagens e consequências em sua adoção. O estilo camadas é fortemente utilizado em

sistemas Web e estava fortemente presente no mapeamento do estudo da literatura.

104


Problema:

O estilo camadas se mostrar frágil quanto ao provimento da comunicação. Esta é

realmente importante para as SM’s. Outras fragilidades desse estilo já foram elencadas

anteriormente, como a tolerância a falhas e a queda de desempenho; tais fragilidades podem

comprometer a qualidade da arquitetura da Máquina Social.

Motivação:

É possível repensar no estilo camadas para as SM’s, onde todas as fragilidades de tal

estilo poderiam ser amenizadas. Isto é válido, visto que o estilo se mostra eficiente para a

implementação de aplicações Web.


Nada impede que outros estilos sejam mesclados ao estilo camada (HOFMEISTER,

2000); mesmo porque, tecnologias emergentes podem ser incorporadas ao estilo para reduzir a

intensidade das conseqüências. A inserção do framework citado na última prática em conjunto

ao MapReduce poderia ser uma idéia proveitosa, sendo que, enquanto o primeiro traria

rapidez ao processo de comunicação, tanto na montagem dos Requests, quando na obtenção

facilitada do estado das SM’s; o segundo auxiliaria na tolerância a falhas.

Outra alternativa seria implementar uma réplica de segurança para cada camada.

Deste modo, quando uma camada falhasse, sua camada réplica estaria pronta para prover os

serviços; nas camadas de acesso a dados já é possível usufruir do artifício da replicação de

dados. Nessa alternativa, caso a SM use um recurso CC, como uma IaaS ou mesmo PaaS, é

possível negociar mais máquinas virtuais ao mesmo fornecedor de servidos de IaaS, ou em

outro fornecedor; além de programar o sistema de infraestrutura de modo que todo o conteúdo

seja replicado no novo ambiente negociado.

As alternativas para se adequar ainda mais o estilo camadas as SM’s são numerosas,

todavia, deve-se analisar novamente os serviços providos pela aplicação, o escopo da mesma,

qual será sua dimensão, e o ambiente no qual ela estará. A execução das 3 (três) primeiras

práticas vai auxiliar fortemente a prática aqui tratada. Já o exemplo a seguir pode auxiliar no

entendimento.

Exemplo: o servidor precisará notificar todos os clientes ativos diariamente. Assim,

seria interessante utilizar o estilo arquitetural Publisher-subscribers na camada de

comunicação, pois ele viabilizaria o registro apenas dos clientes ativos (BUSCHMANN. et al,

1996) notificando os mesmos a cada alteração sem esforço da aplicação servidora.

105


5.3.7. PRÁTICA 7: Determinar o recurso que proverá a comunicação e a interoperabilidade.

A comunicação é uma característica que sobressai na Máquina Social, e a

interoperabilidade é um requisito importantíssimo a ser considerado na arquitetura da mesma.

Portanto, dependendo do tipo de relação existente entre as aplicações, pode ser adotado um

padrão de comunicação entre elas, ou pode haver um consenso quanto aos tipos de mensagens

trocadas e o tempo em que elas serão trocadas.

Quando se trabalha com comunicação entre Máquinas Sociais trabalha-se mais do

que tudo nas integrações requeridas entre esses SM’s; o detalhe neste caso é que tais SM’s

podem apenas manter uma comunicação interna entre os componentes que a compõem, ou

entre as SM’s ditribuídas. Ainda deve-se considerar que a integração ocorrerá também entre

SM’s heterogêneas envolvendo Máquinas Sociais de clientes, de fornecedores e demais

parceiros do negócio.

Problema:

Determinar como será feita a comunicação entre as Máquinas Sociais para que a

continuidade na conexão destas SM’s seja garantida é algo que pode ser provido por meio de

diversificadas soluções. Deste modo, o problema se origina novamente da heterogeneidade de

recursos que são utilizados e que por vezes não agregam um bom resultado à SM,

adicionando complexidade ao seu desenvolvimento. Contudo, prover a comunicação é um

problema gerado principalmente pela falta de análise nas ferramentas e recursos que podem

prover a integração e interoperabilidade das SM’s. Neste aspecto, o conteúdo trocado entre

elas é de total relevância, assim como, o ambiente no qual a Máquina Social está envolta.

Motivação:

A motivação desta prática está em utilizar algum recurso já explorado por outras

SM’s como REST e SOAP. Ou ainda, analisar algum padrão utilizado pelo paradigma Cloud

Computing ou SOA capaz de prover a comunicação por meio de troca de mensagens bem

sucedidas. Contudo, ainda existe a possibilidade de explorar novas idéias que ofertem mais

praticidade na integração entre as SM’s. A integração pode reduzir significativamente os

custos e melhorar a eficiência dos processos organizacionais ao passo que aumenta a

“longevidade” das aplicações (ABINADER e LINS, 2006).

106


Segundo Rezende (2005) (2006); alguns fatores impulsionam a comunicação,

integração e interoperabilidade flexível entre os sistemas. São eles: a expectativa de se obter

retorno financeiro mais rápido; o aumento da demanda no compartilhamento de dados em

tempo real; a necessidade contínua de conter custos; e a necessidade de entregar sistemas de

qualidade que agreguem valor ao negócio.


Baseado no que foi visto até este ponto, as soluções mais próximas da realidade das

SM’s são exibidas em seguida.

1. Web Services:

Web sevices podem ser geridos por frameworks como: Axis 1.0 e 2.0; Jax-WS, SAAJ;

e ainda tecnologias poderosas como REST e SOAP. Enquanto o framework Jax-WS oferta

praticidade com geração de código e automação na criação do Web Service por utilizar

recursos da ferramenta NetBeans, a arquitetura REST oferta interfaces de serviço preparadas

para integrar aplicações que manipulem grande quantidade de dados (WEBBER,

PARASTATIDIS e ROBINSON, 2010) e também aplicações móveis.

Vale ressaltar que o metadado WSDL descreve Web Services com muita proeza, sendo

que ele ainda descreve o serviço, especifica como acessar o Web Service e quais as operações

que o mesmo dispõem. O WSDL é uma ferramenta muito poderosa para a obtenção de

interoperabilidade.

Na indústria de desenvolvimento para a Web existem dois grupos de profissionais

que se dividem em utilizar REST ou em utilizar SOAP. Ambos sustentam argumentos fortes.

Por um lado, as características do REST dão mais praticidade ao desenvolvimento, por outro

lado a completude de recursos que o SOAP possui (KALIN, 2010). A questão por se definir

entre REST ou SOAP é algo que depende de muita prática em desenvolvimento de software,

justamente para que os profissionais possam optar pela tecnologia mais adequada. É

importante lembrar que toda e qualquer escolha possui forte dependência com as

características da Máquina Social, a taxonomia, as interações, e a natureza dos serviços.

Apesar dos benefícios de SOAP, REST seria a solução mais adequada para as SM’s.

O que aproxima REST das Máquinas Sociais é a facilidade com que esta solução pode auxiliar

na identificação dos serviços (WEBBER, PARASTATIDIS e ROBINSON, 2010) e,

107


sobretudo, na utilização das mesmas pelo paradigma Cloud Computing. Vale lembrar que a

identificação dos serviços facilita a execução das primeiras práticas propostas por esse

trabalho.

Em se tratando de CC, a Salesforce utiliza REST para prover a integração entre Web

Services que podem ser necessários para a Máquina Social a ser construída sobre a plataforma

Force.com, no caso dos componentes disponibilizados por tal plataforma não atenderem as

funcionalidades exigidas pelo escopo da Máquina Social. O conhecimento deste parágrafo e

do seguinte estão disponíveis no Guia do Programador da API de Serviços Web da

Force.com37. Com isto é possível ver que CC também adere ao uso de SOAP.

A Force.com ainda fornece suporte a utilização do protocolo de acesso SOAP. Ela

sugere que as aplicações Web que exijam um tempo de resposta curto, que manipulem poucos

dados, e que serão construídas sobre a arquitetura Multitenancy, façam uso de SOAP. Tal

protocolo também ganha notoriedade quando as aplicações são construídas sobre o paradigma

de Arquitetura Orientada a Serviços. Em SOA, solicitantes e provedores de serviços trocam

mensagens do tipo SOAP para encontrar e disponibilizar serviços respectivamente (GOMES,

2010).

2. Enterprise Service Bus - ESBs:

Outro recurso que ganhou força com SOA e que também provê integração e

comunicação são os ESBs (CRAGGS, 2004). O modelo ESB utiliza uma plataforma de

serviço na qual as aplicações recém-criadas e as aplicações legadas podem se conectar

facilmente utilizando XML. A grande vantagem do ESB é que o formato da mensagem já é

conhecido pelas duas aplicações (CRAGGS, 2004), o que proporciona maior velocidade nas

transações.

O ESB é um servidor de aplicação que trabalha com middlewares que podem

integrar os componentes das camadas de processamento da aplicação, além de garantir a

integração de diversas Máquinas Sociais distribuídas utilizando adaptadores e conectores

(LINTHICUM, 2004). Desta forma, o uso de um ESB na camada Wrapper da SM é uma

solução inteligente e ideal para as SM’s, sobretudo, pela padronização de mensagens, o que

facilita o reconhecimento das mesmas por diversas SM’s amenizando assim o problema de

integração.

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

108

http://www.salesforce.com/us/developer/docs/api/index.htm


3. Remote Method Invocation - RMI:

Aplicações que sejam desenvolvidas em Java, por exemplo, podem utilizar o padrão

de comunicação RMI, ou a ferramenta Jini, que, por meio de um conjunto de API’s, pode

conectar diversas aplicações distribuídas em rede (ARNOLD et al, 2009), inclusive

dispositivos móveis. O Jini faz a localização dos serviços sem necessitar consultar nenhum

repositório de serviço (ARNOLD et al, 2009), como SOAP faria. Apesar de ser uma boa

solução, a mesma traria muita dependência com a tecnologia Java, o que contradiz os

princípios da SM de ser independente.

Finalmente a comunicação entre as aplicações ou parte delas pode ser alcançada de

forma prática por meio das tecnologias aqui expostas. Conceitos que são relevantes como

análise do negócio e aviso de entrega de mensagens, estão implícitos nesta abordagem e

devem ser considerados para a adoção de alguma tecnologia.

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

A arquitetura de referência sugere que os recursos disponibilizados pelo paradigma

Cloud Computing sejam inseridos na arquitetura de Máquinas Sociais. Na verdade Cloud

Computing, sobretudo os SaaS, trabalham como SM’s, e estão inseridos no universo da Web

3.0. Por isso, e também pelas vantagens que os serviços Cloud podem trazer, é que deve-se

buscar a inserção de tais recursos no desenvolvimento de aplicações Web.

Os ganhos que são conseguidos por meio da Cloud Computing são refletidos na

disponibilidade de recursos, na manutenção, e na produtividade do desenvolvimento da

aplicação. Deste modo, esta prática irá explorar algumas questões da adoção da Computação

nas Nuvens em alguma parte da arquitetura da Máquina Social.

Problema:

A indústria de desenvolvimento de software vem inserindo os recursos da Cloud

Computing no cotidiano das fábricas de software. O novo paradigma, a priori, parece não

trazer muitas novidades que resolvam de forma diferenciada os já conhecidos problemas do

desenvolvimento de software. É necessário mais atenção e pesquisa para notar os benefícios

que podem ser agregados com a adoção de Cloud Computing. Este talvez seja um ponto

109


problemático para as empresas, que, por vezes não tentam desenvolver projetos experimentais

a ponto de confrontar os resultados da adoção de Cloud Computing.

Um problema relevante nesta questão é o fato de não se ter um parâmetro de como

ou onde usar Cloud Computing. Este paradigma estaria apto a suprir todas as necessidades das

Máquinas Sociais? Abdicar totalmente de uma infraestrutura de processamento e

armazenamento seria uma idéia radical? Ou ideal, para o desenvolvimento de aplicações

Web? Afinal muitas soluções não CC ofertam benefícios que são promessas da Cloud

Computing.

Outro problema inerente às próprias características de Cloud Computing é a

velocidade na taxa de leitura e escrita em disco (KE et al. 2010). Tendo em vista que CC

usufrui de muitas máquinas virtuais para se fazer leitura e escrita, principalmente quando se

trata de sistemas WEB, essas funções de leitura e escrita podem ser desaceleradas conforme a

quantidade de máquinas existentes (MOTAHARI-NEZHAD, 2009). Assim, toda aplicação

que precisar manipular muitos arquivos em disco não vai conseguir taxas altas de leitura e

escrita. Nesta categoria estão os servidores de email e de banco de dados. Sendo assim, ainda

seria interessante deixar o repositório de dados em CC?

Motivação:

A disseminação dos serviços e das ofertas em Cloud Computing pode promover a

criação e proliferação de negócios em setores nos quais os recursos e custos de TI são

impeditivos ao desenvolvimento do negócio. Assim, é extremamente motivador analisar como

o advento de Cloud Computing pode ser atrelado às Máquinas Sociais, e como a integração

entre duas SM’s pode ocorrer (Cloud Computing é uma SM que serve a outras SM’s).

A definição de uma arquitetura deve levar em consideração aspectos inovadores e

que possam ofertar soluções práticas e flexíveis para antigos e novos problemas da engenharia

de software. CC é capaz de ofertar essas soluções, além de ofertar possibilidades de reuso em

recursos computacionais. O próximo parágrafo evidencia ainda mais a motivação por se

analisar a utilização de Computação nas Nuvens.

Cloud Computing pode agregar mais poder de processamento ao desenvolvimento de

software visto que ela oferta alta disponibilidade de recursos para as aplicações e flexibilidade

nas manutenções (WEINHARDT, 2009). Essas manutenções são responsabilidades dos

110


provedores de serviços Cloud Computing e não da equipe que desenvolve a SM que utilizará

CC. (WEISSMAN, 2010).

Exemplo ou Solução:

Tudo em Cloud Computing é feito mediante as questões firmadas no acordo do nível

de serviço (SLA’s) (WEINHARDT, 2009). Portanto, o cuidado e a análise com o SLA é

considerável. Deste modo, é possível verificar a eficiência do modelo de implantação da CC,

se público ou privado, bem como o esforço da equipe de implementação da Máquina Social,

este deve ser o menor possível.

Todavia antes de verificar a adoção de qualquer serviço CC devem-se analisar

anteriormente todas as SLAs referentes ao serviço. Estas formalizam um contrato de acordo

de serviço, ou seja, o que será prestado como serviço e como deve ser o desempenho do

fornecedor de serviço. Tais SLAs devem ter a transparência necessária para deixar evidente o

que será fornecido como serviço, como será fornecido, a que custo será fornecido, os prazos

necessários e etc.

Enquanto as SLAs são protagonistas no assunto, outros serviços e tecnologias

ganham destaque, entre eles:

Cloud Brokers: Trata-se de um seviço de corretagem em CC, empresas

especialistas no assunto ofertam esse serviço que visa indicar qual o melhor

provedor, e quais os serviços Cloud mais adequados ao negócio que pretende

adotar Cloud Computing (GARTNER Inc, 2009). Os Brokers ainda são

capazes de analisar as SLAs existentes em um contrato de pretação de serviço

Cloud, indicar melhorias nesse contrato, e ainda viabilizar a implantação do

serviço, caso a empresa não tenha recursos humanos totalmente capacitados38.

Windows Azure: Segundo experimentos de Kossmann, Kraska e Loesing

(2010) a IaaS Windows Azure é a plataforma que oferta maior performance e

escalabilidade aos sistemas de médio e grande porte. Ou seja, aos sistemas

com lógicas mais complexas, ou, que devem suportar grande volume de

dados e de acessos. Tal plataforma ainda oferta serviços de criptografia RSA

e segurança de dados com firewall.

38 Disponível na página do intituto Gartner, Inc. (NYSE: IT). Fundado em 1979 em Connecticut, U.S.A. Em:

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

http://www.gartner.com/technology/about.jsp


A estratégia para se decidir como usar CC na arquitetura da Máquina Social é

realmente estudar o escopo e a necessidade da aplicação para confrontar com o que Cloud

Computing pode ofertar. É importante compreender as tecnologias que os provedores de

Cloud Computing usam para prestação de serviço assim como as implicações dessas

tecnologias sobre os recursos computacionais, sobre a economia e a segurança. Tal

compreensão é relevante, pois a arquitetura da Máquina Social vai se entrelaçar a alguma

camada da arquitetura do provedor de serviço Cloud Computing.

Esta prática ajudará nas decisões relacionas a Cloud Computing e no entendimento

de alguns de seus recursos relacionados abaixo:

1. Recursos Computacionais:

Ao utilizar um recurso Cloud Computing como IaaS, por exemplo, é possível dispor

de recurso computacional automaticamente conforme a necessidade e crescimento da

aplicação, isto sem esforço da equipe de desenvolvimento da Máquina Social. Além disto,

com esta solução é possível usufruir de alta segurança e disponibilidade dos dados.

Para um serviço de IaaS a empresa Amazon pode ser considerada. A organização, ou

a pessoa, que adquirir os serviço Cloud da Amazon, consegue implantar um software Oracle,

por exemplo, ou fazer backup de um banco de dados, em muito pouco tempo39 e sem

problemas. A Amazon ainda disponibiliza o serviço “Amazon Elastic Compute Cloud (EC2)”.

Com ele é possível montar um ambiente que pode ser usado para as implantações de banco de

dados. Por fim, esses serviços IaaS são capazes de ofertar balanceamento de carga, segurança

por meio de firewall, e replicação de instâncias de bancos de dados.

Algumas recomendações sobre os serviços e recursos Cloud Computing prosseguem

abaixo:

Guardar réplicas de segurança em outros repositório, sejam eles locais ou na

nuvem. Tais cópias devem ser, sobretudo, dos dados. Isto é necessário porque os

recursos Cloud Computing são susceptíveis de falhas.

Usufruir sempre da garantia de disponibilidade e analisar outros métodos que

contribuam para a aquisição de desempenho da aplicação. Pesquisas recentes feitas

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

http://aws.amazon.com/ec2/


pela empresa Compuware40 apontam que 72% das empresas avaliadas em uma

pesquisa alegam que não houve ganhos em desempenho (mal desempenho) ofertados

pelos serviços Cloud Computing.

Trabalhar fortemente com XML para a integração entre as camadas da

arquitetura na aplicação e na nuvem.

Utilizar características de arquiteturas ou redes P2P para amenizar os

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

2009).

2. Economia:

O preço do serviço deve estar claro em uma SLA de CC. Alguns planos do Amazon

EC 2, por exemplo, custam apenas 600 (seiscentos) dólares por ano41. Para algumas empresas,

isto pode significar uma redução de custos, segundo a Forrester Research, de até 80% nos

gastos com infraestrutura.

Cloud Computing pode trazer redução de custos para empresa de pequeno e médio

(PMEs) porte que não possuem um forte parque tecnológico. Logo, o nível de maturidade da

TI em empresas desses portes, principalmente no Brasil, é relativamente baixo (REZENDE,

2006). Para as PMEs, o preço das boas ferramentas tecnológicas sempre foi elevado. Neste

aspecto, as ofertas de Cloud Computing podem ser vantajosas, mostrando um cenário mais

promissor para a TI das PMEs.

Cloud Computing pode ser uma solução econômica em situações onde se requer

poder computacional. O exemplo seguinte explora muito bem essas situações. Segundo

Taurion (2009), o jornal New York Times no ano de 2008 necessitou digitalizar todas as suas

edições desde 1851 até o ano 1989. Entretanto, os recursos computacionais do jornal ficariam

sobrecarragados, o que levaria a aquisição de novos recursos. Nesta situação a equipe de TI

decidiu por adquirir os serviços Cloud Computing EC2 da Amazon, o que possibilitou o

processamento de 3 (três) terabytes de dados, em 24 (vinte e quatro) horas, utilizando 100

(cem) instâncias virtuais a um custou de 240 (duzentos e quarenta) dólares.

40 Disponível em: http://computerworld.uol.com.br/negocios/2010/09/10/desempenho-e-maior-problema-para-usuarios-de-cloud-computing/. Acesso em 30 de jul. 2011.41 Informação disponível em: http://aws.amazon.com/ec2/. Acesso em 19 de ag. 2011.

113


http://computerworld.uol.com.br/negocios/2010/09/10/desempenho-e-maior-problema-para-usuarios-de-cloud-computing/

http://computerworld.uol.com.br/negocios/2010/09/10/desempenho-e-maior-problema-para-usuarios-de-cloud-computing/


Por fim, o uso de SM’s dependerá muito do contexto econômico da empresa, apesar

das aparentes vantagens há de se analisar todas as despesas decorrentes de treinamento,

contratos, marketing e outras vertentes naturais do negócio. Somente assim será possível

verificar se as vantagens serão refletidas por meio de economia financeira. A adoção de Cloud

Computing para redução de custos é algo muito relativo, e não deve ser o fator preponderante

para a adoção.

3. Segurança:

A segurança é um requisito importantíssimo para qualquer sistema computacional. E

a falta de segurança é um perigo presente não só para os usuários de Cloud Computing. Mas,

se tratando de CC, existem receios em sua adoção que são oriundos da falta de segurança. O

fato é que existem realmente riscos, mas, em oposição a eles, existem excelentes soluções que

objetivam garantir a segurança.

A grande preocupação reside em não saber se os dados estariam tão seguros em

Cloud Computing quanto estariam seguros localmente. Pois bem, a privacidade nos dados,

sobretudo quando se utiliza os serviços de uma Public Cloud, ou núvem pública, pode ser

algo delicado, Os dados de uma empresa, ou cliente, que são armazenados em uma nuvem

pública, normalmente residem em um ambiente compartilhado com dados de outros clientes e

empresas. Assim é necessário trabalhar bem com o controle aos meios de acesso aos dados.

Controle de acesso via senha é uma solução bem madura em Cloud Computing, uma

vez que, por meio da senha os clientes e as empresas respondem a um conjunto de questões de

segurança para ter acesso à conta. Neste contexto, a criptografia por meio do algoritmo RSA é

muito bem trabalhada. Existem ainda os certificados de chaves públicas. Eles permitem

transferências de dados sempre protegidos usando novamente a criptografia. Geralmente isto

pode ser implementado em SaaS, PaaS e IaaS diversificadas. Tais chaves rotineiramente são

geradas fora da nuvem, o que oferta mais segurança e confiabilidade ao cliente ou empresa

que são os únicos a terem conhecimento da chave.

Todas as soluções de segurança contempladas nos parágrafos acima foram lançadas

pelo NIST em um documento42 do mês de dezembro do ano de 2011. O mesmo possui

práticas e orientações sobre segurança e privacidade em Cloud Computing. O documento

orienta que a adoção da nuvem privada é mais adequada aos negócios de qualquer natureza,

ou seja, a escolha por uma nuvem pública ou privada dependerá muito da natureza dos dados

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


trafegados. Entretanto, o mesmo documento encoraja experiências com o modelo público de

Cloud Computing.

A segurança tem sido bastante trabalhada em Cloud Computing. Vale reforçar que

novamente as SLAs devem tratar claramente das questões de proteção, privacidade dos dados,

e garantia de integridade das aplicações. A próxima prática deixa a parte as questões de Cloud

Compunting e aborda uma questão de elevada importância para um sistema distribuído em

rede: a questão dos Padrões de Projeto.

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

Padrões de projeto são soluções de código que podem ser reutilizadas para resolver

um determinado problema (GAMMA, et al. 2000). Estes padrões substituem implementações

de códigos e projetos de componentes de software. São produtos preparados para interagir

com implementação e agregar recursos que dêem suporte a alguma funcionalidade a ser

desenvolvida.

Problema:

Os padrões de projeto podem ser utilizados com qualquer linguagem de programação

desde que os conceitos de orientação a objetos sejam vigentes na aplicação. Entretanto, é

necessário guiar esses padrões para o contexto de Máquinas Socias enquanto aplicações Web,

limitando os mesmos. O quantitativo de problemas a serem resolvidos por Máquina Sociais é

vasto, assim, a probabilidade de usar padrões diversificados é grande. Deste modo, deve-se

fechar o escopo dos padrões para Máquinas Sociais a partir das características, conceito, e

particularidades de uma SM’s.

Ao todo existe um universo de 23 padrões de projeto. Quais destes ofertariam melhor

suporte as SM’s? Além deste questionamento, existem também alguns problemas que são

inerentes às Máquinas Sociais e que podem ser solucionados por padrões de projeto

específicos. Alguns destes problemas são:

Não ter fácil acesso às informações sobe o estado dos componentes;

Não ter conexões eficientes entre as Máquinas Sociais e entre os

componentes que constituem as mesmas;

115


Não ter ação necessária de forma imediata após conhecer o estado dos

componentes.

Motivação:

É desejável que existam soluções reutilizáveis em algum nível de abstração e que

sejam voltadas às Máquinas Sociais. Na verdade esse conhecimento poderá motivar o estudo

de novos padrões para SM’s. Ainda assim, os padrões já existentes demonstram muita riqueza

quanto à capacidade de resolver problemas naturais das Máquinas Sociais.


A execução desta prática deve levar em consideração que alguns padrões são

fortemente utilizados no estilo arquitetural camadas, São eles: Observer, Composite e o

Strategy (LARMAM, 2005). Além disto, os padrões são divididos em 3 (três) grupos: padrões

de criação, padrões estruturais, e padrões comportamentais.

Os padrões comportamentais e os padrões estruturais constituem os maiores grupos,

e também são os mais relevantes para as Máquinas Sociais. Isto se deve ao fato do primeiro

grupo de padrões ser o único a se preocupar com a conexão entre os objetos e classes. Estes

padrões também priorizam a cooperação entre os elementos e ainda viabilizam o baixo

acoplamento, o que é fundamental para a arquitetura em Camadas, segundo Craig Larmam,

2005.

Larman também afirma que o outro grupo de padrões estruturais visa a composição

das classes que formam os sistemas de modo que essas classes sempre tenham interfaces

compatíveis no intuito de se unirem para formar uma unidade maior, como um componente

que constituirá o sistema, ou o próprio sistema em si. Vale ressaltar que, se houver

necessidade, os padrões do grupo de criação podem também ser empregados; principalmente

os padrões que criam interfaces, como o Factory Method (GAMMA et al, 2000).

Neste ponto veremos a definição de alguns dos padrões de projeto (GAMMA et al,

2000) mais preparados para atender a maioria das Máquinas Sociais enquanto sistemas Web.

Padrões de Projetos Estruturais

Nome Definição / Problema a ser resolvido116


Adapter Faz a adaptação de interfaces em momento que uma classe não tem a

interface que corresponde ao domínio esperado pela aplicação.

Composite Compõem classes para formar um componente maior, deixando

transparente ao usuário ao qual está fornecendo o serviço, se um

componente ou se o conjunto destes. Previlegia o baixo acoplamento.

Decorator Usa de forma flexível a extensão de subclasses para acrescentar

operações acionais às classes ou objetos. Isto quando se fizer

necessário a adaptação da função de um componente para uma

funcionalidade específica.

Tabela 6. Padrões Estruturais relevantes para as SM’s

Padrões de Projetos Comportamentais

Nome Definição / Problema a ser resolvido

Mediator Armazena em um objeto a forma pela qual todos os outros objetos irão

interagir; ele é aplicado para reduzir a duplicação de código, pois as

classes, ao serem criadas podem ser customizadas para ter sua

comunicação e função viabilizadas por este padrão.

Observer Gera uma ligação entre os objetos de modo que, no momento em que

um objeto alterar seu estado, todos os objetos sejam automaticamente

notificados da alteração.

State Permite que um componente altere suas funções conforme a alteração

do seu estado.

Strategy É um conjunto de algoritmos distintos que pode ser executado para

alterar o comportamento de uma classe conforme as variações do

ambiente ou conforme a necessidade dos requisitos.

Tabela 7. Padrões Comportamentais relevantes para as SM’s

A aplicabilidade dos padrões comportamentais sobre as SM’s é maior do que a

aplicabilidade dos padrões estruturais. Outros padrões, fora ou não desses grupos, podem ser

de grande valia às SM’s, mas isto irá depender unicamente das características da aplicação e

do ambiente onde a mesma está inserida, ou ainda dos requisitos impostos à mesma.

117


O seguinte exemplo pode ocorrer de forma natural no emprego dos padrões às SM’s.

Imaginemos que a camada de negócio poderá ter em seus componentes a inserção do padrão

Strategy, que será útil no caso de uma camada superior da arquitetura ofertar uma resposta

negativa, ou fora do esperado, neste caso, graças ao padrão, a camada inferior não responderia

as solicitações, anulando assim, suas operações.

O exemplo acima é um caso que retrata a contribuição de um padrão na satisfação de

um requisito não funcional para a Máquina Social. Quando se observa melhor a prioridade

desses requisitos, é possível empregar melhor os padrões. A tabela 8 mostra o relacionamento

entre os padrões indicados para as Máquinas Sociais e os requisitos não funcionais das

mesmas.

Padrões

RNF Adapter Composite Decorato

r

Mediator Observe

r

State Strategy

Performance X X X X

Disponibilidade X X X X

Modificabilidade X X X X X X

Interoperabilidad

e

X X X X

Tabela 8. Relação entre os padrões de projeto e os requisitos não funcionais das SM’s

Esta prática, assim como todas as outras, tende a orientar os desenvolvedores quanto

às melhores decisões de projeto para a Máquina Social a ser implementada. A decisão mais

assertiva em relação a banco de dados de Máquinas Sociais será exposta a seguir:

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

Bancos de dados não relacionais, ou NoSQL, surgiram em 1998. O propósito deste

tipo de banco de dados é suprir as carências que estão presentes nos bancos relacionais, entre

elas, a escalabilidade e a flexibilidade em mudar estruturas. A abordagem NoSQL tem sido a

mais explorada entre grandes coorporações da Web 3.0, como: Facebook, Twitter, Google e

Amazon (LEAVITT, 2010).

Problema:

118


O problema reside no fato das Máquinas Sociais serem, em grande parte, aplicações

que necessitam de bom gerenciamento dos acessos aos dados, acessos que passam a ser

crescentes ao passo que cresce a quantidade de usuários da aplicação, necessitando assim de

escalabilidade para a performance. Tal requisito é deficitário em banco de dados relacionais

(LEAVITT, 2010).

Motivação:

Explorar uma abordagem mais moderna e que propicie a escalabilidade de forma

mais simples e mais barata que os modelos relacionais é uma grande motivação para as SM’s.

Não é necessário que a SM a ser desenvolvida tenha milhões de usuários em acessos

simultâneos. Basta que a mesma trabalhe com objetos complexos, ou que tenham entidades

espalhadas em muitas tabelas normalizadas (TIWARI, 2011), isto seria suficiente para

trabalhar com NoSQL. Os bancos não relacionais atendem de forma mais eficiente os

requisitos das Máquinas Sociais, sobretudo, desempenho (TIWARI, 2011).


Para seguir tal prática é necessário avaliar algum banco NoSQL, entre elas se

destacam:

Amazon Dynamo e MemcachedDB: trabalham com armazenamento de dados

baseados no modelo chave-valor (TIWARI, 2011).

CouchDB e MongoDb: trabalham com armazenamento de dados baseado no

modelo orientado a documentos (CHODOROW e DIROLF, 2010).

BigTable, SimpleDB, Hbase e Cassandra: trabalham com armazenamento de

dados baseado no modelo orientado a colunas.

Neo4j e InfoGrid: trabalham com armazenamento de dados baseado em

grafos.

Todas essas soluções são distribuídas e executam o chamado “processo de sharding”.

Esse processo faz o escalonamento paralelizado (TIWARI, 2011), ou seja, os dados são

distribuídos por vários servidores que trabalham de forma paralela. Isto possibilita a

escalabilidade. Já o desempenho da SM é sensivelmente melhorado devido à diminuição do

volume de dados processados pelos servidores de BD NoSQL. Finalmente, um requisito

fortemente atendido e extremamente relevante à SM, é a disponibilidade (LEAVITT, 2010).

119


Esta pode ser atendida, pois, uma ou duas BD’s podem ficar indiponíveis sem causar a

interrupção de toda a SM.

Com NoSQL, disponibilidade, desempenho/performance e flexibilidade são

agregados a arquitetura. Isto contribui ainda mais para o bom funcionamento da SM. Até

mesmo a consistência dos dados pode ser garantida, haja vista que o sistema de banco de

dados possui mecanismos que detectam quando os objetos forem atualizados (CHODOROW

e DIROLF, 2010), retornando sempre o último valor atualizado dos mesmos.

Depois da devida análise da SM a ser construída, é necessário selecionar como será o

sistema de armazenamento. Nesta análise, caso seja detectado que a SM a ser desenvolvida

possa trabalhar com a base de dados relacional, a mesma pode ser adotada, já que ocorrem

diversos benefícios em sua aplicação, principalmente na questão da consistência dos dados.

As conclusões deste capítulo vão em seguida abordando as práticas para SM,

sintetizando as idéias, amadurecendo alguns possíveis trabalhos futuros, além de preparar o

próximo capítulo.


Algumas práticas recomendadas aqui dão novas idéias que podem ser amadurecidas

perfeitamente em trabalhos futuros, como: os padrões de projeto que podem ser adaptados

para as SM’s, fazendo surgir assim um novo padrão; bem como, o framework de Máquinas

Sociais exposto neste trabalho, e ainda, possíveis padrões de processo de SM’s. Os padrões de

processo fazem parte das disciplinas ligadas a negócio e administração de empresas, todavia,

existe uma proposta de padrão de processo chamada Business Pattern, autoria de Mark Endrei

e mais 7 (sete) autores pela empresa IBM no ano de 2004.

Os padrões de processo exibem vários padrões de TI. Estes padrões guiam o

desenvolvimento de aplicações específicas, como por exemplo, ferramentas Web que

viabilizam o trabalho colaborativo. Uma das recomendações para esse tipo de sistema seria

implementar a ferramenta por meio do Collaboration (User-to-User). Este é uma padrão que

teria os conhecimentos mais adequados sobre as tecnologias de implementação, arquitetura e

reuso de componentes do trabalho colaborativo. Logo assim, as práticas aqui tratadas

120


poderiam formar um padrão de construção de SM’s, fazendo parte do catálogo do “Business

Pattern”.

Em vista de justificar alguns conceitos é importante evidenciá-los ao final do

catálogo de boas práticas. Na verdade as práticas constituem sim um padrão para construção

de Máquinas Sociais, e, para isto, adota estratégias que deixam evidente o uso de alguns

conceitos e tecnologias, como componentização de software.

A criação de componentes de software exalta a criação de pequenas partes do

software com funções bem definidas e interfaces adaptáveis para a conexão com uma

variedade de aplicações. A implementação de componentes particiona a aplicação, facilitando

a adoção do estilo camadas e promovendo a independência de tecnologias (CHEESEMAN e

DANIELS, 2001). A manutenção e evolução do software também são facilitadas, podendo a

arquitetura da aplicação ser estendida sem muita dificuldade de modo que seus componentes

possam ser distribuídos (TANENBAUM, 2002), integrados e reutilizados.

Em praticamente todas as práticas existe uma menção à componentização de

software, especialmente as práticas 5 (cinco) e 2 (dois), aliás, a 2ª e 3ª prática tratam dos

assuntos relacionados a SOA inclusive.

As primeiras práticas remetem aos princípios que são trabalhados no paradigma da

Arquitetura Orientada a Serviços – SOA; a adoção desse paradigma já trouxe diversos

benefícios às médias e grandes empresas (ERL, 2008). SOA ou Arquitetura Orientada a

Serviço é baseada em computação distribuída e seu conceito está voltado para a utilização de

software como serviço. SOA, assim como a componentização, contribui para a reutilização de

software favorecendo a comunicação entre os sistemas (JOSUTTIS, 2007).

Para adotar SOA, é necessário fazer um catálogo de todos os processos que apóiam a

TI e que sejam parte do nicho de negócio dos softwares implementados (JOSUTTIS, 2007).

Estudos recentes efetuados pelo instituto de pesquisa Gartner revelam que SOA promove uma

maior eficiência na execução dos processos de negócio, facilitando o surgimento de outros

processos, reduzindo gastos, melhorando a escalabilidade do sistema, a qualidade e o tempo

de entrega dos serviços. SOA também estaria apta a trabalhar dentro do paradigma de Cloud

Computing, segundo o instituto. Tal paradigma está bem maduro e propenso a auxiliar o

desenvolvimento de SM’s.

121


Não é propósito adotar SOA definitivamente em SM’s, mas sim adotar alguns

princípios e conceitos de SOA e que podem auxiliar no desenvolvimento facilitado de SM’s,

como por exemplo: o tratamento aos serviços e o cuidado com a modelagem de processos.

Assim, a modelagem de processo que é tratada na primeira prática pode dar suporte para

demais práticas. Os serviços só são bem mensurados quando se conhece o negócio. Neste

trecho é notável uma relação de dependência entre as práticas.

As práticas 7 (sete) e 9 (nove) estão também bem entrelaçadas às demais práticas.

Neste caso, a prática sete, por exemplo, ajudará a encontrar a melhor solução em comunicação

e interoperabilidade mediante o auxílio de outras práticas, como: as práticas de análise dos

serviços, de implementação dos elementos States e Constraints, dos estilos arquiteturais que

compõem a arquitetura da SM e os padrões de projeto utilizados.

Outra relação que pode ser ainda traçada é entre as práticas e os requisitos não

funcionais que devem ser priorizados para as SM’s. Dentro deste contexto deve-se observar

que a alteração na metodologia proposta deve ajudar a arquitetura a satisfazer os requisitos

não funcionais críticos para a Máquina Social. Deste modo, a tabela 9 relaciona os requisitos

às práticas.

RNF

Práticas

Desempenho /

Performance

Disponibilidade Modificabilidade Interoperabilidade

1.Modelar Processos

X X

2.Reconhecer os Serviços

X X

3.Reconhecer os Provedores

X X X X

122


4.Recursos para Autonomia

X X

5.States e Constraints

X X

6.Extratégia Estilo Arquit.

X X X X

7.Comunicação e Interoper.

X X X X

8.Cloud Computing

X X

9.Padrões de Projeto

X X X X

10. NoSQL 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


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

RMI

ESB’S

Design Patterns

Design Patterns

Des

ign

Patt

erns D

esign Patt

erns

Capítulo

6

6. Experimentação das Práticas

Este capítulo foi concebido para mostrar a aplicação das práticas propostas para o

desenvolvimento de arquiteturas de Máquinas Sociais. O objetivo é guiar as decisões de

projetos e a própria modelagem da arquitetura. Assim, ao final da implementação, será

verificado como o produto desta pesquisa foi útil ao desenvolvimento de SM’s.

125

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

6.1. INTRODUÇÃO

O experimento efetuado é do tipo estudo de caso, ou caso de uso, ou ainda In vivo,

(JURISTO e MORENO, 2001). Trata-se de um caso real de pessoas em seu ambiente próprio

de trabalho. No entanto, antes de exibir o estudo, haverá uma seção para expor brevemente

um projeto piloto, o qual foi utilizado para por em prova o planejamento do estudo de caso e o

próprio objeto de controle, ou seja, a abordagem a ser experimentada.

Nem todos os detalhes sobre o desenvolvimento serão expostos, pois os projetos são

reais de empresas e profissionais fixadas no mercado, onde os produtos, ou SM’s resultantes,

ainda não estão disponíveis aos clientes ou usuários. Os responsáveis pelo desenvolvimento

das SM’s que serão exibidas neste capítulo autorizaram a exposição das mesmas. No entanto,

como já explicitado, por questões de confidencialidade exigidas pelos proprietários das SM’s,

e também por causa de concorrência da indústria de software local, algumas informações

serão subtraídas da exibição do desenvolvimento. Todavia acredita-se que a ausência de tais

informações não deixará pontos duvidosos ou falsos no estudo.

6.2. DEFINIÇÃO DOS OBJETIVOS

1. Objetivo Global: Determinar o efeito do uso das práticas e da arquitetura de

referência na definição de arquiteturas de Máquinas Sociais na qualidade

dessas arquiteturas.

2. Objetivo da Medição Baseado nas Características das SM’s e na

Comparação em não Usar as Práticas e a Arquitetura de Referência - AR:

verificar as vantagens oferecidas pela AR e práticas de SM’s na definição da

arquitetura sobre os aspectos: adequação das práticas, precisão nas escolhas

arquiteturais, usabilidade da arquitetura de referência, agilidade na fase de

projeto de arquitetura, ou simplesmente projeto; e por fim, a qualidade dos

componentes codificados na fase de implementação.

3. Objetivo do Estudo: Analisar a adequabilidade da arquitetura de referência e

das práticas propostas em projetos de Máquinas Sociais quando comparado ao

desuso das mesmas, isto no contexto de empresas que desenvolvem SM’s.126


4. Questões:

a. Os pontos tratados pelos métodos propostos para SM’s, ou seja,

práticas mais AR, são suficientes para a arquitetura da SM ser

desenvolvida em todos os seus aspectos ou ao menos aos aspectos mais

importantes como os requisitos não funcionais?

i. Métrica: Quantidade de pontos ou requisitos trabalhados pela

arquitetura com auxílio dos métodos propostos.

b. As práticas e arquiteturas de referência para SM’s auxiliaram na

definição adequada dos componentes arquiteturais, ofertando assim

maior qualidade do produto de software e consequentemente da

arquitetura?

i. Métrica: Quantidade de não conformidades encontradas por

meio de testes funcionais e também por meio da aceitação do

cliente.

A questão e métrica relacionada as não conformidades são difíceis de serem

controladas. Se este experimento fosse feito em laboratório, onde todas as variáveis fossem

controladas, a dificuldade poderia ser menor (JURISTO e MORENO, 2001). Isto ocorre

porque a quantidade de defeitos encontrados nos produtos de software é muito relativa aos

requisitos, às pessoas envolvidas, e claro, às decisões de projeto e arquitetura. Com isto é

complicado saber qual a causa dos defeitos. No entanto, é válido incluir essa questão e

métrica, pois as práticas trabalham na concepção dos processos de negócio e serviços, o que

faz elas enrriqueçam os requsitos, e melhorem a arquitetura.

Averiguar a quantidade de defeitos encontrados nos artefatos testados após o uso das

práticas na arquitetura de referência dará indiícius de que as mesmas auxiliaram em algum

aspecto, ou mesmo em conjunto a outros fatores, na diminiução dos defeitos.

127


6.3. PLANEJAMENTO

6.3.1. OBJETO DE CONTROLE

O objeto de controle é a abordagem a ser experimentada (WOHLIN. et al, 2002).

Para este estudo, o objeto são as práticas e arquitetura de referência propostas para conceber

arquiteturas de Máquinas Sociais.

6.3.2. UNIDADE EXPERIMENTAL

A unidade experimental é o objeto que receberá o tratamento (JURISTO e

MORENO, 2001). Para este estudo o objeto que será submetido à experimentação é a fase de

projeto, ou modelagem de sistema. Nesta será verificado a utilidade da metodologia de SM e

se a mesma é adequada para a formulação da arquitetura de Máquinas Sociais.

6.3.3. DEFINIÇÃO DAS HIPÓTESES

Serão divididas em hipótese nula, que representa o que o estudo quer negar

(WOHLIN. et al, 2002); e hipótese alternativa, que representa o contrário da hipótese nula

(TRAVASSOS, GUROV e AMARAL, 2002).

HIPÓTESE NULA: O uso das práticas e da arquitetura de referência não

demostrou diferença nos parâmetro abaixo em relação ao não uso das mesmas

pela empresa para a definição de arquitetura.

NºPOR: número de requisitos da SM trabalhados pela arquitetura.

AD: adequação da arquitetura concebida por meio do objeto de controle.

Deste modo o que a hipótese nula afirma é:

NºPORsempráticas+AR=NºPORpráticas+AR

ADsempráticas+AR=ADpráticas+AR

HIPÓTESE ALTERNATIVA: O uso das práticas e AR revelou ganhos em

relação aos parâmetros, de modo que, a qualidade do produto foi atestada

como satisfatória, assim:

NºPORsempráticas+AR<NºPORpráticas+AR

128


ADsempráticas+AR<ADpráticas+AR

Dentre estas variáveis o fator tempo não foi controlado. Entende-se que o mesmo não

agregaria resultados significativos, uma vez que é possível que o tempo da fase de projeto seja

maior com a utilização das práticas. Isto, em equipes que já façam uso de uma metodologia de

concepção da arquitetura. O objetivo também não é viabilizar uma arquitetura em pouco

tempo, mas sim, disponibilizar uma arquitetura correta e de qualidade à Máquina Social.

6.3.4. VARIÁVEIS INDEPENDENTES E DEPENDENTES

VARIÁVEIS INDEPENDENTES:

1. Tipo de Máquina Social a ser construida: é necessário que sejam

desenvolvimentos interessantes de Máquinas Sociais do tipo

Prosumers, pois essas SM’s são mais completas e complexas. Sendo

assim, o resultado pode ser verificado para o caso mais extremo de

SM’s. Com isto, se o resultado for satisfatório, entende-se que o objeto

de controle poderá ser aplicado sem maiores problemas para os projetos

de SM’s mais simples.

2. Habilidade da equipe em desenvolver e entender as aplicações

WEB como Máquinas Sociais: em equipes que já entendem as

apliações como SM’s, as novidades nas práticas e AR poderão não

agregar benefícios de grandes dimensões.

3. Fase do processo de desenvolvimento: a fase é um fator relevante

porque é necessário trabalhar o objeto de controle em um momento que

possibilite o acompanhamento do projeto e a instanciação das práticas e

arquitetura de referência. Ou seja, os desenvolvimentos não devem

estar na fase de codificação da aplicação ou mesmo documentação de

arquitetura.

VARIÁVEIS DEPENDENTES:

1. Maior quantidade de pontos ou requisitos trabalhados pela arquitetura

para satisfazer a Máquina Social;

129


2. Adequabilidade maior da arquitetura à Máquina Social, com poucas, ou

nenhuma não conformidade (defeitos encontrados).

6.3.5. RUÍDOS

Os ruídos podem contaminar as variáveis durante o experimento. Estes ruídos são

erros que ocorrem de forma não intencional e sim inesperada durante o estudo

(TRAVASSOS, GUROV e AMARAL, 2002). Um ruído provável seria a não execução de

alguma prática proposta devido a um acontecimento que exija menos tempo de

desenvolvimento, provocando assim, uma má execução da fase de (projeto) modelagem.

Outro ruído seria a ausência de algum integrante da equipe, ausência provocada por um

problema ou por alguma determinação da empresa.

6.3.6. CONTEXTO

O contexto é caracterizado como sendo In vivo, como já indicado anteriormente.

Ademais, trata-se de um experimento contextualizado como um problema real de produção de

software que utiliza profissionais da área de Ciências da Computação como participantes. Os

resultados deste experimnto podem ser úteis a problemas específicos da modelagem

arquitetural de Máquinas Sociais.

6.3.7. SELEÇÃO DOS INDIVÍDUOS

Os indivíduos que estiveram contidos neste estudo de caso faziam parte da equipe de

desenvolvimento e foram selecionados mediante determinação da própria empresa, antes

mesmo que esta obtivesse conhecimento do planejamento do estudo. A unidade experimental

selecionada estava no momento ideal de ser submetida, ou seja, as fases de projeto e

codificação ainda não haviam iniciado. Além disto, a empresa se colocou à disposição do

experimento.

Quanto à empresa, é importante citar que o estudo de caso foi sobre uma Máquina

Social criada pela empresa MV Informática Nordeste. A MV é uma empresa com mais de 25

anos no mercado de desenvolvimento de software para gestão hospitalar. A linha de produção

da MV é responsável por sistemas que automatizam todos os processos de instituições ligadas

à saúde no Brasil, entre elas: planos de saúde, clínicas, hospitais públicos e privados, e 130


também unidades de pronto atendimento, as UPA’s. Assim, os sistemas possuem

funcionalidades que fazem desde o controle financeiro até o controle de fichas anestésicas de

pacientes, incluindo o prontuário eletrônico do mesmo. A MV autorizou a documentação e

exposição deste experimento.

6.3.8. VALIDADE

Nesta seção as possíveis ameaças à validade do experimento (JURISTO e

MORENO, 2001) serão listadas. Três ameaças à validade foram detectadas, a primeira foi a

Validade Externa.

Validade Externa pode limitar o resultado obtido no experimento de modo que as

práticas e AR para SM’s tenham uma adoção duvidosa por parte da indústria de software.

Nesta categoria, uma ameaça é a inserção de requisitos durante a fase de projeto ou mesmo

após tal fase. É possível que o cliente solicite um requisito fora da fase de análise. Tais

requisitos podem impactar na arquitetura, modificando ou estendendo a mesma. Desta forma,

existiria o risco de dar tratamento acima de uma arquitetura com requisitos diferentes,

afetando assim as variáveis.

Dentre as ameaças a validade houve a imposição da empresa em começar o

desenvolvimento. Havia datas predefinidas e improrrogáveis para o início de cada fase do

processo. O desenvolvimento do produto da MV teve acompanhamento constante, com

exigências de diversos gestores e um diretor. Este fato impulsionou outra ameaça, desta vez à

Validade de Conclusão.

Uma vez que houvesse a pressão para o início do projeto, não haveria tempo hábil

para começar o experimento com o emprego das práticas e da AR de Máquinas Sociais. Deste

modo, o experimento deveria iniciar sem o objeto de controle, apenas por meio da

metodologia tradicional já utilizada anteriormente pela empresa. Esta ameaça própria da

Validade de Conclusão imposibilitaria concluir com convicção o real resultado do tratamento,

ou seja, o real resultado do experimento. Assim, a equipe desenvolvedora e participante do

estudo já teria certo conhecimento de como fazer a modelagem e também de quais problemas

deveriam ser resolvidos, além das necessidades arquiteturais, haja vista que já haveriam

projetado em um momento primário a arquitetura sem o uso das práticas e da AR.

131


O preparo acima mencionado, tanto em relação à equipe quanto ao produto de

software a ser modelado e implementado pode caracterizar outra ameaça para o tipo Validade

Interna. Esta validade se refere ao cansaço mental, físico, preocupação ou estresse dos

participantes durante o experimento, pois que, todos os envolvidos poderiam participar de

outros projetos concomitantemente ao experimento.

6.4. EXECUÇÃO

6.4.1. PROJETO PILOTO

O projeto piloto é a execução da experimentação em outro ambiente, com outras

pessoas e com outra unidade experimental (JURISTO e MORENO, 2001). Ele será útil para

corrigir possíveis erros no planejamento do experimento e verificar se existem melhorias que

possam ser feitas no próprio objeto de controle.

O projeto piloto foi executado sobre uma App de mercado que não foi desenvolvida

por uma fábrica de software, mas trata-se de um projeto realizado por um profissional da área

de TI. Sua implementação e desenvolvimento podem ser atestados na íntegra no trabalho de

Misael Neto, 2012. Tal App chama-se HobNob, este é um aplicativo com escopo bem

delimitado, pois sua função é sugerir acontecimentos sociais (festas) aos usuários conforme a

localização dos mesmo. O HobNob precisa de informações básicas de uma pessoa, precisa

saber sua localidade e os gostos pessoais em relação à música, a artista favorito, e às festas

frequentadas. Essa App é uma aplicação dedica ao Facebook.

A aplicação tratada neste experimento utiliza o Facebook de forma inteligente, haja

vista ela mapeia até as ligações de amizade entre os usuários da rede, ou seja, ele captura o

grafo de amizade codificando os relacionamentos entre os objetos deste grafo. Deste modo, é

possível revelar e indicar festas que amigos de um determinado usuário foram, ou vão, e que

possivelmente este usuário possa querer ir. A formação do conhecimento para poder sugerir

festas a uma pessoa conforme sua localização também parte da utilização dos serviços do

Google Maps. Por este parágrafo é possível observar que o HobNob é uma Máquina Social

Prosumers por natureza. Os principais resultados e efeitos deste projeto piloto serão

detalhados em seguida.

132


Neste projeto inicial, o conjunto de práticas foi seguido, e elas foram plenamente

compreendidas na ordem em que foram documentadas no capítulo 5. Entretanto, nem todas

foram lidas em sua completude, pois, neste experimento o responsável pelo desenvolvimento

já compreendia bem os conceitos de SM’s e de muitas das tecnologias que podem ser

empregadas no contexto da Web 3.0. Desta forma, o desenvolvedor se sentiu seguro o

suficiente para uma leitura superficial das práticas.

Para o projeto piloto, as primeiras práticas não tiveram muita contribuição pelo fato

da aplicação já ser direcionada unicamente ao Facebook e ter um escopo bem limitado.

Apesar deste fato, o conhecimento sobre serviços, que é a proposta das práticas, foi algo novo

no desenvolvimento, logo que, os conceitos relacionados à serviço sempre estavam atrelados

aos fatores mais técnicos da codificação em si, como por exemplo, o emprego de ESBs.

Os relatos acima foram observados e registrados durante o projeto. Este trouxe como

maior resultado a detecção de uma falha no planejamento, falha que resultou na criação da

variável independente número 2 (dois) sobre a habilidade da equipe em desenvovler e

entender as aplciações WEB como SM’s. Ainda sobre os ajustes efetuados após este projeto

piloto, deve-se relatar que todas as práticas foram seguidas, mas, houve a percepção da

ausência de uma recomendação. Assim, uma prática foi adicionada, a mesma é identificada

como prática 10 e faz referência ao uso de NoSQL.

Ao final da execução deste projeto, foi possível notar que o uso de práticas como a de

SM’s foi algo inédito para o desenvolvimento, entretanto, a adoção da AR foi mais proveitosa

em relação às práticas, pois estas não agregaram um ganho significativo para a modelagem da

SM. Isto pode ser explicado pelo fato do desenvolvedor ter um grande conhecimento sobre as

tecnologias que podem ser empregadas sobre as SM’s.

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

6.4.2.1. Preparação

No sistema de prontuário eletrônico de um paciente, ou simplesmente MVPEP, se

encontra o Editor de formulário/telas. O Editor é responsável por criar ou desenvolver

funcionalidades que não são supridas pelo MVPEP, ou seja, o Editor desenvolve telas, ou

133


pequenos programas de software que aceitam entrada de dados, fazem um determinado

processamento, e apresentam um resultado satisfatório ao usuário.

A equipe responsável pela implementação do Editor é composta por 4 (quatro)

pessoas, um analista de sistemas, um arquiteto, e 2 (dois) programadores. A MV determinou

um período de tempo pequeno para desenvolver o Editor, sendo que o início do projeto foi em

setembro de 2011. As entregas do Editor deveriam ser mensais, mesmo porque a equipe de

testes da empresa recebe uma build a cada mês, montando um o relatório de erros encontrados

nos componentes entregues. O mesmo é repassado aos gestores. Dentro deste prazo, a

primeira fase do projeto deveria ser entregue em dezembro de 2011.

Neste momento, os parâmentros eleitos na variável alternativa foram registrados em

um formulário próprio para que os valores fossem pontuados nos mesmos. Para melhor

entendimento dos motivos pelos quais o Editor é considerado uma Máquina Social, fator

relevante para a seleção do projeto como estudo de caso, será apresentado a seguir algumas

poucas funcionalidades do Editor.

Com o Editor, é possível que os profissionais de TI do hospital, clínica ou UPA

possam construir uma tela com vários recursos, desde cálculos, comparações de dados,

respostas automáticas de questionamentos, tabelas e marcação de imagem (onde se marca na

própria imagem a parte afetada em um trauma corporal). Além disto, o Editor pode apenas

montar layout de formulários, trazendo para uma página todos os componentes já criados por

outras funcionalidades do sistema que abriga o Editor.

O Editor é altamente interoperável, pois não é apenas ao MVPEP que o Editor

precisa estar interligado, ele ainda necessita ser inserido em outro grande sistema da MV, o

MVSOUL. Neste, o Editor formata os relatórios e formulários que exibem os dados de

exames de imagem e de laboratório. A figura 24 demonstra a área de trabalho do Editor. Nele

o usuário desempenha todas as funções necessárias para criar documentos ou telas.

134


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

A Figura 25 o Editor é exibido na sua forma de utilização final, ela representa uma

tela com formulário a ser preenchido pelo usuáiro final na utilização do Editor pelo MVPEP.

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

135


6.4.2.2. Execução

A MV iniciou o desenvolvimento do Editor com a análise do negócio e

desenvolvimento dos requisitos. Após o término da fase de requisitos, coube ao arquiteto

desenvolver o projeto arquitetural seguindo um processo para definição da arquitetura que

consistia em analisar os requisitos e propor soluções que satisfizessem os mesmos. O

diagrama de casos de uso e o diagrama de classes foram modelados. Todas as tecnologias

selecionadas nesta fase já haviam sido empregradas em outros projetos da empresa. Ao final

da fase de projeto, com o uso da metodologia tradicional da empresa foi registrado os valores

dos parâmetros avaliados nas hipóteses alternativas.

Após a finalização das etapas iniciais do projeto de desenvolvimento, levou-se algum

tempo até que a confecção de alguns módulos do Editor começasse. Três grandes

funcionalidades foram implementadas: a funcionalidade de integração do editor com os

demais sistemas, a funcionalidade de escrita e edição de texto, e a funcionalidade de criação

de perguntas. Essas 3 (três) funcionalidades fazem com que o Editor seja utilizado pelo seu

usuário final perfeitamente, É claro que as demais funcionalidades que são recursos

adicionais, como por exemplo criação de tabela, devem ser futuramente inseridas.

Todos os resultados deste momento do estudo, com a primeira rodade de

experimentação sem o uso das práticas e AR foram registrados. No apêndice C é possível

verificar o formulário onde os valores dos parâmetros foram apontados.

O desenvolvimento do editor foi paralisado logo na primeira avaliação do cliente,

pois verificou-se não conformidades aos requisitos, principalmente no requisito não funcional

desempenho. Os desenvolvedores da equipe passaram a se empenhar em outras demandas de

desenvolvimento e o arquiteto do Editor iniciou novamente seu trabalho de projeto

arquitetural, desta vez seguindo as orientações das práticas e AR proposta.

Exatamente as mesmas funcionalidades foram desenvolvidas tanto na definição

arquitetural sem uso das práticas e AR, como com o uso destas. A equipe também prevaleceu

a mesma, bem como, os prazos. Na verdade, como houve desaprovação de funcionalidades,

de performance e interoperabilidade, o cliente aproveitou o ensejo e solicitou pequenas

alterações nos requsitos. Foi solicitada nova análise dos problemas e modelagem, o que

possibilitou a experimentação do objeto proposta neste trabalho sem demais problemas.

A experimentação executada com o uso das práticas e AR teve todos os resultados

expostos em um documento em anexo. Nesta seção, será inserido apenas a forma pela qual

houve a adoção da metodologia e os resultados obtidos. Desta maneira, na fase de projeto 136


arquitetural, a arquitetura de referência foi visualizada e compreendida. Em seguida, houve

um esboço da arquitetura Editor_Core, a arquitetura do Editor, que foi amadurecendo ao

passo que as práticas e AR foram compreendidas e atendidas. É importante frisar que

alterações em requisitos não caracterizaram uma alteração brusca do que já havia sido

analisado anteriormente, as alterações foram sutis, mas poderiam estender a arquitetura.

6.4.2.3. Resultados Obtidos

Tanto o arquiteto quanto a equipe responsável pelo desenvolvimento do Editor

estavam mais estressados no momento de refazer a arquitetura e experimentar as práticas e

AR de SM’s. A preocupação foi uma ameaça prevista, pois poderia atrapalhar a averiguação

das variáveis, uma vez que conduziria a equipe a um cuidado maior na segunda rodada de

experimentação com a metodologia de SM’s, fazendo os resultados da mesma sofrerem

influência. De fato todos estavam mais seguros quanto aos requisitos e aos problemas da

aplicação; isto pode ser uma desvantagem para o objeto de controle; mas pode também ser um

forte indício de sua feliz aplicabilidade, sendo que, mesmo a equipe estando com um nível de

estresse mais elevado, foi possível que uma arquitetura mais adequada fosse definida.

O Editor é uma Máquina Social completa e repleta de particularidades que podem

não se repetir em outras SM’s. Mesmo assim, ele é uma SM por ser uma palicação Web que

pode ser incorporada à outra aplicação com a finalidade de suprir alguma funcionalidade não

existente na mesma. Por exemplo: o Editor se incorpora ao sistema de Prontuário de Pacientes

com a finalidade de produzir telas com entrada, processamento, e saída de dados. Ou seja,

funcionalidades não existentes no PEP, como o cálculo e armazenamento da massa corporal

de um paciente.

Mais importante do que construir uma SM por meio das práticas e da arquitetura de

referência foi a experiência e o entendimento dos conceitos das Máquinas Sociais. Os

participantes demonstraram a necessidade de conhecer esses conceitos para que as práticas

fossem aceitas e fizessem sentido.

Foi possível registrar que o entendimento da arquitetura de referência fez a equipe do

Editor notar a forte necessidade de se ter uma camada Wrapper dedicada apenas aos serviços

providos e requeridos. Tal camada deveria ter componentes dedicados a cada sistema no qual

o Editor deveria interagir. Alem disto, na MV não existia a prática de formular um documento

137


de decisão arquitetural no qual a arquitetura seria baseada, isto certamente ocasionava alguns

retrabalhos em determinada fase do desenvolvimento, o que não houve com a adoção das

práticas e da arquitetura de referência.

Ainda por meio do acompanhamento direto do projeto Editor e também do

conhecimento a respeito de outros desenvolvimentos na MV, foi possível fazer uma análise e

notar o que foi obtido por meio da adoção das propostas para concepção de arquiteturas para

SM’s:

Visualizar facilmente a importância de se escrever as decisões de projeto. Na

verdade, as decisões do projeto Editor foram geradas pelas práticas das SM’s em si;

Verificar a necessidade da modelagem de negócio, pois esta fase é geralmente

omitida em alguns projetos de software da MV. Deste modo, a definição de como

alguns serviços seriam providos foi deficitária, obrigando a equipe a modelar alguns

processos de negócio;

Os problemas de integração entre Editor, MVPEP e o MVSOUL foram

descobertos no momento da análise arquitetural, e não no momento da integração,

como ocorreu quando não foram utilizadas as práticas e AR; as práticas 343, 544 e 745

contribuíram fortemente para isto;

Os padrões de projeto mais adequados às SM’s foram estudados. Apesar da

equipe responsável ter grande experiência com Design Pattern, os padrões foram

classificados com a prática 9, proporcionando uma adoção mais rápida, e

demonstrando muita eficiência para o Editor, como o caso do padrão Adapter;

A fase de definição de arquitetura foi desenvolvida resultando em uma

documentação útil à manutenção do Editor, sem, no entanto, ter levado muito tempo

para ser completada;

As facilidades que Cloud Computing poderiam trazer ao desenvolvimento do

Editor foram notadas. Entretanto, para a MV, os recursos de CC ainda é algo fora da

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

138


realidade. No entanto, houve o entusiasmo por parte da equipe e mesmo de alguns

gestores em conhecer mais os benefícios dos recursos Cloud;

A equipe de desenvolvimento pôde conhecer mais dois produtos da MV de

extrema relevância que é o MVSOUL e o MVPEP. Além disto, puderam verificar

que questões relevantes para as SM’s não são devidamente tratadas nesses sistemas,

como exemplo: a disponibilidade. Isto já preparou melhor a equipe para futuros

problemas. As primeiras práticas, sobre serviço, ajudaram fortemente neste avanço;

O trabalho de definição de interface e design gráfico para o Editor foi preciso,

pois as informações adquiridas dos serviços providos e da integração com os

sistemas puderam contribuir para que os designers descobrissem os problemas de

usabilidade que poderiam surgir;

As demais ameaças previstas infelizmente ocoreram. Como explorado na execução,

as práticas e AR de SM’s foram experimentadas em desenvolvimentos que ocorreram após o

desenvolvimento dos módulos sem as práticas e AR (sem alterações). Com isto, por falta de

tempo, de pessoas, e até mesmo por uma evolução do conhecimento a respeito de como

proceder o estudo, não foi possível dividir a equipe e executar simultaneamente a modelagem

da arquitetura com o objeto de controle e sem o objeto de controle. Assim, a equipe já estaria

mais preparada para o problema de software a enfrentar; mas, isso não inviabilizou o estudo,

uma vez que as exigências foram maiores em virtude do descontentamento da primeira

arquitetura, além disto, alguns requisitos foram alterados e eram desconhecidos pela equipe.

Devido às ameaças, infelizmente algumas práticas não puderam ser aproveitadas. A

adoção do Framework de SM’s, por exemplo, não foi possível por não haver tempo hábil para

desenvolvê-lo. No entanto, houve a percepção por parte de toda equipe, que tal recurso seria

interessante. Inclusive as práticas construíram um roteiro no qual a equipe de

desenvolvimento não tinha visibilidade, pois as demandas de desenvolvimento são muitas,

além de serem complexas e de curto prazo, prejudicando por vezes o desenvolvimento

organizado.

Apesar das ameaças, as práticas guiaram a equipe a focar em pontos chaves para o

desenvolvimento eficaz da Máquina Social, pontos que nem sempre foram tratados pela

própria empresa. As práticas 5 e 7 são exemplos disto. Por meio da aplicação do objeto de

controle foi possível que a equipe visualizasse o projeto Editor como de fato um projeto de

139


Máquina Social por todos os aspectos da aplicação, sobretudo, a comunicação e

adaptabilidade aos sistemas da MV.

Outro ponto que também é negligenciado e que foi visualizado e compreendido pela

equipe foram as regras de negócio, em que a primeira prática solicita a modelagem de alguns

processos que atenderam aos serviços. A MV não pensa em serviços na hora de construir suas

aplicações, assim, a modelagem do negócio geralmente era afetada e gerava retrabalho. Para o

projeto Editor este erro não ocorreu. Entretanto, a MV ainda precisa estar atenta a todos os

outros projetos de desenvolvimento espalhados pelas equipes que compõem a fábrica. Sendo

assim, no último período do ano de 2011, a empresa constituiu uma equipe de analistas de

negócios e gerentes de produtos justamente pensando em melhorar a concepção de seus

serviços. O experimento contribuiu fortemente para este pensamento.

Duas outras ações que podem ofertar grande potencial ao desenvolvimento da MV

surgiram por meio deste experimento com o Editor: a melhoria no processo de gerência de

configuração com a adoção da ferramenta Maven46; e o estudo de plataformas como o Open

Services Gateway Initiative - OSGi que contribui para o desenvolvimento de aplicativos

modulares e orientados a serviços (OSGi ALLIANCE, 2005 ).

Muitas ações ainda podem ser geridas para ajudar o trabalho da MV. A utilização das

práticas e da AR auxiliou a equipe do Editor e motivou a MV a utilizar mais vezes tal objeto

em Máquinas Sociais que possam fazer parte do nicho de negócio da empresa. Além disto,

este estudo mostrou a este trabalho de arquitetura e SM’s, como alguns assuntos ainda são

pouco explorados na realidade da indústria de software local. Uma evidência disto foi

revelada pela prática 8.

A prática 8 sobre Cloud Computing mostrou a realidade não só da MV, mas talvez de

muitas outras empresas e fábricas de software em relação à CC. Na MV, são poucos os

profissionais habilitados a trabalhar com Cloud Computing. Além disto, a empresa não tem

nenhuma ação ou planejamento para empregar tal paradigma nos projetos atuais e futuros do

portfólio da empresa.

Por fim, o caso Editor agregou muito conhecimento à equipe responsável, mostrando

indícios de que o projeto é longo e muito ainda deve ser feito para que o Editor seja uma

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

140


Máquina Social excelente; os problemas apresentados ao final do experimento com as práticas

e AR de SM’s foram no requisito de usabilidade. No entanto, tal SM se saiu bem nas etapas

de teste de software e validação do produto entre os clientes. Uma primeira versão do produto

já será homologada em meados de maio de 2012.


A real contribuição e utilidade da proposta deste trabalho para SM’s é proporcional

ao nível de conhecimento que um desenvolvedor de software tem sobre o conceito de SM’s.

Neste momento, não basta conhecer a teoria e compreender as características de SM’s, mas

sim, amadurecer tal paradigma de forma que seja possível entender aplicações Web como

Máquina Social para proceder a sua construção acima dos conceitos de SM’s.

O estudo de caso foi sobre uma equipe atrelada a métodos já tradicionais de

desenvolvimento e tecnologias impostas pela própria empresa, onde esses profissionais estão

familiarizados aos recursos disponíveis. O projeto piloto foi aplicado sobre o

desenvolvimento de um só profissional repleto de novas idéias que circulam o conceito de

Máquina Social, conceito ao qual esse profissional já está habituado.

Ficou nítida a contribuição das práticas no estudo de caso, dos 7 (sete) problemas

detalhadamente pontuados na problemática desta pesquisa, foram resolvidos 5 (cinco) para o

Editor da MV. Além disto, através do experimento um número significativo de idéias

surgiram dentro da empresa. Os seguintes problemas dentro do projeto Editor foram

resolvidos por meio do uso das práticas e da arquitetura:

Interoperabilidade e depedência entre os serviços das SM;

Manutenções demoradas;

Requisitos mal trabalhados;

Ausência da arquitetura;

Falta de adequação da SM na resolução de problemas.

Esta experimentação fez com que a equipe da MV enxergasse o produto Editor de

formulários/telas como uma verdadeira plataforma de serviços pronta para ser transplantada

entre os grandes e complexos sistemas da empresa, neste contexto, as práticas e arquitetura de

141


referência, em seu conjunto de conceitos, revelou sua real contribuição. Demais considerações

sobre este experimento serão publicadas na conclusão do trabalho que vem em seguida.

142

Capítulo

7

7. Conclusões e Trabalhos

FuturosO objetivo de tal capítulo é apresentar um desfecho sobre a

dissertação como um todo. Vale ressaltar que muitas considerações já

foram abordadas nos tópicos conclusivos de cada capítulo. Aqui estarão

algumas reflexões finais sobre o trabalho, especialmente a sua

contribuição, e as indicações dos futuros trabalhos.

143

Capítulo 7. Conclusões e Trabalhos Futuros

Ao fim dessa pesquisa, muitas questões se destacam e serão pontuadas no decorrer

desta consideração final.

Primeiramente a abordagem de conceber aplicações WEB como SM se mostrou

adequada por dois motivos: primeiro, possibilitar que dois desenvolvimentos de SM’s

focassem em pontos fundamentais para as SM’s, pontos que nem sempre possuíam a devida

atenção. Segundo por esclarecer que, através de SM’s, seja possível reinventar projetos em

rede, possibilitando que outros serviços sejam criados e problemas antigos sejam tratados.

Para exemplificar esta idéia, vale tomar nota do web site chamado “Empresa Teia47”, um

projeto puramente brasileiro coordenado por Oswaldo Oliveira, o qual classifica a Empresa

Teia48 como:

A empresa teia é uma infraestrutura completa para quem quer

desenvolver um projeto em rede. Tem como missão oferecer soluções que

viabilizem a evolução sustentável de quem quer articular, fazer negócios ou

trabalhar em rede. Conecta pessoas, instituições e empresas que querem se integrar

nos fluxos da sociedade em rede independentemente do nível de maturidade em que

estão. Faz isto utilizando ferramentas, serviços, processos, ambientes e conexões

disponíveis na nuvem computacional da internet.

A Empresa Teia conecta as pessoas de modo que elas possam prestar serviços

concomitantemente utilizando a Web 2.0 e 3.0 para isto. Este projeto já mostrou a sua força,

principalmente no momento em que o Estado de Minas Gerais resolveu contratar49 a Empresa

Teia para estruturar um ambiente em rede que pudesse auxiliar o desenvolvimento sustentável

do Estado, levando, por meio da Internet, serviços às áreas remotas da circunscrição.

Neste ponto, o projeto Teia, além de inovador, materializa o negócio que envolve as

Máquinas Sociais; a própria página online do projeto Teia é uma SM. Através dela é possível

disponibilizar App’s úteis à pessoas ou empresas que façam parte da rede Teia. Isto é,

promover o negócio de SM. Portanto, cabe aqui concluirmos que as abordagens tecnológicas

de SM’s talvez não sejam tão inovadoras, o que é moderno é a forma de se pensar e usar tal

aparato tecnológico para serviços que podem ser distribuídos em rede. A partir desse ângulo,

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

141


esta dissertação se mostra totalmente relevante, especialmente por focar em adaptações no

modo de usar a tecnologia para se construir Máquinas Sociais para assim poder promover

negócios modernos e lucratios.

É clarividente que há muito para se evoluir no conceito de SM’s, sobretudo, nos

aspectos voltados à Cloud Computing e nas questões de segurança, tanto das SM, quanto das

informações geradas por elas. Outro ponto importante é a manutenção das SM’s, que não

deve ser burocratizada. Para atender a este requisito o uso de Cloud Computing é fortemente

indicado na concepção das SM’s. Porém todos os profissionais envolvidos devem entender

melhor o que é CC.

Quanto à segurança, Máquinas Sociais são aplicações distribuídas em rede. O acesso

a elas deve ser facilitado. Por esse motivo e outros, a segurança continua sendo um ponto a ser

vigorosamente pesquisado e trabalhado. Um exemplo disto pode ser detectado no estudo de

caso da empresa MV, onde surge a preocupação no compartilhamento de documentos e,

mormente no conteúdo que leva cada documento, vez que alguns trabalham com informações

confidenciais e delicadas a um paciente.

O parágrafo supra remete aos trabalhos futuros; nestas concepções futuras há espaço

para experimentar em mais projetos as soluções propostas. Vale salientar que, para esta

pesquisa, houve certa dificuldade em se encontrar projetos de SM que se pudesse acompanhar

a evolução. Com mais estudos de caso será possível verificar pontos que possam ser

amadurecidos na metodologia e no próprio conceito de SM, mais do que isto, será possível

divulgar e empregar fortemente o Framework de SM. Realisticamente o framework requer um

trabalho forte de implementação e documentação, possibilitando assim, a disseminação do uso

do mesmo.

Disseminar as práticas em trabalhos futuros poderá também revelar outros benefícios

em desenvolvimento de SM. Nesta dissertação as práticas se revelaram como forte

contribuição para a resolução de alguns problemas já citados, e principalmente para agregar

qualidade ao processo de desenvolvimento. Neste ponto os valores revelados pelo

experimento não são tão importantes quanto os benefícios qualitativos que começaram a ser

pontuados na página 136. A viabilidade desta idéia pode inclusive consolidar a proposta da

arquitetura de referência.

142


Para a construção da arquitetura, os conceitos e exemplos de Máquina Sociais foram

detalhadamente enunciados em um capítulo. Houve certa dificuldade em se detalhar a

arquitetura, pois, o escopo de Máquinas Sociais teria que ser bem mais delimitado. Para a

arquitetura de referência, cabem outras pesquisas com mais tempo de desenvolvimento e

amadurecimento de conceitos de modo que seja possível vislumbrar um tipo de arquitetura

para cada tipo de Máquina Social, mediante, se possível, a taxonomia das mesmas. Apesar

desta necessidade, vale enfatizar que o estudo de caso deste trabalho aplicou bem a arquitetura

de referência proposta, adaptando a mesma. Para tal arquitetura, a avaliação por meio de

Checklist se mostrou eficiente e apta a ter seu modelo replicado em outros estudos.

A arquitetura de referência foi testada e concebida para atuar em SM’s que sejam

aplicações WEB. Foi possível acompanhar por meio da execução da avaliação da arquitetura

de SM’s como o método foi incrementado com a inserção de rodadas avaliativas, e com a

estratégia de repetir apenas um avaliador entre as rodadas.

O Checklist com os itens de questionamento que avaliaram diferentes aspectos da

arquitetura também foi customizado. Sua alteração foi necessária para que cada item estivesse

mais adequado ao que se desejaria avaliar da arquitetura. Deste modo, houve muito enfoque

nas questões de requisitos não funcionais por tratar-se de uma arquitetura de referência.

Entretanto, a customização do checklist já era algo tratado nas pesquisas utilizadas como

referência para este trabalho.

A interpretação dos itens de questionamento também foi uma novidade ao método, a

tabela 4 foi um instrumento para evitar as dúvidas dos avaliadores. É claro que a resposta

esperada para cada item não foi revelada, mais sim, o que cada item pretendia avaliar. Vale

esclarecer que a exclusão da contabilidade do item 4 (quatro) é algo absolutamente particular

do caso de uso exibido para o método. O item 4 (quatro) pode ser reescrito em outros

checklists, ou pode ser desconsiderado a partir do momento em outro item investigue a mesma

problemática ou aspecto na arquitetura

A outra avaliação ao qual esse trabalho foi submetido foi o estudo de caso. Ele

mostrou que é mais fácil pensar em SM quando se está vinculado totalmente ao conceito de

SM. A empresa que cedeu a unidade experimental percebeu o novo desenvolvimento de

aplicações que estava se instalando em sua fábrica. Contudo, cabe aqui mais uma vez

enfatizar que o processo de evolução dos negócios em rede está em uma interação ainda

143


primária para empresas tradicionais de TI extremamente amarradas a fatores, como: pressão

organizacional e política empresarial.

A experimentação auxiliou na identificação de problemas no conjunto de práticas,

problemas voltados à ausência de questões de banco de dados. Aproximar esse conjunto de

práticas aos padrões IEEE citados é outro trabalho que poderá ser amadurecido futuramente e

que não demanda muitos esforços.

O estudo experimental foi muito proveitoso, apesar de ser exploratório, onde não se

conhecia exatamente os efeitos do experimento, e também apesar das ameaças a validade

terem sido reais. O mais importante, e o que de fato valida o estudo, foi o mesmo ter tido um

planejamento e ser documentado no formato adequado; e principalmente pelo motivo da

empresa ter acreditado no experimento, e enxergar ganhos qualitativos com as práticas e

arquitetura propostas.

O experimento possibilitou a resolução de alguns problemas a partir do momento em

que auxiliou na identificação dos serviços, proporcionando melhorias na interoperabilidade, e

na manutenção das aplicações que deveriam ser interligadas. Entretanto fica a necessidade de

se replicar o experimento como trabalho futuro. Com isto, é possível aproveitar o

planejamento e formato do estudo, com todas as suas seções, em outros trabalhos.

Por fim, este trabalho amadurece todos os conceitos relacionados a SM,

particularmente os relacionados ao modelo de desenvolvimento de Máquinas Sociais. Sendo

assim, o objetivo foi alcançado ao passo que contribui para o desenvolvimento de ao menos

uma Máquina Social real, com idéias modernas, capazes de manter a evolução dos negócios,

proporcionando o amadurecimento na concepção de sistemas Web 3.0.

144

Referências Bilbiográficas

REFERÊNCIAS BIBLIOGRÁFICAS

ABINADER, Jorge; LINS, Rafael. Web Services em Java. 1.ed. São Paulo: Brasport, 2006. 316.p.

AFRAM, Abel. Twitter, uma arquitetura evoluindo. 2009. Disponível em: http://www.infoq.com/br/news/2009/07/Twitter-Architecture. Acesso em: 20. ago. 2010.

AMAZON PRODUCTS & SERVICES. Informações especializadas sobre o servico EC 2 da Amazon. Disponível em: http://aws.amazon.com/ec2/. Acesso em: 21 nov. 2011.

ARNOLD, Ken; O'SULLIVAN, Bryan; SCHEIFLER, Robert; WALDO, Jim; Wollrath, Ann. The Jini™ Specification. 1 ed. Addison-Wesley, 2009.

APIWIKI. Apresenta informações especializadas sobre o desenvolvimento de aplicativos por meio da plataforma Twitter. Disponível em: http://apiwiki.twitter.com/. Acesso em: 20. ago. 2010.

AZEEZ, Afkham; PERERA, Srinath; GAMAGE, Dimuthu; LINTON, Ruwan; SIRIWARDANA, Prabath; LEELARATNE, Dimuthu; WEERAWARANA, Sanjiva; FREMANTLE, Paul. Multi-Tenant SOA Middleware for Cloud Computing. 2010. In IEEE 3rd International Conference on Cloud Computing. Disponível em: http://www.computer.org/portal/web/csdl/doi/10.1109/CLOUD.2010.50. Acesso em: 12 dez. 2010.

BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software Architecture in Practice. 2ª ed. USA: Addison-Wesley, 2003.

BERNERS-LEE, Tim; HENDLER, James; LASSILA, Ora. The semantic Web. 2001. Scienti_c American, pages 35{43. Disponível em: < http://www.sims.monash.edu.au/subjects/ims2603/resources/week9/9.1.pdf>. Acesso em 10 jul. 2011.

BENSLIMANE, Djamal; DUSTDAR, Schahram; SHETH, Amit. Services Mashups: The New Generation of Web Applications. 2008. In Internet Computing, IEEE. Disponível em: < http://dl.acm.org/citation.cfm?id=1439253>. Acesso em: 01 mai. 2011.

BOEHM, Barry; BASILI, Vic. Software Defect Reduction Top 10 List, IEEE Computer , v. 34, n.1, pp. 135-137, 2001

BOYD, Danah; ELLISON, Nicole. Social Network Sites: Definition, History, and Scholarship. 2007. In Journal of Computer-Mediated Communication. Disponível em: < http://onlinelibrary.wiley.com/doi/10.1111/j.1083-6101.2007.00393.x/full> Acesso em: 01 mai. 2011.

BEHRENDT, Michael; GLASNER, Bernard; KOPP, Petra; DIECKMANN, Robert; BREITER; Stefan; KREGER, Heather; ARSANJANI; Ali. IBM Cloud Computing Reference Architecture 2.0, 2011. In: IBM 2011. Disponível em: < https://www.ibm.com/developerworks/mydeveloperworks/blogs/CLLotusLive/entry/ibm_cloud_computing_reference_architecture_what_is_in_for_me29?lang=pt_br>. Acesso em: 10 fev. 2011.

BEZEMER, Paul; ZAIDMAN, Andy. Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare?, 2010. In IWPSE - EVOL. Disponível em: < http://www.st.ewi.tudelft.nl/~zaidman/publications/bezemerIWPSE2010.pdf> Acesso em: 09 jan. 2011.

BELL, M. Modelagem Orientada ao Serviço. 1. ed. Rio de Janeiro: Alta Books, 2008. 384 p.

141

http://www.st.ewi.tudelft.nl/~zaidman/publications/bezemerIWPSE2010.pdf

https://www.ibm.com/developerworks/mydeveloperworks/blogs/CLLotusLive/entry/ibm_cloud_computing_reference_architecture_what_is_in_for_me29?lang=pt_br

https://www.ibm.com/developerworks/mydeveloperworks/blogs/CLLotusLive/entry/ibm_cloud_computing_reference_architecture_what_is_in_for_me29?lang=pt_br

http://dl.acm.org/citation.cfm?id=1439253


http://www.sims.monash.edu.au/subjects/ims2603/resources/week9/9.1.pdf

http://www.computer.org/portal/web/csdl/doi/10.1109/CLOUD.2010.50


http://www.infoq.com/br/news/2009/07/Twitter-Architecture


BUDGEN, David; TURNER, Mark; BRERETON, Pearl; KITCHENHAM, Barbara.Using Mapping Studies in Software Engineering, 2008. In Proceedings of PPIG 2008, Lancaster University, pp. 195-204. Disponível em: < http://www.ppig.org/papers/20th-budgen.pdf>. Acesso em: 11 nov. 2010.

BUSCHMANN, Frank; MEUNIER, Regine; ROHNERT Hans; SOMMERLAD, Peter; STAL, Michael. Pattern Oriented Software Architecture. 1 ed. USA: John Wiley & Sons Ltda, 1996.BOURKE, Tony. Server Load Balancing, 1 ed: O’Reilly, 2001. 192 p.

BEGINNING, Anderson. Flash, Flex, And Air Development For Mobile Devices. 1ed: Wrox Press, 2011. 336 p.

BOOCH, Grady; RUMBAUGN, James; JACOBSON, Ivar. UML Guia do Usuário. 2 ed. Rio de Janeiro: Editora Campus, 2005. 474p.

BREWER, Eric. Towards Robust Distributed Systems, 2000. In: Proc. of PODC, page 7.

COMSCORE. Apresenta pesquisas especializadas em assuntos tecnológicos. Disponível em: <http://www.comscore.com/por/.acesso> Acesso em: 28 set. 2010.CRAGGS, Steve. Best-of Breed ESBS, 2004. In: GLOBAL EAI SUMMIT, Disponível em: <http://www.sonicsoftware.com/products/whitepapers/docs/best_of_breed_esbs.pdf>. Acesso em: 12 nov. 2010

CHEESEMAN, John; DANIELS, John. UML Components: A Simple Process for Specifying Component-Based Software. 2ª ed: Addison-Wesley, 2001.

COMPUTERWORLD. Site com informações sobre o mercado de TI e comunicação. Disponível em: http://computerworld.uol.com.br. Acesso em: 21 nov. 2011.

CHODOROW, Kristina; DIROLF, Michael. Mongo DB: The Definitive Guide. 1 ed. Rio de Janeiro: O’Reilly, 2010.

DISTRIBUTED MANAGEMENT TASK FORCE – DMTF. Informações especializadas sobre padrões de interoperabilidade. Disponível em:< www.dmtf.org>. Acesso em 14 set. 2010.

ERL, Thomas. Service-Oriented Architecture: Concepts, Technology & Design. 2ª ed: Prentice Hall, 2005. p. 792.

EMPRESA TEIA. Possui informações sobre o projeto TEIA. Disponível em: http://empresateia.com.br/. Acesso em 01 set. 2011.

ENDREI, Mark; ANG, Jenny; ARSANJANi, Ali; CHUA, Sook; COMTE, Philippe; KROGDAHL, Pål; LOU, Min; NEWLING, Tony. Patterns: Service-Oriented Architecture and Web Services, 2004. In Redbooks-IBM.com. Disponível em:< http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf> Acesso em: 05 mar. 2010.

FACEBOOK DEVELOPERS. Apresenta informações sobre o desenvolvimento de Aplicações por meio do Facebook. Disponível em: <http://developers.facebook.com/>. Acesso em: 23 set. 2010.

FERREIRA, Kecia; BIGONHA, Mariza; BIGONHa, Roberto. Reestruturação de Software Dirigida por Conectividade para Redução de Custo de Manutenção. In: RITA, Volume XV, numero 2, 2008.

FORCE.COM. Guia do Programador da API de Serviços Web da Force.com . Possui informações sobre o desenvolvimento de aplicações na Force.com. Disponível em: http://www.salesforce.com/us/developer/docs/api/index.htm. Acesso em: 20 nov. 2011.

FORRESTER RESEARCH, INC. Empresa americana especializada em fazer pesquisas sobre Tecnologia da Informação, novas tendências ou descobertas. Disponível em: <http://www.forrester.com/rb/research/>. Acesso: 1 nov. 2011.

FREITAS, Fabricio; MAIA, Camila; COUTINHO, Daniel; CAMPOS, Gustavo; SOUZA, Jefferson. Aplicação de Metaheurísticas em Problemas da Engenharia de Software: Revisão de Literatura, 2009. No II Congresso

142

http://www.forrester.com/rb/research/

http://www.salesforce.com/us/developer/docs/api/index.htm

http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf

http://computerworld.uol.com.br/

http://www.comscore.com/por/.acesso

http://www.ppig.org/papers/20th-budgen.pdf


Tecnológico Infobrasil. Disponível em: < http://issuu.com/fabriciogf/docs/otimizacaoemengenhariadesoftware_surveypt> Acesso em: 11 abr. 2011.

GALBRAITH, Patrick. Developing Web Applications With Apache, Mysql, Memcached. 1ed: John wiley and Sons ltd. 2009.

GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos. 5ª ed. São Paulo: Bookman, 2000.

GORTON, Ian. Essential Software Architecture. 1ed. USA: Springe, 2006. 305 p.

GOVERNOR, James; HINCH, Cliffe; DION, Nickeull; DUANNE Nickull. Web 2.0 Architectures. 1 ed. O’Reilly. 2009. 274 p.

GARLAN, David; SHAW, Mary. An Introduction to Software Architecture, 1994. In CMU Software Engineering Institute Technical Report – CMU/SEI-94-TR-21. Disponível em: < http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf>. Acesso em: 02 nov. 2010.

GARTNER, INC. (NYSE: IT). Web Site da empresa especializada em serviços de tecnologia e pesquisa. Disponível em: http://www.gartner.com/technology/about.jsp. Acesso em: 09 out. 2011.

GOMES, Daniel. Web Services Soap em Java: guia pratico para o desenvolvimento de Web services em Java. 1.ed. Sã Paulo: NOVATEC, 2010. 184 p.

HARMAN, Mark; JONES, Bryan. Search-based software engineering, 2001. In Information and Software Technology 43, pp. 833-839. Disponível em: < http://www.inf.utfsm.cl/~mcriff/Paper-OR-SW/search-based-sw.pdf> Acesso em: 28 mar. 2011.

HOFF. Facebook: an example canonical architecture for scalang billions of messages. Disponível em: http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html. Acesso em 12 jun. 2011.

HOFMEISTER, Christine: NORD, Robert: SONI, Dilip. Applied Software Architecture. 2ªed. USA: Addison Wesley, 2000.

HORN, Paul. Autonomic Computing: IBM Perspective on the State of Information Technology, 2001. Disponível em <http://www.research.ibm.com/ autonomic/manifesto/ autonomic_computing.pdf>. Acesso em: 22 abr. 2011.

IBM. An Architectural Blueprint for Autonomic Computing, 2003. Technical report IBM. Disponível em: <http://www.research.ibm.com/ autonomic>. Acesso em 22 abr. 2011.

IEEE STD 1471-2000. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems. Sixth Edition.

INTERNET WORLD STATS. Apresenta informações especializadas sobre estatísticas e pesquisas feitas sobre a internet. Em: http://www.internetworldstats.com/stats.htm. Acesso: 01 ago. 2010

ISO/IEC 9126-1: 2000. Software engineering: Software product quality- Part 1: Quality Model.

ISO/IEC 9126-2: 2000. Software engineering: Software product quality - Part 2: External Metrics.

JACOBS, Dean. Enterprise software as service, 2005. In Queue, vol. 3, issue 6, p. 36. Disponível em: http://dl.acm.org/citation.cfm?id=1080875. Acesso em: 30 mar. 2011.

143


http://www.internetworldstats.com/stats.htm

http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html

http://www.inf.utfsm.cl/~mcriff/Paper-OR-SW/search-based-sw.pdf

http://www.inf.utfsm.cl/~mcriff/Paper-OR-SW/search-based-sw.pdf

http://www.gartner.com/technology/about.jsp.%20Acesso%20em:%2009

http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf

http://issuu.com/fabriciogf/docs/otimizacaoemengenhariadesoftware_surveypt


JSON. Informações especializadas sobre a ferramenta JSON. Disponível em: <http://www.json.org>/. Acesso em: 13 abr. 2011.

JOSUTTIS, Nicolai. SOA na Prática: A Arte da Modelagem de Sistemas Distribuídos. 1ed. Rio de Janeiro: Jacaré, 2007.

JURISTO. Natalia; MORENO, Ana. Basics of Software Engineering Experimentation. 2ª Ed. USA: Kluweer Academic Publishers, 2001.

JIANHONG, Z.; HUA, Chen (2010). Secuirty Storage in the Cloud Computing : A RSA-based Assumption Data Integrity Check without Original Data. In Conference ICEIT 2010.

LAITENBERGER, O; DEBAUD, Jean. Scenarios, Quality Attributes, and Patterns: Capturing andUsing their Synergistic Relationships for Product Line Architectures. 1998. Kaiserslautern, Germany, Fraunhofer Institute Experimental Software Engineering.

LARMAN, Craig. Utilizando UML e padrões: Uma introdução a análise e ao projeto orientados a objetos. 3ª.ed. Rio Grande do Sul: Bookman, 2007. 696 p.

LEAVITT, Ne. Will NoSQL Databases Live Up to Their Promise?. Computer, vol. 43, no. 2, pp. 12-14, Feb. 2010.

LOPES, Christian; FRANS, Max; KAZI, Farzana; DONALDSON, Sylva; MORRIS, Quaid; BADER, Gary. Cytoscape Web: an interactive web-based network browser. 2010. In Bioinformatics (2010). Volume: 26, Issue: 18, Publisher: Oxford University Press, Pages: 2347-2348. Disponível em: < http://bioinformatics.oxfordjournals.org/content/26/18/2347.short> Acesso em: 13 set. 2011.

LIU, Yan; LIANG, Xin; XU, Lingzhi; STAPLES, M; ZHU, Liming. Using Architecture Integration Patterns to Compose Enterprise Mashups, 2009. In:WICSA/ECSA. Disponível em:<http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F5275158%2F5290660%2F05290797.pdf%3Farnumber%3D5290797&authDecision=-203> Acesso em: 03 mar. 2011.

LIU, Sandy; LIANG, Yong; BROOKS, Martin. Eucalyptus: a Web service-enabled e infrastructure. 2007. In CASCON ’07: Proceedings of the 2007 conference of the center for advanced studies on Collaborative research. Disponível em: http://dl.acm.org/citation.cfm?doid=1321211.1321213. Acesso em: 10 jun. 2011.

LIN, Jimmy; DYER, Chris. Data-Intensive Text Processing with MapReduce, 2010. In Morgan & Claypool Publishers. Disponível em:< http://www.umiacs.umd.edu/~jimmylin/MapReduce-book-final.pdf>. Acesso em 09 jan. 2011.

LAI, Eric. No to SQL? Anti-database movement gains team, 2009. In Computerworld. Disponível em:<http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam>. Acesso em: 22 ago. 2011.

LAZZERI, João Carlos. Arquitetura Orientada a Serviços. 1. ed. Rio de Janeiro: Editora Moderna, 2009. 229 p.

LINTHICUM, David. Next Generation Application Integration: From Simple Information to Web Services.1 ed.USA: Pearson Education, 2004

MCPHERRON, Kate. Software-as-a-Service (SaaS): The New Paradigm for the Software Industry, 2008. Disponível em: <www1.sao.org/Resource_Center/newsletter_articles/200802/Kat_e_McPherron_Software_as_a_Service.php.> Acesso em: 01 jul. 2010.

MERRIL, Duane. Mashups: The new breed of web app, 2003. Disponível em:<

144

http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_

http://dl.acm.org/citation.cfm?doid=1321211.1321213

http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F5275158%2F5290660%2F05290797.pdf%3Farnumber%3D5290797&authDecision=-203

http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F5275158%2F5290660%2F05290797.pdf%3Farnumber%3D5290797&authDecision=-203

http://bioinformatics.oxfordjournals.org/content/26/18/2347.short


http://www.ibm.com/developerworks/web/library/x-mashups.html> Acesso em: 07 mai. 2011.

MEIRA, Silvio. Empresa “Teia”? Como assim?. Dia a dia. Bit a bit. Blog do professor Silvio Romero de Lemos Meira, 8 dez. 2010. Disponível em: http://smeira.blog.terra.com.br/2010/12/08/empresa-teia-como-assim-final/. Acesso em 07 dez. 2011.

MEIRA, S. R. L.; BUREGIO, V.; NASCIMENTO, L. M.; FIGUEIREDO, E. G. M.; NETO, M.; ENCARNAÇÃO, B.; GARCIA. The Emerging Web of Social Machines, 2011. IEEE 35th Annual Computer Software and Applications Conference (pp. 26-27). . Disponível em: < http://goo.gl/YcIB6>. Acesso em: 01 mar. 2011.

MELL, Peter; GRANCE, Tim. Draft NIST Working Definition of Cloud Computing. 2009. In National Institute of Standards and Technology. Disponível em:< http://csrc.nist.gov/groups/SNS/cloud-computing>. Acesso em: 17 ago. 2011.

MORAIS, EF; SOARES, MB. Web semântica para máquinas de busca. Disponível em:<http://homepages.dcc.ufmg.br/~nivio/cursos/pa03/seminarios/seminario7/seminario7.pdf>. Acesso em: 04 out. 2010.

MICROSOFT COMMUNITY BLOGS. Apresenta informações especializadas sobre a Microsoft. Em: http://blogs.msdn.com/b/nick_wong/archive/tags/event+announcements/. Acesso em: 30 ago. 2010.

MOTAHARI-NEZHAD, Hamid; STEPHENSON, Bryan; SINGHAL, Sharad. Outsourcing Business to Cloud Computing Services: Opportunities and Challenges, 2009. In HP Laboratories, HPL 23. Disponível em: < http://www.hpl.hp.com/techreports/2009/> Acesso em: 21 fev. 2011.

MCCANN, Julie; HUEBSCHER, Markus. Evaluation Issues in Autonomic Computing, 2004. In: Proceedings of Grid and Cooperative Computing Workshop, p. 597–608. Disponível em:< http://www.netlab.tkk.fi/opetus/s384030/k06/papers/EvaluationIssues.pdf> Acesso em: 27 jun. 2011.

MULLER, Gerrit. Systems Architecting: A Business Perspective. 2011. 1 ed. 243 p.

NAKAGAWA, E. Y. Uma Contribuição ao Projeto Arquitetural de Ambientes de Engenharia de Software. Tese de Doutorado, Instituto de Ciências Matemáticas e de Computação, ICMC-USP/SãoCarlos, 2006.NIST. Página da Agência governamental de administração da tecnologia. Disponível em:< http:// http://www.nist.gov/index.html>. Acesso em 19 set. 2011.

NETCRAFT.COM. Site que monta pesquisas e exibe estatísticas sobre a Internet e sobre aplicações em geral. Disponível em: <http://news.netcraft.com/> Acesso em: 14 nov. 2011

OBERHEIDE, Jon; COOKE, Evan; JAHANIAN, Farnam. (2008). Cloudav: N-version antivirus in the network cloud. 2008. In SS’08: Proceedings of the 17th conference on Security symposium. Disponível em <http://www.eecs.umich.edu/fjgroup/pubs/usenix08-cloudav.pdf>. Acesso em: 04 abr. 2011.

OFFICIAL GOOGLE BLOG. Contém informações especializadas sobre a Google Corporate em: http://www.google.com/intl/pt-BR/press/. Acesso 16 out de 2010.

O’REILLY, Tim. What is web 2.0, 2005. Disponível em:<http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html> Acesso em: 15 jun. 2010.

OSTENWALDER, Alexander; PIGNEUR, Yves; TUCCI, Christopher. Clarifying business models: origins, present, and future of the concept, 2005. In Communications of AIS, Volume 15, Article 1. Diponível em: http://www.softwarepublico.gov.br/5cqualibr/6-publicacoes-e-artigos/view/vetor-ecossistema/sobre-modelo-de-neg-cios/Claryfing-Busines-Model.pdf Acesso em 05 set. 2010.

OSGI ALLIANCE. OSGi Service Platform - Release 4. 2005. Disponível em: http://www.osgi.org/Main/HomePage. Acesso em: 06 mai. 2011.

145

http://www.osgi.org/Main/HomePage

http://www.softwarepublico.gov.br/5cqualibr/6-publicacoes-e-artigos/view/vetor-ecossistema/sobre-modelo-de-neg-cios/Claryfing-Busines-Model.pdf

http://www.softwarepublico.gov.br/5cqualibr/6-publicacoes-e-artigos/view/vetor-ecossistema/sobre-modelo-de-neg-cios/Claryfing-Busines-Model.pdf

http://www.eecs.umich.edu/fjgroup/pubs/usenix08-cloudav.pdf

http://news.netcraft.com/

http://www.nist.gov/index.html

http://www.netlab.tkk.fi/opetus/s384030/k06/papers/EvaluationIssues.pdf

http://www.hpl.hp.com/techreports/2009/

http://blogs.msdn.com/b/nick_wong/archive/tags/event+announcements/

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

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

http://www.ibm.com/developerworks/web/library/x-mashups.html


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

PETTICREW, M; ROBERTS, H. Systematic Reviews in the Social Sciences: A Practical Guide. 2ª ed. Blackwell Publishing, 2005.

PRESSMAN, Roger. Engenharia de Software: uma abordagem professional. 7ª ed. São Paulo: Bookman, 2011. 780 p.

PRESSMAN, Roger; LOWE, David. Web Engineering: A Practitioner's Approach. 1 ed. São Paulo: McGraw-Hill, 2008.

PASCOE, Geoffrey. Encapsulators: A new software paradigm in Smalltalk-80, 1986. In Object-Oriented Programming Systems, languages, and Applications Conference Proceedings, pagina 341-346. Disponível em: < http://dl.acm.org/citation.cfm?id=28731> Acesso em: 04 jun. 2011.

RAILS. Informações especializadas sobre a linguagem Rails. Disponível em: <http://www.rubyonrails.pro.br/> . Acesso em: 14 abr. 2011

REZENDE, Denis Alcides. Engenharia de software e sistemas de informação. 3ª ed. Rio de Janeiro: Brasport, 2005.

REZENDE, Denis. Tecnologia da Informação Aplicada a Sistemas de Informação Enpresariais: O Papel Estratégico da Informação e dos Sistemas de Informação nas Empresas. 4ª ed. São Paulo: Editora Atlas, 2006. 327.p

ROSEN, Micael; LUBLINSKY, Boris; SMITH, Kevin; BALCER, Marc. Applied SOA: service-oriented architecture and design strategies. 1ed: Wiley Publishing, Inc. Canada, 2008.

SHAW, Mary; GARLAN, David. Software Architecture – Perspectives on an Emerging Discipline. 1 ed. São Paulo: Prentice-Hall, 1996.

SOMMERVILLE, Ian. Engenharia de Software. 9ª ed. São Paulo: Pearson, 2011. 568 p.

SEVERINO. Antônio Joaquim. Metodologia do Trabalho Científico. 23ª Ed. São Paulo: Editora CORTEZ, 2008.

SONATYPE, Company. Maven: The definitive Guide. 1.ed: O’ Reilly, 2008.480 p.

STERRITT, Roy; BUSTARD, David. Autonomic Computing- A Means of Achieving Dependability?, 2003. In: Proceedings OF IEEE International Conference ON THE Engineering Of Computer Based Systems (ECBS’03), p. 247–251. Disponível em: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1194805. Acesso em: 21 abr. 2011.

STONEBRAKER , Michael; Joseph, HELLERSTEIN. Readings in Database Systems. 4ª ed: Morgan Kaufmann, 2005.

SARATHY Vijay; NARAYAN, Purnendu; MIKKILINENI, Rao. Next generation Cloud Computing Architecture: Enabling real-time dynamism for shared distributed physical infrastructure, 2010. In WETICE '10 Proceedings of the 2010 19th IEEE International. TANENBAUM, Andrew. Distributed Systems: Principles and Paradigms. 1 ed. PrenticeHall, 2002.

TANENBAUM, Andrew. Redes de Computadores. 4ª Ed. Rio de Janeiro: Editora Campus, 2003.

TAURION, Cesar. Cloud Computing: Coud Computing - Computaçao em Nuvem: Transformando o Mundo da Tecnologia. 1. Ed. Rio de Janeiro: Editora Brasport, 2009. 228 pg.

146

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1194805



TRAVASOS, Guilherme; GUROV, Dmytro; AMARAL, Edgar. Engenharia de Software Experimental. Relatório Técnico, Universidade Federal do Rio de Janeiro, 2002.

TITTEL, Ed. Xml. 1ed. São Paulo: Bookman Editora, 2003.

TIWARI, Shashank. Professional NoSQL. 1 ed. John Wiley & Sons, 2011.

VECCHIOLA, Cristian; CHU, Xingchen; BUYYA, Rajkumar. Aneka: A Software Platform for .NET-based Cloud Computing, 2009. In: W. Gentzsch, L. Grandinetti, G. Joubert (Eds.). High Speed and Large Scale Scientific Computing. IOS Press. Disponível em:< http://www.buyya.com/gridbus/reports/AnekaCloudPlatform2009.pdf> Acesso em: 22 mar. 2011.

ZHANG, Liang-Jie; ZHOU, Qun. CCOA: Cloud Computing Open Architecture, 2009. In IEEE International Conference on Web Services. Disponível em: http://www.cse.iitb.ac.in/~ashishpardhi/Papers/Cloud_computing/05175875.pdf. Acesso em: 01 set. 2010.

Workshops on Enabling Technologies: Infrastructures for Collaborative Enterprises. Disponível em: <http://www.kawaobjects.com/resources/PID1258479.pdf>. Acesso em: 09 mai. 2011.

WEISSMAN. Craig. The Force.com Multitenant Architecture Understanding the Design of Salesforce.com’s Internet Application Development Platform. In Salesforce com. 2010. Disponível em: <http://www.salesforce.com/au/assets/pdf/Force.com_Multitenancy_WP_101508.pdf?fmSearch=true>. Acesso em: 20 jun. 2010.

WEINHARDT, Christof; ANANDASIVAM, Arun; BLAU, Benjamin; BORISSOV, Nikolay; MEINL, Thomas; MICHALK, Wibke; STOBER, Jochen. Cloud Computing- a Classification, Business Models, and Research Directions, 2009. In Spring, 5 edition. Disponível em:< http://www.springerlink.com/content/w3h62858jpkw56kh/>. Acesso em: 20 dez. 2010.

WEI-TEK; Tsai; SUN, Xin; BALASOORIYA, Janaka. Service-Oriented Cloud Computing Architecture, 2010. In Seventh International Conference on Information Technology. Disponível em:< http://xml.ice.ntnu.edu.tw/JSPWiki/attach/Focusardi/Service-Oriented%20Cloud%20Computing%20Architecture.pdf>. Acesso em: 09 jan. 2011.

WAYNE, Jansen; TIMOTHY, Grance. Guidelines on Security and Privacy in Public Cloud Computing. NIST. Página da Agência governamental de administração da tecnologia. 11 de dezembro de 2011. Disponível em:< http:// http://www.nist.gov/index.html>. Acesso em 19 fev. 2012.

WHITE, Steve; HANSON, James; WHALLEY, Ian; CHESS, David; KEPHART, Jeffrey. Architectural Approach to Autonomic Computing, 2004. In: ICAC '04 Proceedings of the First International Conference on Autonomic Computing, p. 2–9, IEEE Computer Society. Disponível em: <http://www.netlab.tkk.fi/opetus/s384030/k06/papers/AnArchitectureApproachToAutonomicComputing.pdf> Acesso: 20 set. 2011.

KRUCHTEN, Philippe. The 4+1 View Model of architecture, 1995. In Software IEEE 12(6) 42–50. Disponível em: < http://dl.acm.org/citation.cfm?id=625529>. Acesso em: 20 out. 2010.

KITCHENHAM, Barbara; BRERETON, Pearl; BUDGEN, David; TURNER, Mark; BAILEY, John;

LINKMAN, Stephen. Systematic literature reviews in software engineering — a systematic literature review, 2009. In Information & Software Technology 51(1), 7–15. Disponível em:< http://dl.acm.org/citation.cfm?id=1466091> Acesso em: 18 abr. 2011.

KOSSMANN, Donald; KRASKA, Tim; LOESING, Simon. An Avaluation of Alternative Architectures for Transaction Processing in the Cloud (2010). In Conference SIGMOD 2010.

147



http://www.netlab.tkk.fi/opetus/s384030/k06/papers/AnArchitectureApproachToAutonomicComputing.pdf

http://www.nist.gov/index.html

http://xml.ice.ntnu.edu.tw/JSPWiki/attach/Focusardi/Service-Oriented%20Cloud%20Computing%20Architecture.pdf

http://xml.ice.ntnu.edu.tw/JSPWiki/attach/Focusardi/Service-Oriented%20Cloud%20Computing%20Architecture.pdf

http://www.springerlink.com/content/w3h62858jpkw56kh/

http://www.cse.iitb.ac.in/~ashishpardhi/Papers/Cloud_computing/05175875.pdf

http://www.buyya.com/gridbus/reports/AnekaCloudPlatform2009.pdf


KLEIN, Mark; KAZMAN, Rick. Attribute-Based Architectural Styles, 1999. In CMU/SEI-99-TR-022 ESC-TR-99-022 Software engineering institute. Disponível em: <http://sophia.javeriana.edu.co/~cbustaca/DSBP/lecturas/AttributeBased%20Architectural%20Styles.pdf>. Acesso em: 06 mar. 2010.

KALIN, Martin. Java Web Services: Implementando. 1ed. Rio de Janeiro: O’Reilly. 2010. 312 p.

KE, Xu; MEINA, Song; XIAOQI, Zhang; JUNDE, Song (2009). A cloud computing platform based on P2P. In conference ITIME 2009.

WOHLIN. Claes; RUNESON, Per; HOST, Martin; OHLSSON, Magnus; REGNELL, Bjorn; WESSLEN, Anders. Experimentatio in Software Engineering an Introduction. 2º Ed. USA: Kluweer Academic Publishers, 2002.

WEBBER, Jin; PARASTATIDIS, Savas; ROBINSON, Ian. REST in Practice: Hypermedia and Systems Architecture. 1 ed. Rio de Janeiro: O’Reilly, 2010. 448p.

148

http://sophia.javeriana.edu.co/~cbustaca/DSBP/lecturas/AttributeBased%20Architectural%20Styles.pdf

Anexos

ANEXOS

ANEXO 1. PRÁTICAS DO PROJETO EDITOR MVPEP

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

Prática 2: Reconhecer os serviços providos e requeridos para o funcionamento da

Máquina Social

1. Serviços Providos:a. Ajustar a aparência de documentos e telas;b. Disponibilizar modelos de documento e telas formatados para os clientes;c. Processar dados específicos de um segmento hospitalar.

2. Serviços Requeridos:a. Provimento de informações específicas para se utilizar um documento, assim, é

necessário saber se existe, e qual é, a prescrição médica que utilizará o documento;

b. Registro de laudos de exames.

Prática 3: Conhecer os provedores de serviço da aplicação

152

Anexos

Banco de dados Oracle que fornece os dados a serem processados pelo Editor, os dados estão registrados em tabelas diversas;

Sistema MVSOUL (tecnologia Java/Flex/Web Service) onde os laudos são registrados;

Sistema MVPEP por necessitar das informações da prescrição médica; Sistema MV2000, módulo PAGU, para resgatar informações de perguntas.

Prática 4: Verificar a necessidade de recursos que tornem a aplicação auto-gerenciável e

como esses recursos podem ser implementados

A MV para este projeto não desenvolveu nenhum recurso que possa prover o

autogerenciamento.

Prática 5: Determinar os recursos que implementarão os elementos States e Constraints:

No projeto Editor não ocorre a preocupação direta com tais elementos, mas algumas

ações contribuem diretamente para a visualização do estado do SM, bem como, a visualização

das características do mesmo, auxiliando na disponibilidade, e na comunicação. Tais iniciativas

são:

Utilizar Cluster de alta disponibilidade, viabilizados por meio de mecanismos de detecção e recuperação de falhas;

Construir uma segunda camada intermediária (core_flex_service) para prover a interoperabilidade, tal camada possui métodos (classes) específicas para customizar a aplicação no momento requerido, conforme o sistema que for utilizá-la;

Uso do padrão de projeto State; Implementar sensores na camada de persistência que dispara um time a toda solicitação

à base de dados, caso a resposta demore, é indício de que algo aconteceu aos repositórios, e o Editor se prepara para acessar possíveis backups.

Prática 6: Analisar se apenas o estilo arquitetural Camadas é suficiente

para atender a Máquina Social:

O estilo arquitetural Camadas será aplicado na arquitetura em conjunto a outros estilos

também empregados, entretanto, essa mescla só ocorreu na primeira camada da aplicação. Os

estilos adicionais são: Pipes and Filters e Publisher-subscriber.

153

Anexos

Prática 7: Determinar o recurso que proverá a comunicação e interoperabilidade

Web Services com REST para a comunicação com dispositivos móveis; Utilizar o recurso nativo do Adobe Flex, o AMF com auxílio do BlazeDS. O BlazeDS é

um servidor baseado em Java Remoting and Web Messaging, uma tecnologia que viabiliza a comunicação com o back-end distribuído de dados da aplicação. O BlazeDS pode ser utilizado com outras plataformas de cliente, como JavaScript e AJAX, ambas tecnologias exploradas pela MV.

Inserir duas camadas de comunicação na arquitetura, estas irão prover a interoperabilidade entre o Editor os sistemas;

Prática 8: Selecionar o recurso Cloud Computing a ser adotado na SM

A MV ainda não utiliza o paradigma Cloud Computing em seus projetos, pois falta

uma pesquisa adequada para verificar a viabilidade do uso deste novo paradigma na MV, bem

como, do custo de adotar Cloud.

Prática 9: Selecionar os padrões de projeto mais adequados para a arquitetura da

Máquina Social

Padrões mais utilizados:

1. Adapter: para adequar as interfaces de comunicação entre os sistemas;2. Observer: para a gerência dos estados entre os objetos;3. State e Singleton.

Prática 10: Selecionar o banco de dados não relacional

Não foi seguida ou executada

154

Anexos

ANEXO 2. PRÁTICAS DO PROJETO PILOTO HOBNOB

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

Tal diretriz não foi satisfeita para este projeto, o fluxo de negócio não foi algo

tratado na concepção e análise do HobNob, apesar de trabalhar com o conceito de

serviço o responsável pelo desenvolvimento desta SM optou por trabalhar questões

mais técnica e não tanto de negócio.

Prática 2: Reconhecer os serviços providos e requeridos para o

funcionamento da Máquina Social

1.Serviços Providos:c. Sugerir festas e eventos musicais pela cidade de recife;d. Classificar os eventos: classificar os mais procurados, e os mais

freqüentados.2.Serviços Requeridos:

e. Lista de amigos de rede social;f. Dados ou informações das pessoas;g. Links: o que foi acessado, procurado ou visualizado nas redes sociais,

e no Google Map.

Prática 3: Conhecer os provedores de serviço da aplicação

1. Facebook; 2. Google Map;3. Servidor de chat;4. Servidor de banco de dados.

Prática 4: Verificar a necessidade de recursos que tornem a aplicação

auto-gerenciável e como esses recursos podem ser implementados

Usar de forma inteligente alguns recursos e técnicas já populares na

engenharia de software, afim de, prover o autogerenciamento:

Usar o Framework de SM para obter tolerância a falhas; Aplicar boas práticas de programação; Configurar bem o Apache para obter controle de log, e controle de sessão em

banco de dados (segurança).

155

Anexos

Prática 5: Determinar os recursos que implementarão os elementos

States e Constraints:

Usar o Framework para Máquinas Sociais, com o uso será estabelecido

níveis de qualidade e estabilidade para os serviços, existem 5 níveis de estabilidade,

estes se baseiam no tempo de resposta de cada solicitação, entre outros parâmetros.

Prática 6: Analisar se apenas o estilo arquitetural Camadas é suficiente

para atender a Máquina Social:

Sim, apesar a arquitetura em camadas foi utilizada, houve uma customização

desta, além da inserção do Framework para Máquinas Sociais.

Prática 7: Determinar o recurso que proverá a comunicação e

interoperabilidade

WebServices com REST.; Adoção de Json.

Prática 8: Selecionar o recurso Cloud Computing a ser adotado na SM

Utilizar os serviços da PaaS Rackspace, como: backup, SO Linux,

balanceamento de carga, e armazenamento. Esta ofertou melhores opções em relação

ao valor cobrado, neste aspecto houve uma análise dos provedores de serviços CC para

detectar qual o de melhor relação custo/benefício.

Prática 9: Selecionar os padrões de projeto mais adequados para a

arquitetura da Máquina Social

Padrões mais utilizados:

State; Singleton; Facade.

156

Apêndices

APÊNDICES

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

IDENTIFICAÇÂO

Arquitetura a ser avaliada: Arquitetura de referência para Máquinas Sociais

Inspetor:

Visões a serem avaliadas: módulos, componentes e conectores, implantação

Nº Item de Questionamento SIM NÃO NÃO SE

APLICA

1 Ao analisar todos os diagramas, foi identificado algum elemento

arquitetural que não possua relacionamentos, ficando isolado

dos demais?

2 A descrição textual que compõe o documento está de acordo

com o que foi representado nos diferentes diagramas gráficos?

3 Para todos os componentes, em algum diagrama, foram

identificadas as classes ou sub-componentes que o compõem?

4 Os relacionamentos realizados entre classes/sub-componentes

alocados em “componentes pais” distintos foi definido como

uma dependência entre esses “componentes pais” em algum

outro diagrama?

5 As interfaces são disponibilizadas por um único

componente/classe, ou representadas de uma forma mais

simples não expandida?

6 Ao analisar todas as seqüências de execução descritas em uma

visão de interação, pode-se dizer que as classes/componentes

definidas em uma visão modular foram alocadas em ao menos

uma das seqüências?

157

Apêndices

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


10 Elementos relacionados possuem responsabilidades iguais que

possam ser alocadas em um único elemento?

11 Elementos intermediários (ex: máquina virtual, servidor de

nomes, repositórios, API’s) são utilizados como mediadores de

comunicação entre os elementos arquiteturais, diminuindo o

impacto das alterações realizadas em elementos que podem ser

modificáveis?

12 Foi verificado algum componente que exerca controle sobre o

comportamento de outro elemento?

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

IDENTIFICAÇÂO

Arquitetura a ser avaliada: Arquitetura de referência para Máquinas Sociais

Inspetor:

Visões a serem avaliadas: módulos, componentes e conectores, implantação

Observações ou considerações

Nº Item de Questionamento SIM NÃO NÃO SE

APLICA

158

Apêndices

1 Ao analisar todos os diagramas, foi identificado algum elemento

arquitetural que não possua relacionamentos, ficando isolado

dos demais?

2 A descrição textual que compõe o documento está de acordo

com o que foi representado nos diferentes diagramas gráficos?

3 Para os componentes, em algum diagrama, foram identificadas

as classes ou sub-componentes que o compõem?

4 Os relacionamentos realizados entre classes/sub-componentes

alocados em “componentes pais” distintos foi definido como

uma dependência entre esses “componentes pais” em algum

outro diagrama?

5 As interfaces são disponibilizadas por um único

componente/classe, ou representadas de uma forma mais

simples não expandida? Ou seja, ocorre uma representação por

meio de diagrama de classes ou de componentes e conectores

com interfaces requeridas e providas.

6 Ao analisar as seqüências de execução descritas em uma visão

de interação, pode-se dizer que as classes/componentes

definidas em uma visão modular foram alocadas em ao menos

uma das seqüências?

7 Os elementos arquiteturais têm a sua presença na arquitetura

justificada por um conjunto de requisitos não funcionais ou

funcionais?

8 As responsabilidades dos elementos arquiteturais estão

condizentes com os requisitos não funcionais que eles atendem?

9 Táticas arquiteturais foram empregadas para satisfazer os


10 Elementos relacionados possuem responsabilidades iguais que

possam ser alocadas em um único elemento?

11 Elementos intermediários como: máquinas virtuais, servidores

de nomes, repositórios e API’s; são utilizados como mediadores

159

Apêndices

de comunicação entre os elementos arquiteturais.

12 Foi verificado algum componente que exerca controle sobre o

comportamento de outro elemento?

COMENTÁRIOS:

DICAS:

Elementos arquiteturais devem ser entendidos como:

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

APÊNDICE C. VALORES MONITORADOS NO EXPERIMENTO

PARÂMENTROS COM METODOLOGIA

TRADICIONAL

COM METODOLOGIA DE SM

Número de requisitos da SM

trabalhados pela arquitetura.

4 7

Adequação da arquitetura

concebida por meio na metodologia

à Máquina Social.

2 4

OBS.

O quantitativo de 4 (quatro) é referente a todos os casos de testes que foram

contemplados, ou seja, foram feitos 4 (quatro) casos de teste, para todos os quatro o

resultado desejado foi atendido, assim, não houveram defeitos encontrados.

160

Apêndices

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

161

Apêndices

162

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

Documents

Transcript of PRÁTICAS PARA A ESPECIFICAÇÃO DE ARQUITETURAS DE SOFTWARES NO CONTEXTO DE MÁQUINAS SOCIAIS PARA...