Engenharia de Software Análise Estruturada

SUMÁRIO

Introdução ................................................................................................... 04
1.Análise Estruturada ................................................................................ 05
2. Diagrama de Fluxo de Dados ................................................................ 05
2.1.Fluxo de dados .................................................................................... 07
2.1.1. Processo / Função............................................................................ 07
2.1.2. Agentes Externos ou Entidades..................................................... 08
2.1.3. Depósito de Dados / Armazenamento .......................................... 08
3. Dicionário de dados ................................................................................ 08
3.1. Notação para dicionário de dados .................................................. 09
4. Diagrama de Contexto ........................................................................... 10
5. Especificação de Processo ...................................................................... 10
5.1. Tabelas de Decisão ............................................................................ 11
5.2. Árvore de Decisão ............................................................................. 11
5.3. Fluxogramas ...................................................................................... 11
5.4. Português Estruturado ..................................................................... 12
6. Conclusão ................................................................................................ 13
7. Bibliografia ............................................................................................. 14
Engenharia de Software Análise Estruturada 4

INTRODUÇÃO

A Análise Estruturada de Sistemas compõe-se de um conjunto de técnicas e

ferramentas, em constante evolução, nascido do sucesso da programação e dos projetos
estruturados. Ela se conceitua na construção de 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 as necessidades daqueles que dele precisam.
Vamos mostras as ferramentas gráficas e as maneiras como se ajustam para
produzirem um modelo lógico. Como utiliza ferramentas que constróem um modelo
lógico, o método de desenvolvimento do sistema resultante é um tanto diferente dos
métodos tradicionais.
Começamos com o diagrama de fluxos de dados lógicos e com a metodologia
que envolva a construção de um sistema top-dowm por refinamentos sucessivos,
produzindo, primeiro, um fluxo de dados global do sistema, para depois desenvolver
fluxos detalhados, e em seguida, definir os detalhes da estrutura dos dados e da lógica
do processo.
Faremos uma comparação entre os modelos CHRIS GANE/SARSON E
DEMARCO/ YOURDON.
Engenharia de Software Análise Estruturada 5

1. ANÁLISE ESTRUTURADA

Um grupo de normas e recursos gráficos de comunicação, permitindo que o

analista de sistema substitua a especificação em linguagem natural por um tipo de
especificação clara que os usuários possam realmente ler e entender.
Para introduzirmos a técnica de análise estruturada é necessário que tracemos
uma paralelo com a Análise Tradicional ou não estruturada.
A Análise é a fase em que se especificam que informações o sistema deve
fornecer para atender às necessidades de seus usuário, ou seja, define que o sistema
deve fazer.
A Análise de Sistemas tradicional geralmente especifica os requisitos de um
sistema de forma narrativa, com textos contínuos e termos técnicos, e então é fornecida
ao usuário para sua “validação”.
As razões para a dificuldade do usuário com as especificações técnicas feitas
pelos analistas são: abordagem multifuncional, onde o texto trata de diversos assuntos
ou funções simultaneamente, abordagem monolítica, a forma narrativa geralmente não
permite o melhor encadeamento das idéias, apresentando-as todas de uma só vez; falta
de uniformidade e padronização, uma simples mudança nos requisitos do usuário pode
acarretar mudanças em diversas partes da especificação funcional e ausência de padrão
para avaliação de qualidade, o estilo pessoal de cada analista dificulta a interpretação de
texto por parte do usuário.
Tudo isso traz como conseqüência uma grande incidência de alterações
solicitadas pelo usuário durante a fase de desenvolvimento, rejeição do produto final,
difícil manipulação do sistema e baixa confiabilidade trazendo um ciclo de vida muito
reduzido.

2. DIAGRAMA DE FLUXO DE DADOS (D.F.D)

A técnica utilizada pela análise estruturada baseia-se nos diagramas de fluxos

de dados. A grande vantagem da utilização dessa técnica é a de permitir a avaliação do
modelo junto com os usuários, de forma a se identificar as falhas o mais cedo possível.
Além do mais , esta técnica permite um comprometimento maior do usuário com o
processo de desenvolvimento de sistemas.
Duas técnicas principais são utilizadas, uma por GANE e SARSON, outra por
De Marco e YOURDON e que nos conduzem pequenas diferenças na terminologia e
simbologia das várias escolas de Análise Estruturada; ambas as técnicas são similares.
Segundo GANE/830 propósito de um D.F.D é mostrar para um área de
negócios ou um sistema ou parte dele, de onde os dados surgem, para onde vão, quando
são armazenados, que processa os transformam e as interações entre armazenamento de
dados e processos.
É uma ferramenta “top-down” e se estende sucessivamente para os níveis de
maior detalhamento, são multidimencionais e utilizam-se de recursos gráficos. Trata-se
Engenharia de Software Análise Estruturada 6

de uma técnica formal de modelagem de processos, que permite o compartilhamento do

modelo entre a comunidade, possui o foco centrado na questão e no seu refinamento.
O D.F.D utiliza-se de quatro símbolos gráficos, visando representar os
seguintes componentes:
 Fluxo de Dados
 Processos
 Agentes Externos
 Armazenamento
Conforme CHRIS GANE/SARSON conforme DeMarco/YOURDON

SETA
FLUXO DE DADOS

FUNÇÃO / PROCESSOS
RETÂNGULO BOLHA

ARREDONDADO

AGENTES FONTES E
ESTERNOS DESTINOS
QUADRO
CAIXA
DUPLO

OU
01 RETÂNGULO ABERTO ARQUIVO
Engenharia de Software Análise Estruturada 7

2.1. Fluxo de Dados

Representa os dados que fluem entre os componentes de DFD e podem ser

utilizados para transporte de dados entre agentes externos e processos, entre processos,
armazenamento de dados e processos. Não existe a passagem de dados de
armazenamento para agentes externos e vice-versa.
É simbolizado por meio de uma seta, com a ponta indicando a direção do fluxo.
[ CHRIS GANE / SARSON].
Já DeMarco, diz que os fluxos de dados é um tubo, através do qual fluem
pacotes de informações. A maior parte dos fluxos de dados movimentaram-se entre
processos, mas eles podem também fluir para dentro ou para fora de arquivos, indo para
caixas-destino e vindo de caixas-fonte. É simbolizado por meio de vetores.
Convenções de fluxos de dados
1- Nomes em maiúscula e ligadas por hífen;
2- Dois fluxos de dados diferentes não podem Ter o mesmo nome;
3- Os nomes são escolhidos para representarem não apenas o dado que flui
sobre o tubo, mas também o que sabemos sobre o dado;
4- Evite nomes vagos como dados e informação;
5- Dificuldade para achar um nome para fluxo de dados: pode ser indício de
alguma coisa errada.

2.1.1. Processo / Função

São procedimentos predeterminados, que visam transformar os dados de

entrada em dados de saída. Estes procedimentos podem ser quaisquer tipos de operação
aritmética, lógica ou movimentação de dados e representam as coisas que acontecem
aos fluxos, em seu percursso através do sistema.
Em primeiro lugar, os processos são numerados, permitindo identificá-los
rapidamente, principalmente quando eles são agrupados hierarquicamente, o que é
visualizado na ocasião do nivelamento.
É necessário descrever a função de cada processo, para facilitar a referência,
fornecer uma identificação única para cada um, possivelmente associado a um sistema
físico.
A partir do momento em que o processo recebe a identificação esta não pode
ser modificada, exceto para desmembramentos ou agrupamentos, pois serve de
referência para fluxos de dados para decomposição do processo em níveis inferiores.
Convenções para processo ou Função
1- Cada função tem um nome descritivo;
2- Cada função recebe um número único;
3- Caso o nome que melhor represente a função consista de mais de um verbo,
considere um particionamento em mais funções;
Engenharia de Software Análise Estruturada 8

4- Um único verbo de ação forte:

 Verbo na forma imperativa: Ex.: Calcule valor de comissão (DeMarco).
 Verbo na forma infinitiva: Ex.: Calcular valor de comissão (Chrisgane /
Sarson).

2.1.2. Agentes Externos ou Entidades

São todas as organizações, sistemas ou pessoas que interagem com o sistema

através do envio ou recebimento ou fluxo de dados. Normalmente as entidades externas
têm intencionalmente seu nome escrito em maiúsculo, para diferenciá-las de possíveis
depósitos de dados com o mesmo nome.
Quando o sistema enfocado recebe dados de um outro sistema ou fornecidos a
ele, aquele sistema é considerado entidade externa.
O termo sistema empregado aqui, refere-se a um conjunto de procedimentos,
automatizados e manuais utilizados para efetuar um fim desejado.
Convenções:
1- Referência: Letra maiúscula, “E”, seguida de um número sequenciador
(opcional).
2- Nome da entidade: substantivo singular. Pode ser um orgão, uma pessoa ou
um sistema.
3- Indicador de repetição: indica que a entidade está representada mais de uma
vez no mesmo diagrama.

2.1.3. Depósito de Dados / Armazenamento

É um meio de se reter os dados que serão utilizados em outro momento

(tempo) pela mesma função ou por outros.
Os depósitos de dados são simples meios de reprodução de dados estocados,
sem maiores preocupações com suas características físicas em computador.
Convenções:
1- Evite nome codificados
2- A direção das setas é significativa
3- Um depósito de dados é mostrado em um DFD no primeiro nível em que é
usado como interface entre duas funções.

3. DICIONÁRIO DE DADOS

A análise estruturada advoga fortemente a documentação de todos os fluxos de

dados, armazenamento de dados e processos em um dicionário de dados.
O uso do dicionário de dados fornece uma definição padrão desses dados para
subsequente referência associada aos Diagramas de Fluxo de Dados.
Engenharia de Software Análise Estruturada 9

Fornece a informação de texto de suporte para complementar a informação

gráfica mostrada no DFD. Um dicionário de dados é simplesmente um grupo
organizado de definições, de todos os elementos de dados do sistema sendo modelado.
Um ou mais arquivos, descrevendo a natureza, a estrutura e a localização de
dados numa base de dados, de uma forma mais simplificada, é o registro dos arquivos
com seus respectivos campos.
Todas as ferramentas CASE, disponíveis têm um sistema de Dicionário de
Dados, o que resulta em ganhos consideráveis, se estes forem a nível corporativo e que
o Dicionário seja ativo, podendo ser acessado por todas as equipes de projeto.

3.1. Notação para Dicionário de Dados

As diversas convenções de dicionário de dados variam de uma simples forma

de anotação como a usada por DeMARCO, apropriada para o uso manual, passando por
uma abordagem padronizada de dicionário de dados como a usada por WEINBERG, até
uma abordagem automatizada de dicionário de dados como a usada por GANE e
SARSON.
Há vários esquemas comuns de notações usadas pela análise de sistemas; a
seguir, mostraremos uma das mais comuns e que usa um número de símbolos simples:

= É composto de
+ E
() Opcional
{} Iteração
[] Selecione somente uma das alternativas
** Comentário
@ Identificador (campo chave) para um dado
| Separador de alternativa na construção []

Como um exemplo, podemos definir um elemento de dado “nome” onde

utilizamos caracteres válidos, título, primeiro nome e sobrenome obrigatórios:

NOME = TÍTULO + PRIMEIRO_NOME + (NOME_DO_MEIO) +

SOBRENOME
TÍTULO = [SR. | SRA. | SRTA | DR. | PROF. ]
PRIMEIRO_NOME = { CARACTERE_VALIDO}
NOME_DO_MEIO = {CARACTERE_VALIDO}
SOBRENOME = {CARACTERE_VALIDO}
CARACTER_VALIDO = [a-z | A-Z | 0-9 | ‘ | - | |]
Engenharia de Software Análise Estruturada 10

4. DIAGRAMA DE CONTEXTO
O Diagrama de contexto estabelece os limites entre o sistema em questão e o
seu meio ambiente. É utilizado para mostrar as comunicações entre o sistema, o
ambiente e as entidades com as quais se comunica. Representa o Diagrama de Fluxo de
Dados de mais alto nível para um determinado sistema, definindo de forma quantitativa
os limites Sistema – Ambiente.
Os elementos que constituem são:
 Um único processo (O próprio sistema)
 Agentes Externos (Entidades)
 Fluxo de dados.
A única regra, a princípio, para a construção do Diagrama de Contexto é a de
que deva conter somente um processo, com um número ilimitado de Entidades e Fluxo
de Dados.
É de extrema importância a sua construção, pois permite a visualização, em
uma única figura, de todo o sistema a ser desenvolvido, facilitando sobremaneira o
contato com o usuário.
Para o seu refinamento é aconselhável:
 Ser balanceado contra a lista de eventos
 Ser balanceado contra o Dicionário de Dados
 Ter os seus fluxos de dados empacotados para apresentação

5. ESPECIFICAÇÃO DE PROCESSO

Além dos Diagramas de Fluxo de Dados e de um Dicionário de dados, a

Análise Estruturada produz uma série de especificações denominadas de “Minispecs”,
literalmente, miniespecificações ou especificações de processo.
As Miniespecificações podem ser expressas em linguagem estruturada e
documentem os processos e a lógica condicional representada nos Diagramas de Fluxo
de Dados.
Sua finalidade é permitir que o analista de sistemas descreva, rigorosamente e
precisamente, a forma comercial representada por cada um dos processos “at micos”
nos DFD de baixo nível. As especificações de processo podem ser escritas em uma série
de formas:

 Tabelas de decisão.
 Árvores de decisão.
 Fluxogramas.
 Português Estruturado.
Engenharia de Software Análise Estruturada 11

5.1. Tabelas de decisão

As tabelas de decisão especificam políticas para a transformação de entradas

em processamento em saídas, em vez de especificar as características operacionais do
algoritmo que está por baixo dessa transformação. Elas se concentram nas condições e
resultados, ao passo que os outros métodos de miniespecs, como os pseudocódigos e os
Fluxogramas, concentram-se na implementação procedimental da política.
As tabelas de decisão são muito úteis na explicação das miniespecs para os
usuários finais. São boas para clarearem as regras e políticas confusas. Também é
comum uma tabela de decisão revelar discrepâncias ou lacunas nas políticas e
procedimentos existentes, sendo que as pessoas gostam de tabelas bidimensionais
porque estas são de fácil compreensão então são ambíguas, que resultariam em
dificuldades para a sua compreensão.

5.2. Árvores de decisão

Quando a lógica for complexa, para ser detalhada pela utilização de linguagens
estruturadas, então podemos recorrer a outras ferramentas, entre elas a das Árvores de
Decisão.
A árvore de decisão é uma ferramenta “top-dow” que através da divisão das
ações em diferentes ramos, consegue cobrir todos os possíveis desdobramentos de uma
determinada lógica.
As árvores de decisão são bem simples de modificar, de acordo com a evolução
das especificações. A tarefa mais difícil é organizar os critérios de decisão para que cada
teste ocorra somente uma vez, mas, uma vez executada, será fácil acrescentar novas
condições de teste e atualizar a árvore. As miniespecs em árvore de decisão são fáceis
para os programadores seguirem: a ramificação lógica do programa já está desenhada
em forma diagramática.

5.3. Fluxogramas

O fluxograma é também chamado de diagrama de blocos e é uma das mais

antigas e conhecidas ferramentas de modelagem, mesmo com as críticas que sofre dos
grandes autores de técnicas estruturadas.
O fluxograma usa um conjunto de símbolos gráficos que descreve as etapas da
resolução do problema e é normalmente usado antes de se escrever o programa final.
Normalmente é utilizado pelo programador para a documentação do programa,
apresentando com clareza e precisão o raciocínio e as operações envolvidas, de modo
Engenharia de Software Análise Estruturada 12

que possa ser imediatamente transcrito em forma de programa e sirva como meio
eficiente de documentação do mesmo.
Por ser, ainda, amplamente utilizado ele segue algumas padronizações como:
Recomendação R1028 da “Intenational Organization for Standardization”
sobre os símbolos de fluxogramas para informações de processamento.
Se por um lado ele auxilia na solução dos principais problemas de uma
descrição formal em português, por outro não conseguia refletir a realidade do usuário
dado a sua tecnicidade, por utilizar somente símbolos de processamento de dados.

5.4. Português estruturado

O próprio nome já nos indica, um português com estrutura, e é mais uma

ferramenta da Análise Estruturada utilizada para descrever os processos ou bolhas do
DFD.
O Português Estruturado utiliza uma notação muito parecida aos programas
estruturados escritos numa linguagem de alto nível como o COBOL, através do
emprego de quatro estruturas lógicas de especificação de processo:

1. Seqüência.
2. Repetição.
3. Condicional.
4. Acesso a dados.

Com isso, apesar de ser uma linguagem simples torna-se simultaneamente

rigorosa para definir como os fluxos de saída são produzidos a partir dos fluxos de
entrada e como a memória do sistema é afetada ou usada. Deve existir uma
especificação, em português estruturado, para cada primitiva funcional do DFD.

A descrição da primitiva funcional tem que abranger atividades que:

 Obtenham fluxo do dados de outros processos ou entidades externas.

 Geram fluxos destinados a outros processos ou entidades externas.
 Criem ou removam ocorrências de objetos na memória do sistema.
 Derivem elementos de dados ou itens elementares de memória do sistema.
Engenharia de Software Análise Estruturada 13

6. CONCLUSÃO

De acordo com os fatos mencionados no nosso trabalho a análise estruturada é

fundamental no desenvolvimento de um projeto de software. Um bom projeto deve ser
analisado, preocupando-se com acontecimentos futuros. Os principais objetivos da
análise estruturada é reduzir custos, aumentar a produtividade, gerar sistemas
impessoais (não vinculado a um funcionário), aumentar a legibilidade dos sistemas e
aumentar a flexibilidade dos sistemas para facilitar futuras alterações.
Engenharia de Software Análise Estruturada 14

7. BIBLIOGRAFIA

DEMARCO, Tom – “Análise Estruturada e Especificação De Sistema” –

Editora Campus;
GANE, Chris, SARSON, Trish: Análise Estruturada de Sistemas – Livros
Técnicos e Científicos Editora Ltda.