Programação

  • Aula 1

    Pauta:


    • Expectativas e contextos, incluindo inovação e transformação digital, ocorrendo na indústria;
    • Organização de conteúdo e entregas da disciplina;
    • Equipe de apoio;
    • Apoio material.
    • Definição do projeto/tema prático da disciplina.


  • Aula 2

    Tópicos:

    - Arquitetura de um sistema de Software: Um sistema de software deve atender a uma demanda de negócio ou um domínio de aplicação com desempenho, robustez e tolerância a falhas. Envolve a combinação adequada de aspectos como contexto do mundo real, requisitos de funcionalidades, requisitos não funcionais, mecanismos de engenharia e as tecnologias de implementação. 
    - Desenvolvimento colaborativo: planejamento, gestão, entregas - Trello, Gitlab e os conceitos DEVOPS;
    - Aplicação distribuída na nuvem: Montar uma aplicação internet (Hello world);
    - Consolidação dos temas dos projetos, detalhamento das visões do domínio de aplicação e requisitos (funcionais e não funcionais);

  • Aula 3

    Os requisitos funcionais e os requisitos não funcionais direcionam as decisões arquiteturais. Essas decisões incluem camadas, componentes, algoritmos e mecanismos tais como: controle de tempo de execução e espera (time-outs), verificações, controle de demandas (filas, agentes de execução), criptografia, logs, gerenciadores de banco de dados, servidores de aplicação, entre outros.
    Algumas questões:
    - O que é uma solução técnica? Ela atende ao conjunto de requisitos do sistema de maneira positiva (contribui) ou de maneira negativa (prejudicando). Exemplo: Se o aspecto não funcional usabilidade estiver aprofundado em termos de trazer facilidades de uso, pode acontecer que o aspecto não funcional segurança/privacidade esteja prejudicada. O equilibrio (custo/benefício - tradeoff) é o racional das decisões.
    - Como mapear requisitos com as decisões arquiteturais? Uma técnica possível é a das táticas arquiteturais;
    - Exemplificar uma solução técnica - exemplo da automação da iluminação.

  • Aula 4

    Considerando a arquitetura de um sistema, como documentar? As visões indicam as possibilidades, sempre focando utilidade em contraponto ao excesso de documentação:
    Visão 1 - Negócios - Diagramas de processos, com destaques aos business drivers, estatísticas e regras de negócio devem ressaltar o valor adicionado aos clientes e demais stakeholders - BPN, IDEF0, Tabelas e Algoritmos;
    Visão 2 e Visão 3: Requisitos Funcionais e não funcionais - Modelagem estática: diagramas de classes de negócios; Modelagem dinâmica: cenários, diagramas de sequencia e diagrama de estados; Tabelas, textos e algoritmos para descrição de requisitos não funcionais;
    Visão 4: Engenharia: Diagramas de componentes, métodos, frameworks, plataformas, mecanismos que atendem aos requisitos. Lembrar que estes são decisões arquiteturais e produzem tradeoffs de arquitetura. O que serve de "remédio" para um requisito pode servir de "veneno" para outro requisitos. Exemplo: Volume x Tempo de Resposta; Facilidade de uso X Segurança, Desempenho x Facilidade de manutenção, entre outros;
    Visão 5: Tecnologia: Diagramas das plataformas de hardware, software e aplicativos, envolvendo linguagens e bibliotecas.
    Outro aspecto importante das visões conectadas: É o controle de qualidade do sistema? O que deve ser testado prioritariamente? Quais os requisitos funcionais e não funcionais a serem testados? Programas e ferramentas para testar requisitos críticos, especialmente os não funcionais? E o tratamento de incidentes? Qual a origem, recorrência, frequência? Os tratamentos dos incidentes devem cobrir o reativo/paliativo e o preventivo.
    Como aplicar a automação no ciclo de vida dos artefatos: fontes, builds e testes dos requisitos funcionais e não funcionais.


    Conceito:

    Táticas arquiteturais - segundo a SEI/CMU - são diagramas que conectam atributos de qualidade (ligados aos requisitos) com as decisões arquiteturais.
    Na indústria é muito comum a falta de métodos ou base de conhecimentos deficientes. Esse conhecimento fica na experiência de algumas pessoas, de maneira Ad Hoc.


  • Aula 5

    Tópicos:
    1 - Revisão sobre táticas arquiteturais;
    2 - Conceitos sobre microsserviços (Problematização);
    3 - Plataformas - Ferramentas de NLU;
    4 - Ajustes do trabalho: dúvidas, detalhamento do projeto.


  • Aula 6 - Prova P1

    Apresentação do Trabalho:


    V1 - Domínio do problema, negócios, business drivers;


    V2/V3 - Requisitos Funcionais e Não Funcionais (modelagem estrutural, dinâmica e demais especificações);


    V3 - Solução técnica (Hardware, Software e Mecanismos não Funcionais).

  • Aula 7

    As decisões arquiteturais estabelecem os mecanismos de implementação - hardware, software, integração. São constituídos por elementos tais como: processadores, cores, threads, componentes, dispositvos entre outros. Importante destacar que esses mecanismos atuam positivamente em alguns requisitos, e negativamente em alguns requisitos, criando as situações de tradeoff: exemplo, uso de mecanismos de segurança pode atrapalhar a usabilidade. Atender grandes volumes, pode atrapalhar o tempo de resposta e assim por diante. O entendimento das táticas arquiteturais permite a aferição (e testes) dos mecanismos arquiteturais, assim como a documentação.

    Na estrutura de implementação, outro aspecto importante do software nos mecanismos é o desacoplamento e baixa coesão nos elementos do software, facilitando a manutenção e testes. Nesse sentido, os microserviços é um dos pontos bastante explorado em soluções técnicas da atualidade.

    Arquiteturas orientadas a microservicos são bastante alinhados às técnicas ágeis, incluindo o devops. Módulos pequenos com testes automatizados com cobertura adequada garantem qualidade e produtividade.

    Temos a seguinte questão:
    1) Como identificar os microserviços do sistema?

  • Aula 8

    Ganhar agilidade por testes com boa cobertura e garantia de um sistema robusto em termos funcionais e não funcionais é fácil falar e difícil fazer. Em termos de microserviços, podemos indicar os seguintes aspectos que contribuem para os ganhos:

    • Módulos menores é mais fácil testar;
    • Baixo acoplamento e alta coesão garante menor impacto das mudanças;
    Ver os exemplos práticos.
    Ainda relacionados aos mecanismos de arquitetura por microserviços: Base de Dados na nuvem e mecanismo de hardware " just-in-time "  (servless computing).


  • Aula 9

    Quais conceitos, ferramentas e práticas foram discutidas nas aulas até o momento? Uma lista:

    - Business Driver e Adição de Valor (Ficha de Osterwalder);

    - Esteira de agilidade (Scrum/Trello, Sprints, Github) - DEVOPS;

    - Referência arquitetural - RM ODP (5 visões que conecta negócio com aspectos de engenharia);

    - Requisitos não funcionais como diferenciadores de sistemas de software: A funcionalidade deve ser suportada por mecanismos definidos e adotados como decisões de arquitetura para suportar os requisitos alinhados com as necessidades de negócio (explicitos e implícitos) tais como: desempenho em tempo de resposta, usabilidade, precisão, integridade, privacidade, rastreabilidade, acessos simultâneos, entre outros;

    - Organização dos mecanismos como microserviços, buscando na prática a alta coesão e baixo acoplamento para facilitar os procedimentos de aferição da qualidade;

    - Plataformas distribuídas na nuvem, interfaces naturais por voz e texto livre, dispositivos smartphones;

    Onde estamos no Projeto nas aulas (9, 10, 11 e 12)?

    Na implementação. Aqui as seguintes abordagens de engenharia podem ajudar a evidenciar os avanços dos projetos:

    1 - Protótipos de interação humano-computador;

    2 - Componentes de integração - PoC de arquitetura de integração. Esses componentes podem implementados como dois aspectos fundamentais: interface de acesso (parâmetros de entrada, de saída, pre-condições e pós-condições) deve ser especificada e implementada; O conteúdo pode ser simulado, para facilitar a integração;

    3 - Organizar as sprints considerando os aspectos de integração:

    - Interfaces Humano-computador;

    - Lógica de negócio;

    - Acesso a sistemas externos;

    4 - Veja o exemplo de uma estrutura de implementação em microserviços, em anexo, e reflita sobre as seguintes questões:

    • Como organizar Sprints?
    • Como considerar as integrações com sistemas externos/legados?
    • Como considerar os Microserviços?
    • Como considerar os requisitos não funcionais de Disponibilidade?
    • Como considerar is RNFs de Acesso Simultâneo?


  • Aula 10

    Acompanhamento das atividades de implementação:

    - Como estão organizados as sprints?

    - Como os requisitos não funcionais estão considerados nas sprints?

    - Avaliar as implementações já realizadas.

    LEMBRETE: a implementação dos MVPs deve ser implementada até o final de maio.

    • Aula 11

      Entregas ao final da disciplina:

      1) Modelo de Negócio com destaque do Business Drivers;


      2) Especificação de Requisitos: destacar pelo menos 3 RFs e 3 RNFs;


      3) Projeto da Solução Técnica, com detalhamento das táticas arquiteturais para pelo menos 3 RNFs;


      4) Implementação técnica de 3 RFs e pelo menos 2 RNFs, evidenciando o impacto no Business Drivers;

      5) Documentação no GITHUB, incluindo a codificação e as especificações de hardware, com as respectivas configurações.


    • Aula 12

      Avaliação de um sistema: Existe método ou é um trabalho para pessoas que conhecem muito o sistema?


      Para reflexão: Quando um sistema apresenta erros sob carga; quando apresenta problemas de disponibilidade prejudicando negócios; quando um sistema apresenta erros de cálculo e de consulta para os usuários; entre outras situações. Como melhorar? Bastam a bateria de testes funcionais? E os testes não funcionais resolvem?
      Neste caso, saber os pontos positivos e os pontos de vulnerabilidade do sistema e com isso, estabelecer prioridades considerando os recursos disponíveis e criticidade de negócio é o mais adequado. Qual a engenharia para fazer isto?


      Resumo: Como avaliar um sistema de TI? 


      Resposta AdHoc : Aferindo se ele atende
      aos requisitos. A equipe, experiente no desenvolvimento, já sabe dos pontos
      críticos do sistema e avalia diretamente tais pontos. Este procedimento não é
      repetível, e muito provavelmente sem racional/justificativas do que avaliar,
      como avaliar e como atuar para obter resultados.
      Resposta com Método: 


      1) Identifica os fluxos direcionadores (drivers) de negócios suportados pelo sistema, com claras identificações de riscos e danos causados ao domínio de negócios;


      2) Mapeia os elementos estruturais que integrados constituem a solução - visão de alto nível da infraestrutura do sistema. Pode ter ênfase em hardware, software ou combinação. Nesta visão, a forma o comportamento dinâmico do sistema para executar os fluxos críticos de negócio é entendido e questões sobre como a precisão, robustez, segurança, tolerância a falhas, desempenho são entendidos, explicados (ou não);


      3) Dessa visão conjunta, estabelece-se a régua de qualidade de engenharia: cada atributo importante definido valores, percentuais de garantias dos valores;


      4) Adicionalmente, acrescenta-se riscos e não riscos;


      5) Medição - Mapa de cenários arquiteturais que ajudam a certificar os papos dos itens 1) a 4);


      6) Medição - Aferir na prática (sistemas em produção) e conceitualmente/simulação/PoC (sistemas em desenvolvimento);


      7) Avaliar os resultados, com destaques aos pontos positivos, negativos, riscos, não riscos e tradeoffs do sistema.


      8) Comunicação dos resultados.


      Esses tópicos constituem o método ATAM - é repetível e tem o seu racional justificado: cria-se a régua da qualidade (referência/sarrafo) direcionados pelo domínio da aplicação (problema), mede-se e avalia-se com base em resultados aferidos.


    • Aula 13 (05.06.2019)

      Implementação e Ajustes

      Tira-dúvidas.

      • Aula 14 (12.06.2019)

        Implementação e Ajustes

        Tira-dúvidas.


        • Aula 15 (19.06.2019)

          Prova P2


          • DEMONSTRAÇÃO DAS FUNCIONALIDADES;
          • ENTREGA DA DOCUMENTAÇÃO.


          Lembrete:

          -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

          1) Modelo de Negócio com destaque do Business Drivers;


          2) Especificação de Requisitos: destacar pelo menos 3 RFs e 3 RNFs;


          3) Projeto da Solução Técnica, com detalhamento das táticas arquiteturais para pelo menos 3 RNFs;


          4) Implementação técnica de 3 RFs e pelo menos 2 RNFs, evidenciando o impacto no Business Drivers;

          5) Documentação no GITHUB, incluindo a codificação e as especificações de hardware, com as respectivas configurações.

          -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------


          e-Disciplinas - Ambiente de apoio às disciplinas da USP