Arquitetura de Software Visão Geral

Arquitetura de Software
Visão Geral

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.

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: 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.

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.

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.

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.

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.

Fase5: Aumento do uso externo do
conceito e exploraçaõ:1998present
 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: 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.

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.

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.121990: 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.121990:
 Architecture is the organizational structure of a system.


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 TS4619 | 2

O papel da Arquitetura de Software

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
Visão global • Diagramas arquiteturais, especificação informal de
do sistema componentes
• Foco: identificação e alocação de responsabilidades entre
componentes
Arquitetura Lógica
Esquema • Atualiza os diagramas arquiteturais (apresentando as
para os interfaces), especificação interface, especificação de
desenvolv: componentes e guias de utilização
•preciso • Foco: design da interação, mecanismos e protocolos de
conexão; provimento de info contextual para os usuários dos
•Sem
componentes
ambigui
dade 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.

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

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. Infraestruturas 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 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/p1downey.pdf?
key1=1373309&key2=5267377621&coll=GUIDE&dl=GUIDE&CFID=80511111&CFTOKEN=97235781
The Duties, Skills, and Knowledge of Software Architects
http://www.sei.cmu.edu/library/abstracts/newsatsei/architect200701.cfm
Enterprise Solution Architects and Leadership
http://blogs.msdn.com/gabriel_morgan/archive/2009/01/17/enterprisesolutionarchitectsand
leadership.aspx

Arquitetura de Software Visão Geral

Mais conteúdo relacionado

Mais procurados

Semelhante a Arquitetura de Software Visão Geral

Mais de sergiocrespo

Arquitetura de Software Visão Geral