SlideShare ist ein Scribd-Unternehmen logo
1 von 46
Downloaden Sie, um offline zu lesen
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
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
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
1 Histórico

s   1967: O Dr. Ivar Jacobson desenvolve a
    abordagem da Arquitetura Cêntrica




                                             4
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
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
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
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
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
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
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
3 Análise

                                Análise


Especificação    Análise dos                Análise
dos Requisitos   Requisitos                 Rigorosa




                               Modelo dos              Modelo de
                               Requisitos               Análise




                                                                   12
3.1 Análise dos Requisitos / 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
3.1.1 Modelo de Casos 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
3.1.1 Modelo de Casos de Uso

          Sistema de Recebimento de Embalagens




                    Receber                Imprimir
                   Embalagens              Relatório
Cliente




                                   Recolher Embalagens   Operador
                                   Depositadas




                                                                15
3.1.2 Descrição de Interfaces 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
3.1.2 Descrição de Interfaces do
Usuário




                                   17
3.1.3 Modelo de Objetos 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
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
3.2.1 Os Três Tipos 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
3.2.1 Os Três Tipos 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
3.2.1 Os Três Tipos 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
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
3.2.2 Subsistemas

Pacote Cliente            Pacote Alarme e Impressora




      Receptor de Itens        Dispositivo de Alarme




      Painel do Cliente              Impressora


                                                       24
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
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
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
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
4.1.1 Diagrama de Blocos

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
4.1.2 Diagrama de Interaçã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
4.1.2 Diagrama de Interaçã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
obter
                                    nome

4.1.2 Diagrama de Interação       obter valor




   recibo
            Imprimir              Imprimir( logo, data)
             recibo

                       imprimir
                                    Imprimir( nome, qtd, valor)



                       destruir




                                                                  32
4.1.3 Modelo de Interface 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
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
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
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
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
5.1 Teste de Unidade

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
5.2 Teste de Integraçã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
5.3 Teste do Sistema

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
5.4 Modelo de Teste

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

Weitere ähnliche Inhalte

Was ist angesagt?

Geracao Automatica Assistida Iu Marcelo Mrack
Geracao Automatica Assistida Iu Marcelo MrackGeracao Automatica Assistida Iu Marcelo Mrack
Geracao Automatica Assistida Iu Marcelo MrackMarcelo Mrack
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geralsergiocrespo
 
Análise Orientada a Objetos com UML
Análise Orientada a Objetos com UMLAnálise Orientada a Objetos com UML
Análise Orientada a Objetos com UMLEliseu Castelo
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Softwareeros.viggiano
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de SistemasGuilherme
 
Arquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialArquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialAlexandre Leão
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Javaarmeniocardoso
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de SoftwareAricelio Souza
 
Uml Diagramas Estruturais
Uml   Diagramas EstruturaisUml   Diagramas Estruturais
Uml Diagramas Estruturaisthaisedd
 
Modelação Conceptual de Classes
Modelação Conceptual de ClassesModelação Conceptual de Classes
Modelação Conceptual de Classeselliando dias
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwarePeter Jandl Junior
 

Was ist angesagt? (20)

Geracao Automatica Assistida Iu Marcelo Mrack
Geracao Automatica Assistida Iu Marcelo MrackGeracao Automatica Assistida Iu Marcelo Mrack
Geracao Automatica Assistida Iu Marcelo Mrack
 
Arquitetura de Software Visão Geral
Arquitetura de Software Visão GeralArquitetura de Software Visão Geral
Arquitetura de Software Visão Geral
 
Análise Orientada a Objetos com UML
Análise Orientada a Objetos com UMLAnálise Orientada a Objetos com UML
Análise Orientada a Objetos com UML
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Apostila uml
Apostila umlApostila uml
Apostila uml
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Arquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADAArquitetura de Software EXPLICADA
Arquitetura de Software EXPLICADA
 
UML
UMLUML
UML
 
Apresentação da UML
Apresentação da UMLApresentação da UML
Apresentação da UML
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
 
Arquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialArquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencial
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Java
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Eng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. RequisitosEng.ª do Software - 2. Requisitos
Eng.ª do Software - 2. Requisitos
 
Uml Diagramas Estruturais
Uml   Diagramas EstruturaisUml   Diagramas Estruturais
Uml Diagramas Estruturais
 
Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
Modelação Conceptual de Classes
Modelação Conceptual de ClassesModelação Conceptual de Classes
Modelação Conceptual de Classes
 
Introdução à UML com Casos de Uso
Introdução à UML com Casos de UsoIntrodução à UML com Casos de Uso
Introdução à UML com Casos de Uso
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de Software
 

Ähnlich wie Objectory

Ähnlich wie Objectory (20)

Saam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halanSaam & arquiteturas_iu_halan
Saam & arquiteturas_iu_halan
 
Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Padrões de projeto
Padrões de projetoPadrões de projeto
Padrões de projeto
 
Objectory
ObjectoryObjectory
Objectory
 
Padrões de Projeto de Software
Padrões de Projeto de SoftwarePadrões de Projeto de Software
Padrões de Projeto de Software
 
57931578-TI-Analise-de-sistemas-Concursos.pdf
57931578-TI-Analise-de-sistemas-Concursos.pdf57931578-TI-Analise-de-sistemas-Concursos.pdf
57931578-TI-Analise-de-sistemas-Concursos.pdf
 
342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf
 
Unified Modeling Language
Unified Modeling LanguageUnified Modeling Language
Unified Modeling Language
 
Processo Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de SoftwareProcesso Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de Software
 
UML (1).ppt
UML (1).pptUML (1).ppt
UML (1).ppt
 
Apostila apsoo
Apostila apsooApostila apsoo
Apostila apsoo
 
Apresentação dissertação
Apresentação dissertaçãoApresentação dissertação
Apresentação dissertação
 
Caso De Uso E Use Case Point
Caso De Uso E Use Case PointCaso De Uso E Use Case Point
Caso De Uso E Use Case Point
 
Apostila uml
Apostila umlApostila uml
Apostila uml
 
Projeto de Software
Projeto de SoftwareProjeto de Software
Projeto de Software
 
Padrões de projetos
Padrões de projetosPadrões de projetos
Padrões de projetos
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
DCI com PHP
DCI com PHPDCI com PHP
DCI com PHP
 
Aula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de ProjetoAula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de Projeto
 

Mehr von Mauricio Volkweis Astiazara

Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Mauricio Volkweis Astiazara
 
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Mauricio Volkweis Astiazara
 
Comparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-LearningComparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-LearningMauricio Volkweis Astiazara
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeMauricio Volkweis Astiazara
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeMauricio Volkweis Astiazara
 

Mehr von Mauricio Volkweis Astiazara (20)

Como Programar Melhor em Java
Como Programar Melhor em JavaComo Programar Melhor em Java
Como Programar Melhor em Java
 
Sistemas Imunológicos Artificiais
Sistemas Imunológicos ArtificiaisSistemas Imunológicos Artificiais
Sistemas Imunológicos Artificiais
 
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
 
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
Sistema Imunológico Artificial para Predição de Fraudes e Furtos de Energia E...
 
Comparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-LearningComparação de Algoritmos Baseados em Q-Learning
Comparação de Algoritmos Baseados em Q-Learning
 
Classificador de Documentos Naïve Bayes
Classificador de Documentos Naïve BayesClassificador de Documentos Naïve Bayes
Classificador de Documentos Naïve Bayes
 
Visão Computacional
Visão ComputacionalVisão Computacional
Visão Computacional
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre Saúde
 
Sistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre SaúdeSistema de Recomendação de Páginas sobre Saúde
Sistema de Recomendação de Páginas sobre Saúde
 
Processamento de Imagens
Processamento de ImagensProcessamento de Imagens
Processamento de Imagens
 
Percepção, Movimento e Ação
Percepção, Movimento e AçãoPercepção, Movimento e Ação
Percepção, Movimento e Ação
 
Memória e Aprendizagem
Memória e AprendizagemMemória e Aprendizagem
Memória e Aprendizagem
 
Gerência de Requisitos
Gerência de RequisitosGerência de Requisitos
Gerência de Requisitos
 
Testes de Sistema
Testes de SistemaTestes de Sistema
Testes de Sistema
 
Telefonia Móvel
Telefonia MóvelTelefonia Móvel
Telefonia Móvel
 
Telefonia Móvel
Telefonia MóvelTelefonia Móvel
Telefonia Móvel
 
Realidade Virtual
Realidade VirtualRealidade Virtual
Realidade Virtual
 
Protótipo de Simulador de Elevadores
Protótipo de Simulador de ElevadoresProtótipo de Simulador de Elevadores
Protótipo de Simulador de Elevadores
 
Protótipo de Simulador de Elevadores
Protótipo de Simulador de ElevadoresProtótipo de Simulador de Elevadores
Protótipo de Simulador de Elevadores
 
Planejamento de Informática
Planejamento de InformáticaPlanejamento de Informática
Planejamento de Informática
 

Objectory

  • 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. 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 dos Requisitos / 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 de Casos 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 de Casos de Uso Sistema de Recebimento de Embalagens Receber Imprimir Embalagens Relatório Cliente Recolher Embalagens Operador Depositadas 15
  • 16. 3.1.2 Descrição de Interfaces 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 de Interfaces do Usuário 17
  • 18. 3.1.3 Modelo de Objetos 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ês Tipos 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ês Tipos 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ês Tipos 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 de Blocos 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 de Interaçã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 de Interaçã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 de Interface 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 de Unidade 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 de Integraçã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 do Sistema 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 de Teste 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