Arquitetura para computação móvel-DarkMode [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

Recife c J'rrifi» âutcrt’

© 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

UMARIO 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

PRESENTACAO Nos catálogos de 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), têm 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 de

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 de que, para atender sob medida às necessidades tan­ to dos alunos de 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 de

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á devenvolvendo 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,

PARA LER!

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

CONHECER!

►

PARA ASSISTIR!

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

NA WEB 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!

REFÁCIO 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 de 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.

REFLITA 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 em 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.

(

w

1PARA 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 dc 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 de 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 dc modo

interativo. Por exemplo, enquanto o ciclo A realiza a tarefa 1, o ciclo B jrí 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 de vista considera que você, c 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 comprccndc-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

(■'0 z PARA SABER!

às necessidades da organização que fará uso desse sistema.

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.

PARA SABER!

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; dc 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.

*|

12

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.

Segurança (Security)

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

Erro (Error)

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

_ Propa9a

Defeito (Failure)

Causa

Falha (Fault)

13

I4

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.

PARA SABER!

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, c 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 geralmente 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 dc 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.

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

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.

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.

Categoria

Checklist

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.

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

Informação incluída correta mente em 99,9% de tempo

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

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

Resposta

Uma ou mais das seguintes:

com outro sistema.

de execução.

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

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,

4.

que já estão implementados

Qual é o custo das mudanças? Você deve considerar dois pontos:

e em uso (CLEMENTS;

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

Ambiente:

Alterações

tempo de design

realizadas

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

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.

Categoria Atribuição de

responsabilidades

Checklist

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. Geralmente, 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, falo 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 de tempo (throughtput); 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, escalabilidade) 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 latê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 latê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. Categoria Atribuição de

responsabilidades

Modelo de coordenação

Checklist 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

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

elementos arquiteturais Gestão de recursos

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

Tempo obrigatório

Para cada elemento, determinar:

mais eficiente.

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.

Partes do Cenário

Fonte de estímulo

Possíveis Valores 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

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.

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

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.

I Download

de novo aplicativo ou programa

I Ambiente:

I Usuário usa

tempo de execução

a aplicação de modo produtivo

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. Táticas de usabilidade

Iniciativa do usuário

Iniciativa do sistema

Cancelar

—

Modelo de tarefas

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/Retomar - 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.

Categoria Atribuição de

responsabilidades

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

a. b. c. d. e. f. g. h.

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 I--------------1--------------1

Profissional-i

♦ Stakeholders

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

5.

Negócios Técnico Projeto Profissional Stakeholders

Arquiteto Arquitetura 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 deTVe 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.1 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/7- 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 dc 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 dc estilos de arquitetura, des­

critas no Quadro 2.1. Quadro 2.1 Principais estilos de arquitetura.

Categoria

Estilo de arquitetura

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

interoperabilidade. 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 de 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 de arquitetura diz respeito à troca de informações,

com base no uso de 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: PARA SABER!

O message-bus tem

Comunicação orientada a mensagens - forma de comuni­

cação entre processos, em que todas as comunicações entre 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.

’'0 zPARA SABER! A implementação

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

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

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

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.

Cliente móvel: (Três camadas)

Para a rede e o back-end 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 de 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 três 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 àos 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 c 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 e 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-bus?

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 usabilidade, 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 testahilidade.

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

•o g ■g ;g

•' Fachada de aplicação • % ----------...................... -------.........................

| S' u

/Lógica deA/íomponentes de\A Componentes de ^negóciosJ\fluxo de trabalhqjyentidade de negócio

Íí

/componentes de\ /DadosauxiliaresX ÇAgentes de^ E T5 acesso a dados) e utilitários J serviços y

í

í

l

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 dc 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 de 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 eamada 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.

PARA SABER!

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 todo 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 dc 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 reutilizá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

O 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! 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.

1.

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

3.

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

PARA SABER!

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 ..., PARA SABER!

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

e 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 leria “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, temos 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

to Getting on

the

Boardc/

have

LINK>.

the

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

leriam 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 de 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

ck;

:

lang="en">Skateboard backpa­

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.

Caractere

Sequência de escape




&

&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 dc 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





cinput message="tns:pingRequest"/>



cblinding name="pingSoap" type="tns:pingPort">

transport-"http://schemas.xmlsoap.org/soap/ http"/>









Webservices e serviços

For a

complete

description of this

serv­

ice, go to the following URL: http://www.soapware.org/ weblogsCom







Sobre o exemplo, podemos dizer que: Por padrão, o código WSDL aceita dois parâmetros e retorna um valor booleano e uma string. Toda operação de entrada tem uma saída. Isso é necessário

para que o sistema forneça uma resposta.

As informações são apresentadas de maneira abstrata. Não há, necessariamente, detalhes que remetam ao ambiente dc

implantação.

Arquitetura orientada a serviços Introdução e fundamentos da SOA A primeira coisa que devemos considerar quando estudamos arquitetura orientada a serviços (SOA) é que se trata de uma abor­

dagem muito vasta no ramo de plataformas de computação dis­

tribuída. Ela engloba paradigmas próprios de design, conceitos, linguagens-padrão, modelos arquiteturais exclusivos, entre muitas

outras particularidades. Por isso mesmo o foco desse material será nos pontos principais dessa área, separados em tópicos-chavc. A SOA tem como finalidade melhorar requisitos como eficiên­ cia, produtividade e agilidade de uma organização.

A implementação dc uma arquitetura SOA pode conter, de

uma única vez, uma combinação de infraestruturas de suportes, tecnologias próprias e muitos outros serviços. Essa ampla gama

de possibilidades está expressa na Figura 3.1. Nela, diversos ele­

mentos participam e englobam a mesma abordagem SOA: de tec­

nologias de implementação a extensões de infraeslrutura etc.

119

120

Arquitetura para computação móvel

Figura 3.1 Exemplo de elementos que compreendem a SOA.

Camadas

físicas,

Recursos, \

repositórios

lógicas / Plataforma

Extensões da \

‘ em runtime

infraestrutura

Tecnologia da

Outras

implementação

partes

Fonte: Erl (2008, p. 25).

Do ponto dc vista dc design, a orientação a serviços c um con­

junto específico dele. Quando esses princípios de design são apli­ cados a uma lógica, chamamos isso dc lógica orientada a serviços.

Como você deve imaginar, o item essencial dessa relação é o serviço.

Segundo Thomas Erl (2008, p. 25), você pode caracterizar ser­

viços como “programas dc software fisicamente independentes, com características de design distintas que dão suporte à obtenção

dos objetivos”.

Um serviço recebe seu próprio conjunto de capacidades e respon­

sabilidades. Essas capacidades são correlacionadas por protocolos de serviços públicos. Quando isso ocorre, existe uma composição de serviços. A Figura 3.2 apresenta um exemplo dc composição dc serviços onde cada nó representado consiste cm um serviço. Figura 3.2 Exemplo de composição de serviços.

Fonte: Erl (2008, p. 25).

Os inventários de serviços compreendem vários serviços e esta­

belecem quais deles deverão ser reutilizados por várias composições.

Webservices e serviços

Por sua vez, as composições dc serviço consistem cm componentes

que podem estar contidos em inventários de serviços. Figura 3.3 Inventário de serviços.

Inventário de serviços

Suportados pela arquitetura orientada a serviços

Composição de serviços

Fonte: Erl (2008, p. 27).

Para facilitar seu entendimento, veja a Figura 3.4. Ela demons­ tra como os elementos podem estar relacionados em uma arquite­ tura orientada a serviços. Figura 3.4 Computação orientada a serviços.

é projetada para suportar a implementação de

Arquitetura orientada a serviços

édistinguida principalmente por

é projetada para suportar a criação e a evolução de um

é projetada para suportar a implementação de

derivadas de

gma do design orientado a serviços Ljornece princípios que modelam _ o design de

fornece princípios que modelam o design de

são compostas de

Composições de serviços

pode ser composta de

Lógica da solução orientada a serviços

Serviços

é composto de serviços padronizados Fonte: Erl (2008, p. 27).

Inventário de serviços

121

122

Arquitetura para computação móvel

Modelos de serviços Como serviços são componentes encapsulados, é possível observar algumas características. A seguir, listamos três dessas características:

1. 2. 3.

Encapsulanicnto - a lógica de encapsulamcnto utilizada. Reusabilidade - a capacidade de reutilização do serviço. Comunicação - os padrões de comunicação utilizados entre serviços.

A combinação dessas características resulta em três diferentes categorias, convencionalmente conhecidas como modelos de ser­ viços primários. Os três modelos de serviços primários são: 1. 2. 3.

Serviço de entidade. Serviço-tarefa. Serviço utilitário.

Serviço de entidade Formalmente falando, entidades são grupos de atributos. Por exemplo: se considerarmos os atributos guidão, rodas, pe­ dal c correia, o que vem à sua mente? Provavelmente, uma bicicleta. Nesse caso, bicicleta seria uma entidade, enquanto guidão, rodas, pedal e correia seriam seus atributos. Aplicando esse conceito em um ambiente organizacional, temos o exemplo da Figura 3.5. Nele,/w7icÍ0níirío é a entidade, e elementos como HorasSemanaisTrabalhadas, um dos seus atributos. Organizações geralmente têm (e definem) entidades de negócio relevantes. A partir delas, podem criar um modelo de serviço de entidade (ou serviço dc negócio centrado na enti­ dade, ou ainda serviço de entidade de negócio). Figura 3.5 Serviço de entidade: funcionário.

Fonte: adaptada de Erl (2008, p. 28).

Webservices e serviços

Para compreender melhor, pense cm métodos tradicionais.

Exemplos deles são criar, ler, atualizar, excluir etc. As entida­

des de negócio, nesse caso, geralmente são derivadas desses mé­ todos. Por isso mesmo, apresentam uma abstração mediana e são

altamente reutilizáveis. “Um único serviço de entidade pode ser

aproveitado para automatizar uma série de processos de negócio da empresa” (ERL, 2(X)8, p. 28).

Serviço-tarefa Do ponto de vista de entidade, tarefa é a sua etapa de execução. Quais os serviços que uma entidade deverá cumprir? Os serviços-

-tarefa estão uma camada acima dos serviços de entidade. O nível

de abstração deles é maior e sua lógica encapsulada não é muito reutilizável. Veja a Figura 3.6. Figura 3.6 Serviços-tarefa.

Análise

da receita

Envio

Fonte: Erl (2008, p. 29).

Geralmente, por ter a função pouco reutilizável, esses serviços

tendem a controlar todo um grupo dc outros elementos que lerão suas atividades herdadas dessa tarefa geral.

Serviço utilitário E o tipo dc serviço mais peculiar. Certamcntc vocc se lembra

de situações como registro dc eventos cm /og, notificação dc ex­ ceção e seus tratamentos e outros similares. Esse serviço realiza exatamente essas transformações.

Altamente reutilizável, ele consegue dialogar com diversas ca­

pacidades do aplicativo e, mesmo assim, tornar funcionalidades

123

124

Arquitetura para computação móvel

disponíveis cm cada processamento diferenciado. Essa camada dc

serviços é orientada pela tecnologia. Veja a Figura 3.7. Figura 3.7 Camada de serviços orientada pela tecnologia.

Transformar

APImport

APExport ARImport ARExport

Fonte: Erl (2008, p. 30).

Governança Universal Description Discovery and Integration - UDDI Pense na estrutura de uma lista telefônica. Ela c um grande diretório - ainda que analógico - de endereços, telefones e outras

informações sobre pessoas e, principalmente, estabelecimentos

e negócios pertinentes ao ambiente onde ela circula. O serviço UDDI, em tese, é praticamente a mesma coisa. O Universal Description, Discovery and Integration é um di­

retório em que são registradas empresas e/ou perfis de negócios. Daí o termo registrador UDDI. De fato, esse é um serviço web,

cm que você pode tanto publicar como buscar por webservices.

E algo comum provedores de serviços utilizarem do UDDI para divulgar os serviços que oferecem. Para publicar ou procu­

rar um registrador UDDI, vocc utiliza mensagens SOAP (por isso mesmo é um serviço estritamente de web). Ou seja, o acesso é feito por esse tipo de mensagem.

Existem dois tipos primários dc UDDI, e são os mais ampla­

mente usados: UDDIs públicos e UDDIs privados. As de tipo privado naturalmcnte têm acesso restrito. O acesso

ao registrador, nesse caso, é feito por uma única organização. Exis­

tem também controles de segurança para garantir a autenticidade

Webservices e serviços

e a veracidade dc quem está acessando o UDDI, garantindo a in­ tegridade dos registros.

Já os UDDI públicos são de livre acesso on-line. O maior registrador público é o UBR (UDDI Business Registry). Ele é hos­

pedado em conjunto pelas empresas Microsoft, IBM, SAP e NTT. Ao acessar esse banco de dados, você tem acesso livre e gratuito a

diversas interfaces cm HTML. Caso se cadastre, você pode parti­ cipar compartilhando seus próprios modelos - lembrando que eles

sempre serão públicos. Em muitos casos, tanto nos UDDI públicos quanto nos priva­

dos, é comum que cada registrador seja hospedado em pelo menos

dois sites. Esses sites fazem referências entre si. Cada vez que eles

são referenciados, dizemos que fazem um nó. Isso significa que qualquer informação que você publicar em um nó será visível e “pcsquisávcl” a partir dc qualquer outro nó da rede. Este c o caso, por exemplo, do UBR: a relação entre todos os hóspedes é feita por

meio desses nós. De fato, as buscas são visíveis sempre. Mas você

só pode fazer alterações no nó específico cm que a informação ori­

gina) foi publicada.

Estruturas de dados em UDDI UDDI permite cinco tipos dc estruturas dc dados. Quando exis­ te a troca de mensagens SOAP, são esses dados estruturados e em-

pacolados que são transmitidos. A seguir, você tem uma lista e uma

breve explicação dc cada um desses tipos dc estrutura dc dados. Lembre-se: todos eles são elementos XML.

1.

businessEntity

Compreende o encapsulamento de informações básicas de negócios. Por exemplo, nome, endereço, informa­ ções dc contato etc. Dentro dc uma businessEntity pode

haver um (ou vários) elemento(s) businessService. 2.

businessService É, literalmente, a descrição de um serviço prestado. Várias

estruturas businessEntity podem usar o mesmo business­ Service. O elemento XML dele, por sua vez, pode conter

um (ou vários) elemento(s) bindingTemplate.

125

126

Arquitetura para computação móvel

3.

binding Template

É a descrição do ponto de vista técnico do serviço a ser prestado. Contém informações de como conectá-lo ao

serviço web. Esse serviço é encapsulado por elementos tModel - que, por sua vez, podem estar presentes uma

ou muitas vezes em um bindingTemplate. 4.

tModel Define especificações. No caso dc serviços web, é o

tModel que fornecerá um link dc download do docu­

mento WSDL. E isso é tudo o que um registro UDDI faz: não fornece o arquivo em si, mas sim um link para baixá-lo.

5.

puhlisherAssertion

E o relacionamento entre duas entidades dc negócio. O relacionamento dessas cinco categorias é descrito na

Figura 3.8. Figura 3.8 Relação ente as cinco categorias.

Fonte: Qian, Allen, Gan e Brown (2010, p. 354).

Webservices e serviços

Em resumo SOA c uma abordagem arquitetural corporativa

que permite a criação dc serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplica­

ções e empresas. São princípios para SOA:

Serviços são Reutilizáveis Serviços compartilham um Contrato formal Serviços possuem um Baixo Acoplamento Serviços Abstraem a lógica Serviços são capazes dc se Compor Serviços são Autônomos Serviços evitam Alocação de Recursos por longos períodos Serviços são capazes dc ser Descobertos

A Figura 3.9 a seguir apresenta o funcionamento de uma ar­

quitetura SOA. Figura 3.9 Arquitetura SOA.

•

WSDL Service Endpoint

SOAP Message Registro de Serviços UDDI

Implementação

do Serviço JEE

127

128

Arquitetura para computação móvel

Exercícios de fixação 1.

Na Figura 3.10, cada esfera representa um serviço. Cada grupo de serviço é uma composição. Na imagem, existe uma re­ lação aplicada aos negócios já estudada

em "Introdução e fundamentos da SOA". Qual é a relação entre os elementos apresentados na figura?

Figura 3.10

íf ít í?

Equipe do projeto A

Planilha

Equipe do projeto B

de tempo

w ít ít

Equipe do projeto C

Planilha de tempo

Fatura

Fonte: Erl (2008, p. 35).

2. 3.

Qual é a função prática dos webservices? Considere os elementos a seguir e crie um grupo em que devam aparecer to­ dos eles na ordem apresentada. Não se esqueça de acrescentar o type adequado. a. Nome b. Sobrenome c. Data_Nascimento d. Sexo e. Endereço f. EstadO-Civil g. Profissão h. Nível Escolar

4. 5.

6.

7.

Qual é a importância dos XML Schemas? Explique a necessidade dos namespaces. Em qual situação são fundamentais para uma aplicação? Explique e dê exemplos: a. xsd:boolean b. xsd:duration c. xsd:positivelnteger d. xsd:nonNegativelnteger Considere os exemplos a seguir. Diga a quais modelos eles pertencem e o que significam em linguagem humana. a. P7A4M29DT21H55M11.1S b. 1994-04-22T22:30:40.000-03:00

Webservices e serviços

129

Estudo de caso Uma empresa deseja lançar um sistema de comércio eletrônico para vender seus pro­ dutos. Essa empresa vende produtos de di­ versas categorias, como roupas, perfumes e eletrônicos, e aceita diversas formas de pa­ gamento, como cartão de crédito e boleto bancário. No sistema de vendas implementado, cada produto deve ser cadastrado com sua descri­ ção, preço de venda, quantidade em estoque e respectiva categoria. Cada cliente que deseja realizar compras tem de ser cadastrar no sistema indicando seu nome, endereço e e-mail. Se o cliente for cor­ porativo, deve cadastrar seu CNPJ e, se for in­ dividual, seu CPF.

O cliente cadastrado pode realizar um pedi­ do de compra dos produtos em estoque na quantidade que deseja. O cliente escolhe uma forma de pagamento disponível e recebe, por e-mail, o número de pedido e informações do status do pedido. Após a confirmação do pagamento, a loja rea­ liza a entrega dos itens solicitados no endere­ ço do cliente, e envia por e-mail a nota fiscal eletrônica. O cliente pode cancelar seu pedi­ do, desde que não tenha sido pago e também consultar seus pedidos a qualquer momento. O sistema tem de ser capaz de reemitir uma nota fiscal de um pedido de compra de qual­ quer produto e respectivo preço na data da compra realizada pelo cliente.

REFLITA! Para a entidade PEDIDO deste sistema, que representa um pedido de venda que um cliente faz na loja virtual, quais os serviços podem ser definidos para que o site opere utilizando uma arquitetura de webservices.

Na mídia O Projeto NF-e teve como objetivo a implan­ tação de um modelo nacional de documento fiscal eletrônico, identificado pelo modelo 55, visando a substituir a sistemática de emissão

do documento fiscal em papel, modelos 1 e 1A, com validade jurídica garantida pela as­ sinatura digital do emitente, simplificando as obrigações acessórias dos contribuintes e

130

Arquitetura para computação móvel

permitindo, ao mesmo tempo, o acompanha­ mento em tempo real das operações comer­ ciais pelo Fisco. A Nota Fiscal Eletrônica (NF-e) é um documen­ to de existência exclusivamente digital, emitido e armazenado eletronicamente, com o intuito de documentar uma operação de circulação de mercadorias ou prestação de serviços, no cam­ po de incidência do ICMS, cuja validade jurídica é garantida por duas condições necessárias: a assinatura digital do emitente e a Autorização de Uso fornecida pela administração tributária do domicílio do contribuinte. A empresa emissora de NF-e gera um arquivo eletrônico contendo as informações fiscais da operação comercial, o qual deverá ser assina­ do digitalmente, transformando este arquivo em um documento eletrônico nos termos da legislação brasileira de maneira a garantir a integridade dos dados e a autoria do emissor. Este arquivo eletrônico será transmitido pela internet para a Secretaria de Fazenda, Finan­ ças ou Tributação da unidade federada de jurisdição do contribuinte emitente, a qual, após verificar a integridade formal, devolverá um protocolo de recebimento denominado "Autorização de Uso", sem o qual não poderá haver o trânsito da mercadoria, ressalvados os casos previstos na legislação para a hipótese de haver problemas técnicos na comunicação do contribuinte com a Receita. Após a Auto­ rização de Uso, que transforma o documento eletrônico no Documento Fiscal denominado Nota Fiscal Eletrônica, a Secretaria de Fazenda Estadual disponibilizará consulta, através da internet, para o destinatário e outros legítimos interessados, que conheçam a chave de aces­ so do documento eletrônico. As Secretarias de Fazenda Estaduais irão dis­ ponibilizar os seguintes serviços: a. Recepção de NF-e; 1. Recepção de Lote; 2. Consulta Processamento de Lote;

c. Inutilização de numeração de NF-e; d. Consulta da situação atual da NF-e; e. Consulta do status do serviço; f. Consulta cadastro; g. Registro de eventos. Para cada serviço oferecido existirá um webservice específico. O fluxo de comuni­ cação é sempre iniciado pelo aplicativo do contribuinte através do envio de uma men­ sagem ao webservice com a solicitação do serviço desejado. O webservice sempre devolve uma mensagem de resposta con­ firmando o recebimento da solicitação de serviço ao aplicativo do contribuinte na mesma conexão. A solicitação de serviço poderá ser atendida na mesma conexão ou ser armazenada em filas de processamento nos serviços mais críticos para um melhor aproveitamento dos recursos de comuni­ cação e de processamento das Secretarias de Fazenda Estaduais. Os serviços podem ser síncronos ou assíncronos em função da forma de processamento da solicitação de serviços: a. Serviços síncronos - o processamento da solicitação de serviço é concluído na mesma conexão, com a devolução de uma mensagem com o resultado do pro­ cessamento do serviço solicitado; b. Serviços assíncronos - o processamento da solicitação de serviço não é concluí­ do na mesma conexão, havendo a de­ volução de uma mensagem de resposta com um recibo que apenas confirma o recebimento da solicitação de serviço. O aplicativo do contribuinte deverá reali­ zar uma nova conexão para consultar o resultado do processamento do serviço solicitado anteriormente. O diagrama a seguir ilustra o fluxo conceituai de comunicação entre o aplicativo do con­ tribuinte e o Portal da Secretaria de Fazenda Estadual:

Webservices e serviços

131

Figura 3.11 Arquitetura de comunicação - visão conceituai.

.--•Contribuinte .................... . HTTPS Cliente NFe ( ERP ou software específict)

-Secretaria de Fazenda Estadual • Web Service© Transações

Fluxo de Comunicação

Serviços Assíncronos

Notas Fiscais

I

■'—| |

|

f~] /

j

Filas de Msgs

Aplicativo de Faturamento ( ERP ou software especificí)

NFEs

Fonte: NOTA fiscal eletrônica. Manual de orientação

do contribuinte - padrões técnicos de comunicação.

Versão 6.0, setembro 2015. Disponível em: . Acesso em: 15 jul. 2019.

DISCUTA! 1. 2.

3.

Qual é a arquitetura utilizada para esse projeto? Quais são suas características? Quais serviços foram definidos para a comunicação entre os diferentes sistemas? O que são serviços síncronos e assíncronos?

Na academia Ressuscitando dos mortos O crescimento estrondoso do Facebook terminou por diminuir consideravelmente o ritmo de crescimento de outras redes sociais: enquanto a plataforma de Zuckerberg subiu de aproximada­ mente 600 para 1.400 milhões de usuários de 2010 a 2014, o Twitter, por exemplo, saiu dos 150 para quase atingir a meta de 300 milhões. Além disso, o MSN Messenger já não existe e, recen­ temente, o Skype foi vendido à Microsoft. Nenhuma perda, entretanto, doeu tanto no brasileiro quanto a morte do Orkut, no dia 30 de setembro de 2014.

132

Arquitetura para computação móvel

Mas talvez não seja o fim. O web designer e programador Alex Becher, de 35 anos, ao saber dos rumores da eutanásia do Orkut (de fato, o Google informou a decisão meses antes), decidiu criar sua própria rede. Três meses depois de trabalhar todas as noites, nascia o Orkuti.net - versão brasileira do tão nos­ tálgico Orkut. Ele foi lançado no mesmo fatídico dia 30 de setembro de 2014, e conta com re­ cursos famosos como scraps, depoimentos, comunidades e mensagens privadas com amigos. O design do Orkuti.net também é extremamente fiel ao seu inspirador, e já vem com alguns temas e jogos embutidos. Para comemorar o primeiro ano de rede, Becher desenvolveu uma versão APK para Android.Tudo indica que, em breve, uma versão para iOS esteja disponível. A rede já conta com 600 mil usuários em dez países.

Fonte: adaptado de Freire (2015) e Giantomaso (2015). Imagine que você decida criar uma nova rede social. Seu objetivo é ser tão interessante quanto o Orkuti.net e conquistar usuários. Elabore um modelo, utilizando as táticas de XML Schema, que inclua todos os dados que você solicitaria ao novo usuário no ato do cadastro. Lembre-se de que um cadastro em uma rede social não é tão formal quanto um cadastro em um banco, e que dife­ renciais da sua rede contariam vantagens em relação às já existentes.

Recapitulando Nesta unidade, você passou a dominar a lingua­

gem XML e descobriu que esse é um dos cami­

nhos mais usados quando o assunto é troca de informações na web. Em outras palavras, o XML

é o ponto principal de qualquer webservice. Isso porque ele é leve e legível, permite adaptações e, em caso de documentos pequenos, pode até ser

escrito à mão - embora demande mais trabalho, claro. O XML nada mais é do que um documento organizado por marcações. Ele é estruturalmen­ te lógico e utiliza os sinais "" para delimitar elementos. É por isso que, mesmo sendo extre­ mamente trabalhoso criar um documento de descrição XML à mão, ainda sim seria tecnica­

mente possível. Você também aprendeu sobre a

variação XML Schemas e sobre o processamento de documentos XML - DOM, SAX e JAXB. Por fim, adentramos na arquitetura orientada a serviços, a SOA. Você aprendeu os conceitos bá­ sicos e a utilidade prática de se usar SOA em sis­ temas de locações distintas. Um dos pontos mais curiosos em SOA talvez seja o registrador UDDI. Quase como uma lista telefônica digital, ele com­ preende um catálogo extenso de estruturas e interfaces HTML totalmente gratuito. Eles podem ser privados ou públicos, como o UBR. Isso signi­ fica que se você quiser compartilhar seu conhe­ cimento com o mundo, é só fazer um cadastro e pronto, o acesso é livre. Daí para a frente, é só ser criativo(a) e aproveitar o mundo de oportunida­ des que só a internet oferece.

Webservices e serviços

133

PONTOS IMPORTANTES O XML (extensible Markup Language) foi criado a partir da necessidade de se ter um modelo de representação textual para informações estruturadas que fosse extensível e simples. O XML utiliza marcadores identificados pelos sinais o, chamados tags. Existem tags de início e tags de fim, sinalizadas por uma barra. Exemplo: e . A principal vantagem do XML é que ele pode ser lido tanto por software como por humanos. Por isso, um documento XML pode ser document centric, isto é, centrado em textos de marcação, ou data centric, em que as marcações são total­ mente estruturadas. O Prolog de um documento XML contém informações sobre a estrutura do docu­ mento, a codificação e outras característica. É inserido antes da marca de início do elemento raiz ou do documento. Elementos em XML determinam o início e o fim de uma função. São identificados por tags. Atributos são pares nome-valor inseridos dentro de uma tag. Caracteres especiais devem passar por escape. Namespace é uma propriedade XML para evitar conflito de nomes de elementos. Ele é identificado por um prefixo nos elementos, seguido de dois pontos. Existem dois métodos para definir a estrutura de um arquivo XML: Definição de Tipo de Documento (DTD) e XML Schema. XML Schemas definem o que pode aparecer em um documento (elementos, atri­ butos, entradas etc.) e suas respectivas ordens. Processadores XML são ferramentas que manipulam documentos XML a partir de um analisador (parser) que suporte todas as funcionalidades necessárias para percorrer as estruturas destes documentos. São processadores XML: Simple API for XML (SAX) - modelo orientado a eventos originalmente desen­ volvido para Java que analisa o XML em partes. Para utilizar o SAX, você deve escrever métodos de call-back. Document Object Model (DOM) - modelo que analisa todo o arquivo XML de uma única vez e armazena os dados em uma estrutura hierárquica. Java Architecture for XML Binding (JAXB) - permite transformações de classes Java e documentos de instância XML com objetos de instância Java, o que permite converter documentos XML em objetos Java. Web Services Description Language (WSDL) - lida com operações em que é possível saber quais serviços estão disponíveis e como invocá-los remota­ mente, independente da linguagem na qual o webservice foi desenvolvido. Serviços são programas de software fisicamente independentes e características de design distintas que dão suporte para se atingir objetivos. A arquitetura orientada a serviços (SOA) é uma abordagem projetada para su­ portar a implementação de serviços. Isso inclui paradigmas próprios de design, conceitos, linguagens-padrão e modelos arquiteturais.

134

Arquitetura para computação móvel

Por serem componentes encapsulados, os serviços possuem as seguintes características: ■ encapsulamento; reusabilidade; ■ comunicação. Existem três modelos de serviços primários, resultantes da combinação das dife­ rentes características dos serviços: Serviço de entidade - o serviço é baseado em uma entidade, que é um grupo de atributos. Por exemplo: em uma entidade funcionário, é possível ter ele­ mentos que determinam suas horas semanais trabalhadas, seus dados e tam­ bém ações, como atualizar informações. Serviço-tarefa - estão acima dos serviços de entidade. São mais abstratos e menos reutilizáveis. ■ Serviço utilitário - serviços altamente reutilizáveis que conseguem dialogar com diversas capacidades da aplicação, como registro de eventos em log e notificação de exceção. Universal Description, Discovery and Integration (UDDI) é um diretório em que são registradas empresas e/ou perfis de negócios, que pode ser público ou privado.

UNIDADE 4

LINGUAGENS DE DESCRIÇÃO ARQUITETURAL (ADL)

CONHEÇA Os conceitos de modelagem de arquitetura de software.

REFLITA Sobre a importância das linguagens de descrição arquitetural e modelagem de software no projeto de arquitetura de software.

DISCUTA Como a utilização da UML pode auxiliar no desenvolvimento do projeto de arquitetura.

APLIQUE Os conhecimentos adquiridos e desenvolva um projeto de arquitetura de software modelando as funcionalidades do sistema por meio da UML.

#UML

#DIAGRAMAUML

#ARCHITECTUREDESCRIPTION

01 OBJETIVOS DE APRENDIZAGEM Compreender

os princípios e os

conceitos estruturais e

comportamentais das ADLs.

Conhecer os principais modelos de ADL, como a Rapide e o

AADL. Dominar os conceitos

e os fundamentos da UML Adquirir conhecimento

teórico e prático dos diagramas de classe, sequência e de casos de

uso.

INTRODUÇÃO ÀS LINGUAGENS DE DESCRIÇÃO ARQUITETURAL (ADL) O que é ADL? Quais as principais linguagens de descrição arquitetural? Por que a UML é uma das ADL mais populares? O que são diagramas UDL? Qual a diferença entre diagramas estruturais e diagramas de interação?

Linguagens de descrição arquitetural (ADL)

137

Introdução Considere o processo de construção de um aparta­ mento. Por mais que você não seja um engenheiro, deve ter alguma ideia dos passos que normalmen­ te são necessários até que um prédio seja construí­ do e que pessoas possam morar nele. Em linhas gerais, podemos dizer que primeiro um engenhei­ ro ou arquiteto organiza as características físicas que a construção terá. Em seguida, ele desenvolve uma planta, uma espécie de desenho que detalha todos os aspectos físicos do apartamento - tanto os ambientes em si quanto os materiais com os quais esses ambientes serão construídos. Depois dessa etapa, é feita a análise do local físico onde a construção será feita e, só depois de toda a bu­ rocracia, iniciam-se as construções do imóvel, com base, sempre, na planta predefinida. Apesar de aparentarem detalhes maçantes e des­ necessários, imagine quais seriam as consequên­ cias se quem projetou a planta e todas as outras informações não esquematizasse todo o proces­ so. Como iria passar adiante suas idéias? Como a equipe de construtores poderia compreender a estrutura interna do edifício para que pudesse ser construído? Sem uma planta, sem um esquema prático e ricamente descrito, essa pessoa preci­ saria estar presente em todas as etapas da cons­ trução, verbalizando a todo o momento como o serviço deveria ser feito. Percebe como esse mo­ delo seria inviável?

A arquitetura de software é muito parecida com a construção civil em alguns aspectos. Um proje­ to de software precisa de um ou mais arquitetos de software, que devem pensar, prever e adequar o projeto de software. Uma vez pronto, o projeto pode ser desenvolvido por uma equipe de progra­ madores sem a supervisão direta do arquiteto de software. Nesta unidade, vamos aprender um pou­ co mais sobre as ADLs (ou linguagens de descrição arquitetural). Elas dizem respeito sobre a descrição da arquitetura do seu software, são elementos que você usará para descrever a funcionalidade e o fun­ cionamento do seu programa. Existem vários meios de se descrever uma arquite­ tura - ou seja, várias linguagens. Alguns exemplos, que serão tratados nessa unidade, são o AADL e a Rapide. Entretanto, todas as linguagens ADL apre­ sentam algumas características comuns. Elas são: componentes, conexão e configuração. Em linhas gerais, não importa o meio com o qual você vai rea­ lizar a descrição da sua arquitetura: todas elas con­ terão a especificação dos componentes utilizados, a relação da conexão desses componentes e como o programa é configurado. A linguagem mais utilizada para descrição de siste­ mas é a Unified Modeling Language (UML). Ela será tratada no último tópico desta unidade e mostrará como construir diagramas que abrangem uma vi­ são geral do seu programa.

Introdução às linguagens de descrição arquitetural (ADL) Architecture description language (ADL) Linguagens de descrição arquitetural (ADL, na sigla em inglês), nada mais são do que um grupo de linguagens. Elas têm como fun­

ção representar a arquitetura de sistema de um programa e definem:

138

Arquitetura para computação móvel

os tipos dc componentes; os comportamentos desses componentes; os elementos necessários para a interação entre dois ou mais componentes.

As ADLs separam elementos arquiteturais entre componen­

tes e suas conexões. Ou seja, seus conectores. Essas são as duas principais bases de descrição arquitetural. O bom uso de uma ADL requer o bom senso do arquiteto, assim como em muitos

tópicos dentro de arquitetura de software. Existem alguns pas­ sos, algumas características com as quais você pode equipar a descrição de sua arquitetura. Geralmente, para que a descrição

seja bem feita, são necessários pelo menos seis itens. Eles são listados a seguir. Composição - você deve descrever seu software como uma

série de elementos (componentes e conectores) independen­

tes entre si. Abstração - você deve abstrair as funções dos seus elemen­ tos na etapa da descrição da arquitetura. Isso aproxima os

seus componentes do mundo real sem causar complicações (por exemplo, utilize médico como elemento, e não médico

Paulo).

Reúso - lente tornar seus elementos rcutilizáveis, ainda que

cm cenários arquitetônicos diferentes. Configuração - diferentemente da composição, aqui você

deve se preocupar cm descrever a estrutura do sistema dc

software como um todo - independentemente dos elementos

estruturados. Heterogeneidade - você deve tentar manter padrões diversos

nas suas descrições, bem como criar descrições arquiteturais que se combinem de modo heterogêneo.

Análise - você deve proporcionar a oportunidade de outras pessoas poderem analisar seu projeto. Via de regra, todos que

analisarem duas descrições devem chegar basicamente nas mesmas conclusões. Isso caracteriza uma descrição arquite­

tural bem feita e objetiva.

É importante que você dê atenção especial às interfaces de componentes e conectores. Sem elas, sua descrição arquitetural torna-se uma grande coleção de elementos que se conectam sem

Linguagens de descrição arquitetural (ADL)

nenhuma semântica. Lembre-se dc que é sempre a interface desses dois elementos que vai determinar quais componentes são aptos a se conectarem e como isso será feito. Em outras palavras, as inter­

faces garantem que os resultados das operações do seu software sejam os desejados. Naturalmente, as interfaces estão presentes

nos conectores e nos componentes. Nesses dois casos:

A interface de um componente são pontos de ligação com o universo real.

As interfaces limitam-se ao teor operacional dos componen­

tes. Assim, elas: Especificam serviços (mensagens, operações, variáveis etc.).

Solicitam requisitos necessários aos serviços a outros componentes.

Interfaces de conectores limitam-se a criar pontos dc cone­ xão e associação com componentes.

Para criar a semântica entre essa relação componente/conector, é necessária uma semântica adequada. Para isso, existem várias linguagens ADL à sua disposição. Mas por que tantos modelos

de ADL? Você precisa ter cm mente que cada modelo arquitetônico va­

ria conforme a necessidade do cliente que usará o software. Isso muda completamente os pontos dc vista c os tratamentos que uma

arquitetura terá. Cada uma das várias linguagens ADL fornecem

facilidades c são recomendadas para determinadas estruturas. A seguir, listamos duas das principais linguagens.

Rapide Rapide é uma linguagem de descrição de arquitetura orientada

a objetos que trabalha com simulações de eventos. De modo geral,

ela combina resultados simulados com comportamentos proibidos ou permitidos de um sistema. Os eventos nessa ADL são ordena­

dos conforme restrições de tempo em detrimento da causalidade.

Aqui, os componentes, que são executados de forma independen­ te, podem ser observados e gerar eventos. É importante que você

saiba que cada evento é uma ocorrência de atividade. A Rapide faz que os componentes possam gerar dois tipos de eventos:

139

140

Arquitetura para computação móvel

1.

Eventos dependentes:

regras de comportamento de interface;

padrões de ações de módulos; eventos gerados por execução sequencial, entre outros. 2.

Eventos programados:

capacidade de cronometrar ações na/da interface;

tempos dc partida e chegada de eventos, entre outros. Ou seja, esse modelo sempre terá componentes, conexões e res­

trições. Ele suporta hierarquia, por isso mesmo aceita arquiteturas

aninhadas. Criando um modelo simples de elementos arquiteturais

de Rapide, leriamos um esquema como o exibido na Figura 4.1. Figura 4.1 Elementos da arquitetura Rapide.

Sobre a Figura 4.1, podemos observar os seguintes pontos: Componentes - a arquitetura implementa uma interface.

Componentes são os objetos dessa interface. Conexões - os componentes precisam se comunicar. Essa

comunicação é feita por meio dc conexões de envio c recebi­

mento. Essas ações ocorrem entre componentes dc uma mes­

ma interface. Restrições (padrões) - geralmente aparecem diretamente na

interface. Vinculadas a padrões de eventos. Sequenciais - geral mente aparecem em módulos, e são asso­

ciadas a tipos, objetos, declarações etc.

AADL A arquitetura de análise e design de linguagem (AADL) é uma

ADL voltada para a especificação, análise, integração de modo

automatizado e a geração de código de desempenho crítico em tempo real de sistemas de computação distribuídos.

Linguagens de descrição arquitetural (ADL)

Antes da etapa do desenvolvimento, a AADL permite a análise de projetos dc sistemas. É baseada no ciclo dc vida da aplicação. A AADL torna-se uma opção de linguagem de descrição com baixo custo porque apresenta algumas facilidades. Os pontos mais sig­

nificativos dessa linguagem são:

Ela assegura um nível ideal de sintaxe e semântica para um bom desempenho crítico do sistema. Isso faz que sua descri­ ção seja mais bem definida em termos técnicos.

Com a AADL, por meio de um único modelo analisável, você pode modelar arquiteturas em grande escala, poupando trabalho.

Ela analisa a estrutura c o comportamento do software cm tempo dc execução. Assim, pode complementar simulações funcionais.

xADL Dc todas as ADLs, talvez a de maior praticidadc seja o xADL.

Isso porque ele pode ser caracterizado como um conjunto de XMLSchemas. Ou seja: se você dominar a linguagem XML, terá

facilidades em descrever seu projeto utilizando o xADL. Justa­ mente por ser muito ligado ao XML. o xADL tem uma grande flexibilidade de modelagem. Alguns dos suportes fornecidos por

um grupo de esquemas em xADL são, por exemplo:

modelagem de elementos de um sistema em tempo de design e em tempo de execução;

suporte para vários tipos de arquitetura; possibilidade dc configurações de versões para seus esque­ mas, entre outros tipos dc gerenciamento.

PARA SABER!

0 xADL não está relacionado a um estilo arquitetural específico ou a uma

metodologia-padrão. Ele pode ser usado independentemente do domí­

nio escolhido, ou do ambiente de desenvolvimento. Mesmo assim, o am­ biente de desenvolvimento mais utilizado por quem opta pelo xADL é o ArchStudio. Você pode utilizar esse software, além de ferramentas bási­

cas para xADL que ele apresenta, para iniciar sua prática nessa linguagem.

141

142

Arquitetura para computação móvel

UML A linguagem unificada de modelagem é uma linguagem-

-padrão de descrição. Ou seja, por ela você pode visualizar o seu software por meio de esquemas e diagramas. Por convenção, utilizaremos a sigla UML, amplamente conhecida no ramo da informática. Ela é referente ao termo em inglês para essa lingua­ gem: Unified Modeling Language. De um modo geral, muitos

programadores não encontram diferenças ou barreiras entre as

etapas de pensar um sistema e construir os códigos do sistema. A linguagem UML, entretanto, facilita o processo de implemen­

tação. Isso porque ela detalha uma representação conceituai do sistema. E como se todo o processo lógico do software, todas as etapas do seu ciclo de vida, fossem descritos em diagramas. A UML tem finalidades bem definidas, como:

visualizar; especificar; construir; documentar artefatos.

Dc falo, sobre o último tópico citado, podemos dizer que a

documentação dc artefatos compreende, na descrição da UML, tópicos como: requisitos; arquitetura; projeto;

código-fonle; planos do projeto;

testes; protótipos; versões. Vale lembrar que, quando você modela um software utilizando

UML, está tornando os processos de uma aplicação compreensíveis para aqueles que não apresentam afinidade com a implementação

prática da aplicação. Há um motivo simples para isso: a UML é um padrão. Imagine, por exemplo, que o gerente de projetos de uma grande empresa solicite um novo sistema a um programador. Para que o gerente compreenda os processos do novo software, o progra­

mador desenha a funcionalidade da aplicação.

Linguagens de descrição arquitetural (ADL)

Imagine agora que, oito meses depois, o mesmo gerente precise dc alterações nesse software e contrate outro progra­ mador e arquiteto para realizar esse processo. Esse outro pro­

gramador, então, para que o gerente compreenda as mudanças,

desenha as alterações da funcionalidade do sistema de uma for­ ma completamente diferente do primeiro desenho. Para o ge­ rente, que não compreende programação, deve ser complicado, não? E por isso que a UML unifica e padroniza o modo com o

qual você vai representar os processos da sua aplicação. Inde-

pendentemente de quem fará a descrição, por mais que existam particularidades, a base, o esqueleto será sempre o mesmo. O

que facilita imensamente a troca de informação entre programador/cliente c ate mesmo a troca dc conhecimentos entre

programadores. Além dos diagramas, a UML compreende itens c relacionamentos.

Itens Sobre itens, podemos subdividi-los cm quatro subitens: itens estruturais, comportamentais, dc agrupamentos c anotacionais. Veremos esses modelos brevemente nos tópicos a seguir:

Itens estruturais São entidades físicas ou abstratas de um domínio, definidos com notação específica em um diagrama da UML. É a área mais

próxima do mundo real, pois faz ligação com elementos físicos.

Um grupo estrutural forma uma classe. Classes implementam uma ou mais interfaces. A seguir, temos um exemplo:

Janela

Origem

Tamanho AbrirO

FecharO MoverO

ExibirO

As classes são sempre exibidas em retângulos, contendo nome, atributos e operações. O exemplo anterior apresenta a classe

143

144

Arquitetura para computação móvel

janela, para esta classe observamos os atributos origem c tama­ nho, e as operações abrir, fechar, mover e exibir. Observe que os atributos são as características e as operações são as possibilida­

des de ação em relação à janela. A interface é um grupo de operações abstratas de uma classe. A classe interface define graficamente quais operações devem ser implementadas de maneira similar em todas as classes que

forem implementadas. «interface»

panela AbrirQ

FecharO MoverO

ExibirO

Elementos interagem entre si. As colaborações definem essas

interações. Uma classe pode participar dc várias colaborações.

Graficamente falando, esse recurso é exibido por meio dc uma elipse tracejada.

I

I

Cadeia de responsabilidades

/

\

Os casos de uso, em UML, são uma série de ações que trazem

resultados que podem ser observados e medidos. São representa­ dos por uma elipse de traço contínuo e o texto deve sempre des­ crever uma ação. Essas ações geralmente estão mais próximas do

usuário, do mundo real.

Colocar pedido

Linguagens de descrição arquitetural (ADL)

Itens comportamentais

Os itens comportamentais do projeto de software são repre­ sentados por verbos que descrevem o comportamento de uma

determinada funcionalidade. Considere sempre que interação diz respeito à troca de mensagens entre conjuntos de objetos dentro do contexto da sua aplicação. Essa troca de mensagens é exibida

da seguinte forma em um diagrama da UML. exibir

Itens de agrupamentos

Itens dc agrupamentos existem para se realizar a compilação c a organização das funções de sua aplicação no UML. O principal modelo de agrupamento se chama pacote. No entanto, os pacotes

são apenas uma representação conceituai de um conjunto de fun­ ções da sua aplicação e, portanto, não persistem além da etapa de desenvolvimento do software. Os pacotes são exibidos da seguinte

forma em diagrama da UML.

Regras de negócios

Itens anotacionais

Os itens anotacionais consistem no recurso para adicionar

conjunto de informações extras que ajudem a ampliar o entendi­ mento de uma modelagem de software. São informações que não

entram no corpo do diagrama, mas são úteis a quem o analisa.

De maneira bem simples, é o equivalente às anotações que você realiza no Microsoft Word. São representadas da seguinte forma:

Retornar cópia

145

146

Arquitetura para computação móvel

Relacionamentos Os relacionamentos dentro dos diagramas da UML podem ser

subdivididos em quatro especificações: dependência, associação, generalização e realização.

Relacionamento de dependência Quando dois itens estão relacionados dc modo semântico, cm que uma alteração no item A pode criar alterações no item B, di­

zemos que eles estão em um relacionamento de dependência. Esse

relacionamento é descrito da seguinte maneira: --------------------------------------------------------------------------------------- >

Relacionamento de associação

O relacionamento de associação é um grupo de conexões entre

objetos que são instâncias de classes. Representa a ligação entre o todo e suas partes. E descrito graficamente da seguinte maneira: 0..1___________________________ •

empregador

funcionário

Relacionamento de generalização De modo geral, a generalização/especialização é uma relação

onde os elementos generalizados herdam características, compor­

tamentos e funcionalidades dos elementos específicos. E descrito graficamente por meio de uma linha contínua em forma de seta.

------------------------------------------------------------------------------- >

Relacionamento de realização

E a relação semântica entre o contrato dc um classificador e a execução desse contrato por outro classificador. Geralmente é representada por uma seta dc linha tracejada com ponta fechada na cor branca.

Linguagens de descrição arquitetural (ADL)

Diagramas Os treze tipos de diagramas UML são I.

Diagramas de estrutura:

1.

Classe.

2.

Objetos.

3.

Componentes.

4.

Estrutura.

5.

Pacotes.

6.

Implantação.

II.

Diagramas de comportamento:

7.

Casos de uso.

8.

Atividades.

9.

Máquina de estado.

III. Diagramas de interação: 10. Sequência.

11. Comunicação. 12. Tempo. 13. Visão geral de interação. Os diagramas que são abordados nesta unidade são: diagrama

de classe, diagrama de sequência c diagrama de casos de uso, que

são os três diagramas essenciais para o desenvolvimento de uma arquitetura para computação móvel.

Classe Este talvez seja o diagrama mais utilizado cm sistemas orien­

tados a objetos. Aqui, você vai apresentar um plano geral do seu

software dc forma estática. Para entender melhor, veja a Figura 4.2. Repare que na Figura 4.2 é apresentado um diagrama dc classe

de uma empresa, em que são abordados todos os itens essenciais: classes; interfaces;

relacionamentos: dependência; generalização; associação.

147

148

Arquitetura para computação móvel

Figura 4.2 Diagrama de classe.

Fonte: Booch, Rumbaugh e Jacobson (2006, p. 116).

O desenvolvimento desse diagrama é essencial para mensu­ rar o relacionamento entre classes do seu projeto de software.

O diagrama de classe apresenta a relação entre suas classes e

Linguagens de descrição arquitetural (ADL)

suas funcionalidades. Por exemplo, ao construir uma casa, um

arquiteto não poderia colocar uma porta mais larga que a pare­ de onde será assentada, ou então não pode colocar uma porta

em um cômodo onde não exista espaço para que ela seja aberta. Esse diagrama ajuda você a visualizar essas situações no

ponto de vista da programação. Na Figura 4.2, por exemplo, temos a classe pessoa. Os atributos da pessoa, então (da clas­

se), no exemplo, são seu nome, seu código e título. Repare que

as funções dessa classe são dirigidas exatamente ao que ela se refere (no caso, pessoas). No exemplo, as funções são obter

foto, obter telefone, obter registros pessoais, entre outros. Ora,

qualquer pessoa tem um número dc telefone, registros pessoais (como contas, comprovantes) c pode tirar uma foto. Assim, a

funcionalidade da classe está dc acordo com o que ela se re­ fere. É como no nosso exemplo da construção da casa. Não iria adiantar nós colocarmos na classe pessoa a função obter código fonte. Não faria sentido - assim como colocar uma

porta em um cômodo que não tenha espaço para que ela seja aberta - uma vez que, naturalmente, não apresentamos códi­

gos fonte. Tipos de modelagem

Você pode modelar seu diagrama de classe em três formas di­ ferentes. Elas estão listadas a seguir:

1.

Modelagem do vocábulo de um sistema:

Compreende qual o nível de abstração do sistema e seus limites - ou seja, até onde vai a responsabilidade de cada elemento do seu software. 2.

Modelagem dc colaboração simples: Sempre que você agrupa classes, interfaces ou ou­ tros elementos, a fim de analisar um comportamento maior e não tão específico, você estará analisando uma

colaboração. Esse tipo de diagrama privilegia a relação semântica

dessas colaborações, e é indicado para os momentos em

que você deseja analisar o trabalho conjunto de colabo­ rações como apresentada na Figura 4.3.

149

150

Arquitetura para computação móvel

Figura 4.3 Modelagem de colaboração simples.

Fonte: Booch, Rumbaugh e Jacobson (2006, p. 123).

3.

Modelagem de esquema lógieo de um baneo de dados: Por meio dos modelos lógicos de baneo de dados, você

pode armazenar informações de um banco dc dados re­ lacionai em um modelo orientado a objetos.

Sequência Diagramas dc interação são voltados para o tempo dc vida dos objetos da sua arquitetura. Isto é, totalmente cm tempo dc execução. Esses diagramas podem ser de sequência ou de co­

municação. Ambos têm como finalidade expor as interações que

seu sistema executa. Mas enquanto o diagrama dc sequência se preocupa em evidenciar as trocas de mensagens propriamen­ te ditas, os de comunicação se focam em como os objetos es­

tão vinculados. Aqui, vamos nos aprofundar nos diagramas de sequência.

Linguagens de descrição arquitetural (ADL)

Como já dito, esse tipo dc diagrama se concentra nas trocas de mensagens no seu sistema por meio dc um determinado perío­

do de tempo. Os primeiros objetos que participam dessa troca de mensagens são colocados na parte superior do diagrama, seguidos pelos demais na ordem em que interagem.

Aqui, neste diagrama, podemos organizar nossos dados se­ guindo a lógica de dois eixos: ao longo de um eixo X imaginário, você dispõe todos os objetos que vão se relacionar, na ordem em

que relacionam. Já no eixo Y, você dispõe as mensagens: elas apa­ recem em ordem crescente (de tempo). Sempre de cima para baixo (Figura 4.4). Figura 4.4 Organização de dados seguindo a lógica de dois eixos.

Fome: Booch, Rumbaugh e Jacobson (2006, p. 277).

Sobre a Figura 4.4, podemos fazer as seguintes observações.

As linhas verticais representam o tempo de vida do objeto. As linhas de vida apresentam barras. Elas indicam o ponto exato no tempo analisado em que o objeto começou a exis­ tir. Quando ele deixa de existir, insere-se um “x” no final

da barra.

151

152

Arquitetura para computação móvel

Linhas horizontais são as mensagens que os objetos trocam.

Estas têm um pequeno rótulo e parâmetros. Linhas horizontais tracejadas são mensagens de resposta. Seu

uso não é obrigatório. De fato, muitas vezes essas mensagens

de resposta nem são exibidas no gráfico. O motivo é sim­

ples: poluição visual. Seu uso acarreta em muitas setas no diagrama, o que pode ser confuso. Opte por usar esse recurso

apenas quando for realmente necessário.

Controle estruturado Com o diagrama dc sequência, você consegue representar de modo simples uma troca contínua de mensagens lineares. Mas às vezes precisa representar fluxos condicionais ou de repeti­

ção no seu sistema. Por exemplo: representar um loop dentro

do diagrama de sequência pode ser algo complicado, até mesmo impossível.

Exatamente por isso existem representações específicas para operadores de controle. Eles geralmente são apresentados em for­

ma de um retângulo com uma tag. A tag vai definir o tipo de ope­ rador vigente. Linhas dc vida atravessam o operador. Isso significa que ele se

aplica aos objetos daquela linha dc vida vertical. Caso a condição

não se aplique ao objeto, basta interromper a linha de vida no iní­ cio da condição, e retomá-la depois.

Tomemos como exemplo o operador loop dentro do sistema de um caixa eletrônico. Quando o usuário digita uma senha, ele

está enviando uma mensagem para o sistema. O sistema deve verificar essa senha e, caso esteja incorreta, devolverá uma men­

sagem e acionará o loop - ou seja, vai retornar para a tela de

inserção de senha. Isso vai se repetir até que a senha seja correta (ou até que o número limite de tentativas seja alcançado). Por

outro lado, quando digita o número da sua conta e fornece um valor para fazer um saque no caixa eletrônico, você está envian­

do duas mensagens, paralelamente, para o sistema responder com apenas uma mensagem/ação: entregar o dinheiro solicitado.

Esse tipo de ação - o envio paralelo de mensagens (no caso, conta e valor de saque) - é chamado par. Essas duas situações são exemplificadas na Figura 4.5.

Linguagens de descrição arquitetural (ADL)

Figura 4.5 Diagrama.

sd saque

usuário: Pessoa

banco: caixa automático

i __________ i_______________________________ i loop (1,3)

i

------------- ' i

[senha invalida] i

digitar (senha)

. Acesso em: 15 jul. 2019. GIANTOMASO, I. Orkuti comemora 1 ano com 600 mil usuários c

promete app para iPhone. Techtudo, 30 set. 2015. Disponível cm: .

Acesso em: 3 nov. 2015. GRAHAM, S. et al. Building Web Services with Java. Indianapolis: Sams Publishing, 2004. Disponível cm: . Acesso cm: 3 nov. 2015. KELLY, T. Safety Tacticsfor Software Architecture Design. York, UK:

University of York, 2(X)8. Disponível em: . Acesso cm: 27 out. 2015. KOLB, J. J. O modelo em cascata. Compartilhando, 7 nov. 2013.

Disponível em: . Acesso em: 22 out. 2015. LAPRIE, J. C. Cosies A. Dependability: A Unifying Concept for

Reliable Computing. IEEE Z2 International Symposium on Fault

Tolerant Computing - FTCS'82, 1982.

LAPRIE, J. C. Dependability: Basic Concepts and Terminology. Viena: Springer-Verlag, 1992. LAPRIE, J. C. Dependable Computing and Fault Tolerance: Con­

cepts and Terminology. 15th IEEE International Symposium on Fault Tolerant Computing - FTCS'85, Ann Arbor, Michigan, Es­

tados Unidos, pp. 2-11, 1985. LEE, V; SCHNEIDER, H.; SCHELL, R. Aplicações móveis:

arquitetura, projeto e desenvolvimento. Trad. Amaury Bentes e

Deborah Rüdigcr. Rev. tcc. Renato Haddad. São Paulo: Pearson Education do Brasil, 2005.

LEME, E. Análise de falhas em comunicação multicast-gossip no ambiente MANET. 2016. 107 f. Dissertação (Mestrado) - Área de

Referências

Sistemas dc Informação c Comunicação, Universidade Estadual

de Campinas, Limeira, 2016. MEIER, J. D. et al. Microsoft application architecture guide -

patterns & practice. 2nd ed. |s.l.|: Microsoft, 2009. NOTA fiscal eletrônica. Manual de orientação do contribuinte -

padrões técnicos de comunicação. Versão 6.0, setembro 2015. Dis­

ponível em: . Acesso em: 15 jul. 2019. QIAN, K.; ALLEN, R.; GAN, M.; BROWN, R. Desenvolvimento Web Java. Rio de Janeiro: LTC, 2010.

ROMER, R. Desenvolvimento dc apps no Brasil está cm um bom

momento, mas enfrenta desafios. Canaltech, 2 maio 2015. Disponível em: . Acesso em: 5 out. 2015.

SOMMERVILLE, I. Engenharia de Software. 9 cd. São Paulo: Edi­ tora Pearson, 2011. WU, W.; KELLY, T. Safety Tactics for Software Architecture Design.

Computer Software and Applications Conference, 2004. Disponível cm:

. Acesso cm: 27 out. 2015.

167

ESPOSTAS Unidade 1 Exercícios de fixação 1.

Arquitetura dc software foca cm todos os aspectos da produ­ ção dc software, desde os estágios iniciais da especificação

do sistema ate sua manutenção, quando o sistema já está sen­ do usado. Assim como na Arquitetura da construção civil, en­ genheiros fazem as coisas funcionarem. Eles aplicam teorias, métodos e ferramentas onde for apropriado. No entanto, eles os usam seletivamente e sempre tentam descobrir as soluções

para os problemas, mesmo quando não há teorias e métodos

aplicáveis. Os engenheiros também reconhecem que devem

trabalhar de acordo com as restrições organizacionais e finan­

ceiras, então buscam soluções dentro dessas restrições. 2.

Dentro do contexto técnico a arquitetura de software retira

ou associa qualidades aos atributos de um sistema, possibi­

lita a previsão de vários aspectos em sistemas de qualidade e facilita a gestão de mudanças. Para o contexto de ciclo de

vida do projeto, auxilia em todas as fases de desenvolvimen­ to do sistema; atende as necessidades dos negócios de uma organização em que o sistema será implantado e garante que arquitetos de softwares adquiram conhecimento e habilidades

para construção de bons softwares. 3.

As diferentes visões de um negócio organizacional, junta­ mente com os aspectos técnicos, atributos, qualidades e as­

sociações de um sistema, definidas pela equipe técnica de um projeto de desenvolvimento de software, por meio de uma abordagem de desenvolvimento, definem os stakeholders do

projeto de desenvolvimento dc software. Profissionais dc de­ senvolvimento dc software: analistas, engenheiros de requi­ sitos c arquitetos de software, em conjunto com os demais

170

Arquitetura para computação móvel

stakeholders definem uma arquitetura dc software para a im­ plementação dc um sistema dc software.

4.

A arquitetura de software atinge vários pontos que ultrapas­ sam o ambiente de desenvolvimento dc projeto, podendo ser

encarada, por exemplo, como um recurso de auxílio na rela­

ção dc uma empresa com seus stakeholders Considerando apenas o contexto técnico de uma arquitetura de software,

podemos dizer que ela retira ou associa qualidades aos atri­

butos de um sistema; possibilita a previsão de vários aspectos em sistemas de qualidade e facilita a gestão de mudanças. 5.

Interoperabilidade c a capacidade dc o sistema trocar infor­ mações c dados, cm vários níveis do sistema c interpretar da­

dos corretamente quando recebidos.

Como exemplo podemos utilizar aplicativo para celular para que possibilita o transporte dc pessoas, onde o usuário encon­

tra o carro mais próximo c disponível, visualiza no mapa por meio de gcolocalização onde o carro se encontra e onde a

pessoa se encontra. O usuário paga por esse serviço a cada vez que utiliza. Neste sistema existe uma interface dc integra­ ção com o servidor de dados, com os serviços de GPS, com a

operadora financeira do cartão de crédito.

Estudo de caso a) Quando não se utiliza uma quantidade limite de tentativas de acesso para autorização dos serviços o sistema se torna vulnerável no requisito dc segurança. Como o invasor ten­

tou inúmeras vezes até conseguir o acesso, não foi utiliza­

da uma tática para barrar a quantidade dc tentativas dc acesso c bloqueio. b) Dentro do Requisito de Disponibilidade, a tática dc detec­ ção de falhas, como o monitoramento, Time Stamp, por

exemplo, o sistema identifica o funcionamento indevido da funcionalidade. Usando essa ferramenta é possível de­ tectar o congestionamento na rede e anomalias em funcio­

nalidades do sistema, aumento do tráfego a dados, por exemplo, de forma não definida nas funcionalidades do sistema. Outro ponto é a análise dos logs do servidor para

identificar atividades suspeitas. Qualquer requisição feita

Respostas

ao seu servidor deixará algum tipo dc informação. Estu­ dando os registros das conexões, é possível identificar se

há algum ataque. Um indicativo de ação suspeita são visi­ tas regulares ao seu endereço, diversas vezes num período muito curto de tempo. Portanto, se o mesmo IP aparece

nos registros, as chances de presença de invasão são altas. Outra forma é investigar se o IP está em alguma blacklist e qual o motivo de sua classificação numa lista de baixa

reputação.

c) Um tipo de defesa pode ser feita nos roteadores para blo­

quear os endereços IP de origem da invasão. Alternativa é reconfiguração automática do sistema ou remoção dos

serviços vulneráveis.

Na mídia 1.

Requisitos não funcionais para a arquitetura:

Disponibilidade: Sistema deve estar pronto quando so­ licitado. Garantia de 99% de disponibilidade, ou seja,

parada de diária permitida de no máximo 25 minutos. Interoperabilidade: Sistema deve estar apto a efetuar troca de dados entre os demais sistemas que se integra

(Servidor dc Aplicação, Servidor de Dados e Aplicativo dc Celular, Aplicativo SmartTv). A troca de informações ocorre de maneira segura, com confirmação da solicita­ ção e resposta em tempo hábil. Escalabilidade: Sistema preparado para grandes al­

terações de requisitos e aumento de usuários em curto

período de tempo. Adequação de plataforma de desen­ volvimento, servidores de aplicação e dados.

Performance: Garantir tempo razoavelmente curto entre

uma solicitação do usuário para uma função do sistema e a resposta a essa solicitação pelo sistema. As transações

devem ser rápidas e cova feedback para o usuário.

Segurança: Proteger os dados dos usuários do sistema, com regras bem definidas de acesso, perfil. Utilizar téc­ nicas se segurança para proteção dos dados e das transa­

ções realizadas pelo sistema. Garantir que alterações em dados sejam realizadas apenas pelo devido solicitante e

171

172

Arquitetura para computação móvel

com autorização. Garantir a privacidade dc cada usuário, incluindo termos de aceite de acesso e não disponibilizar informações sem devidas autorizações do usuário.

Usabilidade: Interface amigável, fácil e intuitiva nas aplicações realizadas pelo usuário final. 2.

Modelagem para esse sistema Categorias

Recomendações

possui Perfil

—

Conteúdo

Filme

>a ► oerie

cria

Cliente

possui ►

Conta

Plano

contrata ►

Plano Básico

Plano Premium

Plano Padrão

Unidade 2 Exercícios de fixação 1.

A figura apresenta os três pilares da arquitetura de software. Representa a interação entre usuário, objetivos da empresa e o sistema em si. Esta interação permite que os objetivos de

uma empresa sejam atingidos, por meio de recursos profis­ sionais - os usuários que utilizam um sistema informatizado, onde atividades são automatizadas.

2.

Como principal categoria, destaca-se a categoria Comunicação,

que é onde ocorre a i nteração entre as i nformações para uma arqui­

tetura. São definidos dois estilos para a categoria Comunicação: SOA - (Service-Oriented Architecture) - Arquitetura

orientada a serviços, baseada no preceito de organização

em serviços, ou seja, vários sistemas que se comunicam por interoperabilidade. A troca de informações é feita

por meio de protocolos entre os sistemas. Isso possibilita

Respostas

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.

Message-Bus ou barramento - Esse estilo dc arquitetu­

ra diz respeito à troca de informações, com base no uso dc um ou mais canais dc comunicação ou barramento.

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

tes por meio dc mais dc um canal dc forma única, ou seja, suas aplicações podem interagir sem a necessidade

dc ter contato com informações desnecessárias. 3.

A arquitetura base descreve o programa existente, ou seja, faz referências ao que ele será na sua finalização, sendo a partir

dessa base que são realizadas as arquiteturas candidatas.

As arquiteturas candidatas são específicas aos cenários cria­ dos. Será implantado o estilo arquitetônico escolhido e defi­

nição dc tecnologias, atributos dc qualidade. 4.

a) Técnicas dc interação são utilizadas para uma melhor de­ finição da arquitetura de software. São executadas cinco etapas para esse processo na seguinte ordem:

1. Identificar os objetivos da arquitetura 2. Identificar os principais cenários

3. Criar uma visão geral do aplicativo 4. Identificar os pontos principais 5. Definir as soluções

Esse é um ciclo que pode ter várias interações.

b) A categoria de “Interação” utiliza técnicas interativas que

ajudam a potencializar a arquitetura, deixando-a mais próxi­ ma possível dos objetivos organizacionais. Como estilo para essa categoria destaca-se ’Entradas c saídas” que ajudam a

formalizar os requerimentos e as restrições que a arquitetura deve conter, como, requisitos funcionais, não funcionais, atri­ butos de qualidade, segurança, confiabilidade.

5.

Definir cenários-chave na elaboração da sua arquitetura torna esse processo e o resultado final mais preciso, esses recursos

auxiliam na escolha de decisões na fase de criação da me­

lhor arquitetura. Exemplo, para um sistema de transporte por aplicativo de celular, o principal cenário é a “transportar pes­

soas de um local para o outro”. Ao identificar esse cenário e

173

174

Arquitetura para computação móvel

preparar toda a modelagem, utilizando casos dc uso, por exem­ plo, pode-se então documentar as principais funcionalidades, o

fluxo principal c os fluxos alternativos (exceções) que podem ocorrer nesta funcionalidade. Sabendo o que esta funcionalida­ de terá c como serão realizadas as atividades c possível definir

uma melhor arquitetura ao conhecer o negócio.

Estudo de caso 1.

A arquitetura orientada a serviços é baseada no preceito de or­ ganização cm serviços, ou seja, vários sistemas que se comu­

nicam por interoperabilidade. A troca de informações é feita por meio dc 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 dc redes

de conexões”. Para essa API é definido um serviço que pode ser acessado pelos clientes que utilizarão os serviços da Uber ou 99. Esses serviços trocam mensagem para apresentação dos

dados para proteção do motorista e do passageiro. 2.

A possibilidade dc utilizar novamente os serviços comuns dc

segurança para essa API, por meio de interfaces maiores, ga­ rante menor custo e o reúso para a arquitetura SOA.

Camada de '

Negócio

Disponibili/ar Dados de Segurança

)

Utilizar Dados de Segurança

J

Gerenciar denúncias e medidas de proteção J Camada de

Dados

Armazenamento de Dados

)

Respostas

Na mídia 1.

Os desafios são Disponibilidade (SLA), Performance, Segu­ rança (e propagação de identidade), Excelência Operacional

e Governança. 2.

Vantagens, tais como: Reusabilidade, Agilidade e Impacto

mínimo para mudança. 3.

Integrar com os serviços com sistemas legados pode ser um

desafio, pois os mesmo muitas vezes não foram desenvolvidos baseados em camadas e o negócio não ser bem definido, além

de tecnologias ultrapassadas. Além de que há muito ceticismo:

“As pessoas não acreditam que possa acontecer. ”

Unidade 3 Exercícios de fixação 1.

Um serviço recebe seu próprio conjunto de capacidades e responsabilidades. Essas capacidades são correlacionadas por protocolos dc serviços públicos. Quando isso ocorre,

existe uma composição dc serviços. Cada nó representado consiste cm um serviço. A Equipe A define e utiliza o ser­

viço Fatura. A Equipe B define e utiliza o serviço Planilha de Tempo. Ambos os serviços se tornam públicos no dire­

tório de serviços públicos, onde neste caso, são utilizados também pela Equipe C. 2.

Webservices são serviços que circulam pela web dc forma padronizada e possibilitam a integração de diferentes sis­

temas. São baseados em padrões abertos de grande aceita­ ção no mercado. Aplicações podem ser desenvolvidas em qualquer linguagem que possua suporte a webservice de forma bastante simples. Utilizam protocolo de comunica­

ção e formato de dados padrões da web para descrever as

interfaces dos serviços e devido a Infraestrutura de trans­ porte e comunicação já existente, a web, possuem baixos

custos de adoção.

175

176

Arquitetura para computação móvel

3.









4.

Dc um modo geral, XML Schemas definem o que pode apa­ recer em um documento - elementos, atributos, entradas etc. - e suas respectivas ordens. Um documento XML estrutura­

do deve seguir as regras de sintaxe definidas e padronizadas. Existem métodos padrão para definir a estrutura de um arqui­

vo XML, são eles: Definição de Tipo de Documento (DTD) e XML Schema.. Duas características devem ser levadas em

consideração: schemas são escritos diretamente em XML e

são projetados com namespaces. 5.

A propriedade namespace é um recurso do XML para

evitar conflito de nomes de elementos. Um problema co­ mum é a ocorrência de elementos com o mesmo nome.

A duplicidade de elemento pode causar problemas a um desenvolvedor. Dada a duplicidade desse elemento, um al­

goritmo não seria capaz de distinguir quais elementos deve

escolher. A fim dc solucionar o problema de duplicidade dc elementos, o XML define prefixos para elementos para um namespace. 6.

a) xsd:Boolean: Tipo de elemento booleano, permite um va­

lor binário. Exemplo: 1 ou 0. verdadeiro ou falso. b) xsd:duration: Tipo de elemento para indicar um período de

tempo. Exemplo, Pl Y2M3DT10H30M12.3S, refere-se à seguinte informação: 1 ano, 2 meses, 3 dias, 10 horas, 30

minutos e 12,3 segundos. c) xsd:positivclntcger: Tipo de elemento para indicar núme­

ros inteiros positivos. Exemplo: 1, 2, 3.

Respostas

d) xsd:nonNcgativdntcgcr: Tipo dc elemento para indicar números inteiros negativos. Exemplo: -1,-2, -3.

7.

a) P7A4M29DT21H55M11.1S. Pertence o tipo de elemen­ to Data/Hora, xsd:duration. Representa: 7 anos, 4 meses,

29 dias, 21 horas, 55 minutos e 11,1 segundos.

b)

1994-04-22T22:30:40.000-03:00 Pertence o tipo de elemento Data/Hora, xsd:dateTime.

Representa: A data dc 22/04/1994 no horário 22:30:40 no Fuso Horário dc Brasília.

Estudo de caso A entidade PEDIDO pode fornecer os serviços inerentes a criação/alteração de pedidos, tais como:

atualizarPedido*pedido: Pedido) - dado um pedido, o mesmo deverá atualizado. Desde que o mesmo ainda não tenha sido pago, somente não será possível atualizar o id

que identifica o pedido e a consultora que efetuou o pedido. criarPedido(pedido: Pedido) - dado um pedido, o mes­

mo será criado.

consultarPedido(pedidoId: int) - dado o número do pedido, o pedido será retornado com todos seus detalhes.

listarPedidos(cliente: int) - dado o número de um de­ terminada cliente, será retornada uma lista com todos os

pedidos referentes a este cliente cancelarPedido(pedidoId: int) - dado o número do

pedido, o mesmo será cancelado. Desde que o mes­ mo ainda não lenha sido pago, caso o mesmo já tenha sido pago será gerada uma exceção informando que o

mesmo já foi pago.

Na mídia 1.

Para o projeto da nota fiscal eletrônica nacional foi utilizado uma arquitetura baseada em webservices. Para cada serviço

oferecido existe um webservice específico. O fluxo de co­ municação é sempre iniciado pelo aplicativo do contribuinte

através do envio de uma mensagem ao webservice com a so­ licitação do serviço desejado.

177

178

Arquitetura para computação móvel

2.

Recepção de Lote; Consulta Processamento de Lote;

Inutilização de numeração de NF-e; Consulta da situação atual da NF-e; Consulta do status do serviço; Consulta cadastro;

Registro dc eventos. 3.

Serviços síncronos - o processamento da solicitação de

serviço é concluído na mesma conexão, com a devolu­ ção de uma mensagem com o resultado do processamen­

to do serviço solicitado; Serviços assíncronos - o processamento da solicitação de

serviço não é concluído na mesma conexão, havendo a de­

volução de uma mensagem de resposta com um recibo que apenas confirma o recebimento da solicitação de serviço.

Unidade 4 Exercícios de fixação 1.

Linguagens de descrição arquitetural, ADL, têm como fun­ ção representar a arquitetura de sistema de um programa.

Elas definem os tipos de componentes; os comportamentos desses componentes e os elementos necessários para a intera­ ção entre dois ou mais componentes de um sistema.

2.

A Rapide faz que os componentes possam gerar dois tipos dc eventos: 1. Eventos dependentes: regras de comportamento

dc interface; padrões dc ações dc módulos; eventos gerados por execução seqüencial, entre outros. 2. Eventos programa­ dos: capacidade dc cronometrar ações na/da interface; tem­

pos de partida e chegada de eventos, entre outros. 3.

Componentes - a arquitetura implementa uma interfa­

ce. Componentes são os objetos dessa interface.

Conexões - os componentes precisam se comunicar. Essa comunicação é feita por meio de conexões de envio

e recebimento. Essas ações ocorrem entre componentes

de uma mesma interface. Restrições (padrões) - geralmente aparecem direta­ mente na interface. Vinculadas a padrões de eventos.

Referências

Sequenciais - gcralmcntc aparecem cm módulos, e são associadas a tipos, objetos, declarações etc. 4.

a) A elipse contínua indica a notação de um caso de uso no

diagrama de Casos de Usos. Representa uma funcionali­ dade do sistema.

b) A elipse tracejada indica a notação de uma colaboração entre classes no diagrama de classes. Elementos podem interagir entre si.

c) A seta indica um relacionamento de generalização/espe-

cialização nos diagramas da UML. Indica um tipo de re­ lacionamento também conhecido como herança.

d) A seta tracejada indica um relacionamento de realização, geralmenle no diagrama de classe. Indica a relação de

contrato entre um classificador e a execução desse con­ trato por outro classificador. 5.

UML (Unified Modeling Language) ou Linguagem de Mo­

delagem Unificada é uma linguagem visual utilizada para modelar software baseados no paradigma de orientação a ob­ jetos. É uma linguagem dc propósito geral que pode ser apli­ cada a todos os domínios de aplicação. Não é uma linguagem

dc programação e sim uma linguagem dc modelagem, uma notação, cujo objetivo é auxiliar os engenheiros de software a

definirem as características do sistema. Não é um processo dc

desenvolvimento de software e não está ligado a uma forma

exclusiva, sendo totalmente independente. Seus diagramas

têm o objetivo de fornecer múltiplas visões do sistema a ser modelado, analisando-o, modelando-o sob diversos aspectos, procurando-se, assim, atingir a completitude da modelagem

permitindo que cada diagrama complete o outro. 6.

a) Diagrama de Caso de Uso - Apresenta uma visão ex­

terna geral das funcionalidades que o sistema deverá oferecer aos usuários, sem se preocupar com a questão

dc como tais funcionalidades serão implementadas, de­ monstra “O QUE" fazer c não "COMO" fazer.

b) Diagrama dc Sequência - Representam as interações

entre os atores e o sistema. Tem como característica re­ presentar o comportamento e cenários do sistema

c) Diagrama de Classe - Apresenta o projeto lógico do sis­ tema de forma estática. Indica o relacionamento entre as

entidades do sistema - classes.

179

180

Arquitetura para computação móvel

7.

Atores

Atendcnte Cliente Farmacêutico Casos de Uso

Fazer Pedido de Medicamento Faltante Vender Medicamento Assinar Venda dc Remédio Controlado Fechar Caixa

Diagrama

Estudo de caso Atores

Funcionário Gerente de Área Gerente de RH Gerente do Financeiro

Assistente Financeiro Funcionalidades

Solicitar Adiantamento de Despesa

Autorizar Valor de Adiantamento

Respostas

Autorizar Valores Superiores ao Limite

Efetuar Depósito do Valor Prestar Contas da Viagem

Depositar Valores dc Diferença de Acerto

Autorizar Valores Excedentes de Acerto Devolver Valores Restantes

Classes Candidatas

Funcionário

Gerente Adiantamento

Depósito Acerto de Despesa

Aprovação Diagrama de Casos de Uso

181

182

Arquitetura para computação móvel

Na mídia 1.

Para um projeto, uma linguagem de notação arquitetural utili­

za elementos como componentes e suas conexões. Algumas características importantes devem ser consideradas ao utilizar

esses elementos, são elas: Composição, Abstração, Rcuso,

Configuração, Heterogeneidade e Análise. A interface de um componente são pontos de ligação com o universo real. As in­

terfaces limitam-se ao teor operacional dos componentes, ou seja, especificam serviços (mensagens, operações, variáveis

etc.) e solicitam requisitos necessários aos serviços a outros componentes. 2.

Sim, a UML pode ser utilizada, pois representa, cm formato

dc diagramas, com notações específicas a abstração do siste­

ma, para que o mesmo esteja visível e entendido para todos os participantes do projeto. A modelagem desse sistema permite entender suas características e o seu comportamento. Além

da tecnologia de reconhecimento de voz e imagem, muitas abstrações do mundo real precisam ser entendidas para a cria­

ção das funcionalidades desse sistema.

3.

Reconhecer voz Interpretar o som Definir estado emocional

BIBLIOGRAFIA UNIVERSITÁRIA PEARSON

ARQUITETURA PARA COMPUTAÇÃO MÓVEL 2a edição

Organizador Rafael Félix e Everaldo Leme da Silva

Nesta segunda edição de Arquitetura para computação móvel, tópicos como arquitetura de software, projetos arquitetônicos, webservices e serviços e linguagens de descrição são apresentados de um ponto de vista inusitado que possibilita ao leitor um processo intensivo (e real) de aprendizagem.

br.pearson.com ISBN

978-65-5011-058-1

9

'786550

1 10581