Live Revisão- Engenharia de Software

Prévia do material em texto

Disciplina:
Engenharia de Software
Live final de revisão
 
Facilitadora: Sheila Katherine Venero Ferro
Modelos de processo de software
❏Receitas e/ou descrições de como o desenvolvimento de software deveria ser
❏Modelos mais comuns:
❏ Cascata
❏ Incremental
❏ Orientado a reuso
Requisitos Produto
Atividades fundamentais da ES
❏ Especificação de software: a funcionalidade do software e as restrições a 
seu funcionamento devem ser definidas;
❏ Projeto e implementação de software: produzir para atender às especificações;
❏ Validação de software: o software deve ser validado para garantir que atenda às demandas 
do cliente; e
❏ Evolução do software: o software deve evoluir para atender às necessidades de mudança 
dos clientes.
Métodos Ágeis Pretende-se valorizar mais indivíduos e interações do que processos e ferramentas, 
software em funcionamento do que 
documentação abrangente, colaboração do 
cliente do que negociação de contrato, 
respostas a mudanças do que seguir um plano.
● XP
● Scrum
Engenharia de 
requisitos
Requisitos 
❏Un requisito é uma característica do sistema ou descrição de algo que o 
sistema é capaz de realizar, para atingir seus objetivos. 
❏Descrições das restrições sobre o funcionamento do que o sistema.
❏Refletem as necessidades dos clientes que servem a uma finalidade 
determinada.
Níveis de requisitos
❏ Requisito de usuário:
❏ Linguagem natural (podendo ser apoiado por diagramas)
❏ Quais serviços o sistema deverá fornecer a seus usuários
❏ Quais restrições com as quais o sistema deverá operar
❏ Requisitos de sistema:
❏ Costuma ser chamado de “especificação de requisitos”
❏ Deve definir exatamente o que deve ser implementado
❏ Pode ser parte do contrato entre comprador/desenvolvedores
Tipos de requisitos
❏ Requisitos funcionais
❏ Declarações de serviços que o sistema deve fornecer e como reagir a 
entradas específicas
❏ Declarações de como o sistema deve se comportar em determinadas 
situações.
❏ Declarações do que o sistema não deve fazer.
❏ Requisitos não funcionais
❏ Restrições aos serviços ou funções oferecidos pelo sistema.
❏ Incluem restrições de tempo, restrições no processo de desenvolvimento 
e restrições impostas por normas.
❏ Geralmente, aplicam-se ao sistema como um todo.
Sommerville 
(2011)
Processo de Engenharia de Requisitos
Sommerville 
(2011)
Descoberta requisitos
❏ Fontes de informação: documentação, clientes/usuários do sistema e 
especificações de sistemas similares.
❏ Ferramentas/técnicas: observação / etnografia (imersão), entrevistas, 
cenários, protótipos.
Modelagem de 
Software
Modelagem de sistemas é o processo de 
desenvolvimento de modelos abstratos de um 
sistema, representando diferentes visões ou 
perspectivas do sistema. A UML (linguagem 
unificada de modelagem) é a notação gráfica 
preferida atualmente. 
Diagramas
❏ Diagrama de classes: representa as estruturas estáticas de um sistema e/ou contexto.
❏ Diagrama de casos de uso: mostra as funcionalidades do sistema que estarão disponíveis para os 
diversos atores (tipos de usuários)
❏ Diagrama de atividades: mostra as atividades envolvidas em um processo, para representar a 
lógica interna de uma classe ou método, definindo os algoritmos que serão utilizados em uma 
implementação;
❏ Diagramas de sequência: mostram as interações (trocas de mensagens) entre os atores e os 
componentes do sistema (objetos das classes);
❏ Diagrama de estados: utilizada para descrever como o sistema reage a ocorrência de eventos 
externos. 
Projeto de 
Arquitetura
 O projeto de arquitetura define como o sistema está 
organizado e qual é a sua estrutura geral. 
O estilo e a estrutura da arquitetura escolhida para um 
sistema devem depender dos requisitos não 
funcionais.
RNF a ser considerados na Arquitetura
● Desempenho: a arquitetura deve ser projetada para localizar as operações críticas.
● Proteção: deve-se usar uma estrutura em camadas para a arquitetura, com os ativos mais críticos 
protegidos nas camadas mais internas e com alto nível de validação de proteção aplicado a essas 
camadas.
● Segurança: a arquitetura deve ser concebida de modo que as operações relacionadas com a 
segurança estejam localizadas em um único componente ou em um pequeno número de 
componentes. Isso reduz os custos e os problemas de validação de segurança e torna possível 
fornecer sistemas de proteção relacionados que podem desligar o sistema de maneira segura em 
caso de falha.
RNF a ser considerados na Arquitetura
● Disponibilidade: a arquitetura deve ser projetada para incluir componentes redundantes, de modo 
que seja possível substituir e atualizar componentes sem parar o sistema.
● Manutenção: a arquitetura do sistema deve ser projetada a partir de componentes autocontidos de 
baixa granularidade que podem ser rapidamente alterados. Os produtores de dados devem ser 
separados dos consumidores e as estruturas de dados compartilhadas devem ser evitadas
Visões da arquitetura
●Modelo de visão 4+1 (Modelo de Kruchten)
● a visão lógica, que mostra as abstrações fundamentais do sistema como objetos ou classes de 
objetos (em que deveria ser possível relacionar os requisitos de sistema às entidades);
● a visão de processo, que mostra como, em tempo de execução, o sistema é composto por processos 
interativos (útil para fazer julgamentos sobre as características não funcionais do sistema);
● a visão de desenvolvimento, que mostra como o software é decomposto para o desenvolvimento, ou 
seja, apresenta a distribuição do software em componentes que são implementados por um único 
desenvolvedor ou por uma equipe de desenvolvimento (útil para gerentes de software e 
programadores); e
● a visão física, que mostra o hardware do sistema e como os componentes de software são 
distribuídos entre os processadores (útil para a implantação do sistema)
Sommerville 
(2011)
Padrão MVC
Sommerville 
(2011)
Sommerville 
(2011)
Arquitetura em Camadas
Sommerville 
(2011)
Sommerville 
(2011)
Padrão Repositorio
Sommerville 
(2011)
Sommerville 
(2011)
Padrão Cliente-Servidor
Sommerville 
(2011)
Arquitetura SOA As arquiteturas orientadas a serviços são uma forma de desenvolvimento de sistemas distribuídos em que 
os componentes de sistema são serviços autônomos, 
executando em computadores geograficamente 
distribuídos. Protocolos padrões baseados em XML, 
SOAP e WSDL foram projetados para oferecer suporte 
à comunicação de serviços e à troca de informações. 
Assim, os serviços são plataforma e implementação 
independentes de linguagem.
Padrões SOA para Web
❏ SOAP: padrão de troca de mensagens que oferece suporte à comunicação entre serviços. Define os 
componentes essenciais e opcionais das mensagens passadas entre os serviços.
❏ WSDL: linguagem de definição de web services (web service definition language) é um padrão para a 
definição de serviço. Estabelece como as operações de serviço (nomes de operação, parâmetros e seus 
tipos) e associações de serviço devem ser definidas.
❏ WS-BPEL: padrão para linguagem de workflow, usada para definir programas de processos que envolvem 
vários serviços diferentes.
❏ UDDI: padrão de descoberta de serviços que não foi amplamente adotado (universal description, discovery 
and integration), define os componentes de uma especificação de serviço e pode ser utilizado para 
descobrir a existência do serviço. Acabou sendo substituído por mecanismos de busca padrão.
Teste de Software O processo de teste tem dois objetivos 
distintos:
❏ Demonstrar ao desenvolvedor e ao cliente que o 
software atende a seus requisitos; e
❏ Descobrir situações em que o software se comporte 
de maneira incorreta, indesejável ou de forma 
diferente da especificação.
Nomenclatura usual
Erro
Defeito
Falha
Engano
BugDefect
Error
Failure
 
Mistake
Fault
❏ Teste de desenvolvimento, em que o sistema é testado durante o desenvolvimento para descobrir bugs e 
defeitos. Projetistas e programadorespodem estar envolvidos no processo de teste.
❏ Teste de release, em que uma equipe de teste independente testa uma versão completa do sistema antes 
que ele seja liberado para o usuário. O objetivo dos testes de release é verificar se o sistema atende aos 
requisitos dos stakeholders.
❏ Testes de usuário, em que os usuários ou potenciais usuários de um sistema testam o sistema em seu 
próprio ambiente
Fases de Teste
Sommerville 
(2011)
Etapas de teste
Níveis de Granularidade
❏ teste unitário, em que as unidades individuais do programa são testadas individualmente;
❏ teste de componentes, em que várias unidades individuais são integradas para criar componentes 
compostos (testes de componentes devem centrar-se em testar as interfaces dos componentes); e
❏ teste de sistema, em que alguns ou todos os componentes de um sistema estão integrados e o sistema é 
testado como um todo.
Níveis de teste X Fases de desenvolvimento
Modelo em V
(Imagem de 
Herman 
Bruyninckx)
REÚSO E 
ENGENHARIA DE 
SOFTWARE 
BASEADA EM 
COMPONENTES
o reúso de software serve para diminuir custo, 
aumentar qualidade e fazer entregas mais rápidas
Níveis de Reuso
❏ Nível de abstração: não se reusa o software diretamente, mas sim o conhecimento das abstrações de 
sucesso no projeto de software. Os padrões de projeto e de arquitetura são formas de representar o 
conhecimento abstrato para reúso.
❏ Nível de objeto: reusam-se objetos diretamente de uma biblioteca, ao invés de se escrever o código.
❏ Nível de componente: são coleções de objetos e classes de objetos que funcionam em conjunto para 
fornecer funções e serviços relacionados.
❏ Nível de sistema: em que se reusa um sistema de aplicação inteiro com algum tipo de configuração desses 
sistemas.
Bibliografia base
●I. Sommerville, Engenharia de software, 9a ed., 
Pearson, 2011.
●S. L. Pfleeger, Engenharia de software: teoria e 
prática, 2a ed., Pearson, 2004.
●E. Medeiros, Desenvolvendo software com UML 
2.0: definitivo, Pearson, 2004.
Obrigada 
Estes slides são uma adaptação dos slides fornecidos pela UNIVESP 
da disciplina de Engenharia de Software 
Dúvidas? 
sheila.ferro@cursos.univesp.br