Linguagem e Tcnica de Programao Tecnologia Java

Professor: Hlder Seixas Lima E-mail: helder.seixas@ifnmg.edu.br

Fundamentos da Arquitetura de Software e Arquitetura em 3 Camadas

Arquitetura de Software

A Arquitetura de Software a organizao fundamental de um sistema, incluindo seus componentes, o relacionamento entre esses componentes e com o ambiente e os princpios que definem o desenho e a evoluo dos componentes.

Fonte: IEEE 1471/2000 Recommended Practice for Architectural Description of Software-Intensive Systems

Elementos ao projetar a arquitetura

objetivos

requisitos funcionais e no-funcionais do software sendo projetado; definem o contexto de uma arquitetura tornando-a vivel ou no; diferentes possibilidades de solues e a escolha da soluo eleita; diferentes formas de representar a arquitetura de um sistema; descries possibilitando a construo do sistema.

restries

alternativas

representaes

solues

Decomposio da arquitetura

A arquitetura consiste em projetar as partes de um software e como elas se relacionaro. Ou seja, definir a arquitetura um processo de decomposio das partes do software, tambm chamada de componentes.

Arquitetura em camadas

A decomposio em camadas divide o software conforme funes especficas: interao com o usurio (telas), regras de negcio, persistncia de dados, etc... Visa com a separao em camada evitar cdigos confusos e ilegveis que misturam em um mesmo arquivo cdigos relacionados tela, regras de negcio e persistncia de dados. O grande benefcio reaproveitamento de acoplamento. alcanado cdigo e o baixo

Arquitetura em 3 camadas

Padro de projeto (Design Pattern)

uma experincia estruturada de design, pronta para ser reusada para solucionar problemas recorrentes. Um padro de projeto define elementos, relaes e regras a serem seguidas que j tiveram sua utilidade avaliada em solues de problemas passados. Arquitetura em camadas um padro de projeto.

Padro de projeto (Design Pattern)

Um padro de projeto define:

Nome; Problema; Soluo; Quando aplicar esta soluo; Consequncias.

Data Transfer Object - DTO

Nome: Data Transfer Object Transferncia de Dados);

(Objeto

de

Problema: transferncia dos dados entre as camadas; Soluo: criar classes que representem as entidades do domnio do sistema; Referncia
http://sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/transfer-object/

do

padro:

Data Access Object - DAO

Nome: Data Access Object (Objeto de Acesso aos Dados); Problema: Se precisar mudar a forma persistncia de dados tenho que modificar o sistema inteiro; Soluo: Criar objetos que isolam questes especficas do acesso persistncia dos dados. Referncia:
http://sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/dao/

Business Object - BO

Nome: Business Object (Objeto de Negcios); Problema: As regras de negcio ficam misturadas com regras de tela e acesso ao banco de dados; Soluo: Criar objetos que isolam questes especficas das regras de negcio. Referncia:
http://www.corej2eepatterns.com/Patterns2ndEd/BusinessObject.htm

Singleton

Nome: Singleton (Filho nico) Problema: Restringir a instanciao de objetos de uma classe a um nico objeto. Soluo: Tornar o construtor da classe como privado e permitir acesso ao objeto atravs de um mtodo esttico. Referncia: http://www.javabuilding.com/academy/patterns/singleton.html

Como funciona isso na prtica?

O objetivo agora decompor o cdigo do nosso Sistema Bancrio em 3 camadas aplicando os padres de projetos conhecidos.

APRESENTAO NEGCIO PERSISTNCIA

Arquitetura proposta