Resumo Primeira Prova

Assuntos:
- Apresentação da Disciplina
- Conceitos Básicos
- Introdução à Eng. de Requisitos
- Análise e Projeto Orientado a Objetos
- Formulário de Caso de Uso

Apresentação da Disciplina:
❖ Sistema (hardware) X Software (processo);
❖ Software, é um programa de computador com uma documentação associada;
❖ Bom Software, ele tem que ter as funcionalidades e desempenhos pedidas pelo usuário; Além
de ser confiável, eficiente e fácil de manter e usar;
❖ Engenharia de software, é o estabelecimento e uso de técnicas sólidas de engenharia, para
obter um software confiável; se preocupa com os aspectos de produção do software;
❖ Para construir:
➢ Método Empírico (utiliza apenas o conhecimento pessoal além de corrigir erros através
de tentativa e erro; Não possui padronização) X ​Método Científico (faz planejamento,
estuda trabalhos relacionados, verifica padronização, após a construção verifica a
qualidade por meio de experimentos):
❖ Engenharia de software tem como objetivo incentivar o desenvolvimento profissional (científico)
de software, mais do que o pessoal (empírico);
❖ Desafios da E. de Software:
➢ Tempo de entrega curto;
➢ Desenvolver um software confiável, eficiente e de fácil manutenção e uso;

Conceitos Básicos:
❖ Eng. Software
❖ Aplicações de Software:
➢ Básico: conjunto de programa que define o comportamento do equipamento, ou seja,
permite o funcionamento do hardware (Linux, Windows, Android, etc)
➢ Tempo Real: responde dentro de restrições de tempo restrito; monitora e analisa eventos
do mundo real. (software de um avião)
➢ Comercial: facilita as operações comerciais, utilizando técnicas de computação interativa.
(controle de estoque, folha de pagamento, etc)
➢ Científico ou de Engenharia: execução de processamento intenso de números (sistema
de astronomia)
➢ Embutido ou embarcado: controla produtos e sistemas; são caracterizados por utilizarem
uma memória de leitura e usar rotinas limitadas (controle de teclado de microondas, tvs,
etc)
Material produzido por Hévlla Oliveira Souza
 ➢ Computador Pessoal (editor de texto, planilhas, etc)
➢ Inteligência Artificial: uso de algoritmos não numéricos, para resolver problemas
complexos (sistema de reconhecimento de voz, imagem)
➢ P/ internet: são executados na web (firefox, chrome)

❖ Problemas da ES:
➢ manter um programa é caro por projetos ruins (código sem estrutura)
➢ capacidade de construção, não acompanha a demanda crescente
❖ Causas:
➢ Não se dedica tempo necessário para uma coleta de dados, sobre o desenvolvimento do
software;
➢ Comunicação fraca de cliente e desenvolvedor;
➢ Falta de testes completos;
➢ Pouco treinamento formal, para o funcionário;
➢ Gerentes sem portfólio ou sem conhecimento;

Introdução à Eng. de Requisitos

❖ Engenharia de requisitos inclui 4 fases (VA-REV)
➢ Estudo de viabilidade: nesta fase identifica-se os stakeholders e seus diferentes pontos
de vista, ou seja, levantamento de questionamento, na qual se busca conhecer com
maior riqueza de detalhes as necessidades do cliente e funcionalidades do sistema.
➢ Análise de requisitos: (fase de modelagem conceitual) levanta-se os requisitos do usuário
em duas fases:
■ Categoria do requisito:
● R. funcionais: funcionalidade do sistema;
● R. não funcionais: a qualidade do sistema (desempenho, disponibilidade,
etc)
■ Natureza do requisito: que pessoas vão ser envolvidas no sistema (gerente,
cliente, vendedor, etc)
➢ Especificação de requisitos: desenvolvimento dos requisitos de sistema que atende os
requisitos do usuário. Passa de perspectiva de problema para p. da solução.
➢ Validação de requisitos: validação da cobertura do sistema, ou seja, se atende a todos os
requisitos do usuário, assim os stakeholders aceita ou n.
❖ Stakeholders: pessoas que têm influência direta ou indiretamente sobre os requisitos.

Análise e Projeto Orientado a Objetos

❖ Tipos de viabilidade a ser verificada antes da execução:
➢ Econômica: custo benefício; enxergar o potencial de crescimento de mercado pela
ferramenta desenvolvida;

Material produzido por Hévlla Oliveira Souza

 ➢ Técnica: se têm habilidades necessárias, ou seja, existe pessoal treinado para tal
tecnologia? Existe tecnologia existente no mercado que suporte o sistema?
➢ Legal: se o sistema construído está dentro das regras, se não é cópia de outro, etc.
➢ Soluções Alternativas que facilitem o desenvolvimento do sistema;
❖ Relação custo-benefício:
➢ Ponto de Break-even: momento em que os custos e despesas são iguais às receitas do
seu negócio, ou seja, não há lucro ou prejuízo;
❖ Análise (o que o sistema deve fazer/ definição dos problema e requisitos/ uml comportamental) e
Projeto (como o sistema será construído/ solução lógica/ uml estrutural):
➢ Custo da mudança, quanto mais perto do início da produção do software for feito
alterações. menos se pagará pelas mudanças, tendo em vista que, nessa fase a
comunicação deve ser ativa entre as partes interessadas;
❖ UML (​Unified Modeling Language)​ : linguagem padrão para visualizar os resultados das fases de
análise e projeto de sistemas.
➢ Principal notação para descrição de modelagem orientada a objetos.
➢ Usada para especificação, construção, visualização, documentação;
➢ Diagramas se dividem em três tipos de modelagem e duas fases de construção
(análise/projeto):
■ Estático: representa as classes e seus relacionamentos. Abstração da
implementação de um software, assim como suas classes e relacionamentos.
■ Dinâmico: aspectos do sistema que mudam ao longo do tempo, devido a eventos.
Identifica as operações de cada classe.
■ Físico.
➢ Diagramas:
■ Caso de uso: representação dos processos como o ambiente a ser implementado
(atores) Dinâmico/Análise
■ Classe: relacionamento entre os objetos; Estático/ Projeto
■ Estados: como dado objeto responde a estímulo, dado seu estado atual;
Dinâmico/Análise
■ Atividades: quem faz o quê dentro sistema; Dinâmico/Projeto
■ Sequência: como os objetos interagem uns com os outros, para realizar os
processos; Dinâmico/Projeto
■ Colaboração: interação (em torno do objeto) e as ligações dos objetos uns com os
outros; Dinâmico/Projeto
■ Pacotes: onde estão localizados o agrupamento de diagrama de classes;
Físico/Projeto
■ Componentes: organização física do software; Físico/Projeto

Formulário de Caso de Uso:

❖ Os casos de uso servem para enfatizar os objetivos e perspectivas do usuário, pois o maior
motivo de fracasso dos projetos de desenvolvimento é a falta de envolvimento do usuário.

Material produzido por Hévlla Oliveira Souza

❖ Caso de uso é um serviço que o sistema oferece externamente do ponto de vista do ambiente de
negócio, sendo assim, consiste na sequência de eventos de um ator;
❖ Casos de uso são narrativas em texto de algum ator usando um sistema para atingir objetivos.
❖ Caso de uso tem 3 formatos:
➢ Resumido: texto sucinto de um parágrafo que descreve o cenário de sucesso principal do
sistema.
➢ Informal: geralmente em casos de usos que não são diretamente relacionado ao c.u
principal do sistema;
➢ Completo: todos os passos são descritos em detalhes;
❖ Formato do Caso de Uso Completo:

Seção do Caso de Uso Descrição

Nome do caso de uso Começa com um verbo

Escopo Qual o projeto

Nível “Objetivo do usuário” ou “sub-função”

Ator principal Quem chama o sistema para obter serviço

Interessados e Interesse Quem se importa com o c.u e o que desejam?

Pré-condições O que deve existir para começar

Garantia de sucesso O que precisa ser verdade quando for finalizado

Fluxo Básico Descreve o caminho do sistema para o cenário de sucesso

Extensões Caminhos alternativos de sucesso ou fracasso

Requisitos especiais Requisitos não relacionados ao caso de uso (interface)

Lista de Variantes Métodos de entrada e saída de dados (como ler o cartão,

código de barra, qual o tipo de codificação, etc)

Frequência da ocorrência “contínua”, “quase contínua”, “raramente”

Problemas em aberto perguntas que podem ou não envolver o sistema

Material produzido por Hévlla Oliveira Souza

Exercício:

Seção do Caso de Uso Descrição

Nome do caso de uso Cadastrar pedido

Escopo Sistema da Pizza à Pezzi

Nível ?

Ator principal Funcionário

Interessados e Interesse Cliente:​ deseja a exibição de fácil acesso do cardápio,

comprar pizza, pagar pizza;

Funcionário:​ anota pedido, efetua pagamento, passa o

pedido para cozinha, confere e remove itens do estoque
(embalagens e ingredientes), informa estoque faltando.

Cozinheiro​: receber o pedido sem erros, informa que a

pizza está pronta.

Dono:​ adiciona itens ao estoque.

Pré-condições Funcionário está logado no sistema

Garantia de sucesso Venda realizada. Estoque atualizado.

Fluxo Básico 1 - Cliente checa cardápio e escolhe a pizza;

2 - Funcionário anota o pedido;
3 - Funcionário confere o estoque, caso positivo, passo 4,
ao contrário, realiza passo 1 ao 3 novamente;
Funcionário repete os passos 1 à 3, até que indique ter
terminado
4 - Funcionário informa o valor.
5 - Cliente efetua o pagamento.
6 - Funcionário repassa o pedido ao cozinheiro.
7 - Cozinheiro informa finalização da pizza;

Extensões - Cliente/Funcionário erra o pedido:

- Funcionário apaga pedido;
- Cliente escolhe pizza;
- Funcionário anota pedido;
(informo o fluxo novamente?)

- Estoque em falta (comida):

- Funcionário informa ao cliente pizza em falta;

Material produzido por Hévlla Oliveira Souza

 - Funcionário informa ao estoque;
- Cliente escolhe pizza;
- Funcionário anota pedido;

- Estoque em falta (embalagem):

- Funcionário informa ao estoque;
- Dono compra e adiciona ao estoque;

- Cozinheiro erra pedido:

- Cliente informa ao Funcionário;
- Funcionário aciona o Dono;
(o que fazer)

Requisitos especiais Interface de Usuário

Lista de Variantes ?

Frequência da ocorrência Contínuo

Problemas em aberto ?

a) Stakeholders:
i) Os donos;
ii) Os funcionários (atendente, cozinheiro e o ajudante)
iii) Cliente
b) Objetivos do stakeholders:

Material produzido por Hévlla Oliveira Souza

 i) Os donos:
1) Maximizar sua produção;
2) Melhorar o serviço e a entrega das pizzas;
3) Gestão de recursos;
ii) Os funcionários:
1) Anotar o pedido;
2) Montar a pizza de acordo o pedido;
3) Preparar para entrega;
4) Otimizar o fluxo de trabalho;
iii) Cliente:
1) Fazer pedido;
2) Efetuar o pagamento;
3) Receber a pizza;

Caso de uso: Realizar saque.

A operação de um caixa eletrônico tem início a partir de uma sessão em que o cliente seleciona
a opção de realizar saque. O cliente então escolhe uma quantia a ser retirada, a partir de um
conjunto de opções de quantia disponíveis. O sistema verifica se o caixa eletrônico tem saldo e
notas adequadas para compor o valor solicitado (Ex. R$ 50,00 não podem ser fornecidos se só
houver três notas de R$ 20,00). Caso tenha notas adequadas, os números da conta e da
agência do cliente são enviados ao banco para determinar se existe saldo suficiente na conta
do Cliente. Se não houver saldo, uma mensagem adequada é reportada. Havendo saldo, o
sistema inicia uma transação com o ator banco e solicita a retirada da quantia desejada e o
banco aprova ou desaprova a transação. Se a transação é aprovada, a máquina libera a
quantia correspondente e emite um recibo. Se a transação é desaprovada, uma mensagem
adequada é reportada. O banco é notificado, independentemente de uma transação aprovada
ter sido completada ou não pela máquina. Se a transação é completada, o banco realiza o
débito na conta do cliente .

Seção do Caso de Uso Descrição

Nome do caso de uso Realizar saque

Escopo Sistema de caixa automático

Nível Objetivo do usuário

Ator principal Cliente

Interessados e Interesse Cliente:​ deseja realizar o saque rapidamente, informa valor,

conta, agência e senha. Recebe comprovante do saque.

Caixa:​ recebe o valor do saque, verifica se têm notas

disponíveis, confere se o cliente tem saldo na conta, informa
transação ao banco, libera a quantia, emite um recibo.

Banco:​ recebe um pedido de transação do caixa, realiza o

Material produzido por Hévlla Oliveira Souza
 débito da conta do cliente.

Pré-condições Cliente ter conta no banco

Garantia de sucesso Transação completada, recibo impresso.

Fluxo Básico 1 - Cliente escolhe a opção “​realizar saque​”.

2 - Cliente informa o valor a retirar.
3 - Caixa recebe o valor;
4 - Caixa consulta se tem saldo e notas adequadas para o valor.
5 - Cliente informa conta e agência.
6 - Caixa consulta o Banco para ver se tem saldo suficiente na
conta do cliente.
7 - Banco informa se o cliente tem saldo.
8 - Caixa realiza transação com o Banco para retirar as notas
9 - Caixa libera a quantia e emite recibo.
10 - Caixa notifica o banco da transação.
11 - Banco realiza débito na conta do cliente.

Extensões O cliente não digita a quantia desejada:

- Caixa se encerra
- Caixa reinicia o sistema

O caixa automático não tem disponibilidade de dinheiro para

atender a solicitação do ator cliente
- Caixa reporta uma mensagem “Falta de recurso”
- Caixa reinicia o sistema

O caixa automático não tem disponibilidade notas:

- Caixa reporta uma mensagem “não temos notas para
compor este valor, tente outro”

O Cliente não tem saldo suficiente:

- Caixa informa ao Cliente “Saldo insuficiente”
- Caixa reinicia o sistema

O banco não aprova a transação:

- Caixa informa ao Cliente
- Caixa reinicia o sistema

Requisitos especiais Interface gráfica;

Dinheiro?

Lista de Variantes Leitura do cartão

Frequência da ocorrência Contínua

Problemas em aberto

http://www.ebrito.com.br/profa-elaine/uc.pdf

Material produzido por Hévlla Oliveira Souza