Transferir como PDF, PPTX
Carregado porMauricio Volkweis Astiazara
Objectory
s O documento descreve a metodologia Objectory para desenvolvimento de software orientado a objetos. s A metodologia inclui fases de análise, construção e teste. s Na fase de análise, os requisitos são modelados em casos de uso, interfaces e domínio de objetos. Objetos são categorizados e agrupados em subsistemas.
Mais conteúdo relacionado
Objectory
- 1. UNIVERSIDADE LUTERANA DOBRASIL COMUNIDADE EVANGÉLICA LUTERANA “SÃO PAULO” Reconhecida pela Portaria Ministerial nº 681 de 07/12/89 – DOU de 11/12/89 Campus Torres Objectory Engenharia de Software II Aluno: Mauricio Volkweis Astiazara Aluno: Marcelo Waihrich Souza Professor: Adriana Roma Torres, Outubro de 2001 1
- 2. Sumário s Introdução s 1 Histórico s 2 Visão geral s 3 Análise s 4 Construção s 5 Teste s Conclusão 2
- 3. Introdução s O desenvolvimento de software Orientado a Objeto é a grande tendência s É necessário uma metodologia de desenvolvimento que apoie a orientação a objeto s Uma das metodologias orientadas a objeto existentes: Objectory 3
- 4. 1 Histórico s 1967: O Dr. Ivar Jacobson desenvolve a abordagem da Arquitetura Cêntrica 4
- 5. 1 Histórico s 1987: com o aprimoramento desse processo de desenvolvimento, Jacobson o nomeia Objectory e acaba fundando a sua própria empresa: a Objectory AB, na Suécia 5
- 6. 1 Histórico s 1990: Jacobson expande o Objectory para incluir a engenharia de negócios, para assim melhor entender o contexto do negócio e melhor capturar os seus requisitos s 1992: o metodologista lança o OOSE, Object- oriented Software Engeneering - Engenharia de Software Orientada a Objeto, que nada mais é que uma versão simplificada do método Objectory 6
- 7. 1 Histórico s 1995: A companhia de Jacobson, Objectory AB, acaba se fundindo com a empresa Rational Software Corporation s Junto Grady Booch e Jim Rumbaugh, ele desenvolveu UML 7
- 8. 2 Visão Geral s Fases e Modelos Fase Entrada Processos Saída Análise Especificação de Análise de Modelo de Requisitos Requisitos Requisitos Modelo de Análise Análise Rigorosa Construção Modelo de Requisitos Projeto Modelo de Projeto Modelo de Análise Implementação Modelo de Implementação Teste Modelo de Requisitos Teste de Unidade Modelo de Teste Modelo de Projeto Teste de Integração Modelo de Teste do Sistema Implementação 8
- 9. 2 Visão Geral Modelo de Casos de Uso Expressado Realizado por Testado em por Estruturado Implementado por por Modelo de Modelo de Modelo de Modelo de Modelo de Requisitos Análise Projeto Implementação Teste 9
- 10. 3 Análise s 3.1 Análise de Requisitos / Modelo de Requisitos – 3.1.1 Modelo de Casos de Uso – 3.1.2 Descrição de Interfaces do Usuário – 3.1.3 Modelo de Domínio de Objetos s 3.2 Análise Robusta / Modelo de Análise – 3.2.1 Os Três Tipos de Objetos – 3.2.2 Subsistemas 10
- 11. 3 Análise s Especificar e definir o sistema que será construído s A base para esta modelagem são os requisitos dos clientes ou usuários finais s Orientados para a aplicação e não para o ambiente de implementação 11
- 12. 3 Análise Análise Especificação Análise dos Análise dos Requisitos Requisitos Rigorosa Modelo dos Modelo de Requisitos Análise 12
- 13. 3.1 Análise dosRequisitos / Modelo dos Requisitos s Delimita o sistema e define quais as suas funcionalidades s É visão do desenvolvedor do que o cliente quer s É essencial que este modelo seja legível por pessoas leigas 13
- 14. 3.1.1 Modelo deCasos de Uso s Baseado em atores e casos de uso s Atores representam tudo o que interage com o sistema s Cada caso de uso é uma maneira específica de utilizar o sistema s Os casos de uso são realizados por atores no sistema 14
- 15. 3.1.1 Modelo deCasos de Uso Sistema de Recebimento de Embalagens Receber Imprimir Embalagens Relatório Cliente Recolher Embalagens Operador Depositadas 15
- 16. 3.1.2 Descrição deInterfaces do Usuário s Protótipos de interface facilitam a comunicação com os usuários s Mostram o que os usuários verão quando estiverem executando o caso de uso s Reduz a possibilidade de um desentendimento entre o que o usuário quer e o que o analista projeta 16
- 17. 3.1.2 Descrição deInterfaces do Usuário 17
- 18. 3.1.3 Modelo deObjetos do Domínio s Defini os conceitos com o a qual o sistema deve trabalhar s Mostra instâncias de objetos, classes e associações Cliente Venda 18
- 19. 3.2 Análise Robusta/ Modelo de Análise s Processo mais voltado à estrutura lógica interna do sistema s Independe do ambiente de implementação s Distribui os comportamentos dos casos de uso entre os objetos no modelo s O modelo de análise representa a mais estável e manutenível estrutura do sistema 19
- 20. 3.2.1 Os TrêsTipos de Objetos s Objeto Entidade – informação do sistema que deve ser armazenada por algum período de tempo – sobrevive depois que o caso de uso é terminado – estão presentes no modelo de objetos do domínio Objeto Entidade 20
- 21. 3.2.1 Os TrêsTipos de Objetos s Objeto de Interface – através desses objetos que os atores se comunicam com o sistema – descreve a comunicação bidirecional entre o sistema e seus usuários, estes podem ser humanos ou outros sistemas Objeto de Interface 21
- 22. 3.2.1 Os TrêsTipos de Objetos s Objeto de Controle – Modela funcionalidades que não estão naturalmente ligadas aos outros tipos de objetos – consiste em operar diferentes objetos entidade, realizar algum processo e retornar o resultado para um objeto de interface 22 Objeto de Controle
- 23. 3.2.2 Subsistemas s Agrupar os objetos em um ou mais níveis s Para obter uma clara visão e entendimento do modelo s Reduzir a complexidade, organizando o desenvolvimento e manutenção da estrutura s A divisão em subsistemas deve ser baseada na funcionalidade do sistema e no forte acoplamento entre objetos 23
- 24. 3.2.2 Subsistemas Pacote Cliente Pacote Alarme e Impressora Receptor de Itens Dispositivo de Alarme Painel do Cliente Impressora 24
- 25. 4 Construção s 4.1 Projeto / Modelo de Projeto – 4.1.1 Diagrama de blocos – 4.1.2 Diagrama de interações – 4.1.3 Modelo de interface de blocos s 4.2 Implementação / Modelo de Implementação 25
- 26. 4 Construção s Existem três razões principais para o processo de construção: – O modelo de análise não é formal o suficiente. devemos refinar os objetos – Deve ser feita uma adaptação para o atual ambiente de implementação – Fazer a validação interna do resultado da análise 26
- 27. 4 Construção Processo de Construção Modelo de Requisitos Projeto Implementação Modelo de Análise Modelo de Modelo de Projeto Implementação 27
- 28. 4.1 Projeto /Modelo de Projeto s Adaptação do sistema ao ambiente de implementação que será utilizado s Refinar o modelo de análise o suficiente para que ele facilite a escrita do código fonte s Mudanças ocorrem devido a um banco de dados relacional, um ambiente distribuído, requisitos de desempenho ou processos concorrentes 28
- 29. 4.1.1 Diagrama deBlocos s Um bloco é um objeto de projeto s Diferentes tipos de blocos podem ser usados s Inicialmente, cada objeto da análise é simplesmente transformado em um bloco Cliente Venda 29
- 30. 4.1.2 Diagrama deInteração s Descrever como cada caso de uso é manipulado pela interação dos objetos s Interação é o envio ou recebimento de um estímulo de um bloco para outro s Diferentes objetos colaboram para a resolução de um caso de uso 30
- 31. 4.1.2 Diagrama deInteração Borda do Painel do Receptor Base de Item de Impressora Sistema Cliente de Itens Recibos Depósito iniciar criar ativar novo item Item( ) existe( ) inserir( item) incr obter nome obter valor 31 recibo
- 32. obter nome 4.1.2 Diagrama de Interação obter valor recibo Imprimir Imprimir( logo, data) recibo imprimir Imprimir( nome, qtd, valor) destruir 32
- 33. 4.1.3 Modelo deInterface de Blocos s Apresenta toda a funcionalidade que cada bloco deve oferecer s Um retrato completo de cada bloco s Extrair as todas as operações que são requisitadas s Examinar todos os diagramas de interação 33
- 34. 4.2 Implementação /Modelo de Implementação s É feita a codificação do sistema s A base para a implementação é o modelo de projeto s O modelo de implementação consiste do código fonte acompanhado de seus comentários s Transformação de cada bloco do modelo de projeto em uma ou mais unidades de código fonte 34
- 35. 5 Teste s 5 Teste – 5.1 Teste de unidade – 5.2 Teste de integração – 5.3 Teste do sistema – 5.4 Modelo de Teste 35
- 36. 5 Teste s Verifica se o sistema que está sendo construído está correto s Os testes também são guiados pelos casos de uso s Uma abordagem bem organizada e disciplinada é necessária para aumentar a qualidade do sistema 36
- 37. 5 Teste Processo de Teste Modelo de Requisitos Teste de Teste de Teste do Unidade Integração Sistema Modelo de Projeto Modelo de Modelo de Implementação Teste 37
- 38. 5.1 Teste deUnidade s Examinar o sistema a partir de suas menores partes s Essas partes são operações de uma classe, e as próprias classes s A base para estes dois testes é o modelo de projeto, em especial o modelo de interface de blocos 38
- 39. 5.2 Teste deIntegração s Reunir todas as classes envolvidas num determinado caso de uso, testadas no teste de unidade s Verificar se os objetos envolvidos estão se comunicando e colaborando corretamente para a resolução do caso de uso s Este teste é guiado pelo caso de uso que se está testando no momento 39
- 40. 5.3 Teste doSistema s Os casos de uso são testados em conjunto s Verifica se casos de uso que se relacionam estão de acordo s É o teste final do sistema = 40
- 41. 5.4 Modelo deTeste s Resultado documentado dos testes s Relata todo o teste: parte que estava sendo testada, tipo de teste realizado, dados usados, resultado obtido e avaliação (falho ou ok) s Importante quando o sistema está sendo desenvolvido em equipe 41
- 42. Conclusão s Realmente favorece a produção de um sistema com as caraterísticas da orientação a objeto s Centrada nos casos de uso em todas as fases, tende a garantir um sistema consiste e coerente s Esta metodologia favorece o desenvolvimento em equipe, pois permite que as fases ocorram em paralelo 42
- 43. Ícones Voltar s Cliente ou Usuário Final – Pessoa que irá interagir com o sistema que está sendo desenvolvido s Desenvolvedor – Pessoa da equipe de desenvolvimento – Pode ser Analista, Projetista, Programador ou Gerente de Projeto s Sistema – Sistema operacional – Ou Sistema que está sendo desenvolvido 43
- 44. Ícones Voltar s Banco de Dados – Banco de dados relacional ou de outro tipo – Ou arquivo para armazenamento de dados s Ferramenta de Desenvolvimento – Linguagem de programação – Ferramenta case s Arquivo de Código Fonte – Código do sistema – Código de partes do sistema (classes, etc.) 44
- 45. Ícones Voltar s Classes e Objetos – Arquitetura baseada em componentes – Possui reusabilidade e extensibilidade s Requisitos de Desempenho – Tempo máximo para realizar uma tarefa – Capacidade de armazenamento e manipulação de dados s Modelo de Teste – Relatório sobre determinado teste – Descrição e resultado dos testes 45
- 46. Empresas Voltar s Rational > www.rational.com.br – UML > www.rational.com/worldwide/brazil/port_uml.jsp – Jacobson > www.rational.com/media/news/presskit /amigos_bios.pdf s Ericsson > www.ericsson.com s SDL > www.sdl.com 46