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 pressaodescarga Dissipador de Calor ------------------------ areasuperficie

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 areasuperficie Bomba equipamento_id nome preco pressaosuccao pressaodescarga

23. Tabela Única Equipamento equipamento_id nome preco pressaosuccao 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