View
107
Download
3
Category
Preview:
Citation preview
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 AssociadoId_associado – Nome – Endereço - Admissão
Associado------------OidNomeEndereçoAdmissã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 AssociadoId_associado – Nome – Endereço – Admissão
Tabela ContratoId_contrato – NumContrato – DataContrato – Id_Associado
Associado------------OidNomeEndereçoAdmissão
Contrato----------OidNumContratoDataContrato
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 AssociadoId_associado – Nome – Endereço – Admissão
Tabela DependenteId_Dependente – Nome – DataNasc – Id_Associado
Associado------------OidNomeEndereçoAdmissão
Dependente----------OidNomeDataNasc
1 0..*
18
Mapeamento OO - Relacional
Um relacionamento muitos-para-muitos é resolvido, criando tabelas adicionaisno banco de dados relacionais.
Tabela de Atendimentos HospitalaresId_associado – id_Hospital
Associado------------ Hospital
----------1..* 1..*
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----------------nomepreco
Bomba-------------------Pressaosuccaopressaodescarga
Dissipador de Calor------------------------areasuperficie
21
Partição Vertical
Equipamentoequipamento_idnomeprecotipo
Bombaequipamento_idpressaosuccaopressaodescarga
DissipadorCalorequipamento_idareasuperficie
22
Partição Horizontal
Bombaequipamento_idnomeprecopressaosuccaopressaodescarga
DissipadorCalorequipamento_idnomeprecoareasuperficie
23
Tabela Única
Equipamentoequipamento_idnomeprecopressaosuccaoPressaodescargaAreasuperficietipo
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
Recommended