7/21/2019 Resumo ESIII
1/2
Arquitetura de Software (importncia)- construir base slida para
desenvolver aplicaes quevo gerar renda para empresa ou menos
gastos!adro de pro"eto # uma estrutura no pro"eto de software
orientado a ob"eto$ cu"adocumentao vale a pena ser estudada$
visando % resoluo de problemas comuns empro"etos de software So
solues prontas que visam minimi&ar o erro !ara isso$
abstrai$nomeia e identi'ca os aspectos caves de uma estrutura de um
pro"eto comum para torna-lotil a e*ecuo de um ob"eto ++
reutili&,vel ivide-se em estrutural e comportamental$
totali&ando ./ padres So utili&ados polimor'smo$ erana$
modularidade e composio+s padres de pro"eto de software ou padres
de deseno de software$ tamb#m muitoconecido pelo termo original em
ingl0s$ esign !atterns$ descrevem solues paraproblemas recorrentes
no desenvolvimento de sistemas de software orientados a ob"etos
1mpadro de pro"eto nomeia$ abstrai e identi'ca os aspectos cave de
uma estrutura de pro"etocomum para torn,-la til para a criao de um
pro"eto orientado a ob"etos reutili&,vel+s padres de pro"eto
au*iliam no aprendi&ado com a e*peri0ncia dos outros$ a
programarbem com orientao a ob"etos$ esenvolver software de melor
qualidade$ utili&ar um2ocabul,rio comum$ A"uda na documentao e
na aprendi&agem!adres de pro"eto estruturais so padres que
lidam com as estruturas do pro"eto$facilitando a comunicao entre
suas entidades !odemos fa&er de certa forma uma analogiaa
construo civil$ onde os padres estruturais seriam respons,veis por
de'nir o alicerce daconstruo e sua estrutura para conserv,-la!adres
de pro"etos comportamentais So os padres que esto preocupados com
os
algoritmos e as atribuies de responsabilidade entre ob"etos
escrevem no s os padresentre ob"etos ou classes$ mas tamb#m os
padres de comunicao entre elesAnti-patterns3 Solues p#ssimas
adotadas em pro"etos$ documentao de m,s pr,ticas que# comumente
usado$ mas # ine'ciente ou contra produtivo em pr,tica So divididos
em tr0stipos3- Arquitetura3 !roblemas comuns nas fases de concepo$
pro"eto e deseno de um sistema4*3 5ntellectual 2iolence (usar
termos desconecido pelos demais)$ 6einventando a 6oda(reimplementar
tecnologias ", e*istentes ou fa&er do "eito da equipe)-
esenvolvimento3 !roblemas comuns na codi'cao e desenvolvimento de
aplicaes 4*37olden 8ammer (conceito ou tecnologia aplicado de forma
errada para resolver osproblemas)- 7er0ncia3 !roblemas que atingem
a ger0ncia de pessoal e de pro"etos 4*3 cliente acar queprottipo
pode ser usado como produto 'nal$ briga entre equipes!adro /
camadas3 neste modelo a lgica de apresentao esta separada em sua
prpria
camada lgica e f9sica A separao em camadas lgicas torna os
sistemas mais :e*9veispermitindo que as partes possam ser alteradas
de forma independente$ de modo queatuali&aes e correes de
defeitos podem ser feitas sem pre"udicar as demais camadas!or
e*emplo3 alteraes de interface podem ser reali&adas sem o
comprometimento dasinformaes contidas no banco de dados- ;amada de
apresentao - < a camada simplesmente de interface 4sta camada
interagediretamente com o usu,rio$ # atrav#s dela que so feitas as
requisies como consultas$ pore*emplo- ;amada de negcio - =amb#m
camada de >gica empresarial$ 6egras de negcio ou?uncionalidade
< nela que 'cam as funes e regras de todo o negcio @o e*iste
umainterface para o usu,rio e seus dados so vol,teis$ ou se"a$ para
que algum dado se"amantido deve ser utili&ada a camada de
dados- ;amada de ados - A terceira camada # de'nida como o
repositrio das informaes e asclasses que a manipulam 4sta camada
recebe as requisies da camada de negcios e seus
m#todos e*ecutam essas requisies em um banco de dados Alterando
o banco de dadosalteraria apenas as classes da camada de dados$ e o
restante das camadas no seriamafetados por essa alterao!adro 2; no
# um padro de design de aplicaes$ # um padro de arquitetura
quedescreve uma forma coerente de estruturar a sua aplicao 4le
tamb#m determina asresponsabilidades de cada parte dessa estrutura
e como essas partes se relacionam ivide-se em3odel B manipula os
dados2iew B apresenta os dados ao usu,rio;ontroller B recebe e
responde as requisies2antagens3 ;omo o modelo 2; gerencia mltiplos
visuali&adores usando o mesmo modelo #f,cil manter $ testar e
atuali&ar sistemas mltiplosC < muito simples incluir novos
clientesapenas incluindo seus visuali&adores e controlesC =orna
a aplicao escal,velC < poss9vel terdesenvolvimento em paralelo
para o modelo $ visuali&ador e controle pois so
independentesesvantagens3 6equer uma quantidade maior de tempo para
analisar e modelar o sistemaC6equer pessoal especiali&ado
7/21/2019 Resumo ESIII
2/2
A+ (ata Access +b"ect)3 + padro A+ # um padro de pro"eto que
abstrai e encapsula osmecanismos de acesso a dados escondendo os
detales da e*ecuo da origem dos dados+u se"a$ permite criar as
classes de dados independentemente da fonte de dados ser um
Drelacional$ um arquivo te*to$ um arquivo E>$ etc !ara isso$ ele
encapsula os mecanismosde acesso a dados e cria uma interface de
cliente gen#rica para fa&er o acesso aos dadospermitindo que os
mecanismos de acesso a dados se"am alterados independentemente
docdigo que utili&a os dados
!adro Singleton3 + padro Singleton # um padro que a"uda a criar
ob"etos que podempossuir uma nica instncia no sistema Fuando se
possui elementos que so compartiladosentre mdulos do sistema e no #
admiss9vel que a"a duas cpias de ob"etos$ pois asinformaes devem
ser comuns e a manuteno deve ser compartilada 4*3 cai*a dedi,logos
e con'rmao de registros+bserver3 # um padro de pro"eto de software
que de'ne uma depend0ncia um-para-muitosentre ob"etos de modo que
quando um ob"eto muda o estado$ todos seus dependentes
se"amnoti'cados e atuali&ados automaticamente;ommand3
4ncapsular uma solicitao como um ob"eto$ permitindo desta forma
parametri&arclientes com diferentes solicitaes$ en'leirar ou
fa&er o registro (log) de solicitaes esuportar operaes que
podem ser desfeitas 2antagens3- desacopla o ob"eto que invoca a
operao daquele que sabe como e*ecut,-laC- redu&ir a depend0ncia
entre o ob"eto que cama a operao e o ob"eto que e*ecuta
aoperaoC
- podem ser manipulados e estendidos como qualquer outro
ob"etoC- pode ser composto por outros comandosC- facilidade em
acrescentar novos ;ommands porque no # preciso mudar as
classese*istentes?aade G ?acade G ?acada B !rover uma interface
uni'cada para o con"unto de interfaces deum subsistema e'ne uma
interface de alto n9vel que fa& um subsistema mais f,cil de
usar@ecessidade de estruturar um sistema em subsistema$ facilitando
o acesso e minimi&ando acomunicao e depend0ncias entre os
subsistemasAplicabilidadeBese"a-se fornecer uma interface simples e
uni'cada para um sistema comple*oBese"a-se desacoplar os
subsistemas dos clientes$ promovendo-se a independ0ncia
eportabilidade dos subsistemasBese"a-se estruturar o sistema em
camadas?actorH B Ie'nir uma interface para criar um ob"eto$ mas
dei*ar que subclasses decidam
que classe instanciar ?actorH etod permite que uma classe
delegue a responsabilidade deinstanciamento %s subclassesJ K7+?L +u
se"a$ ao inv#s de criar ob"etos diretamente emuma classe concreta$
ns de'nimos uma interface de criao de ob"etos e cada subclasse'ca
respons,vel por criar seus ob"etos 4*3 seria como se$ ao inv#s de
ter uma f,brica decarros$ ns tiv#ssemos uma f,brica da ?iat$ que
cria o carro da ?iat$ uma f,brica da ?ord$ quecria o carro da ?ord
e etcAbstract ?actorH B !rover uma interface para criar fam9lias de
ob"etos relacionados oudependentes sem especi'car suas classes
concretas =amb#m conecido com Mit
