Arquitetura de software - Introdução

Arquitetura de Software
Visão Geral

Introdução
 Emerge a partir dos anos 80 como o principal
meio de estudo para a infra-estruturas 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.

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.

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.

Introdução
 Apesar da existência de livros, artigos e
ferramentas, a Arquitetura de Software
todavia ainda está em uma fase pouco
madura.

Fase1- Pesquisa básica: 1985-1994
 Nesta fase os projetistas descreviam suas estruturas
utilizando-se de diagrams compostos de caixa-e-setas 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.

Fase1- Pesquisa básica: 1985-1994
 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 pipe-filter,
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.

Fase2: Formalização do conceito:
1992-1996
 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),
 Meta-H (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.

Fase3: Development and extension
phase: 1995-2000
 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.

Fase4: Aumento do uso interno do
conceito e exploraçaõ:1996-2003
 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.
 Trabalha-se na ideia de construção de
ferramentas case para automatizar o
processo de contrução de arquiteturas.

Fase5: Aumento do uso externo do
conceito e exploraçaõ:1998-present
 Ocorre a maturidade do conceito e com isso a
sua externalização (industria, governo, etc).
 Uso da UML como um padrão para a
descrição de arquiteturas, junto com o pacote
da Rational.

Fase6: Popularização: 2000-present
 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 web-based e-
commerce. Tecnologias como N-tier client-server
architectures, agent-based architectures, e Service-
Oriented Architectures ajudaram na fixação e uso do
conceito.

Arquitetura de Software, porquê é
importante?
 Comunicação da equipe.
 Antecipação dos aspectos de decisões de
infra-estrutura.
 Transferênicia da abstração de um sistema de
software para outro.
 Importante veículo de comunicação com os
Stakeholder.

Definições
Sistema de Computação
 UML 1.3: A system is a collection of connected units that are organized to
accomplish a specific purpose. A system can be described by one or more
models, possibly from different viewpoints.
 IEEE Std. 610.12-1990: A system is a collection of components organized
to accomplish a specific function or set of functions.
Arquitetura de software
 UML 1.3: Architecture is the organizational structure of a system. An
architecture can be recursively decomposed into parts that interact through
interfaces, relationships that connect parts, and constraints for assembling
parts. Parts that interact through interfaces include classes, components and
subsystems.
Bass, Clements, and Kazman. Software Architecture in Practice,
Addison-Wesley 1997:
 'The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components, and
the relationships among them. © http://www.bredemeyer.com

Definições
Garlan and Perry, guest editorial to the IEEE Transactions on Software
Engineering, April 1995:
 Software architecture is "the structure of the components of a
program/system, their interrelationships, and principles and guidelines
governing their design and evolution over time."
Dewayne E. Perry and Alexander L. Wolf. "Foundations for the Study of
Software Architecture''. ACM SIGSOFT Software Engineering Notes,
17:4, October 1992:
 "... software architecture is a set of architectural (or, if you will, design)
elements that have a particular form.
 We distinguish three different classes of architectural element:
- processing elements;
- data elements; and
- connecting elements.“
IEEE Std. 610.12-1990:
 Architecture is the organizational structure of a system.
© http://www.bredemeyer.com

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.

Podemos fazer melhor que isto!
©2006 JavaOneSM Conference | Session TS-4619 | 2

O papel da Arquitetura de Software

Quais requisitos são importante na
elaboração deu ma Arquitetura?

Fatores que influenciam a Arquitetura
 Arquitetura de software é influenciada por:
 Todos os usuários do sistema;
 Fatores Técnicos e Organizacional da empresa;
 Experiência do Arquiteto de Software.

Fatores que influenciam a Arquitetura
 Desenvolvimento da Organização
 Aspectos de Negócios
 Investir em, ou amortizar a infra-estrutura?
 Reduzir o custo de instalação.
 Investir em novos funcionários ou não?
 Aspectos Organizacionais
 Manter o modelo de negócios usado atualmente?

Ambiente Técnico
 Hoje a organização utiliza:
 Modelo de banco de dados XYZ,
 Web Browser para difundir as informações entre
plataformas.
 Isto ainda será verdade para daqui há 10
anos?

Experiência do Arquiteto
 Experiências com projetos de sucesso,
 Implica em replicar o modelo!
 Experiência com projetos desastrosos
 Implica em desenvolver regras para evitar tal
situação!

O que é Arquitetura de Software?

Ciclo de vida
O clico de vida da arquitetura de software compreende:
 Criar a arquitetura
 Usando padroes arquiteturais, design patterns e
experiências passadas
 Avaliar a Arquitetura
 Refinar, atualizar e refatorar a arquitetura dentro do
ciclo de vida do produto
 Usar a arquitetura como um guia para a
implementação
 Tentar enfatizar a arquitetura durante a
implementação

Visões diferentes para cada público!

O que você e o seu gerente entendem
disto?

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

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

Visões
Arquitetura Conceitual
• Diagramas arquiteturais, especificação informal de
componentes
• Foco: identificação e alocação de responsabilidades entre
componentes
Arquitetura Lógica
• Atualiza os diagramas arquiteturais (apresentando as
interfaces), especificação interface, especificação de
componentes e guias de utilização
• Foco: design da interação, mecanismos e protocolos de
conexão; provimento de info contextual para os usuários dos
componentes
Arquitetura Execução
• Visão do Processo (via Diagramas de Colaboração)
• Foco: informa como se dará o comportamento do componente
em tempo de execução, threads; como eles se comunicam; como
os recursos físicos são alocados.
Visão global
do sistema
Esquema
para os
desenvolv:
•preciso
•Sem
ambigui-
dade
© http://www.bredemeyer.com

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 todo-parte 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

UML: relação entre módulos

Módulo View: alto nível

Para que o Module
Views é bom?

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.

Runtime Views
Mostra as estruturas do sistema em execução.
Elementos:
 Componentes que estão presentes em tempo de execução
(processos, threads, componentes EJBtm, servlets, DLLs,
objetos, etc).
 Dispositivos de armazenamento.
 Relacções:
 mecanismos de interação baseados em tecnologias.
 Arquiteto deve diferenciar: Chamadas locais de remotas.
 Invocação síncrona de assíncorna.

Runtime Views: notação informal

Runtime Views: com UML 2.0
Componentes (como subtipos de classes)
Portas (as quais podem ter multiplas instancias)
Interfaces externas e internas (opcionalmente conectadas por meio de portas)
Assembly conector
Estruturas internas das classes
Conector de delegação

Runtime Views: com SOA

Para que o Runtime
Views é bom?

Para que um Runtime Views é bom?
Ajuda a clarificar:
 Como os componentes interagem em tempo de
execução.
 Quais os componentes que estão duplicados.
 Como o sistema trabalha.
 Análise de propriedades em tempo de execução.
 Análise de critérios de performance.
 Análise de critérios de segurança.
 Análise de critérios de confiabilidade.

Deployment Views
Mostra duas relevantes estruturas:
 1. Infra-estruturas de Hardware do ambiente de produção.
 2. Estruturas de diretórios e arquivos do sistema para
execução.
Elementos:
 Nodos de processamento e comunicação (sevidores, routers).
 Diretórios e arquivos
Relacionamentos:
 Mecanismos de interação entre canais de comunicação e
Estruturas de diretórios.

Deployment Views: Infraestrutura de
Hardware: notação informal

Hardware usando UML 2.0

Hardware

Deployment Views: Deployment
Files: notação informal

Para que a visão de
Deployment é boa?

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

Data Model Views
Mostra as estruturas dos repositórios de dados
Elementos:
 Entidades (elementos persistentes).
Relacionamentos:
 1:1, 1:n e n:n.
 Generalização / Especialização.
 Agregação.

Para que a visão de Data
Model é boa?

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.

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.

Quais as
competências de um
arquiteto de
software?

Áreas de competências
 Tecnológica
 Estratégias de negócios
 Política organizacional
 Consultoria organizacional / Treinamento

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

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

Arquiteto de software: Competências
Who Needs an Architect?
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
The Role of the Architect
http://www.bredemeyer.com/pdf_files/role.pdf
Architecture Competence
http://www.sei.cmu.edu/architecture/research/competence/index.cfm
On Identifying the Skills Needed for Software Architects
http://delivery.acm.org/10.1145/1380000/1373309/p1-downey.pdf?
key1=1373309&key2=5267377621&coll=GUIDE&dl=GUIDE&CFID=80511111&CFTOK
EN=97235781
The Duties, Skills, and Knowledge of Software Architects
http://www.sei.cmu.edu/library/abstracts/news-at-sei/architect200701.cfm
Enterprise Solution Architects and Leadership
http://blogs.msdn.com/gabriel_morgan/archive/2009/01/17/enterprise-
solution-architects-and-leadership.aspx

Arquitetura de software - Introdução

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Arquitetura de software - Introdução

Semelhante a Arquitetura de software - Introdução (20)

Mais de Sergio Crespo

Mais de Sergio Crespo (9)

Último

Último (20)

Arquitetura de software - Introdução