O documento discute arquitetura de software, apresentando sua definição e importância. É destacado que a arquitetura define a estrutura de um sistema em componentes e relações, e que sua descrição é essencial para comunicação, análise e redução de riscos no projeto de software.
Revisa conceitos de Orientação a Objetos. Revisa conceitos de Padrões de Projeto.
Apresenta um breve histórico da evolução da arquitetura de software. Mostra a importância que a escolha do padrão arquitetural exerce na construção de software. Demonstra 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.
Essa palestra tem o objetivo de apresentar conceitos de construção de aplicações escaláveis e de fácil manutenção, aplicando padrões de projetos conhecidos mas com Node.js
Estratégias de Estruturação de Código-fonte e Controlo de VersãoComunidade NetPonto
Muitas das dificuldades no desenvolvimento profissional de software são causadas por problemas (ou a falta de) um correcto sistema e uso de controlo de versões. Nesta apresentação o Tiago Pascoal, MVP em Visual Studio Team System, irá mostrar estratégias sobre como melhor estruturar todos os artefactos de um projecto, incluindo melhores práticas para uso de controlo de versões, tendo por base a plataforma de Application Lifecycle Management da Microsoft (Team Foundation Server / TFS).
Teoria sobre Analise e Projeto de Informação, Tipos de Usuários, Atribuições do Analista. Revisão do conteúdo e reeditoração dos slids do Prof Edinelson.
Revisa conceitos de Orientação a Objetos. Revisa conceitos de Padrões de Projeto.
Apresenta um breve histórico da evolução da arquitetura de software. Mostra a importância que a escolha do padrão arquitetural exerce na construção de software. Demonstra 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.
Essa palestra tem o objetivo de apresentar conceitos de construção de aplicações escaláveis e de fácil manutenção, aplicando padrões de projetos conhecidos mas com Node.js
Estratégias de Estruturação de Código-fonte e Controlo de VersãoComunidade NetPonto
Muitas das dificuldades no desenvolvimento profissional de software são causadas por problemas (ou a falta de) um correcto sistema e uso de controlo de versões. Nesta apresentação o Tiago Pascoal, MVP em Visual Studio Team System, irá mostrar estratégias sobre como melhor estruturar todos os artefactos de um projecto, incluindo melhores práticas para uso de controlo de versões, tendo por base a plataforma de Application Lifecycle Management da Microsoft (Team Foundation Server / TFS).
Teoria sobre Analise e Projeto de Informação, Tipos de Usuários, Atribuições do Analista. Revisão do conteúdo e reeditoração dos slids do Prof Edinelson.
2. 2
Agenda
Ø Introdução
Ø Arquitetura
&
Projeto
de
SoAware
Ø Padrões
de
Projeto
3. 3
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
Em
Arquitetura
4. 4
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
Em
Arquitetura
5. 5
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
Em
Arquitetura
6. 6
Em
So-ware
Ø Dê
um
exemplo
de
soAware
“pequeno”;
Ø Dê
um
exemplo
de
soAware
“grande”;
Ø Qual
o
limite
de
um
soAware?
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
8. 8
Introdução
Ø Expressões
que
indicam
a
adoção
de
um
modelo
arquitetural:
§ Sistemas
de
3
Camadas...
§ Uso
do
Padrão
de
Projeto
X...
§ ...Padrão
Fachada...
§ Uso
da
Arquitetura
MVC
(Modelo-‐Visão-‐
Controlador)
§ Projeto
na
Nuvem...
§ ....
12. 12
Arquitetura
de
So-ware
Amostra
Enactment
GenericDataSource ContractManagement
DiscoverDataLocation SystemInformationManagement
DataChannel MessagesChannel DiscoveryChannel DataExchangeFormat
NotificationInterface
Jxta Channels IMPL (Socket, RMI, WebServices, ....)
ARQUITETURA EM CAMADAS DA EXECUCAO DISTRIBUIDA NO SISTEMA P2Process
O nivel de abstracao cresce de baixo para cima.
No nivel inferior encontram-se os componentes que utilizam diretamente a API JXTA.
No nivel superior esta a interface de execucao de modelos de processos do sistema.
OBS: Dentro de cada pacote há uma descrição breve da funcionalidade de cada camada e componente.
A
B
C
D
E
14. 14
Arquitetura
de
So-ware
Amostra
under
definition
defined
valid
finished
manager started contract defini...
manager finished contract definition / generate contract validation...
contract defined and isValid()==...
not valid
contract defined and isValid()==f...
supplier defines that all activitities are concl...
isValid()==false, becaus e condition has changed to f...
isValid()==true, because condition has changed to ...
supplier defines that all activitities are concl...
15. 15
O
que
é
Arquitetura
de
So-ware?
Ø A
arquitetura
de
soAware
de
um
programa
ou
sistema
computacional
é:
§ a
estrutura
ou
estruturas
do
sistema
que
§ abrange
os
componentes
de
soAware,
§ as
propriedades
externamente
visíveis
destes
componentes
§ e
as
relações
entre
eles
Bass et al apud Pressman
16. 16
O
que
é
Arquitetura
de
So-ware?
Ø Define-‐se
Arquitetura
de
SoAware
como
a
organização
fundamental
de
um
sistema
na
forma
de
componentes,
seus
relacionamentos
com
o
ambiente,
e
os
princípios
que
conduzem
seu
design
e
evolução.
Um
projeto
arquitetural
envolve
a
descrição
formal
dos
elementos
dos
quais
um
sistema
é
construído,
das
interações
entre
estes
elementos,
dos
padrões
que
guiam
sua
composição,
e
das
restrições
sobre
esses
padrões.
Ø A
descrição
arquitetural
envolve
um
conjunto
de
produtos
que
documentam
a
arquitetura.
Para
o
melhor
entendimento
do
sistema
inteiro,
ou
parte
dele,
é
necessário
que
esta
descrição
seja
representada
segundo
diferentes
perspechvas.
Cada
perspechva
possui
o
objehvo
de
representar
um
conjunto
de
interesses
parhculares
a
uma
das
partes
do
sistema.
Assim,
a
parhr
da
combinação
de
várias
perspechvas
o
sistema
inteiro
pode
ser
representado
em
maiores
detalhes.
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
17. 17
O
que
é
Arquitetura
de
So-ware?
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
18. 18
Por
que
Arquitetura
de
So-ware?
Ø A
arquitetura
não
é
um
so-ware
operacional
(executável).
Porém,
permite
a
um
Engenheiro
de
SoAware:
§ Analisar
a
adequação
de
um
projeto
no
atendimento
dos
requisitos
estabelecidos;
§ Considerar
alternaKvas
arquiteturais
em
um
estágio
em
que
as
mudanças
do
projeto
ainda
são
fáceis
e
baratas;
§ Reduzir
os
riscos
associados
com
a
construção
de
soAware;
19. 19
Por
que
Arquitetura
de
So-ware?
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
20. 20
Por
que
Arquitetura
de
So-ware?
Ø Facilitador
da
comunicação
entre
os
envolvidos
com
um
sistema;
Ø Destaca
decisões
iniciais
de
projeto
que
vão
ter
um
impacto
profundo
em
todo
o
trabalho
de
se
segue;
Ø Modelo
relahvamente
pequeno,
intelectualmente
inteligível
de
como
o
sistema
é
estruturado
e
como
seus
componentes
trabalham
em
conjunto;
Engenharia
de
SoAwre
II
21. 21
Como
começar?
Especi"
ficação!
Protótipo!
Projeto!
modelagem!
Engenharia
de
SoAware
II
22. 22
Princípios
de
Projeto
(1)
1. O
projeto
não
pode
ser
“bitolado”
§ Um
bom
projehsta
deve
considerar
abordagens
alternaKvas,
julgando
cada
uma
com
base
nos
requisitos
do
projeto
2. O
projeto
deve
ser
relacionável
ao
modelo
de
análise
§ Como
um
único
elemento
do
projeto
pode
estar
relacionado
com
vários
requisitos,
é
necessários
ter
recursos
para
estabelecer
como
os
requisitos
são
saKsfeitos
pelo
projeto
3. O
projeto
não
deve
reinventar
a
roda
§ Sistemas
são
construídos
usando
um
conjunto
de
padrões
de
projeto,
muitos
dos
quais
estão
descritos
amplamente
na
literatura.
Os
padrões
de
componentes
COTS
devem
ser
escolhidos
como
alternahva
à
reinvenção
(reuso
de
conhecimento)
4. O
projeto
deve
“minimizar
a
distância
intelectual”
entre
o
so-ware
e
o
problema,
tal
como
existe
no
mundo
real
§ O
soAware,
sempre
que
possível,
deve
imitar
a
estrutura
do
domínio
do
problema
5. O
projeto
deve
exibir
uniformidade
e
integração
§ Um
projeto
é
uniforme
se
parece
que
uma
única
pessoa
desenvolveu
a
coisa
toda.
Regras
de
esKlo
e
formato
devem
ser
definidas
para
uma
equipe
de
projeto
antes
que
o
trabalho
inicie.
§ Um
projeto
é
integrado
se
houver
cuidado
na
definição
de
interfaces
entre
os
seus
componentes
23. 23
Princípios
de
Projeto
(2)
6.
O
projeto
deve
ser
estruturado
para
acomodar
modificação
7.
O
projeto
deve
ser
estruturado
para
degradar
suavemente,
mesmo
quando
dados,
eventos
ou
condições
de
operações
aberrantes
são
encontradas
8.
Projeto
não
é
codificação.
Codificação
não
é
projeto
§ Mesmo
quando
os
mais
detalhados
projetos
procedimentais
são
criados
para
os
componentes
de
programa,
o
nível
de
abstração
de
projeto
é
maior
que
o
do
código-‐fonte;
9.
O
projeto
deve
ser
avaliado
quanto
à
qualidade,
à
medida
que
é
criado,
não
depois
do
fato
§ Uma
variedade
de
conceitos
e
medidas
de
projeto
está
disponível
para
auxiliar
o
projehsta
na
avaliação
de
qualidade;
10.
O
projeto
deve
ser
revisto
para
minimizar
erros
conceituais
(semânKcos)
§ A
equipe
de
projeto
deve
garanhr
que
os
principais
elementos
conceituais
(omissões,
ambigüidade
e
inconsistência)
tenham
sido
cuidados
antes
de
se
preocupar
com
a
sintaxe
do
modelo;
24. 24
Princípios
de
Projeto
(3)
Ø 11.
Deve
considerar
de
maneira
detalhada
o
atendimento
aos
requisitos
não-‐funcionais
§ Segurança
§ Escala
§ Tempo
de
resposta
§ Plataforma
operacional
§ Disponibilidade:
24
x
7
§ ...
25. 25
Níveis
de
abstração
de
um
problema
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
26. 26
Exemplo:
Evolução
da
Arquitetura
de
uma
Nave
Espacial
Caso
Millenium
Falcon
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
27. 27
Idade
do
Arquiteto:
3
Nível
de
Experiência:
nenhuma
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
28. 28
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
Idade
do
Arquiteto:
13
Nível
de
Experiência:
estudante
entediado
29. 29
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
Idade
do
Arquiteto:
19
Nível
de
Experiência:
calouro
em
design
30. 30
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
Idade
do
Arquiteto:
23
Nível
de
Experiência:
trainee
de
design
na
Lucas
Arts
31. 31
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)
Idade
do
Arquiteto:
29
Nível
de
Experiência:
Designer
Gráfico
na
Lucas
Arts
32. 32
Perguntas
Ø Qual
o
próximo
nível
de
abstração?
Ø Que
itens
não
foram
considerados
na
abstração
adotada?
Ø A
nave
é
um
“so-ware
operacional”
?
Arquitetura
de
SoAware
(baseado
nos
slides
do
profr
Rodrigo
Quites)