UNIVERSIDADE LUTERANA DO BRASIL   COMUNIDADE EVANGÉLICA LUTERANA “SÃO PAULO”Reconhecida pela Portaria Ministerial nº 681 d...
Sumários   Introduçãos   1 Históricos   2 Visão gerals   3 Análises   4 Construçãos   5 Testes   Conclusão                ...
Introduçãos   O desenvolvimento de software Orientado a    Objeto é a grande tendências   É necessário uma metodologia de ...
1 Históricos   1967: O Dr. Ivar Jacobson desenvolve a    abordagem da Arquitetura Cêntrica                                ...
1 Históricos   1987: com o aprimoramento desse processo    de desenvolvimento, Jacobson o nomeia    Objectory e acaba fund...
1 Históricos   1990: Jacobson expande o Objectory para    incluir a engenharia de negócios, para assim    melhor entender ...
1 Históricos   1995: A companhia de Jacobson, Objectory    AB, acaba se fundindo com a empresa    Rational Software Corpor...
2 Visão Gerals   Fases e Modelos  Fase            Entrada              Processos              SaídaAnálise    Especificaçã...
2 Visão Geral                                    Modelo de Casos                                       de Uso             ...
3 Análises   3.1 Análise de Requisitos / Modelo de    Requisitos    – 3.1.1 Modelo de Casos de Uso    – 3.1.2 Descrição de...
3 Análises   Especificar e definir o sistema que será    construídos   A base para esta modelagem são os    requisitos dos...
3 Análise                                AnáliseEspecificação    Análise dos                Análisedos Requisitos   Requis...
3.1 Análise dos Requisitos / Modelodos Requisitoss   Delimita o sistema e define quais as suas    funcionalidadess   É vis...
3.1.1 Modelo de Casos de Usos   Baseado em atores e casos de usos   Atores representam tudo o que interage com    o sistem...
3.1.1 Modelo de Casos de Uso          Sistema de Recebimento de Embalagens                    Receber                Impri...
3.1.2 Descrição de Interfaces doUsuários   Protótipos de interface facilitam a    comunicação com os usuárioss   Mostram o...
3.1.2 Descrição de Interfaces doUsuário                                   17
3.1.3 Modelo de Objetos do Domínios   Defini os conceitos com o a qual o sistema    deve trabalhars   Mostra instâncias de...
3.2 Análise Robusta / Modelo deAnálises   Processo mais voltado à estrutura lógica    interna do sistemas   Independe do a...
3.2.1 Os Três Tipos de Objetoss   Objeto Entidade    – informação do sistema que deve ser armazenada      por algum períod...
3.2.1 Os Três Tipos de Objetoss   Objeto de Interface    – através desses objetos que os atores se      comunicam com o si...
3.2.1 Os Três Tipos de Objetoss   Objeto de Controle    – Modela funcionalidades que não estão      naturalmente ligadas a...
3.2.2 Subsistemass   Agrupar os objetos em um ou mais níveiss   Para obter uma clara visão e entendimento    do modelos   ...
3.2.2 SubsistemasPacote Cliente            Pacote Alarme e Impressora      Receptor de Itens        Dispositivo de Alarme ...
4 Construçãos   4.1 Projeto / Modelo de Projeto    – 4.1.1 Diagrama de blocos    – 4.1.2 Diagrama de interações    – 4.1.3...
4 Construçãos   Existem três razões principais para o    processo de construção:    – O modelo de análise não é formal o s...
4 Construção                     Processo de Construção Modelo de Requisitos               Projeto                    Impl...
4.1 Projeto / Modelo de Projetos   Adaptação do sistema ao ambiente de    implementação que será utilizados   Refinar o mo...
4.1.1 Diagrama de Blocoss   Um bloco é um objeto de projetos   Diferentes tipos de blocos podem ser usadoss   Inicialmente...
4.1.2 Diagrama de Interaçãos   Descrever como cada caso de uso é    manipulado pela interação dos objetoss   Interação é o...
4.1.2 Diagrama de InteraçãoBorda do             Painel do             Receptor                Base de                Item ...
obter                                    nome4.1.2 Diagrama de Interação       obter valor   recibo            Imprimir   ...
4.1.3 Modelo de Interface de Blocoss   Apresenta toda a funcionalidade que cada    bloco deve oferecers   Um retrato compl...
4.2 Implementação / Modelo deImplementaçãos   É feita a codificação do sistemas   A base para a implementação é o modelo d...
5 Testes   5 Teste    –   5.1 Teste de unidade    –   5.2 Teste de integração    –   5.3 Teste do sistema    –   5.4 Model...
5 Testes   Verifica se o sistema que está sendo    construído está corretos   Os testes também são guiados pelos casos    ...
5 Teste                           Processo de Teste Modelo de Requisitos                Teste de           Teste de       ...
5.1 Teste de Unidades   Examinar o sistema a partir de suas menores    partess   Essas partes são operações de uma classe,...
5.2 Teste de Integraçãos   Reunir todas as classes envolvidas num    determinado caso de uso, testadas no teste    de unid...
5.3 Teste do Sistemas   Os casos de uso são testados em conjuntos   Verifica se casos de uso que se relacionam    estão de...
5.4 Modelo de Testes   Resultado documentado dos testess   Relata todo o teste: parte que estava sendo    testada, tipo de...
Conclusãos   Realmente favorece a produção de um    sistema com as caraterísticas da orientação a    objetos   Centrada no...
Ícones                                       Voltar  s   Cliente ou Usuário Final      – Pessoa que irá interagir com o si...
Ícones                                       Voltar  s   Banco de Dados      – Banco de dados relacional ou de outro tipo ...
Ícones                                       Voltar  s   Classes e Objetos      – Arquitetura baseada em componentes      ...
Empresas                                            Voltars   Rational > www.rational.com.br    – UML > www.rational.com/w...
Próximos SlideShares
Carregando em…5
×

Objectory

557 visualizações

Publicada em

Baixe mais arquivos em http://pastadomau.wikidot.com.
Trabalho sobre a metodologia de desenvolvimento de software de Ivar Jacobson chamada Objectory. Claro, isso foi antes dele juntar-se a Grady Booch e Jim Rumbaugh para desenvolver a UML e o RUP.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
557
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Objectory

  1. 1. UNIVERSIDADE LUTERANA DO BRASIL 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. 2. Sumários Introduçãos 1 Históricos 2 Visão gerals 3 Análises 4 Construçãos 5 Testes Conclusão 2
  3. 3. Introduçãos O desenvolvimento de software Orientado a Objeto é a grande tendências É necessário uma metodologia de desenvolvimento que apoie a orientação a objetos Uma das metodologias orientadas a objeto existentes: Objectory 3
  4. 4. 1 Históricos 1967: O Dr. Ivar Jacobson desenvolve a abordagem da Arquitetura Cêntrica 4
  5. 5. 1 Históricos 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. 6. 1 Históricos 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 requisitoss 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. 7. 1 Históricos 1995: A companhia de Jacobson, Objectory AB, acaba se fundindo com a empresa Rational Software Corporations Junto Grady Booch e Jim Rumbaugh, ele desenvolveu UML 7
  8. 8. 2 Visão Gerals Fases e Modelos Fase Entrada Processos SaídaAnálise Especificação de Análise de Modelo de Requisitos Requisitos Requisitos Modelo de Análise Análise RigorosaConstrução Modelo de Requisitos Projeto Modelo de Projeto Modelo de Análise Implementação Modelo de ImplementaçãoTeste 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. 9. 2 Visão Geral Modelo de Casos de Uso Expressado Realizado por Testado em por Estruturado Implementado por porModelo de Modelo de Modelo de Modelo de Modelo deRequisitos Análise Projeto Implementação Teste 9
  10. 10. 3 Análises 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 Objetoss 3.2 Análise Robusta / Modelo de Análise – 3.2.1 Os Três Tipos de Objetos – 3.2.2 Subsistemas 10
  11. 11. 3 Análises Especificar e definir o sistema que será construídos A base para esta modelagem são os requisitos dos clientes ou usuários finaiss Orientados para a aplicação e não para o ambiente de implementação 11
  12. 12. 3 Análise AnáliseEspecificação Análise dos Análisedos Requisitos Requisitos Rigorosa Modelo dos Modelo de Requisitos Análise 12
  13. 13. 3.1 Análise dos Requisitos / Modelodos Requisitoss Delimita o sistema e define quais as suas funcionalidadess É visão do desenvolvedor do que o cliente quers É essencial que este modelo seja legível por pessoas leigas 13
  14. 14. 3.1.1 Modelo de Casos de Usos Baseado em atores e casos de usos Atores representam tudo o que interage com o sistemas Cada caso de uso é uma maneira específica de utilizar o sistemas Os casos de uso são realizados por atores no sistema 14
  15. 15. 3.1.1 Modelo de Casos de Uso Sistema de Recebimento de Embalagens Receber Imprimir Embalagens RelatórioCliente Recolher Embalagens Operador Depositadas 15
  16. 16. 3.1.2 Descrição de Interfaces doUsuários Protótipos de interface facilitam a comunicação com os usuárioss Mostram o que os usuários verão quando estiverem executando o caso de usos Reduz a possibilidade de um desentendimento entre o que o usuário quer e o que o analista projeta 16
  17. 17. 3.1.2 Descrição de Interfaces doUsuário 17
  18. 18. 3.1.3 Modelo de Objetos do Domínios Defini os conceitos com o a qual o sistema deve trabalhars Mostra instâncias de objetos, classes e associações Cliente Venda 18
  19. 19. 3.2 Análise Robusta / Modelo deAnálises Processo mais voltado à estrutura lógica interna do sistemas Independe do ambiente de implementaçãos Distribui os comportamentos dos casos de uso entre os objetos no modelos O modelo de análise representa a mais estável e manutenível estrutura do sistema 19
  20. 20. 3.2.1 Os Três Tipos de Objetoss 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. 21. 3.2.1 Os Três Tipos de Objetoss 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. 22. 3.2.1 Os Três Tipos de Objetoss 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. 23. 3.2.2 Subsistemass Agrupar os objetos em um ou mais níveiss Para obter uma clara visão e entendimento do modelos Reduzir a complexidade, organizando o desenvolvimento e manutenção da estruturas A divisão em subsistemas deve ser baseada na funcionalidade do sistema e no forte acoplamento entre objetos 23
  24. 24. 3.2.2 SubsistemasPacote Cliente Pacote Alarme e Impressora Receptor de Itens Dispositivo de Alarme Painel do Cliente Impressora 24
  25. 25. 4 Construçãos 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 blocoss 4.2 Implementação / Modelo de Implementação 25
  26. 26. 4 Construçãos 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. 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. 28. 4.1 Projeto / Modelo de Projetos Adaptação do sistema ao ambiente de implementação que será utilizados Refinar o modelo de análise o suficiente para que ele facilite a escrita do código fontes Mudanças ocorrem devido a um banco de dados relacional, um ambiente distribuído, requisitos de desempenho ou processos concorrentes 28
  29. 29. 4.1.1 Diagrama de Blocoss Um bloco é um objeto de projetos Diferentes tipos de blocos podem ser usadoss Inicialmente, cada objeto da análise é simplesmente transformado em um bloco Cliente Venda 29
  30. 30. 4.1.2 Diagrama de Interaçãos Descrever como cada caso de uso é manipulado pela interação dos objetoss Interação é o envio ou recebimento de um estímulo de um bloco para outros Diferentes objetos colaboram para a resolução de um caso de uso 30
  31. 31. 4.1.2 Diagrama de InteraçãoBorda do Painel do Receptor Base de Item de ImpressoraSistema Cliente de Itens Recibos Depósito iniciar criar ativar novo item Item( ) existe( ) inserir( item) incr obter nome obter valor 31 recibo
  32. 32. obter nome4.1.2 Diagrama de Interação obter valor recibo Imprimir Imprimir( logo, data) recibo imprimir Imprimir( nome, qtd, valor) destruir 32
  33. 33. 4.1.3 Modelo de Interface de Blocoss Apresenta toda a funcionalidade que cada bloco deve oferecers Um retrato completo de cada blocos Extrair as todas as operações que são requisitadass Examinar todos os diagramas de interação 33
  34. 34. 4.2 Implementação / Modelo deImplementaçãos É feita a codificação do sistemas A base para a implementação é o modelo de projetos O modelo de implementação consiste do código fonte acompanhado de seus comentárioss Transformação de cada bloco do modelo de projeto em uma ou mais unidades de código fonte 34
  35. 35. 5 Testes 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. 36. 5 Testes Verifica se o sistema que está sendo construído está corretos Os testes também são guiados pelos casos de usos Uma abordagem bem organizada e disciplinada é necessária para aumentar a qualidade do sistema 36
  37. 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 deImplementação Teste 37
  38. 38. 5.1 Teste de Unidades Examinar o sistema a partir de suas menores partess Essas partes são operações de uma classe, e as próprias classess A base para estes dois testes é o modelo de projeto, em especial o modelo de interface de blocos 38
  39. 39. 5.2 Teste de Integraçãos Reunir todas as classes envolvidas num determinado caso de uso, testadas no teste de unidades Verificar se os objetos envolvidos estão se comunicando e colaborando corretamente para a resolução do caso de usos Este teste é guiado pelo caso de uso que se está testando no momento 39
  40. 40. 5.3 Teste do Sistemas Os casos de uso são testados em conjuntos Verifica se casos de uso que se relacionam estão de acordos É o teste final do sistema = 40
  41. 41. 5.4 Modelo de Testes Resultado documentado dos testess 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. 42. Conclusãos Realmente favorece a produção de um sistema com as caraterísticas da orientação a objetos Centrada nos casos de uso em todas as fases, tende a garantir um sistema consiste e coerentes Esta metodologia favorece o desenvolvimento em equipe, pois permite que as fases ocorram em paralelo 42
  43. 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. 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. 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. 46. Empresas Voltars Rational > www.rational.com.br – UML > www.rational.com/worldwide/brazil/port_uml.jsp – Jacobson > www.rational.com/media/news/presskit /amigos_bios.pdfs Ericsson > www.ericsson.coms SDL > www.sdl.com 46

×