Arquitetura de Software Introdu

1
Arquitetura de SoftwareIntrodução

• Por quê? O que? Como? Onde? e Quem?

2
Síntese

• Arquitetura de software é o caminho para
• conectar as metas de negócios ao que iremos
  construir
• obter alinhamento
• organizar a atividade de produção de código
• envolver as diferentes competências de um time
• Arquitetura está muito ligada à vantagem
  competitiva
• Arquitetura não se obtém facilmente
• é um trabalho de design não trivial
• cada um tem um papel a desempenhar na sua criação
• é melhor construída por um time pequeno de
  arquitetos dedicados que dirigem o processo e
  tomas as decisões

Arquitetura funciona como o plano de vôo do
desenvolvimento. Ela deve facilitar o alcance da
estratégia de negócio torna-se a implementação
técnica da estratégia de negócio.
3
Iremos construir um shopping?
Aqui um exemplo de uma arquitetura base e seus
requisitos. É só construir ela!

• Requisitos
• estilo típico
• praça da alimentação central
• ...

4
Suponha o seguinte

• O Boulevard Shopping pretende construir uma nova
  área. Vários aspectos do novo negócio foram
  levantados pelos executivos. É chegado o momento
  de traçar os planos e prazos da nova construção.
  Eles pretendem uma construção rápida, pois vários
  lojistas estão à espera. Os construtores foram
  divididos em times. Ao time mais experiente foi
  entregue a tarefa de traçar a arquitetura do novo
  shopping. Cada parte da arquitetura foi entregue
  a um dos time para construção.
• O que foi obtido ao final?

5
Certo. Mas nós não entregamos modelos...

• No negócio software, nós entregamos código, e
  temos um certo desconforto em trabalhar com
  modelos.
• Porém, se olhamos para o negócio da construção
  civil, eles entregam prédios e não plantas e,
  não iniciam um novo projeto complexo sem começar
  por desenhos de tais estruturas físicas.

6
Nós construímos o shopping!
7
Construir uma arquitetura de software é similar...

• Na construção civil é lugar comum sente-se a
  necessidade de plantas antes de se iniciar uma
  nova construção.
• Existem vários aspectos que se relacionam com
  integridade, integração entre equipes,
  consistência nos detalhes.
• Um plano de atividades é gerado, definindo uma
  sequência clara, incluindo aspectos de sua
  estrutura entradas de luz, tolerância a ventos
  fortes, (em alguns casos) suportar movimentação
  de equipamentos pesados. Ou seja, existem
  condições típicas e atípicas a serem
  consideradas.
• O que resulta de uma arquitetura incompleta?

8
Adaptações na arquitetura...
É muito fácil obter um sistema espaguete!
9
...as adaptações podem levar ao caos!

• Tudo começa com as primeiras decisões de cortes
  ou extensões na arquitetura, com a justificativa
  de melhor atender aos requisitos. Aumenta o
  número de ajustes e o acoplamento cresce a ponto
  de não se poder mais isolar os componentes.
• É assim que um sistema deve evoluir?

10
É a desintegração do sistema, não sua evolução!
11
Seria um problema do negócio Software?

• Um sistema típico de software é perecível,
  resultado de

• incertezas
• no comportamento do sistema
• nas próximas release
• baixa qualidade
• difícil rastrear falhas
• difícil consertar bugs
• difícil alterar
• duro atender às mudanças
• custa mais, leva mais tempo

• Baixo reuso
• difícil isolar blocos para reuso
• blocos são muito específicos (orientados)
• problemas éticos
• perda de market share
• o concorrente é melhor
• não há retorno

12
A Arquitetura faz a diferença!

• Uma arquitetura é algo mais que um rascunho
  desenhado do sistema
• A arquitetura é alinhada a...

13
Conceitos chaves

• Decomposição do sistema
• Como eu quebro o sistema em partes?
• Tenho todas as partes necessárias?
• As partes se encaixam?
• Trade-offs de interesse
• Aspectos de qualidade mais abrangentes ou
  propriedades específicas do sistema (RNF e SLA)
• Relação entre os atributos de qualidade
• Integridade do sistema

14
Decomposição da arquitetura as partes se
encaixam?

• Ao atribuir essa tarefa para o melhor
  engenheiro do time, que entende de
• Motor
• Transmissão
• Suspensão
• Etc
• Podemos construir o melhor carro?

15
Arquitetura deve ter foco nas propriedades mais
críticas primeiro

• Ideia chave a integridade do sistema não pode
  ser alcançada de forma bottom-up
• Você irá precisar de uma visão mais abrangente do
  sistema
• Analise os trade-offs existentes para assegurar
  que as propriedades críticas do sistema continuam
  sendo atendidas quando você o decompõe em partes
• Projete os mecanismos da arquitetura que
  endereçam as propriedades do sistema

16
Decisões Arquiteturais Uma questão de escopo
Quanto mais abrangente a decisão, menos erros
podem ser inseridos! Diferencie decisões de
design de decisões de implementação.
17
Ou seja...

• Se temos em mãos uma dada aplicação, todas as
  decisões que podem ser tomadas por projetistas de
  componentes ou desenvolvedores devem ser
  atribuídas a eles e não surgir como parte da
  arquitetura. Se o escopo da arquitetura é uma
  linha de produtos, então toda decisão referente a
  um dado produto deve constar, pelo menos, na
  arquitetura do produto se não for possível
  constar na arquitetura da linha de produtos.
• Qualquer decisão deve focar no impacto sobre o
  sistema decisões arquiteturais devem focar nas
  propriedades de alto impacto nas áreas que estão
  altamente alinhadas com a estratégia do negócio.

18
Escopo das decisões arquiteturais Exemplo do
Reuso
19
Escopo das decisões arquiteturais Exemplo do
Reuso

• Quando focamos num dado produto, todas as
  decisões são orientadas para atender às demandas
  do respectivo cliente o que torna tais
  componentes menos adequados para outros produtos.
  
• Ao construir arquiteturas devemos analisar os
  trade-offs de forma mais ampla, adequando-os aos
  sistemas globalmente. Decisões sobre propriedades
  individuais devem ser consideradas como parte da
  arquitetura do sistema como um todo.

20
Escopo das decisões arquiteturais Impacto
Baixo Impacto Alto Impacto
Sistêmicas (escopo amplo) Não arquitetural Foco da decisão arquitetural
Local Não arquitetural Em geral, não arquitetural
21
Prioridades do sistema

• A atenção deve estar voltada para as áreas de
  alta prioridade e para os trade-offs entre elas
• o negócio (estratégias, competências e recursos)
• o mercado (clientes, concorrentes e parceiros)
• tecnologia (desafios e oportunidades)
• riscos (investimentos em tecnologias e sistemas
  legados)
• desafios ao sucesso do sistema (desenvolvimento
  em si e do negócio)

22
Arquitetura de Software Conceitos chaves

• Decomposição do sistema
• Trade-offs entre propriedades
• Integridade do sistema

• Alinhamento com o negócio
• Com a estratégia do negócio
• Com o ambiente do negócio
• Legado
• Cultura
• Evolução do sistema
• Vida longa!
• Esquema para a estratégia de implementação
• Lidar com as mudanças, inevitáveis!

23
Não esqueça!

• Decisão bottom-up ? Estratégia bottom-up
• Pode ser um caminho muito arriscado! Nesse caso a
  estratégia real do negócio irá ser resultante das
  decisões dos desenvolvedores...
• Estratégia top-down Estratégia do
  negócio?Estratégia da arquitetura?Estratégia da
  implementação
• A estratégia do negócio é quem dirige a
  arquitetura, que é traduzida tecnicamente para
  suportar toda a evolução do desenvolvimento.

24
Por quê isto é tão importante?

• Permite que sejamos
• Mais produtivos
• Mais criativos
• Mais orientados por nossa estratégia
• De forma que podemos ser
• Mais flexíveis, dando retorno ágil
• aos ajustes necessários (mudanças)
• fazendo mais
• Ser um player dominante no mercado
• Estar no negócio, mesmo 5 anos mais tarde

25
O que é uma arquitetura? (definição formal)

• arquitetura é a estrutura do sistema, que
  compreende
• componentes ou partes da implementação
• as propriedades visíveis externamente desses
  componentes, e
• as relações entre eles.

26
Arquitetura componentes e relações

• Componentes
• Blocos (alto nível) do sistema
• Suporta
• Modularidade
• Separação de papéis
• Colaboração entre componentes
• Prover serviços (funcionalidades)
• Num dado nível de serviço (qualidades)
• Interface entre componentes
• Provê encapsulação, com pontos de acesso
  restritos
• Especificação dos componentes
• Define propriedades visíveis externamente
• Provê guias de utilização

27
Propriedades visíveis externamente o propósito
das interfaces

• Interfaces
• Define os pontos de acesso aos componentes
• Facilita o plug-and-play entre componentes
• ameniza restrições entre clientes e provedores
• Serve como um contrato entre provedores de
  componentes e clientes
• Define externamente propriedades visíveis
• Uma interface bem definida
• Facilita o entendimento e compreensão do
  comportamento do componente e como ele é usado
• Aumenta a produtividade do desenvolvedor
• Foca na montagem e ligação entre componentes
  através de suas interfaces

28
Modelos de arquiteturas

• Ferramentas para apoiar a criação
• Explora alternativas e ideias (mais barato que
  prototipar ou tentar uma versão teste do sistema)
• Por exemplo, explorar as colaborações entre
  componentes para definir as operações da
  interface
• Documentam a arquitetura
• Descritiva ou explícita
• Auxilia na visualização do sistema

29
Visões da arquitetura

• Clientes diferentes apresentam diferentes
  informações sobre suas necessidades

30
Stakeholders da arquitetura

• Gerentes
• Arquitetos
• Desenvolvedores
• QA
• Suporte
• Marketing
• Usuários
• Tomadores de decisão (mercado)
• Administradores de sistemas

31
Visões da arquitetura

• Arquitetura Conceitual
• Diagramas arquiteturais, especificação informal
  de componentes
• Foco identificação e alocação de
  responsabilidades entre componentes

Visão global do sistema

• 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

• Esquema para os desenvolv
• preciso
• Sem 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.

32
Endereçando trade-offs

• (re)Lembrando arquitetura aborda
• a decomposição do sistema em componentes
• foco nas propriedades críticas do sistema e seus
  trade-offs
• Trade-offs devem ser endereçados
• Através de padrões arquiteturais
• Estrutura componentes e interfaces
• Mecanismos papéis dos componentes e padrões de
  interação
• Responsabilidades (atribuídas aos componentes)
• Comportamento expresso nas interações
• fluxo das interações

33
Visões da arquitetura
Qualidades do sistema encapsulação e separação
de papéis

• 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

Mecanismos e interações entre 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.

Topologia do sistema/recursos e concorrência
34
Processo de construção de uma arquitetura
Objetivos

• Criar uma arquitetura
• BOA, tecnicamente válida e bem documentada
• CORRETA, satisfaz aos requisitos dos stakeholders
• De SUCESSO, como as utilizadas na construção civil

35
Processo de construção da arquitetura
36
Conclusão

• Uma arquitetura Boa, Correta e de Sucesso
• Não aparece do nada
• É necessário
• Planejar (tempo!)
• Documentar e seguir avaliando (não é algo
  estático)
• As vezes, joga-se fora e recomeça do zero
• Existe uma contribuição a ser dada por cada um de
  nós

37
Referências

• http//www.bredemeyer.com
• http//www.ewita.com
• http//www.extra.research.philips.com/natlab/sysar
  ch/index.html

38
Padrões de Desenvolvimento
39
Motivação

• Orientação a Objetos enfatiza a notação dos
  diagramas
• Ótimo para especificação e documentação
• Mas O.O. envolve mais que diagramas
• Bons desenhistas nem sempre são bons projetistas
• Bons projetistas se apóiam na experiência
• O mais poderoso reuso é a reutilização de padrões
• Combina o problema com os padrões de projeto já
  existentes

40
Motivação

• O.O. explora estruturas de design que promovem
• Abstração
• Flexibilidade
• Modularidade
• Elegância
• O problema seria a captura, comunicação e
  aplicação deste conhecimento

41
Padrões de Desenvolvimento

• Abstrai uma solução de projeto reutilizável
• Organiza classes e objetos em termos de
• Dependências
• Estrutura
• Interações
• Convenções
• Nomeia e especifica a solução explicitamente
• Traduz experiência em desenvolvimento

42
Padrões de Desenvolvimento

• Divide-se em quatro partes
• Nome
• Descrição do Problema
• Solução
• Conseqüências e considerações acerca de sua
  utilização
• Independente de linguagem ou implementação
• Utiliza a simbologia da UML

43
Padrões GoF

• Adapter
• Facade
• Composite
• Bridge
• Singleton
• Observer
• Mediator
• Proxy
• Chain of Responsibility
• Flyweight
• Builder
• Factory Method

• Abstract Factory
• Prototype
• Memento
• Template Method
• State
• Strategy
• Command
• Interpreter
• Decorator
• Iterator
• Visitor
• Model-View-Controller

44
Adapter

• Converte a interface de uma classe naquela
  esperada pelos clientes
• operacaoAlvo() deve executar metodoNegocios()

45
Facade

• Oferece uma interface única para um conjunto de
  interfaces
• Simplifica a utilização dos subsistemas

46
Singleton

• Garantir que uma classe só tenha uma única
  instância, e prover um ponto de acesso global a
  ela
• Precisa de um construtor privado e um método para
  obter a instância global (estática)

47
Proxy

• Método para que um objeto possa controlar o
  acesso a outro
• Normalmente utilizado em objetos distribuídos

48
Flyweight

• Usar compartilhamento para suportar grandes
  quantidades de objetos refinados eficientemente
• Constituem pools, onde a quantidade de objetos
  pode ser significativamente inferior ao seu nível
  de utilização

49
Abstract Factory

• Prover uma interface para criar famílias de
  objetos relacionados ou dependentes sem
  especificar suas classes concretas
• Exemplo de utilização é o J2EE

50
Strategy

• Promover diferentes estratégias para resolver um
  determinado problema em diferentes condições
• Na prática permite a implementação de diferentes
  algoritmos através de diferentes classes

51
Mais alguns...

• State implementa diferentes reações às mudanças
  de estado de um objeto
• Decorator acrescenta responsabilidades
  dinamicamente aos objetos
• Iterator acessa os elementos de uma coleção
  sequencialmente
• MVC divide o aplicativo em três camadas
  independentes, relacionadas à persistência,
  interface visual e regras de negócios

52
Padrões J2EE

• Front Controller
• View Helper
• Composite View
• Service to Worker
• Dispatcher View
• Intercepting Filter
• Value Object
• Session Facade

• Composite View
• Value Object Assembler
• Value List Handler
• Service Locator
• Business Delegate
• Data Access Object
• Service Activator

53
Front Controller

• Centraliza o controle das requisições do cliente,
  permitindo um único ponto de manipulação na
  entrada
• Aumenta a segurança no acesso
• Define a saída visual correta (Front Controller /
  View Controller)

54
Composite View

• Cria uma interface visual complexa a partir de
  interfaces menores
• Tipicamente utilizado em portais

55
Business Delegate

• Desacopla camadas de apresentação e serviços
• É utilizado um como fachada para cada SessionBean
• Normalmente precisa de um localizador de serviços
  (JNDI)
• Este processo retira o código de localização do
  cliente

56
Session Facade

• Desacopla camadas de apresentação e modelo
  (EntityBean)
• Reduz as chamadas remotas do cliente,
  concentrando no SessionBean
• Transações implementadas no SessionBean ou no
  Container (CMT)

57
Mais alguns...

• Value Object concentra as propriedades
  referentes às entidades, permitindo o envio de um
  objeto com informações completas e,
  conseqüentemente, reduzindo o número de chamadas
• Data Access Object concentra as operações de
  persistência, desacoplando as camadas de
  modelo(Entity), e permitindo um meio comum e
  genérico de acesso aos dados armazenados
• Service Activator utilizado na execução
  assíncrona de serviços, sendo apoiado por uma
  fila de mensagens