Capa Atps

Anal i se Es truturada

Diagrama de Fluxo de Dados

Tecnologia em Processamento de Dados

Analise de Sistemas

2

3

Índice:

1. Introdução, pagina 4

2. Uma Ferramenta Eficaz, pagina 5

3. Analise Estruturada, Benefícios e Problemas, pagina 8

4. Diagrama de Fluxo de Dados Lógico, pagina 8

4.1. Características da Técnica de Análise Estruturada de Sistemas, pagina 9

4.2. Fatores Externos, pagina 9

4.3. Fluxo de Informações, pagina 10

4.4. Processos, pagina 11

4.5. Banco de Informações, pagina 11

5. Convenções para Explosão de Processos, pagina 12

6. Crítica à Análise Estruturada, pagina 13

7. Quando usar a Análise Estruturada, pagina 15

4

ANÁLISE ESTRUTURADA

1.Introdução

O uso de codificação estruturada torna possível quantificarmos alguns benefícios

resultantes: melhor produtividade em linhas de codificação por dia, uso mais apropriado do tempo

de teste e assim por diante.

Com projeto estruturado, os benefícios também são reais porém mais difíceis de

quantificar. Um estudo não publicado sugere que a modificação de um sistema que utilize projeto

estruturado chega a ser sete vezes mais fácil e barato do que sistemas tradicionais.

Realmente, sob certos aspectos, se o trabalho de análise fosse realizado de forma perfeita, o

único resultado seria ausência de problemas.

5

2. Uma ferramenta eficaz

A análise estrutura é uma fase crítica no desenvolvimento de sistemas e programas de

software porque afeta as fases de desenvolvimento seguintes. Ela é difícil por causa dos problemas

de comunicação, das mudanças nos requisitos do sistema e das técnicas inadequadas de avaliação.

Não é fácil descrever os requisitos do sistema em uma forma precisa. A linguagem do usuário e a

linguagem do responsável pelo desenvolvimento são tão diferentes que torna complicada uma

comunicação eficaz. Os requisitos, no entanto, apresentam um alvo móvel que continua a

modificar-se por todo o desenvolvimento do sistema e por todo o seu ciclo de vida.

A análise estruturada tem como objetivo resolver essas dificuldades fornecendo uma

abordagem sistemática, etapa por etapa, para desenvolver a análise e produzir uma especificação

de sistema nova e melhorada. Para conseguir este objetivo, a análise estruturada centraliza-se em

uma comunicação clara e concisa.

A especificação do sistema é o elo entre a análise e o projeto. Ela fornece uma descrição

dos requisitos do sistema a ser construído. O principal objetivo da análise é produzir uma

especificação do sistema que defina a estrutura do problema a ser resolvido de acordo com a visão

do usuário. O objetivo do projeto é definir a estrutura do problema e com os requisitos do usuário.

Os defensores da análise estruturada afirmam que o uso do mesmo método de construção para a

especificação e para o projeto obriga os dois a ficarem mais coesos e a mais provavelmente

representarem um sistema que satisfará às necessidades e expectativas do usuário. Análise

estruturada foi projetada para ser compatível com o projeto estruturado e fornecer a melhor entrada

possível para ele. A especificação é composta de diagrama de fluxo de dados, um dicionário de

dados e especificações dos processos.

A análise estruturada de sistemas 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 perdidas.

O analista serve de intermediário entre a comunidade de usuários e a comunidade de

programadores, portanto ele deve combinar o que é atualmente possível nessa tecnologia (minis,

micros, banco de dados, etc...) e o que vale a pena ser feito para a empresa, em relação a maneira

como é administradas, por este motivo torna-se necessário o uso de melhores ferramentas.

Os problemas que o analista enfrenta são entrelaçados, esta é uma das razões que os tornam

difíceis, como por exemplo:

- O analista acha difícil aprender o bastante sobre a empresa para conseguir determinar os

requisitos do sistema através dos olhos do usuário.

- Os usuários ainda não conhecem o suficiente sobre PD para saberem o que é, ou não viável. Em

geral, a propaganda a respeito dos computadores não proporciona às pessoas idéias específicas ou

precisas sobre o que tais máquinas podem ou não fazer.

6

- O analista pode ficar sobre carregado de detalhes rapidamente, não somente de detalhes técnicas

inerentes ao novo sistema.

- O documento que define os detalhes de um novo sistema (que podemos chamar especificação do

sistema, projeto geral, especificação funcional, ou qualquer nome equivalente) forma efetivamente

um contrato entre o departamento do usuário e o grupo de desenvolvimento de sistema , apesar de

muitas vezes ser impossível aos usuários entenderem, por causa de seu tamanho e dos conceitos

técnicos associados a ele.

- Se o documento da especificação puder ser escrito de forma a fazer sentido para os usuários,

poderá não ser muito útil para os projetistas e programadores que irão construir o sistema.

Mesmo utilizando as melhores ferramentas analíticas possíveis, alguns dos problemas

acima sempre estarão presentes, pois não existe ferramentas analítica que possibilita ao analista

saber o que o usuário pensa mas não diz.

Não há como mostrar um modelo concreto e claro do sistema para os usuários, pois é

difícil para os usuário imaginar o que o novo sistema lhes fornecerá até que esteja realmente em

funcionamento.

Até agora, a único ilustração para um sistema tem sido o Fluxograma. Embora um

Fluxograma possa valor mil palavras, o analista fica preso a um compromisso; o uso dos símbolos

padronizados de Fluxograma significa, inevitavelmente, que o analista deve se comprometer a

uma implementação física do novo sistema.

O próprio ato de desenhar um Fluxograma significa que é preciso tomar uma decisão

quanto à entrada de dados a ser feita por meio de cartões ou através de um terminal de vídeo,

quais arquivos estarão em fita e quais em disco, que programas produzirão saída e assim por

diante. Todovia, essas, decisões são a essência do trabalho do projetista. A partir do momento em

que o analista tiver desenhado um Fluxograma do sistema, o projetista poderá escolher entre

aceitar o projeto físico do analista e então lidar com os detalhes de estrutura de programa e

arquivo, de então (como muitas vezes acontece) retornar à especificação escrita para gerar um

novo projeto. Nenhum dos caminhos é satisfatório.

A especificação não somente deverá descrever tudo o que o usuário vê, incluindo todos as

interfaces, como também deverá evitar a descrição do que o usuário não vê.

Essa é a tarefa do implementador, e aqui sua liberdade deve ser limitada. O analista deve estar

sempre preparado para mostrar uma implementação de qualquer aspecto que ele descreve, mas

não deve tentar ditar a implementação.

7

Processo

Documento

(geralmente saida)

Decisão Fita

magnética

Cartão Perfurado Terminador

Saida em video

Conexão

Entrada Manual

Armazenamento de

dados

Figura: Símbolos convencionais de fluxogramas

O Fluxograma não é útil na “modelagem” do sistema para os usuários. Embora alguns

usuários possam aprender a ler Fluxograma, para a maioria deles o Fluxograma representa um

“Jargão visual”.

8

3. Analise Estruturada, Benefícios e Problemas

Benefícios Problemas

Os usuários obtém uma idéia mais clara do

sistema proposto pelo diagrama de fluxo de

dados, do que a obtida através da narrativa e

Fluxograma de sistemas físicos

O esforço , a formalidade e o grau de detalhe

necessários, especialmente na construção do

dicionário de dados, muitas vezes sofrem

resistência

A apresentação em termos de fluxo lógico

consegue mostrar mal-entendidos e pontos

controversos.

Tem havido uma certa preocupação por parte

dos programadores de que ao obterem

especificações detalhadas da lógica no

português estruturado, acabarão “ retirando

todo o prazer da programação, tornando-os

meros codificadores”

As interfaces entre o novo sistema e outros já

existentes, são mostrados de modo bem mais

claro

Orientação dos usuários e treinamento dos

analistas são necessários, pois com a

introdução da Análise Estruturada foram

mudadas as “regras do jogo” e todos devem

O uso de dicionário de dados para guardar os

itens do glossário do projeto economiza

tempo ao resolver rapidamente os casos em

que pessoas chamam as mesmas coisas por

diferentes nomes

ser bem esclarecidos quanto às novas regras e

à maneira como elas melhoram o jogo.

4. Diagrama de Fluxo de Dados Lógico

Uma diagrama de fluxo de dados é uma representação em rede dos processos (funções os

procedimentos) de um sistema e dos dados que ligam estes processos. Mostra o que um

sistema/procedimento faz, mas não como faz. É a ferramenta principal de modelagem da análise

estruturada e é usada para dividr o sistema em uma hierarquia de processos.

Os símbolos e os conceitos que o representa encontram-se no nível lógico; um fluxo de

dados pode estar contido fisicamente em qualquer lugar em que os dados passem de uma entidade

ou processo para outro. Utilizando os quatro símbolos do D.F.D., podemos desenhar um quadro do

sistema sem nos comprometermos com a sua implementação.

9

Fluxo de dados

Processo que Depósito de dados

transforma os

fluxos de dados

Origem e/ou

destino dos

dados

Figura: Simbologia Básica do Diagrama de Fluxo de dados

4.1.Características da Técnica de Análise Estruturada de Sistemas

A análise estruturada de sistemas é uma técnica que consiste em construir, graficamente,

um modelo lógico para o sistema de informações gerenciais, a qual permite que usuários e

analistas de sistemas, encontrem uma solução clara e única para o sistema de modo que este

transmita as reais necessidades dos usuários.

A análise estruturada de sistemas apresenta um desenvolvimento do geral para o particular

do sistema, começando com um diagrama geral de fluxo de informações e partindo depois por um

refinamento sucessivo através da construção de diagrama de fluxo de informações detalhadas. A

análise estruturada define “o que” o sistema deve fazer e torna-se bastante valiosa no momento de

determinar as entradas para os sistemas de modo que estes fiquem os mais flexíveis possível.

4.2. Fatores externos

Geralmente, são classes lógica, de atividades e ou pessoa que interagem com o sistema

sendo fontes ou destinos das informações. Exemplo: cliente, banco, fornecedores, etc. Pode

também ser considerado fator externo outro sistema que forneça dados ou informações para o

sistema que está sendo descrito, ou que receba dados dos mesmos.

O fator externo é representado por um símbolo que é um quadrado com as faces esquerda e

de cima duplamente traçadas, para distingui-lo dos demais símbolos usados nos diagramas. É

identificado por uma letra minúscula colocada no canto superior esquerdo.

10

a

Para evitar que as linhas dos fluxos de informações se cruzem em demasia, pode-se repetir

o mesmo fator no mesmo fluxo, mais de uma vez, denotando tal fato por meio de uma linha

diagonal que é colocado no canto inferior direito.

Portanto, se um fator precisar ser repetido, coloca-se uma linha diagonal no canto inferior

da mesma; se outro também precisar ser repetido, colocam-se duas linhas diagonais, e assim por

diante, independentemente do número de vezes que o fator aparecer repetido. Exemplo:

a

Cliente

a

Cliente

4.3. Fluxo de Informações

Representam, nos diagramas, um sistema de canalização por onde as informações fluem.

Eles são representados por flechas direcionadas no sentido do fluxo das informações e desenhadas,

de preferência, horizontal ou verticalmente. Dependendo do caso, pode-se usar uma flecha

direcionada nos dois sentidos, se assim for conveniente (normalmente isso acontece quando se

trata de uma atualização num centro de informações). Os fluxos são referenciados por suas

respectivas origem e destinos, nas além disso, devem receber um nome, o mais significativo

possível, para que os diagramas sejam facilmente entendidos pelos usuários.

a

Cliente

1.1

Preenche

proposta e

ficha de

controle /

emissão

Dados para preenchimento da

proposta

11

Salienta-se que, muitas vezes, um fluxo recebe um nome mais abrangente, mas,

geralmente, fluem pelo mesmo vários tipos de dados ou vice-versa, um fluxo recebe um nome bem

detalhado, mas não necessariamente fluem por ele todos os dados ao mesmo tempo.

9.2

Envie

documentação

ao Recursos

Humanos

D

9/4

Documentos

Enviar Documentação

4.4. Processos

São as várias atividades realizadas no sistema. São representado graficamente por um

retângulo de bordas arredondadas, opcionalmente dividido em três áreas.

Identificação

Descrição

Localização Física

Nos processos têm-se as seguintes atividades.

a) 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;

b) 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”;

c) Localização Física: é o nome da unidade organizacional responsável pela atividade, no caso de

o sistemas ser implementado.

4.5.Banco de Informações

São os “armazéns” que guardam dados e informações entre os vários processos são

representados graficamente por um par de linhas paralelas, fechadas apenas de um lado por duas

outras linhas, bem próxima perpendiculares às primeiras, formando, portanto, um pequeno

quadrado do lado esquerdo. Nesse quadrado coloca-se uma referência numérica arbitrária para o

12

depósito, antecedida pela letra “D” e, no espaço restante, coloca-se o nome atribuído ao banco de

informações, que dever ser aquele usado no dia-a-dia do usuário.

Exemplo:

D9/4

Agenda de Controle de

Vencimentos

5.Convenções para Explosão de Processos

Existem algumas convenções que devem ser seguidas na elaboração dessas explosões de processo.

a) os processos do diagrama detalhado devem receber como identificação um número que seja um

decimal do número do processo que está sendo explodido. Exemplo: os processos do diagrama

detalhado referentes à explosão do processo 2 do diagrama geral recebem como identificação os

números; 2,1,2.2,2.3,etc... Da mesma forma, se estes forem detalhados, os processos devem ser

identificados por 2,1.1,2.1.2,2.2.1, e assim sucessivamente.

b) o diagrama detalhado é desenhada dentro de uma retângulo grande, com a forma do símbolo

dos processos, determinado, desse modo, uma linha que delimita os processos da

decomposição. Os fluxos que entram e saem do processo no nível mais alto também devem

cruzar a linha-limite, entrando ou saindo. Os fluxos que cruzam a linha-limite do diagrama

detalhado e que não aparecem no diagrama geral, ao cruzar essa linha, devem ser assinalados

com um “X” no ponto de intersecção.

c) os depósitos de dados e informações são externos ao processos expandido, isto é, aparecem no

diagrama geral usados por outros processos; podem eventualmente aparecer no fluxo detalhado,

metade fora e metade dentro da linha-limite, se isso facilitar o desenho.

d) os depósitos de dados e informações internos a um processo aparecem apenas no diagrama

detalhado, desenhados internamente do lado de dentro da linh-limite, e seus números de

identificação dever ser atribuídos da seguinte maneira: a letra “D” seguida do número do

processo do diagrama geral, uma barra “/” e depois um dígito. Exemplo: pode-se ter deposito

“D3/3 - Arq. de relação X”.

e) as entidades externas não devem, de modo algum, aparecer desenhados no interior da linhalimite

do diagrama detalhado.

13