Projeto de Sistemas OO

Projeto de Sistema Orientado a
Objeto
Arquitetura

Várias definições existentes

Conjunto de artefatos utilizados para especificar:



2
decisões estratégicas sobre a estrutura
comportamento do sistema
as colaborações entre os elementos do sistema
elementos físicos do sistema
e
o
Importância da Arquitetura





3
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
Mecanismos Fundamentais






4
Linguagem de implementação
Armazenamento / Recuperação
Interface com Usuário
Tratamento de Erros
Comunicação
Nomenclatura de Pacotes, Classes, Métodos,
Atributos
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:






5
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
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
6 cenários de partida e término do sistema.

Persistência





7
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.
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.



8
Banco de Dados OO




9
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.
Banco de Dados OO




10
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.
Soluções baseadas em BD Relacional

Forte necessidade de integração entre linguagens
O.O. e Bancos Relacionais:




11
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
BD Relacional



12
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.
Identidade de um Objeto
13

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)
Mapeamento Atributo X Coluna




14
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
Mapeamento OO - Relacional


Normalmente, uma classe é mapeada para uma tabela
Cada instância corresponde a uma linha
Associado
-----------Oid
Nome
Endereço
Admissão
Tabela Associado
Id_associado – Nome – Endereço - Admissão
15
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.
Associado
-----------Oid
Nome
Endereço
Admissão
Contrato
---------Oid
NumContrato
DataContrato
Tabela Associado
Id_associado – Nome – Endereço – Admissão
Tabela Contrato
Id_contrato – NumContrato – DataContrato – Id_Associado
16
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.
Associado
-----------Oid
Nome
Endereço
Admissão
1
0..*
Dependente
---------Oid
Nome
DataNasc
Tabela Associado
Id_associado – Nome – Endereço – Admissão
Tabela Dependente
Id_Dependente – Nome – DataNasc – Id_Associado
17
Mapeamento OO - Relacional

Um relacionamento muitos-para-muitos é resolvido,
criando tabelas adicionaisno banco de dados
relacionais.
Associado
------------
1..*
1..*
Hospital
----------
Tabela de Atendimentos Hospitalares
Id_associado – id_Hospital
18
Mapeamento de Herança
19

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
Mapeamento de Herança
Equipamento
---------------nome
preco
Bomba
------------------Pressaosuccao
pressaodescarga
20
Dissipador de Calor
-----------------------areasuperficie
Partição Vertical
Equipamento
equipamento_id
nome
preco
tipo
Bomba
equipamento_id
pressaosuccao
pressaodescarga
21
DissipadorCalor
equipamento_id
areasuperficie
Partição Horizontal
Bomba
equipamento_id
nome
preco
pressaosuccao
pressaodescarga
22
DissipadorCalor
equipamento_id
nome
preco
areasuperficie
Tabela Única
Equipamento
equipamento_id
nome
preco
pressaosuccao
Pressaodescarga
Areasuperficie
tipo
23
Mapeamento de Herança

Partição Vertical
evita redundância
performance (join)

Partição Horizontal
redundância

Tabela Única
espaço perdido

24
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
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
25
Tratamento de Exceções




26
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
Tratamento de Exceções



27
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.
Padronização de Mensagens




28
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.
Aparência da Interface com o Usuário
29

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
Padrões de Distribuição OO
30

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
Projetos OO
31

Projeto de Classes

Projeto de Atributos e Operações

Projeto de Herança – Polimorfismo

Projeto de Relacionamentos