Projeto de Sistema Orientado a Objeto

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

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

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

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

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.

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.

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.

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.

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.

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

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.

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)

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

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

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

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..*

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 ----------

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

Mapeamento de Herança Equipamento ---------------- nome preco Bomba ------------------- Pressaosuccao pressaodescarga Dissipador de Calor ------------------------ areasuperficie

Partição Vertical Equipamento DissipadorCalor Bomba equipamento_id nome preco tipo DissipadorCalor equipamento_id areasuperficie Bomba equipamento_id pressaosuccao pressaodescarga

Partição Horizontal DissipadorCalor Bomba equipamento_id nome preco areasuperficie Bomba equipamento_id nome preco pressaosuccao pressaodescarga

Tabela Única Equipamento equipamento_id nome preco pressaosuccao Pressaodescarga Areasuperficie tipo

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

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

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

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.

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.

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

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

Projetos OO Projeto de Classes Projeto de Atributos e Operações Projeto de Herança – Polimorfismo Projeto de Relacionamentos