PDF gerado usando o pacote de ferramentas em código aberto mwlib. Veja http://code.pediapress.com/ para mais informações.PDF generated at: Thu, 18 Oct 2012 02:50:31 UTC

caesb editaluml em diante até soap

ConteúdoPáginas

UML 1Diagrama de classes 4Diagrama de objetos 6Diagrama de componentes 7Diagrama de instalação 8Diagrama de pacotes 9Diagrama de estrutura composta 10Diagrama de caso de uso 11Diagrama de transição de estados 14Diagrama de atividade 16Diagrama de sequência 18Diagrama de interatividade 19Diagrama de colaboração 20Diagrama de tempo 21Padrão de projeto de software 22Abstract Factory 25Builder 30Factory Method 34Prototype 40Singleton 43Adapter 48Bridge (padrão de projeto de software) 49Composite 50Decorator 51Façade 52Flyweight 55Proxy (padrões de projeto) 55Chain of Responsibility 57Command 58Interpreter 59Iterator 59Mediator 59Memento (informática) 63Observer 63

State 64Strategy 71Template Method 74Visitor Pattern 77MVC 78Service-oriented architecture 81Análise de pontos de função 87Servlet 89Plataforma Java 90JavaServer Pages 93AJAX (programação) 95JavaServer Faces 101Spring Framework 102Hibernate 103Web service 105XML 112XSLT 116UDDI 117Web Services Description Language 118SOAP 119

ReferênciasFontes e Editores da Página 121Fontes, Licenças e Editores da Imagem 123

Licenças das páginasLicença 124

UML 1

UMLA Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração. AUML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro eem seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramaspadronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É umanotação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamentedesenvolvido utilizando a UML.É importante distinguir entre um modelo UML e um diagrama[1] (ou conjunto de diagramas) de UML. O último éuma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. O XMI(XML Metadata Interchange) na sua versão corrente disponibiliza troca de modelos mas não de diagramas.

especificação, documentação, estruturação para sub-visualização e maior visualização lógica dodesenvolvimento completo de um sistema de informação.

A UML é um modo de padronizar as formas de modelagem.

O futuro da UMLEmbora a UML defina uma linguagem precisa, ela não é uma barreira para futuros aperfeiçoamentos nos conceitosde modelagem. O desenvolvimento da UML foi baseado em técnicas antigas e marcantes da orientação a objetos,mas muitas outras influenciarão a linguagem em suas próximas versões. Muitas técnicas avançadas de modelagempodem ser definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir a sua estruturainterna.A UML será a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual, simulações eambientes de desenvolvimento. Em breve, ferramentas de integração e padrões de implementação baseados em UMLestarão disponíveis para qualquer um.A UML integrou muitas ideias adversas, e esta integração acelera o uso do desenvolvimento de softwares orientadosa objetos.

HistóriaA UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagemde sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson)fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagemde modelagem padrão para modelar sistemas concorrentes e distribuídos.A UML ainda não é um padrão da indústria, mas esse objetivo está a tomar forma sob os auspícios do ObjectManagement Group (OMG). O OMG pediu informação acerca de metodologias orientadas a objetos que pudessemcriar uma linguagem rigorosa de modelagem de software. Muitos líderes da indústria responderam na esperança deajudar a criar o padrão.Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch naRational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, emoutubro de 1995, o esboço da versão 0.8 do Unified Process - Processo Unificado (como era conhecido). Nestamesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar ométodo OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórciointernacional de empresas que define e ratifica padrões na área de Orientação a Objetos.

UML 2

Visão geral da UML

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

UML 3

Elementos•• De estrutura:

•• Classe•• Objetos•• Interface•• Componente•• Colaboração•• Nó

• De comportamento:•• Casos de uso•• Iteração•• Máquina de estados

•• De agrupamento:•• Pacote•• Modelo•• Subsistema•• Framework

•• De anotação:•• Notas

Relacionamentos•• Agregação• Associação (bidirecional ou unidirecional)•• Composição•• Generalização

Ligações externas• (en) OMG/UML [3]

• (en) Understanding the Unified Modeling Language (UML) [4] – Introductory article for UML. Consultado em 7de fevereiro de 2011

• (en) Ferramentas UML [5]

• (pt) Ferramenta CASE para Delphi [6]

• (en) StarUML Open Source UML/MDA [7]

• (en) UMLZone [8]

UML 4

Referências[1][1] Diagramas são meios utilizados para a visualização dos blocos de construção da UML, utilizando representações gráficas de um conjunto de

elementos que permitem visualizar o sistema sob diferentes perspectivas.[2] http:/ / pt. wikipedia. org/ w/ index. php?title=Predefinição:Diagramas& action=edit[3] http:/ / www. uml. org/[4] http:/ / www. methodsandtools. com/ archive/ archive. php?id=76[5] http:/ / case-tools. org/ uml_modeling. html[6] http:/ / www. speedcase. com. br/[7] http:/ / staruml. sourceforge. net/[8] http:/ / www. umlzone. com/

Diagrama de classes

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem demodelo para objetos.É uma modelagem muito útil para o sistema, define todas as classes que o sistema necessita possuir e é a base para aconstrução dos diagramas de comunicação , sequência e estados.

Conceitos• Classe: Elemento abstrato que representa um conjunto de objetos. A classe contém a especificação do objeto;

suas características: atributos e métodos (ações / comportamentos).• Atributo: Define características da classe como:

• Visibilidade: Pública onde outras classes podem ter acesso ao atributo. Privada o atributo somente éacessado diretamente pela própria classe e Protegida ou Pacote que é acessado pelo relacionamento daclasse com a classe externa,.

•• Nome: Identificação do atributo.• Tipo de dados: Tipo de dado do atributo.•• Multiplicidade: Relacionamentos.• Valor inicial: Depende da linguagem de programação, valor opcional.

Diagrama de classes 5

•• Propriedade: Características do elemento, opcional.• Operação: Função requerida a um objeto.

•• Nome, Visibilidade e Parâmetros.• Associação: Relacionamentos entre classes.

•• Nome: Nome da associação.•• Multiplicidade•• Navegação: De onde vem as informações da classe e para onde vai.

Tipos de relacionamentosAgregação e composição são tipos especiais de associações.

AgregaçãoUma agregação representa um todo que é composto de várias partes. Exemplo: um conselho é um agregado demembros, da mesma forma que uma reunião é um agregado de uma pauta, uma sala e de participantes. Aimplementação deste relacionamento não é uma contenção, pois uma reunião não CONTÉM uma sala. Assim sendo,as partes da agregação podem fazer outras coisas em outras partes da aplicação, eles podem ser referenciados poroutros objetos e não somente por um objeto. Em outras palavras, na implementação não há diferença entre agregaçãoe um simples relacionamento “uses”. Nos dois casos, um objeto tem referências para outros objetos. Em UML, aagregação é representada por uma linha com um losango vazio do lado da classe que manda no relacionamento.

ComposiçãoA composição, diferentemente da agregação, é um relacionamento de contenção. Um objeto (container) CONTÉMoutros objetos (elementos). Esses elementos que estão contidos dentro de outro objeto dependem dele para existir.Eles são criados e destruídos de acordo com o seu container. Um exemplo de container poderia ser uma nota fiscal, eseus elementos seriam seus itens. Não faz sentido existirem itens de nota fiscal sem existir uma nota fiscal onde taisitens estariam contidos. Eles só existem se existir uma nota fiscal da qual eles fazem parte. Se a nota fiscal édestruída, todos os seus itens também são, o que não acontece com a agregação, onde, se uma reunião é destruída,seus participantes continuam existindo, pois podem participar de outras reuniões. A composição, na UML, érepresentada por uma linha com um losango preenchido do lado da classe dona do relacionamento.

Diagrama de classes 6

Especialização ou GeneralizaçãoTambém conhecida como herança, representa as dependências e hierarquias.

Exemplo

Hierarquia dos diagramas da UML, mostrados como um diagrama de classes.

Diagrama de objetos

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

O diagrama de objetos é uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que odiagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos é como se fosse operfil do sistema em um certo momento de sua execução.A mesma notação do diagrama de classes é utilizada com duas exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas de objetos não são tão importantes como os diagramas de classes, mas eles são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão. Diagramas de objetos também são usados como parte dos diagramas de colaboração(passou a se chamar comunicação na uml 2.0), onde a colaboração dinâmica entre os objetos do sistema

Diagrama de objetos 7

são mostrados.

Diagrama de componentes

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

Diagrama de componentes da UML ilustra como as classes deverão se encontrar organizadas através da noção decomponentes de trabalho. Por exemplo, pode-se explicitar, para cada componente, qual das classes que elerepresenta.É utilizado para:• Modelar os componentes do código fonte, do código executável do software.• Destacar a função de cada módulo para facilitar a sua reutilização.•• Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus

relacionamentos.

Conceitos•• Não pertence à categoria de diagramas de interação apresentada pela UML 2.0, o diagrama de

componentes.

• Componentes: Peça física distribuível e substituível de código e que contém elementos que apresentam umconjunto de interfaces requeridas e fornecidas.

• Interface: Diagrama de classes.

Diagrama de instalação 8

Diagrama de instalação

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

O diagrama de instalação (ou diagrama de implantação) é definido pela Linguagem de Modelagem Unificada(Unified Modeling Language - UML), descreve os componentes de hardware e software e sua interação com outroselementos de suporte ao processamento. Representa a configuração e a arquitetura de um sistema em que estarãoligados seus respectivos componentes, sendo representado pela arquitetura física de hardware, processadores etc.

Conceitos• Nó: Representa uma peça física de equipamento na qual o sistema será implantado.• Artefatos: Qualquer pedaço físico de informação usada ou produzida por um sistema.• Especificação de implantação: Especifica um conjunto de propriedades que determina os parâmetros de

execução de um artefato que está instalado em um nó.

Diagrama de pacotes 9

Diagrama de pacotes

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

O Diagrama de pacotes, ou diagrama de módulos, definido pela UML descreve os pacotes ou pedaços do sistemadivididos em agrupamentos lógicos mostrando as dependências entre estes, ou seja, pacotes podem depender deoutros pacotes. Este diagrama é muito utilizado para ilustrar a arquitetura de um sistema mostrando o agrupamentode suas classes. Um pacote representa um grupo de classes (ou outros elementos) que se relaciona com outrospacotes através de uma relação de dependência. Um diagrama de pacotes pode ser utilizado em qualquer fase doprocesso de modelagem e visa organizar os modelos.

Diagrama de estrutura composta 10

Diagrama de estrutura composta

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

O Diagrama de estrutura composta definido a partir da UML 2.0 do RUP destina-se a descrição dosrelacionamentos entre os elementos. Utilizado para descrever a colaboração interna de classes, interfaces oucomponentes para especificar uma funcionalidade.[1]

Conceitos• Colaboração: Define um conjunto de regras e suas ligações para ilustrar uma funcionalidade específica.• Parte (Part): Representa as classes internas que compõem uma classe encapsuladora chamada Container.• Port: a interação entre uma classe e/ou objeto e sua interface.[1][1] Guedes, Gilleanes T.A. (2005), UML 2 Guia Prático, Novatec Editora, p19, ISBN 8575220659

Diagrama de caso de uso 11

Diagrama de caso de uso

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema, que será projetado. SegundoIvar Jacobson, podemos dizer que um caso de uso é um "documento narrativo que descreve a sequência de eventosde um ator que usa um sistema para completar um processo". Um caso de uso representa uma unidade discreta dainteração entre um usuário (humano ou máquina) e o sistema. Um caso de uso é uma unidade de um trabalhosignificante. Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" são todos casos de uso.Cada caso de uso tem uma descrição da funcionalidade que irá ser construída no sistema proposto. Um caso de usopode "usar" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento.Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage como sistema para executar um significante trabalho.

Blocos do diagrama de Caso de Uso

AtorAtor especifica um papel executado por um usuário ou outro sistema que interage com o assunto (sistema). O Atordeve ser externo ao sistema. Um ator deve ter associações exclusivamente para casos de uso, componentes ou classesa exceção que um ator possa herdar o papel de outro.Um ator é representado por um boneco (stick man).

Caso de usoÉ uma especificação de um conjunto de ações executadas por um sistema, que contém um resultado observável.Caso de uso é representado por uma elipse, com o nome do caso de uso dentro ou abaixo. Se há limites do sistema nodiagrama, o caso de uso deve ficar dentro.

Diagrama de caso de uso 12

Relação entre blocos

Herança entre atores

Relação entre casos de usos

Interações entre atores não são mostradas no diagrama de caso de uso.Se esta interação é essencial para uma descrição coerente docomportamento desejado, talvez o limite do sistema ou caso de usodeva ser re-examinado. Alternativamente, interação entre atores podefazer parte de suposições do sistemas.

Generalização de atores

Uma popular relação entre atores é a generalização/especialização. Istoé útil para definir sobreposição de papéis entre atores. A notação é umalinha sólida com um triângulo em direção ao ator mais geral.

Relações entre casos de usos

Include

Uma das formas de interação, um dado caso de uso pode incluir outro.Incluir é uma relação direta entre dois casos de usos, implicando que ocomportamento do caso de uso incluído é inserido no comportamentodo caso de uso inclusor. Esta relação indica uma obrigatoriedade docaso de uso incluir a funcionalidade do caso de uso incluído. Assim,sempre que o primeiro ocorrer obrigatoriamente o incluído ocorrerá.

A notação é uma seta pontilhada para o caso de uso incluído com oestereótipo <<include>>.

Diagrama de caso de uso 13

Extend

Outra forma de interação, um caso de uso pode estender outro. Esta relação indica que o comportamento do caso deuso estendido pode ser ou não inserida no caso de uso extensor. Notas ou restrições podem ser associadas aorelacionamento para ilustrar as condições em que este comportamento será executado.A notação é uma seta pontilhada da extensão para o caso de uso estendido com a etiqueta <<extend>>.

Exemplo

O diagrama de casos de uso corresponde a uma visão externa do sistema e representa graficamente os atores, oscasos de uso, e os relacionamentos entre estes elementos. Ele tem como objetivo ilustrar em um nível alto deabstração quais elementos externos interagem com que funcionalidades do sistema, ou seja, a finalidade de umdiagrama de caso de uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de umsistema e as maneiras segundo as quais eles as utilizam.A notação utilizada para ilustrar atores em um diagrama de caso de uso é a figura de um boneco, com o nome do atordefinido abaixo dessa figura. Vale ressaltar que um ator nem sempre é um ser humano. É qualquer elemento externoque interage com o sistema (pessoas, organizações, outros sistemas, equipamentos).Para representar casos de uso, utilizamos uma elipse, com o nome do caso de uso dentro da elipse, ou abaixo dela.Um relacionamento de comunicação é representado por um segmento de reta ligando ator e caso de uso, sendo queum ator pode estar relacionado à vários casos de uso em um mesmo diagrama.

Diagrama de transição de estados 14

Diagrama de transição de estados

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

Em engenharia de software e eletrônica digital, um diagrama de transição de estados é uma representação doestado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Comisso, o objeto pode passar de um estado inicial para um estado final através de uma transição.

Conceitos• Estado: Condição ou situação durante a vida de um objeto na qual ele satisfaz algumas condições, executa

algumas atividades ou espera por eventos.• Transição: O relacionamento entre dois estados, indicando que o objeto que está no primeiro estado irá passar

para o segundo estado mediante a ocorrência de um determinado evento e em certos casos uma condição.• Condição: causa necessária para que haja a transição de estado. Decorre da ocorrência de um evento ou

circunstância que propicia a transição de estado.• Estado inicial: Estado por onde se começa a leitura de um diagrama de estado.• Estado final: Estado que representa o fim de uma máquina.• Barra de Sincronização: Semelhante a um Fork do Diagrama de atividade.• Estado composto: Estado composto por outras máquinas de estado organizadas em regiões que são executadas

em paralelo.• Sincronização: permite que os relógios de dois ou mais processos paralelos estejam sincronizados em um

determinado momento do processo.• Ação: atividade do sistema que efetua a transição de estado.

Diagrama de transição de estados 15

ExemploUm exemplo simples seria um semáforo (sinal de trânsito).Cada estado corresponde a uma situação que ocorrerá. Quando verde, os carros podem prosseguir na via. Passado umtempo, é acionada a tarefa de mudar para amarelo. Então o semáforo passa de verde para amarelo. Aqui os carrosficam em estado de atenção e já aguardam a próxima transição.O próximo passo é passar para vermelho. Nesse estado, os carros estão parados na via. De vermelho, o próximoestado somente será verde, assim, os carros podem voltar a trafegar na via.

Diagrama de transição de estados de um semáforo Diagrama de transição de estados das estaçõesdo ano

Diagrama de atividade 16

Diagrama de atividade

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

O Diagrama de atividade é um diagrama definido pela Linguagem de Modelagem Unificada (UML), e representaos fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle deuma atividade para outra. Comumente isso envolve a modelagem das etapas seqüenciais em um processocomputacional.Os diagramas de atividade não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ouum fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de produção reversa.

Conceitos• Atividades: Comportamento a ser realizado.•• Sub-atividade: Execução de uma sequência não atómica de atividades.•• Transição: Fluxo de uma atividade para outra.•• Ação: Transformação.•• Decisão: Dependendo de uma condição, mostra as diferentes transições.•• Raia: Diferenciação de unidades organizacionais.•• Bifurcação (Fork): Separa uma transição em várias transições executadas ao mesmo tempo.•• Sincronização (Join): Concatenação de transições vindas do Fork.• Objecto: O objecto da atividade.• Envio de sinal: Transição pra um meio externo, por exemplo, um hardware.•• Recepção de sinal: Recepção do envio.•• Região: Agrupamento de uma ou mais atividades.•• Exceção: Atividades que ocorrerem em decorrência de uma excepção.

Diagrama de atividade 17

ComposiçãoOs diagramas de atividade costumam conter:•• Estado de atividade e estado de ação.•• Transições• Objectos

Estado de atividade e estado de açãoNo fluxo de controle modelado por um diagrama de atividade é onde as atividades acontecem. É possível calcularuma expressão que defina um conjunto de valor de um atributo ou que retorne algum valor. Alternativamente, vocêpoderá chamar uma operação num objeto, enviar um sinal a um objeto ou até criar ou destruir um objeto. Estascomputações atómicas executáveis são chamados estado de ação.Os estados de ação não podem ser decompostos. Além disso, os estados de ação são atómicos, significando que oseventos poderão ocorrer, mas o trabalho de estado de acção não é interrompido. O trabalho de estado de ação égeralmente considerado como ocupando um tempo de execução insignificante.Em contraste, os estados de atividade podem ser decompostos, suas atividades sendo representadas por outrosdiagramas de atividades. Além disso, os estados de atividade são não-atómicos, significando que poderão serinterrompidos e, em geral, são considerados como tomando algum tempo para serem completados.E, vale a pena lembrar que a documentação de softwares é extremamente importante.

Ligações externas• (em inglês) Introdução ao diagrama de atividade do UML 2 [1]

• (em inglês) Guias de uso do Diagrama de Atividade do UML 2 [2]

Referências[1] http:/ / www. agilemodeling. com/ artifacts/ activityDiagram. htm[2] http:/ / www. agilemodeling. com/ style/ activityDiagram. htm

Diagrama de sequência 18

Diagrama de sequência

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

Diagrama de sequência (ou Diagrama de Sequência de Mensagens) é um diagrama usado em UML (UnifiedModeling Language), representando a sequência de processos (mais especificamente, de mensagens passadas entreobjetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos em classesdiferentes, pode ser difícil determinar a sequência global do comportamento. O diagrama de sequência representaessa informação de uma forma simples e lógica.Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram em algum comportamento aolongo do tempo. Ele registra o comportamento de um único caso de uso e exibe os objetos e as mensagens passadasentre esses objetos no caso de uso.Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas para representar interações entre objetosde um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído apartir do Diagrama de Casos de Usos. Primeiro, se define qual o papel do sistema (Use Cases), depois, é definidocomo o software realizará seu papel (Sequência de operações).O diagrama de sequência dá ênfase a ordenação temporal em que as mensagens são trocadas entre os objetos de umsistema. Entende-se por mensagens os serviços solicitados de um objeto a outro, e as respostas desenvolvidas para assolicitações.

Conceitos• Atores: São entidades externas que interagem com o sistema e que solicitamserviços.• Objetos: Representam as instâncias das classes representadas no processo.• Gate: Indica um ponto em que a mensagem pode ser transmitida para dentro ou para fora.• Fragmento: Fragmentos de interação como: Alt (Alternativa), Opt (Opcional), Break (Parar), Loop (Repetição) e

outras.• Linha de vida: As linhas de vida compõem a dimensão vertical.

Diagrama de sequência 19

Exemplo

Diagrama de interatividade

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

Diagramas de interatividade são variações de "diagrama de atividades". Nele, sequências formam um fluxo deatividades, mostrando como elas trabalham em uma sequência de eventos.

Diagrama de interatividade 20

Diagrama de interatividade pode ser visto como um diagrama de atividade em que as atividades são substituídas porpequenos diagramas de sequência ou como diagrama de sequência que usam, de forma complementar, a notação dodiagrama de atividades para mostrar controle de fluxo.

Diagrama de colaboração

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

Um Diagrama de colaboração é definido pelo UML (Unified Modeling Language). O Diagrama de Colaboraçãoexibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens quepodem ser trocadas entre eles. O diagrama de sequência e de colaboração são isomórficos.O diagrama de colaboração mostra, de maneira semelhante ao diagrama de seqüência, a colaboração dinâmica entreos objetos. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de seqüência, mas se aênfase for o contexto do sistema, é melhor dar prioridade ao diagrama de colaboração. O diagrama de colaboração édesenhado como um diagrama de objeto, onde os diversos objetos são mostrados juntamente com seusrelacionamentos.O Diagrama de Colaboração dá ênfase à ordenação estrutural em que as mensagens são trocadas entre os objetosde um sistema.

Conceitos•• Objeto: Instância da classe.•• Vínculo: Ligações entre os objetos.•• Mensagem: Mensagem a um método.

Restrições•• New: um objeto ou um vínculo é criado durante uma interação.•• Destroyed: um objeto ou um vínculo é destruído durante uma interação.•• Transient: um objeto ou um vínculo é criado, destruído e recriado em uma mesma interação.

Diagrama de colaboração 21

Exemplo

Exemplo de Diagrama de Colaboração.

Diagrama de tempo

Diagramas da UML 2.0 editar [2]

Diagramas Estruturais

•• Diagrama de classes•• Diagrama de objetos•• Diagrama de componentes•• Diagrama de instalação•• Diagrama de pacotes•• Diagrama de estrutura

Diagramas Comportamentais

•• Diagrama de Caso de Uso•• Diagrama de transição de estados•• Diagrama de atividade

Diagramas de Interação

•• Diagrama de sequência•• Diagrama de Interatividade•• Diagrama de colaboração ou comunicação•• Diagrama de tempo

O Diagrama de tempo (Timing Diagram) incluído a partir da UML 2.0 apresenta o comportamento dos objetos esua interação em uma escala de tempo, focalizando as condições que mudam no decorrer desse período.

Padrão de projeto de software 22

Padrão de projeto de softwareUm Padrão de Projeto de Software ou Padrão de Desenho de Software, também muito conhecido pelo termooriginal em inglês, Design Pattern, descreve uma solução geral reutilizável para um problema recorrente nodesenvolvimento de sistemas de software orientados a objetos. Não é um código final, é uma descrição ou modelo decomo resolver o problema do qual trata, que pode ser usada em muitas situações diferentes. Os Padrões de Projetonormalmente definem as relações e interações entre as classes ou objetos, sem especificar os detalhes das classes ouobjetos envolvidos, ou seja, estão num nível de generalidade mais alto.Um padrão de projeto define :•• seu nome,•• o problema,•• a solução,•• quando aplicar esta solução e•• suas consequências.Os padrões de projeto :•• visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software - e• estabelecem um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos

sistemas de software.

HistóriaChristopher Alexander[1][2][3] Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e APattern Language, ele estabelece que um padrão deve ter, idealmente, as seguintes características:• Encapsulamento: um padrão encapsula um problema/solução bem definida. Ele deve ser independente,

específico e formulado de maneira a ficar claro onde ele se aplica.• Generalidade: todo padrão deve permitir a construção de outras realizações a partir deste padrão.• Equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relacionada com cada uma

das restrições envolvidas, para cada passo do projeto. Uma análise racional que envolva uma abstração de dadosempíricos, uma observação da aplicação de padrões em artefatos tradicionais, uma série convincente de exemplose uma análise de soluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio.

• Abstração: os padrões representam abstrações da experiência empírica ou do conhecimento cotidiano.• Abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe.• Combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nível podem ser compostos

ou relacionados com padrões que endereçam problemas de nível mais baixo.Além da definição das características de um padrão, Alexander definiu o formato que a descrição de um padrão deveter. Ele estabeleceu que um padrão deve ser descrito em cinco partes:• Nome: uma descrição da solução, mais do que do problema ou do contexto.• Exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo de aplicação.• Contexto: a descrição das situações sob as quais o padrão se aplica.• Problema: uma descrição das forças e restrições envolvidos e como elas interagem.• Solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir artefatos de acordo com o

padrão, freqüentemente citando variações e formas de ajustar a solução segundo as circunstâncias. Incluireferências a outras soluções e o relacionamento com outros padrões de nível mais baixo ou mais alto.

Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um trabalho para a conferência OOPSLA, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk.[4] Nos

Padrão de projeto de software 23

anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento destas idéias.O movimento ao redor de padrões de projeto ganhou popularidade com o livro Design Patterns: Elements ofReusable Object-Oriented Software, publicado em 1995. Os autores desse livro, Erich Gamma, Richard Helm, RalphJohnson e John Vlissides, são conhecidos como a "Gangue dos Quatro" (Gang of Four) ou simplesmente "GoF".Posteriormente, vários outros livros do estilo foram publicados, merecendo destaque Applying UML and Patterns:An Introduction to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto depadrões conhecidos como GRASP (General Responsibility Assignment Software Patterns).

Padrões GoFOs padrões "GoF" são organizados em 3 famílias :• Padrões de criação : relacionados à criação de objetos• Padrões estruturais : tratam das associações entre classes e objetos.• Padrões comportamentais : tratam das interações e divisões de responsabilidades entre as classes ou objetos.Padrões "GoF" organizados nas suas 3 famílias:

Padrões de criação

•• Abstract Factory•• Builder•• Factory Method•• Prototype•• Singleton

Padrões estruturais

•• Adapter•• Bridge•• Composite•• Decorator•• Facade•• Flyweight•• Proxy

Padrões comportamentais

•• Chain of Responsibility•• Command•• Interpreter•• Iterator•• Mediator•• Memento•• Observer•• State•• Strategy•• Template Method•• Visitor

Um padrão "GoF" também é classificado segundo o seu escopo em 2 outros grupos :• Padrões com escopo de classe : definido por relacionamentos de herança e em tempo de compilação.

Padrão de projeto de software 24

• Padrões com escopo de objeto : encontrados no relacionamento entre os objetos definidos em tempo deexecução.

Padrões GRASP[5]

•• Especialista na Informação•• Criador•• Controlador•• Acoplamento Fraco•• Coesão Alta•• Polimorfismo•• Invenção Pura•• Indireção•• Variações Protegidas

CríticasSegundo alguns, alguns 'Padrões de Projeto' são apenas evidências de que alguns recursos estão ausentes em umadeterminada linguagem de programação (Java ou C++ por exemplo). Nesta linha, Peter Norvig demonstra que 16dos 23 padrões do livro 'Design Patterns' são simplificados ou eliminados nas linguagens Lisp ou Dylan, usando osrecursos diretos destas linguagens. [6]

Segundo outros, excessos nas tentativas de fazer o código se conformar aos 'Padrões de Projeto' aumentamdesnecessariamente a sua complexidade. [7]

Bibliografia• Christopher Alexander. Notes on the Synthesis of Form. Estados Unidos: Harvard University Press, 1964. ISBN

0-674-62751-2• Christopher Alexander. The Timeless Way of Building. Estados Unidos: Oxford University Press, 1979. ISBN

0-19-502402-8• Christopher Alexander. A Pattern Language. Estados Unidos: Oxford University Press, 1977. ISBN

0-19-501919-9• Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and

Iterative Development. 1 ed. Estados Unidos: Prentice Hall, 2004. 736 p. ISBN 0-13-148906-2• Gregor Hohpe, Bobby Woolf. Enterprise Integration Patterns: Designing, Building, And Deploying Messaging

Solutions. 1 ed. Estados Unidos: Addinson-Wesley, 2004. 659 p. ISBN 0-321-20068-3• Pablo Dall'Oglio. PHP Programando com Orientação a Objetos [8]: Inclui Design Patterns. 1 ed. São

Paulo: Novatec, 2007. 576 p. ISBN 978-85-7522-137-2• Alexandre Altair de Melo e Mauricio G. F. Nascimento. PHP Profissional [9]: Aprenda a desenvolver sistemas

profissionais orientados a objetos com padrões de projeto. 1 ed. São Paulo: Novatec, 2007. 464 p. ISBN978-85-7522-141-9

[1] O conceito de padrão de projeto foi criado na década de 70 pelo arquitecto Christopher Alexander.[2] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. 1 ed.

Estados Unidos: Addison-Wesley, 1995. ISBN 0-201-63361-2[3] Doug Lea. Christopher Alexander:An Introduction for Object-Oriented Designers (http:/ / g. oswego. edu/ dl/ ca/ ca/ ca. html) (em Inglês).

Página visitada em 18 de abril de 2007.[4] Kent Beck, Ward Cunningham. Using Pattern Languages for Object-Oriented Programs (http:/ / c2. com/ doc/ oopsla87. html) (em Inglês).

Página visitada em 18 de abril de 2007.[5][5] Utilizando UML e Padrões 2ª Edição - Craig Larman

Padrão de projeto de software 25

[6] Norvig, Peter (1998). " Design Patterns in Dynamic Languages (http:/ / www. norvig. com/ design-patterns/ )". {{{booktitle}}}.[7] McConnell, Steve. Code Complete: A Practical Handbook of Software Construction, 2nd Edition. [S.l.: s.n.], 2004. p. 105.[8] http:/ / www. adianti. com. br/ phpoo[9] http:/ / www. novatec. com. br/ livros/ phppro

Ligações externas• Lista de alguns padroes comuns (http:/ / www. mindspring. com/ ~mgrand/ pattern_synopses2. htm) (em inglês)• Página com descrições e exemplos dos padrões GoF (http:/ / www. vincehuston. org/ dp/ ) (em inglês)• Jogo de Memorização Padrões de Projeto - GOF (http:/ / www. questoex. com/ games/ gof/ ) (em português)

Abstract FactoryAbstract Factory é um padrão de projeto de software (também conhecido como design pattern em inglês). Estepadrão permite a criação de famílias de objetos relacionados ou dependentes, através de uma única interface e semque a classe concreta seja especificada.

UtilizaçãoO padrão Abstract Factory pode ser utilizado na implementação de um toolkit que disponibilize controles quefuncionem em diferentes interfaces gráficas, tal como Motif, GTK+ (GNOME) ou Qt (KDE). Estas GUIs possuemdiferentes padrões de controles visuais e, para facilitar a construção de aplicativos que interajam facilmente comdiferentes interfaces gráficas, é interessante que se defina interfaces comuns para acesso aos controles,independentemente da GUI utilizada. Este problema pode ser resolvido através de uma classe abstrata que declarauma interface genérica para criação dos controles visuais e de uma classe abstrata para criação de cada tipo decontrole. O comportamento específico, de cada um dos padrões tecnológicos contemplados, é implementado atravésde uma classe concreta. O aplicativo, ou "cliente", interage com o toolkit através das classes abstratas sem terconhecimento da implementação das classes concretas.Um exemplo bem simplista seria um projeto com interface para Mobile e para Desktop, uma boa opção parareaproveitar os mesmos controles de interface seria criar pacotes com classes abstratas e os pacotes com as classesconcretas implementando apenas as diferenças. Esse padrão também se aplica na padronização de ambientes, porexemplo, tamanhos de botões, fontes, cores de fundo, largura de bordas. Com isso e havendo uma política que exijaque os desenvolvedores usem essas classes em vez das nativas da linguagem, ajudará a padronizar a aparência ecomportamento das aplicações.

ExemploNeste exemplo, a classe abstrata WidgetFactory possui duas especializações: MotifWidgetFactory para widgetsMotif e QtWidgetFactory para widgets Qt. Essas especializações são classes concretas capazes de "produzir" oselementos da interface gráfica. O cliente do toolkit obtém os elementos gráficos de que necessita através da classe(interface) WidgetFactory sem ter conhecimento das classes concretas. Da mesma maneira, o cliente somenteinterage com as interfaces que representam os elementos produzidos pela Abstract Factory (no exemplo, a classeJanela e a classe Botao).

Abstract Factory 26

Estrutura

Exemplo de Diagrama em UML para o Padrão Abstract Factory.

Código em Java

Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima. Por uma questão desimplicidade, o código relacionado às janelas é omitido.

abstract class WidgetFactory

{

public static WidgetFactory obterFactory()

{

if( Configuracao.obterInterfaceGraficaAtual() ==

Configuracao.MotifWidget )

{

return new MotifWidgetFactory();

}

else

{

return new QtWidgetFactory();

}

}

public abstract Botao criarBotao();

}

class MotifWidgetFactory extends WidgetFactory

{

public Botao criarBotao() {

Abstract Factory 27

return new BotaoMotif();

}

}

class QtWidgetFactory extends WidgetFactory

{

public Botao criarBotao() {

return new BotaoQt();

}

}

abstract class Botao

{

public abstract void desenhar();

}

class BotaoMotif extends Botao

{

public void desenhar() {

System.out.println("Eu sou um botao Motif!");

}

}

class BotaoQt extends Botao

{

public void desenhar() {

System.out.println("Eu sou um botao Qt!");

}

}

public class Cliente

{

public static void main(String[] args)

{

WidgetFactory factory = WidgetFactory.obterFactory();

Botao botao = factory.criarBotao();

botao.desenhar();

}

}

Este exemplo imprimiria na tela o texto "Eu sou um botao Motif!" ou "Eu sou um botao Qt!" dependendo do valorretornado pelo método Configuracao.obterInterfaceGraficaAtual(), que descobre a interfacegráfica, Motif ou Qt, utilizada pelo sistema.

Abstract Factory 28

Código em VB.NET

Public MustInherit Class WidgetFactory

Shared Function obterFactory() As WidgetFactory

If Configuracao.obterInterfaceGraficaAtual() Is

Configuracao.MotifWidget Then

Return New MotifWidgetFactory()

Else

Return New QtWidgetFactory()

End If

End Function

Public MustOverride Function criarBotao() As Botao

End Class

Public Class MotifWidgetFactory

Inherits WidgetFactory

Public Overrides Function criarBotao() As Botao

Return New BotaoMotif

End Function

End Class

Public Class QtWidgetFactory

Inherits WidgetFactory

Public Overrides Function criarBotao() As Botao

Return New BotaoQt

End Function

End Class

Public MustInherit Class Botao

Public MustOverride Sub desenhar()

End Class

Public Class BotaoMotif

Inherits Botao

Public Overrides Sub desenhar()

Console.Out.WriteLine("Eu sou um botão Motif.")

End Sub

End Class

Abstract Factory 29

Public Class BotaoQt

Inherits Botao

Public Overrides Sub desenhar()

Console.Out.WriteLine("Eu sou um botão Qt.")

End Sub

End Class

Public Class Client

Public Shared Sub main()

Dim factory As WidgetFactory = WidgetFactory.obterFactory

Dim botao As Botao = factory.criarBotao

botao.desenhar()

End Sub

End Class

Padrões relacionados•• Factory Method•• Prototype•• Singleton

Bibliografia• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable

Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2• Steven John Metsker. Padrões de Projeto Em Java. 1 ed. Brasil: Bookman, 2004. ISBN 85-363-0411-1

Builder 30

BuilderBuilder é um padrão de projeto de software que permite a separação da construção de um objeto complexo da suarepresentação, de forma que o mesmo processo de construção possa criar diferentes representações.

Estrutura

Diagrama UML da estrutura do padrão Builder

O padrão Builder, da forma como foidescrito no livro Design Patterns:Elements of Reusable Object-OrientedSoftware, contém os seguinteselementos:

• director — constrói um objetoutilizando a interface do builder;

• builder — especifica uma interfacepara um construtor de partes doobjeto-produto;

• concrete builder — define uma implementação da interface builder, mantém a representação que cria e forneceinterface para recuperação do produto;

• product — o objeto complexo acabado de construir. Inclui classes que definem as partes constituintes.

UtilizaçãoO padrão Builder pode ser utilizado em uma aplicação que converte o formato RTF para uma série de outrosformatos e que permite a inclusão de suporte para conversão para outros formatos, sem a alteração do código fontedo leitor de RTF.A implementação da solução para esse problema pode ser realizada através de uma classe de leitura (director)associada a uma classe capaz de converter o formato RTF para outra representação (builder). O objeto da classe deleitura lê cada token do texto e executa o método apropriado no objeto de conversão, de acordo com tipo do token. Aclasse de conversão possui um método para cada tipo de token, incluindo os caracteres comuns, parágrafos, fontes eetc. Para cada formato de texto suportado é criada uma classe de conversão especializada (concrete builder). Umconversor para formato ASCII, por exemplo, poderia ignorar qualquer requisição para converter tokens que nãofossem caracteres comuns. Um conversor para o formato PDF, por outro lado, iria processar qualquer requisição parapoder converter o estilo, além do texto.

Comparação com o Abstract FactoryO padrão Builder é muitas vezes comparado com o padrão Abstract Factory pois ambos podem ser utilizados para aconstrução de objetos complexos. A principal diferença entre eles é que o Builder constrói objetos complexos passoa passo e o Abstract Factory constrói famílias de objetos, simples ou complexos, de uma só vez.

ExemploNeste exemplo, o método lerRTF() (classe LeitorRTF) percorre uma lista com os tokens encontrados no texto de entrada (formato RTF) e, para cada tipo de token, chama um método do objeto de tipo ConversorTexto. Dependendo do formato escolhido para o texto de destino, será escolhida uma implementação da classe ConversorTexto: ConversorPDF, ConversorTeX ou ConversorASCII. Cada uma destas classes implementa os métodos de acordo com as características do formato relacionado. A classe ConversorASCII não

Builder 31

implementa os métodos converteParagrafo() e converteFonte() pois este formato (ASCII) não possuielementos de estilo.

Diagrama

Exemplo de Diagrama em UML para o Padrão Builder.

Código

Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima.

abstract class ConversorTexto {

public void converterCaractere(char c) {

// vazio

}

public void converterParagrafo() {

// vazio

}

public void converterFonte(Fonte f) {

// vazio

}

}

class ConversorPDF extends ConversorTexto {

public void converterCaractere(char c) {

System.out.print("Caractere PDF");

}

public void converterParagrafo() {

System.out.print("Parágrafo PDF");

Builder 32

}

public void converterFonte(Fonte f) {

System.out.print("Fonte PDF");

}

}

class ConversorTeX extends ConversorTexto {

public void converterCaractere(char c) {

System.out.print("Caractere Tex");

}

public void converterParagrafo() {

System.out.print("Paragrafo Tex");

}

public void converterFonte(Fonte f) {

System.out.print("Fonte Tex");

}

}

class ConversorASCII extends ConversorTexto {

public void converterCaractere(char c) {

System.out.print("Caractere ASCII");

}

}

class LeitorRTF {

private ConversorTexto conversor;

LeitorRTF(ConversorTexto c) {

this.conversor = c;

}

public void lerRTF() {

List<Token> tokens = obterTokensDoTexto();

for (Token t : tokens) {

if (t.getTipo() == Token.Tipo.CARACTERE) {

conversor.converterCaractere(t.getCaractere());

}

if (t.getTipo() == Token.Tipo.PARAGRAFO) {

conversor.converterParagrafo();

}

if (t.getTipo() == Token.Tipo.FONTE) {

Builder 33

conversor.converterFonte(t.getFonte());

}

}

}

}

public class Cliente {

public static void main(String[] args) {

ConversorTexto conversor;

if (args[0].equals("pdf")) {

conversor = new ConversorPDF();

} else if (args[0].equals("tex")) {

conversor = new ConversorTeX();

} else {

conversor = new ConversorASCII();

}

LeitorRTF leitor = new LeitorRTF(conversor);

leitor.lerRTF();

}

}

A classe Cliente determina, através do parâmetro passado ao programa Java ("pdf" para formato PDF, "tex" para Texe qualquer outro para ASCII), qual das classes derivadas de ConversorTexto irá utilizar na construção da classeLeitorRTF.

Padrões relacionados•• Abstract Factory•• Composite

Bibliografia• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable

Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2

Factory Method 34

Factory MethodFactory Method, na ciência da computação, é um padrão de projeto de software (design pattern, em inglês) quedefine uma classe para criação de um objeto, mas permite que as subclasses escolham qual classes instanciar. Ofactory method permite delegar a instanciação para as subclasses.

Estrutura

Diagrama UML da estrutura do padrão Factory Method

O padrão Factory Method, da formacomo foi descrito no livro DesignPatterns: Elements of ReusableObject-Oriented Software, contém osseguintes elementos:

• Creator — declara o factory method(método de fabricação) que retornao objeto da classe Product(produto). Este elemento tambémpode definir uma implementaçãobásica que retorna um objeto deuma classe ConcreteProduct (produto concreto) básica;

• ConcreteCreator — sobrescreve o factory method e retorna um objeto da classe ConcreteProduct;• Product — define uma interface para os objectos criados pelo factory method;• ConcreteProduct — uma implementação para a interface Product.

UtilizaçãoEste padrão é muito utilizado em frameworks para definir e manter relacionamentos entre objetos. O frameworkSpring, dependendo da configuração, pode utilizar um Factory Method para criar os seus beans.[1]

Este padrão pode ser utilizado na construção de um framework que suporta aplicações que apresentam múltiplosdocumentos ao usuário. Normalmente este tipo de aplicação manipula um número variável de formatos dedocumento e, por isso, este framework deve ser flexível o bastante para suportar qualquer formato. Uma solução paraeste problema poderia disponibilizar, no framework, o código para alguns dos formatos mais utilizados. Mas, naprática, esta solução seria uma implementação pouco flexível, e até mesmo incompleta, já que é custoso implementaros mais variados formatos. O padrão Factory Method propõe uma solução que deixa para o cliente (a implementaçãoda aplicação) a tarefa de suportar os formatos necessários e para o framework o papel de definição de uma abstraçãoque oferece uma interface única para criação de documentos.Este framework seria baseado em duas classes abstratas, que representam a Aplicação e o Documento. O cliente doframework fornece um par de classes concretas, uma aplicação e o respectivo documento, para cada um dos formatosde Documento suportados pela Aplicação. Se for necessário apresentar um documento que suporte desenho, porexemplo, o cliente deve disponibilizar as classes AplicacaoDesenho e DocumentoDesenho (supondo que osufixo "Desenho" indique classes que suportam esta funcionalidade).O objetivo do Factory Method está em diversas classes que implementam a mesma operação, retornarem o mesmotipo abstrato, mas internamente instanciam diferentes classes que o implementam. Com o Factory Method o criadordo objeto faz uma escolha de qual classe instanciar para o cliente. Para ser um Factory Method o método precisaretornar uma interface ou uma classe abstrata e, dependendo das necessidades do cliente, criar um objetodeterminado como retorno. Um exemplo clássico do Factory Method são os iteradores tanto em Java como em .NET.

Factory Method 35

ExemploNeste exemplo, uma aplicação, que é construída através de um framework baseado no padrão Factory Method,suporta a criação de documentos do tipo MeuDocumento. O framework é constituído pelas classes abstratasAplicacao e Documento. A aplicação disponibiliza as classes concretas MinhaAplicacao eMeuDocumento. A classe MinhaAplicacao é uma implementação da abstração definida pela classeAplicacao.

Diagrama

Exemplo de Diagrama em UML para o Padrão Factory Method.

A chave deste padrão está na declaração do método abstrato criaDocumento, da classe Aplicacao, e na suautilização pelo método novoDocumento. Este arranjo permite que o método novoDocumento crie documentossem conhecer os detalhes de implementação, existentes em cada tipo de documento suportado pela aplicação. Istopermite que a implementação do método criaDocumento (neste exemplo situada na classe MinhaAplicacao)varie livremente, para atender os diversos formatos possivelmente suportados, sem que seja necessário modificar ocódigo das classes abstratas.

Código em Java

Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima.

/**

* Abstração de uma Aplicação capaz de manipular

* documentos.

*/

abstract class Aplicacao {

private Documento doc;

Factory Method 36

/**

* Abstração do Factory Method

*/

abstract Documento criaDocumento();

void novoDocumento() {

this.doc = this.criaDocumento();

}

void abrirDocumento() {

this.doc.abrir();

}

}

/**

* Abstração de um Documento.

*/

abstract class Documento {

void abrir() {

System.out.println("Documento:Abrir documento!");

}

void fechar() {

System.out.println("Documento:Fechar documento!");

}

void gravar() {

System.out.println("Documento:Gravar documento!");

}

}

/**

* Esta classe concreta contém a implementação

* de uma aplicação capaz de manipular documentos

* do tipo MeuDocumento.

*/

class MinhaAplicacao extends Aplicacao {

/**

* Uma implementação do Factory Method. Este método é

* especializado na criação de documentos do tipo MeuDocumento

*/

Documento criaDocumento() {

return new MeuDocumento();

}

}

Factory Method 37

/**

* Esta classe concreta contém a implementação

* de um tipo de documento específico.

*/

class MeuDocumento extends Documento {

}

Código em VB.NET

O mesmo exemplo acima, em linguagem Visual Basic .NET.

Public MustInherit Class Aplicacao

Private doc As Documento

MustOverride Function criaDocumento() As Documento

Sub novoDocumento()

Me.doc = Me.criaDocumento

End Sub

Sub abrirDocumento()

Me.doc.abrir()

End Sub

End Class

Public MustInherit Class Documento

Sub abrir()

Console.WriteLine("Documento:Abrir documento!")

End Sub

Sub fechar()

Console.WriteLine("Documento:Fechar documento!")

End Sub

Sub gravar()

Console.WriteLine("Documento:Gravar documento!")

End Sub

End Class

Public Class MinhaAplicacao

Inherits Aplicacao

Public Overrides Function criaDocumento() As Documento

Factory Method 38

Return New MeuDocumento

End Function

End Class

Public Class MeuDocumento

Inherits Documento

End Class

Código em C#

O mesmo exemplo acima, em linguagem C#

public abstract class Aplicacao

{

private Documento doc;

Documento criaDocumento();

void novoDocumento()

{

this.doc = this.criaDocumento();

}

void abrirDocumento()

{

this.doc.abrir();

}

}

public abstract class Documento

{

void abrir()

{

Console.WriteLine("Documento:Abrir documento!");

}

void fechar()

{

Console.WriteLine("Documento:Fechar documento!");

}

void gravar()

{

Console.WriteLine("Documento:Gravar documento!");

Factory Method 39

}

}

public class MinhaAplicacao : Aplicacao

{

public Documento criaDocumento()

{

return new MeuDocumento();

}

}

public class MeuDocumento : Documento

{

}

Padrões relacionados•• Abstract Factory•• Template Method•• Prototype[1] Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark

Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans. The SpringFramework - Reference Documentation (http:/ / www. springframework. org/ docs/ reference/ beans.html#beans-factory-class-instance-factory-method) (em Inglês). Página visitada em 16 de maio de 2007.

Bibliografia• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable

Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2• Steven John Metsker. Padrões de Projeto Em Java. 1 ed. Brasil: Bookman, 2004. ISBN 85-363-0411-1

Prototype 40

PrototypePrototype, na ciência da computação, é um padrão de projeto de software (design pattern, em inglês) que permite acriação de objetos a partir de um modelo original, ou protótipo.

Estrutura

Diagrama UML da estrutura do padrão Prototype

O padrão Prototype, da forma como foidescrito no livro Design Patterns:Elements of Reusable Object-OrientedSoftware, contém os seguinteselementos:

• prototype — uma classe que declarauma interface para objetos capazesde clonar a si mesmo;

• prototype concreto —implementação de um prototype;

• cliente — cria um novo objetoatravés de um prototype que é capazde clonar a si mesmo.

Efetivamente, cada objeto é, ele próprio, um factory especializado em construir objetos iguais a si mesmo. O padrãoPrototype é utilizado freqüentemente em linguagens estaticamente tipadas como C++ e Java, e menosfreqüentemente utilizadas em linguagens dinamicamente tipadas como Smalltalk.

O padrão Prototype exige a implementação de uma operação de clonagem em cada uma das classes concretas doprotótipo. Esta tarefa pode ser inconveniente, no caso do reaproveitamento de classes pré-existentes que nãopossuem tal operação, ou mesmo complexa, se for considerada a possibilidade de existirem referências circulares nosatributos de um objeto (um objeto possui um atributo que referência um objeto que, por sua vez, referência o objetooriginal).

UtilizaçãoO padrão Prototype pode ser utilizado em sistemas que precisam ser independentes da forma como os seuscomponentes são criados, compostos e representados. O padrão Prototype pode ser útil em sistemas com as seguintescaracterísticas:• sistemas que utilizam classes definidas em tempo de execução;• sistemas que utilizam o padrão Abstract Factory para criação de objetos. Neste caso, a hierarquia de classes pode

se tornar muito complexa e o padrão Prototype pode ser uma alternativa mais simples, por realizar a mesma tarefacom um número reduzido de classes;

•• sistemas que possuem componentes cujo estado inicial possui poucas variações e onde é convenientedisponibilizar um conjunto pré-estabelecido de protótipos que dão origem aos objetos que compõem o sistema.

Quando utiliza o framework Spring, por exemplo, um desenvolvedor pode configurar um JavaBean como"prototype". Esta configuração faz com que cada uma das referências a um JavaBean aponte para uma instânciadiferente. O comportamento padrão, ou singleton, define que todas as referências a um JavaBean apontem para amesma instância de uma classe.[1]

Prototype 41

ExemploNeste exemplo é mostrado uma hierarquia de classes representando documentos de formato ASCII e PDF que sãocriados através da classe Cliente. A partir de duas instâncias prototípicas, ascii e pdf, o métodocriarDocumento cria clones de documentos de acordo com o tipo desejado. A tarefa de realizar a criação dainstância é implementada na classe Documento e herdada por suas classes filhas, ASCII e PDF.

Diagrama

Exemplo de Diagrama em UML para o Padrão Prototype.

Código

Este código, escrito na linguagem Java, mostra a implementação do diagrama mostrado acima.

abstract class Documento implements Cloneable {

protected Documento clone() {

Object clone = null;

try {

clone = super.clone();

} catch (CloneNotSupportedException ex) {

ex.printStackTrace();

}

return (Documento) clone;

}

}

class ASCII extends Documento {

}

class PDF extends Documento {

}

Prototype 42

class Cliente {

static final int DOCUMENTO_TIPO_ASCII = 0;

static final int DOCUMENTO_TIPO_PDF = 1;

private Documento ascii = new ASCII();

private Documento pdf = new PDF();

public Documento criarDocumento(int tipo) {

if (tipo==Cliente.DOCUMENTO_TIPO_ASCII) {

return ascii.clone();

} else {

return pdf.clone();

}

}

}

Observação: Na linguagem Java, a interface Cloneable não possui métodos e é utilizada apenas para indicar queo método Object.clone() pode realizar uma cópia, atributo por atributo, das instâncias de uma classe. [2]

Neste exemplo, a implementação da cópia da instância é delegada ao método clone da super classe Object (Aclasse raiz da hierarquia de classes da linguagem Java). Se fosse necessário, as classes Documento, ASCII ouPDF implementariam esse método para refletir algum comportamento específico.

Padrões relacionados•• Abstract Factory•• Composite•• Decorator[1] Rod Johnson, Juergen Hoeller, Alef Arendsen, Colin Sampaleanu, Rob Harrop, Thomas Risberg, Darren Davison, Dmitriy Kopylenko, Mark

Pollack, Thierry Templier, Erwin Vervaet, Portia Tung, Ben Hale, Adrian Colyer, John Lewis, Costin Leau, Rick Evans. The SpringFramework - Reference Documentation (http:/ / www. springframework. org/ docs/ reference/ beans. html#beans-factory-scopes-prototype)(em Inglês). Página visitada em 13 de junho de 2007.

[2] Sun Microsystems. JavaTM 2 Platform Std. Ed. (http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ api/ java/ lang/ Cloneable. html) (em inglês).Página visitada em 13 de junho de 2007.

Bibliografia• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable

Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0-201-63361-2

Singleton 43

Singleton

Diagrama UML de uma classe singleton.

Singleton, é um padrão de projeto de software (do inglês DesignPattern). Este padrão garante a existência de apenas uma instância deuma classe, mantendo um ponto global de acesso ao seu objeto.

Nota linguística: O termo vem do significado em inglês quando seresta apenas uma carta nas mãos, num jogo de baralho.

Muitos projetos necessitam que algumas classes tenham apenas umainstância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementaruma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que éacessível unicamente através da classe singleton.

Onde UsarQuando você necessita de somente uma instância da classe, por exemplo, a conexão com banco de dados, vamossupor que você terá que chamar diversas vezes a conexão com o banco de dados em um código na mesma execução,se você instanciar toda vez a classe de banco, haverá grande perda de desempenho, assim usando o padrão singleton,é garantida que nesta execução será instânciada a classe somente uma vez. Lembrando que este pattern é consideradopor muitos desenvolvedores um anti-pattern, então, cuidado onde for utilizá-lo. [1]

Exemplos

Em JavaSegue um exemplo em Java de uma classe Singleton.

public final class MySingleton {

// Instancia estática privada que será acessada

private static final MySingleton INSTANCE = new MySingleton();

// Construtor privado. Suprime o construtor público padrao.

private MySingleton() {

// Operações de inicialização da classe

}

// Método público estático de acesso único ao objeto!

public static synchronized MySingleton getInstance(){

return INSTANCE;

}

}

Singleton 44

Em C++Segue um exemplo em C++ da implementação de uma classe Singleton:

class MyClass

{

private:

// atributo estático da "instância única"

static MyClass *instance = 0;

//construtor privado, não pode ser utilizado fora da classe

MyClass() {}

public:

// Função-membro que retorna sempre a mesma instância do objeto

static MyClass& getInstance()

{

if (!instance) instance = new MyClass();

return *instance;

}

};

Em DelphiAbaixo segue um exemplo de como implementar uma classe Singleton:

interface

type

TSingleton= class

private

class var FInstance: TSingleton;

class function GetInstance: TSingleton; static;

public

class property Instance : TSingleton read GetInstance;

end;

implementation

class function TSingleton.GetInstance: TSingleton;

begin

If FInstance = nil Then

FInstance := TSingleton.Create();//objeto instanciado através do

Finstance

Result := FInstance;//retorna o objeto

end;

Em PHP<?php

class Singleton

{

private static $_instance;

// Evita que a classe seja instanciada publicamente

Singleton 45

private function __construct() { }

// Evita que a classe seja clonada

private function __clone() { }

public static function getInstance()

{

if (!isset(self::$_instance)) { // Testa se há instância

definifa na propriedade, caso sim, a classe não será instanciada

novamente.

self::$_instance = new self; // o new self cria uma

instância da própria classe à própria classe.

}

return self::$_instance;

}

}

Em Rubyclass Classe

include Singleton

end

Em VB.NET Public Class MyClass

Private Shared _instancia As MyClass

Private Shared objetoSincronia As New Object

Private Sub New()

End Sub

Public Shared Function getInstancia() As MyClass

If _instancia Is Nothing Then

SyncLock objetoSincronia

If _instancia Is Nothing Then _instancia = New MyClass

End SyncLock

End If

Return _instancia

End Function

End Class

Em ActionScript 3package{

public class ExemploSingleton {

private static var instance:ExemploSingleton;

public function

Singleton 46

ExemploSingleton(enforcer:SingletonEnforcer) : void {

if (enforcer == null)

throw new Error("Só pode haver uma instância de

ExemploSingleton");

}

public static function getInstance() : ExemploSingleton {

if (instance == null)

instance = new ExemploSingleton( new

SingletonEnforcer );

return instance;

}

}

}

//Para bloquear o acesso ao constructor.

class SingletonEnforcer {

}

Em c# (utilizando Generics)public sealed class GenericSingleton<T> where T : class, new()

{

private static T _instance;

public static T GetInstance()

{

lock (typeof(T))

{

if (_instance == null)

_instance = new T();

return _instance;

}

}

}

// Teste do padrão Singleton

public class Car { public int Color { get; set; } }

public class Person { public string Name { get; set; } }

class Program

{

static void Main(string[] args)

{

Car car = GenericSingleton<Car>.GetInstance();

car.Color = 1;

Person per = GenericSingleton<Person>.GetInstance();

Singleton 47

per.Name = "John";

Car car2 = GenericSingleton<Car>.GetInstance();

car.Color = 2;

}

}

Obs: Esta solução não impede a criação de múltiplas instâncias das classes Car e Person. Como a classe genéricaGenericSingleton obriga que as classes passadas no parâmetro T tenham um construtor público, é possívelcriar instâncias em qualquer trecho de código através de construções do tipo: Car car3 = new Car();.

Benefícios•• Permite o controle sobre como e quando os clientes acessam a instância.• Várias classes singleton podem obedecer uma mesma interface, permitindo assim que um singleton em particular

seja escolhido para trabalhar com uma determinada aplicação em tempo de execução.• Com apenas uma implementação interna do singleton pode-se fazer com que o singleton crie um número

controlado de instâncias.•• É mais flexível que métodos estáticos por permitir o polimorfismo.[1] Quando você necessita de somente uma instância da classe, por exemplo, a conexão com banco de dados, vamos supor que vc terá que

chamar diversas vezes a conexão com o banco de dados em um código na mesma execução, se você instanciar toda vez a classe de banco,haverá grande perda de desempenho, assim usando o padrão singleton, é garantida que nesta execução será instânciada a classe somente umavez. Lembrando que este pattern é considerado por muitos desenvolvedores um anti-pattern, então, cuidado onde for utilizá-lo. Clube daProgramação - Sobre design patterns: Singleton | url: http:/ / www. clubedaprogramacao. com'' (http:/ / www. clubedaprogramacao. com/forum/ index. php?/ topic/ 872-sobre-design-patterns-1ª-aula-singleton/ )

Aula sobre design patterns - Singleton | url: http:/ / www. clubedaprogramacao. com (http:/ / www.clubedaprogramacao. com/ forum/ index. php?/ topic/ 872-sobre-design-patterns-1ª-aula-singleton/ )Exemplo do uso de Singleton em aplicativo JSE | url: http:/ / www. patternizando. com. br (http:/ / www.patternizando. com. br/ 2011/ 01/ singleton-na-pratica-criando-apenas-um-jinternalframe-por-classe/ )Singleton | url: http://www.dsc.ufcg.edu.br[[bg:Сек (шаблон) (http:/ / www. dsc. ufcg. edu. br/ ~jacques/ cursos/map/ html/ pat/ singleton. htm/ )]

Adapter 48

AdapterAdapter, também conhecido como Wrapper, é um padrão de projeto de software (do inglês design pattern). Estepadrão é utilizado para 'adaptar' a interface de uma classe. O Adapter permite que classes com interfacesincompatíveis possam interagir.Adapter permite que um objeto cliente utilize serviços de outros objetos com interfaces diferentes por meio de umainterface única.

Bridge (padrão de projeto de software) 49

Bridge (padrão de projeto de software)Bridge é um padrão de projeto de software, ou design pattern em inglês, utilizado quando é desejável que umainterface (abstração) possa variar independentemente das suas implementações.Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas. Neste sistema sãoencontrados diversos tipos de janelas, como ícones, diálogos, etc. Estas janelas formam uma hierarquia que contémuma abstração das janelas (classe base). Normalmente, a portabilidade seria obtida criando-se especializações dostipos de janelas para cada uma das plataformas suportadas. O problema com essa solução reside na complexidade dahierarquia gerada e na dependência de plataforma que existirá nos clientes do sistema.Através do padrão Bridge, a hierarquia que define os tipos de janelas é separada da hierarquia que contém aimplementação. Desta forma todas as operações de Janela são abstratas e suas implementações são escondidas dosclientes.

ExemploO diagrama mostra a solução para o problema citado. Temos duas hierarquias de classes relacionadas: a hierarquiade tipos de janelas (Janela, Icone e Dialogo) e a de implementação nas plataformas suportadas (JanelaImpl,XWindowImpl e MSWindowImpl). O relacionamento entre as interfaces, Janela e JanelaImpl, é a "ponte" que"desacopla" a interface da implementação. Para que um ícone seja desenhado, faz-se uma chamada ao métodoDesenhaBorda() que por sua vez realiza "n" chamadas ao método DesenhaLinha() da classe XWindowImpl ouMSWindowImpl, dependendo da plataforma desejada.

Exemplo de Diagrama em UML para o Padrão Bridge.

Composite 50

CompositeComposite é um padrão de projeto de software utilizado para representar um objeto que é constituído pelacomposição de objetos similares a ele. Neste padrão, o objeto composto possui um conjunto de outros objetos queestão na mesma hierarquia de classes a que ele pertence. O padrão composite é normalmente utilizado pararepresentar listas recorrentes - ou recursivas - de elementos. Além disso, esta forma de representar elementoscompostos em uma hierarquia de classes permite que os elementos contidos em um objeto composto sejam tratadoscomo se fossem um único objeto. Desta forma, todos os métodos comuns às classes que representam objetosatômicos da hierarquia poderão ser aplicáveis também ao conjunto de objetos agrupados no objeto composto.

AplicaçãoUtilizado sempre que é necessário representar elementos que são compostos por outros elementos similares.Por exemplo, em interfaces gráficas um elemento gráfico pode ser constituído pela composição de vários outroselementos gráficos. Uma janela pode conter um ou mais ícones, uma caixa de texto e vários outros elementosgráficos - até mesmo outra janela. Considerando que uma determinada hierarquia de classes indicasseElementoGráfico como a super-classe comum a todas classes que representassem os elementos gráficos atômicos, aclasse Janela seria representada como uma classe que contém zero (0) ou mais elementos gráficos. Veja diagrama aseguir.Outro exemplo clássico é o de gramáticas utilizadas para definir linguagens de programação. Se utilizarmos umahierarquia de classes para representar os comandos da linguagem, supondo que a super-classe seria Comando,teríamos uma classe para o comando de atribuição, outro para, digamos, o comando While, outra para o comandocomposto - comando que é constituído por uma lista de outros comandos normalmente delimitados por indicadorescomo { e } ou palavras reservadas como begin e end - e assim por diante. Pois bem, comandos que podem conteroutros comandos - como o comando composto ou o comando While do exemplo - normalmente serão representadosutilizando-se o padrão composite. Também é apresentado um diagrama a seguir que representa esta hierarquia.É importante observar que será responsabilidade do objeto composto, para cada método a ser aplicável à lista deobjetos que possui, implementá-lo de maneira repetitiva. Por exemplo, no caso da hierarquia de elementos gráficosexemplificada, suponha que um objeto cliente ative o método desenha() de um objeto do tipo Janela. Estemétodo deverá ser capaz de ativar os métodos desenha() de cada um dos objetos que ele contém. Desta maneiraserá possível interagir com uma composição de objetos da mesma forma que se interage com objetos individuais.

EstruturaO diagrama abaixo mostra a estrutura de classes do exemplo de componentes gráficos apresentada acima.

Hierarquia de Classes para Elemento Gráfico

Ressalte-se aí que a estrutura do padrão composite é sempre composta por uma estrutura auto-referenciada como ado diagrama. O próximo diagrama representa a hierarquia de classes do exemplo de comandos da linguagem deprogramação hipotética apresentada.

Composite 51

Hierarquia de Classes para Comando

Padrões relacionados•• Decorator•• Flyweight•• Iterator•• Visitor pattern

Bibliografia• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable

Object-Oriented Software. 1 ed. Estados Unidos da América: Addison-Wesley, 1995. ISBN 0201633612

DecoratorDecorator, ou Wrapper, é um padrão de projeto de software que permite adicionar um comportamento a um objetojá existente em tempo de execução, ou seja, agrega dinamicamente responsabilidades adicionais a um objeto.[1]

Intenção•• Acrescentar responsabilidades a um objeto dinamicamente•• Prover alternativa flexível ao uso de subclasses para se estender a funcionalidade de uma classe

Motivação•• Objeto usado possui as funcionalidades básicas, mas é necessário adicionar funcionalidades adicionais a ele que

podem ocorrer antes ou depois da funcionalidade básica•• Funcionalidades devem ser adicionadas em instancias individuais e não na classe.

Consequências•• Mais flexibilidade do que herança

•• Adição ou remoção de responsabilidades em tempo de execução•• Adição da mesma propriedade mais de uma vez

•• Evita o excesso de funcionalidades nas classes•• Decorator e seu componente não são idênticos

•• Comparações tornam-se mais complexas•• Resulta em um design que tem vários pequenos objetos, todos parecidos

Decorator 52

Aplicabilidade•• Acrescentar ou remover responsabilidades a objetos individuais dinamicamente, de forma transparente•• Evitar a explosão de subclasses para prover todas as combinações de responsabilidades

Padrões relacionados• Adapter: Decorator muda comportamento; Adapter muda interface• Composite: Pode ser visto como um composite com um único componente; porém, não tem intenção de agregar

objetos• Strategy: Decorator envolve o objeto; Strategy muda o funcionamento interno[1] SILVA, V. T. Padrões de Design. Disponível em: http:/ / www. lia. ufc. br/ ~eti/ menu/ modulos/ _Pattern/ aulaDesignPatternsI4pp. pdf .

Acessado em Janeiro de 2005.[ligação inativa]

FaçadeEm padrões de projeto de software, um façade (fachada em francês) é um objeto que disponibiliza uma interfacesimplificada para uma das funcionalidades de uma API, por exemplo. Um façade pode:• tornar uma biblioteca de software mais fácil de entender e usar;•• tornar o código que utiliza esta biblioteca mais fácil de entender;•• reduzir as dependências em relação às características internas de uma biblioteca, trazendo flexibilidade no

desenvolvimento do sistema;•• envolver uma interface mal desenhada, com uma interface melhor definida.Um façade é um padrão de projeto (design pattern) do tipo estrutural. Os façades são muito comuns em projetoorientados a objeto. Por exemplo, a biblioteca padrão da linguagem Java contém dúzias de classes paraprocessamento do arquivo fonte de um caractere, geração do seu desenho geométrico e dos pixels que formam estecaractere. Entretanto, a maioria dos programadores Java não se preocupam com esses detalhes, pois a bibliotecacontém as classes do tipo façade (Font e Graphics) que oferecem métodos simples para as operaçõesrelacionadas com fontes.

Façade 53

Estrutura

Client1, Client2

Usuários da APIFaçade

Define uma interface para os packages 1, 2 e 3, isolando-os do resto da aplicação.

ExemploEsse é um exemplo abstrato de como um cliente ("você") interage com um façade (o "computador") para um sistemacomplexo (as partes internas do computador como o processador e o disco rígido).

/* Complex parts */

class CPU {

public void freeze() { ... }

public void jump(long position) { ... }

public void execute() { ... }

}

class Memory {

public void load(long position, byte[] data) { ... }

}

class HardDrive {

public byte[] read(long lba, int size) { ... }

}

Façade 54

/* Facade */

class Computer {

private CPU cpu;

private Memory memory;

private HardDrive hardDrive;

public Computer() {

this.cpu = new CPU();

this.memory = new Memory();

this.hardDrive = new HardDrive();

}

public void startComputer() {

cpu.freeze();

memory.load(BOOT_ADDRESS, hardDrive.read(BOOT_SECTOR,

SECTOR_SIZE));

cpu.jump(BOOT_ADDRESS);

cpu.execute();

}

}

/* Client */

class You {

public static void main(String[] args) {

Computer facade = new Computer();

facade.startComputer();

}

}

Ligações externas• Descrição do padrão façade [1] (em inglês)• Descrição do padrão façade [2] por Vince Huston (em inglês)• Descrição do padrão façade na linguagem Java [3] (em inglês)

Referências[1] http:/ / c2. com/ cgi/ wiki?FacadePattern[2] http:/ / home. earthlink. net/ ~huston2/ dp/ facade. html[3] http:/ / www. allapplabs. com/ java_design_patterns/ facade_pattern. htm

Flyweight 55

FlyweightFlyweight é um padrão de projeto de software apropriado quando vários objetos devem ser manipulados, e esses nãosuportam dados adicionais. No padrão flyweight não existem ponteiros para os métodos do dado, pois isto consomemuita memória. Em contrapartida são chamadas sub-rotinas diretamente para acessar o dado.Um exemplo é o processador de texto. Cada caractere representa um objeto que possui uma família de fonte, umtamanho de fonte e outras informações sobre o símbolo. Como imaginado, um documento grande com tal estruturade dados facilmente ocuparia toda a memória disponível no sistema. Para resolver o problema, como muitas dessasinformações são repetidas, o flyweight é usado para reduzir os dados. Cada objeto de caractere contém umareferência para outro objeto com suas respectivas propriedades.

Ligações externasExemplo de implementação de FlyWeight para gerenciamento de recursos em jogos [1]

Referências[1] http:/ / www. pontov. com. br/ site/ index. php/ arquitetura/ 51-programacao/ 126-gerenciando-recursos?showall=1

Proxy (padrões de projeto)Em programação, o padrão proxy é um padrão de projeto de software.Um proxy, em sua forma mais geral, é uma classe que funciona como uma interface para outra classe. A classe proxypoderia conectar-se a qualquer coisa: uma conexão de rede, um objeto grande em memória, um arquivo, ou algumrecurso que é difícil ou impossível de ser duplicado.Um exemplo bem conhecido do padrão proxy é um objeto ponteiro de referência de contagem.Em situações onde múltiplas cópias de um objeto complexo deve existir o padrão proxy pode ser adaptado paraincorporar o padrão flyweight a fim de reduzir o rastro de memória das aplicações. Normalmente uma instância deum objeto complexo é criada e vários objetos proxies são criados, todos contendo uma referência ao único objetocomplexo original. Quaisquer operações realizadas nos proxies são enviadas ao objeto original. Uma vez que todasas instâncias do proxy estiverem fora do escopo, a memória do objeto complexo pode ser desalocada.

ExemploO seguinte exemplo em Java ilustra o padrão "proxy virtual". A classe ImagemProxy é utilizada para acessar ummétodo remoto.

import java.util.*;

interface Imagem {

public void mostrarImagem();

}

// no Sistema A

class ImagemReal implements Imagem {

private String nomeDoArquivo;

public ImagemReal(String nomeDoArquivo) {

Proxy (padrões de projeto) 56

this.nomeDoArquivo = nomeDoArquivo;

carregarImagemDoDisco();

}

private void carregarImagemDoDisco() {

System.out.println("Carregando " + nomeDoArquivo);

}

public void mostrarImagem() {

System.out.println("Mostrando " + nomeDoArquivo);

}

}

// no Sistema B

class ImagemProxy implements Imagem {

private String nomeDoArquivo;

private Imagem imagem;

public ImagemProxy(String nomeDoArquivo) {

this.nomeDoArquivo = nomeDoArquivo;

}

public void mostrarImagem() {

imagem = new ImagemReal(nomeDoArquivo);

imagem.mostrarImagem();

}

}

class ExemploProxy {

public static void main(String[] args) {

Imagem imagem1 = new ImagemProxy("ResOi_10MB_Foto1");

Imagem imagem2 = new ImagemProxy("ResOi_10MB_Foto2");

imagem1.mostrarImagem(); // necessário o carregamento

imagem2.mostrarImagem(); // necessário o carregamento

}

}

A saída do programa é:

Carregando ResOi_10MB_Foto1

Mostrando ResOi_10MB_Foto1

Carregando ResOi_10MB_Foto2

Mostrando ResOi_10MB_Foto2

Chain of Responsibility 57

Chain of ResponsibilityO padrão de projeto de software Chain of Responsibility representa um encadeamento de objetos receptores para oprocessamento de uma série de solicitações diferentes. Esses objetos receptores passam a solicitação ao longo dacadeia até que um ou vários objetos a tratem.Cada objeto receptor possui uma lógica descrevendo os tipos de solicitação que é capaz de processar e como passaradiante aquelas que requeiram processamento por outros receptores. A delegação das solicitações pode formar umaárvore de recursão, com um mecanismo especial para inserção de novos receptores no final da cadeia existente.Dessa forma, fornece um acoplamento mais fraco por evitar a associação explícita do remetente de uma solicitaçãoao seu receptor e dar a mais de um objeto a oportunidade de tratar a solicitação.Um exemplo da aplicação desse padrão é o mecanismo de herança nas linguagens orientadas a objeto: um métodochamado em um objeto é buscado na classe que implementa o objeto e, se não encontrado, na superclasse dessaclasse, de maneira recursiva.

Situações de utilização•• mais de um objeto pode tratar uma solicitação e o objeto que a tratará não é conhecido a priori;•• o objeto que trata a solicitação deve ser escolhido automaticamente;•• deve-se emitir uma solicitação para um dentre vários objetos, sem especificar explicitamente o receptor;•• o conjunto de objetos que pode tratar uma solicitação deveria ser especificado dinamicamente.Em um sistema orientado a objetos esses interagem entre si através de mensagens, e o sistema necessita dedeterminar qual o objeto que irá tratar a requisição. O padrão de projeto Chain of Responsibility permite determinarquem será o objeto que irá tratar a requisição durante a execução. Cada objeto pode tratar ou passar a mensagem parao próximo na cascata.Em um escritório, por exemplo, onde se tem 4 linha telefônicas, a primeira linha é o primeiro objeto, a segunda linhaé o segundo, e assim sucessivamente até a gravação automática que é o quinto objeto. Se a primeira linha estiverdisponível ela irá tratar a ligação, se não ela passa a tarefa para o próximo objeto, que é a segunda linha. Se essaestiver ocupada ela passa a tarefa para a próxima e assim sucessivamente até que um objeto possa tratar a tarefa.Nesse caso, se todas as linhas estiverem ocupadas o último objeto, que é a gravação automática, tratará da tarefa.

Ligações externas• Referência a Chain of Responsibility no portal de padrões de projeto da Profa. Simone Nasser Matos

(CEFET-PR) [1] (em português)

Referências[1] http:/ / www. pg. cefetpr. br/ coinf/ simone/ patterns/ chain. php

Command 58

CommandCommand é um dos 23 padrões de projeto de software do GOF e é um dos 11 padrões comportamentais.

ObjetivoEncapsular uma solicitação como um objeto, desta forma permitindo que clientes parametrizem diferentessolicitações, enfileirem ou façam o registro (log) de solicitações e suportem operações que podem ser desfeitas..

ProblemaAlgumas vezes é necessário emitir solicitações para objetos nada sabendo sobre a operação que está sendo solicitadaou sobre o receptor da mesma.Utilizar quando:

•• Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametrização numa linguagemprocedural através de uma função callback, ou seja, uma função que é registrada em algum lugar para serchamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks;

•• Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command pode ter um tempo devida independente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneiraindependente do espaço de endereçamento, então você pode transferir um objeto Command para a solicitaçãopara um processo diferente e lá atender a solicitação;

•• Suportar desfazer operações. A operação Execute, de Command, pode armazenar estados para reverter seusefeitos no próprio comando. A interface do Command deve ter acrescentada uma operação Unexecute, que oreverte.efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma listahistórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente,chamando operações Unexecute e Execute, respectivamente.

AplicaçãoA chave deste padrão è uma classe abstrata Command, a qual declara uma interface para execução de operações. Nasua forma mais simples, esta interface inclui uma operação abstrata Execute. As subclasses concretas de Commandespecificam um par receptor-ação através do armazenamento do receptor como uma variável de instância e pelaimplementação de Execute para invocar a solicitação. O receptor tem o conhecimento necessário para poder executara solicitação.

SinônimosTambém conhecido como Action, Transaction (Ação, Transação, respectivamente).

Interpreter 59

InterpreterInterpreter é um padrão de projeto de software que especifica como entender frases em uma determinada linguagemde programação.O padrão de projeto Interpreter pode ser utilizado para representar e resolver problemas recorrentes que possam serexpressos sob a forma de uma linguagem formal simples.Gramáticas simples não precisam ser interpretadas por códigos criados através de geradores de analisadoressintáticos. Para isso, podemos criar uma simples hierarquia de classes baseada na gramática que, através de recursão,devolve a interpretação do código de entrada. É justamente isso que apresenta o padrão Interpreter: uma soluçãoelegante na interpretação de pequenas gramáticas.

IteratorIterator, em programação de computadores, permite a "iteração" e um modo de acesso a elementos de um agregadode objetos, sequencialmente, sem exposição de estruturas internas.Um exemplo: Considere uma lista simplesmente encadeada. Um iterador deve permitir o acesso a todos os elementosda lista de uma forma segura sem que ocorra perda de informação ou modificações não permitidas.

MediatorUm mediador, em linguagem de programação de computadores, é quem desacopla e gerencia as colaborações entreum grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo.É um dos 23 padrões de projetos descritos para reutilização de softwares orientados a objetos. Ele permite aunificação da interface de um sistema. Esse padrão é considerado um padrão comportamental devido à maneiracomo ele pode alterar a execução do software.Normalmente, um programa é feito por um número muito grande de classes. Então, a lógica e o código sãodistribuídos entre essas classes. No entanto, quanto mais classes houver no seu projeto, a comunicação entre essasclasses será mais complexa. Isso faz com que a leitura e a manutenção do programa fique mais difícil, tal situaçãoacarreta na dificuldade de mudanças no projeto, já que, uma simples mudança pode afetar todo o código e as outrasclasses.Com o padrão mediator, a comunicação entre os objetos é encapsulada com um objeto mediador. Isso reduz adependência entre os objetos que estão se comunicando.

Exemplo//Colleague interface

interface Command {

void execute();

}

//Concrete mediator

class Mediator {

BtnView btnView;

Mediator 60

BtnSearch btnSearch;

BtnBook btnBook;

LblDisplay show;

//....

void registerView(BtnView v) {

btnView = v;

}

void registerSearch(BtnSearch s) {

btnSearch = s;

}

void registerBook(BtnBook b) {

btnBook = b;

}

void registerDisplay(LblDisplay d) {

show = d;

}

void book() {

btnBook.setEnabled(false);

btnView.setEnabled(true);

btnSearch.setEnabled(true);

show.setText("booking…");

}

void view() {

btnView.setEnabled(false);

btnSearch.setEnabled(true);

btnBook.setEnabled(true);

show.setText("viewing…");

}

void search() {

btnSearch.setEnabled(false);

btnView.setEnabled(true);

btnBook.setEnabled(true);

show.setText("searching…");

}

}

//A concrete colleague

class BtnView extends JButton implements Command {

Mediator 61

Mediator med;

BtnView(ActionListener al, Mediator m) {

super("View");

addActionListener(al);

med = m;

med.registerView(this);

}

public void execute() {

med.view();

}

}

//A concrete colleague

class BtnSearch extends JButton implements Command {

Mediator med;

BtnSearch(ActionListener al, Mediator m) {

super("Search");

addActionListener(al);

med = m;

med.registerSearch(this);

}

public void execute() {

med.search();

}

}

//A concrete colleague

class BtnBook extends JButton implements Command {

Mediator med;

BtnBook(ActionListener al, Mediator m) {

super("Book");

addActionListener(al);

med = m;

med.registerBook(this);

}

public void execute() {

med.book();

Mediator 62

}

}

class LblDisplay extends JLabel {

Mediator med;

LblDisplay(Mediator m) {

super("Just start…");

med = m;

med.registerDisplay(this);

setFont(new Font("Arial", Font.BOLD, 24));

}

}

class MediatorDemo extends JFrame implements ActionListener {

Mediator med = new Mediator();

MediatorDemo() {

JPanel p = new JPanel();

p.add(new BtnView(this, med));

p.add(new BtnBook(this, med));

p.add(new BtnSearch(this, med));

getContentPane().add(new LblDisplay(med), "North");

getContentPane().add(p, "South");

setSize(400, 200);

setVisible(true);

}

public void actionPerformed(ActionEvent ae) {

Command comd = (Command) ae.getSource();

comd.execute();

}

public static void main(String[] args) {

new MediatorDemo();

}

}

Mediator 63

ComponentesMediator - define a interface para a comunicação entre objetos "amigos".ConcreteMediator - implementa a interface e coordena a comunicação entre os objetos ligados.ConcreteColleague - se comunica com outros objetos através do mediator

Memento (informática)Memento é um padrão de projeto que permite armazenar o estado interno de um objeto em um determinadomomento, para que seja possível retorná-lo a este estado, caso necessário.Três objetos estão envolvidos na implementação do padrão Memento.• Originador é o objeto cujo estado se deseja capturar.• Memento é o objeto definido dentro da classe Originador, com modificador de acesso privado, cujo estado do

objeto originador será armazenado.• Cliente é o objeto que acessará o originador, e deseja desfazer qualquer mudança efetuada, caso necessário.O cliente deve requisitar um objeto memento, antes de se valer do originador. Após efetuar as operações desejadasno originador, o cliente devolve a este o objeto memento, caso deseje desfazer qualquer alteração.O objeto memento não permite o acesso de qualquer classe além da classe originador. Assim, tal padrão mostra-seútil por não violar o conceito de encapsulamento.

ObserverO Observer é um padrão de projeto de software que define uma dependência um-para-muitos entre objetos de modoque quando um objeto muda o estado, todos seus dependentes sejam notificados e atualizados automaticamente.Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outroobjeto.O padrão Observer é também chamado de Publisher-Subscriber, Event Generator e Dependents.

MotivaçãoUm objeto que possua agregações deve permitir que seus elementos sejam acessados sem que a sua estrutura internaseja exposta. De uma maneira geral pode-se desejar que estes elementos sejam percorridos em várias ordens.Como garantir que objetos que dependem de outro objeto percebam as mudanças naquele objeto?•• Os observadores (observer) devem conhecer o objeto de interesse.•• O objeto de interesse (subject) deve notificar os observadores quando for atualizado.Os objetos devem-se interligar entre si de forma a que não se conheçam em tempo de compilação de forma a criar oacoplamento e desfazê-lo a qualquer momento em tempo de execução. Solucionar isso fornece uma implementaçãomuito flexível de acoplamento de abstrações.

Observer 64

AplicabilidadeO padrão Observer pode ser usado quando uma abstração tem dois aspectos, um dependente do outro. Encapsulartais aspectos em objetos separados permite que variem e sejam reusados separadamente. Quando uma mudança a umobjeto requer mudanças a outros e você não sabe quantos outros objetos devem mudar ou quando um objeto deve sercapaz de avisar outros sem fazer suposições sobre quem são os objetos. Em outras palavras, sem criar umacoplamento forte entre os objetos.

Ligações externas• Observer Pattern em Java (Portuguese) [1]

Referências[1] http:/ / www. patternizando. com. br/ 2011/ 03/ design-pattern-observer-com-aplicacao-swing-jse/

StateState é um padrão de projeto de software usado quando ocomportamento de um objeto muda, dependendo do seu estado.

Introdução

Em certas ocasiões, quando o contexto em que está a desenvolverrequer um objeto que possue comportamentos diferentes dependendo de qual estado se encontra, é difícil manejar amudança de comportamento e os estados desse objeto, tudo dentro do mesmo bloco de código. O padrão Statepropõe uma solução para esta complicação, criando basicamente, um objeto para cada estado possível do objeto queo chama.

ObjetivoPermite que um objeto altere seu comportamento de acordo com o estado interno que se encontra em um momentodado.

MotivaçãoO padrão State é motivado por aqueles objetos que, em seu estado atual, varia o seu comportamento devido asdiferentes mensagens que possa receber. Como exemplo, tomamos uma classe Livro, um objeto desta classe terárespostas diferentes, dependendo da seu estado(Disponível o Prestado). Por exemplo invocando o método reservar deum objeto da classe Livro seu comportamento será diferente, se o Livro está no estado Disponível o no estadoPrestado.

State 65

Diagrama de ClassesO seguinte diagrama é uma representação da estrutura e relações das classes que servem de modelo para os objetos.

Diagrama de EstadosNo seguinte diagrama representamos os possíveis estados ou situações em que um Livro pode se encontrar nodecorrer da execução em nosso sistema.

ProblemaHá uma extrema complexidade no código quando tentamos gerênciar comportamentos diferentes, dependendo de umnúmero de estados diferentes. Também manter o código torna-se difícil, e mesmo em alguns casos, podem apontar auma inconsistência de estados atuais na forma de implementação dos diferentes estados no código (por exemplo,com variáveis para cada estado).

ConsideraçõesDevemos analisar a complexidade em comparação com outras soluções.

State 66

SoluçãoSe implementa uma classe para cada estado diferente do objeto e o desenvolvimento de cada método para cadaestado em particular. O objeto da classe a que pertencem esses estados resolvem os diferentes comportamentos,dependendo de sua condição, com as instâncias das classes de estado. Assim, sempre está presente em um objeto oseu estado atual e se comunica com ele a resolvendo suas responsabilidades.A idéia principal do padrão State é a introdução de um classe abstrata EstadoLivro que representa os estados e umainterface para todas as classes que representam os próprios estados. Por exemplo, as classes Disponível e Prestadoimplementam responsabilidades especiais para os estados Disponível e Prestado respectivamente do objeto Livro. Aclasse Livro mantém uma instância de alguma subclasse de EstadoLivro com o atributo estado que representa oestado actual do Livro. Na implementação dos métodos de Livro haverá chamadas a esses objetos que serãorepresentados pelo atributo estado para a execução das responsabilidades, dependendo de qual estado se encontre enesse momento, enviará essas chamadas para um objeto ou outro das subclasses de EstadoLivro.

Os participantes1. Contexto: Este integrante define a interface com o cliente. Mantém uma instância de Estado Concreto que define

seu estado atual.2. Estado: Define uma interface para encapsular as responsabilidades associadas a um estado particular de contexto.3. Subclasse EstadoConcreto: Cada uma dessas subclasses implementa o comportamento ou responsabilidade de

Contexto.O Contexto delega o estado específico para o objeto EstadoConcreto atual. Um objeto de Contexto pode passar-secomo parâmetro a um objeto Estado. Assim, a classe Estado pode acessar o contexto, se fosse necessário. Contexto éa interface principal para o cliente. O cliente pode configurar um contexto com objetos Estado. Uma vez feito isso,os clientes não têm de lidar com objetos de tipo Estado diretamente. Tanto o objeto de Contexto como os objetos deEstadoConcreto podem decidir a mudança de estado.

ColaboraçõesO padrão de State pode usar o padrão Singleton quando necesita a existe de apenas uma instância de cada estado. Sepode utilizar quando se compartem os objetos como Flyweight existindo uma única instância de cada Estado e esta écompartilhada com mais de um objeto.

Como funcionaA classe Contexto envia mensagens para os objetos de EstadoConcreto dentro de seu código para dar a estes aresponsabilidade que deve ser cumplida pelo objeto Contexto. Então, o objeto Contexto vai mudando asresponsabilidades de acordo com o estado em que se encontra, devido a que também muda de objeto EstadoConcretoao fazer a mudança de estado.

State 67

Quando usá-lo?Está recomendado quando um determinado objeto tem estados e responsabilidades diferentes, dependendo de qualestado você está em determinado momento. Também pode ser usada para simplificar os casos em que há códigocomplicado e extenso de decisão que depende do estado do objeto

Vantagens e desvantagensSão as seguintes vantagens:• É fácil de localizar as responsabilidades de estados específicos, devido a que os encontram nas classes que

correspondem a cada estado. Isto proporciona uma maior clareza no desenvolvimento e na manutençãosubsequente. Esta facilidade é fornecida pelo fato de que diferentes estados são representados por um únicoatributo (estado) e não envolvidos em diferentes variáveis e grandes condicionais.

•• Faz as mudanças de estado explícitas, posto que em otro tipo de implantação os estados são alterados,modificando os valores em variáveis, enquanto aqui fazer-se representar cada estado.

• Os objetos Estado podem ser compartilhados se eles não contêm variáveis de instância, isto pode ser alcançado seo estado está totalmente codificado representando seu tipo. Quando isso é feito, os estados são flyweights semestado intrínseco.

•• Facilita a expansão de estados.•• Permite a um objeto alterar de classe em tempo de execução dado que ao modificar suas responsabilidades pela de

outro objeto de outra classe, a herança e responsabilidades do primeiro mudaram pelas do segundo.Desvantagem:•• Aumenta o número de subclasses.

Implementação (Java)public class Main {

public static void main(String argv[]) {

Livro l1 = new Livro("Design Patterns");

Livro l2 = new Livro("Java Programming Language");

l1.solicitar(); // Disponivel -> Prestado

l1.solicitar(); // Ops, o livro já está prestado

l1.devolver(); // Prestado -> Disponible

l2.devolver(); // nada, o livro já está disponível

}

}

/**

* Livro define o contexto para este exemplo simples de padrao estado.

* Um Livro puede estar em dos estados: Disponível y Prestado, de tal modo que

* se escolhemos por representar o estado com um atributo, os métodos da

* clase Livro acabariam por convertir-se em condicionais sobre esse estado

*/

State 68

public class Livro {

// O construtor da classe, además de inicializar o título do

// livro, define o estado inicial (Disponível). Como neste caso

// os estados de livros têm o seu próprio estado, usamos um singleton.

public Livro(String titulo) {

_titulo = titulo;

_estado = Disponivel.instancia();

}

public String toString() { return (_titulo + " (" + _estado + ")" ); }

// Este método modifica o estado do livro. Problema: o método deve

// ser acessado a partir de uma classe externa (EstadoLibro), o que exclui

// a visibilidade private e protect. public é demasiado geral pois

// *todas* as classes pode acessar o método... Neste caso, sugere-se a

// visibilidade de package, com Livro e os seus estados no mesmo package...

void estabelecerEstado(EstadoLibro estado) {

System.out.println("Transitando de " + _estado + " a " + estado);

_estado = estado;

}

// Os métodos de dependentes do estado delegam o comportamento

// definido para cada estado. Uma vez que vamos a responsabilizar aos

// estados de realizar as transições, passamos o livro ao estado

// para que possa, se lhe interessa, chamar estabelecerEstado

public void devolver() { _estado.devolver(this); }

public boolean solicitar() { return _estado.solicitar(this); }

//-------- privadas ---------

private EstadoLibro _estado; // implementa associação com o estado

private String _titulo;

}

/**

* Esta é a classe abstrata que define as operações específicas do Estado

* del estado. Os métodos podem ser declarados abstratos, de modo que

* as classes derivadas têm que implementar-los forzosamente, o podem

* ter uma implementação por defeito, definida neste nível

*/

State 69

public abstract class EstadoLivro {

// Os métodos devolver e solicitar são abstratos (devem ser implementados

// pelos estados concretos) e sao tomados como argumento livro, se

// desejamos aceder posteriormente aos atributos e métodos do mesmo

abstract public void devolver(Livro livro);

abstract public boolean solicitar(Livro livro);

// Além disso, adicionamos um método com um string que identifica o status

// do livro -- a definição estabelece um valor por defeito que será

// usado se as sub-clases nao redefinem

public String toString() { return "Desconhecido"; }

}

/**

* Um dos estados concretos do livro. A classe Disponivel faz a

* transição Disponivel -> Prestado ao chamar a solicitar. Ignora

* as devolucioes (nao se contemplam várias cópias do mesmo livro)

*/

public class Disponivel extends EstadoLibro {

// Uma vez que em este exemplo os estados dos livros nao vao a conter

// atributos dependentes do contexto, fazemos que Disponivel seja um

// Singleton

protected Disponivel() {}

public static Disponivel instancia() {

if (_instancia == null)

_instancia = new Disponivel();

return _instancia;

}

// Métodos específicos deste estado concreto. Solicitar modifica o estado

// do livro, enquanto que devolver simplesmente o ignora

public boolean solicitar(livro livro) {

System.out.println("Atendendo pedido do livro " + livro);

livro.estabelecerEstado(Prestado.instancia());

return true;

}

public void devolver(livro livro) {

State 70

System.out.println("Oba... já tenho o livro " + livro);

}

// Redefine o nome do estado...

public String toString() { return "Disponivel"; }

//--------- privadas ------------

// Instancia do Singleton Disponivel

private static Disponible _instancia;

}

/**

* Um dos estados concretos do livro. A classe Prestado faz a

* transição Prestado -> ao chamar a devolver. Ignora

* os pedidos (não se contemplam reservas)

*/

public class Prestado extends EstadoLivro {

// Dado que neste exemplo os estados dos livros não vão a conter

// atributos dependentes do contexto, fazemos que Prestado seja un

// Singleton

protected Prestado() {}

public static Prestado instancia() {

if (_instancia == null)

_instancia = new Prestado();

return _instancia;

}

// Métodos específicos deste estado concreto. Devolver faz a transicão

// a Disponible, enquanto que solicitar rejeita

public boolean solicitar(livro livro) {

System.out.println("El livro " + livro + " não está disponível");

return false;

}

public void devolver(livro livro) {

System.out.println("Ok. O livro " + livro + " foi devolvido");

livro.estabelecerEstado(Disponivel.instancia());

}

State 71

// Redefine o nome do estado

public String toString() { return "Prestado"; }

//--------- privadas ------------

// Instancia do Singleton Prestado

private static Prestado _instancia;

}

ConclusõesO padrão não indica exatamente donde definir as transições de um estado para outro. Há duas maneiras de contornarisso: Uma delas é definir essas transições dentro da classe Contexto, a outra é definir essas transições nas subclassesde Estado. É mais conveniente utilizar a primeira solução quando o critério a ser aplicado é fixo, ou seja, nãomudará. O segundo é conveniente quando este critério é dinâmico, a desvantagem aqui é apresentada na dependênciade código entre as subclasses.Precisamos também avaliar a implementação ao criar instancias de estado concreto diferentes ou usar a mesmainstância compartilhada. Isto irá depender se a mudança de estado é menos frequente ou mais frequente,respectivamente.

StrategyStrategy é um padrão de projeto de software (do inglês design pattern). O objetivo é representar uma operação a serrealizada sobre os elementos de uma estrutura de objetos. O padrão Strategy permite definir novas operações semalterar as classes dos elementos sobre os quais opera. Definir uma família de algoritmos e encapsular cada algoritmocomo uma classe, permitindo assim que elas possam ter trocados entre si. Este padrão permite que o algoritmo possavariar independentemente dos clientes que o utilizam.

AplicaçãoUtilizar o padrão Strategy quando:•um objeto deve ser parametrizado com um de vários algoritmos, os quais podem ser encapsulados e representadospor uma única interface.Segue um exemplo em Java onde o valor de comissão difere de acordo com o cargo do funcionario.

/**

* Enumeration de cargos.

*/

public enum Cargo {

ATENDENTE,

VENDEDOR,

GERENTE;

}

/**

* Dados do funcionario.

Strategy 72

*/

public class Funcionario {

private long id;

private enum cargo;

// Construtor, getters e setters

. . .

}

/**

* Interface pattern Strategy.

*/

public interface Strategy {

// Calcula comissão.

double calcularComissao(double valorVenda);

}

/**

* Classe que calcula comissão de venda.

*/

public class Venda {

private double valorVenda;

private Funcionario funcionario;

private Strategy calculoComissao;

// Construtor [Implementa STRATEGY].

public Venda() {

switch (funcionario.getCargo()) {

case ATENDENTE :

this.setCalculoComissao(new Strategy() {

@Override

public double calcularComissao(double

valorVenda) {

return (valorVenda * 0.01);

}

});

break;

case VENDEDOR :

this.setCalculoComissao(new Strategy() {

Strategy 73

@Override

public double calcularComissao(double

valorVenda) {

return (valorVenda * 0.02);

}

});

break;

case GERENTE :

this.setCalculoComissao(new Strategy() {

@Override

public double calcularComissao(double

valorVenda) {

return (valorVenda * 0.03);

}

});

break;

}

}

private void setCalculoComissao(Strategy calculoComissao) {

this.calculoComissao= calculoComissao;

}

private Strategy getCalculoComissao() {

return (this.calculoComissao);

}

public void save() {

//. . .

/*

* Calcula o valor da comissão de venda sem que haja a

necessidade de

* verificar qual o tipo cargo toda vez que o metodo <b>save</b>

for executado.

*/

final double valorComissao =

this.getCalculoComissao().calcularComissao(this.valorVenda);

// . . .

}

Strategy 74

}

}

Template MethodUm Template Method auxilia na definição de um algoritmo com partes do mesmo definidos por Método abstratos.As subclasses devem se responsabilizar por estas partes abstratas, deste algoritmo, que serão implementadas,possivelmente de várias formas, ou seja, cada subclasse irá implementar à sua necessidade e oferecer umcomportamento concreto construindo todo o algoritmo.O Template Method fornece uma estrutura fixa, de um algoritmo, esta parte fixa deve estar presente na superclasse,sendo obrigatório uma classeAbstrata que possa conter um método concreto, pois em uma interface só é possívelconter métodos abstratos que definem um comportamento, esta é a vantagem de ser uma Classe Abstrata porquetambém irá fornecer métodos abstratos às suas subclasses, que por sua vez herdam este método, por Herança(programação), e devem implementar os métodos abstratos fornecendo um comportamento concreto aos métodosque foram definidos como abstratos. Com isso certas partes do algoritmo serão preenchidos por implementações queirão variar, ou seja, implementar um algoritmo em um método, postergando a definição de alguns passos doalgoritmo, para que outras classes possam redefiní-los.[1]

EstruturaA representação do diagrama de classe no modelo da UML mostra como acontece físicamente a herança e quem ficaresponsável pela implementação. A importância de um diagrama de classes é porque descreve os tipos de objetospresentes no sistema e os vários tipos de relacionamentos estáticos existentes entre eles.[2]

Exemplo de Diagrama em UML para o Padrão TemplateMethod.

Template Method 75

Código JavaUma abordagem diferente é ter o código fonte, cujo diagrama de classe está representado acima, seja fiel ao que estásendo representado no diagrama UML.

package br.com.nc.architect.templatemethod;

public abstract class AbstractClass {

public final void templateMethod() {

System.out.println("AbstractClass.templateMethod()

called");

primitiveOperation1();

primitiveOperation2();

}

public abstract void primitiveOperation1();

public abstract void primitiveOperation2();

}

package br.com.nc.architect.templatemethod;

public class Concrete1 extends AbstractClass {

public void primitiveOperation1() {

System.out.println("Concrete1.primitiveOperation1()

called");

}

public void primitiveOperation2() {

System.out.println("Concrete1.primitiveOperation2()

called");

}

}

package br.com.nc.architect.templatemethod;

public class Concrete2 extends AbstractClass {

public void primitiveOperation1() {

System.out.println("Concrete2.primitiveOperation1()

called");

}

public void primitiveOperation2() {

System.out.println("Concrete2.primitiveOperation2()

Template Method 76

called");

}

}

package br.com.nc.architect.templatemethod;

public class TestTemplateMethod {

public static void main(String[] args) {

System.out.println("Test TemplateMethod");

System.out.println("-------------------------");

AbstractClass class1 = new Concrete1();

AbstractClass class2 = new Concrete2();

class1.templateMethod();

class2.templateMethod();

}

}

Referências[1][1] METSKER, Steven John. PADRÕES DE PROJETO EM JAVA, Pág. 197. 2004[2][2] FOWLER, Martin. UML ESSENTIALS: um breve guia para a linguagem-padrão de modelagem de objetos. 3ª ed. pág 52. Porto

Alegre.Bookman. 2005.

Visitor Pattern 77

Visitor PatternEm programação orientada a objetos e engenharia de software, o visitor pattern é um padrão de projetocomportamental. Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitorpermite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera. É umamaneira de separar um algoritmo da estrutura de um objeto. Um resultado prático é a habilidade de adicionar novasfuncionalidades a estruturas de um objeto pré-existente sem a necessidade de modificá-las.A idéia é usar uma classe de elementos como uma estrutura, sendo que cada uma delas possui um método cujo umdos argumentos é um objeto do tipo visitor. Visitor é uma interface que possui um método visit() paracada classe de elementos. O método accept() de uma classe de elementos invoca o método visit() de suarespectiva classe. Classes visitor concretas distintas podem então ser escritas para implementar operaçõesespeciais.O padrão Visitor é uma solução para separar o algoritmo da estrutura. Uma das vantagens desse padrão é ahabilidade de adicionar novas operações a uma estrutura já existente. Com ele, podemos ter a classe ObjetoSolido eo comportamento de queda em uma classe Gravidade, separada da estrutura do ObjetoSolido. Isso é feito através deuma interface, onde o objeto que vai executar esse método da classe do comportamento, passa uma referencia delamesmo junto dos parâmetros normais da classe. No caso desse exemplo, teríamos:

Visitor gravidade = new Gravidade(); //esse é o nosso visitor,

responsável pelo comportamento de queda.

Solido solido = new Solido("caixa"); //solido que recebera o

comportamento

solido.accept(gravidade); //recebe o comportamento Gravidade

Internamente, o método accept(Visitor visitor) de Solido faz o seguinte:

public void accept(Visitor visitor) {

visitor.visitSolido(this);

}

Ao passar para o Visitor uma referencia de si mesmo, o visitor pode acessar os métodos e atributos públicos dessaclasse, que no nosso caso, vai adicionar a aceleração da gravidade ao Solido. Assim como o comportamento dequeda foi adicionado, outros também poderiam ser feitos da mesma maneira, como movimentação através doteclado, sons... as possibilidades são infinitas.

MVC 78

MVC

Um diagrama simples exemplificando a relaçãoentre Model, View e Controller. As linhas sólidasindicam associação direta e as tracejadas indicam

associação indireta.

Model-view-controller (MVC) é um modelo de desenvolvimento deSoftware, atualmente considerado uma "arquitetura padrão" utilizadana Engenharia de Software. O modelo isola a "lógica" (A lógica daaplicação) da interface do usuário (Inserir e exibir dados), permitindodesenvolver, editar e testar separadamente cada parte.

História

O padrão MVC foi descrito pela primeira vez em 1979[1] por TrygveReenskaug, que trabalhava no Smalltalk, na Xerox PARC. Aimplementação original é descrita em profundidade no artigo "Applications Programming in Smalltalk-80: How touse Model–View–Controller".[2]

ComponentesO modelo (model) é usado para definir e gerenciar o domínio da informação e notificar observadores sobremudanças nos dados. Ele é uma representação detalhada da informação que a aplicação opera. A lógica de negócioadiciona valor semântico aos dados, e quando há mudança de estado o modelo notifica seus observadores. Porexemplo, aluno, professor e turma fazem parte do domínio de um sistema acadêmico. Operações como calcular amédia final do aluno ou o índice de faltas da turma fazem parte da lógica de domínio. A forma como o dado éarmazenado ou acessado não é de interesse do MVC, assume-se que é de responsabilidade do modelo.A visão (view) apresenta o modelo num formato adequado ao utilizador, na saída de dados, e diferentes visõespodem existir para um mesmo modelo, para diferentes propósitos.O controlador (controller) recebe a entrada de dados e inicia a resposta ao utilizador ao invocar objetos do modelo, epor fim uma visão baseada na entrada. Ele também é responsável pela validação e filtragem da entrada de dados.Um caso prático é uma aplicação web em que a visão é um documento HTML (ou derivado) gerado pela aplicação.O controlador recebe uma entrada GET ou POST após um estímulo do utilizador e decide como processá-la,invocando objetos do domínio para tratar a lógica de negócio, e por fim invocando uma visão para apresentar a saída.

JustificativaCom o aumento da complexidade das aplicações desenvolvidas,sempre visando a programação orientada a objetonao devemos esquecer que torna-se relevante a separação entre os dados e a apresentação das aplicações. Destaforma, alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alteraro layout.Esse padrão resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógicade apresentação e de interação com o utilizador, introduzindo um componente entre os dois, o controlador.

MVC 79

Plataformas de desenvolvimento

ActionScript 3• Cairngorm - da Adobe•• PureMVC•• Swiz

ASP•• ASP Xtreme Evolution•• Toika•• AJAXED

.NET• ASP.NET MVC - oficial da Microsoft• C#.NET MVC - oficial da Microsoft

Java•• Mentawai•• VRaptor•• Neo Framework•• Brutos Framework•• Apache Struts•• Tapestry•• WebWork•• Play! Framework•• Spring MVC•• JSF•• Click Framework

Perl•• Catalyst•• Mojolicious•• Gantry

PHP•• Akelos• CakePHP - para as versões 4 e 5• CodeIgniter - para as versões 4 e 5•• iGrape• Kohana Framework - para a versão 5• LightVC - para a versão 5.• Megiddo [3] - para a versão 5• Oraculum PHP Framework - para a versão 5• PageletBox - IDE para Celular WAP com framework MVC embutido em PHP 5•• PHPBurn• PHPonTrax - para a versão 5

MVC 80

• PRADO - para a versão 5•• Seagull•• Spaghetti*• Symfony - para a versão 5•• Vórtice Framework• XPT Framework - para a versão 5• Yii Framework - para a versão 5• Zend Framework - da ZEND, mantenedora oficial do PHP 5 no padrão MVC

Python•• Django•• TurboGears•• Web2py

Ruby•• Rails•• Merb[1] Trygve M. H. Reenskaug/MVC (http:/ / heim. ifi. uio. no/ ~trygver/ themes/ mvc/ mvc-index. html)—XEROX PARC 1978-79[2] How to use Model–View–Controller ALLAN (MVC) (http:/ / st-www. cs. uiuc. edu/ users/ smarch/ st-docs/ mvc. html)[3] http:/ / github. com/ Suga/ Megiddo

Leitura adicional• MVC e Camadas (http:/ / fragmental. com. br/ wiki/ index. php?title=MVC_e_Camadas)

Service-oriented architecture 81

Service-oriented architectureService-Oriented Architecture (SOA), pode ser traduzido como arquitetura orientada a serviços, e é um estilode arquitetura de software cujo princípio fundamental prega que as funcionalidades implementadas pelas aplicaçõesdevem ser disponibilizadas na forma de serviços.[1][2] Frequentemente estes serviços são conectados através de um"barramento de serviços" (enterprise service bus, em inglês) que disponibiliza interfaces, ou contratos, acessíveisatravés de web services ou outra forma de comunicação entre aplicações.[2][3][4] A arquitetura SOA é baseada nosprincípios da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre ossistemas clientes e os sistemas que implementam os serviços.[5]

Além da perspectiva estritamente técnica, a arquitetura orientada a serviços também se relaciona com determinadaspolíticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a tarefa de encontrar, definir egerenciar os serviços disponibilizados.[6][7]

A arquitetura orientada a serviços também se insere em um processo de reorganização dos departamentos detecnologia da informação das organizações, permitindo um melhor relacionamento entre as áreas que dão suportetecnológico à empresa e as áreas responsáveis pelo negócio propriamente dito, graças a maior agilidade naimplementação de novos serviços e reutilização dos ativos existentes.[8][9]

SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negóciointeroperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas. — Gartner Group

IntroduçãoAs implementações SOA dependem de uma rede de serviços de software. Serviços incluem baixo acoplamento deunidades e de funcionalidade. Cada serviço implementa uma ação, como preencher um requerimento on-line parauma conta ou visualizar um banco on-line de instrução, ou colocar uma reserva on-line ou para bilhete de avião. Emvez de serviços de chamadas para encaixar uns aos outros em seu código fonte que eles usam protocolos definidosque descrevem como os serviços de análise e passar mensagens, utilizando metadados descrição.Desenvolvedor SOA associa objetos individuais usando orquestração. No processo de orquestração que odesenvolvedor associa funcionalidade de software (serviços) em um arranjo não-hierárquico usando uma ferramentade software que contém uma lista completa de todos os serviços disponíveis, suas características e os meios paracriar uma aplicação utilizando essas fontes.Programadores fazem amplo uso da linguagem XML para descrição dos tipos e estruturas de dados em SOA.Também baseada em XML, a Web Services Description Language (WSDL) normalmente descreve os serviços,enquanto o protocolo SOAP descreve os protocolos de comunicação, além de outros padrões alternativos, comoWADL e REST. SOA depende dos dados e serviços que são descritos por metadados que devem satisfazer osseguintes critérios:1. Os metadados devem vir de uma forma que os sistemas de software podem usar para configurar dinamicamente adescoberta e a incorporação de serviços definidos, e também para manter a coerência e integridade. Por exemplo, osmetadados podem ser utilizados por outros aplicativos, como um catálogo, para executar serviços de autodescoberta,sem modificar o contrato de um serviço funcional.2. Os metadados devem vir de uma forma que o designer de sistema seja capaz de compreender e gerir com um gastorazoável de custo e esforço.Para isto funcionar, não deve existir interações entre os pedaços dentro do especificado, ou pedaços de si. Em vezdisso, os seres humanos especificam a interação dos serviços (todos eles pares não associados) em uma formarelativamente ad hoc com a intenção impulsionado por exigências de recém-emergente. Assim, há a necessidade deserviços como unidades de maior funcionalidade do que as funções tradicionais ou classes, para que a enorme

Service-oriented architecture 82

complexidade de milhares de tais objetos granulares não sobrecarreguem o designer de aplicativo. Os programadoresdesenvolvem os próprios serviços usando linguagens tradicionais como Java, C, C++, C# ou COBOL.A partir de 2008, um número crescente de empresas de software de terceiros oferecem serviços de software para umataxa. No futuro, sistema SOA pode consistir de tais serviços de terceiros combinado com outros criados em casa.Este tem o potencial de repartir os custos sobre os clientes e usa muitos dos clientes e promove a normalização, tantodentro como através das indústrias. Em particular, a indústria do turismo tem agora um bem-definidas edocumentadas conjunto de ambos os serviços e dados, suficiente para permitir que qualquer engenheiro de softwarerazoavelmente competente para criar software de agência de viagens que utilizam os serviços totalmenteoff-the-shelf software.Outras indústrias, como a indústria financeira, também começaram a fazer progressos significativos nesse sentido.SOA como uma arquitetura depende de orientação a serviços como o seu princípio fundamental de design. Se umserviço apresenta uma interface simples que abstrai a complexidade subjacente, os usuários podem acessar osserviços independentes, sem conhecimento da execução do serviço de plataforma.SOA se baseia em serviços expondo suas funcionalidades através de interfaces que outros aplicativos e serviçospossam ler para entender como utilizar esses serviços.

RequisitosA fim de utilizar eficientemente uma SOA, deve-se atender aos seguintes requisitos:A interoperabilidade entre diferentes sistemas e linguagens de programação fornece a base para a integração entreaplicações em diferentes plataformas, através de um protocolo de comunicação. Um exemplo dessa comunicaçãodepende do conceito de mensagens. Usando mensagens, através de canais de mensagens definidos, diminui acomplexidade da aplicação final, permitindo que o desenvolvedor do aplicativo se concentre na funcionalidade doaplicativo de verdade, em vez das necessidades intrincadas de um protocolo de comunicação. O desejo é o de criarum conjunto de recursos a ser compartilhado, bem como estabelecer e manter o fluxo de dados para um sistema debanco de dados compartilhado. Isto permite que novas funcionalidades sejam desenvolvidas para um formato denegócio de referência comum para cada elemento de dados.

Abordagem Serviços WebServiços Web podem implementar uma arquitetura orientada a serviços. Serviços Web fazem blocos funcionais deconstrução acessíveis através de protocolos de Internet padrão independente de plataformas e linguagens deprogramação. Estes serviços podem representar tanto novas aplicações quanto apenas invólucros em torno dossistemas legados existentes para torná-los em rede ativada.Cada bloco de construção SOA pode desempenhar um ou ambos os papéis:Service Provider - O prestador de serviços cria um serviço Web e, eventualmente, publica sua interface e acesso ainformação para o registro de serviços. Cada fornecedor deve decidir quais os serviços irá expor, como fazertrade-offs entre a segurança e a facilidade de acesso, como preço dos serviços, ou (se nenhuma taxa extra), como e sea explorá-los para outro valor. O provedor também tem que decidir em qual categoria os serviços devem ser listadosem um dado serviço de broker e que tipo de acordos com parceiros comerciais são obrigados a usar o serviço. Eleregistra que os serviços estão disponíveis dentro dele, e as listas de todos os beneficiários potenciais do serviço. Oimplementador do corretor, então, decide o âmbito do corretor. Corretores públicos estão disponíveis através daInternet, enquanto intermediários privados só são acessíveis a um público limitado, por exemplo, os usuários de umaintranet da empresa. Além disso, a quantidade de informações oferecidas tem de ser decidido. Alguns corretoresespecializados em muitas listas. Outros oferecem altos níveis de confiança nos serviços listados. Algumas cobremum amplo panorama de serviços e outros, o foco dentro de uma indústria. Alguns corretores catálogam outros.Dependendo do modelo de negócio, os corretores podem tentar maximizar o look-up dos pedidos, o número de

Service-oriented architecture 83

anúncios ou exatidão dos anúncios. O Universal Description Discovery and Integration (UDDI) define uma maneirade publicar e descobrir informações sobre os serviços da Web. Outros serviços incluem (por exemplo) ebXML(Electronic Business utilizando eXtensible Markup Language) e aqueles baseados na ISO / IEC 11179 MetadataRegistry (MDR) padrão.Atendimento ao consumidor - O consumidor de serviços ou cliente do serviço web localiza entradas no registro docorretor para encontrar as operações e, em seguida, liga-se ao prestador do serviço para invocar um de seus serviçosde web. Seja qual for o serviço a serviço, os consumidores precisam, eles têm que levá-la para o corretor, emseguida, vinculá-lo com o respectivo serviço e usá-lo. Eles podem acessar vários serviços, se o serviço oferece váriosserviços.

AcoplamentoÉ o nível de interdependência entre os módulos de um sistema. Por outro lado, um módulo é considerado coesoquando possui uma atividade bem definida. Diferentemente do que as pessoas pensam, SOA não se trata de umasimples invenção. A arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemastradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas demercado, que se faz cada vez mais exigente em qualidade e agilidade.

ServiçoUm serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é disponibilizadopara outro sistema. Um serviço deve funcionar de forma independente do estado de outros serviços, exceto nos casosde serviços compostos (composite services), e deve possuir uma interface bem definida. Normalmente, acomunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web services.

Processos

Mais do que uma tecnologia, SOA também influencia regras e processos denegócios,além de muitas vezes implicar reengenharia de software simultaneamente. — Gartner Group

A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de"find-bind-execute paradigm" o que significa aproximadamente paradigma de "procura-consolida-executa". Talconceito é análogo a "Ciclo de Deming" aplicado aos serviços, que define o ciclo que envolve o planejamento, aexecução, o monitoramento e a tomada de ação pró ativa para a melhoria da qualidade.

Service-oriented architecture 84

Esquema adaptado do paradigma "find-bind-execute"

Tecnicamente falando, o processopreconiza que os provedores deserviços registrem informações em umregistro central, com suascaracterísticas, indicadores, e aspectosrelevantes às tomadas de decisões. Oregistro é utilizado pelo cliente paradeterminar as características dosserviços necessários, e se o mesmoestiver disponível no registro central,como por exemplo por um catálogo deserviços, o cliente poderá utilizá-lo,sendo este oficializado através de umcontrato que enderece este serviço.

TecnologiaO termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Serviços expressa um conceito no qualaplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) deforma independente e se comunicando através de padrões abertos. A maior parte das implementações de SOA seutilizam de Web services (SOAP , REST e WSDL). Entretanto, uma implementação de SOA pode se utilizar dequalquer tecnologia padronizada baseada em web.

Definições de SOAO SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão de serviços e ao cliente.

Termo Definição / Comentário

Serviço É uma função independente, sem estado (stateless) que aceita uma ou mais requisições e devolve uma ou mais respostas através deuma interface padronizada e bem definida. Serviços podem também realizar partes discretas de um processo tal como editar ouprocessar uma transação. Serviços não devem depender do estado de outras funções ou processos. A tecnologia utilizada para provero serviço, tal como uma linguagem de programação, não pode fazer parte da definição do serviço.

Orquestração Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados.

Stateless Não depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebemtodas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos serviçosé possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados depipelines) para executar a lógica de uma aplicação.

Provedor O recurso que executa o serviço em resposta a uma requisição de um consumidor.

Consumidor É quem consome ou pede o resultado de um serviço fornecido por um provedor.

Descoberta SOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de umdiretório que descreva quais os serviços disponíveis dentro de um domínio.

Binding A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; ela é estabelecida em tempo de execuçãoatravés de um mecanismo de binding.

Service-oriented architecture 85

SOA FundamentalComo serviços encapsulam a lógica

Pode ser em contextos distintos. Estes contextos podem ser específicos para uma tarefa de negócio, entidades denegócio e outros agrupamentos de negócio.

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Na figura, quando construímos umasolução consistente de serviço, cadaserviço pode encapsular a tarefarealizada por um passo individual ouum sub-processo composto de umconjunto de passos. Um serviço podeencapsular toda a lógica do processo.O último caso representado peloserviço pode englobar a lógicaencapsulada de outros serviços.Como serviços são relacionados

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Dentro do SOA serviços podem serusados por outros serviços ou poroutros programas. Independentemente,o relacionamento por trás do serviço ébaseado no entendimento que osserviços possam interagir. Eles devemestar atentos ao outro. Esta consciênciaé obtida através do uso da descrição doserviço.Como serviços se comunicam

Quando as mensagens são enviadaseles perdem o controle do que acontecedepois. Essas mensagens podem serequipadas com inteligência suficientepara auto-governar as partes lógicas do processamento.

Service-oriented architecture 86

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Esta arquitetura é similar ao passadoda arquitetura distribuída que suportamensagens e separação de interface deprocessamento lógico. O que distingueé como esses três componentesfundamentais (serviço, descrição emensagem) são projetados. Onde entraa orientação de serviços.Como serviços são projetados

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Acoplamento: busca-se um fracoacoplamento. Contrato de serviço:meio de acesso a esse serviço.Autonomia: serviços têm controlesobre a lógica que a encapsulam.Abstração: além do que é descrito nocontrato de serviço, serviços escondema lógica do mundo exterior.Reusabilidade: a lógica é dividida noserviço com a intenção de reuso.Agregabilidade: coleções de serviçospodem ser coordenados e montados emforma de serviços compostos.Statelessness: serviços minimizam aretenção da informação emdeterminada atividade. Descoberta:serviços são projetados para serexteriormente descrito, para quepossam ser encontrados e avaliados através de mecanismos de descobertas disponíveis.

Como serviços são construídos A obtenção do SOA não exige serviço web, mas SOA pode e deve ser realizadaatravés do uso da plataforma de tecnologia de serviço web.

Ligações externas• Norbert Bieberstein et al. Service-Oriented Architecture Compass by Pearson 2006 [10]

• IBM Systems Journal edition on SOA [11]

• Oracle Service-Oriented Architecture Technology Center [12]

• Revista PortalBPM [13]

• Seebeyond - ICAN [14]

• Site com opiniões e comentários de especialistas em SOA [15]

Service-oriented architecture 87

Referências[1] SOA Working Group of The Open Group. Definition of SOA (http:/ / opengroup. org/ projects/ soa/ doc. tpl?gdid=10632) (em inglês). Página

visitada em 4 de junho de 2007.[2] Boris Lublinsky. Defining SOA as an architectural style (http:/ / www. ibm. com/ developerworks/ library/ ar-soastyle/ ) (em ingles). Página

visitada em 4 de junho de 2007.[3] Dirk Krafzig, Karl Banke, Dirk Slama. Enterprise SOA: Service-Oriented Architecture Best Practices. 1 ed. Estados Unidos da

América: Prentice Hall, 2004. ISBN 0131465759[4] Martin Keen, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, Paul Verschueren, Amit Acharya.

Patterns: Implementing an SOA using an Enterprise Service Bus (http:/ / www. redbooks. ibm. com/ redbooks/ pdfs/ sg246346. pdf) (eminglês). Página visitada em 4 de junho de 2007.

[5] Raghu R. Kodali. What is service-oriented architecture? (http:/ / www. javaworld. com/ javaworld/ jw-06-2005/ jw-0613-soa. html) (eminglês). Página visitada em 4 de junho de 2007.

[6] Bobby Woolf. Introduction to SOA governance (http:/ / www. ibm. com/ developerworks/ library/ ar-servgov/ ) (em inglês). Página visitadaem 4 de junho de 2007.

[7] OASIS. Reference Model for Service Oriented Architecture 1.0 (http:/ / www. oasis-open. org/ committees/ download. php/ 19679/ soa-rm-cs.pdf) (em inglês). Página visitada em 4 de junho de 2007.

[8] Chris Harding, The Open Group. Achieving Business Agility through Model-Driven SOA (http:/ / www. ebizq. net/ topics/ soa/ features/ 6639.html). Página visitada em 4 de junho de 2007.

[9] Rich Rogers. Reuse engineering for SOA (http:/ / www. ibm. com/ developerworks/ webservices/ library/ ws-reuse-soa. html). Página visitadaem 4 de junho de 2007.

[10] http:/ / www. ibmpressbooks. com/ bookstore/ product. asp?isbn=0131870025& rl=1[11] http:/ / www. research. ibm. com/ journal/ sj44-4. html[12] http:/ / www. oracle. com/ technology/ tech/ soa/ index. html[13] http:/ / www. portalbpm. com. br[14] http:/ / eaiseebeyond. blogspot. com[15] http:/ / www. aqueleblogdesoa. com. br

Análise de pontos de funçãoAnálise de Pontos de Função (APF) é uma técnica para a medição de projetos de desenvolvimento de software,visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a funcionalidadeimplementada, sob o ponto de vista do usuário. A medida é independente da linguagem de programação ou datecnologia que será usada para implementação.Sob esse contexto, os objetivos da APF são:•• medir a funcionalidade solicitada pelo usuário, antes do projeto de software, de forma a estimar seu tamanho e seu

custo;•• medir projetos de desenvolvimento e manutenção de software, independentemente da tecnologia utilizada na

implementação, de forma a acompanhar sua evolução;•• medir a funcionalidade recebida pelo usuário, após o projeto de software, de forma a verificar seu tamanho e

custo, comparando-os com o que foi originalmente estimado;As organizações podem aplicar a Análise de Pontos por Função como:•• uma ferramenta para determinar o tamanho de pacotes de software adquiridos, através da contagem de todos os

Pontos por Função incluídos no pacote;•• uma ferramenta para apoiar a análise da qualidade e da produtividade;•• um mecanismo para estimar custos e recursos envolvidos em projetos de desenvolvimento e manutenção de

software;•• um fator de normalização para comparação de software.

Análise de pontos de função 88

LigaçõesA Análise de Pontos de Função (APF) é uma medida de tamanho de claro significado ao nível do negócio. A APFfoi divulgada pela primeira vez por Allan Albrecht da IBM em 1979. A APF quantifica as funções contidas nosoftware em termos significativos para os respectivos usuários. A medida relaciona-se diretamente aos requisitos donegócio que o software pretende tratar. Dessa forma, a APF é imediatamente aplicável a um amplo espectro deambientes e ao longo da vida de um projeto de desenvolvimento, desde a definição inicial dos requisitos até a fase deplena utilização operacional. Também podem ser derivadas outras medidas úteis ao negócio, tais como aprodutividade do processo de desenvolvimento e o custo unitário de suporte ao software.A própria medida em pontos de função é derivada segundo um certo número de etapas. De acordo com um conjuntode critérios padronizados, é atribuído um índice numérico a cada uma das funções do negócio, conforme osrespectivos tipo e complexidade. Tais índices são totalizados, de modo a fornecer uma medida inicial de tamanho, aqual é então normalizada, através da incorporação de um conjunto de fatores relacionados ao software como umtodo. O resultado final é um único número, chamado o índice de Pontos de Função, que mede o tamanho ecomplexidade do produto de software.Em resumo, a técnica de pontos de função fornece uma medida objetiva e comparável que auxilia a avaliação,planejamento, gerência e controle da produção de software.

Ligações externas• International Function Point Users Group (IFPUG) [1]

• The Netherlands Software Metrics users Association (NESMA) [2]

• Brazilian Function Point Users Group (BFPUG, em português) [3]

Referências[1] http:/ / www. ifpug. org/[2] http:/ / www. nesma. nl/ english/[3] http:/ / www. bfpug. com. br/

Servlet 89

Servlet

Ciclo de vida de um componente JSP.

Servlet é um componente como umservidor, que gera dados HTML eXML para a camada de apresentaçãode um aplicativo Web. É basicamenteuma classe na linguagem deprogramação Java que dinamicamenteprocessa requisições e respostas,proporcionando dessa maneira novosrecursos aos servidores. A definiçãomais usada considera-os extensões deservidores. Servlet é um módulo queestende a funcionalidade de umservidor Web, através de módulos deaplicação implementados em Java.

DescriçãoA Java Servlet API (no pacote javax.servlet) proporciona ao desenvolvedor a possibilidade de adicionar conteúdodinâmico em um servidor web usando a plataforma Java.Essa tecnologia disponibiliza ao programador da linguagem Java uma interface para o servidor web (ou servidor deaplicação), através de uma API. As aplicações baseadas no Servlet geram conteúdo dinâmico (normalmente HTML)e interagem com os clientes, utilizando o modelo request/response. Os servlets normalmente utilizam o protocoloHTTP, apesar de não serem restritos a ele.Um Servlet necessita de um container Web para ser executado.

Hierarquia das classes ServletToda classe Servlet é extensão direta ou indireta da classe GenericServlet, que trata dos métodos relacionados a umaServlet genérica. A classe HttpServlet, por exemplo, estende Generic Servlet. Como é específica para o protocoloHTTP, métodos específicos são implementados, como os métodos doPost e doGet.

Exemplo da implementação de um Servlet Hello Worldimport java.io.IOException;

import java.io.PrintWriter;

//Bibliotecas da classe Servlet

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

public class HelloWorld extends HttpServlet {

public void doGet(HttpServletRequest request, HttpServletResponse

response)

throws ServletException, IOException {

Servlet 90

PrintWriter out = response.getWriter();

out.println("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " +

"Transitional//EN\">\n" +

"<html>\n" +

"<head><title>Hello WWW</title></head>\n" +

"<body>\n" +

"<h1>Hello WWW</h1>\n" +

"</body></html>");

}

}

Plataforma JavaPlataforma Java é o nome dado ao ambiente computacional, ou plataforma, criada pela empresa estadunidense SunMicrosystems e vendida para a Oracle depois de alguns anos. A plataforma permite desenvolver aplicativosutilizando qualquer uma das linguagens criadas para a plataforma Java, sendo a linguagem padrão a que leva seupróprio nome: Linguagem Java. Uma grande vantagem da plataforma é a de não estar presa a um único sistemaoperacional ou hardware, pois seus programas rodam através de uma máquina virtual que pode ser emulada emqualquer sistema que suporte a linguagem C++.

A plataformaO universo Java é um vasto conjunto de tecnologias, composto por três plataformas principais que foram criadaspara segmentos específicos de aplicações:• Java SE (Java Platform, Standard Edition). É a base da plataforma; inclui o ambiente de execução e as bibliotecas

comuns.• Java EE (Java Platform, Enterprise Edition). A edição voltada para o desenvolvimento de aplicações corporativas

e para internet.• Java ME (Java Platform, Micro Edition). A edição para o desenvolvimento de aplicações para dispositivos móveis

e embarcados.Além disso, pode-se destacar outras duas plataformas Java mais específicas:• Java Card. Voltada para dispositivos embarcados com limitações de processamento e armazenamento, como

smart cards e o Java Ring.• JavaFX. Plataforma para desenvolvimento de aplicações multimídia em desktop/web (JavaFX Script) e

dispositivos móveis (JavaFX Mobile).

Tecnologias JavaA plataforma Java é constituída de um grande número de tecnologias, cada uma provê uma porção distinta de todo oambiente de desenvolvimento e execução de software. Os usuários finais, tipicamente, interagem com a máquinavirtual Java (Java Virtual Machine, ou JVM) e um conjunto padrão de bibliotecas de classe.Existe um grande número de maneiras de se utilizar uma aplicação Java, incluíndo applets embutidas em páginasweb, aplicativos de uso geral em desktops, aplicativos em aparelhos celulares e em servidores de aplicações paraInternet(Apache Tomcat, Glassfish, JBoss etc).Os desenvolvedores de aplicações em Java utilizam um conjunto de ferramentas de desenvolvimento, o JDK.

Plataforma Java 91

Ambiente de execução JavaUm programa escrito para a plataforma Java necessita de dois componentes para ser executado: a máquina virtualJava, e um conjunto de bibliotecas de classe que disponibilizam um série de serviços para esse programa. O pacotede software que contém a máquina virtual e esta biblioteca de classes é conhecido como JRE (Java RuntimeEnvironment).

Java Virtual MachineO coração da plataforma Java é o conceito de um processador "virtual", que executa os programas formados porbytecodes Java. Este bytecode é o mesmo independentemente do hardware ou sistema operacional do sistema emque o programa será executado. A plataforma Java disponibiliza um interpretador, a JVM, que traduz, em tempo deexecução, o bytecode para instruções nativas do processador. Isto permite que uma mesma aplicação seja executadaem qualquer plataforma computacional que possua uma implementação da máquina virtual.Desde a versão 1.2 da JRE, a implementação da Sun da JVM inclui um compilador just-in-time (JIT). Com estecompilador todo o bytecode de um programa é transformado em instruções nativas e carregado na máquina virtualem uma só operação, permitindo um ganho de desempenho muito grande em comparação com a implementaçãoanterior, onde as instruções em bytecode eram interpretadas uma por vez. O compilador JIT pode ser projetado deacordo com a plataforma ou hardware de destino, e o código que ele gera pode ser otimizado com base naobservação de padrões de comportamento dos programas.Desde a primeira versão, este ambiente de execução vem equipado com gestão automática de memória, realizada porum algoritmo colector de lixo garbage collector, que liberta o programador das tarefas de alocação e libertação dememória, fonte de muitos erros de programação.A plataforma Java não é a primeira plataforma baseada em uma máquina virtual, mas é de longe a mais conhecida ea que alcançou maior sucesso. Anteriormente esta tecnologia era utilizada na criação de emuladores para auxílio aoprojeto de hardware ou de sistemas operacionais. A plataforma Java foi desenhada para ser implementadainteiramente em software, enquanto permitindo a sua migração de maneira fácil para plataformas de hardware detodos os tipos.

Bibliotecas de classesNa maioria dos sistemas operacionais modernos, um corpo formado por código reusável é organizado edisponibilizado para simplificar o trabalho do programador. Este código encontra-se, normalmente, na forma debibliotecas dinâmicas que a aplicação utiliza durante a sua execução. Como a plataforma Java não é dependente dequalquer sistema operacional, as aplicações não podem depender das bibliotecas destes sistemas. Ao contrário, aplataforma Java disponibiliza um grande conjunto padronizado de bibliotecas de classe, que contém praticamente omesmo número de funções encontradas nos sistemas operacionais modernos.Uma classe de biblioteca Java serve a três propósitos dentro da plataforma Java. Como outras bibliotecas padrão,elas disponibilizam ao programador um conjunto de funções bem conhecidas que realizam tarefas comuns, como amanutenção de listas de elementos ou manipulação de strings. Em adição, a biblioteca contém uma interface paratarefas que dependem do hardware e do sistema operacional. Tarefas como acesso a rede e a arquivos são altamentedependentes das capacidades nativas do ambiente. As bibliotecas java.net e java.io implementam o códigonecessário internamente, e disponibilizam uma interface padrão para que as aplicações Java possam executar estastarefas. Finalmente, se alguma plataforma não suportar alguma função que uma aplicação Java necessita, asbibliotecas implementam esta funcionalidade usando os recursos disponíveis, ou disponibilizam um meio consistentepara que a aplicação verifique a presença de determinada funcionalidade.

Plataforma Java 92

LinguagensA palavra Java usualmente é uma referência a linguagem de programação Java, que é a primeira linguagem criadapela Sun Microsystems para a JVM. A segunda linguagem criada pela Sun Microsystems para a JVM é chamada deGroovy, uma linguagem mais dinâmica, inspirada em linguagens como Python, Ruby e Smalltalk. Também existemimplementações para a linguagem Python, a Jython, e para a linguagem Ruby, a JRuby.

Plataformas similaresO sucesso da plataforma Java e o seu conceito write once, run anywhere levaram a outros esforços similares. O maisnotável destes esforços é a plataforma .NET, da Microsoft, que utilizou muitos dos conceitos e inovações daplataforma Java sem, contudo, implementar os recursos de portabilidade entre sistemas operacionais e plataformasque a plataforma Java possui.

Ligações externas• (em inglês) - Página oficial da plataforma Java [1]

Bibliografia• LUCKOW, Décio Heinzelmann; MELO, Alexandre Altair de. Programação Java para a Web [2]: Aprenda a

desenvolver uma aplicação financeira pessoal com as ferramentas mais modernas da plataforma Java. 1 ed. SãoPaulo: Novatec, 2010. 640 p. ISBN 978-85-7522-238-6

Referências[1] http:/ / java. sun. com[2] http:/ / www. javaparaweb. com. br

JavaServer Pages 93

JavaServer PagesJavaServer Pages (JSP) é uma tecnologia utilizada no desenvolvimento de aplicações para Web, similar àstecnologias Active Server Pages (ASP) da Microsoft ou PHP. Por ser baseada na linguagem de programação Java,tem a vantagem da portabilidade de plataforma, que permite a sua execução em diversos sistemas operacionais,como o Windows da Microsoft, Unix e Linux. Esta tecnologia permite ao desenvolvedor de páginas para Internetproduzir aplicações que acessem o banco de dados, manipulem arquivos no formato texto, capturem informações apartir de formulários e captem informações sobre o visitante e sobre o servidor.Uma página criada com a tecnologia JSP, após instalada em um servidor de aplicação compatível com a tecnologiaJava EE, é transformada em um Servlet.São exemplos de servidor compatível com a tecnologia JSP o Tomcat e o Glassfish.

A linguagemEm relação a arquitetura, JSP pode ser visto como uma abstração de alto nível dos Java servlets. Páginas JSP sãocarregadas dentro do servidor e processado a partir de uma estrutura especial do servidor Java, chamada Java EEWeb Application, muitas vezes como um arquivo .war .ear.JSP permite que código Java e certas ações pré-definidas sejam intercaladas com conteúdo de marcação estático,resultando na página sendo compilada e executada no servidor para ser entregue num documento HTML ou XML.As páginas compiladas e qualquer dependência de biblioteca Java usa os bytecodes primeiro que o formato nativo desoftware, e deve assim ser executado com uma JVM, a máquina virtual Java, integrada com o host do sistemaoperacional para prover um ambiente de abstração de plataforma.A sintaxe de JSP é uma mistura de dois tipos básicos de conteúdo: scriptlet elements e markup. Markup étipicamente um padrão HTML ou XML, enquanto os elementos scriptlet são blocos de código Java os quais podemser unidos com o tipo de marcação, markup. Quando a página é requisitada o código Java é executado e sua saída éadicionada, in loco, com o ambiente de marcação para gerar a página final. Códigos JSP devem ser compiladas paracriação das classes bytecodes antes de serem executadas, mas essa compilação é necessária apenas quando é feitauma mudança no código.

Comentários JSPO JSP tem um tipo de comentário próprio, por exemplo: <%-- comentário --%>Nota: este comentário só aparece do lado do servidor, não aparecendo por isso no código-fonte do browser !!

Tags JSPNo JSP existem 5 tags:1 - Declaration tag

Esta tag permite declarar variáveis e métodos. A sua sintaxe é: <%! …mais alguma coisa.. %> Um exemplo,

<%!

private int contador= 0 ;

%>

2 - Expression tag

Esta tag permite mostrar algum resultado. A sua sintaxe é: <%=..algo para mostrar…%> Por exemplo, para mostraro valor da variável contador bastava apenas:

JavaServer Pages 94

<%=contador %>3 - Directive tag

Esta tag permite dar informação sobre a página ao motor JSP. Existe 3 tipos de directivas:page - processa informação para esta página. Existem 11 atributos opcionais. Sintaxe: <%@ page atributo=”valor”%>Include – arquivos para serem incluidos. Sintaxe: <%@ include file=”pagina.jsp” %>Taglib- Define uma biblioteca a ser usada. Precisa de um prefixo e de um url: Sintaxe: <%@ taglib prefix ="prefixo" uri = "taglib.tld" %>4 - Scriplet tag

Todo o código entre <% %> é chamado de scriptlet. Sintaxe: <% …código %>

5 - Action tag

Esta tag tem como principais funcionalidades:1. Acessar e alterar propriedades de JavaBeans (jsp:useBean, jsp:getProperty e jsp:setProperty);2. Redirecionar a requisição para outra página JSP (jsp:forward);3. Uma única tag para a inclusão de applets Java em páginas, independentemente do browser cliente

(jsp:plugin e jsp:fallback).

Ligações externas• Página oficial [1]

• Tutorial em Português sobre JSP [2]

Referências[1] http:/ / java. sun. com/ products/ jsp/[2] http:/ / www. javafree. org/ artigo/ 868717/ JSP-Java-Server-Pages. html

AJAX (programação) 95

AJAX (programação)AJAX (acrônimo em língua inglesa de Asynchronous Javascript and XML[1], em português "Javascript e XMLAssíncronos") é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para tornarpáginas Web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. Foiinicialmente desenvolvida pelo estudioso Jessé James Garret e mais tarde por diversas associações. Apesar do nome,a utilização de XML não é obrigatória (JSON é frequentemente utilizado) e as solicitações também não necessitamde ser assíncronas[2].

DescriçãoAJAX não é um novo modelo para desenvolvimento web. Os navegadores implementam essa tecnologia desde o ano2000(no mínimo). Porém sua popularização nos últimos anos tem também trazido consigo muitas outras melhoriaspara a Web. Tem estimulado a construção de aplicações Web mais dinâmicas e criativas. AJAX não é umatecnologia, mas um conjunto de tecnologias conhecidas trabalhando juntas, cada uma fazendo sua parte, oferecendonovas funcionalidades. AJAX incorpora em seu modelo:• Exposição e interação dinâmica usando o DOM;• Intercâmbio e manipulação de dados usando XML e XSLT;• Recuperação assíncrona de dados usando o objeto XMLHttpRequest e XMLHttpResponse;• JavaScript fazendo a junção entre os elementos.O modelo clássico de aplicação web trabalha assim: a maioria das ações do usuário na interface dispara umasolicitação HTTP para o servidor web. O servidor processa algo, recuperando dados, realizando cálculos,conversando com vários sistemas legados, e então retorna uma página HTML para o cliente. É um modelo adaptadodo uso original da Web como um agente de hipertexto, porém o que faz a web boa para hipertexto nãonecessariamente a faz boa para aplicações de software.Com a popularização de sistemas que funcionam inteiramente na Web e também com o aumento da velocidade dasconexões banda larga, o problema da espera pelo envio e retorno da página inteira se tornou muito mais evidentepara o usuário. Obviamente, se nós estivéssemos projetando a Web a partir do zero para aplicações, não faríamoscom que os usuários esperassem em vão. Uma vez que a interface está carregada, por que a interação do usuáriodeveria parar a cada vez que a aplicação precisasse de algo do servidor? Na realidade, por que o usuário deveria ver aaplicação ir ao servidor toda vez?As principais vantagens das aplicações que utilizam AJAX para determinadas requisições é que os dados trafegadospela rede são reduzidos e o usuário não precisa aguardar a página ser recarregada a cada interação com o servidor.A popularização das tecnologias que o AJAX reúne foi muito importante para a criação do conceito Web 2.0, que atéhoje gera grandes divisões entre os maiores pensadores da Web.Apesar de não possuir nada inovador em sua essência, o uso de AJAX revolucionou a Web inteira, trazendo à tonamuitos conceitos importantes para o desenvolvimento web.

AJAX (programação) 96

Os quatro princípios de AjaxO modelo clássico de aplicação baseado em páginas está relacionado com muitas das estruturas que nós usamos, etambém em nossas maneiras de pensar. Vamos fazer uma análise de alguns minutos para descobrir o que são estassuposições essenciais e como necessitamos repensar estas idéias para entendermos Ajax suficientemente.

O navegador hospeda uma aplicação, e não conteúdoNuma aplicação web clássica baseada em páginas, o navegador é efectivamente um terminal burro. Ele não sabenada sobre o que o utilizador está realmente realizando em suas ações conseqüentes. Todas essas informações sãoretidas no servidor web, tipicamente na sessão do utilizador. Sessões de utilizador no lado servidor são comunsatualmente. Se a aplicação foi escrita em PHP, Plataforma Java, .NET, Ruby on Rails ou outra linguagem utilizadano desenvolvimento de aplicações para Web, a sessão no lado servidor faz parte da API padrão, assim como ocontrole de solicitações, respostas, e tipos de conteúdo (MIME).Quando o utilizador entra ou de outra maneira inicia uma sessão, vários objetos são criados no servidor,representando, por exemplo, a cesta de compras e as credenciais de cliente do utilizador. Ao mesmo tempo, a páginainicial é servida ao navegador, em um fluxo de marcações HTML que mistura um anúncio de apresentação padrão edados específicos do utilizador juntos com o conteúdo, como por exemplo, uma lista de itens exibidos recentemente.Toda vez que o utilizador interage com o sítio, um outro documento é enviado para o navegador, contendo a mesmamistura de cabeçalhos e dados. O navegador retira o documento anterior e exibe o novo, porque ele não sabe que ooutro documento produz um resultado muito semelhante.Quando o utilizador efetua a saída ou fecha o navegador, a aplicação sai e a sessão é destruída. Qualquer informaçãoque o utilizador necessite ver na próxima vez que ele entrar terá que ser passada para a camada de persistência dedados em cada visita. Já em uma aplicação AJAX, parte da lógica da aplicação é movida para o navegador.Neste novo cenário, quando o utilizador entra, um documento mais complexo é entregue ao navegador, uma grandeproporção do qual é código JavaScript. Este documento permanecerá com o utilizador por toda a sessão, ainda queele resolva provavelmente alterar sua aparência consideravelmente, enquanto o utilizador está interagindo com ele.Ele sabe como responder às informações inseridas pelo utilizador e é capaz de decidir se manipula a entrada doutilizador ele mesmo ou se passa uma solicitação para o servidor web (o qual tem acesso ao banco de dados dosistema e outros recursos), ou ainda, se faz uma combinação de ambos.Ele também pode armazenar o estado, porque o documento continua persistindo sobre toda a sessão do usuário. Porexemplo, o conteúdo de uma cesta de compras pode ser armazenado no navegador, em vez de ser armazenado nasessão do servidor.

O servidor fornece dados, e não conteúdoComo observamos, uma aplicação web clássica oferece a mesma mistura de alegorias, conteúdos e dados em todosos passos. Quando nosso usuário adiciona um item na cesta de compras, tudo que precisamos realmente é respondercom o valor atualizado da cesta ou informar se alguma coisa deu errado.Um carrinho de compra baseado em Ajax pode comportar-se de forma mais inteligente, por meio de remessas desolicitações assíncronas ao servidor. O cabeçalho, o histórico de navegação, e outras características do layout dapágina estão todas carregadas, portanto o servidor necessita enviar de volta somente os dados relevantes.Uma aplicação AJAX poderia fazer isto de vários modos, como por exemplo, devolver um fragmento de JavaScript,um fluxo de texto simples, ou um pequeno documento XML. Nós mostraremos em detalhes as vantagens edesvantagens de cada um, mais a frente. É suficiente dizer por agora que qualquer um destes formatos será muitomenor que a mistura de informações devolvida pela aplicação web clássica.Em uma aplicação Ajax, o tráfego tem sua maior intensidade no início, com um largo e complexo cliente sendo entregue em uma única explosão, quando o usuário entra. As comunicações subseqüentes com o servidor são muito

AJAX (programação) 97

mais eficientes, de qualquer forma. Para uma aplicação breve, o tráfego cumulativo pode ser menor em umaaplicação de página web convencional. Mas conforme o tamanho médio do tempo de interação aumentar, o custo delargura de barramento da aplicação Ajax torna-se menor do que sua aplicação clássica equivalente.

A interação do utilizador com a aplicação pode ser flexível e contínuaUm navegador web oferece duas maneiras de enviar entradas de dados para um outro computador: com os enlaces eformulários HTML.Os hyperlinks podem ser carregados com parâmetros CGI (Common Gateway Interface – Interface de ComunicaçãoComum) apontando para páginas dinâmicas ou servlets. Eles podem estar vinculados com imagens e folhas de estilo(CSS) para oferecer uma pequena melhoria na interface, como por exemplo, definir efeitos quando o mouse estiversobre eles.Os controles de formulário oferecem um subconjunto básico de componentes padrões de interface com o usuário:caixas de texto, caixas de checagem e botões de rádio, além de listas de seleção. Entretanto estes controles não sãosuficientes. Não existem controles de seleção em árvores, grades para edição, ou caixas de combinação. Osformulários, assim como os hyperlinks, apontam para URLs residentes no servidor.Alternativamente, os hyperlinks e os controles de formulário podem apontar para funções JavaScript. Isto é umatécnica comum em páginas web para prover uma validação de formulário rudimentar em JavaScript, verificando porcampos vazios, valores fora de intervalo, e assim por diante, antes de submeter os dados para o servidor. Estasfunções JavaScript existem somente enquanto a própria página existe e é substituída quando a página efetuar o seuenvio.Enquanto a página está sendo enviada, o usuário aguarda a sua resposta. A página anterior pode ainda estar visívelpor algum tempo, e o navegador pode até permitir que o usuário clique em qualquer um dos links visíveis, mas seassim for feito, produzirá resultados imprevisíveis e até entornar em uma confusão com a sessão no servidor. Ousuário está normalmente aguardando a página ser atualizada que, frequentemente, possuem quase que as mesmasinformações que lhes foram apanhadas instantes atrás. Adicionando um par de calças à cesta de compras não érazoável modificar as categorias em um nível acima por “roupas masculinas”, “roupas femininas”, “infantis” e“acessórios”.Voltemos ao exemplo do carrinho de compras novamente. Devido ao facto de que nosso carrinho de compras emAjax pode enviar dados assíncronamente, os utilizadores podem soltar os objectos dentro dele tão rápido quanto elespodem clicar. Se o código de nosso carrinho no lado cliente for robusto, ele tratará esta tarefa facilmente, e osusuários podem continuar com o que eles estão fazendo.É claro que não existe nenhum carrinho para colocarmos as coisas, somente um objeto em sessão no servidor. Masos usuários não querem saber sobre objetos de sessão enquanto estão fazendo compras, e a metáfora do carrinhoprovê uma descrição do mundo real mais confortável do que está acontecendo. Troca de contextos entre a metáfora eo acesso direto ao computador é uma distração para usuários. Aguardar uma página ser atualizada levará o usuário àrealidade de estar sentado em um computador por um curto tempo, e nossa implementação em Ajax evita que istoocorra. Fazer compras é uma atividade transitória, mas se considerarmos um domínio de negócios diferente, porexemplo, um cenário de assistência e atendimento intensivo ou uma tarefa de planejamento complexa, então o custode interrupção da seqüência de trabalho em alguns poucos segundos, com uma atualização de página, é algo inviável.A segunda vantagem de Ajax é que podemos associar eventos a um maior número de ações do usuário. Os conceitosmais sofisticados de interface com o usuário, assim como "arrastar e soltar", se tornam praticáveis, trazendo asexperiências dessas interfaces em pé de igualdade com os controles de aplicações desktop. Da perspectiva deusabilidade, esta liberdade é importante não somente porque ela permite exercer nossa imaginação, mas porque nospermite combinar a interação do usuário e as solicitações ao servidor de maneira mais completa.

AJAX (programação) 98

Para comunicar com o servidor em uma aplicação web clássica, necessitamos clicar em um hyperlink ou submeterum formulário, e então aguardar. No entanto, este método interrompe a interação com o usuário. Em contraste, apossibilidade de se comunicar com o servidor em resposta a um movimento ou arraste do mouse, ou até quandodigitamos, habilita o servidor a trabalhar juntamente com o usuário. O Google Suggest é um exemplo muito simplese efetivo disto: responder às teclas pressionadas enquanto ele digita dentro da caixa de pesquisa, e então, comunicarcom o servidor para recuperar e exibir uma lista de possíveis finalizações para as expressões, baseada nas pesquisasfeitas por outros usuários do mecanismo de busca em todo o mundo.

A codificação real requer disciplinaNeste momento, as clássicas aplicações web fazem uso de JavaScript em certas ocasiões, para adicionarcaracterísticas avançadas de um programa, agregando-as nas páginas. O modelo baseado em páginas impedequalquer uma destas melhorias que provoque em um atraso longo demais, limitando sua utilidade. Isto fez com queJavaScript recebesse injustamente, uma reputação de algo banal – por má sorte da linguagem – e não sendo bemvista pelos desenvolvedores sérios.Codificar uma aplicação Ajax é algo completamente diferente. O código que você fornece quando os usuáriosiniciam a aplicação deve executar até que eles encerrem-na, sem interrupção, sem diminuição de velocidade, e semprodução de escapes de memória. Se estivermos mirando no mercado de aplicações poderosas, então temos em vistamuitas horas de intenso uso. Para atingirmos este objetivo, devemos escrever códigos de alto desempenho, emanuteníveis, usando a mesma disciplina e entendimento que é aplicado com sucesso às camadas do servidor.A base de código será tipicamente mais ampla que qualquer código escrito para uma aplicação web clássica. Boaspráticas na construção da base de código se tornam muito importantes. O código deve tornar-se, de preferência,responsabilidade de uma equipe do que apenas um indivíduo, criando edições de manutenibilidade, separações deinteresses, e estilos e padrões de codificação comum. Uma aplicação Ajax, portanto, é uma porção de códigofuncionalmente complexa que comunica eficientemente com o servidor enquanto o usuário continua com seutrabalho. Ela é claramente uma descendência da aplicação clássica baseada em páginas.

Código de exemploO Código a seguir mostra um exemplo do uso do AJAX para enviar e receber informações do servidor usando ométodo GET (crie os arquivos com os nomes em negrito para visualizar o comportamento, e em seguida abra oarquivo exemplo_ajax.html em um navegador atualizado):Arquivo: exemplo_ajax.html

<!DOCTYPE html>

<html lang="pt-br">

<head>

<meta charset="UTF-8" />

<title>Exemplo de Aplicação em ajax</title>

<script src="enviar_Dados.js" />

</head>

<body>

<!--formulário para entrada dos dados.

Quando ele for enviado, o método "enviarDados()" será executado,

e em seguida retornará "false" para evitar que a página seja recarregada.Parâmetros:

remetente.value - valor digitado no elemento com id = remetente

exibicao_dos_dados - objeto com o id = exibicao_dos_dados-->

<form method="get" onsubmit="enviarDados(remetente.value, exibicao_dos_dados); return false;">

<label for="remetente">Digite o seu nome e clique no botão "Enviar":

AJAX (programação) 99

<input type="text" id="remetente" name="remetente" />

<input type="submit" value="Enviar" />

</form>

<!--Espaço em que será mostrado a resposta do servidor-->

<div id="exibicao_dos_dados"> </div>

</body>

</html>

O código a seguir executará a solicitação através do próprio navegador.Arquivo: enviar_Dados.js

//Função que será executada quando o usuário enviar o formulário.

function enviarDados(remetente, saida) {

//Cria um novo objeto XMLHTTPRequest e o armazena na variável

objeto_xhr

var objeto_xhr = new XMLHttpRequest();

//Armazena uma função que será chamada sempre que a propriedade

"readyState" do objeto "objeto_xhr" tiver o seu valor modificado.

objeto_xhr.onreadystatechange = function() {

//Se não ocorrer nenhum erro na solicitação, mostra a resposta

do servidor dentro do elemento HTML "DIV"

if(objeto_xhr.readyState == 4 && objeto_xhr.status == 200) {

saida.innerHTML = objeto_xhr.responseText;

}

//Mensagem que será mostrada se a página solicitada não for

encontrada

else if(objeto_xhr.status == 404) {

saida.innerHTML = "A página solicitada não existe.";

}

//Mensagem que será mostrada enquanto a solicitação está sendo

processada

else if(objeto_xhr.readyState == 1 || objeto_xhr.readyState ==

2 || objeto_xhr.readyState == 3) {

saida.innerHTML = "Por favor, aguarde enquanto a sua

solicitação é processada...";

}

//O texto adicionado após o nome da página(?remetente =

remetente) é o valor que será enviado para o servidor

objeto_xhr.open("GET", "processamento_ajax.php?remetente=" +

remetente, true);

objeto_xhr.send(); //Envia os dados para o servidor

}

}

O arquivo a seguir processará através de um servidor a solicitação do cliente e responderá com um texto simples.Para o processamento dos dados, será necessário ter o programa PHP e um servidor(como o Servidor Apache)instalados e configurados em seu computador.Arquivo: processamento_ajax.php

AJAX (programação) 100

<?php

//armazena o nome recebida do formulário pelo método GET

$nome_remetente = $_GET["remetente"];

//armazena o horário do servidor

$horario_recebimento = date("H:i:s");

//exibe a resposta na tela

echo "Obrigado, " . $nome_remetente . ". A sua solicitação foi recebida

às " . $horario_recebimento;

//A saída será semelhante ao texto: "Obrigado, Fulano. A sua

solicitação foi recebida às 13:30:40

>

Algumas tecnologias que fazem uso de AJAX•• Google earth•• Google maps•• Facebook•• AWB

Ligações externas• AJAX - Visão Conceitual [3]

• Cloning Google Suggest with AjaxAC [4]

• Ajax Tutorial [5] Get, post, text, XML.• AJAX DWR tutorial [6]

• Wiki de padrões ajax (inglês) [7]

• AJAX Tool [8] Framework de Código Aberto leve para usar ajax com qualquer linguagem de servidor.

Referências[1] Jesse James Garrett (18 de fevereiro de 2005). Ajax: A New Approach to Web Applications (http:/ / www. adaptivepath. com/ ideas/ essays/

archives/ 000385. php). AdaptivePath.com. Página visitada em 21 de março de 2012.[2] Chris Ullman. In: wrox. Beginning Ajax (http:/ / www. wrox. com/ WileyCDA/ Section/ id-303217. html). [S.l.: s.n.]. ISBN

978-0-470-10675-4. Página visitada em 21 de março de 2012.[3] http:/ / www. w3schools. com/ ajax/ default. asp[4] http:/ / www. phpriot. com/ d/ articles/ php/ application-design/ google-suggest-ajaxac/ index. html[5] http:/ / www. xul. fr/ en-xml-ajax. html[6] http:/ / soaagenda. com/ journal/ articulos/ el-mejor-ejemplo-dwr-o-el-mejor-tutorial-dwr/[7] http:/ / ajaxpatterns. org/[8] http:/ / code. google. com/ p/ easyajaxtool/

JavaServer Faces 101

JavaServer FacesJavaServer Faces (JSF) é um framework MVC de aplicações Web baseado em Java que se destina a simplificar odesenvolvimento de interfaces de usuário baseadas em web.O JavaServer Faces ganhou expressão na versão 1.1 quando implementado pela comunidade utilizando aespecificação 127 [1] do Java Community Process [2], evidenciando maturidade e segurança.Hoje ele está na versão 2.0 da especificação 252 [3] do JCP. A fundação Apache vem realizando esforços naimplementação da especificação através do projeto MyFaces. O reconhecimento do trabalho é visto por diversasempresas, tanto é que a Oracle doou os fontes do ADF Faces, conjunto de mais de 100 componentes JSF, para oprojeto MyFaces que o denominará de Trinidad.O JSF é atualmente considerado pela comunidade Java como a última palavra em termos de desenvolvimento deaplicações Web utilizando Java, resultado da experiência e maturidade adquiridas com o JSP/Servlet (Model1),Model2 (MVC) e Struts.

Características•• Permite que o desenvolvedor crie UIs através de um conjunto de componentes UIs pré-definidos;•• Fornece um conjunto de tags JSP para acessar os componentes;•• Reutiliza componentes da página;•• Associa os eventos do lado cliente com os manipuladores dos eventos do lado do servidor (os componentes de

entrada possuem um valor local representando o estado no lado servidor);• Fornece separação de funções que envolvem a construção de aplicações Web.•• Utiliza Ajax em alguns de seus componentes tornando alguns processos mais rápidos e eficientes.

Recursos visuaisO framework JSF permite a inserção, via IDE, de:•• Folhas de estilo (CSS);•• Comandos em Java Script;•• Metodologia Ajax.

JSF inclui•• Suporte a internacionalização e acessibilidade;•• Um conjunto padrão de componentes de interface de usuário que possibilitam validação padronizada;•• Duas bibliotecas de etiqueta ("tag libraries") especiais do JavaServer Pages (JSP) para expressar a interface do

JavaServer Faces dentro de uma página JSP;•• Um modelo de eventos do lado servidor ("server-side event model");•• Gerência de estados;•• Managed Beans;•• Linguagem de Expressão Unificada ("Unified Expression Language") para JSP 2.0 e JSF 1.2.

JavaServer Faces 102

Ferramentas de desenvolvimento•• Eclipse•• Java Studio Creator•• JBuilder•• JDeveloper•• MyEclipse•• NetBeans•• Rational Application Developer for WebSphere Software•• Red Hat Developer Studio

Ligações externas• Página JSF da Sun [4]

[1] Java127 (http:/ / www. jcp. org/ en/ jsr/ detail?id=127)[2] JCP (http:/ / www. jcp. org/ en/ home/ index)[3] Java252 (http:/ / www. jcp. org/ en/ jsr/ detail?id=252)[4] http:/ / java. sun. com/ javaee/ javaserverfaces

Bibliografia• LUCKOW, Décio Heinzelmann; MELO, Alexandre Altair de. Programação Java para a Web (http:/ / www.

javaparaweb. com. br): Aprenda a desenvolver uma aplicação financeira pessoal com as ferramentas maismodernas da plataforma Java. 1 ed. São Paulo: Novatec, 2010. 640 p. ISBN 978-85-7522-238-6

Spring FrameworkO Spring é um framework open source para a plataforma Java criado por Rod Johnson e descrito em seu livro"Expert One-on-One: JEE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões deprojeto inversão de controle (IoC) e injeção de dependência.No Spring o container se encarrega de "instanciar" classes de uma aplicação Java e definir as dependências entre elasatravés de um arquivo de configuração em formato XML, inferências do framework, o que é chamado deauto-wiring ou ainda anotações nas classes, métodos e propriedades. Dessa forma o Spring permite o baixoacoplamento entre classes de uma aplicação orientada a objetos.O Spring possui uma arquitetura baseada em interfaces e POJOs (Plain Old Java Objects), oferecendo aos POJOscaracterísticas como mecanismos de segurança e controle de transações. Também facilita testes unitários e surgecomo uma alternativa à complexidade existente no uso de EJBs.Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, comomódulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos.

Spring Framework 103

Ligações externas• (em inglês) Página oficial do projeto [1]

• Spring Framework: Introdução [2]

• Integração Spring Framework e Hibernate [3]

• Guia itexto: o Container de Injeção de Dependências do Spring Framework 3.0 [4]

Referências[1] http:/ / www. springsource. org/[2] http:/ / www. imasters. com. br/ artigo/ 4497/ java/ spring_framework_introducao/[3] http:/ / www. javafree. org/ artigo/ 871470/ Integracao-Spring-e-Hibernate. html[4] http:/ / www. itexto. net/ devkico/ ?p=859

Hibernate

HibernateDesenvolvedor Red Hat

Lançado em 2001 (10–11 anos)

Versão estável 4.1.4 (31 de maio de 2012)

SistemaOperacional

Multiplataforma

Gênero(s) Mapeamento objeto-relacional

Licença LGPL

Página oficial www.hibernate.org [1]

Portal das Tecnologias de informação

O Hibernate é um framework para o mapeamento objeto-relacional escrito na linguagem Java, mas também édisponível em .Net como o nome NHibernate. Este framework facilita o mapeamento dos atributos entre uma basetradicional de dados relacionais e o modelo objeto de uma aplicação, mediante o uso de arquivos (XML) ouanotações Java (veja Annotation_(java)).Hibernate é um software livre de código aberto distribuído com a licença LGPL.

CaracterísticasO objetivo do Hibernate é diminuir a complexidade entre os programas Java, baseado no modelo orientado a objeto,que precisam trabalhar com um banco de dados do modelo relacional (presente na maioria dos SGBDs). Emespecial, no desenvolvimento de consultas e atualizações dos dados.Sua principal característica é a transformação das classes em Java para tabelas de dados (e dos tipos de dados Javapara os da SQL). O Hibernate gera as chamadas SQL e libera o desenvolvedor do trabalho manual da conversão dosdados resultante, mantendo o programa portável para quaisquer bancos de dados SQL, porém causando um pequenoaumento no tempo de execução.Nas questões relacionadas para o gerenciamento de transações e na tecnologia de acesso à base de dados são deresponsabilidade de outros elementos na infraestrutura do programa. Apesar de existirem API no Hibernate parapossuir operações de controle transacional, ele simplesmente delegará estas funções para a infraestrutura na qual foiinstalada.

Hibernate 104

No caso de aplicações construídas para serem executadas em servidores de aplicação, o gerenciamento dastransações é realizado segundo o padrão JTA. Já nas aplicações standalone, o programa delega o tratamentotransacional ao driver JDBC.Hibernate pode ser utilizado em aplicações Java standalone ou em aplicações Java EE, utilizando servlet ou sessõesEnterprise Java Beans.

HistóriaHibernate foi criado por desenvolvedores Java, espalhados ao redor do mundo, e liderado por Gavin King.Posteriormente, JBoss Inc (empresa comprada pela Red Hat) contratou os principais desenvolvedores do programapara fazer o seu suporte.A atual versão do Hibernate é a 4.x, que incorporou características como a nova arquitetura Interceptor/Callback,filtros definidos pelo usuário e anotações JDK 5.0 (Metadados do Java), que substitui os arquivos XML. Hibernate 3também se aproxima das especificações EJB 3.0 e atua como a espinha dorsal das implementações EJB 3.0 emJBoss.

HQLA HQL (Hibernate Query Language) é um dialeto SQL para o Hibernate. Ela é uma poderosa linguagem de consultaque se parece muito com a SQL, mas a HQL é totalmente orientada a objeto, incluindo os paradigmas de herança,polimorfismo e encapsulamento.No Hibernate, você pode escolher tanto usar a SQL quanto a HQL. Escolhendo a HQL, você poderá executar ospedidos SQL sobre as classes de persistência do Java ao invés de tabelas no banco de dados.

Ligações externas• Página oficial [1]

• Hibernate no SourceForge [2]

• Comparação entre Hibernate e TopLink com base Mysql [3]

• Hibernate no JavaFree Wiki [4]

• Pequeno tutorial em Portugues [5]

• Relatórios com Hibernate Annotations [6]

• Entrevista com o Criador do Hibernate [7]

• Tutorial sobre HQL [8]

• Tutorial completo sobre Hibernate [9]

• Primeiro programa no Hibernate [10]

• Introdução ao Hibernate [11]

• Página do NHibernate [12] - Hibernate para a plataforma .NET

Hibernate 105

Referências[1] http:/ / www. hibernate. org/[2] http:/ / sourceforge. net/ projects/ hibernate[3] http:/ / www. patternizando. com. br/ 2011/ 01/

comparacao-de-desempenho-entre-hybernate-e-toplink-para-persistencia-baseada-em-jpa-com-mysql/[4] http:/ / www. javafree. org/ wiki/ hibernate[5] http:/ / www. javafree. org/ artigo/ 3721/ Pequeno-Tutorial-sobre-Hibernate. html[6] http:/ / www. javafree. org/ artigo/ 870555/ RelatorioHibernate-Annotations-+ -JSF-+ -iReport. html[7] http:/ / www. javafree. org/ artigo/ 871457/ Entrevista-com-Gavin-King-o-criador-do-Hibernate. html[8] http:/ / www. hibernate. org/ hib_docs/ v3/ reference/ en/ html/ queryhql. html[9] http:/ / www. visualbuilder. com/ java/ hibernate/ tutorial/[10] http:/ / www. laliluna. de/ first-hibernate-example-tutorial. html[11] http:/ / hibernate. javabeat. net/ articles/ 2007/ 05/ hibernate-orm-framework-introduction/[12] http:/ / www. nhibernate. org/

Web serviceWeb service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Comesta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemasdesenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem àsaplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que étraduzida para uma linguagem universal, o formato XML.Para as empresas, os Web services podem trazer agilidade para os processos e eficiência na comunicação entrecadeias de produção ou de logística. Toda e qualquer comunicação entre sistemas passa a ser dinâmica eprincipalmente segura, pois não há intervenção humana.Essencialmente, o Web Service faz com que os recursos da aplicação do software estejam disponíveis sobre a redede uma forma normalizada. Outras tecnologias fazem a mesma coisa, como por exemplo, os browsers da Internetacedem às páginas Web disponíveis usando por norma as tecnologias da Internet, HTTP e HTML. No entanto, estastecnologias não são bem sucedidas na comunicação e integração de aplicações. Existe uma grande motivação sobre atecnologia Web Service pois possibilita que diferentes aplicações comuniquem entre si e utilizem recursosdiferentes.Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efectuar tarefas simples ou complexasmesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Por outraspalavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação clientepossa operar e extrair os recursos fornecidos pelo Web Service.Os Web Services são identificados por um URI (Uniform Resource Identifier), descritos e definidos usando XML(Extensible Markup Language). Um dos motivos que tornam os Web Services atractivos é o facto deste modelo serbaseado em tecnologias standards, em particular XML e HTTP (Hypertext Transfer Protocol). Os Web Services sãoutilizados para disponibilizar serviços interactivos na Web, podendo ser acessados por outras aplicações usando, porexemplo, o protocolo SOAP (Simple Object Access Protocol).O objectivo dos Web Services é a comunicação de aplicações através da Internet. Esta comunicação é realizada comintuito de facilitar a EAI (Enterprise Application Integration) que significa a integração das aplicações de umaempresa, ou seja, interoperabilidade entre a informação que circula numa organização nas diferentes aplicaçõescomo, por exemplo, o comércio electrónico com os seus clientes e seus fornecedores. Esta interação constitui osistema de informação de uma empresa. E para além da interoperabilidade entre as aplicações, a EAI permite definirum workflow entre as aplicações e pode constituir uma alternativa aos ERP (Enterprise Resource Planning). Com umworkflow é possível optimizar e controlar processos e tarefas de uma determinada organização.

Web service 106

PadrãoO W3C, OASIS são as instituições responsáveis pela padronização dos Web Services. Empresas como IBM eMicrosoft, duas das maiores do setor de tecnologia, apoiam o desenvolvimento deste padrão.Segundo o W3C (World Wide Web Consortium) um Web Service define-se como: um sistema de softwareprojectado para suportar a interoperabilidade entre máquinas sobre rede.Tem uma relação descritiva num formato machine-processable, especificamente WSDL (Webservice DescriptionLanguage).Outros sistemas interagem com o Web Service usando as mensagens SOAP, tipicamente sobre HTTP com XML najunção com outros standards da Web.

TecnologiasAs bases para a construção de um Web service são os padrões XML e SOAP. O transporte dos dados é realizadonormalmente via protocolo HTTP ou HTTPS para conexões seguras (o padrão não determina o protocolo detransporte). Os dados são transferidos no formato XML, encapsulados pelo protocolo SOAP.

SegurançaMuitas empresas temiam, no passado, prover funcionalidades na Internet devido ao medo de expor seus dados. Mascom advento dos Web Services elas podem publicar serviços de forma simples e que são totalmente isolados da basede dados.A segurança dos Web Services é um dos pontos fracos desta tecnologia. O problema não é a falta de mecanismos desegurança mas sim a falta de consenso em qual deve ser o mecanismo a ser adaptado pela tecnologia Web Service,As questões mais relevantes na segurança são as seguintes: - Autenticidade (ter a certeza que uma transacção do WebService ocorreu entre o servidor e seu cliente; - Privacidade (todas as mensagens trocadas entre o servidor e o clientenão são interceptadas por uma pessoa não autorizada); - Integridade (as mensagens enviadas tanto pelo servidor aocliente, como o contrário, devem permanecer inalteradas).A seguir, descrevem-se os principais mecanismos de segurança.

SSLO SSL (Secure Socket Layer) [Netscape 1996] quando aplicado a pequenos dispositivos oferece autenticação,integridade de dados e privacidade de serviços. Assim, tornou-se possível enviar informação confidencial utilizandoum mecanismo de segurança SSL sob HTTP também conhecido como HTTPS (Hypertext Transfer Protocol Secure).Este mecanismo protege informações confidenciais e é fácil de ser configurado. Tem como desvantagem ser maislento do que as transacções HTTP não cifradas pelo que não é adequado para taxas de transferências de dadoselevadas. Por ser um mecanismo de proteção no nível de transporte, apresenta restrições para ser aplicado emaplicações webservices, pois o SSL não permite criptografia de parte da informação nem o uso de sessões segurasentre mais de duas partes, uma vez que seu funcionamento se baseia em uma arquitetura de transporte fim-a-fim.

Xml signatureA XML Signature [IETF e W3C 2000] é uma iniciativa conjunta da IETF (Internet Engineering Task Force) e doW3C para especificar uma sintaxe XML e regras de processamento para criação e representação de assinaturadigital. As vantagens na utilização da XML Signature, ao contrário de outras normas de assinaturas digitais, estãobaseadas na independência da linguagem de programação, fácil interpretação humana e independência do fabricante.Esta tecnologia também permite assinar digitalmente subconjuntos de um documento XML.

Web service 107

Xml encryptionA XML Encryption [IETF e W3C 2002] especifica um processo para cifra de dados e sua representação em formatoXML. Os dados podem ser dados arbitrários (incluindo um documento XML), elementos XML ou conteúdos deelementos XML. Um documento XML que utiliza a XML Encryption pode ser visto por qualquer utilizador, masapenas o proprietário da chave de descodificação conseguirá compreender o conteúdo codificado.

Ws-securityO WS-Security (Web Services Security) é uma iniciativa conjunta de empresas como Microsoft, IBM e Verisigndestinada ao uso da XML-Signature e da XML-Encryption para fornecer segurança às mensagens SOAP. OWS-Security é um esforço destinado a fazer com que os Web Services trabalhem melhor em um ambiente global. OWS-Security também inclui alguns importantes componentes como encaminhamento, confiança e tratamento detransações.

SamlO SAML (Security Assertion Markup Language) [OASIS 2001] é um padrão emergente para a troca de informaçãosobre autenticação e autorização. O SAML soluciona um importante problema para as aplicações da próximageração, que é a possibilidade de utilizadores transportarem seus direitos entre diferentes Web Services. Isto éimportante para aplicações que tencionam integrar um número de Web Services para formar uma aplicaçãounificada.

Limitações associados aos Web ServicesApesar da sua grande popularidade [carece de fontes?] e relativa simplicidade [carece de fontes?], o SOAP tem váriaslimitações, que por sua vez afetam os Web Services diretamente, por dependerem de tais recursos.As limitações são descritas em seguida:• Segurança e privacidade — nenhuma das versões do SOAP define qualquer tipo de segurança. Isto é devido ao

SOAP utilizar HTTP, mas para implementar mecanismos de segurança no nível da transporte pode utilizar oprotocolo SSL no HTTP (também conhecido como HTTPS) para garantir a confidencialidade, a integridade e aautenticação do cliente, do servidor e da comunicação cifrada. Como não existe um suporte para segurança, queinclui a privacidade, nas normas que compõem os Web Services, tem levado cada projeto a procurar diferentessoluções para resolver o problema da segurança o que se torna incompatível com a promessa de implementar umanormalização a nível global.

• Mensagens e encaminhamento — para suportar as funcionalidades das mensagens assíncronas tradicionais• Qualidade de serviço e confiabilidade — para garantir tempos de resposta e detectar exceções• Processamento transaccional — para suportar comunicação transaccional, para associar essa comunicação

transaccional com as transacções locais e para participar em transacções distribuídas• Gestão — para controlar o estado e comportamento dos Web Services• Desempenho — para optimizar a execução dos Web Services que tem implicações ao nível do desenho das

aplicações, chamadas remotas, características da rede e armazenamento/processamento dos documentos• Interoperabilidade — suportar a interoperação sem problemas é o grande objetivo dos Web Services e do SOAP,

ou seja, fornecerem uma plataforma de integração entre aplicações e diferentes linguagens e implementados emqualquer sistema operacional.

Assim, esta tecnologia seria uma tecnologia normalizada, mas, no entanto, existem algumas incompatibilidades entre os WSDL´s disponibilizados entre os diferentes fornecedores. A exemplo da especificação, ao que refere-se ao binding [1], podem ser implementados de diferentes maneiras, causando um conflito de como fazer a interpretação.

Web service 108

Alguns fazem tal qual a especificação, relacionando e declarando todos os métodos e objetos complexos de formaexplícita, enquantos outros fornecedores não o fazem desta forma, tornando-os assim, incompatíveis.

Integração de sistemasMuitas pessoas consideram que os Web services corrigem um grande problema da informática: a falta de integraçãode sistemas.Os Web services permitem que a integração de sistemas seja realizada de maneira compreensível, reutilizável epadronizada.É uma tentativa de organizar um cenário cercado por uma grande variedade de diferentes aplicativos, fornecedores eplataformas.

Tecnologias Utilizadas

Para a representação e estruturação dos dados nas mensagensrecebidas/enviadas é utilizado o XML (eXtensible Markup Language).As chamadas às operações, incluindo os parâmetros de entrada/saída,são codificadas no protocolo SOAP (Simple Object Access Protocol,baseado em XML). Os serviços (operações, mensagens, parâmetros,etc.) são descritos usando a linguagem WSDL (Web ServicesDescription Language). O processo de publicação/pesquisa/descobertade Web Services utiliza o protocolo UDDI (Universal Description,Discovery and Integration).

XML

Extensible Markup Language (XML) é a base em que os Web Services são construídos. O XML fornece a descrição,o armazenamento, o formato da transmissão para trocar os dados através dos Web Services e também para criartecnologias Web Services para a troca dos dados.

A sintaxe de XML usada nas tecnologias dos Web Services especifica como os dados são representadosgenericamente, define como e com que qualidades de serviço os dados são transmitidos, pormenoriza como osserviços são publicados e descobertos. Os Web Services decodificam as várias partes de XML para interagir com asvárias aplicações.

SoapO SOAP (Simple Object Access Protocol) baseia-se numa invocação remota de um método e para tal necessitaespecificar o endereço do componente, o nome do método e os argumentos para esse método. Estes dados sãoformatados em XML com determinadas regras e enviados normalmente por HTTP para esse componente. Nãodefine ou impõe qualquer semântica, quer seja o modelo de programação, quer seja a semântica específica daimplementação. Este aspecto é extremamente importante, pois permite que quer o serviço, quer o cliente que invocao serviço sejam aplicações desenvolvidas sobre diferentes linguagens de programação. Por esta razão, o SOAPtornou-se uma norma aceita para se utilizar com Web Services, uma tecnologia construída com base em XML eHTTP. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, atravésda utilização da linguagem XML e do mecanismo de transporte HTTP ou outro como, por exemplo, SMTP. O SOAPpermite que os documentos XML de envio e de recepção sobre a Web suportem um protocolo comum detransferência de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o transporte de dadospara os Web Services.

Web service 109

Em relação a Web, o SOAP é um protocolo de RPC que funciona sobre HTTP (ou SMTP, ou outro) de forma aultrapassar as restrições de segurança/firewalls normalmente impostas aos sistemas clássicos de RPC (RMI, DCOM,CORBA/IIOP) suportando mensagens XML. Em vez de usar HTTP para pedir uma página HTML para servisualizada num browser, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma resposta, seexistir, através da resposta do HTTP. Para assegurar correctamente a transmissão da mensagem de XML, o servidorde HTTP, tais como Apache ou IIS (Microsoft Internet Information Server), recebe mensagens SOAP e deve validare compreender o formato do documento XML definido na especificação SOAP v1.1.

WsdlÉ a sigla de Web Services Description Language, padrão baseado em XML para descrever o serviço como no COM,onde ele traz os métodos do Web Service. Funciona como uma espécie de "TypeLibrary" do Web Service, além deser usado para a validação das chamadas dos métodos.O WSDL (Web Services Description Language) é uma especificação desenvolvida pelo W3C que permite descreveros Web Services segundo um formato XML.O WSDL é extensível para permitir a descrição dos serviços e suas mensagens, independentemente dos formatos demensagem e dos protocolos de rede que sejam usados. No entanto, é comum usar-se o MIME (Multipurpose InternetMail Extensions) e o HTtp://SOAP.O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML, este providencia adocumentação necessária para se chamar um sistema distribuído e o procedimento necessário para que estacomunicação se estabeleça. Enquanto que o SOAP especifica a comunicação entre um cliente e um servidor, oWSDL descreve os serviços oferecidos.

UddiProtocolo desenvolvido para a organização e registro de Web Services.O UDDI (Universal Description Discovery and Integration) é uma iniciativa em desenvolvimento no âmbito doconsórcio industrial UDDI promovido originalmente pela IBM, Microsoft e Arriba, com objectivo de acelerar ainteroperabilidade e utilização dos Web Services, pela proposta de um serviço de registro de nomes de organizaçõese de descrição do serviço.Um registro UDDI contém três tipos de informação:•• informações gerais de cada organização, tais como o nome, morada, telefone e contactos;•• informações de organizações e serviços por categorias de negócios;•• informações técnicas sobre os serviços providenciados pelas organizações.O UDDI providencia três funções principais, conhecidas como publicação, descoberta e ligação:1) publicação: permite que uma organização divulgue o(s) seu(s) serviço(s); 2) descoberta: permite que o cliente doserviço, procure e encontre um determinado serviço; 3) ligação (bind): permite que o cliente do serviço, possaestabelecer a ligação e interagir com o serviço.

Web service 110

Ws-iÉ o consórcio que garante a integração entre os Web Services para garantir sempre que os Web Services possam"conversar entre-si".

Iniciativas em cursoO sucesso que os Web Services possam vir a apresentar passa necessariamente pela vontade da indústria, pelapartilha e abertura dos processos de normalização e das próprias especificações daí resultantes. Parte significativadesse processo tem sido desenvolvida no âmbito do W3C. No entanto, dever-se-á também referir outros esforços econsórcios que têm vindo a ser desenvolvidos, designadamente o UDDI, o ebXML, ou o XML/EDI. Por exemplo, oebXML é um esforço patrocinado pela UN/CEFACT e pela OASIS, cujo objectivo é a produção de um conjunto deespecificações para permitir colaborações de negócio electrónico. O standard ebXML pode ser visto como umaextensão às funcionalidades de descrição, publicação e descoberta de serviços (definidas no âmbito do UDDI), aotratar os seguintes aspectos: como especificar os processos de negócio; como identificar os Web Servicesparticipantes e respectivas colaborações; ou, que padrões de negociação existem na colaboração entre osparticipantes. Estes aspectos, são tratados nomeadamente nas seguintes especificações:1) esquemas para especificação de processos de negócio, BPSS (business process specification schema); 2) acordosde protocolos de colaboração, CPA (collaboration protocol agreement); 3) ou perfis de protocolos de colaboração,CPP (collaboration protocol profile).

Contribuição das empresasAs principais empresas, para além de promoverem e participarem activamente nos vários consórcios denormalização, têm vindo a incorporar nas suas próprias infra-estruturas de desenvolvimento e suporte de aplicaçõesimplementações das normas ligadas aos Web Services. Entre outras, merece referência a plataforma da Microsoft,".Net", da Sun, "Java ONE (Open Net Environment)", da Hewlett-Packard, "e-speak" e da IBM, "IBM WebServices".

Evolução dos Web Services

Novos Modelos de NegócioSó o futuro dirá quem tem razão: se os cépticos ou conservadores, se os que arriscam e concretizam a sua visão. Como conceito dos Web Services talvez o mais importante nem seja a tecnologia em si, mas toda uma discussão à voltados factores económico-políticos que este paradigma poderá suscitar, bem como os modelos de negócio que poderãoemergir.Parece natural a emersão de novos portais, não para as pessoas consultarem e usarem, mas para as aplicações, i.e.,para os serviços se registarem/publicarem de modo a tornarem-se conhecidos, descobertos e usados. Esses portais deserviços (tecnicamente consiste em serviços de registos UDDI e/ou ebXML) poderão ser definidos a nível global,regional, para domínios de negócio horizontais ou verticais.

Novos Requisitos TecnológicosNo entanto e naturalmente, novos problemas e requisitos tecnológicos são colocados com o conceito dos WebServices. Desde logo, ao nível da modelação destes serviços e dos processos de negócio em que aqueles participam.Aspectos como a composição de serviços, coordenação de fluxos de trabalho, identificação e privacidade, segurança,negociação, contratos e pagamentos, tratamento de excepções, categorização e taxonomias de serviços, etc., deverãoser adequadamente investigados e tratados de forma que este paradigma possa vir a apresentar um largo consenso esucesso.

Web service 111

Vantagens e DesvantagensOs Web Services são modelos que surgiram para o desenvolvimento de aplicações típicas de negócio electrónico,envolvendo e suportando o estabelecimento da colaboração e negociação de forma aberta, distribuída e dinâmicaentre distintos parceiros.Os Web Services podem no futuro representar um sucesso significativo por causa de existir um esforço significativo,por parte da maioria dos parceiros industriais, na normalização das tecnologias envolvidas.As tecnologias subjacentes aos Web Services (tais como HTTP, SOAP, WSDL, UDDI, XML) são abertas,amplamente divulgadas e consensuais. Por outro lado, existe potencial para haver uma real independência daslinguagens de programação (Java, C++, VB, Delphi, C#), das arquitecturas de computadores e sistemas operativos, oque permite uma evolução mais suave e económica para este modelo computacional.No entanto, existe críticas que demonstram medos ou falsas expectativas que os investimentos em Web Servicespodem suscitar. Uma dessas críticas diz respeito ao facto do SOAP é menos eficiente do que os sistemas de RPCexistentes. Por exemplo, as mensagens (com os respectivos envelopes e descrição de tipos) trocadas entre as partessão descritas em formato de texto/XML enquanto que nos sistemas clássicos de RPC são trocadas em formatobinário.No entanto, esta desvantagem é compensada significativamente pela facilidade de interoperação entre os serviços,sem os problemas conhecidos de segurança/firewalls, e pela facilidade de se esconder os detalhes proprietários dasinfra-estruturas de suporte..

Ligações externas• Web services em Java. Construindo, disponibilizando e acessando Web Services via J2SE e J2ME [2]

• Web Services com NetBeans [3]

• Web Services no devedge.mozilla.org [4]

• Services.NET [5]

• Portal Nacional da Nota Fiscal Eletrônica [6] (em português)• Página referência para Web Service. O w3c é um consórcio internacional que tenta encontrar um padrão para

protocolos e linguagens usadas na WEB [7]

Referências[1] http:/ / www. w3. org/ TR/ wsdl#_soap:binding[2] http:/ / www. javafree. org/ artigo/ 871485/ Web-Services-Construindo-disponibilizando-e-acessando-Web-Services-via-J2SE-e-J2ME. html[3] http:/ / www. javafree. org/ artigo/ 874362/ Web-Services-com-NetBeans. html[4] http:/ / devedge-temp. mozilla. org/ viewsource/ 2002/ soap-overview/ index_pt_br. html[5] http:/ / asp. net[6] http:/ / www. nfe. fazenda. gov. br/ portal/ Default. aspx[7] http:/ / www. w3. org/ 2002/ ws/

XML 112

XMLXML (eXtensible Markup Language) é uma recomendação da W3Cpara gerar linguagens de marcação para necessidades especiais.

É um dos subtipos da SGML (acrônimo de Standard GeneralizedMarkup Language ou Linguagem Padronizada de MarcaçãoGenérica) capaz de descrever diversos tipos de dados. Seu propósitoprincipal é a facilidade de compartilhamento de informações através dainternet.

Entre linguagens baseadas em XML incluem-se XHTML (formatopara páginas Web), RDF, SDMX, SMIL, MathML (formato paraexpressões matemáticas), NCL, XBRL, XSIL e SVG (formato gráficovetorial). A principal característica do XML, de criar umainfraestrutura única para diversas linguagens, é que linguagensdesconhecidas e de pouco uso também podem ser definidas sem maiortrabalho e sem necessidade de ser submetidas aos comitês depadronização.

Características do XMLEm meados da década de 1990, o World Wide Web Consortium (W3C) começou a trabalhar em uma linguagem demarcação que combinasse a flexibilidade da SGML com a simplicidade da HTML. O princípio do projeto era criaruma linguagem que pudesse ser lida por software, e integrar-se com as demais linguagens. Sua filosofia seriaincorporada por vários princípios importantes:•• Separação do conteúdo da formatação•• Simplicidade e legibilidade, tanto para humanos quanto para computadores• Possibilidade de criação de tags sem limitação• Criação de arquivos para validação de estrutura (chamados DTDs)• Interligação de bancos de dados distintos•• Concentração na estrutura da informação, e não na sua aparênciaO XML é um formato para a criação de documentos com dados organizados de forma hierárquica, como se vê,frequentemente, em documentos de texto formatados, imagens vetoriais ou bancos de dados.Pela sua portabilidade, já que é um formato que não depende das plataformas de hardware ou de software, um bancode dados pode, através de uma aplicação, escrever em um arquivo XML, e um outro banco distinto pode ler entãoestes mesmos dados.

Exemplos

Curriculum VitaeCódigo XML descrevendo um currículo:

<?xml version="1.0" encoding="UTF-8"?>

<curriculo>

<InformacaoPessoal>

<DataNascimento>23-07-68</DataNascimento>

<Nomecompleto>...</Nomecompleto>

XML 113

<Contato>

<Morada>

<Rua>R.Topazio</Rua>

<Num>111</Num>

<Cidade>Porto</Cidade>

<Pais>Portugal</Pais>

</Morada>

<Telefone>9999-9999</Telefone>

<CorreioEletronico>email@email.com</CorreioEletronico>

</Contato>

<Nacionalidade>Portuguesa</Nacionalidade>

<Sexo>M</Sexo>

</InformacaoPessoal>

<objetivo>Atuar na area de TI</objetivo>

<Experiencias>

<Experiencia>

<Cargo>Suporte técnico</Cargo>

<Empregador>Empresa, Cidade - Estado</Empregador>

</Experiencia>

</Experiencias>

<Formacao>Superior Completo</Formacao>

</curriculo>

Receita de pãoEste exemplo demonstra a sintaxe flexível do XML sendo usada para descrever uma receita de pão:

<?xml version="1.0" encoding="ISO-8859-1"?>

<receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">

<titulo>Pão simples</titulo>

<ingredientes>

<ingrediente quantidade="3" unidade="xícaras">Farinha</ingrediente>

<ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente>

<ingrediente quantidade="1.5" unidade="xícaras" estado="morna">Água</ingrediente>

<ingrediente quantidade="1" unidade="colheres de chá">Sal</ingrediente>

</ingredientes>

<instrucoes>

<passo>Misture todos os ingredientes, e dissolva bem.</passo>

<passo>Cubra com um pano e deixe por uma hora em um local morno.</passo>

<passo>Misture novamente, coloque numa bandeja e asse num forno.</passo>

</instrucoes>

</receita>

Onde temos na primeira linha:

<Receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">

"Receita" é o nome principal para o seu documento. Note que a semelhança entre XML e HTML é grande, na 1ªlinha abrimos a tag Receita e na última linha a fechamos, como em HTML, assim se estendendo por todo o exemplo.

XML 114

Vantagens e desvantagensCom relação aos outros "formatos universais para intercâmbio de dados" já propostos e experimentados, o XMLapresenta diversas vantagens técnicas, mas são as vantagens não-técnicas que o tornam um tópico de tão grandeimportância:•• É um padrão "de fato" e formalmente: num universo onde cada desenvolvedor e cada fabricante tem a liberdade

de criar e impor seu próprio formato, a aceitação do XML tem sido vista como o seu maior trunfo• Tem sua origem em uma instituição de padronização das mais abertas e dinâmicas, o W3C• Se baseia na experiência de sucesso do SGML, sendo considerado inclusive o "sucessor da SGML"

Vantagens técnicas•• É baseado em texto simples

Com relação aos formatos não-texto (binários), um debate existe desde os tempos do SGML, mas ainda hoje acomunidade de usuários e desenvolvedores prefere o texto ao binário, e as opções do tipo txt.zip (textocomprimido) tais como o OpenDocument são a saída mais largamente adotada

• Suporta Unicode, permitindo que a maior parte da informação codificada em linguagem humana possa sercomunicada

•• Pode representar as estruturas de dados relevantes da computação: listas, registros, árvores• É auto-documentado (DTDs e XML Schemas): o próprio formato descreve a sua estrutura e nomes de campos,

assim como valores válidos• A sintaxe restrita e requerimentos de parsing tornam os algoritmos de análise mais eficientes e consistentes•• É editável, devido à popularidade do XML nos dias de hoje, com diferentes níveis de automação, em qualquer

ambiente:• Sem automação: editores txt antigos, tais como vi•• Com recurso automático de destaque: a maior parte dos editores txt modernos oferece recursos para destaque

de XML (distinção visual entre tag, atributo e conteúdo)• Com recursos de visualização e controle (folding) da hierarquia: editores txt mais especializados e editores

simples acoplados a navegadores• Com recursos de validação e análise sintática: ferramentas um pouco mais sofisticadas, orientadas a

programadores, tais como as IDEs, ou orientadas a conteúdo, tais como editores XHTML, ambos vem seadaptando para lidar com outros formatos XML, interpretando DTD, XSLT ou XML Schema

Desvantagens técnicasAs desvantagens em geral se restringem às aplicações que não demandam maior complexidade, tais como vetores,listas associativas (chave-valor) e informações relativas a configuração, em que o bom senso estabelece a melhorescolha (entre o XML ou um formato menos popular).O "XML simples" pode ser substituído por formatos mais simples, como properties, YAML, JSON e Simple OutlineXML. Os principais critérios para se avaliar a demanda por um formato mais simples são:• Velocidade: a grande quantidade de informação repetida prejudicando a velocidade de transferência real de

informação (quando esta é transportada na forma de XML)• Editabilidade txt: o arquivo "XML simples" (como se pode ver nos exemplos acima) pode ser bem pouco

intuitivo, dificultando sua edição com editores txt por pessoas leigas, mais ainda no caso de volume de dadosmuito grandes, onde o XML pode sequer ser facilmente editável por pessoas experientes

O formato properties, por exemplo, é mais fácil de ser editado por leigos, por ser apenas uma lista de itens do tipochave-valor, e o JSON é um exemplo de um formato mais prático e rápido em contexto Javascript.

XML 115

O exemplo abaixo equivale ao exemplo da receita de pão e demonstra como um XML, mesmo sendo sintaticamenteválido, pode ficar de difícil leitura quando criado por ferramentas geradoras de código. A interpretação e a edição degrandes arquivos XML não indentados são ainda mais complexas para todos,leigos ou experientes:

<?xml version="1.0" encoding="ISO-8859-1"?><receita nome="pão" tempo_de_preparo="5 minutos"

tempo_de_cozimento="1 hora"><titulo>Pão simples</titulo><ingredientes><ingrediente quantidade="3"

unidade="xícaras">Farinha</ingrediente><ingrediente quantidade="7"

unidade="gramas">Fermento</ingrediente><ingrediente quantidade="1.5"

unidade="xícaras" estado="morna">Água</ingrediente><ingrediente quantidade="1"

unidade="colheres de chá" >Sal</ingrediente></ingredientes><instrucoes><passo>Misture

todos os ingredientes,e dissolva bem.</passo><passo>Cubra com um pano e deixe por uma

hora

em um local morno.</passo><passo>Misture novamente, coloque numa bandeja e asse num

forno.</passo>

</instrucoes></receita>

Regras para boa formação de um arquivo XML•• Todo documento XML, além da tag introdutória, deve ter um único elemento (tag) que sirva como raiz para todos

os demais elementos do documento;• XML é case sensitive, portanto difere letras maiúsculas e minúsculas, devendo tomar cuidado com o uso de

CamelCases.• Todo elemento XML deve ser iniciado e fechado, exceto o que define a versão do XML usada e outras definições

de tag única, exemplo <system opera="ligado" onde="aqui" />.• Comentários em XML são iguais ao HTML (<!--comentário-->) .

Ligações externas• Página oficial [1]

• W3Schools [2] (em inglês)

Referências[1] http:/ / www. w3. org/ XML/[2] http:/ / www. w3schools. com/ xml/

XSLT 116

XSLTXSL Transformations, ou XSLT (eXtensible Stylesheet Language for Transformation - linguagem extensível parafolhas de estilo de transformações), é uma linguagem de marcação XML usada para criar documentos XSL que,por sua vez, definem a apresentação dos documentos XML nos browsers e outros aplicativos que a suportem.É importante observar que o documento XSL não altera o documento XML original, ou seja, não cria outrodocumento. Neste sentido, ele (o documento XSLT) atua como as folhas de estilos CSS: apenas determina como obrowser apresenta o documento XML ao qual ele está associado ou anexado (de uma forma bem parecida à usadapara associar uma folha de estilos CSS a um documento (X)HTML). O browser recebe o documento XML original,na íntegra, como ele foi criado. E apresenta-o como o documento XSL determina.Mas há uma diferença importante entre XSLT e CSS: o documento XSL pode adicionar conteúdo à apresentação dodocumento XML no browser, e também pode esconder conteúdo do XML apresentado no browser. Portanto, XSLTpossibilita transformações mais potentes do que as folhas de estilo CSS.Veja um bom exemplo, bem explicado, em http:/ / www. w3schools. com/ xsl/ xsl_transformation. asp. Nestapágina, você pode ver :•• um arquivo XML sem um arquivo XSL associado a ele,•• um arquivo XSL criado para determinar uma apresentação específica do arquivo XML,•• como este arquivo XSL é anexado ao arquivo XML e•• a apresentação do arquivo XML no browser, quando linkado ao arquivo XSL.Olhe o 'source' do arquivo XML no browser, para constatar que ele de fato permanece inalterado.XSLT é parte da especificação XSL (as outras partes sendo XSL-FO e XPath). Como a XML e a HTML, aespecificação XSLT é uma recomendação desenvolvida pela W3C.

Veja TambémXSLXSL-FOXPath

UDDI 117

UDDIUDDI (originado do acrônimo inglês Universal Description, Discovery and Integration) é um serviço de diretórioonde empresas podem registrar (publicar) e buscar (descobrir) por serviços Web (Web Services). UDDI é ainda umframework de plataforma independente (desenvolvido na plataforma .NET) para descrição de serviços,descobrindoas empresas, e integrar os serviços de negócios usando a internet. A comunicação é realizada através do SOAP e asinterfaces web service são descritas por WSDL.[1]

Um serviço de registro UDDI é um Web Service que gerencia informação sobre provedores, implementações emetadados de serviços. Provedores de serviços podem utilizar UDDI para publicar os serviços que eles oferecem.Usuários de serviços podem usar UDDI para descobrir serviços que lhes interessem e obter os metadados necessáriospara utilizar esses serviços.A especificação UDDI define:• APIs SOAP utilizadas para publicar e obter informações de um registro UDDI• Esquemas XML do modelo de dados do registro e do formato das mensagens SOAP• Definições WSDL das APIs SOAP•• Definições de registro UDDI (modelos técnicos - tModels) de diversos sistemas de identificação e categorização,

que podem ser utilizados para identificar e categorizar registros UDDI

Ligações externas• (em inglês) As especificações UDDI [2]

• (em inglês) Introdução a UDDI [3]

[1] (http:/ / www. w3schools. com/ wsdl/ wsdl_uddi. asp), W3C Schools - WSDL and UDDI[2] http:/ / www. oasis-open. org/ committees/ uddi-spec/ doc/ tcspecs. htm[3] http:/ / uddi. xml. org/ uddi-101

Web Services Description Language 118

Web Services Description LanguageO Web Services Description Language (WSDL) é uma linguagem baseada em XML utilizada para descrever WebServices funcionando como um contrato do serviço. Trata-se de um documento escrito em XML que além dedescrever o serviço, especifica como acessá-lo e quais as operações ou métodos disponíveis.Foi submetido ao W3C por Ariba, IBM e Microsoft em março de 2001 sendo que seu primeiro rascunho foidisponibilizado em julho de 2002.A versão atual é 2.0; a versão 1.1 não foi endossada pelo W3C. O WSDL 1.2 foi renomeado para 2.0 e aceita todosos métodos de requisição HTTP (não apenas GET e POST).WSDL é utilizado para definir serviços como uma coleção de endpoints (endereços de rede), ou portas. A definiçãoabstrata de portas e mensagens são separadas do uso concreto de instâncias, permitindo o reuso de definições. Umaporta é definida por associação a um endereço de rede com um binding reutilizável, e uma coleção de portasdefinidas como serviço. Mensagens são descrições abstratas dos dados a serem trocados.Recursos são expostos pelo Web Services Interoperability (WS-I Basic Profile) e framework WSRF.

Objetos de WSDL 1.1Serviço

Pode ser visto como um container para conjunto de funções de sistema que foram expostos a protocolobaseado em web;

PortaNão é nada além da definição do endereço ou ponto de conexão para o Web Service. É representadotipicamente por uma URL simples com http;

BindingEspecifica o tipo de porta, define o estilo de SOAP binding (RPC ou Document) e transporte (protocoloSOAP). Seções de binding também definem as operações;

Tipo de portaO elemento <portType> define um web service, as operações que podem ser executadas, e as mensagenstrocadas para executar a operação;

OperaçãoCada operação pode ser comparada à um método ou chamada de função em uma linguagem de programaçãotradicional. Aqui as ações soap são definidas e o tipo de mensagem é codificado;

MensagemTipicamente, uma mensagem corresponde a uma operação. A mensagem contém as informações necessáriaspara executar a operação;

ElementoDefinidos com a tag <types>, consistem em um nome único e tipo de dado. Seu propósito é descrever um dadoe definir uma tag que delimite os dados enviados;

Arquivos XSDElementos podem ser definidos em um esquema XML - XSD (XML Schema Definition). Pode estar nomesmo arquivo WSDL ou em arquivo separado.

Web Services Description Language 119

Ligações externas• W3C WSDL Specifications [1] (em inglês)• W3Schools WSDL Tutorial [2] (em inglês)• Descrevendo um Web Service - WSDL [3] (em português)

Referências[1] http:/ / www. w3. org/ TR/ wsdl[2] http:/ / www. w3schools. com/ wsdl/ default. asp[3] http:/ / imasters. uol. com. br/ artigo/ 4422/ webservices/ descrevendo_um_web_service_-_wsdl/

SOAP

Estrutura do SOAP.

SOAP, originado do acrônimo inglês Simple Object AccessProtocol, e em português Protocolo Simples de Acesso aObjetos, é um protocolo para troca de informaçõesestruturadas em uma plataforma descentralizada e distribuída.Ele se baseia na Linguagem de Marcação Extensível (XML)para seu formato de mensagem, e normalmente baseia-se emoutros protocolos da Camada de aplicação, mais notavelmenteem Chamada de Procedimento Remoto (RPC) e Protocolo deTransferência de Hipertexto (HTTP), para negociação etransmissão de mensagens. SOAP pode formar a camada basede uma pilha de protocolos de web services, fornecendo umframework de mensagens básico sob o qual os serviços webpodem ser construídos. Este protocolo baseado em XMLconsiste de três partes: um envelope, que define o que está namensagem e como processá-la, um conjunto de regrascodificadas para expressar instâncias do tipos de dadosdefinidos na aplicação e uma convenção para representarchamadas de procedimentos e respostas.

Sua especificação define um framework que provê maneiras para se construir mensagens que podem trafegar atravésde diversos protocolos e que foi especificado de forma a ser independente de qualquer modelo de programação ououtra implementação específica. Por não se tratar de um protocolo de acesso a objetos, o acrônimo não é maisutilizado.Geralmente servidores SOAP são implementados utilizando-se servidores HTTP, embora isto não seja uma restriçãopara funcionamento do protocolo. As mensagens SOAP são documentos XML que aderem a uma especificaçãofornecida pelo órgão W3C.O primeiro esforço do desenvolvimento do SOAP foi implementar RPCs sobre XML.

SOAP 120

DefiniçãoEnvelope das mensagens, regras de codificação, convenção RPC, ligação com protocolos subjacentes.O SOAP tem:•• mecanismo para definir a unidade de comunicação,•• mecanismo para lidar com erros,•• mecanismo de extensão que permite evolução,•• mecanismo entre as mensagens SOAP e o HTTP, representar tipos de dados em XML.

ConcepçãoSimplicidade, independente de vendedor, independente da linguagem, independente do modelo de objetos,independente do transporte.

Ligações externas• W3C SOAP Specifications [1] (em inglês)• W3Schools SOAP Tutorial [2] (em inglês)

Referências[1] http:/ / www. w3. org/ TR/ soap/[2] http:/ / www. w3schools. com/ soap/

Fontes e Editores da Página 121

Fontes e Editores da PáginaUML  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32594357  Contribuidores: 200.181.84.xxx, Adailton, Agil, Albertoivo, Alchimista, André Koehne, André Villeneuve, Canofre,ChristianH, Darwinius, Dayane C., Eamaral, Eduardoferreira, FSogumo, Fredmaranhao, Get It, HecKel, Hyju, Israelrocha, JMGM, Jic, Jml, Joaovollu, Jorge.roberto, Lameiro, Leonardo.stabile,LeonardoG, LeonardoPinheiro, LeonardoRob0t, Leonardorejorge, Manomauricio, Manuel Anastácio, Marcelogomes1, Mca.leite, MelM, Mosca, Mschlindwein, Nuno Tavares, OS2Warp,Parreigadas, PedroPVZ, Porantim, Profvalente, Reporter, Reynaldo, Ricardo Caetano de Moraes, Risthel, Saori, Servant, Spoladore, Tenchi, Vanthorn, Viniciusea, VonNaturAustreVe, Xandi,ce01pc02.netcabo.net, 208 edições anónimas

Diagrama de classes  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30089276  Contribuidores: Alchimista, Bisbis, Chico, Clarice Reis, Colaborador Z, Dvulture, Dwandarti, GOE, GRS73,Get It, Gladstone, JoaoMiranda, Jonatas.oliveira, Jorge, Jorge.roberto, João Sousa, Kim richard, Leonardo.stabile, LeonardoG, Lucianobb1, Nanitobi, Ricardo Caetano de Moraes, Wbrito, Zumg,67 edições anónimas

Diagrama de objetos  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30067405  Contribuidores: Chico, Leonardo.stabile, LeonardoG, Nuno Tavares, Rei-artur, Tschulz, 5 edições anónimas

Diagrama de componentes  Fonte: http://pt.wikipedia.org/w/index.php?oldid=25805210  Contribuidores: Chico, Draftholds, Leonardo.stabile, LeonardoG, Manuel Anastácio, Tumnus, 10edições anónimas

Diagrama de instalação  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32622772  Contribuidores: Albertoivo, Chico, Dvulture, Epinheiro, EuTuga, Get It, Kerr, Leonardo.stabile,LeonardoG, Masmangan, Rafael.afonso, Yanguas, 13 edições anónimas

Diagrama de pacotes  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32622651  Contribuidores: Albertoivo, Chico, Francisco Leandro, Leonardo.stabile, LeonardoG, Wickeeed2k, Yanguas,5 edições anónimas

Diagrama de estrutura composta  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30647000  Contribuidores: Albertoivo, Chico, Dtonon, Leonardo.stabile, LeonardoG, 4 edições anónimas

Diagrama de caso de uso  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30165926  Contribuidores: Dwandarti, Evertondanilo, FSAJ, Fernando S. Aldado, Jorge Morais, Kelovy,Leonardo.stabile, LeonardoG, Luiz Carlos Bernardo Vessosa Junior, Miguel Couto, Mschlindwein, Slashme, Zdtrlik, 31 edições anónimas

Diagrama de transição de estados  Fonte: http://pt.wikipedia.org/w/index.php?oldid=31645858  Contribuidores: Albertoivo, Chico, DalGond, Darwinius, Hyju, José Roberto A. JR.,Leonardo.stabile, LeonardoG, Mauro Babinski, Nuno Tavares, O CoRVo, 11 edições anónimas

Diagrama de atividade  Fonte: http://pt.wikipedia.org/w/index.php?oldid=31371825  Contribuidores: 4you, Amats, Chico, Daimore, Darwinius, Glum, Junior.fcr, Leonardo.stabile, LeonardoG,M.Floriano, Marlosin, Tristacci, 33 edições anónimas

Diagrama de sequência  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30499913  Contribuidores: Adailton, Bjverde, Borg, Chico, Davidrobert, GOE, Leandromaster, Leonardo.stabile,LeonardoG, Luís Felipe Braga, Nuno Tavares, Oritemis, Patrick, Rsakai, Saulolps, Scoep, Sturm, 44 edições anónimas

Diagrama de interatividade  Fonte: http://pt.wikipedia.org/w/index.php?oldid=25727295  Contribuidores: Chico, FSAJ, Fernandoacorreia, Gunnex, Pedrohnog, 9 edições anónimas

Diagrama de colaboração  Fonte: http://pt.wikipedia.org/w/index.php?oldid=29920268  Contribuidores: Acscosta, Albertoivo, Chico, Gunnex, Jorge, Leonardo.stabile, LeonardoG, ManuelAnastácio, Nuno Tavares, OS2Warp, Ramorim, 15 edições anónimas

Diagrama de tempo  Fonte: http://pt.wikipedia.org/w/index.php?oldid=22153798  Contribuidores: Chico, Leonardo.stabile, LeonardoG, 2 edições anónimas

Padrão de projeto de software  Fonte: http://pt.wikipedia.org/w/index.php?oldid=31918492  Contribuidores: Acdcjunior, Bisbis, Brunoslessa, CasperBraske, ChristianH, Colaborador Z,Defender, Dobau, Dvulture, FML, FlavioMattos, Francisco Leandro, Gunnex, Hgfernan, Jorge.roberto, Kaktus Kid, Kleiner, Leofreitas, Leonardo.stabile, LeonardoG, Luizleroy, Luís FelipeBraga, Marcos canbeiro, Misaelsantos, Morebros, Pablodalloglio, Rachmaninoff, Rafael.afonso, Ricardo Ferreira de Oliveira, Rui Silva, Villarinho, ViniGodoy, Wbrito, Yanguas, 72 ediçõesanónimas

Abstract Factory  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30303467  Contribuidores: Agil, Comdanilo, Kleiner, Lameiro, Luís Felipe Braga, Reynaldo, 11 edições anónimas

Builder  Fonte: http://pt.wikipedia.org/w/index.php?oldid=25330211  Contribuidores: Kleiner, Luís Felipe Braga, 12 edições anónimas

Factory Method  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32261923  Contribuidores: Comdanilo, Epinheiro, FabioFromBrasil, Gunnex, Kleiner, Luís Felipe Braga, Mglfilho, 18edições anónimas

Prototype  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30356902  Contribuidores: Amestis, Carloskleber, Elvire, Epinheiro, Evandro Ishy Medeiros, Kleiner, Luís Felipe Braga, Meirarc,Mr.Yahoo!, Reynaldo, Villarinho, Waltercruz, 9 edições anónimas

Singleton  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32103654  Contribuidores: Belanidia, CasperBraske, FML, Fabyo, Kleiner, Leonardo.stabile, Leondil Ribeiro Jr, Luizleao,Luizleroy, Luís Felipe Braga, Lépton, Rafaelplaurindo, Reynaldo, Xurumelous, Érico Júnior Wouters, 75 edições anónimas

Adapter  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30426324  Contribuidores: Adailton, Jon.balbs, Kleiner, Luís Felipe Braga, Ricardo Caetano de Moraes, Xdeco, 8 edições anónimas

Bridge (padrão de projeto de software)  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30345915  Contribuidores: Kleiner, Luís Felipe Braga, MarlonMFD, Nuno Tavares, Yanguas, 2edições anónimas

Composite  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30050748  Contribuidores: Carlos28, Elvire, Gabriel Monteeiro, Gfc, Kleiner, LeonardoG, Luís Felipe Braga, 7 edições anónimas

Decorator  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30911060  Contribuidores: EuTuga, Viniciusilveira, 2 edições anónimas

Façade  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30391665  Contribuidores: Acfborges, Csvila, Daimore, Elvire, Fabiano Tatsch, Fabio Goulart de Matos, Joluchetta, Kleiner, LuísFelipe Braga, 12 edições anónimas

Flyweight  Fonte: http://pt.wikipedia.org/w/index.php?oldid=28153971  Contribuidores: Bcsanches, Kleiner, Leonardo.stabile, Luís Felipe Braga, Pcalvesjr, 3 edições anónimas

Proxy (padrões de projeto)  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30120966  Contribuidores: Belanidia, ChristianH, Tiago de Jesus Neves, 1 edições anónimas

Chain of Responsibility  Fonte: http://pt.wikipedia.org/w/index.php?oldid=28638479  Contribuidores: Bathmann, Bisbis, JamesgotardiCastilho, Kleiner, Luís Felipe Braga, Samiboy, ThiagoSerra, Waltercruz, 4 edições anónimas

Command  Fonte: http://pt.wikipedia.org/w/index.php?oldid=29518631  Contribuidores: Batman, Kleiner, Luís Felipe Braga, Onjacktallcuca, Salamat, Samiboy, Waltercruz, 13 ediçõesanónimas

Interpreter  Fonte: http://pt.wikipedia.org/w/index.php?oldid=27221419  Contribuidores: Arges, Batman, EuTuga, Fabiano Tatsch, Feen, Girino, Hermógenes Teixeira Pinto Filho, Herschel,Kleiner, Luís Felipe Braga, 7 edições anónimas

Iterator  Fonte: http://pt.wikipedia.org/w/index.php?oldid=31604801  Contribuidores: 555, Arges, Edsiddos, Herenvaryar, Kleiner, Leonardo.stabile, LeonardoG, Luís Felipe Braga, 15 ediçõesanónimas

Mediator  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30368264  Contribuidores: 555, Batman, Camponez, Carlos Luis M C da Cruz, Chico, ChristianH, Dcolli, Geowane, Jack Bauer00,Kleiner, Lucacarvalho371, Luís Felipe Braga, OS2Warp, PedR, Usien, 7 edições anónimas

Memento (informática)  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30372462  Contribuidores: 555, Alexmoita, Batman, Elvire, Kleiner, Luís Felipe Braga, Villarinho, Yanguas, 2edições anónimas

Fontes e Editores da Página 122

Observer  Fonte: http://pt.wikipedia.org/w/index.php?oldid=31441613  Contribuidores: Arges, Edemar CS, Jack Bauer00, Kleiner, Leandromartinez, Luís Felipe Braga, Tiago de Jesus Neves, 12edições anónimas

State  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32192047  Contribuidores: Categorizador, Feen, José Joaquim de Moura Ramos, Kleiner, Potapczuk, Reynaldo, 6 edições anónimas

Strategy  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30357089  Contribuidores: Elvire, Kleiner, Luís Felipe Braga, PauloSJR, 3 edições anónimas

Template Method  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32192197  Contribuidores: Daimore, Desempates, Elvire, FSogumo, JCSJesus, Kleiner, 11 edições anónimas

Visitor Pattern  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32189601  Contribuidores: Evoluter, Kleiner, Leonardo.stabile, Marco Martins Costa, Mschlindwein, Villarinho, 3 ediçõesanónimas

MVC  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32439306  Contribuidores: Alchimista, Bisbis, Bonás, ChristianH, Darwinius, Davjoh1, Dmendes, Dpc01, Eamaral, EuTuga, FML, Italomaia, Jborme, Kleiner, Leonardo.stabile, LeonardoG, Leonardob, Lotif, Lourenzo, Luís Felipe Braga, Marianoaloi22, MewRS, Nagaozen, OffsBlink, Onjacktallcuca, Partenon, Patrixsbs,Profvalente, QuarkAWB, Rachmaninoff, Rics, Rodrigo72lopes, Simaopedros, Sirbyte, ThiagoRuiz, Tiago de Jesus Neves, VictorHaine, Vitor Mazuco, Xurumelous, Yone Fernandes, 127 ediçõesanónimas

Service-oriented architecture  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30769640  Contribuidores: Acdcjunior, BioPupil, Braswiki, Chico, Danjo, Eduardoferreira, Epinheiro,Felipe.ferreira, Flcsilva, Gabrielmdias, Gandrade28, Glum, Josir, JotaCartas, Leandromartinez, Leonardo.stabile, LeonardoG, Lijealso, Luís Felipe Braga, Nanyprata, OS2Warp, PedroMCLopes,Rachmaninoff, Rei-artur, Rhe, Risthel, Ruy Pugliesi, Srrs, Vf, Vigia, Wbrito, 70 edições anónimas

Análise de pontos de função  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30639289  Contribuidores: Ajlvermeulen, Alchimista, Blacks, Dayane C., Fabio Rosa, Fabiorosa, Fmendes1,Gunnex, Jo Lorib, Mca.leite, Rui Silva, Tilgon, Villarinho, 35 edições anónimas

Servlet  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32542630  Contribuidores: Ashimono, Fausto.st, Get It, Gladstone, Leofreitas, Luís Felipe Braga, Maxtremus, Mschlindwein,Onjacktallcuca, Rickgauden, Salamat, Tiago de Jesus Neves, Yanborowski, 26 edições anónimas

Plataforma Java  Fonte: http://pt.wikipedia.org/w/index.php?oldid=30669678  Contribuidores: Augusto Men, Bisbis, Brurei, Cidandrade, Darwinius, Helder.wiki, Jesuino master, Josepojr,Lechatjaune, Leonardo.stabile, LuisVeiga, Luís Felipe Braga, Maxtremus, OS2Warp, Pietro Roveri, Porantim, Taikanatur, Wbrito, 26 edições anónimas

JavaServer Pages  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32546837  Contribuidores: 333, Acdcjunior, Airtonbjunior, Beria, Cidandrade, Duranduran, Gdamasceno, Get It, Gladstone,Jonas AGX, Jose felgueiras, Leonardo.stabile, Luís Felipe Braga, OS2Warp, Rafael.afonso, Rennerocha, Viniciusmc, Yakuza, 45 edições anónimas

AJAX (programação)  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32381952  Contribuidores: !Silent, Albmont, Alchimista, Anderson J de Souza, AnibalSolon, Arcf br, Beto Sis,Brunolmfg, Cassiozen, Darwinius, Diogocolla, Djio, Dobau, Dpc01, Edneiiamaguti, Eduardoferreira, ElementoX, Epinheiro, Erick C Ribeiro, Esthonm, Eulinonetto, Euproprio, FML, FSogumo,Felipe Pinto, Fernando S. Aldado, Fábio Soldá, Gdamasceno, Get It, Giro720, Hyju, Insign, Josenaves, Juntas, Lechatjaune, Leonardo.stabile, LeonardoG, Lijealso, LucianoMaia, Luis Otávio,Luís Felipe Braga, Marcio68almeida, Mário Henrique, NGen, Onjacktallcuca, Phillmelon, Pilha, Poncius, Porantim, Profvalente, Rei-artur, Rhe, Ribafs, Rui Silva, Sam, Seduardo, Slade, Sr X,TXiKi, Thom, Villarinho, Viniciusmc, Vitorsilva, Xicouto, 270 edições anónimas

JavaServer Faces  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32438068  Contribuidores: !Silent, 2001:1291:200:8391:0:0:0:2D, Acdcjunior, Alchimista, Bigs, Bonás, Ce3po, ChristianH,Fabiano Tatsch, Gildemax, Jic, Jo Lorib, Juntas, Lechatjaune, Luizp.ribeiro, Luís Felipe Braga, OS2Warp, Onjacktallcuca, Porantim, Rafael.afonso, Ruy Pugliesi, Thiagoprocaci, Zanatto, 55edições anónimas

Spring Framework  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32268006  Contribuidores: Brdag84, Dielson Sales, Gaf.arq, Leonardo.stabile, Luís Felipe Braga, Onjacktallcuca, 15edições anónimas

Hibernate  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32517511  Contribuidores: Acdcjunior, Adailton, Belanidia, Brurei, Camponez, Ce3po, Daltondecamargo, Davemustaine, DielsonSales, Giro720, Helder.wiki, Kascyo, Leonardo.stabile, Luís Felipe Braga, Ricvelozo, Rodrigozanatta, Scholzwiki, Sspecter, Theus PR, Thiagoprocaci, Thom, 46 edições anónimas

Web service  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32194914  Contribuidores: !Silent, Agil, Alchimista, Alquimista Digital, Angelodaniel, Bitolado, Cangou Ira, Chiclops,Choccomond, Colaborador Z, Dbastro, Elementox, FML, FSogumo, Fabiano Tatsch, Gandbranco, IESF MonicaOliveira, Jo Lorib, KalEl, Leonardo.stabile, Luís Felipe Braga, Nikolofski1,OS2Warp, PiRSquared17, RafaAzevedo, Rafael Zanoni, Rjclaudio, Santana-freitas, Stuckkey, Tschis, Tumnus, Wagnerfrancisco, Xicouto, Yanguas, Érico Júnior Wouters, 130 edições anónimas

XML  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32473675  Contribuidores: !Silent, 333, Adailton, Altenorjr, Antonypeople, Beria, Betty VH, Brurei, C goulao, Chris Swift,Danielprovin, Darwinius, Delemon, Diego Queiroz, Dmoises, Dpc01, Ebalter, EliasAmaral, Fabrício Assumpção, Gandbranco, Get It, Gtondello, Gui Pitta, JMGM, JuloCesarGama, Knee427,Krauss, Leonardo.stabile, Leslie, Lijealso, Lombardi.leo, Lufer, Luís Felipe Braga, Marcelo Reis, Maurowil, Maurício I, Ninho, Nuno Tavares, Onjacktallcuca, Osias, Porantim, Profvalente, Rfr,Ricvelozo, Samuel Costa, Scott MacLean, Sr X, Stuckkey, Thegoergen, Vigia, Villarinho, Whooligan, 146 edições anónimas

XSLT  Fonte: http://pt.wikipedia.org/w/index.php?oldid=31526604  Contribuidores: !Silent, Dvulture, Eduardoferreira, MC Markup, Nuno Tavares, Ruy Pugliesi, TXiKi, Vituzzu, 14 ediçõesanónimas

UDDI  Fonte: http://pt.wikipedia.org/w/index.php?oldid=29209412  Contribuidores: Angelodaniel, Clara C., Ebalter, OS2Warp, Profvalente, Tdperez, 3 edições anónimas

Web Services Description Language  Fonte: http://pt.wikipedia.org/w/index.php?oldid=21060519  Contribuidores: Barone, Burmeister, Daemorris, Dwandarti, Leonardo.stabile, Lourenzo,MarceloB, 12 edições anónimas

SOAP  Fonte: http://pt.wikipedia.org/w/index.php?oldid=32231269  Contribuidores: Agil, Claudomiro Jr, Eduardoferreira, Flaviolins, Gdamasceno, Gunnex, Hgfernan, Leonardo.stabile,LeonardoRob0t, Luís Felipe Braga, Missionary, OS2Warp, Osias, Silver Spoon Sokpop, TXiKi, Tiago de Jesus Neves, V1d4l0k4, Yanguas, 25 edições anónimas

Fontes, Licenças e Editores da Imagem 123

Fontes, Licenças e Editores da ImagemFicheiro:Uml hierarchie des diagrammes.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Uml_hierarchie_des_diagrammes.png  Licença: GNU Free Documentation License Contribuidores: Ais523, LeonardoG, LordTFicheiro:UML-usecase-actorInheritance.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:UML-usecase-actorInheritance.png  Licença: Public Domain  Contribuidores:FredThwaitesFicheiro:UML-usecase-usecaserelationships.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:UML-usecase-usecaserelationships.png  Licença: Public Domain  Contribuidores:FredThwaitesFicheiro:UML Use Case diagram.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:UML_Use_Case_diagram.svg  Licença: Creative Commons Attribution-Share Alike Contribuidores: SlashmeFicheiro:semaforo.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Semaforo.jpg  Licença: Public Domain  Contribuidores: SmartkidsFicheiro:Transicaoestado.JPG  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Transicaoestado.JPG  Licença: Public Domain  Contribuidores: MtheusFicheiro:exemplo seq.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Exemplo_seq.jpg  Licença: Creative Commons Attribution-ShareAlike 3.0 Unported  Contribuidores:Akinom, LeonardoG, PerhelionFicheiro:Diagrama de Colaboracao.jpeg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Diagrama_de_Colaboracao.jpeg  Licença: Public Domain  Contribuidores: RamorimFicheiro:Abstract Factory.gif  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Abstract_Factory.gif  Licença: Public Domain  Contribuidores: Giacomo Ritucci, LoStrangolatore, LuísFelipe BragaFicheiro:Builder UML class diagram.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Builder_UML_class_diagram.svg  Licença: Public Domain  Contribuidores: TrashtoyFicheiro:Builder (padrão).png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Builder_(padrão).png  Licença: Public Domain  Contribuidores: B3t, Danim, LoStrangolatore, LuísFelipe BragaFicheiro:Factory Method UML class diagram.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Factory_Method_UML_class_diagram.png  Licença: Public Domain Contribuidores: TrashtoyFicheiro:Factory Method (portuguese).png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Factory_Method_(portuguese).png  Licença: Public Domain  Contribuidores: Luís FelipeBragaFicheiro:Prototype UML (padrão).png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Prototype_UML_(padrão).png  Licença: Public Domain  Contribuidores: Luís Felipe BragaFicheiro:Prototype sample.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Prototype_sample.png  Licença: Public Domain  Contribuidores: Luís Felipe BragaImagem:Singleton.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Singleton.png  Licença: GNU Free Documentation License  Contribuidores: B3t, Bayo, Forseti,LoStrangolatore, Ma-Lik, ManuelGRImagem:Adapter.PNG  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Adapter.PNG  Licença: Public Domain  Contribuidores: Original uploader was Xdeco at pt.wikipediaImagem:Bridge.gif  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Bridge.gif  Licença: Public Domain  Contribuidores: LoStrangolatore, Luís Felipe BragaImagem:ElementoGrafico.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:ElementoGrafico.jpg  Licença: Public Domain  Contribuidores: GfcImagem:Comando.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Comando.jpg  Licença: Public Domain  Contribuidores: GfcFicheiro:FacadeDesignPattern.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:FacadeDesignPattern.png  Licença: GNU Free Documentation License  Contribuidores: Originaluploader was 에멜무지로 at en.wikipediaFile: StateColorido.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:StateColorido.jpg  Licença: Creative Commons Attribution-Sharealike 3.0  Contribuidores: User:JkimFile:LibroActualizado.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:LibroActualizado.jpg  Licença: Creative Commons Attribution-Sharealike 3.0  Contribuidores: User:JkimFile:EstadosState.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:EstadosState.jpg  Licença: Creative Commons Attribution-Sharealike 3.0  Contribuidores: User:JkimImagem:ClassDiagramTemplateMethod.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:ClassDiagramTemplateMethod.png  Licença: GNU Free Documentation License Contribuidores: Carlos Augusto Matos Coutinho Julio Cesar Soares de JesusFicheiro:ModelViewControllerDiagram2.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:ModelViewControllerDiagram2.svg  Licença: Public Domain  Contribuidores:ModelViewControllerDiagram.svg: Traced by User:Stannered derivative work: Davjoh (talk)Imagem:cquote1.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Cquote1.svg  Licença: Public Domain  Contribuidores: Adambro, Editor at Large, Infrogmation, P 96glin, 1edições anónimasImagem:cquote2.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Cquote2.svg  Licença: Public Domain  Contribuidores: Editor at Large, InfrogmationImagem:Find-bind-execute-pt.PNG  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Find-bind-execute-pt.PNG  Licença: Creative Commons Attribution-ShareAlike 3.0 Unported Contribuidores: GlumImagem:Fig3.1.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Fig3.1.jpg  Licença: Public Domain  Contribuidores: SrrsImagem:Fig3.2.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Fig3.2.jpg  Licença: Public Domain  Contribuidores: SrrsImagem:Fig3.3.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Fig3.3.jpg  Licença: Public Domain  Contribuidores: SrrsImagem:Fig3.4.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Fig3.4.jpg  Licença: Public Domain  Contribuidores: SrrsFicheiro:JSPLife.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:JSPLife.svg  Licença: Creative Commons Attribution-Sharealike 3.0  Contribuidores: ZedlanderFicheiro:Webservices.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Webservices.png  Licença: GNU Free Documentation License  Contribuidores: H. VoormannFicheiro:XML.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:XML.svg  Licença: Creative Commons Attribution-Sharealike 2.5  Contribuidores: en:User:DreftymacFicheiro:SOAP.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:SOAP.svg  Licença: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0  Contribuidores: Silver SpoonSokpop

Licença 124

LicençaCreative Commons Attribution-Share Alike 3.0 Unported//creativecommons.org/licenses/by-sa/3.0/