Introdução a Arquitetura de Software

Introdução a Arquitetura de Software

1. 1.1 Arquitetura de Software

   • Se refere à descrição dos elementos com os quais um sistema é construído, as interações entre estes elementos, os padrões que guiam a sua composição e as restrições nesses padrões.
     • Define a estrutura do software, que compreende os componentes com suas propriedades visíveis externamente e os relacionamentos entre os mesmos.
   • Questões Abordadas
     • Seleção de Alternativas de Projeto
     • Escalabilidade
     • Desempenho Protocolos de Comunicação
     • Sincronização Atribuição de Funcionalidade
     • Componentes de Projeto
   • Uma Arquitetura Pode
     • Atuar como uma estrutura a fim de atender os requisitos de um sistema.
     • Auxiliar na estimativa de custos e no gerenciamento do processo de desenvolvimento
     • Servir de base para a análise de consistência e de dependências
     • Prover suporte ao reuso
   • Questões Fundamentais
     • Existe uma arquitetura genérica que pode atuar como modelo para o sistema?
     • Como o sistema será distribuído?
     • Que padrões ou estilos de arquitetura podem ser usados?
     • Como componentes serão decompostos?
     • Qual a melhor organização da arquitetura para satisfazer requisitos não funcionais?
     • Como o projeto de arquitetura será avaliado?
     • Como a arquitetura deve ser documentada?

2. 1.2 O Arquiteto

   • Características
     • Deve ser capaz de reconhecer estruturas comuns em sistemas já desenvolvidos
     • Deve usar o conhecimento sobre arquiteturas existentes para tomar decisões de projeto em novos sistemas
     • Analisar as propriedades do sistema
     • Apresentar a arquitetura para outras pessoas
   • Habilidades
     • Compreensão profunda do domínio e das tecnologias pertinentes
     • Técnicas de modelagem e metodologias de desenvolvimento
     • Entendimento das estratégias de negócios da instituição onde atua
     • Conhecimento de produtos, processos e estratégias de concorrentes
   • Atividades
     • Modelagem
     • Análise de trade-offs e Viabilidade
     • Prototipação, Simulação e Realização de Experimentos
     • Análise de Tendências Tecnológicas
     • Atuação como Mentor de Arquitetos Novatos

3. 1.3 Integração com Outros Papéis

   • Trabalho do Arquiteto de Software está integrado ao trabalho de vários outros papeis típicos do desenvolvimento de software
   • Analista de Requisitos
     • Discutir os requisitos não funcionais
     • Discutir funcionalidades do sistema
     • Discutir soluções viáveis de arquitetura
     • Apoiar verificações de documentos de requisitos
   • Desenvolvedor
     • Apresentar a arquitetura do sistema
     • Definir padrões de desenvolvimento
     • Atuar como referência técnica dos desenvolvedores
   • Analista de Testes
     • Discutir requisitos e critérios de aceitação, especialmente para requisitos não funcionais
     • Discutir estratégias de automação de testes
     • Apoiar a execução de testes de integração
   • Gerente de Projetos
     • Apoiar o planejamento de atividades técnicas da equipe
     • Acompanhar atividades da equipe
     • Apoiar estimativas de atividades
   • Gestor de Configuração
     • Apoiar a geração de releases e linhas de base
     • Apoiar a disseminação de boas práticas relacionadas à gerência de configuração na equipe de desenvolvimento
   • Equipe de Qualidade
     • Apoiar a formulação de padrões de qualidade
     • Apoiar a inspeção de artefatos técnicos
   • Equipe de Processos
     • Apoiar a escrita de processos (atividades, templates, etc.) relacionados à disciplina de Arquitetura

4. 1.4 Requisitos Arquiteturais

   • Uma condição ou capacidade que deve ser cumprida ou possuída por um sistema ou componente do sistema para satisfazer um contrato, padrão, especificação ou outro documento formal imposto
   • Requisitos Funcionais
     • Especificam ações que um sistema deve executar, sem levar em consideração restrições físicas
   • Requisitos Não Funcionais
     • Descrevem restrições desejadas ou necessárias, atributos do sistema ou de seu ambiente
     • Categorias
       • Confiabilidade
       • Usabilidade
       • Desempenho
       • Suporte
       • Desenho
       • Físico
       • implementação
       • interface
       • Segurança
   • Classificação FURPS+
     • Funcionalidade (Functionality)
     • Usabilidade (Usability)
     • Confiabilidade (Reliability)
     • Desempenho (Performance)
     • Suportabilidade (Supportability)

5. 1.5 UML

   • Componentes
     • Parte encapsulada, reusável do software. São como blocos que combinados formam seu software. Podem ser do tamanho de uma classe até um subsistema
     • Exemplos
       • Para registrar logs
       • Para fazer parsing de documentos XML
       • Para edição de texto
     • Caracteristicas
       • Um componente pode fazer tudo que uma classe faz
       • Não podem ter muita dependência
       • Mudanças em um componente não devem afetar o restante do sistema
       • São acessados por meio de interfaces
       • Precisam ser pouco acoplados para que possam ser alterados sem demandar mudanças no sistema
     • Diagrama
       • Apresentar a disposição dos componentes “físicos” de um sistema
       • Exemplo
         • um .class
         • um .exe
         • uma DLL
       • Interface
         • Fornecida
           • Interface que o componente fornece para outros
         • Demandada
           • Interface que o componente precisa para funcionar
   • Pacotes
     • Permite ordenar e agrupar entidades. Mais comuns: diagramas de pacotes de classes e de casos de uso. Diagrama de pacotes favorece a organização lógica das camadas
     • Estereótipos
       • <<facade>>
       • <<framework>>
       • <<model>>
       • <<stub>>
       • <subsystem>>
       • <<system>>
     • Diretrizes
       • Classes da mesma hierarquia tipicamente pertencem ao mesmo pacote
       • Classes relacionadas a outra por composição frequentemente possuem o mesmo pacote
       • Classes com alto grau de acoplamento em geral devem ser aproximadas pertencendo ao mesmo pacote
   • Implantação
     • Contemplam a visão física do sistema. Abrange os elementos físicos do sistema. Arquivos executáveis e hardware sobre o qual o sistema executa
     • Nodo
       • É um recurso de hardware ou software que pode hospedar software ou arquivos relacionados
         • Podem-se usar nodos para representar elementos de hardware, porém, nodos não precisam ser sempre hardware
       • Exemplos
         • Servidor
         • Computador Desktop
         • Drives de Disco
     • Artefatos
       • São arquivos físicos que executam ou são usados pelo software
       • Exemplos
         • Executáveis, como .exe ou .jar
         • Bibliotecas como dlls
         • Fonte como .java ou .cpp
         • De configuração .xml, .properties, .txt