Arquitetura de Software (importncia)- construir base slida para desenvolver aplicaes que

vo gerar renda para empresa ou menos gastos.

Padro de projeto uma estrutura no projeto de software orientado a objeto, cuja
documentao vale a pena ser estudada, visando resoluo de problemas comuns em
projetos de software. So solues prontas que visam minimizar o erro. Para isso, abstrai,
nomeia e identifica os aspectos chaves de uma estrutura de um projeto comum para torna-lo
til a execuo de um objeto OO reutilizvel. Divide-se em estrutural e comportamental,
totalizando 23 padres. So utilizados polimorfismo, herana, modularidade e composio.
Os padres de projeto de software ou padres de desenho de software, tambm muito
conhecido pelo termo original em ingls, Design Patterns, descrevem solues para
problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um
padro de projeto nomeia, abstrai e identifica os aspectos chave de uma estrutura de projeto
comum para torn-la til para a criao de um projeto orientado a objetos reutilizvel.
Os padres de projeto auxiliam no aprendizado com a experincia dos outros, a programar
bem com orientao a objetos, Desenvolver software de melhor qualidade, utilizar um
Vocabulrio comum, Ajuda na documentao e na aprendizagem.
Padres de projeto estruturais so padres que lidam com as estruturas do projeto,
facilitando a comunicao entre suas entidades. Podemos fazer de certa forma uma analogia
a construo civil, onde os padres estruturais seriam responsveis por definir o alicerce da
construo e sua estrutura para conserv-la.
Padres de projetos comportamentais So os padres que esto preocupados com os
algoritmos e as atribuies de responsabilidade entre objetos. Descrevem no s os padres
entre objetos ou classes, mas tambm os padres de comunicao entre eles.
Anti-patterns: Solues pssimas adotadas em projetos, documentao de ms prticas que
comumente usado, mas ineficiente ou contra produtivo em prtica. So divididos em trs
tipos:
- Arquitetura: Problemas comuns nas fases de concepo, projeto e desenho de um sistema.
Ex: Intellectual Violence (usar termos desconhecido pelos demais), Reinventando a Roda
(reimplementar tecnologias j existentes ou fazer do jeito da equipe)
- Desenvolvimento: Problemas comuns na codificao e desenvolvimento de aplicaes. Ex:
Golden Hammer (conceito ou tecnologia aplicado de forma errada para resolver os
problemas)
- Gerncia: Problemas que atingem a gerncia de pessoal e de projetos. Ex: cliente achar que
prottipo pode ser usado como produto final, briga entre equipes.
Padro 3 camadas: neste modelo a lgica de apresentao esta separada em sua prpria
camada lgica e fsica. A separao em camadas lgicas torna os sistemas mais flexveis
permitindo que as partes possam ser alteradas de forma independente, de modo que
atualizaes e correes de defeitos podem ser feitas sem prejudicar as demais camadas.
Por exemplo: alteraes de interface podem ser realizadas sem o comprometimento das
informaes contidas no banco de dados.
- Camada de apresentao - a chamada simplesmente de interface. Esta camada interage
diretamente com o usurio, atravs dela que so feitas as requisies como consultas, por
exemplo.
- Camada de negcio - Tambm chamada de Lgica empresarial, Regras de negcio ou
Funcionalidade. nela que ficam as funes e regras de todo o negcio. No existe uma
interface para o usurio e seus dados so volteis, ou seja, para que algum dado seja
mantido deve ser utilizada a camada de dados.
- Camada de Dados - A terceira camada definida como o repositrio das informaes e as
classes que a manipulam. Esta camada recebe as requisies da camada de negcios e seus
mtodos executam essas requisies em um banco de dados. Alterando o banco de dados
alteraria apenas as classes da camada de dados, e o restante das camadas no seriam
afetados por essa alterao.
Padro MVC no um padro de design de aplicaes, um padro de arquitetura que
descreve uma forma coerente de estruturar a sua aplicao. Ele tambm determina as
responsabilidades de cada parte dessa estrutura e como essas partes se relacionam. Dividese em:
Model manipula os dados
View apresenta os dados ao usurio
Controller recebe e responde as requisies.
Vantagens: Como o modelo MVC gerencia mltiplos visualizadores usando o mesmo modelo
fcil manter , testar e atualizar sistemas mltiplos; muito simples incluir novos clientes
apenas incluindo seus visualizadores e controles; Torna a aplicao escalvel; possvel ter
desenvolvimento em paralelo para o modelo , visualizador e controle pois so independentes.
Desvantagens: Requer uma quantidade maior de tempo para analisar e modelar o sistema;
Requer pessoal especializado.

DAO (Data Access Object): O padro DAO um padro de projeto que abstrai e encapsula os
mecanismos de acesso a dados escondendo os detalhes da execuo da origem dos dados.
Ou seja, permite criar as classes de dados independentemente da fonte de dados ser um BD
relacional, um arquivo texto, um arquivo XML, etc. Para isso, ele encapsula os mecanismos
de acesso a dados e cria uma interface de cliente genrica para fazer o acesso aos dados
permitindo que os mecanismos de acesso a dados sejam alterados independentemente do
cdigo que utiliza os dados.
Padro Singleton: O padro Singleton um padro que ajuda a criar objetos que podem
possuir uma nica instncia no sistema. Quando se possui elementos que so compartilhados
entre mdulos do sistema e no admissvel que haja duas cpias de objetos, pois as
informaes devem ser comuns e a manuteno deve ser compartilhada. Ex: caixa de
dilogos e confirmao de registros.
Observer: um padro de projeto de software que define uma dependncia um-para-muitos
entre objetos de modo que quando um objeto muda o estado, todos seus dependentes sejam
notificados e atualizados automaticamente.
Command: Encapsular uma solicitao como um objeto, permitindo desta forma parametrizar
clientes com diferentes solicitaes, enfileirar ou fazer o registro (log) de solicitaes e
suportar operaes que podem ser desfeitas. Vantagens:
- desacopla o objeto que invoca a operao daquele que sabe como execut-la;
- reduzir a dependncia entre o objeto que chama a operao e o objeto que executa a
operao;
- podem ser manipulados e estendidos como qualquer outro objeto;
- pode ser composto por outros comandos;
- facilidade em acrescentar novos Commands porque no preciso mudar as classes
existentes.
Faade / Facade / Fachada Prover uma interface unificada para o conjunto de interfaces de
um subsistema. Define uma interface de alto nvel que faz um subsistema mais fcil de usar.
Necessidade de estruturar um sistema em subsistema, facilitando o acesso e minimizando a
comunicao e dependncias entre os subsistemas.
Aplicabilidade
Deseja-se fornecer uma interface simples e unificada para um sistema complexo.
Deseja-se desacoplar os subsistemas dos clientes, promovendo-se a independncia e
portabilidade dos subsistemas.
Deseja-se estruturar o sistema em camadas.
Factory Definir uma interface para criar um objeto, mas deixar que subclasses decidam
que classe instanciar. Factory Method permite que uma classe delegue a responsabilidade de
instanciamento s subclasses. [GOF]. Ou seja, ao invs de criar objetos diretamente em
uma classe concreta, ns definimos uma interface de criao de objetos e cada subclasse
fica responsvel por criar seus objetos. Ex: seria como se, ao invs de ter uma fbrica de
carros, ns tivssemos uma fbrica da Fiat, que cria o carro da Fiat, uma fbrica da Ford, que
cria o carro da Ford e etc
Abstract Factory Prover uma interface para criar famlias de objetos relacionados ou
dependentes sem especificar suas classes concretas. Tambm conhecido com Kit.