Projeto de Software

Aula 4 - 2023/2

Profª. Sofia Costa Paiva

sofialarissa@ufg.br
Arquitetura de Software
● Conceito
● Sistemas Distribuídos
● C4 Model - Diagrama de
Contexto
○ PlantUML -
notação para
escrever o
diagrama

2
●

3
PlantUML
● Linguagem para descrição e geração de diagramas:
http://www.plantuml.com/plantuml/
● Pode gerar Diagramas do C4 Model
● Exemplo:
@startuml
!include
https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_
Container.puml

Person(personAlias, "Label", "Optional Description")

Container(containerAlias, "Label", "Technology", "Optional Description")
System(systemAlias, "Label", "Optional Description")

Rel(personAlias, containerAlias, "Label", "Optional Technology")

4
@enduml
Exercício
1. Usando um Diagrama de Contexto, faça
uma possível visão arquitetural para um
sistema Web de emissão de passagens
aéreas.

5
Exercício
1. Usando um Diagrama de Contexto, faça
uma possível visão arquitetural para um
sistema Web de emissão de passagens
aéreas.

6
Sistemas Distribuídos
● Sistema mais complexo que os sistemas centralizados, o que
os torna mais difíceis de projetar

7
Questões Fundamentais
de Projeto

8
Ao disponibilizar um produto Qual é a característica mais
de software…
importante?

9
● Re

10
Escalabilidade
● Re

11
Como medir a qualidade de software?
● ISO/IEC 25010 define um conjunto de 8 características internas e
externas de produto de software
○ Adequação funcional
○ Confiabilidade
○ Usabilidade
○ Eficiência de desempenho
○ Segurança
○ Compatibilidade
○ Capacidade de manutenção
○ Portabilidade

12
Como medir a qualidade de software?
● ISO/IEC 25010 define um conjunto de 8 características internas e
externas de produto de software
○ Adequação funcional
○ Confiabilidade
○ Usabilidade
○ Eficiência de desempenho
○ Segurança
○ Compatibilidade
○ Capacidade de manutenção
○ Portabilidade

13
Confiabilidade
● É o software que se mantém com um comportamento consistente
com o esperado ao longo do tempo
● Tem relação com a minimização da quantidade de defeitos do
software e com a forma como ele funciona perante situações
anômalas

● Subcaracterísticas:
○ Maturidade
○ Disponibilidade
○ Tolerância a falhas
○ Recuperabilidade
14
Confiabilidade
● Subcaracterísticas:
○ Maturidade: medida da frequência em que um software apresenta
defeitos. Software maduro apresenta menos defeitos em um período de
tempo fixo.
○ Disponibilidade: avalia o quanto o software está operacional e disponível
para uso quando necessário
○ Tolerância a falhas: tem relação com a forma como o software reage
quando em situação anômala. Requisitos de tolerância a falhas deveriam
ser definidos durante o projeto de software. Um software que consegue
continuar funcionando mesmo quando ocorrem falhas tem boa
avaliação em relação a essa qualidade
○ Recuperabilidade: capacidade de recuperar dados e colocar-se
novamente em operação após uma situação de desastre/situação mais
crítica 15
Eficiência de desempenho
● Otimização do uso de recursos de tempo e espaço.
● Muitas vezes é necessário evoluir o uso de recursos de tempo e
espaço em um sistema, para atender a demanda que pode crescer.
○ ESCALABILIDADE
○ Reflete sua capacidade de oferecer um serviço de alta
qualidade, uma vez que aumenta a demanda de sistema.
○ Neuman (1994) identifica três dimensões de escalabilidade:
■ Tamanho
■ Distribuição
■ Capacidade de gerenciamento

16
Eficiência de desempenho
● ESCALABILIDADE
○ Neuman (1994) identifica três dimensões de escalabilidade:
○ Tamanho: deve ser possível adicionar mais recursos a um sistema para
lidar com um número crescente de usuários
■ Escalar para cima: substituir recursos por outros mais poderosos.
Ex.: aumentar a memória do servidor de 16GB para 64GB
■ Escalar para fora: adicionar recursos ao sistema. Costuma ser
mais efetivo, mas o sistema precisa ser projetado para
processamento concorrente. Ex: colocar um servidor Web extra ao
lado do servidor existente
○ Distribuição: deve ser possível dispersar geograficamente os
componentes de um sistema sem comprometer seu desempenho
○ Capacidade de gerenciamento: é possível gerenciar um sistema à
medida que ele aumenta de tamanho, mesmo que partes dele estejam
localizadas em organizações independentes 17
Segurança/Proteção
● Devem ser estabelecidas políticas de proteção para o sistema
● Tipos de ataques dos quais um sistema distribuído deve se defender
○ Intercepção: a comunicação entre as partes do sistema são
interceptadas por um invasor de tal modo que haja perda de
confidencialidade
○ Interrupção: serviços de um sistema são atacados e não podem ser
entregues conforme o esperado. Pode envolver bombardear com
solicitações de serviço ilegítimas, para que ele não consiga lidar com
solicitações válidas
○ Modificação: dados ou serviços no sistema são alterados por um
invasor
○ Fabricação: um invasor gera informações que não deveriam existir e, em
seguida, usa-as para obter alguns privilégios. Ex.: invasor pode gerar
uma entrada de senha falsa e usá-la para obter acesso a um sistema 18
Segurança/Proteção
● Como o sistema pode ser projetado para que os ativos críticos
(dados, códigos, etc) possam ser protegidos de ataques externos?

19
Segurança/Proteção
● Como o sistema pode ser projetado para que os ativos críticos
(dados, códigos, etc) possam ser protegidos de ataques externos?
○ Proteção
● Como os ativos de sistema devem ser distribuídos de modo que os
efeitos de um ataque bem-sucedido sejam minimizados?

20
Segurança/Proteção
● Como o sistema pode ser projetado para que os ativos críticos
(dados, códigos, etc) possam ser protegidos de ataques externos?
○ Proteção
● Como os ativos de sistema devem ser distribuídos de modo que os
efeitos de um ataque bem-sucedido sejam minimizados?
○ Distribuição

21
Atividade
1. Identifique diretrizes gerais (boas práticas) de projeto de
software que fazem com que os software construídos sejam
protegidos, seguros, com bom desempenho e confiáveis
a. Coisas que devem estar no código-fonte ou em outros artefatos
para que o software atenda a essas características de qualidade

22