Arquitetura para computação móvel [2 ed.] 9786550110581

Citation preview

---

ARQUITETURA PARA COMPUTAÇÃO MÓVEL J

2a edição

Pearson

BUP

EXATAS

QUER SEP MAIS LIVRE? Aprenda a Pesquisar e Fazer Ebooks | Armazene arquivos de forma segura

APRENDA A FAZER EBOOKS

HTTPS://ODYSEE.COM

Seja a partir de Livro ou PDF escaneado Construa PDF pesquisável ou Epub Qualidade Profissional

Plataforma descentralizada para Reprodução e Hospedagem de arquivos Garantida por BlockChain

Rápido e Eficiente

Prática como Youtube Descentralizada e resiliente como torrent Facilitadora de transações financeiras como Bitcoin

t.me/AnonLivros

Acervo em Português Mais de 70 mil ebooks no Telegram t.me/PolemicBooks Mais de 2 mil cursos em vídeo t.me/oAcervoCursos

HTTPS://LIBGEN.IS HTTPSy/Z-LIB.ORG Portais de Ebooks e artigos científicos Mais de 2 milhões de documentos

Cursos via streaming no Telegram t.me/LivreSaber

CONTRA A PROPRIEDADE INTELECTUAL A fundamentação Teórica em favor do Conhecimento Livre https://www.mises.org.br/Ebook.aspx?id=29

t.me/AnonLivros

Arquitetura para COMPUTAÇÃO MÓVEL

Arquitetura para COMPUTAÇÃO MÓVEL 2a edição

Organizadores Rafael Félix

Cientista de dados pelo Laboratório de Computação Natural da Universidade Presbiteriana Mackenzie - UPM Mestre em engenharia da computação pela UPM Bacharel em sistemas de informação pela Universidade Estadual de Montes Claros Everaldo Leme da Silva

Mestre em Sistemas de Informação e Comunicação pela Faculdade de Tecnologia da Unicamp Especialista em Engenharia de Software pela Unicamp MBA em Gerenciamento de Projetos com ênfase em TI pela FGV Bacharel em Análise de Sistemas pela Pontifícia Universidade Católica de Campinas - PUC

Pearson

am

Respeite c J'reito aujota’

© 2020 by Pearson Education do Brasil

Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de sistema de armazenamento e transmissão de informação, sem prévia autorização, por escrito, da Pearson Education do Brasil.

Gerente de produtos: Alexandre Mattioli Coordenador editorialize Xavier Editoras assistentes: Karina Ono e Mariana Rodrigues Redatores: Fernando Martins Minighiti e Luiz Fukushiro Editor: Casa de Idéias Capa: Natália Lopes Projeto gráfico e diagramação: Casa de Idéias Créditos das imagens das aberturas: (1) scyther5/iStockphoto; (2) spxChrome/iStockphoto; (3) ContentWorks/iStockphoto; e (4) mumininan/iStockphoto

Dados Internacionais de Catalogação na Publicação (CIP)

(Câmara Brasileira do Livro, SP, Brasil)

índice para catálogo sistemático:

2019 Direitos exclusivos cedidos à Pearson Education do Brasil Ltda., uma empresa do grupo Pearson Education Avenida Francisco Matarazzo, 1400 Torre Milano - 7'-’ e 81’ andares 05000-903 | Agua Branca | São Paulo-SP Telefone +55 (11) 4210-4450 www.pearson.com.br

UMÁRIO Apresentação.................................................................. VII Prefácio............................................................................ IX Unidade 1

Introdução à arquitetura de software...................... 1 Introdução à arquitetura de software.............................................. 3 Objetivos da arquitetura de software............................................. 3 Contextos da arquitetura de software............................................ 5 Requisitos arquiteturais....................................................................... 11 Dependabilidade.................................................................................. 12 Funcionalidade...................................................................................... 14 Interoperabilidade.............................................................................. 22 Escalabilidade....................................................................................... 27 Performance.......................................................................................... 35 Segurança.............................................................................................. 41 Usabilidade............................................................................................ 46

Unidade 2

Modelos e projetos arquitetônicos........................ 59 Padrões de projeto e arquitetura de software........................... 61 Estilos de arquitetura......................................................................... 61 Arquitetura baseada em componentes........................................ 85 Abordagem da arquitetura...............................................................85 Tendências arquitetônicas................................................................86 Princípios fundamentais de arquitetura...................................... 88

Unidade 3

Webservices e serviços................................................97 Arquitetura baseada em webservices.......................................... 100 XML......................................................................................................... 100 Processando o XML........................................................................... 114 Arquitetura orientada a serviços................................................... 119 Introdução e fundamentos da SOA............................................ 119 Modelos de serviços......................................................................... 122 Governança......................................................................................... 124

Unidade 4

Linguagens de descrição arquitetural (ADL)......................................................................... 135 Introdução às linguagens de descrição arquitetural (ADL)............................................................................ 137

VI

Arquitetura para computação móvel

Architecture description language (ADL).....................................137 Rapide.................................................................................................... 139 AADL...................................................................................................... 140 xADL....................................................................................................... 141 UML........................................................................................................ 142 Diagramas............................................................................................ 147

Referências.................................................................... 165 Respostas....................................................................... 167

Apresentação Nos catálogos dc livros universitários, há vários títulos cuja pri­ meira edição saiu há 40, 50 anos, ou mais. São livros que, graças à

identificação da edição na capa (c somente a ela), tem sua idade re­ velada. E, ao contrário do que muitos podem imaginar, isso não é um problema. Pelo contrário, são obras conhecidas, adotadas em diversas

instituições de ensino, usadas por estudantes dos mais diferentes per­ fis e reverenciadas pelo que representam para o ensino. Qual o segredo de sucesso desses livros? O que eles têm de

diferente de vários outros que, embora tenham tido boa aceita­ ção em um primeiro momento, não foram tão longe? Em poucas palavras, esses livros se adaptaram às novas realidades ao longo

do tempo, entendendo as mudanças pelas quais a sociedade - e, consequentemente, as pessoas - passava c as novas necessidades que se apresentavam.

Para que isso fique mais claro, vamos pensar no seguinte: a maneira como as pessoas aprendiam matemática na década dc

1990 é igual ao modo como elas aprendem hoje? Embora os ali­ cerces da disciplina permaneçam os mesmos, a resposta é: não!

Nesse intervalo de tempo, ocorreram mudanças significativas - a internet se consolidou, os celulares se popularizaram, as redes so­

ciais surgiram etc. E todas essas mudanças repercutiram no modo de vida das pessoas, que se tornou mais rápido e desafiador, trans­ formando os fundamentos do processo de ensino/aprendizagem.

Foi com base nisso que nasceu a Bibliografia Universitária Pearson (BUP). Concisos sem serem rasos e simples sem serem simplistas, os livros que compõem esta série são baseados na

premissa dc que, para atender sob medida às necessidades tan­ to dos alunos dc graduação como das instituições de ensino independentemente de eles estarem envolvidos com ensino presen­

cial ou a distância -, é preciso um processo amplo c flexível dc

construção do saber, que leve cm conta a realidade cm que vivemos.

VIII

Arquitetura para computação móvel

Assim, as obras apresentam de maneira clara os principais conceitos dos temas pro­ postos, trazendo exatamente aquilo que o estudante precisa saber, complementado com

aprofundamentos e discussões para reflexão. Além disso, possuem uma estrutura didá­ tica que propõe uma dinâmica única, que convida o leitor a levar para seu dia a dia os

aspectos teóricos apresentados. Veja como isso funciona na prática: Neste novo projeto, além da revisão de conteúdo, também foram criadas algumas novas seções para guiar o aluno a uma reflexão prática sobre os conceitos. A seção “Es­

tudo de caso” simula situações de tomada de decisão e oferece aos alunos ferramentas

para solucionar um conflito apresentado. Já a seção “Na mídia” permite que o estudante veja como a teoria é aplicada em situações reais. Por fim, a seção “Na academia” traz

propostas de atividades ou projetos que incentivam o estudante a aprofundar seus conhe­

cimentos por meio da prática da pesquisa.

Na mídia

Estudo de caso Alegria, estresse, raiva: Amazon desen para reconhecer emoçô Considere o seguinte cenário para um negócio

O assistente financeira apos aprovação, efe­

A Amazon está doumvolvendo um dispositivo

anonlmato |

para reembolso de despesas em uma empresa:

tua o depósito na conta do funcionário

inteligente ativado por voz que pode reconhe­

na Um prog

O funcionário solicita um valor de adianta

Apôs a viagem o funcionário deve prestar

cer as emoções de seres humanos. 0 aparelho

mento, disse

mento para efetuar uma viagem a serviço da

contas apresentando todos os recebidos de

de pulsoé descrito como um produtode saúde

se o teste Ir

empresa. A viagem pode ser para reunião,

pagamento. Todos os gerentes e assistente

e bem esUr em documentos Internos anallsa-

soltware de

congresso ou curso.

tambãm são funcionários da empresa.

0 valor do adiantamento ó autorizado pelo

Caso o valor gasto soja maior que o adiantado,

Ao longo do livro, o leitor pode encontrar vários

hipertextos. Classificados como “Para saber!”, “Para ler!”, “Para conhecer!”, “Para assistir!”, “Na web” e PARA ASSISTIR!

“Na prática”, esses hipertextos permitem ao aluno ir além em suas pesquisas, oferecendo-lhe amplas pos­ NA PRÁTICA

sibilidades de aprofundamento. A linguagem dialógica aproxima o estudante dos temas abordados, eliminando qualquer obstáculo

para seu entendimento e incentivando o estudo. A diagramação contribui para que o estudante registre idéias e faça anotações, interagindo com o

conteúdo. Todas essas características deixam claro que os

livros da Bibliografia Universitária Pearson consti­ tuem um importante aliado para estudantes conecta­

dos e professores objetivos - ou seja, para o mundo

de hoje - e certamente serão lembrados (e usados) por muito tempo.

Boa leitura!

A habilidade de desenvolver aplicações para computação móvel é cada vez mais valiosa para a indústria do século XXI. O

desenvolvimento de soluções mais sofisticadas para esse tipo de aplicação carece da correta compreensão da arquitetura de sof­

tware, que cncapsula a computação móvel. Por isso, a prepara­

ção desta obra introdutória, Arquitetura para computação móvel, foi um grande desafio c visou o desenvolvimento de um material

didático que atenda aos interesses da atualidade e, ao mesmo

tempo, contenha a fundamentação teórica necessária para o de­ senvolvimento de tal habilidade.

O principal objetivo desta obra é reunir temas da atualidade que estimulem o estudante e introduzam-no às necessidades do

mercado brasileiro. Por outro lado, buscamos também disponibi­ lizar um conhecimento sólido que proporcione ao estudante um

bom desenvolvimento da base teórica. Desta forma, utilizamos

uma abordagem objetiva e prática apoiada em exemplos do dia a dia que sejam comuns ao estudante. A abordagem pretende apre­ sentar de maneira didática diversos conceitos e construções teóri­ cas da arquitetura de software para computação móvel. Tivemos o cuidado de indicar as obras em que nos baseamos para que o leitor possa recorrer a esses textos sempre que sentir a necessidade de se

aprofundar em determinado tema.

Seguindo a proposta de outros livros desta coleção, o conteúdo divide-se em quatro unidades, todas enriquecidas com boxes de

ampliação, seções especiais c exercícios para fixação e reflexão. A Unidade 1 concentra-se na arquitetura de software e dos re­

quisitos arquiteturais. Essa unidade apresenta didaticamente todo

o contexto da arquitetura de s oftware, mostrando seus objetivos, seu ciclo de vida e a contextualização em diversos âmbitos. Fixa­ dos os conceitos da arquitetura de software, são apresentados os requisitos arquiteturais ao longo do segundo tema, bem como seus

conceitos e suas teorias, como funcional idade, disponibilidade, es-

calabilidade, entre outros.

X

Arquitetura para computação móvel

Para dar continuidade a esses assuntos, ao longo da Unidade 2

o leitor conhece diversos conceitos dos padrões de projetos e tem a oportunidade dc aprofundar seus conhecimentos sobre o ciclo dc vida dos diferentes estilos de arquitetura. Além disso, o leitor ob­ serva as vantagens c as desvantagens dc cada um desses padrões.

O objetivo principal da Unidade 3 é permitir que o leitor se fa­ miliarize com as arquiteturas baseadas cm wcbscrviccs c serviços.

Alguns conceitos fundamentais para a arquitetura para computação móvel são abordados nessa unidade, como XML c SOA.

Por fim, a Unidade 4 traz reflexões atuais e práticas sobre as linguagens dc descrição arquitetural (ADL). O leitor c confronta­

do com diferentes tipos de descrição de projetos de software e

pode perceber os benefícios c as dificuldades dc cada uma. A abordagem proposta permite que o leitor adquira um olhar críti­

co para escolher a melhor linguagem dc descrição de arquitetura para seus projetos. Esperamos que esta obra seja uma introdução divertida e infor­

mativa para o leitor.

Boa Leitura! Rafael Félix

UNIDADE 1

INTRODUÇÃO À ARQUITETURA DE SOFTWARE

CONHEÇA Os requisitos da arquitetura de software.

REFUTA Sobre a importância de definir os requisitos corretos para a arquite­ tura de software.

DISCUTA Como definir as funcionalidades do software por meio dos requisitos arquiteturais.

APLIQUE Os conhecimentos adquiridos para obter uma arquitetura de softwa­ re robusta, escalável e de alto desempenho.

#REQUISITOS #ESCALABILIDADE

#ARQUITETURADESOFTWARE

01

O que é arquitetura de software? Como é estrutu­ rada a arquitetura de um sistema? Quais os aspec­ tos principais da arquitetura de software? Quais os tipos de processos de desenvolvimento? O que é importante na hora de definir um projeto?

OBJETIVOS DE APRENDIZAGEM Compreender os objetivos e as funcionalidades da arquitetura de software.

Conhecer os diferentes contextos da arquitetura de software e suas múltiplas abordagens. Identificar os principais requisitos arquiteturais como funcionalidade, disponibilidade, performance e segurança.

Relacionar os principais requisitos arquiteturais com situações do dia a dia.

INTRODUÇÃO À ARQUITETURA DE SOFTWARE

02

REQUISITOS ARQUITETURAIS O que são requisitos arquiteturais? O que é fun­ cionalidade? Como calcular a disponibilidade? O que é interoperabilidade? O que é escalabilidade? Como manter um sistema seguro?

Introdução à arquitetura de software

3

Introdução Quando ouvimos falar sobre arquitetura, rapida­ mente associamos a palavra ao ato de construir casas e prédios. De fato, arquitetura é uma pala­ vra originalmente relacionada ao design de uma construção interna ou de uma estrutura externa. O que nós esquecemos é que toda e qualquer coisa organizada e estruturada possui uma ar­ quitetura, ou seja, uma forma, independente­ mente do seu tipo. Por exemplo, a hierarquia de uma escola, que vai do diretor ao faxineiro passando por coordenado­ res, vice-diretores, alunos e professores também forma uma estrutura; quando assistimos a um filme e o vilão bola uma estratégia, ele diz estar arquitetando um plano mirabolante. Mesmo um filme, que precisa ser estruturado para ser editado e montado, possui uma arquitetura.

Com a computação não seria diferente. Aqui, arqui­ tetura também se refere à estrutura de um sistema, compreendendo todas as características que um sistema deve conter, sejam requisitos técnicos ou não. Ou seja, a arquitetura de um sistema não de­ pende apenas de código e infraestrutura, mas tam­ bém estratégia, relações pessoais e conhecimento. Antes mesmo de pensar em soluções tecnológicas, é preciso se comunicar com o cliente, saber o desejo dos tomadores de decisão e entender muito bem o problema para só aí se pensar na melhor solução. Por isso, vamos adentrar um mundo mais analítico do desenvolvimento de software. Esperamos que, ao fi­ nal desta unidade, você olhe para seu software e não veja apenas linhas de código, que representam tare­ fas a serem executadas, mas o resultado da análise de algo com uma estrutura bem definida.

Introdução à arquitetura de software Objetivos da arquitetura de software Para compreender o objetivo da arquitetura de software, pense

nos conceitos de objetivos e resultados. O objetivo c a descrição

do que se deseja obter como resultado prático. Assim, você pode considerar um objetivo como algo abstraio - isto é, um plano que

não é físico, não é tangível - e o resultado como algo concreto, que pode ser locado ou medido. É exatamente no meio termo desses dois extremos que está a

arquitetura de software. Ela é criada e utilizada para ajudar organi­

zações a atingirem seus objetivos finais, transformando algo abs­ trato em um resultado prático e mensurável. Essa transformação

ocorre por meio da modelagem de software. A modelagem é o processo de desenvolvimento de modelos

abstratos de um software, em que cada modelo apresenta uma

4

Arquitetura para computação móvel

visão ou perspectiva, diferente do software. A modelagem geral­

mente representa o sistema com algum tipo dc notação gráfica, baseada em notações de UML (Unified Modeling Language).

A arquitetura de um sistema compreende um conjunto de es­ truturas necessárias a ele, além de seus elementos, propriedades e relações - que, por sua vez, visam alcançar algum objetivo. Primeiro, pense em arquitetura como uma serie dc estruturas.

Podemos dividi-las em três partes: 1.

Estrutura modular - módulos são responsáveis por fun­

ções específicas. Por exemplo: o time I realiza a função x; o time 2 realiza a função y; e assim por diante. As vezes,

esses módulos podem ser subdivididos, caso a arquitetura seja muito extensa.

2.

Componentes e conexões (C&C) - para o bom funcio­

namento de uma arquitetura modular, é necessário que

existam elos bem estruturados entre cada módulo. Os co­ nectores garantem que os componentes da arquitetura se comuniquem da melhor maneira possível, para que haja

sincronia entre eles.

3.

Estrutura de locação - descreve o mapa dc desenvolvimen­

to, instalação e execução de um sistema. Por exemplo: mó­

dulos organizarão a estrutura dc funções cm um sistema; os componentes desses módulos serão executados por meio de

um hardware. Com isso em mente, um mapa que une essas duas funções é chamado dc estrutura de locação.

PARA SABER!

Ao criar a arquitetura de um software, você usará elementos do mundo real. Então, para facilitar a sua organização e não esbarrar em problemas, é plausível omitir

algumas informações particulares dos elementos de sua arquitetura, mantendo

aquilo que for essencial. Por exemplo: imagine um sistema de uma clínica na qual os atores sejam a secretária Esteia e o médico Alberto. Ao criar esse sistema, bem como

sua arquitetura, seria recomendável que você omitisse os dados "Esteia" e "Alberto* usando apenas "secretária* e "médico" Isso diminui as chances de mal entendidos no

momento em que esse sistema for aplicado na clínica.

Introdução à arquitetura de software

Contextos da arquitetura de software Você pode entender a arquitetura de software por meio de dife­

rentes pontos de vista. Isso é possível porque, além de considerar eventos técnicos (operacionais) de um sistema, você pode pensar

em como eles vão atingir o sistema de uma organização, por exem­ plo. Uma arquitetura de software pode ser tratada a partir dos se­

guintes pontos de vista: Técnico - uma arquitetura c a descrição de um sistema. Então,

qual é o papel técnico disso no sistema cm si? Qual é a sua função prática?

Ciclo de vida do projeto - softwares possuem um ciclo de

vida. Como uma arquitetura interage com esse ciclo? Negócios - como uma arquitetura de software pode impactar

o ambiente de negócios de uma organização? Profissional - qual é o papel de uma arquitetura de software

em um ambiente organizacional? A seguir, vamos nos aprofundar em cada um desses quatro pon­

tos de vista.

Contexto técnico A arquitetura de software atinge vários pontos que ultrapassam

o ambiente de desenvolvimento de projeto, podendo ser encarada, por exemplo, como um recurso de auxílio na relação de uma em­

presa com seus stakeholders (pessoas ou negócios interessados

cm uma organização), englobando aspectos não técnicos, como a estrutura de uma equipe de trabalho.

Mas se você considerar apenas o contexto técnico de uma ar­ quitetura de software, podemos dizer que ela: Retira ou associa qualidades aos atributos de um sistema; Possibilita a previsão de vários aspectos em sistemas de

qualidade;

Facilita a gestão de mudanças. Um dos pontos mais importantes da visão técnica de uma ar­ quitetura é o primeiro item. Isso porque os atributos determinarão as características do sistema. Por exemplo: se você precisa de um

programa de alta performance, pode organizá-los e associá-los de

5

6

Arquitetura para computação móvel

uma maneira específica. Essa maneira, naturalmente, não seria igual caso a função do programa fosse outra. Lembre-se, também,

de que para criar uma boa arquitetura de software, principalmente

do ponto de vista técnico, é preciso considerar detalhes como:

Atenção à relação entre elementos dos sistemas e à previsão de como reagirão a erros - todo o projeto pode precisar de

remanejamento caso exista uma falha.

Atenção à usabilidade do sistema. A interface é essencial, pois é a principal janela com o usuário. Se a função do seu sistema é testar elementos, você deve

prestar atenção no detalhamento da funcionalidade daqueles que serão testados. Ao criar uma arquitetura de software, você deve ponderar qual

caminho vai seguir: leste de elementos, relacionamento com o

usuário, ou algum outro. Em seguida, desenvolverá lodo o pro­ cesso a partir das características mais adequadas para a finalidade

do programa.

Contexto de ciclo de vida do projeto Dentro de uma abordagem de ciclo de vida, existem vários pro­

cessos de desenvolvimento de software. Esses processos são mo­

delos padrões para o desenvolvimento de um sistema. Neste livro, vamos destacar quatro processos principais, que veremos a seguir: Waterfall (cascata) - durante muitos anos. Waterfall foi con­ siderado o principal modelo dc ciclo de vida cm arquiteturas

de softwares. Essa abordagem organiza o ciclo de vida dc um sistema cm uma sequência dc atividades, sendo que todas elas

devem possuir condições de entradas e saídas. Também preci­ sam ser devidamente relacionadas às etapas anteriores e pos­ teriores. As atividades para esse modelo preveem: análise e

especificações de requisitos, projeto e arquitetura de software, codificação, testes e implantação e manutenção.

Interativo - com o tempo, assim como você pode perce­ ber. os caminhos dc retorno (feedback) no modelo Waterfall

tornou o sistema tão carregado que foi necessário desenvol­ ver outro. Esse novo modelo é o interativo. Nele, você vai

trabalhar pensando em desenvolvimento de software como uma série dc ciclos curtos. Cada ciclo é responsável por uma

Introdução à arquitetura de software

função específica c trabalha individualmente, mas de modo

interativo. Por exemplo, enquanto o ciclo A realiza a tarefa 1, o ciclo B já está realizando a tarefa 2. A Figura 1.1 mostra um

diagrama de funcionamento do modelo em cascata. Figura 1.1 Modelo em cascata.

Fonte: adaptada de Sommerville (2011, p. 20).

Agile Software Development (Desenvolvimento ágil de software) - assim como o desenvolvimento interativo, essa abordagem também trabalha com pequenos ciclos, que apre­ sentam menores intervalos de tempo. Essa metodologia per­

mite a “conversa” entre a organização e os desenvolvedores

de software. Também tem uma adaptação rápida a mudanças

no cenário do sistema. Model driven development - esse ponto dc vista considera

que você, e nenhum outro ser humano, deveria criar códigos na linguagem dc programação. Para isso, o responsável deve criar um modelo independente dc plataforma (platform-inde­

pendent model - PIM), que será combinado a um modelo de definição de plataforma (platform-definition model - PDM) e, só então, um código seria gerado automaticamente.

7

3

Arquitetura para computação móvel

É importante saber que, indcpcndcntcmcntc do processo de desenvolvimento de ciclo de vida escolhido (Waterfall, Model

driven development etc.), existem alguns métodos que você pode

utilizar. São eles:

■

Fazer um estudo de caso para o sistema Etapa na qual quem vai criar a arquitetura “conversa” com

a organização. Ou seja, procura-se justificar o investimen­ to feito na criação do sistema. Nesta etapa, perguntas como

“quanto o projeto vai custar?”, “qual é o público-alvo?”, e “a interface do sistema deverá interagir com outros sistemas?”

devem ser respondidas com clareza. Elas ajudarão o progra­ mador a compreender as necessidades da organização, facili­

tando o percurso entre os objetivos abstratos e os resultados concretos. Identificar os requisitos da arquitetura

Aqui, você vai decidir qual técnica melhor se aplica às neces­

sidades da organização. Por exemplo: a programação orien­ tada a objetos é uma linguagem que utiliza casos e cenários

que aproximam o sistema do mundo real, sendo assim, deve ser aplicada em situações desse tipo. Uma forma de identi­

ficar qual é a melhor técnica para a organização é seguir os modelos de softwares já existentes nessa organização. Você

também pode partir para a realização de pequenos protótipos.

Os protótipos testam os comportamentos desejados, o design

da interface c outros detalhes, até que o sistema fique dc acor­ do com as necessidades da organização.

■

Modelagem e Projeto de Arquitetura

Os modelos dc projeto dc arquitetura são usados para faci­

litar a discussão sobre o sistema. Uma vez que a visão de

alto nível da arquitetura não é muito detalhada, isso ajuda na comunicação com os stakeholders do sistema e no planeja­ mento do projeto. Os stakeholders podem se relacionar e ter

uma visão abstrata do sistema. E, então, discutir o sistema

como um todo, sem a possibilidade de serem confundidos pelos detalhes.

Também um modelo de projeto é utilizado como uma forma

dc documentar uma arquitetura projetada. O objetivo aqui é produzir um modelo dc sistema completo que mostre os

Introdução à arquitetura de software

Q

diferentes componentes cm um sistema, suas interfaces e

suas conexões. Documentar c comunicar a arquitetura

Documentar e comunicar a arquitetura agregam duas funções básicas:

1.

Ajudar os desenvolvedores a acompanhar o andamento

do projeto. Aqui, mesmo que detalhada, tal documenta­ ção não possui um caráter necessariamente formal. 2.

Apresentar, em forma de documento, o programa ao cliente, dc modo que possa compreende-lo. Deve ser um

documento objetivo e claro, de forma que toda e qual­ quer pessoa possa entender seu conteúdo sem ambigui­ dades ou dúvidas. Caso existam alterações no sistema,

elas também devem ser documentadas.

■

Analisar as interfaces Ao criar uma arquitetura de software, você certamente vai

criar interfaces. Analisar ou avaliar essas interfaces é de extre­ ma importância para selecionar aquela que mais se enquadra às necessidades da organização que fará uso desse sistema.

v)PARA SABER!

Implementar e testar o sistema Etapa na qual o desenvolvedor implementa e realiza os testes unitários de cada parte desenvolvida do sistema.

A arquitetura de software não está apenas relacionada à programação, mas

Verificação e validação de software

também a todo o contexto

Atividades para verificar se o software está de acordo com

do negócio do cliente

as especificações estabelecidas e com a arquitetura projeta­

e às diferentes visões

da, além de validar se atende as o que o usuário realmente

estruturais do sistema.

necessita.

Contexto de negócios Empresas c organizações sempre possuem objetivos, que

podem ter os mais diferentes teores, desde como aumentar sua

participação no mercado, melhorar a qualidade dos produtos, até manter seus stakeholders satisfeitos, entre muitos outros. Como

dissemos anteriormente, a arquitetura de software tem papel fun­ damental para o alcance desses objetivos. Isso porque, muitas ve­

zes, essas metas influenciam diretamente atributos de um sistema,

e até mesmo a própria arquitetura em si.

10

Arquitetura para computação móvel

Arquitetura dc software não requer apenas programação, há

todo o contexto do negócio do cliente e as diferentes visões es­ truturais do sistema elaboradas pela engenharia de requisitos e

arquitetos de software. Quando essas decisões atingem direta­

mente os atributos de um sistema ou sua arquitetura, dizemos que o objetivo do negócio leva a mudanças nos atributos ou na

arquitetura.

Algumas vezes, mudanças nos requisitos de um sistema podem resultar em

mudanças na arquitetura. Você pode perceber que esse fato está exemplificado

na Figura 1.2.

Existem também objetivos que não envolvem, necessariamente, soluções dc arquitetura. Por exemplo: imagine que a organização dc

um banco dc dados dc funcionários tem como função manter todos os funcionários dc uma empresa, ou dc uma determinada área, de­

vidamente identificados para que recebam o salário. Realizar essa organização e incluir esse banco dc dados cm um sistema não impli­

ca necessariamente em uma mudança na arquitetura do banco, pois

já é um elemento pronto. Veja, na Figura 1.2, que a relação desse exemplo é ilustrada pela seta pontilhada. Já as outras setas indicam

objetivos que interferem em elementos e na arquitetura. Figura 1.2 Diagrama da influência do negócio na arquitetura do projeto.

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 50).

Contexto profissional Você deve ter percebido que um arquiteto de software não se limita apenas ao desenvolvimento do código. Ele é muito

mais do que isso: um profissional que desenvolve arquitetura

Introdução à arquitetura de software

de softwares precisa dc três qualidades fundamentais para ter sucesso no mercado: 1.

Habilidade.

2.

Atribuições.

3.

Conhecimento.

Um arquiteto não consegue realizar todo o projeto sem uma boa conversa com o seu cliente. Somente dessa maneira ele co­ nhecerá a fundo as metas que o cliente deseja atingir e poderá desenvolver um programa adequado. Assim, você deve ter a ha­

bilidade da comunicação, aprendendo a negociar, argumentar c dialogar. É dever dc um arquiteto comunicar suas idéias da ma­ neira mais clara possível, abrangendo todas as possibilidades, sem deixar margens para erros de comunicação ou interpretação. Isso

afeta direlamente o resultado do programa.

O arquiteto também deve ter conhecimento atualizado sobre o

ramo, como as últimas tecnologias de bancos de dados, serviços padrões de internet, entre outros. Tudo isso qualifica uma boa ar­ quitetura, além de qualificar a pessoa como um bom profissional.

Requisitos arquiteturais Você já sabe que os requisitos para a criação de um sistema

têm base em diversas situações: por meio de um estudo de caso

das necessidades de uma empresa; de sistemas já existentes; do histórico da empresa, entre outras situações.

Os requisitos do sistema podem ser classificados como: Requisitos funcionais - São declarações dc serviços que o sistema deve fornecer, de como o sistema deve reagir a en­

tradas específicas e de como o sistema deve se comportar em

determinadas situações, ou seja, as funções de um sistema. Requisitos não funcionais - São restrições aos serviços ou

funções oferecidos pelo sistema. Incluem restrições de tem­ po, restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das características indi­

viduais ou serviços do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo e afetam

diretamente a arquitetura do software.

*| *|

*| 2

Arquitetura para computação móvel

Dependabilidade Os trabalhos de Laprie e Costes estabelecem uma visão do conceito de dependabilidade (dependability, em inglês) e seus

atributos. Define-se dependabilidade como sendo a habilidade de um sistema prover serviços que, justificadamente, possam

ser confiáveis. Esta definição realça a necessidade de justificar a confiabilidade. A definição alternativa fornece o critério para decidir se o serviço é dependable, dizendo que a dependabili­

dade de um sistema é a capacidade de evitar falhas de serviço que são mais frequentes e mais graves do que é aceitável. Tam­ bém, segundo Avizienis, é a capacidade de evitar que ocorram

defeitos frequentes ou com severidade maior que o esperado pelos usuários. Um defeito ocorre quando o serviço prestado se desvia daquele que seria esperado segundo os objetivos do

sistema. Como desenvolvido ao longo das últimas três décadas, de­ pendabilidade é um conceito integrado que engloba os seguintes atributos:

Disponibilidade (availability) - prontidão para o serviço correio; Confiabilidade (reliability) - a continuidade do serviço

correto; Segurança física (safety) - ausência de consequências catas­ tróficas sobre o usuário e sobre o meio ambiente;

Integridade (integrity) - ausência dc alterações inadequadas

do sistema e

Manutenibilidade (maintainability) - capacidade dc sofrer modificações c reparos. Ao abordar a segurança lógica (security), um atributo adi­

cional tem grande destaque, a confidencialidade (confiden­ tiality), ou seja, a ausência de divulgação não autorizada dc informações. A segurança lógica (security) é um conjunto de

atributos de confidencialidade, integridade e disponibilidade (confidentiality, integrity e availability). A Figura 1.3 apresen­

ta o relacionamento de atributos entre dependabilidade e segu­ rança lógica (security).

Introdução à arquitetura de software

Figura 1.3 Dependabilidade, segurança e seus atributos.

Fonte: adaptada de Leme (2016).

Falhas, erros e defeitos são ameaças à dependabilidade de um

sistema computacional. A terminologia (em português) proposta por tradução apresentada por Leite c Losqucs, define que uma fa­

lha de software é um engano do programador que se perpetua no código por ele escrito. Quando ativada, leva o sistema a um estado errôneo. Este estado errôneo pode levar o sistema a um desvio

dc sua especificação, o que se configura um defeito. Nos casos em que o serviço de um sistema c utilizado por outro sistema, pode-se ter situações em que uma falha que cause um defeito no primeiro sistema conduza o segundo sistema a um estado errôneo

e, possivelmente, a um defeito (propagação dc erros), criando uma cadeia dc causalidade entre erros e defeitos. Um mecanismo de

tolerância a falhas pode impedir a propagação do erro, colocando fim nessa cadeia. A Figura 1.4 ilustra a definição de falhas, erros e

defeitos proposta por Alvizicnis et al. Figura 1.4 Ameaças à dependabilidade.

Falha (Fault)

Ativa

Fonte: adaptada de Alvizienis et al. (2014, p. 11).

Defeito

(Failure)

Causa

Falha

(Fault)

13

1 4*

Arquitetura para computação móvel

Funcionalidade Em linhas gerais, você pode dizer que “funcionalidade é a

capacidade do sistema de realizar a sua função” (CLEMENTS; BASS; KAZMAN, 2013). Justamente por dizer qual será a função

do sistema, a funcionalidade vai ajudar no momento de defini-lo. Para que tudo esteja correto, você deve considerar o tipo de programa que está fazendo para eleger quais serão os requisitos

funcionais e os não funcionais. Isto é, os atributos que farão parte

diretamente das atividades do programa estarão em evidência.

A funcionalidade do sistema e as restrições técnicas sobre essas funcionalidades definem a arquitetura para o software.

Disponibilidade Essa é a função do software que sempre está pronta para realizar

tarefas quando necessário. De fato, você pode notar que o signifi­

cado da palavra disponibilidade está bastante próximo do conceito dc confiabilidade. Mas a diferença é que a disponibilidade também

compreende o ato de recuperar dados. Ou seja, quando um sistema falha - ou quebra - é possível recuperá-lo para que continue sendo

executado. Uma maneira mais completa de definir disponibilidade seria a seguinte: disponibilidade se refere à capacidade de o sistema

reparar erros desde que o período de interrupções não exceda um valor específico em um período de tempo determinado. Esses valores são determinados por quem cria o sistema. Logo,

disponibilidade sempre estará relacionada à redução do tempo de interrupção do serviço por meio da diminuição de falhas, que são

desvios do sistema visíveis externamente.

Para isso, é importante que sua arquitetura seja tolerante a fa­

lhas. Ou seja, que saiba se adaptar a vários tipos de falhas (veja

o Quadro 1.1). Isso significa que quando o seu sistema identifica

uma falha, ele pode reiterá-la, removê-la ou prevê-la.

Introdução à arquitetura de software

Quadro 1.1 Tipos de falhas.

Tipo de falha Sem efeito

Definição

Falha que não implica em impactos na segurança ou na operação do sistema

Pequena

A falha é notificada, mas possui impacto reduzido, se comparada às faltas maiores.

A falha é notificada e é relevante, mas resulta apenas em um

Grande

desconforto de quem usa o sistema, e não em prejuízos. Perigosa

Resulta em um grande impacto negativo na segurança ou na

operação do sistema. É notificada e perceptível visualmente.

Pode resultar em sérios prejuízos aos usuários. Catastrófica

Esse tipo de falha quebra o sistema, representando a perda

de sua função principal

Lembre-se de que defeitos geral mente são visíveis aos usuá­ rios, mas eles não sabem qual é o tempo necessário para o sistema resolvê-la. Por isso, ter conhecimento do tempo necessário para a solução de um erro é fundamental - quanto menor, melhor. Sc uma falha ocorre cm uma linha dc código, mas o programa consegue recuperá-la sem existir desvios no comportamento ori­

ginal do programa, então essa falha é imperceptível ao usuário. A disponibilidade de um sistema pode ser calculada por meio

da probabilidade de fornecimento de serviços dentro de limites de tempo requeridos. Esse estado, no qual o sistema fica “parado”, é chamado dc disponibilidade dc estado estacionário, sendo calcu­

lado pela fórmula: estado estacionário =----- -----------(tmef +tmr)

Onde,

ttnef: tempo médio entre falhas ímr: tempo medio dc reparo. Com essa fórmula, você pode calcular a probabilidade de acer­

tos e erros do sistema. A recuperação de erros varia, podendo ser automática ou demandar a intervenção do usuário. A

Tabela

disponibilidade:

l.l

mostra

exemplos

das

porcentagens

de

15

1 6

Arquitetura para computação móvel

Tabela 1.1 Porcentagens de disponibilidade.

Tempo de Parada (Downtime/90 dias)

Tempo de Parada (Downtime/Ano)

99.0%

21 horas, 36 minutos

3 dias, 15,6 horas

99.9%

2 horas, 10 minutos

8 horas, 46 segundos

99.99%

12 minutos, 58 segundos

52 minutos, 34 segundos

99.999%

1 minuto, 18 segundos

5 minutos, 15 segundos

99.9999%

8 segundos

32 segundos

Disponibilidade

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 81).

Cenário Podemos, agora, considerar o cenário geral de disponibilida­ des. Veja o Quadro 1.2 a seguir: Quadro 1.2 Cenário de disponibilidades.

Valores Possíveis

Partes do Cenário

Fonte de estímulo

Interna/Externa: pessoas, hardware, software, infraestrutura física, ambiente físico.

Estímulo

Erros: omissão, quebra, tempo incorreto, resposta incorreta.

Artefato

Processadores, canais de comunicação, armazenamento persistente, processos.

Ambiente

Operação normal, inicialização, desligamento, modo de reparação,

modo limitado, operação sobrecarregada.

Resposta

Prevenir o erro para que não se torne uma falha. Detectar o erro: Registrar o erro.

Notificar as entidades apropriadas - pessoas ou sistemas.

Recuperar o erro: Desabilitar a fonte de eventos que causam o erro. Tornar o sistema temporariamente indisponível enquanto o reparo é

efetuado.

Corrigir ou mascarar o erro. Operar em modo limitado enquanto o erro é corrigido ou mascarado.

Mensuração da

Tempo de intervalo para que o sistema esteja disponível.

resposta

Porcentagem de disponibilidade (99.999%).

Tempo para detectar o erro. Tempo para reparar o erro. Tempo de intervalo em que o sistema ficou em modo limitado. Fonte: adaptado de Clements, Bass e Kazman (2013, p. 81).

Introdução à arquitetura de software

A respeito do Quadro 1.2, podemos dizer que:

Fonte de estímulo - causas de falhas externas ou internas

decidem qual será a resposta do sistema.

Estímulo - uma falha pode acontecer nas seguintes ocasiões: Omissão - um componente falha ao receber um valor.

Quebra (crash) - um componente apresenta repetida­

mente várias falhas de omissão. Tempo - um componente responde cedo ou tarde demais. Resposta - o componente falha ao responder um valor incorreto.

Artefato - especificações dos recursos para que exista uma

boa disponibilidade (processador, canal de comunicação etc.). Ambiente - estágio em que o sistema pode afetar a resposta desejada.

Respostas - há uma série de respostas possíveis do siste­ ma sobre uma falha. Primeiro, ele deve localizá-la e isolá-

-la. Depois, deve recuperá-la, isto é, registar o tipo dc falta;

notificá-la adequadamente (a um autor ou a outros sistemas);

recuperá-la por meio de ações como: desabilitar a fonte dos eventos que resultaram em erros; ou tornar o sistema tempo­

rariamente indisponível enquanto a falha é recuperada. Essas ações dependerão do tipo de falha. Mensuração da resposta - especifica a disponibilidade cm

porcentagem - o tempo para localizar uma falha, para recuperá-la etc.

Táticas Uma falha ocorre quando o sistema não atende uma especificação. Uma ou mais falhas resultam em um erro, que por sua vez gera um

defeito ao usuário. Táticas dc disponibilidade, então, fazem com que

o sistema supere os erros apresentados, conforme visto na Figura 1.5. A Figura 1.6, na página seguinte, mostra algumas táticas possíveis

para a recuperação de um erro: Figura 1.5 Recuperação de erros.

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 81).

17

18

Arquitetura para computação móvel

Figura 1.6 Táticas de disponibilidade.

I

Detectar falhas

Ping/Echo

Monitor

Heartbeat (batimento cardíaco)

Time

stamp

Verificação de sanidade

Condições de monitoramento

Rollback

Voting

Upgrade de software

Replicação

Nova tentativa

Redundância funcional

Ignorar comportamento da falha

Redundância

analítica

Detecção

Degradação

Reconfigu ração

de exceção

Auto-teste

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 81).

Introdução à arquitetura de software

Detectando falhas Antes de tudo, você precisa preparar o sistema para que ele reconheça e detecte falhas. As opções são as seguintes: Ping/echo - medição de estímulo-resposta entre elementos.

O único parâmetro para que o sistema considere a existência de uma falha é quando o tempo limite expira.

Monitor - monitora o funcionamento de várias partes do sistema, assim como processos, memória etc. Pode detectar

falhas ou congestionamentos na rede. Heartbeat - mecanismo dc detecção dc falhas que empre­ ga as mensagens entre o monitor e o objeto que está sendo

monitorado.

Time stamp - tática usada para detectar sequências incorretas de eventos. Ocorre quando há o estabelecimento do tempo logo após que determinado evento ocorre. Verificação de sanidade - verifica e valida operações espe­ cíficas ou saídas de um componente.

Condições de monitoramento - checa as condições dc um processo, além de verificar suposições feitas na etapa de

design do sistema. Também previne falhas de comportamento.

Voting - trabalha com o conceito de redundância modular tripla (Triple Modular Redundancy - TMR). Esse processo

compreende o uso dc três componentes para realizar a mes­ ma tarefa, recebendo informações iguais e checando as suas

saídas para verificar inconsistências. Quando uma inconsis­ tência é retornada, a falha é detectada.

Replicação - forma simplificada do Vofíng, que usa cópias idênticas de componentes.

Redundância funciona) - similar ao Voting. mas, neste caso, os componentes devem retornar resultados iguais das mes­

mas entradas, ainda que sejam designados e implementados de modos diferentes.

Redundância analítica - similar à redundância funcional, permite que as saídas também sejam diversificadas.

Detecção de exceção - momento no qual o sistema identifica algo que altere o fluxo normal de uma execução. Autoteste - componentes podem rodar um procedimento

que teste a eles mesmos, verificando se os próprios compor­

tamentos estão corretos.

19

20

Arquitetura para computação móvel

Recuperando falhas Para recuperar falhas, esta etapa é subdividida em preparação!

reparação e reintrodução. A preparação/reparação consiste em: Redundância ativa - configuração ativada quando elemen­

tos recebem entradas paralelas idênticas, causando uma re­

dundância. O sistema pode lidar com a falha em questão de

milissegundos. Redundância passiva - atualiza periodicamente o status da

reposição de uma redundância de um grupo de elementos Spare - redundâncias ficam fora de serviço até que uma falha

significativa ocorra. Manipular exceção - quando uma falha ocorre, o sistema deve

manuseá-la de alguma forma. Ou seja, aqui, o sistema irá re­ tornar uma mensagem com o tipo de exceção encontrada, suas causas c demais informações. Rollback - essa tática permite ao sistema retornar a uma eta­

pa antes do aparecimento da exceção.

Upgrade de software - melhora os códigos executáveis por meio de táticas de upgrades, sem afetar o serviço cm si. Nova tentativa - considera que falhas podem ser corrigidas por meio de outras tentativas de realizar a mesma operação.

Ignorar comportamento de falha - ignora mensagens de erros enviadas a uma fonte particular.

Degradação - protege as funções mais importantes de um

sistema, sem focar em funções secundárias. Reconfiguração - recupera falhas de um componente, alte­ rando suas responsabilidades. Já a reintrodução contempla os seguintes pontos:

Modo sombra (shadow) - trata uma falha com antecipação

em um “modo shadow”. O tempo de tratamento de falhas pode ser predeterminado. É chamado de modo “shadow”, pois é feita em segundo plano, enquanto o sistema é executado. O

comportamento dessa tática pode ser monitorado. Ressincronização - etapa seguinte das táticas de redundân­ cia ativa e passiva, podendo ser feita de forma orgânica. A

redundância passiva visa o mascaramento de falhas. Ou seja, ela não será visível e o sistema não vai indicá-la. Já uma

Introdução à arquitetura de software

redundância ativa irá detectar, localizar c recuperar a falha em questão. Reinicialização escalonável - escala de reinicialização, ou

seja, o que o sistema fará quando reiniciado, e quantas vezes o fará. Por exemplo, ao ser reiniciado pela primeira vez, o programa tomará determinada atitude para resolver o erro.

Se não corrigido e reiniciado uma segunda vez, ele tomará a

atitude y, e assim por diante.

Encaminhamento contínuo - conceito que suprime altera­ ções nos elementos. A função é diminuir o tempo em que o

seu sistema estará indisponível. Por exemplo, quando o seu navegador trava e você não consegue nem mover o mouse,

o encaminhamento contínuo trabalharia para diminuir esse tempo cm que seu navegador fica parado.

Prevenindo falhas Depois de localizar um erro e corrigi-lo, tudo o que o sistema

pode fazer é evitar que falhas ocorram novamente. A respeito des­ se tema, podemos fazer as seguintes considerações:

Remoção do serviço - coloca um elemento fora dc serviço temporariamente, com o único propósito de diminuir falhas.

Transações - garante a troca de mensagens feitas em proto­ colo 2PC (Two-phase commit protocol). Modelo previsível - vai fornecer ao monitor as condições normais de funcionamento de um elemento específico, bem

como quais ações tomar quando determinadas condições fo­ rem localizadas.

Prevenção de exceção - disponibiliza exceções que podem

ocorrer ao sistema. Aumento do cenário dc competência - cenário em que o programa tem ação competente. Por exemplo, uma divisão

por zero não é competência de quase nenhum sistema. Au­

mentar as competências de um sistema aumenta as possibili­ dades de tratamento de uma exceção.

Checklist A seguir, veja o Quadro 1.3 com um checklist de análise e de­ sign para compreender melhor o processo de disponibilidade.

21

22

Arquitetura para computação móvel

Quadro 1.3 Checklist do processo de disponibilidade.

Checklist

Categoria

Atribuição de

Registrar o erro.

responsabilidades

Notificar entidades apropriadas. Desabilitar fontes de eventos que causam erros.

Tornar o sistema temporariamente indisponível. Operar em modo limitado.

Modelo de coordenação

Garantir que o sistema seja capaz de detectar omissões, quebras, tempos e respostas incorretas.

Garantir que o sistema possa registrar falhas. Garantir que a troca de artefatos usados (como processadores, canais de comunicação, entre outros) seja suportada. Por exemplo, o sistema continuaria operando se um servidor fosse substituído?

Determinar se é possível que o sistema opere em modo limitado.

Modelo de dados

Determinar quais partes do sistema estão disponíveis, definindo quais dessas partes estão causando erros ou falhas.

Garantir que cada operação (ou atributo) que cause erros ou falhas possa

ser desabilitada temporariamente, ou mascarada, durante o evento de uma falha

Mapeamento entre

elementos arquiteturais

Após determinar qual artefato (processador, canal de comunicação etc.) é

a fonte do erro, garantir que a arquitetura seja flexível o suficiente para permitir a sua recuperação.

Gestão de recursos

Determinar qual recurso crítico é necessário para continuar operando na

presença de um erro.

Tempo obrigatório

Determinar como e quando os elementos arquiteturais serão obrigatórios, já

que mudanças serão feitas durante o tempo de parada obrigatório.

Escolha de tecnologia

Determinar qual é a melhor tecnologia para identificar e tratar erros.

Fonte: adaptado de Clements, Bass e Kazman (2013, p. 96-98).

Interoperabilidade No contexto de arquitetura de software, interoperabilidade é

a capacidade de o sistema trocar informações e dados, em vários graus e entre interfaces. Você deve chamar essa troca de dados de interoperabilidade sintática. A segunda função da interoperabili­

dade é interpretar dados corretamente quando recebidos. A isso, damos o nome dc interoperabilidade semântica. Por vezes, você terá acesso à estrutura dc um sistema com o

qual o seu programa irá realizar um processo dc interoperabilidade.

Introdução à arquitetura de software

Nesse caso, você já pode criar um design específico na arquitetura

do seu sistema voltado para essa interoperabilidade. Caso con­ trário, deverá fazer um modelo mais genérico que identifique os

requisitos do outro sistema que fará essa relação.

Existem vários níveis em interoperabilidade. O nível mais baixo significa que os sistemas não trocam nenhum tipo de dado, ou que trocam dados sem nenhum sucesso. O nível mais alto de interopera­

bilidade significa que os sistemas trabalham juntos, mas sem nenhum tipo de erro ou engano de interpretação entre os dados trocados.

Você pode usar a interoperabilidade em diversos casos, como

nos dois exemplos a seguir:

1.

Quando não sc sabe nada a respeito dos sistemas com os

quais o programa terá que realizar o processo dc interoperabi­ lidade, pode-se criar na arquitetura uma coleção dc sistemas desconhecidos, que se adaptarão entre si.

2.

Quando um conjunto de operações depende de vários sis­

temas. Por exemplo, um deles é responsável por analisar o ambiente; o segundo por processar os dados recebidos; o ter­

ceiro por interpretar esses dados; e o quarto por distribuir es­

ses dados. Esses quatro sistemas deveríam realizar o processo de interoperabilidade entre eles. Dessa forma, podemos destacar dois pontos importantes da in­ teroperabilidade, que definem seu cenário:

1.

Descoberta - usuário deve descobrir a localização, a identi­

dade ou a interface do serviço.

2.

Manuseando a reposta - etapa dividida em três partes a.

O sistema retorna uma solicitação com a resposta.

b.

() sistema envia a resposta para outro sistema.

c.

O sistema envia a reposta para qualquer parte que tenha relação com ela.

Cenário A seguir, temos um exemplo de cenário de interoperabilida­ de. Nele, podemos ver que um sistema de localização de veículos

envia um estímulo para um sistema de monitoramento. Esse sis­ tema combina a localização enviada com outros dados (o Google

Maps, por exemplo). A resposta dessa combinação é retornada com 99,9% de precisão.

23

24

Arquitetura para computação móvel

Figura 1.7 Cenário de interoperabilidade.

Resposta

Envio de localização atual

O monitoramento de tráfego combina a localização atual com outra informação (como sobreposições de posições em sites como o Google Maps)

Ambiente: o sistema sabe o tempo de resposta

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 107).

Ainda sobre o cenário de interoperabilidade, podemos fazer as seguintes considerações: Fonte de estímulo - sistema que inicia um requerimento. Estímulo - requisito para trocar informações com outros sistemas. Artefatos - sistemas que realizam a interoperabilidade. Ambiente - sistemas que realizam a interoperabilidade e en­ contram os dados em tempo de execução. Resposta - requisição para interoperar informações trocadas; podem ser sintáticas e semânticas, ou mesmo rejeitadas. Mensuração da resposta - porcentagem dc informação tro­ cada c processada corretamente ou a porcentagem dc infor­ mação rejeitada. Quadro 1.4 Partes do cenário de interoperabilidade.

Valores Possíveis

Partes do Cenário

Fonte de estímulo

Sistema inicia uma requisição para realizar o processo de interoperabilidade com outro sistema.

Estímulo

Troca de informações entre sistemas.

Artefato

Sistema deseja realizara interoperabilidade.

Ambiente

Sistemas que desejam realizar a interoperabilidade são descobertos em tempo

de execução.

Resposta

Uma ou mais das seguintes:

A requisição é rejeitada e as entidades necessárias são notificadas. A requisição é aceita e a troca de informações é realizada com sucesso. A requisição é registrada por um ou mais sistemas envolvidos. Mensuração da resposta

Uma ou mais das seguintes:

Porcentagem de informações trocadas processadas corretamente. Porcentagem de informações rejeitadas corretamente.

Fonte: adaptado de Clements, Bass e Kazman (2013, p. 108).

Introdução à arquitetura de software

Táticas A seguir, veja um diagrama na Figura 1.8, com os objetivos do cenário de interoperabilidade: Figura 1.8 Diagrama do cenário de interoperabilidade..

Troca de

Táticas de

Requisição

informações

controle de

requerida

interoperabilidade

corretamente manipulada

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 110).

Repare que, no exemplo, não está descrita a tática em si. Isso

acontece porque existem duas formas de criar táticas para intero­

perabilidade, são elas: localização e interfaces.

Localização Existe apenas uma tática nesta subdivisão, conhecida como Discover service, que tem a função de procurar um diretório de serviço conhecido. Eles são localizados por meio de atributos como tipo de serviço, nome, localização, entre outros. É utilizada quando sistemas que realizam interoperabilidade devem ser loca­

lizados em tempo de execução.

Gerenciador de interface Interfaces são padrões para a comunicação entre dois ou mais elementos. Elas são capazes de perceber se a troca de informações

dar-se-á de forma clara ou não. Sendo assim, um dado precisa

dialogar apenas com a interface de um outro elemento, e não com

seus dados em si. Você pode gerenciar suas interfaces por meio dc duas táticas: Orquestração - coordena e gerencia uma sequência dc cha­

mados a serviços particulares. A orquestração é geralmente utilizada quando dois sistemas complexos tiverem que reali­

zar o processo de interoperabilidade. Tailor interface - adiciona capacidades a uma interface.

Também tem como função retirar algumas capacidades, [...]

ocultando-as dos usuários.

25

26

Arquitetura para computação móvel

Checklist A seguir, o Quadro 1.5 apresenta um checklist de design e aná­

lise do processo dc interoperabilidade. Quadro 1.5 Checklist do processo de interoperabilidade.

Categoria Atribuição de

responsabilidades

Checklist

Determinar qual dos sistemas precisa realizar interoperabilidade e com qual sistema fará isso.

Garantir que as responsabilidades sejam alocadas de modo a serem

conhecidas pelos sistemas externos. Garantir que as responsabilidades sejam alocadas de modo que possam se adaptar às regras:

aceitar requisitos;

trocar informações; rejeitar requisitos;

notificar pessoas e sistemas;

registrar requisitos.

Modelo de coordenação

Garantir que os mecanismos de coordenação possam encontrar as qualidades de atributos requeridas.

Modelo de dados

Determinar a sintaxe e a semântica dos dados que realizarão o processo de

interoperabilidade - de modo abstrato. Mapeamento entre

elementos arquiteturais

Garantir requisições de segurança, disponibilidade e performance durante a interoperabilidade.

Gestão de recursos

Garantir que o processo de interoperabilidade nunca escape de seus recursos.

Tempo obrigatório

Garantir um limite de acesso entre sistemas (quando realizarem a

interoperabilidade). Garantir mecanismos que estejam aptos para negar um tempo maior que o obrigatório. Escolha de tecnologia

Questionar se a tecnologia que você usa é visível na interface do sistema, e, se sim, saber quais são os seus efeitos. Considerar tecnologias aptas a receber o processo de interoperabilidade,

como em serviços de web. Por exemplo: a troca de informações no Google Maps, que combina o que é digitado (uma entrada de usuário) a uma imagem de localização. Fonte: adaptado de Clements, Bass e Kazman (2013, p. 114).

Introdução à arquitetura de software

Escalabilidade A escalabilidade existe devido a um detalhe: mudança. É um detalhe, mas se tratado sem o devido cuidado, pode resultar cm si­ tuações catastróficas. Mudanças existem para todos os propósitos. Em computação, você realizará mudanças em seus sistemas para que eles se adequem às novas tecnologias, aos novos protocolos, às novas plataformas etc. Você também pode se ver em uma situação de mudança em software quando precisar aprimorar a relação do programa com o usuário, quando consertar algum problema, ou aumentar a segu­ rança do sistema, por exemplo. Antes de partir para mudanças em seu sistema e arquitetura, você deve responder a quatro perguntas:

1.

() que pode ser mudado?

Mudanças podem ocorrer em todas as áreas do sistema: nas funções do sistema, na plataforma (hardware, SO, entre ou­ tros), no ambiente em que o sistema opera, nos atributos do

sistema e na sua capacidade. Então é necessário identificar o que será mudado para que nada seja alterado do necessário,

evitando erros.

2.

Quais são as probabilidades da mudança?

Você deve ponderar quais mudanças são concebíveis, tecni­

camente falando, para o sistema que for modificar. Ou seja,

3.

deve saber quais mudanças são suportadas e quais não são. Quando a mudança será feita e por quem será feita?

No passado, todas as mudanças eram feitas por um arquiteto

ou um desenvolvedor direto no código fonte. Hoje, esse con­

ceito ficou bem mais amplo. Por exemplo: quando você troca o protetor de tela do seu computador, já está fazendo uma mu­ dança no sistema. É claro que esses dois tipos de mudanças

são diferentes. Por isso ela é dividida em cinco tipos. São eles:

i.

Mudanças por implementação - feitas por desenvolve­ dores, diretamente no código fonte.

ii.

Mudanças durante a compilação - realizadas por switches em tempo dc compilação.

iii. Mudanças durante a construção - feitas por meio de escolhas de bibliotecas específicas.

iv.

Mudanças durante a configuração de setup - feitas por várias técnicas, inclusive parâmetros de configuração.

27

28

Arquitetura para computação móvel

v.

Mudanças em tempo de execução - feitas por meio dc plugins, configurações (settings), entre outros.

vi.

Mudanças de Requisitos do Sistema - realizadas por

Estudos comprovam que

demandas do usuário para alterar uma funcionalidade,

a maior parte dos custos

ou incluir novas funcionalidades, ou então corrigir al­

em engenharia de software

gum erro dc especificação dc requisito.

é com manutenção e

modificação de sistemas,

que já estão implementados e em uso (CLEMENTS;

4.

Qual é o custo das mudanças?

■

Você deve considerar dois pontos:

BASS;KAZMAN, 2013).

i.

O custo da introdução de um mecanismo confiável.

ii.

O custo da modificação cm si, por meio do mecanismo utilizado.

Por exemplo: quando a mudança necessária é apenas refe­ rente a alguma alteração no código-fonte, então o custo seria

zero. Mas se você tiver que construir uma nova interface com o usuário (UI), então o custo seria o da construção da UI, da implementação da mesma no código-fonte e do teste da UI.

Cenário A partir das considerações feitas, podemos iniciar o estudo do cenário da escalabilidade. A seguir, veja o Quadro 1.6 que repre­ senta as diversas partes desse cenário. Em seguida, apresentamos uma serie dc considerações sobre ele. Quadro 1.6 Partes do cenário de escalabilidade.

Partes do cenário

Possíveis valores

Fonte de estímulo

Usuário final, desenvolvedor, administrador de sistema.

Estímulo

Adicionar, deletar ou modificar funcionalidades, bem como alterar qualidades de atributos, capacidade ou tecnologia.

Artefato

Códigos, dados, interfaces, componentes, recursos, configurações.

Ambiente

Tempo de execução, de compilação, de construção, de iniciação, de desenvolvimento (design).

Resposta

Uma ou mais das seguintes: ■ realizar a modificação; ■ testar a modificação; ■ implementar a modificação.

Mensuração da resposta

Variável conforme: ■ número, tamanho ou complexidade dos artefatos alterados; ■ esforço do arquiteto; ■ calendário; ■ entre outros.

Fonte: adaptado de Clements, Bass e Kazman (2013, p. 120).

Introdução à arquitetura de software

A respeito do Quadro 1.6 c o cenário dc cscalabilidadc, pode­

mos dizer o seguinte: Fonte de estímulo - define quem faz as mudanças, podendo ser o desenvolvedor, o administrador do sistema ou um usuá­

rio final.

Estímulo - especifica a mudança a ser feita. Essa alteração pode ser de implementação, alteração ou exclusão de uma

função ao sistema. Mudanças também podem ser feitas nas

qualidades de um atribulo, aumentando sua disponibilidade, por exemplo. A capacidade dc um sistema também pode ser

modificada. Em outras palavras, essas alterações geralmente

são feitas para acompanhar novas tecnologias. Artefato - especifica o que deve ser mudado. Por exemplo: as mudanças especificadas em estímulo serão aplicadas aos módulos? Aos componentes específicos? À plataforma

do sistema? Ao ambiente do sistema? A outro sistema que

está realizando o processo de interoperabilidade? E assim por diante.

Ambiente - define o tempo em que a mudança deve ser feita.

Os tempos podem ser: ■

tempo de design, construção;

■

tempo de compilação;

■

tempo de construção;

■

tempo de instalação;

■

tempo de execução.

Resposta - realiza a alteração, a testa e a emprega.

Mensuração da resposta - toda mudança custa tempo c di­

nheiro, sendo medido nessa etapa. O tempo pode ser medido de forma natural ou tempo de equipe. Já o custo, geralmente, é diário. Outras medidas também são aplicáveis a essa etapa,

como a extensão das alterações (tudo aquilo que foi alterado: módulos, elementos e outros itens afetados pela mudança),

número de novos defeitos encontrados após a mudança, entre outros fatores.

A seguir, a Figura 1.9 mostra um diagrama que exemplifica o

processo de escalabilidade.

29

30

Arquitetura para computação móvel

Figura 1.9 Diagrama do processo de escalabilidade.

Fonte de

Estímulo

estímulo Desenvolvedor

Resposta

Artefato: códigos

Mudanças

Ambiente:

Alterações

no sistema

tempo de design

realizadas

Mensuração da resposta

Em 3 horas

e testadas

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 120).

Táticas

Níveis de coesão interferem

diretamente na qualidade

do sistema. Uma boa arquitetura prevê alta

coesão e baixo acoplamento entre os componentes de um sistema.

As táticas dc escalabilidade devem ser tão complexas quanto as alterações em um sistema podem ser. Mas antes dc falarmos de táti­ cas, devemos manter em mente o conceito de acoplamento e coesão. Quando uma alteração é feita em um módulo, as suas respon­ sabilidades são alteradas de alguma maneira. Isso porque eles pos­ suem funções e responsabilidades. Realizar uma alteração em um único módulo é simples e barato. No entanto, é bom lembrar que as funções ou as responsabili­ dades de um módulo podem estar sobrepostas, ou dependerem de funções e responsabilidades de outros módulos. Sc você, por aca­ so, fizer uma alteração em um deles que possua responsabilidades sobrepostas a outro módulo, então essa única mudança afetará a função dos dois - mesmo que a alteração seja destinada apenas a um deles. Isso é chamado dc acoplamento. A mensuração do acoplamento c feita por meio da probabilidade de uma mudança afetar outros módulos além do necessário. Quanto maior o índice de acoplamento, pior para a sua escalabilidade. Já a coesão mede a “força" das responsabilidades de um mó­ dulo, ou seja, mede o quanto uma mudança no cenário da escala­ bilidade afeta ou não as suas funções. Quanto maior for a coesão, menor será a probabilidade de uma mudança atingir mais que uma responsabilidade. Veja na Figura 1.10 um diagrama simples que representa o procedimento básico da escalabilidade.

Figura 1.10 Diagrama de escalabilidade.

Mudanças requeridas

Táticas de

Mudanças feitas

controle de escalabilidade

dentro do tempo

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 121).

e orçamento

Introdução à arquitetura de software

Agora que você conhece os conceitos dc coesão c acoplamen­

to, podemos nos aprofundar um pouco mais nas táticas dc escala-

bilidade. Sobre elas, podemos dizer o seguinte: Tamanho do módulo - pense que você precisa modificar

partes de um módulo. O custo dessa atividade pode ser re­ duzido ao dividi-lo. Por exemplo, se você dividir um módu­ lo em partes que serão modificadas e partes que não serão

modificadas, o custo será mais baixo. A modificação de um

módulo tem menor custo quando este pode ser dividido. Acoplamento - imagine três módulos A, B e C. Os módu­

los A e B estão acoplados. Agora, suponha que você precisa realizar alterações cm A c C. O custo das alterações cm A

seria maior do que as mesmas alterações em C. Isso porque o módulo A está acoplado ao B. Reduzir o acoplamento en­

tre dois módulos reduz o custo de alterações. Uma tática para reduzir esse acoplamento é inserir vários tipos de mó­

dulos entre A e B.

Coesão - retomando o exemplo anterior, se o módulo A tiver uma baixa coesão, então ele pode ser improvisado ao retirar

responsabilidades que não serão modificadas. Tempo de modificação-arquilelurasjá podem ser equipadas

para receberem possíveis alterações futuras. Inicialmente,

isso encarece o desenvolvimento. Mas, se algum dia o usuá­

rio precisar realizar alguma mudança quando o programa já estiverem uso, ele não terá custo nenhum, ou algum valor re­

lativamente baixo. Já um sistema que não c preparado para rcccbcr mudanças pode sair mais barato. Porém, se algum tipode

alteração precisar ser feita, o custo para realizá-la será ele­

vado. Uma arquitetura que já seja equipada para receber

modificação mesmo depois que já estiver em uso, vai custar,

geralmente, menos do que uma que não possui. Isso porque o custo para realizar mudanças do zero em um sistema já em

uso é elevado - o que muda se o sistema já estiver preparado para alterações posteriores, derrubando o custo para zero,

ou para um valor realmente baixo. A seguir, a Figura 1.11 mostra um diagrama exemplificando as táticas de escalabilidade. Após o diagrama, vamos fazer nossas

últimas considerações sobre esse tema.

31

32

Arquitetura para computação móvel

Figura 1.11 Táticas de escalabilidade.

Dividir módulo

Aumentar coesão

semântica

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 122).

Reduzir o tamanho do módulo Consiste em uma única tática chamada dividir módulo (split module). Se um módulo possuir uma alta gama de responsabilida­ de, o custo de modificá-lo, normalmente, será alto. O melhor que você pode fazer é subdividir esse módulo em diversos outros, com funções específicas. Assim, o custo para modificar uma função específica, em média, será bem mais barato.

Aumentar a coesão Também consiste em apenas uma tática chamada aumentar a coesão semântica (increase semantic coherence). O objetivo é ób­ vio: quanto maior for a coesão, melhor será a escalabilidade. Quando você possuir um módulo com muitas responsabilida­ des, o melhor a fazer é separar essas responsabilidades em outros módulos. Por exemplo: se um módulo possui as funções A e B, e as mudanças a serem feitas não compreendem essas duas funções, então A e B são separados em outros módulos. Assim, as altera­ ções afetam apenas aquilo que precisa, de fato, ser afetado.

Introdução à arquitetura de software

Reduzir o acoplamento

Para reduzir o acoplamento, você pode usar as seguintes táticas:

Encapsulação - essa tática introduz uma interface única a um módulo. Essa interface é associada às suas responsabi­ lidades, impedindo com que ele se acople. O ponto fraco

dessa tática é que a criação de uma interface limita a rela­ ção da função encapsulada, ou seja, os outros módulos não

irão interagir com o que está cncapsulado, apenas com a sua

interface. Uso de intermediários - usar um intermediário quebra a de­

pendência. O tipo dc intermediário varia conforme o tipo dc dependência entre dois módulos. Por exemplo, no caso de uma

calculadora programada para medir a velocidade em que um objeto cai no chão, devem ser usados valores fixos (o valor da

aceleração da gravidade, por exemplo, g = 10 m/s2) e variáveis, como o peso do objeto que cai. Essa variável seria o interme­

diário do módulo que representaria a gravidade.

Dependências restritas - considere o módulo A, que exibe uma imagem na tela, e o módulo B, que recebe uma informa­ ção digitada pelo usuário para que seja exibida na tela. Se o

módulo B estiver dependendo do módulo A, então essa tática pode restringir o módulo B. Isso acontece porque o módulo B

não seria mais visível. Ou seja, essa técnica restringe a intera­ ção dc dependência entre módulos.

Refatoração - tática usada cm uma situação bastante espe­ cífica. Às vezes, uma alteração afeta dois módulos pelo fato dc os dois módulos serem cópias, com funções idênticas. Quando isso acontece, essa tática pode ser útil. Refalorar os

módulos pode reduzir o acoplamento entre eles.

Serviços comuns abstratos - quando módulos tiverem ser­ viços parecidos, mas não exatamente iguais, é possível criar um serviço genérico para esses dois módulos. Assim, quando uma mudança for aplicada a esse elemento mais geral, tudo o que os módulos contiverem dele será modificado, e apenas isso. Por exemplo: um módulo A reconhece entradas literais e um módulo B reconhece entradas numéricas. Entretanto, se

você quiser que todas as entradas, independente do formato,

sejam alinhadas à direita quando forem exibidas, então essa

mudança afetará esses dois módulos, A e B.

33

34

Arquitetura para computação móvel

Adiando a vinculação Geralmente, o seu trabalho como programador lerá um custo

mais elevado do que se o computador cuidar das alterações. Então,

é sempre esperado que um sistema possa lidar o máximo possível

com as alterações necessárias. Para isso, devemos vincular valores e o caminho para isso ocorrer é por meio de parâmetros (a exemplo das funções f(a, b)).

Quando nós vinculamos um valor dos parâmetros a outro ponto do

ciclo de vida do sistema que não aquele definido como parâmetro,

então estamos adiando a vinculação (defer binding tatic).

Checklist A seguir, o Quadro 1.7 apresenta um checklist para avaliação e design do processo de escalabilidade. Quadro 1.7 Checklist do processo de escalabilidade.

Checklist

Categoria Atribuição de responsabilidades

Determinar as responsabilidades que deverão ser adicionadas, deletadas ou modificadas, para que as mudanças sejam feitas corretamente.

Determinar quais responsabilidades são impactadas pelas alterações. Modelo de coordenação

Determinar se as mudanças e as alterações no sistema podem ser feitas em

tempo de execução ou não. Garantir que as mudanças atinjam apenas o número necessário de módulos.

Modelo de dados

Definir quais mudanças e alterações serão feitas em um dado abstrato, garantindo que afete o menor número de módulos possível.

Mapeamento

entre elementos

Determinar se é desejável ou não que as mudanças atinjam a funcionalidade em tempo de execução, compilação e desenvolvimento.

arquiteturais Gestão de recursos

Determinar como adição, exclusão ou alteração de um módulo ou atributo de qualidade irá afetar os recursos requeridos.

Tempo obrigatório

Para cada mudança ou categoria de mudança: determinar o tempo limite para a alteração ser feita; determinar o custo de realização da alteração.

Escolha de tecnologia

Verificar se o sistema possibilita alterações, e se as torna mais fáceis ou não.

Fonte: adaptado de Clements, Bass e Kazman (2013, p. 125-127).

Introdução à arquitetura de software

Performance Este é o atributo que mais dialoga com o usuário final, ou com

o senso comum. Isso porque é estritamente relacionado ao tem­ po. Performance é o tempo que o software leva para realizar as

suas funções. Todas as funções em um sistema, visíveis ou não aos usuários finais, devem responder a estímulos em um determinado intervalo de tempo. Esse atributo é tão visado que pode ser determinante para um

software ser considerado bom ou ruim. Por exemplo, quando você digita um texto no computador ou no celular, é inaceitável que as letras apareçam na tela com um minuto ou dez segundos de atraso. Até mesmo um segundo de atraso entre o teclar e a aparição da

letra na tela pode ser algo que irrite o usuário. Tudo é uma questão de tempo.

Cenário O cenário de performance começa quando um evento é re­

cebido pelo sistema. Eventos podem chegar de forma previsível

(padrão) ou inesperada. No primeiro caso, as entradas são carac­ terizadas em: Periódica - são eventos recebidos de maneira previsível den­

tro de um intervalo regular de tempo. Geral mente, esse tempo é de 10 milissegundos. Esse tipo de evento ocorre com mais

frequência em sistemas de tempo real. Estocástica - são eventos recebidos dentro dc um intervalo

estatístico dc tempo. Por exemplo: sabe-se que um evento x será recebido entre os tempos 1 s e 10 s, mas não se sabe com

precisão em qual segundo (1 s, 2 s, 3 s, 4 s,... 10 s) o evento vai chegar.

Esporádica - são eventos recebidos em um padrão que não se enquadra nas características estocásticas e periódicas. Ge­

ralmente, são caracterizados por circunstâncias. Por exemplo, você sabe que 600 eventos podem acontecer em um minuto, e que existirá pelo menos 200 milissegundos de tempo entre

cada evento recebido. Nesse caso, você sabe quantos eventos

serão recebidos, mas não tem como saber quando cada evento

em particular vai acontecer.

35

36

Arquitetura para computação móvel

Já sobre a resposta do sistema aos estímulos recebidos, pode­

mos dizer o seguinte: Latência - o tempo entre o recebimento do estímulo e a res­

posta do sistema a ele. Quanto menor for a latência, mais rápida será a resposta.

Deadline do processo - uma resposta só é dada quando uma condição for atingida.

Transações do sistema - número de transações que um sis­ tema pode processar em uma determinada unidade de tempo.

Variação da resposta - variação permitida e considerada nor­

mal na latência. Número de eventos não processados - aumenta quando o sistema estiver ocupado demais para responder.

Agora que já fizemos tais considerações, podemos nos aprofun­

dar no cenário da performance. A seguir, o Quadro 1.8 resume esse cenário. Em seguida, veremos algumas considerações sobre ele. Quadro 1.8 Partes do cenário de performance.

Possíveis Valores

Partes do Cenário

Fonte de estímulo

Interna ou externa.

Estímulo

Recebimento de eventos periódicos, esporádicos ou estocásticos.

Artefato

0 próprio sistema ou um ou mais componentes do sistema.

Ambiente

Modo operacional, que pode ser normal, emergencial, sobrecarregado, ou peak load.

Resposta

Eventos processados, mudança do nível do serviço.

Mensuração da resposta

Latência, deadline etc.

Fonte: adaptado de Clements, Bass e Kazman (2013, p. 134).

Se nos aprofundarmos no Quadro 1.9, teremos: Fonte de estímulo - o estímulo chega ao sistema a partir do

meio externo.

Estímulo - chegada do evento. Se ele for previsível, pode ser classificado em uma das classificações que você leu

anteriormente. Artefato - um sistema, ou um ou mais de seus componentes.

Introdução à arquitetura de software

Ambiente - o sistema pode estar cm diversos modos operacionais.

Resposta - o sistema precisa processar os eventos que rece­

beu, fato que altera temporariamente o seu cenário. Mensuração da resposta - a mensuração do cenário é dada por uma ou mais das seguintes análises:

■

tempo de chegada do evento (latência);

■

variação desse tempo (jitter);

número de eventos que podem ser processados em um

intervalo dc tempo (throughtpuf); caracterização dos eventos que não puderam ser pro­ cessados (miss rate).

Táticas O objetivo das táticas de performance é gerar uma resposta cm intervalo dc tempo limitado. Você pode verificar esse objetivo nos diagramas da Figura 1.12. Figura 1.12 Objetivo das táticas de performance.

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 135).

Esse tempo dc resposta - quando o estímulo é enviado até a

resposta recebida - pode ser dividido, ainda, no tempo dc proces­ samento. O tempo dc processamento é o tempo que o sistema de­

mora para processar o estímulo, ou seja, é o tempo entre a entrada

e a saída do estímulo. Já o tempo de bloqueio é o período de tempo em que o sistema

está ocupado demais para responder, podendo ser subdivido em:

■

Contenção de recursos - você irá reparar que, às vezes, um sistema suporta apenas um cliente por vez. Sendo

37

38

Arquitetura para computação móvel

assim, o próximo deveria esperar para usar o programa. Isso significa que o recurso principal fica contido por um

tempo, para quem está esperando. Quanto maior a conten­ ção, maior a lalência Disponibilidade de recursos - mesmo sem a presença de contenção de recursos, um sistema não pode prosseguir caso

tenha recursos indisponíveis. Essa indisponibilidade pode ser

causada, por exemplo, por um recurso que está off-line.

Dependência de outra computação - isso acontece quan­ do um resultado que já foi parcialmente computado, depende

de informações de outra computação que está em andamento para retornar. Assim, o dado só será retornado quando tudo o

que precisar ser computado tiver passado por essa etapa. Agora, vamos estudar as táticas dc performance, propriamente ditas. Para começar, veja o diagrama da Figura 1.13. Figura 1.13 Táticas de performance.

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 141).

Introdução à arquitetura de software

Você reparou que as táticas se dividem cm controle de deman­ da de recursos e gestão de recursos? Vejamos essas divisões com mais detalhes a seguir.

Controle de demanda de recursos Uma forma de você aumentar a performance é gerir cuidadosamente a demanda por recursos. Para isso, existem as técnicas listadas a seguir: Gerenciamento de taxa de amostragem - deve-se reduzir

a frequência de amostragem do ambiente em que o dado é capturado. Assim, a demanda cai. Resposta-limite de evento - quando um evento chega rápido demais para que possa ser processado, ele deve ficar enfileirado com outros eventos na mesma situação, até que seja possível processá-lo. Eventos prioritários - se nem todos os eventos que chegam ao seu sistema possuem a mesma importância, você pode impor uma ordem de prioridade em que o sistema processa primeiro os de maior importância. Se não houver recursos o suficiente, uma “baixa-prioridade” talvez possa ser ignorada. Redução de sobrecarga - o uso extremo dc intermediários (que você aprendeu no item anterior, cscalabilidade) pode criar um overhead nos recursos, ou seja, sobrecarregá-los. Limite de tempo de execução - colocar um limite de tem­ po que a execução do sistema pode demorar para responder um evento. Aumentar a eficiência dos recursos - melhorar os algoritmos utilizados nas áreas críticas do sistema pode diminuir a lalência. Gestão de recursos

Você pode tratar os recursos de uma demanda, e as táticas para esses tratamentos são as seguintes:

Aumentar recursos - processadores mais rápidos, assim como memórias e processadores adicionais, podem reduzir significativamente a lalência. As vezes, pode ser a forma mais barata de resolver esse problema de forma imediata. Introduzir a concorrência - se você puder processar requi­ sitos paralelamente, então o tempo dc bloqueio será menor. Ou seja, você vai usar esta técnica quando tratar dc diferentes eventos e diferentes tópicos ao mesmo tempo.

39

40

Arquitetura para computação móvel

Manter múltiplas cópias de cálculos - guardar os cálculos dc um evento economiza espaço, podendo ser reutilizados quando necessário. Manter múltiplas cópias de dados - consiste em manter có­ pias de dados com diferentes acessos. Isso reduz a contenção por acessos múltiplos. Tamanho de filas vinculadas - refere-se ao numero máximo que uma fila de eventos ainda não processados pode conter. Ao usar essa tática, é necessário saber o momento em que essa

fila irá causar um overhead. Programação de recursos - sempre que existir uma conten­ ção em um recurso, ele deve ser programado. Você precisa en­ contrar a melhor maneira dc realizar essa tarefa, dependendo do tipo dc recurso com o qual você está lidando.

Checklist A seguir, o Quadro 1.9 apresenta um checklist dc análise e de­ sign de um processo de performance. Quadro 1.9 Checklist de um processo de performance.

Checklist

Categoria Atribuição de

responsabilidades

Modelo de coordenação

Determinar as responsabilidades de sistema que terão carregamento pesado e

definir o tempo limite de resposta aos requerimentos. Determinar os elementos de um sistema que irão se coordenar e escolher a

forma com que ele fará isso.

Modelo de dados

Determinar quais dados lerão carregamento mais lento, determinando em quais

situações: A multiplicação de cópias de chaves de arquivos são benéficas para o sistema. 0 corte de dados é benéfico para o sistema.

A redução de processos é necessária.

Adição de recursos torna-se útil. Mapeamento entre

elementos arquiteturais

Determinar o momento de realocar componentes para que o sistema torne-se mais eficiente.

Gestão de recursos

Determinar quais recursos em seu sistema são essenciais para a performance.

Tempo obrigatório

Para cada elemento, determinar:

Tempo necessário para realizar a tarefa. Tempo adicional introduzido em caso de sobrecarga.

Escolha de tecnologia

Questionar se a tecnologia escolhida oferece tempo de adaptação muito curto; se elege prioridades na performance do sistema e se a tecnologia escolhida acaba causando sobrecarga em tarefas normalmente leves.

Fonte: adaptado de Clements, Basse Kazman (2013, p. 142-144).

Introdução à arquitetura de software

Segurança Como você pode imaginar, a segurança protege o seu sistema de usuários indesejados, assim como um policial evita que um ladrão assalte um banco. Uma tentativa de acesso não autoriza­

da aos dados de um sistema é considerada um ataque, e pode ter inúmeras formas. Em uma abordagem simples, podemos separar

segurança em três itens: 1.

Confidencialidade - proteção dc um dado ou um serviço contra acessos não autorizados.

2.

Integridade - capacidade dc um dado ou serviço não estar

sujeitado a modificações não autorizadas. Por exemplo, uma

planilha de dados protegida não será modificada por um usuá­ rio não autorizado.

3.

Disponibilidade - capacidade de um sistema permanecer in­

disponível para um usuário não autorizado. Aprofundando um pouco mais, podemos citar ainda mais três

aspectos:

1.

Autenticação - verificação e identidade. Por exemplo, quan­

do você recebe um e-mail do seu banco, geralmente o serviço da caixa de entrada vai verificar se a mensagem realmente foi

enviada pelo banco ou é uma fraude. 2.

Não-repúdio (nonrepudiation) - uma vez que uma mensa­

gem foi enviada e recebida, garante que quem enviou não pode negar que enviou a mensagem. Muito menos que o re­ ceptor não recebeu a mensagem.

3.

Autorização - garante privilégios a quem possui uma autori­

zação. Por exemplo, o sistema on-line do seu banco permite que você, c apenas você, acesse sua conta por meio da internet.

Cenário Uma técnica bastante utilizada no domínio de segurança é a

criação de um modelo de ameaça. Ele é muito parecido com o mo­ delo de falhas, que você viu no início deste tema. Os estímulos nes­ se cenário serão os níveis de possíveis ataques. As respostas a esses

estímulos sempre serão defender a CIA. Por CIA, compreendemos confidencialidade, integridade e disponibilidade (confidentiality,

41

42

Arquitetura para computação móvel

integrity c availability, na sigla cm inglês). A seguir, o Quadro 1.10 apresenta um resumo do cenário dc segurança de um sistema. Quadro 1.1 o Partes do cenário de segurança.

Possíveis Valores

Partes do Cenário Fonte de estímulo

Usuário ou sistemas autorizados. Um usuário no papel de ameaça pode agir

dentro ou fora da organização. Estímulo

Tentativa de acesso não autorizado, mudança ou exclusão de dados. Mudança do

comportamento do sistema ou redução da disponibilidade.

Artefato

Serviços do sistema, dados do sistema, componentes de recursos etc.

Ambiente

0 sistema, seja on-line ou off-line, conectado ou desconectado à rede.

Resposta

Dados ou serviços protegidos de acessos não autorizados. Dados ou serviços não podem ser manipulados sem autorização.

Dados, recursos e serviços do sistema são disponíveis apenas para usuários legítimos, autorizados. 0 sistema rastreia atividades por meio de:

gravação de acesso ou modificação; gravação de tentativas de acesso a dados e outros; notificação a usuários ou outros sistemas quando reconhecer uma ameaça.

Mensuração

Comprometimento de um sistema quando um arquivo dele está em risco.

da resposta

Quanto tempo passa entre o ataque até a resolução do mesmo.

Quantos ataques ele resiste.

Quão longa é a recuperação de um ataque.

Vulnerabilidade de um dado a um único ataque. Fonte: adaptado de Clements, Bass e Kazman (2013, p. 150).

Aprofundando no Quadro 1.10, podemos dizer que: Fonte de estímulo - a fonte do ataque pode ser tanto um

humano quanto outro sistema, c pode ser previamente iden­ tificada ou não. Além disso, no caso de um ataque humano,

o atacante pode agir dentro ou fora da organização na qual o sistema alua.

Estímulo - o estímulo é o ataque. Ataques podem ser con­ siderados tentativas de acesso não autorizadas, modifica­ ção ou exclusão de dados, tentativa de acesso ao sistema

de modificação de comportamento do sistema, entre outras atitudes.

Introdução à arquitetura de software

43

Artefato - o alvo do ataque também podem ser serviços do

sistema. Alguns ataques são destinados a componentes parti­ culares sem proteção.

Ambiente - ataques podem acontecer quando o sistema está on-line ou off-line, conectado ou desconectado, em operação

ou inoperante.

Resposta - o sistema sempre deve tratar um ataque de modo a proteger os dados. Eles não podem ser apagados, modifica­ dos ou alterados se o acesso não for autorizado.

Mensuração da resposta - as formas de mensurar uma res­ posta a um ataque consideram o quanto o sistema consegue

proteger determinados elementos, quanto tempo demorou para que o sistema reconhecesse o ataque, quantos ataques o sistema suportou com sucesso, quanto tempo demorou para

o sistema se recuperar do ataque c quanto um dado pode ser vulnerável a um único ataque.

A Figura 1.14 mostra esse cenário em ação: um funcionário

tenta modificar o próprio pagamento no sistema da empresa em que trabalha. O sistema, ao receber esse comando, inicia uma au­

ditoria e os dados voltam ao estado original dentro de um dia. Figura 1.14 Cenário de segurança em ação.

Empregado descontente em fonte

Modifica lista de pagamento

Ambiente:

operação normal

Sistema realiza auditoria dos dados

remota

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 149).

Táticas A partir das táticas dc segurança, você pode desenvolver padrões

para a integridade do seu software. Você já sabe que a segurança cm

seu programa vai reduzir o maior número dc consequências indesejadas possíveis. Ou seja, a finalidade sempre será evitar falhas.

Caso elas ocorram, é tarefa das táticas dc segurança detectá-las e contê-las.

Dado original é restaurado em um dia e a fonte de alteração é identificada

44

Arquitetura para computação móvel

A seguir, a Figura 1.15 mostra uma relação da hierarquia dc

segurança - naturalmente, algo abstrato. Figura 1.15 Hierarquia das táticas de segurança.

i

i

Fonte: adaptada de Wu e Kelly (2004, p. 4).

Evitar falhas () primeiro objetivo da segurança é evitar falhas. Esta é uma ta­

refa complicada, que envolve planejamento e suposições, até certo ponto. Ainda assim, c o foco principal do projeto de arquitetura.

Tornar o seu programa simples pode ser uma maneira dc evitar falhas. Softwares menores, dc componentes simples c interfaces

mais dcscomplicadas, são menos propensos a falhas. Como con­ sequência, são mais seguros. É um recurso bastante procurado e usado em arquitetura, mas pode ser difícil simplificar um software que natural mente será complexo.

Detectar falhas

Você deve considerar que não existem softwares totalmente à

prova dc falhas. Em algum momento c em alguma localidade do

programa, algum dado ou arquivo pode se tornar vulnerável - seja pela ação do tempo em relação às tecnologias ou por quaisquer outros fatores. Assim, é imprescindível que você use recursos em

sua arquitetura que sejam capazes de identificar falhas, evitando erros que eventualmente podem afetar todo o seu sistema. Táticas como timeout e monitoramento podem ajudá-lo nessa etapa - você

pode ver essas e algumas outras táticas no item Detectando falhas

do tópico Disponibilidade deste livro.

Introdução à arquitetura de software

Conter falhas

Essa é a etapa de diminuição das consequências dc uma falha.

Logicamente, ela vem após o sistema reconhecer e identificar

uma delas. Você pode conter uma falha por meio de redundân­ cias, recuperação de falhas e mascaramento. Veja mais detalhes a seguir. A redundância é uma tática eficiente, porém cara, que se divi­

de em replicação, redundância funcional e redundância analítica: Replicação - modelo de redundância mais simples, que in­

troduz no sistema componentes adicionais (um ou mais). Mas

eles são idênticos. Ou seja, a replicação duplica componentes em busca de falhas no hardware. Isso porque, quando dupli­

cados, os componentes continuarão com falhas de software, se elas existirem. Assim, apesar de ser barata e simples, só é

recomendável para buscas de falhas no hardware. Redundância funcional - diferentes componentes são adi­

cionados, mas os dados dc saída serão sempre os mesmos. Isso faz com que sejam detectadas falhas tanto no hardware

quanto no software.

Redundância analítica - diversos componentes são adicio­ nados. As entradas são iguais, mas podem produzir resulta­

dos diferentes. Enquanto um componente lê uma entrada,

outro pode calculá-la, por exemplo. Em outras palavras, é um sistema em que tudo é feito duas vezes e de duas formas di­

ferentes. Por isso é uma opção bastante cara e trabalhosa, por

mais que seja eficiente. A recuperação de falhas é uma tática que, depois de detectar

uma falha, é nela que a falha é tratada. Ou seja, nessa etapa, será feito o processo de recuperação da falha. A principal tática, roll­ back, recupera completamente um ataque indo a uma etapa segura

para que a ação que levou ao ataque seja repetida. Isso para que a falha não volte a acontecer. O mascaramento é uma tática que mascara a falha, o seja, o

seu sistema irá impedir que ela se propague para todos os limites

do software. A tática mais comum de mascaramento é o voting.

Voting - introdução de um componente que decide que valor tomar e que atitude escolher. Assim, as falhas que ocorrem

serão falhas deste componente, e não dc um sistema inteiro.

45

46

Arquitetura para computação móvel

Geralmente c utilizado quando há um número ímpar dc da­ dos, por meio dc um componente de confiança. Só pode ser

aplicada se houver alguma forma de redundância.

A seguir, na Figura 1.16, veja um exemplo de um bloqueio feito por voting. Figura 1.16 Bloqueio por voting.

Output

Fonte: Kelly (2008, p. 29).

Usabilidade A usabilidade se preocupa com o quão fácil é para o usuário acompanhar as tarefas do sistema e o tipo de usuário suportado por ele, sendo o meio mais barato e prático para conferir qualidade ao seu sistema. A usabilidade compreende as seguintes áreas: Aprender as características do sistema - se um usuário não é familiar com alguma particularidade do sistema, como o sistema pode tornar a realização da tarefa mais fácil para ele? Um bom exemplo disso são as notas explicativas ao usuário na interface do sistema. Usar o sistema com eficiência - o que o sistema pode fazer para que o usuário tire o máximo de proveito dele? Minimizar o impacto de erros - o que o sistema pode fazer para que, caso o usuário cometa algum erro, esse impacto seja o menor possível? Adaptar o sistema às necessidades do usuário - como o sistema pode se adaptar ao usuário (e vice-versa) para que as operações sejam facilitadas? Um exemplo disso seriam as

Introdução à arquitetura de software

47

sugestões dc sites que aparecem quando vocc começa a digi­ tar uma URL na barra apropriada em seu navegador. Aumentar a confiança e a satisfação - o que o sistema pode fazer para dar confiança ao usuário que o utiliza?

Cenário Veja o Quadro 1.11, que resume as características do cenário

de usabilidade. Quadro 1.11 Características do cenário de usabilidade.

Possíveis valores

Partes do cenário

Fonte de estímulo

Usuário final (possivelmente alguém familiarizado).

Estímulo

Usuário final tenta usar o sistema de modo eficiente, aprender a usar o novo sistema, minimizar possíveis erros, adaptar ou configurar o sistema.

Artefato

0 sistema, ou uma parte específica dele, em que o usuário deve estar interagindo.

Ambiente

Tempo de execução ou configuração.

Resposta

0 sistema deve oferecer informações complementares ao usuário antes que ele precise dessas informações.

Mensuração da

Número de erros.

resposta

Número de tarefas realizadas.

Satisfação do usuário. Ganho de conhecimento do usuário, entre outros.

Fonte: adaptado de Clements, Bass e Kazman (2013, p. 176).

A respeito do Quadro 1.11, podemos dizer que: Fonte de estímulo - o usuário final sempre é a fonte de estí­ mulo para a usabilidade. Estímulo - o estímulo sempre é o que o usuário final deseja, mi­ nimizando erros, se familiarizando com o programa, entre outros. Artefato - o artefato sempre c o sistema como um todo, ou a parle do sistema que o usuário interage. Ambiente - as ações de usabilidade sempre ocorrem em tem­ po de execução ou em tempo de configuração. Resposta - o sistema sempre deve prover o usuário final com características de usabilidade que antecipem suas ações. Mensuração da resposta - a mensuração considera o tempo de realização de tarefa, o número de erros, a satisfação do

usuário, o ganho de conhecimento por parte do usuário, entre outros aspectos.

48

Arquitetura para computação móvel

A Figura 1.17 exemplifica esse cenário. Nela, o usuário baixa um programa e se familiariza com ele em menos dc dois minutos. Figura 1.17 Exemplo do cenário de usabilidade.

Fonte

Estímulo

Artefato:

Resposta

Mensuração da resposta

Sistema

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 177).

Táticas A usabilidade está concentrada na relação usuário-sistema, dessa forma, podemos separar os termos iniciativa do usuário,

iniciativa do sistema e iniciativa mista. Por exemplo: o usuário decide cancelar uma operação - isso é uma iniciativa do usuá­ rio. Durante o cancelamento, o sistema apresenta um indicador de

progresso - isso é uma iniciativa do sistema. Assim, o processo de

cancelamento é uma iniciativa mista.

Veja, a seguir, a Figura 1.18 que apresenta o diagrama dessa relação. Figura 1.18 Táticas de usabilidade.

Desfazer

Modelo de usuário

Pausar/ retornar

Modelo de sistema

Agregar

Fonte: adaptada de Clements, Bass e Kazman (2013, p. 181).

Introdução à arquitetura de software

Para nos aprofundarmos cm cada uma dessas duas áreas dc

interação, devemos fazer as seguintes considerações:

Iniciativa do usuário Sempre que um sistema é executado por um usuário, a usabili-

dade deve fornecer um feedback para que o usuário tome as deci­

sões correias. Todas as situações a seguir, por exemplo, fornecem relatórios aos usuários para tornar a experiência mais eficiente.

Cancelar - quando um usuário escolhe cancelar uma ação, o sistema deve responder. Qualquer recurso que estava cm uso deve ser liberado para que os componentes que serão utili­

zados para o cancelamento realizem as tarefas correiamente.

Desfazer - o sistema deve ter memória o suficiente para quan­

do o usuário selecionar uma opção de desfazer uma determi­ nada ação, o sistema poder recuperar a última etapa salva. Pausar/Retornar - quando o usuário realiza uma tarefa de longa duração, ele pode escolher pausar a operação. Isso sig­ nifica que o sistema deve ser capaz de liberar, temporaria­

mente, todos os recursos que estavam em uso.

Agregar - quando o usuário precisa realizar uma tarefa repe­ tidas vezes, ele tem a opção dc agregar elementos c realizar a

tarefa apenas uma vez. Por exemplo: você não muda a fonte dc um texto digitado letra por letra. Você seleciona todas as

palavras desejadas c faz apenas uma alteração, que é aplicada

a todos os elementos. Iniciativa do sistema Quando o sistema recebe uma iniciativa, ele precisa ter como

base um modelo de usuário. Cada tipo de entrada do usuário ca­

racteriza um modelo diferente. A seguir, você tem uma lista com os principais modelos c seus enquadramentos para identificar e

adaptar o software ao comportamento do usuário final.

Modelo de tarefas - o modelo dc tarefas é utilizado pelo sis­ tema para determinar o que o usuário está fazendo, para que, então, ele possa ajudá-lo. Por exemplo, o sistema pode per­

ceber quando é a hora de colocar uma letra maiuscula e fazer

isso por você automaticamente (quando você troca de linha

ou coloca um ponto final em um editor de texto, por exemplo, o sistema sempre vai colocar a letra seguinte em maiuscula, sem que você precise se preocupar com isso).

49

50

Arquitetura para computação móvel

Modelo de usuário - conhecimento do usuário sobre o sis­ tema, e o comportamento dele em relação ao tempo de com­

portamento do sistema esperado.

Modelo de sistema - modelo do sistema por ele mesmo, uti­

lizado pelo sistema para prever comportamentos futuros. Por exemplo, uma barra de carregamento ou de download.

Checklist A seguir, o Quadro 1.12 apresenta um checklist de análise e suporte do processo de usabilidade. Quadro 1.12 Checklist do processo de usabilidade.

Checklist

Categoria Atribuição de responsabilidades

Garantir que o sistema se responsabilize:

pelo aprendizado de como usar o sistema; por informações eficientes sobre sua usabilidade;

pela adaptação da configuração; pela recuperação de erros do usuário e do sistema.

Modelo de coordenação

Determinar quais propriedades do programa serão utilizadas para facilitar a experiência do usuário com o novo programa. Por exemplo: quando o usuário interagir com o mouse em determinada parte do sistema, ou em

determinados botões, informações explicativas podem surgir em tempo

de execução.

Modelo de dados

Determinar o maior número possível de dados relacionados a possíveis

comportamentos da perspectiva do usuário. Mapeamento

Determinar quais partes do mapa de arquitetura serão visíveis ao usuário final.

entre elementos

Essas partes que ficarão expostas devem ser organizadas visualmente para

arquiteturais

facilitar a navegação do usuário pelo programa.

Gestão de recursos

Determinar o quanto o usuário pode modificar e configurar o sistema e seus

recursos para enriquecer sua experiência com o programa. Tempo obrigatório

Garantir que o usuário tome decisões que não interfiram na usabilidade satisfatória do sistema.

Escolha de tecnologia

Questionar se a tecnologia usada auxilia na experiência do usuário. Por exemplo: há suporte on-line? 0 programa coleta feedbacks do usuário? Quão"usáveré a

tecnologia escolhida?

Garantir que a tecnologia utilizada não atrapalhe a experiência do usuário. Fonte: adaptado de Clements, Bass e Kazman (2013, p. 181 -182).

Introdução à arquitetura de software

51

Outros requisitos Em relação à variabilidade, temos:

Forma especial de “modificabilidade”.

Refere-se à habilidade de um sistema de suportar artefatos e requerimentos diferentes uns dos outros na questão de forma. Seu objetivo é tornar mais fácil a construção e o tratamento

de produtos em um período de tempo estabelecido. Em relação à portabilidade, temos:

Também é uma forma especial de “modificabilidade".

Refere-se à facilidade de cada software em criar e transitar entre plataformas, sendo utilizada para evitar dependências.

Exercícios de fixação 1.

2.

3.

Explique as semelhanças e/ou diferenças entre a arquitetura de software e a arqui­ tetura de construção civil. Discuta sobre de que maneira a arquite­ tura de software pode ser útil como base de análise do seu sistema. Explique a relação contida no diagrama a seguir, que apresenta os elementos: 4. Negócios

Técnico Projeto

Profissional

I__ _1___ I 5. Stakeholders

Arquiteto

Sistema

Fonte: Clements, Bass e Kazman (2013, p. 56).

a. Negócios b. Técnico c. Projeto d. Profissional e. Stakeholders f. Arquiteto g. Arquitetura h. Sistema Explique o contexto técnico de arquite­ tura de software e como ele influencia uma estrutura organizacional. Qual é a importância da interoperabili­ dade? Descreva um sistema on-line que usaria esse conceito.

52

Arquitetura para computação móvel

Estudo de caso O perigo mora on-line Em pesquisa realizada pelo Trend Micro, e di­ vulgada pelo site CanalTech, o Brasil é líder mundial em sites mal intencionados que dis­ tribuem malwares por computadores afora. Segundo a pesquisa, quase 89% de todos os sites mal intencionados da rede são de do­ mínio brasileiro. O segundo colocado são os Estados Unidos, com quase 3%, seguido pelo Japão, com quase 2% dos sites maliciosos. Esses sites, especialidades brasileiras, alteram as configurações DNS dos roteadores - sejam eles quais forem. Uma vez que isso acontece, o usuário não tem como saber se está navegan­ do em um site totalmente confiável ou se está interagindo com uma cópia fiel do mesmo. Isso ocorre com grande frequência em sites que necessitam de autorização pessoal para serem acessados, como serviços de e-mail, in­ ternet banking, entre outros. Isso porque infor­ mações valiosas podem ser retiradas desses sites: um simples deslize e o seu saldo pode

ficar negativo da noite para o dia. A causa? Um invasor no seu acesso ao banco pela internet. É bom notar que você pode usar algumas tá­ ticas para evitar tais ataques. A mais simples é utilizar sempre senhas fortes - combinações de números e letras. Se possível, variar entre letras maiúsculas e minúsculas e, ainda, usar caracteres especiais, como #, $, % ou *. Utilizar endereços de IP diferentes e desativar as opções de monitoramento remoto da sua máquina também são atitudes válidas, assim como trocar as configurações DNS do seu roteador. Também vale a pena verificar se os sites que você frequenta, seja no desktop ou no celular, já que muitos sites já possuem versões móveis para dispositivos menores, possuem um certi­ ficado SSL de segurança válido. Se esse certifi­ cado for exibido e for válido, siga tranquilo: o site é realmente seguro. Fonte: Brasil (2015).

REFLITA! Ataques provenientes de uma fonte externa não afetam apenas computadores pessoais. Muitas empresas precisam se proteger fortemente contra intrusos, que podem tentar invadir seus sistemas em benefício próprio. E, de fato, elas sofrem essas tentativas. Elabore um cenário em que um invasor tenta acessar um sistema que contém todas as movimentações de uma empresa de médio porte. Esse invasor tenta usar senhas aleatoriamente até que uma delas é correta. a. O sistema vai liberar o acesso depois de quantas tentativas falhas? b. Como o sistema vai perceber que aquilo é uma fraude? c. Como o sistema vai reagir a esse ataque?

Introdução à arquitetura de software

53

Na mídia NETFLIX - Filmes, séries e muito mais. Sem limites A Netflix é um serviço de transmissão online que permite aos clientes assistir a uma am­ pla variedade de séries, filmes e documen­ tários premiados em milhares de aparelhos conectados à internet. Com a Netflix, você tem acesso ilimitado ao nosso conteúdo, sempre sem comerciais. Aqui você sempre encontra novidades. A cada mês, adicionamos novas séries de TV e filmes.

1. Acesso à Netflix Após abrir o aplicativo ou o site da Netflix, bas­ ta selecionar Entrar (Sign In) para acessar sua conta e começar a assistir aos seus filmes e sé­ ries. Você pode assistir à Netflix em qualquer aparelho compatível e até em mais de um ao mesmo tempo! Se você ainda não tiver o apli­ cativo Netflix, pode baixá-lo.

2. Criação de perfis É possível criar perfis para cada pessoa que mora com você. Assim, cada um tem uma experiência personalizada na Netflix. Sua conta pode ter até cinco perfis individuais, e cada um desses perfis pode ter um nível de maturidade diferente. Cada perfil terá suas próprias recomendações de acordo com as classificações e preferências pessoais.

3. Gerenciamento da conta Você pode atualizar as informações da sua conta quando quiser, alterando seu e-mail, número de telefone ou até mesmo o plano de assinatura. Para isso, basta selecionar a opção Conta (Account) no menu Netflix. Na página "Conta" (Account), também é possível

ajustar controles de conteúdo, como qualida­ de da reprodução, idioma e legendas.

4. Plano de transmissão da Netflix A Netflix disponibiliza três planos de trans­ missão para atender ao seu estilo. O plano escolhido determina em quantos aparelhos você pode assistir à Netflix ao mesmo tempo. Qualquer que seja o plano escolhido, você po­ derá instalar o aplicativo da Netflix em quan­ tos aparelhos desejar e desfrutar de quantas séries e filmes quiser, quando quiser e onde quiser. O plano básico permite que você assista às séries e filmes da Netflix em um aparelho por vez em definição padrão (SD). Esse plano também permite que você baixe os títulos para um telefone ou tablet. O plano padrão permite que você assista às séries e filmes da Netflix em dois aparelhos ao mesmo tempo e, quando disponível, em alta definição (HD). Esse plano também permite baixar os títulos para dois celulares ou tablets. Já o plano premium permite que você assista às séries e filmes da Netflix em quatro aparelhos ao mesmo tempo e, quando disponível, em alta definição (HD) e ultra-alta definição (UHD). Esse plano também permite baixar os títulos para quatro celulares ou tablets.

5. Como encontrar filmes e séries Para encontrar sua próxima maratona, pes­ quise os títulos que sejam do seu interesse ou navegue pelas nossas sugestões. Depois que você começar a assistir e a avaliar os títulos,

54

Arquitetura para computação móvel

as nossas recomendações vão sugerir cada vez mais títulos que correspondem às suas preferências. Você também pode ativar legen­ das, legendas ocultas ou áudio alternativo em diversos títulos ou navegar pelos títulos que atendem às suas preferências de idioma de legendas ou áudio.

5.7 Recomendações A Netflix usa diversos métodos para ajudá-lo a encontrar séries e filmes para assistir. Você pode encontrá-los nas "Recomendações" (Re­ commendations), usando a busca ou navegan­ do pelas categorias. Para ajudá-lo a encontrar suas novas séries ou filmes favoritos, a Netflix exibe recomendações em fileiras para que você possa navegar por elas. Entre os exem­ plos de fileiras de recomendações, estão: Em alta (Trending Now), Adicionados recentemen­ te (Recently Added), Séries incríveis (Exciting TV Shows), Comédias (Comedies), Principais esco­ lhas para você (Top Picks For You), Porque você assistiu (Because You Watched)... 5.2 Busca Manual

A Netflix permite que você busque filmes e séries de diversas maneiras, explicadas abaixo. Enquanto faz a sua busca, lembre-se de que: Se o que você está buscando não estiver dis­ ponível, a Netflix sugerirá títulos semelhantes que podem interessantes para você. Se os termos da busca forem muito vagos, a Netflix oferecerá sugestões de pessoas, tí­ tulos, gêneros ou diretores que possam ser relevantes. Em alguns casos, a Netflix pode adicionar um espaço reservado para uma série ou filme que aparece nos resultados de busca, mas ainda

não tem botão de reprodução. Isso geralmen­ te acontece com títulos prestes a serem lança­ dos. Os resultados de busca variam de acordo com o nível de classificação etária do perfil usado. 5.3 Filtros de séries e filmes

Na maioria dos aparelhos, você pode sele­ cionar Séries (TVShows) ou Filmes (Movies) e refinar ainda mais por gênero. Esses filtros ge­ ralmente aparecem na parte superior da tela de aparelhos móveis e navegadores, ou no menu vertical das TVs. Na maioria das TVs, é possível encontrar fi­ leiras de categorias (Categories), na qual você seleciona uma categoria de conteúdo em que tem interesse. Essas categorias tam­ bém são exibidas quando você seleciona a opção Buscar (Search). A Netflix tem fileiras de títulos sugeridos com base nos conteúdos a que você costuma as­ sistir. Essas fileiras mostram mais títulos rela­ cionados e podem mudar de acordo com a frequência que você as usa. Se uma fileira nunca for usada (você não gosta de filmes de terror e nunca clica nessa fileira sugerida), ela será deslocada cada vez mais para baixo até deixar de ser exibida. As fileiras podem variar em função do aparelho usado. As séries e filmes que acreditamos que você gostará são exibidos em destaque. Esses títu­ los geralmente são exibidos na parte superior da tela, com uma grande imagem represen­ tando a série ou filme sugerido. Os resultados sugeridos variam de acordo com o nível de classificação etária do perfil usado. Fonte: NETFLIX Brasil. Disponível em: . Acesso em: 11 abr. 2019.

Introdução à arquitetura de software

55

DISCUTA! Com base nas funcionalidades estabelecidas pela plataforma de streaming de vídeos Netflix em sua página na web, discuta: 1. Dentre os requisitos não funcionais estudados neste capítulo envolvendo inte­ roperabilidade, escalabilidade, performance, segurança e usabilidade, defina alguns exemplos para cada requisito baseado no negócio. 2. Por meio da modelagem de software defina uma arquitetura para esta plata­ forma estabelecendo os módulos existentes para esse negócio. Lembre-se se garantir conceitos de coesão e acoplamento.

Na academia Uma arquitetura de software é uma descrição de como um sistema de software é organizado. Decisões de projeto de arquitetura incluem decisões sobre o tipo de aplicação, a distribuição do sistema, e o estilo de arquitetura a ser usada. As arquiteturas podem ser documentadas de várias perspectivas ou visões diferentes tais como uma visão conceituai, uma visão lógica, uma visão de processo, uma visão de desenvolvimento e uma visão física. Baseado nestes conceitos defina os requisitos da arquitetura para um aplicativo de celular que possibilite a utilização de bicicletas de maneira comunitária em determinado espaço físico, uma região, um bairro, ou um parque. Os usuários visualizam as bicicletas disponíveis e podem utilizá-las por certo período. O usuário deve estar pré-cadastrado no sistema e ao utilizar a bicicleta deve ler um código QR que estará visível na própria bicicleta. Todo o controle do espaço e da utilização da bicicleta será visualizado em um mapa do aplicativo, por meio de GPS.

Recapitulando Nesta primeira unidade, você foi apresentado a diversos conceitos relacionados à arquite­ tura de software, incluindo a sua definição, que basicamente é a de ajudar organizações a atingirem objetivos por meio de soluções e resultados. Você viu ainda os componentes da estrutura da arquitetura de software e também os seus contextos, que não são só necessaria­ mente técnicos, mas também relacionados ao projeto, aos negócios e ao profissional. É quase como um mosaico: são peças que, combinadas, formam um desenho. Se você as recombinar,

formam outro desenho completamente dife­ rente. É assim com a arquitetura de software:,

observá-la a partir da perspectiva dos seus stakeholders é completamente diferente da sua visão como desenvolvedor. Da mesma forma, dependendo do tipo de processo de desenvol­ vimento, haverá interações diferentes entre os profissionais e o cliente. No segundo tema, você aprendeu a aplicar ele­ mentos como disponibilidade, interoperabili­ dade, escalabilidade, performance e segurança. Cada um desses atributos contribui de uma forma

56

Arquitetura para computação móvel

única para o seu sistema, desde a possibilidade de torná-lo mais rápido como mais seguro, estável e imune a ataques e perdas de dados confidenciais. Por mais simples que um sistema possa pare­ cer, ele precisará contar com esses conceitos.

Esperamos que, a partir dos seus estudos nes­ ta primeira unidade, você esteja preparado para analisar os diversos aspectos da arqui­ tetura de software e assim oferecer a melhor solução possível.

PONTOS IMPORTANTES A arquitetura de software é criada e utilizada para ajudar organizações a atingi­ rem objetivos abstratos por meio de um resultado concreto. ■ Podemos dividir a estrutura da arquitetura de um sistema em três partes: ■ Estrutura modular - em que cada módulo é responsável por uma função específica. ■ Componentes e conexões (C&C) - são os elos que conectam os módulos. ■ Estrutura de locação - relacionada à instalação e execução de um sistema. A arquitetura de software pode ser vista por diferentes pontos de vista: ■ técnico; ■ ciclo de vida do projeto; ■ negócios; ■ profissional. ■ No contexto técnico, a arquitetura de software retira ou associa qualidades aos atributos de um sistema, possibilita a previsão de vários aspectos em sistemas de qualidade e facilita a gestão de mudanças. Nessa visão, é preciso considerar a relação entre elementos dos sistemas, prever como eles reagem a erros, atentar à usabilidade do sistema e testar elementos. Existem vários processos de desenvolvimento de software em uma abordagem de ciclo de vida: ■ Waterfall - organiza o ciclo de vida em uma sequência de atividades, sem análise e especificação de requisitos, e cada atividade é relacionada à etapa anterior eà posterior. ■ Interativo - o desenvolvimento é dividido em ciclos curtos, e cada um é respon­ sável por uma função específica e tem o trabalho realizado individualmente. ■ Desenvolvimento dg//- também trabalha com pequenos ciclos, mas com me­ nores intervalos de tempo. ■ Model driven development - o desenvolvimento é definido por meio de mo­ delos de negócios, para que o código seja gerado automaticamente. Em uma arquitetura, é sempre importante: ■ fazer um estudo de caso para o sistema; ■ identificar os requisitos da arquitetura; ■ projeto e criar o modelo da arquitetura; ■ documentar e comunicar a arquitetura; ■ analisar as interfaces;

Introdução à arquitetura de software

■

■

■

■ ■

■

■

■ ■ ■

57

■ implementar e testar o sistema; ■ verificar e validar o software. O contexto de negócios envolve aspectos que nào são necessariamente ligados à programação, como aumentar participação no mercado, manter stakeholders satisfeitos e melhorar a qualidade dos produtos. Já no contexto profissional, são pensadas as habilidades necessárias para um pro­ fissional atuar em um projeto, suas atribuições e o conhecimento necessário para isso. Os requisitos arquiteturais podem ser: ■ Requisitos funcionais - relacionados às funções de um sistema. ■ Requisitos não funcionais - restrições aos serviços ou funções, como tempo, no processo de desenvolvimento ou normas. Funcionalidade é a capacidade do sistema de realizar a sua função. Disponibilidade se refere à capacidade de o sistema reparar erros desde que o pe­ ríodo de interrupções não exceda um valor específico em um período de tempo determinado. Disponibilidade do estado estacionário é o estado em que o sistema fica "parado" e é calculado da seguinte forma: estado estacionário = tmef / (tmef + tmr), em que tref é o tempo médio entre falhas e tmr é o tempo médio de reparo. Interoperabilidade é a capacidade de o sistema trocar informações e dados, em vários graus e entre interfaces (interoperabilidade sintática) e interpretar dados corretamente quando recebidos (interoperabilidade semântica). Escalabilidade é a capacidade de mudança e adaptabilidade de um sistema. Performance é o tempo que o software leva para realizar as suas funções. A segurança de um sistema é composta principalmente pelos itens: confidencia­ lidade, integridade e disponibilidade.

UNIDADE 2

MODELOS E PROJETOS ARQUITETÔNICOS

CONHEÇA Os modelos e os estilos arquiteturais.

REFLITA Sobre a importância de adotar um modelo arquitetural que melhor se aplique ao contexto de um sistema.

DISCUTA Como os padrões de arquitetura de software e como a arquitetura baseada em componentes pode ser aplicada em um projeto.

APLIQUE Os conhecimentos adquiridos e defina a arquitetura de um projeto baseada em componentes.

#DESIGNPATTERNS #COMPONENTIZAÇÃO

#ESTILOSDEARQUITETURA

01 OBJETIVOS DE APRENDIZAGEM Compreender os conceitos de padrões de

arquitetura de software.

Aprender e aplicar os diversos estilos arquitetônicos

abordados.

Compreender e aplicar na prática o

conceito de interação.

Identificaras particularidades da

arquitetura baseada em componentes.

PADRÕES DE PROJETO E ARQUITETURA DE SOFTWARE Quais os pilares da arquitetura de software? O que é um padrão de arquitetura? O que é orienta­ ção a serviços? O que é cliente e servidor? O que é camada? Qual o melhor padrão de arquitetura?

02

ARQUITETURA BASEADA EM COMPONENTES O que são componentes? O que deve ser levado em conta ao se implementar uma arquitetura baseada em componentes? Como chegar a uma boa arquitetura? Quais os princípios fundamen­ tais da arquitetura?

Modelos e projetos arquitetônicos

Q *]

Introdução Nesta unidade, você terá contato com diversos pa­ drões arquitetônicos, suas estruturas e aplicações. Para entender melhor o conteúdo que será tratado, vamos considerar padrões de arquitetura como um meio de organização. Vamos pensar, por exemplo, nas músicas que você ouve em seu smartphone ou em seu computador. Pensando logicamente, podemos ouvir música de várias maneiras: pelo artista, por álbum, pelo ano de lançamento, por gênero musical, ou mesmo em playlists que levam em conta o "clima" da música, como uma lista só com músicas lentas ou músicas para acompanhar seu exercício. O modo de realizar essa organização, portanto, cabe ao ouvinte. Se você tiver acesso a uma bi­ blioteca digital com três artistas, totalizando seis álbuns diferentes, você pode, simplesmente, orga­ nizar a execução das músicas por álbuns. Por outro lado, caso queira escutar as canções de apenas um

artista, pode organizar toda a execução de modo que somente as canções desejadas sejam reprodu­ zidas, e assim por diante. As maneiras de organizar e reproduzir uma biblio­ teca musical são inúmeras. Ainda assim, a finalida­ de é única: escutar as músicas, independente da forma com que você escolheu organizá-las. Com os estilos arquitetônicos não é tão diferente. Isto é, ao criar sua arquitetura, você pode optar por percorrer diversos caminhos que o levarão ao mes­ mo lugar, ou seja, terão a mesma finalidade. O que muda, nesse caso, é que alguns caminhos são mais fáceis que outros, dependendo do tipo de software que você está criando. Aqui, aprenderemos que é possível organizar sua arquitetura utilizando padrões como client/server, SOA, message-bus com foco em camadas e outras táticas. Cada uma delas possui sua particularidade e oferece benefícios.

Padrões de projeto e arquitetura de software Estilos de arquitetura Na unidade anterior, você aprendeu os conceitos básicos e as prin­

cipais etapas para a elaboração de uma boa arquitetura dc software.

Assim, deve-se lembrar que o desenvolvimento de todo e qualquer

sistema é uma interação entre usuários, objetivos e o sistema em si. Em outras palavras, o objetivo da arquitetura de software

é “construir uma ponte entre os objetivos de uma empresa e os recursos técnicos necessários para a construção de um sistema, que devem ser aplicados conforme as necessidades da empresa”

(ME1ER et al., 2009, p. 5). A Figura 2.1 ilustra a relação entre os três pilares da arquitetu­

ra de software, mencionados anteriormente.

62

Arquitetura para computação móvel

Figura 2.1 Pilares da arquitetura de software.

É importante lembrar que a arquitetura de software pode e

deve ser flexível, ou seja, capaz dc adaptar-se a diversos tipos de situações e objetivos. Quando a arquitetura possui essa ca­ racterística, dizemos que ela tem um design flexível. Mas, como

trabalhar para chegar a esse ponto?

Para responder essa pergunta, temos que nos aprofundar em

alguns estilos de arquitetura, também chamados de padrões de arquitetura. Um estilo de arquitetura é uma família de sistemas

trabalhando de uma maneira determinada, organizada dentro de uma estrutura específica. Em linhas gerais, é a forma que a arqui­ tetura vai apresentar, que varia conforme os objetivos do usuário

e/ou organização. Existem quatro áreas principais de estilos de arquitetura, des­ critas no Quadro 2.1. Quadro 2.1 Principais estilos de arquitetura.

Estilo de arquitetura

Categoria

Comunicação

Service-Oriented Architecture (SOA), Message-bus

Implantação

Implantação distribuída e não distribuída, Client/server, Servidores N-Tier e 3-Tier

Domínio

Domain model (Domain Driven Design)

Interação

Entradas e saídas

Soluções

Arquitetura base e arquitetura candidata

Estrutura

Component-Based, Object-oriented, Layered Architecture

Agora que já conhecemos as principais categorias de estilos de

arquitetura, vamos nos aprofundar em cada uma delas.

Modelos e projetos arquitetônicos

Comunicação Service-Oriented Architecture (SOA)

Esse estilo pode ser traduzido, literalmente, como arquite­

tura orientada a serviços, e é baseada no preceito de organiza­ ção em serviços, ou seja, vários sistemas que se comunicam por

i nteroperab i 1 i dade. A troca de informações é feita por meio de protocolos entre os sistemas. Isso possibilita que “clientes e outros serviços [...]

acessem serviços locais rodando na mesma camada, bem como serviços remotos através de redes de conexões” (MEIER et al.,

2(X)9, p. 33). Agora que você sabe que os serviços de um sistema são o foco

do SOA, podemos listar algumas de suas características: Autonomia - cada serviço é desenvolvido, aplicado e man­ tido dc forma independente. Distribuição - cada serviço pode estar alocado cm uma

parte específica do sistema, em bases locais ou remotas. Nesse caso, a única especificação é que o serviço alocado

remotamente atenda aos requisitos dos protocolos de comu­ nicação utilizados. Redução de acoplamento - cada serviço, por ser indepen­ dente, pode ser substituído ou alterado, sem causar danos a

outras aplicações que o utilizam.

Esquemas e protocolos - serviços compartilham esquemas e

protocolos quando se comunicam. Compatibilidade baseada em políticas - políticas significam as regras que os recursos presentes na arquitetura, como trans­

porte de informações, protocolos e segurança, devem seguir.

Para compreender melhor o conceito de vários serviços com

baixo índice de acoplamento, basta imaginar o sistema de um banco. Nesse sistema, podemos encontrar os serviços de saque, abertura de conta, depósitos, pagamentos, saldo, extrato, entre

outros. Cada um desses serviços possui uma interface única. O que muda entre eles são apenas informações necessárias por meio de interoperabilidade. A seguir, veja uma lista de alguns benefícios da utilização da

arquitetura orientada a serviços.

63

64

Arquitetura para computação móvel

Reúso - possibilidade dc utilizar novamente (rcúso) serviços

comuns por meio dc interfaces maiores, possibilitando a re­ dução de custos.

Autonomia versus acoplamento - sistemas são autônomos, se relacionam por protocolos e isso reduz o acoplamento.

Fácil localização - serviços podem expor descrições que permitem a outras aplicações encontrá-los, determinando a interface.

Interoperabilidade - devido à interoperabilidade, o sistema

pode ser desenvolvido e criado em diferentes plataformas. Message-bus Esse estilo dc arquitetura diz respeito à troca dc informações,

com base no uso dc um ou mais canais dc comunicação ou barra-

mento. Ele permite que seu sistema troque informações diferen­

tes por meio de mais de um canal de forma única, ou seja, suas aplicações podem interagir sem a necessidade de ter contato com informações desnecessárias.

Convencional mente o termo bus é traduzido para harramento - exatamente o que faz a comunicação entre as aplicações. En­

tre as habilidades do message-bus, podemos destacar as seguintes capacidades: Comunicação orientada a mensagens - forma de comuni­

cação entre processos, em que todas as comunicações entre O message-bus tem

aplicações são feitas com base em esquemas conhecidos.

sido amplamente

Processamento lógico complexo - operações complexas

utilizado para suportar

podem ser realizadas por meio da combinação dc uma série

processamentos complexos

de operações menores. Cada uma dessas operações tem uma

(MEIER et al. 2009).

tarefa específica, e o conjunto dessas pequenas tarefas e de

suas trocas de informações formam uma operação maior e, portanto, complexa.

Modificação de processamento lógico - as interações feitas por meio do message-bus são baseadas em esquemas e co­ A implementação

mandos similares. Sendo assim, basta adicionar ou remover

mais comum do

aplicações no processo para mudar a lógica com a qual os

message-bus é o

serviços vão operar.

roteamento de mensagens

Integração com ambientes diferentes - por meio do message-

(MEIER et al, 2009).

-bus, é possível interagir com aplicações desenvolvidas cm am­

bientes diferentes.

Modelos e projetos arquitetônicos

Dentre os benefícios dc utilizar o modelo message-bus, pode­ mos destacar: Extensibilidade - aplicações podem ser adicionadas ou remo­

vidas dos barramentos sem afetar outras aplicações existentes. Baixa complexidade - a complexidade de comunicação é

baixa, já que cada aplicação precisa saber como se comunicar apenas com o barramento, de modo que o message-bus fará

o resto do trabalho. Flexibilidade - considere que uma aplicação faz parte de um

processo complexo. Essa aplicação pode ser alterada facil­

mente por meio dc um novo requerimento, que c adicionado nos parâmetros dc controle dc roteamento dc informações. Baixo acoplamento - o que entra cm contato com o barramen­

to é a interface da aplicação. Isso significa que ela pode ser alte­

rada sem causar danos a outros elementos do sistema. De falo, o índice de acoplamento cai com o uso de barramentos. Escalabilidade - uma aplicação pode ter várias instâncias no mesmo barramento, implicando na possibilidade de requisi­

ções simultâneas a uma aplicação. Aplicação simples - embora a implementação do message-

-bus aumente a complexidade da estrutura, cada aplicação precisa manter apenas uma conexão com ele, em vez de man­

ter uma conexão com cada uma das outras aplicações, facili­

tando a criação dc estruturas complexas. Existem, ainda, algumas variações do message-bus. São elas:

Enterprise Service Bus (ESB) - utiliza serviços para a co­

municação entre o barramento e seus componentes. Um ESB também faz uso de serviços para transformar mensagens de

um formato para outro. Isso significa que dois clientes po­

dem se comunicar em formatos incompatíveis sem perda de performance. Internet Service Bus (ISB) - bastante similar ao ESB. mas,

neste caso, o ISB compreende aplicações em um host na nuvem.

Implantação Como já vimos, a escolha de um tipo de design de arquitetu­ ra leva em consideração muitos fatores, como necessidades das

65

66

Arquitetura para computação móvel

organizações, cenários, entre outros. Mas independentemente do

design que escolher, ele deverá ser implantado. Para isso, a implantação (deployment) também deve conside­

rar o ambiente físico da organização e suas limitações. Primeiro

deve-se identificar as restrições do seu design para escolher uma

estratégia de implantação. Ao optar por uma estratégia ficar atento

aos seguintes pontos:

1.

Compreender o ambiente físico de implantação.

2.

Compreender as limitações arquiteturais e de design para o ambiente de implantação.

3.

Compreender que a segurança c a performance impactam di­

retamente cm seu ambiente dc implantação. Implantação distribuída c não distribuída Ao criar o seu ambiente de implantação, primeiro, deve identi­ ficar se sua aplicação consiste em processos simples ou complexos.

Esse é um fator fundamental que determina se sua implantação

será distribuída ou não.

Considere que você está construindo uma aplicação com base

em intranet para uma organização. O número de acessos a esse sistema é finito, pois diz respeito apenas aos funcionários da or­

ganização em questão. Nesse caso, é recomendada a utilização de

uma implementação não distribuída. Aqui, todas as camadas compartilham o mesmo hardware. Essa abordagem minimiza o número de servidores, sendo um mo­

delo simples que também diminui o impacto quando a comunica­ ção entre camadas deve utilizar meios físicos entre servidores. A

Figura 2.2 exemplifica esse modelo. Figura 2.2 Implementação não distribuída.

Fonte: Meier et al. (2009, p. 240).

Modelos e projetos arquitetônicos

Por outro lado, você deve ficar atento: se todas as camadas

compartilham os mesmos recursos (o mesmo servidor), então uma camada pode afetar negativamente todas as outras.

Se você estiver trabalhando com um sistema maior, pode dividi-lo em servidores específicos. Aqui, o modelo de implementação distribuída seria o ideal.

Nesse modelo, as camadas da aplicação residem em camadas

separadas fisicamente. Isso proporciona ambientes e servidores exclusivos, especiais para cada operação e requisito do sistema. Você pode separar suas aplicações em vários níveis físicos, con­

forme a Figura 2.3. Figura 2.3 Implementação distribuída.

Fonte: Meier et al. (2009, p. 241).

Como já dito, esse modelo permite que você direcione os servidores para as camadas específicas, otimizando a aplicação. “Quanto mais camadas você usa, mais opções dc implementação você tem para cada componente” (ME1ER et al., 2009, p. 241).

Outro ponto positivo é a possibilidade dc desenvolver uma

aplicação com mais segurança. Ou seja: quanto mais flexível, quanto mais servidores específicos sua aplicação tiver, mais rigo­

rosa pode ser a segurança, já que existem diversos tipos de auten­

ticações e autorizações que podem ser aplicadas entre servidores. Por outro lado, tenha em mente que quanto mais camadas físi­ cas criar, maior será a complexidade do projeto, além do custo e

do esforço de implementação serem maiores. Client/server

O estilo arquitetônico client/server caracteriza-se como um tipo de arquitetura dc aplicação. Nela, “um ou mais dispositivos

67

68

Arquitetura para computação móvel

clientes solicitam informações a um servidor. O servidor cm geral responde com as informações solicitadas” (LEE; SCHNEIDER;

SCHELL, 2005, p. 23).

A seguir, temos um exemplo básico do processo de uma arqui­

tetura client/server na Figura 2.4. Figura 2.4 Arquitetura client/server.

Servidor(es)

BD

Solicitação

Resposta

420^. Cliente(s)

Fonte: Lee, Schneider e Schell (2005, p. 24).

A arquitetura client/server faz uso de camadas e filas. Vamos compreender melhor esses dois conceitos adiante. Em relação às camadas, o código de aplicação do seu software

nem sempre irá lidar com todos os processos do programa em si.

Por exemplo: algumas seções dos seus códigos vão lidar apenas

com o relacionamento com o usuário final por meio da interface; já outras seções podem ser responsáveis por captar entradas ou

gerenciar a lógica do negócio, entre outras funções. São muitas as possibilidades. Pensando nessa pluralidade dc opções que devemos aplicar a

divisão cm camadas, elas são subdivisões dc trabalhos dentro dc um mesmo código dc aplicação, que pode ser feita tanto no cliente quanto no servidor. Do ponto de vista do cliente, geralmcnte são aplicadas de zero

a três camadas de código. Já no servidor, de uma a três camadas. Não são números fixos, mas representam um bom projeto de soft­

ware. Você pode colocar mais camadas, tanto no cliente quanto no

servidor. Mas lembre-se que camadas demais podem dificultar a manutenção e o gerenciamento do seu programa.

A camada mais próxima do usuário final geralmente é cha­ mada de camada de apresentação. A camada seguinte, que trata

Modelos e projetos arquitetônicos

da lógica, é chamada dc camada de negócios. A terceira e última parte, a camada de acesso a dados, tem como função realizar a

comunicação com o banco de dados (Figura 2.5). Figura 2.5 Camadas.

Camadas

■ 1 - apresentação ■ 2-negócios 13- acesso a dados

Fonte: Lee, Schneider e Schell (2005, p. 24).

Já para trabalharmos com filas, devemos utilizar diversas máquinas. Isso torna a arquitetura escalável, o que não seria

possível utilizando apenas as camadas. Em outras palavras,

“a segmentação em filas geralmente envolve a colocação de

módulos de código em máquinas diferentes num ambiente de servidores distribuídos” (LEE; SCHNEIDER; SCHELL, 2005,

p. 25). Aqui, o código com mais proximidade de interação com o usuário é colocado na fila de apresentação. A lógica de negócio

de aplicação é colocada na segunda fila, chamada de aplicação. Já a terceira fila costuma abrigar o banco de dados em si ou a

fonte dos dados, chamada fila de banco de dados (Figura 2.6). Figura 2.6 Filas.

Filas

■ 1 - apresentação

• 2-aplicação

■ 3 - banco de dados

Fonte: Lee, Schneider e Schell (2005, p. 25).

Clientes Dispositivos móveis (para os quais você cria aplicações), como

smartphones, tablets, laptops, entre outros, podem ser divididos

entre clientes magros e clientes gordos.

69

70

Arquitetura para computação móvel

Os clientes magros (Figura 2.7) apresentam as seguintes

características: Costumam compreender uma única camada e não apresen­

tam código de aplicação personalizado. Dessa forma, depen­ dem total mente do servidor. Utilizam navegadores de web e WAP para exibir conteúdos como: HTML e XML (web); ou WML (WAP).

Alterações e manutenções são mais fáceis em clientes ma­ gros, justamente pela ausência de códigos de aplicações

personalizados. Figura 2.7 Cliente magro sem camadas.

Cliente móvel: (Nenhuma camada)

A aplicação não possui código

Possivelmente: Navegador web

Navegador WAP

A

V

Para a rede e o back-end

Fonte: Lee, Schneider e Schell (2005, p. 26).

Os clientes gordos (Figura 2.8) são caracterizados pelos se­

guintes elementos: Geralmente, possuem entre uma e três camadas. É recomen­ dável usar esse tipo de cliente quando a comunicação entre

cliente e servidor é baixa - uma vez que esse tipo de clien­ te consegue ser independente do servidor por algum tempo.

Por exemplo: se a conexão com o servidor for perdida, esse

Modelos e projetos arquitetônicos

cliente consegue armazenar entradas no banco dc dados até

que a conexão se restabeleça e seja possível transferir essas entradas para o servidor adequado. Justamente por depender menos do servidor, esse cliente vai se basear no sistema operacional e no tipo de dispositivo em

que será usado. Você pode usar até três camadas, mas o mais

recomendável é o uso de três, uma vez que, assim, você pode reutilizar o que for possível do código de aplicação. Figura 2.8 Cliente gordo - três camadas.

Fonte: Lee, Schneider e Schell (2005, p. 28).

Servidores n-tier e 3-tier

Ao criar uma aplicação em várias camadas, significa que você está usando uma aplicação n-tier. “N” porque as camadas lógicas criadas podem ser inúmeras. Aqui, cada segmento pode ser aloca­

do em unidades físicas diferentes, com seus próprios servidores,

unidos por meio dc uma rede. Um dos modelos mais famosos é o 3-tier, ou modelo cm três

camadas, bastante utilizado cm casos dc aplicações web, cm que a segurança é primordial. Nessa situação, teremos três camadas:

71

72

Arquitetura para computação móvel

1.

Interface com o usuário - apresentação (P).

2.

Lógica de negócios - negócios (B).

3.

Banco de dados - acesso a dados (D). A Figura 2.9 ilustra essa lógica.

Figura 2.9 Arquitetura de três filas.

Servidor de

Servidor de

P = Apresentação B = Negócios

D = Acesso a dados Fonte: Lee, Schneider e Schell (2005, p. 33).

Dentre os pontos positivos de utilizar esse método, os princi­

pais são:

Manutenção - isso é possível porque você separa as camadas em servidores independentes. Assim, as alterações realizadas em uma delas não acarretam mudanças nas outras camadas, e

não afetará o sistema como um lodo. Escalabilidade - os níveis são baseados nos níveis dc cama­

das, fazendo com que dimensionar aplicações seja relativa­ mente simples. Flexibilidade - isso acontece porque cada camada é geren­ ciada individualmente. Disponibilidade - já que aplicações são facilmente escaláveis, a disponibilidade aumenta.

Outras características próprias do n-tier e 3-tier são:

Modelos e projetos arquitetônicos

baixo custo dc disponibilização, manutenção dc dados c mu­ dança dc lógica de negócio; armazenamento otimizado;

reutilização de recursos.

Domínio Domain model Domain model, ou Domain Driven Design (DDD), é uma

abordagem de desenvolvimento que projeta o seu software basea­ do no domínio de negócios. Geralmente, quem aplica esse modelo precisa ter um conheci­ mento profundo do negócio no qual atua. Em função disso, é co­

mum encontrarmos o arquiteto, o desenvolvedor e um especialista no negócio atuando juntos.

O núcleo do software é o modelo de domínio, que contém

uma linguagem comum compartilhada. Isso faz com que a equi­ pe encontre lacunas no software rapidamente. Em outras pa­ lavras, isso facilita a comunicação entre os elementos da sua

aplicação. Aplicar o Domain Driven Design pode resultar em um custo

elevado. Exatamente por isso (e por facilitar a manutenção do seu software) é recomendável a utilização desse modelo apenas em

aplicações complexas. Meier et al. (2009) enumeram os Ires principais benefícios que

o sistema Domain Driven Design oferece, são eles:

1.

Comunicação - todas as partes dentro de uma equipe de desenvolvimento podem usar o modelo de domínio e suas

entidades. Esse uso é útil para comunicar conhecimentos e requisitos, utilizando uma linguagem de domínio comum de

negócios, sem a necessidade de termos técnicos. 2.

Extensibilidade - muitas vezes, o modelo de domínio é mo­

dular e flexível. Isso os torna mais fáceis de serem atualiza­ dos e estendidos, conforme os requisitos e as condições são alterados.

3.

Testabilidade - os objetos do modelo de domínio possuem

baixo acoplamento e alta coesão, permitindo que sejam testa­ dos com maior facilidade.

73

74

Arquitetura para computação móvel

Alguns dos pontos positivos para a utilização do Domain Driven Design são:

Facilita a compreensão e a comunicação de domínios com­ plexos dentro da sua equipe de desenvolvimento. Em função da utilização dessa abordagem, a linguagem utili­ zada por todos os envolvidos no projeto é unificada. Simplifica o gerenciamento dc processos e, consequentemente,

a manutenção deles.

Interação Técnicas interativas ajudam a potencializar sua arquitetura,

deixando-a mais próxima possível dos seus objetivos. Para isso, vamos rever alguns conceitos já estudados, em um total de cinco etapas que serão explicadas detalhadamente adiante.

Entradas e saídas As entradas, ou inputs, ajudam a formalizar os requerimentos e as restrições que a arquitetura deve conter, como requisitos funcio­

nais, não funcionais, atributos de qualidade, segurança, confiabili­ dade etc. Para isso, vamos seguir os seguintes passos:

1.

Identificar os objetivos da arquitetura - objetivos claros

ajudam a concentrar sua arquitetura em soluções mais rápi­ das c eficazes. 2.

Identificar os principais cenários - um cenário principal é o local em que sua aplicação deve concentrar as informações mais importantes.

3.

Criar uma visão geral do aplicativo - para que o software

seja adequado ao seu propósito, é fundamental identificar o

tipo de aplicação, a arquitetura de implantação, os estilos, as tecnologias etc.

4.

Identificar os pontos principais - identificamos os pon­

tos principais do nosso design com base nos atributos de qualidade.

5.

Definir as soluções - resolução dc problemas, atua na me­ lhora, na solução e na avaliação de cenários e problemas de

implementação.

Modelos e projetos arquitetônicos

Para compreender melhor o processo descrito, veja a Figura 2.10. Figura 2.10 Etapas da interação.

Fonte: Meier et al. (2009, p. 38).

Agora que já sabemos quais são as cinco etapas necessárias,

vamos nos aprofundar em cada uma delas. Identificar os objetivos da arquitetura O objetivo de uma arquitetura é a sua finalidade e as suas limi­

tações. Para identificar os objetivos de uma arquitetura, existem

três pontos-chave que podem ajudar:

75

76

Arquitetura para computação móvel

1.

Identificar os objetivos da arquitetura no início - o tempo

investido cm cada etapa da elaboração da arquitetura depende dos seus objetivos. Por exemplo, se você está criando um pro­

tótipo, o que pode ser mais útil, o teste constante de elemen­ tos ou um processo de arquitetura de longa duração?

2.

Identificar quem será o consumidor - questionar se seu

projeto será utilizado por outros arquitetos, desenvolvedores ou testadores. Saber quem será o usuário muda a forma final

com que a sua arquitetura será apresentada, para ser sempre acessível a quem será o seu usuário.

3.

Identificar as restrições - compreender e respeitar as condi­

ções da sua arquitetura o mais cedo possível, evitando surpre­

sas desagradáveis no futuro. Identificar os principais cenários

Considerando-se arquitetura e design, podemos classificar um

caso de uso como a relação das interações dc um ou mais usuários

com o sistema. Lembre-se dc que esse usuário c chamado, nas descrições c na linguagem técnica, dc ator. Os atores podem ser O objetivo dos cenários-chave

tanto um usuário físico, ou seja, uma pessoa, ou outro sistema.

"é alcançar um equilíbrio

Já um cenário é a descrição dc maneira mais ampla da relação

entre os objetivos do usuário, do negócio e do

ator/sistema, representando um panorama geral, c não um cami­

sistema" (MEIER et al., 2009,

nho específico que essa relação contém.

Definir cenários-chave na elaboração da sua arquitetura torna

p. 41). Essa relação pode ser observada na Figura 2.1, no início desta unidade.

esse processo - e o resultado final - mais preciso. De modo geral, esses recursos auxiliam na escolha de decisões na fase de criação.

Os cenários-chave compreendem uma ou mais das seguintes características:

■

problema a ser resolvido;

■

caso dc uso significativo; interseção dc atributos dc qualidade e funcionalidade;

■

compromisso entre atributos dc qualidade. Por exemplo, um cenário de autenticação de usuário poderia

ser considerado um cenário principal. Isso porque há:

■

atributo de qualidade (segurança); funcionalidades (entradas do usuário ao sistema);

interação entre atributo de qualidade e funcionalidades.

Modelos e projetos arquitetônicos

Casos de uso significativo são aqueles que terão um im­ pacto maior na sua arquitetura e design, dividindo-se cm duas categorias: Negócio crítico - o caso de uso tem alta frequência. Também

pode ser considerado como de grande importância para ou­

tras áreas do sistema, mesmo que indiretamente. Alto impacto - o caso de uso cruza com funcionalidades e

qualidades de atributos. Criar uma visão geral do aplicativo O objetivo dessa etapa é criar uma visão geral da sua aplica­ ção. Isto é, você vai revisar seu software sempre com o intuito

de tornar a arquitetura mais acessível e compatível com o mundo real. Lembre-se de que isso é a chave para uma boa interação ator/

sistema - ainda mais quando o ator representa uma pessoa. Para atingir tais objetivos, veja as seguintes dicas:

Determine o tipo de aplicação - responder algumas per­ guntas facilitam o processo de desenvolvimento, assim como: o que você está desenvolvendo? Qual é o tipo de software? É uma aplicação móvel? Uma aplicação on-line,

para a internet? É uma junção desses dois tipos? Muito ou

pouco detalhado? Identifique as restrições de aplicação - além de conside­

rar itens importantes como segurança e confiabilidade (na

questão do design), você precisa estar atento a outros tipos de restrições. Por exemplo, ao desenvolver uma aplicação

para uma organização rígida, o design e a arquitetura do software devem estar dc acordo com os parâmetros da em­

presa. Ou seja, nessa etapa, o diálogo com o usuário final do sistema c o conhecimento da infraestrutura c da lógi­ ca do ambiente em que ele será implantado é de grande

importância. Identifique o estilo arquitetônico mais adequado - mais uma vez, você deve considerar possibilidades e decidir o me­

lhor estilo arquitetônico, principalmente por meio de análises do ambiente em que a aplicação será implantada e da sua finalidade. Isto é, você desenvolverá sua arquitetura através

de SOA, client/server, ou message-bus1!

77

78

Arquitetura para computação móvel

Escolha a tecnologia mais apropriada - agora que você

definiu o tipo de aplicação e o estilo arquitetônico, deve escolher a tecnologia que mais se adequa aos padrões

desejados. Lembre-se de que a tecnologia que vai ao en­ contro do seu projeto deve sempre complementá-lo. Por

exemplo, se você criasse um aplicativo para dispositivos

móveis, poderia usar o Mobile Applications. Com isso, você teria acesso a tecnologias de apresentação de cama­

das, como .NET Compact Framework, ASP, Silverlightfor

Mobile, entre outros.

Identificar os pontos principais

Alguns erros podem acontecer durante a elaboração da sua aplicação. Para isso, existem algumas perguntas que você pode

fazer - c aplicar no projeto - para localizar, corrigir c evitar falhas. Por exemplo: Eu posso trocar de serviços sem grandes problemas?

Minha aplicação suporta novos clientes? Minha aplicação está preparada para eventuais mudanças tec­ nológicas, upgrades e afins? Verificar espaçamento.

Mesmo que esses fatores sejam dc teor generalizante, eles

implementam os atributos de qualidade. Esses atributos afetam o tempo de execução e o comportamento do seu programa. Uma

combinação bem-feita de atributos de qualidade (como usabilida­ de, segurança, confiabilidade, desempenho etc.) garante um bom

software. Não existem modelos dc combinações e prioridades dc atributos predefinidos, isso varia conforme o tipo de software que você cria e domínio de negócio da aplicação.

Alguns atributos dizem respeito à funcionalidade geral do sis­ tema. Outros possuem funções específicas em tempo de execução,

design, ou cm determinadas áreas do projeto.

A seguir, você verá uma lista com os principais atributos para ajudá-lo a decidir qual é o melhor momento para utilizá-los. Atributos de qualidade do sistema - refere-se às qualidades geral de todo o sistema. Podemos tomar como exemplo o su­

porte ou a testabilidade.

Modelos e projetos arquitetônicos

Atributos de qualidade de tempo de execução - qualidade

do sistema apenas em tempo dc execução. Aqui, bons exem­

plos seriam a disponibilidade, a interoperabilidade, a escala­ bilidade, a confiabilidade e outros atributos que influenciam

diretamenle a execução do software. Atributos de qualidade de design - enquadram-se todos os

atributos que facilitam a manutenção do seu software e sua con­ cepção. Exemplos seriam a flexibilidade e a “reusabilidade” de elementos. Atributos de qualidade de usuário - táticas que facilitam a usabilidade do sistema para o usuário final.

Definir soluções Depois de percorrer as quatro etapas anteriores é possível defi­

nir as resoluções de problemas para melhorar, solucionar e avaliar os cenários e os problemas de implementação.

Soluções Agora que você já decidiu o tipo de tecnologia, o modelo ar­

quitetônico e os assuntos-chave, já pode criar a sua arquitetura base.

Arquitetura base e arquitetura candidata A arquitetura base deverá descrever o programa existente. Ou seja, você deve fazer referências ao que ele será na sua fina­

lização, sendo a partir dessa base que são alçadas as arquiteturas candidatas. As arquiteturas candidatas são específicas aos cenários cria­ dos. Nessa etapa, você irá implantar o estilo arquitetônico, as es­ colhas de tecnologias, os atributos de qualidade etc. Lembre-se

sempre de realizar testes com os assuntos-chave, para evitar futu­ ros erros mais críticos.

Estrutura Baseada em componentes Quando você utiliza a estrutura baseada em componentes,

vai perceber que eles fornecem uma forma de isolar conjuntos

79

80

Arquitetura para computação móvel

específicos dc funcionalidades dentro dc unidades. Você pode

distribuir e instalar esses conjuntos dc funcionalidades separada­

mente. Quando for realizar esse processo, é necessário seguir as seguintes diretrizes: Aplicar princípios de design sólido para as classes, os prin­ cipais são:

Princípio da responsabilidade - suas classes devem ter apenas responsabilidades.

Princípio aberto/fechado - suas classes devem ser ex­

tensíveis, sem exigir modificações. Princípio da substituição Liskov - seus subtipos de­

vem ser substituíveis. Princípio da segregação de interfaces - suas classes

devem ter interfaces separadas para diferentes clientes,

com requisitos diferentes. Princípio de inversão de dependência - as dependên­

cias entre as classes devem ser no nível de abstração, evitando-se detalhes.

■

Evitar sobrecarga: Evite a sobrecarga de componentes, por exemplo, sem misturar lógica de acesso a dados com lógica de negócios. Isso torna a funcionalidade da aplicação mais coesa.

Um componente não deve confiar cm detalhes internos

dc outros componentes. Para ajudar a criar um aplicativo mais adaptável, garantir que cada componente ou objeto chame um método de outro ob­

jeto ou componente que vai saber como processar e encami­ nhar o chamado.

Compreender como os componentes se comunicam com os

outros. Aplicar os princípios fundamentais da arquitetura baseada em

componentes. Ou seja, os componentes devem ser reutiliza-

veis, substituíveis, extensíveis, encapsulados independentes e dc contexto específico.

Nesse modelo, cada camada deve conter uma série dc compo­

nentes, que devem implementar a funcionalidade dessa camada. A Figura 2.11 ilustra os tipos de componentes mais encontrados em

uma camada.

Modelos e projetos arquitetônicos

QJ ■o q ■g ;g

/

| S' u

/Lógica deA/íomponentes de\A Componentes de ^negóciosJ\fluxo de trabalhqjyentidade de negócio

Íí

E TJ .«J «V

Fachada de aplicação . % ----------...................... -------.........................

/componentes de\ /DadosauxiliaresX ÇAgentes de^ acesso a dados) e utilitários J serviços y ~r~

—

Fontes de dados

Fonte: Meier et al. (2009, p. 137).

Podemos sintetizar a Figura 2.11 da seguinte maneira:

1.

Componentes da camada de interface com o usuário -

responsável pela interação do sistema com o usuário. Estão

relacionados a ela: Componentes de interface - os componentes estão cn-

capsulados e tem a funcionalidade dc apresentar infor­ mações aos usuários e captar entradas.

Apresentação de componentes de lógica - representa o código do aplicativo que define o comportamento e a

81

82

Arquitetura para computação móvel

estrutura lógica dc uma forma independente da interfa­

ce com o usuário. Faz a intermediação entre o usuário e a lógica do programa.

2.

Componentes da camada de serviço - sua aplicação pode

ter uma camada de serviço para interagir com clientes ou outros sistemas. Nessa camada, é comum encontrarmos:

Interface de serviços - serviço em que toda mensagem

de entrada é enviada. O conjunto de mensagens que deve ser trocado com um serviço para que ele execute uma

tarefa específica, constituindo um protocolo. Tipos de mensagem - estruturas de dados contêm mensagens que garantem suporte a diferentes tipos de operações. Isso acontece na troca dc dados, na camada

de serviço. 3.

Componentes da camada de negócios - implementa a

funcionalidade do núcleo do sistema e encapsula a lógica de negócios relevante. Nessa camada, podemos encontrar o seguinte: Fachada dc aplicação - simplifica a interface dos com­

ponentes de lógica de negócios. Reduz dependências, porque os chamados externos não precisam saber os de­ talhes dos componentes, assim como suas relações.

Lógica de negócios - toda e qualquer lógica de apli­ cação relacionada à recuperação, ao processamento, à

transformação e à gestão de dados do aplicativo, po­ dendo ser subdividida em:

Componentes de fluxo de trabalho - depois

que uma entrada é reconhecida na interface com o usuário, e é enviada para a camada de negócios,

esses componentes podem usá-la para processar

e executar ações. Apresenta várias etapas, poden­

do ser implementado por meio de ferramentas de gestão de processos de negócios

Componentes de entidades de negócios - encap-

sulam a lógica dc negócio e dados necessários para a representação de elementos do mundo real, assim como clientes, ordens etc.

Modelos e projetos arquitetônicos

4.

Componentes da camada de dados - fornecem acesso a

dados na mesma locação e com os que são expostos cm re­

des. Nessa camada, podemos encontrar os seguintes tipos de

componentes: Componentes de acesso a dados - abstraem a lógica necessária para acessarem dados subjacentes.

Dados auxiliares e utilitários - diminuem a complexi­ dade dos componentes de acesso a dados.

Acesso a dados que utiliza lógica comum pode ser

aplicado a componentes auxiliares rcutilizáveis. Já tarefas que não são comuns a todos os compo­

nentes, podem ser implementadas cm componen­ tes utilitários separados. Agentes de serviços - úteis quando um componente

deve utilizar a funcionalidade fornecida por um serviço externo, gerenciando essa comunicação. Oferecem ser­ viços adicionais como cache e suporte off-line.

5.

Componentes transversais - algumas tarefas demandam

mais de uma camada. Componentes transversais criam fun­

cional ides que podem ser acessadas de qualquer camada para

outra. Aqui, podemos encontrar o seguinte: Componentes de implementação de segurança - in­

cluem componentes que farão a autenticação, a valida­ ção c a autorização dc acesso. Componentes para implementar funções de gestão

operacional - incluem políticas dc exceção dc mani­ pulação, contador de desempenho, entre outros. Componentes de implementação de comunicação - ser­

viço de comunicação com outras aplicações ou serviços.

Orientada a objetos A modelagem orientada a objetos consiste em um sistema em que a aplicação é baseada em objetos rcutilizáveis e independen­

tes. Cada um deles deve ter atribulos/propriedades e métodos per­ tinentes à sua função. Em vez de uma série de rotinas c instruções dc processos, esse

tipo de design consiste em uma série de objetos que colaboram

83

84

Arquitetura para computação móvel

entre si, utilizando interfaces. Por meio delas são chamados méto­ dos para acessar propriedades dc outros objetos.

Objetos são discretos, independentes e de baixo índice de acoplamento (MEIER etal. 2009).

Os princípios que baseiam esse tipo de arquitetura são os seguintes:

Abstração - permite reduzir uma operação complexa cm uma única generalização. Naturalmente, as características

básicas da operação cm si são mantidas. Em outras palavras, a classe abstrata c um tipo dc classe que pode ser herdada, mas não pode ser instanciada. Ou seja, podemos dizer que

esse tipo de classe é conceituai e define funcionalidades para

que suas subclasses (classes que herdam dessa classe) pos­ sam implementá-las de forma não obrigatória. Repare que, ao definir um conjunto de métodos na classe abstrata, não é de

total obrigatoriedade a implementação de todos os métodos em suas subclasses. Uma classe abstrata obriga todas as clas­ ses estendidas a implementarem seus métodos. Composição - seus objetos podem ser criados a partir de ou­ tros objetos já existentes. Essa parle interna, criada posterior­

mente, pode ser ocultada de outras classes c interfaces. Herança - objetos podem herdar características, proprieda­

des e métodos. Isso, naturalmente, facilita as atualizações e as modificações. Qualquer dado modificado no objeto base,

também será modificado nos objetos que herdaram as carac­

terísticas que foram alteradas. Encapsulamento - objetos são encapsulados para trocar

funcionalidades somente por meio de métodos. Lembre-se de

que é a interface pública do objeto que faz essa interação. Demais informações, como variáveis, mantêm-se ocultas aos outros objetos. Isso facilita a sua manutenção, uma vez que

não afeta lodo o sistema.

Modelos e projetos arquitetônicos

Polimorfismo - substituição do comportamento dc um tipo

base que suporta determinadas operações por meio de tipos

que são intercambiáveis com o objeto em si. Dissociação - objetos podem ser dissociados em uma interface geral abstrata. Geralmente, isso acontece para que o usuário final possa compreender o software.

Na prática, você vai reparar que a arquitetura orientada a ob­ jetos é bastante usada em sistemas com operações financeiras e

científicas complexas. Clientes, empresas, bem como outros ele­ mentos do mundo real, são representados dentro de um domínio

dc negócios, na forma dc objetos abstratos.

Alguns dos benefícios dc utilizar a arquitetura orientada a ob­ jetos são os seguintes:

Compreensível - a aplicação desse método estreita a ligação dos objetos com elementos do mundo real. Reutilizável - com esse método, é possível munir-se de ob­

jetos rcutilizáveis por meio do polimorfismo e da abstração.

Extensível - encapsulação, polimorfismo e abstração garan­

tem que as alterações feitas nos dados não afetem a comuni­ cação com outros objetos. Ou seja, mesmo com mudanças

internas, a interface continua realizando sua função de comu­ nicar os elementos entre si.

Altamente coeso - para aumentar a coesão, pode-se deter­ minar métodos c recursos específicos cm um único método,

usando outros para demais conjuntos dc recursos.

Arquitetura baseada em componentes Abordagem da arquitetura A estrutura da arquitetura baseada em componentes conside­ ra o sistema em si, os objetivos da empresa ou a organização, e

o usuário final. A arquitetura tem como foco a maneira como os elementos e os componentes de uma aplicação se comportam, interagem e são usados por outros componentes.

Para realizarmos uma arquitetura sólida devemos considerar os seguintes itens:

85

86

Arquitetura para computação móvel

■

Como o usuário manipulará a aplicação? Como o software será relevante para a empresa ou a organização?

Quais são os requisitos de atributos de qualidade que serão

aplicados (como segurança, desempenho, entre outros)?

Como a aplicação será flexível o bastante para suportar atualizações?

Quais tendências arquitetônicas podem afetar o software com

o tempo?

Uma boa arquitetura é capaz de:

■

Realizar a análise dc requisitos.

■

Compreender os casos dc uso. Implementar os casos dc uso.

Você também precisa se preocupar com um bom design, pois ele deve ser eficiente para lidar com a defasagem de software e

com as limitações de hardware, estando sempre apto para mudan­ ças e upgrades.

Em uma arquitetura baseada em componentes, o arquiteto deve se preocupar com os seguintes fatores:

Detalhar a estrutura do sistema, mas sem deixar dc esconder

os detalhes da implementação. Implementar todos os casos dc uso e cenários.

Abordar as necessidades do maior número de interessados. Lidar com requisitos funcionais e não funcionais.

PARA SABER!

Requisitos funcionais definem a função de um sistema de software ou de seus componentes. Os requisitos funcionais podem ser cálculos, detalhes técnicos,

manipulação de dados e de processamento, ou qualquer outra funcionalidade

específica que define o que um sistema será capaz de realizar.

Tendências arquitetônicas O modo de fazer a arquitetura de software envolve as decisões do próprio arquiteto, não existindo um padrão fixo para determi­ nadas demandas, ou seja, tudo pode variar. Por exemplo: duas

Modelos e projetos arquitetônicos

empresas dc telefonia precisam da mesma arquitetura dc software

e contratam o mesmo arquiteto. A função final do sistema desen­ volvido para cada empresa pode até ser igual, mas a arquitetura

em si varia conforme elementos, tais como: profissionais, funcio­ nalidades, fluxo de trabalho.

Além disso, você já sabe que uma boa arquitetura precisa ser adaptável a alterações. Isso porque, com o tempo, softwares

tornam-se obsoletos, assim como o hardware para o qual ele foi

desenvolvido. Exatamente por esse motivo, você precisa acompa­

nhar as principais tendências na prática arquitetônica. Isso previne que o seu software desvalorize e/ou não tenha mais utilidade em

pouco tempo, além de torná-lo apto para mudanças futuras.

A seguir, veja alguns dos principais caminhos para constituir

uma boa arquitetura do seu software. Poder ao usuário - uma aplicação que suporta a tomada de

decisões pelo usuário torna-se, naturalmente, mais flexível. Isso porque ele será configurado totalmente segundo a expe­

riência de quem utiliza o software. Oferecer a opção para o usuário de interagir com a aplicação, em vez de ditar ordens,

faz com que quem utilize o software o programe e o configu­

re segundo suas necessidades, otimizando a relação usuário/ máquina.

Maturidade de mercado - aproveite tecnologias existentes, construindo algo de maior desempenho tendo como base uma

aplicação já existente, cm vez dc criar do zero algo que já

existe. Isso será possível devido à reusabilidade dc elementos já existentes, ou seja, herdar características já prontas c adi­ cionar funcionalidades novas.

Design flexível - neste caso, o foco é a redução de acopla­

mento. Isso possibilita a reutilização de modelos, tornando a sua aplicação mais flexível. O padrão de arquitetura SOA,

que você viu no primeiro tema desta unidade, é um forte alia­ do na flexibilização de uma aplicação. Tendências futuras - considere sempre as possíveis me­ lhorias em questão de hardware, o uso crescente de novas

tecnologias, as mudanças de paradigma c as diversas outras

mudanças que podem afetar sua aplicação futuramente.

87

88

Arquitetura para computação móvel

Princípios fundamentais de arquitetura Ao criar sua arquitetura de software com base em componen­

tes, considere os seguintes tópicos: Construir para mudar e não construir para durar - pense

que o seu software precisa se adaptar sempre às novas rea­

lidades, necessidades e tecnologias. Invista na flexibilidade. Analisar e reduzir riscos - use ferramentas dc modelagem e

design para visualizar melhor a sua arquitetura e design, en­

contrando possíveis erros com mais facilidade. Uma forma dc fazer isso e usando a linguagem dc modelagem dc software, por exemplo a UML ( Unified Modeling Language). Conside­

re também as mudanças que o software pode sofrer.

Lembre-se de que na criação de uma arquitetura, você nunca deve

imaginar um modelo pronto e já finalizado. Pense em um processo

em que existe a possibilidade de incrementar e adicionar elementos. Comece pela linha base da arquitetura, para evoluir aos pou­ cos, levando em consideração requisitos necessários e pressu­

postos. Assim, detalhes aparecerão com base no que você cria, à medida que os testa. Um erro comum dos arquitetos é dedicar-se demais aos detalhes muito rapidamente, o que pode levar a esco­

lhas erradas, atrasando o trabalho.

Princípios de arquitetura O foco da arquitetura com base cm componentes está na de­ composição da estrutura dc funcionalidade. Cada estrutura possui

sua interface de comunicação, encapsulando componentes res­ ponsáveis por funções específicas.

Partindo desse preceito, o nível de abstração é alto. Para isso, lemos algumas chaves que são princípios importantes para esse

método. Duas dessas chaves, o reúso e a extensihilidade, já foram vistas nos tópicos anteriores. Além dessas duas, lemos:

Encapsulamento - componentes devem ser encapsulados, garantindo que os processos ou as variáveis internas não se­

jam revelados ao resto do sistema. Toda a comunicação é fei­ ta por meio da interface do componente.

Independência - deve ser mantido o mínimo de dependên­ cia entre os componentes. Até mesmo pelo fato de poderem

Modelos e projetos arquitetônicos

ser divididos em vários servidores físicos. Isso garante que a

alteração ou a atualização de um componente não irá afetar outros, ou o sistema como um lodo.

Vantagens e desvantagens Agora, vamos ficar atentos a algumas vantagens e desvanta­ gens nas considerações feitas no item anterior. São elas:

A manutenção explícita de um componente pode ser a prin­ cipal forma de editar informações. O desenvolvedor irá

detalhar todas as alterações que devem ser feitas, mas é ne­ cessário que o arquiteto lenha um conhecimento profundo e

detalhado do funcionamento do componente. Isso pode trazer

complicações. Em linguagem Java, voce pode criar uma relação de heran­

ça entre os componentes. Esse é apenas outro nome para a

relação dc extensão, que você já leu nesta unidade. E um facilitador, pois economiza tempo e otimiza o seu projeto. No entanto, é necessário ter conhecimento detalhado da sua

superclasse, para não correr o risco de herdar elementos desnecessários. Você já sabe que o encapsulamento protege informações de

um componente, e que a principal vantagem dessa técnica é a

facilitação de comunicação entre componentes antes incom­ patíveis. Isso acontece porque tudo o que é usado na comuni­

cação é apenas a interface. Mas, por outro lado, pode existir

uma sobrecarga de implementações na sua aplicação, se to­ dos os seus componentes forem encapsulados - até mesmo aqueles que não necessitam de uma interface própria para se

relacionarem com outros elementos.

Implementação prática Para implementar e executar seus componentes, mesmo que

alocados em servidores diferentes, você pode usar o Enterprise Java Beans. Esse sistema é desenvolvido pela Sun Microsystems e

permite que você interconecte componentes remotos cm sistemas

empresariais, por exemplo. Você também pode reutilizar compo­ nentes por meio dessa aplicação.

89

90

Arquitetura para computação móvel

Exercícios de fixação 1. A figura a seguir está relacionada à arquite­ tura baseada em componentes. Explique.

2. Ao longo desta unidade, foram apresen­ tadas algumas categorias de arquitetura, bem como os estilos respectivos a cada uma delas. Escolha uma categoria e dis­ corra sobre seus estilos. 3. Explique com suas palavras os concei­ tos de arquitetura base e sua importân­ cia para a arquitetura candidata. 4. A partir da figura a seguir, faça as atividades: a. Identifique os erros e coloque as eta­ pas na ordem correta. b. Explique o modelo do qual esses pas­ sos fazem parte.

5. "O objetivo dos cenários-chave é alcançar um equilíbrio entre os objetivos do usuá­ rio, do negócio e do sistema". (MEIER et al., 2009, p. 41). Com base na citação, qual é a importância prática dos cenários-cha­ ve na elaboração de uma boa arquitetu­ ra? Dê exemplos.

Modelos e projetos arquitetônicos

91

Estudo de caso Como funciona o Uber Voucher, nova forma de pagamento do aplicativo Empresas podem cobrir os custos de viagem para colaboradores e clientes

0 Uber Voucher é a nova aposta da Uber para empresas. O serviço de transporte para An­ droid e iPhone (iOS) permite que as viagens feitas por clientes e colaboradores sejam custeadas pela companhia por meio de um cupom. A cortesia é gerada por um painel de controle no Uber para Empresas e o aba­ timento é feito ao confirmar o endereço da corrida. Os tickets obedecerão a regras corpo­ rativas, que podem definir data de expiração e destino para o qual a viagem é válida. A ideia do aplicativo é oferecer um sistema capaz de atrair e fidelizar consumidores. As firmas que aderem ao recurso conseguem acompanhar a corrida dos colaboradores, além de estabelecer regras e administrar os pagamentos. A partir do painel de controle,

também é possível enviar o carro para um local determinado quando a empresa quiser proporcionar viagens aos clientes. As cobran­ ças são efetuadas na conta corporativa da Uber para Empresas. As pessoas que tiverem o Perfil Trabalho não conseguem usar o vou­ cher, mas é possível indicar outro perfil para resgatar o benefício. A plataforma oferece um suporte dedicado à incorporação e transição do serviço. Outra maneira para implementar o uso do Uber Voucher é uma API (Application Programming Interface ou Interface de Programação de Aplicações, em português), que habilita uma integração direta à plataforma do cliente. Fonte: Ferreira (2019).

REFLITA! 1.

De acordo com os conceitos de interoperabilidade e SOA, como pode ser defi­ nida a arquitetura para essa API? 2. Reúso é uma característica predominante para uma arquitetura SOA. Para essa API, pode ser definida essa característica? 3. Construa uma estrutura baseada em componentes para essa API.

92

Arquitetura para computação móvel

Na mídia Sucesso com SOA na CISCO Harvinder Kalsi, arquiteto líder do domínio SOA/BPM na Cisco, apresentou um estudo de caso em dezembro no SOA Consortium meeting em Santa Clara na adoção de uma abordagem holística de SOA para supor­ tar Commerce Transformation Initiative da Cis­ co que visa transformar a Cisco de fornecedor de equipamentos de rede a fornecedor de soluções. Harvinder vê SOA como sendo: "as políticas, princípios e frameworks que oferecem capacidades de negócio a ser prestado e consumido como conjunto de serviços." Ele enfatiza: "Os Serviços em SOA são serviços de negócio... atualização de uma citação do cliente é um serviço de negócio, atualização de um registro em um banco de dados não é". Em sua opinião, nós estamos em um momen­ to crucial para SOA. Ele argumenta que a par­ tir de 2008, o padrão e as tecnologias estarão bastante maduras enquanto o interesse dos negócios está crescendo. Neste estudo de caso o negócio foi o principal driver por trás do desenvolvimento SOA. Eles estabeleceram suas estratégias SOA uti­ lizando quatro passos para o processo de maturidade: 1. Serviço permite sistemas legados 2. Criar uma camada de serviço de negócios

Atingir a excelência dos processos de negócio 4. Dar visibilidade ao negócio Eles veem vários benefícios gerados pela abordagem SOA: ■ Reusabilidade ■ Agilidade ■ Impacto mínimo para mudança Finalmente, em sua opinião SOA permite pe­ gar a funcionalidade que a Cisco tem inter­ namente e a oferecer ao seu ecossistema de parceiros, ampliando os benefícios para toda a cadeia de estoque. Ele nota que há, entretan­ to muito ceticismo:"As pessoas não acreditam que possa acontecer." Em particular ele vê que SOA tem desafios inerentes: ■ Disponibilidade (SLA) ■ Performance ■ Segurança (e propagação de identidade) ■ Excelência Operacional ■ Governança Em última análise a parte mais difícil da Com­ merce Transformation Initiative foi que seus sis­ temas legados tornam-se difíceis.

3.

Fonte: DUBRAY, J.-J. Sucesso com SOA na CISCO. InfoQ, 9 fev. 2009. Disponível em: . Acesso em: 4 maio 2019.

Modelos e projetos arquitetônicos

93

DISCUTA! 1. 2. 3.

Quais são os desafios para a arquitetura SOA? Quais as vantagens de se utilizar a arquitetura SOA? Por que os sistemas legados podem ser tornar mais difíceis ao utilizar a arquite­ tura SOA na opinião do arquiteto da CISCO?

Na academia Desenvolvimento de apps no Brasil está em bom momento O mercado de apps continua em crescimento constante e não dá sinais de que vai mudar de figu­ ra tão cedo. De acordo com uma pesquisa divulgada este mês pela Canalys, as quatro principais lojas de aplicativos - iTunes App Store, Google Play, Windows Phone Store e BlackBerry World - atingiram a marca de 13,4 bilhões de downloads em todo o mundo no primeiro trimestre deste ano. Mas neste mercado, como fica a posição para desenvolvedores dentro do Brasil? De acordo com o instituto Ibope, cada vez mais, os smartphones se tornam o principal objeto de desejo dos consumidores brasileiros. Segundo os resultados, a penetração desses dispositivos no mercado nacional praticamente dobrou no último ano, atingindo a marca de 44%. A média global é de 48%. Fonte. Romer (2015).

Conforme a matéria sugere, a participação do Brasil no mercado de aplicativos móveis vem cres­ cendo. Sendo assim, pense no projeto de um aplicativo novo e crie apenas a camada da arquite­ tura base. Lembre-se de que, conforme a sua concepção, algumas escolhas podem ser melhores do que outras. Documente a criação e explique sua usabilidade e afins.

Recapitulando Esta unidade apresentou os principais funda­ mentos teóricos dos principais estilos arquite­ tônicos atuais. Esperamos que você, após esses estudos, se sinta mais confiante para criar seus próprios aplicativos, principalmente móveis. Aqui, você aprendeu que os principais estilos ar­ quitetônicos são divididos em categorias, a partir de seu principal foco: comunicação, implantação, domínio e interação. Você conheceu os padrões

de serviço orientado a objetos, message-bus, client/server e tier. Cada um desses estilos tem suas próprias características e particularidades. Sendo assim, o uso deles não é obrigatório em determi­ nadas situações. Na verdade, cada situação (clien­ tes, usuários finais, objetivos do programa etc.) é que decide qual dessas estruturas é a ideal. Você também relembrou e estudou os prin­ cipais pilares da arquitetura baseada em

94

Arquitetura para computação móvel

componentes: objetivos da empresa, sistema e usuário. Esperamos que você tenha fixado a ideia que melhor define a relação entre esses três pontos: construir uma ponte entre os três objetivos, para que trabalhem em uníssono, em plena capacidade. Em arquitetura de software, muitas decisões pa­ recem ser subjetivas, mas o ponto de partida, isto é os problemas a serem solucionados e os obje­ tivos a serem alcançados, devem ser sempre o ponto de partida para criar uma solução. Naturalmente, não fazemos esses projetos sozinhos. O trabalho é feito com equipes de

desenvolvedores, além do diálogo aberto e di­ reto com nossos clientes, sejam empresas ou pessoas. Detalhes como objetivos e definição da usabilidade do sistema só serão captados com precisão após esse diálogo. E, como em todos os outros campos das ciências, uma escolha que não seja bem ponderada pode trazer atrasos ou prejuízos. Por isso, lembre-se sempre de testar sua arquitetura durante o pro­ cesso de elaboração. Erros acontecerão e isso é normal, mas corrigi-los antes da finalização é o segredo para um produto final terminado em menos tempo e com mais qualidade.

PONTOS IMPORTANTES Sistema é uma interação entre usuários, objetivos e o sistema em si. Esses três elementos formam os pilares da arquitetura de software. ■ A arquitetura e o software devem ter um design flexível, isto é, serem capazes de adaptar-se a diversos tipo de situação e objetivos. ■ Existem diversos padrões ou estilos de arquitetura, que é a forma que a arquite­ tura vai apresentar. Esses padrões são divididos em quatro categorias principais: comunicação, implantação, domínio e estrutura. Padrões de comunicação: ■ Arquitetura orientada a serviços (service-oriented architecture, SOA): ■ organiza os sistemas em serviços, que se comunicam por protocolos; ■ cada serviço tem autonomia e pode ser substituído ou alterado, o que re­ duz o acoplamento. ■ Message-bus: ■ diz respeito à troca de informações, com base no uso de um ou mais ca­ nais de comunicação; ■ o sistema troca informações diferentes por meio de mais um canal de for­ ma única, evitando informações desnecessárias; ■ bus (barramento) é o que faz a comunicação entre as aplicações. ■ Padrões de implantação devem levam em conta as limitações do ambiente físico: ■ Implantação não distribuída: ■ ideal para acessos finitos (como a intranet de uma organização); ■ todas as camadas compartilham o mesmo hardware, o que minimiza o número de servidores, mas uma camada pode afetar todas as outras. ■ Implantação distribuída: ■ ideal para sistemas maiores; ■ as camadas residem em camadas separadas fisicamente, o que proporcio­ na ambientes e servidores exclusivos para cada operação.

Modelos e projetos arquitetônicos

■

95

Client/server: ■ dispositivos clientes solicitam informações a um servidor que responde com as informações solicitadas; ■ utiliza os conceitos de camadas e filas; ■ clientes magros possuem uma única camada e não apresentam código de aplicação personalizado, enquanto clientes gordos possuem entre uma e três camadas (3-tier). Padrões de domínio: ■ Domain model ou domain-driven design (DDD) -software baseado no do­ mínio de negócios, e seu núcleo contém uma linguagem comum comparti­ lhada, o que facilita a comunicação entre os elementos da aplicação. ■ Para uma arquitetura atingir seus objetivos, é preciso seguir os seguintes passos: ■ identificar os objetivos da arquitetura; ■ identificar os principais cenários; ■ criar uma visão geral do aplicativo; ■ identificar os pontos principais; ■ definir as soluções. Arquitetura base é a descreve o programa existente enquanto a arquitetura can­ didata é específica aos cenários criados. A estrutura de uma arquitetura pode ser baseada em componentes ou orientada a objetos. ■ Arquitetura baseada em componentes ■ fornece uma forma de isolar conjuntos específicos de funcionalidades dentro de unidades; ■ os conjuntos de funcionalidades podem ser distribuídos e instalados separadamente; ■ devem seguir os princípios da responsabilidade, aberto/fechado, da subs­ tituição, da segregação de interfaces e de inversão de dependência; ■ devem evitar a sobrecarga de componentes, e um componente não deve confiar em detalhes internos de outros componentes. ■ Arquitetura orientada a objetos ■ a aplicação é baseada em objetos reutilizáveis e independentes, que pos­ suem atributos e métodos; ■ os objetos colaboram entre si, utilizando interfaces; ■ essa arquitetura é baseada nos princípios de abstração, composição, he­ rança, encapsulamento, polimorfismo e dissociação. Uma arquitetura sólida considera as seguintes questões: ■ como o usuário manipulará a aplicação? ■ como o software será relevante para a empresa ou a organização? ■ quais são os requisitos de atributos de qualidade que serão aplicados? ■ como a aplicação será flexível o bastante para suportar atualizações? ■ quais tendências arquitetônicas podem afetar o software com o tempo?

96

Arquitetura para computação móvel

Uma boa arquitetura: ■ realiza a análise de requisitos; ■ compreende os casos de uso; ■ implementa os casos de uso. ■ Os fatores considerados em uma arquitetura baseada em componentes sâo: ■ detalhar a estrutura do sistema sem deixar de esconder os detalhes da implementação; ■ implementar todos os casos de uso e cenários; ■ abordar as necessidades do maior número de interessados; ■ lidar com requisitos funcionais e não funcionais. ■ Principais caminhos para construir uma boa arquitetura de software: ■ Poder ao usuário - suportar a tomada de decisões pelo usuário, o que torna a aplicação mais flexível. ■ Maturidade de mercado - ter como base tecnologias existentes e consolidadas. ■ Design flexível - reduzir acoplamento e reutilizar modelos. ■ Tendências futuras - considerar as novas tecnologias e as possíveis mu­ danças de paradigma. ■ Leve em consideração dois princípios fundamentais da arquitetura: construir para mudar, e não construir para durar, isto é, o software precisa se adaptar a novas realidades, necessidades e tecnologias, e analisar e reduzir riscos, isto é, visualizar melhor a arquitetura e o design para encontrar possíveis erros e considerar as mu­ danças que o software pode sofrer. ■

UNIDADE 3

WEBSERVICES E SERVIÇOS

CONHEÇA Os fundamentos e as técnicas de utilização de webservices.

REFLITA Sobre a importância da comunicação entre diferentes sistemas baseados em serviços.

DISCUTA Sobre o modelo de representação textual para comunicação baseado em XML.

APLIQUE Os conhecimentos adquiridos para criação de uma estrutura de webservices para interação entre vários sistemas.

#XML

#SOA

#WEBSERVICE

01 OBJETIVOS DE APRENDIZAGEM Compreender os conceitos de

webservices.

Conhecer e aplicar, na prática, conceitos de XML (extensible

Markup Language) e suas

técnicas essenciais, como os namespaces.

Dominar os princípios da SOA.

ARQUITETURA BASEADA EM WEBSERVICES O que é XML? Como se estrutura um documento XML? O que são elementos e atributos? Para que servem os namespaces? O que é um processador XML?

02

ARQUITETURA ORIENTADA A SERVIÇOS O que é um serviço? Como funciona a SOA? Quais as características dos serviços? Quais os modelos de serviços primários? O que é UDDI?

Webservices e serviços

99

Introdução No mundo em que vivemos, a troca de informa­ ção em escala global e em tempo real é cada vez maior. Isso muda os parâmetros e as necessida­ des das empresas, que precisam se adaptar a uma realidade extremamente dinâmica. Tendo em vista essas relações mundiais, um dos requi­ sitos mais valorizados na hora de contratar um novo funcionário é, justamente, o domínio que ele tem sobre outras línguas. Não é preciso ir muito longe para vivenciarmos essa realidade. Ao procurar por vagas de empre­ go, você já deve ter se deparado com especifica­ ções que diziam claramente que o domínio de uma língua estrangeira seria considerado um diferencial do candidato. Infelizmente, o nosso cérebro não é um banco de dados que podemos preencher com vocábulos estrangeiros do dia para a noite. 0 aprendizado é constante e, por vezes, pode levar muito tempo até que domine­ mos a semântica de outra língua. Inclusive, mui­ tas vezes aprendemos a dominar outra língua por meio de associações. Por exemplo: a frase "eu te amo" corresponde a "Hoveyou", em inglês, e a "te quiero", em espanhol - três frases com o mesmo significado que são escritas de forma completamente diferente. Mas imagine um tipo de linguagem universal, que traduza as três frases ("eu te amo", "Hoveyou" e"te quiero") em um único código que todo mun­ do conheça. Digamos, então, que essa frase cor­ responda a"". Ora, sempre que qualquer pessoa se deparasse com "", ela saberia

que aquilo significaria "eu te amo" em sua língua nativa, seja ela qual for. Isso certamente facilita­ ria o estudo de idiomas, não?

Pois esta é exatamente a proposta da Lingua­ gem de Marcação Estendida, o XML (em inglês, extensible Markup Language). Ela é nada mais que um documento de descrição extremamente portátil. Isso porque ele é organizado por marca­ ções. Essas marcações definem e localizam da­ dos específicos. Como essa linguagem também é independente de software e hardware, qualquer local que importar um documento XML será ca­ paz de identificar os dados necessários e arma­

zená-los em seus próprios bancos de dados. Esse sistema de marcação (marcadores de aber­ tura [o] e de finalização []) torna o docu­ mento extremamente leve e, o mais importante,

legível. Claro que, com a diversidade de finalida­ des dos webservices, existem várias ramificações do XML, como os esquemas e as diversas formas

de processar o documento (aqui, abordaremos o SAX (Simple API for XML), o DOM (Document Object Model) e o JAXB (Java Architecture for XML Binding). Por fim, na segunda parte deste capítulo, abordaremos a arquitetura orientada a serviços, das suas aplicações técnicas até o UDDI

- uma espécie de biblioteca digital, gratuita e aberta, em que você pode divulgar e conhecer diversas interfaces em HTML - afinal de con­

tas, nada melhor do que curtir e compartilhar conhecimento.

100

Arquitetura para computação móvel

Arquitetura baseada em webservices XML O XML {extensible Markup Language) começou a ser uti­ lizado como suporte à World Wide Web na década de 1990 mais precisamente em 1996. Ele surgiu a partir da necessidade

de se ter um modelo de representação textual para informações estruturadas e semiestruturadas que fosse extensível e, o mais importante, simples.

O W3C e suas recomendações

Com o advento da World Wide Web nos anos 1990, o mundo precisou encontrar padrões para torná-la acessível, no sentido prático, para o maior número possível

de pessoas. Foi para isso que foi fundada em 1994 a World Wide Web Conscortium, a W3C. Ela é um consórcio internacional que compreende mais de 400 membros

entre empresas, ONGs e organizações governamentais. Eles têm o intuito de criar alguns padrões de arquivos e dados legíveis a qualquer máquina, independente­ mente de hardware, software ou tecnologia.

Alguns padrões W3C são inevitavelmente utilizados por programadores, como

as linguagens CSS, XHTML e o próprio XML. Outros padrões estão bem mais pró­

ximos do público considerado leigo: imagens salvas nos formatos JPG e PNG, por exemplo, são consideradas dentro do padrão W3C: essas duas extensões são recomendadas por esse consórcio. Elas poderão ser reconhecidas por meio de

qualquer tecnologia e dispositivo em todo o mundo.

De fato, o conceito dc marcação generalizada (GM. na sigla

em inglês), com o qual o XML trabalha, é de fácil assimilação. Ele é caracterizado por marcadores que são identificados pelos sinais o, por exemplo. Dessa maneira, a palavra “bold” (do inglês, negrito) acrescida dos sinais forma o marcador .

Essas tags são separadas em “de início" e “de fim". Por exem­

plo, é uma tag que indica o início de conteúdo em negrito. Já , sinaliza onde o negrito deve ser finalizado. Como você pode

perceber, a adição da barra “/" sinaliza a tag de encerramento.

Webservices e serviços

101

No exemplo a seguir, temos várias marcações que indicam que um livro apresenta um único título e vários autores:

NA PRÁTICA

Building Web Services with Java

Steve Graham Simeon Simenov Toufic Boubez

Doug Davis Glen Daniels Yuichi Nakamura

Ryo Neyama



Se você usa a ferramenta Blogger, do Google, deve se lembrar

de que esse recurso pode ser usado ao clicar na aba HTML no

campo de criação de postagem. Essas tags também foram muito famosas em redes sociais como o Orkut, em que você podia editar os textos que publicava por meio de marcações como ...,

..., entre outras.

Veja, no Quadro 3.1, algumas das marcações mais conhecidas Muitas especificações são

em XML.

construídas em XML para

estender suas capacidades

Quadro 3.1 Marcações em XML

e permitir o seu uso em Tag

Tipo

uma ampla gama de

cenários. Ele tornou-se

Marcadores de estruturação

, ,

,


Marcadores de formatação

,

de informações estruturadas

Marcadores de inserção de links/imagens

,

e semiestruturadas

Marcadores de inserção de dados

, ,

(GRAHAM et al, 2004).

Agora que já fomos apresentados aos conceitos básicos do XML,

podemos nos aprofundar nos padrões dessa linguagem que são as bases para serviços de web. Webservices apresentam a maior gama

de utilização de XML. Os padrões que estudaremos são os seguintes:

padrão em representação

102

Arquitetura para computação móvel

■

instâncias XML;

■

esquemas XML;

■

espaços de nome em XML (XML Namespaces);

■

processamento XML.

Antes de nos aprofundarmos nesses lemas, vamos compreen­

der os conceitos de document centric e data centric.

Document centric O XML teve uma rápida aceitação em representação de do­ cumentos semiestruturados. Esses documentos fazem a media­ ção homcm-máquina. Isso porque, além dc um computador ler

c compreender um documento XML, você também pode com­ preender do que se trata o conteúdo do documento, já que ele

pode ser nada mais que um documento de texto organizado logicamente por marcações. Ou seja, onde você normal mente le-

ria “José Alencar”, em XML você teria: “José Alcncar”. Os elementos-chave desses documentos XML de modelo se-

miestruturado que usa o document centric são textos de marcação.

No exemplo a seguir, lemos um bom modelo dessas marcações (, por exemplo, que indica que a palavra ficará em negrito).

Note que são definidos de modo bem genérico e vago:

NA PRÁTICA Skateboard Usage Requirements

In order to use the FastGlide skateboard you

have to have:

A strong pair of legs. A reasonably long stretch of smooth road surfa­ ce.

The impulse to impress others.

If you have all of the above, you can proceed to Getting on the Boardc/ LINK>.

Webservices e serviços

Data centric O data centric refere-se a textos de marcações tolalmente estrutu­

radas. Diferentemente do XML, essas marcações são desenvolvidas por máquinas para serem consumidas por máquinas. Geralmente é

utilizado cm banco de dados e transações financeiras. Diferentemente das marcações genéricas do exemplo anterior

em document centric, repare nas marcações do exemplo a seguir. Note que elas são mais complexas e específicas. Elas se referem a

uma compra de 5 mochilas, 12 skates e 1.000 adesivos para skates, feita pela varejista SkatesTown.

NA PRÁTICA

The Skateboard Warehouse

One Warehouse Park

Building 17

Boston MA 01775



The Skateboard Warehouse

One Warehouse Park

Building 17

Boston MA 01775



citem sku="318-BP" quantify="5"> Skateboard

backpack;

five

pockets

citem sku="947-TI" quantity="12"> Street-style titanium skate­

board.

103

104

Arquitetura para computação móvel

citem sku="008-PR" quantify="1000">



Instância XML A estrutura XML deve seguir regras de sintaxe. O termo ins­ tância refere-se ao uso particular de um tipo específico de XML.

Documento Prolog O Prolog de um documento XML é, como o próprio nome diz,

o seu prólogo. Em atividades escolares, sobretudo nos primeiros anos do ensino básico, a professora provavelmente lembrava os

alunos de colocar o cabeçalho. Com isso, todos entendiam que precisavam escrever, antes dc tudo, seus nomes, a data, a disci­

plina etc. Em suma, informações que ajudavam as pessoas que leríam aquela atividade a saber do que se tratava antes de partirem

para o conteúdo. No caso dos documentos XML, o prólogo seria uma espécie

de cabeçalho. Ou seja, contém informações que aparecem antes da

marca de início do elemento raiz ou do documento. Essas informa­

ções contêm, geralmente, dados sobre a estrutura do documento, o

tipo de codificação, entre outras características que introduzem o que se segue. Esse “cabeçalho” é opcional.

Você identifica um documento como XML por meio de Instru­

ções de Processamentos (Pis, na sigla em inglês). Elas apresentam a seguinte sintaxe:

Ou seja, o objetivo aqui é colocar uma palavra-chave refe­

rente ao tratamento da aplicação. Tudo entre é conside­

rado a palavra-chave. As letras “x”, “m” e “I”, maiusculas ou minúsculas, são reservadas e não usadas como nomes dc Pis.

Você também pode adicionar comentários ao Prolog do seu do­ cumento. Ele pode ter várias linhas, mas não pode ser acoplado -

um comentário dentro de um comentário é ignorado. A sintaxe que você deve seguir é a seguinte:

Webservices e serviços

Elementos Elementos em XML determinam o início e o fim de uma fun­ ção. Lembra-se do exemplo dc negrito, o e o ? É exata­

mente isso. A marcação de elemento caracteriza-se por duas tags cor­ respondentes (de início e de fim) emparelhadas. O elemento em

questão será aplicado no que estiver entre elas.

Os elementos podem conter todos os caracteres - ou seja, de

0 a 9, de A a Z (em maiúsculo) e de a a z (em minúsculo) -, bem

como sublinhado (_), hífen (-) e dois pontos (:). Mas lembre-se de sempre iniciar um elemento com uma letra.

Importante: elementos são sensíveis ao tipo de caixa da letra, em outras palavras o termo “Nome-do-Cliente” não é o mesmo que “nome-do-cliente”.

Outro fator essencial é que os elementos devem manter a or­

dem de abertura e fechamento. Veja o exemplo:

Texto em negrito e itálico em um parágrafo

Essas marcações determinam que a frase será um parágrafo em negrito e em itálico. Repare na ordem delas:

e . Isso significa que sua finalização deve ser alinhada, espelhada. Isso

nos dá, então, a finalização na seguinte ordem: , e . Isso é necessário porque você cria uma hierarquia de estrutura quando coloca determinada ordem de marcações. É como quando você monta uma pilha com peças de Lego: depois de encaixar uma

peça em cima da outra, você não consegue desmontar a pilha pela peça do meio. Você, então, deve iniciar a desmontagem retirando

primeiro a última peça que foi colocada. No esquema das marca­

ções é a mesma coisa. Os exemplos a seguir estão incorretos. No primeiro, I c B não

são finalizados corretamente. O mesmo acontece com P e B no seguinte.

Texto em negrito e itálico em um parágrafo

105

106

Arquitetura para computação móvel

Texto em negrito e itálico em um parágrafo,

Atributos Você pode adicionar atributos nas suas marcações. Lembre-

-se de que um atributo é um par de nome-valor. A sintaxe envol­

ve o sinal de igualdade (=), que é seguido de um valor constante.

Os valores são colocados entre aspas simples (‘) ou duplas (“). No exemplo a seguir, o elemento po de uma ordem de compra

tem dois atributos: id e submitted.

NA PRÁTICA ...

Atributos que começam com xml: são reservados a especifica­ ções XML. Xml: lang, por exemplo, c usado para identificar a lín­ gua cm que o texto do atributo é escrito. Veja o exemplo a seguir, que identifica o atributo como escrito em inglês (“en”)

NA PRÁTICA description xml : lang="en">Skateboard backpa­ ck; five pockets

Escape Você já usa caracteres especiais na sintaxe dc XML. Por exem­

plo,

entre outros. Isso significa que se você usar es­

ses mesmos caracteres dentro de elementos XML, seu documento vai gerar um erro.

Para evitar situações como essa, você pode substituir esses ca­

racteres “proibidos” por uma sequência de escape. Existem cinco sequências predefinidas, que estão listadas no Quadro 3.2.

Webservices e serviços

Quadro 3.2 Sequências de escape.

Sequência de escape

Caractere




&

&apm;

/

'

"

Para que você compreenda melhor esse conceito, veja o exem­

plo a seguir: se multa > 500 então

Nesse caso, o documento iria gerar um erro. Repare que “” são os sinais dc abertura c fechamento dc marcações. Usar

o símbolo “>” entre as marcações geraria o erro. Para contornar a situação, a mesma linha deveria ser escrita da seguinte forma:

se multa > 500 então

Namespace A propriedade namespace é um recurso do XML para evitar

conflito de nomes de elementos. Um problema comum é a ocor­

rência de elementos com o mesmo nome. Considere o exemplo de documento XML a seguir, observe que neste documento existe a repetição do elemento

.

uva

maçã

Tabela Futuristica

107

108

Arquitetura para computação móvel

77

lll

Observe que a duplicidade do elemento nesse docu­ mento XML pode causar problemas a um desenvolvedor. Con­

sidere que o desenvolvedor precise capturar as informações do elemento que apresentam as informações da tabela fu-

turística. Dada a duplicidade desse elemento, seu algoritmo não

seria capaz de distinguir quais das tabelas escolher. A fim de solucionar o problema de duplicidade de elementos,

o XML define prefixos para elementos. Dessa maneira, a utiliza­ ção dc prefixos possibilita a existência dc dois elementos .

O exemplo a seguir apresenta a utilização dc prefixos no docu­ mento anterior.



uva maçã



Tabela Futuristica 77 lll

Os prefixos p e q, utilizados neste exemplo, diferenciam o mesmo elemento e evitam conflitos. Mas isso não é tudo. Você precisa atribuir o seu prefixo com

um atribulo xmlns. Assim, você dá ao seu prefixo um nome quali­ ficado a um namespace. A sintaxe é a seguinte:

Xmlns : namespace-prefix="namespace" Dessa forma, no nosso exemplo, seria feito o seguinte:

Xmlns : p= "http://www.w3.org/tr/html4"

Webservices e serviços

A especificação do namespace sempre será um Identificador

de Recurso Uniforme (URI, na sigla em inglês). Geralmente, ele sempre será um domínio dc internet. Quando um namespace é atribuído, os elementos filhos já re­

cebem as especificações. Ou seja, no caso do nosso exemplo, após

atribuir o namespace c:, os próximos elementos não precisarão conter esse namespace.

XML Schema Um documento XML estruturado deve seguir as regras de sinta­

xe já descritas nesta unidade. Mesmo assim, esses arquivos podem ser passíveis de falhas e resultados inesperados. Principalmente se

o arquivo de texto XML for extremamente grande. Nesses casos, ambiguidades sintáxicas são quase impossíveis de evitar. Existem dois mélodos-padrão para definir a estrutura de um

arquivo XML, são eles: Definição dc Tipo de Documento (DTD)

e XML Schema, derivado desse primeiro. Aqui, vamos nos apro­

fundar no XML Schema. A primeira característica que devemos levar em consideração

nesse caso é que os schemas são escritos diretamente cm XML:

se você dominar essa linguagem, terá facilidade com o funcionamento

dos Schemas. Em segundo lugar, devemos notar que eles são proje­ tados com namespaces. De um modo geral, XMLSchemas definem

o que pode aparecer cm um documento - elementos, atributos, entra­

das etc. - e suas respectivas ordens. Veja o exemplo a seguir. Ele diz respeito a uma estrutura dc uma ordem dc compra da SkatesTown.

NA PRÁTICA



Ordem de compra para loja SkatesTown.



109

110

Arquitetura para computação móvel

No exemplo, repare que todo elemento pertencente à especi­

ficação dos schemas tem o prefixo “xsd:”. Esse prefixo vem de

XML Schema Definition, e sua utilização é padrão. No exemplo, o prefixo é associado ao namespace chttp://

www.w3.org/2OOl/XMLSchema>, que identifica a recomendação

W3C. Note que o namespace-padrão do exemplo é . Esse segundo refere-se à ordem de com­ pra da SkatesTown. O documento precisa desses dois namespaces

para identificar qual é relativo à operação (compra) e qual é rela­ tivo aos schemas. Ao declarar elementos em XML Schemas - ou seja, em do­

cumentos XSD - você vai utilizar a tag . Lembre-se sempre do “prefixo” “xsd:”. Os principais tipos dc elementos c suas respectivas descrições são:

■

Name - nome do elemento;

■

Type - tipo do elemento; minOccurs - número mínimo de ocorrências;

■

maxOccurs - número máximo de ocorrências.

O exemplo a seguir contempla todos os tipos citados:

Nesse exemplo, declaramos o elemento nome, que recebe um

tipo string e pode aparecer no mínimo nenhuma vez e. no máxi­ mo, uma vez. Aos minOccurs e maxOccurs, chamamos de atributos. Eles

justamente restringem o elemento. No nosso exemplo, “nome” de­

veria aparecer, especificamente, uma ou nenhuma vez. A seguir, o Quadro 3.3 exibe os atributos mais comuns. Quadro 3.3 Principais atributos.

Atributo

Descrição

length

Comprimento da cadeia de caracteres

minLength

Comprimento mínimo da cadeia de caracteres

maxLength

Comprimento máximo da cadeia de caracteres

minExclusive

Faixa exclusiva mínima de um número

maxExclusive

Faixa exclusiva máxima de um número

Notas

continuo

Webservices e serviços

111

continuação minlnclusive

Faixa inclusiva mínima de um número

maxlnclusive

Faixa inclusiva máxima de um número

totalDigits

Total de dígitos possíveis

Desconsiderando decimais

fractionDigits

Total de dígitos possíveis

Especificamente na parte fracionária

Fonte: adaptado de Qian, Allen, Gan e Brown (2010, p. 31).

Sobre os tipos de elementos, podemos classificá-los em vários grupos e subgrupos. Para facilitar seu entendimento, os tipos mais usados foram compilados no Quadro 3.4. Quadro 3.4 Tipos de elementos.

Tipo

Descrição

xsd:hexBinary

Dígitos hexadecimais

xsd:base64Binary

Dígito binário base 64

Boolean

xsd:boolean

1,0-true, false

String

xsd:strlng

Qualquer caractere Unicode

xsdioken

Caracteres sem espaço

xsd:dateTime

2015-10-12T13:20:00.000-03:00

Binários

Data/Hora

Notas

O exemplo ao lado se

refere ao dia 12 de outubro (10) de 2015, às 13:20 no horário de Brasília. O fuso horário é definido pelo UTC

separado por um ponto após a informação da hora - no caso, UTC-3, referente

ao horário de Brasília.

xsd:date

YYYY-MM-DD

xsdlime

HH:MM:SS.000

xsd:duration

P1Y2M3DT10H30M12.3S

É sempre um período de tempo. O exemplo ao

lado refere-se à seguinte informação: 1 ano, 2 meses,

3 dias, 10 horas, 30 minutos e 12,3 segundos.

continua

112

Arquitetura para computação móvel

continuação Numéricos

Links

xsd:integer

Números inteiros

xsd:positivelnteger

Números inteiros positivos

xsd:negativelnteger

Números inteiros negativos

xsd:nonNegativelnteger

Números inteiros positivos

Inclui oO

xsd:nonPositivelnteger

Números inteiros negativos

Inclui oO

xsd:decimal

Números decimais

xsd:anyURI

Fonte: adaptado de Graham et al. (2004, p. 60).

A declaração de atributos é similar à declaração de elementos.

Aqui, vocc tem três principais atributos:

■

name - nome do atributo;

■

type - tipo do atributo;

■

use - utilização do atributo.

Onde name c type especificam o nome c os tipos dc dados dos seus atributos. Os tipos já foram apresentados no quadro anterior. Use diz respeito à utilização do atributo, ao seu requerimento.

Eles podem ser requeridos, opcionais ou proibidos. Os exemplos a seguir apresentam esses atributos.

NA PRÁTICA Exemplo 1

Nesse exemplo, temos o atributo nascimento do tipo date (ano-mês-dia). Essa informação é obrigatória (use="required"). Veja o próximo exemplo: Exemplo 2

Já no segundo exemplo, temos o atributo sexo, que recebe o tipo string

(qualquer caractere). 0 seu uso é opcional. Sua não utilização não acarre­ tará em erros.

Webservices e serviços

Grupos Dissemos que os XML Schemas ajudam a organizar, entre ou­

tros detalhes, a ordem em que seus elementos devem aparecer.

Isso é possível por meio dos conectores. São três: all, choice e sequence. Veja o Quadro 3.5. Quadro 3.5 Descrição dos conectores.

Descrição

Conector

Elementos em uma lista podem aparecer em qualquer ordem

Uma lista de escolhas deve aparecer no documento de instância

Os elementos devem aparecer na ordem mostrada

Fonte: adaptado de Qian, Allen, Gan e Brown (2010, p. 32).

NA PRÁTICA A seguir, você tem alguns exemplos úteis dos conectores descritos no Quadro 3.5: Exemplo 1



Exemplo 2



Exemplo 3



No nosso primeiro exemplo, o conector sequence especifica que todos os

elementos devem aparecer na ordem em que foram dispostos no docu­ mento XSD. A única mudança do primeiro para o segundo exemplo é o

conector all. Nesse caso, all especifica que todos os elementos apareçam,

mas sem uma ordem predefinida.

113

114

Arquitetura para computação móvel

Por fim, o conector choice, do terceiro e último exemplo, nos permite dar a opção de apenas um dos elementos aparecerem no documento. Caso os

dois apareçam (no caso do exemplo, RG e CPF), ocorrerá um erro.

Processando o XML Processadores XML são as principais ferramentas para a mani­

pulação de documentos XML. Para a manipulação de documentos XML é necessário a exis­ tência de um analisador (parser) que suporte todas as funcionali­ dades necessárias para percorrer as estruturas destes documentos,

permitindo o acesso aos seus elementos e atributos. Cada parser possui suas próprias características. Estes processadores são APIs (Application Programming In­

terface) utilizadas para facilitar a leitura, criação e atualização dc

documentos no formato XML. APIs que disponibilizam dados XML para as aplicações po­

dem utilizar uma abordagem baseada em objetos ou em eventos. A seguir serão apresentados alguns processadores e suas características.

SAX O Simple API for XML (SAX) é um modelo orientado a even­ tos originalmente desenvolvido para Java. Sua rápida populariza­ ção tornou o modelo acessível também para outras linguagens,

como Pascal, C++, Perl e Python, mas suas versões oficiais sem­ pre são publicadas em Java.

Aqui, métodos de call-hack são invocados à medida que um analisador lê os dados XML. Esses métodos call-hack (o ContentHandler e o ErrorHandler, por exemplo, que você verá a seguir)

são derivados de padrões da linguagem Java. De falo, diversos métodos estudados nesta unidade são padrões Java. Diferentemente do DOM (que veremos a seguir), o SAX apre­ senta a característica dc ler fragmentos específicos de um docu­

mento XML, e não o arquivo na sua totalidade.

Para usar o SAX, você deve, em linhas gerais, escrever méto­

dos de call-hack. Existem quatro interfaces possíveis para esses

Webservices e serviços

métodos. Cada uma delas, obviamente, tem uma finalidade. São as seguintes:

org.xml.sax.ContentHandler

Os dados lidos pelo analisador SAX são registrados na interface da ContentHandler. Essa interface deve conter elementos correspondentes aos tipos de dados que fazem parte do documento XML (tags, namespaces etc.).

A ferramenta analisadora, então, lc um trecho do documen­

to c chama um método apropriado - e assim por diante.

org.xml.sax.ErrorHandler Aqui, quando o analisador SAX encontrar um erro, ele

não lançará uma exceção. Quando uma situação dessas ocorrer, ele chamará métodos do interceptador Error Handler. São três métodos possíveis:

1.

public void errorfSAXParseException exception) throws SAXException

2.

public void fata/ErrorfSAXParseException excep­ tion) throws SAXException

3.

public void warning(SAXParseException exception) throws SAXException

Um erro que não seja fatal comporta situações como

não conformidade em XML Schemas, por exemplo. Er­ ros fatais, por outro lado, significam que a formatação

do arquivo XML não está bem feita. Provavelmente, existe erro de sintaxe nesses casos - como uma tag

de início sem a respectiva tag de fim, ou então ambas

desparelhadas. ■

org.xml.sax.DTDHandler Analisa um documento XML com uma DTD (uma op­ ção ao XML Schema). São dois métodos:

1.

public void notationDecl (String name, String puhli-

cld, String systemld) throws SAXException

2.

public void unparsedEntityDecl (String name, String publicld, String systemld, String notationName) throws SAXException

115

116

Arquitetura para computação móvel

■

org.xmLsax.EntityResolver

Usado quando uni analisador SAX não consegue resol­

ver uma entidade externa. EntityResolver, então, deve ser chamado. Ele deve retornar um objeto org.xml.sax.

InputSource. Tem apenas um método:

1.

public InputSource resolveEntity (String publicld, String systemld) throws SAXException, java.io.IOException

DOM Como você leu em SAX, a diferença desse modelo para o DOM (Document Object Mode!) é que esse segundo analisa todo arquivo XML de uma única vez. Ao passo que o SAX lê partes específicas do arquivo, o DOM lê

o documento inteiro e armazena os dados cm estruturas com o for­ mato dc árvores - ou hierarquias - de objetos que se chamam nós.

O DOM apresenta a vantagem dc todo o documento ser aces­

sível aleatoriamente enquanto estiver na memória. Recomenda-se utilizar arquivos em menor volume, pois a utilização de arquivos

de grande volume causa atrasos no processo de leitura desses ar­ quivos para a memória. Para a utilização de arquivos de grande

volume recomenda-se o SAX.

JAXB A principal função do Java Architecture for XML Binding

(JAXB) é permitir transformações de classes Java e documentos de instância XML com objetos de instância Java. Isso facilita o desenvolvimento de serviços web. Em outras palavras, o JAXB

permite que você converta documentos XML em objetos Java. Mesmo que o XML seja um formato comum de troca de dados,

por vezes ele não é o mais recomendável. Em algumas aplicações, as representações para troca de informações devem ser feitas pre-

fcrencialmente por meio de objetos, recurso típico da linguagem Java. Objetos são incompatíveis com o formato XML. É por isso que essa ferramenta é importante.

O JAXB, então, vai converter dados XML em objetos Java. Por exemplo: pense em um documento XML que contenha in­

formações como nome, idade, sexo e outros dados sobre alguém.

Webservices e serviços

Realizando a conversão cm objetos Java, voce terá uma classe

Java para cada tipo presente no esquema XML - ou seja, justa­

mente os dados como nome, idade e sexo.

WSDL Webservices é um modo dc desenvolvimento dc software que leva cm consideração componentes remotos. Ele descreve como

um conjunto dc serviços dc terminais diferentes que trocam men­ sagens, ou seja, uma funcionalidade que pode ser descrita, pu­ blicada, encontrada e invocada dinamicamente em algum tipo

de rede (normalmente internet). Um exemplo dessa usabilidade são softwares que precisem de itens remotamenle locados para que funcionem. A descrição dessas mensagens trocadas é feita de

modo abstrato. Existem várias tecnologias, todas elas em XML:

SOAP, UDD1 e, a que veremos nesta seção, WSDL. A Linguagem de Descrição de Serviços Web (por conven­

ção, utilizaremos o termo WSDL, referente à sigla cm inglês para Web Services Description Language) lida com operações

nas quais é possível saber quais serviços estão disponíveis e como invocá-los remotamente e independe da linguagem na qual o webservice foi desenvolvido.

Com WSDL especifíca-se: o que o serviço faz, como chamar suas operações e onde encontrar o serviço.

Por ser em formato XML, também dispõe de tags, que cor­ respondem a serviços. Veja o exemplo a seguir. Depois, faremos algumas breves con­

siderações sobre o código.

NA PRÁTICA

definitions

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s-"http://www.w3.org/2001/XMLSchema" xmlns:tns="uri:weblogscom" targetNamespace="uri:weblogscom" xmlns="http://schemas.xmlsoap.org/wsdl/">

117

118

Arquitetura para computação móvel