Engenharia de Software1

Prévia do material em texto

Conteúdo:
ENGENHARIA 
DE SOFTWARE
Aline Zanin
Izabelly Soares 
de Morais
Revisão técnica:
Jeferson Faleiro Leon
Desenvolvimento de Sistemas 
Especialista em Formação Pedagógica de Professores
Catalogação na publicação: Karin Lorien Menoncin CRB-10/2147
M827e Morais, Izabelly Soares de.
 Engenharia de software [recurso eletrônico] / Izabelly
 Soares de Morais, Aline Zanin ; revisão técnica : Jeferson
 Faleiro Leon. – Porto Alegre : SAGAH, 2017.
 
 ISBN 978-85-9502-253-9
 Engenharia. 2. Engenharia de software auxiliada por 
 computador. I. Zanin, Aline. II. Título.
 
CDU 004.41
Modelo de análise 
de software (análise 
estruturada)
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar os objetivos da análise estruturada. 
 � Compreender os principais elementos de modelagem (diagrama de 
fluxo de dados e dicionário de dados). 
 � Descrever as vantagens e desvantagens desse modelo.
Introdução
A análise estruturada é um dos métodos utilizados e presentes nas ca-
madas da Engenharia de Software. As ferramentas de análise estruturada 
permitem que um profissional de software crie modelos de dados, mo-
delos de fluxos e modelos comportamentais para possibilitar a análise 
de consistência, a continuidade, a fácil edição e a extensão. 
Os modelos criados, empregando tais ferramentas, fornecem ao en-
genheiro de software uma visão da representação de análise e podem 
ajudar a eliminar erros antes que se propaguem pelo projeto ou, pior 
ainda, na própria implementação. 
A análise estruturada considera os dados e os processos que transfor-
mam os dados como entidades separadas na modelagem de um sistema. 
Os objetos de dados são modelados de maneira a definir seus atributos 
e relações. Processos que manipulam objetos de dados são modelados 
para mostrar como transformam os dados à medida que objetos de 
dados fluem por meio do sistema.
Neste capítulo, você vai adquirir conhecimentos fundamentais para 
avançar no aprendizado sobre análise estruturada. Vai ver também os 
principais elementos de modelagem e algumas vantagens e desvanta-
gens desse modelo.
Engenharia de software aplicada à análise 
estruturada de sistemas
A Engenharia de Software nos traz metodologias que auxiliam no processo de 
desenvolvimento de um software, porém, só começou a ser vista como algo 
colaborativo durante este processo no início da década de 1970. Foi entre as 
décadas de 1970 e 1980 que ocorreram grandes progressos nas técnicas que 
já estavam sendo utilizados anteriormente.
Um acontecimento muito relevante para o contexto computacional e do 
desenvolvimento de software foi o surgimento de um paradigma utilizado na 
análise de sistemas (que trazem um conjunto de elementos, que juntos têm 
o intuito de atingir algum propósito ou solucionar algum problema), que, 
inicialmente, foi definido como clássico, porém, posteriormente, passou a ser 
chamado também de estruturado. 
De acordo com Schach (2010, p. 40), uma das principais razões para o su-
cesso limitado do paradigma clássico foi que as técnicas clássicas são orientadas 
a operações ou orientadas a atributos (dados), mas não a ambos ao mesmo 
tempo. Os componentes básicos de um produto de software são as operações do 
produto e os atributos sobre os quais essas operações agem. Algumas técnicas 
clássicas, quanto à análise de fluxo de dados, são orientadas a operações, 
ou seja, tais técnicas se concentram nas operações do produto; os atributos 
ficam em segundo plano. Diferentemente, técnicas como o desenvolvimento 
de sistemas são orientadas a atributos. A ênfase, nesse caso, é nos atributos; 
as operações que atuam sobre os atributos são menos significativas.
 Ainda sob a ótica do autor, esses atributos devem ser apresentados de forma 
explícita, assim como os principais objetivos e funcionalidades do sistema. 
Dessa forma, Schach (2010, p. 351) diz que 
“um documento de especificação deve satisfazer a duas exigências mutuamente 
contraditórias. De um lado, esse documento deve ser claro e inteligível para 
o cliente, que, provavelmente, não é um especialista em informática. [...] De 
outro lado, o documento de especificação deve ser completo e detalhado, pois é 
praticamente a única fonte de informações disponível para elaborar o projeto”. 
Modelo de análise de software (análise estruturada)2
A análise estruturada traz uma sequência de desenvolvimento, ou seja, 
uma fase que tanto depende dos resultados obtidos em suas fases anteriores 
quanto afeta as fases posteriores. Em razão da utilização de uma metodologia 
disciplinada, que exige certa sistematização de etapas e até do uso de técni-
cas, faz-se necessária uma boa comunicação, clara e concisa, entre todos os 
envolvidos no projeto. Portanto, podemos concluir que 
“compõe-se de um conjunto de técnicas e ferramentas, em constante evolução. 
Seu conceito fundamental é a construção de um modelo lógico (não físico) de 
um sistema, utilizando técnicas gráficas capazes de levar usuários, analistas 
e projetistas a formarem um quadro claro e geral do sistema e de como suas 
partes se encaixam para atender às necessidades daquele que dele precisam. 
Antes do desenvolvimento dessas ferramentas de Análise Estruturada de 
Sistemas, todos os detalhes da implementação física eram perdidos” (GANE; 
SARSON, 1985). 
A Figura 1 a seguir traz alguns símbolos criados por Gane e Sarson para 
a realização da análise estruturada de software. Esta notação é vista como 
uma das mais utilizadas na prática da análise estruturada.
Figura 1. Os símbolos da análise de sistemas 
estruturada de Gane e Sarson.
Fonte: Schach (2010, p. 356).
3Modelo de análise de software (análise estruturada)
Para utilizar esse tipo de análise, devemos inicialmente determinar as 
necessidades do sistema, para que, depois, o fluxo de dados lógico determine 
“o que” deverá ser feito e o fluxo de dados físicos determine “como” será 
realizado. A representação gráfica facilita a visualização de todo o sistema, 
tanto para a equipe de desenvolvimento quanto para o cliente, que geralmente 
é leigo nos assuntos que norteiam o ciclo de desenvolvimento de um sistema 
computacional. Para isso, trataremos no próximo tópico sobre os principais 
elementos de modelagem utilizados neste modelo de análise.
O uso de elementos gráficos para especificar software foi uma técnica importante dos 
anos 1970. Três técnicas que utilizam elementos gráficos tornaram-se particularmente 
populares: as técnicas de DeMarco (1978), Gane e Sarson (1979) e Yourdon e Constantine 
(1985). Todas elas são igualmente satisfatórias e, basicamente, equivalentes (SCRACH, 
2010).
Elementos de modelagem
Um sistema computacional tem três estágios básicos: entrada, processamento 
e saída de dados. Para isso, o uso de uma análise de software estruturada 
requer que haja o estudo da viabilidade do projeto e a análise e as especifi-
cações dos requisitos e do projeto, para que possa ocorrer a implementação, 
os testes e a manutenção do sistema que será desenvolvido. Um elemento 
ligado à modelagem que podemos destacar é o uso dos gráficos, que trazem 
simbologias conceituais e que seguem uma sequência lógica de execução, 
permitindo que tanto os clientes quanto a equipe desenvolvedora compreenda 
as especificações do sistema.
As metodologias que utilizam este princípio foram desenvolvidas para 
auxiliar os desenvolvedores neste processo. Para isso, diversas ferramentas 
e metodologias foram predefinidas. Selecionamos aqui o diagrama de fluxo 
de dados (DFD) e o dicionário de dados (DD).
Modelo de análise de software (análise estruturada)4
Diagrama de fluxo de dados (DFD)
O diagrama de fluxo de dados (DFD), assim como os demais diagramas, tem 
como função principal expor informações vistas antes como abstratas, tais 
como os processos que compõem o sistema. É visto como a principal ferramentautilizada para a análise estruturada, pois deixa em evidência todo o fluxo de 
entrada e saída de dados. 
Dessa forma, este tipo de diagrama “é construído identificando-se os 
fluxos de dados contidos no documento de levantamento de necessidades ou 
no protótipo rápido. Cada fluxo de dados inicia e termina em uma origem, um 
destino de dados (representado por um quadrado duplo), ou um repositório 
de dados (representado por um retângulo com um lado aberto). Os dados são 
transformados por um ou mais processos (representados por um retângulo com 
cantos arredondados). A cada refinamento gradual sucessivo é acrescentado um 
novo fluxo de dados ao DFD, ou um fluxo de dados existente é refinado pelo 
acréscimo de outros detalhes” (SCHACH, 2010). Esses recursos gráficos podem 
ser visualizados na Figura 1, mostrada anteriormente, na qual os símbolos da 
análise de sistemas estruturada propostos por Gane e Sarson foram expostos.
Conforme Oliveira (2011), os autores Yourdon e Constantine (1985) apre-
sentam, em sua obra, alguns conceitos sobre os componentes do diagrama 
de fluxo de dados. Mais tarde, outros autores acrescentaram mais algumas 
representações gráficas e que são retratadas a seguir no Quadro 1.
Componentes do DFD Funções Regras
Bolha de processos Representa um 
processo, uma 
atividade ou 
uma função. É 
o componente 
ativo que realiza 
a transformação 
no sistema. 
- Todo nome de processo 
deve indicar uma ação a ser 
feita, ou seja, deve conter 
um verbo infinitivo mais um 
complemento. Exemplo: 
emitir cobrança, gerar 
relatório, cadastrar cliente; 
- Todo processo deve estar 
devidamente numerado, 
levando em consideração 
o número e o nível em 
que ele se encontra.
Quadro 1. Componentes gráfico do diagrama de fluxos de dados.
(Continua)
5Modelo de análise de software (análise estruturada)
Componentes do DFD Funções Regras
Processos São as várias 
atividades 
realizadas no 
sistema.
Deve conter:
- Identificação: é um 
número atribuído ao 
processo, exclusivamente 
para identificá-lo, não 
tendo, portanto, outro 
significado. Geralmente, 
esses números são 
colocados da esquerda 
para a direita no diagrama 
de fluxo de informações; 
- Descrição: é uma frase 
imperativa, formada por 
um verbo referente a uma 
ação (registro, controle, 
preencha, etc.), seguido 
por um objeto. Exemplo: 
“remeta pagamento atraso”; 
- Localização física: é 
o nome da unidade 
organizacional responsável 
pela atividade, no caso de o 
sistema ser implementado 
(DUQUE DE CAXIAS, 2017). 
Fluxo de Dados Representa os 
insumos ou 
produtos dos 
processos, ou seja, 
representa dados 
trafegando entre 
processos ou 
entre processos e 
o mundo externo. 
As setas indicam 
o sentido do 
fluxo, e devem 
vir com o nome 
do fluxo ao qual 
estão associadas.
- Todo fluxo de dados 
deve ter nome;
- Fluxo de dados não 
tem ação, somente 
representam os dados;
- Não podem existir 
nomes repetidos de 
fluxo de dados.
Quadro 1. Componentes gráfico do diagrama de fluxos de dados.
(Continuação)
(Continua)
Modelo de análise de software (análise estruturada)6
(Continuação)
Componentes do DFD Funções Regras
Entidade Externa Representa o 
processo de 
entrada ou 
recebimento de 
dados, que são 
denominados 
respectivamente 
de fontes e 
terminadores.
- Entidade externa 
não se comunica com 
outra entidade;
- Entidade externa não 
acessa depósito de dados.
Depósito de Dados 
ou Arquivos
Elementos que 
representam um 
arquivo ou um 
local onde as 
informações são 
depositadas para 
uso posterior 
por qualquer 
processo dentro 
do escopo do 
sistema. Exemplo: 
pastas, ficheiros, 
dentre outros.
- Não podem existir 
depósitos de dados 
somente com entrada 
ou somente com saídas 
dentro do sistema.
Convenções Adicionais É utilizado quando 
o cruzamento 
de linhas de 
fluxos deve ser 
minimizado e/
ou quando o 
cruzamento 
for inevitável 
(TEIXEIRA, 
2003, p. 69).
Quadro 1. Componentes gráfico do diagrama de fluxos de dados.
7Modelo de análise de software (análise estruturada)
Algumas boas práticas são indicadas para que um diagrama de fluxo de 
dados seja concebido de maneira correta, no sentido de que todas as informa-
ções inseridas irão retornar o resultado esperado. Para isso, Teixeira (2003, 
p. 72), destacam-se as seguintes diretrizes:
 � escolher nomes significativos para os processos, fluxos, depósitos e 
terminadores.
 � numerar os processos.
 � produzir o DFD seguindo a organização visual de seus elementos.
 � evitar trazer complexidade ao DFD.
 � verificar a consistência interna do DFD e de seu relacionamento com 
outros DFDs.
Dicionário de dados (DD)
A concepção de um software envolve diversas operações. Para isso, os recur-
sos tecnológicos nos auxiliam durante esse processo. Além de metodologias, 
existem diversas formas práticas de se desenvolver algo. Para tanto, podemos 
fazer uso das chamadas ferramentas “CASE”, que nada mais são do que a uti-
lização do computador como recurso para aplicação de práticas da Engenharia.
Uma importante categoria das ferramentas CASE são os dicionários de 
dados (DD), uma lista informatizada de todos os dados definidos no produto. 
Um produto grande contém dezenas (talvez centenas) de milhares de dados, 
e o computador é ideal para armazenar informações, como nomes e tipos de 
variáveis e o local em que cada uma delas é definida, bem como nomes de 
procedimento e de parâmetros e seus tipos. Uma parte importante de toda a 
entrada de um dicionário de dados é a descrição do item 
O poder dos dicionários de dados pode ser ampliado combinando-o com 
um verificador de consistência, uma ferramenta para verificar se cada dado no 
documento de especificações está refletido no projeto e, ao contrário, se cada 
dado no projeto foi definido no documento de especificações O dicionário de 
dados pode ser visto como um parâmetro que traz informações sobre todos os 
elementos do sistema. Para isso, ele possui algumas informações relevantes, 
como os dados elementares, que estão envolvidos no contexto do usuário, por 
exemplo, quando vamos preencher o endereço de um usuário, geralmente essa 
informação requer diversos dados, ou seja, é um elemento de dados composto, 
pois para ficar completo temos que inserir, além do nome da rua ou avenida, 
o número, o CEP e até outras informações (SCHACH, 2010).
Modelo de análise de software (análise estruturada)8
Com o uso do DD, podemos detalhar os seguintes itens: depósito de dados, 
fluxo de dados e dados que são elementares e constituem fluxos e depósito de 
dados. De acordo com o material disponibilizado pela Universidade Estadual 
Paulista (UNESP, 2015), cada entrada é constituída por um identificador e sua 
respectiva descrição. Esta descrição deve ser composta por: 
 � O seu significado;
 � O seu conteúdo (utilizado apenas em dados compostos);
 � Os valores permitidos e as unidades (utilizados apenas para dados 
elementares);
 � A chave primária (apenas para depósito de dados).
O material ainda traz a notação utilizada no dicionário de dados, que será 
apresentada no Quadro 2 a seguir:
UNESP, 2015.
Símbolo Significado
= é constituído por ou é definido por
+ e (conjunção ou concatenação)
( ) enquadram componentes opcionais
[ ] enquadram componentes que são 
utilizadas alternativamente
| separam componentes alternativas enquadradas por [ ] 
{ } enquadram componentes que se repetem 0 ou mais vezes
* * enquadram comentários
@ identifica a chave primária de um depósito
Quadro 2. Notação do dicionário de dados (DD).
A descrição de alguns dados elementares é necessária apenas quando as 
informações dos elementos de dados não ficam claras e podem gerar entendi-
mentos dúbios. O ideal é que o sistema retorne sempre mensagens confirmando 
se os procedimentos foram concluídos e/ou realizados com sucesso, como a 
9Modelo de análise de software (análise estruturada)
confirmação de que um cadastro foi finalizado. Geralmente, a descrição dos 
dados informa o modo correto de se preencher alguns campos. Um exemploclássico é o CPF, que pode conter ou não os caracteres, como pontos e hífen. 
Dessa forma, deve haver uma sinalização informando como o usuário deve 
preencher este campo, ou seja, se é ou não para utilizar os caracteres ou apenas 
números para informar o CPF.
Os elementos de modelagem visam oferecer um suporte maior para a 
realização da análise estruturada de sistemas.
Além dos elementos da modelagem utilizados em uma análise estruturada de software, 
podemos citar também a existência dos fluxogramas, que também trazem represen-
tações gráficas ao processo de produção de um software. 
De acordo com Manzano (2012), a análise estruturada é uma ferramenta usada e 
desenvolvida pelos profissionais da área de análise de sistemas. Tem como finalidade 
descrever o fluxo de ação de um determinado trabalho lógico, seja manual ou mecânico, 
especificando os suportes usados para os dados e para as informações. Usa símbolos 
convencionais (norma ISO 5807:1985), permitindo poucas variações.
Vantagens e desvantagens da análise 
estruturada
De acordo com Schach (2010), entre as técnicas que formavam o paradigma 
clássico havia a análise de sistemas estruturada, a análise de fluxo de dados, a 
programação estruturada e os testes estruturados. Inicialmente, quando usadas, 
essas técnicas pareciam extremamente promissoras. Entretanto, à medida que 
o tempo foi passando, constatou-se que elas ficaram aquém do esperado em 
dois aspectos, os quais são expostos pelo autor a seguir:
1. Algumas vezes, as técnicas eram incapazes de lidar com o tamanho cada 
vez maior dos produtos de software, isto é, as técnicas clássicas eram 
adequadas para elaborar produtos de escala pequena (tipicamente com 
5 mil linhas de código) ou até mesmo produtos de escala média, com 
cerca de 50 mil linhas de código. Atualmente, entretanto, produtos de 
larga escala, com 500 mil linhas de código, são relativamente comuns. 
Modelo de análise de software (análise estruturada)10
Até mesmo produtos com 5 milhões ou mais de linhas de código não 
são considerados raros. Entretanto, as técnicas clássicas normalmente 
não conseguem ser ampliadas de forma a conseguir lidar com o desen-
volvimento dos produtos atuais de maior porte.
2. O paradigma clássico não estava à altura das expectativas iniciais 
durante a manutenção pós-entrega. Um importante agente propulsor 
do paradigma clássico há 30 anos foi que, em média, dois terços do 
orçamento para software eram destinados à manutenção pós-entrega. 
Infelizmente, o paradigma clássico não havia resolvido esse problema, 
várias organizações ainda despendem de 70% a 80% ou mais de seu 
tempo e esforços em manutenção pós-entrega (YOURDON, 1992; 
HATTON, 1998 apud SCHACH, 2010). 
Diante das informações trazidas pelo autor, podemos concluir que a análise 
estruturada nos traz conceitos tradicionais e iniciais sobre a prática, quando 
inserida no processo de desenvolvimento de um software. Porém, não se tornou 
menos importante, pois traz a base de outras metodologias de análise, sendo, 
dessa forma, utilizada até os dias de hoje.
Ela é indicada diante de contextos simples, já o diagrama de fluxo de dados, 
pode ajudar a esboçar uma visão do sistema, fazendo com que seja necessário 
o uso de metodologias mais concisas e que possam abranger qualquer tipo de 
contexto, até mesmo porque atualmente vivemos em uma era tecnológica que 
exige cada vez mais sistemas computacionais complexos.
Acesso o link a seguir e leia o artigo Need for systems analysis 
and design, que aborda a importância da realização da 
análise de sistemas. 
https://goo.gl/yYX9ss
11Modelo de análise de software (análise estruturada)
Figura 2. Diagrama de fluxo de dados com todos os elementos gráficos. 
Fonte: Schach (2010, p. 357)
DEMARCO, T. Structured Analysis and System Specification. New York: Yourdon Press, 1978.
DUQUE DE CAXIAS. Secretaria Municipal de Educação. Análise Estruturada: diagrama 
de Fluxo de Dados. Duque de Caxias: SME, 2017. Disponível em: <http://smedu-
quedecaxias.rj.gov.br/nead/Biblioteca/Forma%C3%A7%C3%A3o%20Continuada/
Tecnologia/cursos/programacao/analise%20e%20logica/metodo%20integrado/
DFD.pdf>. Acesso em: 13 ago. 2017.
GANE, C. P.; SARSON, T. Análise Estruturada de Sistemas. São Paulo: LTC, 1985.
KENDALL, J. E.; KENDALL, K. E. Systems Analysis and Design. Upper Saddle River: Pren-
tice Hall, 2002.
MANZANO, J. A. N. G.; OLIVEIRA, J. F. Algoritmos: lógica para desenvolvimento e 
programação de computadores. 26. ed. São Paulo: Érica, 2012.
OLIVEIRA. R. C. Engenharia de Software. Uberlândia: UFU, 2011. Disponível em: < http://
www.facom.ufu.br/~ronaldooliveira/aps-2017-2.html#material>. Acesso em: 13 ago. 
2017.
SCHACH, S. R. Engenharia de software: os paradigmas clássicos e orientado a objetos. 
7. ed. Porto Alegre: AMGH, 2010.
Modelo de análise de software (análise estruturada)12
TEIXEIRA, M. N. Análise estruturada de sistemas. 3M Soluções, São Paulo, 2003. Dis-
ponível em: http://www.3msolucoes.com.br/adm/downloads/AE_Aulas_final.pdf. 
Acesso em: 13 ago. 2017.
UNESP. Dicionário de dados (DD): análise estruturada. São Paulo: UNESP, 2015. Disponível 
em: <https://moodle.unesp.br/ava/pluginfile.php/24935/mod_resource/content/2/4-
-DicionarioDados.pdf>. Acesso em : 16 out. 2017.
YOURDON, E.; CONSTANTINE, L. L. Structured Design: fundamentals of a Discipline 
of Computer Program and Systems Design. Englewood Cliffs: Prentice Hall, 1979.
Leituras recomendadas
JONES, M. P. Projeto Estruturado de Sistemas. Nova Iorque: McGraw-Hill, 1988.
MARTIN, J.; MCCLURE, C. Técnicas Estruturadas e CASE. São Paulo: Makron Books,1991.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 
8. ed. Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
SLACK, N.; CHAMBERS, S.; JOHNSTON, R.; BETTS, A. Gerenciamento de operações e de pro-
cessos: princípios e práticas de impacto estratégico. 2. ed. Porto Alegre: Bookman, 2013.
13Modelo de análise de software (análise estruturada)
Conteúdo: