PARADIGMAS DE ANA-LISE E DESENVOLVIMENTOS - AULAS

Prévia do material em texto

PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
AULA 01
ABORDAGEM INICIAL
Nesta aula, você irá:
1. Reconhecer a importância das linguagens de 
p r o g r a m a ç ã o n o c o n t e x t o d e 
desenvolvimento de software.
2. Conhecer os conceitos e os principais 
paradigmas de Linguagens de Programação.
3. Conhecer os conceitos e os principais 
metodologias e técnicas de programação.
4. Saber re lac ionar as a t i v idades de 
programação com atividades de análise de 
sistemas.
5. Entender a tênue re lação entre os 
paradigmas de Linguagens de Programação, 
de programação e de Análise de Sistemas.
Por que linguagens de programação?
! As linguagens de programação exercem um 
pape l p reponderan te no p rocesso de 
desenvolvimento de software, pois possibilitam 
aos profissionais da área o exercício de   uma 
atividade fundamental: a programação. Ou seja, 
as linguagens de programação permitem a 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 1
escrita dos programas, que serão integrados 
para compor o software. 
Os principais objetivos de uma linguagem de 
programação são:
1. Tornar mais produtivo o trabalho dos 
programadores, ou seja, desenvolver e 
manter softwares.
2. Propiciar ao programador desenvolver o 
software atendendo a padrões de qualidade 
pré-estabelecidos, sendo que as principais 
propriedades desejadas de um software são: 
confiabilidade, manutebilidade (capacidade 
de ser mantido) e eficiência. 
3. Prop ic ia r ao programador escrever 
programas que atendam as expetativas e 
requisitos de seus usuários.
LINGUAGENS DE PROGRAMAÇÃO
Temos, hoje em dia, um vasto universo de 
linguagens de programação, que atendem a 
diferentes propósitos, ou seja, a diferentes tipos 
d e p r o b l e m a s d e m a n d a d o s p a r a o 
desenvolvimento de sistemas. Surge então a 
dúvida: qual linguagem de programação deve 
ser usada no novo projeto?
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 2
A tendência, na prática, é que as empresas 
usem a linguagem com que seus programadores 
tenham experiência e, preferencialmente, 
possuam uma vasta biblioteca de rotinas e 
funções desenvolvidas, o que vai, certamente, 
agilizar o desenvolvimento. Quanto mais 
experiência um programador tiver no uso de uma 
linguagem de programação, com mais eficiência 
ele poderá atuar na programação de um 
software, maximizando os recursos da 
linguagem em prol de uma boa solução 
computacional.
À partir da década de 90 (noventa) muitas 
linguagens de programação passaram a ser de 
propósito geral (podendo ser usadas na maior 
dos problemas e vêm logrando êxito). Mas nem 
sempre é possível, ou seja, alguns sistemas vão 
requerer l inguagens com características 
específicas para que possam ser confiáveis, 
manutíveis e eficientes. Ou seja, o tipo de 
problema a ser resolvido e consequentemente o 
tipo de sistema a ser desenvolvido influenciam 
na escolha da linguagem de programação a ser 
usada.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 3
Por exemplo, o desenvolvimento de um Sistema 
Especialista, do ramo da IA (Inteligência 
Artificial), requer uma linguagem que possibilite a 
implementação da lógica de predicados e de um 
motor de inferência, o que não é viável usando 
linguagens de programação que, tipicamente, 
resolvem problemas comerciais das empresas, 
como por exemplo, contas a pagar, contas a 
receber e fluxo de caixa.
A linguagem de programação é fundamental 
dentro do contexto do desenvolvimento de 
software. Programadores devem conhecer cada 
vez mais as linguagens com as quais trabalhem. 
Vejamos os principais motivos:
★Maior capacidade em desenvolver soluções 
para os problemas. Se os programadores 
tiverem uma maior compreensão e habilidade 
com a linguagem, seus elementos e sus 
comandos, terão mais facilidade ao darem as 
soluções computacionais para determinados 
problemas e terão mais habilidade em como 
pensar e resolver problemas. 
★Maior habilidade ao usar uma linguagem de 
programação. O fato do programador 
conhecer a fundo as características da 
linguagem lhe confere a capacidade de 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 4
escrever programas mais eficientes, do ponto 
de vista técnico.
★Maior capac idade para esco lher as 
linguagens mais apropriadas ao respectivo 
projeto, através de maior entendimento dos 
recursos e da forma de implementá-los na 
linguagem de programação. 
★Maior habilidade para aprender novas 
linguagens de programação. Por exemplo o 
programador que conhece bem a linguagem 
C (e C++) tem mais facilidade para aprender 
JAVA (e C#). 
Ou seja, quanto mais conhecermos as 
propriedades das linguagens de programação, 
maior será a possibilidade de escrevermos 
programas com eficiência. 
A INFLUÊNCIA DAS LINGUAGENS DE 
PROGRAMAÇÃO NAS METODOLOGIAS E 
TÉCNICAS DE PROGRAMAÇÃO
! Nas décadas de 40 e 50, nos primórdios da 
computação, a linguagem dominante era a 
binária (composta por sequência de 1’s e 0’s) ou 
de linguagem máquina e a programação era feita 
pensando em como determinado processador 
funcionava. O tipo de problema que a 
computação se destinava a resolver era simples 
e l imi ta-se a cálculos complexos, não 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 5
demandando nenhuma técnica de programação. 
O programa era uma sequência de conjunto de 
bits, conforme o tamanho da palavra do 
processador. E cada sequência de bits 
representava uma instrução do programa.
Cada processador tem seu respectivo conjunto 
de instruções, que representa o chamado Set de 
Instruções do Processador.
No quadro, abaixo, temos um exemplo de uma 
instrução em código de maquina escrita em 
hexadecimal, de forma a diminuir a quantidade 
de dígitos.
Veja o exemplo de um programa em 
código máquina: 
A1 01 10 03 06 01 12 A3 01 14 
T r a t a - s e d a r e p r e s e n t a ç ã o 
hexadecimal de um programa que 
soma os valores de duas casas da 
memória e armazena o resultado em 
uma terceira casa. É óbvio que este 
tipo de escrita é dificilmente legível por 
nós, humanos. 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 6
Um pouco da história das linguagens de 
programação
Na década de 50, com o intuito de facilitar a vida 
do programador, minimizando seu esforço e 
fazê-lo abstrair-se do endereçamento direto de 
memória e da combinação de bits, surgiam as 
primeiras linguagens de montagem (assembly), 
onde as operações realizadas pelo processador 
eram representadas por mnemônicos como ADD 
(Adicione), SUB (Subtraia), MOV (carrega 
valores para o registrador) e etc.
É importante ressaltar que cada processador 
tinha seu respectivo conjunto de instruções em 
linguagem de montagem, na relação de 1 para 1 
para o conjunto de instruções do processador 
em linguagem de máquina (set de instruções do 
processador).
A tabela 2, abaixo, mostra que em linguagem de montagem 
toda instrução tem uma notação simbólica associada 
(fornecida pelo fabricante do processador).
Instrução em 
código de 
máquina
Hexadecimal
Instrução em 
linguagem de 
montagem
Comentários sobre a instrução
 A1 01 10 MOV AX, 
[0110] 
Copiar o conteúdo de 0110 no registro 
AX
03 06 01 12 ADD AX, 
[0112]
Adicionar o conteúdo de 0112 à AX e 
por o resultado no AX
A3 01 14 MOV [0114], AX Armazenar AX no endereço da memória 
0114
Tabela 2: exemplo de programa em linguagem de montagemPARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 7
Inicialmente, tal qual na linguagem de máquina o 
tipo de problema a ser resolvido era simples, 
geralmente numérico e não existia técnica de 
programação. Porém a necessidade de 
programação crescia e os programas também, 
assim as linguagens de montagem mais 
avançada criaram o conceito de macro, que 
pode-se dizer foi a base da criação da técnica da 
programação modular. Um macro é um trecho de 
código (módulo) que se repete ao longo de um 
programa, que era escrito uma única vez e 
chamado sempre que necessário.
Abaixo, a figura 1 (Exemplo de código assembly 
com macro) mostra 2 colunas a primeira com o 
código sem macro e a segundo com o código 
com a macro de nome
CHANGE. Perceba que o código é o mesmo alterando 
apenas o conteudo (P,Q,R,S) que vai ser armazendo nos 
registradores (EAX e EBX). A macro change usa 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 8
parâmetros (P1 e P2) e é chamada 2 vezes, para realizar 
as trocas de conteúdos desejados).
Figura 1: exemplo de código Assembly com Macro
Na final da década de 50 e início da década de 
60 surgem as primeiras linguagens de alto nível, 
que são assim chamadas pela sintaxe dos 
comandos que são bem próximas a linguagem 
humana (no inglês, no caso). A primeira 
linguagem dessa geração de linguagens, que 
seria a 3a. Geração (1a. Geração, a linguagem 
de máquina e 2a geração, a linguagem 
assembly) fo i o For t ran, desenvolv ida 
inicialmente para computadores IBM, destinada 
a aplicações numérico-científicas (poucos dados 
e muita computação). Não focava a eficiência 
dos programas na medida em que as estruturas 
de controle eram todas focadas em GOTO 
(desvio incondicional), que são a implementação 
das macros nas linguagens de 3a. Geração. 
Nesse estado da arte, começa a surgir a idéia de 
programação modular, ou seja criação de sub-
rotinas para parte de programas que se repetem, 
mas a programação com desvios dificultava a 
lei tura e manutenção dos códigos dos 
programas
A tabela 3, abaixo, mostra o exemplo de um 
programa em Basic, uma linguagem de 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 9
programação das décadas 60/70, usando desvio 
incondicional (GOTO), uma forma de simular 
repetições.
10 REM RESOLVE EQUACAO DO SEGUNDO 
GRAU
20 READ A,B,C
30 IF A=0 THEN GOTO 410
40 LET D=B*B-4*A*C
50 IF D<0 THEN GOTO 430
60 PRINT "SOLUCAO"
70 IF D=0 THEN GOTO 100
80 PRINT "PRIMEIRA SOLUCAO",(-B+SQR(D))/
(2*A) 
90 PRINT "SEGUNDA SOLUCAO",(-B-SQR(D))/
(2*A) 
100 GOTO 20
200 PRINT "SOLUCAO UNICA",(-B)/(2*A)
300 GOTO 20
400 PRINT "A DEVE SER DIFERENTE DE 
ZERO"
410 GOTO 20
420 PRINT "NAO HA SOLUCOES REAIS"
430 GOTO 20
490 DATA 10,20,1241,123,22,-1
500 END
Tabela 3: exemplo de programa em basic, usando GOTO
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 10
No início da década de 70 iniciou-se o 
movimento de técnica de programação 
estruturada, na tentativa de tornar os códigos 
dos programas mais legíveis. A essa altura os 
programas eram lotados de instruções de desvio 
incondicional (os chamados GOTO), que tiravam 
a seqüência lógica das instruções do programa e 
tornavam a leitura e conseqüente entendimento 
do programa em algo muito difícil. Nessa época 
as linguagens de programação eram pobres em 
estruturas de controle (decisão e repetição) e 
não verificavam consistência de tipos, onde 
destacavam-se na época: Fortran, Basic e Cobol 
(as mais usadas).
Em 1971 foi criada por Niklaus Wirth a 
linguagem Pascal, para fins acadêmicos de 
ensino da programação estruturada. Seu 
pequeno número de comandos básicos pode ser 
combinado de forma a torna-la mais poderosa, 
mas sem perder a clareza lógica de suas 
construções. O uso de subprogramas permite a 
técnica de refinamentos sucessivos (metodologia 
top-down) conseguindo hierarquia na estrutura 
do programa.
Além da técnica de refinamentos sucessivos, a 
programação estruturada caracteriza-se pela 
construção de programas com 3 estruturas 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 11
básicas de controle: sequencia, decisão e 
repetição (iteração).
A tabela 4, abaixo, mostra um programa em 
Pascal que representa a linguagem clássica, 
onde predominava a técnica de programação 
estruturada.
program Soma_Pares;
 uses crt;
 var
 superior, soma, num: integer;
 begin
 soma:=0;
 write ('Entre com o limite superior');
 readln (superior);
 num:=2;
 repeat
 soma:=soma+num;
 num:=num+2;
 until (num > superior);
writeln('A soma dos números pares de 2 até ', 
superior,' é ', soma);
readln; end.
Tabela 4: exemplo de programa em Pascal – Programação 
estruturada
Durante os anos 80 houve um rápido 
crescimento do uso de computadores pessoais, 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 12
em função do barateamento do hardware. Surge 
a fábrica de software e com ela a necessidade 
de produzir e atualizar software com mais 
rapidez, pois a demanda é grande. Assim sendo 
a reutilização de código, que já vinha sendo 
perseguida pela técnica de programação 
estruturada, passa a ser um conceito central 
para a produtividade no desenvolvimento de 
software. 
Na mesma época, iniciou-se as mudanças das 
metodologias de projeto de programas 
orientadas para o processo, para orientadas a 
dados, o que precisou que as linguagens 
implementassem os tipos abstratos de dados 
(TADs). 
Inicia-se então a programação orientada a 
objeto, que teve inicio com a abstração de 
dados, a qual encapsula o processamento com 
objeto de dados oculta o acesso a eles e 
adiciona herança e vinculação dinâmica de tipos.
O conceito de paradigma
Consultando o Minidicionário Aurélio,  7ª edição, 
temos a seguinte descrição para o vocábulo 
paradigma: sm (substantivo masculino). Modelo, 
padrão.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 13
O Dicionário Didático SM (Ensino fundamental) 
define o termo paradigma como: substantivo 
masculino. Modelo ou exemplo. 
O ministro propôs um novo paradigma nacional 
de transporte, mais urbano e adequado ao meio 
ambiente. 
Trazendo a idéia para o contexto das linguagens 
de programação, temos que:
PARADIGMA é o conjunto de características que 
servem para categorizar um grupo de linguagens 
com características semelhantes e que apoiem o 
desenvolvimento de sistemas com determinadas 
características. 
Ou seja um paradigma agrupa linguagens com 
características semelhantes, que são usadas 
para o desenvolvimento de sistemas que 
aproveitem essas características
POR QUE ENTENDER OS PARADIGMAS DAS 
LINGUAGENS DE PROGRAMAÇÃO
O entendimento das características das 
categorias de linguagens é fundamental para 
entender o estado da arte e compreender o que 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 14
cada linguagem pode prover e para que tipos de 
problemas devemos usar cada uma.
OS PARADIGMAS DE LINGUAGENS DE 
PROGRAMAÇÃO 
Existem muitas classificações de paradigmas 
sendo a mais comum a que divide nos 
paradigmas Imperativo, Funcional, Lógico e 
Orientado a Objetos, conforme ilustrado pela 
figura 3 (Paradigmas de Linguagem de 
programação), abaixo.
CLASSIFICAÇÕES DE PARADIGMAS DE LINGUAGENS 
DE PROGRAMAÇÃO
Paradigma Imperativo Ou Procedural
Visão:
 “ O computador é uma calculadoraprogramável”
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 15
A maioria das linguagens, de alto nível, 
existentes até a década de 80 seguiam o 
p a r a d i g m a i m p e r a t i v o , c a r a c t e r i z a d o 
basicamente por seguir as características da 
arquitetura de Von Neumann , que tem formado 
a base para o projeto de muitas linguagens de 
programação. Tais linguagens têm um forte 
compromisso com a eficiência.
A Arquitetura de von Neumann - de 
John von Neumann - é uma 
arquitetura de computador que se 
caracteriza pela possibilidade de uma 
máquina digital armazenar seus 
programas no mesmo espaço de 
memória que os dados, podendo 
assim manipular tais programas.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 16
Ilustração representando a 
"Arquitetura de von Neumann"
Neumann, à época de 
Los Alamos (ca. 
1943-1945)
As LPs incluídas nesse paradigma especificam 
como a computação é realizada por uma 
sequência de alterações no estado da memória 
do computador. 
Os conceitos fundamentais são: 
Variável, valor e atribuição, ou seja o tempo todo 
atribui-se valor a variáveis.
Essa classe de LPs é caracterizada pelo 
desenvolvimento do programa através de 
r e fi n a m e n t o s s u c e s s i v o s ( t o p d o w n ) , 
incentivando a organização do programa em 
subprogramas (partes), construídos com 3 tipos 
de processamento: 
sequencial, condicional e iterativo (repetitivo). 
Ou se ja o parad igma imperat ivo es ta 
intimamente relacionado com as técnicas e 
linguagens estruturadas.
Esta classe de linguagens contendo membros 
tão díspares como FORTRAN, COBOL, 
PASCAL, CLU e ADA, deve seu nome ao papel 
dominante desempenhado pelos comandos ou 
instruções iterativas. Nestas linguagens a 
unidade de trabalho é o comando. Os efeitos de 
comandos individuais são combinados para a 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 17
obtenção dos resultados desejados em um 
programa.
Com forte influência da arquitetura de Von 
Neumann , 3 características permeiam tal classe 
de linguagens :
★Variáveis – a memória é um componente 
vital de tal arquitetura sistêmica, sendo 
composta por um conjunto de unidades, 
denominadas células, onde os dados ficam 
armazenados. Para acessar tais dados na 
memória necessitamos saber o endereço 
de cada cé lu la . Como programar, 
referenciando os endereços físicos de 
memória é uma tarefa extremamente 
complexa, as linguagens de programação 
dispuseram aos programadores o conceito 
de variável, permitindo a eles abstraírem-se 
do conhecimento de que dado estaria 
armazenado em que célula (com endereço 
específico) de memória. Assim uma variável 
é em última análise, uma célula de 
memória, onde se armazenam dados, e que 
possuem um nome (identificador).
★Operação de Atribuição – cada dado que 
precisa ser processado deve estar 
previamente armazenado na memória, isto 
é seu valor deve ser atribuído a uma célula 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 18
de memória. O comando de atribuição tem 
alto grau de importância nas linguagens 
imperativas, forçando ao programador a um 
estilo de pensamento que é moldado pela 
arquitetura de Von Neumann. 
★Repetição (iteração) – um programa, nesta 
classe de linguagens, geralmente cumpre 
seu objetivo, executando repetidamente 
uma seqüência de passos (comandos) 
elementares. Isto é uma conseqüência da 
arquitetura de Von Neumann, posto que as 
inst ruções também prec isam estar 
previamente armazenadas na memória 
antes de sua execução. A única maneira de 
fazer algo mais complexo é repetindo uma 
seqüência de instruções.
As linguagens imperativas permitem descrever a 
resolução de problemas através de uma série de 
tarefas elementares (comandos) que o 
computador pode executar. A seqüência de 
comandos define o procedimento.
A fi m d e i l u s t r a r a i n t e r a ç ã o d e s t a s 
características e seus efeitos, consideremos o 
programa abaixo, escrito em PASCAL, que 
mostra os números primos compreendidos entre 
2 e Num, sendo Num um valor lido do dispositivo 
de entrada DEFAULT (teclado).
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 19
Program Primo;
Var Num,I,J : Integer; Primo : Boolean;
Begin
Readln (Num);
For I:=2 to Num do
Begin
J:=2; Primo:=True;
While (Primo) and (J <= I div 2) do
If (I mod J) <> 0 Then J:=J+1
Else Primo:=False;
If Primo Then writeln (´O número ´, I , ´e primo´)
End;
End.
Considerações sobre o programa :
★Baseia-se em duas malhas de repetição, 
uma dentro da outra. A repetição mais 
externa(For I:=1 to Num) percorre os 
valores no intervalo de interesse 3 (2 a 
Num), ao passo que a mais interna 
(While...) testa cada um destes números 
quanto a ser primo ou não.
★A malha mais interna depende – de 
maneira não tão simples – da malha mais 
externa.
★A malha mais externa também depende – 
na instrução If Primo Then..... – da 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 20
atribuição feita na malha mais interna 
(primo:=false).
★O programa não é hierárquico no sentido 
de cada componente ser composto de 
outros componentes (de nível mais baixo). 
Ao contrário cada componente usa efeito 
dos outros.
★Um componente é usado não para produzir 
(calcular) um valor, mas para produzir um 
efeito, especificamente o efeito de atribuir 
valores a variáveis. 
★As estruturas de controle são usadas para 
ordenar as instruções de maneira que os 
efeitos combinados atinjam o fim desejado
Vantegens das LPs 
Imperativas
Desvantagens das 
LPs Imperativas
Os programas tendem 
a ser eficientes, pois 
essas LPs simulam o 
func ionamento da 
a r q u i t e t u r a d o 
hardware
Dificulta a escrita de 
p r o g r a m a s 
c o m p l e x o s , p e l a s 
características das 
linguagens no que se 
re fere a segu i r a 
M a q u i n a d e Vo n 
Neumann.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 21
Vantegens das LPs 
Imperativas
Desvantagens das 
LPs Imperativas
I n a d e q u a d o a 
c o m p u t a ç ã o e m 
paralelo
★D i fi c u l d a d e e m 
corrigir programas, já 
que essa atividade 
d e c o r r e d a 
d e p e n d ê n c i a d o 
conteúdo de cada 
célula de memória.
★R e q u e r 
a c o m p a n h a m e n t o 
passo a passo do 
e s t a d o d e c a d a 
variável.
PARADIGMA ORIENTADO A OBJETOS 
Na medida em que os programas tornam-se 
maiores e mais complexos, cresce a dificuldade 
não só em desenvolvê-los, mas sobretudo 
mantê-los ao longo do tempo. As LPs desse 
paradigma oferecem recursos para tornar o 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 22
desenvolvimento de software mais rápido e 
confiável.
A diferença básica entre as LPs desse 
paradigma e das LPs do paradigma estruturado 
é que enquanto essas focam nas abstrações de 
controle de execução dos programas, aquelas 
estão fundamentadas nas abstrações de dados 
Classes, nesse paradigma, são abstrações que 
definem uma estrutura de dados e um conjunto 
de operações, os chamados métodos, que 
podem ser realizadas sobre elas.
Na implementação dos métodos das classes são 
usados os conceitos do paradigma estruturado, 
daí dizermos que o paradigma OO é uma 
evolução do paradigma estruturado.
Uma linguagem é dita orientada à objetos 
quandoela dá suporte lingüístico para objetos, e 
requer que estes objetos sejam instâncias de 
classes e um mecanismo de herança deve ser 
permitido.
Linguagens Orientada a Objetos = Objetos + 
Classes + herança
Podemos identificar similaridades entre o 
paradigma imperativo (ou procedural) com o 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 23
paradigma da orientação a objetos. A Tabela 
abaixo , traça um paralelo entre estas 
abordagens.
Paradigma Imperativo Paradigma de Objetos
Tipos de dados Classes / Tipos abstratos de 
dados
Variável Objeto / Instância
Função / Procedimento Operação / Serviços
C h a m a d a d e 
procedimento / função
Envio de mensagens
PARADIGMA CONCORRENTE
O paradigma concorrente engloba LPs que 
oferecem recursos para o desenvolvimento de 
sistemas concorrentes, cada vez mais usados. A 
programação concorrente existe quando vários 
processos executam simultaneamente e 
concorrem por recursos, o que pode acontecer 
quando há uma ou mais unidades de 
processamento.
As principais linguagens para essa finalidade 
são: ADA e JAVA.
PARADIGMA DECLARATIVO
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 24
Em contraste com o paradigma interativo, onde 
os programas especificam exatamente como o 
computador deve realizar a tarefa, nesse 
paradigma declara-se (descrição) o que é a 
tarefa, de forma abstrata.
Essas LPs especificam as relações ou funções, 
não tendo atribuição de valores a posições de 
memória. As variáveis são incógnitas e não 
células de memória. 
O paradigma declarativo é subdividido em: 
Paradigma funcional e lógico, que são abaixo 
descritos.
Paradigma Funcional
Visão : “ O computador calcula funções 
matemáticas complexasl”
O paradigma funcional contemplam linguagens 
que basicamente operam funções ou seja 
recebem um conjunto de valores e retornam um 
valor, como resposta ao problema. Exemplos 
dessas LPs são: LISP e HASKELL.
O paradigma funcional focaliza o processo de 
resolução de problemas. A visão funcional 
resulta num programa que descreve as 
operações que devem ser efetuadas para 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 25
resolver o problema. O programa é uma função, 
ou grupo de funções composto por funções 
simples. A relação entre as funções é simples : 
uma função pode chamar outra, ou o resultado 
de uma função pode ser utilizado como 
argumento para outra função. 
A tendência são programas menores, com 
menos código, nas linguagens funcionais.
Exemplo: Considere a seguinte função para 
calcular o fatorial de um número, dada em uma 
linguagem imperativa C.
Int Fatorial (int n)
{
Int Fat=1;
While (n > 0)
{
fat=fat*n
n—
}
return fat
}
Podemos usar a mesma função sem utilizar a 
variável local fat para armazenar os 
valores. Para tal faremos uso da recursividade:
Int Fatorial (int n, inf f)
{
If (n > 0)
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 26
Factorial (n-1,f*n)
Else
Return f;
}
Se quisermos calcular o fatorial de 5, basta 
chamar Fatorial (5,1).6
A linguagem funcional mais conhecida é LISP, 
muito usada na área de Inteligência Artificial 
(especificamente para a construção de sistemas 
especialistas, processamento de linguagem 
natural e representação do conhecimento), 
devido a facilidade de interpretação recursiva.
A linguagem APL embora tenha comando de 
atribuição (por atender ao paradigma imperativo) 
também é considerada uma linguagem funcional 
e pode ser usada para vários tipos de 
aplicações, desde controle de hardware e 
dispositivos até sistemas de informação 
gerencial.
Paradigma Lógico
Visão : “ O computador entende a lógica formal 
(fatos e regras)”
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 27
A mais conhecida linguagem desse paradigma 
chama-se Prolog e como as demais LPs desse 
grupo estão baseadas em um conjunto de 
predicados. Um predicado define uma relação 
entre constantes ou variáveis.
No paradigma lógico, os programas são 
declarativos: declara-se os resultados e não os 
procedimentos e à partir daí o programa 
encontra o caminho.
O paradigma lógico está relacionado à 
perspectiva da pessoa: ele encara o problema 
de uma perspectiva lógica. Um programa lógico 
é equivalente à descrição do problema expresso 
de maneira formal, similar à maneira como o ser 
humano raciocina sobre ele : de posse de vários 
fatos, derivam-se conclusões e novos fatos. 
Assim quando uma questão é formulada, um 
mecanismo de inferência tenta deduzir novos 
fatos a partir dos existentes para verificar a 
veracidade da questão.
A principal característica do paradigma lógico é 
que a execução dos programas corresponde a 
um processo de dedução automática.
A linguagem lógica mais conhecida é PROLOG. 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 28
Tal paradigma é bastante utilizado na construção 
de linguagens de acesso a banco de dados, 
sistemas especialistas (IA), tutores inteligentes e 
etc.
Nesta aula, você: 
★A impor tânc ia das l i nguagens de 
p r o g r a m a ç ã o n o c o n t e x t o d e 
desenvolvimento de software.
★Os conceitos e os principais paradigmas de 
Linguagens de Programação.
★Os conceitos e as principais metodologias e 
técnicas de programação.
★A relacionar as atividades de programação 
com atividades de análise de sistemas.
★Sobre a tênue relação entre os paradigmas 
de Linguagens de Programação, de 
programação e de Análise de Sistemas.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 29
REGISTRO DE PARTICIPAÇÃO
1.Um paradigma de programação fornece e 
determina a visão que o programador possui 
sobre a estruturação e execução do programa. 
Por exemplo, em programação orientada a 
objetos, programadores podem abstrair um 
programa como uma coleção de objetos que 
interagem entre si, enquanto em programação 
funcional os programadores abstraem o 
programa como uma sequência de funções. 
Portanto, surge a necessidade de estudar 
diferentes paradigmas de programação de 
virtude de:
I. Habi l idade maior de projetar novas 
linguagens.
II. Introdução de programas de inclusão social.
III. Aumenta-se a habilidade de aprender novas 
linguagens.
IV. Maior capacidade em desenvolver soluções 
computacionais.
Com base na aná l i se das asse r t i vas 
apresentadas, assinale a ÚNICA alternativa 
CORRETA.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 30
 1) Apenas I, III e IV corretas 
 2) Apenas I, II e III corretas 
 3) Apenas I, II e IV corretas 
 4) Apenas II, III e IV corretas 
 5) Apenas II e IV corretas 
2.Um paradigma é uma forma de abordar um 
problema. No paradigma da orientação a 
objetos, há um elemento, uma entidade 
autônoma que contém seus próprios dados que 
são manipulados pelos processos definidos para 
o objeto que interage com outros objetos para 
alcançar um determinado objetivo.  
O paradigma da orientação a objetos visualiza 
um sistema de software como: 
I. uma coleção de objetos interconectados.
II. Cada objeto é responsável por realizar tarefas 
específicas.
III. O sistema deve ser descrito a partir de suas 
funções mais amplas (FUNCIONAL e não OO). 
Com base na análise das assertivas abaixo, 
assinale a alternativa CORRETA.
 1) Apenas I e II corretas 
 2) Apenas I correta 
 3) Apenas I correta4) Apenas III correta 
 5) Apenas I e III corretas 
 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 31
3.Com relação aos diversos paradigmas de 
linguagens estudados, analise as assertivas 
abaixo 
I. No paradigma lógico há predomínio do uso 
de funções (FUNCIONAL e não lógico)
II. No paradigma concorrente as linguagens 
oferecem recursos para os programas 
executarem simultaneamente e concorrerem 
aos recursos.
III. No paradigma lógico declaram-se os 
resultados e não os procedimentos
IV. O paradigma OO, utiliza conceitos do 
paradigma imperativo na medida em que a 
programação dos métodos das classes é 
feira usando seus conceitos. 
Com base na análise das assertivas abaixo, 
assinale a alternativa CORRETA.
 1) Apenas II, III e IV corretas 
 2) Apenas II e III estão corretas 
 3) Apenas I, III e IV estão corretas 
 4) Apenas II e IV corretas 
 5) Apenas I e III estão corretas. 
 
4.A técnica de programação estruturada, 
caracterizada pela programação que se valia de 
3 estruturas de comandos: sequencial, decisão e 
iteração, além de uso da técnica de refinamento 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 32
sucessivos (top-down), surgia na época do 
paradigma:
 1) Imperativo 4) Lógico
 2) Orientado a objeto 5) Concorrente
 3) Funcional 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 33
CCT0208_EX_A1_201102276103
Disciplina: CCT0208 - PARAD.ANAL. E DESEN. 
Período Acad.: 2014.1 - EAD (G) / EX
1. Como se chama o técnica de programação que, 
primeiro, coibiu o uso de desvios incondicionais 
(como por exemplo GOTO), por ser prejudicial às 
boas técnicas de programação?
( ) Programação Orientada a objeto
( ) Programação Essencial
( ) Programação lógica
( ) Programação em Linguagem de Máquina
( x ) Programação Estruturada
2. Conceitualmente Paradigma é definido como um 
grupo de linguagens semelhantes que tenham 
características em comum. O paradigma imperativo 
ou procedural especifica a sequência de 
procedimentos com alterações no estado da memória 
da máquina de Von Neumann. Na lista abaixo marque 
uma vantagem do uso de uma linguagem de 
programação imperativa :
Facilidade na correção de programas.
( ) Adequado a computação paralela.
( x ) Eficiência nos programas, pois essas Linguagens 
de programação simulam a arquitetura do hardware. 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 34
( ) Requer acompanhamento passo a passo do estado 
de cada Variável.
( ) Facilidade na escrita de programas complexos.
3. Como se chama o paradigma de linguagem de 
programação que em que o computador é visto como 
uma máquina programável e que esta baseado no 
funcionamento da máquina de Von Neumman?
( ) Paradigma Lógico
( x ) Paradigma Imperativo ou Procedural
( ) Paradigma Concorrente
( ) Paradigma Orientado a Objeto
( ) Paradigma Funcional
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 35
AULA 2
PARADIGMAS DE ANÁLISE E PROJETO DE SOFTWARE
Nesta aula, você irá:
1.Conhecer os conceitos e os principais 
paradigmas de análise de sistemas.
2.Conhecer a evolução histórica dos paradigmas 
de análise de sistemas, identificando os 
problemas de cada um, propiciando o 
surgimento do próximo.
3.Conhecer as principais características e 
ferramentas (modelos) das análises tradicional, 
estruturada, essencial e orientada a objetos.
O processo de desenvolvimento de Software
★A tarefa de desenvolver software com 
qualidade não é fácil e demanda uma série 
de atividades com diferentes níveis de 
abstração, valendo-se de diferentes 
técnicas e propósitos. Conforme vimos nas 
aulas de PDS (Processos de Desenvolvimento de 
Software), o desenvolvimento de software 
requer algumas ETAPAS que, de acordo 
com a forma com que se relacionam entre 
si, originam os diferentes processos de 
desenvolvimento. 
★Estudamos, ainda na disciplina PDS, 
alguns processos, dentre os quais podemos 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 36
citar: Processo em Cascata Clássico, 
P r o c e s s o e m C a s c a t a c o m 
Retroalimentação, Processo Iterativo-
Incremental, Processo Prototipação, 
Processo Espiral, Processos Ágeis (como 
Extreme Programming – XP e Scrum) e 
RUP (Processo Unificado).
★Os processos têm em comum a existência 
de etapas ou fases e diferem na forma 
como o sistema é desenvolvido e na 
integração e relacionamento entre as 
respectivas fases (ou etapas) do processo. 
Por exemplo, no processo em Cascata 
Clássico, os requisitos tinham que ser 
TODOS identificados na fase de análise 
(início do processo) e caso alguma 
mudança fosse necessária, não haveria 
possibilidade de ajuste, devendo congelar 
os novos requisitos identificados até que o 
conjunto inicial de requisitos estivessem 
implementados.
★Já o Modelo Iterativo-Incremental divide os 
requisitos em partes e o sistema vai sendo 
construído aos poucos e as partes recém 
criadas vão sendo integradas às já 
existentes, repetindo este processo até que 
todos os requisitos do sistema estejam 
implementados.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 37
De acordo com o processo de desenvolvimento 
e a forma de sua implantação nas empresas, 
podem acontecer pequenas variações nas fases 
(ou etapas). Em alguns processos, algumas 
podem ser agrupadas em única fase, outras 
podem ser suprimidas, mas de uma forma geral: 
análise, projeto e implementação tendem a 
existir.
C o n c e p ç ã o ↔ A n á l i s e ↔ P r o j e t o ↔ 
Implementação ↔ Testes ↔ Manutenção ↔ 
Implantação 
O CONTEXTO DA ANÁLISE DE SISTEMAS
A análise de sistemas é um das principais fases 
de um processo de desenvolvimento de 
software, qualquer que seja este. Geralmente, 
uma das fases iniciais. As principais atividades a 
serem desenvolvidas na fase de análise, onde é 
feito um estudo do problema, ou seja, estudo do 
sistema e do contexto em que está inserido (na 
organização) são: 
★Identificar os requisitos do sistema, através 
do levantamento de dados com os usuários. 
Aqui, são usadas diversas técnicas, 
conforme as necessidades: entrevistas 
individuais, ou em grupo, questionário, 
reuniões planejadas, brainstorm, análise de 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 38
documentos, visitas in locco (ou análise de 
campo), dentre outras.
★Especificar O QUE o sistema deve fazer, 
em termos essenciais e com base nos 
requisitos identificados, ou seja, definir as 
funcionalidades que o sistema deve ter para 
atender ao que desejam seus usuários.
As definições da fase de análise independem de 
tecnologia, ou seja, são as soluções para o 
problema em estudo. É salutar que haja essa 
independência tecnológica para que a solução 
perdure no tempo, com diferentes possíveis 
implementações. Por exemplo, se fizermos uma 
solução lógica de divisão das partes do sistema 
dependendo de determinada linguagem de 
programação, amanhã, quando essa linguagem 
estiver obsoleta, a divisão terá que ser refeita. 
Se não houvesse tal dependência, mesmo que 
houvesse a troca da linguagem, a solução de 
análise continuaria a funcionar com várias 
tecnologias diferentes.
A tarefa de análise é desenvolvida pelos 
analistas de sistemas, que precisam ter ou 
desenvolver algumas aptidões, para conseguir 
lidar, de um lado, com o alto nívelde abstração 
dos usuários e, de outro, com o alto nível técnico 
da equipe de desenvolvimento (projetistas, 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 39
programadores, analistas de dados de dados, 
especialistas em redes, dentre outros).
A imagem (Relacionamento do Analista com 
usuários e equipe) mostra que o analista de 
sistemas precisa entender as necessidades e 
expectativas dos usuários a cerca do sistema e 
comunicar esse entendimento a equipe de 
desenvolvimento, através da especificação e 
modelagem do sistema.
Desde os primórdios da computação, a 
insatisfação dos usuários com o atendimento de 
suas necessidades e expectativas é causa de 
transtorno para os profissionais da área, sendo 
este mais um motivo para uma atenção efetiva 
do analista para com os usuários do sistema.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 40
Usuário
ENTENDIMENTO
Analista de Sistemas
ESPECIFICAÇÃO
Equipe de Desenvolvimento
OS PARADIGMAS DE ANÁLISE DE SISTEMAS
Os paradigmas que categorizam as técnicas e 
métodos usados na fase de Análise de Sistemas, 
conforme já explicado na aula 1, têm relação 
íntima com os paradigmas de programação que, 
por sua vez, ditam o estado da arte, posto que 
as linguagens de programação surgem antes 
das técnicas de análise e projeto de sistemas.
Todavia, ao escolher a técnica de análise a ser 
usada, conforme mostrou a imagem anterior, é 
feita, também, a escolha do paradigma da 
linguagem de programação que será usada, 
conforme ilustra a tabela.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 41
Paradigmas de Análise x Paradigmas de LPs
PARADIGMA DA ANÁLISE TRADICIONAL
A análise tradicional é a técnica que era usada 
na fase anterior ao surgimento da análise 
estruturada. Basicamente, produzia documento 
textual com a descrição do sistema e seus 
requisitos e, eventualmente, fazia uso de uma 
fer ramenta bastante popu lar chamada 
fl u x o g r a m a . A a b o r d a g e m u s a d a e r a 
exclusivamente voltada para a perspectiva das 
f u n c i o n a l i d a d e s d o s i s t e m a , m a i s 
especificamente dos programas (daí o uso dos 
fluxogramas).  Traçando um paralelo, no tempo, 
com os paradigmas de LPs, corresponde ao 
momento onde surgiam as linguagens de 3ª 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 42
geração (alto nível), mas os programas não 
eram estruturados sob nenhum aspecto e os 
GOTOs (desvios incondicionais) eram usados 
em demasia.
Corresponde ao momento inicial da crise do 
software (anos 70), pois, a complexidade dos 
sistemas demandados crescia dia a dia e os 
programas escritos eram de difícil manutenção o 
que não facilitava as melhorias nos sistemas já 
desenvolvidos. Pouco havia de testes no 
processo de desenvolvimento, que ainda não 
estava formalizado e firmado como era 
necessário, ou seja, a qualidade do software era 
relegada ao segundo plano.
PARADIGMA DA ANÁLISE ESTRUTURADA
Esse contexto, nada positivo, foi o pano de fundo 
para o surgimento (com esperança) da chamada 
análise estruturada, no início da década de 70, 
juntamente com as linguagens de 3ª geração 
(alto nível) ditas estruturadas, ou seja, que 
permitiam a escrita de programas com apenas 3 
estruturas: sequencial, decisão e repetição, 
abolia o uso de GOTOs, surgia a programação 
modular com refinamentos sucessivos, ou top-
down. Como os s istemas demandados 
aumentavam em complexidade, a técnica de 
anál ise est ru turada t rouxe a idé ia da 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 43
documentação do sistema através de diagramas, 
ou seja, de modelos que representavam a 
realidade. O reconhecimento da importância da 
modelagem de sistemas foi um marco muito 
importante no processo de desenvolvimento. 
Outra característica relevante foi a percepção da 
necessidade em se dividir o processo de 
desenvolvimento de sistemas em fases, em que 
cada uma representava um nível de abstração 
do sistema. Enquanto a sua percursora, a 
análise tradicional considerava apenas a 
perspectiva da análise funcional (como os 
processos funcionavam), a análise estruturada 
mostrou a importância de outra perspectiva 
fundamental: dos dados. O reconhecimento da 
importância dos dados gerou questionamentos 
do que era mais relevante: os dados ou as 
funções de um sistema? Mal se sabia que esse 
quest ionamento vir ia mais tarde a ser 
respondido pela análise orientada a objetos, que 
integrou as 2 perspectivas (funções e dados), 
mostrando que são igualmente relevantes.
A análise estruturada lançou mão de modelos 
gráficos para representar os requisitos e 
funcionamento. O principal modelo apresentado 
foi o DFD (Diagrama de Fluxo de dados); 
Segundo Edward Yourdon   Um DFD é uma 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 44
ferramenta de modelagem que nos permite 
imaginar um sistema como uma rede de 
processos funcionais, interligados por “dutos” e 
“tanques de armazenamento de dados". O DFD 
mostra a visão   estruturada das funções que 
compõem um Sistema. Conforme ilustrado pela 
figura 4 (DFD em níveis), o DFD pode ter vários 
níveis de detalhamento (metodologia Top down 
ou refinamentos sucessivos).
 A cada nível, mais detalhes são inseridos. O 
DFD de contexto representa   o relacionamento 
do sistema com as entidades externas e   o 
diagrama de nível ZERO mostra as principais 
funções. Em um DFD, as funções são 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 45
representadas por processos (representados 
pelos círculos), que quando não forem mais 
detalhados em outros níveis, devem ter sua 
lóg ica de func ionamento dev idamente 
especificada, conforme ilustra a figura   5 
(Especificação de processo).
O Dicionário de Dados (DD) é a ferramenta que 
complementa o DFD, explicando o conteúdo de 
cada um de seus elementos, conforme ilustra a 
figura 6 (Dicionário de dados).
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 46
PARADIGMA DA ANÁLISE ESSENCIAL
Antes da Análise OO, que revolucionaria a forma 
de pensar e estruturar os sistemas e programas 
viria a análise essencial como uma evolução 
(melhoria) da técnica de análise estruturada, na 
tentativa de solucionar os problemas surgidos 
com a aplicação prática desta. Os principais 
problemas da análise estruturada eram:
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 47
★Por onde começar a fase de análise? 
Não havia uma diretriz clara de como 
iniciar a modelagem na fase de análise. 
A d e c i s ã o fi c a v a a c a r g o d o s 
profissionais, ditada pelas experiências 
desses profissionais. Ou seja, mostrava 
s e r u m p r o c e s s o d e e x t r e m a 
subjetividade, como em geral são os 
processos analíticos que dependem dos 
seres humanos.
★Separação entre aspectos lógicos e físicos, 
ao modelar o sistema: 
Dizia-se que o DFD devia ser um 
modelo lógico, sem considerar aspectos 
físicos (tempo, forma de fazer e etc). 
Mas esse era um conceito abstrato e 
muitas vezes não considerado. Na 
verdade, o que se desejava era se 
concentrar nos reais requisitos dos 
usuár ios, sem confundi- los com 
aspectos irrelevantes.
★ A identificação das principais funções do 
sistema (nível zero do DFD) era 
subjetiva e o mesmo sistemapodia ter 
diferentes formas de agrupar e dividir 
funções, dependendo da visão de quem 
o modelava.
★ O DFD dava pouca ênfase a análise de 
dados, por isso, somente mais tarde, 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 48
quando Peter Chain cria o MER (Modelo 
de Entidade e Relacionamentos), pouco 
antes do surg imento da anál ise 
estruturada, é que o modelo de dados foi 
incorporado à fase de análise.
★ Um DFD desenvolvido com a técnica de 
análise estruturada sempre é diferente 
se feito por profissionais diferentes, dada 
a subjetividade da técnica.
A Análise Essencial, também chamada de 
Análise Estruturada Moderna surgiu como uma 
estratégia de modelar o que o sistema deve 
fazer para satisfazer os requisitos dos usuários, 
partindo do princípio que dispomos de tecnologia 
perfeita, obtida a custo zero. Essa característica 
visa resolver o problema de número [2] - 
Separação entre aspectos lógicos e físicos, ao 
modelar o sistema. Ao separar a tecnologia e 
dando-a como perfeita, capaz de processar tudo, 
de armazenar tudo, sem custo, concentra-se no 
problema do usuário e com isso aumentar as 
chances de sucesso do sistema.
Para suportar a modelagem dos sistemas 
complexos e grandes, característicos daquele 
momento, a Análise Essencial não atendia 
plenamente. Ainda havia lacunas a serem 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 49
preenchidas e estávamos no meio da crise do 
Software, onde o mercado clamava por uma 
metodologia de análise e projeto de sistemas 
mais efetiva, que apresentasse, na prática, 
m e l h o r e s r e s u l t a d o s . E m t e r m o s d e 
programação, as pessoas já haviam aprendido a 
usar rotinas e funções de bibliotecas, otimizando 
o tempo de desenvolvimento, mas faltava algo 
mais, que pudesse aumentar o índice de 
aproveitamento de código e otimizar o 
desenvolvimento. A fase de manutenção também 
não apresentava resultados satisfatórios, com 
custos elevados, dispêndio de tempo excessivo 
e programas de baixa qualidade.
Estávamos no auge da crise do software e os 
problemas mais contundentes da época eram:
✴Duplicação de esforços na construção do 
software.
✴Dificuldade em estimar (poucos dados 
iniciais). 
✴Não cumprimento de prazos (cronograma) 
de desenvolvimento.
✴Alto Custo de desenvolvimento (tempo e 
mão de obra).
✴Software não atende aos requisitos.
✴Alto custo de manutenção.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 50
✴Alto volume de documentação demandada 
pelos sistemas e dificuldade em mantê-los 
atualizados durante a fase de manutenção.
As pesquisas e desenvolvimento, em nível de 
linguagens de programação, já apontavam para 
as primeiras experiências com as linguagens 
orientadas a objeto. O conceito de objeto vem de 
encontro do que se precisa em termos de 
melhorias na implementação do código e 
potencializa a solução dos problemas que são 
apresentados a seguir, na medida em que:
✴Facilita o controle da complexidade inerente 
ao software.
✴Promove a reusabilidade --> componentes 
de código reutilizáveis.
✴Promove o desenvolvimento de sistemas de 
fácil manutenção, como consequência dos 
dois itens acima.
PARADIGMA DA ANÁLISE ORIENTADA A OBJETO (OO)
O paradigma orientado a objeto, doravante 
paradigma OO, trouxe uma grande revolução na 
forma de se pensar “o desenvolvimento de um 
sistema”, comparativamente ao paradigma 
antecessor, a Análise Essencial.   A visão de 
sistema, ilustrado na figura 10 (Mudança de 
Paradigma: Módulo x Objeto), até aquele 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 51
momento visto como um “conjunto de módulos 
(partes, ou subsistemas) integrados”, passa a 
ser a de um “conjunto de objetos 
Mudança de Paradigma: Módulo x Objeto
X
Conforme ilustrado na imagem, ao passo em 
que na análise essencial (e estruturada) o 
sistema era visto sob duas perspectivas isoladas 
(procedimentos que realizam operações sobre 
os dados), na análise OO, os objetos possuem 
características próprias, modeladas por seus 
atributos (dados) e métodos (procedimentos) e 
as classes representam um conjunto de objetos 
com as mesmas características. Ou seja, houve 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 52
uma integração entre procedimentos (agora 
chamados de métodos) e os dados (atributos) 
das duas perspectivas sobre as quais se 
modelavam os sistemas.
Classe encapsula dados e funções
MAIS SOBRE ANÁLISE ORIENTADA À OBJETOS
Na prática, em termos de modelagem conceitual 
de análise, a tarefa principal passa a ser a 
identificação dos objetos (na verdade as classes) 
envolvidos no contexto do sistema. 
Ao identificar os objetos, naturalmente, 
mode lam-se os a t r i bu tos (dados que 
carac te r izam o ob je to ) e os métodos 
(funcionalidades do sistema, inerentes aquele 
objeto ou classe). Na medida em que são 
identificados todos os objetos pertinentes a um 
sistema, já teremos os dados e procedimentos 
relacionados. 
Um modelo OO tem com entidade fundamental o 
Objeto, que recebe e envia mensagens, executa 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 53
procedimentos e possui um estado que, por 
proteção apenas ele pode modificar. Problemas 
são resolvidos, por meio de objetos, que enviam 
mensagens uns aos outros.
Um Modelo OO é formado por quatro elementos 
básicos:
1. Objeto: É o principal elemento do modelo OO. 
Representa as “coisas” a serem modeladas do 
mundo real. Um objeto pode ser algo concreto 
como um carro, um aluno ou algo abstrato 
como uma disciplina. Cada objeto possui os 
dados inerentes a ele, como por exemplo, 
Nome (José) e Matrícula (201101272201) de 
um aluno e possui as operações que ele 
executa, como incluir novo aluno ou alterar 
dados de um aluno existente.
2. Mensagens: Quando um outro objeto deseja 
que seja executada uma operação, da 
responsabilidade de outro objeto, ele manda 
uma mensagem a esse objeto, informando o 
que ele deseja que seja feito. A operação 
desejada será implementada por meio de um 
método.
3. Atributos: São dados que caracterizam o 
objeto.
4. Métodos : É um procedimento (implementado 
por uma rotina ou função) que executa uma 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 54
operação em um objeto e define parte de seu 
comportamento.
5. Classes: É um conjunto de objetos com as 
mesmas características (atributos e métodos). 
Por exemplo, os objetos IX35 e Sportage são 
o b j e t o s d a c l a s s e C A R R O , c u j a s 
características em comuns são:
a)Atributos: modelo, fabricante, ano de 
fabricação, portas, dentre outros
b)Métodos: incluir carro, vender carro, 
dentre outros.
Dentre as principais característ icas do 
paradigma orientado a objeto (OO), destacamos:
1. Encapsulamento: Encapsular significa 
esconder, ou seja, o objeto esconde seus 
dados do acesso indevido de outros 
objetos e somente permite que eles sejam 
acessados por operações implementadas 
p e l o s s e u s p r ó p r i o s m é t o d o s 
(funcionalidades que implementam o 
comportamento do objeto). Com isso, o 
encapsulamento protege os dados do 
objeto do uso arbitrário ou não intencional, 
o que pode ser visualizado na figura 12 
(Encapsulamento). O encapsulamento é 
u m a t é c n i c a p a r a m i n i m i z a r a 
interdependências entre as classes, pois 
apenas os métodos da respectiva classePARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 55
podem alterar seus dados (atributos), 
facilitando a identificação de erros e a 
alteração dos programas.
2. Herança: Mecanismo para derivar novas 
classes a partir da definição de classes 
existentes através de um processo de 
refinamento. Uma classe derivada ou 
descendente herda os dados (atributos) e 
comportamento (métodos) da classe base 
o u a n c e s t r a l o u a s c e n d e n t e . A 
implementação da herança garante a 
reutilização de código, que além de 
economizar tempo e dinheiro, propicia mais 
s e g u r a n ç a a o p r o c e s s o d e 
d e s e n v o l v i m e n t o , p o s t o q u e a s 
funcionalidades da classe base já foram 
usadas e testadas.
3. Polimorfismo: A palavra polimorfismo, 
deriva do grego e significa “muitas formas”. 
A partir do momento em que uma classe 
herda atributos e métodos de uma 
(herança simples) ou mais (herança 
múltipla) classes base, ela tem o poder de 
alterar o comportamento de cada um 
desses procedimentos (métodos). Isso 
amplia o poder do reaproveitamento de 
código promovido pela herança, permitindo 
que se aproveitem alguns métodos e se 
alterem (redefina) outros. Dessa forma um 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 56
método com mesmo nome em classes 
d i s t i n t a s p o d e t e r d i f e r e n t e s 
comportamentos. Por exemplo, pode-se 
usar a Herança para representar um 
r e l a c i o n a m e n t o e n t r e a s c l a s s e s 
Documento e Email, de forma que Email 
herda as definições (Atributos e métodos) 
de Documento. Suponha que um dos 
métodos de Documento seja Imprime. A 
classe email pode escrever novo código 
para o método Imprime, de forma que o 
email seja impresso de forma diferente do 
Documento. O método Imprime terá o 
mesmo nome, mas em cada classe se 
comportará de forma distinta.
O modelo de objetos surgiu (década de 80) 
c o m o u m m o d e l o p r o m i s s o r p a r a o 
desenvolvimento de software mais confiável 
devido as características inerentes ao modelo de 
objetos. Vejamos:
➡O conceito de encapsulamento permite a 
construção de classes independentes uma 
das outras, facilitando o desenvolvimento e 
a manutenção do software (alterações e 
melhorias na classe).
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 57
➡A herança e o polimorfismo permitem e 
facilitam a reutilização de código, útil na 
fases de implementação e manutenção.
O uso de técnicas orientadas a objetos facilita o 
controle da complexidade, uma vez que promove 
uma melhor estruturação de seus componentes 
e também permite que componentes já usados e 
validados possam ser reaproveitados. Cabe 
ressaltar que uma das principais razões para a 
baixa produtividade no desenvolvimento de 
software é a dificuldade de reutilização de código 
gerado pelos paradigmas de análise tradicionais. 
As hierarquias de classes (herança) são 
componentes portáveis entre aplicações, que, se 
bem projetados, podem ser reutilizados em 
vários sistemas sem modificação e, além disso, 
podem ser estendidos (polimorfismo) sem 
corromper o que já existe. Assim sendo, 
podemos dizer que o modelo de objetos 
proporciona modularidade trazendo os seguintes 
benefícios:
✴Reusabilidade: Softwares podem ser 
escritos com base em componentes já 
existentes.
✴Extensibilidade: Novos componentes de 
software podem ser desenvolvidos a partir 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 58
de outros já existentes, sem afetar o 
comportamento do componente de origem.
Sabe-se que software são intrinsecamente 
complicados devido aos novos requisitos das 
aplicações modernas: alta confiabilidade, alto 
desempenho, desenvolvimento de software 
rápido e barato, alta complexidade e tamanhos 
grandes.
O modelo OO veio para combater os problemas 
derivados da crise do Software, termo cunhado 
em 1968 na Europa e caracterizado pelos 
seguintes problemas do software: 
• baixa confiabilidade, 
• baixa qualidade, 
• alto custo de manutenção e 
• Qdupl icação de esforços na sua 
construção (tempo e dinheiro).
Um sistema desenvolvido com as características 
do modelo OO tende a ser bem estruturado, 
posto que os objetos são unidades coesas com 
interfaces simples que escondem as suas 
implementações.
No que se refere à forma de desenvolvimento, o 
que envolve o processo de desenvolvimento 
utilizado, o modelo OO permite uma melhoria 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 59
substancial do processo de construção de 
software em relação aos paradigmas tradicionais 
(tradicional, estruturado e essencial). A chave da 
análise OO é o foco em objetos (e em classes) e 
não em funções. O início da fase de análise não 
se dá mais pela identificação das diferentes 
funcionalidades do sistema e sim pela 
identificação dos objetos que compõem o 
sistema.
Inicialmente, vários especialistas criaram 
diferentes diagramas de análise e projeto OO. 
Num dado momento, tais profissionais se 
juntaram e com o melhor de cada um criaram 
uma linguagem de modelagem orientada a 
objeto, nascia a UML (Unified modeling 
language), cujos principais diagramas eram:
✴Diagrama de Casos de Uso.
✴Diagrama de Classes.
✴Diagrama de sequencia.
✴Diagrama de Atividades.
✴Diagrama de Implementação.
✴Diagrama de Componentes.
NESTA AULA, VOCÊ: 
Sobre os paradigmas de análise: 
tradicional, estruturado, essencial e 
orientado a objeto;
A contribuição de cada modelo para o 
processo de desenvolvimento de software;
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 60
As características e principais modelos de 
ferramentas de cada paradigma de análise 
de sistemas.
Registro de Participação
Com relação a fase de análise de qualquer 
processo de desenvolvimento de software, 
analise as assertivas a seguir:
i) É uma fase onde identificamos os requisitos 
do sistema, ou seja, aquilo que o usuário 
precisa que o sistema faça.
ii) É uma fase onde se especifica COMO fazer.
iii) É uma fase que independe de tecnologia, mas 
que já temos que saber a linguagem com que 
desenvolveremos.
iv)Sabermos a linguagem é fundamental para 
sabermos o paradigma de análise que 
usaremos.
v) É uma fase independente de tecnologia, para 
que a solução possa ser implementada de 
várias formas.
Com base em sua análise, assinale a alternativa 
correta:
 
 1) Estão corretas as opções I e V 
 2) Estão corretas as opções I, II e V 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 61
 3) Estão corretas as opções I, III e V 
 4) Estão corretas as opções I, IV e V 
 5) Estão corretas as opções I, II, IV e V 
 
2. Sobre a análise estruturada, assinale a 
ÚNICA opção falsa:
1.Foi o primeiro paradigma de análise a usar 
diagramas para representar o funcionamento do 
sistema. 
2.Surgiu num momento em que o software 
crescia de complexidade e via sua primeira 
crise. 
3.Surgiu na época da programação orienta a 
objeto. 
4.O processo de análise era segmentado: 
funcionalidade e dados em duas perspectivas 
distintas. 
 
3. Sobre a análise essencial, assinale a ÚNICA 
opção correta:
1. Revolucionou a forma de pensar sistemas, 
usando modelos distintos do paradigma 
antecessor. 
2. Trouxe uma grande contribuição ao 
mundo: a lista de eventos, facilitando a 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS62
atividade inicial do processo de análise de 
sistemas 
3. Surgiu numa época em que o software vivia 
sua era de ouro, onde os principais problemas 
haviam sido resolvidos 
4. Os principais modelos usados eram: DFD, 
DD, especificações dos casos de uso e 
diagrama de hierarquia entre os módulos. 
 
4. Sobre os conceitos inerentes ao paradigma 
orientado a objeto, analise cada assertiva abaixo 
e classifique-as como Verdadeira ou Falsa:
i. O conceito de encapsulamento é a base do 
modelo OO, permitindo que os atributos de 
um objeto sejam protegidos e só possam ser 
alterados pelos métodos do próprio objeto.
ii. O conceito de herança e polimorfismo facilita 
a reutilização de código.
iii. Objeto é um conjunto de classes com as 
mesmas características, por exemplo, os 
objetos Flamengo e Vasco são da classe 
Times.
iv. O modelo OO trabalha como o modelo 
essencial, ou seja, com as perspectivas de 
dados e funções de forma isolada.
Assinale a opção que apresenta a correta 
sequencia de V e F:
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 63
 1) V, V, F ,F 
 2) V, V, V, F 
 3) V, F, V, F 
 4) F, F, V, V 
 5) V, F, F, V 
 
 
CCT0208_EX_A2_201102276103
Disciplina: CCT0208 - PARAD.ANAL. E DESEN. 
Período Acad.: 2014.1 - EAD (G) / EX
1.
Com relação a fase de análise, existente em qualquer 
processo de desenvolvimento de software, analise as 
assertivas a seguir:
I. É uma fase onde identificamos os requisitos do 
sistema ou seja aquilo que o usuário precisa que o 
sistema faça.
II. É uma fase onde especifica-se o "COMO fazer".
III. É uma fase que independe de tecnologia, contudo 
já temos que definir a linguagem de programação com 
que desenvolveremos o sistema.
IV. É uma fase independente de tecnologia, para que a 
solução possa ser implementada de várias formas.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 64
Com base em sua análise das assertivas, assinale a 
ÚNICA alternativa correta
( ) Estão corretas apenas as assertivas I, III e IV
( X ) Estão corretas apenas as assertivas I e IV
( ) Está correta apenas a assertiva IV
( ) Está correta apenas a assertiva I
( ) Estão corretas apenas as assertivas II, III e IV
2.
No que tange ao papel desempenhado pelo analista de 
sistemas, qualquer que seja o porte ou tamanho da 
empresa, analise as seguintes assertivas. I. O analista 
de sistemas deve interagir apenas com o usuário-
gestor, ou seja aquele que toma decisão na empresa II. 
O analista de sistemas não pode interagir com os 
programadores, apenas com os projetistas de sistemas 
III. O analista de sistemas é o elo de ligação entre os 
usuários e a equipe de desenvolvimento IV. O analista 
de sistemas deve preocupar-se apenas com aspectos 
lógicos, abstraindo-se de qualquer aspecto tecnológico
( ) Apenas a opção IV está correta
( ) Estão corretas as opções I e IV
( ) Apenas a opção III está correta
( ) Estão corretas as opções I, III e IV
( X ) Estão corretas as opções III e IV
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 65
3.
Na programação orientada a objetos, muitos conceitos 
são abordados, dentre eles, podemos citar o de 
Herança, polimorfismo, objetos, classes, métodos e 
encapsulamento. Dentre as opções abaixo, qual 
conceitua encapsulamento ?
( X ) é definido como a forma de acesso a objetos onde 
desconhecemos os seus procedimentos internos e 
acessamos os mesmos através dos seus métodos, 
sempre protegendo os atributos
( ) é definido como uma instância criada a partir de 
uma classe, recebendo todas as características da 
classe o qual foi originada.
( ) é definido como a possibilita a criação de uma 
nova classe de modo que essa classe (denominada 
subclasse, classe-filha ou classe derivada) herda todas 
as características da classe-mãe (denominada 
superclasse, classe base ou classe primitiva); podendo, 
ainda, a classe-filha possuir propriedades e métodos 
próprios.
( ) é definido como a habilidade do analista de 
sistemas de modelar características do mundo real.
( ) é capacidade ou técnica que permite a um objeto 
possuir "vários comportamentos".
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 66
AULA 03
ANÁLISE ESTRUTURADA
Nesta aula, você irá: 
1. Entender um projeto desenvolvido com a 
técnica de análise estruturada, através das 2 
perspectivas: Modelo Funcional e Modelo de 
dados do Sistema.
2. Entender o modelo funcional do sistema, 
através do Diagrama de Fluxo de Dados 
(DFD), Dic ionár io de Dados (DD) e 
Especificação dos Processos primitivos do 
DFD.
3. Entender o modelo de dados do sistema, 
através dos depósitos de dados do DFD e do 
Modelo de Entidade e Relacionamento (MER).
4. Desenvolver pequenos sistemas usando a 
técnica da Análise Estruturada, bem como 
e n t e n d e r a s d i fi c u l d a d e s d e s s e 
desenvolvimento.
Contextualizando o momento em que surge a 
análise estruturada
Antes do surgimento da análise estruturada não 
existiam técnicas e nem ferramentas para 
especificação e modelagem de sistemas. As 
especificações iniciais eram meramente textuais 
e, mais tarde, com uso de fluxogramas, que na 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 67
verdade são mais adequados a especificação da 
lógica de programas e não de requisitos de 
sistemas.
N e s s a é p o c a n ã o h a v i a e q u i p e d e 
desenvolvimento com funções bem definidas tais 
como: analista, projetista e programador de 
s is temas. Geralmente poucas pessoas 
trabalhavam em um sistema e, portanto, 
participavam em sua maioria de todas as fases 
as fases do processo de desenvolvimento de 
sistemas.
Havia dificuldade do analista de sistemas em 
entender as necessidades do usuário e 
r ep resen tá - l as de f o rma adequada à 
compreensão da equipe técnica, ou seja, 
aumentam as dificuldades do analista de 
sistemas no papel de   comunicador e elo de 
ligação entre usuário e equipe técnica de 
desenvolvimento do sistema.
Os sistemas desenvolvidos não atendem as 
especificações dos analistas e necessidades dos 
usuários, em função da incompreensão das  
reais necessidades desses.
Os sistemas extrapolavam seus orçamentos e 
cronogramas, em função da dificuldade em 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 68
realizar previsões de tempo e dinheiro 
adequadamente e do real entendimento 
necessidades do que deve ser o sistema 
(funcionalidades que deve possuir).
Aumenta o tamanho e a complexidade dos 
sistemas e com isso as dificuldades no processo 
de desenvolvimento do software.
Surgem, em função do exposto no item [4], 
acima, as equipes de desenvolvimento para 
suprir a necessidade do trabalho em fases 
(analise, projeto, desenvolvimento, testes e 
implantação). Surgia o primeiro processo de 
desenvolvimento de software, denominado “Em 
Cascata Clássico”.
ATENÇÃO
O cenário estava propício à absorção 
d e n o v a s t é c n i c a s d e 
desenvolvimento de Sistemas, pois 
crescia, dia a dia, a demanda por 
novos e modernos sistemas nas 
empresas.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 69
UM BREVE HISTÓRICO DA ANÁLISE ESTRUTURADA
No início da década de 70 ganhou notoriedade, 
pela utilidade prática para construção de 
programas eficientes, a técnica de programação 
estruturada, possível com as linguagens 
estruturadas de alto nível (Fortran, COBOL, 
Pascal e etc).Tal técnica caracteriza-se pela escrita dos 
programas usando apenas 3 estruturas: 
sequencial, decisão e repetição, além da não 
utilização dos desvios incondicionais (GOTO), 
que tornavam os programas ilegíveis. A 
programação estruturada visava a escrita de 
programas legíveis, eficientes e de fácil 
manutenção.
Como a programação estruturada teve sucesso, 
foi necessária a criação de técnicas de 
construção de Projeto de Software compatível 
com os preceitos da programação estruturada.
Era a chegada da técnica do Pro jeto 
Estruturado, possibilitando que os programas 
pudessem ser projetados para usar as 
características superlativas da programação 
estruturada. Tal técnica trouxe ferramentas como 
o DEM , que dividia o programa em módulos 
(físicos) a serem programados. Trouxe também 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 70
relevantes conceitos como acoplamento e 
coesão e formas eficientes de particionar a 
arquitetura do software. 
Seguindo a cronolog ia, observamos o 
surgimento, no início dos anos 80, da técnica de 
Análise Estruturada, popularizada por Tom 
DeMarco, em seu livro sobre o assunto, 
chamado Análise Estruturada e Especificação de 
Sistema, uma referência para estudo do assunto.
CONCEITOS E CARACTERÍSTICAS DA ANÁLISE 
ESTRUTURADA
A Análise Estruturada, na prática, é uma 
atividade composta por um conjunto de técnicas 
e ferramentas cuja finalidade é auxiliar no 
processo de desenvolvimento de sistemas, 
especificamente na fase de análise e 
definição de sistemas. Descreve, passo a 
passo, as etapas que vão desde a identificação 
do problema até a efetiva implantação, na 
empresa, do sistema de informação que 
contemplará a sua solução.
A análise estruturada é uma atividade baseada 
na construção de modelos utilizando técnicas 
gráficas, como diagramas.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 71
AS PRINCIPAIS CARACTERÍSTICAS DA ANÁLISE 
ESTRUTURADA SÃO:
OBJETIVO
✴Visa auxiliar no estudo de partes ou toda a 
empresa com vistas a especificação de um 
sistema de computação eficiente que ajude a 
empresa a resolver problemas específicos.
COMO A ANÁLISE ESTRUTURADA CUMPRE O 
SEU PAPEL
✴Cria modelos, que são diagramas ou imagens 
gráficas, para representar os sistemas e 
facilitar as alterações necessárias (a qualquer 
tempo).
✴Retrata, nos diagramas, os fluxos de dados 
que fluem na empresa, especificamente nos 
processos pertinentes a área da empresa em 
estudo. O fluxo dos dados representado 
mostra como o processo funciona, ou seja, 
que entradas de dados recebe, quais 
processamento realiza e quais informações ou 
saídas gera.
✴Usa a técnica de refinamentos sucessivos ou 
top down, onde o sistema é dividido em 
partições funcionais, ou seja, apresentado sob 
a visão de múltiplos níveis, onde cada um 
detalha mais características que o nível 
anter ior. Út i l para o entendimento e 
modelagem de sistemas grandes e complexos, 
partindo-se de uma visão geral (macro) do 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 72
sistema e detalhando-o melhor na medida em 
que o estudo e a compreensão do problema 
avançam .
O PRINCIPAL ELEMENTO DA ANÁLISE ESTRUTURADA: 
O DFD - DIAGRAMA DE FLUXO DE DADOS
A base da proposição da Análise Estruturada é a 
elaboração do DFD. O DFD, por definição, é um 
modelo funcional, posto que apresenta a rede 
dos processos que compõem o sistema em 
desenvolvimento, interligados por fluxos de 
dados.
O DFD baseia-se no conceito de que um sistema 
baseado em computador é representado como 
“um transformador de dados em informação”, 
através do processamento, conforme mostrado 
na imagem.
Sistema como Processo de transformação d 
dados de entrada em Informação
A imagem mostra todos os elementos de um 
DFD.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 73
Processo:
1. Representado pela elipse ou círculo.
2. O nome do processo deve estar relacionado 
com uma atividade ou função do negócio. 
Devem ser evitados nomes muito físicos(gravar, 
imprimir), muito técnicos (deletar, becapear) ou 
nomes muito genéricos (processar).  
3. Transforma, pelo processamento, dados de 
entrada em informação de saída.
4. Representa as ações que o sistema executa.
5. Nem todos os processos representados no 
DFD devem ser automatizados.
6. Regras: Nenhum processo pode ter apenas 
saídas  (transforma o que?).
7. Nenhum processo pode ter apenas entradas 
(buraco negro)
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 74
Nome do Processo = verbo no infinitivo + 
substantivo + (Qualificador)
Fluxo de dados
Representado pela seta com o nome do fluxo.  
Veja abaixo as notações possíveis:
1. São dados e informações que trafegam pelo 
sistema.
2. Mostra como os fluxos fluem através do 
sistema, o caminho percorrido pelos dados no 
sistema.
3. O nome do fluxo deve ser um substantivo que 
facilite a identificação do dado ou pacote de 
dados transportado.  Todo fluxo de dados possui 
direção (origem e destino).  
4. Vejamos pelo exemplo apresentado na figura.
Fluxo 1 = entrada de dados enviada pela 
Entidade Externa 1
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 75
Fluxo 2 = entrada de dados enviada pela 
Entidade Externa 2
Fluxo 3 = dado armazenado no depósito 
de dados
Fluxo 4 = informação gerada pelo 
processo, pelo processamento dos fluxos: 
fluxo 1, Fluxo 2 e Fluxo 3.
Fluxo de dados
Regras para uso de fluxos de dados:
A.   O fluxo de dados tem 1 única direção, exceto 
de/para depósitos de dados.
B.   É permitido fluxo de dados entre:
       A.  2 processos.
       B.  1 processo e 1 depósito.
       C.  1 processo e 1 entidade.
C.   Não são permitidos fluxos de dados entre:
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 76
       A.  2 ou mais entidades externas.
       B.  2 ou mais depósitos de dados.
       C.  1 entidade externa e 1 depósito de 
 dados.
D.   O cruzamento de fluxos deve ser
 minimizado.
Depósito de dados
1. Representado pelas linhas paralelas ou 
retângulo aberto do lado direito, conforme   a 
imagem.
2.Armazenam, temporariamente, os dados que 
fluem no sistema.
3. Const i tuem a memór ia do s is tema. 
Representando os dados em estado de repouso.
4. As operações (fluxos entrando e saindo) em 
depósitos de dados são:
       -Incluir dados: seta (fluxo) chegando no 
depósito
       -Alterar e excluir dados: seta (fluxo) dupla 
(chegando e   saindo), representando uma 
consulta (existência do dado) e uma atualização 
dos dados.
    -Leitura de dados: seta saindo do depósito.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 77
Entidade Externa
a. São as fontes dos dados de entrada e destino 
das informações de saídas, respectivamente 
conduzidas pelos fluxos de dados.
b. Não fazem parte do sistema, mas interagem 
com ele, mostrando fontes dos dados de entrada 
e dest ino das informações de saídas, 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 78
respectivamente conduzidas pelos fluxos de 
dados.
Não fazem parte do sistema, mas interagem com 
ele, mostrando 
Conceitos e característ icas da anál ise 
estruturada
O DFD EM NÍVEIS
A análise estrutura propõe a elaboração do DFD 
em níveis,