54
Arquitetura de Software Questões relevantes, geralmente não abordadas Fábio Nogueira de Lucena Instituto de Informática (UFG) XVI Jornada Goiana em Engenharia de Software

Arquitetura software

Embed Size (px)

Citation preview

Page 1: Arquitetura software

Arquitetura de SoftwareQuestões relevantes, geralmente não abordadas

Fábio Nogueira de LucenaInstituto de Informática (UFG)

XVI Jornada Goiana em Engenharia de Software

Page 2: Arquitetura software

Direitos autorais

Imagens obtidas da internet

Uso interno apenas

Page 3: Arquitetura software

Vamos “limpar” nossa mente eesclarecer algumas questões...

Isso não é uma introdução!

Page 4: Arquitetura software

Arquitetura de Software é meio

Objetivos do negócio

Implementaçãodo software

Arquitetura de Software

Requisitos Projeto Construção

Page 5: Arquitetura software

Visão funcional

Definir a Arquitetura de Software

Requisitos

Conhecimento; Experiência; “Plágio”; Intuição; Restrições; ...

Representação daArquitetura de Software

Processo definido por

Page 6: Arquitetura software

Especificações de Requisitos de Software

Quem lê?

Page 7: Arquitetura software

Especificações de área, volume, dimensões,...

Pessoas preferem “navegar” pelo domínio da solução

Page 8: Arquitetura software

Por que usar “documentação executável”?

Estratégia para reduzir riscos.

Requisitos “compreendidos” e executáveis!

Arquitetura que admite testes “facilmente”

Page 9: Arquitetura software

Representação (apresentadas como arquitetura)

Page 10: Arquitetura software

Mais ilustrações

Page 11: Arquitetura software

Mais ilustrações

Page 12: Arquitetura software

Mais ilustrações

Page 13: Arquitetura software

Outra exemplo

Page 14: Arquitetura software

Mais uma representação “bonita”

Page 15: Arquitetura software

“Diagrama conceitual” (antes era “arquitetura”)

Java 8(JDK 1.8)

Page 16: Arquitetura software

Contexto (escopo)

Arquitetura Corporativa

Arquitetura de Sistema

Arquitetura de

Software

Impõe restrições

Impõe restrições

hardware + software + pessoas

Como software apoia objetivos do negócio?

Sistema. LZFSE oferece baixo consumo de energia.

Corporativa. Departamento ocioso, que usa Python é agregado ao projeto.

Page 17: Arquitetura software

Todo software possui uma arquitetura

Qualquer software pode ser “pensado” pelos seus elementos e relações.

Todo software possui uma arquitetura,mesmo que seja desconhecida

Documentaçãoda arquitetura

Arquitetura de

Software

Existe independente da documentação

Page 18: Arquitetura software

Como registrar a “motivação” de uma decisão?

Documenting Architecture DecisionsMichael Nygard

Page 19: Arquitetura software

Nem todas arquiteturas são iguais

Arquitetura pode permitir ou inibir um requisito

Dadas duas arquiteturas, uma pode ser“melhor” que a outra

Tentativa & Erro Design Avaliação

Inaceitável

Page 20: Arquitetura software

De fato, uma arquitetura de software pode ser...

Documentada

Projetada

Analisada

Page 21: Arquitetura software

"Arquitetos devem tomar decisões, ...que devem ser documentadas,revisadas e aprovadas, além de servircomo restrição para a futura construção."

Page 22: Arquitetura software

On Architecture: The Accidental ArchitectureGrady Booch,IEEE Podcast

“Arquitetura acidental surge como resultado de numerosas decisões ao longo do desenvolvimento.”

“Arquitetura intencional é uma arquitetura explicitamente identificada e só então implementada.”

Page 23: Arquitetura software

O que é arquitetura de software?

“É o conjunto de estruturas, compostas de elementos e dasrelações entre eles.”

Page 24: Arquitetura software

Modelagem da definição de arquitetura

Page 25: Arquitetura software

Estruturas e visões

Estruturas

Visões

Documentadas por

Visão A Visão B

Representações distintas (por exemplo, stakeholders distintos)

Page 26: Arquitetura software

ISO/IEC/IEEE 42010:2011Systems and SoftwareEngineering -- Architecture Description

Page 27: Arquitetura software

Categorias de estruturas(estática) Módulos

Divide o sistema em unidades de implementação, distribui responsabilidades

Base para atribuição de tarefas a equipes de programação

Estrutura estática (classes, camadas, …)

(dinâmica) C&C (component-and-conector)

Componente = entidade que existe apenas em tempo de execução

Estrutura dinâmica

Foco na interação entre os elementos da estrutura

Alocação

Mapeamento das estruturas em:

Ambientes de execução

Instalação

Desenvolvimento

Page 28: Arquitetura software

Estruturas de módulos (estática)

Qual a principal responsabilidade?

Quais elementos um módulo pode usar?

Quais os módulos usados por um módulo?

Quais os relacionamentos entre módulos? (herança)

Page 29: Arquitetura software

Exemplo de módulos (SGBD)

Page 30: Arquitetura software

Outros exemplos (outros SGBDs)

Page 31: Arquitetura software

Estruturas C&C

Quais os principais componentes em execução?

Como interagem em tempo de execução?

Quais partes do sistema são executadas em paralelo?

Page 32: Arquitetura software

Alocação

Em qual processador cada elemento de software é executado?

Em quais diretórios cada elemento é armazenado durante o desenvolvimento?

E durante os testes e building?

Qual equipe desenvolve cada elemento?

Page 33: Arquitetura software

Exemplo de “alocação”

O que esse diagrama diz?

Page 34: Arquitetura software

Se tivermos “muitos” usuários?

Instalar e configurar Adobe Flash => Suporte

Page 35: Arquitetura software

Quais são os demais elementos?

1. Web Server2. Apache3. Application Server4. Tomcat5. Servlet (aplicação)6. JVM (omitida)7. JDBC8. Database Server9. MySQL

Page 36: Arquitetura software

Qual é o problema?

Web ServerApacheApplication ServerTomcatServlet (aplicação)JVM (omitida)JDBCDatabase ServerMySQL

● Configuração complexa● Monitoramento● Instalação● Atualização

Page 37: Arquitetura software

Resposta para configurar e instalar

Deploy. Manage systems. Crush complexity.

Web ServerApacheApplication ServerTomcatServlet (aplicação)JVM (omitida)JDBCDatabase ServerMySQL

Page 38: Arquitetura software

Distribuição (“sem instalação”)

Web ServerApacheApplication ServerTomcatServlet (aplicação)JVM (omitida)JDBCDatabase ServerMySQL

Page 39: Arquitetura software

Monitorar (antecipar problemas, manter em operação)

Web ServerApacheApplication ServerTomcatServlet (aplicação)JVM (omitida)JDBCDatabase ServerMySQL

Pode exigir uso de JMX

Page 40: Arquitetura software

Ligação com tecnologia

Por que Tomcat?

● Java○ Jetty, WebLogic, Glassfish,

JBoss, JOnAS, Resin, WildFly, …○ GAE (Google)○ Netty○ Spray○ Grizzly○ Vert.x○ Mina

● Windows○ .Net Core (Web API)○ .Net Framework

● C○ libmicrohttpd, facil.io, libuv,

nanomsg, lighttpd, ...

Algumas opções:

Arquiteturas lógicas e físicas.

Page 41: Arquitetura software

Estrutura “preferida”: decomposição

Tende a “dirigir” a estrutura do projeto por “espelhar” a estrutura de equipes de desenvolvimento.

“Organizações que projetam sistemas… tendem a produzir projetos que são cópias das estruturas de comunicação dessas organizações.” Lei de Conway.

Pesquisadores do MIT e Harvard Business School“Equipes distribuídas tendem a desenvolver software mais modular”

Page 42: Arquitetura software

“Uma equipe” vs “Várias” (influência na arquitetura)

Especialização de tarefas Equipes multidisciplinares

Page 43: Arquitetura software

Requisitos de qualidade (como me orientar?)

34 páginas!

Page 44: Arquitetura software

Nem todos os requisitos de qualidade são RARs

RAR: Requisito Arquiteturalmente Relevante

Stakeholders distintos, interferências distintas.

Stakeholder “relevante” (SR) r1, r2, …, rn (definidos pelo SR)

Subconjunto relevante = { si, sj, sk }(priorizados)

Page 45: Arquitetura software

“Prática” (SGBD)

Database System ImplementationMolina, Ullman e WidomPrentice-Hall, 2000

Componentes de um SGBD(página 7, figura 1.1)

Page 46: Arquitetura software

SGBD (recorte para análise)

Query compiler

Execution engine

Simplificação?

Page 47: Arquitetura software

Recorte Query compiler para query compilation

Page 48: Arquitetura software

Módulos de um compilador

Page 49: Arquitetura software

Módulos de um compilador

Page 50: Arquitetura software

O que o “mundo” está falando sobre o assunto?

DevOps, Entrega Contínua

Page 51: Arquitetura software

Compreender cenários “complexos”

Menos elementosMais elementos, combinação mais complexa, maiores riscos

Page 52: Arquitetura software

Visualização (CodeCity) (raio X para software)

Page 53: Arquitetura software

Seria bom estar lá...

Um dos mini-cursos:We’ll focus on the eight core principles

stability, reliability, performance, scalability, fault-tolerance, catastrophe-preparedness, monitoring, and documentation.

Susan FowlerReliability engineer at Uber

Page 54: Arquitetura software

Alegrem-se na esperança, sejam pacientes na tribulação. Romanos 12:12