Projeto Arquitetural

Fundamentos da Análise Arquitetural

Trata de modelos que ajuda o implementador a construir o software.

Questões Principais

• Como decompor um sistema em diversos pacotes e subsistemas?
• Quais classes devem estar em cada subsistema de forma a permitir mais reutilização de subsistemas?
• Quais dependências entre os subsistemas?
• Quais os conectores devem ser usados entre os subsistemas?
• Como distribuir cada um dos subsistemas em diferentes nós de processamento?
• Apenas um subsistema em cada maquina ou mais de um?
• Qual o impacto no resto do sistema se agruparmos ou separarmos subsistemas em diferentes nós?

 Propriedades do sistema

• Escala: número de usuários 
• Capacidade: de atender ao um certo número de requisições
• Degradação: como o sistema se comporta (degrada) se a capacidade for ultrapassada
• Desempenho
• Portabilidade

Projeto arquitetural identifica:

• Componentes: definem onde ocorre o processamento;
• Conectores: mediam as interações entre os componentes;
• Propriedades: informações para a construção e análise;

Modelo "4+1" visões arquiteturais

• Visão de projeto ou lógica: estamos interessados em definir a funcionalidade do sistema, vocabulário dos objetos de negócio do sistema
• Visão de implementação ou componentes: definir o gerenciamento da configuração, quais os elementos que vão fazer parte da configuração do sistema. Aqui definimos como fazer o build do sistema.
• Visão de processo: interessados na visão de execução do sistema, nessa etapa que nos preocupamos com as propriedades do sistema (acima). 
• Visão de implantação: mostra como os componentes de software estão mapeados pelos componentes de hardware. (Topologia, distribuição, fornecimento, instalação, etc)
• Visão de caso de uso: diagrama de casos de uso.

A visões são como as diferentes visões de uma casa, como a planta baixa, projeto elétrico, projeto hidráulico, maquete 3D, etc.

Pontos de Variação e Evolução 

• Pontos de Variação: variações previstas nos requisitos do sistema.
• Ponto de evolução: pontos especulativos de variação que podem surgir no futuro mas que não estão presentes nos requisitos existentes.

Passos para fazer análise arquitetural:

• Identificar e analisar os requisitos não-funcionais e funcionais
• Analisar alternativas e criar soluções que resolvam o impacto, documentando as decisões arquiteturais

Fatores arquiteturais

• Segurança
• Como o controle de segurança afeta o projeto do sistema para evitar uso indevido do sistema?
• Confiabilidade, tolerância a falhas
• Como os requisitos de confiabilidade e tolerância a falhas afetam o projeto?
• Custo
• Custo de software de terceiros adquiridos vai afetar os lucros, etc.
• Adaptabilidade, configurabilidade
• Como afetam o projeto?
• Desempenho, capacidade e degradação
• Como afetam o projeto?
• Usabilidade
• Como impacta no projeto?
• Restrições de projeto
• Como as interfaces externas com outros sistemas, o ambiente de desenvolvimento e execução impactarão na solução?
• Restrições de Processo
• Como a documentação exigida, normas e processos a serem seguidos no desenvolvimento vão impactar a arquitetura?

Padrões Arquiteturais

São formas conhecidas para se estruturar um sistema. Se diferem um dos outros nos componentes, nas formas de conexão e formas de se conectar.

Categorias de padrões arquiteturais

• Sistemas de fluxo de dados;
• Disponibilidade dos dados controla a computação;
• Estrutura baseia-se na transferência ordenada de dados entre componentes;
• Não há outra forma de interação entre componentes;
• Variações: Batch sequencial, pipe-e-filtro e padrão de camadas;
• Exemplo: comunicação entre camadas de redes (ISO/OSI)
• Sistemas de chamada-e-retorno;
• Sistema em rede;
• Cliente-servidor: 
• Em geral, clientes iniciam as computações e interagem com usuários. Servidores: executam as computações e provêm recursos.
• P2P
• Componentes executam em máquinas distintas;
• Cada componente age como ambos, cliente e servidor.
• Em geral, existe um servidor centralizado onde os componentes se registram.
• É um padrão resiliente. Tolera a remoção de componentes.

• Sistemas interativos;
• Repositórios;
• Sistemas orientados a serviços;
• Componentes são serviços de organizações possivelmente diferentes (provedores).
• Conectores são XML
• Aplicações que requisitam os serviços, são os consumidores
• Existe um diretório de serviços (banco de dados) onde eles podem ser descobertos
• Requisitante pode ser uma aplicação, web service, mobile, etc.
• Computação nas nuvens
• Funcionalidade é toda através de serviços
• Está fora da empresa que necessita do serviço
• As maquinas são virtualizadas. Configuradas de acordo com a necessidade, como o S.O.
• Os recursos são escaláveis
• Gerenciamento
• Serviços são providos no modelo de pilha
• IaaS: Infra Ex: EC2 (Amazon)
• PaaS: Plataforma Ex: Google AppEngine, MS Azure
• SaaS: Software (Aplicação) Ex: SalesForce

Arquitetura na UML

Voltar no modelo 4+1

• Visão de casos de uso
• É um resumo dos casos de uso mais significativos
• Ilustra a cobertura arquitetural mais significativa
• O caso de uso "Processar Venda" exercita vários elementos arquiteturais, por isso, é interessante detalhar. Podemos incluir realizações, contratos de operação, diagramas de interação.
• Visão lógica ou de projeto
• Mostra a organização conceitual do software, em termos de camadas, subsistemas, pacotes, frameworks, classes importantes.
• É uma visão para o modelo de projeto do RUP
• Visão de implementação ou de componentes
• Inclui os componentes utilizados para montar e entregar o sistema físico
• Um componente de software é uma unidade indivisível de um sistema. Ex: Banco de dados, navegador web.
• Podem ser substituídos por outros componentes que fazem a mesma coisa
• Caixa preta com interface bem definida
• Fornece ou requisita serviços a outros componentes
• Visão de implantação
• Representa a topologia física do sistema e componentes que são executados nessa topologia. Mostra um mapeamento entre elementos de hardware e software.
• Elementos do diagrama são os nós de processamento e conexões.
• Nós: processadores, sensores, etc. (executam software)
• Conexões: meio físicos de comunicação (cabos), ou protocolos (tcp, etc)

Arquitetura na UML

Como representar arquitetura na UML, utiliza os conceitos de:

• Pacotes
• É um mecanismo para agrupar vários artefatos de um modelo
• Podem conter outros pacotes
• Podem existir relacionamentos entre pacotes

• Interfaces 
• É um conjunto de especificações de serviço
• Não contém estrutura interna (diferente de uma classe abstrata)
• Quando uma classe implementa as operações de uma interface, a classe realiza essa interface
• Subsistemas