universidade federal fluminense - ic.uff.br · gramação orientada a objetos e programação...
TRANSCRIPT
UNIVERSIDADE FEDERAL FLUMINENSEFABRICIO CÉSAR DE SOUSA BARBOSA
UM ESTUDO SOBRE PARADIGMAS DE PROGRAMAÇÃO: PROGRA-MAÇÃO PROCEDURAL, PROGRAMAÇÃO ORIENTADA A OBJETOS
E PROGRAMAÇÃO ORIENTADA A ASPECTOS
NITERÓI2010
FABRICIO CÉSAR DE SOUSA BARBOSA
UM ESTUDO SOBRE PARADIGMAS DE PROGRAMAÇÃO: PROGRA-MAÇÃO PROCEDURAL, PROGRAMAÇÃO ORIENTADA A OBJETOS
E PROGRAMAÇÃO ORIENTADA A ASPECTOS
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólo-
go em Sistemas de Computação.
Orientador:Cristiano Grijó Pitangui
NITERÓI2010
FABRICIO CÉSAR DE SOUSA BARBOSA
UM ESTUDO SOBRE PARADIGMAS DE PROGRAMAÇÃO: PROGRA-MAÇÃO PROCEDURAL, PROGRAMAÇÃO ORIENTADA A OBJETOS
E PROGRAMAÇÃO ORIENTADA A ASPECTOS
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólo-
go em Sistemas de Computação.
Niterói, ___ de _______________ de 2010.
Banca Examinadora:
_________________________________________
Prof. Cristiano Grijó Pitangui, Msc. – Orientador
UFRJ – Universidade Federal do Rio de Janeiro
_________________________________________
Prof. Leandro Soares de Sousa, Msc. – Avaliador
UFF - Universidade Federal Fluminense
Dedico este trabalho em primeiro lugar a
Deus, que sempre esteve iluminando o meu
caminho, aos meus pais Francisco e Josélia
e meus irmãos Fabio e João, que sempre
ofereceram apoio e incentivo aos meus estu-
dos.
AGRADECIMENTOS
A Deus, que sempre iluminou a minha cami-
nhada.
A meu Orientador Cristiano Grijó Pitangui
pelo estímulo e atenção que me concedeu
durante o curso.
Aos meus Tutores e Colegas de curso pelo
incentivo e troca de experiências.
Aos funcionários da Secretaria do Pólo de
São Fidélis pela atenção durante o curso.
Aos meus colegas de trabalho da UENF, Eli-
sael, Célio e Rita, bolsistas e estagiárias pelo
apoio e compreensão concedida durante o
curso.
Aos meus colegas de trabalho da Biblioteca
da FDC pelo apoio e compreensão concedida
durante o curso.
Aos meus amigos Daniélly, Carlos Antônio,
Davi Marcos e Maycon Douglas pelo apoio e
colaboração concedida durante o curso.
A todos que, direta ou indiretamente, contri-
buíram pelo fechamento dessa jornada.
“Quem conhece a sua ignorância revela a
mais profunda sapiência. Quem ignora a sua
ignorância vive na mais profunda ilusão.”
Lao-Tsé
RESUMO
O presente trabalho monográfico visa discutir sobre as várias técnicas de programa-ção existentes, de forma padronizada, denominada de paradigmas de programação. O estudo é feito sobre os mais importantes paradigmas de programação, entre eles, serão abordados: programação procedural, programação orientada a objetos e, por último, o mais recente, programação orientada a aspectos. Conceitos fundamentais dos paradigmas serão introduzidos, para melhor compreensão dos mesmos. Serão feitas, comparações entre os paradigmas abordados, citando as principais vanta-gens e desvantagens, semelhanças e diferenças.
Palavras-chaves: paradigmas de programação, programação procedural, pro-gramação orientada a objetos e programação orientada a aspectos.
ABSTRACT
This paper aims to discuss the various programming techniques available, in a stand-ardized way, called programming paradigms. The study is done on the most import-ant programming paradigms, among them, will be approached: procedural program-ming, object-oriented programming and, finally, the most recent, aspects-oriented programming. Fundamental concepts of paradigms will be introduced to better under-stand them. Comparisons will be made between them, mentioning the main advant-ages and disadvantages, similarities and differences.
Keywords: Programming Paradigms, Procedural Programming, Object-Ori-ented Programming, Aspects-Oriented Programming.
LISTA DE ILUSTRAÇÕES
Figura 1.1: Foto do ENIAC [68]...................................................................................16
Figura 1.2: Arquitetura de von Neumann [3]...............................................................17
Figura 2.3: Etapas para a construção de um programa [12]......................................22
Figura 2.4: Uso do algoritmo [12]................................................................................23
Figura 2.5: Fluxogramas das estruturas de controle em Java [11].............................25
Figura 2.6: Algoritmo em pseudocódigo.....................................................................26
Figura 2.7: Processo de compilação [15]....................................................................29
Figura 2.8: Interpretação pura [15]..............................................................................31
Figura 2.9: Sistema de implementação híbrido [15]...................................................32
Figura 2.10: Linha evolutiva das linguagens de programação [9]..............................38
Figura 2.11: Evolução das linguagens em relação aos paradigmas [9].....................40
Figura 3.12: Exemplo do uso do comando goto em FORTRAN [17]..........................45
Figura 3.13: Exemplo de pseudocódigo estruturado e comentado [17].....................46
Figura 3.14: Fluxograma mais simples [11]................................................................47
Figura 3.15: Aplicando repetidamente a regra 2 ao fluxograma mais simples [11]....47
Figura 3.16: Aplicando a regra 3 ao fluxograma mais simples [11]............................48
Figura 3.17: Formatos de vírgula-flutuante IEEE: (a) precisão única, (b) precisão du-
pla [15].........................................................................................................................54
Figura 3.18: Descritor em tempo de compilação para cadeias estáticas [15]............56
Figura 3.19: Descritor em tempo de execução de cadeias dinâmicas limitadas [15].57
Figura 3.20: Mapeamento [16]....................................................................................58
Figura 3.21: Descritor em tempo de compilação para um registro [15]......................60
Figura 3.22: Exemplos de tipos enumerado em Pascal e C [16]................................62
Figura 3.23: Conceito de variável [15]........................................................................64
Figura 3.24: Precedência dos operadores em Pascal [27].........................................68
Figura 3.25: Estrutura do comando de seleção..........................................................70
Figura 3.26: Estrutura do comando de repetição [16].................................................71
Figura 4.27: O processo de abstração [33].................................................................80
Figura 4.28: Representação de uma classe [32]........................................................82
Figura 4.29: Esquema de uma classe [30]..................................................................83
Figura 4.30: Encapsulamento de um objeto [29]........................................................85
Figura 4.31: Representação de uma herança [32].....................................................86
Figura 4.32: Implementação do polimorfismo.............................................................87
Figura 5.33: Divisão da Engenhara de Software [38].................................................89
Figura 5.34: Código entrelaçado [40]..........................................................................92
Figura 5.35: Separação de interesses com POA [39].................................................94
Figura 5.36: Composição de aspectos a partir de atributos e métodos espalhados
pelas classes [51]........................................................................................................95
Figura 5.37: Implementação em POA [37]..................................................................98
Figura 5.38: Composição de sistema utilizando POA [43].......................................100
Figura 5.39: Representação de um aspect [39]........................................................101
Figura 5.40: Joinpoints de um fluxo de execução [44]..............................................102
Figura 6.41: Enfoques dos paradigmas PP e POO..................................................106
Figura 6.42: Acoplamento entre objetos [9]..............................................................111
LISTA DE TABELAS
Tabela 2.1: Critérios de avaliação e as características [15].......................................37
Tabela 3.2: Tipo inteiro na linguagem Pascal [26]......................................................53
Tabela 3.3: Tipo vírgula-flutuante na linguagem Turbo Pascal [26]...........................53
Tabela 5.4: Alguns designadores de pointcut [44]....................................................103
Tabela 5.5: Tipos de caracteres especiais [44]........................................................103
Tabela 5.6: Advices em AspectJ [44]........................................................................103
Tabela 5.7: Introduction em AspectJ [44]..................................................................104
Tabela 5.8: Outras construções em AspectJ [44].....................................................104
Tabela 6.9: Comparação entre PP e POO [65]........................................................109
LISTA DE GRÁFICOS
Gráfico 1.1: Crescimento do número de transistores da CPU [4]...............................18
Gráfico 3.2: Tendência dos custos de software/hardware [17]...................................41
LISTA DE ABREVIATURAS E SIGLAS
PP – Programação Procedural
POO – Programação Orientada a Objetos
POA – Programação Orientada a Aspectos
ENIAC – Electrical Numerical Integrator and Computer
EDVAC – Electronic Discrete Variable Computer
EDSAC – Electronic Delay Storage Automatic Calculator
ORDVAC – Ordnance Variable Automatic Computer
SEAC – Standards Electronic Automatic Computer
UNIVAC – Universal Automatic Computer
CPU – Central Processing Unit
COBOL – COmmon Business Oriented Language
APL – Array Programming Language
LISP – LISt Processing
FORTRAN – FORmula TRANslator
ALGOL – ALGOrithmic Language
PROLOG – PROgrammation en LOGique
IBM – International Business Machines
PL/S – Programming Language/Systems
BLISS – Basic Language for Implementation of System Software
TCL – Tool Command Language
RPG – Report Program Generator
APT – Automatically Programmed Tools
GPSS – General Purpose Simulation System
BASIC – Beginners All-purpose Symbolic Instruction Code
BCD – Binary Coded Decimal
ASCII – American Standard Code for Information Interchange
AOO – Análise Orientada a Objeto
UML – Unified Modeling Language
PHP – Php: Hypertext Preprocessor
API – Application Programming Interface
QIDL – Quality Interface Definition Language
COOL – COOrdination aspect Language
RIDL – Remote Interaction and Data transfers aspect Language
D2AL – Design-based Distribution Aspect Language
SUMÁRIO
RESUMO ...................................................................................................................... 7
ABSTRACT ................................................................................................................... 8
LISTA DE ILUSTRAÇÕES ........................................................................................... 9
LISTA DE TABELAS .................................................................................................. 11
................................................................................................................................... 11
LISTA DE GRÁFICOS ................................................................................................ 12
LISTA DE ABREVIATURAS E SIGLAS ..................................................................... 13
1 INTRODUÇÃO ......................................................................................................... 16
2 PARADIGMAS DE PROGRAMAÇÃO ..................................................................... 20
3 PROGRAMAÇÃO PROCEDURAL .......................................................................... 41
4 PROGRAMAÇÃO ORIENTADA A OBJETOS ......................................................... 77
5 PROGRAMAÇÃO ORIENTADA A ASPECTOS ...................................................... 89
6 COMPARAÇÕES ENTRE OS PARADIGMAS ...................................................... 105
CONCLUSÕES E TRABALHOS FUTUROS ........................................................... 113
CONCLUSÕES E TRABALHOS FUTUROS ........................................................... 113
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 115
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 115
1 INTRODUÇÃO
Hoje em dia, em qualquer seguimento da sociedade, em qualquer país,
em qualquer esfera organizacional, é fácil encontrar um computador. Seja em um
comércio, no posto de gasolina, no consultório médico, nas escolas ou universida-
des, em casa, enfim, quase em qualquer lugar existe um computador, ou vários
computadores auxiliando a vida do homem em suas tarefas. Seja profissionalmente,
seja por diversão ou para o conhecimento, o computador faz parte do dia-a-dia do
homem, facilitando a própria evolução humana e contribuindo para a história da hu-
manidade.
Desde os primórdios da computação o homem sempre soube aproveitar a
enorme capacidade de processamento dessas máquinas. Tudo começou com os
aparecimentos dos primeiros computadores mecânicos constituídos por válvulas que
tinham como objetivo fazer operações matemáticas. A aplicação fundamental des-
ses dispositivos se deu nos campos científico e militar. Um exemplo disso foi a cria-
ção em 1943-1946 do computador ENIAC (Electrical Numerical Integrator and Com-
puter) (Referência à figura?).
Figura 1.1: Foto do ENIAC [68]
O ENIAC era uma máquina gigantesca, contendo mais de 17.000 válvulas
e 800 quilômetros de cabos. Pesava cerca de 30 toneladas e consumia uma enorme
16
quantidade de eletricidade, além de válvulas, que queimavam com grande freqüên-
cia devido ao calor. O ENIAC foi projetado para calcular trajetórias balísticas em
meio a Segunda Guerra Mundial, mas só tornou operacional após o final da guerra.
O processamento computacional era bem grande para a época, sendo capaz de
executar cerca de 10.000 operações por segundo [1].
O ENIAC era programado através da redistribuição de cabos em tomadas
diferentes e rearranjo de chaves (possuía cerca de 6000 interruptores multiposição)
[3], tarefa que poderia levar muitos dias. Algumas máquinas de calcular que vieram
antes do ENIAC recebiam instruções por meio de uma fita de papel perfurado. Ope-
rações no ENIAC eram um tanto complicadas e tediosas e de manutenção dispendi-
osa devido às sucessivas queimas de válvulas [1].
Computadores que surgiram posteriormente foram inspirados no ENIAC,
como o EDVAC (Electronic Discrete Variable Computer), o EDSAC (Electronic Delay
Storage Automatic Calculator), o ORDVAC (Ordnance Variable Automatic Compu-
ter), o SEAC (Standards Automatic Computer) e o UNIVAC (Universal Automatic
Computer), contudo, a contribuição de John von Neumann foi fundamental para o
avanço desses dispositivos.
John von Neumann propôs mudanças na estrutura do computador, permi-
tindo armazenar programas e dados na mesma unidade de memória, o que faria sua
execução e leitura mais rápidas [2, 4].
Figura 1.2: Arquitetura de von Neumann [3]
A arquitetura de von Neumann tornaria a programação e computação mais
eficientes, pois tornaria possível ao programa modificar suas próprias instruções [2].
A leitura e processamento eram feitas pela CPU (Central Processing Unit - unidade
17
central de processamento), que era composta pela Unidade de Controle e a Unidade
de Lógica e Aritmética. Esta arquitetura ainda é utilizada nas máquinas atuais.
Com o avanço da tecnologia, no rápido desenvolvimento dos transistores, as
válvulas a vácuo tornaram-se obsoletas dando lugar aos circuitos integrados cada
vez menores. O gráfico 1.1 mostra a evolução dos transistores:
Gráfico 1.1: Crescimento do número de transistores da CPU [4]
O gráfico 1.1 é a previsão que Gordon Moore fez em relação ao cresci-
mento do número de transistores. Essa previsão ficou famosa como a Lei de Moore.
Moore previu para um futuro próximo que o número de transistores que podiam ser
impressos em uma única pastilha dobrava a cada ano. E isso realmente aconteceu
[4].
Com a evolução dos transistores e a grande contribuição de von Neu-
mann, os computadores ficaram com uma estrutura mais simples, tornaram-se mais
rápidos, menores e, o fundamental, os microcomputadores ficaram mais baratos e
mais acessíveis às pessoas, espalhando assim, o uso do microcomputador.
Com o aparecimento das linguagens de programação, linguagens de baixo
nível e de alto nível, a programação de computadores ficou facilitada. Essa grande
quantidade de linguagens, cada uma com suas particularidades, fazem o programa-
dor solucionar um problema de diversas formas. Isso fez com que o programador
necessitasse de padrões para um melhor aproveitamento de sua atividade. São es-
ses padrões, denominado de paradigmas de programação, que orientam o progra-
mador/desenvolvedor na hora de escrever seu código.
18
Nos tempos atuais, é exigido bastante do programador/desenvolvedor. Es-
crever códigos coesos e organizados é fundamental para sucesso e futuro da aplica-
ção. Seja para manutenção ou para mudanças, um código bem estruturado, facilita a
sua posterior compreensão. A reutilização do código, também é desejável. Grandes
problemas podem ser resolvidos facilmente seguindo um estilo norteado por um pa-
radigma.
Existem vários paradigmas de programação, este trabalho monográfico se
propõe discutir os mais importantes. A grande motivação desse trabalho é fazer este
documento servir como uma espécie de manual de referência para o
programador/desenvolvedor na hora de escrever seu código, podendo, este, esco-
lher o padrão mais apropriado para analisar e solucionar cada problema.
O trabalho se organiza como segue. No Capítulo dois será definido para-
digma de programação, serão apresentadas boas práticas para resolver um proble-
ma computacional, abordaremos linguagens de programação e faremos um breve
histórico das linguagens de programação, juntamente com os seus paradigmas. No
Capítulo três será conceituada a crise do software, serão introduzidos os conceitos
da programação estruturada e os conceitos e fundamentos do paradigma Programa-
ção Procedural (PP), bem como, as linguagens que fazem uso desse paradigma de
programação. No Capítulo quatro será visto o paradigma Programação Orientado a
Objetos (POO). Funcionamento principal e linguagens de programação que ofere-
cem suporte a esse paradigma serão discutidos. No Capítulo cinco será abordado o
paradigma Programação Orientado a Aspectos (POA). Já no Capítulo seis, será feita
uma comparação entre os paradigmas abordados, citando semelhanças e diferen-
ças, vantagens e desvantagens. O Capítulo sete apresenta as conclusões a respeito
do estudo desenvolvido.
19
2 PARADIGMAS DE PROGRAMAÇÃO
Neste capítulo, definimos paradigmas de programação, introduzimos
meios que facilitam a resolução de problemas computacionais, abordaremos concei-
tos básicos das linguagens de programação e explanamos um breve panorama his-
tórico da evolução das linguagens de programação e consequentemente dos para-
digmas de programação.
2.1 DEFINIÇÃO DE PARADIGMA
De acordo com o dicionário Aurélio [5] em sua primeira definição, atribui
ao termo paradigma como “modelo, padrão, estalão”. Ainda sobre o dicionário Auré-
lio, na sua segunda definição, utiliza a visão de Thomas Kuhn, célebre historiador da
ciência, para formalizar a definição de paradigma.
Thomas Kuhn designou o termo paradigma para as realizações científicas
que geram modelos que por período mais ou menos longo e de modo mais ou me-
nos explícito, orientam o desenvolvimento posterior das pesquisas exclusivamente
na busca da solução para os problemas por elas suscitados [5].
Embora esta definição tenha sido formalizada para as ciências físicas e
químicas, ela pode ser interpretada para definir paradigma para a computação.
Um paradigma de programação faz o programador pensar de diversas ma-
neiras sobre a tarefa de programar, dependendo somente da escolha do paradigma
usado. O paradigma de programação sustenta a atividade de programar e oferece
suporte a solução do problema. Programar nos diferentes paradigmas significa, por-
tanto, representar, segundo modelos diferentes, a solução do problema a ser resolvi-
do na máquina [6].
20
Existem várias outras definições do termo paradigma voltada para a área
da computação que podem ser a dos autores Peter Van Roy e David Watt. Segundo
Peter Van Roy, um paradigma de programação é um sistema formal que define
como a programação é realizada. Cada paradigma tem o seu próprio conjunto de
técnicas para a programação e forma de estruturar o pensamento na concepção dos
programas. [8] Segundo David Watt, o termo paradigma de programação consiste na
seleção de conceitos chaves da programação (tipos de dados, variáveis, escopo,
abstração, concorrência e controle), usados de maneira conjunta para formar um es-
tilo de programação [7].
As linguagens de programação oferecem suporte ao modelo de um para-
digma. Linguagens de programação e paradigmas de programação exercem uma
forte relação. São elas que tornam o paradigma aplicável.
Em suma, paradigma de programação é a maneira de compreender um
problema do mundo real e transformar este problema em uma solução computacio-
nal [9]. Cada paradigma determina uma forma particular de abordar os problemas e
de formular respectivas soluções [10].
2.2 RESOLVENDO UM PROBLEMA COMPUTACIONAL
Antes de escrever um programa para resolver um problema, é essencial
ter um entendimento completo do problema e uma abordagem cuidadosamente pla-
nejada para resolvê-lo [11].
Segundo Avillano [12], existem cinco passos básicos para solucionarmos
um problema. São eles:
1) Compreender o problema.
• Qual é o problema?
• Quais são as informações utilizadas? (dados)
• Quais as condições exigidas?
• É possível satisfazer as condições exigidas?
• As condições entram em contradições com o problema?
2) Adoção do método para a resolução do problema.
21
• Este problema já foi visto antes? Sob forma pouco diferente.
• Achando um problema já resolvido, podemos utilizá-lo?
• Será necessário dividir o problema em módulos para simplificação?
• É possível reformular o problema?
3) Esquematizar a resolução do problema (plano).
4) Testar o plano elaborado (teste de mesa).
• Verificar cada passo dado.
• Avaliar a exatidão de cada passo.
5) Retrospectiva do que foi feito.
• Os resultados foram satisfatórios?
• Os objetivos foram plenamente atingidos?
• É possível chegar ao resultado por outro caminho?
Esses passos mostram uma grande preocupação no entendimento do pro-
blema. Simplificando, devemos formular a definição do problema (o que) e posterior-
mente partir para o desenvolvimento (como). A Figura 2.1 está ilustrando as etapas
para a construção de um programa.
Figura 2.3: Etapas para a construção de um programa [12]
A definição do problema tem que estar bastante clara. Para projetar a so-
lução, o uso de algoritmo é recomendado. A elaboração de algoritmos facilita no de-
senvolvimento da solução.
22
Figura 2.4: Uso do algoritmo [12]
A figura 2.2 ilustra como é necessário utilizar meios como o algoritmo para
auxiliar na solução do problema.
Existem meios que auxiliam na hora de escrever um programa. Esses mei-
os proporcionam uma visão mais ampla do problema e, partindo da análise desses
meios, fica mais fácil chegar à solução do problema. São eles: algoritmo, fluxograma
e pseudocódigo.
2.2.1 ALGORITMO
Os computadores só fazem aquilo que mandamos e não necessariamente
que desejamos que eles façam [12].
Um algoritmo é a descrição de um conjunto de comandos que, obedeci-
dos, resultam numa sucessão finita de ações [13]. Essas ações são uns aconteci-
mentos que, a partir de um estado inicial, após um período de tempo finito, produz
um estado final previsível e bem definido [13].
O conceito de algoritmo é freqüentemente ilustrado pelo exemplo de uma
receita, embora muitos algoritmos sejam mais complexos. Eles podem repetir pas-
23
sos (fazer iterações) ou necessitar de decisões (tais como comparações ou lógica)
até que a tarefa seja completada [14].
Um algoritmo é a forma pela qual descrevemos soluções de problemas do
nosso mundo, afim de, serem implementadas utilizando os recursos do mundo com-
putacional [14].
Qualquer problema computacional pode ser resolvido executando uma sé-
rie de instruções em uma ordem específica, seguindo certo algoritmo e especifican-
do a maneira que ele se comportará em todas as circunstâncias. Os algoritmos, por-
tanto, representam os passos necessários para realizar uma tarefa.
2.2.2 FLUXOGRAMA
Um fluxograma é uma representação gráfica de um algoritmo ou de uma
parte de um algoritmo [11]. Um fluxograma oferece uma visão geral de um algoritmo,
sendo possível, visualizar sua estrutura.
Para a representação gráfica dos fluxogramas, é necessário utilizar certos
símbolos. Esses símbolos, cada um com significado próprio, moldam a estrutura do
algoritmo. Os símbolos são retângulos, losangos, ovais e pequenos círculos. Para
conectar esses símbolos são usados setas, denominadas de linhas de fluxo. Elas in-
dicam a ordem em que às ações do algoritmo são executadas.
A representação gráfica dos algoritmos na forma de fluxograma fica evi-
dente para visualizar as estruturas de controle presentes em um algoritmo. As estru-
turas de controle podem ser de seqüência, de seleção ou de repetição. O símbolo
retângulo é utilizado para representar a ação que pode ser um cálculo ou uma ope-
ração de entrada/saída. Os losangos são utilizados para representar uma decisão.
Este símbolo é de grande importância para a visualização do algoritmo, estando pre-
sente na estrutura de seleção. A figura 2.3 exemplifica os fluxogramas.
24
Figura 2.5: Fluxogramas das estruturas de controle em Java [11]
A figura 2.3 mostra as estruturas de controle da linguagem Java na forma
de fluxogramas. Utilizando-se fluxogramas, fica evidente a visualização da estrutura
e seqüência das ações de um algoritmo.
2.2.3 PSEUDOCÓDIGO
Pseudocódigo é uma forma genérica de escrever um algoritmo, utilizando
uma linguagem simples sem necessidade de conhecer a sintaxe de nenhuma lingua-
gem de programação [14]. O pseudocódigo cria uma facilidade na hora de codificar.
Essa facilidade se deve pelo motivo da utilização da pseudolinguagem que serve
como intermediário entre a linguagem natural e a linguagem de programação.
25
A pseudolinguagem utiliza certas palavras-chave, que indicam a natureza
da operação. Para indicar a estrutura do algoritmo, utiliza espaços no começo das li-
nhas para indicar o alinhamento dos blocos. Utiliza, também, ponto-e-vírgula para
separar os passos consecutivos [12]. A figura 2.4 mostra um exemplo de algoritmo
escrito em pseudocódigo, que consiste em ler 10 números e calcular a sua média.
Figura 2.6: Algoritmo em pseudocódigo
Os pseudocódigos são de grande ajuda para o programador, pois ajudam
a “estudar” um programa antes de tentar escrevê-lo em uma linguagem de progra-
mação qualquer.
2.3 LINGUAGENS DE PROGRAMAÇÃO
As linguagens de programação permitem ao homem expressar, por meio
de instruções, o que ele deseja que o computador execute. É o conjunto de símbolos
e regras que associamos semânticas utilizadas para programar computadores [12].
26
Cada linguagem de programação possui suas particularidades. Elas po-
dem ser diferenciadas por tipos (linguagens de máquina, linguagens assembly ou
linguagens de alto nível), e podem ser distinguidas pelo método de implementação
(compilação, interpretada ou sistemas de implementação híbridos). Algumas lingua-
gens de programação são mais adequadas para serem implementadas nos vários ti -
pos de aplicações existentes, por isso é interessante conhecer os tipos mais comuns
de aplicações. Numa tentativa de direcionar a escolha da linguagem de programa-
ção pelo programador, foram estipulados critérios que definem o que deve conter
uma boa linguagem de programação.
2.3.1 TIPOS DE LINGUAGENS
Os programadores escrevem instruções em várias linguagens de progra-
mação, algumas diretamente compreensíveis pelo computador e outras que reque-
rem passos intermediários de tradução [11]. As linguagens de programação podem
ser divididas em três tipos de linguagem: linguagens de máquina, linguagens assem-
bly e linguagens de alto nível.
A linguagem de máquina é a “linguagem natural” de um computador espe-
cífico [11]. Elas são implementadas através de código binário. Esses códigos instru-
em os computadores a realizarem suas operações mais elementares; uma de cada
vez.
Uma desvantagem de se programar utilizando linguagens de máquina está
no fato de ser imprescindível conhecer a arquitetura do computador em questão,
pois a linguagem de máquina é dependente da máquina, não sendo possível o efeito
da portabilidade. Alem do mais, a programação em código binário é altamente incô-
moda para maioria dos programadores, tornando uma tarefa árdua, tediosa e com-
plicada.
Numa tentativa de mudar o cenário da programação de computadores, até
então desenvolvido através das linguagens de máquinas, sugiram as linguagem de
assembly. As linguagens assembly introduziam um novo conceito para a programa-
ção de computadores que consistia em utilizar abreviações semelhantes ao inglês
27
(load, add, store, etc) ao invés de seqüência de números para representar as instru-
ções das operações elementares do computador. Essas abreviações formam a base
das linguagens assembly.
Para executar um código escrito em linguagem assembly, é necessário uti-
lizar programas-tradutores denominado de montadores, que tinham a função de con-
verter o código da linguagem assembly para a linguagem de máquina. A linguagem
de máquina é a linguagem que realmente o computador entende.
Com o aumento do uso de computadores, surgiu a necessidade de progra-
mar mais rapidamente. As linguagens assembly exigiam muitas instruções para se
escrever um código até mesmo de tarefas simples. Com esse intuito foram desen-
volvidas nas linguagens de alto nível.
Nas linguagens de alto nível, os códigos podem ser escritos em instruções
únicas para realização das tarefas. Isso permitiu a aceleração do processo de pro-
gramação. As instruções escritas em linguagens de alto nível se assemelham com o
inglês cotidiano e permitem a utilização de notações matemáticas comuns. As lin-
guagens de alto nível também utilizam programas-tradutores denominados compila-
dores para traduzir o código para linguagem de máquina ou interpretadores.
Na visão dos programadores, as linguagens de alto nível trazem maior fa-
cilidade na hora do desenvolvimento do que as linguagens assembly ou de máquina.
Linguagens de alto nível como Java, C++ ou Object Pascal estão entre as mais utili-
zadas.
2.3.2 TIPOS DE IMPLEMENTAÇÕES
O tipo de implementação das linguagens de programação pode ser um fa-
tor importante para velocidade de execução dos programas. As implementações po-
dem ser de três tipos, por meio de compilação, por meio de interpretação pura ou
por meio dos sistemas de implementação híbridos.
28
2.3.2.1 Compilação
O processo de compilação consiste em traduzir os programas escritos em
uma linguagem de programação para linguagem de máquina. Após essa tradução,
o programa é executado diretamente na máquina. Este método de implementação
torna a execução do programa mais rápida. Linguagens de programação como CO-
BOL (COmmon Business Oriented Language), C e Ada1 utilizam compiladores para
traduzir seus códigos-fonte. A figura 2.5 mostra as etapas do processo de compila-
ção.
Figura 2.7: Processo de compilação [15]
1 O nome da linguagem de programação Ada é uma homenagem a Condessa de Lovelace, Ada Au-
gusta. Ela trabalhou com Charles Babbage no seu projeto de máquina analítica, em 1842. Ela é con-
siderada a primeira mulher programadora da história da computação.
29
O analisador léxico tem a função de juntar os caracteres do código-fonte
em unidades léxicas. Essas unidades léxicas são os identificadores, as palavras es-
peciais, os operadores e os símbolos de pontuação.
A função do analisador sintático é reunir as unidades do analisador léxico
e construir a estrutura sintática do programa.
Uma linguagem intermediária é criada no gerador de código intermediário.
Essa linguagem fica entre o código-fonte e o código compilado. Algumas vezes essa
linguagem intermediária se comporta como a linguagem de montagem e, em outras
vezes, ela está em um nível bem acima do que a linguagem de montagem. O anali -
sador semântico, presente no gerador de código intermediário, verifica erros durante
a análise sintática como erros de tipo.
A otimização é uma parte opcional da compilação. Com a otimização os
programas tornam-se menores ou mais rápidos. Essa opção é válida para progra-
mas onde a velocidade de execução é mais importante do que a velocidade de com-
pilação.
E por último, a função do gerador do código é converter o código interme-
diário do programa para um programa em linguagem de máquina.
2.3.2.2 Interpretada
Sem a necessidade de conversão do código, nesse tipo de implementa-
ção, o programa é interpretado por um outro programa chamado interpretador. Este
método de implementação consiste em fornecer uma máquina virtual, onde o progra-
ma interpretador funciona como um programa simulador e o código-fonte é interpre-
tado ao invés de convertido para linguagem de máquina.
A vantagem desse tipo de implementação, denominada interpretação
pura, está no fato de implementar muitas operações de depuração do código-fonte,
pois as mensagem de erro em tempo de execução referem-se a unidade de código,
mostrando onde o erro ocorreu. Uma desvantagem desse tipo de implementação é
que torna a execução do programa mais lenta, devido à interpretação dos códigos-
30
fonte em linguagens de alto nível, onde a instrução é bem mais complexa. A figura
2.6 mostra o processo de interpretação pura.
Figura 2.8: Interpretação pura [15]
As linguagens com estruturas simples utilizam esse tipo de implementação
como a APL (Array Programming Language) e a LISP (LISt Processing). A lingua-
gem JavaScript é puramente interpretada.
2.3.2.3 Sistemas de Implementação Híbridos
Implementação híbrida é um método de implementação que gera uma lin-
guagem intermediária, ficando entre a interpretação total do código-fonte e a sua
compilação para linguagem de máquina. Essa linguagem intermediária é o resultado
da tradução do código-fonte oriundo de uma linguagem de alto nível, gerando o pro-
grama.
Esse método de implementação é mais rápido do que a interpretação
pura, devido ao fato das instruções do código-fonte ser decodificado somente uma
vez. A figura 2.7 mostra como é o processo.
31
Figura 2.9: Sistema de implementação híbrido [15]
Esse processo consiste em interpretar simplesmente o código intermediá-
rio ao invés de transformá-lo em código de máquina.
Uma linguagem que faz uso desse tipo de implementação é a linguagem
Perl. Inicialmente, a linguagem Java utilizava esse tipo de implementação. O código
intermediário era chamado de código de bytes. A maquina virtual Java, dotada de
um interpretador de código byte e um sistema em tempo de execução, fazia a imple-
mentação do programa. Atualmente existem sistemas que traduzem código de byte
para código de máquina, permitindo assim uma execução mais rápida.
32
2.3.3 TIPOS DE APLICAÇÕES
Existem diversos tipos de aplicações em diferentes áreas que fazem uso
do computador. Por causa dessa grande diversidade, linguagens de programação
com metas muito diferentes têm sido desenvolvidas como, por exemplo, linguagens
para aplicações científicas, aplicações comerciais, para a área da inteligência artifici -
al, para programação de sistemas, linguagens de scripting e linguagens de propósi-
tos especiais [15].
Aplicações científicas, em geral, têm estruturas de dados simples e reque-
rem um grande número de computações aritméticas. Utilizam matrizes e laços de
contagem e seleções em seus programas. Os primeiros computadores digitais eram
usados e foram inventados para as aplicações científicas. Foram projetadas lingua-
gens de programação de alto nível, com suporte a essas exigências e que tinham
como a primeira preocupação a eficiência. A primeira linguagem de programação cri-
ada para aplicações científicas foi a FORTRAN (FORmula TRANslation). A lingua-
gem de programação ALGOL 60 (ALGOrithmic Language) também foi criada para
esse propósito e outras áreas relacionadas.
Para as aplicações comerciais também foram desenvolvidas linguagens
especiais, juntamente com equipamentos que oferecem suporte para essas aplica-
ções. A linguagem de programação COBOL foi à primeira linguagem de alto nível
projetada para os negócios e teve boa aceitação.
As linguagens de programação para aplicações comerciais têm como ca-
racterísticas a facilidade de produzir relatórios, o armazenamento preciso dos dados
e suporte para operações aritméticas com decimais. Mais tarde, com o avanço da
tecnologia e aparecimento dos sistemas de banco de dados e planilhas eletrônicas,
outras linguagens de programação foram criadas com esse suporte.
Na área de inteligência artificial também foram desenvolvidas linguagens
específicas. Nessa área, que é bastante abrangente, a característica fundamental é
a computação simbólica ao invés de numérica. O termo computação simbólica con-
siste na manipulação de símbolos e nomes. Manipulação de listas encadeadas de
dados é uma característica das linguagens que oferecem suportam para esta área,
pois oferecem maior flexibilidade, que é uma exigência dessa área.
33
A linguagem funcional LISP foi a primeira linguagem projetada para a área
de inteligência artificial. Esta linguagem utiliza o paradigma da programação funcio-
nal como padrão. Outra linguagem que surgiu posteriormente foi a linguagem lógica
PROLOG (PROgrammation en LOGique), uma alternativa na abordagem dos proble-
mas nessa área. A linguagem lógica PROLOG utiliza o paradigma da programação
lógica como modelo.
A programação de sistemas que é uma área cujos programas são acessa-
dos constantemente tem como características eficiência na execução e execução rá-
pida. Também é desejável para essa área recursos presente nas linguagens de bai-
xo nível como interface com os dispositivos externos. As linguagens desenvolvidas
para esse domínio devem possuir estas características.
Alguns fabricantes de computadores como a IBM (International Business
Machines), a Digital e a Burroughs/Unisys desenvolveram linguagens de alto nível
orientadas especialmente para as suas máquinas. A IBM utilizava a linguagem PL/S
(Programming Language/Systems) para programar softwares para seus equipamen-
tos. Já a Digital utilizava a linguagem BLISS (Basic Language for Implementation of
System Software) e a Burroughs/Unisys utilizava a Extended ALGOL.
A linguagem C também possui boas características para programação de
sistemas, como programação em baixo nível, execução eficiente e não ser pressa à
arquitetura do computador. O sistema operacional Unix foi escrito quase inteiramen-
te em C.
As linguagens de scripting utilizam uma lista de comandos, chamados de
script. Esses comandos são implementados de forma interpretada. A linguagem sh,
de shell, foi a primeira linguagem a ser desenvolvida, ela possuía uma pequena co-
leção de comandos que tinha como objetivo, por exemplo, gerenciamento e filtragem
simples de arquivos em subprogramas de sistemas. A linguagem ksh, foi uma evolu-
ção da sh, nela foram adicionados novos recursos como variáveis, instruções de flu-
xo de controle e funções, tornando uma linguagem de programação completa.
Outras linguagens de scripting surgiram como awk, TCL (Tool Command
Language) e Perl. Essa última tornou uma linguagem de programação bastante po-
derosa e conhecida, devido o seu uso para programação voltada para aplicações
para Web.
34
A linguagem JavaScript também é uma linguagem de scripting voltada
para aplicações para Web, sendo usada tanto em servidores como em navegadores.
Possui alta aceitação e bastante popularidade.
E por fim, as linguagens de propósitos especiais criadas, cada uma para
uma finalidade especial de aplicação como RPG (Report Program Generator), usada
para produzir relatórios comerciais, APT (Automatically Programmed Tools), usada
para instruir ferramentas de máquinas programáveis e GPSS (General Purpose Si-
mulation System), usada para simulação de sistema.
2.3.4 CARACTERISTICAS DESEJÁVEIS DAS LINGUAGENS
Na tentativa de avaliar as linguagens de programação, critérios foram esti-
pulados, informalmente, para esse fim. Embora essa avaliação, na forma dos critéri-
os estipulados, seja informal, esses critérios entram em concordância com a visão
da maioria dos cientistas da computação [15].
As características desejáveis para uma linguagem de programação são
[16]:
1. Legibilidade: as linguagens devem possuir única e exclusivamente elementos
de fácil entendimento e não ambíguos. Para preservar a característica de legibili-
dade, as linguagens devem combinar:
• Simplicidade e ortogonalidade: a linguagem deve prover um número redu-
zido de elementos básicos, evitando multiplicidade de escrita e facilitando
o entendimento dos programas descritos. A linguagem deve também con-
ter um conjunto mínimo de primitivas que possam ser combinados, de for-
ma que componentes mais elaborados na linguagem sejam apenas com-
binações dos elementos básicos;
• Instruções de controle que não comprometem a clareza dos programas:
as instruções de controle devem ser reduzidas ao conjunto estritamente
essencial para o controle de fluxo de execução dos programas. Instruções
de desvio (go to) explícito, como as existentes em linguagens mais antigas
, são hoje preservadas em algumas linguagens apenas com propósitos
35
bem específicos, dado que seu uso indiscriminado prejudica a legibilidade
dos programas. Cada instrução da linguagem deve ter um propósito explí-
cito para que seja utilizada adequadamente;
• Facilidade para representação de tipos e estruturas de dados: a linguagem
deve prover facilidades para a representação de dados comumente neces-
sários para a resolução de problemas. Tipos primitivos, tais como números
inteiros e reais, bem como tipos compostos devem ter mecanismos de de-
finição e manipulação intuitivos e de fácil assimilação;
• Sintaxe “limpa” e concisa: cada instrução deve representar de forma única
e intuitiva o seu significado;
2. Facilidade de escrita: simplicidade e ortogonalidade são características desejá-
veis para a legibilidade que também facilitam a escrita de programas. Programas
facilmente entendidos são, em geral, provenientes da facilidade de escrita provi -
da pela linguagem. Além da simplicidade da linguagem, o suporte a abstrações
deve ser provido na linguagem para facilitar a programação. Formas abstratas de
representar transformações (por exemplo, de dados ou objetos) denotam modos
facilitados de solucionar problemas, em que apenas os elementos essenciais são
representados. Funções em linguagens imperativas, por exemplos são formas
abstratas de representar soluções, nas quais os parâmetros abstraem os dados
reais a serem manipulados. Um bom projeto de linguagem deve, portanto, tratar
da expressividade necessária para resolver problemas dos domínios requisitados
de forma clara e natural;
3. Confiabilidade: espera-se que soluções dadas aos problemas sejam confiáveis.
Implementações correspondentes aos problemas especificados devem produzir
os resultados esperados. É desejável, por exemplo, que os programadores não
façam indesejavelmente operações com tipos conflitantes, de forma que resulta-
dos inexistentes sejam produzidos. Por isso, as linguagens atuais possuem na
sua maioria, mecanismos para verificação de tipos. Apesar destes não serem um
custo mais elevado que a verificação. Ainda neste sentido, a manipulação de ex-
ceções tem sido cada vez mais utilizada nas linguagens de programação atuais.
Tais mecanismos permitem um tratamento uniforme de operações sem prejuízo
à confiabilidade dos resultados; resultados são produzidos apenas para dados
consistentes, e exceções são providas quando a consistência é violada;
36
4. Custo: o custo associado a uma linguagem de programação vai desde o custo
de desenvolvimento da mesma até sua amortização proveniente da aceitação no
mercado e os custos relativos ao seu uso. Tem-se, dessa forma, o custo relativo
ao treinamento de pessoas para o uso da linguagem, bem como o custo de escri -
ta de programas na linguagem, e os custos de compilação e de execução dos
programas. Portanto, linguagens legíveis, de fácil escrita e confiáveis, tendem a
ter um custo mais baixo de treinamento e são mais aceitas no mercado, desde
que dêem suporte a características desejáveis aos domínios de aplicação requi-
sitados pelo mercado.
Esses critérios são úteis para o programador/desenvolvedor na hora de
optar por uma ou outra linguagem de programação. A tabela 2.1 resume os critérios
que foram expostos.
Tabela 2.1: Critérios de avaliação e as características [15]
2.4 UM BREVE HISTÓRICO
Com a evolução das linguagens de programação, características seme-
lhantes das linguagens são agrupadas e com isso é formado o paradigma corres-
pondente. A abstração é o maior motivo da evolução das linguagens de programa-
ção.
37
No contexto histórico, as linguagens de programação podem ser enqua-
dradas em cinco diferentes gerações [9]. A figura 2.8 mostra a evolução das lingua-
gens no decorrer das últimas décadas.
Figura 2.10: Linha evolutiva das linguagens de programação [9]
A evolução dos paradigmas de programação pode ser mostrada através
da evolução das linguagens de programação na forma de gerações.
Primeira Geração (1940): nesta geração, em meados de 1940, a progra-
mação de computadores era feita utilizando linguagem de máquina que consistia em
instruções em código binário ou octais. O código binário realizava as operações
acessando diretamente as instruções do processador. A programação por meio de
linguagem de máquina era tediosa e altamente propensa ao erro, gerando muita in-
satisfação nos programadores. Programas com maior complexidade eram inviáveis
de se projetar, devido às dificuldades.
Segunda Geração (1950): com a insatisfação dos programadores, no iní-
cio da década de 1950, surgiu a linguagem assembly. A linguagem assembly propu-
nha facilidade na escrita do código fazendo uso de abreviações de palavras do idio-
ma inglês, como mnemônicos, para representar as instruções do programa. Para a
execução do programa, havia a necessidade de tradução do código em linguagem
assembly para a linguagem de máquina. Isso era feito através do programa tradutor
assembler ou “montador”. O conceito da linguagem assembly contribui bastante para
a tentativa de aproximação das linguagens de programação ao dialeto humano.
Terceira Geração (1954): Nesta geração de linguagens, surgiram as lin-
guagens de alto nível. A proposta das linguagens de alto nível era facilitar em termos
38
de manipulação dos comandos sem a necessidade de conhecimento profundo da ar-
quitetura da máquina. Outra característica das linguagens dessa geração é o fato de
estarem mais próximos da linguagem humana, facilitando na concepção dos códi-
gos. Em 1954 surgiu a linguagem FORTRAN com propósito de oferecer maior abs-
tração. Nessa mesma época, surgiram outras linguagens como COBOL e ALGOL.
Mais tarde, em meados da década de 60, outras linguagens surgiram como Pascal,
Ada, C e BASIC (Beginners All-purpose Symbolic Instruction Code). O paradigma
procedural foi então criado para modelar padrões para essas linguagens. As lingua-
gens de alto nível tornaram a programação mais intuitiva e simples, contudo continu-
ava a preocupação com o gerenciamento da memória e manipulação direta das vari-
áveis. Em 1960 surgia a linguagem LISP com adição de novos recursos como recur-
sividade e condicionais. Isso permitiu o aumento da abstração em comparação a ou-
tras linguagens. Posteriormente surgiram outras linguagens como o mesmo objetivo
da linguagem LISP como Haskell, Sisal, pH e ML. Com o aparecimento da lingua-
gem LISP e linguagens similares, o paradigma funcional surgiu como padrão.
Quarta geração (1970): Nessa geração surgiram as linguagens de pro-
gramação que possibilitavam resolver problemas computacionais com maior nível de
abstração, se aproximando ao máximo ao entendimento humano. Em 1967 surgiu à
linguagem Simula que aspirava construir sistemas computacionais simulando o mun-
do real por meio de objetos. Utilizava o conceito de classe para representar entida-
des. Porém, esta proposta não foi bem aceita nesta época. Em 1970 surgiu a lingua-
gem Smalltalk que estendeu os conceitos da linguagem anterior e adicionou novos
recursos como encapsulamento e variáveis de classe, introduzindo de vez o concei-
to proposto pelo Simula que alterava a forma de visualizar os problemas computaci-
onais. Outras linguagens surgiram como o mesmo objetivo como Object Pascal, C++
e Java, estas representam entidades do mundo real ou virtual por meio de objetos.
Com a criação de todas essas linguagens de programação, foi criado um modelo pa-
drão na forma do paradigma orientado a objeto. Quase simultaneamente, em 1972
surgiu a linguagem PROLOG que propunha nova maneira de criar programas. Essa
linguagem permitiria realizar deduções lógicas. A linguagem PROLOG segue o mo-
delo do paradigma lógico.
Quinta Geração (atualidade e futuro): Nessa geração, os conceitos pro-
postos pelas linguagens até a quarta geração são mesclados com novas linguagens
39
de programação como framework JESS. Os elementos da base dessa linguagem é
representado como objetos implementados em Java, com o objetivo de serem mani-
pulados por regras. Novos conceitos são propostos para as linguagens já existentes
como o framework JADE, permitindo a implementação de agentes em Java. Estão
presentes nessa geração linguagens que oferecem suporte a conceitos de mais de
um paradigma, classificadas como linguagens multi-paradigmas. Essas linguagens
podem ser de origem multi-paradigma propriamente dita como a linguagem Oz ou de
paradigma único como C++ e Java que são estendidos para conceder novos para-
digmas. As linguagens multi-paradigmas permitem empregar diferentes formas de
resolver cada problema, cabendo ao programador a escolha daquela que melhor se
adapta ao problema. Paradigmas de programação emergentes estão presentes nes-
sa geração como paradigma orientado a componentes, paradigma orientado a agen-
tes e paradigma orientado a aspectos [9].
O paradigma orientado a componentes, a agentes e a aspectos tem a
aceitação de seus conceitos facilitada devido ao fato de utilizar conceitos das lingua-
gens de paradigmas já criados como as linguagens C++ e Java. Embora alguns des-
ses paradigmas possuem linguagens próprias. A figura 2.9 mostra a classificação
das linguagens de programação em paradigmas.
Figura 2.11: Evolução das linguagens em relação aos paradigmas [9]
40
3 PROGRAMAÇÃO PROCEDURAL
Nesse capítulo, abordaremos a crise do software e introduzimos a progra-
mação estruturada. Discutiremos, também, o paradigma programação procedural, e
por fim listamos algumas linguagens de programação procedurais.
3.1 CRISE DO SOFTWARE
A chamada crise do software começou no final dos anos 60. No começo
do uso do computador o fator dominante nos custos da computação era o equipa-
mento eletrônico: o hardware. Por volta dos anos 80, a situação se inverteu drastica-
mente [17]. Gráfico 3.1 com a tendência dos custos de software por hardware.
Gráfico 3.2: Tendência dos custos de software/hardware [17]
O gráfico 3.1 mostra a tendência da relação dos custos de
sofware/hardware de projetos típicos de programação de grande porte desenvolvi-
dos nos Estados Unidos [17]. Uma grande porcentagem dos custos de desenvolvi-
mento de software pode ser atribuída a analistas e programadores.
41
O rápido desenvolvimento tecnológico dos equipamentos de computação,
projetando máquinas cada vez menores, potentes e mais baratas e o desenvolvi -
mento insuficiente da tecnologia do software foram os fatores principais que contri-
buíram para elevar a crise do software.
A crise do software ficou marcada pela dificuldade do desenvolvimento de
software frente ao rápido crescimento da demanda de software, da complexidade
dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para
o desenvolvimento de sistemas que funcionassem adequadamente conforme a ne-
cessidade do cliente, ou pudessem ser homologados pelos mesmos [18].
A baixa produtividade dos programadores acarretada pela falta de técnicas
e metodologias para o desenvolvimento de programas contribuiu para elevar os cus-
tos do desenvolvimento de programas. Os processos de construção de programas
eram muitos ineficientes e custosos. O aumento do nível de complexidade dos pro-
gramas e o modo como os programas eram feitos, muitas vezes ad hoc2, fazia com
que o produto final ficasse cheio de erros. Numa tentativa de reduzir os erros, era
feito um novo e custoso processo de depuração o que levava os programas a um ní-
vel mais aceitável [17].
A confiabilidade de um software é medida em função de suas instruções.
A complexidade das interações é um forte causador de defeitos em softwares. Pro-
gramas de aplicação de porte médio possuem em média 10000 a 100000 instruções
de máquinas. Caso os erros nos programas ocorram, eles podem ter sido causados
por uma por uma falha do hardware ou por causa de uma falha da transferência de
controle das instruções, executando a instrução errada.
Numa tentativa de mudar o cenário do desenvolvimento de programa e au-
mentar o nível de confiabilidade dos programas surgiu, em fins dos anos 60, a pro-
gramação estruturada. O propósito da criação da programação estrutura é embutir a
confiabilidade no próprio projeto do programa, eliminando posteriormente a etapa de
depuração de possíveis erros.
2 Expressão utilizada para designar ciclos completos de construção de softwares que não foram devi -
damente projetados em razão da necessidade de atender a uma demanda específica do usuário, liga-
da a prazo, qualidade ou custo [19].
42
3.2 PROGRAMAÇÃO ESTRUTURADA
A programação estruturada surgiu com objetivo de suprir a deficiência da
programação tradicional que não evidenciava com clareza a relação entre o aspecto
estático (o texto) e o aspecto dinâmico (a execução) [17]. A programação tradicional
tornava o processo de análise do texto de um programa uma tarefa difícil, sendo em
muitas vezes impossível prever o que aconteceria se determinada instrução fosse
executada. Com o advento das técnicas da programação estruturada. a manutenção
dos softwares ficou facilitada. Realçou-se a importância da documentação dos pro-
gramas e introduziu-se a utilização de estruturas de controle simples ao invés de
desvio do fluxo de execução que dificultava o entendimento dos programas.
3.2.1 MANUTENIBILIDADE
Um dos fatores mais custosos em produção de programas é o prejuízo
causado por erros não detectados na fase de depuração. Nos programas oferecidos
comercialmente, tornou-se prática comum lançá-los no mercado incompletamente
depurado, esperar as reclamações dos usuários, descobrir os erros por análise das
queixas, e produzir novas versões à medida que os erros vão sendo corrigidos [17].
Desse modo, os programas costumam sofrer revisões periódicas, sendo
para correção de erros ou mudanças de especificações onde são acrescentadas no-
vas funcionalidades. Esse processo de revisão denomina-se manutenção de softwa-
re e representa um alto custo no ciclo de vida de um programa.
A utilização da programação estrutura torna menos freqüente o uso do
processo de manutenção de software, pois tem o objetivo de aumentar a confiabili-
dade do produto original com instruções bem definidas. Mesmo que alguns erros
persistam, a presença de uma estrutura no programa torna o código mais legível e
bem mais fácil de detectar erros e posteriormente realizar a depuração.
43
3.2.2 IMPORTÂNCIA DA DOCUMENTAÇÃO
Uma boa documentação dos programas “facilita a vida” de quem progra-
ma, de quem modifica, de quem usa e de quem administra [17]. Mas, muitos progra-
madores são contrários ao fato de documentar programas.
Na programação tradicional, a documentação dos programas que consisti-
am em criar fluxogramas e comentários podiam ser feitos a posteriori, depois de o
programa ter sido criado. Isso levaria um tempo a mais para os programadores, sen-
do esse o motivo da aversão ao fato de documentar programas.
Na programação estruturada, a documentação do programa pode ser feita
simultaneamente com a codificação, tornando código e documentação aspectos indi-
visíveis de um mesmo produto [17].
3.2.3 FLUXO DE CONTROLE
A proposta das linguagens de programação da terceira geração era de ob-
ter o maior nível de abstração, para melhor atender as complexidades dos proble-
mas. Linguagens de programação como FORTRAN, COBOL e ALGOL ainda manti-
nham a mesma essência das linguagens de máquina e assembly. Elas manipulavam
dados armazenados na memória do computador através de uma seqüência única de
comandos. Numa tentativa de contornar essa sequencialidade, os programadores
faziam uso do comando de desvio goto [9].
O comando goto era utilizado para implementar laços de repetição ou utili-
zado para transferir o fluxo de execução normal do código. Mas, o uso indiscrimina-
do desse comando, fazendo desvios na seqüencialidade, tornava difícil a leitura do
código [20].
Para solucionar esse problema, foram criadas as linguagens de programa-
ção estruturadas como Pascal, Ada, BASIC e C. Essas linguagens propunham uma
maior organização dos programas por meio de estruturas de repetição, estruturas de
44
decisão e funções voltadas à modularização do código, trazendo assim, maior pro-
dutividade, qualidade e facilidade de manutenção [21].
Para afirmar que a execução de um programa está correta, é necessário
essencialmente que todas as execuções possíveis produzam resultados corretos. A
principal dificuldade em utilizar o comando goto é que obriga o leitor a ler um algorit-
mo em forma pouco natural, ou seja, “pulando” mentalmente para frente e para trás
no programa. Além disso, para cada goto condicional ele deve ainda, lembrar de
onde ele “pulou”, para poder retornar ali a análise do caso alternativo (da condição
do goto ser falsa) [17]. A figura 3.1 ilustra o uso do comando goto num trecho de pro-
grama em FORTRAN.
Figura 3.12: Exemplo do uso do comando goto em FORTRAN [17]
Fica evidente a problemática em entender o fluxo de execução do progra-
ma. A figura 3.2 mostra o mesmo exemplo acima a partir do uso de estruturas bási-
cas de controle. Note como a interpretação de tal código é em muito facilitada.
45
Figura 3.13: Exemplo de pseudocódigo estruturado e comentado [17]
O uso da indentação no trecho do pseudocódigo acima facilita a visualiza-
ção das estruturas aninhadas. É de bom senso na atividade de programar fazer uso
de comentários explicativos, como também mostra a figura 3.2.
3.2.4 CRIAÇÃO DE PROGRAMAS ESTRUTURADOS
A programação estruturada produz programas que são mais fáceis de en-
tender que programas sem estrutura e, por isso, são mais fáceis de testar, depurar,
modificar, e até mesmo de demonstrar como corretos no sentido matemático [11].
Para auxiliar na criação de programas estruturados, existem quatros re-
gras que sempre resultam em um fluxograma estruturado com aparência nítida de
blocos de construção. As regras para formar programas estruturados são [11]:
46
Regra 1 – Inicie com o “fluxograma mais simples”.
Figura 3.14: Fluxograma mais simples [11]
Regra 2 – Qualquer retângulo (ação) pode ser substituído por dois retân-
gulos (ações) em seqüência.
Figura 3.15: Aplicando repetidamente a regra 2 ao fluxograma mais simples [11]
Regra 3 – Qualquer retângulo (ação) pode ser substituído por qualquer es-
trutura de controle (seqüência, seleção e repetição).
47
Figura 3.16: Aplicando a regra 3 ao fluxograma mais simples [11]
Regra 4 – As regras 2 e 3 podem ser aplicadas de quantas vezes você
quiser e em qualquer ordem.
Os fluxogramas que emergem a partir da aplicação dessas quatro regras
constituem o conjunto de todos fluxogramas estruturados possíveis e, por isso, o
conjunto de todos os programas estruturados possíveis [11].
48
3.3 CONCEITOS DO PARADIGMA PROGRAMAÇÃO PROCEDURAL
O paradigma Programação Procedural (PP) também é chamado de para-
digma imperativo e paradigma procedimental. Este paradigma foi o primeiro a existir.
O paradigma PP utiliza o conceito de um estado e de ações que manipu-
lam esse estado, nele encontramos procedimentos e sub-rotinas que servem de me-
canismos de estruturação [10].
Programar segundo o paradigma PP significa estabelecer uma série de
instruções que por meio de ações (procedimentos) serão executadas seqüencial-
mente pelo computador a fim de resolver um determinado problema [6, 23]. No para-
digma PP, o programa representa a prescrição da solução para o problema [6].
O fundamento para o paradigma PP é o conceito da máquina de Turing3.
Os conceitos da máquina de Turing foram aproximados por John Von Neumann a
uma arquitetura de computadores [16]. O paradigma PP é baseado na arquitetura
dos computadores e é o que mais se aproxima do uso da arquitetura Von Neumann
como modelo para representação da solução de um problema a ser resolvido pela
máquina [6, 10].
O paradigma PP é bem aceito entre os programadores devido a sua apro-
ximação com a arquitetura dos computadores. Outros fatores que contribuíram para
o sucesso do PP podem ser resumidos como segue [16]:
1. A descrição de estados de uma máquina abstrata por valores de um conjunto de
variáveis, sendo que uma variável é um identificador de um local (um endereço
de memória, por exemplo) que atua como repositório para determinado conjunto
de valores.
2. Reconhecedores desses estados, que são expressões compostas por relações
entre valores e/ou resultados de operações utilizando valores. Alguns desses va-
lores podem ser substituídos por variáveis e, nesse caso, o valor presente na va-
riável será o valor utilizado na expressão.
3 Máquina de Turing é uma abstração matemática, proposta pelo pesquisador Alan Turing, que cor-
responde ao conjunto de funções computáveis [16]. A máquina de Turing é o modelo computacional
mais conhecido e comumente utilizado para a formalização de algoritmos [24].
49
3. Comandos, que podem ser de dois tipos:
a) Comandos de atribuição, que constroem valores efetuando operações a
partir de valores preexistentes e atualizam os conteúdos de variáveis;
b) Comandos de controle, que determinam qual o próximo comando a ser
executado.
A organização do paradigma PP é baseada na seqüência de variáveis e
comandos. As variáveis representam os estados das entidades e os comandos exe-
cutam ações sobre estes estados, sendo as variáveis e comandos organizados em
funções e procedimentos [9].
A execução de um programa procedural se assemelha, portanto, à simula-
ção da operação de uma máquina física. Cada estado da máquina, uma vez reco-
nhecido, leva a uma seqüência de ações. As ações alteram o estado da maquina,
suscitando novas ações e assim por diante até que seja reconhecido um “estado fi-
nal”, que indica a conclusão de uma tarefa [16].
O paradigma PP ainda vigora pelos motivos de considerável modulariza-
ção, certa simplicidade de programação e relativa eficiência oferecida, uma vez que
a forma de codificação dos comandos condiz com a forma pela qual os mesmos são
executados pela máquina. Este fato facilita a geração de executáveis enxutos e efici-
entes [9].
3.4 OS DADOS
Os dados têm papel central em qualquer programa, uma vez que são eles
que alimentam um programa e/ou resultam dele. De certa maneira, podemos afirmar
que os dados são a razão de existência dos programas. E, por sua vez, os progra-
mas são a razão de existência das linguagens de programação [16]. Os dados são
caracterizados por três aspectos básicos: valores, tipos e variáveis [16].
50
3.4.1 VALORES
Valores são representações simbólicas de conceitos. Se, por exemplo, o
conceito representado é a temperatura que marca um termômetro, o número indica-
do pela coluna de mercúrio será um valor numérico [16].
Os programas existem basicamente para manipular valores. Durante a
execução do programa, os valores podem ser avaliados, armazenados, atualizados
e transmitidos.
Quando pensamos em soluções computacionais para problemas, precisa-
mos, inicialmente, modelar o “mundo real” em elementos que possam ter seus valo-
res representados. Desta forma, nos reportamos a valores conhecidos que designa-
mos como representações para valores do problema do “mundo real” [16].
3.4.2 TIPOS
Tipos são classes de valores. Eles devem representar os conjuntos de va-
lores elementares de se deseja tratar nas linguagens de programação. Por exemplo,
se todos os valores relevantes para resolver um problema são numéricos, os valores
podem ser classificados segundo o seu tipo como naturais, inteiros e reais [16].
Os tipos podem ser divididos em: tipos primitivos, tipos cadeia de caracte-
res, tipos matriz, tipos registro, tipos ponteiro e tipos construídos pelo programador.
3.4.2.1 Tipos Primitivos
Os tipos primitivos são aqueles cujos valores são “atômicos”, ou seja, não
podem ser desmembrados em valores mais simples. A escolha dos tipos primitivos
para uma linguagem de programação está intimamente relacionada com os propósi-
tos para os quais a linguagem foi criada, como por exemplo, a linguagem FORTRAN
51
que foi criada primordialmente para resolver problemas científicos, manipulando ti-
pos primitivos numéricos que compreendem em números reais, variações de preci-
são, números inteiros e números complexos, bem como a linguagem COBOL que
propunha fazer o processamento de dados comerciais, manipulando cadeias de ca-
racteres como tipo primitivo [16]. Alguns dos tipos de dados primitivos são reflexos
de hardware, por exemplo, os tipos inteiros. Outros exigem somente um pequeno
suporte de software para sua implementação [15]. Os tipos primitivos podem ser dos
tipos numéricos e dos tipos não numéricos.
• Tipos Numéricos: muitas das primeiras linguagens de programação tinham so-
mente tipos primitivos numéricos que ainda desempenham um papel fundamental
entre os suportados pelas linguagens contemporâneas [15]. Os tipos numéricos
se dividem em: inteiro, vírgula-flutuante e decimais.
1) Inteiro: o tipo de dados primitivo numérico mais comum é o inteiro. Um valor
inteiro é representando em um computador por uma cadeia de bits, com um
dos bits tipicamente a extrema esquerda, representando o sinal. Tipos inteiros
são suportados diretamente pelo hardware. Um inteiro negativo poderia ser
armazenado de três tipos de notações: sinal-magnitude, complemento de dois
ou complemento de um. Na notação sinal-magnitude o bit de sinais é fixado
para indicar o valor negativo, enquanto o restante da cadeia de bits indicava o
valor absoluto. Nessa notação não é possível efetuar operações aritméticas.
Na notação complemento de dois é possível fazer operações de adição e
subtração com os inteiros negativos. A representação do inteiro negativo é
feita tomando-se o complemento lógico da versão positiva do número e adici-
onando-se um. Na notação complemento de um, o valor negativo de um nú-
mero inteiro é armazenado como o complemento lógico de seu valor absoluto.
Na notação complemento de um o zero possui duas representações [15].
As linguagens possuem nomenclatura própria para representar os inteiros. Na
linguagem de programação C, por exemplo, o inteiro é representado como int
[16]. O tamanho suportado para representar os inteiros depende da lingua-
gem de programação, por exemplo, a linguagem Ada que permite três tama-
nhos para a implementação dos inteiros: short integer, integer e long integer.
A tabela 3.1 mostra as implementações do tipo inteiro na linguagem Pascal.
52
Tabela 3.2: Tipo inteiro na linguagem Pascal [26]
2) Vírgula-Flutuante: os tipos de dados com vírgula-flutuante modelam os núme-
ros reais, mas as representações são somente aproximações para a maioria
dos números reais. Na maioria dos computadores, os números com vírgula-
flutuante são armazenados em dígitos binários. A tabela 3.2 mostra as imple-
mentações do tipo vírgula-flutuante na linguagem de programação Pascal.
Tabela 3.3: Tipo vírgula-flutuante na linguagem Turbo Pascal [26]
Operações aritméticas com números representados por vírgula-flutuante per-
dem a exatidão. Os valores de vírgula-flutuante são representados como fra-
ções e como expoentes. Máquinas atuais usam o formato IEEE Floating-Point
Standard 754 para representações de valores com vírgula-flutuante. Os imple-
mentadores de linguagens usam qualquer representação suportada pelo
hardware. Além da nomenclatura real, designada para representação do tipo
vírgula-flutuante na linguagem Pascal, existe outros dois tipos de representa-
53
ções frequentemente utilizados entres as linguagens de programação, que
são o float e o double. O float é o tamanho padrão, normalmente armazenado
em quatro bytes de memória. O double é fornecido para situações em que se
necessitam partes fracionárias maiores, pois ocupam duas vezes mais espa-
ço do que a float e oferecem o dobro do número de bits da fração. Os termos
precisão e faixa são definidos para representar conjunto de valores para um
tipo de vírgula-flutuante. Precisão é a exatidão da parte fracionária de um va-
lor, medida como o número de bits. Faixa é uma combinação de faixa de fra-
ções e, o que é mais importante, da faixa de expoentes. A figura 3.6 mostra o
formato IEEE Floating-Point Standard 754 para representação da precisão
única e dupla [15].
Figura 3.17: Formatos de vírgula-flutuante IEEE: (a) precisão única, (b) precisão dupla [15]
3) Decimais: a maioria dos grandes computadores projetados para suportar apli-
cações de sistemas comerciais tem suporte de hardware para tipos de dados
decimais, que armazenam um número fixo de dígitos decimais, com a vírgula
decimal em uma posição fixa no valor. A linguagem COBOL utiliza tipo de da-
dos decimais. Os tipos decimais são armazenados usando códigos binários
para os dígitos decimais. Essas representações são chamadas decimais codi-
ficadas em binário – BCD (binary coded decimal). As operações com valores
decimais são feitas em hardware em máquinas que têm essas capacidades,
caso contrário, são simuladas em software. Os tipos decimais têm a vanta-
54
gem da capacidade de armazenar, com precisão, valores decimais, pelo me-
nos os de dentro de uma faixa restrita, o que não pode ser feito em vírgula-
flutuante. A desvantagem é que a faixa de valores é restrita, pois não se per-
mite nenhum expoente, e a representação dos mesmos na memória é um
desperdício [15].
• Tipos Não Numéricos: nem todos os problemas a serem resolvidos computacio-
nalmente possuem natureza exclusivamente numérica, e por isso tipos que re-
presentam valores não numéricos devem também ser providos pelas linguagens
[16]. Os tipos não numéricos são os tipos booleanos e os tipos caracteres.
1) Tipos Booleanos: os tipos booleanos são, talvez, os mais sim-
ples de todos. Sua faixa de valores tem somente dois elementos: um para
verdadeiro e um para falso. Um valor booleano é armazenado na menor célu-
la de memória eficientemente endereçável tipicamente o byte, embora seja re-
presentado por um único bit [15]. Na linguagem de programação Pascal, o
tipo booleano é denotado por boolean e assume os valores true para verda-
deiro e false para falso.
2) Tipos Caracteres: os dados são armazenados nos computadores como codifi-
cações numéricas. A codificação mais comumente usada é a ASCII (Ameri-
can Standard Code for Information Interchange), que usa valores de 0 a 127
para codificar 128 diferentes caracteres. Para fornecer o meio de processar
codificações de caracteres únicos, muitas linguagens de programação inclu-
em um tipo primitivo para elas [15]. Na linguagem de programação C o tipo
caractere é denotado por char [16].
3.4.2.2 Tipos Cadeia de Caracteres
Um tipo cadeia de caracteres é aquele cujos valores consistem em se-
qüências de caracteres. Cadeias de caracteres são um tipo fundamental para todos
os programas com manipulação de caracteres.
Na linguagem de programação Ada, string é um tipo que é predefinido
como uma matriz unidimensional de elementos character. Referências a sub-cadei-
55
as, a concatenação, operadores relacionais e a atribuição são oferecidos para os ti-
pos string.
A linguagem de programa C usa vetores char para armazenar cadeias de
caracteres e para oferecer uma coleção de operações com cadeias por meio de uma
biblioteca-padrão cujo arquivo de cabeçalho é string.h. A maior parte dos usos de
cadeias e a maioria das funções de biblioteca usam a convenção segundo a qual as
cadeias de caracteres são finalizados com um caractere especial nulo, que é repre-
sentado por ‘\0’.
O FORTRAN 77, 90 e, o BASIC, tratam as cadeias como um tipo primitivo
e oferecem atribuição, operadores relacionais, concatenação e operações de refe-
rência a subcadeias para elas.
Os tipos cadeia de caracteres, às vezes, são suportados diretamente em
hardware, mas, na maioria dos casos, usa-se software para implementar o armaze-
namento, a recuperação e a manipulação.
Existem dois tipos que determinam o tamanho dos valores da cadeia, são
eles: cadeia de tamanho estático e cadeia de tamanho dinâmico limitado.
Cadeia de tamanho estático, como o próprio nome diz, o tamanho é estáti-
co e especificado na declaração. Essa é a opção existente nas linguagens de pro-
gramação FORTRAN 90, COBOL, Pascal e Ada. Na implementação da cadeia de
caracteres estática, é necessário um descritor, que é uma exigência durante a com-
pilação. O descritor possui três campos: o primeiro campo é o nome do tipo, o se-
gundo campo é especificado o tamanho do tipo, em caracteres e o terceiro campo é
endereço do primeiro caractere. A figura 3.7 mostra o descritor em tempo de compi-
lação para cadeias estáticas.
Figura 3.18: Descritor em tempo de compilação para cadeias estáticas [15]
56
Cadeia de tamanho dinâmico limitado permite que as cadeias tenham tama-
nhos variáveis até um máximo declarado e fixo estabelecido pela definição da variá-
vel. Tais variáveis podem armazenar qualquer número de caracteres entre zero e o
máximo. A implementação das cadeias dinâmicas limitadas exigem um descritor em
tempo de execução para armazenar tanto o tamanho máximo fixo como o tamanho
atual. A figura 3.8 mostra o descritor em tempo de execução para cadeias dinâmicas
limitadas.
Figura 3.19: Descritor em tempo de execução de cadeias dinâmicas limitadas [15]
As cadeias dinâmicas limitadas para a linguagem de programação C não
exigem descritores em tempo de execução, pois o final de uma cadeia é marcado
com um caractere nulo. Elas não precisam do tamanho máximo porque os valores
de índice nas referências de vetor não são verificados quanto à faixa nessas lingua-
gens.
3.4.2.3 Tipos de dado Matriz
Uma matriz é um agregado homogêneo de elementos de dados cujo ele-
mento individual é identificado por sua posição no agregado em relação ao primeiro.
Os elementos de dados individuais de uma matriz são de algum tipo previamente
definido, primitivo ou não. A necessidade universal das matrizes é evidente, pois a
maioria dos programas de computadores precisa modelar coleções de valores do
mesmo tipo e que devem ser processadas da mesma maneira.
57
Elementos específicos de uma matriz são referenciados por meio de um
mecanismo sintático de dois níveis, cuja primeira parte é o nome do agregado e a
segunda é um seletor possivelmente dinâmico que consiste em um ou mais itens co-
nhecidos como subscritos ou índices. Se todos os índices em uma referência forem
constantes, o seletor será estático, caso contrário, será dinâmico. Às vezes, as ma-
trizes são chamadas de mapeamento finito. A figura 3.9 mostra possíveis mapea-
mentos para os conjuntos A e B criando-se os conjuntos C e D.
Figura 3.20: Mapeamento [16]
Os conjuntos C e D, na figura 3.9, representam possíveis valores quando
queremos representar um dos três primeiros dias do mês para cada um dos meses
do primeiro trimestre [16].
Mapeamentos de valores aparecem na maioria das linguagens de progra-
mação como arrays [16].
A sintaxe das referências a matrizes é mais ou menos universal: ao nome
da matriz segue-se o da lista de índices, colocada entre parênteses ou entre colche-
tes. As linguagens FORTRAN e Ada usam parênteses para envolver índices de ma-
triz, já as linguagens Pascal e C usam colchetes para delimitar seus índices de ma-
triz.
Implementar matrizes exige mais esforço em tempo de compilação do que
implementar tipos simples, como, por exemplo, o inteiro. O código que permite aces-
sar elementos de uma matriz deve der gerado no tempo de compilação. Em tempo
58
de execução, este código deve ser executado para produzir endereços de elemen-
tos.
3.4.2.4 Tipos Registro
Um registro é um agregado possivelmente heterogêneo de elementos de
dados. Cada elemento individual é identificado por seu nome.
Os registros são projetados para atenderem a necessidade dos programas
de modelaram conjuntos de dados que não são homogêneos, como, por exemplo,
informações a respeito de um estudante colegial que poderiam incluir nome, número
do estudante, média das notas e assim por diante. Um tipo de dados para esse con-
junto poderia usar uma cadeia de caracteres para o nome, um número inteiro para o
número do estudante, um número real para a média das notas, etc. Os registros, fre-
quentemente, são tipos de dados valiosos nas linguagens de programação.
Os registros e as matrizes são formas estruturais estreitamente relaciona-
das e, por conseguinte, é interessante compará-los. As matrizes são usadas quando
todos os valores de dados têm o mesmo tipo e são processados da mesma maneira.
Isto é feito facilmente quando há uma maneira sistemática de percorrer estrutura. Tal
processamento é bem suportado, usando-se índices dinâmicos como o método de
endereçamento.
Os registros são usados quando um conjunto de valores de dados é hete-
rogêneo, e os diferentes campos não são processados da mesma maneira. Além
disso, os campos de um registro, muitas vezes, não precisam se processados em
uma ordem seqüencial particular. Os nomes de campos são como índices literais ou
constantes. Uma vez que são estáticos, eles oferecem um acesso muito eficiente
aos campos. Índices dinâmicos poderiam ser usados para acessar campos de regis-
tro, mas isso rejeitaria a verificação de tipos e também seria mais lento.
A diferença fundamental entre um registro e uma matriz é a homogeneida-
de dos elementos nas matrizes contra a possível heterogeneidade dos elementos
nos registros. Os elementos do registro, ou os campos, normalmente não são refe-
59
renciados por índices, como nas matrizes, as referências são feitas usando identifi-
cadores.
As referências aos campos individuais de registros são sintaticamente es-
pecificadas por meio de diversos métodos diferentes, dois dos quais nomeiam o
campo desejado e seus registros envolventes.
A maioria das linguagens de programação usa a notação de pontos para
as referências a campos, cujos componentes da referência são conectados com
pontos, exceto a linguagem de programação FORTRAN 90 que utiliza o símbolo por-
centagem (%) ao invés do ponto (.).
A atribuição é uma operação de registro comum. Na maioria dos casos, os
tipos dos dois lados devem ser idênticos.
Para a implementação de tipos registro é necessário um descritor em tem-
po de compilação. A figura 3.10 mostra a forma geral do descritor em tempo de com-
pilação de um registro.
Figura 3.21: Descritor em tempo de compilação para um registro [15]
Os campos dos registros são armazenados em localizações de memória
adjacentes. O endereço do deslocamento, em relação ao seu inicio, é associado a
cada campo. Os acessos a estes são manipulados usando-se esses deslocamentos.
Descritores em tempo de execução para registros são desnecessários.
60
3.4.2.5 Tipos Ponteiro
Um tipo ponteiro é aquele em que as variáveis têm uma faixa de valores
que consiste em endereços de memória e um valor especial, o nil. O nil não é um
endereço válido e serve para indicar que um ponteiro não está sendo usado atual-
mente para referenciar qualquer célula de memória.
Os ponteiros são usados para dar flexibilidade de endereçamento e para
controlar o gerenciamento de armazenamento dinâmico.
Os ponteiros foram projetados para dois tipos distintos de usos. Primeiro,
eles apresentam parte do poder de endereçamento indireto, muito usado em progra-
mação em linguagem de montagem. Em segundo lugar, fornecem um método de ge-
renciamento de armazenamento dinâmico. Um ponteiro pode ser usado para aces-
sar uma localização na área em que o armazenamento é alocado dinamicamente,
chamada usualmente de monte. Variáveis alocadas dinamicamente no monte são
chamadas dinâmicas no monte. Variáveis sem nomes são chamadas variáveis anô-
nimas.
Os ponteiros, diferentemente das matrizes e dos registros, não são tipos
estruturados, ainda que sejam definidos um operador de tipo. Na linguagem de pro-
gramação C o operador de tipo é o asterisco (*), na linguagem Ada usa-se access e
na linguagem de programação Pascal o operador de tipo é o circunflexo (^). Além
disso, eles também diferem das variáveis escalares porque são mais frequentemen-
te usados para referenciar alguma outra variável, em vez de armazenarem dados de
alguma espécie.
Na linguagem de programação Pascal, os ponteiros são usados somente
para acessar variáveis anônimas alocadas dinamicamente. A linguagem de progra-
mação Ada oferece ponteiros, chamados acessos. Na linguagem de programação C,
ponteiros podem ser usados de uma maneira muito semelhante àquele que os ende-
reços são usados em linguagens de montagem. Isso significa que eles são extrema-
mente flexíveis, mas devem ser usados com grande cuidado. Diferentemente dos
ponteiros do Pascal e da Ada 83, que somente podem apontar para dentro do mon-
te, os ponteiros do C podem apontar para, virtualmente, qualquer variável em qual-
quer lugar da memória. Na linguagem de programação FORTRAN 90, os ponteiros
61
são usados para apontar tanto para variáveis dinâmicas no monte como para variá-
veis estáticas.
Os ponteiros são custosos de implementar se forem usados para gerenci-
amento do armazenamento dinâmico. O gerenciamento do monte é relativamente fá-
cil se todas as células tiverem o mesmo tamanho, mas torna-se mais complicado
com a alocação e desalocação de células de tamanho variável.
3.4.2.6 Tipos Ordinais Construídos pelo Programador
Um tipo ordinal é aquele cuja faixa de valores possíveis pode ser facilmen-
te associada ao conjunto dos números inteiros positivos. No Pascal e na Ada, por
exemplo, os tipos ordinais primitivos são o inteiro, o caractere e o booleano. Em mui-
tas linguagens, os usuários podem definir dois tipos de ordinais: tipos enumerado e
tipos subfaixa [15].
• Tipos Enumerado: algumas linguagens de programação fornecem mecanismos
para construção de novos conjunto de valores definidos pelos seus usuários,
através da enumeração [16]. Um tipo enumerado é aquele em que todos os va-
lores possíveis, os quais se tornam constantes simbólicas, são enumerados na
definição. A figura 3.11 mostra a criação de conjunto de valores para representar
os meses do ano, nas linguagens de programação Pascal e C.
Figura 3.22: Exemplos de tipos enumerado em Pascal e C [16]
Os tipos enumerados normalmente são implementados, associando um valor in-
teiro não negativo a cada constante simbólica no tipo. Normalmente, o primeiro
valor de enumeração é representado como 0, o segundo como 1 e assim por di-
ante. Obviamente, as operações permitidas são drasticamente diferentes daque-
62
las com números inteiros, exceto para os operadores relacionais, que são idênti-
cas. Os tipos enumerados ANSI C frequentemente são tratados exatamente
como números inteiros.
• Tipos Subfaixa: um tipo subfaixa é uma subseqüência de um ordinal. Os tipos
subfaixa foram introduzidos pelo Pascal e também estão incluídos na Ada. A co-
nexão de um tipo subfaixa ao seu primitivo é estabelecida combinando-se os va-
lores existentes na definição da subfaixa com os dos ordinais anteriormente de-
clarados ou incorporados. Os tipos subfaixa são implementados exatamente da
mesma maneira que seus tipos-pai, exceto que as verificações de faixas devem
ser implicitamente incluídas pelo compilador em toda atribuição de uma variável
ou de expressão a uma variável de subfaixa. Isso aumenta o tamanho do código
e o tempo de execução, mas, usualmente, considera-se que vale o custo. Além
disso, um bom compilador otimizador pode melhorar a parte da verificação.
Os tipos enumerados e os tipos subfaixa definidos pelo usuário são conve-
nientes e aumentam a legibilidade e a confiabilidade dos programas.
3.4.3 VARIÁVEIS
Para que as soluções dos problemas computacionais sejam concretiza-
das, precisamos, na maioria das vezes, de mecanismos para armazenar valores de
forma que estes possam ser usados a posteriori. Em grande parte das linguagens de
programação os valores são armazenados em variáveis, as quais permitem que os
mesmos sejam usados em diversos pontos do programa [16]. Uma variável de pro-
grama é uma abstração de uma célula ou de um conjunto de células de memória do
computador. Os programadores frequentemente pensam nas variáveis como nomes
para localizações da memória, mas há muito mais coisas nelas do que apenas um
nome [15].
Para a solução dos problemas reais, devemos inicialmente escolher valo-
res que denotam os valores reais do problema. A representação desses conjuntos
de valores se dá por tipos, os quais podem ser tão simples como os tipos primitivos,
quanto mais elaborados como os tipos construídos.
63
Nas linguagens de programação, denominamos de variáveis os nomes
fantasia utilizados nos programas para representar valores que podem ser transfor-
mados (manipulados) ao longo da computação do programa.
Na execução de um programa, uma variável é um objeto identificado por
um nome fantasia que contém um valor (o seu conteúdo), o qual pode ser consulta-
do ou modificado tantas vezes quanto necessário ao longo da computação do pro-
grama. Essas variáveis são então usadas para modelar os objetos reais de forma
que seus valores possam ser consultados ou modificados.
O armazenamento das variáveis é feito pelo uso de células de memória e
o número de células usadas para o armazenamento de uma variável depende do
tipo de dados associado e da linguagem de programação. A figura 3.12 mostra o
conceito das variáveis.
Figura 3.23: Conceito de variável [15]
Para cada variável de um programa, temos associado: um identificador (o
nome fantasia), um endereço da(s) célula(s) de memória aonde o valor é armazena-
do, e mais o conteúdo (valor) no endereço de memória, como mostra a figura 3.12.
Quando criamos variáveis em um programa, estamos na realidade criando
um espaço de memória que pode acomodar qualquer valor do tipo declarado. Além
disso, criamos um nome fantasia que queremos tratar, para não termos que lidar
com o endereço físico da memória reservada.
3.4.3.1 Tempo de Vida das Variáveis
O tempo de vida de uma variável é o tempo durante o qual esta é vincula-
da a uma localização de memória específica. Sendo assim, seu tempo de vida inicia-
se quando ela é vinculada a uma célula específica e encerra-se quando ela é des-
vinculada dessa célula [15].
64
Uma variável existe desde o momento em que é associada (vinculada) a
uma célula de memória (a chamada alocação) da variável, e cessa sua existência
quando o dado espaço de memória é disponibilizado (desalocação) [16]. Variáveis
que tem a sua alocação antes que se inicie a execução dos blocos de comandos do
programas é chamado de variáveis globais e locais.
Variáveis globais são aquelas vinculadas às células de memória antes da
execução do programa e assim permanecem até que a execução do programa se
encerre. O tempo de vida das variáveis locais está relacionado aos blocos de execu-
ção nos quais elas estão inseridas. Dessa forma, as variáveis locais têm seu escopo
de existência delimitado pela ativação do bloco de execução no qual está inserida.
Esses blocos individuais podem ser ativados sucessivas vezes durante a execução
de um programa, contudo, os valores das variáveis locais aos blocos são novos a
cada ativação do bloco na maioria das linguagens.
Linguagens como Pascal, Ada e C, possuem blocos de comandos nos
quais podemos ter definidos estes variáveis locais, que são acessíveis apenas no
tempo de execução dos blocos. A linguagem C, contudo, permite que valores de va-
riáveis locais sejam retidos, quando as variáveis são declaradas como static (um
atributo de variáveis que as torna globais).
3.4.3.2 Vinculações de Armazenamento
A vinculação de um tipo a uma variável associa aquele variável aos possí-
veis valores que ela pode assumir.
A vinculação de tipos às variáveis em linguagens de programação proce-
durais pode ser de diversas maneiras para os tipos estáticos e dinâmicos.
• Tipos estáticos: se uma linguagem tem tipos estáticos, então, as variáveis preci-
sam ser declaradas antes de ser utilizadas, e o tipo de cada variável é determina-
do quando ela é declarada. Uma variável não pode ser declarada mais de uma
vez, portanto, o tipo dos valores que podem ser armazenados no local identifica-
do pelo nome de uma variável é único, fixo e determinado ao longo de todo o
programa. Todas as atribuições de valores a variáveis precisam ser de tipos
65
compatíveis com aqueles das variáveis que recebem os valores. A verificação de
compatibilidade pode ser efetuada durante a compilação do programa, liberando
a execução da necessidade de novas verificações de tipos. Com isso, os progra-
mas se tornam mais eficientes e o código executável mais compacto.
• Tipos dinâmicos fortes: os tipos dinâmicos fortes permitem que valores de dife-
rentes tipos sejam armazenados em uma mesma variável. A única exigência é
que as expressões e comandos sejam coerentes com relação a tipos. Ou seja,
se uma expressão ou comando contém operações com valores e relações entre
esses valores, então essas operações e relações devem fazer sentido no que diz
respeito a tipos. A verificação de compatibilidade de tipos pode ser feita durante
a compilação de um programa. Entretanto, durante a execução do programa são
necessárias verificações adicionais, para garantir que tipos específicos de valo-
res armazenados nas variáveis sejam compatíveis.
• Tipos dinâmicos fracos: esses tipos indicam que uma linguagem de programação
não verifica os tipos dos valores atribuídos às variáveis. A linguagem não oferece
qualquer assistência ao programador para garantir a integridade do programa no
que se refere aos tipos de dados. Os compiladores e interpretadores construídos
dessa forma são mais compactos e eficientes, mas fica totalmente a cargo do
programador garantir a correção das atribuições, operações e relações em seu
programa.
3.5 EXPRESSÕES E COMANDOS
A computação de um programa é considerada como uma máquina de
transformação em que podemos distinguir dois estados primordiais do programa: o
estado inicial – quando nenhuma transformação sobre os dados ainda foi realizada –
e o estado final, após todas as transformações realizadas pelo programa. A maioria
dos programas, no entanto, é formada por sucessivas transformações de dados, por
suas expressões e comandos. Dessa forma, podemos subdividir o programa em ele-
mentos de transformação sucessiva [16].
66
Para as linguagens de programação que possuem variáveis para “guardar”
valores de dados a serem computados pelo programa, o estado é refletido pelo con-
junto de variáveis e o seu fluxo de controle. O estado inicial de um programa é, por -
tanto, caracterizado pelo conjunto de suas variáveis, com os seus respectivos conte-
údos, quando a computação do programa é iniciada. Após uma primeira transforma-
ção, temos um novo estado do programa, e assim sucessivamente até o final da
computação, chegando ao estado final do programa. Para programas seqüências, a
computação de um programa é, na realidade, uma transformação sucessiva de esta-
dos.
As expressões são os recursos disponíveis nas linguagens de programa-
ção para a transformação de dados, alguns dados são fornecidos e um resultado é
obtido a partir da computação desses dados. Elas são os elementos de transforma-
ção de dados em um programa: a partir de valores, uma transformação é aplicada e
um valor resultado é produzido. As expressões atuam primordialmente sobre os va-
lores, elas recebem e produzem valores.
Os comandos, por sua vez, atuam sobre o fluxo de controle e estados do
programa. Assim como as expressões são responsáveis pela transformação de da-
dos, os comandos são responsáveis pelas mudanças de estados nas linguagens
dos programas. As mudanças podem ocorrer nas variáveis, mudando o seu conteú-
do ou nas estruturas de controle no nível de instrução que direcionam os passos
subseqüentes da computação do programa.
Os comandos e expressões são classificados como: operações, atribui-
ções e controle.
3.5.1 OPERAÇÕES
Da avaliação de uma expressão, resulta o cálculo da expressão, dados os
valores. Para literais (os literais nas linguagens de programação são expressões que
denotam um valor fixo de algum tipo, como, por exemplo, 2 que denota o valor dois
do tipo inteiro), por exemplo, o cálculo resultante da expressão é o valor correspon-
dente do literal. Para variáveis, o cálculo da expressão corresponde ao conteúdo da
67
variável. Para as expressões aritméticas e lógicas, contudo, o cálculo só pode ser
realizado mediante as regras de precedência dos próprios operadores ou impostas
pelos parênteses, a ordem de avaliação dos operandos, e ainda as regras da lingua-
gem quando a sobrecarga de operadores é permitida [16].
3.5.1.1 Ordem de Avaliação
A ordem de avaliação depende primordialmente da precedência dos ope-
radores, bem como dos parênteses, e a ordem da avaliação dos operandos. A figura
3.13 mostra a ordem da prioridade dos operadores na linguagem Pascal, os de mai-
or precedência estão em cima.
Figura 3.24: Precedência dos operadores em Pascal [27]
Nas expressões aritméticas, por exemplo, temos em geral os operadores
binários de multiplicação e divisão com a mesma prioridade, mas com prioridade
maior que os operadores de soma e subtração. Para operadores associativos defini-
dos com a mesma prioridade, o resultado da expressão independe da ordem em que
eles são avaliados.
Quando se deseja dar prioridade a operadores explicitamente, usamos os
parênteses para denotar a ordem de avaliação de uma expressão: as subex-
pressões nos parênteses mais internos são calculadas, depois os imediatamente
mais externos e assim sucessivamente até completar o cálculo de toda a expressão.
As expressões lógicas seguem o mesmo raciocínio. Na maioria das lin-
guagens, o operador lógico de maior prioridade é o unário not, seguido do binário
and, seguido do or. Outras linguagens, tal como Ada, tratam todos os operadores ló-
68
gicos com a mesma prioridade, e assim as expressões devem ser colocadas entre
parêntesis porque estes operadores não são associativos.
Além da precedência natural dos operadores e a ordem de avaliação im-
posta pelos parênteses, devemos notar que a maioria das linguagens avalia as ex-
pressões da esquerda para a direita da ordem de escrita.
3.5.2 ATRIBUIÇÕES
Os comandos de atribuições são responsáveis pela mudança explícita de
estado do programa, onde uma ou mais variáveis têm seus valores modificados. As
linguagens de programação que possuem variáveis possuem também comandos de
atribuição.
Por convenção, todas as linguagens de programação procedurais têm um
único comando de atribuição. Denotamos aqui esse comando utilizando o operador⇐ [16]. Este operador é binário e infixo. À esquerda do operador encontramos sem-
pre uma variável, e à direita do operador encontramos uma operação dependente de
tipo. A verificação de consistência de tipos é efetuada no momento apropriado, de-
pendendo de a linguagem utilizar tipos estáticos, dinâmicos fortes ou dinâmicos fra-
cos. Se o tipo da variável for compatível com o tipo do resultado da operação, então
o comando atualiza o valor da variável, que passa a ser o resultado da operação.
A atribuição admite formatos especiais para entrada e saída de dados. Po-
demos considerar que existem duas variáveis especiais denominadas Entrada e Saí-
da. A variável Entrada ocorre sempre à direita das atribuições e a variável Saída
ocorre sempre à esquerda das atribuições. Quando um valor é atribuído à Saída, va-
lores adicionais de controle são fornecidos que determinam um dispositivo de saída
(impressora, tela do computador, etc.) e um formato apropriado de apresentação de
um valor. Nesse caso, em vez de o resultado de uma operação ser armazenado em
um local específico pelo nome da variável, ele é enviado para o dispositivo de saída
com o formato especificado. De maneira similar, os valores da variável Entrada são
obtidos de algum dispositivo de entrada (teclado, mouse, etc.). A verificação de con-
sistência de tipos ocorre normalmente também para essas variáveis [16].
69
3.5.3 CONTROLE
Os programas procedurais são uma seqüência ordenada de comandos.
Um comando de controle reconhece o estado da máquina representada pelo progra-
ma e permite determinar a seqüência de execução dos comandos.
Sem comandos de controle, os comandos de atribuição de um programa
são executados na seqüência em que são apresentados no programa. Existem duas
categorias de comandos de controle: seleção e iteração.
3.5.3.1 Seleção
As instruções de seleção permitem escolher entre duas ou mais seqüênci-
as de instruções a serem executadas nos programas e são fundamentais às lingua-
gens de programação.
O comando de seleção é composto por três partes [16]:
a) Um teste;
b) Um comando ou bloco de comandos que é executado se o resulta-
do do teste for verdadeiro;
c) Um comando ou bloco de comandos que é executado se o resulta-
do do teste for falso.
A figura 3.14 mostra, em pseudocódigo, a estrutura do um dos comandos
de seleção existentes.
Figura 3.25: Estrutura do comando de seleção
70
As linguagens de programação procedurais, em sua maioria, apresentam
uma variedade de comandos de seleção, para comodidade do programador. Os co-
mandos são todos sinônimos, no sentido que para qualquer trecho de programa que
utiliza algum dos comandos de seleção, podemos escrever um trecho de programa
utilizando outro comando de seleção que atribui valores equivalentes às mesmas va-
riáveis.
3.5.3.2 Iteração
Os comandos iterativos fazem com que uma instrução, ou um conjunto de
instruções, seja executada nenhuma, uma ou várias vezes. Esses comandos possu-
em basicamente o corpo do comando (conjunto de instruções a serem executadas)
que deve ser executado repetidas vezes, e mais uma expressão de controle que de-
termina quando o corpo do comando deve ser executado, o controlador do laço.
O comando de iteração é composto de duas partes [16]:
a) Um teste;
b) Um comando ou bloco de comandos que é executado repetidamen-
te enquanto o resultado do teste for verdadeiro. O teste é reavaliado
ao final da execução comando ou bloco de comandos.
A figura 3.15 mostra, em pseudocódigo, a estrutura do um dos comandos
de repetição existentes.
Figura 3.26: Estrutura do comando de repetição [16]
71
No exemplo acima, se os valores de x, y, e de z são do tipo inteiro, ao final
da execução do trecho do programa o valor de y é xx (assumindo que o valor forneci-
do para x é maior que 0).
Assim como ocorre com os comandos de seleção, as linguagens de pro-
gramação procedurais, em sua maioria, apresentam uma variedade de comandos si-
nônimos de repetição, para comodidade do programador.
3.6 MODULARIDADE
A possibilidade de impor uma estrutura modular a um programa por ser
muito útil. Essa estrutura pode permitir [16]:
• A determinação de um escopo restrito para cada nome de variável.
• A associação de nomes a trechos do programa utilizados com freqüência,
que podem então passar a ser invocados por esses nomes.
• A separação do programa em trechos menores, que podem ser compila-
dos separadamente e até mesmos executados de forma concorrente.
Uma unidade de programa por ser composto por [16]:
• Uma interface, que pode conter um nome para o módulo e a especificação
dos parâmetros de entrada e de saída do módulo (ou seja, variáveis com
escopo restrito ao módulo cujos valores são importados para o módulo ou
exportados a partir dele).
• A declaração de itens de escopo local ao módulo (variáveis, constantes e
tipos). Esses existem somente enquanto o módulo é executado.
• Uma seqüência de comandos, incluindo comandos de controle.
Unidade de programa é um nome genérico que se aplica a diversas estru-
turas de programa. A forma mais simples e comum às linguagens de programação
procedurais são os blocos, procedimentos e funções.
72
3.6.1 BLOCOS
Um bloco é uma seqüência de comandos (incluindo comandos de contro-
le) delimitada por um marcador de início e um marcador de fim de bloco. Um bloco
não tem um nome nem parâmetros de entrada e saída. Essencialmente, blocos são
os subprogramas associados aos comandos de seleção e iteração.
Um bloco é executado quando o controle da execução do programa atinge
o seu marcador de inicio. O término da execução do bloco ocorre quando o controle
de sua execução atinge o marcador de fim.
A maioria das linguagens de programação procedurais permite o aninha-
mento de blocos.
3.6.2 PROCEDIMENTOS E FUNÇÕES
As abstrações de procedimentos são realizadas por uma série de coman-
dos que provocam mudanças sucessivas nos valores de suas variáveis. Elas são
denotadas pelas suas definições e classificadas como abstrações de processos por
descreverem um comportamento computacional. O usuário destas não precisa co-
nhecer os passos internos de sua computação, mas apenas a mudança de estado
do programa provocado por elas. A chamada de um procedimento é observada pelo
usuário apenas como uma mudança no estado do programa influenciado pelos argu-
mentos fornecidos por ele. A maioria das linguagens de programação procedurais
possui formas de abstrair procedimentos.
Uma função é representada por uma expressão que denota o comporta-
mento do mapeamento entre um domínio e a imagem da função. A aplicação de
uma função resulta em um valor: o elemento da imagem relacionado com o dado
elemento do domínio. O usuário de uma função observa apenas o valor resultado,
em vez dos passos de avaliação da expressão. Exemplos de abstrações de funções
podem ser encontrados nas várias linguagens de programação procedurais.
73
Procedimentos e funções são muito similares a blocos, exceto que eles
têm nomes e parâmetros. Um nome de procedimento é inserido na seqüência de co-
mandos de um programa como se fosse um comando da própria linguagem de pro-
gramação. Quando o controle da execução do programa atinge o nome do procedi-
mento, o procedimento correspondente é ativado.
Quando um procedimento é ativado, o controle do programa é transferido
para o procedimento e passa a executá-lo até atingir o seu marcador de fim de pro-
cedimento. Quando isso acontece, o controle do programa é devolvido ao programa
que ativou o procedimento e continua a sua execução normalmente.
Uma função é um procedimento que, quando atinge seu marcador de fim,
retorna para o programa ativador um valor. Esse valor é retornado como o valor de
uma variável cujo nome coincide com o nome da função, e o controle é devolvido ao
programa ativador no ponto de chamada da função, ou seja, no ponto onde ocorre o
nome da função no programa ativador. Esse ponto pode inclusive fazer parte de
uma expressão.
Além de permitir que repetições de sequências de comandos idênticas se-
jam evitadas, a utilização de subprogramas permite que um programa seja escrito
em módulos, o que possibilita as seguintes vantagens [28]:
1) Maior legibilidade do programa.
2) O programa pode ser desenvolvido em equipe, cada membro se encarregan-
do do desenvolvimento de alguns de seus subprogramas.
3) A validação do programa através de testes pode ser realizada testando-se
cada um dos subprogramas isoladamente, o que facilita a detecção e identifi-
cação de erros de lógica.
4) Atualizações posteriores do programa (atos chamados genericamente de ma-
nutenção de programa) são facilitadas, pelo fato de que apenas atualizações
em alguns subprogramas são requeridas.
74
3.6.3 PARÂMETROS
Procedimentos e funções utilizam parâmetros para comunicar valores. Os
parâmetros são chamados de parâmetros de entrada quando os seus valores são
atualizados dentro do procedimento ou função, e de parâmetros de saída quando os
seus valores são os resultados fornecidos pelo procedimento ou função para o pro-
grama ativador [16].
Denominamos de parâmetros formais os parâmetros da declaração de
uma função ou procedimento e chamamos de parâmetros atuais os parâmetros na
ativação da função ou procedimento.
Existem duas maneiras de relacionar parâmetros formais e parâmetros
atuais [16]:
1) Relacionamento por palavra-chave: o mesmo nome de variável deve ser utili-
zado para relacionar um parâmetro formal e um parâmetro atual. Antes de ati-
var uma função ou procedimento, a variável com nome apropriado de receber
o valor desejado.
2) Relacionamento posicional: a posição de cada parâmetro nas seqüências de
parâmetros formais e atuais determina o seu relacionamento. Assim, o valor
do primeiro parâmetro atual é transmitido para o primeiro formal, o valor do
segundo parâmetro atual é fornecido para o segundo formal, e assim por di-
ante.
Existem também diversos métodos para efetivamente passar parâmetros
para procedimentos e funções. Os métodos mais utilizados são [16]:
• Passagem por valor: o valor de cada parâmetro atual é calculado no
contexto do programa ativador, e então transmitido para o parâmetro
formal correspondente. O parâmetro formal passa a atuar como uma
variável com escopo local ao módulo ativado, cujo valor inicial é aquele
determinado pelo parâmetro atual.
• Passagem por referência: o valor de cada parâmetro atual é uma refe-
rência para o próprio local onde são armazenados os valores de uma
variável. Uma referência explícita ao valor armazenado naquele local
permite a consulta e atualização daquele valor, independente do esco-
75
po do módulo. Essa é a maneira mais comum de possibilitar que um
procedimento atualize valores de variáveis, de forma que esses valores
sejam visíveis para o programa ativador.
3.7 LINGUAGENS DE PROGRAMAÇÃO PROCEDURAIS
Devido ao grande sucesso do paradigma PP que foi o mais utilizado até a
década de 90, muitos dos sistemas comerciais atuais foram implementados com lin-
guagens procedurais e ainda tantos outros continuam sendo desenvolvidos nestas
linguagens [25].
Uma linguagem de programação que utiliza o paradigma PP manipula va-
riáveis a partir de ordens ou comandos. As variáveis são lidas na entrada, são mani-
puladas e colocadas em outras variáveis, ditas saídas, manipulando estados [22].
As linguagens no paradigma PP têm sido usadas nas várias áreas de apli -
cações. Grande parte da automação bancária, projetos científicos em universidades
e órgãos de pesquisas utilizam linguagens procedurais [16]. Alguns exemplos de lin-
guagens baseadas no paradigma PP são FORTRAN, COBOL, ALGOL, BASIC, Pas-
cal, C e Ada, entre outras. [9].
76
4 PROGRAMAÇÃO ORIENTADA A OBJETOS
Neste capítulo serão expostas as principais idéias do paradigma progra-
mação orientada a objetos, bem como os conceitos básicos para sua compreensão:
abstração, objeto, classe, atributo, método, encapsulamento, herança e polimorfis-
mo. Por último, citamos algumas linguagens de programação que oferecem suporte
à orientação a objetos.
4.1 CONCEITOS FUNDAMENTAIS
Na compreensão do mundo real, as pessoas empregam constantemente
três métodos de organização, sempre presentes em todos os seus pensamentos
[29]:
1. Diferenciação, baseada na experiência de cada um, de objetos particulares e
seus atributos;
2. Distinção entre objetos como um todo e entre suas partes componentes;
3. Formação de, e distinção entre, as diferentes classes de objetos.
O paradigma Programação Orientada a Objetos (POO) se apóia nestes
três métodos usuais de organização. No paradigma POO a programação é imple-
mentada pelo envio de mensagens a objetos [29].
Pelo fato de muitos dos problemas solucionáveis computacionalmente es-
tarem intrinsecamente relacionados ao mundo composto por objetos, o paradigma
POO propõem a concepção de sistemas computacionais por meio da composição e
relacionamentos entre entidades computacionais chamadas de objetos [31].
A idéia básica do paradigma POO é imaginar que programas simulam o
mundo real, baseados em objetos, onde esses objetos possam enviar e receber
mensagens e reagir a mensagens recebidas [6, 22, 23].
77
Ao trabalharmos com orientação a objetos é fundamental entender o con-
ceito de classes e objetos. Uma classe é uma estrutura de define um tipo de dados,
podendo conter atributos (variáveis) e também funções (métodos) para manipular
esses atributos. Um objeto contém exatamente a mesma estrutura e as proprieda-
des de uma classe, no entanto sua estrutura é dinâmica, seus atributos podem mu-
dar de valor durante a execução do programa e podemos declarar diversos objetos
oriundos de uma mesma classe [36].
O paradigma POO tem como princípio à solução de problemas pela coo-
peração de vários elementos. As linguagens de POO permitem a criação de objetos,
os quais são entidades computacionalmente ativas que guardam um conjunto de da-
dos (os atributos), e os serviços (os métodos) que ele pode prover. Para proporcio-
nar a colaboração computacional dos objetos, deve-se também ter meios para fazer
a comunicação entre eles (as mensagens) [16].
Os principais fundamentos das linguagens de programação com o objetivo
de prover objetos estão centrados nos conceitos de abstrações. Cada objeto é um
elemento abstrato responsável pelo seu estado e faz as transformações sobre tal es-
tado mediante um conjunto fixo de regras de comportamento. A definição do conjun-
to de dados que um objeto deve conter (os atributos), bem como das regras de
transformação sobre esses dados (os métodos) devem ser definidos como um tipo
abstrato (as classes). Assim, a unidade de definição dos tipos abstratos são as clas-
ses e a ativação ou uso de um elemento daquele tipo é um objeto. Desta forma,
cada objeto encapsula os seus dados e todas as suas possíveis transformações, en-
quanto as classes são o elemento de definição [16].
Na POO, existem certas características (herança e encapsulamento) que
permitem que, quando for necessária alguma alteração, modifique-se apenas o obje-
to que necessita dessa alteração, e ela propagar-se-á automaticamente às demais
partes do software que utilizam este objeto. O conceito de orientação a objetos for-
nece também possibilidade de um objeto acessar e usar como se fossem seus, os
métodos e a estrutura de outros objetos [29].
A POO reduz a complexidade e a manutenção dos produtos desenvolvi-
dos (os softwares) e possibilita uma maior produtividade por meio da reutilização de
produtos de projetos anteriores. Permite, também, escalabilidade, isto é, possibilita a
78
evolução incremental do sistema e conceitualmente está relacionada com as tecno-
logias de Interface Gráfica e Cliente-Servidor [30].
A computação de um programa orientado a objetos pode ser visto como a
ativação de objetos, mediante a sua criação, e colaboração entre esses objetos ati-
vos. Como cada objeto é responsável pelos seus próprios dados (estado) e transfor-
mações (encapsulamento dos métodos), o estado do programa pode ser claramente
visto como o conjunto de estados dos objetos ativos. A solução computacional de
um problema nesse paradigma pode ser reduzida a definir: quais objetos são neces-
sários e como eles devem cooperar entre si. Assim, os objetos passam a ser unida-
des computacionais claramente independentes, com seus próprios dados e compor-
tamento, e resolver o problema significa resolver cada uma dessas unidades junta-
mente com a comunicação entre elas [16].
Os objetos do paradigma POO abstraem os objetos do mundo, apresenta-
do somente às características pertinentes para a implementação das soluções com-
putacionais [9].
4.2 ABSTRAÇÃO
Na sua segunda definição, o dicionário Aurélio [5, p.18] atribui o significa-
do para abstração como “ato de separar mentalmente um ou mais elementos de
uma totalidade complexa (coisa, representação, fato), os quais só mentalmente po-
dem subsistir fora dessa totalidade “. Ou seja, partimos do enfoque global de um de-
terminado problema e procuramos separar os elementos fundamentais e colocá-los
de uma forma mais próxima da solução [32].
A idéia da abstração é identificar os elementos essenciais de um problema
e suas propriedades fundamentais, separando ocorrências e atributos acidentais
[32].
A abstração constitui-se em um processo mental através do qual o ser hu-
mano modela uma entidade, isolando as características importantes, tendo por obje-
tivo a redução de sua complexidade [33]. A figura 4.1 mostra o processo de abstra-
ção.
79
Figura 4.27: O processo de abstração [33]
O processo de construção de um modelo para resolução de um problema
envolverá sempre um processo de abstração, alias, o modelo será o resultado dessa
abstração, como mostra a figura 4.1.
O problema da complexidade é até certo ponto resolvido lidando com a
abstração. O problema é dividido em subproblemas, em seguida, novamente em
subproblemas e assim por diante, até que os problemas individuais se tornem sufici-
entemente pequenos para serem fáceis de lidar com eles. Resolvendo um dos sub-
problemas, não pensamos mais sobre os detalhes dessa parte, mas tratamos a solu-
ção como um simples bloco de construção para o nosso próximo problema. Essa
técnica é às vezes referida como dividir para conquistar [35].
Para a Análise Orientada a Objeto (AOO), abstração é o processo de iden-
tificação dos objetos e seus relacionamentos. Ela permite ao programador concen-
trar-se no que um objeto é e faz, sem se preocupar como ele o faz [32].
4.3 OBJETO
Objetos são compreendidos como elementos ativos (por exemplo, pessoa
e pássaro) ou inativos (por exemplo, mesa e porta) que compõem o mundo real, o
abstrato e o abstrato-informático (por exemplo, arquivo, tabela e botão de uma inter-
face gráfica) [9]. Um objeto é uma entidade concreta que apresenta um comporta-
mento bem definido. O comportamento é estimulado pelo recebimento de mensa-
gens ao objeto. Objetos são, portanto, qualquer coisa do mundo real que pode ser
modelado [30].
80
Um objeto possui determinadas propriedades que o caracterizam e que
são armazenadas no próprio objeto. As propriedades de um objeto são chamadas
de atributos. O objeto interage com o meio e, em funções de excitações que sofre,
realiza determinadas ações que alteram o seu estado (seus atributos). Os atributos
de um objeto não são estáticos, pois sofrem alterações com o tempo [32].
De maneira simples, um objeto é uma entidade lógica que contêm dados e
código para manipular esses dados. Os dados denominados como sendo atributos
do objeto, ou seja, a estrutura que o objeto possui, e o código que o manipula, deno-
minado método. Um método é uma função que manipula a estrutura de dados do
objeto [29].
Para a AOO, um objeto é uma entidade única que reúne atributos e méto-
dos, ou seja, reúne as propriedades do objeto e as reações às excitações que sofre.
Quando temos uma instância de uma classe, possuímos um objeto dessa classe.
Instância é outro nome que se dá ao objeto, geralmente se refere a um objeto espe-
cífico [32].
4.4 CLASSES
Classe é o termo técnico utilizado em linguagens orientadas e objetos que
descreve um conjunto de dados estruturados que são caracterizados por proprieda-
des comuns. Também pode ser interpretado como uma estrutura modular completa
que descreve as propriedades estáticas e dinâmicas dos elementos manipulados
pelo programa [29]. A estrutura de uma classe é estática e é utilizada para descrever
objetos mediante atributos (propriedades) e métodos (funcionalidades) [36].
Uma classe descreve um grupo de objetos com os mesmos atributos e
comportamentos, além dos mesmos relacionamentos com outros objetos. Ela con-
tém a descrição da forma do objeto e pode ser entendida como um molde para a cri-
ação do objeto, ou uma matriz geradora de objetos, ou ainda uma fábrica de objetos
[32].
A classe contém a descrição das propriedades (conjunto de atributos) e
comportamento (conjunto de operações) de um determinado tipo de objeto. A classe
81
pode ser identificada como um modelo para a criação de objetos em tempo de exe-
cução dos programas. Sendo assim, cada objeto é uma instância de uma classe. Ou
seja, instanciar uma classe é criar um novo objeto da classe [30]. A figura 4.2 mostra
a representação de uma classe.
Figura 4.28: Representação de uma classe [32]
Podemos observar na figura 4.2 que os atributos e métodos podem ou não
ser incluídos. Uma representação mais detalhada dos atributos engloba sua visibili -
dade, seu tipo e valor, da mesma forma, podem-se detalhar os métodos, incluindo
os parâmetros, o retorno e o tipo de acesso.
Com relação à visibilidade dos atributos e dos métodos, a composição das
classes, relativa a mensagens, é dividida em três partes [30] (veja figura 4.3):
• Public: todas as características e métodos declarados como Public, po-
dem ser acessados por qualquer outro objeto. Na figura 4.2 tal visibili-
dade é graficamente simbolizada com +.
• Private: todas as características e métodos declarados como Private,
não estão disponíveis para outros objetos. Na figura 4.2 tal visibilidade
é graficamente simbolizada com -.
82
• Protected: todas as características e métodos declarados como Protec-
ted, só são visíveis pelas classes herdeiras. Na figura 4.2 tal visibilida-
de é graficamente simbolizada com #.
Figura 4.29: Esquema de uma classe [30]
Para a AOO, uma classe é um conjunto de códigos de programação que
incluem a definição dos atributos e dos métodos necessários à criação de um ou
mais objetos [32].
4.5 ATRIBUTOS
Um atributo é um dado para o qual cada objeto tem seu próprio valor. Atri -
butos são, basicamente, a estrutura de dados que vai representar a classe [29]. Os
atributos de um objeto definem a composição deste objeto e podem ser modelados,
dependendo do contexto, como simples valores ou como outros valores objetos [33].
Podemos relacionar alguns atributos (propriedades) a todo objeto. Na
POO, os atributos são definidos na classe e armazenados de forma individual ou co-
letiva pelos objetos. Na forma individual, o atributo é armazenado no objeto, sendo
que na forma coletiva, o atributo é armazenado na classe e dividido entre todos os
objetos daquela classe [32].
83
4.6 MÉTODOS
Métodos são declarados dentro de uma classe para representar as opera-
ções que os objetos pertencentes a esta classe podem executar [29].
Determinados comportamentos, ações e reações podem ser relacionados
a um objeto. Na AOO, as ações e os comportamentos dos objetos são descritos pe-
los métodos, ou seja, os métodos servem para manipular e alterar os atributos do
objeto (altera o estado do objeto) [32]. Os métodos podem ser classificados em [30]:
1. Modificador: altera o estado do objeto.
2. Recuperador: acessa o estado sem alterá-lo (read-only).
3. Construtor: possibilita a criação de instâncias, isto é, aloca espaço e cria um
objeto.
4. Destruidor: destrói as instâncias, antes de desalocar o espaço permite algu-
mas ações.
Com exceção dos métodos Modificadores e Recuperadores, que podem existir
mais de um, os métodos Construtor e Destruidor, podem ou não existir uma única
vez na vida de um objeto [30].
4.7 ENCAPSULAMENTO
O encapsulamento é o ocultamento de uma seleção de atributos e méto-
dos dos objetos para o acesso externo. Esta propriedade evita que certas partes de
um objeto se tornem desnecessariamente acessíveis a outros [9]. A teoria da orien-
tação a objetos reza que o único meio de manipular o estado de um objeto é através
das operações associadas a ele [34], logo, o objetivo do encapsulamento é “escon-
der” o estado do objeto e a implementação das operações [30].
A proposta do encapsulamento consiste em que, quanto menos as diferen-
tes partes de um sistema souberem umas das outras, mais fácil será a manutenção
desse sistema [30].
84
O conceito de encapsulamento é decorrente do fato de se combinar os da-
dos (atributos) e o código que manipula estes dados (métodos) em um único objeto.
Ele garante que a única forma de acesso aos dados é através dos métodos disponí-
veis ao usuário (chamados públicos). Os demais métodos e os atributos da classe fi-
cam sendo privados, ou seja, apenas funções-membro da classe têm acesso direto
aos mesmos [29]. A figura 4.4 ilustra o funcionamento do encapsulamento de um ob-
jeto.
Figura 4.30: Encapsulamento de um objeto [29]
Para a AOO, encapsulamento é o ato de esconder do usuário informações
que não são de seu interesse. O objeto atua como uma caixa preta, que realiza de-
terminada operação, mas o usuário não sabe, e não precisa saber, exatamente
como é feita. Ou seja, o encapsulamento envolve a separação dos elementos visí-
veis de um objeto dos invisíveis [32].
4.8 HERANÇA
A herança permite reusar a estrutura de classes já definidas em classes
derivadas, contribuindo para reusar a quantidade de código a ser elaborado pelo
programador. A herança é uma solução típica para prover o reuso [9], pois permite
que as características comuns de um grupo de objetos diferentes sejam concentra-
das em uma única classe [34].
85
A herança está relacionada às hierarquias e às relações entre os objetos.
Ela permite implementar classes descendentes descrevendo os métodos e atributos
que se diferenciam da classe pai. Herança, portanto, é a propriedade de podermos
criar classes que se ampliam de classes mais simples e genéricas, para classes
mais complexas e específicas [32]. A figura 4.5 mostra a representação de uma he-
rança em uma classe.
Figura 4.31: Representação de uma herança [32]
Podemos observar na figura 4.5 que a classe-base é mais genérica, e as
classes derivadas são especificações da classe-base.
Conceitualmente, uma classe criada como subclasse de outra herda todas
as definições da classe superior (classe-pai), e todas as outras superiores na hierar-
quia. Além disso, novos elementos podem ser criados na subclasse como, por
exemplo, novos métodos e variáveis, ou ainda fazer uma sobrecarga dos elementos
existentes [16].
As heranças podem ser de dois tipos: herança simples e herança múltipla.
Na herança simples, a classe herda as propriedades de uma única classe-pai, já na
herança múltipla, a herança ocorre quando uma classe tem mais de um pai [32].
Na AOO, herança é o mecanismo em que uma classe-filha (classe-deriva-
da) compartilha automaticamente todos os métodos e atributos de sua classe-pai
(classe-base) [32].
86
4.9 POLIMORFISMO
O polimorfismo refere-se a definições de métodos que aparentemente se
apresentam similares, mas que apresentam comportamentos diferentes segundo o
subtipo de cada objeto [9]. Polimorfismo é a propriedade de uma ou mais classes
responderem a mesma mensagem, cada uma de uma forma diferente [29]. A figura
4.6 mostra a implementação do polimorfismo.
Figura 4.32: Implementação do polimorfismo
A palavra polimorfismo significa muitas formas e representa o fato de uma
determinada característica ser diferente para cada filho. Em suma, estamos partindo
de um objeto mais simples e evoluindo. Apesar disto, os conceitos do objeto-pai con-
tinuam a existir nos objetos descendentes, mesmo que tenham sofrido modificações,
aperfeiçoamentos e assumido novas formas (polimorfismo) [32].
87
4.10 LINGUAGENS DE PROGRAMAÇÃO ORIENTADAS A OBJETOS
As linguagens de POO foram criadas, juntamente com os seus ambientes,
para dar suporte ao desenvolvimento de sistemas mais complexos, e por isso têm
sido aplicadas em novos sistemas comerciais. O uso crescente dessas linguagens
se dá principalmente pelo desenvolvimento de novas metodologias de sistemas que
empregam o paradigma POO. A maioria dos sistemas atuais para Web é desenvolvi-
da nesse paradigma [16].
A POO é suportada atualmente por um conjunto de linguagens e proces-
sos de modelagem, fiéis ao paradigma POO, que antecedem a atividade de progra-
mação no chamado ciclo de engenharia de software. Dentre elas, a linguagem mais
popular é a UML (Unified Modeling Language) [9].
As linguagens de programação que materializam o paradigma POO são a
Simula, Smalltalk, C++, Java, Object Pascal, Objectice-C, Eiffel, Python, PHP4 (Php:
Hypertext Preprocessor) a partir da versão 3, Ruby, C#, entre outras.
4 PHP foi criada em 1994 para a criação de páginas dinâmicas utilizando scripts e posteriormente fo-
ram adicionadas novas funcionalidades que permitiam desenvolver de forma simples aplicações para
Web e nomeou essa versão como PHP/FI (Personal Home Pages/Forms Interpreter). Em 1997 foi
lançada a segunda versão denominada PHP/FI 2. Novas características foram adicionadas a segunda
versão como: extensibilidade, possibilidade de conexão com vários bancos de dados, novos protoco-
los, sintaxe mais consistente, suporte à orientação a objetos e uma nova API (Application Program-
ming Interface), dando origem a uma nova versão denominada PHP 3. A partir dessa versão o signifi -
cado da sigla PHP mudou para PHP: Hypertext Preprocessor. O PHP 4 foi lançado em 2000 e o PHP
5 foi lançado em 2004, trazendo de um maior suporte à orientação a objetos [36].
88
5 PROGRAMAÇÃO ORIENTADA A ASPECTOS
Neste capítulo é abordado o paradigma Programação Orientada a Aspectos
(POA). Inicialmente são apresentados os conceitos fundamentais e posteriormente
tópicos importantes como: aspects, joinpoints, pointcuts e advices, bem como a im-
plementação dos aspectos são discutidos. Finalmente, aborda-se, resumidamente, a
linguagem de aspecto denominada AspectJ.
5.1 CONCEITOS FUNDAMENTAIS
Com a evolução das tecnologias o produto software tem se tornado cada
vez mais importante para as organizações, sendo que atualmente inúmeras tarefas
não seriam possíveis de serem realizadas sem a presença de um sistema de infor-
mação que as automatizassem. Neste âmbito, a tarefa de desenvolver software tor-
na-se cada vez mais complexa e, felizmente, a engenharia de software vem para
propiciar a desenvolvedores um melhor arcabouço na desgastante tarefa de agregar
ao software a maior qualidade possível [38].
A engenharia de software se ocupa de todos os aspectos da produção do
software, desde os estágios iniciais de especificação do sistema até sua manuten-
ção, depois que ele entrou em operação. A figura 5.1 ilustra a divisão da engenharia
do software.
Figura 5.33: Divisão da Engenhara de Software [38]
89
A figura 5.1 demonstra como a engenharia de software é uma tecnologia
que pode ser dividida em três camadas [38]. Os métodos constituem a técnica de
“como fazer” para construir softwares, os processos (procedimentos) são uma espé-
cie de adesivo que mantém juntos os métodos e as ferramentas e permitem o de-
senvolvimento racional e oportuno do software e por fim, as ferramentas fornecem
apoio automatizado ou semi-automatizado para os métodos [46].
A engenharia de software e as linguagens de programação coexistem em
um relacionamento de suporte mútuo. A maioria dos processos de desenvolvimento
de software considera um sistema em unidades (módulos) cada vez menores. As lin-
guagens de programação, por sua vez, fornecem mecanismos que permitem a defi-
nição de abstrações de unidades de sistemas e a composição destas de diversas
formas possíveis à produção do sistema como um todo [37, 43, 53].
O advento do paradigma POO trouxe grandes avanços para o desenvolvi-
mento de software, permitindo a construção de sistemas mais fáceis de serem proje-
tados, maior reusabilidade de componentes, modularidade, implementações menos
complexas e redução do custo de manutenção. Muitas aplicações não estão em
apenas um único módulo de código contido em um único arquivo. Aplicações são
coleções de módulos (classes) que trabalham juntas para fornecer determinadas
funcionalidades para um conjunto de requisitos bem definidos [47]. Porém, existem
certas propriedades que se pretende programar em um sistema que não são ade-
quadamente encapsuladas em classes, seja porque se aplicam as diversas classes
de um sistema simultaneamente, seja porque não pertencem à natureza intrínseca
da(s) classe(s) a(s) qual (is) se aplicam. A dificuldade de modularizar alguns tipos de
funcionalidades causa um acúmulo de responsabilidade adicional que o projeto da
classe não previa, ocasionando um entrelaçamento da responsabilidade inicial - in-
trínseca da classe – com responsabilidade extra [43].
Quando abordagens orientadas a objetos são utilizadas para o desenvolvi-
mento de sistemas complexos, nota-se que os seus requisitos não são claramente
separados em um nível adequado. Isso acontece porque existem propriedades que
não devem ser encapsuladas totalmente numa unidade funcional, como uma classe,
pois participam de várias dimensões do sistema, várias classes [38].
No desenvolvimento de software existem propriedades que não se enqua-
dram em componentes da decomposição funcional, tais como: tratamento de exce-
90
ções, restrições de tempo real, distribuição e controle de concorrência. Elas normal-
mente estão aplicadas em diversos componentes do sistema afetando a performan-
ce ou a semântica da aplicação [37].
Devido ao entrelaçamento de responsabilidades (crosscutting) de uma
classe, surge o paradigma Programação Orientada a Aspectos (POA). A implemen-
tação dos aspectos fornece subsídio a POO para tratar de tais responsabilidades ex-
tras através da decomposição funcional da classe [48]. O aspecto consiste de carac-
terísticas estruturais e/ou comportamentais que devem ser adicionadas a diversas
partes do sistema, mas que são projetadas e codificadas separadamente. Quando o
sistema é compilado os aspectos combinam as responsabilidades extras, ou ortogo-
nais, com as responsabilidades intrínsecas de cada módulo afetado, fazendo com
que todas as responsabilidades apresentem as propriedades pretendidas sem com-
prometer a coerência de cada módulo [49].
O paradigma POA surgiu da carência que os paradigmas atuais apresen-
tam em relação a uma separação adequada dos interesses comuns, pois atualmente
muitas vezes ocorre o entrelaçamento entre interesses distintos no sistema [51].
Esse entrelaçamento causa dificuldade no desenvolvimento, na manutenção e no
reuso de partes do código-fonte [38, 45].
O paradigma POA procura solucionar a ineficiência em capturar algumas
das importantes decisões de projeto que um sistema deve implementar. Essa dificul-
dade faz com que a implementação destas decisões de projeto sejam distribuídas
pelo código, resultando num entrelaçamento e espalhamento do código com diferen-
tes propósitos. Este entrelaçamento e espalhamento tornam o desenvolvimento e a
manutenção destes sistemas extremamente difícil. Desta forma, POA aumenta a
modularidade separando código que implementa funções específicas, afetando dife-
rentes partes do sistema, chamadas preocupações ortogonais (crosscutting concern)
[37, 38, 45]. Exemplos de crosscutting concern são: persistência, distribuição, con-
trole de concorrência, tratamento de exceções e depuração [40]. O aumento da mo-
dularidade implica em sistemas legíveis, os quais são mais facilmente projetados e
mantidos [44, 43]. A figura 5.2 ilustra o código entrelaçado resultante da implementa-
ção de características de natureza ortogonal da aplicação [40].
91
Figura 5.34: Código entrelaçado [40]
As aplicações estão ampliando os limites das técnicas de programação
atuais, de modo que certas características de um sistema afetam seu comportamen-
to de tal forma que as técnicas atuais não conseguem capturar essas propriedades
de forma satisfatória. Estas propriedades não deixam de ser importantes para a apli-
cação e acabam sendo inseridas no código dos componentes em formas mais ou
menos arbitrárias [50].
A POA visa reduzir algumas limitações encontradas na orientação a obje-
tos, como o espalhamento e entrelaçamento de código. Isto é feito através do en-
capsulamento das preocupações ortogonais (crosscutting concerns) em módulos
chamados aspectos [45].
A POA permite que a implementação de um sistema seja separada em re-
quisitos funcionais e não-funcionais. Dos requisitos funcionais resulta um conjunto
de componentes expressos em uma linguagem de programação atual, por exemplo,
92
Java. Já dos requisitos não-funcionais, resultam um conjunto de aspectos (crosscut-
ting concerns) relacionados às propriedades que afetam o comportamento do siste-
ma. Com o uso da abordagem, os requisitos não-funcionais podem ser facilmente
manipulados sem causar impacto no código de negócio (requisitos funcionais), uma
vez que estes códigos não estão entrelaçados e espalhados em várias unidades do
sistema. Desta forma, POA possibilita o desenvolvimento de programas utilizando
tais aspectos, o que inclui isolamento, composição e reuso do código de implemen-
tação dos aspectos [44].
Com a POA, o desenvolvedor precisa preocupar-se apenas em desenvol-
ver códigos referentes às regras de negócios inerentes aos métodos e às classes do
programa, não se preocupando com outras funções básicas e de igual importância
ao funcionamento do sistema, como o tratamento de exceções, permissões de aces-
sos às rotinas, auditoria, concorrência, dentre muitas outras [41, 43].
Em POA, alguns conceitos diferentes dos encontrados nos demais para-
digmas são evidenciados, tais como: aspects, joinpoints, pointcuts e advices [38].
É importante salientar que a POA não propõem substituir nenhum dos pa-
radigmas já existentes, e sim, acrescentar suporte a modularização das proprieda-
des relativas ao crosscutting concerns (assuntos que entrecortam o sistema) [41,
43].
5.2 CROSSCUTTING CONCERN
O termo crosscutting concern é utilizado para definir quando um código
participa em várias unidades no sistema [56]. Crosscutting concerns são nada mais
que funcionalidades de um programa, que não podem ser encapsuladas numa clas-
se ou objeto [42].
Quando duas propriedades sendo programadas devem ser compostas de
maneira diferente e ainda se coordenarem é dito que elas são ortogonais entre si.
Essas propriedades são conhecidas como interesses ortogonais (crosscut-con-
cerns). Ao tentar-se implantar estes interesses ortogonais pelo sistema, obtêm-se
código emaranhado. Pode-se afirmar que o principal objetivo da POA é separar o
93
código referente ao negócio do sistema, dos interesses não inerentes ao negócio, de
uma forma centralizada [39]. A figura 5.3 exemplifica a separação e centralização
dos interesses ortogonais.
Figura 5.35: Separação de interesses com POA [39]
O trabalho de organizar os requisitos de software em nichos de funcionali-
dades, interesse, preocupações e responsabilidades, denomina-se separação de
preocupações ou interesses (separation of concerns). A atividade de separação de
interesses é facilitada pela POA com certa elegância, através de um mecanismo
para descrição de comportamentos de aparecem espalhados por vários componen-
tes (crosscutting concerns) [51].
Considerando aspectos no desenvolvimento de software, pode-se então
separar ou modularizar diferentes preocupações do desenvolvimento, tais como:
persistência de dados, interface, segurança, distribuição, auditoria, registros de logs,
controle de concorrência, tratamento de erros e outros, que aparecem na POO espa-
lhados ao longo do código [51]. A figura 5.4 ilustra como o espalhamento e o entrela-
çamento são tratados na POA.
94
Figura 5.36: Composição de aspectos a partir de atributos e métodos espalhados pelas classes [51]
O espalhamento e o entrelaçamento é o fenômeno no qual a implementa-
ção de uma ou mais propriedades mistura-se à implementação de um ou mais com-
ponentes do sistema. Esse fenômeno é tratado na POA através da composição de
aspectos com interesses encontrados em várias classes – chamados interesses
transversais (crosscutting concerns) [51].
5.3 ASPECT
Um aspecto deve ser visto como um componente que contém uma estru-
tura de pointcuts (um conjunto de pontos de junção declarados) que podem conveni-
entemente executar advices (outra função que não pertence ao fluxo normal do pro-
grama) [51, 52, 42]. Cada aspecto define uma função específica que pode afetar vá-
rias partes de um sistema, como, por exemplo, distribuição [37, 44]. Pode-se consi-
derar que cada aspect se associa a um crosscutting concerns, com o objetivo de
agrupar os concerns [42].
Aspects possuem semelhanças e diferenças com as classes na POO.
Como semelhanças: podem ser estendidos, abstratos ou concretos e possuem um
tipo, atributos e métodos. Como diferenças: não possuem um construtor, destruidor
e podem conter pointcuts e advices como atributos [38].
95
5.4 JOINPOINT
Os joinpoints (pontos de junção) constituem um ponto bem definido no flu-
xo de execução de um programa para controlar o fluxo interrompendo o seu curso
natural para inserção de novas rotinas ou funções [38, 37].
Os pontos de junção compõem a base da POA. Utilizando-se de joinpoin-
ts, determinam-se quais os métodos terão suas chamadas e/ou execuções intercep-
tadas, aplicando-se comparação de assinatura dos métodos. Além das assinaturas,
pode-se utilizar também a finalidade do método, como, por exemplo, selecionar ape-
nas gets ou sets, ou construtores de uma determinada classe [52].
5.5 POINTCUT
Um pointcut declara pontos onde se deseja interromper a execução de um
programa para inserir um comportamento e armazena uma lista contendo as assina-
turas de métodos que se tem interesse em interceptar. Essa interceptação é feita
com o objetivo de alterar o fluxo original do programa e inserir novas chamadas ou
advices [51].
Os pointcuts correspondem a agrupamentos de joinpoints, sendo que es-
tes devem basear-se num critério bem definido [38, 37].
5.6 ADVICE
Advices são equivalentes a métodos (ou funções) e são formados por um
conjunto de instruções que poderão ser executados no momento em que um ponto
de combinação (joinpoint) for alcançado [51].
Advices são trechos de código associados a pointcuts, que injetam um
novo comportamento em todos os joinpoints, representados pelo pointcut, dividindo-
96
se em vários tipos que correspondem ao momento de ação do referente ponto de
corte (pointcut) [38]. Portanto, advice é o trecho de código que é executado antes,
depois e simultaneamente a um joinpoint [37].
5.7 IMPLEMENTAÇÃO DOS ASPECTOS
Uma propriedade de um sistema, que deve ser implementada, pode ser
vista como um componente ou como um aspecto. A propriedade pode ser vista
como um componente se puder ser encapsulada em um procedimento generalizado.
Os componentes tendem a ser unidades da decomposição funcional do sistema. Os
aspectos não são normalmente unidades da decomposição funcional do sistema,
mas sim propriedades que envolvem diversas unidades de um sistema, afetando a
semântica dos componentes funcionais sistematicamente [37, 57].
Uma implementação baseada no paradigma POA é composta normalmen-
te de [37, 57]:
• Uma linguagem de componentes para a programação de componen-
tes;
• Uma ou mais linguagens de aspectos para a programação de aspec-
tos;
• Um combinador de aspectos (aspect weaver) para a combinação das
linguagens;
• Um programa escrito na linguagem de componentes;
• Um ou mais programas escritos na linguagem de aspectos.
A figura 5.5 mostra a implementação baseada no paradigma POA.
97
Figura 5.37: Implementação em POA [37]
A figura 5.5 mostra a necessidade de uma linguagem para programar os
componentes, uma ou mais linguagens para programar os aspectos e um weaver
para combinar as duas linguagens. O weaver funciona como uma espécie de monta-
dor onde são inseridos um programa de componentes e os programas de aspectos e
como saída um programa em uma linguagem específica [38].
5.7.1 LINGUAGENS DE COMPONENTES
A linguagem de componente deve permitir ao programador escrever pro-
gramas que implementem as funcionalidades básicas do sistema, ao mesmo tempo
em que não provêem nada a respeito do que deve ser implementado na linguagem
de aspecto [55, 41]. As linguagens de componentes focalizam-se na resolução dos
problemas encontrados durante a fase de análise, preocupando-se em resolver os
problemas de negócio [43].
Filtros de composição é uma técnica de POA onde diferentes aspectos
são expressos em filtros, de maneira declarativa, juntamente com especificações
para a transformação de mensagens. As linguagens de POO utilizam essa técnica e
a linguagem de aspectos é o mecanismo de filtros de composição. A maioria do pro-
cesso de combinação ocorre em tempo de execução. Portanto, os filtros de compo-
98
sição podem ser anexados a objetos de diferentes linguagens orientadas a objeto
[37].
“Programas de componentes” é o arquivo fonte escrito em determinada lin-
guagem de programação, por exemplo, Java, C, C++, etc., onde o desenvolvimento
codifica as regras de negócio do sistema em classes conforme definido durante a
fase de análise do projeto [43].
5.7.2 LINGUAGENS DE ASPECTOS
A linguagem de aspectos deve suportar a implementação das proprieda-
des desejadas de forma clara e concisa, fornecendo construções necessárias para
que o programador crie estruturas que descrevam o comportamento dos aspectos e
definam em que situações eles ocorrem [37, 55, 41].
Um programa de aspecto é o arquivo fonte codificado em uma linguagem
de aspecto. Algumas linguagens de aspectos são voltadas a preocupações específi -
cas, e neste caso devem ser utilizadas múltiplas linguagens de aspectos, uma para
cada preocupação [43].
São exemplos de ferramentas/linguagens que oferecem suporte a POA:
HyperJ, QIDL (Quality Interface Definition Language), AOP/ST, AspectJ, AspectS,
AspectC, AspectC++, D, COOL (COOrdination Aspect Language), RIDL (Remote In-
teraction and Data transfers aspect Language), IL, D2AL (Design-based Distribution
Aspect Language), JST e AspectIX [37, 53, 54].
5.7.3 COMBINADOR DE ASPECTOS
O processo de combinação realizado pelo combinador de aspectos (as-
pect weaver) é o produto do cruzamento de um ou mais aspectos com os compo-
nentes descritos na linguagem de componentes. A função do combinador de aspec-
tos é processar a linguagem de aspectos e a de componentes, compondo essas lin-
99
guagens corretamente a fim de produzir a operação geral desejada [37]. Portanto, a
tarefa do combinador de aspectos é combinar os programas escritos em uma lingua-
gem de componentes (as classes onde estão codificadas as regras de negócio) com
os programas escritos em linguagem de aspectos (classes de aspectos) [43]. Um
processo de combinação é mostrado na figura 5.6.
Figura 5.38: Composição de sistema utilizando POA [43]
Combinadores de aspectos podem atuar em tempo de compilação ou exe-
cução. Implementadores de combinadores em tempo de execução têm a possibilida-
de interessante de permitir a adição/exclusão de aspectos com a aplicação em pleno
funcionamento [43].
5.8 LINGUAGEM DE ASPECTO: ASPECTJ
AspectJ é uma linguagem de aspectos open source de propósito geral que
estende a linguagem Java para suportar a POA. Esta linguagem provê uma série de
construções que permitem a definição de aspectos (aspects) e pontos de junção
(joinpoints). Os joinpoints tratam-se de pontos onde os aspectos devem ser entrela-
100
çados ao código de componentes. AspectJ contém um pré-processador cuja função
é combinar o código de aspectos com as classes do código de componentes. Esta
combinação ocorre de acordo com os pontos de junção especificados no código de
aspectos [45].
Os elementos básicos em AspectJ são: aspects, joinpoints, pointcuts, ad-
vices e declarações inter-types [43, 56, 57].
Os aspects são definidos em AspectJ de forma similar às declarações de
uma classe. As declarações de aspectos podem incluir pointcuts, advices, além de
outros tipos de declarações permitidas nas declarações de classes, como métodos e
atributos. Ainda é possível utilizar os conceitos de herança introduzidos pelo para-
digma POO [45, 37]. Os aspectos podem alterar a estrutura estática (através das de-
clarações inter-types) e dinâmica (através dos joinpoints) de um programa [57]. A fi-
gura 5.7 ilustra a representação de um aspect.
Figura 5.39: Representação de um aspect [39]
É importante observar que os pointcuts e os advices são elementos reais,
ou seja, são representados fisicamente por trechos de código criados pelo progra-
mador. Já os joinpoints não existem fisicamente. Eles são apenas os “pontos de en-
tradas” mentalizados pelo programador, como marcadores imaginários de pontos
onde se deseja executar porções extras de códigos [39].
101
Os joinpoints, na linguagem AspectJ, podem ser dos seguintes tipos: cha-
mada de métodos, execução de métodos, chamada de construtores, execução de
inicialização, execução de construtores, execução de inicialização estática, pré-inici-
alização de objetos, inicialização de objetos, referência a campos e tratamento de
exceções [43, 37, 56, 57]. A figura 5.8 mostra um exemplo de fluxo de execução en-
tre dois objetos e identifica alguns joinpoints.
Figura 5.40: Joinpoints de um fluxo de execução [44]
Na figura 5.8, o primeiro joinpoint é a invocação de um método do objeto
A, o qual pode retornar com sucesso, ou levantar uma exceção. O próximo joinpont
é execução deste método, que por sua vez também pode retornar com sucesso ou
levantar uma exceção. Durante a execução do método do objeto A, é invocado um
método do objeto B. A invocação e execução deste método são joinpoints, e da
mesma forma que os do objeto A, pode retornar com sucesso ou levantar uma exce-
ção [44].
Pointcut se trata de um conjunto de pontos de junção unidos através de
operadores lógicos, como && (e), || (ou) e ! (não). São utilizados para indicar em que
pontos do código de componentes uma determinada preocupação deve ser executa-
da [45].
102
Para definir pointcuts, identificando os joinpoints a serem afetados, utiliza-
mos construtores de AspectJ chamados de designadores de pointcut (pointcut de-
signators). Alguns deles são apresentados na tabela 5.1.
Tabela 5.4: Alguns designadores de pointcut [44]
O tipo padrão na tabela 5.1 é uma construção que pode definir um conjun-
to de utilizadores wildcards5. A tabela 5.2 mostra alguns wildcards.
Tabela 5.5: Tipos de caracteres especiais [44]
Advice é uma construção que define o código adicional a ser inserido nos
pontos de junção. Cabe ao desenvolvedor definir o momento em que o advice deve
ser disparado com relação ao ponto de junção (antes, depois ou durante) [45]. Os
advices de AspectJ são apresentados na tabela 5.3.
Tabela 5.6: Advices em AspectJ [44]
Declarações inter-types são descritas como interesses estáticos (static
crosscutting) e provêem, no AspectJ, uma maneira de alterar a estrutura de uma
aplicação. Estas declarações provêm uma construção chamada Introduction [56].
5 Wildcards é utilizado para representar qualquer seqüência de parâmetros [44]. São caracteres espe-
ciais denominados coringas [38].
103
Introduction é o mecanismo que adiciona membros a uma classe. Em As-
pectJ podemos introduzir métodos concretos ou abstratos, construtores e atributos
em uma classe [37, 44]. Na tabela 5.4 é mostrado as construções do tipo introducti-
on de AspectJ.
Tabela 5.7: Introduction em AspectJ [44]
Existem outras construções em AspectJ que alteram a estrutura estática
de um programa [37, 44]. A tabela 5.5 mostra essas construções.
Tabela 5.8: Outras construções em AspectJ [44]
A linguagem AspectJ possibilita a implementação de funcionalidades em
separado da parte funcional do sistema, inserindo ou removendo essas funcionalida-
des (na forma de aspectos) automaticamente no código do sistema. Essa possibili-
dade se torna a maior vantagem da linguagem AspectJ. Para remover um aspecto
do sistema, basta gerar uma nova versão do sistema sem o aspecto que se quer re-
mover. Além disso, para alterar um aspecto, como mudar o protocolo de distribuição
de um sistema, basta implementar outro aspecto de distribuição, e passar a usá-lo
no processo de recomposição. Com a separação, a legibilidade do código funcional
é favorecida, uma vez que não há códigos com diferentes propósitos entrelaçados
entre si e com código funcional. Isso também permite a validação precoce dos requi-
sitos funcionais, antes mesmo da implementação de aspectos como persistência,
distribuição e controle de concorrência, tendo assim um desenvolvimento progressi-
vo [37, 44].
104
6 COMPARAÇÕES ENTRE OS PARADIGMAS
Neste capítulo faremos uma comparação entre os paradigmas PP, POO e
POA.
6.1 COMPARAÇÕES ENTRE OS PARADIGMAS PP, POO E POA
No fim da década de 60 e início da década de 70, como resultado da crise
ocorrida em razão do aumento da complexidade dos programas, emergiram alguns
padrões de projeto e de programação, com o objetivo de organizar e apoiar o pro-
cesso de desenvolvimento de software. Nessa época o paradigma PP tornou-se do-
minante e, devido à utilização desses padrões de projeto e programação, possibili-
tou-se o desenvolvimento de código mais legível, fácil de manter e mais flexível. Adi-
cionalmente, boas práticas de projeto foram estabelecidas ao longo dos anos para o
paradigma PP [58].
Com a evolução desses padrões e o avanço das técnicas de programa-
ção, foi concebido o paradigma POO, que tornou possível o desenvolvimento de sis-
temas particionados em módulos (classes) capazes de encapsular abstrações de
dados juntamente com operações sobre esses dados. Esse paradigma de progra-
mação possibilitou uma melhor separação dos diversos interesses de um sistema,
com a estruturação de projetos e códigos mais próxima da maneira como os desen-
volvedores naturalmente idealizam os sistemas. Além disso, entre outros benefícios,
essa técnica de programação facilitou a reutilização de código desenvolvido em dife-
rentes projetos, auxiliando também a modelagem de aplicações do mundo real [58].
Apesar de o paradigma POO ter revolucionado as técnicas de programa-
ção, alguns problemas não foram completamente resolvidos por suas construções e,
especificamente, essa técnica não permite a clara separação de alguns interesses,
105
geralmente não funcionais (também chamados de interesses transversais). Como
uma proposta de resolução desse problema, surgiu a POA, que oferece mecanismos
para a construção de programas em que os interesses transversais ficam isolados e
separados dos interesses funcionais, em vez de espalhados pelo sistema. A POA
não tem o intuito de ser um novo paradigma de programação, mas uma técnica para
ser utilizada em conjunto com as atuais linguagens de programação, possibilitando a
construção de sistemas com maior qualidade [58].
Nas subseções subseqüentes, faremos uma comparação entre os para-
digmas PP e POO e entre os paradigmas POO e POA, focalizando suas diferenças,
vantagens e desvantagens.
6.1.1 PARADIGMA PP VERSUS PARADIGMA POO
A ênfase da PP está nos procedimentos, implementados em blocos estru-
turados, com comunicação entre procedimentos por passagem de dados. Já o enfo-
que da POO está nos dados e procedimentos que fazem parte de um só elemento
básico (objeto ou classe). Os elementos básicos comunicam-se entre si caracteri-
zando a execução do programa. Os dados e procedimentos são encapsulados em
um só elemento [61]. A figura 6.1 mostra os enfoques dos paradigmas PP e POO.
Figura 6.41: Enfoques dos paradigmas PP e POO
Com a proposta das propriedades, como encapsulamento, herança e poli-
morfismo, o paradigma POO se difere do paradigma PP na questão organizacional,
ou seja, na separação de atributos e métodos em uma estrutura modular. No para-
106
digma PP, a essência da programação é decompor o programa em uma coleção de
variáveis, estrutura de dados e funções, enquanto que em POO a decomposição
ocorre em termos mais abstratos, ou seja, em classes e no emprego de proprieda-
des, como as já citadas [9].
O paradigma PP é altamente flexível, podendo ser migrado para outros
paradigmas facilmente, além de ser bastante eficiente por possuir embutido o mode-
lo von Neumann. Essas características podem ser citadas como as vantagens da uti-
lização do paradigma PP [22].
Como desvantagem da utilização do paradigma PP, podemos citar o fato
de este possuir relacionamento indireto com a entrada/saída, resultando numa difícil
legibilidade do programa. Erros podem ser introduzidos no código dificultando sua
manutenção, ocasionados pela difícil legibilidade. O paradigma PP focaliza o “como”
é feito o desenvolvimento e não o “que” é desenvolvido [22]. Uma outra característi-
ca do paradigma PP é a alta taxa de dependência entre os procedimentos e dados,
o que pode elevar os custos de manutenção uma vez que pequenas alterações nos
dados podem implicar em profundas alterações em outras partes do software [59].
Outra grande desvantagem da programação procedural, baseada em fun-
ções, é a sua construção. Quando uma aplicação sob este tipo de programação
cresce, a modificação do código se torna muito trabalhosa e difícil devido ao fato de
que a mudança de uma só linha em uma função, pode acarrear à modificação de
muitas outras linhas de código pertencentes a outras funções que estejam relaciona-
das [63].
Com o paradigma POO o programa fica melhor modularizado, além de
possuir grande reusabilidade, podendo ser utilizado partes dele em outros progra-
mas. Possui, também, conceitos altamente sofisticados como polimorfismo, funções
de alta ordem e avaliações sob demanda. O paradigma POO possui grande aceita-
ção do mercado [22]. Essas características podem ser citadas como as possíveis
vantagens na utilização do paradigma POO.
Também podemos citar como vantagem na utilização do paradigma POO
o seu caráter unificador: trata todas as etapas do desenvolvimento de sistemas e
ambientes sob uma única abordagem. Nesse sentido, podemos ter análise, projeto,
programação, banco de dados e ambientes orientados a objetos, eliminando as dife-
renças de “impedância” entre eles [64].
107
Outra grande vantagem da utilização do paradigma POO é a reusabilidade
de código, pois permite que programas sejam escritos mais rapidamente, utilizando
códigos já existentes [64].
O polimorfismo também pode ser visto com vantagem na utilização do pa-
radigma POO, pois torna o programa mais enxuto, claro e fácil de compreender [64].
A POO pretende agrupar o código encapsulando-o e tornando-o indepen-
dente, de maneira que uma modificação devida ao crescimento da aplicação só afe-
te a poucas linhas [63].
Em suma, podemos citar, resumidamente, como vantagens e objetivos da
orientação a objetos [62]:
• Natural – Não precisamos saber como um software funciona para usá-
lo e sim no que ele faz.
• Confiável – Aceita alterações em uma parte do programa. É possível
validar um componente independentemente dos outros, podendo reuti-
lizá-lo com confiança.
• Reutilizável – Assim como os módulos, podemos utilizar objetos em
muitos programas diferentes. A POO introduz a herança para permitir
que você estenda objetos existentes e o polimorfismo, para escrever
código genérico.
• Manutenível – Para corrigir um erro, você simplesmente corrige o pro-
blema em um lugar. Como a mudança no código é transparente, todos
os objetos se beneficiarão.
• Extensível – A POO apresenta vários recursos para estender o código.
Esses recursos são: herança, polimorfismo, sobreposição, delegação
e uma validade de padrões de projeto.
• Oportuno – Quando dividimos o programa em vários objetos (uma
classe para cada desenvolvedor) o desenvolvimento de cada parte
pode ser paralelo. O software natural simplifica o projeto de sistemas
complexos, porque podemos nos concentrar no problema a resolver.
Como possíveis desvantagens no uso do paradigma POO podemos real-
çar o fato de que os conceitos da POO têm que estar bem definidos e compreendi -
dos pelos desenvolvedores, para assim, aproveitar ao máximo os benefícios ofereci-
108
dos pelo paradigma POO, pois exige formas de pensar relativamente complexas
[10].
A POO requer definições precisas de classes. Definições flexíveis e impre-
cisas não são suportadas pelo paradigma. Os critérios para classificar objetos po-
dem mudar significativamente na mente humana. A apropriação utilizada na POO
torna-a muito rígida para trabalhar com situações dinâmicas e imprecisas [64].
A tabela 6.1 mostra algumas diferenças entre o paradigma PP e o paradig-
ma POO.
Tabela 6.9: Comparação entre PP e POO [65]
6.1.2 PARADIGMA POO VERSUS PARADIGMA POA
O paradigma POA é fortemente fundamentado no POO, pois certos pro-
blemas do paradigma POO serviram como inspiração para que os fundamentos do
POA fossem propostos. Desta forma, POA permite que os conceitos do POO conti-
109
nuem sendo empregados, porém, com alguns aperfeiçoamentos suficientes para al-
terar a forma de visualizar os problemas computacionais [9].
Em um projeto de software – para fins de simplicidade, legibilidade, e con-
seqüente facilidade na manutenção e maior potencial para reutilização – é importan-
te que os vários interesses relevantes para um sistema estejam localizados em mó-
dulos separados [58].
A utilização das classes do paradigma POO é adequada para encapsular
dados e operações relativas a uma funcionalidade do sistema. Quando há a necessi-
dade de implementar um interesse como o rastreamento, por exemplo, este não
pode ser encapsulado adequadamente por uma classe e sua codificação fica espa-
lhada e entrelaçada pelos métodos do sistema. Isso significa que há código de ras-
treamento em várias classes do sistema e existem várias classes que implementam
parte do rastreamento, além do interesse que deve implementar. Esse espalhamen-
to e entrelaçamento do código tornam os sistemas mais difíceis de compreender,
projetar, evoluir, manter e reusar [60].
No paradigma POO, o relacionamento entre os objetos pode ocasionar
acoplamento, uma vez que o funcionamento de um programa neste paradigma é to-
talmente dependente da relação entre os objetos. No paradigma POO, um programa
executa por meio da oferta e procura de serviços (métodos) que é gerenciada por
eles próprios e concretizada através dos relacionamentos, gerando uma espécie de
“rede de comunicações” entre os objetos [9].
A representação desta “rede de comunicações” é ilustrada na figura 6.2,
na qual os objetos são representados pelos círculos e os relacionamentos são ilus-
trados pelas setas. Nesta ilustração, todos os objetos se apresentam inter-relaciona-
dos, direta ou indiretamente.
110
Figura 6.42: Acoplamento entre objetos [9]
Este inter-relacionamento entre os objetos ocorre naturalmente segundo
as diretivas do modelo de programação do paradigma POO. Normalmente, as clas-
ses apresentam atributos que guardam referência para outras classes, acoplando
estas classes [9].
A fim de tentar minimizar este problema típico do paradigma POO, enge-
nheiros de software propuseram várias soluções em forma de padrões de software.
Apesar de estas soluções serem efetivas para o que se propõem, as mesmas exi-
gem maiores esforços para serem aplicadas pelo programador, não provendo o reu-
so de forma natural e transparente como desejado [9].
Em suma, o paradigma POO não é totalmente claro em seus objetivos
como paradigma. Primeiramente, este propõe a estruturação do código por meio de
classes e propriedades como a herança e encapsulamento, objetivando entre outras
vantagens, maior capacidade de reuso do que na PP. Entretanto, o que se constata
na POO é que apenas o uso destas propriedades não é suficiente para se atingir
alto nível de reuso, principalmente porque a essência do paradigma impõe alguns
empecilhos. A essência da execução de um programa implementado sobre os con-
ceitos do paradigma POO, pela comunicação entre os objetos, incentiva o acopla-
mento. A existência de altos níveis de acoplamento reduz as capacidades de reuso
de partes de um programa [9].
Outro fator de desvantagem na utilização do paradigma POO está no fato
do código orientado a objeto ser de difícil compreensão, não só pela sintaxe, mas
111
pela organização da lógica da aplicação. Devido aos relacionamentos/entrelaçamen-
tos entre os objetos, se torna difícil compreender uma funcionalidade analisando
apenas uma classe. Geralmente, é preciso considerar as demais classes relaciona-
das. Esta dificuldade se deve à dispersão da lógica da aplicação por métodos de vá-
rios objetos coligados, o que leva a necessidade de seguir o fluxo de chamada de
método para entender toda a lógica [9].
O paradigma POO é usado na maioria dos projetos de desenvolvimento
de software. A POO se mostra bastante útil quando de trata de modelar comporta-
mento em comum. A POO não modela adequadamente comportamentos que se es-
tendem ao longo de vários módulos. A POA representa o próximo grande passo na
evolução das metodologias de programação [67].
Um aspecto é similar a uma classe tendo um tipo, estendendo outras clas-
ses e outros aspectos. O aspecto pode ser abstrato ou concreto e ter campos, méto-
dos e tipos como membros. A POA permite e implementação individual de comporta-
mentos, de forma fracamente acoplada, e a combinação dessas implementações
para formar o sistema final. De fato, cria um sistema usando implementações modu-
lares, fracamente acopladas, de comportamentos cruzados [66].
A unidade modular da POA é o aspecto. Na POO, a unidade natural mo-
dular é a classe, e um comportamento cruzado está espalhado em várias classes.
Trabalhar com código que aponta para responsabilidade que atravessam o sistema
gera problemas que resultam na falta de modularidade. A POA complementa a POO
por facilitar um outro tipo de modularidade que expande a implementação espalhada
de um comportamento dentro de uma simples unidade. Como resultado, um único
aspecto pode contribuir na implementação de procedimentos, módulos ou objetos,
aumentando a reusabilidade dos códigos [66].
Uma vantagem na utilização da orientação a aspectos está na diminuição
do tamanho do código dos componentes (visto que parte do código fica na definição
dos aspectos), diminuindo sua complexidade [37].
Por estar centralizado em uma única unidade, alterações são muito mais
simples de acontecer na POA, não é preciso reescrever inúmeras classes. É claro
que um código mais conciso facilita sua manutenibilidade e reusabilidade [37].
112
CONCLUSÕES E TRABALHOS FUTUROS
O crescimento da demanda e da complexidade dos sistemas de software
nas últimas décadas fez com que as linguagens e paradigmas de programação evo-
luíssem para cada vez mais permitir a decomposição dos sistemas em partes geren-
ciáveis com o objetivo de diminuir a complexidade do seu desenvolvimento e au-
mentar o reuso de suas partes.
A separação de interesses, princípio de decompor o software em módulos
gerenciáveis para tratar separadamente cada funcionalidade, requisito ou caracterís-
tica do sistema, aumenta a flexibilidade, a compreensibilidade e a reusabilidade de
software.
Este princípio foi um dos motivos pelo qual as linguagens de programação
evoluíram e consequentemente, aparecimento e evolução de seus paradigmas
como, por exemplo, da linguagem assembly para as linguagens procedurais, que
passaram a ter funções e procedimentos e foram norteadas pelo paradigma PP, até
chegar às orientadas a objetos, com classes, métodos e atributos, norteadas pelo
paradigma POO. Apesar dessas linguagens e paradigmas terem contribuído para o
aumento da separação de interesses nos sistemas, as mesmas não solucionaram
totalmente o problema. Com isso, um novo paradigma surgiu, denominado POA,
como evolução do paradigma POO para resolver os problemas causados pelo entre-
laçamento e espalhamento de código dos interesses transversais e promover uma
clara separação de interesses na implementação dos sistemas de software. A POA
fornece mecanismos para o encapsulamento adequado dos interesses transversais
por meio de módulos chamados de aspectos.
Pelo exposto, concluímos que por se tratar de um processo evolutivo, o
paradigma mais evoluído, POA, é o mais adequado para resolver situações onde de-
manda alta complexidade no seu desenvolvimento. Este paradigma contém embuti-
das as técnicas dos outros paradigmas (PP e POO) além de suas próprias, permitin-
do índices maiores de abstrações. Contudo, vale realçar que se o problema não de-
113
manda alta complexidade, não faz sentido utilizar um paradigma mais sofisticado,
sendo nesse caso mais apropriado o uso de um paradigma sem tantos recursos,
como o paradigma PP.
Para trabalhos futuros, sugerimos um estudo mais aprofundado de outros
paradigmas de programação como programação funcional, programação lógica, pro-
gramação orientada a eventos, programação orientada a agentes, programação ori-
entada a componentes, programação orientada a sujeitos, paradigma adaptativo e
programação multiparadigma.
114
REFERÊNCIAS BIBLIOGRÁFICAS
1. MONTEIRO, Mário A. Introdução à organização de computadores. 4. ed.
Rio de Janeiro: LTC, 2002.
2. WEBER, Raul Fernando. Fundamentos da arquitetura de computadores. 2. ed. Porto Alegre: Sagra Luzzatto, 2001.
3. TANENBAUM, Andrew S. Organização estruturada de computadores. 5.
ed. São Paulo: Pearson, 2007.
4. STALLINGS, William. Arquitetura e organização de computadores: projeto
para o desempenho. 5. ed. São Paulo: Pearson, 2002.
5. FERREIRA, Aurélio Buarque de Holanda. Novo Aurélio Século XXI: o dicio-
nário da língua portuguesa. 3. ed. Rio de Janeiro: Nova Fronteira, 1999.
6. BARANAUSKAS, Maria Cecília Calani. Procedimento, função, objeto ou ló-gica?: linguagens de programação vistas pelos seus paradigmas. Disponí-
vel em: <http://www.nied.unicamp.br/publicacoes/arquivos/3XaQ1o8Nmk>.
Acesso em: 21 jul 2010.
7. WATT, D. Programming language design concepts. [San Francisco]: J.
Willey & Sons, 2004.
8. ROY, P. V.; HARIDI, S. Concepts, techniques, and models of computer programming. [Cambridge]: MIT Press, 2004.
9. BANASZEWSKI, Roni Fabio. Paradigma orientado a notificações: avanços
e comparações. 2009. 263 f. Dissertação (Mestrado em Engenharia Elétrica e
Informática Industrial)-Universidade Tecnológica Federal do Paraná, Curitiba,
2009. Disponível em: <http://arquivos.cpgei.ct.utfpr.edu.br/Ano_2009/disserta-
coes/Dissertacao_500_2009.pdf>. Acesso em: 3 ago. 2010.
10.JUNGTHON, Gustavo; GOULART, Cristian Machado. Paradigmas de pro-gramação. Disponível em: <http://fit.faccat.br/~guto/artigos/Artigo_Paradig-
mas_de_Programacao.pdf>. Acesso em: 8 jul. 2010.
11.DEITEL, II. M. Java, como programar. 3. ed. Porto Alegre, Bookman, 2001.
115
12.AVILLANO, Israel de Campos. Algoritmos e Pascal: manual de apoio. 2. ed.
Rio de Janeiro: Ciência Moderna, 2006.
13.FARRER, Harry et al. Programação estruturada de computadores: algorit-
mos estruturados. 3. ed. Rio de Janeiro: LTC, 2008.
14.MOTA, Jorge. Elementos de algoritmia: introdução à ciência dos computa-
dores. Disponível em: <http://www.jorgemota.com/ICC/Apontamentos%20ICC
%206.7.pdf.> Acesso em: 22 ago. 2010.
15.SEBESTA, Robert W. Conceitos de linguagens de programação. 5. ed.
Porto Alegre: Bookman, 2003.
16.MELO, Ana Cristina Vieira de; SILVA, Flávio Soares Corrêa da. Princípios de linguagens de programação. São Paulo: E. Blücher, 2003.
17.GUIMARÃES, Ângelo de Moura; LAGES, Newton Alberto de Castilho. Algo-ritmos e estruturas de dados. Rio de Janeiro: LTC, 2008.
18.SOUZA, Karina Guedes de Melo. Crise do software, métricas e modelos de qualidade. 2008. 71 f. Dissertação (Mestrado em Engenharia de Software)-
Universidade Estadual de Londrina, Londrina, 2008. Disponível em:
<http://www2.dc.uel.br/nourau/document/?down=751>. Acesso em: 26 ago.
2010.
19.SALDANHA, Sara Alves. Qualidade de software e a importância dos tes-tes nas empresas de desenvolvimento de software. 2009. 56 f. Trabalho
de Conclusão de Curso (Tecnólogo em Informática para Gestão de
Negócios)-Centro Paula Souza, São Paulo, 2009. Disponível em:
<http://www.fateczl.edu.br/TCC/2009-2/tcc-58.pdf>. Acesso em: 26 ago. 2010.
20.DIJKSTRA, E. Go to statement considered harmful. Communications of the ACM, p. 147-148, 1968.
21.BROOKSHEAR, J. G. Computer science: an overview. 9. ed. [Massachu-
setts]: Addison Wesley, 2006.
22.HEIDRICH, Leonardo. Paradigmas de programação: imperativo x orientado
a objeto. Disponível em: <http://www.inf.unisinos.br/~barbosa/grefe/ativida-
des/at1/leonardo_1.pdf> Acesso em: 30 ago. 2010.
23.VALENTIM, Henryethe. Um estudo sobre o ensino-aprendizagem de lógi-ca de programação. Disponível em:
<http://www.foco.fae.ufmg.br/cd/pdfs/137.pdf > Acesso em: 8 jul. 2010.
116
24.ALVES, Débora Pandolfi. Equivalência de máquinas universais: demons-
tração, análise e simulação. 2007. 118 f. Monografia (Bacharel em Ciência da
Computação)-Universidade do Vale do Rio dos Sinos, São Leopoldo, 2007.
Disponível em: <http://www.debora.wait4.org/tc.pdf>. Acesso em: 29 ago.
2010.
25.KING, K. N. C programming: a modern approach. 2ª. ed. [New York]: W. W.
Norton & Company, 2008.
26.TIPOS de dados em Pascal. Disponível em:
<http://www.cultura.ufpa.br/ferreira/Disciplinas/Programacao/TiposPascal.htm
>. Acesso em: 4 set. 2010.
27.MIYAZAWA, Flávio Keidi. Notas de aula de algoritmos e programação de computadores. Disponível em:
<http://olimpiada.ic.unicamp.br/info_geral/programacao/programacao_junior/p
df/introcomp/secao2.pdf> Acesso em: 6 set. 2010.
28.EVARISTO, Jaime. Programando com pascal: a linguagem do turbo pascal
e do Delphi. 2. ed. Disponível em:
<http://www.ebah.com.br/programacao-pascal-pdf-a48206.html#>. Acesso
em: 26 ago. 2010.
29.PROGRAMAÇÃO orientada a objetos. Disponível em:
<http://www.jack.eti.br/www/arquivos/apostilas/java/poo.pdf>. Acesso em: 8
jul. 2010.
30.TOSCANO, Wagner. Programação orientada a objeto: POO. Disponível em:
<http://wagnertoscano.eti.br/Pool/%5BPOO%5DObjeto.pdf>. Acesso em: 8
jul. 2010.
31.POO, D.; KIONG, D. Object-oriented programming and Java. [New York]:
Springer, 2008.
32.BUENO, André Duarte. Programação orientada a objeto com C++. São
Paulo: Novatec, 2003.
33.BORATTI, Isaias Camilo. Programação orientada a objetos: usando Delphi.
3. ed. Florianópolis: Visual Books, 2004.
34.SICA, Carlos. PHP orientado a objetos: fale a linguagem da internet. Rio de
Janeiro: Ciência Moderna, 2006.
117
35.BARNES, David J.; KÖLLING, Michael. Programação orientada a objetos com Java. São Paulo: Pearson Prentice Hall, 2004.
36.DALL’OGLIO, Pablo. PHP: programando com orientação a objetos. São Pau-
lo: Novatec, 2007.
37.SOARES, Alexandre Henrique Vieira et al. Programação orientada a aspec-tos: uma visão geral. Disponível em: <http://www.ic.unicamp.br/~rocha/colle-
ge/src/aop.pdf>. Acesso em: 8 jul. 2010.
38.PAES, Fabiano Gama; FERNANDES, Mikael de Souza. Programação orien-tada a aspectos. Disponível em:
<http://www.fp2.com.br/fernando/artigos_alunos/2007_1_programacao_orien-
tada_aspectos.pdf>. Acesso em: 8 jul. 2010.
39.SOUZA JÚNIOR, Vicente Goetten de; WINCK, Diogo Vinícius; MACHADO,
Caio de Andrade Penteado e. Programação orientada a aspectos: abordan-
do Java e AspectJ. Disponível em:
<http://inf.unisul.br/~ines/workcomp/cd/pdfs/2337.pdf>. Acesso em: 8 jul.
2010.
40.FURTADO, André Wilson Brotto. Identificando oportunidades de progra-mação orientada a aspectos no desenvolvimento de jogos. Disponível
em: <http://www.cin.ufpe.br/~awbf/files/SBGames2004_GamesAOP.pdf>.
Acesso em: 8 jul. 2010.
41.FORTES, Charles Wellington de Oliveira. Programação orientada a aspec-tos aplicada. Disponível em: <http://dev.eclipse.org/mhonarc/lists/ajdt-
dev/pdfX5BLjbBrV0.pdf>. Acesso em: 8 jul. 2010.
42.LOUREIRO, João Manuel Bonita Pereira et al. Programação orientada a as-pectos. Disponível em: <http://paginas.fe.up.pt/~aaguiar/es/artigos
%20finais/es_final_15.pdf>. Acesso em: 15 out. 2010.
43.HUGO, Marcel; GROTT, Marcio Carlos. Estudo de caso aplicando progra-mação orientada a aspecto. Disponível em:
<http://www.inf.furb.br/seminco/2005/artigos/108-vf.pdf>. Acesso em: 21 jul.
2010.
44.SOARES, Sérgio; BORBA, Paulo. AspectJ: programação orientada a aspec-
tos em Java. Disponível em: <http://www.cin.ufpe.br/~phmb/papers/AspectJ-
TutorialSBLP2002.pdf>. Acesso em: 16 jul. 2010.
118
45.STEINMACHER, Igor; LIMA, José Valdeni de. Extensão da UML para mode-lagem orientada a aspectos baseada em AspectJ. Disponível em:
<http://www.igor.pro.br/publica/papers/CACIC04-Aspectos.pdf>. Acesso em:
16 jul. 2010.
46.PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books,
1995.
47.GRADECK, Joe; LESIECKI, Nicolas. Mastering AspectJ: aspect-oriented
programming in Java. Indiana: Wiley, 2003.
48.SOARES, S; BORBA, P. Progressive implementation with aspect–oriented
programming. In: WORKSHOP FOR PHD STUDENTS IN OBJECT-ORI-
ENTED SYSTEMS, 12, 2002, Malaga. Anais... Spain: Springer -Verlag, 2002.
49.LADDAD, Ramnivas. AspectJ in action: practical aspect-oriented program-
ming. Canadá: Mannig, [2003].
50.LOPES, Cristina Isabel Videira. D: a language framework for distributed pro-
gramming. 1997. 295 f. Tese (Doutorado em Filosofia)- Northeastern Univer-
sity, Boston, 1997. Disponível em: <http://www2.parc.com/csl/groups/sda/pu-
blications/papers/Lopes-Thesis/dissertation.pdf>. Acesso em: 15 out. 2010.
51.NUNES, Alexandre Becker; AZAMBUJA, Rogério Xavier. Orientação a aspec-
tos: uma nova metodologia no desenvolvimento de software. In: CONGRES-
SO DE INICIAÇÃO CIENTÍFICA E TECNOLÓGICA EM ENGENHARIA, 21.,
2006, Ijuí. Anais eletrônicos... Disponível em: <http://200.169.53.89/downlo-
ad/CD%20congressos/2006/CRICTE%202006/trabalhos/324225-comp-01-09-
83157.pdf.>. Acesso em: 16 out. 2010.
52.RESENDE, Antônio Maria Pereira de; SILVA, Claudiney Calixto da. Progra-mação orientada a aspectos em Java. Rio de Janeiro: Brasport, 2005.
53.SANTOS, Rodrigo Pereira dos. Critérios de manutenibilidade para cons-trução e avaliação de produtos de software orientados a aspectos. 2007.
92 f. Monografia (Bacharel em Ciência da Computação)- Universidade Fede-
ral de Lavras, Lavras, 2007. Disponível em: <http://www.bcc.ufla.br/monografi-
as/2006/Criterios_de_manutenibilidade_para_construcao_e_avaliacao_de_pr
odutos_de_software_orientados_a_aspectos.pdf>. Acesso em: 16 out. 2010.
54.STEINMACHER, Igor Fábio. Estudo de princípios para modelagem orien-tada a aspectos. 2003. 63 f. Monografia (Bacharel em Ciência da Computa-
119
ção) - Universidade Estadual de Maringá, Maringá, 2003. Disponível em:
<http://www.lafhis.dc.uba.ar/~ferto/docs/tesis2.pdf>. Acesso em: 16 out. 2010.
55. IRWIN, John et al. Aspect-oriented programming. In: EUROPEAN CONFER-
ENCE, 11, 1997, Finland. Anais... Filand: Springer - Verlag, 1997.
56.PETRI, João Paulo Delgado. Programação orientada a aspecto com As-pectJ. Disponível em: <http://200.169.53.89/download/CD
%20congressos/2004/Sucesu/tut_prat/PROGRAMA%C3%87%C3%83O
%20ASPECTJ.pdf>. Acesso em: 13 out. 2010.
57.MONTEIRO, Elaine da Silva; PIVETA, Eduardo Kessler. Programação orien-
tada a aspectos em AspectJ. In: ENCONTRO DE ESTUDANTES DE INFOR-
MÁTICA DO TOCANTIS, 5., Palmas. Anais... Disponível em:
<http://www.dsc.ufcg.edu.br/~patricia/plp2005.1/aulas/aspectj-
encoinfo2003.pdf>. Acesso em: 16 out. 2010.
58.LEMOS, Otávio Augusto Lazzarini. Teste de programas orientados a as-pectos: uma abordagem estrutural para AspectJ. 2005. 103 f. Dissertação
(Mestrado em Ciência de Computação e Matemática Computacional)-Univer-
sidade de São Paulo, São Carlos, 2005. Disponível em: <http://www.te-
ses.usp.br/teses/disponiveis/55/55134/tde-13042005-111234/publico/Dis-
sert.pdf>. Acesso em: 24 out. 2010.
59.PRADO, Marllos Paiva. Um estudo de caracterização e avaliação de crité-rios de teste estruturais entre os paradigmas procedimental e OO. 2009.
134 f. Dissertação (Mestrado em Ciência de Computação e Matemática Com-
putacional)-Universidade de São Paulo, São Carlos, 2009. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/55/55134/tde-18062009-
091608/publico/dissertacao_marllos.pdf>. Acesso em: 24 out. 2010.
60.ELER, Marcelo Medeiros. Um método para o desenvolvimento de software baseado em componentes e aspectos. 2006. 158 f. Dissertação (Mestrado
em Ciência de Computação e Matemática Computacional)-Universidade de
São Paulo, São Carlos, 2006. Disponível em:
<http://www.teses.usp.br/teses/disponiveis/55/55134/tde-04072006-
114542/publico/MarceloMedeirosEler_dissertacaoMetodoDSBCA.pdf>. Aces-
so em: 24 out. 2010.
120
61.MESQUITA, Renato Cardoso. Introdução à programação e análise orientada
a objetos . In: ______. Programação orientada a objetos em C++. Disponí-
vel em: <http://www.cpdee.ufmg.br/~jramirez/disciplinas/cdtn/cap2.pdf>. Aces-
so em: 24 out. 2010.
62.PROGRAMAÇÃO orientada a objetos. Disponível em:
<http://piber2009.hd1.com.br/poo.pdf>. Acesso em: 24 out. 2010.
63.RECIO, Francisco; PROVENCIO, David. Programação orientada a objetos:
introdução. Disponível em: <http://www.criarweb.com/artigos/programacao-o-
rientada-objetos.html>. Acesso em: 24 out. 2010.
64.SOBRAL, Adilson Benevides. Programação orientada a objetos: POO. We-bArtigos.com, 23 jun. 2009. Disponível em: <http://www.webartigos.com/arti-
cles/20199/1/PROGRAMACAO-ORIENTADA-A-OBJETO---
POO/pagina1.html>. Acesso em: 25 out. 2010.
65.PILLAT, Valdir Gil. Programação visual: Visual Basic. Disponível em:
<http://www1.univap.br/~valdirgp/Apostilas/VB/Aula1.pdf>. Acesso em: 25 out.
2010.
66.SILVEIRA, Karina Kohl; WEBER, Taisy Silva. Um injetor de falhas de comu-nicação construído usando programação orientada a aspectos. Disponí-
vel em:
<http://www.lume.ufrgs.br/bitstream/handle/10183/10003/000581025.pdf?se-
quence=1>. Acesso em: 26 out. 2010.
67.LADDAD, Ramnivas. I want my AOP!, part 1: separate software concerns with
aspect-oriented programming. InfoWorld: JavaWorld, 18 jan. 2002. Disponí-
vel em: <http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-
aspect.html?page=1>. Acesso em: 26 out. 2010.
68.MARTINS, Guilherme Teixeira Azeredo. Elementos fundamentais da infor-mática. Rio de Janeiro: Imprinta, 2008. Disponível em: <http://www.faetec.rj.-
gov.br/ist-rio/app/images/livros/elementos.pdf>. Acesso em: 11 nov. 2010.
121