Macro Arquitetura de Software

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
Julho de 2013

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
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
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
A Plataforma Java
● Java
● JCP
● Open source e o Java
● Java Virtual Machine

6
JVM: Java Virtual Machine
● Características
● JIT Compiler: compilação em tempo de
execução
● Garbage Collector
● Sytem.gc
● finalizer

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
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
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
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
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
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
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
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
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
. . . Arquitetura
● O diagrama abaixo representa uma
arquitetura de software?

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
. . . Arquitetura
● Enfatiza a separação de interesses:
– Funcionalidade
– Interação

19
. . . Arquitetura
● O diagrama abaixo não representa uma
arquitetura de software.

20
. . . Arquitetura
● Exemplo de Arquitetura

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
. . . 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
. . . Arquitetura
● Escalabilidade e Disponibilidade
● Confiabilidade
● Extensibilidade e manutenabilidade
● Gerenciabilidade

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
. . . 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
. . . Arquitetura
● Cliente-Servidor

27
. . . Arquitetura
● Arquitetura Pipe - Filter

28
. . . Arquitetura
● Dividindo em camadas

29
. . . Arquitetura
● MVC – Model View Controller

30
. . . Arquitetura
● Arquitetura contemporânea e o Cloud

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
. . . 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
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
● 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
● 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
● 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
Projeto prático JAVA EE
● Demonstração de maneira prática:
– partes da arquitetura definida nesta
apresentação

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
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
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.

Macro Arquitetura de Software

Mais conteúdo relacionado

Mais procurados

Semelhante a Macro Arquitetura de Software

Último

Macro Arquitetura de Software