Buscar

PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS - AULA 02

Prévia do material em texto

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 1
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 2
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 3
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 4
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.
Usuário
⬇ Entendimento
Analistas de Sistema
⬇ Especificação
Equipe de Desenvolvimento
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 5
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 x Paradigmas de LPs
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 6
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ª 
geração (alto nível), mas os programas não 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 7
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 fundopara 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 
documentação do sistema através de diagramas, 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 8
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 percussora, 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 
ferramenta de modelagem que nos permite 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 9
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 
representadas por processos (representados 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 10
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 11
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 12
★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 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 13
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 14
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 15
✴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ódigoreutilizá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 16
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 17
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 18
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 19
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 classe 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 20
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 21
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 22
➡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 serestendidos (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 23
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 duplicaçã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 
substancial do processo de construção de 
software em relação aos paradigmas tradicionais 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 24
(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 25
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:
 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 26
 1) Estão corretas as opções I e V 
 2) Estão corretas as opções I, II e V 
 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. 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 27
2. Trouxe uma grande contribuição ao 
mundo: a lista de eventos, facilitando a 
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.
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 28
Assinale a opção que apresenta a correta 
sequencia de V e F:
 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 
 
 PARADIGMAS DE ANÁLISE E DESENVOLVIMENTOS 29

Outros materiais

Materiais relacionados

Perguntas relacionadas

Materiais recentes

Perguntas Recentes