Building Business Objects by HC120503213742

VIEWS: 9 PAGES: 45

									Building Business Objects


          Por Rafael Chaves (Jan/1999)
          Apresentação baseada no livro homônimo,
                       de Peter Eeles e Oliver Sims
Conceitos Fundamentais
         Objeto de Negócios
• Representação de um conceito “forte” do
  mundo real
• Autônomo
• Independente de aplicação
              Objetos
     Distribuídos x Embutidos
• Objeto Distribuído: visível além do escopo
  do programa, disponível no nível da rede
• Objeto Embutido: uma construção da
  linguagem de programação, visível apenas
  no escopo do programa
             Componente
• Objeto com interface bem definida
• Auto-descritivo (meta-informação)
• Relativamente independente e autônomo
• Pode encapsular um ou mais objetos
  (distribuídos e/ou embutidos)
• Funcionalidade específica
 Business Object Facility (BOF)
• Infra-estrutura com suporte ao
  desenvolvimento de aplicativos baseados
  em objetos de negócios
• Alto nível de abstração
• Encapsula serviços (diretórios, persistência,
  eventos, transações, ciclo de vida, etc.) e
  tecnologias específicas (linguagens de
  programação, bancos de dados, protocolos
  de rede) subjacentes
CAPÍTULO 1: Buildind a
   Business Object
Componentes de Negócios
     Componente de Negócios
• Realização de um objeto de negócios
• Compreende diferentes aspectos do objeto
  de negócios:
  – estado e comportamento
  – apresentação
  – persistência
     Componente de Negócios
• Permeia todas as fases do ciclo de vida do
  aplicativo
• Compõe-se de diversos objetos,
  responsáveis por diferentes aspectos do
  objeto de negócio representado
              Model / View
• Separação dos aspectos de representação e
  apresentação
• Isola o objeto modelo das idiossincrasias da
  apresentação
• Aumenta a reusabilidade
• Permite fornecer múltiplas visões para um
  mesmo modelo
  Distribuição de Componentes:
             Módulos
• Normalmente contém apenas um
  componente
• Fornecem um mecanismo para atualização
  dinâmica de componentes
• Dependente do sistema operacional
• Exemplos: Dynamically Linked Libraries
  (Windows) e Shared Libraries (UNIX)
  Distribuição de Componentes:
             Pacotes
• Unidade de distribuição de componentes
• Incluem, além do próprio componente,
  documentação para a utilização e quaisquer
  outros recursos necessários para o
  funcionamento
CAPÍTULO 2: The Case For
      Components
Aplicações Tradicionais
          X
     Reutilização
          Compartilhamento
• Aplicações são distribuídas como caixas-
  pretas, sem quaisquer interfaces com o
  mundo externo
• Componentes estão aprisionados nas
  aplicações, impossibilitando a reutilização
• Resultado: conceitos comuns entre
  aplicações são desnecessariamente
  duplicados
    Dificuldade de Manutenção
• Uma modificação em um “componente”
  utilizado em mais de um aplicativo requer
  recompilação, testes e redistribuição de
  todas os aplicativos afetados
     Dificuldade de Integração
• Só há integração entre aplicações que foram
  previamente desenvolvidas com este
  requisito
• A integração em um ambiente distribuído é
  ainda mais complexa
       Aplicações Monolíticas
• Novas funcionalidades só podem ser
  adicionadas se forem incorporadas ao projeto
  da aplicação, e esta for reconstruída
• A reutilização permanece um aspecto de
  tempo de projeto, não de execução
• Resultado: crescimento inevitável do
  software e gerenciamento comprometido
  Aplicações Tradicionais
            X
Modelo Conceitual do Usuário
           Correspondência
• representações computacionais possuem
  fraca correspondência com os conceitos do
  mundo real
• Resultado: o usuário não consegue aplicar
  no software os métodos que utiliza na
  prática
        Conceitos Artificiais
• O processo de desenvolvimento orientado a
  objetos não mantém o paradigma na
  concepção da aplicação
• O conceito “aplicação” não existe no
  mundo real; “entidades” e “processos” são
  conceitos naturais
Aplicações Tradicionais
          X
      Mudanças
       Resistência a Mudanças
• Uma aplicação só permite sua utilização para
  uma finalidade previamente concebida
• Novas necessidades requerem modificações e,
  conseqüentemente, recompilação, teste e
  redistribuição da nova versão
• Não é possível para o usuário adaptar ou
  estender uma aplicação existente sem acesso ao
  código-fonte e conhecimento técnico
CAPÍTULO 3: Business Objects
    and Business Entities
Aplicações Baseadas em Objetos
        de Negócios...
   ... Reutilizam Componentes
• Se uma aplicação é formada por
  componentes de negócios, então estes
  componentes podem ser reutilizados por
  outras aplicações
• A uniformidade de significação para a
  modelagem dos conceitos do mundo real
  depende de iniciativas de padronização,
  como o RFP Common Business Objects, da
  OMG
 ...São Altamente Manuteníveis
• Modificações requerem a recompilação,
  teste e redistribuição apenas do(s)
  componente(s) afetado(s)
• Não há necessidade de interrupção no
  funcionamento das aplicações para que a
  nova versão do componente se torne ativa
     ... São Fáceis de Integrar
• Componentes existem para serem
  integrados
• Componentes podem ser reutilizados em
  aplicações diferentes das previstas
• Componentes podem encapsular aplicativos
  pré-existentes, tornando-os aptos à
  integração
• Componentes de Negócios são
  inerentemente distribuídos
      ... Não São Monolíticas
• Se um aplicativo necessita da
  funcionalidade de um novo componente, ela
  simplesmente o reutiliza
• Novas funcionalidades não provocam
  crescimento do código da aplicação
...Não Impõem Limites Artificiais
• Há uma ampla correspondência entre os
  conceitos do mundo real e os componentes
  de negócios
 ... São Compostas de Conceitos
          do Mundo Real
• Os conceitos detectados na análise de
  requisitos permanecem nos modelos de
  análise e projeto, na implementação e na
  própria utilização do software
• Esta continuidade permite que usuários,
  analistas, projetistas e programadores
  utilizem os mesmos termos, melhorando a
  comunicação
    ... São Orientadas a Objetos
• Como no mundo real, o software baseado
  em objetos de negócios enfatiza os objetos
  (entidades e processos) e suas
  características (estado e comportamento)
• Um aplicativo é na verdade uma agregação
  determinada de componentes
  independentes, no intuito de resolver um
  determinado problema
     ... Comportam Mudanças
• Mudanças nos requisitos requerem
  modificações em alguns poucos
  componentes
• Um usuário mais ambicioso é capaz de
  efetuar determinadas adaptações/extensões,
  dado que o aplicativo é composto de
  componentes que representam conceitos
  que lhe são familiares
CAPÍTULO 4: Business Objects
   and Business Processes
Objetos de Negócios,
    Entidades e
     Processos
     Entidades e Processos de
            Negócios
• Conceitos do mundo real possuem aspectos
  estruturais e comportamentais
• Normalmente há uma ênfase em um destes
  aspectos (data-centric e process-centric)
• Entidades do mundo real são data-centric
• Processos do mundo real são process-
  centric
Por quê Modelar Processos como
        Componentes?
• Processos constituem o aspecto mais volátil
  do ambiente de negócios
• A lógica do processo não deve ser atribuída
  aos componentes existentes, para não
  comprometer a reusabilidade
• Para obter os benefícios presentes na
  modelagem de entidades (reusabilidade,
  modelo conceitual superior, suporte a
  mudanças)
  Componentes de Processos de
          Negócios
• Coordenam o fluxo de controle
• Fazem uso dos componentes data-centric
  para realizar suas atividades
• Podem fazer uso de outros componentes
  process-centric para realizar sua função
  (múltiplos níveis)
• Fornecem uma implementação coerente
  para workflow
CAPÍTULO 5: Business Objects
    and Business Change
Mudanças nas Regras
    Mudanças São Inevitáveis
• Uma importante influência na escolha de
  uma tecnologia é sua capacidade de
  adaptação ao desenvolvimento e
  modificação dos negócios
• Os principais conceitos que fundamentam a
  tecnologia de objetos de negócios
  endereçam os requisitos no suporte a
  mudanças
      Requisitos de Negócios
• Modificações devem ser efetuadas
  rapidamente
• Aplicativos não devem precisar ser
  interrompidos
• Os sistemas devem ser projetados para
  comportar futuras modificações
      Requisitos Tecnológicos
• Objetos devem ser interoperáveis
• A implementação de um objeto deve ser
  transparente aos clientes
• Interfaces devem poder evoluir
• Objetos devem ter baixo acoplamento entre
  si
Building Business Objects


          Por Rafael Chaves (Jan/1999)
          Apresentação baseada no livro homônimo,
                       de Peter Eeles e Oliver Sims

								
To top