O documento fornece uma visão geral da arquitetura de software, discutindo sua importância, definições e histórico. A arquitetura de software emerge nos anos 80 como forma de estudar infraestruturas de software e agora oferece notações para ajudar no desenvolvimento de sistemas complexos. Uma boa arquitetura permite que um sistema atenda requisitos chaves, enquanto uma má pode ser desastrosa.
2. Introdução
Emerge a partir dos anos 80 como o principal
meio de estudo para a infraestruturas de
grandes sistemas de software.
Inicialmente a pesquisa visava a pratica da
construção do software e agora a área oferece
uma notação mais concreta para ajudar no
desenvlvimento e projeto de software com alto
grau de complexidade.
3. Introdução
Um ponto crítico no projeto e na construção de todo
o sistema de software é sua arquitetura: isto é, sua
organização bruta como uma coleção de
componentes de interação.
Uma boa arquitetura pode permitir que um sistema
satisfaça às exigências chaves em áreas como: o
desempenho, a confiabilidade, a portabilidade, a
escalabilidade, e a sua interoperabilidade.
Uma arquitetura má pode ser desastrosa.
4. Introdução
No Passado, a arquitetura recebeu uma crescente atenção
como uma subárea importante da Engenharia de Software.
Os especialistas pregam que uma boa arquitetura é um fator
crítico de sucesso para o projeto e o desenvolvimento do
sistema. Começaram a reconhecer o valor de fazer escolhas
arquiteturais explícitas.
5. Introdução
Apesar da existência de livros, artigos e
ferramentas, a Arquitetura de Software
todavia ainda está em uma fase pouco
madura.
7. Fase1 Pesquisa básica: 19851994
Nesta fase os projetistas descreviam suas estruturas
utilizandose de diagrams compostos de caixaesetas e
notas informais. Experientes projetistas reconheciam a
fragilidade da metodologia utilizada de forma ad hoc. Estas
estruturas algumas vezes eram chamadas de arquitetura
embora nem sempre tivessem o seu processo realizado de
forma sistemática.
Em meados dos anos 80, várias ideias se firmaram tais como:
ocultamento da informação, tipos abstratos de dados,
orientação a objetos e herança. Estas técnicas contribuiram
para a ideia de considerar softwares como caixas pretas. A
orientação a objetos foi importante na fixaçao deste conceito.
Outras qualidades como dependabilidade e manutenibilidade
foram discutidas.
8. Fase1 Pesquisa básica: 19851994
Desenvolvedores iniciavam a exploração das ideias
de especialização do software para problemas
específicos. Alguns trabalhos focaram em estruturas
de software para produtos particulares com: aviação,
osciloscópios e controle de misseis.
Paralelamente, iniciaram a catalogação de soluções
estruturais comuns a diversas áreas e a ideia de
arquitetura tomou forma. Estruturas como pipefilter,
repositórios, invocação implícita, processos
cooperativos ajudaram a identificar arquiteturas para
classes de problemas específicos e desta forma
permitir uma melhor formalização da solução.
9. Fase2: Formalização do conceito:
19921996
Modelos básicos foram elaborados e explorados largaente através da
descrição de linguagens de arquiteturas, recentemente formalizadas e
classificadas. A idéia principal estava centrada nas estruturas do software
que eram comumente encontradas em outros sistemas. Os estudos nesta
época ajudaram a organizar os princípios das boas práticas.
As Principais linguagens de descrição de arquiteturas (ADLs) eram:
Aesop (explorava propriedades específicas de estilos arquiteturais),
C2 (explorava o poder de estilos baseados em eventos),
Darwin (projeto e especificação de sistemas distribuidos),
MetaH (projetos de contrloes em tempo real para aviação),
Rapide (simulação e analise de sistemas com comportamento dinamico),
UniCon (uso de conectores), e
Wright (interação entre componentes).
O importante desta fase foi a conscientização do conceito de visão
arquitetural como um conceito de trabalho.
10. Fase3: Development and extension
phase: 19952000
Durante esta fase, ocorre a troca do foco para a
unificação e refinamento dos conceitos iniciais. O
refinamento das taxonomias dos elementos
arquiteturais e linguagens também ocorreu.
Ocorre uma maturidade dos institutos de pesquisa,
pesquisadores e desenvolvedores. O IEEE
Transactions on Software Engineering, em 1995
lança um número especial no tema software
architecture.
11. Fase4: Aumento do uso interno do
conceito e exploraçaõ:19962003
O coneito estilos arquiteturais, nesta fase,
passou a ser conhecido como padrões
arquiteturais.
Avaliação e análise de arquiteturas tomam
corpo como tópicos de pesquisa.
Trabalhase na ideia de construção de
ferramentas case para automatizar o
processo de contrução de arquiteturas.
13. Fase6: Popularização: 2000present
A popularização foi caracterizada pela produção
qualificada, suporte,comercialização e marketing de
produtos para a comunidade interna e externa.
Padrões arquiteturias foram fortemente utilizados
com a explosão da World Wide Web e webbased e
commerce. Tecnologias como Ntier clientserver
architectures, agentbased architectures, e Service
Oriented Architectures ajudaram na fixação e uso do
conceito.
14.
15. Arquitetura de Software, porquê é
importante?
Comunicação da equipe.
Antecipação dos aspectos de decisões de
infraestrutura.
Transferênicia da abstração de um sistema de
software para outro.
Importante veículo de comunicação com os
Stakeholder.
18. Definições
Apesar de existirem numerosas definições sobre
arquitetura do software, no núcleo de tudo está a noção
de que a arquitetura de um sistema descreve sua
estrutura bruta.
Esta estrutura ilumina as decisões de projeto de alto nível,
incluindo coisas como:
o sistema é composto das peças de interação, onde estão os
principais caminhos de interação
Adicionalmente, uma descrição arquitetural inclui informação
suficiente para permitir a análise de alto nível e crítica do
sistema.
28. Arquitetura de Software: Visões
Sistemas são compostos de várias estruturas:
Unidades de código, suas decomposições e dependências;
Processos e suas interações;
Como o software é masterizado no hardware;
e outros
Uma View é uma representaçao destas estruturas, isto é, a
representação de um conjunto de elementos e seus
relacionamentos
29. Visões
Um arquiteto pode considerar 4 visões:
Como estruturar como um código de unidades?
Usando módulos
Como é estruturado o conjunto de elementos em tempo de
execução?
Usando visão de Runtime
Como os artefatos são organizados no sistema e como ocorre
o deployment?
Usar visão de Deployment
Qual a estrutura de dados do repositorio?
Modelo de dados
32. Modulo Views
Mostra estruturas do sistema em termos de unidades de
código.
Elementos: módulos, unidades de código que
implementam alguma funcionalidade
Relacionamentos:
A é parte de B: relação todoparte entre módulos
A depende de B: relação de dependência entre os módulos
A é B: relação de especialização/generalização entre
módulos ou realização de interfaces
37. Para que um Module Views é bom?
Auxilia na:
Construção blueprints (modelo, boas praticas)
para o código fonte.
Treinamento de novos desenvolvedores.
Analise de mudancas e seus impactos.
Visão de custos, atribuição de tarefas, tracking.
51. Para que a visão de Deployment
Views é boa?
Ajuda a clarificar:
Definição de regras para deployment e procedimentos
operacionais
Auditoria de falhas em tempo de execução
Planificação de aquisição de novos equipamentos
Analise de:
Disponibilidade
Performace (throughput, largura de banda)
Segurança
Confiabilidade
Treinamento e melhoria de comunicação com os stakeholder
56. Para que a visão de Data Model é boa?
Ajuda a clarificar:
Blueprint para Sistemas Gerenciadores de Banco de
Dados.
Referência para todos os módulos que manipulam
dados.
Database tuning.
Para melhorar a performance e modificabilidade do
SGBD.
Para diminuir redundância.
Para aumentar a consistência.
59. The Matrix Reloaded Architect
The Architect Hello, Neo.
Neo Who are you?
The Architect I am the Architect. I created the matrix. I've been waiting for you.
You have many questions, and although the process has altered your
consciousness, you remain irrevocably human. Ergo, some of my answers you
will understand, and some of them you will not. Concordantly, while your first
question may be the most pertinent, you may or may not realize it is also the most
irrelevant.
Neo Why am I here?
The Architect Your life is the sum of a remainder of an unbalanced equation inherent
to the programming of the matrix. You are the eventuality of an anomaly, which
despite my sincerest efforts I have been unable to eliminate from what is
otherwise a harmony of mathematical precision. While it remains a burden
assiduously avoided, it is not unexpected, and thus not beyond a measure of
control. Which has led you, inexorably, here.
60. Quais as
competências de um
arquiteto de
software?
61. Áreas de competências
Tecnológica
Estratégias de negócios
Política organizacional
Consultoria organizacional / Treinamento
63. Arquiteto: habilidades desejadas
Compreensão profunda do domínio e tecnologias
pertinentes.
Entendimento de aspectos técnicos para desenvolver
sistema com sucesso.
Uso de técnicas de elicitação, técnicas de
modelagem e métodos de desenvolvimento.
Entendimento das estratégias de negócios da
instituição onde atua.
Conhecimento de produtos, processos e
estratégias de concorrentes.
http://www.unibratec.com.br/revistacientifica/n1_artigos/n1_silvafilho.pdf
64. Arquiteto: tarefas atribuídas
Modelagem.
Análise de compromissos/viabilidade.
Prototipação, simulação, realização de
experimentos.
Análise de tendências de tecnologias.
Atuar como mentor de arquitetos novatos
http://www.unibratec.com.br/revistacientifica/n1_artigos/n1_silvafilho.pdf