macro arquitetura de software

Edjalma Queiroz da [email protected]

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

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 ProjetoO 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 ProjetoPadrõ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 ProjetoPadrõ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 ProjetoPadrõ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

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


● 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

Technology