Modelagem e Design de Software

Unidade IIII
Traduzindo o modelo de requisitos em modelo de design
• As Especificações de Controle (CSPEC) são usadas para indicar (1) como o software
comporta-se quando um evento ou sinal de controle é percebido e (2) quais processos são
invocado como consequência da ocorrência do evento.

• A especificação do processo descreve a entrada para uma função, o algoritmo, o

PSPECindica restriçõestoneladas e limitações impostas ao processo (função)
características de desempenho que são relevantes para o processo e design
restrições que podem influenciar a maneira como o processo será implementado.

• Um dicionário de dados é um repositório estruturado de dados sobre dados.

Weeklytmesheet=Emplyee_Name + Employee_ID + {Regular_hours +
overtme_hours}
Pay_rate = {Horly | Daily | Weekly} + Dollar_amount
Employee_Name = Last + First + Middle_Init
Cada um dos elementos do modelo de análise fornece informações que
é necessário criar os quatro modelos necessários para um completo
especificação de design.

1. Thedata/class designtransformsanalysis classes into design classes

junto com os dados estruturais necessários para uma especificação completa do design.

2. O projeto arquitetônico define a relação entre os principais

elementos estruturais do software; estilos arquitetônicos e design
padrões ajudam a alcançar os requisitos definidos para o Sistema.

3. O design da interface descreve como o software se comunica

com sistemas que interoperam com ele e com humanos que o utilizam.

4. O design em nível de componente transforma elementos estruturais do

arquitetura de software em descrição procedural de software
componentes.
 Modelagem de Dados
• Modelagem de dados é o processo de criação
um modelo de dados para que os dados sejam armazenados em
umBancoDeDados.

• Este modelo de dados é conceitual

representação de objetos de dados.
 Cardinalidade

• A cardinalidade é a especificação do número de ocorrências de um

objeto que pode estar relacionado ao número de ocorrências de outro
objeto.

• A cardinalidade é geralmente expressa como simplesmente 'um' ou 'muitos'.

• Um objeto pode se relacionar com apenas outro objeto (um 1:1

relacionamento);

• Um objeto pode se relacionar com muitos outros objetos (um relacionamento 1: N);

• Algum número de ocorrências de um objeto pode se relacionar com outro.

número de ocorrências de outro objeto (uma relação M:N);
 Relacionamentos
• Objetos de dados estão conectados uns aos outros de várias maneiras
de maneiras diferentes. Esta ligação ou conexão de dados
objetos ou entidades entre si é chamado de
relacionamento.
• Uma conexão é estabelecida entre
pessoa e carro, porque os dois objetos estão relacionados.

Uma pessoa possui um carro

Uma pessoa compra um carro
 Objetos de dados
Um objeto de dados é uma representação de quase qualquer composto
informação que deve ser compreendida pelo software.

Por informação composta, algo que possui um número de

propriedades ou atributos diferentes.

Exemplo:
Largura‖ (um único valor) não seria um objeto de dados válido, mas
as dimensões (incorporando altura, largura e profundidade) poderiam ser
definido como um objeto.
 Atributos

Atributos definem as propriedades de um objeto de dados e assumem um dos

três características diferentes.
(Os dados armazenados no banco de dados em um determinado momento são
instância chamada do banco de dados.)

Eles podem ser usados para:

1. Nomeie uma instância dos objetos de dados,
2. Descreva a instância,
3. Faça referência a outra instância em outra tabela.

Os atributos devem ser definidos como "identificador".

Referindo-se ao objeto de dados carro, um razoável
o identificador ou atributo pode ser o ID No, Cor.
 Modelagem de Análise

• O modelo de análise e a especificação de requisitos

fornecer um meio para avaliar a qualidade uma vez que o
o software é construído.
• Os resultados da análise de requisitos na especificação
das características operacionais do software.
O modelo de análise como uma ponte entre o sistema
descrição e o modelo de design.

O modelo de análise de objetivos deve atingir três principais

objectves:
[Link] as necessidades do cliente

[Link] uma base para o design de software

[Link]fine a set of requirements that can be validated once
o software está construído.
elementos da modelagem de análise
• Scenario based ElementsThe system isdescribed
do ponto de vista do usuário usando essa abordagem.
Isto serve como entrada para a criação de outros
elementos de modelagem.
• Elementos baseados em classe Cada cenário de uso implica um
conjunto de objetos que são manipulados como um ator
interage com o sistema. Esses objetos são
categorias em classes – uma coleção de coisas que
têm atributos similares e comportamentos comuns. A
Modelo de Colaborador de Responsabilidade de Classe (CRC)
• Behavioral ElementsThe behavior of the system
pode ter um efeito profundo no design que é
escolhido. O diagrama de estados é um dos métodos
para representar o comportamento de um sistema.

• Elementos Orientados para Fluxo A informação é

transformado à medida que flui através do computador
sistema baseado. O sistema aceita entradas em um
variedade de formas, aplica funções para transformá-lo;
e produz saída em diferentes formas. O
transformações podem compreender uma única lógica
comparação, um algoritmo numérico complexo ou um
sistema especialista. Os elementos da informação
o fluxo está incluído aqui.
 Análise de Domínio

[Link]finaton
• A Análise de Domínio é o processo que identifica o
objetos relevantes de um domínio de aplicação.
• O objetivo da Análise de Domínio é a Reutilização de Software.
• Quanto maior for o nível do objeto do ciclo de vida para
reutilizar, maiores são os benefícios provenientes de sua
reutilização, e mais difícil é a definição de um funcionamento
processo.
 2. Conceito e domínio de aplicação técnica do software

(a) Frameworks são excelentes candidatos para Análise de Domínio: eles estão em um
nível mais alto do que o código, mas programadores medianos podem entendê-los.

(b) Atividade guarda-chuva envolvendo a identificação, análise e especificação

de requisitos comuns de um domínio de aplicação específico, tipicamente para
reutilizar em múltiplos projetos

(c) A análise de domínio orientada a objetos envolve a identificação, análise,

especificação de capacidades reutilizáveis dentro de uma aplicação específica
domínio em termos de objetos comuns, classes, submontagens, e
frameworks
3. Estrutura de Entrada e Saída da análise de domínio

(a) A figura mostra o fluxo dos dados de entrada e saída

no módulo de análise de domínio.
(b) O objetivo principal é criar as classes de análise e
funções comuns.
(c) A entrada consiste no domínio do conhecimento.
(d) A entrada é baseada na pesquisa técnica, cliente
pesquisa e aconselhamento de especialistas.

(e) O domínio de saída consiste em usar a entrada como o

referência e desenvolvimento dos modelos funcionais
 Modelagem de Design
O design de software é um processo iterativo através do qual os requisitos são traduzidos em um
―plano‖ para a construção do software.

O design é uma representação em alto nível de abstração - dados, funcionais e

requisitos comportamentais. À medida que as iterações de design ocorrem, o refinamento subsequente leva a
representações de design em níveis de abstração muito mais baixos.

Há três características que servem como guia para a avaliação de um bom design:
1. O design deve implementar todos os requisitos explícitos contidos nos requisitos.
modelo, e deve acomodar todos os requisitos implícitos desejados pelas partes interessadas.
2. O design deve ser um guia legível e compreensível para aqueles que geram código e
para aqueles que testam e posteriormente suportam o software.
3.O design deve fornecer uma visão completa do software, abordando os dados,
domínios funcionais e comportamentais para implementação.
 Modularity :

A arquitetura de software e os padrões de design incorporam modularidade;

isto é, o software é dividido em partes separadamente nomeadas e endereçáveis
componentes, às vezes chamados de módulos, que são integrados a
satisfazer os requisitos do problema.

É a compartimentalização de dados e funções. É mais fácil para...

resolver um problema complexo quando você o divide em partes gerenciáveis
peças. ―Dividir e conquistar‖. Não sobre-modularize.

A simplicidade de cada pequeno módulo será ofuscada pelo

complexidade da integração ―Custo‖.
 Encobrimento de Informações

• Esconder implica que uma modularidade eficaz pode ser alcançada por
definindo um conjunto de módulos independentes que se comunicam
with one another only that informaton necessary to achieve
função de software.
• The use of Informaton Hiding as a design criterion for
sistemas modulares oferecem os maiores benefícios quando
modificações são necessárias durante o teste e depois, durante
soſtware maintenance.
• Porque a maioria dos dados e procedimentos estão escondidos de outros
partes do software, erros inadvertidos introduzidos durante
as modificações são menos propensas a se propagar para outros locais
dentro do software.
 Resumo

• No mais alto nível de abstração, uma solução é apresentada em termos amplos usando o
idioma do ambiente do problema. Em níveis mais baixos de abstração, um mais
uma descrição detalhada da solução é fornecida. À medida que avançamos através de diferentes
níveis de abstração, trabalhamos para criar abstrações de procedimentos e dados.

• Uma abstração procedural refere-se a uma sequência de instruções que têm uma
função específica e limitada. Um exemplo de uma abstração procedural seria
a palavra aberta para uma porta. Uma abstração de dados é uma coleção nomeada de dados que
descreve um objeto de dados.

• No contexto da abstração procedural aberta, podemos definir um dado

abstração chamada porta. Como qualquer objeto de dados, a abstração de dados para porta
abrangeria um conjunto de atributos que descrevem a porta (por exemplo, tipo de porta,
direção do balanço, peso).
 Diagrama de Fluxo de Dados (DFD)

1) Diagrama de Fluxo de Dados (DFD) também é chamado de 'Gráfico de Bolhas'.

é uma técnica gráfica que representa o fluxo de informação, e
transformadores são aplicados quando os dados se movem da entrada para
saída.

2) DFD representa os requisitos do sistema que se tornam

programa em design.

3) O DFD pode ser ainda segmentado em diferentes níveis para mostrar

fluxo de informação detalhado, por exemplo, nível 0, nível 1, nível 2 etc.
4) O DFD foca no fato de que o fluxo de dados' em vez de como
os dados são processados
5) O DFD é usado para representar o fluxo de informações, e o
transformadores que são aplicados quando os dados se movem de
entrada para saída.
6) Para mostrar o fluxo de dados com mais detalhes, o DFD é
further extended to level 1, level 2, level 3, etc. conforme o
requisito.
7) O valor típico para o DFD é sete. Qualquer sistema pode
ser bem representado com detalhes até o sétimo nível.
 Nível 0
O primeiro nível do DFD é conhecido como nível de contexto ou Nível 0 que
fornece o funcionamento geral do Sistema.

O Nível 1 fornece uma representação modular do sistema

contendo módulos primários do sistema.

A partir do Nível 2, um designer começa a revisitar cada e

cada módulo para uma análise aprofundada do sistema que
contém funções menores a serem realizadas por todos
módulo.
The Safe Home product, a level 0 DFD
sistema de gestão de biblioteca DFD nível 0.
sistema de gestão de biblioteca DFD nível 1
diagrama de fluxo de dados nível 0 e 1 para uma editora de livros
diagrama de fluxo de dados nível 0 e nível 1 para "Exame Online. Win17 do preenchimento de formulário no site MSBTE".
DFD level 0 and level 1 for Hotel management system.
 Testng
• Testng está executando um sistema para identificar quaisquer lacunas,
erros ou requisitos ausentes em contrariedade ao real
requisitos.

• Na maioria dos casos, os seguintes profissionais estão envolvidos na testagem

um sistema dentro de suas respectivas capacidades −

Testador de Software
Desenvolvedor de Software

Líder/Gerente de Projeto
Usuário Final
O que é Testng de Software?
O teste de software é definido como uma atividade para verificar se
os resultados reais coincidem com os resultados esperados e para garantir
que o sistema de software éDefeitográtis.

Tipos de Teste de Software

Normalmente, o Testng é classificado em três categorias.
• Teste Funcional
• Teste Não Funcional ouTeste de Desempenhotng
• Manutenção (Regressão e Manutenção)
 Princípios do Testng
Todos os testes devem ser rastreáveis aos requisitos do cliente.
O objetivo dos testes de software é descobrir erros. Consequentemente, o mais
defeitos graves (do ponto de vista do cliente) são aqueles que causam o
programa para não atender aos seus requisitos.

2. Os testes devem ser planejados muito antes do início do teste.

O planejamento de testes pode começar assim que o modelo de requisitos estiver completo.
A definição detalhada dos casos de teste pode começar assim que o modelo de design tiver sido
solidificado. Portanto, todos os testes podem ser planejados e projetados antes que qualquer código tenha sido
foi gerado.

3. O princípio de Pareto se aplica a testes de software.

Simplificando, o princípio de Pareto implica que 80 por cento de todos os erros
descoberto durante os testes provavelmente será rastreável a 20 por cento de todo o programa
componentes. O problema, claro, é isolar esses suspeitos
componentes e testá-los completamente.
[Link] deve começar "pequeno" e progredir para "grande".
Os primeiros testes planejados e executados geralmente se concentram em componentes individuais. Como
Conforme os testes avançam, o foco se desloca em uma tentativa de encontrar erros em clusters integrados de
componentes e, em última análise, no sistema inteiro.

5. Testes exaustivos não são possíveis.

O número de permutações de caminhos para um programa de tamanho moderado é
excepcionalmente grande. Por essa razão, é impossível executar cada combinação de
caminhos durante o testng. É possível, no entanto, cobrir adequadamente a lógica do programa e
garantir que todas as condições no design a nível de componente tenham sido exercitadas.

6. Para ser mais eficaz, os testes devem ser realizados por uma terceira parte independente.
Por mais efetivo, queremos dizer testes que tenham a maior probabilidade de encontrar erros.
(o objetivo principal do testng). O engenheiro de software que criou o sistema é
não é a melhor pessoa para conduzir todos os testes do software.
 Teste de Caixa Branca

Às vezes chamado de teste de caixa de vidro, é um design de caso de teste.

filosofia que usa a estrutura de controle descrita como
parte do design em nível de componente para derivar casos de teste.

Necessário: -Avaliar e validar o código e interno

estrutura do programa/código.

Características: -O código é visível para o testador de software, então

eles podem verificar a correção do código.
 Teste de Caixa Preta
Também chamado de teste comportamental, foca na funcionalidade
requisitos do software.
Ou seja, técnicas de teste de caixa-preta permitem que você derive conjuntos de
condições de entrada que exercerão totalmente todas as funcionalidades
requisitos para um programa.

Necessidade: Avaliar a correção do comportamento do Software.

Características: -Validar comportamento funcional e desejado

resultado/fluxo do sistema.
 Testng de Software - Níveis
Os níveis de testng incluem diferentes metodologias que podem ser usadas.
Durante a realização de testes de software. Os principais níveis de software
testng são −
• Teste Funcional
• Teste não funcional

• Teste de unidade
• Teste de Integração
• Teste de Validação Testng
• Teste de Sistema
Teste de unidade
Os testes unitários começam no centro e cada unidade é implementada no código-fonte.

Teste de integração
Um teste de integração foca na construção e design do software.

Teste de validação
Verifique todos os requisitos, como funcionais, comportamentais e de desempenho.
os requisitos são validados contra o software de construção.

Teste de sistema
O teste de sistema confirma que todos os elementos e o desempenho do sistema foram testados.
totalmente.
 TESTES UNITÁRIOS
• É um nível de teste de software onde unidades/componentes individuais de
um software é testado.
• Uma unidade é a menor parte testável de qualquer software.
• É realizado usando oTeste de Caixa Brancatngmétodo.

Vantagens:
• Reduz Defeitos nas funcionalidades recém-desenvolvidas ou reduz bugs
ao mudar a funcionalidade existente.
• Reduz os custos do Testng, pois os defeitos são capturados em uma fase muito inicial.
• Melhora o design e permite uma melhor refatoração do código.
• Testes de Unidade, quando integrados com a compilação, fornecem a qualidade da compilação.
também.
 Documentação de Teste
• Um modelo de caso de teste é um documento que se enquadra em um
doteste artfatos, que permite aos testadores desenvolver
os casos de teste para um cenário de teste específico na ordem
para verificar se as funcionalidades de uma aplicação são
funcionando conforme o previsto ou não.

• Os casos de teste são o conjunto de positivos e negativos

etapas executáveis de um cenário de teste que possui um conjunto de
pre-conditons, test data, expected result, post-
condições e resultados reais.
 Pré-condição:
Teste Teste Caso de Teste Etapas de Teste Caso de teste Defeito de Teste
Case ID Case Descripton status Priority severidade
Name Etapa Esperada Atual aprovado/reprovado
 Plano de Teste

• ATEST PLAN é um documento que descreve o escopo de teste de software

e atividades. É a base para testar formalmente qualquer
software/produto em um projeto.

• Estrutura
1. Processo Testng
2. Rastreabilidade de Requisitos
3. Itens Testados
4. Cronograma do Testng
5. Procedimento de Gravação de Teste
6. Requisitos de hardware e software
7. Restrições
 Defect Report
• O RELATÓRIO DE DEFECTOS é um documento que identifica
e descreve um defeito detectado por um testador.
O objetivo de um relatório de defeito é declarar o
o problema o mais claramente possível para que
os desenvolvedores podem replicar o defeito facilmente e
conserte isso.
 Defect Report Template

• Na maioria das empresas, uma ferramenta de reporte de defeitos é

usado e os elementos de um relatório podem variar.
No entanto, em geral, um relatório de defeito pode
consiste nos seguintes elementos.
ID Identificador único dado ao defeito. (Normalmente, automatizado)

Projeto Nome do projeto.

Produto Nome do produto.

Versão de Lançamento Versão de lançamento do produto. (por exemplo, 1.2.3)

Módulo Módulo específico do produto onde o defeito foi detectado.

Compilação Detectada Versão do produto onde o defeito foi detectado

Versão (ex. [Link])

Summary Summary of the defect. Keep this clear and concise.

Descrição Detailed descripton of the defect. Describe as much as possible but
sem repetir nada ou usar palavras complexas. Mantenha simples
mas abrangente.

Passos para Replicar Descrição passo a passo da maneira de reproduzir o defeito.

Numere os passos.

Resultado Atual O resultado real que você recebeu ao seguir os passos.

Resultados Esperados Os resultados esperados.

Anexos Anexe qualquer informação adicional, como capturas de tela e logs.

Observações Algum comentário adicional sobre o defeito.

Defect Severity Severidade do Defeito.

Defect Priority Prioridade do Defeito.

Relatado Por O nome da pessoa que relatou o defeito.

Assigned To The name of the person that is assigned to analyze/fix the defect.

Status O status do defeito.

Versão de Build Fixada Build version of the product where the defect was fixed (e.g. [Link])
 Relatório Resumo de Teste
Identificador do Relatório de Resumo do Teste

Algum tipo de número único gerado pela empresa para

identifique este relatório resumido, seu nível e o nível de
software ao qual está relacionado. Preferencialmente o nível do relatório
será o mesmo que o nível de software relacionado. O
o número também pode identificar se o relatório resumido
é para o projeto inteiro ou um nível específico de teste.
Isso é para ajudar na coordenação de software e teste.
versões dentro da gestão de configuração.