ANA2001 – Análise de Sistemas e de Requisitos

Software II

Universidade do Estado de Santa Catarina

Centro de Ciências Tecnológicas – DCC

Prof. Dr. William Alberto Cruz Castañeda

2021/2
[ Especificação e Aplicação de Requisitos
Não Funcionais ]
Requisitos Não Funcionais

• Requisitos de um sistema quando ele é implantado (requisitos operacionais);

• Não possui um modelo especifico em UML;
• Restrições arquitetônicas e operacionais são as principais fontes;

Duas categorias:

1. Restrições → informa o que o sistema não pode fazer.

2. Qualidade → partes interessadas nos negócios informam o que desejam do sistema em uma
função.

3
4
Estabelecer um projeto de arquitetura começa com os Requisitos Não Funcionais.

1. Refinar os requisitos não funcionais em requisitos mais detalhados que são usados para
ajudar a selecionar a arquitetura e quais componentes do software serão colocados em cada
dispositivo.
2. Requisitos não funcionais e o projeto de arquitetura são usados para desenvolver a
especificação de hardware e software.
3. Quatro tipos principais de requisitos não funcionais são importantes no projeto de
arquitetura: operacionais, desempenho, segurança e culturais/políticos.

5
6
Requisitos Operacionais

Especificam os ambientes operacionais em que o sistema deve executar e como esses podem
mudar com o tempo.

Geralmente se refere a sistemas operacionais, software de sistema e sistemas de informação

com os quais o sistema deve interagir. Também inclui o ambiente físico.

7
8
Requisitos de Desempenho
Concentram-se em questões como tempo de resposta, capacidade e confiabilidade.

9
Requisitos de Segurança

Capacidade de proteger o sistema contra interrupções e perda de dados, seja causada por um
ato intencional ou um evento aleatório.

Responsabilidade operacional → instalação de firewalls, sistemas de detecção de intrusão,

rotinas de backup e recuperação.

Responsabilidade no desenvolvimento → garantir que os requisitos do sistema produzam

precauções razoáveis para evitar problemas. Desenvolvedores são responsáveis por garantir a
segurança nos próprios sistemas.

10
11
Requisitos Políticos e Culturais

12
[ Projeto de Arquitetura ]
• Descreve os ambientes de hardware, software e rede do sistema.

• Obtida a partir dos requisitos não funcionais (operacionais, desempenho, segurança,

culturais, políticos, etc.).

• Inclui a arquitetura e as especificações de hardware e software.

• Etapa importante → plano de como o sistema será distribuído entre computadores e que
hardware e software serão usados para cada computador.

14
[ Elementos ]
O objetivo do projeto de arquitetura é determinar quais partes do software serão atribuídas ao
hardware. Todos os sistemas de software podem ser divididos em quatro funções básicas:

1. Armazenamento de dados (gestão de dados e persistência de objetos);

2. Logica de acesso a dados (gestão de dados e classes de manipulação);

3. Logica da aplicação (casos de uso, diagramas de atividades, sequencia, comunicação,

maquinas de estado);

4. Logica de apresentação (interface de usuário);

16
Blocos de construção básicos de qualquer software.

17
Principais componentes de hardware de um sistema são:

1. Clientes → dispositivos de E/S (desktop, laptops, smartphones, terminais, etc.);

2. Servidores → computadores usados para processamento e armazenamento com softwares e

hardwares que podem ser acessados por qualquer pessoa que tenha permissão.

3. Rede → permite conectar os computadores. Pode variar em velocidade.

18
Arquiteturas baseadas em Servidor

• Simples e funcional.
• Servidor executa todas as funções.
• Clientes enviam e recebem mensagens do servidor.
• Software armazenado e dados em um computador.
• Ponto de controle.
• Problema → servidor processa todas as mensagens.
• Aumento na demandas sobrecarrega e pode se tornar incapaz de processar as solicitações.
• Tempo de resposta lento.

19
Arquiteturas baseadas no Cliente
• Simples e funcional.
• Clientes em rede local (LAN) e servidor na mesma rede.
• Clientes responsáveis pela lógica de apresentação, lógica do aplicativo e lógica de acesso a
dados, o servidor armazena os dados.
• Problema → dados no servidor devem ser transferidos ao cliente para processamento.
• Aumento da demanda, rede pode ficar sobrecarregada.

20
Arquiteturas Cliente - Servidor

• Equilibra o processamento.
• Lógica do software no cliente ou no servidor ou pode ser dividida.
• Cliente responsável pela lógica de apresentação, servidor responsável pela lógica de acesso a
dados e armazenamento de dados.

21
• Prática atual é implementar o uso de thin clients porque há menos sobrecarga e manutenção
no suporte ao software.

22
Benefícios

• Escalabilidade → fácil aumentar ou diminuir os recursos de armazenamento e

processamento dos servidores (para executar a lógica da aplicação, lógica de acesso a dados
ou armazenamento de dados).
• Suporte a vários clientes e servidores;
• Acesso simples e separado de logica de aplicação, apresentação e acesso a dados por meio
do uso de padrões.
• Confiável → não existe um só servidor que suporta toda a aplicação.

23
Camadas Cliente-Servidor

Arquitetura em duas camadas → implementa dois conjuntos de computadores, clientes e

servidores.

24
Arquitetura de três camadas → utiliza três conjuntos de computadores. Cliente responsável
pela lógica de apresentação. Servidor (ou servidores) responsável pela lógica de aplicação e um
servidor (ou servidores) de banco de dados responsável pela lógica de acesso a dados e
armazenamento de dados.

25
Arquitetura de n camadas → utiliza mais de três
conjuntos de computadores. Cliente responsável pela
lógica de apresentação. Servidor (ou servidores) de
banco de dados responsável pela lógica de acesso a
dados e armazenamento de dados. Lógica do aplicativo
é distribuída por dois ou mais conjuntos diferentes de
servidores.

Vantagem → separa o processamento para equilibrar a

carga nos diferentes servidores. É mais escalável.

26
[ Modelo de Rede ]
• Focado em mostrar os principais componentes do sistema e suas localizações geográficas
em toda a organização.

• Objetivo duplo: transmitir a complexidade do sistema e mostrar como os componentes de

software do sistema interagem (se encaixam).

• Ajuda a desenvolver as especificações de hardware e software.

• Cria diagramas de alto e baixo nível.

28
Diagrama de alto nível

29
Diagrama de baixo nível

30
Diagrama de baixo nível

31
Diagrama de baixo nível

32
ANA2001 – Análise de Sistemas e de Requisitos
Software II

Universidade do Estado de Santa Catarina

Centro de Ciências Tecnológicas – DCC

Prof. Dr. William Alberto Cruz Castañeda

2021/2