A maior rede de estudos do Brasil

Grátis
Estruturas_de_Dados_e_Algoritmos_em_C.erivanildo- Blog - conhecimentovaleouro.blogspot.com by @viniciusf666

Pré-visualização | Página 39 de 50

de programação procedimental é enunciado da seguinte forma “decide os 
procedimentos que precisas e usa os melhores algoritmos possíveis”. Consiste na 
decomposição hierárquica da solução do problema, também designada de decomposição 
do topo para a base (Top-Down Decomposition), ou seja, implementa a estratégia do dividir 
para conquistar. A única maneira de lidar com um problema complexo consiste em 
decompô-lo num conjunto de problemas mais pequenos, cada um deles de resolução mais 
fácil que o problema original. Outra técnica que permite decompor a complexidade de um 
problema, em problemas mais pequenos que têm a particularidade de serem exactamente 
do mesmo tipo do problema original, é a construção de soluções recursivas. 
 
A estratégia da decomposição hierárquica é implementada através da definição de novas 
operações no âmbito da linguagem, ou seja, através da criação de subprogramas. No caso 
da linguagem Pascal temos dois tipos de subprogramas, que são o procedimento e a 
função. No caso da linguagem C, temos apenas a função generalizada que é um tipo de 
subprograma que combina as características apresentadas pelo procedimento e pela função. 
 
O subprograma pode ser visto como uma caixa preta, que recebe informação à entrada e 
que produz informação à saída, escondendo no entanto os detalhes da implementação da 
operação, ou seja, as acções que dentro do subprograma transformam a informação de 
entrada na informação de saída. Estas acções são invisíveis externamente e, portanto, não 
originam qualquer interacção com o exterior. Este conjunto de acções detalhadas, que 
representam a solução do problema, designa-se por algoritmo. Ao encapsulamento do 
algoritmo dentro de um subprograma, designa-se por abstracção procedimental. 
 
A abstracção procedimental permite fazer a separação entre o objectivo de um 
subprograma da sua implementação. Após a definição do subprograma, a nova operação é 
identificada por um nome e por uma lista de parâmetros de comunicação com o exterior. 
Do ponto de vista operacional, tudo o que o programador precisa de saber para utilizar o 
subprograma é o seu nome e a sua interface com o exterior, que deve estar bem 
documentada. O programador não precisa de conhecer a sua implementação, ou seja, o 
algoritmo utilizado. Daí que, as linguagens de alto nível providenciam facilidades para a 
passagem de informação, de e para os subprogramas, de maneira a estabelecer o fluxo dos 
dados através das subprogramas e por conseguinte, ao longo do programa. 
 
Uma questão essencial a ter em conta durante o desenvolvimento de um subprograma, é 
que ele deve ser implementado de forma a ser, se possível, completamente autónomo do 
ambiente externo onde vai ser utilizado, tornando-o versátil. Assim assegura-se que ele 
pode ser testado separadamente e, mais importante, que pode ser reutilizado noutro 
contexto. É portanto, uma nova operação que estende a operacionalidade da linguagem. 
Com a criação de subprogramas autónomos é possível criar bibliotecas de subprogramas 
que poderão ser reutilizados mais tarde noutros programas. 
 
Neste paradigma de programação, os subprogramas podem ser vistos como blocos que 
podem ser interligados para construir programas mais complexos, fazendo uma montagem 
do programa da base para o topo (Bottom-Up Assembly). Permitindo assim, validar a solução 
do problema de uma maneira controlada e integrar de um modo progressivo os diferentes 
subprogramas, avaliando possíveis soluções alternativas através de diferentes arranjos de 
subprogramas. 
3 CAPÍTULO 5 : MEMÓRIAS 
 
 
Assim, se potenciarmos ao máximo a reutilização de subprogramas, o esforço que é 
necessário despender para criar novos programas é menor do que implementá-los de raiz. 
No entanto, a autonomia de um subprograma está limitada ao facto de a estrutura de dados 
que o seu algoritmo manipula ser exterior ao subprograma. Pelo que, a utilização do 
subprograma tem que ter sempre em conta não só a lista de parâmetros de comunicação 
com o exterior, mas também a própria estrutura de dados para o qual foi desenvolvido. O 
que implica, que se um programa necessitar de uma estrutura de dados que mesmo sendo 
semelhante é implementada de forma diferente, então o subprograma tem de ser 
modificado antes de ser reutilizado. Assim a reutilização do subprograma com um mínimo 
de esforço pode estar comprometida. 
 
Por outro lado, ao longo dos anos, a ênfase na implementação do software dirigiu-se em 
direcção à organização de estruturas de dados cada vez mais complexas. Para estruturas de 
dados complexas não faz sentido implementar subprogramas de uma forma isolada, mas 
sim providenciar um conjunto de subprogramas que as manipulam e que permitem que as 
estruturas de dados sejam encaradas como um novo tipo de dados da linguagem. Um tipo 
de dados permite a declaração de variáveis desse tipo e tem associado um conjunto de 
operações permitidas sobre essas variáveis. 
 
Este paradigma de programação, a que se dá o nome de programação modular, é 
enunciado da seguinte forma “decide os módulos que precisas e decompõe o programa 
para que as estruturas de dados sejam encapsuladas nos módulos”. Nesta filosofia de 
programação já não escondemos apenas os algoritmos, mas também as estruturas de dados 
que são processadas pelos algoritmos. Ou seja, à abstracção procedimental acrescenta-se 
também a abstracção das estruturas de dados. Com a abstracção das estruturas de dados o 
programador concentra a sua atenção na operacionalidade das operações que processam as 
estruturas de dados, ou seja, na acção das operações sobre as estruturas de dados, em vez 
de se preocupar com os detalhes da implementação das operações. 
 
Portanto, o paradigma de programação modular consiste na decomposição do programa 
em estruturas autónomas interactivas, onde existe uma separação clara entre a definição do 
módulo, ou seja, a sua interface com o exterior e a respectiva implementação do módulo. 
Do ponto de vista operacional, tudo o que o programador precisa de saber para utilizar o 
módulo é o seu nome e a sua interface com o exterior, que deve estar bem documentada. 
O programador não precisa de conhecer a sua implementação, ou seja, a organização da 
estrutura de dados interna do módulo e os algoritmos utilizados pelas operações. 
 
Esta filosofia de programação permite a criação de estruturas de dados abstractas, uma vez 
que os detalhes da sua implementação estão escondidos, ou seja encapsulados no módulo. 
Permite também a sua protecção uma vez que não estão acessíveis a partir do exterior a 
não ser através das operações de processamento disponibilizadas pelo módulo. Permite 
ainda, a criação de operações virtuais, uma vez que se podem experimentar vários 
algoritmos alternativos de manipulação das estruturas de dados, através da criação de 
módulos de implementação alternativos, para a mesma interface. 
 
Os módulos são assim entidades mais autónomas do que os subprogramas e por 
conseguinte mais reutilizáveis. São blocos construtivos mais poderosos, tanto mais 
poderosos quanto a sua estrutura de dados for reconfigurável em função das necessidades 
da aplicação, ou seja, quanto mais abstracta for a estrutura de dados interna do módulo. A 
abstracção tem a vantagem de esconder completamente a implementação da estrutura de 
dados, protegendo-a assim de operações que não são fornecidas pelo módulo. 
 
PROGRAMAÇÃO ESTRUTURAS DE DADOS E ALGORITMOS EM C 4 
Logo, uma questão essencial a ter em conta durante o desenvolvimento de um módulo, é 
que ele deve ser implementado da forma mais abstracta possível, tornando-o assim 
genérico. Um módulo genérico é um módulo cuja estrutura de dados pode ser do tipo de 
dados determinado pelo programador, em função da aplicação onde o módulo vai ser 
utilizado, sem que ele tenha que modificar a implementação do módulo. Um módulo 
genérico assegura uma