UNIDADE III

DESENHO DE SOFTWARE

Visão Geral do Processo de Design: Resultado do Processo de Design – Classificação do Design

Atividades
Design:-Visão Geral da Metodologia SA/SD–Análise Estruturada–Desenvolvendo o Modelo DFD
de um Sistema: Diagrama de Contexto – Design Estruturado – Design Detalhado.

DESIGN DE SOFTWARE:

As atividades realizadas durante a fase de design (chamada de processo de design) transformam o SRS
documento no documento de design.

VISÃO GERAL DO PROCESSO DE DESIGN

O processo de design transforma essencialmente o documento SRS em um documento de design.
1. RESULTADO DO PROCESSO DE DESIGN

Os seguintes itens são projetados e documentados durante a fase de design.

Módulos diferentes necessários: Os diferentes módulos na solução devem ser claramente identificados.
Cada módulo é uma coleção de funções e dos dados compartilhados pelas funções do módulo.
Cada módulo deve realizar uma tarefa bem definida dentro da responsabilidade geral do
software. Cada módulo deve ser nomeado de acordo com a tarefa que realiza. Por exemplo, em um
software de automação acadêmica, o módulo consistindo nas funções e dados necessários para
realizar a tarefa de registro dos alunos deve ser nomeado gerenciar registro de alunos.
Controlar relacionamentos entre módulos: Um relacionamento de controle entre dois módulos essencialmente

surge devido a chamadas de função entre os dois módulos. As relações de controle existentes entre
vários módulos devem ser identificados no documento de design.

Engenharia de Software Page 1 Preparado por [Link], Prof. Assoc. GASC, Ngl.
Interfaces entre diferentes módulos: As interfaces entre dois módulos identificam o exato
itens de dados que são trocados entre os dois módulos quando um módulo invoca uma função do
o outro módulo.
Estruturas de dados dos módulos individuais: Cada módulo normalmente armazena alguns dados que o
as funções do módulo precisam compartilhar para cumprir a responsabilidade geral do módulo.
Estruturas de dados adequadas para armazenar e gerenciar os dados de um módulo precisam ser corretamente

projetado e documentado.
Algoritmos necessários para implementar os módulos individuais: Cada função em um módulo geralmente
realiza algumas atividades de processamento. Os algoritmos necessários para realizar o processamento
as atividades de vários módulos precisam ser cuidadosamente projetadas e documentadas devida
considerações dadas à precisão dos resultados, complexidades de espaço e tempo. Começando com o
O documento SRS (conforme mostrado na Figura 5.1), os documentos de design são produzidos por meio de iterações.

em uma série de etapas. Os documentos de design são revisados pelos membros da equipe de desenvolvimento
equipe para garantir que a solução de design esteja em conformidade com a especificação dos requisitos.

2. CLASSIFICAÇÃO DAS ATIVIDADES DE DESIGN

Um bom design de software raramente é realizado por meio de um procedimento de um único passo; em vez disso, requer

iterando sobre uma série de etapas chamadas de atividades de design. Dependendo da ordem em
quais várias atividades de design são realizadas, podemos classificá-las amplamente em duas
estágios importantes.

• Design preliminar (ou de alto nível), e

• Projeto detalhado.
O significado e o escopo dessas duas etapas podem variar consideravelmente de uma metodologia de design para outra.

para outro. No entanto, para a abordagem de design tradicional orientada a funções, é possível definir
os objetivos do design de alto nível são os seguintes:
Através do design de alto nível, um problema é decomposto em um conjunto de módulos. O controle
as relações entre os módulos são identificadas, e também as interfaces entre vários
módulos são identificados.
O resultado do design de alto nível é chamado de estrutura do programa ou do software
arquitetura. O design em alto nível é uma etapa crucial no design geral de um software.

engenharia de software Page 2 Preparado por [Link], Prof. Assistente, GASC, Ngl.
 Quando o projeto de alto nível estiver completo, o problema deve ter sido decomposto em
muitos pequenos módulos funcionalmente independentes que são coesos, têm baixo acoplamento entre si

eles mesmos, e estão organizados em uma hierarquia.

Muitos tipos diferentes de notações foram usados para representar um design de alto nível. Uma notação
que está sendo amplamente utilizado para desenvolvimento procedural é um diagrama em forma de árvore chamado de

gráfico de estrutura. Outra técnica de representação de design popular chamada UML que está sendo
usado para documentar design orientado a objetos, envolve o desenvolvimento de vários tipos de diagramas para

documente o design orientado a objetos de um sistema.

Uma vez que o design de alto nível está completo, o design detalhado é realizado.
Durante o design detalhado, cada módulo é examinado cuidadosamente para projetar suas estruturas de dados e

osalgoritmos.
O resultado da fase de design detalhado é geralmente documentado na forma de um módulo
documento de especificação (MSPEC).
Depois que o design de alto nível estiver completo, o problema terá sido decomposto em partes pequenas
módulos, e as estruturas de dados e algoritmos a serem usados descritos usando MSPEC e podem
ser facilmente compreendido por programadores para iniciar a codificação.

3. COMO CARACTERIZAR UM BOM DESIGN DE SOFTWARE?

Chegar a uma caracterização precisa de um bom design de software que se sustente
através de diversos domínios problemáticos não é certamente fácil.

De fato, a definição de um design de software "bom" pode variar dependendo do exato

aplicativo está sendo projetado.

Por exemplo, ―o tamanho da memória utilizado por um programa ‖ pode ser uma questão importante para

Caracterize uma boa solução para o desenvolvimento de software embarcado - uma vez que embarcado

as aplicações muitas vezes são obrigadas a trabalhar com tamanhos de memória severamente limitados devido ao custo,

espaço ou considerações de consumo de energia.

Para aplicações embarcadas, fatores como a compreensibilidade do design podem ficar em segundo plano.
ao julgar a qualidade do design. Assim, para aplicações embarcadas, pode-se sacrificar
compreensibilidade do design para alcançar a compactação do código.

A maioria dos pesquisadores e engenheiros de software concorda sobre algumas características desejáveis que todo

um bom design de software para aplicações gerais deve possuir.

Engenharia de Software Page 3 Preparado por [Link], Prof. Assistente, GASC, Ngl.
 Essas características estão listadas abaixo:
Corretude: Um bom design deve, antes de tudo, ser correto. Ou seja, ele deve implementar corretamente
todas as funcionalidades do sistema.
Compreensibilidade: Um bom design deve ser facilmente compreensível. A menos que uma solução de design seja

facilmente compreensível, seria difícil implementá-lo e mantê-lo.

Eficiência: Uma boa solução de design deve abordar adequadamente os recursos, o tempo e o custo
questões de otimização.
Manutenibilidade: Um bom design deve ser fácil de mudar.
Compreensibilidade de um Design: Uma Grande Preocupação

Enquanto realizamos o design de um certo problema, assumimos que chegamos a um grande

número de soluções de design e necessidade de escolher a melhor.
Obviamente, todos os designs incorretos devem ser descartados primeiro.

Dentre as soluções de design corretas, como podemos identificar a melhor?

Dado que estamos escolhendo apenas entre soluções de design corretas, a compreensibilidade de um design
a solução é possivelmente a questão mais importante a ser considerada ao avaliar a qualidade de
um design.
Um design compreensível é modular e em camadas
Para podermos comparar a compreensibilidade de duas soluções de design, devemos ter pelo menos
uma compreensão das características gerais que um design de fácil entendimento deve possuir.
Uma solução de design deve ter as seguintes características para ser facilmente compreensível:
Deve atribuir nomes consistentes e significativos a vários componentes de design.
Deve fazer uso dos princípios de decomposição e abstração de forma adequada.
medidas para simplificar o design.
Uma solução de design deve ser modular e em camadas para ser compreensível.

Modularidade
Um design modular é uma decomposição eficaz de um problema. É uma característica básica de
qualquer boa solução de design.

Um design modular, em palavras simples, implica que o problema foi decomposto em um conjunto.
de módulos que têm apenas interações limitadas entre si.

Engenharia de Software Page 4 Preparado por [Link], Prof. Assistente. GASC, Ngl.
 A decomposição de um problema em módulos facilita a exploração da divisão e
princípio da conquista.

Se diferentes módulos não tiverem interações ou tiverem poucas interações entre si, então
cada módulo pode ser entendido separadamente.
Isso reduz muito a complexidade percebida da solução de design.
Para entender por que isso é assim, lembre-se de que pode ser muito difícil quebrar um monte de
gravetos que foram amarrados juntos, mas muito fáceis de quebrar os gravetos individualmente.
Uma solução de design é considerada altamente modular, se os diferentes módulos na solução tiverem
alta coesão e seus acoplamentos entre módulos são baixos.
Um design de software com alta coesão e baixo acoplamento entre módulos é o efetivo
decomposição de problemas reduzindo a complexidade percebida do problema.

Com base nessa classificação, seríamos capazes de julgar facilmente a coesão e o acoplamento.
existente em uma solução de design.

A partir do conhecimento da coesão e do acoplamento em um design, a modularidade do design

a solução pode ser alcançada.
Design em camadas
Um design em camadas é aquele em que as relações de chamada entre diferentes módulos são
representado graficamente, resultaria em um diagrama em forma de árvore com camadas claras.
Em uma solução de design em camadas, os módulos são dispostos em uma hierarquia de camadas.
Um módulo só pode invocar funções dos módulos na camada imediatamente abaixo dele.
Os módulos de camada superior podem ser considerados semelhantes a gerentes que invocam (ordenam) o
módulos de camada inferior para realizar certas tarefas.

Engenharia de Software Page 5 Preparado por [Link], Prof. Assistente, GASC, Ngl.
 Um design em camadas pode ser considerado como a implementação de abstração de controle, uma vez que um módulo em
uma camada inferior não está ciente de (sobre como chamar) os módulos da camada superior.

4. DESIGN DE SOFTWARE ORIENTADO A FUNÇÕES:-

O termo decomposição de cima para baixo é frequentemente usado para denotar a decomposição sucessiva de um conjunto

de funções de alto nível em funções mais detalhadas.

VISÃO GERAL DA METODOLOGIA SA/SD
A metodologia SA/SD envolve a realização de duas atividades distintas:

Análise Estruturada (AE)

Design estruturado (DE)
Durante a análise estruturada, o documento SRS é transformado em um diagrama de fluxo de dados (DFD)
modelo.
Durante o design estruturado, o modelo DFD é transformado em um diagrama de estrutura.

A atividade de análise estruturada transforma o documento SRS em um modelo gráfico chamado

Modelo DFD. Durante a análise estruturada, a decomposição funcional do sistema é alcançada.
é importante entender que o propósito da análise estruturada é capturar os detalhes
estrutura do sistema percebida pelo usuário, enquanto o objetivo do design estruturado é
defina a estrutura da solução que seja adequada para implementação em alguma programação
idioma.

5. ANÁLISE ESTRUTURADA
A técnica de análise estruturada é baseada nos seguintes princípios subjacentes:
Abordagem de decomposição de cima para baixo.

Aplicação do princípio de dividir e conquistar. Através disso, cada função de alto nível é
decomposto de forma independente em funções detalhadas.
Representação gráfica dos resultados da análise usando diagramas de fluxo de dados (DFDs).

Engenharia de Software Page 6 Preparado por [Link], Prof. Assistente, GASC, Ngl.
Um DFD é um modelo gráfico hierárquico de um sistema que mostra os diferentes processos.
atividades ou funções que o sistema realiza e a troca de dados entre essas funções.
Símbolos primitivos usados para construir DFDs
Existem essencialmente cinco tipos diferentes de símbolos usados para construir DFDs. Esses primitivos
os símbolos estão retratados na Figura 6.2. O significado desses símbolos é explicado da seguinte forma:

Símbolo de função: Uma função é representada usando um círculo.

Símbolo de entidade externa: Uma entidade externa, como um bibliotecário, um membro da biblioteca, etc. é

representado por um retângulo.

Um símbolo de fluxo de dados representa o fluxo de dados que ocorre entre dois processos ou entre um

entidade externa e um processo na direção da seta do fluxo de dados.

Símbolo de armazenamento de dados: Um armazenamento de dados é representado por duas linhas paralelas. Ele representa uma lógica

arquivo. Ou seja, um símbolo de armazenamento de dados pode representar tanto uma estrutura de dados quanto um arquivo físico no disco

Símbolo de saída: O símbolo de saída é como mostrado na Figura 6.2. O símbolo de saída é usado quando
uma cópia impressa é produzida.

Um dicionário de dados lista a finalidade de todos os itens de dados e a definição de todos os dados compostos.

itens em termos de seus itens de dados componentes.

6. DESENVOLVENDO O MODELO DFD DE UM SISTEMA

Um modelo DFD de um sistema representa graficamente como cada dado de entrada é transformado em seu
dados de saída correspondentes através de uma hierarquia de DFDs.

O modelo DFD de um problema consiste em muitos DFDs e um único dicionário de dados.

Exemplo. Sistema de Automação de Casa de Negócios (TAS) Uma casa de negócios deseja desenvolver um

sistema computerized que automatizaria várias atividades de contabilidade associadas a isso

negócios.

Engenharia de Software Page 7 Preparado por [Link], Prof. Assistente, GASC, Ngl.
Engenharia de Software Page 8 Preparado por [Link], Prof. Assistente, GASC, Ngl.
Dicionário de dados para o modelo DFD do TAS
response: [bill + material-issue-slip, reject-msg,apology-msg]
período /* consulta do gerente sobre as estatísticas de vendas */
[data+data,mês,ano,dia]
ano + mês + dia
mês
id-do-cliente + {itens + quantidade}* + número-do-pedido

a) Diagrama de Contexto
O diagrama de contexto é a representação de fluxo de dados mais abstrata (nível mais alto) de um sistema. Ele

representa todo o sistema como uma única bolha. A bolha no diagrama de contexto é anotada
com o nome do sistema de software que está sendo desenvolvido (geralmente um substantivo).

O diagrama de contexto estabelece o contexto em que o sistema opera; ou seja, quem são os
usuários, quais dados eles inserem no sistema e quais dados eles recebem do sistema.

1. Construção do diagrama de contexto: Examine o documento SRS para determinar:

•Funções de alto nível diferentes que o sistema precisa realizar.
•Entrada de dados para cada função de alto nível.

•Saída de dados de todas as funções de alto nível.

•Interações (fluxo de dados) entre as funções de alto nível identificadas.
Engenharia de Software Page 9 Elaborado por [Link], Prof. Assistente, GASC, Ngl.
Construção do diagrama de nível 1: Examine as funções de alto nível descritas no SRS
documento. Se houver três a sete requisitos de alto nível no documento SRS, então
represente cada uma das funções de alto nível na forma de uma bolha. Se houver mais de sete
bolhas, então algumas delas precisam ser combinadas. Se houver menos de três bolhas, então algumas
desses têm que ser divididos.
Construção de diagramas de nível inferior: Decompõe cada função de alto nível em seus constituintes
subfunções através do seguinte conjunto de atividades:
Identifique as diferentes subfunções da função de alto nível.
•...Identifique a entrada de dados para cada uma dessas subfunções.
•...Identifique a saída de dados de cada uma dessas subfunções.
•...Identifique as interações (fluxo de dados) entre essas subfunções.

7. DESENHO ESTRUTURADO
O objetivo do design estruturado é transformar os resultados da análise estruturada (ou seja,
o modelo DFD) em um diagrama de estrutura.

Engenharia de Software Page 10 Preparado por [Link], Prof. Assistente. GASC, Ngl.
 Um gráfico de estrutura representa a arquitetura de software. Os vários módulos que compõem outros
módulos), e os parâmetros que são passados entre os diferentes módulos.
A representação do gráfico de estrutura pode ser facilmente implementada usando algum programa
idioma. Como o foco principal em uma representação de gráfico de estrutura é na estrutura do módulo
de um software e a interação entre os diferentes módulos, os aspectos procedimentais.
Os blocos de construção básicos com os quais os gráficos de estrutura são projetados são os seguintes:

Caixas retangulares: Uma caixa retangular representa um módulo. Normalmente, cada caixa retangular é
anotado com o nome do módulo que representa.
Setas de invocação de módulo: Uma seta conectando dois módulos implica que durante o programa
o controle de execução é passado de um módulo para o outro na direção da conexão
seta. No entanto, apenas ao olhar para o diagrama de estrutura, não podemos dizer se um módulo chama
outro módulo apenas uma vez ou muitas vezes. Além disso, apenas olhando para o gráfico de estrutura, não podemos

diga a ordem em que os diferentes módulos são invocados.

Setas de fluxo de dados: Estas são pequenas setas que aparecem ao lado das setas de invocação do módulo.
As setas de fluxo de dados estão anotadas com o nome correspondente dos dados. Setas de fluxo de dados

representar o fato de que os dados nomeados passam de um módulo para o outro na direção do
seta.
Módulos de biblioteca: Um módulo de biblioteca é geralmente representado por um retângulo com bordas duplas.

As bibliotecas compreendem os módulos frequentemente chamados. Normalmente, quando um módulo é invocado por muitos

outros módulos, ele é transformado em um módulo de biblioteca.

Seleção: O símbolo do diamante representa o fato de que um módulo de vários módulos

conectado com o símbolo de diamante é invocado dependendo do resultado da condição
anexo com o símbolo de diamante.

Engenharia de Software Page 11 Preparado por [Link], Prof. Assistente. GASC, Ngl.
Repetição: Um laço em torno das setas de fluxo de controle denota que os módulos respectivos são
invocado repetidamente.
Fluxograma versus diagrama de estrutura

O fluxograma é uma técnica conveniente para representar o fluxo de controle em um programa.

Um diagrama de estrutura difere de um diagrama de fluxo em três principais aspectos: geralmente é difícil
identificar os diferentes módulos de um programa a partir de sua representação em fluxograma. Intercâmbio de dados

entre diferentes módulos não está representado em um diagrama de fluxo. A ordenação sequencial das tarefas que é

inato a um fluxograma é suprimido em um diagrama de estrutura.

Gráfico de estrutura de um supermercado.

8. DESIGN DETALHADO
Durante o design detalhado, a descrição em pseudocódigo do processamento e os diferentes
estruturas de dados são projetadas para os diferentes módulos do gráfico de estrutura.
Estes são geralmente descritos na forma de especificações de módulo (MSPEC).
MSPEC é geralmente escrito usando inglês estruturado.
O MSPEC para os módulos não folha descreve as diferentes condições sob as quais o
as responsabilidades são delegadas aos módulos de nível inferior.
O MSPEC para os módulos de nível de folha deve descrever em forma algorítmica como o
passos de processamento primitivos são realizados.

Para desenvolver o MSPEC de um módulo, geralmente é necessário referir-se ao modelo DFD

e o documento SRS para determinar a funcionalidade do módulo.

Engenharia de Software Page 12 Preparado por [Link], Prof. Assistente, GASC, Ngl.