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.

1. 1
Arquitetura
de
So-ware
Prof.
Adailton
Magalhães
Lima
2014.4

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)

7. 7
Arquitetura
de
So-ware
Introdução
e
Visão
Geral

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...
§ ....

9. 9
Arquitetura:
o
que
aprender
da
construção
civil?

10. 10
Arquitetura:
o
que
aprender
da
construção
civil?

11. 11
Arquitetura:
o
que
aprender
da
construção
civil?

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

13. 13
Arquitetura
de
So-ware
Amostra

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)