projeto de sistema orientado a objeto. 2 arquitetura várias definições existentes conjunto de...

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