Arquitetura de Software e APIs

Aula 7. Parte 1

• A aula recapitula os conteúdos anteriores, mencionando User Story e User Mapping, e apresenta uma persona de vendedor com ações em um sistema de vendas.
• É enfatizada a importância de traduzir as necessidades do cliente para uma arquitetura de software adequada.
• São abordados os conceitos de projeto preliminar, projeto detalhado e a definição de arquitetura de software.
• Projeto preliminar visa mapear e identificar uma potencial arquitetura de software, relacionando-se ao "como".
• API (Interface de Programação de Aplicações) é um conjunto de definições e protocolos para criar e integrar softwares de aplicações.
• A arquitetura de software define a organização do sistema, estabelecendo elementos estruturais, interfaces, comportamento por colaboração entre elementos e composição em subsistemas.
• O design da arquitetura deve vir antes da escolha da tecnologia.
• A arquitetura de software serve como ponte entre os requisitos de negócio e a aplicação propriamente dita.
• Concorrência ocorre quando vários usuários tentam acessar o mesmo tipo de funcionalidade.
• A interface do usuário (UI) é o espaço de interação entre usuários e um site, programa ou aplicativo, incluindo telas, mouse, teclados e a aparência da área de trabalho.
• A arquitetura precisa ser projetada para facilitar a manutenção e permitir evoluções e correções de forma clara.
• O modelo de visão 4+1, desenvolvido por Philippe Kruchten, descreve o funcionamento de sistemas de software através de múltiplas visões concorrentes.
• A Prova de Conceito (POC) é uma etapa de teste para verificar se um software atende aos requisitos da organização antes da contratação.

Requisitos e Arquitetura de Software

• Além dos requisitos funcionais, os requisitos não funcionais (disponibilidade, usabilidade, desempenho, confiabilidade, segurança e manutenibilidade) influenciam fortemente a arquitetura do software.
• Aspectos-chave na arquitetura de software incluem concorrência, controle e tratamento de eventos, distribuição de componentes e tratamento de exceções e tolerância a falhas.
• Características de um software bem arquitetado: performance, escalabilidade e flexibilidade.
• Equilíbrio entre as prioridades do cliente, como desempenho e segurança, é crucial.
• As decisões do engenheiro de software devem ser baseadas nos interesses do cliente.

Aula 7. Parte 2

• No padrão de segurança centralizada, o conceito de manutenibilidade e sua relação com a performance são revistos
• Problemas a serem solucionados considerando segurança e usabilidade são apresentados, abordando o padrão de segurança em níveis e a relação entre disponibilidade e time-to-market, além de componentes redundantes.
• A segurança centralizada simplifica o acesso à informação, centralizando os dados em um único local, mas também pode levar a perda de todos os dados em caso de falha de segurança.
• Uma arquitetura com múltiplos bancos de dados pode ser mais lenta e cara.
• Componentes redundantes permitem que um sistema substitua componentes com falha utilizando outros recursos.
• O foco da organização dos componentes deve estar nos componentes de larga escala, analisando elementos essenciais sem se ater aos detalhes.
• O modelo de camadas é utilizado para demonstrar a organização dos componentes, com cada camada tendo uma área de responsabilidades independente e interfaces bem definidas.
• Questões transversais na arquitetura de camadas relacionam aspectos como segurança, performance e disponibilidade.

Aula 7. Parte 3

• É abordado o conceito de UML (Linguagem Unificada de Modelagem) e modelos de diagramas (atividades, classes, sequência, componente e implantação).
• Todas as classes mapeadas em um diagrama UML precisam mostrar propriedades/atributos e comportamentos/métodos.
• Diagramas UML auxiliam a equipe de desenvolvimento a visualizar soluções de software de forma ilustrativa.
• UML Serve para modelar e documentar as fases do desenvolvimento de sistemas orientados a objetos
• Diagramas são empregados em softwares complexos, para entender a solução, regras de negócio complexas, documentar a implantação, modelar estruturas de dados e reutilizar partes do projeto.
• Diagramas ajudam a equipe de desenvolvimento no entendimento sobre os aspectos estruturais e comportamentais da solução.
• Diagramas de atividades podem esclarecer fluxos de execução complexos.
• Uma classe UML representa um objeto ou conjunto de objetos com a mesma estrutura e comportamento.

Padrões de Projeto

• "Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos" (GoF) divide os padrões em 24 tipos, classificados em criação, estruturais e comportamentais.
• Um padrão de projeto é expresso como contexto, problema e solução, considerando escopo de classe ou objeto.,
• Um padrão é uma regra expressa em três partes: contexto, problema e solução

Padrão Strategy

• Permite a criação de uma família de classes para variações de um algoritmo, delegando a execução para diferentes instâncias de Strategy em tempo de execução.

Padrão Singleton

• Garante que uma classe tenha apenas uma instância e fornece um ponto de acesso global a essa instância, evitando múltiplas instancias.
• O uso de padrões deve facilitar a leitura e manutenção do código.

Aula 7. Parte 4

• A arquitetura de software facilita o desenvolvimento, instalação, operação e manutenção do sistema.
• Formas de arquitetura em camadas são apresentadas para relembrar os conceitos vistos, refletidos numa atividade de implementação e citadas as características de um bom arquiteto de software.
• Um bom arquiteto maximiza as decisões que não precisam ser tomadas no início.
• Bons arquitetos separam os detalhes dos objetivos do projeto.

Arquitetura Limpa

• Apresenta o paradigma revolucionário com Código Limpo (Robert C. Martin).

Características tradicionais da arquitetura:

• Independência de frameworks, testabilidade, independência da interface com o usuário, independência de gerenciadores de banco de dados e independência de agentes externos.

Arquitetura Limpa

• Propõe uma estrutura em elipse das mais internas para as mais externas (regras de negócio, regras da aplicação, adaptadores de interface, frameworks e drivers).
• Os círculos mais externos contém "mecanismos", enquanto os mais internos contêm "políticas".
• As regras de negócio raramente sofrem alterações devido a solicitações relativas à aplicação em si.
• As regras da aplicação encapsulam e implementam os casos de uso/user stories.
• O nível de adaptadores de interface converte os dados para formatos convenientes para os casos de uso e para níveis externos, como persistência e GUI.
• O nível de frameworks e drivers contém serviços dependentes de tecnologia específica (API externa, protocolo de comunicação, etc.).

Aula 7. Parte 5

• O vídeo traz como exercício a criação de um diagrama de classes para uma máquina de venda de bebidas, recomendando o uso da ferramenta Astah.
• O exemplo de uma biblioteca é usado para demonstrar em qual camada classes, interfaces e gerenciadores de banco de dados devem ser inseridos.
• A criação de uma arquitetura de sistema é acompanhada, dividindo em pacote de negócios, pacote de aplicação e adaptadores.
• Os adaptadores requerem conteúdos da camada de aplicação e informações da camada de negócios.
• Arquitetura de software: num sistema existe uma interface com métodos de negócio.
• Astah é uma ferramenta CASE (Computer-Aided Software Engineering) para modelagem de soluções de software usando UML.
• Banco de Dados Relacional: coleção de itens de dados com relacionamentos predefinidos. Organizada como tabelas com colunas e linhas.