PARADIGMAS DE ANALISE E DESENVOLVIMENTOS 2

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
AULA 01
ABORDAGEM INICIAL
Nesta aula, você irá:
1. Reconhecer a importância das linguagens de
programação	no	contexto	de
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. S a b e r r e l a c i o n a r a s a t i v i d a d e s d e
programação com atividades de análise de
sistemas.
5. E n t e n d e r a t ê n u e r e l a ç ã o e n t r e o s
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
papel preponderante no processo 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. P r o p i c i a r a o p r o g r a m a d o r e s c r e v e r
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
de problemas demandados para 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 linguagens 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 capacidade para escolher 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 limita-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
Trata-se da representaçã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
A1 01 10
03 06 01 12
Instrução em
linguagem de
montagem
MOV AX,
[0110]
ADD AX,
[0112]
Comentários sobre a instrução
Copiar o conteúdo de 0110 no registro
AX
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 montagem
PARADIGMAS 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) foi o Fortran, desenvolvida
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
leitura 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 calculadora programá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
paradigma imperativo, caracterizado
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.
Ilustração representando a
"Arquitetura de von Neumann"
Neumann, à época de
Los Alamos (ca.
1943-1945)
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
16
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
refinamentos sucessivos (top down),
incentivando a organização do programa em
subprogramas (partes), construídos com 3 tipos
de processamento:
sequencial, condicional e iterativo (repetitivo).
Ou seja o paradigma imperativo esta
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
d e c a d a c é l u l a . C o m o p r o g r a m a r,
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
instruções também precisam 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 fim de ilustrar a interação destas
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 Desvantagens das
Imperativas	LPs Imperativas
Os programas tendem
a ser eficientes, pois
essas LPs simulam o
funcionamento da
arquitetura	do
hardware
Dificulta a escrita de
p r o g r a m a s
complexos, pelas
características das
linguagens no que se
refere a seguir a
M a q u i n a d e Vo n
Neumann.
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
21
Vantegens das LPs Desvantagens das
Imperativas	LPs Imperativas
Inadequado	a
computação em
paralelo
★D i fi c u l d a d e e m
corrigir programas, já
que essa atividade
decorre	da
dependência do
conteúdo de cada
célula de memória.
★R	e	q	u	e	r
acompanhamento
passo a passo do
estado de cada
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
quando ela 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 identi ficar 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
Tipos de dados
Variável
Paradigma de Objetos
Classes / Tipos abstratos de
dados
Objeto / Instância
Função / Procedimento Operação / Serviços
C h a m a d a	d e Envio de mensagens
procedimento / função
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 i m p o r t â n c i a d a s l i n g u a g e n s d e
programação no contexto de
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.	Habilidade 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álise das assertivas
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 correta
4) 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,
Processo	em	Cascata	com
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.
Concepção ↔ Análise ↔ Projeto ↔
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ível de 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.
Usuário
ENTENDIMENTO
Analista de Sistemas
ESPECIFICAÇÃO
Equipe de Desenvolvimento
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
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
ferramenta bastante popular chamada
fluxograma. A abordagem usada era
exclusivamente voltada para a perspectiva das
funcionalidades do sistema, mais
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 sistemas demandados
aumentavam em complexidade, a técnica de
análise estruturada trouxe 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
questionamento viria 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ógica de funcionamento devidamente
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 decisão ficava a cargo dos
profissionais, ditada pelas experiências
desses profissionais. Ou seja, mostrava
ser um processo de extrema
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ários, 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 sistema podia 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 surgimento da análise
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,
melhores resultados. Em termos de
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 identi ficar os objetos, naturalmente,
modelam-se os atributos (dados que
caracterizam o objeto) 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
objetos da classe CARRO, cujas
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ísticas do
paradigma orientado a objeto (OO), destacamos:
1. Encapsulamento: Encapsular signi fica
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
pelos seus próprios métodos
(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 é
uma técnica para minimizar a
interdependências entre as classes, pois
apenas os métodos da respectiva classe
PARADIGMAS 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
ou ancestral ou ascendente. A
implementação da herança garante a
reutilização de código, que além de
economizar tempo e dinheiro, propicia mais
segurança	ao	processo	de
desenvolvimento, posto que as
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
distintas pode ter diferentes
comportamentos. Por exemplo, pode-se
usar a Herança para representar um
relacionamento entre as classes
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)
como um modelo promissor para 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
•	Qduplicaçã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 (Uni fied 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 DESENVOLVIMENTOS
62
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), Dicionário 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
entender as dificuldades desse
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.
Nessa época não havia equipe de
desenvolvimento
com funções bem definidas tais
como: analista, projetista e programador de
sistemas. 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
representá-las de forma 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
de	novas	técnicas	de
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, e ficientes 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 Projeto
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 cronologia, 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.
C ONCEITOS 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,
especi ficamente 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
A S 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
a n t e r i o r. Ú t i l p a r a o e n t e n d i m e n t o 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. Constituem a memória do sistema.
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 destino 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ísticas da análise
estruturada
O DFD EM NÍVEIS
A análise estrutura propõe a elaboração do DFD
em níveis, através da técnica de refinamentos ou
top down, onde se inicia com um DFD geral e
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
79
detalha-se cada um, na medida em que há
necessidade.
DFD EM NÍVEIS
✴ Usado para sistemas grandes, cuja
representação do DFD equivalente torna-se
grande, complexo e ininteligível para ser
modelado em único diagrama.
✴ Idéia de modularizar o sistema em sub-
sistemas e assim sucessivamente até
chegar a um nível em que a composição
não seja mais necessária.
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
80
✴ A uma função que não precisa mais ser
decomposta, chamamos de função primitiva
ou primitiva funcional.
✴ Todo DFD pode ser decomposto em DFDs
de nível inferior, recursivamente, até
alcançarem as primitivas funcionais.
✴ Processos Pais e Filhos.
✴ Convenção : Número de processos
(funções) por níveis : +- 7, ou seja mínimo
de 5 a máximo de 9. O mínimo não deve
ser muito considerado, mas o máximo sim
(dificulta entendimento).
✴ É conveniente que em cada nível os
processos estejam em nível de
detalhamento próximo, ou seja não convém
que em 1 dos níveis um dos processos
ainda precise ser detalhado em outros
níveis inferiores ao passo que outros
processos do mesmo nível já são primitivos.
Cada DFD deve apresentar um nível de
detalhe equilibrado.
✴ Os processos que tratam de rotinas de
erros e exceção devem ser tratados nos
níveis mais inferiores.
1ª Etapa : DIAGRAMA DE CONTEXTO.
✴ Objetivo : Delinear o âmbito do sistema em
estudo. Representa o Sistema e suas
interfaces.
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
81
✴ Mostra :
✓ Um grande Processo – o Sistema
✓ TODAS as entidades externas, que
interagem com o Sistema.
✓ Principais fluxos relacionados com as
entidades externas.
✴ NÃO Mostra
✓ Fluxos de erros ou exceção
✓ Depósitos de dados.
Vide figura abaixo, mostrando o DFD de contexto
para o Sistema de Controle de Pedidos.
2ª Etapa : DIAGRAMA de NÍVEL 0
✴ Objetivo : Apresentar as "macro-funções" do
sistema.
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
82
✴ Identifique as principais funções lógicas do
sistema. Cada uma dessas divisões deve ser
um processo de nível 1.
✴ Neste nível temos que olhar e entender as
"macro funções” do sistema, sem entender
detalhes.
✴ Deve Representar o "todo" e as principais
relações entre os processos.
✴ Todos os fluxos mostrados no Diagrama de
Contexto devem estar representados no nível
0.
✴ É hora de representar os principais Depósitos
de dados (acessados por pelo menos 2
depósitos). Podem haver depósitos cuja
necessidade de representação se faça sentir
apenas em níveis mais inferiores (depósitos
locais, inerentes ao processo em explosão).
3ª Etapa : DIAGRAMA de NÍVEL N (1 EM
DIANTE)
✴ Cada processo que ainda não se encontra em
sua primitiva funcional precisa ser
decomposto.
✴ Esta decomposição deve-se à complexidade
do processo, cujo desenho ainda é complexo e
difícil de ser especificado.
✴ Quando um processo tem uma especificação
(em português estruturado) complexa e de
difícil compreensão (na prática, seria uma
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
83
especificação que exceda uma folha), deve ser
“explodido” em um nível, para representa-lo de
forma mais efetiva, em outros sub processos.
BALANCEAMENTO DO DFD
É necessário que haja coerência entre os níveis
de DFD e que haja um balanceamento também.
REGRA GERAL: Ao particionar (explodir) um
processo, qualquer fluxo, depósito ou entidade
que esteja em 1 nível, deve aparecer no nível
imediatamente anterior.
Cada DFD deve estar balanceado com relação
ao processo que o originou:
O conjunto de entradas e saídas de 1 DFD
deve ser equivalente ao que o originou.
A consistência da entrada e saída entre os
níveis é obrigatória: não pode haver fluxo de
entrada/saída no nível inferior que não esteja
no nível superior.
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
84
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
85
Pelo exemplo, o DFD que contém os processos
2.1 e 2.2 encontra-se NÃO balanceado pois:
1. No nível anterior (processos 1, 2 e 3), acima e
a esquerda, o processo 2, recebe como entrada
o fluxo “e” (do processo 1) e gera como saída o
fluxo “d” (para o processo 3).
2. No nível seguinte, existe um fluxo “x”, que
chega ao processo 2.1, que não existe chegando
ao processo 2, no diagrama do nível anterior
(acima e a esquerda). Por isso diz-se que o
mesmo esta NÃO balanceado, pois está
incompatível com o nível anterior e deve ser
revisto.
Num DFD não é necessário desenhar um
depósito de dados que apareça apenas no
interior de cada um seus processos. Se um
depósito é usado por mais de 1 processo em 1
DFD então deve ser representado.
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
86
Quando um depósito de dados é usado por 2 ou
mais processos, deve ser apresentado neste
nível e em cada diagrama de nível inferior que
descreva os processos que usam o depósito de
dados.
AS FERRAMENTAS DA ANÁLISE ESTRUTURADA
Além do DFD, a análise estruturada utiliza dois
outros modelos que o complementam.
Dicionário de Dados (DD) que complementa o
DFD, explicando melhor seus elementos:
entidades, fluxos de dados e depósito de dados.
Ao ler um DFD você precisará ter em mãos o DD
(Dicionário de dados), para que possa
compreender os dados que compõem um fluxo
ou os dados que estão sendo armazenados em
um depósito de dados, por exemplo.
1. Para as entidades, descreve-se a sua
finalidade (interação com o sistema).
2. Para os fluxos de dados, descreve-se a sua
composição. Por exemplo, vamos supor o fluxo
de dados Pedidos_Livro. No DD deve-se
especificar todos os dados que fazem parte
desse pedido.
3. Para os depósitos de dados deve-se
especi ficar os dados que estão sendo
armazenados.
PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS
87
4. Os fluxos e depósitos vão gerar estruturas
intermediárias chamadas Estruturas de dados.
5. As estruturas de dados