1. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
1
SENAI
Departamento Regional do Estado de Goiás
MACRO ARQUITETURA DE SOFTWARE
COM EXPERIMENTO PRÁTICO EM JAVA
Edjalma Queiroz da Silva
Julho de 2013

2. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
2
Objetivos Gerais
● Revisar conceitos de Orientação a Objetos
● Revisar conceitos de Padrões de Projeto.
● Apresentar um breve histórico da evolução da
arquitetura de software.
● Mostrar a importância que a escolha do padrão
arquitetural exerce na construção de software.
● Demonstrar de maneira prática e em forma de
experimento, um projeto de software Java que
tenha sido aplicado os padrões arquiteturais
adotados no mercado de trabalho, habilitando os
alunos a definirem e utilizarem os padrões
arquiteturais.

3. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
3
Objetivo Específico
● Capacitar o aluno a utilizar os mais
variados tipos de padrões de projeto e
decidir qual arquitetura é a mais
apropriada sob os principais aspectos da
macro aquitetura de software.

4. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
4
Conteúdo Programático
● A plataforma Java
● JVM: Java Virtual Machine
● Orientação a Objetos
● Padrões de Projeto
● Frameworks
● Separação de responsabilidade e Inversão de
Controle
● Arquitetura
● Decisões arquiteturais
● Integração de sistemas na Web

5. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
5
A Plataforma Java
● Java
● JCP
● Open source e o Java
● Java Virtual Machine

6. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
6
JVM: Java Virtual Machine
● Características
● JIT Compiler: compilação em tempo de
execução
● Garbage Collector
● Sytem.gc
● finalizer

7. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
7
Orientação a Objetos
● Orientação à objetos
● Encapsulamento
– JavaBeans e getters e setters
● Polimorfismo
● Herança
● Interface
● Acoplamento e Coesão
● Testes de unidade e TDD
(Desenvolvimento dirigido por Testes)

8. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
8
Padrões de Projeto
● O que é e para que servem?
● Padrões GoF
– Padrões de criação
– Padrões estruturais
– Padrões comportamentais
● Padrões GRASP

9. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
9
Padrões de Projeto
O que é e para que servem?
● O Conceito de padrão de projeto foi criado na década de
70 pelo arquiteto Chistopher Alexander.
● A partir dos conceitos criados por Alexander, os
programadores Kent Beck e Ward Cunningham
propuseram os primeiros padrões de projeto para a
área de ciência da computação.
● Descrevem soluções para problemas recorrentes no
Desenvolvimento de Softwares (Orientado a objetos)
● Cada padrão é composto por um Nome, Definição de
um problema, a solução, quando aplicar esta solução e
suas consequências.
● Visam facilitar a reutilização de soluções de desenho
(Engenharia de Software – fase de concepção)

10. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
10
Padrões de Projeto
Padrões GoF
● São organizados em famílias de padrões: de
criação, estruturais e comportamentais.
● Um padrão “GoF” também é classificado
segundo o seu escopo:
– de classe
● Relacionado com herança e em
tempo de compilação
– de objeto.
● Comportamental e em tempo de
execução

11. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
11
Padrões de Projeto
Padrões GoF
Exemplos
● Exemplos:
– Criação: Abstract Factory, Builder Factory
Method, Prototype, Singleton
– Estrutural: Adpter, Bridge, Composite, Decorator,
Facade, Flyweigth, Proxy
– Comportamentais: Chain of Responsibility,
Command, Interpreter, Iterator, Mediator,
Memento, Observer, State, Strategy, Template
Method, Visitor

12. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
12
Padrões de Projeto
Padrões GRASP
● Consistem de um conjunto de práticas para
atribuição de responsabilidades a classes e objetos
● Alguns padrões GoF implementam soluções
correspondentes com padrões GRASP
● Exemplos: Controlador (Controller), Criador
(Creator),Indireção (Indirection), Especialista na
informação (Information expert), Alta coesão (High
Cohesion), Baixo acoplamento (Loose coupling),
Polimorfismo (Polymorphism), Variações protegidas
(Protected variations), e Invenção pura (Pure
fabrication).

13. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
13
Frameworks
● Captura a funcionalidade comum a várias
aplicações
● As aplicações devem ter algo
razoavelmente grande em comum:
pertencem a um mesmo domínio de
problema
● Várias definições de frameworks

14. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
14
Separação de responsabilidade
e Inversão de Controle
● Gerencie suas dependências através de
injeção
● Considere usar um framework de Injeção
de Dependências
– Spring
● Fábricas e o mito do baixo acoplamento

15. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
15
Arquitetura
● O que é Arquitetura?
– Discussão bem abstrata
– Trata de princípios bem estabelecidos e práticas
mais definidas começam a ser disseminadas.
– Consequência de escolhas
– Define a estrutura do software, que compreende
os componentes com suas propriedades
visíveis externamente e os relacionamentos
entre eles.

16. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
16
. . . Arquitetura
● O diagrama abaixo representa uma
arquitetura de software?

17. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
17
. . . Arquitetura
● Componetes: Cliente, Servidor,
Subsistema, etc.
● Conectores: Iteração entre os
componentes (WS, API, etc)
● Configuração: Grafo de componentes e
conectores ligados, descrevendo uma
estrutura arquitetural.

18. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
18
. . . Arquitetura
● Enfatiza a separação de interesses:
– Funcionalidade
– Interação

19. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
19
. . . Arquitetura
● O diagrama abaixo não representa uma
arquitetura de software.

20. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
20
. . . Arquitetura
● Exemplo de Arquitetura

21. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
21
Arquitetura
● Requisitos
– São as características que o software construído
deve conter.
– Funcionais: Dizem respeito às funcionalidades
do software.
– Não-Funcionais: São inerentes ao negócio –
Tratamento de Exceções, Portabilidade,
Manutenibilidade, Persistência.

22. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
22
. . . Arquitetura
● Performance
– Do ponto de vista da qualidade de
software é a dimensão mais mal tratada
durante o desenvolvimento de um
software.
– “Vamos apenas desenvolver o sistema e
ver o que pode ser feito quanto a
performance”.
– “Colacaremos o software em um
computador com mais capacidade de
processamento”.

23. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
23
. . . Arquitetura
● Escalabilidade e Disponibilidade
● Confiabilidade
● Extensibilidade e manutenabilidade
● Gerenciabilidade

24. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
24
. . . Arquitetura
● Facilita a combinação de abordagens de
reuso de software (Ex.: estilos, Pradrões
de Projeto)
● Possibilita análise da descrição da
arquitetura nas fases iniciais do
desenvolvimento (Ex.: propriedades não
funcionais ou conformidade com um
estilo)
● Facilita a evolução do software
● Permite uma melhor comunicação entre
os stakeholders

25. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
25
. . . Arquitetura
● Estilo Arquitetural
– Consite de um vocabulário de elementos
de projeto e um conjunto de regras de
configuração que governam a
combinação desses elementos.
● Elementos Arquiteturais (de projeto)
– Componentes
– Conectores
● Exemplo de regras de configuração
– Uma camada pode somente se comunicar
com a camada adjacente no estilo
Camadas.

26. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
26
. . . Arquitetura
● Cliente-Servidor

27. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
27
. . . Arquitetura
● Arquitetura Pipe - Filter

28. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
28
. . . Arquitetura
● Dividindo em camadas

29. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
29
. . . Arquitetura
● MVC – Model View Controller

30. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
30
. . . Arquitetura
● Arquitetura contemporânea e o Cloud

31. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
31
Decisões arquiteturais
● Desenvolvimento Web MVC
● Domine sua ferramente de mapeamento objeto
relacional
– JPA
● RMI
– É uma interface de programação que permite
a execução de chamadas remotas no estilo
RPC em aplicações desenvolvidas em
Java.
– É uma das abordagens da plataforma Java
para prover as funcionalidades de uma
plataforma de objetos distribuídos
– Segue arquitetura Cliente-Servidor

32. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
32
. . . Decisões Arquiteturais
● EJB
– É um componente da plataforma JEE que
roda em um container de um servidor de
aplicação.
– Seu principal objetivo consiste em fornecer
um desenvolvimento rápido e simplificado
de aplicações Java, com base em em
componentes distribuídos, transacionais,
seguros e portáveis.

33. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
33
Integração de sistemas na Web
SOA – Service Oriented Architecture
– É um estilo de arquitetura de software cujo princípio
fundamental prega que as funcionalidades
implementadas pelas aplicações devem ser
disponibilizadas na forma de serviços.
– 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íveis através de web services
ou outra forma de comunicação entre aplicações.
– A arquitetura SOA é baseada nos princípios da
computação distribuída e utiliza o paradigma
request/reply para estabelecer a comunicação
entre os sistemas clientes e os sistemas que
implementam os serviços.

34. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
34
Integração de sistemas na Web
● WSDL
– WSDL: é uma linguagem baseada em XML utilizada
para descrever Web Services funcionando como
um contrato do serviço. Trata-se de um documento
escrito em XML que além de descrever o serviço,
especifica como acessá-lo e quais as operações ou
métodos disponíveis.

35. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
35
Integração de sistemas na Web
● POX: Plain Old XML
– Plain Old XML (POX) é um XML básico,
algumas vezes mixada com outras
especificações como namespaces,
Dublin Core, dentre outros.

36. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
36
Integração de sistemas na Web
● REST: arquitetura distribuída baseada em
hipermídia
– Descrever qualquer interface web simples
que utiliza XML e HTTP (ou YAML, JSON,
ou texto puro), sem as abstrações
adicionais dos protocolos baseados em
padrões de trocas de mensagem como o
protocolo de serviços web SOAP.

37. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
37
Projeto prático JAVA EE
● Demonstração de maneira prática:
– partes da arquitetura definida nesta
apresentação

38. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
38
Conclusão
● Em uma arquitetura bem definida, os interesses
estão bem separados e modularizados.
● Reduz o acoplamento do software
● Facilita a manutenibilidade
● Não impede que códigos indevidos sejam
inseridos em pontos não adequados
● Aumenta a semântica no relacionamento entre
os requisitos e o código
● Fornece uma base para as outras fases de
desenvolvimento do software

39. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
39
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
● Larman, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto
orientados a objetos. Porto Algre: Bookman, 2000.
● [Brooks 1987] Brooks Jr, Frederic P. No Silver Bullet: Essence and Accidents of
Software Engineering. Computer. Volume 20, Issue 4. p 10-19. 1987.
● [Fowler 2003] Fowler, Martin. Who Needs an Architect? IEEE Software. Volume 20,
Issue 5. p. 11-13. 2003.
● [SBCARS] Simpósio Brasileiro de Componentes, Arquitetura e Reuso de Software.
Disponível em: <http://wiki.dcc.ufba.br/CBSOFT/SBCARS2010>. Acesso: 01 Nov
2010.
● [IEEE 610] IEEE Std 610.12-1990, IEEE standard glossary of software engineering
terminology. IEEE. 1990.
● [Gamma 1995] 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.
● [Fowler 2006] Martin Fowler. Padrões de Arquitetura de Aplicações Corporativas.
Editora Bookman, 2006. ISBN 8536306386, 9788536306384. 493 páginas.

40. Edjalma Queiroz da Silva
edjalma@ambientinformatica.com.br
40
Bibliografia
● BASS, LEN; CLEMENTS, PAUL; & KAZMAN, RICK. Software Architecture in
Practice, Second Edition. Boston, MA: Addison-Wesley, 2003.
● Doug Lea. Christopher Alexander:An Introduction for Object-Oriented Designers (em
Inglês). Página visitada em 18 de Junho de 2008.
● Kent Beck, Ward Cunningham. Using Pattern Languages for Object-Oriented
Programs (em Inglês). Página visitada em 18 de Junho de 2008.
● 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
● [Wiki 2010-b] WIKIPEDIA. Arquitetura. Disponível em:
<http://pt.wikipedia.org/wiki/Arquitetura>. Acesso: 16 Out 2010.
● [Wiki 2010-c] WIKIPEDIA. MVC. Disponível em: <http://pt.wikipedia.org/wiki/MVC>.
Acesso: 02 Nov 2010.
● [Wiki 2010-d] WIKIPEDIA. Requisito Não-Funcional. Disponível em:
<http://pt.wikipedia.org/wiki/Requisito_n%C3%A3o-funcional>. Acesso: 06 Nov 2010.