O documento discute o papel do arquiteto de software, incluindo a definição de arquitetura de software e estilos arquiteturais. Também aborda a descrição de arquiteturas usando linguagens como ADL e o papel importante do arquiteto de software no projeto de sistemas.

1. +
O Papel do
Arquiteto de Software
Prof. Me. Peter Jandl Junior
ADS | CC | SI | UniAnchieta

2. +
Roteiro
 Objetivos & Justificativa
 Arquitetura de Software
 Estilos de Arquiteturas de
Software
 Descrição de Arquiteturas
 Papel do Arquiteto de
Software
 Arquitetura de Software e os
currículos de Bacharelado e
Tecnologia
 Considerações Finais
30/10/2016(C) 2016, PJandl, V WTI

3. +
Objetivos e Justificativa
Sempre é bom deixar claro o que se pretende e o porquê
30/10/2016 (C) 2016, PJandl, V WTI 3

4. +
Objetivo: Desenvolvimento
Profissional de Software
 Software complexo,
profissional, de qualidade,
não pode ser desenvolvido
informalmente, como
artesanato.
30/10/2016(C) 2016, PJandl, V WTI
4
 Engenharia de software é
disciplina essencial para
estudar e dirigir o processo
completo de desenvolvimento
de software.

5. +
Justificativa
 Sistemas de Software desejados são cada vez
maiores e mais complexos.
 Exigência de maior produtividade e lucratividade:
 competição e demandas corporativas exigem redução dos
tempos e dos custos de desenvolvimento e manutenção.
 Arquitetura de Software desempenha papel
fundamental na gerência da complexidade do
software a ser desenvolvido.
30/10/2016(C) 2016, PJandl, V WTI
5
Necessidade de Processos Formais de
Desenvolvimento de Software

6. +
Processos de Software
A visão completa do software visto como produto, ao longo de todo
seu ciclo de vida, de sua concepção até sua obsolescência.
30/10/2016 (C) 2016, PJandl, V WTI 6

7. +
Processos de Software
Processo unificado de desenvolvimento de software
em relação do ciclo de vida de produto
30/10/2016(C) 2016, PJandl, V WTI
7

8. +
Processos de Software
30/10/2016(C) 2016, PJandl, V WTI
8
Desenvolvimento incremental
Definição dosDefinição dos
Requisitos IniciaisRequisitos Iniciais
Atribuição dosAtribuição dos
Requisitos aosRequisitos aos
IncrementosIncrementos
Definição daDefinição da
Arquitetura doArquitetura do
SistemaSistema
DesenvolvimentoDesenvolvimento
de Incrementode Incremento
Validação doValidação do
IncrementoIncremento
Integração doIntegração do
IncrementoIncremento
Validação doValidação do
SistemaSistema
SistemaSistema
FinalFinal
Concepção doConcepção do
SistemaSistema
n iterações

9. +
Processos de Software
30/10/2016(C) 2016, PJandl, V WTI
9
Processo genérico
Arquitetura
de Sistema
Especif. de
Software
Especif. de
Interface
Especif. de
Componente
Especif. de
Estrutura de
Dados
Especif. de
Algoritmo
Projeto de
Arquitetura
Especificação
Abstrata
Projeto de
Interface
Projeto de
Componente
Projeto de
Estrutura de
Dados
Projeto de
Algoritmo
Especificação
de Requisitos

10. +
Arquitetura de Software
Algumas definições.
30/10/2016 (C) 2016, PJandl, V WTI 10

11. +
Elementos Arquiteturais
 São elementos arquiteturais de um sistema de
software:
 bancos de dados
 bibliotecas de software
 clientes
 componentes de software
 filtros
 módulos
 servidores
30/10/2016(C) 2016, PJandl, V WTI
11
As arquiteturas de software envolvem elementos
computacionais em sua definição.

12. +
Arquitetura de Software::AS
 A arquitetura de um software define em termos
computacionais quais são seus elementos
arquiteturais e como ocorre a interação entre eles
[FIELDING, 2000].
 Uma arquitetura de software envolve a descrição de
elementos arquiteturais dos quais os sistemas serão
construídos, interações entre esses elementos,
padrões que guiam suas composições e restrições
sobre estes padrões [PLEEGER, 1998].
30/10/2016(C) 2016, PJandl, V WTI
12
Existem conceituações diferentes da AS e do seu
papel.

13. +
Arquitetura de Software::AS
 Existem diversos elementos arquiteturais, cujas
interações podem ocorrer através de chamadas de
procedimentos, acesso a variáveis, uso de
protocolos para acesso a clientes e servidores,
bancos de dados e outros eventos quaisquer
[GARLAN, 2000].
30/10/2016(C) 2016, PJandl, V WTI
13
Existem conceituações diferentes da AS e do seu
papel.

14. +
Arquitetura de Software::AS
 Norma IEEE 1471 define
arquitetura de software
como a organização
fundamental de um
sistema embutida em
seus componentes, nos
relacionamentos entre
estes e o ambiente, além
dos princípios que
orientam seu projeto e
evolução.
30/10/2016(C) 2016, PJandl, V WTI
14

15. +
Arquitetura de Software::AS
30/10/2016(C) 2016, PJandl, V WTI
15
Esquema "4 + 1" do processo unificado.

16. +
Arquitetura de Software::AS
30/10/2016(C) 2016, PJandl, V WTI
16
Esquema "4 + 1" do processo unificado.
 Arquitetura do software envolve conjunto de
decisões que definem a organização do sistema que
tem como objetivos:
 Definir os elementos estruturais e suas interfaces
[determina composição do sistema].
 Estabelecer o comportamento obtido pela colaboração dos
componentes sistêmicos
[determina interações].
 Identificar subsistemas compostos do elementos estruturais
e comportamentais
[determina agregações].

17. +
Arquitetura de Software::AS
 Arquitetura dos computadores
 Características dos Bancos de Dados
 Linguagem de Programação
 Bibliotecas/Frameworks
 Características do ambiente gráfico e da interface desejada
 Sistemas Operacionais
 Protocolos de Rede
 Integração com Sistemas Legados
 Requisitos Não Funcionais (performance, portabilidade etc.)
30/10/2016(C) 2016, PJandl, V WTI
17
É influenciada por fatores determinados pela
implementação.

18. +
Funções da
Arquitetura de
Software
 Arquitetura de Software:
 é um meio de
comunicação.
 representa as decisões
iniciais de um projeto.
 é a base das estratégias
de divisão de trabalho.
 é um meio de avaliar os
atributos de qualidade.
 é uma medida de reuso.
O papel e valor da arquitetura de
software para uma organização.
30/10/2016(C) 2016, PJandl, V WTI

19. +
Estilos de Arquiteturas de
Software
Princípios e regras gerais aplicadas a definição de arquiteturas de
software.
30/10/2016 (C) 2016, PJandl, V WTI 19

20. +
Estilos de Arquiteturas de Software
 Um estilo arquitetônico ou um padrão de arquitetura
é um conjunto de regras de projeto para identificar
tipos de componentes, seu relacionamento e
também restrições existentes na construção de um
sistema e seus subsistemas.
30/10/2016(C) 2016, PJandl, V WTI
20

21. +
Estilos de Arquiteturas de Software
 Coleção de decisões
de arquitetura restritas
que são aplicadas em
um contexto
determinado e,
portanto, específicas
para um software
igualmente
determinado.
 Termo mais comum.
 Conjunto de decisões
de arquitetura que são
aplicáveis em
problemas recorrentes
de projeto
30/10/2016(C) 2016, PJandl, V WTI
21
ESTILO PADRÃO

22. +
Estilos de Arquiteturas de Software
 Orientada a:
 Objetos
 Eventos
 Serviços (SOA)
 Organizada em Camadas
 Cliente-Servidor
 Peer-to-Peer
 Mestre-Escravo
 Pipe-Filter
 Broker
 Model-View-Control::MVC
 Microkernel
30/10/2016(C) 2016, PJandl, V WTI
22

23. +
AS Orientada a Objetos
 Baseada no uso de conjuntos
particulares de objetos que
interagem entre si para alcançar
os objetivos do sistema.
 Os objetos são oriundos de
classes, as quais tem
características e funcionalidades
específicas.
 A construção das classes e a
interação entre seus objetos deve
procurar a maior coesão e o menor
acoplamento possíveis.
30/10/2016(C) 2016, PJandl, V WTI
23

24. +
AS Organizada em Camadas
 Cada camada (layer) provê
conjunto de funcionalidades
específicas.
 A comunicação só pode
envolver camadas vizinhas
imediatas.
 Camadas podem ser:
 substituídas, desde que
mantidas suas interfaces;
 distribuídas local ou
remotamente.
30/10/2016(C) 2016, PJandl, V WTI
24

25. +
AS Pipe-Filter
 Composta de pipes (conectores) e filters (filtros).
 Útil para sistemas que envolvem o
processamento/transformação sequencial de dados.
 Por meio dos conectores, os filtros podem ser combinados de
inúmeras maneiras, adequando-se a diferentes propósitos.
 Não é apropriado para aplicações interativas.
30/10/2016(C) 2016, PJandl, V WTI
25

26. +
AS Broker
 Arquitetura onde clientes e
servidores interagem
indiretamente por meio de
um intermediário comum
(broker) que pode prover
serviços adicionais.
 Oferece como vantagens a
grande independência e
interoperabilidade entre
elementos do cliente e do
servidor. Mas tem como
desvantagens a maior
complexidade e questões
de desempenho.
30/10/2016(C) 2016, PJandl, V WTI
26

27. +
AS Model-View-Control
 Model define modelo de dados
da aplicação.
 View realiza apresentação
visual (interface).
 Control determina o
comportamento (semântica)
da aplicação gerenciando
interação com usuário.
 Muito apropriado para
sistemas interativos.
30/10/2016(C) 2016, PJandl, V WTI
27

28. +
AS Orientada a Serviços
 Decomposição das
funcionalidades da
aplicação em serviços
simples, isolados por meio
de interfaces bem definidas.
 Um barramento de serviços
conecta os serviços e
disponibiliza interfaces e
contratos por meio de web
services.
 Criação de aplicações por
meio da composição de
serviços.
30/10/2016(C) 2016, PJandl, V WTI
28

29. +
Descrição de Arquiteturas
Como sistematizar e documentar a descrição de arquiteturas
computacionais.
30/10/2016 (C) 2016, PJandl, V WTI 29

30. +
Descrição de
Arquiteturas de Software
30/10/2016(C) 2016, PJandl, V WTI
30
 Podem empregar
Architecture Description
Languages (ADL).
 Uma ADL ou AL é uma forma
de expressão para a descrição
de uma arquitetura
[ISO/IEC/IEEE42010].
 Pode ser uma linguagem
formal ou uma combinação de
outros meios que permita
especificar conceitos de
arquitetura por meio de
diferentes pontos de vista.

31. +
Descrição de
Arquiteturas de Software
 Uma ADL deve permitir a expressão de
características estruturais e comportamentais dos
sistemas.
 Também devem possibilitar o registro de fatores de
implementação e também o reuso/reutilização.
 Devem oferecer primitivas de composição de
sistemas, além de elementos básicos como
componentes, conectores e configurações.
30/10/2016(C) 2016, PJandl, V WTI
31

32. +
Linguagens de Descrição de
Arquiteturas de Software
 ACME (Architectural Description
Language - Carnegie Mellon University)
 ADAGE (Avionics Domain Application
Generative Environment)
 ADLARS
 ADML (XML based AL)
 AESOP
 C2
 Darwin
 EAADL (Extended Architecture
Analysis Description Language)
 Koala (Consumer electronics domain-
specific design)
 Meta-H
 Rapide
 SADL (Structural Architecture
Description Language)
 UML (Unified Modeling Language)
 Weaves (concurrent communicating
components modeling)
 Wright
30/10/2016(C) 2016, PJandl, V WTI
32

33. +
Exemplo ADL::
Modelo AADL
30/10/2016(C) 2016, PJandl, V WTI
33

34. +
Exemplo ADL::
Modelo Darwin
30/10/2016(C) 2016, PJandl, V WTI
34

35. +
Exemplo ADL::
Modelo xADL/ArchStudio
30/10/2016(C) 2016, PJandl, V WTI
35

36. +
Papel do Arquiteto de
Software
A importância e o valor deste profissional.
30/10/2016 (C) 2016, PJandl, V WTI 36

37. +
Papel do Arquiteto de Software
Dos requisitos das aplicações.
Das tecnologias disponíveis para apoio a
construção da arquitetura e do próprio
software.
Dos processos de software adequados ao
desenvolvimento das aplicações.
30/10/2016(C) 2016, PJandl, V WTI
37
Requer conhecimento técnico profundo.

38. +
Papel do Arquiteto de Software
Deve exercer papel de liderança.
Deve possuir visão holística.
Deve ter habilidade para lidar com pessoas,
solucionar conflitos e gerenciar mudanças.
Deve saber ouvir,
ser comunicativo, coerente e flexível.
30/10/2016(C) 2016, PJandl, V WTI
38
Além do conhecimento técnico:

39. +Arquitetura de Software
e os currículos de
Bacharelado e Tecnologia
30/10/2016 (C) 2016, PJandl, V WTI 39

40. +
Arquitetura de Software na Graduação
 Cursos tradicionais
 de bacharelado (em Ciência da Computação ou Sistemas de
Informação)
 e de tecnologia (em Análise e Desenvolvimento de Sistemas)
 não contêm disciplinas diretamente voltadas para o estudo de
arquiteturas de software porque:
 prioriza apresentar e discutir os conhecimentos essenciais que
formam a base técnica deste profissionais;
 além do que o estudante ainda tem pouca experiência profissional.
30/10/2016(C) 2016, PJandl, V WTI
40
Como os cursos de graduação tradicionais lidam com
a questão da Arquitetura de Software

41. +
Arquitetura de Software na Graduação
 Ao mesmo tempo, tais cursos abordam, invariavelmente,
vários dos conhecimentos requeridos para a formação de um
arquiteto de software:
 Engenharia de Software
 Linguagens e Programação de Computadores
 Banco de Dados
 Redes de Computadores
 Projeto de Interfaces
 Sistemas Operacionais
 Arquitetura e Organização de Computadores
 Integração de Sistemas
30/10/2016(C) 2016, PJandl, V WTI
41
Como os cursos de graduação tradicionais lidam com
a questão da Arquitetura de Software

42. +
Considerações Finais
30/10/2016 (C) 2016, PJandl, V WTI 42

43. +
Considerações Finais
Arquiteturas
baseadas em
Componentes
Arquiteturas
baseadas em
Componentes
Arquiteturas
baseadas em
Serviços
Arquiteturas
baseadas em
Serviços
Arquiteturas
baseadas em
Modelos
Arquiteturas
baseadas em
Modelos
30/10/2016(C) 2016, PJandl, V WTI
43
Sobre as Arquiteturas de Software

44. +
Considerações Finais
 Existem muitos estilos e padrões, que devem ser
conhecidos e estudados antes que sejam propostos e
adotados como soluções.
 A arquitetura do software influencia o resultado de todo o
ciclo de vida do produto, não apenas seu
desenvolvimento.
 Podem ser formalizadas por meio de ADL
(Architecture Description Languages).
 Ênfase atual nas arquiteturas organizadas em camadas,
ou orientadas a serviços e baseadas em microkernel.
 Tendência: disponibilização de serviços por meio de Cloud
Computing.
30/10/2016(C) 2016, PJandl, V WTI
44
Sobre as Arquiteturas de Software

45. +
Considerações Finais
Requer muito estudo, conhecimento e
experiência.
O papel do arquiteto de software tem influencia
em todo o ciclo de vida do produto, não
apenas em sua concepção.
Carreira de grande valor agregado e enorme
potencial de remuneração.
30/10/2016(C) 2016, PJandl, V WTI
45
Sobre os Arquitetos de Software

46. +
Prof. Me.
Peter Jandl Jr
 Coordenador Graduação
ADS, CC e SI
UniAnchieta, Jundiaí.
 Coordenador Pós-Graduação
TACS e TDS
SENAC, Sorocaba.
 Docente ADS
FATEC, Jundiaí.
30/10/2016(C) 2016, PJandl, V WTI

47. +
Referências Bibliográficas
 BRAUDE, E. Projeto de software: da programação à arquitetura: uma
abordagem baseada em Java. Porto Alegre: Bookman, 2005. 619 p.
 CLEMENTS, P., BACHMANN, F., BASS, L., et al.. Documenting Software
Architectures: Views and Beyond. New York: Addison-Wesley, 2002.
 FOWLER, M. Padrões de arquitetura de aplicações corporativas. Porto Alegre:
Bookman, 2008, 493p.
 GARLAN, D..Software Architecture: a Roadmap. In: International Conference
on Software engineering: Future of SE Track, pp. 91-101, Limerick, Ireland,
2000.
 GASEVIC, D. Model Driven Architecture and Ontology Development. New York
(NY): Springer, 2006. 311 p.
 KRUCHTEN, P., 1995, The 4+1 View Model of Architecture, IEEE Software, v.
12, n. 6 (November), pp. 42-50.
 MENDES, A.. Arquitetura de Software: desenvolvimento orientado a
arquitetura. Rio de Janeiro: Campus. 2002.
30/10/2016(C) 2016, PJandl, V WTI
47

48. +
Referências Bibliográficas
 RICHARDS, M. Software Architecture Patterns. Sebastopol: O'Reilly, 2015.
 SHAW, M., GARLAN, D.. Software Architecture: Perspectives on an Emerging
Discipline, New Jersey: Prentice-Hall,1996.
 SILVEIRA, P. et al. Introdução à Arquitetura e Design de Software. Rio de
Janeiro: Campus, 2012.
Internet:
 http://www.sei.cmu.edu/architecture/
 http://www.theenterprisearchitect.eu/blog/2008/01/16/mda-model-driven-
architecture-basic-concepts/
 http://www.omg.org/mda/
 http://www.oracle.com/bea/index.html
 http://ftacademy.org/
30/10/2016(C) 2016, PJandl, V WTI
48