O QUE É ORIENTAÇÃO A OBJETO?
UM MODELO "OO" É CONSTRUIDO COM
OBJETOS, CLASSES E RELACIONAMENTOS ENTRE ELES
MAS O QUE SÃO ESSAS COISAS?
UM SISTEMA CONSISTE DE OBJETOS
EXEMPLO: OBJETOS NUM SISTEMA DE
PEDIDOS EM 3 CAMADAS
OBJETOS TÊM RESPONSABILIDADES
RESPONSABILIDADE DE SABER CERTAS COISAS
RESPONSABILIDADES DE FAZER CERTAS COISAS
OBJETOS COLABORAM PARA DESEMPENHAR SUAS
RESPONSABILIDADES
EXISTEM RELACIONAMENTOS
ENTRE OBJETOS
PROPRIEDADES DE UM OBJETO
OBJETOS TÊM ESTADO:
A COLEÇÃO DE INFORMAÇÃO (ATRIBUTOS) MANTIDA DENTRO DO
OBJETO
EXEMPLO: OBJETO REPRESENTANDO
UMA PESSOA PODERIA TER UM NOME, CPF, ETC.
EXEMPLO: OBJETO REPRESENTANDO UM
PEDIDO PODERIA TER UMA DATA, LINHAS DE DETALHE,
ETC.
EXEMPLO: OBJETO REPRESENTANDO UM
MAILBOX PODERIA TER UMA LISTA DE MENSAGENS, ETC.
OBJETOS TÊM COMPORTAMENTO:
OPERAÇÕES OU AÇÕES FEITAS PELO OBJETO, NORMALMENTE
ENVOLVENDO SEU ESTADO
EXEMPLO: O OBJETO MAILBOX
PODERIA DESEMPENHAR A AÇÃO "ADICIONA
MENSAGEM"
OBJETOS TÊM IDENTIDADE:
CADA OBJETO É DIFERENTE DO OUTRO (TEM ESTADO PRÓPRIO) E
CADA UM TEM SEU PRÓPRIO TEMPO DE VIDA
CARACTERÍSTICAS DA MODELAGEM OO
ABSTRAÇÃO:
CONTROLAR A COMPLEXIDADE PELA ÊNFASE EM CARACTERÍSTICAS
ESSENCIAIS E PELA SUPRESSÃO DE DETALHES
É IMPORTANTE NÃO CONSIDERAR ALGO PARA
CONTROLAR A COMPLEXIDADE
O QUE NÃO CONSIDERAMOS É A IMPLEMENTAÇÃO
O QUE NÃO CONSIDERAMOS É A INTERFACE
ENCAPSULAÇÃO:
COLOCAR TUDO DA ABSTRAÇÃO (DADOS E COMPORTAMENTO)
DENTRO DE UM CONTAINER E FORÇAR O ACESSO ÀS
PARTES INTERNAS APENAS ATRAVÉS DA INTERFACE PÚBLICA
AGORA, AQUILO QUE NÃO
QUERÍAMOS CONSIDERAR NA ABSTRAÇÃO ESTÁ ESCONDIDO
É A TÉCNICA USADA PARA
ALCANÇAR A ABSTRAÇÃO DESEJADA E NÃO PERMITIR
FUJIR DELA E MEXER COM COISAS ÍNTIMAS
RESUMINDO: ABSTRAÇÃO É O QUE
SE QUER, ENCAPSULAÇÃO É UMA FORMA BOA DE
FAZÊ-LO
VANTAGEM BÁSICA DA
ENCAPSULAÇÃO: FACILITAR
MUDANÇAS ISOLANDO PEDAÇOS UNS DOS OUTROS
(REDUZINDO O ACOPLAMENTO)
MODULARIZAÇÃO:
DECOMPOR O MUNDO EM PEDAÇOS MENORES
VANTAGEM BÁSICA: CONTROLAR A COMPLEXIDADE
MANTENDO O FOCO EM COISAS MENORES, COESAS E
FRACAMENTE ACOPLADAS
HIERARQUIA:
ORGANIZAR AS ABSTRAÇÕES RELACIONADAS
VANTAGEM BÁSICA: PROMOVE A REUTILIZAÇÃO DE
ABSTRAÇÕES E A FLEXIBILIDADE (VER ADIANTE)
RELACIONAMENTOS ENTRE OBJETOS
JOÃO É O PAI DE MARIA. MARIA É A
FILHA DE JOÃO.
BIDU É O CACHORRO DE MARIA. MARIA É A
DONA DE BIDU.
ANA É A EMPREGADORA DE JOÃO. JOÃO É
EMPREGADO DE ANA.
ÀS VEZES, PODEMOS ESCOLHER ENTRE
REPRESENTAR ALGO COMO ATRIBUTO OU COMO RELACIONAMENTO
EXEMPLO: JOÃO É EMPREGADO DE
ANA PODE SER UM RELACIONAMENTO MAS PODERÍAMOS
DIZER TAMBÉM QUE JOÃO TEM UM ATRIBUTO
"EMPREGADOR"
OBJETOS COLABORAM ENTRE SI (USANDO OS
RELACIONAMENTOS)
OBJETOS ENVIAM MENSAGENS UM PARA
O OUTRO PARA IMPLEMENTAR ESTA COLCABORAÇÃO
CLASSIFICAÇÃO
É NATURAL AGRUPAR OBJETOS SEMELHANTES
EM CLASSES
FATORAR COISAS COMUNS É UMA
FORMA DE SIMPLIFICAR TAREFAS DE ENTENDIMENTO E DE
IMPLEMENTAÇÃO
EXEMPLO:JOÃO E MARIA SÃO
OBJETOS DA CLASSE "PESSOA"
É A CLASSE QUE DEFINE OS ATRIBUTOS E
OPERAÇÕES
OBJETOS SÃO INSTÂNCIAS DE
CLASSES
RELACIONAMENTOS ENTRE CLASSES: HERANÇA
CERTAS CLASSES PODEM TER UM
RELACIONAMENTO DE GENERALIZAÇÃO/ESPECIALIZAÇÃO
ENTRE ELAS
EXEMPLO: UMA CLASSE
"CLIENTE PESSOA FÍSICA" E
"CLIENTE PESSOA JURÍDICA" PODERIA SER
ESPECIALIZAÇÕES DA CLASSE GERAL
"CLIENTE"
"CLIENTE" É A SUPERCLASSE
"CLIENTE PESSOA
FÍSICA" E "CLIENTE PESSOA
JURÍDICA" SÃO SUBCLASSES
A SUPERCLASSE MANTÉM INFORMAÇÃO COMUM
(ATRIBUTOS E/OU OPERAÇÕES) A TODAS AS SUBCLASSES
DIZEMOS QUE AS SUBCLASSES HERDAM DA SUPERCLASSE
MODELAGEM OO
RESUMO: PODEMOS MODELAR O MUNDO COM
"OBJETOS"
OBJETOS
CLASSES
RELACIONAMENTOS ENTRE OBJETOS
RELACIONAMENTOS ENTRE CLASSES
AS ABSTRAÇÕES PODEM CORRESPONDER ÀS COISAS DO
DOMÍNIO DO PROBLEMA
O NÍVEL É MAIS MAIS
NATURAL
É MAIS FÁCIL
COMUNICAR-SE COM O USUÁRIO OU DOMAIN
EXPERT NA LINGUAGEM DELE
OS MESMOS OBJETOS EXISTEM EM TODAS AS FASES E UMA
NOTAÇÃO ÚNICA (OBJETOS) FACILITA PORTANTO A INTEGRAÇÃO ENTRE FASES DE
DESENVOLVIM,ENTO (PASSAR DE UMA FASE PARA A OUTRA)
FASES POSTERIORES ADICIONAM NOVOS OBJETOS MAS
OS OBJETOS DO DOMÍNIO DO PROBLEMA PERMANECEM:
SÃO ESTÁVEIS
É MAIS FÁCIL ENTENDER O DOMÍNIO DO PROBLEMA QUANDO
ESTA É QUEBRADO EM PEDAÇOS: GERENCIAMENTO
DA COMPLEXIDADE ATRAVÉS DA MODULARIZAÇÃO
O MESMO PODE SER DITO NO DOMÍNIO DO COMPUTADOR
(PROJETANDO E PROGRAMANDO COM OBJETOS)
A ABSTRAÇÃO CONTROLA A
COMPLEXIDADE (ESCONDENDO ALGO ATRAVÉS DA
SEPARAÇÃO DA INTERFACE E DA IMPLEMENTAÇÃO)
A ENCAPSULAÇÃO FACILITA AS
MUDANÇAS (ATRAVÉS DO ISOLAMENTO)
A HIERARQUIA (GRAFO DE HERANÇA) PERMITE UMA MELHOR REUTILIZAÇÃO
HIERARQUIA PROMOVE A FLEXIBILIDADE DE FAZER MUDANÇAS
DE FORMA LOCALIZADA
EXEMPLO: NOVOS TRECHOS DE
PROGRAMAS PODEM USAR UMA SUB-CLASSE NOVA E
CÓDIGO ANTIGO CONTINUA USANDO A SUPERCLASSE E
NÃO TOMA CONHECIMENTO DAS MUDANÇAS
PORÉM, HÁ PROBLEMAS DE
ACOPLAMENTO COM HERANÇA QUE VEREMOS EM OUTRO
CAPÍTULO
A REUTILIZAÇÃO DE PEDAÇOS É MAIS DIFÍCIL USANDO
PARADIGMAS ANTERIORES (MODULARIZAÇÃO VIA FUNÇÕES)
PORQUE NÃO POSSO USAR COISAS PRÉ-EXISTENTES TÃO
FACILMENTE
COM OBJETOS, POSSO DIZER: "ME DÊ DOIS
DAQUELES" PORQUE OBJETOS TÊM ESTADO
NÃO POSSO FAZER ISSO COM FUNÇÕES PORQUE
ELAS NÃO ENCAPSULAM ESTADO
PRECISAMOS DE UMA FERRAMENTA BÁSICA
PARA MODELAR: UMA LINGUAGEM QUE POSSA SER USADA EM TODAS
AS ETAPAS DO DESENVOLVIMENTO
UMA LINGUAGEM DE MODELAGEM PERMITE:
VISUALIZAR
ESPECIFICAR
CONSTRUIR
DOCUMENTAR SISTEMAS ORIENTADOS A
OBJETO
A LINGUAGEM PADRÃO DO MOMENTO: UNIFIED
MODELING LANGUAGE (UML)
VAMOS FAZER UMA RÁPIDA TOURNÊ DA
LINGUAGEM UML PARA COMEÇAR A PEGAR SEU SABOR
-
-
-
-
-
UMA LINGUAGEM DE MODELAGEM NÃO É
SUFICIENTE
PRECISAMOS TAMBÉM DE UM PROCESSO DE
DESENVOLVIMENTO
LINGUAGEM DE MODELAGEM +
PROCESSO DE DESENVOLVIMENTO = MÉTODO (OU
METODOLOGIA) DE DESENVOLVIMENTO
O QUE É UM PROCESSO DE DESENVOLVIMENTO?
DEFINE QUEM
FAZ O QUE, QUANDO E COMO, PARA ATINGIR UM
CERTO ALVO
VEREMOS DETALHES DE UM PROCESSO ADIANTE
POR ENQUANTO, SÓ UMA
INTRODUÇÃO
AS GRANDES FASES DE QUALQUER PROCESSO DE
DESENVOLVIMENTO
LEVANTAMENTO
DE REQUISITOS
ANÁLISE
PROJETO
IMPLEMENTAÇÃO
TESTES
HOJE, É CONSIDERADO ERRADO TER UM
PROCESSO QUE GERE UM "BIG BANG!"
NÃO SE DEVE TER O SOFTWARE
INTEIRO FUNCIONANDO POR INTEIRO NO PRIMEIRO
RELEASE
O RISCO É GRANDE DEMAIS!
UM PROCESSO DE DESENVOLVIMENTO DEVE SER:
ITERATIVO
(TER VÁRIAS ITERAÇÕES NO TEMPO)
INCREMENTAL
(GERAR NOVAS VERSÕES INCREMENTADAS A CADA
RELEASE)
"CORTES"
NO ESPAÇO DE SOLUÇÃO
ENTENDIMENTO
DO QUE O USUÁRIO QUER
O RESULTADO É UMA PROMESSA PARA O
CLIENTE
NÃO SÓ REQUISITOS FUNCIONAIS, MAS
TAMBÉM:
FACILIDADE DE USO NECESSÁRIA
QUEM UTILIZARÁ O PRODUTO
HARDWARE E SOFTWARE ALVO PARA O PRODUTO
QUALIDADE
DESEMPENHO
SEGURANÇA
COMPATIBILIDADE COM OUTROS PRODUTOS/VERSÕES
E NECESSIDADES DE MIGRAÇÃO
NECESSIDADES DE INTERNACIONALIZAÇÃO DO
PRODUTO
SUPORTE
PREÇO DA SOLUÇÃO
DOCUMENTAÇÃO NECESSÁRIA
USO DE PADRÕES
ASPECTOS LEGAIS
INTEGRAÇÃO COM OUTROS PRODUTOS
PACKAGING
ETC.
NÃO SE FALA "COMO" AS COISAS SERÃO FEITAS
"USE CASES" DESCREVEM CENÁRIOS DE
FUNCIONALIDADE DESEJADA
A ANÁLISE GERA UM MODELO PARA ENTENDER
O DOMÍNIO DO PROBLEMA
ANÁLISE TAMBÉM TRATA EM ALTO NÍVEL DE COMO UMA SOLUÇÃO POSSÍVEL PODE SER
MONTADA PARA ATENDER AOS REQUISITOS
ACABA GERANDO UMA ESPECIFICAÇÃO, MAS SEMPRE
DO PONTO DE VISTA DO USUÁRIO E TRATANDO APENAS
DO DOMÍNIO DO PROBLEMA
NÃO TRATA DE DETALHES DE IMPLEMENTAÇÃO
OBJETOS TRATADOS SÃO SEMPRE DO DOMÍNIO DO PROBLEMA
(BUSINESS OBJECTS)
MUITOS DIAGRAMAS UML PODEM SER USADOS
O MODELO É PARA O CLIENTE E NÃO PARA O
PROGRAMADOR
O PROJETO É UMA EXTENSÃO DO MODELO DE ANÁLISE
VISANDO SUA IMPLEMENTAÇÃO NUM COMPUTADOR
NOVOS OBJETOS APARECEM, MAS NÃO SÃO DO DOMÍNIO DO
PROBLEMA
O RESULTADO É PARA O PROGRAMADOR VER, NÃO O CLIENTE
OBJETOS DA ANÁLISE SÃO MANTIDOS E SÃO EMBUTIDOS
NUMA INFRAESTRUTURA TÉCNICA
AS CLASSES TÉCNICAS AJUDAM OS BUSINESS
OBJECTS A:
SEREM PERSISTENTES
SE COMUNICAREM
SE APRESENTAREM NA INTERFACE DO
USUÁRIO
TEREM DESEMPENHO ACEITÁVEL (USANDO
CACHES OU THREADS, POR EXEMPLO)
AS ATIVIDADES DE PROJETO INCLUEM:
FASE ARQUITETURAL (HIGH LEVEL DESIGN)
DEFINIÇÃO DE PACOTES, INTERFACES
ENTRE PACOTES
LEVANTAMENTO DE NECESSIDADES DE CONCORRÊNCIA
DETALHAMENTO DO FORMATO DE SAÍDA (INTERFACE
COM USUÁRIO, RELATÓRIOS, TRANSAÇÕES ENVIADAS
PARA OUTROS SISTEMAS, ...)
DECISÃO SOBRE USO/CRIAÇÃO DE BIBLIOTECAS
E/OU COMPONENTES
MAPEAMENTO DE OBJETOS PARA TABELAS SE O BD
FOR RELACIONAL
CONSIDERAÇÕES DE TRATAMENTO DE FALTAS
ESCRITA DO CÓDIGO
RELATIVAMENTE SIMPLES SE O PROJETO TIVER SIDO BEM
FEITO
PROGRAMADORES DEVEM NORMALMENTE SEGUIR REGRAS DE
CODIFICAÇÃO DA EMPRESA
ATIVIDADES INCLUEM CODE REVIEWS
NÃO SE DEVE CHEGAR A ESTA FASE CEDO DEMAIS!
MAIS CEDO VOCÊ AGARRA O TECLADO, MAIS VAI
DEMORAR A TERMINAR!
POUCOS NOVOS DIAGRAMAS NESTA FASE
INCLUI VÁRIAS FASES DE TESTES
TESTES FEITOS PELO PRÓPRIO PROGRAMADOR
UNIT TEST: TESTE DE CLASSES INDIVIDUAIS (OU
DE GRUPOS DE CLASSES RELACIONADAS)
FUNCTION TEST: TESTE DE FUNÇÕES INTEIRAS
(ITEM DE MENU, P. EX.)
COMPONENT TEST: TESTE DE COMPONENTES INTEIROS
(EXE, DLL, ...) SEM (OU COM POUCO) SCAFFOLDING
TESTES FEITOS POR EQUIPES INDEPENDENTES DE TESTE
SYSTEM TEST: TESTA A INTEGRAÇÃO ENTRE TODOS
OS COMPONENTES DO PRODUTO
ALPHA TEST: TESTE DE PRODUTO INTEIRO DENTRO
DE CASA
BETA TEST: TESTE DE PRODUTO INTEIRO FORA DE
CASA
TESTES DEVEM SER AUTOMATIZADOS
intro2.htm programa