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 (continuação)
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.
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 Visão de Processo Visão Física Visão de Desenvolvimento
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.
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.
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.
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
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
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 herança, associações e agregações.
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 como CORBA ou memória compartilhada.
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.
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).
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*. * http://www.sei.cmu.edu/ata/arch_duties.html
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 Gerenciamento de Risco
Ligação Estabelece a ligação entre o cliente/consumidor ou equipe de vendas e os times de desenvolvimento.
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
Conhecimento de Tecnologia Arquitetos devem ter um profundo conhecimento de tecnologias. Deve ter conhecimento para avaliar e escolher componentes e tecnologias de terceiros.
Gerenciamento de Riscos Bons arquitetos devem ser cautelosos. Eles constantemente enumeram e avaliam os riscos associados com o desenho e as tecnologias escolhidas.
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 especial em um contexto determinado aplicativo.
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. Permite aos arquitetos reduzir os riscos através de projetos bem sucedidos com atributos de engenharia conhecidos.
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.
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 mensagens podem ser enviadas, e assim por diante. Estes são considerados todos os detalhes de implementação.
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.
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).
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.
Padrões e Tecnologias
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.
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 selecionar um produto que tem os atributos de qualidade que satisfaçam os requisitos da aplicação.
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.
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. A história da indústria de software está cheia de más escolhas e subseqüentes projetos fracassados.
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 sub-ótimas feitas parcialmente no escuro