Topic outline
-
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.
-
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); -
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. -
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. -
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. -
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). -
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? -
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;
Ainda relacionados aos mecanismos de arquitetura por microserviços: Base de Dados na nuvem e mecanismo de hardware " just-in-time " (servless computing). -
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?
-
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.
-
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. -
Implementação e Ajustes
Tira-dúvidas.
-
Implementação e Ajustes
Tira-dúvidas.
-
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.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -