Curso: PCS3553 - Laboratório de Engenharia de Software II (2019)
PCS3553 - Laboratório de Engenharia de Software II (2019)
Expectativas e contextos, incluindo inovação e transformação digital, ocorrendo na indústria;
Organização de conteúdo e entregas da disciplina;
Apoio material.
Definição do projeto/tema prático da disciplina.
Referencias: ISO 25010, Visões de arquitetura, Taticas Arquiteturais Arquivo
Top 15 Best Global Brands Ranking (2000-2018) URL
Algoritmos em tempo real Arquivo
Planejamento de aulas Arquivo
Proposta de Valor Arquivo
- 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);
Repositório - Exemplo Android + Flask URL
Android Maps sample Arquivo
Diagrama Conceitos e Tecnologias Arquivo
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.
- 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.
Exemplo: Diagramas que compõem uma visão. Arquivo
Arquitetura e controle de qualidade Arquivo
Exercicio exemplo Arquivo
IoT Infra estrutura Arquivo
Exemplo Blynk IoT Arquivo
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.
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.
Como conectar os requisitos com as decisões arquiteturais? Arquivo
ISO 25010 Arquivo
Força de modelagem Arquivo
Taticas arquiteturais Arquivo
Exemplo de modelagem e documentação de um sistema Arquivo
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.
Material da aula anterior Arquivo
Material para o dia da prova P1 (em 03/04) Arquivo
Material para a preparação da prova Arquivo
Interface em linguagem livre, natural Arquivo
Interface de Voz Arquivo
Aula 6 - Prova P1
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).
Lista de Itens - Preparação da Prova - Anotações do Quadro Arquivo
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.
1) Como identificar os microserviços do sistema?
Microservices Arquivo
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).
Exemplo Taticas Arquiteturais Arquivo
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?
Exemplo e questões sobre arquitetura em microservicos Arquivo
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.
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.
Testes Funcionais e Testes não Funcionais Página
Testes e Garantia de Qualidade Arquivo
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.