Anotações APD

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.