Desafio 1

A- Projeto de Arquitetura:
Quando feita definio das estratgias de integrao dos
vrios sistemas de uma empresa, essencial que conheam como estes
sistemas encontram-se implantados.
No escopo desta disciplina e do engenheiro de automao, bom saber as
arquiteturas tpicas existentes e com as quais um dado sistema a ser integrado
dever ter que lidar para poder interoperar com os demais (instalados na
prpria empresa, ou em outras empresas).
A definio impacta a qualidade do projeto global de sistemas, porque uma
mesma empresa, ou uma mesma ferramenta, possvel conviver e interoperar
com sistemas disponibilizados em mais do que um tipo de arquitetura.

TIPOS & MODELOS DE ARQUITETURAS

-Centralizado;
- Cliente / Servidor Clssico;
- Provedores de Servios de Aplicao (ASP);
- Software-como-um-Servio (SaaS) e Nuvem
Esses quatro modelos diferentes no so mutuamente
exclusivos, podendo coexistir em uma mesma empresa ou arquitetura global de
integrao.
O modelo Centralizado
onde os sistemas da empresa (ou parte deles) esto
implantados em mainframes ou em alguns poucos servidores de grande poder
de processamento. Neste modelo, todo o processamento central e existe um
repositrio de dados tambm central, que chamado de banco de dados
corporativo.
-No h processamento no lado dos clientes, que usam estaes ou terminais
passivos.
-O acesso s aplicaes e ao banco de dados feito atravs de uma
requisio, via rede local ou VPN, fazendo uso de uma Intranet ou Portal da
empresa. Os aspectos de segurana e demais de QoS so determinados pelo
computador central e pela banda & hardware da rede.

-Os sistemas acessados so pagos usualmente na forma de licena nica e

multiplicada pelo nmero de terminais clientes. O conceito de software livre e
gratuito praticamente no se coloca.
-A integrao de um sistema heterogneo com uma aplicao do mainframe
d-se ou de forma indireta via Banco de Dados, ou de forma semi-direta,
atravs de uma requisio (procedimento batch) para o mainframe.
A Computao em Nuvem (Cloud Computing) no deixa de ser equivalente ao
modelo centralizado; porm, na Nuvem, centralizado e com protocolos de
comunicao e ferramentas de acesso diferentes.

MODELO CLIENTE: SERVIDOR CLSSICO

O modelo Cliente: Servidor atualmente o mais comum, do

ponto de vista conceitual de redes, contm em todos os modelos de
comunicao hoje usados.
A perspectiva enfatizar de que o processamento no totalmente
centralizado em um nico computador, mas sim distribudo por vrios
servidores. Por consequncia, a hospedagem e a execuo de aplicaes, e a
persistncia de dados, so todos descentralizadas.
Neste modelo, o processamento distribudo e podem existir um central ou
vrios repositrios de dados, cada um conhecido sobre sua funo (servidor
de impresso, servidor de arquivos, servidor de modelos de produtos, etc.),
mas transparente s aplicaes.
-Existe processamento no lado das aplicaes-cliente, que usam os servios
do servidor para dar sequencia s suas execues / processos de negcios.
-O acesso s aplicaes e ao banco de dados tambm feito atravs de uma
requisio, via rede local ou VPN, fazendo uso de Internet, Intranet ou Portal da
empresa. Os aspectos de segurana e demais de QoS so determinados pela
qualidade dos servidores e pela banda & hardware da rede.

-Os sistemas acessados so pagos na forma de licena nica por servidor, e

multiplicada pelo nmero de terminais de clientes. O uso de software livre
comum, potencialmente gratuito.
-A integrao de um sistema heterogneo com uma aplicao de um servidor
de forma indireta via Banco de Dados, ou de forma direta, atravs de uma
requisio de servio para o servidor (via API, RPC, RMI, etc.).
Uma importante variante atual deste modelo clssico so os sistemas
baseados no modelo P2P (Peer-to-Peer).
- O conceito clssico de cliente: servidor estendido no sentido de que todos
os ns so, ao mesmo tempo, clientes e servidores. bastante usado para
uma melhor distribuio de contedo e para compartilhamento de arquivos.
-A requisio do servio feita via plataformas (middlewares) e protocolos em
especial desenhados para P2P, que abstraem a localizao dos servidores que
tm toda ou parte da informao desejada.

MODELO ASP
O Modelo ASP (Application Service Provider - Provedor de
Servios de Aplicao) um modelo mais recente que se baseia na ideia da
disponibilizao de aplicaes inteiras via Internet, que ficam fora da empresa,
e que so completamente gerenciadas por uma empresa terceira. A empresa
cliente no compra a licena do software e no o hospeda localmente, mas
simplesmente o aluga, pagando pelo seu uso, via rede.

Provedor (servidor) rede clientes

Sua arquitetura basicamente contempla um servidor que prov o acesso

aplicao. Na maior parte dos casos, so aplicaes baseadas em web, onde
basta ao cliente ter acesso rede e a um navegador. Baseado em um contrato
de utilizao (sob vrios modelos de negcio) SLA (Service Level Agreement)
todo o armazenamento e acesso a aplicaes terceirizado (outsourcing),
assim como o cumprimento dos aspectos de QoS acordados. A empresagestora (o provedor) fica totalmente responsvel pela segurana, atualizao
de verses, manuteno, treinamento, etc., da aplicao. Neste modelo, o
processamento logicamente centralizado (depende de como o provedor
implanta a aplicao). O provedor tambm pode ser o responsvel por todo
hospedagem dos dados, de forma que o repositrio de dados da empresa pode
ser igualmente centralizado (embora de forma transparente ao usurio).
-H um processamento no lado das aplicaes-cliente, que usam os servios
do servidor para dar sequencia s suas execues / processos de negcio.
Porm, o usurio est imerso na aplicao, apenas com o fato de que toda a
navegao pelas funcionalidades da aplicao e transaes disparadas acaba
sendo feitas via rede, e executadas no provedor. Os aspectos de segurana e
demais de QoS so determinados pela qualidade dos servidores do provedor,
pela banda contratada & hardware da rede.
-Rgida observncia dos SLAs.
-Os sistemas acessados so pagos na forma de licena nica por servidor, e
multiplicada pelo nmero de terminais clientes. No mundo corporativo, o uso de
software livre no comum neste modelo.
-A integrao de um sistema heterogneo com uma aplicao de um servidor
ASP d-se ou de forma indireta via Banco de Dados, ou de forma direta,
atravs de uma requisio para o servidor. Porm, as requisies chegaro e
sero gerenciadas pelo provedor, e no pela empresa-cliente.
MODELO SAAS
O Modelo SaaS (Software-as-a-Service / Software-como-umServio) o modelo mais recente. Ele se baseia na ideia da disponibilidade de
servios especializados de software, relativamente pequenos, (e no mais
de pacotes inteiros, muito grandes) via Internet, que ficam fora da empresa, e

que so tambm completamente gerenciados por uma empresa terceira. A

empresa cliente no compra licena alguma de software e no o hospeda
localmente, mas simplesmente invoca o servio, acessando-o on-demand
(apenas quando o requer/usa) e paga pelo seu uso.
Sua arquitetura basicamente contempla um servidor que prov o acesso aos
servios. Na maioria dos casos, so servios baseados em web, onde basta ao
cliente ter acesso rede e a um navegador. Tambm baseados em SLAs, todo
o armazenamento e acesso aos servios terceirizado, assim como o
cumprimento dos aspectos de QoS acordados. A empresa-gestora (o provedor)
fica totalmente responsvel pela segurana, atualizao de verses,
manuteno, treinamento, etc., do servio.
- O processamento tambm centralizado (depende de como o provedor
implanta a aplicao). O provedor pode ser o responsvel por toda
hospedagem dos dados, de forma que o repositrio de dados da empresa pode
ser igualmente centralizado (embora de forma transparente ao usurio), e
acessado como um servio, e no indiretamente via uma aplicao.
-H tambm processamento no lado das aplicaes-cliente, que usam os
servios do servidor para dar sequencia s suas execues, aqui o usurio
normalmente no est imerso na aplicao (como no ASP), mas sim usando
servios especficos, desacoplados dos demais servios. Os aspectos de
segurana e demais de QoS so determinados pela qualidade dos servidores
do provedor, pela banda contratada & hardware da rede.
-Rgida observncia dos SLAs.
-Os servios acessados so pagos de acordo com o uso (pay-per-use). O uso
de software livre por empresas pode se aplicar neste modelo.
-A integrao de um sistema heterogneo com um servio de um servidor
SaaS d-se de forma direta, atravs de uma requisio para o servidor. Caber
ao cliente, ou invocar um dado servio de dentro da aplicao e gerenciar o
resultado, ou receber o resultado direto no seu navegador.

Cliente

rede

mltiplos provedores

- O conceito original de SaaS alargado, no sentido de que os servios de

software passam a ser disponibilizados como funcionalidades de baixa
granularidade, altamente reutilizveis, para compor aplicaes no lado do
cliente.
-A integrao da aplicao com um servio SaaS d-se de forma direta, atravs
de uma requisio para o servidor. Caber ao cliente encontrar e invocar um
dado servio de dentro da aplicao e gerenciar o resultado

-Porm, a sua potencialidade tem sido pouca utilizada ainda na prtica. Na

maior parte dos casos, a prpria empresa-cliente atua como o provedor de
servios (i.e. ela que tem e gerencia o repositrio de servios) e, assim, a
aplicao-cliente no precisa descobrir onde est o provedor que tem o servio
desejado.
-As empresas que, usam a figura de uma empresa-provedora externa,
acessam os devidos servios apenas dessa empresa, e no de outras que
eventualmente tenham servios equivalentes.
A complexidade de integrao / interoperao de aplicaes numa perspectiva
SaaS ou SOA deve ser vista sob duas ticas:
-Do ponto de vista estritamente tecnolgico, a interoperao tende a ser menos
complexa (exceto a semntica), pois as TIs de suporte usadas so
majoritariamente baseadas em padres atualmente muito utilizados (ex. XML,

SOAP e web services), o que diminui os problemas de interoperabilidade (mas

no (!) os resolve, pois muitos desses padres no so interoprveis entre si).
- Se o modelo SaaS permite uma maior flexibilidade / independncia de um
nico provedor de software (podendo-se tentar at usar o melhor servio do
momento, sem estar preso a um contrato fixo e de longa durao), a
composio (e posterior execuo da aplicao SOA com base em servios
SaaS pode ser altamente (!) complexa. por que tem que criar uma camada de
ligao entre os vrios servios (gerados por vrios provedores diferentes),
tratar dos seus argumentos, semnticas, etc., onde tem que ser feito
manualmente, programando-se.
B-Arquitetura de Sistemas distribudos:
Arquiteturas Centralizadas
Modelo Cliente-Servidor
processos so divididos em dois grupos
Servidor: processo que programa um servio especfico
Cliente: processo que requisita um servio ao servidor
Requisio -> Resposta
Considerando aplicaes cliente-servidor que visam dar suporte ao acesso de
usurios a banco de dados:
Nvel de interface
Nvel de processamento
Nvel de dados
Com a distino entre trs nveis lgicos, como distribuir fisicamente uma
aplicao cliente-servidor por vrias mquinas?
Arquitetura de duas divises fsicas
Arquitetura de trs divises fsicas
Conceito formal.
Definimos um sistema distribudo como sendo aquele no qual
os componentes de hardware ou software, localizados em computadores
interligados em rede, se comunicam e coordena suas aes apenas enviando
mensagens entre si.

C - Arquitetura de Aplicaes:

Arquitetura Cliente-Servidor
-A existncia de dois processos, sendo um Cliente requisitando um servio e
um Servidor disponibilizando este servio (ou recurso), caracteriza o modelo de
arquitetura cliente- servidor.
- So exemplos de aplicaes deste modelo: Servios de compartilhamento de
recursos (arquivos, impressoras) e-mail DNS, FTP, Telnet
Arquitetura Cliente-Servidor com Arquivos Compartilhados
-Cliente: responsvel pela apresentao (telas), processamento (regras de
negcio) e gerenciamento de dados.
_ Servidor: responsvel somente pelo compartilhamento de arquivos onde os
dados so gravados.
_ Esta arquitetura s tem um bom funcionamento para um nmero pequeno de
usurios concorrentes, tendo um grande trfego na rede, quando se trabalha
com grandes volumes de dados.
_ Exemplos atuais: aplicaes com MS Access e Borland Paradox
Para resolver esse problema foram criados os
-Sistemas de Gerenciamento de Banco de Dados (SGBD) ou Servidores de
Banco de Dados.
_ Um SGBD um processo servidor que gerencia o acesso concorrente a
dados.
_ As requisies so feitas utilizando-se comandos na linguagem SQL
(Structured Query Language).
_ Exemplos: Oracle, MS SQL Server, IBM DB2, MySQL

 um modelo computacional que faz uma separao entre cliente e servidor,

mesmo que esto interligados por uma rede de computadores. modelo que
favorece o cliente e o servidor.
D. Gerenciamento de Configuraes

Gerenciamento de Configurao e de Solicitaes de

Mudana (CM e CRM) envolve:

A identificao dos itens de configurao,

A restrio de mudanas nesses itens,

A auditoria das mudanas feitas nesses itens e

A definio e o gerenciamento das configuraes desses itens.

Os mtodos, os processos e as ferramentas utilizados para o gerenciamento

de configurao e mudana de uma organizao podem ser considerados
como o Sistema de CM da organizao. O Sistema de Gerenciamento de
Configurao e Solicitaes de Mudana (Sistema de CM) de uma organizao
contm informaes-chave sobre os processos de desenvolvimento,
implantao e manuteno de produtos da organizao e armazena a base de

artefatos ativos potencialmente reutilizveis resultantes da execuo destes

processos.O Sistema de CM parte fundamental e integrante dos processos
gerais de desenvolvimento.Um Sistema de CM fundamental para controlar os
inmeros artefatos produzidos por muitas pessoas que trabalham em um nico
projeto. O controle ajuda a evitar confuses dispendiosas e garante que os
artefatos resultantes no entrem em conflito devido a um dos seguintes
problemas:

Atualizao Simultnea

Notificao Limitada

Vrias Verses

Atualizao Simultnea
Quando dois ou mais membros da equipe trabalham separados
no mesmo artefato, o ltimo membro a fazer mudanas desfaz o trabalho
realizado pelo anterior. Pode ter um problema bsico , se um sistema no
permite a atualizao simultnea, pode levar a mudanas em srie e diminui o
ritmo do processo de desenvolvimento. Portanto, com a atualizao
simultnea, o desafio detectar se ocorreram atualizaes simultneas e
resolver quaisquer problemas de integrao quando essas mudanas forem
incorporadas.
Notificao Limitada
Quando um problema corrigido nos artefatos compartilhados
por vrios desenvolvedores e muitos deles no so notificados da mudana.
Vrias Verses
A maioria dos programas de grande porte desenvolvida em
releases evolutiva. Um release pode estar sendo usado pelo cliente, enquanto
outro est em teste e um terceiro ainda est em desenvolvimento. Se forem
encontrados problemas em qualquer uma das verses, as correes devero
ser propagadas entre elas. Isso pode levar a confuses, que acarretam
correes e retrabalho, a menos que as mudanas sejam cuidadosamente
controladas e monitoradas. Um Sistema de CM til para gerenciar diversas
variantes de sistemas de software em desenvolvimento, controlando as
verses que so usadas em determinados builds do software, compilando
builds de programas individuais ou de releases inteiras de acordo com

especificaes de verso definidas pelo usurio e impondo polticas de

desenvolvimento especficas do site.
Alguns dos benefcios diretos obtidos pelo uso de um Sistema de CM incluem:

Suporte a mtodos de desenvolvimento,

Preservao da integridade do produto,

Garantia de abrangncia e preciso do produto configurado,

Ambiente estvel no qual o produto deve ser desenvolvido,

Restrio das mudanas feitas nos artefatos com base nas polticas do
projeto e

Trilha de auditoria indicando por que, quando e por quem um artefato foi
alterado.

Um Sistema de CM armazena dados detalhados sobre a 'contabilidade' do

processo de desenvolvimento: quem criou uma verso especfica (e tambm
quando e por que), quais verses dos cdigos-fonte foram usadas em um
determinado build, alm de outras informaes relevantes.

http://www.faes.org.br/doc/jornal/1401305145_Aulas02-SD.pdf
http://www.cesar.org.br/~ccbs/SAI/Principios_SD/03_SAI-IntroSDModel_Arquit_Cli-Srv.pdf
http://www.funpar.ufpr.br:8080/rup/process/workflow/conf_mgt/in_cm.htm