arquitetura de sistemas e padroes de projeto - aula 01 - parte 01
DESCRIPTION
Aula 01 da disciplina Análise Orientada a Objetos e Projeto Arquitetural no UNIPAM.TRANSCRIPT
Graduado em Sistemas de Informao (UNIPAM) Mestrado em Cincias da Computao (UFU) Analista de Sistemas Senior Mercado Financeiro Professor FPU UNIPAM Java .NET Scala C/C++
Augusto A. B. Branquinho. 05/05/2012
SUMRIO1. Introduo 2. Arquitetura de Sistemas2.1. Padres Arquiteturais
3. Padres de Projetos3.1. 3.2. 3.3. 3.4. 3.5. GRASP Padres Padres Padres Padres
de Criao Estruturais Comportamentais de Concorrncia
Referncias.com
Arquitetura + Software = ? Software
com Slida Fundaode uma boa arquitetura
Planejamento
Problemas Instvel
em uma arquitetura pobre
Impossvel
de dar suporte Impossvel adicionar novos requisitos Difcil implantao Difcil gerenciamento.com
Padres de Projeto + Software = ? Padres
de Projeto
Problemas
comuns em projetos Solues padronizadas Usado nos mdulos (componentes) Aplicado pontualmente Tornar flexvel a adio de novas funcionalidades Manutenibilidade do projeto/cdigo.com
Sistemas
Distribudos
.com
Um
software deve ser projetado considerando
Usurio (necessidades) Sistema (infraestrutura) Negcio (requisitos) As
REAS so baseadas na soluo e vice-versa
No focar em uma rea especfica
Usurio
Negcio
Sistema.com
Questes Como
que devem ser levantadas na elaborao de uma arquiteturaos usurios iram usar o sistema? Como a aplicao ser implantada e gerenciada em produo? Como a aplicao deve ser projetada para ser flexvel e manutenvel? Quais so as tendncias de arquiteturas que podem afetar a aplicao agora e no futuro?.com
Questes Quais
que devem ser levantadas na elaborao de uma arquiteturaso os atributos de qualidade requeridos? Segurana Performance Concorrncia Internacionalizao Configurao.com
Necessidades
que devem ser
consideradas Expor
a estrutura do sistema mas esconder os detalhes de implementao Abordar todos os casos de uso e cenrios Tentar abordar os requisitos dos Stakeholders Lidar com requisitos funcionais e de qualidade.com
Princpios
chave
Separao
de preocupaes Princpio da responsabilidade nica Princpio do menor conhecimento No duplicar a anlise em mais de um local Projetar apenas o necessrio
.com
Prticas Manter
de Projetos
os padres de projetos No duplicar as funcionalidades Preferir composio em vez de herana Estabelecer um estilo de codificao Estabelecer uma conveno de nomes Manter a qualidade usando tcnicas automatizadas de Anlise de Qualidade Considerar as operaes da aplicao.com
Camadas Separar
(mdulos) da Arquitetura
as camadas pelas preocupaes Explicitar a comunicao entre camadas Baixo acoplamento entre camadas No misturar o tipo de lgica das camadas Interface grfica Processamento Persistncia ... No misturar a formatao de dados entre das camadas.com
Mdulos Um
componente no deve conhecer a implementao de outro componente Definir bem o contrato entre os mdulos Depende da arquitetura Flexibilidade na alterao da forma de comunicao Manter manutenvel a comunicao entre mdulos.com
Consideraes Determinar Determinar
da Arquitetura
Determinar Determinar Determinar
o tipo da aplicao a forma de Deploy as apropriadas tecnologias os atributos de qualidade as preocupaes transversais
Arquitetos
devem realizar provas de conceito (PoC) sobre propostas de arquitetura.com
Padres
(estilos) arquiteturais
Cliente/Servidor Camadas
(N-tier, 3-tier) Componentes Domain Driven Design Barramento de mensagens Orientado a servios (SOA) On demand Geralmente
so feitas combinaes desses padres.com
.com
.com
.com
.com
.com
Padres Padres
de Projeto
usados para resolver problemas comuns em projetos
Os
padres de projeto devem ser
Especfico
para resolver um problema Genrico para atender problemas e requisitos futuros Analistas
de sistemas experientessolues que funcionaram no
Reutilizam
passado
.com
Objetivos
Reutilizar solues bem sucedidas Tornar flexvel o projeto para alteraes Evitar alternativas que comprometem a reutilizao e estrutura do projeto
O
que um padro de projeto?
Nome do padro Problema Soluo Consequncias.com
GRASP
(General Responsibility Assignment Software Patterns) Padro
gerais para atribuio de responsabilidade em projetos
Padres
de Criao Padres Estruturais Padres Comportamentais Padres de Concorrncia.com
Responsabilidade Fazer
dos objetos
algo o prprio objeto Iniciar aes de outros objetos Controlar e coordenar atividades de outros objetos Conhecimento Sobre
dos objetos
o encapsulamento de dados privados Sobre objetos relacionados Sobre coisas que pode calculado.com
Responsabilidade
e mtodos
.com
5
primeiros padres Information expert Creator High Cohesion Low Coupling Controller
.com
Information
Expert Classe possui informaes necessrias para sua responsabilidade Classe
Creator
possui a responsabilidade para criar instncias/objetos
Low
Couplingacoplamento entre classes.com
Baixo
High
Cohesion Altamente coeso das classes Controller Associar
responsabilidade para receber e coordenar um eventos de sistema
.com
Abstrair
o processo de instanciao Auxilia o sistema no baixo acoplamento Delegar a criao para outros objetos Centralizar a criao Privilegiar o uso de interface em vez das classes concretas
.com
Preocupa
com a forma que as classes so formadas Meio de compor as classes de forma extensvel Meio de compor as classes manutenveis
.com
Preocupam
com as atribuio dos
objetos Usar composio em vez de herana Determinar a forma de interao entre objetos
.com
Tratar
de problemas de concorrncia Tratar o acesso a classes Diminuir o acoplamento entre o controle de concorrncia e as classes
.com
GUTHRIE, S.; SOMASEGAR, S.; et al. Microsoft Application Architeture Guide. 2 Ed. 2009. Pginas 1 52. Disponvel em: http://apparchguide.codeplex.com/LARMAN, C. Applying UML and Patterns: Na Introduction to Object-Oriented Anlysis and Design and the Unified Process. 2 Ed. 2004. GAMMA, Erich. Padres de Projeto: Solues Reutilizveis de Software Orientado a Objetos. Porto Alegre: Bookman, 2005..com
M e s s a g e B U S
M e s s a g e B U S M e s s a g e B U S Market Data OMS ...
M e s s a g e B U S
Professor: Augusto A. B. Branquinho. Email: [email protected] Blog: http://wpattern.com
.com