Desenvolvimento Global de Software

1
Desenvolvimento Global de Software

• Mestrado de Informática / UFPB
• Francilene Procópio Garcia, D.Sc.
• francilene_at_ieee.org

Arquiteturas baseadas em Componentes - Parte V
2
Introdução

• Metodologias OO vs. Metodologias baseadas em
  componentes
• Metodologias OO existem para apoiar os
  desenvolvedores no uso de linguagens OO na
  criação de aplicações OO
• Ainda, a análise pode ser OO, porém o
  desenvolvimento fazer uso de algum outro método
  de desenvolvimento
• Algumas da metodologias OO dizem suportar reuso e
  desenvolvimento baseado em componentes uma
  afirmação ambígua!
• Em geral, metodologias OO focam mais nos
  requisitos e na análise e deixam de lado o
  projeto e a codificação onde os componentes e o
  reuso devem ocorrer...
• Metodologias baseadas em componentes assumem a
  existência prévia de componentes não tratam o
  desenvolvimento como uma seqüência de passos onde
  se inicia necessariamente com os requisitos

3
Introdução

• Metodologias baseadas em componentes
• O ponto central do desenvolvimento de aplicações
  baseado em componentes é a definição de quais
  componentes são necessários e se os componentes
  disponíveis atendem às funcionalidades requeridas
• Ainda, a metodologia baseada em componentes deve
  distinguir componentes e repositórios e mostrar
  como tais repositórios são acessíveis
• Existem dois tipos de metodologias baseadas em
  componentes
• Metodologias que focam no desenvolvimento de
  componentes
• Metodologias que focam no desenvolvimento de
  aplicações baseadas em componentes
• Na indústria, muitas empresas que tiveram sucesso
  real na implementação de reuso de programas,
  reorganizaram seus processos de desenvolvimento
  de software e criaram grupos independentes
  especializados na criação e manutenção de
  bibliotecas de objetos e componentes

4
Metodologias baseadas em componentes
Metodologia
Pessoas
Tools
Resultados
5
Algumas definições importantes

• Componente um módulo de código que tem uma ou
  mais interface padrão
• Interface é construída a partir da assinatura de
  métodos
• OMG, IDL, MS's COM especificam LP's nas quais
  interfaces de componentes podem ser definidas
• Repositório - local onde os componentes são
  armazenados
• Tipos de Componentes (1) Componentes GUI (2)
  Componentes de Infra Estrutura (DB's, network,
  etc) (3) Componentes de Negócios (capturam a
  lógica do negócio para manuseio de tarefas
  específicas reconhecidas no negócio)

6
Algumas definições importantes

• Pattern - uma descrição abstrata de um caminho
  efetivo para organização de objetos e componentes
  que foram especificados/ criados para realizar
  uma tarefa recorrente
• Framework - um conjunto de objetos ou componentes
  organizados através de um ou mais patterns. Um
  framework projetado para manusear uma tarefa
  complexa, provavelmente deverá combinar
  componentes do tipo infraestrutura e do tipo
  negócios. Por exemplo, um componente projetado
  para suportar pocessamento de texto, deverá
  conter muitos componentes pequenos e vários
  patterns bem definidos

7
Projeto baseado em componentes vs. Projeto OO

• Quando se faz o design baseado em componentes,
  não é necessário saber como eles são são
  representados (objetos ou instâncias de classes).
  Como em programas OO, objetos devem acessar a
  informação mantida por outros objetos, de forma
  que numa arquitetura baseada em componentes
  existem interfaces bem definidas para comunicação
  entre componentes.
• Porém, algumas distinções entre Projeto baseado
  em componentes e Projeto OO são claras
• Componentes fazem uso de formas de armazenamento
  persistente - programas OO, tipicamente,
  trabalham na memória principal, onde a
  persistência é feita em separado

8
Projeto baseado em componentes vs. Projeto OO

• Porém, algumas distinções entre Projeto baseado
  em componentes e Projeto OO são claras
• Componentes possuem vários mecanismos para
  intercomunicação, tais como eventos, workflows -
  OO atua basicamente com mensagens. Tais
  mecanismos suportam uma composição flexível entre
  as partes num CBD
• Componentes são frequentemente de propósito mais
  geral, e são implementados através de múltiplos
  objetos de diferentes classes
• Um pacote de componentes inclui tanto as
  definições de interfaces que suportam como as que
  requerem - classes tradicionais focam apenas
  sobre as operações suportadas
• Objetos tendem ser dinâmicos (número de clientes,
  produtos, mudam dinamicamente) componentes
  tendem a ser mais estáticos (um componente para
  controle de pagamento, por exemplo)

9
A evolução dos componentes

• A idéia presente nos componentes é tão antiga
  quanto a idéia do software em si, porém algumas
  coisas mudaram
• a granularidade dos componentes e respectiva
  unidade de plugabilidade variando de sistemas
  monolíticos, partições cliente-servidor, sistemas
  operacionais e seus serviços até às abordagens de
  componentes baseados em objetos nos dias de hoje
• os esforços para facilitar a conexão dinâmica de
  componentes para compor sistemas maiores ou
  aplicações mais complexas, apenas através da
  visualização da configuração e conexão dos
  componentes
• os esforços e custos na criação das aplicações
  de sistemas customizados monolíticos à soluções
  em pacotes gigantes, ou ainda nos componentes
  menores construídos através de interfaces padrões
  

10
Tipos de arquiteturas

• Podem existir muitas variações para a
  implementação de um dado modelo de arquitetura, e
  o mesmo modelo de arquitetura pode ser aplicado a
  muitas aplicações diferentes. Uma arquitetura de
  um dado componente, portanto, deve descrever seu
  tipo ou estilo e sua implementação
• tipo ou estilo da arquitetura - indica as
  categorias de conectores permitidas entre
  componentes, o que cada um deles faz e as regras
  e limites para o seu uso
• implementação da arquitetura - como cada
  categoria de conector atua internamente,
  incluindo o protocolo de interação entre eles
• Exemplos CORBA e COM

11
Tipos de arquiteturas

• É importante lembrar que uma arquitetura não
  define necessariamente qualquer código. Uma
  arquitetura provê ao desenvolvedor do componente
  um conjunto de regras e facilidades - na verdade
  alguns patterns para as interações mais típicas
• Em suma, uma arquitetura não limita os tipos de
  ação que os componentes podem fazer juntos, o que
  ela faz é facilitar a documentação das categorias
  de interação e encorajar o uso de componentes
  existentes

12
Variações de arquiteturas cliente-servidor
13
3 camadas vs. 2 camadas
14
Desenvolvimento baseado em componentes

• Uma abordagem possível
• Um ciclo iterativo possibilita a identificação
  progressiva de componentes e apoia na decisão
  sobre qual deve ser desenvolvido, qual deve ser
  reusado, e qual pode ser comprado.
• O foco na arquitetura do software permite que a
  estrutrura seja articulada - os componentes e os
  caminhos de sua integração, incluindo os
  mecanismos básicos e os patterns par ainteração
  entre eles
• Conceitos, tais como pacotes, subsistemas e
  camadas são usados todo o tempo para organização
  dos componentes e especificação de suas
  interfaces
• Os testes são realizados primeiro sobre os
  componentes, e gradualmente abrangem os conjuntos
  integrados de componentes

15
Tarefas

• Component Methodologies. Component Development
  Strategies, November 1998, Vol. VIII, No. 11
• Fases do ciclo de desenvolvimento de aplicações
  baseadas em componentes
• Developing Large-Scale Systems with the Rational
  Unified Process
• Desenvolvimento distribuído de sistemas
• Web Architecture Patterns
• Web delivery
• Modeling Web Application Architectures with UML
• Arquiteturas de aplicações Web