APD III

24-01-2015

Os padres arquiteturais existem devido complexidade dos projetos de sistema

atuais.
A Arquitetura de um sistema a estrutura ou conjunto estruturais do sistema, a qual
composta pelos elementos de software, propriedades externas visveis e os
relacionamentos entre esses elementos.
Estrutura esttica
- elementos estticos internos do software ou seja, planejados em tempo de
concepo ou planejamento do projeto.
- exemplo: Modulos, objetos, classes, pacotes, servios
(tudo o que planejou e espera que d certo)
Estrutura dinmica
- Elementos dinmicos (runtime), ou seja, que podem sofrer alteraes em tempo de
execuo.
Ex. fluxo de informaes entre elementos.

Comportamento externamente visvel

- interaes funcionais entre o sistema e o seu ambiente
- fluxo de informao de entrada e sada, como o sistema responde ao estmulos
externos, o contrato publicado ou API que arquitetura tem com o mundo exterior.
- O comportamento externo deve ser modelado observando o sistema como caixa
preta.
Requisitos funcionais : funes internas, tudo o que tem haver com o funcionamento
interno do sistema.
Requisitos no funcionais
- Propriedades no funcionais, externas e visveis. (implementao fsica, controle de
acesso)
Desempenho, segurana e outros.
Como o sistema se comporta do ponto de vista de um observador externo.
Arquitetura candidata
um conjunto de estruturas estticas e dinmicas que tem o potencial de mostrar
comportamento interno visvel e requisito no funcionais.

Importncia da arquitetura
- Prov uma forma direta entre os stakeholders (-negociao de requisitos)

- uma manifestao das decises antecipadas do projeto.

Planejamento de budget, equipes e planejamento.
Base para a integrao, testes e manuteno
Decises sobre os requisitos no funcionais.
- uma abstrao transfervel e reutilizvel
Muitos projetos com arquiteturas similares.
03/03
MVC
Model View Controller

Antes do MVC os sistemas eram monolticos, isto , os dados eram misturados, o

processamento da entrada junto com o processamento de sada.
Depois do MVC os dados de entrada e sada no se comunicam diretamente.
MVC separao entre camada de negcio(model) e a camada de visualizao(view)
com um medidor de comunicao (controller).

Modelo 3 camadas Apresentao, Regras de Negcio e Dados

Modelo 5 camadas Cliente, Apresentao, Negcio, Persistncia e Dados
_____________________________________________________________________
17/03
Arquitetura de 2 camadas:
Cliente e Servidor
Arquitetura de 3 camadas:
Cliente (browser), Camada de negcio (php, jsp, etc) e Dados (banco de
dados). (servidor sendo as 2 ultimas camadas). No tem definida a camada de
apresentao, fica separada entre a camada cliente e a camada de negcio. Como
no tem a camada de persistncia de dados bem definida, ela fica separada entre a
camada de negcio e a camada de dados.
MVP - Model View Presenter: modelo parecido com a arquitetura de 3 camadas. Tem
uma viso, um modelo com a lgica de negcios e a camada de apresentao que
cuida da apresentao da view e faz com que a view no tenha acesso a lgica de
negcio.

Historia de usurio - maneira de detalhar os requisitos do usurio de forma mais

detalhada. Deve-se definir algumas metas para teste para verificar que a historia de
usurio foi atendida.
A partir da histria do usurio criam-se mokups (https://moqups.com/ http://
pencil.evolus.vn/ ), que um prottipo da interface

31/03

Diagrama de componentes: mostra os componentes, interfaces e interaes entre

eles.
Uma classe pode ser um componente, um conjunto de classes que se relacionam
pode ser um componente.

Diagrama de Deployment (Diagrama de distribuio ou Implantao) - mostra como a

arquitetura de um sistema ser implementada em relao ao hardware. Composto:
ns (elementos fsicos), artefatos (so rodados dentro dos ns) e elementos de
comunicao.
N - elemento fsico (hardware) - local onde ir implantar ou distribuir os artefatos
Artefato - software

Os diagramas de deployment e de componentes se relacionam, pois os componentes

do diagrama de componentes se tornam os artefatos do diagrama de deployment.

Diagrama de pacotes - mostra a estrutura de pacotes da aplicao e suas

dependncias.
_____________________________________________________________________
Arquitetura Orientada a Componentes

Componentes - uma unidade independente de software que encapsula um conjunto

de requisitos funcionais e no funcionais e que possui interface de comunicao bem
definidas.

- na arquitetura baseada em componentes um conjunto de componentes forma um

sistema complexo

- os componentes de um sistema trocam mensagens por meio de interface

- palavra - chave -> Reuso
Tipos de reuso:

- sistema completo de uma aplicao (alta granularidade)

- componentes (meio termo) - subsistema, objeto
- funes (baixa granulosidade)
Tipos de componentes:

- customizados: o componente feito do zero. Demanda maior tempo e dinheiro

- reusveis: j esto prontos, vem de outros projetos seus, podem ser feitos algumas
modificaes. So perigosos, pois foram feitos para outra aplicao e podem gerar
erros.

- comerciais: comprou um componente, geralmente no podem ser modificados.

Problemas de Reuso:

- no fornecida toda a informao necessria

- nem sempre pode ser modificada
COTS - analise que permite decidir entre comprar componentes de terceiros, reusar
ou desenvolver internamente componentes de um software.
_____________________________________________________________________
Arquitetura Orientada a Servios

Pensar no sistema como um conjunto de servios prestados e servios consumidos

SOA: padro de arquitetura que prev que seus produtos sejam parecidos com
servios.

5 camadas do SOA:
Camada Corporativa - conjunto de processos
Camada de Processos - conjunto de servios (orquestrao ou coreografia de
servios)
Camada de servios - servios isolados
Camada de componentes
Camada de Objetos

SOA - Conceito de Arquitetura corporativa que promove a integrao entre o negcio e

a TI por meio de um conjunto de interfaces de servios acoplados.Arquitetura
tecnolgica mas que tenha domnio do negcio. As informaes ficam disponveis para
todos os participantes da corporao
Palavra-chave -> Baixo acoplamento! Interoperveis -> elementos que se comunicam

Implementar web services baseados no XML usando SOA parece ser a melhor
proposta para qualquer arquitetura de corporao.
Paradigma Find-Bind-Execute - Procurar um servio, se associe a esse servio e
execute esse servio (Base para o RMI, Java e SOA)

Para fazer a parte do Find-Bind usa-se um middleware

middleware: deixa escondido para o cliente a parte de desenvolvimento, no interessa
ao cliente quem vai responde-lo ou de quem vem o seu servio. Integram clientes que
desejam acessar servios da aplicao.
SOAP - UDDI
CORBA - ORB
RMI - rmiregistry

ESB - Enterprise services bus. Do ponto de vista arquitetural.

- middleware de integrao
- adio de uma camada que isola os clientes do provedor do servio
Cliente do Servico <-> Contexto de construo (intermedirio) <-> Provedor de Servio

ESB uma camada adicional facilitadora de servios

Propriedades:

- membros do barramento - identifica os componentes que compem o barramento

- destinos
- mediaes
- barramentos externos
- servicios de entrada
orquestrao - composio de servios onde existe a figura de um servio central que
controla e coordena os demais processos. cada servio participante no tem
conhecimento de que faz parte de uma composio de processos com exceo do
servio mestre.
coreografia - composicao de servios onde no existe a figura de um servio mestre
que controla e coordena os demais servios. Um servio intercepta uma requisio, e
sabe que deve se combinar com outro servio para executar essa requisio. Cada
servio envolvido tem o conhecimento de que faz parte de uma composio e que
precisa interagir com outros servios de maneira ordenada para que a composio
resultante tenha sucesso. Um servio tem noo da existncia de outro.
_____________________________________________________________________

ESTUDO

Vises RUP - 4+1

- Viso lgica: Para analistas de negcios e desenvolvedores. Descreve requisitos

comportamentais e a decomposio do sistema. Expressa funcionalidades.
Diagramas de classe, colaborao e de sequencia.

- Viso da Implementao: Para desenvolvedores e gerentes. Descreve os mdulos

do sistema ou subsistemas. Expressa gesto da configurao. Diagramas de
componentes e pacotes.

- Viso de Processo: Projetistas e integradores do sistema. Descrevem como os

processos do sistema se comunicam. Expressa desempenho, escalabilidade e
vaso. Diagramas de atividades.

- Viso da Implantao: Para sustentao. Descreve como a aplicao instalada e

executada. Expressa topologia do sistema, comunicao e provisionamento.
Diagramas de implantao.

- Cenrios: Para usurios e desenvolvedores. Descreve formas de utilizao do

sistema. Expressa aes. Diagramas de casos de uso.

Diagramas de Componentes e de Deployment

- Mostra os componentes, interfaces e as interaes entre eles.

- Componentes previamente construdos podem ser reutilizados ou substitudos.
- Componente: representa parte de um sistema que encapsula um comportamento
em um determinado ambiente. Interfaces providas ou Interfaces consumidas.

- Conectores: especificam um link de comunicao entre componentes regidos por

um contrato de comunicao.

- Conector de comunicao: conectam dois ou mais componentes por meio de suas

interfaces de comunicao

- Conectores de delegao: conectam interfaces de comunicao internas com

componentes externos ao componente.

Diagrama de Deployment

- Mostra como a arquitetura de um sistema ser implementada em relao ao

hardware.

- Ns: Representam recursos computacionais que serviro como elementos de

execuo de um artefato. Onde so implementados os artefatos e de forma indireta
aos pacotes. Conectados por linhas de comunicao

- Dispositivos: n que representa um recurso com capacidade de processamento

onde artefatos podem ser implantados para execuo.

- Ambientes de execuo: n que representa um ambiente de execuo para um

conjunto de componentes.

- Artefatos: representam elementos que sero implantados em um ambiente de

execuo. Sempre so implantados em um n.

- Elementos de comunicao: associao entre dois ns que permite a comunicao

entre eles. Comunicao entre dispositivos a conexo fsica entre os elementos.
Comunicao entre ambientes de execuo o protocolo de comunicao.

- Deployment: Descreve a alocao de um artefato dentro de um n.

Diagrama de Pacotes

- Mostra a estrutura de pacotes da aplicao e suas dependncias.

- Pacotes: elementos semanticamente relacionados e que mudam juntos, que
recebem um nome. Os elementos so alterados e excludos de forma conjunta ao
prprio pacote.

- Elementos de um pacote: type, classe, caso de uso, componente, pacote,

dependencia, evento.

- Tipos de relacionamento: Importao (import), uso (use), merge (extends)

Diagrama de pacotes

Diagrama de deploymet + componentes + pacotes

Diagrama de Modelo

- mostra a estrutura das camadas da aplicao e seus pacotes.

- composto por pacotes e camadas

Arquitetura Orientada a Servios

- servios: aplicaes identificadas por uma URL/URI disponveis na Web com a

finalidade de oferecer servios para integrao de sistemas e comunicao entre
aplicaes diferentes.

- SOAP: forma de fazer Remote Procedure Call (RPC) usando documentos XML.
- WSDL: linguagem XML que contem informaes sobre a interface, a semantica e
outros detalhes de chamada de um web service.

- UDDI: permite cadastrar registros e localiza-los. No necessrio usar UDDI se o

cliente j tiver o documento WSDL

- Webservice: ponto de acesso a funcionalidade que pode ser localizado

dinamicamente, ter sua interface descoberta automaticamente e ser chamado na
Web.

- Restful web service: permitem uma combinao de mltiplos web services em

novas aplicaes

- Servios de restful no requerem XML, SOAP ou WSDL

- Verbos HTTP: GET, POST, PUT, DELETE
SOA

- Vantagens: Reutilizao de aplicaes existentes, utilizao de padres abertos,

interoperabilidade de plataformas e linguagens e simplificao do processo de
desenvolvimento.

- Riscos e desvantagens: Disponibilidade, interfaces imutveis, garantia de

execuo, desempenho, segurana, privacidade, e suporte a transaes.

- Conceito de arquitetura corporativa que promove a integrao entre o negcio e a TI

por meio de um conjunto de interfaces de servios acoplados.

- Definido como a arquitetura que permite ligar os recursos segundo a demanda.

- Servios independentes e o baixo acoplamento formam a arquitetura do SOA.
- ESB: Enterprise Service Bus. Middleware de integrao. Adio de uma camada
que isola os clientes do provedor de servios. Fornece as caractersticas para que
SOA possa ser implementado. uma camada adicional facilitadora de servios.

- Propriedades do ESB: Membros do barramento, destinos, mediaes,

barramentos externos, servios de entradas, servios de sada, entrada de dados
de autenticao, especificao de ativao JMS

Exercicio da prova: (Correo do Fe)

3. Classe por si s representa uma abstrao, um modelo, um molde de um objeto do
mundo real. Quando falamos de componentes, aumentamos o nvel de abstrao, pois
um componente possui interfaces, classes de comunicao bem definidas que
encapsulam um conjunto de requisitos, tornando-o uma unidade independente de
software, possuindo vrios objetivos e funes.
Um servio aumenta ainda mais o nvel de abstrao da relao, pois oferece meios
de integrao de sistemas e comunicao entre aplicaes.

O fato de componentes serem complexos, instveis, custosos para serem adaptados e

de difcil integrao e reuso, pois propriedades de um componente nem sempre
podem ser modificados, levou a criao da arquitetura orientada a servios, que
possibilita a reutilizao de aplicaes, utilizao de padres abertos e
interoperabilidade de plataformas e linguagens para disponibilizar funcionalidades na
forma de servios.
4.

Explicao Sites Deployment

A UML 2 diagrama de implantao descreve uma viso esttica da configurao de

tempo de execuo dos ns de processamento e os componentes que so
executados em ns. Em outras palavras, diagramas de implantao mostrar o
hardware para o seu sistema, o software que est instalado no que hardware, eo
middleware usado para ligar as mquinas dspares entre si. Voc deseja criar um
diagrama de implantao para aplicativos que so implantados para vrias mquinas,
por exemplo, um aplicativo de ponto-de-venda em execuo em um computador de
rede de cliente fino que interage com vrios servidores internos por trs do firewall
corporativo ou um sistema de atendimento ao cliente implantado usando uma
arquitetura de como .NET da Microsoft de servios web. Os diagramas de implantao
tambm podem ser criados para explorar a arquitetura de sistemas embarcados,
mostrando como os componentes de hardware e software trabalham em conjunto. Em

suma, voc pode querer considerar a criao de um diagrama de implantao para

todos, mas o mais trivial dos sistemas.
A Figura 1 apresenta um exemplo de um diagrama de implantao UML 2 totalmente
processado para o aplicativo de administrao do estudante. As caixas tridimensionais
representar ns, software ou de hardware. Ns fsicos devem ser rotulados com o
dispositivo esteretipo, para indicar que um dispositivo fsico, como um computador
ou switch. Como voc pode ver eu no indicam que WebServer um dispositivo - que
ser pelo menos algum tipo de artefato de software e muito bem pode ser um ou mais
dispositivos fsicos, bem, mas a minha equipa no tenha tomado essa deciso ainda.
Lembre-se, os modelos evoluem com o tempo. As conexes entre os ns so
representados com linhas simples, e so atribudos esteretipos tais como RMI e
barramento de mensagens para indicar o tipo de conexo.
Nodes pode conter outros ns ou artefatos de software. O n ApplicationServer
contm EJBContainer (um n de software), que por sua vez contm trs componentes
de software, uma especificao de implantao, e um artefato de software. Os
componentes de software utilizar a mesma notao como diagramas de componentes
(eu poderia ter anotado-los com suas interfaces apesar de que no teria acrescentado
qualquer valor na minha opinio). Especificaes de implantao so, basicamente, os
arquivos de configurao, como um descritor de implementao EJB, que definem
como um n deve operar. Eles so descritos como dois-seccionados retngulos com a
especificao de implantao esteretipo, a top box indica o nome ea caixa inferior
lista as propriedades de implantao (se houver) para o n. Na minha opinio as
propriedades de implantao suprfluo, pois isso o tipo de informao que est
contida no arquivo de especificao de implantao real em tempo de execuo.
Artefatos de software so mostrados com o esteretipo visual de uma pgina com um
canto dobrado ou com o artefato esteretipo textual (ou ambos, por vezes, que eu
tambm acredito que suprfluo). Neste caso, o artefato de software um framework
de persistncia ficcional comprado de AmbySoft (o fornecedor indicado com uma
corda propriedade UML).

Quando voc

parar e pensar sobre isso, os esteretipos que eu aplicados para as conexes no

estiverem correctas. Na realidade, o software no servidor web est se comunicando
atravs do protocolo RMI sobre a conexo com o software no servidor de aplicativos. A
conexo fsica entre os ns de hardware fsico est em um nvel mais baixo, talvez
uma conexo Ethernet, assim, na realidade eu realmente deveria ter modelado uma
conexo entre os ns de hardware com Ethernet como um esteretipo e uma segunda
conexo entre elementos de software com o esteretipo RMI. Eu tambm preciso para
modelar uma relao de dependncia entre a conexo software ea conexo de
hardware, talvez com o esteretipo de mais. Embora este seria mais preciso seria um
monte de trabalho que eu provavelmente no iria se beneficiar muito de. Lembre-se,
os modelos geis no precisa ser perfeito, eles precisam ser bons o suficiente
apenas .
Eu nunca desenhar diagramas de implantao a seguir o show estilo na Figura 1 ,
exceto quando eu estou escrevendo sobre modelagem de implantao, porque na
minha opinio esta notao visualmente desperdcio. Um exemplo melhor
mostrado na Figura 2 . elementos de software so agora simplesmente listados por
seus nomes de arquivos fsicos, informaes de que os desenvolvedores so muito
provvel que esteja interessado em, e, portanto, um diagrama mais compacta
possvel. Eu tambm usou um tambor como um esteretipo visual para o banco de
dados University DB, tornando-o mais fcil de distinguir no diagrama. Outra diferena
que a verso concisa mostra menos detalhes, no como muitos valores marcados
so mostrados como esta informao pode ser captada em qualquer documentao
de apoio, arquivos de configurao, ou cdigo-fonte. Os diagramas de implantao
tendem a se tornar muito grandes muito rapidamente, porque eles refletem as
complexidades fsicas de seu sistema, portanto, uma notao concisa torna-se
fundamental para seu sucesso.
Figura 2. Concise UML 2 diagrama de implantao.

!
Como gil so diagramas de implantao? Como sempre, depende de seus objetivos.
Muitas vezes, menos detalhados diagramas de rede , que so, sem dvida, diagramas
de implantao com o uso extensivo de esteretipos visuais, so uma opo melhor.
Isto particularmente verdadeiro quando voc est modelando um ambiente
composto por um muitas mquinas interligadas. s vezes, um alto nvel de forma livre
diagrama uma opo melhor porque a notao muito mais flexvel. As informaes
contidas no Figura 2 pode ser to facilmente capturados em qualquer um diagrama de
rede ou um diagrama de forma livre em combinao com scripts de instalao.

Quando voc pensa sobre isso scripts de instalao so efetivamente "cdigo fonte de
implementao".
Para determinar se voc precisa criar um modelo de implantao, pergunte-se: se
voc no sabia nada sobre o sistema e algum lhe pediu para instal-lo e / ou manter
e apoi-lo, voc iria querer uma descrio de como as partes do sistema de ajuste
juntos? Quando eu fao esta pergunta das equipas de projecto com quem trabalho,
quase sempre decidir desenvolver algum tipo de modelo de implantao. Mais
importante, a prtica tem mostrado que a modelagem de implantao bem a pena.
Modelos de implantao for-lo a pensar sobre problemas de implantao
importantes muito antes que voc deve entregar o sistema real.
Ao determinar como modelar a arquitetura de implantao de um sistema,
independentemente dos artefatos escolhido, eu vou normalmente:
1
Identificar o mbito do modelo. O endereo diagrama como implantar uma
verso de um nico aplicativo ou ser que retratam a implantao de todos os
sistemas dentro de sua organizao?
2
Considere questes tcnicas fundamentais. O que vocs vo existente
sistemas precisam interagir / integrao com? Como que o seu robusto
sistema precisa ser (haver hardware redundante para failover a)? O que /
quem vai precisar se conectar e / ou interagir com o seu sistema e como eles
vo fazer isso (atravs da Internet, a troca de arquivos de dados, e assim por
diante)? O middleware, incluindo o sistema operacional e de comunicaes
abordagens / protocolos, ir usar o seu sistema? O hardware e / ou software ir
seus usurios interagir diretamente com (PCs, computadores de rede,
navegadores e assim por diante)? Como voc pretende monitorar o sistema,
uma vez que foi implantado? Quo seguro que o sistema precisa ser (voc
precisa de um firewall, voc precisa de hardware fisicamente seguro, e assim
por diante)?
3
Identificar a arquitetura de distribuio. Voc pretende fazer uma
abordagem cliente-gordo, onde a lgica de negcios est contida em um
aplicativo de desktop ou de uma abordagem de cliente magro, onde a lgica de
negcios implantado em um servidor de aplicativos? Ser que a sua
aplicao tem duas camadas, trs camadas, ou mais? Sua estratgia de
arquitetura de distribuio, muitas vezes, ser pr-determinado para a sua
aplicao, especialmente se voc estiver implantando o sistema para um
ambiente tcnico existente.
4
Identificar os ns e suas conexes. Sua estratgia de distribuio ir definir
o tipo geral de ns vai ter, mas no os detalhes exatos. Voc precisa tomar
decises de plataforma, tais como os sistemas operacionais e de hardware
para ser implantado, incluindo a forma como os vrios ns ser conectado
(talvez atravs de RMI e um barramento de mensagens como na Figura 2 ).
5
Distribuir software para ns. Ambas as verses dos diagramas de
implantao indicar o software que implantado em cada n, informaes
crticas para qualquer pessoa envolvida no desenvolvimento, instalao ou
operao do sistema.