Programacao_Estruturada

8/2/2019 Programacao_Estruturada

1/24

O Site da EletrnicaProgramao Extruturada

1. PROGRAMAO ESTRUTURADA 31. PROGRAMAO ESTRUTURADA

11..11 -- DDEEFFIINNIIEESS 311..22 -- OOBBJJEETTIIVVOOSS 311..33 -- PPRROOPPRRIIEEDDAADDEESS 311..44 -- EESSTTRRUUTTUURRAASSBBSSIICCAASS DDEECCOONNTTRROOLLEE 411..55 -- FFOORRMMAATTOOPPAADDRROONNIIZZAADDOO DDOOMMDDUULLOO 411..66 -- EESSTTRRUUTTUURRAA DDEECCOONNTTRROOLLEE DDOOPPRROOGGRRAAMMAA 5

11..66..11 -- RREEGGRRAASS PPAARRAA OOFFLLUUXXOO DDEECCOONNTTRROOLLEE DDOOPPRROOGGRRAAMMAA EEMM UUMMPPRROOGGRRAAMMAAEESSTTRRUUTTUURRAADDOO 511..77 -- DDOOCCUUMMEENNTTAAOO 5

2. PROGRAMAO MODULAR 62. PROGRAMAO MODULAR

22..11 -- DDIIVVIIDDIIRR--PPAARRAA--CCOONNQQUUIISSTTAARR 622..22 VVAANNTTAAGGEENNSS DDAAPPRROOGGRRAAMMAAOOMMOODDUULLAARR 622..33 -- EESSQQUUEEMMAASS DDEEMMOODDUULLAARRIIZZAAOO 722..33..11 TTAAMMAANNHHOO DDOOMMDDUULLOO 7

3. PROGRAMAO POR REFINAMENTO SUCESSIVO (STEPWISE REFINEMENT) 83. PROGRAMAO POR REFINAMENTO SUCESSIVO (STEPWISE REFINEMENT)

33..11 -- DDEEFFIINNIIOO 833..22 -- CCAARRAACCTTEERRSSTTIICCAASS DDOORREEFFIINNAAMMEENNTTOO 8

4. TOP-DOWN E BOTTOM-UP 94. TOP-DOWN E BOTTOM-UP

44..11-- MMEETTOODDOOLLOOGGIIAASS DDEEPPRROOGGRRAAMMAAOOEESSTTRRUUTTUURRAADDAA 944..22 -- PPRROOGGRRAAMMAAOOTTOOPP--DDOOWWNN 944..22..11 -- VVAANNTTAAGGEENNSS 1044..22..22 -- EETTAAPPAASS DDAAPPRROOGGRRAAMMAAOOTTOOPP--DDOOWWNN 10

44..22..33 -- PPRRIINNCCPPIIOOSSBBSSIICCOOSS DDAAPPRROOGGRRAAMMAAOOTTOOPP--DDOOWW 1044..33 -- PPRROOGGRRAAMMAAOOBBOOTTTTOOMM--UUPP VVEERRSSUUSSPPRROOGGRRAAMMAAOOTTOOPP--DDOOWWNN 1044..44 -- PPRROOGGRRAAMMAAOOBBOOTTTTOOMM--UUPP 1144..44..11 -- EETTAAPPAASS DDAAPPRROOGGRRAAMMAAOOBBOOTTTTOOMM--UUPP 1144..44..22.. -- CCAARRAACCTTEERRSSTTIICCAASS DDOO PPRROOCCEESSSSOO DDEE CCOONNCCAATTEENNAAOO 11

5. DIAGRAMAS ESTRUTURADOS 125. DIAGRAMAS ESTRUTURADOS

55..11 -- IINNTTRROODDUUOO 1255..22 -- FFUUNNEESS DDOOSSDDIIAAGGRRAAMMAASSEESSTTRRUUTTUURRAADDOOSS 12

55..33 -- CCAA

TT

EE

GG

OO

RR

IIAA

SS

DD

EE

DDIIAA

GG

RR

AA

MM

AA

SS

EESS

TT

RR

UU

TT

UU

RR

AA

DD

OO

SS

1255..44 -- CCLLAASSSSIIFFIICCAAOO DDAASSTTCCNNIICCAASS DDEEDDIIAAGGRRAAMMAAOO 13

http://www.li.facens.br/eletronica1

1


2/24


6. DIAGRAMAS DE NASSI-SHNEIDERMAN 146. DIAGRAMAS DE NASSI-SHNEIDERMAN

66..11 -- IINNTTRROODDUUOO 1466..22 -- EESSTTRRUUTTUURRAASSBBSSIICCAASS DDEECCOONNTTRROOLLEE 1466..33 -- EEXXEEMMPPLLOO DDEE UUMM DDIIAAGGRRAAMMAANN--SS 16

66..44 -- CCRRTTIICCAA AAOODDIIAAGGRRAAMMAA DDEENNAASSSSII--SSHHNNEEIIDDEERRMMAANN 17

7. DIAGRAMA DE FLUXO DE DADOS 187. DIAGRAMA DE FLUXO DE DADOS

77..11 -- IINNTTRROODDUUOO 1877..22 -- CCOOMMPPOONNEENNTTEESS DDEE UUMMDDFFDD 1877..33 NNIIVVEELLAAMMEENNTTOO DDEE UUMMDDFFDD 2077..44 EESSPPEECCIIFFIICCAAOO DDEEPPRROOCCEESSSSOO EEDDIICCIIOONNRRIIOO DDEEDDAADDOOSS 2277..55 -- CCRRTTIICCAASS AAOODDFFDD 23

8. NOTAO DE GANE E SARSON 248. NOTAO DE GANE E SARSON

88..11 IINNTTRROODDUUOO 24


2


3/24


11.. PPrrooggrraammaaoo EEssttrruuttuurraaddaa

11..11 DDeeffiinniieess

No existe uma definio universalmente aceita para a programao estruturada; aocontrrio, existem vrias escolas de pensamento que a conceituam.

No sentido mais restrito, o conceito de programao estruturada diz respeito forma doprograma e do processo de codificao. um conjunto de convenes que o programador podeseguir para produzir o cdigo estruturado. As regras de codificao impem limitaes sobre ouso das estruturas bsicas de controle, estruturas de composio modular e documentao. Comeste sentido, a programao estruturada enfoca os seguintes tpicos:

Programao sem GO TO (eliminao completa ou parcial do comando GO TO) Programao com apenas trs estruturas bsicas de controle:

seqncia, seleo e iterao Forma de um programa estruturado Aplicao de convenes de codificao estruturada a uma linguagem de programao

especfica

Em um sentido mais amplo, a programao estruturada dirigida tanto aos mtodos deprogramao como forma do programa. Implica seguir uma metodologia estruturada paraorganizar o projeto e a implantao do programa. Os tpicos envolvidos incluem:

Programao modular Refinamento gradual (stepwise refinement)

Nveis de abstrao Programao top-down e bottom-up

11..22 OObbjjeettiivvoossO principal objetivo da programao estruturada produzir um programa de alta

qualidade a baixo custo, proporcionando uma disciplina de programao para conseguir: Melhorar a confiabilidade do programa Aumentar a legibilidade do programa

Minimizar a complexidade do programa Simplificar a manuteno do programa Aumentar a produtividade do programador Estabelecer uma metodologia disciplinada de programao

11..33 PPrroopprriieeddaaddeessAs caractersticas mais notveis de um programa estruturado so sua forma

hierarquizada e o conjunto reduzido de suas estruturas bsicas de controle. Alm dessas,tambm so consideradas propriedades igualmente importantes, a estrutura de controle

padronizada, os requisitos de programao e as convenes de estilo. A seguir, um resumo daspropriedades de um programa estruturado.


3


4/24


PPrroopprriieeddaaddee 11 - o programa dividido em um conjunto de mdulos dispostos em umahierarquia que define suas relaes lgicas e de tempo de execuo.

PPrroopprriieeddaaddee 22 - o fluxo de execuo de mdulo para mdulo restringe-se a um esquemasimples, fcil de entender, no qual o controle deve ser passado para o

mdulo em seu nico ponto de entrada, sair do mdulo de seu nico pontode sada e retornar sempre ao mdulo que o chamou.

PPrroopprriieeddaaddee 33 - a construo do mdulo padronizada de acordo com as regras tradicionaisde modularizao, e as estruturas bsicas de controle so limitadas aseqncia, seleo, iterao e desvio.

PPrroopprriieeddaaddee 44 - requerida a documentao relativa ao cdigo fonte, para descrever a funodo programa como um todo e descrever, para cada mdulo, sua funo, suaestrutura de dados e sua relao com outros mdulos do programa.

11..44 EEssttrruuttuurraass BBssiiccaass ddee CCoonnttrroollee

As trs estruturas bsicas de controle para a construo de programas estruturados :SSeeqqnncciiaa - usada para controlar a execuo do programa, os comandos so executados na

mesma ordem em que aparecem no cdigo fonte.

As estruturas de seleo, iterao e desvio so usadas para alterar o fluxo de execuodo programa de sua ordem seqencial normal.SSeelleeoo - usada para testar uma condio e, ento, dependendo de ser o teste verdadeiro ou

falso, um dos dois conjuntos alternativos de instrues executado.

IItteerraaoo - usada para executar um conjunto de instrues em um nmero inteiro de vezes -isto , para construir um lao (loop). Deve-se observar que existem duas formas

bsicas para a estrutura de iterao: DO UNTIL e WHILE.

11..55 FFoorrmmaattoo PPaaddrroonniizzaaddoo ddoo MMdduullooUm programa estruturado um programa modular. Porm, em um programa estruturado

o mdulo, alm de seguir as regras bsicas de modularizao, tem sua forma mais limitada. A

imposio de regras de formato rigorosas para a construo de um mdulo estruturado umoutro meio de simplificar a estrutura do programa. Elas permitem que o programador concentresua ateno no contedo e no na forma do programa.

As regras para a construo de um mdulo estruturado so as seguintes: Um mdulo tem um nico ponto de entrada e um nico ponto de sada. Um mdulo uma estrutura completa - executa uma nica tarefa lgica no programa

e limitado pelo seu ponto de entrada e seu ponto de sada. As estruturas bsicas de controle legais restringem-se seqncia, seleo

(admitindo-se extenses), iterao e desvio para o ponto de sada do mdulo.


4


5/24


11..66 -- EEssttrruuttuurraa ddee CCoonnttrroollee ddoo PPrrooggrraammaa

Existe uma relao de chamada entre dois mdulos, A e B, em um programaestruturado, se o mdulo A requisita o mdulo B para executar sua funo.Do ponto de vista da estrutura do controle do programa, isto significa que o mdulo A

chama o mdulo B. Quando o mdulo A chama o mdulo B, o controle do programa passadodo A para o B, o cdigo do B ento executado e quando este completa sua execuo, passa ocontrole de volta ao mdulo A.

O mdulo A (mdulo chamador) denominadopaido mdulo B (mdulo chamado) e omdulo B denominado filho do mdulo A. Em um programa estruturado, a relao dechamada entre dois mdulos s funciona em uma direo; isto , se o mdulo A chama omdulo B, o mdulo B no pode chamar o mdulo A, direta ou indiretamente, atravs de umfilho ou neto. Alm disso, um mdulo no pode chamar a si prprio. Estas relaes no so

permitidas porque no podem ser implantadas facilmente em muitas linguagens de programaoe porque tendem a aumentar a complexidade do programa.

11..66..11 -- RReeggrraass ppaarraa oo FFlluuxxoo ddee CCoonnttrroollee ddoo PPrrooggrraammaa eemm uumm PPrrooggrraammaa EEssttrruuttuurraaddoo

Existe um e somente um mdulo raiz, em um programa estruturado. A execuo do programa deve comear com o mdulo raiz. Somente um pai pode chamar um filho. Um filho no pode chamar seu pai, nem um

mdulo pode chamar a si prprio. O controle do programa deve ser passado para um mdulo em seu ponto de entrada e

deve sair do mdulo em seu ponto de sada. O controle retorna sempre ao mdulo chamador, quando o mdulo chamado

completa a execuo.

OOBBSSEERRVVAAOO: estas regras no se aplicam a linguagem C. Em C permitido queo mdulo filho chame ao mdulo pai ou que um mdulo chame a si mesmo.

O menor programa estruturado consiste apenas em um mdulo raiz. Outros programaspodem conter um mdulo raiz e um ou mais filhos. Com exceo do mdulo raiz, todos osmdulos devem ter pelo menos um pai. Se um mdulo tem mltiplos pais chamado de mdulocomum. Qualquer mdulo, incluindo o mdulo raiz, pode ter zero, ou mltiplos filhos. Um

mdulo sem filhos chamado de folha. Todo ramo em uma hierarquia modular deve terminarcom um mdulo folha.

11..77 -- DDooccuummeennttaaooA documentao uma parte essencial de um programa bem-estruturado. Ela dirigida

a trs nveis de compreenso do programa: Global Organizao do programa Instruo do programa

Cada nvel sucessivo fornece uma viso mais detalhada do programa e todos os trsnveis so necessrios para a sua compreenso e manuteno.


5


6/24


22.. PPrrooggrraammaaoo MMoodduullaarr

22..11 -- DDiivviiddiirr--ppaarraa--CCoonnqquuiissttaarr

A programao estruturada tem sua origem na programao modular. Grande parte dafilosofia estruturada construda sobre a filosofia de modularizao de dividir-para-conquistar.A programao modular utiliza essa filosofia para resolver o problema da complexidade do

programa. Quando um programa dividido em partes independentes, fceis de serementendidas, sua complexidade pode ser grandemente reduzida. A filosofia estruturada utilizadividir-para-conquistar e amplia a filosofia de modularizao acrescentando os importantesconceitos de organizao hierrquica e nveis de abstrao para controlar as relaesintermodulares.

A programao modularpode ser definida como a organizao de um programa em

unidades independentes, chamadas mdulos, cujo comportamento controlado por um conjuntode regras. Suas metas so as seguintes:

Decompor um programa em partes independentes Dividir um problema complexo em problemas menores e mais simples Verificar a correo de um mdulo de programa, independentemente de sua

utilizao como uma unidade em um sistema maior

A modularizao pode ser aplicada em diferentes nveis. Pode ser usada para separar umproblema em sistemas, um sistema em programas e um programa em mdulos.

22..22 VVaannttaaggeennss ddaa PPrrooggrraammaaoo MMoodduullaarr

Os programas modulares so mais fceis de entender, porque a anlise do programapode ser feita atravs da anlise dos mdulos, um de cada vez.

O teste do programa mais simples. Os erros do programa so mais fceis de serem isolados e corrigidos. As mudanas no programa podem ser limitadas a apenas alguns mdulos, em vez de

percutirem pela maior parte do cdigo do programa. Pode-se aumentar mais facilmente a eficincia do programa. Os mdulos do programa podem ser reutilizados como blocos de construo de

outros programas. O tempo de desenvolvimento do programa pode ser diminudo, porque diferentes

mdulos podem ser designados a diferentes programadores, que podem trabalharcom maior ou menor independncia.


6


7/24


22..33 -- EEssqquueemmaass ddee MMoodduullaarriizzaaoo

Dividir um programa em mdulos pode ser um meio muito eficaz de controlar acomplexidade. O problema que surge quanto melhor forma de dividir o programa. Mesmo

para um programa simples, existem inmeras maneiras de dividi-lo em um conjunto de mdulosestruturados. A maneira escolhida pode afetar significativamente a complexidade do programa.Por exemplo, definir mdulos grandes demais ou pequenos demais aumenta a complexidade, oscustos e a probabilidade de erros no programa.

A forma de dividir um programa em mdulos chamada de seu esquema demodularizao. Um grande objetivo da programao modular definir um bom esquema demodularizao (aquele que reflita rigorosamente os componentes do problema a ser

programado, minimize a complexidade e possa ser fcil e eficazmente implantado).

22..33..11 TTaammaannhhoo ddoo MMdduullooPara ajudar o projetista de programa na escolha de um bom esquema de modularizao,

tm sido desenvolvidas diretrizes relativas ao tamanho do mdulo. A IBM, por exemplo,recomenda que se definam mdulos com, no mximo, 50 linhas de cdigo de programa ou auma pgina de listagem do programa fonte (uma tela de vdeo), pois permite que o leitor veja, e

portanto compreenda, todo o cdigo de uma s vez.Um nmero semelhante surge de Weinberg, cujos trabalhos demonstram que mdulos

que possuem mais de 30 instrues de programao so difceis de entender.De uma maneira geral, o tamanho do mdulo deve estar compreendido entre 10 e 100

instrues. Mdulos com mais de 100 instrues so mais dispendiosos em relao a testes e

manutenes, enquanto mdulos com menos de 10 instrues podem dividir o programa emmuitas partes, afetando desfavoravelmente a eficcia do programa.


7


8/24


33.. PPrrooggrraammaaoo ppoorrRReeffiinnaammeennttoo SSuucceessssiivvoo((SSTTEEPPWWIISSEERREEFFIINNEEMMEENNTT))

33..11 -- DDeeffiinniioo a maneira de desenvolver um programa executando uma seqncia de etapas de

refinamento. O processo comea com a definio dos dados e tarefas procedurais bsicas, pararesolver o problema de programao. Esta definio inicial feita em nvel bem alto e geral. O

processo pra quando todas as tarefas do programa so expressas em uma forma que diretamente traduzvel na(s) linguagem(ns) de programao.

A cada etapa de refinamento, uma ou vrias tarefas so decompostas em subtarefas maisdetalhadas. A definio de uma subtarefa freqentemente acompanhada por um refinamentoda definio dos dados necessrios para as tarefas de interface. Por esta razo o refinamento detarefa e o refinamento de dados so executados em paralelo.

33..22 -- CCaarraacctteerrssttiiccaass ddoo RReeffiinnaammeennttoo O processo avana em etapas explcitas. A cada etapa, um conjunto de tarefas e estruturas de dados apresentado. O

programa, tal como foi desenvolvido at este ponto, definido em termos desteconjunto.

O conjunto de tarefas e estruturas de dados usado em uma etapa define, com maiordetalhe, o conjunto que foi apresentado na etapa de refinamento anterior.

A notao usada para definir as tarefas e estruturas de dados geral, porm vaitornando-se mais detalhada e mais semelhante linguagem de programao real, medida que o processo de refinamento completa-se.

As etapas de refinamento so o produto das decises de projeto do programa,envolvendo uma definio adicional das partes funcionais do programa e suasestruturas de dados.

Quo bem as decises do projeto de programa forem tomadas, to bem o programa serestruturado em mdulos fceis de serem entendidos e de serem modificados.


8


9/24


44.. TTOOPP--DDOOWWNNee BBOOTTTTOOMM--UUPP

44..11 -- MMeettooddoollooggiiaass ddee PPrrooggrraammaaoo EEssttrruuttuurraaddaa

Os programas podem ser desenvolvidos de cima para baixo ou de baixo para cima. Tantoum como outro so adaptaes da programao por refinamento sucessivo.

Quando um sistema construdo de baixo para cima, o projetista primeiro cria oscomponentes, faz cada um deles funcionar bem e, ento agrupa os componentes.

Quando um projetista trabalha de cima para baixo, primeiramente cria a estrutura global,definindo os componentes. medida que o projeto vai progredindo, ele completa os detalhes,construindo os componentes de nveis inferiores.

Em projetos complexos, comumente requerida uma combinao de projetos top-down e

bottom-up.

44..22 -- PPrrooggrraammaaoo TToopp--DDoowwnn

um mtodo organizado de projetar, codificar e testar um programa em etapasprogressivas. O mtodo baseado na programao por refinamento sucessivo.

A programao top-down produz um programa modular, estruturado hierarquicamente.O mdulo de nvel mais alto na hierarquia representa a funo global do programa. Os mdulos

dos nveis inferiores representam subfunes que definem as tarefas do programa com maioresdetalhes.Na programao top-down, a ordem das etapas de projeto, codificao e teste diferente

daquela do desenvolvimento tradicional de programa. No desenvolvimento tradicional,primeiramente o programa inteiro projetado, depois codificado e, finalmente, testado. Astrs etapas so executadas separada e seqencialmente, chamada de abordagem por fases ouabordagem tudo-em-um. No desenvolvimento top-down, ao contrrio, as trs etapas soexecutadas em paralelo, chamada de abordagem incremental ou abordagem passo a passo.Primeiramente, um mdulo projetado, codificado e testado. Depois, um outro mdulo

projetado, codificado e testado, e assim por diante, at terminarem todos os mdulos doprograma. Como parte da etapa de teste, cada mdulo recentemente codificado combinado e

testado com todos os mdulos concludos at aquele ponto. O programa cresce gradualmente,um mdulo por vez. A integrao realizada em etapas e no em grandes blocos no final do

projeto, como acontece na abordagem por fases.Na prtica, a abordagem tradicional por fases no tem tido muito xito. Tende a adiar a

descoberta de problemas graves at uma fase bem avanada do projeto. Esta situao revela-seem estouros de cronogramas e oramentos e em graves problemas de testes de integrao.Como conseqncia, a fase de testes a fase mais mal executada e a que mais foge do esquema

planejado. Alm disso, os problemas provavelmente continuaro na fase de manuteno,transformando o programa em um custoso pesadelo a ser mantido.


9


10/24


44..22..11 -- VVaannttaaggeennss

A abordagem top-down pode evitar muitos destes problemas. Tem a vantagem de iniciaros testes mais cedo, no processo de desenvolvimento. Desta forma os problemas de integrao

podem ser descobertos e corrigidos antes e a um custo mais baixo.

Uma segunda vantagem que existe um esqueleto do programa desde as primeirasetapas de desenvolvimento, fornecendo ao usurio uma verso parcial do programa bem antesde sua concluso.

44..22..22 -- EEttaappaass ddaa PPrrooggrraammaaoo TToopp--DDoowwnn

O desenvolvimento top-down do programa segue a estrutura lgica do programa,iniciando-se com o mdulo de nvel mais alto e continuando, em etapas bem organizadas, at os

mdulos de nvel mais baixo. As etapas so as seguintes:

EEttaappaa ll - comea com uma anlise do problema e, ento, prope um plano de abordagem,definido como a estrutura geral do programa. Representa a soluo como um esboo queidentifica o processamento e os componentes de dados gerais do programa. Neste ponto, oscontedos dos componentes no so definidos em detalhes. O esboo obtido dividindo-se o

problema em partes lgicas que refletem as tarefas funcionais que o programa deve executarpara realizar seu objetivo (por exemplo, calcular o pagamento bruto, selecionar o formato datela).

EEttaappaa 22--nn - em etapas, expande o esboo do programa chegando ao programa completo. O

processo de expanso segue as regras do processo de refinamento. Os componentes doprograma so refinados em subcomponentes (stubs tocos), os quais so tambm refinados, eassim por diante. O processo terminar quando o programa puder ser escrito como um conjuntode componentes diretamente representveis na linguagem de programao.

44..22..33 -- PPrriinnccppiiooss BBssiiccooss ddaa PPrrooggrraammaaoo TToopp--DDooww

As decises de projeto devem ser feitas de tal forma que dividiro o problema em

partes cujos componentes estaro relacionados a ele. Os detalhes de implantao no devem ser considerados at o processo dedesenvolvimento estar avanado, mas em cada etapa devem ser exploradasalternativas.

As etapas de refinamento devem ser simples e explcitas.

44..33 -- PPrrooggrraammaaoo BBoottttoomm--UUpp vveerrssuuss PPrrooggrraammaaoo TToopp--DDoowwnn

Embora a programao top-down seja geralmente considerada como o melhor mtodo

de desenvolver um programa estruturado, a programao bottom-up , s vezes, uma alternativavivel. Ambos os mtodos compartilham os mesmos objetivos:


10


11/24


sistematizar o processo de programao fornecer uma estrutura para a resoluo do problema produzir um programa modular

Ambas so compatveis com a metodologia de programao estruturada. Contudo,

abordam o desenvolvimento de programa de maneiras opostas. Na programao top-down, atcnica de construo usada no desenvolvimento de programa a decomposio - o sentido dodesenvolvimento de uma soluo abstrata e de alto nvel para o ambiente de programao real.

Na programao bottom-up, o caminho de desenvolvimento seguido oposto. Oprograma construdo pela combinao de componentes simples, atmicos, para formarcomponentes mais abstratos e de nvel mais alto. Esta tcnica de construo a concatenao.

44..44 -- PPrrooggrraammaaoo BBoottttoomm--UUpp

A programao bottom-up desenvolve o programa em etapas. Assim como em top-down, o processo pode ser dividido em duas partes. Primeiramente, proposta uma soluoinicial para o programa e depois, so desenvolvidos os componentes que tratam dos detalhes.

44..44..11 -- EEttaappaass ddaa PPrrooggrraammaaoo BBoottttoomm--UUpp

EEttaappaa 11 - comea com um esboo do programa proposto. Este esboo contm os componentesgerais do programa - componentes funcionais e de dados.

EEttaappaa 22--nn - em etapas explcitas, desenvolve o programa combinando os componentes de nvelmais baixo para formar componentes de nvel mais alto. Este processo chamado deconcatenao. Esse processo terminar quando for construdo a partir de elementos disponveisno ambiente de programao real, um conjunto de funes e estruturas de dados do programa,capazes de resolver o problema de programao. Acionadores de testes so usados pararepresentar os mdulos de nvel mais alto que sero desenvolvidos em etapas posteriores.

44..44..22.. -- CCaarraacctteerrssttiiccaass ddoo pprroocceessssoo ddee ccoonnccaatteennaaoo

O processo prossegue em etapas explcitas. A cada etapa, construda uma mquina. Os componentes desta mquina so

formados a partir dos componentes da mquina desenvolvida durante a etapa deconcatenao anterior.

Cada etapa o resultado de uma deciso de combinar alguns componentes damquina anterior.

Na prtica, o processo de concatenao, de maneira anloga ao processo de refinamento,no um procedimento de um passo. Erros e omisses podem forar a repetio de parte do

processo ou de todo o processo.


11


12/24


55.. DDiiaaggrraammaass EEssttrruuttuurraaddooss

55..11 -- IInnttrroodduuooAs tcnicas de diagramao estruturada oferecem muitas vantagens. Combinam

notaes grficas com narrativas, para aumentar a compreenso. Os grficos soparticularmente teis porque tendem a ser menos ambguos do que a descrio narrativa. Almdisso os grficos, porque tendem a ser mais resumidos, podem ser desenhados em um tempo

bem menor do que poderia ser gasto para escrever um documento narrativo contendo a mesmaquantidade de informao.

As tcnicas de diagramao estruturada apoiam uma abordagem de desenvolvimento

top-down e estruturado. Podem descrever um sistema ou programa com vrios graus dedetalhes, durante cada etapa do processo de decomposio funcional. Tornam claras as etapas eos resultados do processo de decomposio funcional, ao fornecerem um modo padronizado dedescrever a lgica dos procedimentos e as estruturas de dados.

55..22 -- FFuunneess ddooss DDiiaaggrraammaass EEssttrruuttuurraaddooss Contribuir para a clareza de pensamento Possibilitar uma comunicao precisa entre os membros da equipe de

desenvolvimento Facilitar a definio de interfaces padres entre mdulos Impor uma boa estruturao Ajudar a depurao Ajudar a efetuar mudanas nos sistemas (manuteno) Acelerar o desenvolvimento (com diagramao apoiada por computador) Impor preciso nas especificaes Integrar as ferramentas de administrao de dados Fornecer condies aos usurios finais para esboar suas necessidades com clareza Integrar a checagem automtica com a gerao de cdigo

55..33 -- CCaatteeggoorriiaass ddee DDiiaaggrraammaass EEssttrruuttuurraaddooss

Os diagramas so usados em vrias reas:MMooddeelloo gglloobbaall ddaa eemmpprreessaa - as funes e processos de uma empresa so decompostashierarquicamente.AAnnlliissee ddee ssiisstteemmaa gglloobbaall o fluxo de dados global entre eventos e processos comerciais desenhado.PPrroojjeettoo ddee ssiisstteemmaa - a relaes entre os componentes de um sistema so desenhadas.

AArrqquuiitteettuurraa ddoo pprrooggrraammaa - a arquitetura global de um programa ou de um conjunto deprogramas desenhada, mostrando os mdulos independentes.


12


13/24


DDeettaallhhee ddoo pprrooggrraammaa - a lgica detalhada dentro de um mdulo de programa desenhada.MMooddeellooss ddee ddaaddooss - um modelo lgico global dos dados desenhado. importante aqui que sefaa a distino entre modelos de banco de dados e representao de arquivos.EEssttrruuttuurraass ddee ddaaddooss - as estruturas dos bancos de dados ou dos arquivos so desenhadas.EEssttrruuttuurraass ddee ddiillooggooss - as possveis seqncias das telas e interaes em um dilogo homem-

computador podem ser desenhadas.

55..44 -- CCllaassssiiffiiccaaoo ddaass TTccnniiccaass ddee DDiiaaggrraammaaoo

Tcnicas Sist. Global Arq. Programa Lg. Detalhada Estrut. Arq. Estrut. BDDFD XDecomp. Funcional XDiagr. Estrutura X XHipo X X XWarnier-Orr X X X X

Michael Jackson X XFluxograma XPseudocdigo X

Nassi-Shneiderman XDiagr. Ao X X X Xrvores de deciso X XTabelas de deciso XD. Estrut. Dados XEntidade-Rel. (E-R) XD. Naveg. Dados X X

Diagr. HOS X X X X


13


14/24


66.. DDiiaaggrraammaass ddee NNAASSSSII--SSHHNNEEIIDDEERRMMAANN

66..11 -- IInnttrroodduuoo

Os fluxogramas, no so tcnicas adequadas para descrever programas estruturados.Do uma viso no-estruturada do mundo e tendem a gerar programas com GO TOs, em vez de

programas hierarquicamente estruturados.I. Nassi e B. Shneiderman resolveram substituir o fluxograma tradicional por um

diagrama que apresenta uma viso hierrquica e estruturada da lgica do programa. (N. Chapinusa um tipo de diagrama semelhante, denominado por ele diagrama Chapin.)

Os diagramas de Nassi-Shneiderman (N-S) representam estruturas de programas quetm um ponto de entrada e um ponto de sada e so compostos pelas estruturas bsicas decontrole (seqncia, seleo e repetio). Enquanto difcil mostrar o embutimento e arecursividade com o fluxograma tradicional, fcil mostr-1os com um diagrama N-S e fcil,

tambm, converter um diagrama N-S em cdigo estruturado.Um diagrama N-S consiste em um retngulo que representa a lgica do mdulo do

programa. Pretende-se que este retngulo seja desenhado em uma pgina. Portanto ele deve ter,no mximo, cerca de 15 a 20 subdivises. Quando um diagrama N-S torna-se muito grande, assubfunes so separadas e desenhadas em um outro diagrama. Foi projetado para ser usadocom mtodos top-down e de refinamento gradual.

Para representar a lgica do processo, vrias estruturas so embutidas dentro doretngulo.No permitida uma instruo de desvio.

66..22 -- EEssttrruuttuurraass BBssiiccaass ddee CCoonnttrroollee

Cada estrutura bsica de controle usada em programao estruturada pode serrepresentada por um smbolo do diagrama de N-S.

SSeeqqnncciiaa - mostrada por uma pilha vertical de retngulos de processo:

Por exemplo, a Figura 6.1 descreve a seqncia de quatro processos : CHECAR NOMEE ENDEREO, CHECAR CEP NUMRICO, CHECAR TERMOS VLIDOS e CHECARPAGAMENTO.


14


15/24


SSeelleeoo - apresenta-se a seleo (IF-THEN-ELSE) dividindo-se o retngulo de processo em 5partes. A metade superior dividida em trs tringulos. O tringulo superior contm a condioa ser testada. Os tringulos inferiores indicam a parte verdadeira e a partefalsa do IF-THEN-ELSE. A metade inferior dividida em retngulo de processo verdadeiro e retngulo de

processofalso, p-1 e p-2, respectivamente.

C?V F

p-1 p-2

Por exemplo, na Figura 6.1, o ltimo teste de condio no diagrama a checagem doINDICADOR INVLIDO. Se o teste verdadeiro, o processo ESCREVER MENSAGENSERROS executado. Se o teste falso, nada feito, pois o processo falso nulo.

Observe que a estrutura de seleo pode ser embutida. Na Figura 2.1, o teste decondio para ERROS embutido no teste de condio para RENOVAO.

A estrutura de condio pode ser ampliada para a estrutura de casos, na qual umaseleo feita entre vrias opes mutuamente exclusivas, como se segue:

EXECUTE CASO 1 CASO1 2 n ou

i = 1 i = 2 .... i = n cond.1 cond.2 cond.n defaultp-1 p-2 .... p-n p-1 p-2 ... p-n p-d

RReeppeettiioo - indicada por uma estrutura REPETIR ENQUANTO ou uma estrutura REPETIRAT.

CONDIO REPETIR ENQUANTO PROCESSO

PROCESSO CONDIO REPETIR AT

do while do - until

Observe que na estruturaDO WHILEa condio testada em primeiro lugar; ento, se acondio for verdadeira, o processo executado. Na estrutura DO UNTIL, o processo executado em primeiro lugar; depois a condio testada.

Na Figura 6.1, a estrutura de repetio usada para indicar que o processo de validaoe processamento de uma assinatura executado uma vez para cada assinatura no arquivo detransaes.


15


16/24


66..33 -- EExxeemmpplloo ddee uumm ddiiaaggrraammaa NN--SS

VALIDAR ITEM ASS:

CHECAR FORMATO GERAL

ERROS?NO SIM

ESCREVER MENSAGEM ERRO

NOVA ASS?NO SIM

CHECAR NOME E ENDEREOCHECAR CEP NUMRICOCHECAR TERMOS VLIDOS

CHECAR PAGAMENTO

ERROS?NO SIM

POSICIONAR POSICIONARINDICADOR INDICADORVLIDO INVLIDO

RENOVAO?NO SIM

CHECAR TERMOS VLIDOSCHECAR PAGAMENTO

ERROS?NO SIM

POSICIONAR POSICIONARINDICADOR INDICADORVALIDO INVLIDO

CANCELAMENTO?NO SIM

POSICIONAR SINALIZADORCANCELAMENTO

INDICADOR INVLIDO ?NO SIM

ESCREVER MENSAGENSERROS

Figura 6.1 Exemplo de um diagrama N-S para validar assinaturas


16


17/24


66..44 -- CCrrttiiccaa aaoo DDiiaaggrraammaa ddee NNaassssii--SShhnneeiiddeerrmmaann

O diagrama de Nassi-Shneiderman uma tcnica de diagramao usadafundamentalmente para o projeto detalhado de programa. uma ferramenta fraca para mostrar a

estrutura hierrquica de controle, de alto nvel, para um programa. Embora ela possa mostrar oscomponentes procedurais bsicos, no apresenta as interfaces ligando estes componentes.

uma alternativa para os fluxogramas tradicionais de programas, diagramas HIPO epseudocdigos. Entre estas tcnicas, o diagrama N-S o mais fcil de ser lido e o mais fcil deser convertido em cdigo de programa. Contudo, apenas uma ferramenta para o projeto de

procedimento e no pode ser usado para projetar estruturas de dados. Embora sua leitura sejafcil, o seu desenho nem sempre o . O desenho de um diagrama N-S pode levar trs ou quatrovezes mais tempo para ser executado do que seu pseudocdigo correspondente.

Uma outra grande falha do diagrama N-S no ser orientado para banco de dados. Eleno se relaciona com um modelo de dados ou um dicionrio de dados.

Os diagramas de ao apresentam todas as informaes que esto no diagrama de Nassi-Shneiderman e so bem mais fceis de serem usados com editores estruturados. Vriasferramentas CASE usam diagramas de ao; nenhuma usa os diagramas de Nassi-Shneiderman.


17


18/24


77.. DDiiaaggrraammaa ddee FFlluuxxoo ddee DDaaddooss

77..11 -- IInnttrroodduuoo

Um diagrama de fluxo de dados (DFD) apresenta os processos e o fluxo de dados entreeles. Em alto nvel, usado para mostrar eventos de negcios e as transaes resultantes desseseventos. Em nvel mais baixo, usado para mostrar programas ou mdulos de programas e ofluxo de dados entre estas rotinas.

Um DFD usado como o primeiro passo em um projeto estruturado. Apresenta o fluxode dados global em um sistema ou programa. principalmente uma ferramenta de anlise desistemas, para desenhar os componentes procedurais bsicos e os dados que passam entre eles.

O diagrama de fluxo de dados mostra como o dado flui atravs de um sistema lgico,mas no d informao sobre controle ou seqncia.

77..22 -- CCoommppoonneenntteess ddee uumm DDFFDD

Um DFD uma representao em rede de um sistema que mostra os processos e asinterfaces de dados entre eles. O DFD construdo a partir de 4 componentes bsicos:

o fluxo de dados o processo o depsito de dados

os pontos terminais

FFlluuxxoo ddee DDaaddooss conduz o fluxo de informaes atravs dos processos de um sistema. Osentido do fluxo de dados indicado por uma seta. Na verdade, mostra como os processos sointerligados. Os dados so identificados por nomes escritos ao lado de sua flechacorrespondente; por exemplo:

PRODUTOS PEDIDOS

PPrroocceessssoo um componente procedural do sistema. Opera sobre (ou transforma) os dados. Por

exemplo, pode executar operaes aritmticas ou lgicas com os dados, para produziralgum(ns) resultado(s). Cada processo representado no DFD por um crculo ou um retngulocom os vrtices arredondados. O nome do processo escrito dentro do crculo. Deve ser usadoum nome significativo, para definir a operao executada pelo processo, por exemplo:

VALIDARCLIENTE


18


19/24


Nenhuma outra informao sobre o que faz o processo mostrada no DFD.Normalmente, os dados entram e saem de cada processo. Geralmente, existem mltiplos fluxosde dados entrando e saindo de um processo; por exemplo:

REGISTRO CLIENTE

PEDIDO VALIDAR PRODUTOS PEDIDOSCLIENTE

CLIENTE INVLIDO

DDeeppssiittoo ddee DDaaddooss representa um arquivo lgico. desenhado no DFD como um par delinhas paralelas (s vezes, fechadas em um dos lados). O nome do depsito de dados escritoentre as linhas; por exemplo:

ARQUIVO PRODUTOS ou ARQUIVO PRODUTOS

Cada depsito de dados ligado a um "retngulo" de processo por meio de um fluxo dedados. O sentido da seta do fluxo de dados mostra se os dados esto sendo lidos do depsito de

dados para o processo ou produzidos pelo processo e ento enviados para o depsito de dados.No exemplo mostrado a seguir, as informaes sobre erros so produzidas peloPROCEDIMENTO ERROS e gravadas no ARQUIVO ERROS:

PROCESSARERROS

INFORMAES SOBRE ERROS

ARQUIVO ERROS

PPoonnttoo TTeerrmmiinnaall - mostra a origem dos dados usados pelo sistema e o ltimo receptor de dadosproduzidos pelo sistema. A origem dos dados chamada de fonte e o receptor dos dados chamado de destino. Para representar um ponto terminal em um DFD, usado um retngulo(como mostrado) ou um quadrado duplo. Na verdade, os pontos terminais situam-se fora doDFD.

DEPTO. PEDIDOSVENDAS


19


20/24


77..33 NNiivveellaammeennttoo ddee uumm DDFFDD

Um DFD uma ferramenta para anlise top-down. Pode-se usar DFDs para fornecertanto uma viso em alto nvel como tambm vises detalhadas de um sistema ou programa. Oque acontece dentro de um dos retngulos do DFD pode ser mostrado com detalhes em umoutro DFD.A seguir um exemplo de um sistema de distribuio de vendas.

SISTEMA DISTRIBUIAO VENDAS

ARQUIVO PEDIDO CLIENTE

PEDIDO

PROCESSARACEITAO ARQUIVO ESTOQUEPEDIDO

PEDIDO ACEITO REGISTRO PEDIDO

PROCESSARCOMPLETARPEDIDO

ARQUIVO CLIENTE ARQUIVOCLIENTE

PRODUTOS PRODUTOSREGISTRO PEDIDOS PEDIDOS ENDEREOCLIENTE CLIENTE

PROCESSAR PROCESSARFATURAMENTO ENTREGA

PEDIDOINFORMAOFATURA VENDAS INFORMAO

ENTREGASARQUIVO FATURA ESTATSTICAS VENDAS

ARQUIVO ENTREGASQUANTIA DEVIDA

CONTAS A PAGAR

Figura 7.1 DFD do sistema de distribuio de vendas.


20


21/24


A Figura acima mostra a viso em alto nvel do processo aceitao de pedido. Ela nosindica que o processo aceitao de pedido um dos quatro processos do sistema de distribuiode vendas. Esta viso, porm, no nos fornece nenhuma informao detalhada sobre o processoe o fluxo de dados necessrios para registrar um pedido. Se necessitarmos de mais detalhes,

devemos olhar dentro do retngulo do processo para ver quais subprocessos esto contidos noPROCESSO ACEITAO DE PEDIDO.

ARQUIVO CLIENTE

ARQUIVO PEDIDO REGISTRO CLIENTE

PEDIDO VALIDARCLIENTE ARQUIVO PRODUTOS

REGISTROS PEDIDOCLIENTE REGISTRO

PRODUTO

CLIENTE CHECARINVALIDO DISPONIBILIDADE

PRODUTOPRODUTOINVLIDO INFORMAO

ENTREGAPRODUTO PRODUTO

PROCESSAR NOERROS DISPONVELARQUIVO CATEGORIA

INFORMAES PEDIDOSOBRE ERRO

PROCESSAR INFORMAOARQUIVO ERROS PEDIDOS

CATEGORIAPENDENTES

INFORMAO CRIAR

ENTREGA PEDIDOPRODUTO CLIENTE

PEDIDOINFORMAO CLIENTE

PEDIDO

PEDIDO ARQUIVO PEDIDOCONFIRMADO ACEITO

Figura 7.2 DFD do processo ACEITAO DE PEDIDO.


21


22/24


Podemos continuar a expandir nossa viso do sistema, olhando dentro de cada processo,at onde quisermos. Quo detalhada deve ser nossa viso? Uma regra prtica seria: continuarexpandindo os retngulos de processos, para criar DFDs detalhados, at as operaesexecutadas por cada processo poderem ser descritas em uma especificao de uma pgina.

A cada nvel, o DFD deve conter menos que 12 retngulos de processos,

preferivelmente, seis ou sete. DFDs maiores so um sinal de tentativa de mostrar muitosdetalhes, e so difceis de serem lidos.

Este processo de definir um sistema em uma maneira top-down chamado denivelamento de um DFD.

77..44 EEssppeecciiffiiccaaoo ddee PPrroocceessssoo ee DDiicciioonnrriioo ddee DDaaddooss

Quando um DFD desenvolvido durante a anlise estruturada, so desenvolvidos,

tambm,. especificaes de processo e dicionrio de dados, para darem informaes adicionaissobre o sistema.Uma especificao de processo criada para cada retngulo do DFD de nvel mias

baixo. Define como o fluxo de dados entra e sai do processo e quais operaes so executadascom os dados. Uma especificao de processo descrita com outras tcnicas. A seguir, umaverso em portugus estruturado do que acontece no retngulo rotulado VALIDAR CLIENTE,da Figura 2.

VALIDAR CLIENTEPARA CADA PEDIDO REALIZADO;

ENCONTRAR REGISTRO CLIENTE CORRESPONDENTE;SE CLIENTE ENCONTRADO

SE CRDITO CLIENTE BOA SITUAOREUNIR TODOS PEDIDOS PRODUTO PARA AQUELE CLIENTE;CRIAR REGISTRO PEDIDO_CLIENTE

CASO CONTRRIO (CLIENTE M SITUAO)ESCREVER MENSAGEM ERRO CLIENTE INVLIDO

FIMSE.CASO CONTRRIO (CLIENTE NOVO A SER ACRESCENTADO NO

ARQUIVO)CRIAR REGISTRO CLIENTE NOVO;REUNIR TODOS PEDIDOS PRODUTO PARAAQUELE CLIENTE;CRIAR REGISTRO PEDIDO CLIENTE

FIMSE.

O dicionrio de dados contm definies de todos os dados do DFD. Pode incluir,tambm, informao fsica sobre os dados, tais como dispositivos de armazenamento, e mtodosde acesso aos dados. O termo dicionrio de dados, usado em conjuno com a definio de umDFD, no o mesmo quando usado em conjuno com sistemas de gesto de banco de dados.A seguir, apresentado um exemplo


22


23/24


ARQUIVO CLIENTE = [registros de cliente]

Os colchetes [ ] indicam que neste exemploARQUIVO CLIENTE repeties de registros de cliente.

registro-cliente = nome-cliente + endereo-cliente + informao-pagamento + pedidos-pendentes + tipo-cli

O sinal + indica que neste exemplo um registro de cliente um item de dadocomposto formado por umaseqncia dos itens de dados relacionados acima.

tipo-cli = empr | indivduo

A barra | indica que tipo-cli uma empresa ou um indivduo.

77..55 -- CCrrttiiccaass aaoo DDFFDD

Os diagramas de fluxo de dados so uma ferramenta muito valiosa para traar fluxos dedocumentos e fluxos de dados em sistemas complexos. Algumas organizaes estendem seu uso

para a estruturao interna de programas. Este uso pode ser questionado, pois existem tcnicasmelhores.

DFDs so usados erroneamente em muitos casos. Especificaes grandes e complexasso criadas com a ajuda de tais diagramas, mas a tarefa de fazer a checagem cruzada de todas as

entradas e sadas de dados muitas vezes, no executada adequadamente.Muitos conjuntos de especificaes, a partir das quais os programadores codificam, tm

diagramas de fluxo de dados nos quais as entradas e sadas so inconsistentes. Aps o cdigoter sido escrito, muito dispendioso acertar a confuso resultante.

Os autores de diagramas de fluxo de dados declaram que quando desenham osdiagramas iniciais, diagramas em alto nvel, no podem ainda conhecer os detalhes que surgiroquando estiverem desenhando os diagramas subseqentes. verdade que os diagramas iniciaisso esboos, ainda sem detalhes e preciso. Contudo, quando o detalhe definido, ele deve serrefletido nos nveis mais altos, de forma que estes fiquem coerentes. Em outras palavras, o

projeto do detalhe deve nos induzir a mudar os demais nveis do diagrama.Com uma ferramenta computadorizada (CASE), isto pode ser feito automaticamente. As

entradas e sadas detalhadas das camadas de nveis mais baixos podem ser refletidas nascamadas de nveis mais altos. Porm, nem todas as ferramentas computadorizadas fazem isto.Elas so simplesmente apoios para o desenho, sem ligao com as desejadas checagens deintegridade.


23


24/24


88.. NNoottaaoo ddee GGaannee ee SSaarrssoonn

88..11 IInnttrroodduuoo

Gane e Sarson adotaram, para diagramas de fluxo de dados, convenes de diagramaoligeiramente diferentes daquelas tornadas populares por Yourdon e De Marco. Sob algunsaspectos, a notao de Gane e Sarson melhor. A figura a seguir apresenta um resumo dasduas.

Yourdon, De Marco e outros Gane e Sarson

Fluxo de dados

Processo que transforma osdados

Descrio doprocesso

Identificao

Descrio doProcesso

Localizao

Depsito de dados

IdentificaoOrigem ou destino de dadosexternos

Fluxo de materiais

Depsito de dados repetidos emum diagrama

N linhas para n repetiesOrigem ou destino de dadosexternos repetidos em umdiagrama

N linhas para n repeties

http://www.li.facens.br/eletronica 24

Documents

Programacao_Estruturada