Projeto de Sistema Orientado a Objeto

1
Projeto de Sistema Orientado a Objeto
2
Arquitetura

• Várias definições existentes
• Conjunto de artefatos utilizados para
  especificar
• decisões estratégicas sobre a estrutura e o
  comportamento do sistema
• as colaborações entre os elementos do sistema
• elementos físicos do sistema

3
Importância da Arquitetura

• Base arquitetural é essencial para o sucesso de
  um projeto OO.
• Alguns tentam ignorar esa fase (rush to code)
• Resultado problemas posteriores.
• A arquitetura é desenvolvida de forma interativa
  ao longo da fase de Elaboração
• Desenvolvimento da arquitetura implica em código
  executável testado - validação da arquitetura

4
Mecanismos Fundamentais

• Linguagem de implementação
• Armazenamento / Recuperação
• Interface com Usuário
• Tratamento de Erros
• Comunicação
• Nomenclatura de Pacotes, Classes, Métodos,
  Atributos

5
Mecanismos Fundamentais

• Mecanismos fundamentais são decisões que guiarão
  todo o projeto de um software OO.
• Envolve a padronização de etapas de projeto e
  implementação, seguindo um modelo comum
  compartilhado por todos os elementos da equipe.
• Exemplos
• partida e término do sistema
• armazenamento / recuperação de objetos
• tratamento de exceções
• nomenclatura de classes, métodos, atributos
• aparência da interface com o usuário
• distribuição

6
Partida e Término do Sistema

• Se estas situações não foram cobertas na análise,
  casos de uso devem ser definidos para especificar
  o comportamento do sistema na iniciação e
  finalização.
• Cenários devem ser desenvolvidos para cada caso
  de uso - suportando as situações normais e
  anormais.
• Durante este processo, novos estados e
  comportamentos podem ser descobertos para as
  classes existentes, podendo surgir a necessidade
  de criação de novas classes para realizar os
  cenários de partida e término do sistema.

7
Persistência

• Necessidade de utilizar objetos criados durante a
  execução de um programa em execução futuras do
  mesmo, ou ainda em outras aplicações
• Um objeto persistente é aquele que existe
  logicamente além do escopo do programa que o cria
• As linguagens de programação OO lidam apenas com
  objetos essencialmente transientes (residentes em
  memória).
• Armazenamento salvar um objeto em algum tipo de
  armazenamento persistente.
• Recuperação criar um objeto em memória a partir
  de uma fonte de armazenamento persistente.

8
Armazenamento - Alternativas

• Soluções baseadas em arquivos sequenciais
• Soluções baseadas em BD orientados a objetos
• Soluções baseadas em BD relacionais
• Soluções baseadas em outros BD.
• Hoje relacionais e BDOO são os mais comuns.

9
Banco de Dados OO

• Interface sem igual entre a aplicação OO eo banco
  de dados.
• Código relativamente pequeno é necessário para
  manter objetos persistentes.
• Muito práticos com sistemas que precisam tratar
  estrutura de dados complexas. (CAD, p.e.).
• Performace muito melhor para navegação em
  estruturas complexas.

10
Banco de Dados OO

• BD Relacionais dispõem de maior suporte de
  ferramentas para gerência e manipulação.
• Maior quantidade de mão - de - obra com
  experiência em bancos relacionais.
• Maturidade dos vendedores de bancos O.O.
  Existem mais fornecedores do que o mercado
  suporta.
• O investimento existente na tecnologia relacional
  deve ser considerado quando a tecnologia OO for
  avaliada.

11
Soluções baseadas em BD Relacional

• Forte necessidade de integração entre linguagens
  O.O. e Bancos Relacionais
• Grau de amadurecimento de soluções com BD
  Relacionais
• Popularidade de SQL e ferramentas baseadas em SQL
• Profissionais em experiência em BD relacionais
• Investimento já efetuados em BD relacionais

12
BD Relacional

• Os Bancos de Dados Relacionais constituem a forma
  de armazenamento mais utilizada e robusta
  atualmente.
• Entretanto, existe uma diferença semântica
  natural entre o modelo OO e o modelo baseado em
  tabelas de um BD relacional
• Um mecanismo de mapeamento entre os dois modelos
  é necessário.

13
Identidade de um Objeto

• A identidade de um objeto é um conceito
  fundamental no mapeamento OO Relacional
• Toda instância tem um ID(número com auto
  incremento, sem significado semântico)

14
Mapeamento Atributo X Coluna

• Um atributo de objeto 0 ou mais colunas no BD
  relacional
• 1 atributo 0 coluna alguns atributos podem ser
  transientes
• 1 atributo 1 coluna atributos sem estrutura
• Ex data, string
• 1 atributo N colunas atributos com estrutura.
• Ex endereço

15
Mapeamento OO - Relacional

• Normalmente, uma classe é mapeada para uma tabela
• Cada instância corresponde a uma linha
• Tabela Associado
• Id_associado Nome Endereço - Admissão

Associado ------------ Oid Nome Endereço Admissão
16
Mapeamento OO - Relacional

• Um relacionamento um-para-um é mapeado com uma
  chave estrangeira no banco de dados relacional. A
  chave deverá ser feita através dos Ids das
  tabelas.
• Tabela Associado
• Id_associado Nome Endereço Admissão
• Tabela Contrato
• Id_contrato NumContrato DataContrato
  Id_Associado

Associado ------------ Oid Nome Endereço Admissão
Contrato ---------- Oid NumContrato DataContrato
17
Mapeamento OO - Relacional

• Um relacionamento um-para-muitos é mapeado com
  uma chave estrangeira no banco de dados
  relacional. A chave deverá ser feita através dos
  Ids das tabelas.
• Tabela Associado
• Id_associado Nome Endereço Admissão
• Tabela Dependente
• Id_Dependente Nome DataNasc Id_Associado

Associado ------------ Oid Nome Endereço Admissão
Dependente ---------- Oid Nome DataNasc
1 0..
18
Mapeamento OO - Relacional

• Um relacionamento muitos-para-muitos é resolvido,
  criando tabelas adicionaisno banco de dados
  relacionais.
• Tabela de Atendimentos Hospitalares
• Id_associado id_Hospital

Associado ------------
1.. 1..
Hospital ----------
19
Mapeamento de Herança

• Partição Vertical
• 1 tabela por classe
• Partição Horizontal
• 1 tabela por classe folha (migração dos
  atributos para subclasses
• Tabela Única
• 1 tabela para toda linha de herança
  (migração dos atributos para a superclasse

20
Mapeamento de Herança
Equipamento ---------------- nome preco
Bomba ------------------- Pressaosuccao pressaodes
carga
Dissipador de Calor ------------------------ areas
uperficie
21
Partição Vertical
Equipamento equipamento_id nome preco tipo
DissipadorCalor equipamento_id areasuperficie
Bomba equipamento_id pressaosuccao pressaodescarga
22
Partição Horizontal
DissipadorCalor equipamento_id nome preco areasupe
rficie
Bomba equipamento_id nome preco pressaosuccao pres
saodescarga
23
Tabela Única
Equipamento equipamento_id nome preco pressaosucca
o Pressaodescarga Areasuperficie tipo
24
Mapeamento de Herança

• Partição Vertical
• evita redundância
• performance (join)
• Partição Horizontal
• redundância
• Tabela Única
• espaço perdido
• Compromissos entre performance, espaço em disco e
  facilidade de modificação são usados para decidir
  que mapeamento deve ser usado para situações de
  herança

25
Tratamento de Exceções

• Um padrão para detectar e tratar exceções deve
  ser elaborado para facilitar a adoção de uma
  abordagem consistente na implementação
• Os objetos devem detectar erros que iriam violar
  sua integridade. Isto inclui erros
• Que ocorrem dentro de suas operações
• Resultantes de parâmetros recebidos de
  objetos clientes
• Resultantes de valores de retorno
  enviados por objetos fornecedores

26
Tratamento de Exceções

• O tratamento de esceções deve ser cuidadosamente
  projetado mais de 30 do código final
  geralmente está associado a tratamento de
  condições de exceção
• Linguagens modernas OO oferecem facilidades de
  tratamento de exceção
• Estes mecanismos permitem que um erro seja
  tratado por um objeto diferente daquele que
  detectou o erro
• Isto geralmente é apropriado, uma vez que o
  impacto geral de um erro no sistema não é sempre
  conhecido pelo objeto detector

27
Tratamento de Exceções

• Uma exceção é geralmente uma condição de erro ou
  outro evento que interrompe o fluxo normal de
  execução de uma aplicação
• Quando uma exceção é gerada, o controle é
  transferido do ponto corrente de execução para
  uma parte do código que capturará a exceção
• Object Pascal tem uma maneira estruturada de
  separar a lógica normal do programa da lógica de
  tratamento de exceções.

28
Padronização de Mensagens

• As mensagens enviadas para o usuário durante a
  interação usuário-sistema deverão ser tratadas de
  foema padronizada
• Ambientes operacionais como o Windows, possuem
  caixas de diálogo específicas para tratar as
  mensagens usuais de interface com o usuário
• Deve-se criar uma classe global responsável pelas
  mensagens usuário-sistema que abstraia o sistema
  operacional utilizado.
• Eventuais mudanças no estilo de exibição de uma
  mensagem podem ser tratadas em apenas um lugar.

29
Aparência da Interface com o Usuário

• A interface do usuário deverá ser padronizada
  para facilitar a manipulação dos sistema da
  empresa
• A principal interface a ser padronizada é a
  interface de persistência de objetos ou interface
  cadastral

30
Padrões de Distribuição OO

• Escolher um padrão de distribuição é uma decisão
  de projeto se o seu sistema usa objetos
  distribuídos
• Existem 2 padrões emergentes para distribuição
  OO
• CORBA Common Object Request Broker
  Architecture
• DCOM Distributed Component Object
  Model

31
Projetos OO

• Projeto de Classes
• Projeto de Atributos e Operações
• Projeto de Herança Polimorfismo
• Projeto de Relacionamentos