Copy of Copy of Estudo de Segunda Feira pelo AVA

Prévia do material em texto

Estudo de Segunda Feira pelo AVA 
 
Evolução do Desenvolvimento de Software 
 Logo, os desenvolvedores perceberam que poderiam criar seus programas mais rapidamente, 
se usassem partes de software que já haviam sido desenvolvidos e que já estavam sendo 
usados. Isso levou ao conceito de reuso de software... 
 Entre as principais ferramentas para o reuso de software estão o uso de frameworks e 
de padrões de projeto. 
 Criando o primeiro projeto 
 Arquivo – Novo Projeto – Java Web – Aplicação Web – Coloque o nome do projeto – Java 
Server Faces 
Framework 
 Os frameworks foram desenvolvidos como uma ferramenta que orienta o desenvolvedor 
de software a usar certos procedimentos para criar um software. 
 Ao usar a orientação a objetos, é mais comum criar a estrutura em que o aplicativo será 
desenvolvido nos conceitos de abstração, polimorfismo e herança. 
 Assim, os frameworks costumam estruturar o código-fonte usado para criar um aplicativo em 
classes funcionais, que vão além da representação da base e dados e da criação de telas para 
interação com os usuários. Essas classes criam certos tipos de objetos e as interações entre os 
mesmos, para que uma determinada funcionalidade do software funcione. 
 O código gerado pelo framework pode ser entendido como um template, a ser customizado 
pelo desenvolvedor de acordo com a aplicação que ele está desenvolvendo. 
 
 Um dos primeiros frameworks a ser amplamente difundido na orientação a objetos foram 
o SmallTalk Model-View-Controller (MVC), as principais vantagens de usar um 
framework são: 
• Facilidade de reuso de partes prontas, para implementar novos 
sistemas; 
• Segmentar o processamento no máximo de classes possíveis: o 
framework se torna mais flexível à medida que quanto mais 
específicas as classes que eles implementam , assim, para 
coletar dados e gravar numa base de dados, é melhor ter uma 
classe para a tela, outra para representar a tabela na base de 
dados e outra classe para conectar as outras duas classes do que 
ter apenas uma classe que faça tudo isso; 
• Possibilidade de expandir o sistema: ao usar classes mais 
específicas, é facilitada a adição de novas partes aos sistemas, 
através do uso de interfaces que permitam conectar o novo 
software ao que já existe; 
 Outra característica dos frameworks que costuma ser apresentado é que os frameworks 
passam a controlar a execução das classes e do software, retirando parte da 
responsabilidade do desenvolvedor em criar classes de controle. 
 
Padrões de Projeto 
 
 Enquanto um framework orienta o desenvolvedor sobre como estruturar um software que 
será desenvolvido, um padrão de projeto orienta o desenvolvedor sobre como 
implementar uma solução para um problema específico desse software a ser 
desenvolvido. 
 
Quando Usar Framework e Padrão de Projetos 
 
 Ao usar a orientação a objetos para desenvolver um software, se costuma usar uma 
estrutura de software que separe as classes em funções específicas para implementar cada um 
desses módulos. Para isso, usamos o framework. 
 Se o sistema de vendas on-line precisa lidar com um volume muito grande de registros, 
processar essas informações e exibi-las para o usuário pode levar um tempo considerável, 
devido a um processamento complexo de dados, se o desenvolvedor optar por carregar os 
resultados de cada página diretamente do servidor de dados, conforme o usuário navega pelas 
telas com o resultado da pesquisa. Esse é um problema específico do software, e nesse caso, é 
recomendado usar um padrão de projeto. 
Conclusão 
 O desenvolvimento de software pode ser facilitado, feito com mais qualidade, com mais 
eficiência e mais rapidamente se forem usados frameworks e padrões de projeto. 
 
 
 
 
 
 
 
 
 
 
 
Capitulo 2 
Sistemas colaborativos 
 
A diferença principal entre os aplicativos das redes sociais para as aplicações 
corporativas é o objetivo final do software. Nas aplicações corporativas, a intenção do 
software é prover um serviço específico, Por sua vez, as redes sociais permite que os 
usuários compartilhem suas informações com outros usuários, seja de modo isolado, 
ou sob a forma de grupos, e o software usado para prover o funcionamento das redes 
sociais se baseia no conceito de groupware. 
 
GroupWare, ou Sistema Colaborativo 
 
 O conceito de groupware é um software que apoia o trabalho em grupo, de modo que 
ele possa ser executado coletivamente. Assim, vários usuários poderiam editar 
simultaneamente um mesmo texto, caso ele estivesse situado num ponto central, e 
todos aqueles que o estiverem editando possuem acesso a esse documento. 
Além das redes sociais, também são exemplos de sistemas colaborativos: 
Sistemas de controle de versão de software: vários programadores possuem acesso a 
um servidor que centraliza todo o resultado do desenvolvimento de um projeto de 
software 
Aplicações de telemedicina: atualmente, há vários tipos de aplicações que permitem que 
equipes médicas remotas possam trabalhar em conjunto no atendimento de pacientes. 
Educação a distância: possibilidade de um aluno acompanhar remotamente o conteúdo que é 
ministrado on-line por professores, 
Teletrabalho: um grupo de pessoas pode operar conjuntamente em vários locais 
remotos, mas estarem sempre em contato para troca de informações e atualização 
dos trabalhos. 
 
Desenvolvendo Sistema Colaborativos 
 
 Dado o exposto acima, é possível concluir que a definição mais simples para um 
sistema colaborativo é: um sistema projetado para auxiliar um grupo de pessoas a 
realizar um trabalho (ou objetivo) comum a todas elas. 
 
 
Conclusão 
 
Neste tópico falamos bastante sobre sistemas colaborativos, pois eles representam o 
máximo de complexidade que podemos encontrar ao desenvolver um projeto de 
software, pois demandam usuários remotos, execução e comunicação com sistemas 
remotos, muitas vezes, legados, uso de sistemas de bases de dados, várias vezes, que 
estão remotas ao servidor da aplicação sendo executada. 
 
 
 
 
 
 
Capitulo 3 
Arquitetura de Sistemas Colaborativos 
 As aplicações usadas para prover a colaboração entre usuários, permitem que a 
comunicação entre eles ocorra de modo assíncrono ou síncrono. 
 No modo síncrono, um usuário envia um conteúdo para os outros usuários que usam a 
aplicação. Esse trabalho é transmitido imediatamente aos outros, que ao receber esse 
conteúdo, o visualizam, e todos eles, incluindo o usuário que enviou o conteúdo, 
visualizam exatamente o mesmo conteúdo, e isso sempre ocorre em tempo real. 
No modo assíncrono, um usuário envia um conteúdo aos demais usuários do aplicativo. 
Entretanto, cada um desses usuários pode receber ese conteúdo num momento diferente 
dos demais. 
Existem várias definições para sistemas distribuídos, sendo a mais comum a que define 
um sistema distribuído como sendo um conjunto de componentes de hardware e software 
localizados em computadores autônomos, que se comunicam através da troca de 
mensagens 
Sistema distribuído necessita ter pelo menos um componente que gerencie a 
concorrência no acesso aos demais componentes de hardware ou software. Esse 
gerenciador de acessos concorrentes pode adotar uma das abordagens: 
 
 
 
 
• Controle de concorrência pessimista: o componente controla, 
serializa e sincroniza todas as operações sobre os recursos 
compartilhados; 
• Controle de concorrência otimista: o componente que gerencia 
o uso dos recursos, ao invés de evitar problemas devidos à 
inconsistência, ele tenta detectar que quando esses problemas 
estão prestes a ocorrer, e se propõe a evitarque esses 
problemas ocorram; 
 
 Características dos sistemas distribuídos: 
 
• Transparência da distribuição dos componentes: 
• Extensibilidade 
• Escalabilidade: isso requer que o sistema seja capaz de atender 
o aumento de solicitações de processamento estão sendo 
usados; 
• Tolerância a falhas: isso quer dizer que o sistema deve ser 
capaz de continuar executando os serviços que ele foi 
projetado para executar, mesmo quando falhas ocorrerem; 
• Interoperabilidade: isso quer dizer que o sistema poderá conter 
componentes de hardware e/ou software que são fornecidos 
pelos mais variados fabricantes. 
• Portabilidade: isso significa que cada um dos componentes de 
software usados para um sistema distribuído pode ser 
transferido para outro sistema distribuído, e eles continuarão 
funcionando exatamente do mesmo modo; 
 Os componentes de hardware e software podem se comunicar através de padrões de 
comunicação, como os arquivos de metadados baseados no padrão JSON e XML, ou em 
camadas de software, como o CORBA (Common Object Request Broker Architecture), ou 
baseados no uso de uma máquina virtual, como a JVM de Java que permite a execução de 
componentes desenvolvidos de acordo com o modelo EJB (Enterprise Java Beans). 
Alguns dos problemas encontrados nos sistemas distribuídos são potencializados, 
como por exemplo: 
 
• O controle do uso de recursos compartilhados é muito mais 
complexo quando ocorre a colaboração entre vários usuários, 
uma vez que um grande número deles pode acessar 
simultaneamente um determinado recurso exatamente ao 
mesmo tempo; 
• A colaboração entre os usuários deve ser complementada 
através de serviços que permitam a troca de mensagens 
instantâneas, conversas por áudio ou vídeo, entre seus usuários, 
e sempre em tempo real; 
• Como pode ser observado nas comunidades existentes nas 
redes sociais, é possível que um sistema colaborativo possua 
grupos específicos de colaboração, o que pode exigir uso de 
políticas descentralizadas para gerenciar as informações 
relacionadas a esses grupos, de segurança e de 
compartilhamento de informações e recursos; 
• O controle de uso do sistema é feito sobre os usuários, 
enquanto que nos demais tipos de sistemas distribuídos, o 
controle é exercido sobre os componentes que formam o 
sistema; 
• 
Arquitetura Centralizada 
A centralização do processamento em um único servidor também facilita a gestão dos 
recursos compartilhados, evita boa parte dos problemas de concorrência no uso desses 
recursos e da segurança a ser aplicada no sistema no acesso e no compartilhamento das 
informações que ele armazena, além de facilitar a autenticação dos usuários que se 
conectam a esse sistema. 
Arquiteturas Descentralizadas 
As vantagens da arquitetura descentralizada estão o fato de serem adicionados novos 
serviços ao sistema sem interferir nos serviços já existentes, ser mais fácil aumentar a 
capacidade de processamento do aplicativo, pela simples adição de novos componentes de 
software ou de hardware. Além disso, é possível reusar um componente do sistema em 
outro sistema, sem haver interferência nos demais componentes do sistema. 
Arquiteturas Híbridas 
Um modelo de arquitetura híbrida bastante interessante é o modelo que centraliza os 
componentes que realizam funções bastante específicas do aplicativo, em servidores 
únicos, e esses componentes podem ser acessados pelos diversos componentes espalhados 
na rede usada pelo aplicativo. 
 
 
 
 
 
 
 
 
Capitulo 4 
 
Arquitetura de Software 
 
Para projetar um software, há dois modelos principais, que são a análise estruturada, 
e a análise orientada a objetos. Os dois modelos orientam o desenvolvedor sobre o 
que ele deve considerar na hora de projetar um software, e de como ele deve ser 
documentado. 
A análise estruturada se tornou popular durante os anos 1980, e ela orienta o 
desenvolvedor a projetar o software, considerando os processos que estão sendo 
automatizados, e na forma como esses processos modificam uma determinada 
informação. 
Padrão da análise orientada a objetos método de trabalho deles consistia em 
determinar, a partir do conceito do sistema, quais seriam os objetos que interagiriam 
com o sistema, e como cada um deles é afetado, ou se ele afeta, o sistema no qual 
está inserido. 
Entre os vários diagramas que a UML apresenta, os mais indicados para a arquitetura 
de software são: diagramas de classes; diagramas de componentes; diagramas de 
instalação (ou implantação); diagrama de pacotes e os diagramas de estrutura 
composta. 
Diagrama de Classes 
Esse é um dos diagramas mais significativos da UML, e são usados para representar a 
estrutura e relações das classes usadas para construir o software. O diagrama de 
classes é conceitual, e por isso, ele pode ser usado para representar o sistema inteiro, 
ou partes dele. 
Diagrama de Componentes 
 Por exemplo, um sistema pode ter um componente de software que valide o CPF de 
um determinado usuário. O diagrama de componentes mostrará como ele se relaciona 
com outros componentes de software, quais os dados que ele precisa para realizar a 
validação do CPF, e quais serão as respostas que ele dará aos componentes com os 
quais ele se relaciona. 
Diagramas de Instalação (ou Implantação) 
Este diagrama é usado para apresentar a arquitetura do sistema. Ele mostra a 
distribuição dos componentes de hardware e software e sua interação com outros 
elementos que processam os dados usados no sistema. 
Diagrama de Pacotes 
Os diagramas de pacotes ilustram como as classes que implementam um sistema estão 
divididas sob a forma de pacotes, que são agrupamentos lógicos usados para organizar 
o software a ser implementado. 
 
Diagrama de Estrutura Composta 
Este diagrama costuma ser mais usado para demonstrar a arquitetura interna de 
alguma funcionalidade do software, ilustrando como os elementos que implementam 
o software se relacionam entre si, descrevendo a colaboração interna de classes, 
interfaces ou componentes para especificar uma funcionalidade do software. 
 
 
Capitulo 5 
 
Arquitetura em 3 Camadas 
 
De acordo com a UML, uma das formas mais interessantes para o desenvolvimento de 
aplicativos, é dividir o aplicativo em componentes de software. 
Para estabelecer um entendimento comum, nós definimos um componente de 
software como sendo a parte de uma aplicação que é responsável pela execução de 
determinada tarefa ou serviço, 
Os componentes de software são usados para estruturar um aplicativo de software, 
como é o caso dos frameworks, entretanto, componentes de software são mais 
complexos, uma vez que um componente de software pode ser usado como um 
aplicativo completo, dependendo da tarefa que ele executa. 
 
Porque usar Componentes de Software? 
 
Com a evolução do software, chegou-se à conclusão de que se um sistema fosse projetado 
sob a forma de componentes de software, ele seria flexível para ser facilmente alterado, 
além disso, ela seria mais facilmente integrada a outros sistemas. Outra vantagem dos 
componentes de software é que eles podem ser adaptados para funcionar segundo vários 
modelos de arquiteturas. Essa facilidade fez com que alguns desenvolvedores optassem 
por agrupar componentes de software com funções semelhantes, dentro de camadas de 
serviços, para facilitar o trabalho de modelagem da arquitetura. 
 
Modelo - Visão - Controle (MVC) 
Um dos primeiros padrões de projeto a surgir, mesmo antes dos componentes de 
software, o padrão de projeto denominado MVC, também conhecido como Model-
View-Controller, orienta o desenvolvedor a organizarseus componentes em 3 
camadas: 
• Modelo: esta camada agrupa os componentes de software que executam as 
regras de negócios, gerenciamento de conexão com as bases de dados, além de 
lógica e funções necessárias para manter o software sendo executado; 
• Visão: esta camada agrupa os componentes que permitem ao usuário do 
software informar, ou ter acesso, aos dados que o sistema tráfega; 
• Controle: esta camada agrupo os componentes de software que controlam a 
troca de informações entre os componentes que estão instalados nas outras 
duas camadas;. 
 
Modelos em 3 Camadas 
O MVC surgiu durante a década de 1970, para um determinado cenário que havia no 
desenvolvimento de software, e o seu uso vem sendo aperfeiçoado até os dias atuais, 
pois surgiram novas tecnologias, como linguagens de programação, além de novos 
procedimentos, frameworks e outros padrões de projeto, além dos ambientes de 
desenvolvimento, que melhoraram bastante. 
 
 
Capitulo 6 
 
Arquitetura Orientada a Serviços (SOA) 
 
Esse modelo orienta o desenvolvedor a basear seu projeto em componentes de 
software que executam serviços específicos. Normalmente, eles se comunicam com 
outros componentes, seja para realizar um serviço para outros componentes, seja para 
solicitar que outros componentes façam algum serviço. 
 
Comunicação Entre Componentes de Software 
 
Um componente de software se comunica com outro componente de software através 
da troca de mensagens. Nesse processo, quando um componente de software envia 
uma mensagem, ele inicia uma comunicação para solicitar que outro componente de 
software execute algum tipo de processamento 
Uma estratégia bastante usada é a comunicação ponto a ponto. Nesse modelo de 
comunicação, os dados que serão transportados pelas mensagens serão sempre 
inseridos no sistema através de um nó (que pode ser um computador, um dispositivo 
móvel ou um servidor). Esse nó que foi usado para inserir os dados, faz uma cópia 
dessa mensagem, e a envia para um nó, ou conjunto de nós, que deverão estar 
conectados na rede para receber a mensagem. 
A comunicação broadcast funciona de modo análogo às transmissões de rádio e TV. 
Ou seja, um nó envia uma mensagem pela rede, ela trafega na rede, disponível a todo 
e qualquer nó conectado na rede 
A vantagem do modelo cliente-servidor é que os clientes que deverão receber as 
mensagens inseridas pelo servidor, não precisam estar conectados ao sistema. 
Estes dois modos de comunicação são exemplos de comunicação unicast, na qual um 
nó determina o nó, ou nós, que deverá receber a mensagem. Neste caso, é comum 
implementar uma verificação do recebimento da mensagem em cada um dos nós, 
além de manter um controle que assegure que as mensagens foram enviadas e 
recebidas apenas pelos destinatários aos quais haviam sido endereçadas. 
 
Arquitetura Orientada a Serviços (SOA) 
O modelo de Arquitetura Orientada a Serviços, conhecida como SOA (do inglês Service 
Oriented Architecture), prevê um modelo em que o aplicativo é implementado 
através da composição de serviços. 
A forma de análise para determinar os serviços do software é praticamente o mesmo 
usado para projetar os componentes de software. O projetista identica quais são os 
serviços que o software precisa para funcionar, e como eles deverão se comunicar com 
outros componentes, seja através de metadados, ou através de mensagens. 
O modelo de arquitetura SOA se baseia em três componentes principais: 
• Provedor de Serviço: responsável por executar um determinado serviço, e por 
manter a rede de comunicação informada sobre qual é o tipo de serviço que 
ele está oferecendo; 
• Serviço de Descoberta: responsável por armazenar a localização dos serviços 
disponíveis na rede, e conectar o serviço solicitado ao serviço que solicitou a 
execução desse serviço; 
• Consumidor: é quem solicita a execução de um serviço. 
O SOA se baseia no modelo de comunicação híbrida, onde um nó presenta na rede de 
comunicação pode ser definido tanto como sendo um cliente quanto sendo um 
servidor. 
Para implementar uma aplicação baseada em SOA, o desenvolvedor do software 
precisa projetar seus componentes de software para prover um serviço ao aplicativo 
A interface de serviço representa uma forma de contato através de um conjunto de 
métodos que podem ser invocados pelo Consumidor, e os tipos de dados que serão 
usados durante a invocação e execução do serviço. 
Outra característica de SOA é a possibilidade de combinar os serviços já existentes 
para criar novos serviços. Nesse caso, deve haver um componente de software que 
coordenará a execução dos serviços. Esse componente de software também controlará 
os componentes de software que executam os serviços do Provedor de Serviços. 
 
Aplicando o Modelo SOA 
Aplicando esse modelo ao desenvolvimento dos aplicativos colaborativos, e seus 
similares, é através de um modelo em que os usuários possam colaborar entre si 
através da criação e compartilhamento de serviços. Desse modo, os usuários do 
sistema podem atuar tanto como Provedores de Serviços, no momento em que ele cria 
e publica um serviço, quanto como Consumidores de serviços, momento em que o 
usuário pesquisa por um serviço capaz de atender às suas necessidades, para invocá-lo 
e usá-lo. 
 
 
 
 
Capitulo 7 
 
Servidores de Aplicação 
A função de um servidor é prover algum tipo de serviço para seus usuários, como por 
exemplo: armazenamento de dados, serviços de correio eletrônico (e-mail), 
compartilhamento de arquivos; apenas para citar os usos mais comuns. Além deles, 
também há os servidores web, que são usados para hospedar e executar aplicativos 
usados na Internet. 
A função do desenvolvedor dessas aplicações é fazer com que o software seja capaz de 
se conectar e gerenciar aos vários tipos de servidores usados, para acessar os dados e 
o conteúdo armazenados pela aplicação, gerenciar e disponibilizá-los de acordo com o 
desejo do usuário. 
Sendo uma plataforma, ele possibilita que outras aplicações possam usar seus 
recursos, e há vários aplicativos on-line, desde jogos até aplicações sérias. E isso traz 
outros requisitos: 
• Verificar se o aplicativo é uma fonte segura; 
• Verificar quais os tipos de informações do usuário que o aplicativo pode 
acessar; 
Para ser usada, a plataforma Java EE precisa de um servidor de aplicações, que é a 
forma através do qual essa plataforma é disponibilizada a seus usuários. No caso, 
os desenvolvedores de software, não os usuários dos aplicativos finais. 
 
Um desenvolvedor que usa a linguagem de programação Java, usa o Java EE para ter 
acesso aos serviços que um servidor de aplicações disponibiliza, e que resolvem 
problemas de infraestrutura, como: 
• ter segurança no acesso às informações; 
• garantir a disponibilidade dos serviços; 
• balancear a carga de uso dos servidores; 
• gerenciar as bases de dados usadas pela aplicação; 
Precisa conectar seu aplicativo aos serviços disponibilizados pelo servidor de 
aplicações, obedecendo às seguintes regras: 
• Seguir os padrões e especificações usados pela Java EE; 
• Que ele possa prover serviços de infraestrutura que possam ser usados por 
outras aplicações; 
• Que seu aplicativo possa gerenciar a comunicação com outros servidores de 
aplicações; 
• Quando possível, disponibilizar frameworks para gerenciar/desenvolver 
serviços para outras aplicações; 
Comparando Java EE com .Net 
• Os aplicativos criados em Java podem ser executados em 
qualquer sistema operacional, aproveitando o máximo do que a 
plataforma permite. Para .NET, apesar de iniciativas como 
Mono e DotGNU, runtimes para poder executar aplicativos.Net no Linux, para que o desenvolvedor aproveite todo 
potencial da plataforma, é necessário que o aplicativo 
desenvolvido seja executado no Windows; 
• Para a escalabilidade dos aplicativos (capacidade para 
incrementar o potencial da aplicação simplesmente 
adicionando novos componentes de hardware ou de software), 
as duas plataformas possuem mecanismos eficazes; 
• Quanto às linguagens de programação, .NET permite que os 
vários componentes da aplicação sejam escritos em VB.NET, 
C#, C/C++ ou J#. O uso de várias linguagens de programação 
diminui a facilidade no compartilhamento de informações e, 
pior, aumenta a complexidade na manutenção da aplicação, 
pois ser necessário contratar vários experts em cada uma 
dessas linguagens, aumentando o custo de desenvolvimento. 
Java EE usa apenas a linguagem Java. 
• A curva de aprendizado das duas plataformas é similar, mas 
Java leva vantagem por haver uma quantidade maior de 
material disponível aos desenvolvedores. 
• Por último, há a portabilidade das aplicações, e neste quesito, 
pouco pode ser comparado, pois graças à sua runtime, à 
padronização na forma de realizar a programação e à 
obediência das especificações de tecnologias e produtos 
associados ao Java, um aplicativo construindo com Java EE 
pode ser executado em qualquer sistema operacional, enquanto 
que o .NET somente pode ser totalmente aproveitado se 
executado sobre o sistema operacional da Microsoft, e do 
hardware que esse sistema está habilitado a usar. 
Conclusão 
Para os desenvolvedores de Java EE, um servidor de aplicações é um ambiente que 
permite desenvolver e executar aplicações de grande porte, baseadas em modelos de 
arquitetura distribuída. Os desenvolvedores o usam, porque ele possui a implementação 
dos serviços disponíveis na plataforma Java EE, e que podem ser usados para 
desenvolver os mais variados tipos de aplicações., 
 
 
 
 
Capitulo 7 
 
Metadados para Troca de Dados (XML e JSON) 
 
. Para permitir a comunicação entre os sistemas desenvolvidos com tecnologias diferentes, 
uma das formas mais usuais é o uso de metadados. 
 Nos anos 1990, as aplicações para a Internet trouxeram novos tipos de metadados, 
baseados em padrões abertos, como os formatos XML e JSON. A principal vantagem no 
uso desses tipos de arquivos se deve ao fato de que são arquivos que podem ser 
escritos e lidos pro rotinas escritas usando qualquer linguagem de programação 
XML (eXtensible Markup Language) 
 Projetada para ser incrementada de acordo com os seguintes princípios: 
• Separar o conteúdo a ser apresentado, da formatação do 
conteúdo (arquivos conhecidos como DTD); 
• Ser uma estrutura que possa ser facilmente entendida por 
máquinas e seres humanos; 
• Não haver limitação na quantidade de tags que podem ser 
criadas num arquivo XML; 
• Pode servir de agente de transporte de informações entre 
sistemas e bases de dados distintos; 
• Manter o foco do desenvolvedor no conteúdo a ser transmitido, 
e não em sua aparência. 
JSON (JavaScript Object Notation) 
 
Uma alternativa bastante popular em relação ao XML é o formato JSON, foi criado 
para servir como um padrão com baixo custo de processamento que permitisse a 
transmissão de informações entre os lados cliente e servidor de um aplicativo web. 
Ele tem como características principais: 
• É uma coleção de dados no formato nome da informação : 
valor da informação. Esse formato foi definido assim pois era 
a forma mais usual para definir as estruturas, ou uniões, de 
dados em aplicativos escritos nas linguagens C e C++, e que 
era facilmente tratada na forma de um vetor de dados, ou array; 
• Ele tem uma estrutura de informações que pode ser facilmente 
entendida por seres humanos e máquinas; 
• Apesar de ser um subconjunto da linguagem de programação 
JavaScript, a forma como a informação é tratada é totalmente 
independente da linguagem de programação; 
 
 
Capitulo 8 
 
RMI, SOAP (Web Services) e REST 
 
O RPC (sigla de Chamada Remota de Procedimento, tradução para Remote Procedure Call) é 
um procedimento para permitir que um programa de computador possa chamar e executar 
outro programa sendo executado em outro computador (desde que eles estejam conectados 
na mesma rede de comunicação), sem que o programador não precise implementar o 
software que estabeleça e controle a conexão entre os dois computadores, um vez que isso já 
é feito pelos outros protocolos de transferência de dados usados na Internet. 
Seguindo essa tendência, as plataformas de desenvolvimento, como Java EE e .Net, 
incorporaram componentes que implementam o RPC, o RMI para o Java, e o DCOM para o 
.Net. 
RMI (Remote Method Invocation) 
 Nesse processo, o aplicativo executado no cliente, invoca um aplicativo sendo 
executado no servidor, envia uma mensagem com os dados que ele quer que sejam 
processados, e espera uma resposta do aplicativo sendo executado no servidor. A 
resposta vem na forma de uma mensagem, contendo o resultado do processamento 
efetuado pelo servidor. Isso significa que o aplicativo executado no servidor tem 
que ficar sempre em execução, ou processando os dados, ou esperando por uma 
nova requisição enviada por um cliente. 
Como esse procedimento é realizado em dois locais diferentes, e um depende do 
outro, é necessário que o desenvolvedor sempre leve em consideração: 
• O aplicativo sendo executado no cliente ou no servidor deve 
prever a ocorrência de erros causados por falhas na rede de 
comunicação, e tratar esses erros; 
• O aplicativo cliente também deve considerar possíveis falhas 
no aplicativo do servidor, e tratar essas informações de modo 
coerente; 
• As trocas de informações devem ser feitas somente por troca 
de mensagens, uma vez que as variáveis indicam endereços de 
memória, e um aplicativo sendo executado no cliente não é 
capaz de acessar a memória do servidor, e o mesmo ocorre 
com o aplicativo sendo executado no servidor, em relação ao 
aplicativo sendo executado no cliente; 
• O aplicativo apresentará queda no desempenho, uma vez que 
esse comunicação entre cliente e servidor demanda um certo 
tempo para ser processado, e se for muito elevado, certamente 
comprometerá o uso do aplicativo; 
• O aplicativo sendo executado no servidor tem que saber quem 
está solicitando o processamento, para encaminhar o resultado 
para esse cliente, ou seja, isso significa que a comunicação 
deve ocorrer sempre de modo seguro. 
SOAP (Simple Object Access Protocol) 
O protocolo simplificado de acesso a objetos, SOAP, é uma especificação de protocolo 
usado na troca de dados estruturados entre aplicativos para a Internet, através de 
serviços web (Web Services). 
 
SOAP Envelope 
Esse elemento ( xmlns:soap) é a raíz da mensagem SOAP e é ele quem identifica 
que o arquivo XML é uma mensagem SOAP. Esse elemento é definido pelo valor 
“http://www.w3.org/2003/05/soap-envelope/”, como pode ser observado na 
Listagem 4. 
SOAP Encoding 
Esse elemento (soap:encodingStyle) define o tipo de dado que é usado no arquivo, 
e pode aparecer em qualquer elemento SOAP, e ele é aplicado ao conteúdo do 
elemento, e de deus elementos filhos. 
SOAP Header 
Esse elemento é opcional e contém informações específicas à aplicação (como por 
exemplo: forma de autenticação, pagamento, etc...) sobre a mensagem SOAP. Se 
esse elemento está presente, ele deve ser o primeiro elemento filho do elemento 
Envelope. 
 
REST (Representational State Transfer) 
A transferência do estado representativo é outra solução para a integração de 
vários aplicativos, baseada em Web Services. Mas ao contrário dos serviços web 
baseados em SOAP, quetrocam arquivos XML entre os clientes e aplicativos que 
executam os serviços, o REST foca o uso do protocolo HTTP e nas URI 
(Identificador Uniforme de Recursos). 
Em suma, o REST disponibiliza recursos que são identificados pelos URIs, e eles 
podem ser manipulados por uma interface padrão, como o HTTP, e a troca de 
informações ocorre através das representações desses recursos. 
 
 
 
 
 
Capitulo 9 
 
Design Patterns 
 
Ser um desenvolvedor de software que segue a linha “pensar em como deve ser feito, e 
depois fazer” significa que se trata de uma pessoa que está disposta a seguir algumas 
regras de trabalho, e uma dessas regras é usar ao máximo possível padrões de projetos, 
que também são conhecidos como design patterns. Os livros Padrões de Projeto de 
Erich Gamma e Utilizando UML e Padrões de Craig Larman são dois clássicos sobre o 
assunto, explicando vários dos padrões existentes. 
Os padrões de projetos são oriundos de boas práticas de programação, definidas por 
alguns desenvolvedores de software no início dos anos 1970. Em congressos, 
seminários, etc... , a troca de experiências entre eles fez com que fossem notados 
problemas que eram comuns a qualquer tipo de software, e o primeiro problema a ser 
atacado, foi a relação entre as interfaces de usuário, regras de negócio e bases de dados, 
e como uma dessas partes poderia ser modificada sem causar problemas às outras duas 
partes. Outra questão que foi analisada, foi a possibilidade de fazer um novo software, 
sem ser necessário fazê-lo desde o início. 
Dessa troca de experiências, surgiu o MVC (Model-View-Controller), um padrão de 
projeto que modela uma arquitetura de sofware para orientar os desenvolvedores de 
software a separar seu código-fonte em três partes principais: interação com o usuário 
(view), regras de negócio e rotinas de acesso às bases de dados (model) e algo que 
conecte essas duas partes (controller); Essas três partes serão totalmente independentes 
entre si, e se conectadas corretamente, formam um software totalmente funcional. 
 
 
Capitulo 10 
 
Frameworks 
Quando falamos de framework no desenvolvimento de software, estamos falando de 
uma solução que costuma ser desenvolvida e usada para a solução de um problema 
específico, mas que ainda não é um software executável. 
Um framework é um conjunto de bibliotecas, associadas com interfaces que permitem 
acoplar essas bibliotecas ao software que está sendo desenvolvido. 
O objetivo de um framework é fornecer uma funcionalidade genérica, que ao ser usada 
por uma desenvolvedor, pode implementar uma funcionalidade específica. 
Vantagens no uso de frameworks: 
• maior facilidade para a detecção de erros; 
• ter uma garantia melhor da qualidade do software que ele está 
desenvolvendo; 
• ele se concentra no desenvolvimento do aplicativo final; 
• reuso de solução que já resolve alguns problemas conhecidos; 
• uso otimizado de recursos. 
 
 
 
Capitulo 11 
 
Frameworks para Aplicativos Web 
A grande questão é quando é necessário controlar o conteúdo HTML a ser exibido pela 
interface web. Nesses casos, a plataforma Java EE disponibiliza um subconjunto de 
tecnologias denominado Java Web, formado por JSP, Servlets e JavaBeans 
Há várias formas de usar essas tecnologias, desde escrever toda a regra de negócios em 
arquivos JSP, ou distribuí-los em classes do tipo JavaBeans e usar Servlets para 
conectar as páginas JSP e/ou HTML aos JavaBeans. 
Java WEB foi projetado para ser usado da seguinte maneira: 
• JSP (Java Server Pages): misturado ao código HTML, em arquivos de extensão 
JSP, é usado com a função de controlar o conteúdo HTML a ser apresentado ao 
usuário. Ele pode ter seu layout aprimorado com o uso de CSS e JavaScript, 
como se fosse um arquivo HTML puro; 
• Servlet: são classes que tratam requisições e geram respostas de aplicações web, 
elas podem ser usadas para controlar a navegação entre as várias páginas do site, 
e controlam o uso das classes JavaBeans; 
• JavaBeans: são classes que executam as regras de negócio e as tarefas de infra-
estrutura, como acesso a bases de dados; 
 
Na computação em nuvem, podem ser usados aplicativos executados em outros 
servidores. Para acessar esses aplicativos, podem ser usados tanto Servlets quanto 
JavaBeans. A comunicação entre servidores remotos exige algumas tecnologias 
adicionais de Java EE, como: 
• JNDI: usado para endereçar o servidor, usuários ou os serviços que são 
executados remotamente; 
• RMI: usado para estabelecer a comunicação entre objetos remotos; 
• JTA: usado para controlar remotamente a execução de transações; 
 
Frameworks para Design Responsivo 
 
Design Responsivo, que na prática, é a forma que o próprio aplicativo web tem para 
reconhecer qual é o tamanho da tela que o usuário está usando paar visualizar o 
conteúdo, e realinhar, ou redesenhar, a formatação da tela, para se adequar à 
renderização que o browser usado pelo usuário é capaz de executar 
BootStrap 
Como a maior parte das ferramentas usadas no desenvolvimento de aplicações web, o 
BootStrap é o resultado do trabalho de uma equipe de desenvolvedores resolvendo um 
problema específico. No caso, a equipe que desenvolveu o Twitter desenvolveu um 
framework para facilitar o seu trabalho, e esse framework começou a ser usado em 
outras aplicações, até ser criado uma comunidade de desenvolvedores que continua o 
desenvolvimento do BootStrap. 
jQuery 
O framework jQuery (https://jquery.com/) é provavelmente o framework mais usado 
nos aplicativos web. Ele é um framework que facilita o uso da linguagem de 
programação JavaScript, que foi originalmente desenvolvida para processar as 
informações que um usuário digitava num formulário web, diretamente no browser. Ele 
é um framework simples, mas bastante rápido e eficiente, que manipula o conteúdo 
HTML que o browser está renderizando. Ele ajuda a manipular a informação sendo 
exibida, animações e implementa o Ajax de modo mais simples do que é possível fazer 
com JavaScript. Uma das habilidades dele é detectar qual é o browser sendo usado pelo 
usuário, e ajustar o uso de JavaScript de acordo com o que o browser permite executar 
de JavaScript, uma vez que não uma padronização na forma como o broswer pode 
interpretar o os scripts escritos em JavaScript. 
Ajax 
O framework Ajax (ou AJAX), sigla para XML e JavaScript Assíncrono (do inglês 
Asynchronous JavaScript and XML) é um conjunto de técnicas de desenvolvimento 
web combinada a um conjunto de tecnologias, que são executadas no browser para 
estabelecer aplicações web que permitam atualizar o browser com as atualizações de 
conteúdo que estão sendo realizadas pelo servidor, de modo a diminuir o tráfego de 
informações entre o browser e o servidor. Como as atualizações podem não ocorrer no 
servidor, o Ajax não depende das atualizações efetuadas pelo servidor, e por isso, essa 
comunicação não pecisa ser sincronizada. 
Hibernate 
A motivação do Hibernate foi prover uma ferramenta que pemitiria desenvolver 
aplicativos web, baseado em classes que representavam as entidades e relacionamentos 
definidos no banco de dados, classes que controlam a execução de transações SQL em 
bases de dados, ele cria formulários baseados em páginas html ou jsp, e classes que 
conectam as classes que controlam a execução das transações SQL com as páginas HTML 
e JSP. 
 
 
 
 
 Capitulo 12 
 
Frameworks para Gerenciamento de Dados 
 
Os dados que um aplicativo manipula costumam ser armazenados em diversas formas, 
mas a forma mais comum é através de um sistema de gerenciamento de banco de dados 
(SGBD), e de acordo com várias pesquisas específicas,a maior parte dos SGBD são bases 
de dados relacionais que executam a linguagem de consultas estruturada (SQL), mas há 
vários outros, também conhecidos como NoSQL e orientados a objetos. 
 
Desenvolvendo um Framework ou API de Persistência de Dados 
 
A diferença entre um framework e uma API é a forma como eles são usados pelo 
desenvolvedor. Enquanto um framework provê um conjunto de classes, métodos ou 
bibliotecas que permitem ao desenvolvedor criar alguma coisa a ser usada pelo seu 
software. Neste caso, a camada de persistência de dados. Uma API é um conjunto de 
classes ou métodos que realiza uma tarefa para o aplicativo que a usa. 
 
Mapas Objeto-Relacional (ORM) 
Esses frameworks desenvolveram um conceito usado em APIs como a JPA e o Entity 
Frameworks, que é o de mapas objeto-relacional (abreviados como ORM). Esse 
conceito orienta o desenvolvedor a escrever classes que ao invés de usar a técnica 
tradicional da orientação a objetos, onde os objetos representam as entidades que 
interagem com um sistema, e transformam a informação que esse sistema processa. 
O uso do ORM nessas APIs serve para mapear os relacionamentos das entidades 
usadas pelo SGBD para armazenar as informações usadas pelo sistema. Normalmente, 
essas classes são denominadas como classes de entidade. Assim, cada classe de 
entidade é usada para representar uma entidade no SGBD, e o desenvolvedor a usará 
para informar para a API o nome da entidade à qual ela está associada, a relação de 
colunas que o objeto está conectado, e as restrições de chave primária ou estrangeira 
que a entidade está usando. 
 
 
 
 
 Capitulo 13 
 
Frameworks usados para implementar software em 3 camadas 
 
Os frameworks são ferramentas que agilizam o desenvolvimento de software, pois de 
modo geral, eles disponibilizam um conjunto de funcionalidades que já fazem alguma 
coisa em relação aos requisitos não funcionais. Como os requisitos não funcionais estão 
conectados ao que o software precisa para ser executado, e não sobre o que ele realmente 
precisa fazer, os frameworks direcionam os desenvolvedores a focar seu trabalho em 
implementar as regras de negócios do aplicativo. 
 
Os frameworks de software costumam ter funcionalidades que já avaliam o que 
será usado, como será usado, como o desenvolvedor deve expandir suas 
funcionalidades, e garantem uma certa estabilidade no aplicativo final que foi 
desenvolvido. Entretanto, um framework de software sempre atende a um domínio 
bastante específico de problemas, como: 
• Modelagem de aplicações usados no mercado financeiro; 
• Modelagem de processos usados no mercado corporativo; 
• Sistemas com suporte de decisão; 
• Aplicações que usam os sistemas de informações geográficas; 
• Autoração e reprodução de arquivos multimídia; 
• Sincronização de informações entre clientes e servidores; 
• Sincronização de dados entre sistemas remotos; 
• Vários tipos de middleware; 
• Desenvolvimento rápido de interfaces gráficas de usuários; 
• Gerenciamento de bases de dados; 
Spring Framework 
 
O Spring framework possui um núcleo central, que é estendido por seus usuários para 
desenvolver o aplicativo. Esse núcleo central (Core Container) assume o controle do 
aplicativo através do uso de uma técnica de programação, conhecida como reflexão de 
objetos. Através da reflexão, o núcleo central do Spring se torna o responsável por 
gerenciar o ciclo de vida dos objetos criados por seus usuários, isso significa, que é ele 
quem cria os objetos que implementam as regras de negócio, executa os métodos que 
inicializam esses objetos, conecta e gerencia a conexão dos objetos que precisam ser 
encadeados para executar as regras de negócio. Esses objetos são chamados objetos 
gerenciados. 
O Spring permite que seus usuários configuram a forma como seu núcleo central deve 
funcionar, através de arquivos de configuração XML, ou através da injeção automática 
de código (a partir de sua versão 3.0) diretamente nas classes implementadas pelos 
desenvolvedores, através do uso de anotações. 
 
ASP.NET 
O ASP.NET é a plataforma desenvolvida pela Microsoft como framework para 
desenvolvimento de aplicações web, baseadas no Framework .Net, e feito com base na 
tecnologia ASP, que caiu em desuso quando ASP.NET foi introduzido no mercado. 
Como ocorre com qualquer outro tipo de aplicativo para o .Net, o ASP.NET herda todas 
as características do Framework .Net. Assim, ele permite que seja usada qualquer uma 
das linguagens de programação disponíveis no Visual Studio, para construir as 
aplicações ASP.NET. Entretanto, a mais popular é a linguagem de programação C#. 
Essa característica das linguagens de programação pode criar um cenário, onde uma 
aplicação ASP.NET pode ser formada por vários componentes de software, sendo cada 
um deles escrito numa linguagem diferente dos demais. 
 
Ruby on Rails (Rails) 
Ruby on Rails, ou simplesmente Rails ou RoR, é um framework para desenvolver 
aplicações web usado diretamente no lado do servidor. Ele foi escrito com a linguagem 
de programação Ruby para permitir o desenvolvimento de aplicações web, seguindo o 
modelo de arquitetura MVC, e fornecendo módulos padronizados para conexão com 
bases de dados, execução de web services e implementação de páginas web. O RoR 
não usa nenhum modelo de programação proprietário, com a maioria dos outros 
frameworks, e encoraja seus usuários a explorarem o máximo possível o uso de vários 
dos padrões web, como JSON e XML para transferência de dados, e HTML, CSS e 
JavaScript para o desenvolvimento das interfaces de usuário. 
 
Laravel 
Laravel é um framework open source que permite o desenvolvimento de aplicações 
PHP de acordo com o modelo de arquitetura MVC. Ele contém um sistema modular de 
organização do código-fonte, com um componente dedicado para a gestão de 
dependências. Como a maioria dos outros frameworks de aplicação, permite que o 
aplicativo se conecte a vários sistemas de banco de dados relacionais, e provê 
ferramentas que o desenvolvedor pode usar para acelerar o desenvolvimento de 
software.