• Nenhum resultado encontrado

UFG - Instituto de Informática

N/A
N/A
Protected

Academic year: 2021

Share "UFG - Instituto de Informática"

Copied!
31
0
0

Texto

(1)

UFG - Instituto de Informática

Curso: Sistemas de Informação

Arquitetura de Software

Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 3 – Introdução à Arquitetura de Software

(2)

Visões de Arquitetura

 Uma arquitetura de software representa um

artefato de design complexo.

 Para a maioria dos artefatos complexos,

existem várias maneiras de olhar e compreender uma arquitetura.

(3)

Visões de Arquitetura

O termo “pontos de vista da arquitectura” ganhou destaque no papel de Philippe Krutchen de 1995, relativo ao modelo de visão 4 +1.

Este apresentou uma maneira de descrever e compreender uma arquitetura baseada em quatro seguintes pontos de vista:

 Visão Lógica

(4)

Visão Lógica

 Descreve os elementos significativos da

arquitetura e as relações entre eles.

 O ponto de vista lógico, essencialmente, capta

a estrutura da aplicação, utilizando diagramas de classe ou equivalentes.

(5)

Visão de Processo

 Isto foca na descrição dos elementos de concorrência

e de comunicações de uma arquitetura.

 Em aplicações de TI, as principais preocupações

estão descrevendo componentes multi-threaded ou replicados, e os mecanismos de comunicação síncrona e assíncrona utilizada.

(6)

Visão Física

 Isso mostra como os principais processos e

componentes são mapeadas para o hardware aplicações.

 Ele poderá mostrar, por exemplo, como os

servidores de banco de dados e web para um aplicativo são distribuídos por um número de máquinas servidoras.

(7)

Visão de Desenvolvimento

 Isto capta a organização interna dos

componentes de software, normalmente como eles são mantidos em um ambiente de desenvolvimento ou uma ferramenta de gerenciamento de configuração.

 Por exemplo, a representação de um pacote

aninhado e hierarquia de classes para uma aplicação Java

(8)

Visões e Além

Isto recomenda capturar um modelo de arquitetura usando três diferentes visões:

 Módulo

 Componente e Conector  Alocação

(9)

Módulo

 Esta é uma visão estrutural da arquitetura,

incluindo o código de módulos, tais como classes, pacotes e subsistemas no projeto.

 Ele também capta módulo de decomposição, a

(10)

Componente e Conector

 Esta visão descreve os aspectos

comportamentais da arquitetura.

 Os componentes são geralmente objetos,

threads ou processos, e os conectores descrevem como os componentes interagem.

 Conectores comuns são tomadas, middleware

(11)

Alocação

 Esta visão mostra como os processos na arquitetura

são mapeadas para o hardware, e como eles se comunicam através de redes e ou bancos de dados.

 Ele também capta uma vista do código fonte dos

sistemas de gestão de configuração, e que no grupo de desenvolvimento tem a responsabilidade de cada módulo.

(12)

Visões e Além

 A terminologia utilizada em “Visões e Além" é

fortemente influenciada pela descrição da comunidade de pesquisa de linguagem arquitetura (ADL).

(13)

O que um arquiteto de software

faz?

 O ambiente que um arquiteto de software trabalha em

tende a definir exatamente seus papéis e responsabilidades.

 Uma boa descrição geral do papel do arquiteto é

mantido pela SEI em seu web site*.

(14)

O que um arquiteto de software

faz?

Em vez de resumir isso, vamos descrever brevemente, em nenhuma ordem particular, quatro competências essenciais para um arquiteto de software, independentemente do seu ambiente profissional.

 Ligação

 Engenharia de Software

 Conhecimento de Tecnologia

(15)

Ligação

 Estabelece a ligação entre o

cliente/consumidor ou equipe de vendas e os times de desenvolvimento.

(16)

Engenharia de Software

 Os arquitetos devem promover boas práticas

de engenharia de software.

 Seus projetos devem ser devidamente

documentadas e comunicadas, e seus planos devem ser explícitas e justifica

(17)

Conhecimento de Tecnologia

 Arquitetos devem ter um profundo

conhecimento de tecnologias.

 Deve ter conhecimento para avaliar e escolher

(18)

Gerenciamento de Riscos

 Bons arquitetos devem ser cautelosos.

 Eles constantemente enumeram e avaliam os

riscos associados com o desenho e as tecnologias escolhidas.

(19)

Arquiteturas e Tecnologias

 Os arquitetos devem tomar decisões de projeto no

início de um ciclo de vida do projeto.

 Muitos destas decisões são difíceis, se não

impossíveis, para validar e testar até que partes do sistema são realmente construídas.

 Prototipagem judiciosa das principais componentes da

arquitetura podem ajudar a aumentar a confiança em uma abordagem de design, mas às vezes ainda é difícil ter certeza do sucesso de uma opção de design

(20)

Arquiteturas e Tecnologias

 Devido à dificuldade de validar as decisões

iniciais do projeto, arquitetos de forma sensata experimentam abordagens testadas para resolver certas classes de problemas.

 Este é uma das grandes vantagens de padrões

arquitetônicos.

(21)

Arquiteturas e Tecnologias

 Os padrões são uma representação abstrata

de uma arquitetura, no sentido de que pode ser realizado em múltiplas formas concretas.

(22)

Exemplo

 O padrão de arquitetura Publish-Subscribe descreve

um mecanismo abstrato para baixo acoplamento.

 A comunicação de muitos para muitos entre os

Publicadores de mensagens e Assinantes que desejam receber as mensagens.

 No entanto, não especifica como publicações e

assinaturas são geridos, quais os protocolos de comunicação são utilizados, quais os tipos de

(23)

Padrões e tecnologias

 Infelizmente, descrições abstratas de

arquiteturas não executam ainda em computadores, quer diretamente, quer através da transformação rigorosa.

 Até que eles fazem, arquiteturas abstratas

devem ser reificadas pelos engenheiros de software como implementações concretas de software.

(24)

Padrões e Tecnologias

 Felizmente, os vendedores de produtos de

software têm vindo para o resgate.

 Padrões de arquitetura amplamente utilizados

são suportados em uma variedade de tecnologias comerciais de prateleira (COTS).

(25)

Padrões e Tecnologias

 Se um projeto exige publicação/assinatura de

mensagens (Publisher-Subscriber), ou um corretor de mensagens (Message Broker), ou uma arquitetura de três camadas, em seguida, as escolhas das tecnologias disponíveis são muitas e variadas.

 Este é um exemplo de tecnologias de software que

fornece o software reutilizável, independente da aplicação das infra-estruturas que implementam abordagens comprovadas de arquitetura.

(26)
(27)

Padrões e Tecnologias

 Dentro de cada classe há produtos

concorrentes comerciais e open source.

 Embora esses produtos sejam superficialmente

similares, terão diferentes conjuntos de recursos, seja implementada de forma diferente e têm diversas limitações à sua utilização.

(28)

Padrões e Tecnologias

 Arquitetos são um pouco simultaneamente abençoada

e amaldiçoada com essa diversidade de escolha de produtos.

 A concorrência entre os fornecedores de produtos

guia a inovação de drives, melhores funcionalidades e implementações, e preços mais baixos.

 Porém, coloca um fardo sobre o arquiteto para

(29)

Padrões e Tecnologias

 Todas as aplicações são diferentes em alguns

aspectos, e há raramente, ou nunca, há um produto que se encaixa em tudo.

 Diferentes implementações COTS tem diferentes

conjuntos de pontos fortes e fracos e os custos e, consequentemente, ser mais adequada para alguns tipos de aplicações do que outras.

(30)

Padrões e Tecnologias

 A dificuldade para arquitetos está na compreensão

destes pontos fortes e fracos no início do ciclo de desenvolvimento de um projeto, e escolher uma reificação adequada dos padrões arquitetônicos que precisam.

 Infelizmente, esta não é uma tarefa fácil, e os riscos e

custos associados à seleção de uma tecnologia inadequada são elevados.

(31)

Resumindo

“The life of a software architect is a long (and sometimes painful) succession of sub-optimal decisions made partly in the dark”

[Philippe Krutchen]

“A vida de um arquiteto de software é uma grande sucessão (e por vezes dolorosa) de decisões

Referências

Documentos relacionados

Local de realização da avaliação: Centro de Aperfeiçoamento dos Profissionais da Educação - EAPE , endereço : SGAS 907 - Brasília/DF. Estamos à disposição

Verificada a efetividade da proposta, a Comissão de Licitações declarou vencedor o licitante Francisco Souza Lima Helm, sendo o total do item 14 licitado o valor de

Para que o estudo seja possível, houve um levantamento bibliográfico sobre o cenário do sistema produtivo da saúde no Brasil, tendo em vista a proteção

Para atingir este fim, foram adotados diversos métodos: busca bibliográfica sobre os conceitos envolvidos na relação do desenvolvimento de software com

Objetivo: Garantir estimativas mais realistas e precisas para o projeto, ao considerar nesta estimativa o esforço necessário (em horas ou percentual do projeto) para

Ainda segundo Gil (2002), como a revisão bibliográfica esclarece os pressupostos teóricos que dão fundamentação à pesquisa e às contribuições oferecidas por

c.4) Não ocorrerá o cancelamento do contrato de seguro cujo prêmio tenha sido pago a vista, mediante financiamento obtido junto a instituições financeiras, no

Para disciplinar o processo de desenvolvimento, a Engenharia de Usabilidade, também conceituada e descrita neste capítulo, descreve os métodos estruturados, a