Você está na página 1de 23

Universo – Campus BH

Prof. Leila Guimarães


Bibliografia
 Gane, Chris e Sarson, Trish, Análise Estruturada de Sistemas, Ed. LTC,
1983.
 Davis, W. S., Análise e Projetos de Sistemas: Uma abordagem Estruturada,
Ed. LTC, 1987.
 DeMarco, Tom, Análise Estruturada e Especificação de Sistema, Ed.
Campus, 1989.
 Yourdon, Edward, Análise Estruturada Moderna, Ed. Campus,
 McMenamim, Sthephen M. e Palmer, John F., Análise Essencial de
Sistemas, Editora McGraw-Hill, Ltda., 1991.
 Booch, G., Rumbaugh, J. e Jacobson, I., The Unified Modeling language
User Guide, Addison-Wesley, 1999.
 Wazlawick, Raul Sidney, Análise e Projeto de Sistemas de Informação
Orientados a Objetos, Ed. Campus, Série Campus/SBC, 2004.
 Rumbaugh, James, e outros, Modelagem e Projetos Baseados em Objetos,
Editora Campus, 1994.
 Coad, Peter e Yourdon, Edward, Análise Baseada em Objetos, Editora
Campus, 1992.
 Coad, Peter e Yourdon, Edward, Projeto Baseado em Objetos, Editora
Campus, 1993.
Histórico das Metodologias de
Desenvolvimento de Sistemas

Crise do Software (~1970)


• Desenvolvimento de Software como “arte” – desenho de telas e
arquivos
• Problemas de execução - erros
• Prazos extrapolados
• Custos inesperados – correção de erros e adaptação do código às
reais necessidades do usuário
• Empresas dependentes de computadores com sistemas legados
que necessitam modificações mas com código/documentação ilegível
ou inexistentes.
• Insatisfação de usuários
Crise do Software (~1970)

Problemas
• Pouco tempo para coletar dados sobre o desenvolvimento do software
• Comunicação durante o desenvolvimento muito fraca
• Falta de testes complexos

Surgem as Metodologias de Desenvolvimento de Sistemas

• Análise Estruturada
• Análise Essencial
• Análise Orientada a Objetos
A Análise auxilia na comunicação entre as pessoas
envolvidas, no gerenciamento da complexidade e na
redução dos custos de desenvolvimento.

Evolução da Análise:
Técnica Enfoque Abordagem

Análise Estruturada Processos e Top-Down


Dados (Decomposição
Funcional)
Análise Essencial Controles, Middle- Out (Lista de
Processos Eventos)
e Dados
Análise Orientada ao Dados, Controles (Def. De Objetos).
Objetos e Processos
Análise Estruturada
 Enfatiza a perspectiva das funções, com ênfase nos processos.
 Utiliza as seguintes ferramentas:
 Diagrama de Fluxo de Dados.
 Dicionário de Dados.
 Especificação da Lógica de Processos.
 A análise estruturada clássica não modela o comportamento temporal,
nem complexos relacionamentos de dados.
 Bibliografia
Gane, Chris e Sarson, Trish, Análise Estruturada de Sistemas, Ed. LTC,
1983.
Davis, W. S., Análise e Projetos de Sistemas: Uma abordagem
Estruturada, Ed. LTC, 1987.
DeMarco, Tom, Análise Estruturada e Especificação de Sistema, Ed.
Campus, 1989.
Análise Estruturada - DFD

Pedido_preços
E1 E2
Departamento Fornecedores
de produção
P1
Lista_materiais
Entidade Escolher Preços_material
necessários
externa fornecedor
ced or
ne
for
ad os_ Processo
D Lista

D1 Fornecedores
P2
Dado Pedir Nota_encomenta
s _for
n eced materiais
o r
Depósito
Fluxo de dados
De dados
Diagrama de Contexto

Análise Estruturada
Diagrama Zero

1
2

Diagrama 1 Diagrama 2
Explosõe
s
1.2 2.1

1.1 2.2

Especificação
Processo Processo Processo Processo
da lógica dos
1.1 1.2 2.1 2.2
processos
Análise Essencial
 É uma evolução da Análise Estruturada por adicionar a
preocupação com o controle.
 Usa uma lista de eventos externos como base para o
particionamento do sistema.
 O modelo essencial é construído sem considerar restrições
de implementação (assume uma tecnologia perfeita) –
essência do sistema
 Bibliografia:
Yourdon, Edward, Análise Estruturada Moderna, Ed. Campus,
McMenamim, Sthephen M. e Palmer, John F., Análise
Essencial de Sistemas, Editora McGraw-Hill, Ltda., 1991.
Análise Essencial

 O modelo essencial é formado pelo:


 Modelo Ambiental – define a fronteira entre o sistema
e o ambiente.
 Modelo Comportamental – descreve o comportamento
interno do sistema.
 Modelo de Informação – modela os dados necessários
às atividades essenciais do sistema.
 Modelo de Implementação – extensão do modelo
essencial com restrições de implementação
Análise Essencial
 Modelo Ambiental
 Diagrama de Contexto - Define as interfaces entre o sistema e
o ambiente. São identificadas informações externas e as
produzidas como saída.
 Lista de Eventos - Identifica os eventos que ocorrem no
ambiente e como o sistema deve reagir.

• Modelo Comportamental
 Mostra o comportamento interno do sistema.
 Usa como ferramenta DFD com abordagem diferente.
 Constrói um DFD para cada evento (DFD de resposta a
eventos). A partir dele é feito o agrupamento para formar os
diagramas superiores e inferiores.
 Dicionário de Dados e Especificação de processos
Análise Essencial
 Modelo de Informação
 Representa os dados necessários ao sistema.
 Ferramentas utilizadas são:
 Diagrama de entidade e relacionamento
 Deriva da lista de eventos
 Representa a estrutura estática dos dados
 Dicionário de Dados
1 n
Empregado Dependente
Análise Essencial

Modelo de implementação
 Insere restrições de implementação aos modelos
comportamental e de dados
Fronteiras de automação, tempo de execução, capacidade
de armazenamento, comunicação, etc.
Análise Orientada a Objetos
 Cenário
 Mudança do enfoque das funções para os dados
 Preocupação em modelar de forma mais detalhada o sistema
 Análise mais próxima da realidade
 Facilidade na comunicação com o usuário
 Objetos como entidades do mundo real
 Objetos com estrutura e comportamento e que se
comunicam
 Dificuldades em fazer alterações nas estruturas de dados nas
abordagens tradicionais
 “Se eu alterar a definição desse dado, quais programas
serão afetados?”
Análise Orientada a Objetos
 Cenário
 Trabalha com conceitos já conhecidos - Modularidade,
Abstração, Encapsulamento, Mascarar informações, etc
 Orientação a objetos apesar de antiga não era utilizada
por falta de pessoas treinadas, interesse em manter a
cultura adquirida, ferramentas imaturas. Isso começa a se
resolver.
O mundo real é composto por objetos. Cada objeto tem propriedades
e comportamentos. Então porquê não desenvolver programas que
simulem no computador os objetos do mundo real com suas
propriedades e comportamentos?
Análise Orientada a Objetos
 Segundo Yourdon, “Um sistema construído usando um
método Orientado a Objetos é aquele cujos componentes
são partes encapsuladas de dados e funções, que podem
herdar atributos e comportamentos de outros componentes
da mesma natureza, e cujos componentes comunicam-se
entre si por meio de mensagens.”

 Objetivo: Encontrar os objetos, organizá-los, descrever como


interagem através de mensagens, definir operações de seus
comportamentos.
Análise Orientada a Objetos
 Nos métodos tradicionais de análise, o comportamento do
sistema e seus dados eram considerados separadamente.
Com orientação a objetos, comportamento e dados são
integrados, assim encapsulando detalhes internos de um
objeto dos demais.

Análise Enfoque Foco

Estruturada Conjunto de programas que executam processos Sistema


e Essencial Sobre dados

Orientada a Conjunto de “entidades” que têm características e Objeto


Objetos Comportamentos próprios
 
Análise Orientada a Objetos
 Concentra-se nos aspectos essenciais do objeto sem
detalhamento, focando em suas características e o que ele faz;
 Impede que um sistema se torne tão interdependente que uma
pequena alteração ou implementação resulte em grandes
alterações em sua estrutura;
 Combina estrutura (dados) e comportamento (funções) em um
único objeto;
 Compartilha elementos estruturais e de comportamento com
objetos de níveis inferiores;
 Enfatiza a estrutura de objetos ao invés da estrutura de
procedimentos, ou seja, o que o objeto é e não como ele é
utilizado.
Por que usar Orientação a
Objetos?
 Atualmente temos ferramentas completas para sua utilização
(integrando especificação e implementação)
 Praticamente todas as ferramentas novas de programação
permitem suporte a sua utilização
 Qualidade melhor do software (se usada corretamente)
 Produtividade em função do reuso (não é imediata)
 Produção de códigos mais fáceis de serem entendido (se for bom)
 Adequada para a construção de sistemas distribuídos e para
aplicações voltadas a Internet
 Permite acesso controlado às informações
Dificuldade:
Usuário não pensam seus problemas de
forma orientada a objetos
Requisitos não são orientados a objetos

Requisitos de usuários são


funcionais
 Com o rápido crescimento surgiram várias metodologias
principalmente ente 1989-1994
 Metodologias (processo OO e linguagem de modelagem
própria). As mais significativas foram:
 OMT, Rumbaugh

 COAD/YOURDON, Coad-Yourdon,

 OOSE, Jacobson,

 SHLAER/MELLOR, Shlaer-Mellor,

 BOOCH, Grady Booch


 Como os métodos Booch e o OMT estavam sendo largamente
utilizados, seus autores juntaram forças para fazer um método
unificado, com uma linguagem padrão. Posteriormente Jacobson
juntou-se a equipe.
 Linguagem de modelagem proposta por Booch, Rumbaugh e
Jacobson
 UML (Unified Modeling Language)
 Padronizada pela OMG (Object Management Group)
 Conta atualmente com o apoio de vários autores e várias
empresas
 O RUP (Rational Unified Process) foi proposto como uma
metodologia para desenvolvimento de sistemas, orientada a
objetos, utilizando UML

Você também pode gostar