+
O Papel do
Arquiteto de Software
Prof. Me. Peter Jandl Junior
ADS | CC | SI | UniAnchieta
+
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
+
Objetivos e Justificativa
Sempre é bom deixar claro o que se pretende e o porquê
30/10/2016 (C) 2016, PJandl, V WTI 3
+
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.
+
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
+
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
+
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
+
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
+
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
+
Arquitetura de Software
Algumas definições.
30/10/2016 (C) 2016, PJandl, V WTI 10
+
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.
+
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.
+
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.
+
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
+
Arquitetura de Software::AS
30/10/2016(C) 2016, PJandl, V WTI
15
Esquema "4 + 1" do processo unificado.
+
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].
+
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.
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
Descrição de Arquiteturas
Como sistematizar e documentar a descrição de arquiteturas
computacionais.
30/10/2016 (C) 2016, PJandl, V WTI 29
+
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.
+
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
+
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
+
Exemplo ADL::
Modelo AADL
30/10/2016(C) 2016, PJandl, V WTI
33
+
Exemplo ADL::
Modelo Darwin
30/10/2016(C) 2016, PJandl, V WTI
34
+
Exemplo ADL::
Modelo xADL/ArchStudio
30/10/2016(C) 2016, PJandl, V WTI
35
+
Papel do Arquiteto de
Software
A importância e o valor deste profissional.
30/10/2016 (C) 2016, PJandl, V WTI 36
+
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.
+
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:
+Arquitetura de Software
e os currículos de
Bacharelado e Tecnologia
30/10/2016 (C) 2016, PJandl, V WTI 39
+
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
+
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
+
Considerações Finais
30/10/2016 (C) 2016, PJandl, V WTI 42
+
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
+
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
+
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
+
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
+
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
+
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

O (papel do) Arquiteto de Software

  • 1.
    + O Papel do Arquitetode 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 deSoftware  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 deSoftware 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 Avisã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 Processounificado 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 Algumasdefinições. 30/10/2016 (C) 2016, PJandl, V WTI 10
  • 11.
    + Elementos Arquiteturais  Sãoelementos 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 Arquiteturasde 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 Arquiteturasde 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 Arquiteturasde 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 Arquiteturasde 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 aObjetos  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 emCamadas  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  Compostade 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  Arquiteturaonde 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  Modeldefine 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 aServiç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 Comosistematizar e documentar a descrição de arquiteturas computacionais. 30/10/2016 (C) 2016, PJandl, V WTI 29
  • 30.
    + Descrição de Arquiteturas deSoftware 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 deSoftware  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çãode 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.
  • 34.
  • 35.
  • 36.
    + Papel do Arquitetode Software A importância e o valor deste profissional. 30/10/2016 (C) 2016, PJandl, V WTI 36
  • 37.
    + Papel do Arquitetode 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 Arquitetode 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 eos currículos de Bacharelado e Tecnologia 30/10/2016 (C) 2016, PJandl, V WTI 39
  • 40.
    + Arquitetura de Softwarena 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 Softwarena 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.
  • 43.
    + Considerações Finais Arquiteturas baseadas em Componentes Arquiteturas baseadasem 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  Existemmuitos 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 muitoestudo, 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 JandlJr  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