UNIVERSIDADE FEDERAL DE SÃO CARLOS
CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
“Uma Abordagem para o Desenvolvimento de Software
Baseado em Componentes Distribuídos”
Orientador: Prof. Dr. Antonio Francisco do Prado
Co-Orientador: Prof. Dr. Luis Carlos Trevelin
Aluno: Eduardo Santana de Almeida
Fevereiro/2003
“...eu vim da Bahia, mas algum dia eu volto pra lá...”
Gilberto Gil, 1965
i
A DEUS, minha maravilhosa Mãe, Nando, Marcelo e Loana.
ii
Agradecimentos
Ao longo desse período de um ano e dez meses, muitas pessoas
contribuíram e me incentivaram nesta conquista tão almejada.
Inicialmente, não poderia deixar de agradecer ao meu Deus, que
tanto me deu força e coragem para lutar pelos meus sonhos e
objetivos, não me deixando abater pelos obstáculos encontrados
ao longo do caminho.
Em
seguida,
(Universidade
esforços
agradeço
Salvador),
para
especialmente,
Gorgonio
a
meu
que
me
ingresso
Antonio
Barreto
todos
Carlos
Araújo,
os
incentivaram
na
Fontes
Isaac
professores
e
da
UNIFACS
não
mediram
carreira
Atta,
Douglas
acadêmica,
Dalila
Moreira
e
Haickel,
Vicente
Manuel Moreira Júnior.
A Cesar Augusto Camillo Teixeira pelo grande incentivo e
hospitalidade para o meu ingresso na Universidade Federal de
São Carlos, e pelas criticas e sugestões realizadas durante os
exames de qualificação e dissertação de mestrado.
Ao professor Mauro Biajiz e a professora Marina Teresa Pires
Vieira pela confiança depositada no meu potencial durante o
ingresso nesta universidade.
Ao
meu
orientador
Antonio
Francisco
do
Prado
por
toda
orientação, incentivo e confiança depositada ao longo deste
período
e
pelas
diferentes,
pesquisador.
mas
inúmeras
que
me
discussões
ajudaram
sobre
muito
a
pontos
de
engrandecer
vista
como
iii
Ao meu co-orientador Luis Carlos Trevelin que desde o início
deste trabalho se mostrou sempre uma pessoa amiga e disposta a
cooperar
através
de
inúmeras
conversas
e
discussões
sobre
temas relacionados ao trabalho, além do seu grande incentivo.
Aos colegas Luis Fernando Hachich de Souza e Alexandre Álvaro
pelas inúmeras discussões sobre objetos distribuídos.
A
todos
os
amigos
do
especialmente,
Calebe
de
incentivo
e
inúmeras
grupo
Paula
discussões;
de
engenharia
Bianchini
Daniel
de
por
software,
toda
Lucrédio
força,
por
estar
sempre disposto a ajudar e discutir novas idéias e projetos; e
Valdirene
Fontanette
pelas
inúmeras
traduções
e
auxílio
no
inglês.
A Orlando de Andrade Figueiredo por toda hospitalidade e
grande ajuda durante minha chegada em São Carlos.
A Dona Ofélia e toda a sua família por toda a ajuda, carinho
e amizade.
Aos
colegas
descontração,
de
república
especialmente,
pelos
momentos
Fernando
César
de
amizade
Balbino,
e
Edson
Guimarães, Cláudio Haruo Yamamoto e Alessandro Rodrigues.
Aos professores Guilherme Horta Travassos e, especialmente,
Márcio de Oliveira Barros, da Universidade Federal do Rio de
Janeiro, pelas inúmeras contribuições para o desenvolvimento
do experimento.
Ao professor Silvio Romero de Lemos Meira pelas criticas e
sugestões apresentadas durante a defesa de dissertação.
A
todos
alunos
que
aceitaram
participar
do
estudo
experimental.
A Fundação de Amparo a Pesquisa do Estado da Bahia (FAPESB)
pelo financiamento parcial deste projeto.
Ao grande amigo Vinicius Cardoso Garcia, companheiro de longa
data, por toda ajuda dada nos momentos de extrema dificuldade
em São Carlos; pelas inúmeras conversas por noites e viagens
afora; por todo incentivo, amizade e disponibilidade em sempre
querer ajudar.
iv
A toda família Maricondi por todo apoio, carinho e incentivo.
A minha maravilhosa mãe, pelo grande amor, incentivo, carinho
e grande esforço que fez durante toda a vida para me oferecer
os subsídios para minha chegada neste ponto.
A minha segunda mãe, Luiza, por todo o amor e carinho que
sempre teve por mim, estando eu, longe ou perto.
Ao meu irmão Nando pelo incentivo, companheirismo, carinho,
amizade; por contribuir em parte de minha formação e por tudo
que sempre fez para me ver feliz.
Ao
meu
irmão
Marcelo
que
contribuiu
muito
para
minha
formação, por todo amor e incentivo nos momentos difíceis; e,
por
muitas
vezes,
abrir
mão
de
certas
coisas
que
a
vida
poderia te proporcionar para investir no meu estudo e na minha
formação
desde
os
tempos
de
criança;
com
certeza,
este
trabalho deve-se muito a você.
A Loana, o amor de minha vida, pela excepcional pessoa que
sempre se mostrou, por todo o amor, companheirismo, carinho e
incentivo que sempre teve comigo.
Mais uma vez gostaria de agradecer a minha mãe, Marcelo,
Nando e Loana, sem vocês, certamente, este trabalho não se
concretizaria. Amo todos vocês.
v
Sumário
AGRADECIMENTOS .............................................................................................................. II
SUMÁRIO................................................................................................................................. V
LISTA DE FIGURAS ........................................................................................................... VIII
LISTA DE TABELAS .............................................................................................................. X
RESUMO .................................................................................................................................XI
ABSTRACT ........................................................................................................................... XII
INTRODUÇÃO.......................................................................................................................... 1
1.1 MOTIVAÇÃO ................................................ 1
1.2 APRESENTAÇÃO ............................................. 3
ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES................................... 5
2.1 INTRODUÇÃO ...............................................5
2.2 ARTEFATOS REUTILIZÁVEIS ....................................6
2.2.1 ABORDAGENS PARA REUTILIZAÇÃO ................ .........6
2.3 ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES ...................7
2.3.1 ENGENHARIA DE DOMÍNIO ...............................7
2.3.1.1 ATIVIDADES DA ENGENHARIA DE DOMÍNIO ...............8
2.3.1.2 PROFISSIONAIS ENVOLVIDOS COM A ENGENHARIA DE DOMÍNIO .8
2.3.1.3 PRODUTOS GERADOS PELA ENGENHARIA DE DOMÍNIO ........9
2.4 DESENVOLVIMENTO BASEADO EM COMPONENTES (DBC) ..................10
2.4.1 COMPONENTES DE SOFTWARE ........................... 11
2.4.2 COMPONENTES E OBJETOS ..............................15
2.4.3 MODELO DE COMPONENTES ..............................16
2.4.3.1 ELEMENTOS DE UM MODELO DE COMPONENTES ............17
2.4.3.2 IMPLEMENTAÇÃO DE UM MODELO DE COMPONENTES .........18
2.4.4 MÉTODOS PARA DESENVOLVIMENTO DE COMPONENTES ............19
2.4.4.1 CATALYSIS ..................................20
2.4.4.2 RATIONAL UNIFIED PROCESS (RUP) ................22
2.4.4.3 SELECT PERSPECTIVE ...........................24
2.4.4.4 UML COMPONENTS ..............................25
2.5 REPOSITÓRIO DE COMPONENTES ............................... 25
2.6 COMMERCIAL-OFF-THE-SHELF (COTS) ........................
27
vi
2.7 TÓPICOS DE PESQUISA EM DBC ................................29
2.7.1 MEDIDAS E MÉTRICAS PARA COMPONENTES DE SOFTWARE .........29
2.7.2 AGENTES DE SOFTWARE COMO A PROXIMA GERAÇÃO DE COMPONENTES 30
2.7.3 PROGRAMAÇÃO ORIENTADA A ASPECTOS .....................31
2.8 RESUMO .................................................33
PADRÕES DE SOFTWARE....................................................................................................34
3.1 INTRODUÇÃO ............................................. 34
3.2 DISTRIBUTED ADAPTERS PATTERN (DAP) ........................ 36
3.3 PADRÕES PARA O MAPEAMENTO DE OBJETOS DE NEGÓCIO PARA BANCO DE DADOS
RELACIONAL ..................................................39
3.3.1 PERSISTENCE LAYER .................................40
3.3.2 CRUD (CREATE, READ, UPDATE, DELETE) ............41
3.3.3 CONNECTION MANAGER .................................41
3.3.4 TABLE MANAGER ......................................42
3.4 RESUMO ..............................................
43
COMPUTAÇÃO DISTRIBUÍDA E OBJETOS DISTRIBUÍDOS .........................................44
4.1 INTRODUÇÃO ..............................................44
4.2 MIDDLEWARE ...........................................
46
49
4.2.1 OBJECT REQUEST BROKER (ORB) ....................
4.2.1.1 COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) 50
4.2.1.2 ARQUITETURA CORBA .........................
51
4.3 RESUMO ................................................ 59
FERRAMENTAS CASE ....................................................... .................................................60
5.1 INTRODUÇÃO ..............................................60
5.2 FERRAMENTAS DE ANÁLISE E PROJETO ........................... 64
5.2.1 MVCASE ....................................... 64
5.2.2 NOTAÇÕES UML SUPORTADAS PELA MVCASE ............... 65
5.3 RESUMO .................................................68
ABORDAGEM DE DESENVOLVIMENTO DE SOFTWARE BASEADO EM
COMPONENTES DISTRIBUÍDOS .......................................................................................69
6.1 INTRODUÇÃO ..............................................69
6.2 MECANISMOS DA ABORDAGEM ...................................70
6.2.1 MÉTODO CATALYSIS ..................................70
6.2.2 MIDDLEWARE .......................................71
6.2.3 FRAMEWORK E PADRÕES ................................71
6.2.3.1 FRAMEWORK PERSISTENCE ............................72
6.2.4 FERRAMENTA MVCASE ................................73
6.2.4.1 MODELO DE COLABORAÇÃO ..........................74
6.2.4.2 FRAMEWORK DE MODELOS E MODELO DE APLICAÇÃO DO FRAMEWORK
............................................................74
6.2.4.3 WIZARD PARA GERAÇÃO DE CÓDIGO DOS COMPONENTES .......76
6.3 ABORDAGEM DE DESENVOLVIMENTO DE SOFTWARE BASEADO EM COMPONENTES
DISTRIBUÍDOS ................................................77
6.3.1 DESENVOLVVER COMPONENTES DISTRIBUÍDOS .................78
6.3.1.1 DEFINIR PROBLEMA ..............................80
6.3.1.2 ESPECIFICAR COMPONENTES .........................81
vii
6.3.1.3 PROJETAR COMPONENTES ...........................83
6.3.1.3.1 APLICANDO O DAP ...........................84
6.3.1.3.2 OUTROS REQUISITOS NÃO FUNCIONAIS .............85
6.3.1.4 IMPLEMENTAR COMPONENTES ........................87
6.3.2 DESENVOLVER APLICAÇÕES DISTRIBUÍDAS .......................88
6.3.2.1 ESPECIFICAR APLICAÇÃO ..........................89
6.3.2.2 PROJETAR APLICAÇÃO ............................89
6.3.2.2.1 PREPARAR AMBIENTE .........................90
6.3.2.3 IMPLEMENTAR APLICAÇÃO ..........................91
6.4 TESTES ENVOLVENDO OS COMPONENTES E AS APLICAÇÕES ...............92
6.5 AVALIAÇÃO DA ABORDAGEM ...................................93
6.5.1 INTRODUÇÃO .......................................93
6.5.2 A ABORDAGEM ......................................93
6.5.2.1 PLANEJAMENTO..................................94
6.5.2.2 MONITORAÇÃO ..................................94
6.5.2.3 AVALIAÇÃO DOS RESULTADOS ........................96
6.6 RESUMO .................................................97
ESTUDO EXPERIMENTAL ..................................................................................................98
7.1 INTRODUÇÃO ..............................................98
7.2 TERMINOLOGIA UTILIZADA ....................................99
7.3 ESTUDO EXPERIMENTAL ......................................100
7.3.1 DEFINIÇÃO DO ESTUDO EXPERIMENTAL ....................101
7.3.2 PLANEJAMENTO ....................................102
7.3.3 PROJETO UTILIZADO NO ESTUDO EXPERIMENTAL ..............108
7.3.4 INSTANCIAÇÃO DO ESTUDO EXPERIMENTAL ..................108
7.3.5 EXECUÇÃO DO ESTUDO EXPERIMENTAL .....................109
7.3.6 ANALISE DOS RESULTADOS DO ESTUDO EXPERIMENTAL ..........110
7.3.7 LIÇÕES APRENDIDAS ................................114
7.4 RESUMO ................................................115
CONCLUSÕES .....................................................................................................................116
8.1 SOBRE O TRABALHO ........................................116
8.2 PRINCIPAIS CONTRIBUIÇÕES ..................................117
8.3 TRABALHOS RELACIONADOS ...................................118
8.3.1 A PROPOSTA DE GUIMARÃES ...........................118
8.3.2 A PROPOSTA DE CLEMENT .............................119
8.3.3 OUTRAS FERRAMENTAS ...............................119
8.4 TRABALHOS FUTUROS .......................................120
8.5 CONTRIBUIÇÕES ACADÊMICAS ..................................122
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................125
APÊNDICE ............................................................................................................................144
viii
Lista de Figuras
FIGURA 1: PROCESSO
DESENVOLVIMENTO
DE
FIGURA 2: UM EXEMPLO
FIGURA 3: ESTRUTURA
FIGURA 4: SERVIÇOS
SOFTWARE
EM
CATALYSIS ....... 22
DAP .................................. 37
PADRÃO DAP .............................. 38
DO
DE
FIGURA 5: ESTRUTURA
DO
DE
MIDDLEWARE ............................... 48
DE UM
ORB ................................. 52
FIGURA 6: OBJECT MANAGEMENT ARCHITECTURE ......................... 55
FIGURA 7: DIAGRAMA
DE
CLASSES.................................. 66
FIGURA 8: DIAGRAMA
DE
COMPONENTES .............................. 67
FIGURA 9: DIAGRAMA
DE
CASO
USO
DE
SEQÜÊNCIA .................... 67
E
FIGURA 10: FRAMEWORK PERSISTENCE ............................... 72
FIGURA 11: MODELO
DE
COLABORAÇÃO ............................... 74
FIGURA 12: FRAMEWORK
DE
MODELOS ................................ 75
FIGURA 13: MODELO
DE
APLICAÇÃO
DO
FRAMEWORK ...................... 76
FIGURA 14: WIZARD
PARA
GERAÇÃO
DE
CÓDIGO
FIGURA 15: ABORDAGEM
DE
FIGURA 16: PASSOS
DESENVOLVIMENTO
DO
DE
TIPOS
DA
MODELOS
FIGURA 20: MODELO
DE
APLICAÇÃO
FIGURA 21: MODELO
DE
CLASSES OBTIDO
FIGURA 22: MODELO
DE
COMPONENTES
CÓDIGO
FIGURA 24: DESENVOLVIMENTO
COMPONENTES DISTRIBUÍDOS .... 79
PASSO ESPECIFICAR COMPONENTES ......... 81
DO
DE
DE
DOS
ABORDAGEM: DEFINIR PROBLEMA ........... 80
FIGURA 19: FRAMEWORK
FIGURA 23: GERAÇÃO
COMPONENTES............ 77
DBCD ................................. 78
FIGURA 17: PRIMEIRO PASSO
FIGURA 18: MODELO
DOS
DO
NA
DAS
DO
DOMÍNIO
DE
ORDEM
DE
SERVIÇOS ...... 82
FRAMEWORK ...................... 82
DO
APÓS
MODELO
APLICAR
DE
O
TIPOS ............. 84
DAP ............... 85
FERRAMENTA MVCASE ................ 87
APLICAÇÕES DISTRIBUÍDAS ............. 88
ix
FIGURA 25: COMPONENTES REUTILIZADOS
FIGURA 26: PROJETO
DA
PARA
APLICAÇÃO REGISTRAR CLIENTE .. 89
APLICAÇÃO DISTRIBUÍDA ...................... 90
FIGURA 27: MODELO OBJECT WEB ESTENDIDO .......................... 91
FIGURA 28: IMPLEMENTAÇÃO
FIGURA 29: TIPOS
DE
FIGURA 30: DESCRIÇÃO
DA
APLICAÇÃO REGISTRAR CLIENTE ............ 92
VARIÁVEIS
DO
EM UM
PROJETO
DE
EXPERIMENTO ................... 99
DESENVOLVIMENTO ............... 108
x
Lista de Tabelas
TABELA 1: ELEMENTOS
DE UM
MODELO
DE
COMPONENTES ................... 17
TABELA 2: DIAGRAMAS ESTRUTURAIS ................................ 65
TABELA 3: DIAGRAMAS COMPORTAMENTAIS ............................. 65
TABELA 4: CATALYSIS VERSUS ABORDAGEM
DE
DBCD..................... 71
TABELA 5: ARTEFATOS DISPONIBILIZADOS ............................ 96
TABELA 6: PERFIL
DOS
PARTICIPANTES
TABELA 7: DADOS OBTIDOS
TABELA 8: DADOS OBTIDOS
POR CADA
DO
ESTUDO EXPERIMENTAL .......... 110
PARTICIPANTE UTILIZANDO
POR CADA
A
PARTICIPANTE UTILIZANDO
ABORDAGEM . 111
A
ABORDAGEM AD-
HOC ........................................................ 111
TABELA 9: MÉDIA
DOS
DADOS OBTIDOS
PELOS
DOIS GRUPOS .............. 112
xi
Resumo
Apesar
das
recentes
e
constantes
pesquisas
na
área
de
Desenvolvimento Baseado em Componentes (DBC), ainda existe uma
carência de padrões, abordagens e metodologias que suportem,
efetivamente,
quanto
término
o
o
desenvolvimento
desenvolvimento
da
Internet,
tanto
última
onde
com
década,
a
reutilização.
com
distribuição
para
se
o
acelerado
tornou
reutilização,
Considerando
o
crescimento
da
requisito
não
um
funcional essencial em muitas aplicações, o problema tornou-se
ainda maior.
Este projeto apresenta uma Abordagem para o Desenvolvimento
de Software Baseado em Componentes Distribuídos, que integra
os
princípios
de
engenharia
de
software
baseada
em
componentes, frameworks, padrões e distribuição. A abordagem é
dividida em duas etapas: no desenvolvimento para reutilização
e no desenvolvimento com reutilização. Uma ferramenta CASE é o
principal
mecanismo
de
execução
da
abordagem,
suportando,
inclusive, a geração de código dos componentes e aplicações.
Um ambiente para distribuição dos componentes e aplicações é
proposto
para
experimental,
execução
são
da
abordagem.
mostrados
os
Através
resultados
de
da
um
estudo
análise
da
viabilidade de utilização da abordagem no desenvolvimento de
software baseado em componentes distribuídos.
xii
Abstract
In spite of recent and constant researches in the ComponentBased
Development
patterns,
support
as
(CBD)
approaches
much
the
area,
and
there
is
methodologies
development
for
still
a
that
effectively
reuse
as
lack
with
of
reuse.
Considering the accelerated growth of the Internet over the
last decade, where distribution has become an essential nonfunctional
requirement
of
most
applications,
the
problem
became bigger.
Thus,
this
project
presents
a
Distributed
Component-Based
Software Developmente Approach that integrates the concepts of
Component-Based
Software
Engineering
(CBSE),
frameworks,
patterns, and distribution. This approach is divided into two
stages: in the development for reuse, and in the development
with reuse. A CASE tool is the main mechanism to apply this
approach,
supporting
inclusively,
the
code
generation
of
applications
environment
is
components and applications
A
distributed
components
and
proposed for accomplishing the results of this approach. The
results of the analysis of the viability of using the approach
in the distributed component-based software development are
presented through an experimental study.
Capítulo 1
Introdução
1.1 Motivação
Uma das razões mais convincentes para a adoção de abordagens
de desenvolvimento de software baseado em componentes, com ou
sem objetos, é a premissa de reutilização. A idéia é construir
software
de
componentes
já
existentes
primariamente
pela
montagem e substituição de suas partes interoperáveis. Estes
componentes abrangem desde controles de interfaces de usuário,
como
listboxes
e
HTML
browsers,
até
componentes
para
persistência em banco de dados e distribuição. As implicações
de redução de tempo de desenvolvimento e melhoria da qualidade
do produto tornam esta abordagem muito atrativa [Szyperski,
1998].
A
reutilização
reaproveitar
ao
implementação
mesma
idéia
desenvolvido,
implantá-lo
já
é
uma
máximo
variedade
de
técnicas
trabalho
de
análise,
o
concluído.
O
objetivo
cada
vez
que
mas
sim
organizar
imediatamente
em
um
um
novo
o
é
não
produto
trabalho
novo
que
projeto
e
reinventar
a
tiver
já
contexto.
visa
que
ser
realizado
Deste
e
modo,
mais produtos podem ser entregues em menores tempos, os custos
referentes às tarefas de manutenção são reduzidos, uma vez que
as melhorias realizadas em um segmento do projeto refletir-seão em todos os projetos nos quais este está sendo utilizado e,
2
Capítulo 1 – Introdução
por
fim,
tem-se
uma
melhoria
de
qualidade,
visto
que
os
componentes reutilizados já foram bem testados.
Para que a reutilização possa ser efetiva, deve-se considerála
em
todas
as
fases
do
processo
de
desenvolvimento
do
software. Portanto, o Desenvolvimento Baseado em Componentes
(DBC)
deve
suportem
oferecer
desde
componentes,
do
a
métodos,
técnicas
identificação
domínio
do
e
problema,
e
ferramentas
especificação
até
o
seu
que
dos
projeto
e
implementação em uma linguagem orientada a componentes. Além
disso, o DBC deve empregar inter-relações entre componentes já
existentes,
previamente
testados,
visando
reduzir
a
complexidade e o custo de desenvolvimento do software [Werner,
2000].
Componentes de software já se tornaram realidade no nível de
implementação [Szyperski, 1998] e, atualmente, o conceito deve
ser
consolidado
nas
fases
anteriores
do
ciclo
de
vida
de
desenvolvimento. Deste modo, os princípios e os conceitos de
DBC
devem
ser
desenvolvimento
aplicados
e
durante
realizados
de
todo
uma
o
fase
processo
para
de
outra,
consistentemente. Os métodos e as abordagens atuais de DBC,
discutidos em [D’Souza, 1999], [Perspective, 2000], [Jacobson,
2001],
não
incluem
o
suporte
total
para
o
conceito
de
um
componente. Isto resulta do fato de que os componentes são
tratados
principalmente
nas
fases
de
implementação
e
implantação, ao invés de serem focados durante todo o ciclo de
vida de desenvolvimento [Stojanovic, 2001]. Além disso, estes
métodos não definem claramente como adicionar requisitos não
funcionais, como, por exemplo, distribuição e persistência em
banco de dados e como se dá o desenvolvimento das aplicações
reutilizando os componentes previamente construídos, deixando
esta tarefa totalmente a cargo do desenvolvedor.
Assim, motivado pelas idéias de reutilização, desenvolvimento
baseado em componentes e distribuição, este projeto pesquisa
uma Abordagem para o Desenvolvimento de Software Baseado em
3
Capítulo 1 – Introdução
Componentes Distribuídos que procura orientar o engenheiro de
software
tanto
no
desenvolvimento
dos
componentes
de
um
domínio do problema, quanto no desenvolvimento das aplicações
que os reutilizam.
1.2 Apresentação
Esta
dissertação
está
organizada
em
oito
capítulos
e
um
engenharia
de
apêndice. O primeiro capítulo contém esta introdução.
O
Capítulo
2
apresenta
uma
visão
geral
da
software baseada em componentes, discutindo, detalhadamente, a
Engenharia
de
Componentes.
O
Domínio
e
o
Desenvolvimento
capítulo
contém,
ainda,
uma
Baseado
em
descrição
dos
mecanismos essenciais no processo de engenharia de software
baseada em componentes: a utilização de um repositório para
armazenamento
e
busca
dos
Commercial-Off-The-Shelf
discutidos
os
componentes
(COTS).
principais
Por
tópicos
e
a
fim,
de
utilização
são
de
relatados
pesquisa
que
e
estão
começando a ser explorados na área de DBC.
O Capítulo 3 apresenta os padrões de software, em especial,
os
padrões
negócio
para
para
distribuição
banco
de
e
mapeamento
dados
de
relacional,
objetos
de
utilizados
na
abordagem proposta.
O Capítulo 4 descreve a evolução da computação centralizada,
passando pelas redes locais até chegar aos chamados objetos
distribuídos;
elemento
introduz
fundamental
arquiteturas
alguns
dos
também
nos
o
sistemas
cliente/servidor,
principais
conceito
tipos
middleware,
distribuídos
descrevendo
de
de
e
nas
superficialmente
middleware
existentes.
Em
seguida, descreve, com detalhes, uma tecnologia específica de
middleware,
o
Object
Request
Broker,
ou
simplesmente
ORB,
definindo suas principais funcionalidades e aplicações.
O Capítulo 5 introduz as ferramentas CASE, sua taxonomia,
baseada
no
ferramenta
critério
MVCASE,
de
onde
função
se
como
apóia
elemento
toda
a
chave,
abordagem
e
a
de
4
Capítulo 1 – Introdução
desenvolvimento
de
software
baseado
em
componentes
distribuídos.
O
Capítulo
6
apresenta,
Desenvolvimento
de
detalhadamente,
Software
Baseado
a
Abordagem
em
de
Componentes
Distribuídos, discutindo seus principais mecanismos, suas duas
grandes
etapas
e
os
aspectos
envolvendo
os
testes
dos
componentes e aplicações. Por fim, é apresentado e discutido
um processo inicial de validação, ao qual a abordagem foi
submetida.
O
Capítulo
7
apresenta
a
definição,
o
planejamento,
a
execução e os resultados alcançados pelo estudo experimental
de
viabilidade
da
abordagem
proposta
no
desenvolvimento
de
software baseado em componentes distribuídos.
O
Capítulo
dissertação,
8
apresenta
ressaltando
as
suas
considerações
contribuições,
finais
desta
limitações
e
perspectivas futuras.
O
apêndice
apresenta
os
dois
questionários
estudo experimental apresentado no Capítulo 7.
utilizados
no
Capítulo 2
Engenharia de Software Baseada em
Componentes
2.1 Introdução
Antes
de
apresentar
e
discutir
a
engenharia
de
software
baseada em componentes, este capítulo apresenta um princípio
chave na área: a reutilização.
Segundo
[Pressman,
2001],
a
reutilização
no
contexto
da
engenharia de software não é uma idéia velha, nem nova. Ainda
conforme
o
autor,
os
programadores
têm
utilizado
idéias,
abstrações e processos desde os primeiros dias da computação,
mas as primeiras abordagens à reutilização eram as da prática
corrente. Atualmente, sistemas complexos e de alta qualidade
baseados em computador necessitam ser construídos em curtos
períodos de tempo. Isso indica uma abordagem mais organizada e
voltada à reutilização.
Um dos grandes pesquisadores na área de reutilização, Martin
Griss, visualiza a mesma como uma simples e bem conhecida
idéia [Griss, 1996]. A partir da necessidade de se construir
um
novo
software,
construídos.
Deste
deve-se
modo,
utilizar
tem–se
a
componentes
redução
nos
previamente
custos
de
desenvolvimento, testes, documentação e manutenção.
O mais comum produto de software reutilizável é o código
fonte, o qual é o produto final e mais importante da atividade
de desenvolvimento. Adicionalmente ao código, qualquer produto
6
Capítulo 2 – Engenharia de Software Baseada em Componentes
intermediário
do
ciclo
de
vida
do
software
pode
ser
reutilizado [Yunwen, 2001].
2.2 Artefatos Reutilizáveis
D’Souza
parte
de
[1999]
projeto.
define
artefato
trabalho
que
O
considera
autor
possa
reutilizável
como
qualquer
ser
utilizado
em
mais
os
seguintes
artefatos
de
um
como
candidatos à reutilização:
•
Código compilado; objetos executáveis.
•
Código Fonte; classes e métodos.
•
Casos de testes.
•
Modelos e Projetos: frameworks, padrões.
•
Interface de usuário.
•
Planos, estratégias e regras arquiteturais.
2.2.1 Abordagens para a Reutilização
Em uma cultura de reutilização, o desenvolvimento tende a ser
realizado
através
de
duas
atividades
distintas
[D’Souza,
1999]:
•
Desenvolvimento do Produto: corresponde ao projeto e à
criação das aplicações para resolver o problema. Essa
atividade é centralizada no entendimento do problema e
na
rápida
localização
e
montagem
dos
artefatos
reutilizáveis, necessários à implementação.
•
Desenvolvimento dos Artefatos: corresponde ao projeto e
à criação de componentes reutilizáveis que possam ser
utilizados em diferentes contextos.
Apesar
de
bem
conhecidos
os
benefícios
do
uso
da
reutilização, esse objetivo ainda é complexo na prática. Não
basta apenas agrupar partes de software em uma biblioteca e
disponibilizá-la
[Yunwen,
2001].
para
reutilização
Assim,
os
pelos
componentes
desenvolvedores
têm
de
ser
7
Capítulo 2 – Engenharia de Software Baseada em Componentes
cuidadosamente
projetados
e
desenvolvidos,
a
fim
de
propiciarem uma reutilização adequada em todas as etapas do
processo de desenvolvimento [Griss, 2001].
Segundo Griss [1996], o processo de desenvolvimento necessita
ser
mudado
para
dar
suporte
ao
desenvolvimento
e
à
reutilização de componentes. As pessoas precisam ser treinadas
de modo a utilizar os componentes e as bibliotecas, novas
tecnologias
e
o
próprio
processo
de
desenvolvimento.
Novos
métodos, visando o desenvolvimento baseado em componentes e a
reutilização,
precisam
ser
estabelecidos
e,
por
fim,
as
empresas necessitam ganhar experiências com essas mudanças.
2.3
Engenharia
de
Software
Baseada
em
Componentes
A engenharia de software baseada em componentes é um processo
que enfatiza o projeto e a construção de sistemas baseados em
computador, utilizando componentes de software reutilizáveis
[Pressman, 2001]. O modelo de processo para a engenharia de
software baseada em componentes enfatiza caminhos paralelos,
nos
quais
duas
atividades
são
essenciais:
a
Engenharia
de
Domínio e o Desenvolvimento Baseado em Componentes.
2.3.1 Engenharia de Domínio (ED)
Segundo Pressman [2001], a intenção da Engenharia de Domínio
(ED)
é
identificar,
construir,
catalogar
e
disseminar
um
conjunto de componentes de software que possua aplicabilidade
para software existente ou futuro, dentro de um particular
domínio
de
mecanismos
aplicações.
que
Deste
sistematizem
a
modo,
busca
a
e
ED
a
deve
estabelecer
representação
de
informações do domínio, de forma a facilitar ao máximo a sua
reutilização [Werner, 2000].
8
Capítulo 2 – Engenharia de Software Baseada em Componentes
2.3.1.1 Atividades da Engenharia de Domínio
Pesquisas [Prieto-Diaz, 1990], [Griss, 1998], [Pressman, 2001]
apontam que existem basicamente três etapas principais na ED:
•
Análise do Domínio: corresponde ao processo pelo qual a
informação usada no desenvolvimento do sistema, para um
determinado
organizada,
domínio,
com
a
é
identificada,
proposta
de
ser
capturada
reutilizada
para
e
a
criação de novos sistemas [Prieto-Diaz, 1990];
•
Projeto do Domínio: nesta etapa, os resultados da análise
do
domínio
soluções
são
usados
para
os
para
identificar
requisitos
e
comuns,
generalizar
através
da
especificação de uma arquitetura de software do domínio.
As
oportunidades
de
reutilização,
identificadas
na
análise do domínio, são refinadas de forma a especificar
as restrições do projeto [Werner, 2000]; e
•
Implementação do Domínio: nesta etapa, transformam-se as
oportunidades de reutilização e soluções do projeto para
um
modelo
implementacional,
que
inclui
serviços,
tais
como: a identificação, reengenharia e/ou construção, e
manutenção
dos
componentes
reutilizáveis,
que
suportem
estes requisitos e soluções de projeto [Werner, 2000].
2.3.1.2
Profissionais
envolvidos
com
a
Engenharia de Domínio
Em [Simos, 1996], [Werner, 2000], são apresentados três grupos
principais de profissionais, que atuam de forma efetiva num
processo de ED:
•
Fontes: são os usuários finais, que utilizam aplicações
já desenvolvidas naquele domínio, e os especialistas do
domínio, que provêem informações a respeito de conceitos
e funcionalidades relevantes no domínio;
9
Capítulo 2 – Engenharia de Software Baseada em Componentes
•
Produtores: são os analistas e os projetistas do domínio,
que capturam as informações das fontes e de aplicações
existentes
e
realizam
implementação
a
análise,
o
e
o
empacotamento
dos
são
os
desenvolvedores
de
projeto,
a
componentes
reutilizáveis; e
•
Consumidores:
aplicações
e
usuários finais interessados no entendimento do domínio,
que
utilizam
para
a
os
modelos
gerados
especificação
entendimento
de
nas
etapas
aplicações
dos
conceitos
e
Produtos
gerados
pela
anteriores
e/ou
funções
maior
inerentes
ao
domínio.
2.3.1.3
Engenharia
de
Domínio
Um método de engenharia de domínio, para ser efetivo, deve
prover
representações
específicas
para
documentar
os
resultados de cada uma das fases da ED [Werner, 2000]. Estas
representações devem, prioritariamente, representar o escopo e
a abrangência do domínio, descrever os problemas passíveis de
serem
solucionados,
domínio,
e
através
prover
de
componentes
especificações
de
software,
arquiteturais
no
e
implementacionais que solucionem os problemas encontrados do
domínio. Desta forma, para cada uma das fases da engenharia de
domínio,
devem
existir
produtos
específicos
a
serem
disponibilizados.
Na fase de análise de domínio, devem ser disponibilizadas
representações
que
capturem
o
contexto
e
a
abrangência
no
domínio, explicitando seu relacionamento com outros domínios.
Nesta
fase,
ainda,
devem
ser
disponibilizados
modelos,
que
capturem os principais conceitos e funcionalidades inerentes
ao domínio, gerando, assim, um ou mais modelos com abstrações
do domínio [SEI, 1999a].
10
Capítulo 2 – Engenharia de Software Baseada em Componentes
O
projeto
do
especifiquem
a
domínio
deve
estrutura
disponibilizar
arquitetural
a
ser
modelos
seguida
que
pelas
aplicações do domínio. As representações geradas devem prover
modelos
arquiteturais
arquiteturas
que
específicas
auxiliem
para
cada
na
especificação
aplicação
(SEI,
de
1999b),
[Werner, 2000].
A
fase
de
implementação
do
domínio
deve
disponibilizar
componentes implementacionais, que especifiquem as principais
funcionalidades encontradas em aplicações do domínio. Estes
componentes implementacionais devem estar em conformidade com
o modelo de abstrações da fase de análise e com os modelos
arquiteturais da fase de projeto, de forma que possam cooperar
entre si para implementar todas as funcionalidades necessárias
para uma determinada aplicação [SEI, 1999b].
2.4
Desenvolvimento
Baseado
em
Componentes
(DBC)
Até bem pouco tempo atrás, o desenvolvimento da maioria dos
produtos de software, disponíveis no mercado, era baseado em
uma
abordagem
de
desenvolvimento
de
blocos
monolíticos,
formados por um grande número de partes inter-relacionadas,
onde
estes
relacionamentos
estavam,
na
maioria
das
vezes,
implícitos. O DBC surgiu como uma nova perspectiva para o
desenvolvimento de software, cujo objetivo é a “quebra” destes
blocos monolíticos em componentes interoperáveis, reduzindo,
desta forma, a complexidade do desenvolvimento, assim como os
custos,
através
da
utilização
de
componentes
que,
em
princípio, seriam adequados para serem utilizados em outras
aplicações [Sametinger, 1997].
Este objetivo não é novo no desenvolvimento de software. Em
[Werner,
2000],
são
listados
alguns
trabalhos
que,
desde
então, vislumbravam uma indústria de componentes de software
reutilizáveis. A diferença é que estas abordagens se baseavam,
essencialmente, em código. Entretanto, constata-se que o DBC,
11
Capítulo 2 – Engenharia de Software Baseada em Componentes
para
ser
efetivo,
envolve
muito
mais
do
que
isto.
Apenas
recentemente, o DBC está sendo considerado como uma técnica
importante
fatores
no
desenvolvimento
despertou
este
novo
de
software.
interesse
na
Um
conjunto
área,
de
provendo
a
motivação necessária para se acreditar que o DBC possa ser
agora mais efetivo e realizado em larga escala. Dentre estes
fatores, podemos citar [Sametinger, 1997], [D’Souza, 1999]:
•
Desenvolvimento da Internet, que aumentou a preocupação
em relação à computação distribuída;
•
A mudança da estrutura de sistemas baseados em mainframes
para sistemas baseados na arquitetura cliente e servidor,
levando os desenvolvedores a considerarem as aplicações
não
mais
como
sistemas
monolíticos,
mas
sim
como
um
conjunto de sub-sistemas interoperáveis; e
•
Uso
de
Padrões
para
construção
de
aplicações,
como
o
Object Management Group (OMG) e Component Object Model
(COM).
2.4.1 Componentes de Software
O conceito exato de componente em DBC ainda não é um tópico
fechado. Cada grupo de pesquisa caracteriza, da maneira mais
adequada ao seu contexto, o que seria um componente e, assim,
não há ainda, na literatura, uma definição comum e precisa
para este termo.
Desde
o
primeiro
workshop
de
DBC
em
1998,
Kyoto
[Brown,
1998], até o mais recente, na Flórida, Estados Unidos [CBSE,
2002],
passando
[ICSR,
2002],
apresentadas.
por
[WCOP,
Em
outras
conferências
2002],
diversas
[Heineman,
2001],
um
mais
específicas
definições
grupo
têm
formado
sido
por
especialistas na área de engenharia de software baseada em
componentes relata que ao fim de dezoito meses chegou-se a um
consenso sobre o que seria um componente de software.
Segundo esses especialistas, um componente de software é um
elemento
de
software
em
conformidade
com
um
modelo
de
12
Capítulo 2 – Engenharia de Software Baseada em Componentes
componentes
e
que
pode
ser
independentemente
implantado
e
composto sem modificações, conforme um padrão de composição.
Em [Brown, 1998], são apresentadas diversas definições do que
vem a ser um componente. Algumas dessas visões são:
•
“Um
componente
como
um
elemento
arquitetural.
Este
componente deve prover e estar em conformidade com um
conjunto de interfaces”;
•
“Um
componente
acessado
como
através
de
um
elemento
interfaces
bem
implementacional
documentadas,
que
podem ser descobertas em tempo de execução”;
•
“Um componente como um elemento implementacional, mas
que faz parte de um contexto arquitetural específico”;
•
“Um componente de negócio representa a implementação de
um conceito autônomo de negócio ou processo. Consiste
dos artefatos de software necessários para expressar,
implementar
e
executar
o
conceito
como
um
elemento
reutilizável de um grande sistema de negócio”.
Cada uma dessas visões ressalta um determinado aspecto de um
componente.
Atualmente,
pode-se
notar
que
já
existem
definições mais precisas e convergentes. Em [Werner, 2000],
são listados alguns aspectos que um componente de software
deve
realizar.
Dentre
estes
aspectos,
constatou-se
que
um
componente deve:
•
descrever ou realizar uma função específica [Sametinger,
1997], [D’Souza, 1999];
•
estar em conformidade e prover um conjunto de interfaces
bem definidas [Sametinger, 1997], [Szyperski, 1998];
•
ter disponível uma documentação adequada [Sametinger,
1997];
•
estar inserido no contexto de um modelo que oriente a
composição deste componente com outros (arquitetura de
software);
13
Capítulo 2 – Engenharia de Software Baseada em Componentes
•
ser autocontido em termos da funcionalidade que provê.
Outro
ponto
importante
é
que,
no
início,
a
visão
de
um
componente como um elemento, somente como código, era bastante
comum e, atualmente, esta visão está mudando e os engenheiros
de
software
níveis
de
começam
a
abstração
visualizar
[D’Souza,
componentes
1999],
em
todos
[Heineman,
os
2001],
[Ommering, 2002].
Segundo Williams [2001], os componentes podem ser divididos
em três categorias:
•
Componentes
GUI:
são
os
componentes
encontrados
mais
no
conhecidos
mercado.
Nessa
tipos
de
categoria
enquadram-se todos os botões, menus e outros widgets
utilizados na criação de interfaces para aplicações.
•
Componentes de Serviços: provêem acessos para serviços
comuns
necessários
em
muitas
aplicações.
Isso
inclui
acesso a banco de dados, acesso a serviços de mensagens
e
transações
e
serviços
de
integração.
Uma
característica comum dos componentes de serviços é que
estes utilizam uma estrutura adicional ou sistemas para
realizar suas funções. Por exemplo, pode-se empacotar um
sistema
existente
a
fim
de
criar
um
componente
de
serviço e este realize funções para outras aplicações
[Mehta, 2002].
•
Componentes do Domínio: também chamados de componentes
de
negócio,
são
os
componentes
mais
difíceis
de
se
projetar e construir. Esses componentes necessitam de um
alto conhecimento do domínio para sua construção, a fim
de permitirem uma maior reutilização no desenvolvimento
das aplicações.
Considerando todos os aspectos aqui mencionados, a definição
de
Sametinger
satisfatória,
a
[1997]
fim
de
apresenta-se
estabelecer
o
que
suficientemente
vem
a
ser
um
14
Capítulo 2 – Engenharia de Software Baseada em Componentes
componente de software. Esta definição é a que será utilizada
como base no decorrer deste trabalho.
“Componentes
claramente
reutilizáveis
identificáveis,
são
que
artefatos
descrevem
autocontidos,
ou
realizam
uma
função específica e têm interfaces claras em conformidade com
um
dado
modelo
de
arquitetura
de
software,
documentação
apropriada e um grau de reutilização definido.”
Ser
autocontido
significa
que
a
função
que
o
componente
desempenha deve ser realizada por ele, de forma completa. Um
componente
deve,
também,
ser
claramente
identificável,
de
forma que possa ser encontrado de maneira facilitada. Este
atributo,
inclusive,
vem
sendo
alvo
de
inúmeras
pesquisas
[Werner, 2000a], [Yunwen, 2002], [Elias, 2002].
Um determinado componente não é completamente independente
dos outros componentes e do ambiente. O que determina como se
dá esta dependência do componente, em relação aos demais e ao
ambiente que o cerca, são suas interfaces. As interfaces de um
componente
determinam
como
este
componente
pode
ser
reutilizado e interconectado com outros componentes.
Szyperski [1998] define uma interface como um conjunto de
assinaturas
cliente.
de
operações
Segundo
Councill
que
podem
[2001],
ser
a
invocadas
interface
por
descreve
um
o
comportamento de um componente, que é obtido por considerar
somente as interações de suas interfaces e por ocultar todas
as demais interações.
Ainda conforme Councill, existem dois tipos de interfaces:
providas e requisitadas. Um componente suporta uma interface
provida
se
contém
definidas
pela
necessita
de
interação
definida
a
implementação
interface.
uma
Por
interface
na
de
outro
todas
lado,
requisitada
interface
e
espera
elemento de software suporte essa interface.
as
um
se
que
operações
componente
solicita
algum
uma
outro
15
Capítulo 2 – Engenharia de Software Baseada em Componentes
Nestes dois casos, a conexão entre os componentes é realizada
através
de
suas
interfaces,
de
maneira
direta,
sendo
as
próprias interfaces dos componentes o elemento de conexão dos
mesmos. Porém, existem casos em que esta conexão não pode ser
realizada de forma direta, sendo necessária a utilização de um
outro
esta
componente,
conexão,
projetado
denominado
exclusivamente
por
alguns
para
intermediar
autores
de
conector
[Wills, 2001].
A documentação é também indispensável para a reutilização.
Esta
deve
componente,
ser
suficiente
avaliar
sua
para
que
se
adequabilidade
possa
para
recuperar
um
contexto
da
o
reutilização, fazer adaptações (se for o caso) e integrar o
componente ao seu novo ambiente. Outro conceito importante é o
que
os
pesquisadores
chamam
de
“grau
de
reutilização”
do
componente. O grau de reutilização contém informações, tais
como: quantas vezes e onde o componente foi reutilizado, quem
é
responsável
pela
manutenção
do
componente
e
quem
é
o
proprietário [Sametinger, 1997].
2.4.2 Componentes e Objetos
Segundo [Weinreich, 2001], a engenharia de software baseada em
componentes
é
considerada
o
passo
seguinte
à
orientação
a
objetos. Ainda conforme o autor, não são surpreendentes os
fatos
de
os
componentes
serem
geralmente
relacionados
a
objetos e, em alguns casos, o termo ser simplesmente utilizado
como
um
sinônimo
para
objeto.
Entretanto,
os
conceitos
de
componentes e objetos são independentes, embora muitos modelos
de componentes sejam baseados em objetos.
Objetos
são
comportamento
entidades
e
que
possuem
encapsulam
um
um
estado
identificador
e
um
único.
O
comportamento e a estrutura dos objetos são definidos através
de
suas
classes.
Uma
classe
serve
para
vários
propósitos.
Inicialmente, a mesma implementa o conceito de Tipo Abstrato
de Dados (TAD) e provê uma descrição abstrata do comportamento
16
Capítulo 2 – Engenharia de Software Baseada em Componentes
dos seus objetos. Em seguida, uma classe provê a implementação
do comportamento dos objetos. Por último, é utilizada para
criar objetos, isto é, instâncias dessas classes [Weinreich,
2001].
Atualmente, a maioria dos modelos de componentes são baseados
no paradigma da orientação a objetos. A premissa básica da
orientação a objetos é construir programas a partir de um
conjunto de objetos. Este processo não muda com as abordagens
de
desenvolvimento
baseado
em
componentes.
Componentes
são
similares às classes. Assim como as classes, os componentes
definem
o
comportamento
e
a
criação
dos
objetos.
Objetos
criados através de componentes são chamados de instâncias de
componentes.
Ambos,
implementação
componentes
através
de
e
classes,
descrições
realizam
de
essa
comportamentos
abstratos, chamados interfaces [Weinreich, 2001].
Assim como as classes, a implementação de um componente é
geralmente
forma
oculta
e,
binária.
em
alguns
Internamente,
casos,
um
somente
avaliada
na
pode
ser
componente
implementado por uma simples classe, por diversas classes ou
através
de
procedimentos
programação
não
tradicionais
orientada
a
objetos.
em
uma
Por
linguagem
último,
a
de
mais
importante distinção é que os componentes de software estão em
conformidade
com
um
padrão
definido
através
do
modelo
de
componentes.
2.4.3 Modelo de Componentes
Segundo [Weinreich, 2001], um modelo de componentes define um
conjunto
de
padrões
interoperabilidade,
para
customização,
implementação,
composição
e
nomeação,
evolução
dos
componentes.
Councill [2001] define o modo de operação de um modelo de
componentes através de duas fases. Na primeira fase, o modelo
de componentes define como construir um componente de maneira
individual. Por exemplo, o Microsoft Component Object Model
17
Capítulo 2 – Engenharia de Software Baseada em Componentes
(COM)
requer
que
cada
componente
COM
possua
uma
interface
IUnKnown. Na fase subseqüente, um modelo de componentes pode
determinar um comportamento global sobre como um conjunto de
componentes
pode
interagir
e
se
comunicar
em
um
sistema
baseado em componentes.
Atualmente,
existem
diversos
modelos
de
componentes
disponíveis. Dentre estes modelos, vêm obtendo grande destaque
o OMG Corba Component Model (CCM) [OMG, 2002], o Microsoft
DCOM/COM+ [Microsoft, 2002] e, os Sun Microsystem JavaBeans e
Enterprise JavaBeans [Sun, 2002].
2.4.3.1 Elementos de um Modelo de Componentes
Dentro
do
podem
ser
composição
mercado
de
componentes
independentemente
através
de
de
software,
implantados
componentes
componentes
e
adquiridos
sujeitos
de
à
terceiros.
Assim, o mercado de componentes necessita de padrões. Padrões
para comunicação e intercâmbio de dados entre componentes de
diferentes propósitos são necessários.
Segundo [Weinreich, 2001], os elementos básicos de um modelo
de componentes são padrões para: interfaces, nomeação, meta
dados,
customização,
composição,
evolução
e
implantação.
A
Tabela 1 [Weinreich, 2001] mostra esses elementos.
Tabela 1 - Elementos de um Modelo de Componentes.
Padrões para
Interfaces
Descrição
Especificação de comportamento
dos
componentes
e
de
suas
únicos
para
propriedades.
Nomeação
Nomes
globais
interfaces e componentes.
Meta dados
Informações
componentes,
sobre
as
interfaces
seus relacionamentos.
os
e
Capítulo 2 – Engenharia de Software Baseada em Componentes
18
Interoperabilidade
de
Comunicação
dados
e
intercâmbio
entre
componentes
diferentes
de
fornecedores,
implementados
em
diferentes
linguagens.
Customização
Interfaces
e
ferramentas
para
customizar componentes.
Composição
Interfaces
e
regras
para
combinar componentes a fim de
criar grandes estruturas.
Suporte a Evolução
Regras
e
serviços
substituir
para
componentes
ou
interfaces por novas versões.
Empacotamento e Implantação
Empacotamento da Implementação
e
recursos
instalar
necessários
e
para
configurar
um
componente.
Um modelo de componentes pode ter padrões especializados para
descrever características específicas do domínio, necessárias
para
determinadas
componentes
dentro
aplicações.
de
Por
domínios
exemplo,
com
a
composição
atividades
de
concorrentes
necessita de padrões apropriados para tratamento de Threads e
mecanismos de sincronização. Um segundo exemplo pode ser um
sistema de processamento distribuído que necessita de padrões
para invocação remota de métodos e aspectos relacionados à
segurança [Weinreich, 2001].
2.4.3.2
Implementação
de
um
Modelo
de
Componentes
Um
importante
padronização
componentes.
elemento
do
de
ambiente
um
de
modelo
de
suporte
componentes
à
execução
é
a
dos
19
Capítulo 2 – Engenharia de Software Baseada em Componentes
A implementação de um modelo de componentes é um dedicado
conjunto
de
elementos
de
software
executáveis,
necessários
para suportar a execução dos componentes conforme um modelo de
componentes previamente definido [Councill, 2001].
O
Common
Object
Request
Broker
Architecture
(CORBA),
padronizado pelo Object Management Group (OMG), por exemplo,
funciona
em
um
sistema
aberto
de
processamento
distribuído
utilizando Object Request Broker (ORB); por outro lado, as
aplicações de software executam em sistemas operacionais como
o Windows ou UNIX. CORBA é um padrão aberto, através do qual o
OMG promove um padrão, mas não é um produtor de componentes
que provê a implementação de um modelo de componentes. Quando
um produtor de uma implementação do modelo de componentes é
também o projetista de um modelo de componentes, o modelo de
componentes pode se tornar proprietário, isto é, somente uma
implementação do modelo de componentes torna-se disponível.
2.4.4
Métodos
para
Desenvolvimento
de
Componentes
Como todo processo de desenvolvimento de software, é preciso
prover
uma
componentes,
controlada,
sistemática
devendo
para
ser
para
o
ser
cuidadosamente
efetiva.
desenvolvimento
Assim,
é
baseado
em
planejada
e
necessária
uma
abordagem que enfatize a reutilização em todas as etapas do
desenvolvimento, não envolvendo apenas código [Werner, 2000].
Segundo Krueger [1992], o processo de desenvolvimento pode
ser dividido em duas etapas: desenvolvimento para reutilização
e desenvolvimento com reutilização. Colocando esta abordagem
sobre o prisma do desenvolvimento baseado em componentes, esta
nomenclatura
poderia
ser
mudada
e,
assim,
tem-se
a
mesma
divisão: desenvolvimento de componentes e desenvolvimento com
componentes.
Ao considerar componentes muito mais do que somente código,
uma abordagem de desenvolvimento de componentes pode ser vista
20
Capítulo 2 – Engenharia de Software Baseada em Componentes
como um processo de engenharia de domínio completo, onde a
preocupação, além de ser com a disponibilização de componentes
em
todos
os
níveis
de
abstração,
não
é
com
uma
única
aplicação, mas com uma família de aplicações. Assim, o grau de
reutilização de um determinado componente será muito maior e
seu
entendimento
também,
uma
vez
que
este
componente
será
disponibilizado tanto para especificação quanto para código.
Por outro lado, o desenvolvimento com componentes deve ser
visto como um processo de desenvolvimento de aplicações, onde
a reutilização de componentes deve estar presente em todas as
fases.
Ainda
por
ser
uma
abordagem
nova
para
a
engenharia
de
software, o número de métodos projetados especificamente para
DBC ainda é limitado. Alguns destes métodos são extensões de
métodos
já
existentes,
em
particular,
métodos
de
desenvolvimento orientado a objetos.
Dentre estes métodos, pode-se destacar o Catalysis [D’Souza,
1999], o Rational Unified Process (RUP) [Jacobson, 2001], o
Select
Perspective
[Cheesman,
descrição
2000].
desses
[Perspective,
A
seção
métodos.
2000]
seguinte
O
e
o
UML
apresenta
critério
Components
uma
selecionado
breve
para
apresentação dos métodos foi puramente de ordem alfabética,
não considerando demais características.
2.4.4.1 Catalysis
Na
tentativa
software
de
melhorar
orientado
a
o
processo
objetos,
de
desenvolvimento
pesquisadores
de
desenvolveram
vários métodos, destacando-se o OMT [Rumbaugh, 1991] e o de
Booch [Booch, 1994]. Esses métodos, embora tenham contribuído
continuamente
para
produzir
apresentavam
problemas
de
software
com
rastreamento
melhor
qualidade,
de
requisitos,
semântica para verificar consistência, níveis de granularidade
e refinamento e distinção entre modelo do domínio, modelo do
sistema
e
arquitetura
[D’Souza,
1999].
A
evolução
desses
21
Capítulo 2 – Engenharia de Software Baseada em Componentes
métodos
resultou
construir
em
um
Sistemas
método
integrado
Distribuídos
de
técnicas
Orientado
a
para
Objetos,
denominado Catalysis [D’Souza, 1999].
Catalysis
é
Universidade
uma
de
iniciativa
Brighton,
de
pesquisa
Inglaterra,
por
desenvolvida
D’Souza
e
na
Wills
[D’Souza, 1999]. Conforme os autores, o método Catalysis é um
método
de
desenvolvimento
baseado
em
componentes
completo,
cobrindo todas as fases do desenvolvimento de um componente a
ser utilizado no desenvolvimento de uma dada aplicação, desde
a especificação até sua implementação.
Catalysis é baseado em um conjunto de princípios [D’Souza,
1999]
para
o
princípios,
desenvolvimento
pode-se
refinamento,
de
destacar:
componentes
software.
a
“plug-in”
Dentre
esses
abstração,
precisão,
e
leis
algumas
de
reutilização.
O princípio abstração orienta o desenvolvedor na busca de
aspectos essenciais do sistema, dispensando detalhes que não
são
relevantes
para
o
contexto
do
sistema.
O
princípio
precisão tem como objetivo descobrir erros e inconsistências
na
modelagem.
fase
para
Refinamentos
outra
são
sucessivos
aplicados,
de
transições
buscando-se
obter
de
uma
artefatos
cada vez mais precisos e propícios à reutilização. O princípio
componentes “plug-in” suporta a reutilização de componentes, a
fim
de
construir
outros.
Por
fim,
a
principal
lei
de
reutilização do método Catalysis é não reutilizar código sem
reutilizar modelos de especificações desses códigos.
O
processo
Catalysis
é
de
desenvolvimento
dividido
Especificação
dos
em
três
de
software
níveis:
Componentes
e
Domínio
Projeto
utilizando
do
Problema,
Interno
dos
Componentes, como mostra a Figura 1. Estes níveis correspondem
às
fases
tradicionais
elicitação,
Assim
análise
como
software,
em
no
e
do
ciclo
modelagem,
ciclo
Catalysis,
e
tradicional
pode-se
de
vida
projeto
de
retornar
do
dos
software:
requisitos.
desenvolvimento
ao
nível
de
anterior
22
Capítulo 2 – Engenharia de Software Baseada em Componentes
para remover inconsistências com o domínio do problema e com a
especificação [D’Souza, 1999].
Identificar o problema
Estabelece a terminologia de Domínio do
Problema
Entende os processos de negócios e
colaborações
Domínio do
Problema
Especificar o sistema
Define responsabilidades e escopo dos
componentes
Especifica as operações desejadas dos
componentes e define suas interfaces
Especificação dos
Componentes
Especificar o sistema
Define a arquitetura interna dos
componentes
Define o comportamento interno dos
componentes e suas colaborações
Projeto Interno
dos Componentes
Figura 1 – Processo de Desenvolvimento de Software em Catalysis.
No nível Domínio do Problema é dada ênfase no entendimento do
problema, especificando-se “o quê” o sistema deve atender para
solucionar
o
Componentes,
problema.
é
descrito
Em
seguida,
o
na
comportamento
forma não ambígua e, no último nível,
Especificação
do
sistema
de
dos
uma
Projeto Interno dos
Componentes, define-se como serão implementados os requisitos
especificados para os componentes [D’Souza, 1999].
2.4.4.2 Rational Unified Process (RUP)
O Rational Unified Process [Jacobson, 2001] é o método de
engenharia
de
método
interativo,
é
software
da
Rational
orientado
a
Software
Corporation.
O
controlado
e
objetos,
suportado através de ferramentas, podendo ser aplicado a todo
tipo de projeto de desenvolvimento de software. O RUP alcançou
grande popularidade na indústria de software, especialmente,
entre usuários das ferramentas Rational que oferecem suporte à
modelagem e à implementação.
Conforme os autores [Jacobson, 2001], o RUP representa mais
do
que
um
simples
processo
de
desenvolvimento
de
software
23
Capítulo 2 – Engenharia de Software Baseada em Componentes
capaz de transformar requisitos do usuário em um sistema de
software. Ele é um framework de processo genérico, capaz de
ser especializado para diferentes áreas de aplicação, tipos de
organização, níveis de competência e tamanhos de projeto.
O processo de desenvolvimento utilizando o RUP é dividido em
quatro fases: concepção, elaboração, construção e transição, e
um número arbitrário de interações. Adicionalmente, o RUP é
estruturado
através
de
um
conjunto
de
workflows,
os
quais
agrupam diferentes tipos de atividades.
O RUP não introduz nenhum novo conceito de modelagem, pois o
mesmo
se
apóia
na
utilização
da
Unified
Modeling
Language
(UML) para estas tarefas, porém introduz novos conceitos, como
artefatos,
atividades
e
workflow.
Esses
conceitos
capturam
abstrações, como: “quem” deve fazer “o quê”, “como” e “quando”
[Boertin, 2001].
O
conceito
chave
do
RUP
é
a
definição
de
atividades
(workflows) realizadas do começo ao fim do ciclo de vida de
desenvolvimento, como a identificação dos requisitos, análise,
projeto, implementação e teste. No RUP, o suporte à abordagem
de
DBC
é
encorajado,
porém
esse
suporte
ainda
é
muito
influenciado e restringido pela notação UML. A visão do método
no
conceito
voltada
de
mais
ao
componente
nível
programação,
baseando-se
implantação.
Isto
componente
como
é
ainda
físico
em
não
muito
de
pela
trivial,
limitada,
pacotes
componentes
comprovado
“uma
é
UML
de
e
definição
quase
sendo
código
de
diagramas
do
de
RUP
de
independente,
e
substituível parte de um sistema que realiza uma função clara
no contexto de uma arquitetura bem definida”. RUP utiliza o
conceito da UML de subsistema para a proposta de modelagem dos
componentes,
mas
não
detalha
como
esse
processo
deve
ser
realizado [Stojanovic, 2001].
Uma das principais vantagens do RUP é prover uma oportunidade
para
o
desenvolvimento
de
sistemas,
de
forma
interativa
e
24
Capítulo 2 – Engenharia de Software Baseada em Componentes
incremental, o que é visto, atualmente, como uma das melhores
práticas de desenvolvimento [Jacobson, 2001].
2.4.4.3 Select Perspective
O método Select Perspective foi originalmente criado em 19941995,
através
da
combinação
do
Object
Modelling
Technique
(OMT) [Rumbaugh, 1991] e do método Use Case Driven Objectory
[Jacobson, 1992], baseando-se em princípios
Rapid Application
Development (RAD). Originalmente, o Select suportava somente a
modelagem
de
negócio,
casos
de
uso,
classes,
modelagem
de
interação dos objetos e modelagem de estados. Após o crescente
interesse
e
importância
do
paradigma
de
desenvolvimento
baseado em componentes, o método foi estendido a fim de prover
mecanismos para modelagem de componentes [Perspective, 2000],
[Boertin, 2001], [Stojanovic, 2001].
Além
da
modelagem
de
componentes,
o
Select
Perspective
utiliza a notação adotada da metodologia CSC Catalyst [CSC,
1995]
para
modelagem
do
negócio,
mantendo
o
link
entre
processos de negócios e classes e casos de uso associados.
Além
disso,
(ERD)
para
diagramas
o
método
modelagem
UML
Perspective
e
utiliza
dos
modelos
trata
o
Entity-Relationship
dados
e
provê
relacionais
conceito
de
de
Diagrams
mapeamento
dados.
componente,
O
entre
Select
utilizando
a
definição de pacote da UML, como [OMG, 1999] “um mecanismo de
proposta
geral
para
organizar
elementos
em
grupos”.
Dois
stereotypes básicos para pacotes são distinguidos: pacotes de
serviços, utilizados na modelagem de componentes orientado ao
negócio, e pacote de componentes, utilizado na implementação
de componentes e sistemas. Um pacote de serviço contém classes
que possuem um alto nível de interdependência e servem como
uma
proposta
comum
de
oferecer
um
consistente
conjunto
de
serviços. Por outro lado, um pacote de componentes representa
um componente executável, isto é, o código fonte [Perspective,
2000], [Stojanovic, 2001].
25
Capítulo 2 – Engenharia de Software Baseada em Componentes
2.4.4.4 UML Components
Segundo Cheesman [2000], o método UML Components representa um
processo
para
a
especificação
de
software
baseado
em
componentes. Neste processo, os sistemas são estruturados em
quatro camadas distintas: interface com o usuário, comunicação
com o usuário, serviços de sistemas e serviços do negócio. O
relacionamento entre estas camadas representa a arquitetura do
sistema.
O UML Components propõe a utilização da UML para modelar
todas
as
fases
componentes,
do
desenvolvimento
compreendendo
as
de
sistemas
atividades
de
baseado
definição
em
dos
requisitos, identificação e descrição das interfaces entre os
componentes,
especificação,
implementação
e
montagem
dos
componentes. Além disso, os autores tiveram a preocupação de
oferecer uma solução sem especificar uma particular plataforma
de desenvolvimento.
Outros métodos de DBC, não abordados neste trabalho, também
vêm sendo alvos de pesquisas e sucessivos refinamentos. Dentre
estes métodos, encontram-se o CADA [2000], o COmponent-based
METhodology (COMET) [COMET, 1997] e o KobrA [Kobra, 2000].
2.5 Repositório de Componentes
Antes
dos
engenheiros
de
software
obterem
as
vantagens
inerentes à reutilização, eles devem possuir mecanismos hábeis
a fim de facilitar a busca e o armazenamento dos componentes.
Nesse
contexto,
encaixa-se
a
idéia
de
repositório
de
componentes. Um repositório de componentes pode ser entendido
como um sistema de informação que auxilia os programadores na
localização
Esses
dos
sistemas
componentes
componentes
possuem
três
reutilizáveis,
interface para interação.
reutilizáveis
um
conotações:
mecanismo
[Yunwen,
uma
de
2001].
coleção
busca
e
de
uma
26
Capítulo 2 – Engenharia de Software Baseada em Componentes
Sametinger [1997] conceitua repositório de componentes como
sendo uma base preparada para o armazenamento e a recuperação
de componentes. Para que esta recuperação venha a se tornar
efetiva, o autor ressalta a importância do armazenamento de
informações
adicionais
relativas
ao
componente.
Assim,
a
chance que um desenvolvedor tem de reutilizar um determinado
componente,
ao
invés
de
desenvolver
um
novo,
depende
da
disponibilidade do componente em um repositório, de forma que
este possa ser facilmente localizado e recuperado.
Ainda segundo Sametinger, existem três tipos de repositórios,
a saber:
•
Repositórios Locais: armazenam componentes de propósito
geral em um único repositório;
•
Repositórios
específicos
componentes
a
específicos,
um
com
domínio:
escopo
armazenam
bem
definido,
podendo prover componentes alternativos para as mesmas
tarefas;
•
Repositórios
de
referências:
auxiliam
na
busca
por
componentes em outros repositórios, funcionando como uma
espécie de páginas amarelas.
De
acordo
com
centralizados
Seacord
que
[1999],
os
armazenam
repositórios
componentes
locais
e
genéricos,
historicamente, falharam, principalmente por serem projetados
como
sistemas
centralizados.
verifica
a
viabilidade
traders,
brokers,
de
Ainda
neste
utilização
serviços
de
de
localização
trabalho,
o
autor
tecnologias,
e
como
mecanismos
de
buscas, aliados a introspecção de código, a fim de criar um
repositório de componentes distribuído e acessível através da
Internet. Esse repositório recebeu a denominação de Agora.
Mesmo
sendo
específicos,
considerado
adotando
os
uma
evolução
princípios
de
dos
repositórios
repositórios
de
referências, o sistema Agora apresentou muitas limitações. Por
basear-se
num
mecanismo
de
busca
utilizando
introspecção
27
Capítulo 2 – Engenharia de Software Baseada em Componentes
computacional,
o
semanticamente
sistema
quanto
apresentou
na
limitações
abrangência,
uma
vez
tanto
que
são
recuperados apenas componentes binários.
Atualmente, um novo tipo de repositório vem sendo pesquisado,
o
sistema
2002].
Em
de
repositórios
contraste
convencional,
onde
aos
os
de
componentes
mecanismos
usuários,
de
ativos
acesso
a
[Yunwen,
informação
explicitamente,
iniciam
o
processo de busca à informação, os mecanismos de entrega ativa
apresentam
informações
relevantes
para
os
usuários
sem
que
estes tenham feito requisições explícitas [Fischer, 1993].
No
sistema
sistema
CodeBroker
realiza
desenvolvido
inferências
sobre
o
em
[Yunwen,
código
fonte
2001],
ainda
o
em
desenvolvimento, buscando componentes que possam realizar as
mesmas
tarefas.
aplicação,
estas
o
Assim,
sistema
tarefas.
Essa
enquanto
apresenta
o
desenvolvedor
possíveis
abordagem
de
codifica
componentes
repositório
de
a
para
sistemas
ativos, embora interessante, apresenta alguns problemas. No
modelo atual são feitas inferências a partir da assinatura dos
métodos e de comentários JavaDoc. O grande problema é que os
componentes
são
representando
vistos
modelos
de
apenas
alto
como
nível,
código
fonte,
restringindo
não
assim,
o
grau de reutilização.
Este tipo de repositório parece bastante promissor, porém,
uma série de refinamentos ainda deve ser realizada, a fim de
oferecer um melhor rastreamento do conceito de componentes,
não apenas como código fonte.
2.6 Commercial-Off-The-Shelf (COTS)
O
crescimento
em
tamanho
e
complexidade
dos
sistemas
de
software aumentou o interesse no desenvolvimento de sistemas
baseados em componentes reutilizáveis adquiridos de terceiros,
conhecidos na literatura como Commercial-Off-The-Shelf (COTS).
Segundo
comunidade
Heineman
de
[2001a],
engenharia
de
atualmente,
o
software
que
é
consenso
na
comprar
um
28
Capítulo 2 – Engenharia de Software Baseada em Componentes
componente é melhor do que desenvolvê-lo. A determinação de
“melhor”
é
baseada
na
concepção
de
que
os
custos
para
desenvolver, testar e manter um componente excedem os custos
de desenvolver um novo.
Oberndorf [1997] define COTS como produtos que são vendidos,
alugados ou licenciados para o público; isto é, usualmente
avaliados
sem
código
fonte,
ou
seja,
suportados
e
desenvolvidos pelos vendedores, os quais possuem os direitos
legais
de
abordagem
propriedade
são
as
intelectual.
reduções
de
Os
benefícios
custos
e
do
desta
tempo
de
desenvolvimento. A natureza de COTS sugere que o modelo de
desenvolvimento de software baseado em componentes deve ser
diferente
do
resultado,
convencional
uma
modelo
significante
de
mudança
desenvolvimento.
tem
sido
Como
observada:
do
desenvolvimento convencional de software para uma abordagem
voltada à obtenção de componentes [Tran, 1997]. Em geral, o
ciclo
de
vida
de
sistemas
baseados
em
COTS
consiste
das
seguintes fases: identificação, avaliação, seleção, integração
e atualização dos componentes [Oberndorf, 1997].
A
abordagem
de
desenvolvimento
utilização
de
de
software
componentes
tem-se
mostrado
COTS
no
bastante
promissora a fim de melhorar a qualidade e a produtividade
[Hissam,
2002].
Entretanto,
a
utilização
de
software
COTS
introduz alguns problemas e riscos, inerentes à dificuldade de
seleção
adequada
dos
componentes
e
análise
de
requisitos
[Lipson, 2001]. Por exemplo, em um intensivo sistema com COTS,
muitos
produtos
de
diferentes
vendedores
têm
que
ser
integrados e adaptados para prover uma completa funcionalidade
do
sistema.
Em
desenvolvidos
em
fornecedores.
Além
limitado
ao
muitos
casos,
tempos
disso,
projeto
as
interno
estes
produtos
diferentes,
empresas
do
por
possuem
produto
e
a
COTS
são
diferentes
acesso
opções
muito
pré-
definidas de customização de seu comportamento [Alves, 2001].
29
Capítulo 2 – Engenharia de Software Baseada em Componentes
A grande maioria dos métodos de DBC, incluindo os mencionados
neste trabalho, ainda não oferece suporte ao conceito de COTS.
Assim, ainda existe um gap nestes métodos, uma vez que se
considera apenas o processo de criação dos componentes e não a
reutilização com componentes adquiridos de terceiros.
2.7 Tópicos de Pesquisa em DBC
Existem
ainda
pesquisa
em
na
DBC
literatura
que
estão
diversos
começando
outros
tópicos
de
ser
explorados
e
a
evidenciados. Apesar das pesquisas ainda estarem incipientes,
elas se mostram bastante promissoras. Dentre elas, destacamse: medidas e métricas para componentes de software, agentes
de
software
como
a
próxima
geração
de
componentes
e
a
Programação Orientada a Aspectos.
2.7.1 Medidas e Métricas para Componentes de
Software
Criar produtos de qualidade requer, cada vez mais, um controle
e
gerenciamento
sistemático
através
de
todo
o
ciclo
da
engenharia de software baseada em componentes. Métricas podem
ajudar a estimar, planejar e identificar áreas para melhorar a
qualidade,
reduzir
custos,
otimizar
o
gerenciamento
dos
projetos e facilitar o gerenciamento de riscos.
Poulin
[2001]
utilizadas
nos
define
projetos
algumas
métricas
envolvendo
que
engenharia
podem
ser
de
software
quantidade
de
produtos
tempo.
métrica
baseada em componentes. Dentre estas, destacam-se:
•
Produtividade:
entregue
por
representa
unidade
a
de
A
de
produtividade pode ser calculada através do total de
horas de desenvolvimento por projeto/total de linhas de
código dos componentes (SLOC);
•
Grau de reutilização: representa as linhas de códigos
propícias à reutilização pelo total de linhas de código
30
Capítulo 2 – Engenharia de Software Baseada em Componentes
do
componente.
A
métrica
correspondente
ao
grau
de
reutilização pode ser calculada através das linhas de
código reutilizadas/total de linhas de código;
•
Performance:
cada
vez
mais
a
performance
vem
sendo
utilizada como um requisito não funcional necessário em
muitas
aplicações.
distribuídos,
este
Tratando-se
requisito
de
componentes
torna-se
ainda
mais
importante. Assim, o tempo de resposta das operações
disponibilizadas pelos componentes torna-se um atributo
essencial.
Além destas métricas aqui mencionadas, um projeto envolvendo
engenharia de software baseada em componentes pode utilizar as
seguintes
informações
como
medidas
adicionais:
linhas
de
código por componente, tempo de desenvolvimento, classificação
do componente (componente de negócio, componente GUI), custos
e total de defeitos encontrados [Poulin, 2001].
2.7.2
Agentes
de
Software
como
a
próxima
comércio
eletrônico
geração de Componentes
O
crescente
ofereceu
volume
uma
das
grande
atividades
motivação
e
de
oportunidade
para
as
atividades de busca, análise e negociação da informação. Estas
novas classes de aplicações demandam flexibilidade e soluções
inteligentes.
agentes
de
componentes,
Neste
contexto
software.
que
está
Agentes
oferecem
uma
são
inserida
tipos
a
tecnologia
de
especializados
de
flexibilidade
maior
que
os
componentes de software tradicionais [Griss, 2001a].
A fim de integrar processos de negócios entre companhias, as
próximas
gerações
de
aplicações
de
comércio
eletrônico
necessitam ser mais robustas, complexas e flexíveis [Sharman,
1999]. Como estas aplicações serão desenvolvidas utilizando
componentes
escritos
por
diferentes
desenvolvedores
em
31
Capítulo 2 – Engenharia de Software Baseada em Componentes
períodos diferentes, os desenvolvedores necessitam ter modos
poderosos
para
construir
sistemas
flexíveis
rapidamente
e
oferecer serviços mais atrativos para os usuários.
O desenvolvimento de software orientado a agentes estende o
convencional
desenvolvimento
baseado
em
componentes,
promovendo sistemas baseados em componentes mais flexíveis,
com menor tempo de projeto e implementação e diminuindo o
acoplamento entre agentes [Griss, 2001]. Do mesmo modo que
modelos,
colaborações,
padrões
e
programação
orientada
a
aspectos auxiliam na construção de componentes mais robustos e
flexíveis, as mesmas técnicas podem ser aplicadas para agentes
e sistemas baseados em agentes [Griss, 2001].
Assim, pesquisas [Chen, 2000], [Griss, 2000], [Griss, 2002],
[Griss,
2002a]
estão
sendo
realizadas
na
área
de
comércio
eletrônico, direcionadas em simulação, comunicação de agentes,
dispositivos móveis e sistemas multi-agentes. Estas pesquisas
estão interessadas em questões relacionadas a como os agentes
são definidos e construídos, como ocorre a comunicação entre
estes e como a colaboração entre grupos de agentes pode ser
estabelecida
combinados
e
a
significantes,
controlada.
workflows,
além
a
dos
já
Estes
fim
agentes
de
estão
oferecer
conhecidos
sendo
benefícios
relacionados
a
componentes.
2.7.3 Programação Orientada a Aspectos
A Programação Orientada a Objetos (POO) foi apresentada como
um
paradigma
que
poderia,
fundamentalmente,
auxiliar
a
engenharia de software, uma vez que um determinado programa
pode resolver um problema do mundo real através de um conjunto
de abstrações bem definidas, cada uma simulando um fenômeno
específico
Entretanto,
técnicas
da
de
um
problema
existem
alguns
orientação
a
capturar [Kiczales, 1997].
do
mundo
problemas
objetos
não
real
de
[Kienzle,
programação
são
2002].
que
suficientes
as
para
32
Capítulo 2 – Engenharia de Software Baseada em Componentes
Além disso, o paradigma da orientação a objetos tem algumas
limitações, como o entrelaçamento e o espalhamento de código
com diferentes propósitos, por exemplo, o entrelaçamento de
código de negócio com código de apresentação, e o espalhamento
de código de acesso a dados em diversos módulos do sistema
[Kiczales, 2001].
Assim,
extensões
do
paradigma
programação
orientada
a
programação
adaptativa
orientado
aspectos
a
objetos,
[Kiczales,
[Lieberherr,
como
1997]
1994],
vêm
e
sendo
pesquisadas, a fim de solucionar as limitações do paradigma
orientado a objetos.
A Programação Orientada a Aspectos (POA) [Kiczales, 1997],
[Elrad, 2001], [Duclos, 2002] é uma destas técnicas que vêm
obtendo grande destaque. POA foi proposta como uma técnica
para melhorar a separação de conceitos no desenvolvimento de
software, evitando o entrelaçamento e o espalhamento de código
com
diferentes
modularidade
propósitos.
separando
Desta
código
forma,
que
POA
aumenta
implementa
a
funções
específicas, que afetam diferentes partes do sistema, chamadas
preocupações
ortogonais
(crosscutting
concern).
Exemplos
destas preocupações ortogonais são persistência, distribuição,
controle
de
concorrência
e
tratamento
de
exceções
[Soares,
2002].
Trazendo os princípios de POA para o desenvolvimento baseado
em componentes, tem-se que um sistema pode ser separado em
dois segmentos: requisitos funcionais e não-funcionais. Dos
requisitos
funcionais
resulta
um
conjunto
de
componentes,
expressos em uma linguagem de programação, como, por exemplo,
Java [Horstmann, 2001]. Os requisitos não-funcionais resultam
um
conjunto
afetam
o
utilização
manipulados
de
aspectos
comportamento
de
POA,
sem
os
relacionados
do
sistema.
requisitos
causar
impacto
não
no
às
propriedades
Deste
modo,
funcionais
código
com
podem
de
que
a
ser
negócio
(requisitos funcionais), uma vez que estes códigos não estão
33
Capítulo 2 – Engenharia de Software Baseada em Componentes
entrelaçados
Assim,
e
POA
espalhados
possibilita
em
diversas
o
partes
desenvolvimento
do
de
sistema.
sistemas
utilizando aspectos, o que inclui refinamentos das técnicas de
DBC, como isolamento, composição e reutilização de código dos
aspectos e introduz velhos problemas de DBC, como a busca de
aspectos em grandes repositórios.
2.8 Resumo
Este
capítulo
software
apresentou
baseada
em
uma
visão
geral
componentes,
da
engenharia
discutindo,
de
de
forma
detalhada, desde os princípios de reutilização até as duas
etapas que compreendem o modelo de processo: a Engenharia de
Domínio
e
o
Desenvolvimento
introduziu
os
literatura
e
principais
os
Baseado
métodos
mecanismos
em
Componentes.
de
DBC
essenciais
no
Também
relatados
na
processo
de
engenharia de software baseada em componentes: a utilização de
um repositório para armazenamento e busca dos componentes e a
utilização de COTS. Por fim, foram relatados e discutidos os
principais
tópicos
de
pesquisa
que
estão
começando
a
ser
explorados e evidenciados na área de DBC. O capítulo seguinte
descreverá os Padrões de Software, que fazem parte do objetivo
deste
trabalho
e
que
possuem
como
distribuição e acesso a banco de dados.
base
os
padrões
para
Capítulo 3
Padrões de Software
3.1 Introdução
Segundo Gamma [1995], o conceito de padrões foi proposto pelo
arquiteto Alexander [1977], para construção de arquiteturas e
planejamento urbano. Na área de software, foram recentemente
popularizados
para
apoiar
uma
larga
variedade
de
domínios,
relacionados às atividades de desenvolvimento de projetos.
A utilização de padrões em sistemas complexos de software
permite
que
soluções,
previamente
testadas,
sejam
reutilizadas, tornando o sistema mais compreensível, flexível,
fácil de desenvolver e manter. O objetivo do uso de padrões de
software é a disseminação das soluções de desenvolvimento de
software já existentes [Johnson, 1992].
Gamma [1995] propõe o uso de padrões de projeto de software
como um novo mecanismo para expressar soluções na elaboração
de projetos orientados a objetos. Padrões de projeto fornecem
uma linguagem comum, que irá facilitar a comunicação entre
desenvolvedores e projetistas; os padrões também melhoram o
aprendizado
de
jovens
desenvolvedores,
incrementando
a
padronização do desenvolvimento, permitindo a construção de
software
reutilizável,
que
se
comporta
como
blocos
de
construção para sistemas mais complexos. Gamma apresenta os
conceitos básicos sobre os padrões, as formas para selecionálos e utilizá-los. Como estudo de caso, um editor de texto,
35
Capítulo 3 – Padrões de Software
denominado
Lexi,
foi
desenvolvido
para
solucionar
vários
problemas de projeto existentes, com o uso dos padrões. Seus
autores respondem de forma prática a questões do tipo: como
reconhecer um problema e como escolher e utilizar um padrão de
projeto.
É
também
projeto,
organizado
apresentado
segundo
um
dois
catálogo
de
padrões
de
critérios:
a)
propósito
-
indica o que o padrão de projeto faz; b) escopo - especifica
se
o
padrão
de
projeto
é
aplicável
a
classes
ou
objetos.
Quanto ao propósito, os padrões de projeto são divididos em
três categorias: criacionais, estruturais e comportamentais.
Padrões de projeto criacionais organizam o processo de criação
de
objetos.
composição
Padrões
de
comportamentais
de
classes
projeto
ou
estruturais
objetos.
caracterizam
as
demonstram
Padrões
formas
como
a
de
projeto
os
objetos
interagem entre si.
Em geral, um padrão é definido através de quatro elementos
essenciais [Gamma, 1995], [Yoder, 2002]:
•
nome: uma designação que descreve com propriedade um
problema de projeto, suas soluções e conseqüências em
uma palavra ou duas;
•
problema: descreve o problema e o contexto em que o
mesmo ocorre. Pode conter um conjunto de condições que
devem ser satisfeitas para a aplicação do padrão de
projeto;
•
solução:
descreve
necessários
para
os
elementos
a
construção
(classes
do
e
objetos)
projeto,
seus
relacionamentos, responsabilidades e colaborações. Esta
solução não é restrita a um caso em particular, e sim
genérica o suficiente para ser aplicada a diferentes
situações;
•
conseqüências: são os resultados, positivos e negativos,
ao
se
utilizar
padrões
de
projeto.
As
conseqüências
permitem analisar os custos e benefícios da aplicação de
um determinado padrão de projeto.
36
Capítulo 3 – Padrões de Software
No
projeto
Baseado
em
da
Abordagem
Componentes
de
Desenvolvimento
Distribuídos
são
de
Software
utilizados
padrões
para distribuição dos componentes e acesso à banco de dados
relacional. Estes padrões são apresentados a seguir.
3.2 Distributed Adapters Pattern (DAP)
O Distributed Adapters Pattern (DAP) [Alves, 2001], [Alves,
2001a] foi desenvolvido com a proposta de refinar as camadas
de
distribuição
atualmente,
é
numa
uma
arquitetura
combinação
do
distribuída.
Facade,
Adapter
O
e
DAP,
Factory
design patterns [Gamma, 1995].
O
DAP
é
um
comunicação
padrão
remota
que
entre
está
dois
inserido
no
componentes.
contexto
De
maneira
de
a
resolver esta tarefa, componentes em um cenário distribuído
comunicam-se com outros por meio de algum mecanismo interprocesso.
Os
componentes
podem
se
comunicar
entre
si
ou
delegar esta função a outros componentes.
A primeira alternativa requer menos componentes; isto conduz
a aplicações, onde o núcleo da funcionalidade dos componentes
é realizado através de tarefas de comunicação. Deste modo, as
aplicações dependem de um mecanismo particular de comunicação
e os componentes se tornam difíceis de serem reutilizados e
estendidos [Alves, 2001a].
A
segunda
alternativa
(DAP)
permite
obter
aplicações
modulares com um conjunto de componentes interoperáveis. Como
o
desenvolvimento
da
aplicação
é
mais
fácil
de
manter
e
estender, estes componentes podem ser facilmente reutilizados
em outras aplicações [Alves, 2001a].
Assim, o DAP oferece os seguintes benefícios [Alves, 2001]:
•
um componente pode acessar serviços remotos, oferecidos
por outros componentes;
•
os
componentes
são
independentes
de
Programming Interfaces (API) de comunicação;
Application
37
Capítulo 3 – Padrões de Software
•
as modificações no código dos componentes, para oferecer
suporte à comunicação, são minimizadas;
•
as mudanças no mecanismo de comunicação se tornam uma
tarefa facilitada, minimizando o impacto no código de
negócio.
A
técnica
adotada
funcionalidades
objetos
pelo
mencionadas
adaptadores,
desacoplamento
DAP,
dos
para
acima,
é
visando
componentes
oferecer
todas
introduzir
um
conseguir
dentro
de
um
uma
estas
par
de
melhor
arquitetura
distribuída. Os adaptadores, basicamente, encapsulam a API,
que é necessária para permitir o acesso distribuído ou remoto
para objetos de negócio. Deste modo, a camada de negócio de
uma aplicação torna-se independente em relação à camada de
distribuição e as mudanças nesta camada não causam impactos.
No padrão, existem dois tipos de adaptadores: Source Adapter
e
Target
Adapter.
Em
uma
interação
típica,
um
objeto
que
possua a interface do usuário em uma máquina solicita serviços
de um source adapter localizado na mesma máquina. O source
adapter, em seguida, solicita os serviços de um correspondente
target adapter, residido em uma máquina remota. Finalmente, o
target
adapter
solicita
serviços
de
um
objeto
Facade,
co-
localizado com o target adapter. A Figura 2 [Alves, 2001a]
mostra este exemplo.
Source
Adapter
<<Source>>
User Interface
Machine A
Target
Adapter
<<Target>>
Facade
Machine B
Figura 2 - Um exemplo do DAP.
Os Adaptadores Source e Adapter provêem um nível de abstração
maior que stubs e skeletons. Os adaptadores isolam a interface
38
Capítulo 3 – Padrões de Software
do usuário e o código de negócio da API de distribuição, visto
que os stubs e skeletons isolam a interface do usuário e o
código
de
negócio
da
implementação
dos
aspectos
de
distribuição, mas não da API de distribuição. Source Adapter
delega baixo nível de distribuição através do empacotamento
para os stubs, e os Target Adapter delegam esta questão para
os skeletons.
A Figura 3 [Alves, 2001] detalha a estrutura do DAP através
de um Diagrama de Classes.
Figura 3 - Estrutura do Padrão DAP.
As
classes
Source
e
Target
abstraem
os
componentes
de
negócio, conforme foi mencionado anteriormente. A interface
TargetInterface abstrai o comportamento da classe Target em um
cenário distribuído. De qualquer modo, esta interface e as
classes, Source e Target, não possuem código de comunicação.
Estes
três
elementos
constituem
uma
camada
padrão
de
independente
de
distribuição.
Os
principais
elementos
do
distribuição
são
SourceAdapter e TargetAdapter. Estes elementos estão ligados a
uma API específica de distribuição e encapsulam os detalhes de
39
Capítulo 3 – Padrões de Software
comunicação. SourceAdapter é um adaptador que isola a classe
Source do código de distribuição. Este reside na mesma máquina
que o Source e trabalha como um proxy para o TargetAdapter.
Este último reside em outra máquina, isolando a classe Target
do código de distribuição. Como SourceAdapter e TargetAdapter,
usualmente, residem em máquinas diferentes, e não interagem
diretamente: TargetAdapter implementa RemoteInterface, da qual
SourceAdapter depende [Alves, 2001].
A
classe
NameService
possui
para
operações
registrar
e
efetuar lookup em um objeto remoto; ambos adaptadores usam
esta classe, a qual representa um serviço genérico de nomes e
é
comum
em
muitas
plataformas
de
distribuição.
A
classe
Initializer reside na mesma máquina que as classes Target e
TargetAdapter, e é responsável por criar objetos TargetAdapter
e Target.
3.3 Padrões para o mapeamento de Objetos de
negócio para Banco de Dados relacional
Desenvolvedores de sistemas orientados a objetos que utilizam
banco
de
dados
parcela
de
relacional
tempo
persistência
dos
gastam,
realizando
objetos.
usualmente,
tarefas
Isto
uma
grande
relacionadas
ocorre
devido
à
à
incompatibilidade de tipos entre os dois paradigmas, uma vez
que os objetos são definidos pelos dados e comportamento e,
geralmente,
composição
podem
e
estar
relacionados
associação.
Já
um
através
banco
de
de
dados
herança,
relacional
consiste de tabelas, relações e funções básicas de predicados
para retornar os valores desejados [Yoder, 1998].
Uma alternativa para evitar a incompatibilidade entre objetos
e relações é utilizar um banco de dados orientado a objetos.
Entretanto,
objetos
política
os
em
um
da
relacional
em
sistemas,
banco
de
empresa
é
lugar
de
geralmente,
dados
a
um
de
necessitam
relacional.
utilizar
orientado
a
um
Outras
banco
objetos.
armazenar
vezes,
de
a
dados
Assim,
um
40
Capítulo 3 – Padrões de Software
sistema que armazena objetos em um banco de dados relacional
necessita
prover
um
mecanismo
que
realize
esta
integração
entre os dois paradigmas.
Uma solução para resolver este problema é a utilização de uma
camada de persistência, Persistence Layer [Yoder, 1998], que
isola
o
desenvolvedor
dos
detalhes
de
implementação
de
persistência e protege as aplicações de mudanças de código ou
banco
de
dados.
Assim,
foi
proposto
em
[Yoder,
1998],
um
catálogo de padrões com esta finalidade. O catálogo é composto
de doze padrões, sendo que, no desenvolvimento deste trabalho,
apenas quatro foram utilizados, a saber: Persistence Layer,
CRUD, Connection Manager e Table Manager.
3.3.1 Persistence Layer
A construção de sistemas orientados a objetos, que efetuam o
armazenamento de objetos em banco de dados relacional, consome
uma grande parcela de tempo efetuando as operações necessárias
para persistência. Caso este processo de mapeamento não seja
cuidadosamente
sistema,
realizado,
necessita
cada
conhecer
programador,
a
sintaxe
trabalhando
Structured
no
Query
Language (SQL) e, além disso, o código pode vir a se tornar
restrito a um particular tipo de banco de dados. Deste modo,
perde-se muito tempo caso ocorra, por exemplo, uma migração de
um sistema que utilize o Microsoft Access para um IBM DB2.
Assim,
torna-se
necessário
um
mecanismo
responsável
por
separar o conhecimento do domínio do conhecimento de como os
objetos são armazenados em banco de dados, a fim de proteger
as atividades de desenvolvimento com estas possíveis mudanças
[Yoder, 1998].
Neste contexto, encaixa-se o Persistence Layer. Este é um
padrão que provê uma camada persistente, capaz de realizar o
mapeamento de objetos para banco de dados relacional, de forma
transparente aos desenvolvedores. Através do padrão, todos os
objetos
persistentes
utilizam
uma
interface
comum
do
41
Capítulo 3 – Padrões de Software
Persistence
Layer.
armazenamento
dos
Desta
dados
forma,
sofra
caso
o
alterações,
mecanismo
somente
a
de
camada
persistente necessita ser mudada.
3.3.2 CRUD (Create,
Read, Update, Delete)
Qualquer objeto persistente necessita de operações para ser
lido e escrito em um banco de dados. Algumas vezes, estes
objetos também podem ser excluídos do meio de armazenamento
persistente. Assim, é importante prover um conjunto mínimo de
operações
para
criar,
ler,
atualizar
e
excluir
informações
[Yoder, 1998].
A
solução
Update,
adotada
Delete)
persistência
quantidade
é
dos
através
do
oferecer
objetos.
suficiente
as
O
de
padrão
CRUD
(Create,
Read,
operações
básicas
para
ponto
importante
operações,
é
prover
necessárias
a
para
instanciar objetos de um banco de dados e armazenar objetos
recentemente criados ou alterados.
3.3.3 Connection Manager
Quando um objeto persistente está sendo lido ou escrito num
banco de dados, uma conexão com o banco de dados deve ser
realizada.
Nesta
conexão,
as
informações
usualmente
necessárias são: o nome do banco de dados, usuário, senha e
outras
informações
relativas
a
configurações.
Estas
informações podem ser consultadas ao usuário cada vez que uma
determinada conexão é realizada; porém, esta interação pode
vir
a
sistema
tornar-se
e,
além
altamente
disso,
frustrante
muitas
vezes
para
essas
os
usuários
informações
do
são
desconhecidas. Uma possível solução seria a de capturar o nome
e
a
senha
do
usuário
no
momento
de
início
do
sistema
e
construir um esquema de conexão onde estas informações seriam
encaminhadas para o código. Entretanto, este mecanismo faz com
que uma grande quantidade de informação extra, não necessária
42
Capítulo 3 – Padrões de Software
naquele
momento,
também
seja
transmitida.
A
solução
mais
propícia, a fim de resolver estas questões, é a de construir
um gerente de conexão, sendo este o responsável por armazenar
as
informações
globais
e
as
utilizar
no
momento
exato
de
realizar um acesso ao banco de dados.
Assim,
o
padrão
Connection
Manager
cria
um
objeto
que
armazena todas as informações necessárias para utilizar uma
conexão com o banco de dados [Yoder, 1998]. As informações
comuns
são,
usualmente:
nome
do
usuário,
senha,
driver
de
banco de dados, usuário atual do sistema e outras informações
necessárias para efetuar operações de auditoria e controle de
transações. Deste modo, quando uma aplicação necessita manter
uma cópia de alguma informação deste tipo, a mesma utiliza um
objeto
do
geralmente,
tipo
Singleton
armazenado
em
[Gamma,
um
1995].
único
O
esquema
Singleton
de
é,
localização
global, como um atributo de uma classe ou uma própria classe,
evitando, assim, que qualquer mudança dessas informações seja
impactuada na aplicação.
3.3.4 Table Manager
O mecanismo de armazenamento persistente, no qual os objetos
são mapeados, pode sofrer evoluções com o decorrer do tempo,
seja por uma mudança de produto ou uma simples atualização de
versão. Um gerente de tabelas descreve o mapeamento de tabelas
e
colunas
para
o
banco
de
dados,
mantendo
estes
detalhes
transparentes ao desenvolvedor. Deste modo, mudanças podem ser
realizadas
no
esquema
de
banco
de
dados
sem
afetar
o
desenvolvimento das aplicações [Yoder, 1998].
Neste contexto, encaixa-se o padrão Table Manager. Este provê
um
local
para
recuperar
os
nomes
das
colunas
e
tabelas
necessárias para persistência dos objetos. Assim, quando um
objeto está sendo armazenado, este consulta as informações num
Table
Manager.
Por
possuir
um
mecanismo
que
define
estas
informações em somente um local, as modificações e os testes
43
Capítulo 3 – Padrões de Software
podem
ser
realizados
de
maneira
mais
simples
e
eficiente,
sendo transparente a outros segmentos da aplicação.
3.4 Resumo
Este capítulo apresentou os padrões de software, vistos como
um
mecanismo
projetos
para
orientados
vocabulário
comum,
expressar
a
experiências
objetos.
reduzindo
Estes
a
na
padrões
complexidade
elaboração
de
fornecem
um
do
sistema
utilizando abstrações, constituindo uma base de experiência
para
o
desenvolvimento
de
software
reutilizável.
Foram
relatados os princípios e os padrões que são utilizados na
Abordagem
de
Desenvolvimento
de
Software
Baseado
em
Componentes Distribuídos, objetivo de pesquisa deste trabalho.
O capítulo seguinte apresenta, em detalhes, a evolução da
computação
centralizada,
passando
pelas
redes
locais,
até
chegar aos chamados objetos distribuídos, um dos requisitos
essenciais deste trabalho.
Capítulo 4
Computação Distribuída e Objetos
Distribuídos
4.1 Introdução
Uma
aplicação
distribuída
é
uma
aplicação
na
qual
os
componentes de software residem em mais de um computador na
rede, com esta composta tipicamente por diversos computadores
e sistemas operacionais (uma rede heterogênea) [Mitre, 1998].
Em [Souza, 2001], é apresentada a evolução da computação
distribuída,
fases.
A
dividida
primeira
por
Hampshire
delas,
[1999]
conhecida
como
em
três
Primeira
grandes
Onda,
ocorrida por volta de 1975, referiu-se aos chamados sistemas
monolíticos ou centralizados, protagonizada pelos computadores
de grande porte (mainframes). Nessa primeira fase, todos os
programas
e
dados
eram
fortemente
interdependentes,
o
que
tornava muito difícil a modelagem e a reutilização dos códigos
e das informações corporativas. Não existia a possibilidade de
se
compartilhar
software,
exceto
dados
os
com
outros
pertencentes
sistemas
àquele
de
próprio
hardware
e
mainframe.
Essas aplicações monolíticas eram ineficientes, não flexíveis
e de alto custo.
Com a disponibilidade das redes de computadores, PCs de baixo
custo e interfaces gráficas, surgiu, por volta de 1982, o que
se chamou de Segunda Onda. Nessa fase, também conhecida como
Era da Arquitetura Cliente/Servidor, era possível modelar as
45
Capítulo 4 – Computação Distribuída
informações e criar repositórios de dados, passíveis de serem
acessados por múltiplos programas, e, dessa forma, simplificar
o desenvolvimento e a manutenção de sistemas mais complexos.
Em outras palavras, as aplicações podiam ser particionadas ou
divididas
em
implementavam
componentes
a
lógica
de
do
lado
cliente,
apresentação
e
os
quais
continham
grande
parte da lógica de negócio, e componentes do lado servidor,
contendo a lógica de negócio na forma de stored procedures e
triggers.
Um cliente é definido como um solicitador de serviços e um
servidor
é
definido
máquina
simples
como
pode
um
ser
fornecedor
tanto
de
cliente
serviços.
como
Uma
servidor
dependendo da configuração do software [Orfali, 1998].
Mesmo nessa fase, a reutilização de código ainda era difícil
[Emmerich, 2002]. Além disso, a dificuldade em se escalar tal
arquitetura
para
a
Internet
arquitetura
cliente/servidor,
necessidade
do
levou
que
desenvolvimento
a
mudanças
passou
de
a
no
ser
aplicações
foco
a
da
grande
corporativas
integradas com transações Web. Chegou-se, então, no ano de
1990, ao que é chamado de Terceira Onda, ou ObjectWeb (Objetos
Distribuídos + Web).
A união da orientação a objetos com sistemas distribuídos
originou a área de Objetos Distribuídos. A base para o modelo
de objetos distribuídos é o conceito fundamental de objetos,
que são definidos como entidades que possuem comportamentos
específicos
e
atributos,
fornecendo
uma
maneira
simples
de
combiná-los. Os atributos permitem que se recuperem ou que se
definam
dados
para
um
objeto.
Os
objetos
podem
receber
operações ou invocações. Uma operação identifica uma ação que
pode ser executada em um objeto, dado um conjunto especificado
de argumentos [Otte, 1996]. Os objetos podem ser clientes,
servidores, ou ambos. Um objeto está na função de cliente
quando é o originador de uma invocação em um outro objeto e
46
Capítulo 4 – Computação Distribuída
está
na
função
de
servidor
quando
é
o
receptador
de
uma
invocação [Mowbray, 1995], [Souza, 2001].
Na
realidade,
as
aplicações
com
objetos
distribuídos
representam um caso particular das aplicações cliente/servidor
multicamadas. Outros exemplos de aplicações cliente/servidor
multicamadas incluem os monitores de transações e a própria
Web [Orfali, 1998], [Souza, 2001].
As
aplicações
representam
cliente/servidor
uma
cliente/servidor
de
evolução
duas
multicamada
natural
camadas
(multi-tier)
das
(two-tier).
aplicações
Neste
ponto,
basicamente, cria-se uma camada adicional, intermediária, com
toda a lógica necessária para acesso aos dados, retirando-se
do cliente essa tarefa. Dessa forma, tem-se o que se chama de
cliente magro (thin client), responsável, principalmente, pela
lógica de apresentação ao usuário final, não sendo preciso ter
no cliente nenhum driver ou outra facilidade para acesso às
bases de dados.
Embora esse tipo de aplicação multicamadas represente uma
série de novas funcionalidades, inexistentes na Segunda Onda,
o
tipo
de
aplicação
multicamadas
responsável
pela
nova
revolução é a aplicação com objetos distribuídos [Emmerich,
2002]. Há uma variedade de maneiras de se implementar esta
camada intermediária. Entre elas, pode-se citar: monitores de
transações, servidores de mensagens, servidores de aplicação,
e frameworks [Otte, 1996], [Souza, 2001].
A
próxima
seção
descreve,
detalhadamente,
essa
camada
intermediária, também conhecida como middleware.
4.2 Middleware
Diferentemente
das
arquiteturas
cliente/servidor
de
duas
camadas, onde o cliente identifica e se sincroniza diretamente
com o servidor requisitado, o conceito de middleware assume o
papel da camada adicional entre o cliente e o servidor nas
47
Capítulo 4 – Computação Distribuída
aplicações
multicamadas
e
nas
aplicações
com
objetos
distribuídos descritas na seção anterior.
Eckerson
[1995]
conectividade
define
que
middleware
consiste
de
um
como
um
software
conjunto
de
de
serviços
disponíveis que permite que múltiplos processos, executando em
uma
ou
mais
máquinas,
interajam
através
de
uma
rede.
O
middleware, que evoluiu rapidamente durante os anos 90 para
fornecer interoperabilidade, é considerado essencial para a
migração
de
aplicações
cliente/servidor
e
mainframes
distribuídas,
e
para
para
aplicações
prover
comunicação
entre plataformas heterogêneas.
Colocado de forma mais técnica, o middleware é uma API de
fácil
utilização,
que
se
localiza
entre
a
aplicação
e
os
recursos que a aplicação necessita. Pode-se citar o exemplo de
um applet Java que acessa uma base de dados; neste caso, é
necessário usar as classes Java DataBase Connectivity (JDBC)
para
acessar
programador
as
as
informações.
diversas
Essas
classes
complexidades
da
removem
base
de
do
dados
utilizada e permitem que os applets utilizem qualquer número
de bases de dados, sem conhecer as características nativas de
cada uma delas. Utilizando uma API comum, o middleware realiza
todo o trabalho [Linthicum, 1997], [Souza, 2001].
Segundo Bernstein [Bernstein, 1996], os middlewares fornecem
serviços,
os
serviços
de
middleware,
para
auxiliarem
na
resolução de problemas de heterogeneidade e interoperabilidade
entre aplicações. O autor define que um serviço de middleware
é
um
serviço
de
propósito
geral
que
se
localiza
entre
as
aplicações e as plataformas de hardware, conforme mostra a
Figura
4.
serviços
Por
de
plataforma,
baixo
nível
define-se
e
como
elementos
de
um
conjunto
de
processamento,
definidos por uma arquitetura de processador e por uma API de
sistema
operacional,
tais
como
Intel
x86
e
Win32,
SPARCStation e SunOS, IBM RS/6000 e AIX, entre outras.
Sun
48
Capítulo 4 – Computação Distribuída
Figura 4 – Serviços de Middleware.
Um
serviço
de
middleware
deve
possuir
implementações
que
executam em diversas plataformas de hardware. Caso contrário,
ele será considerado como um serviço de plataforma de hardware
específico [Emmerich, 2002]. Pode-se citar, como exemplo, os
SGBDs,
que
funcionam
independência
de
em
diversas
plataforma
permite
plataformas.
que
os
Esta
serviços
de
middleware abranjam uma parte maior de aplicações que dependam
deles.
Se,
além
interoperabilidade
disso,
pode
o
ser
serviço
melhorada
é
com
distribuído,
as
aplicações
a
em
diferentes plataformas, utilizando o serviço para se comunicar
e/ou trocar dados. Para uma boa cobertura de plataformas, os
serviços de middleware são programados para serem portáveis,
porque, dessa forma, eles podem ser transferidos para outras
plataformas
com
mínimas,
ou
até
mesmo
nenhuma
modificação
[Souza, 2001].
Segundo Bray [1997], os middlewares podem ser classificados
de diversas formas: Transaction Processing Monitors (TPs), que
controlam aplicações de transações e executam computações de
negócios e atualizações em bancos de dados; Remote Procedure
Calls
(RPCs),
que
permitem
que
clientes
de
uma
aplicação
chamem funções para acessar servidores em sistemas remotos;
Remote Method Invocation (RMI), que estendem RPC para acesso
remoto a métodos (de objetos implementados); Message-Oriented
Middlewares
(MOMs), que residem em ambas as partes de uma
arquitetura cliente/servidor e suportam chamadas assíncronas
49
Capítulo 4 – Computação Distribuída
entre as aplicações; e os Object Request Brokers (ORBs), que
permitem
que
objetos
que
compõem
uma
aplicação
sejam
distribuídos em redes heterogêneas. A seção seguinte apresenta
e discute os middlewares do tipo Object Request Broker.
4.2.1 Object Request Broker (ORB)
Object Request Broker, ou simplesmente ORB, é uma tecnologia
que gerencia a comunicação e a troca de dados entre objetos.
Em outras palavras, o ORB provê interoperabilidade em sistemas
de objetos distribuídos. Ele permite a construção de sistemas
pelo agrupamento de objetos que se comunicam entre si através
dele. Os detalhes da implementação do ORB, geralmente, não são
importantes para os desenvolvedores de sistemas distribuídos.
Os desenvolvedores devem se preocupar apenas com os detalhes
da interface do objeto [Orfali, 1998].
A
tecnologia
diferentes
ORB
permite
máquinas,
a
comunicação
diferentes
de
software
objetos
e
entre
diferentes
fornecedores. Um ORB provê um diretório de serviços e auxilia
a estabelecer conexões entre clientes e esses serviços.
Um ORB deve suportar muitas funções, com o objetivo de operar
consistente
funções
e
são
efetivamente,
e,
transparentes
ao
responsabilidade
do
ORB
além
disso,
usuário
fornecer
a
muitas
do
ORB.
dessas
É
de
transparência
de
localidade, ou seja, fazer com que o objeto requisitado pareça
local
para
o
cliente,
enquanto
que,
na
realidade,
ele
se
localiza em processos ou máquinas diferentes [Orfali, 1998].
Portanto,
um
ORB
fornece
um
barramento
para
a
comunicação
entre objetos em diferentes sistemas. Este é o primeiro passo
para
alcançar
a
interoperabilidade
em
sistemas
de
objetos
distribuídos [Souza, 2001].
O
passo
seguinte
é
a
comunicação
de
objetos
entre
plataformas. Um ORB permite aos objetos ocultar seus detalhes
de
implementação
dos
clientes.
Isto
inclui
linguagens
de
programação, sistemas operacionais, hardware, e localização de
50
Capítulo 4 – Computação Distribuída
objetos.
Cada
um
desses
itens
deve
ser
pensado
como
uma
transparência, e diferentes tecnologias de ORBs podem suportar
diferentes transparências, fazendo com que os benefícios da
orientação a objetos entre plataformas e canais de comunicação
sejam estendidos [Wang, 2001].
O funcionamento de um ORB foi descrito por Otte [1996]. Um
ORB atua como um elemento intermediário para as requisições
que os clientes enviam para os servidores. É responsável por
todos os mecanismos necessários para encontrar a implementação
de
um
objeto,
preparar
a
implementação
para
receber
a
requisição e comunicar os dados na requisição.
Hampshire [1999] cita os principais padrões utilizados para
computação distribuída e que utilizam a tecnologia ORB:
•
Common Object Request Broker Architecture (CORBA);
•
Distributed Component Object Model (DCOM) [Microsoft,
2002];
•
A
Java Remote Method Invocation (Java RMI) [SUN, 2002a].
seção
a
seguir
descreve,
em
detalhes,
a
plataforma
distribuída CORBA.
4.2.1.1
Common
Object
Request
Broker
Architecture
Common Object Request Broker Architecture (CORBA) [Ben-Natan,
1995], [OMG, 1996], [Orfali, 1998] é a especificação de uma
arquitetura
objetos.
padrão
Esta
desenvolvam
para
sistemas
arquitetura
ORBs,
interoperabilidade
que
entre
padrão
distribuídos
permite
suportem
aplicações
baseado
que
empresas
portabilidade
escritas
em
em
e
diferentes
linguagens, compiladas para diversas plataformas e sistemas
operacionais, e que se comuniquem com outras implementações de
ORBs.
A especificação CORBA foi desenvolvida pelo OMG, o qual é um
consórcio de centenas de empresas dentro do campo de objetos
51
Capítulo 4 – Computação Distribuída
distribuídos,
ferramentas.
inicial
incluindo
O
OMG
surgiu
aplicações
foi
em
fundado
1992.
em
Desde
e
desenvolvedores
1988
e
a
então,
de
especificação
ela
vem
sendo
aperfeiçoada e, hoje, se encontra na versão 3.0. Conforme a
especificação CORBA [OMG, 1996]:
″Utilizando
um
ORB-CORBA,
um
cliente
pode
invocar
transparentemente um método no objeto servidor, o qual pode
estar
na
mesma
máquina
ou
distribuído
na
rede.
O
ORB
intercepta a chamada, e é responsável por encontrar um objeto
que possa atender a requisição, passando-lhe os parâmetros,
invocando
invocação.
seus
O
métodos,
cliente
e
não
retornando
deve
saber
os
onde
resultados
o
objeto
da
está
localizado, qual é a sua linguagem de programação, qual é o
sistema operacional, ou qualquer outro aspecto que não seja
parte da interface do objeto″.
Outros autores consideram que CORBA pode ser definida como um
barramento
de
comunicação
para
objetos
cliente
e
servidor
[Wang, 2001]. Deste ponto de vista, CORBA pode ser pensada
como uma generalização da RPC, incluindo refinamentos, tais
como [Ben-Natan, 1995], [Orfali, 1998]:
•
uma linguagem de definição de interface mais abstrata e
poderosa; e
•
suporte
direto
para
uma
variedade
de
conceitos
de
orientação a objetos.
4.2.1.2 Arquitetura CORBA
O paradigma básico do CORBA é solicitar serviços de um objeto
distribuído.
Para
oferecer
suporte
a
este
paradigma,
a
arquitetura CORBA possui três objetivos principais: abstração,
localização
e
[Orfali, 1998].
acesso
transparente,
e
interoperabilidade
52
Capítulo 4 – Computação Distribuída
Dessa
forma,
o
OMG
partiu
para
a
especificação
de
uma
interface comum aos objetos, que possa ser gerada a partir de
diferentes linguagens. Assim, não existe uma linguagem padrão,
e seus elementos podem ser desenvolvidos em
COBOL,
Eifell,
Smalltalk,
entre
outras.
C,
As
C++,
Java,
interfaces
dos
objetos são definidas em uma linguagem neutra, a Interface
Definition Language (IDL). Assim, os componentes, ou objetos,
escritos
em
IDL,
são
portados
através
de
linguagens,
ferramentas e sistemas operacionais. Deste modo, através da
IDL, a arquitetura abstrai a implementação.
Localização e acesso transparente são os meios através dos
quais os componentes CORBA, estando em qualquer ponto da rede,
podem enviar uma mensagem para outro, onde aquele não precisa
saber onde este se encontra e sua invocação é idêntica a uma
chamada
de
serviço
local.
Um
objeto
cliente
não
precisa
conhecer detalhes de implementação dos servidores. Além disto,
um só componente pode funcionar ora como cliente, ora como
servidor. Para isto, basta que os objetos tenham interfaces
especificadas
de
acordo
com
a
IDL.
Este
mecanismo
de
localização e acesso transparente é implementado pelo ORB, o
qual localiza o objeto remoto, comunica a solicitação para
este objeto, espera por resultados e os envia de volta para o
cliente. A Figura 5 [Orfali, 1998] mostra a estrutura do ORB.
Figura 5 – Estrutura de um ORB.
53
Capítulo 4 – Computação Distribuída
A figura acima mostra os dois lados de um ORB CORBA: o lado
do
cliente
e
o
lado
do
servidor.
Orfali
[1998]
também
descreveu a função de cada componente do ORB:
•
Client IDL Stubs: provêem interfaces estáticas para os
acessos aos objetos remotos. Estes stubs pré-compilados
definem como o cliente invoca serviços nos servidores.
Do ponto de vista do cliente, os stubs agem como um
proxy para o objeto remoto do servidor. Os serviços são
definidos
utilizando-se
a
IDL
e
os
stubs;
para
os
clientes e servidores, são gerados pelo compilador IDL.
Um cliente deve possuir um stub para cada interface que
ele utiliza no servidor. Os stubs também incluem código
para
realizar
o
marshalling
decodificação
dos
mensagens
formatos
com
métodos
e
(codificação
e
parâmetros
em
seus
padrões).
Ele
também
inclui
código para acesso a outras linguagens de alto nível,
como C, C++;
• Dynamic
Invocation
Interface
(DII):
permite
descobrir
métodos de servidores remotos em tempo de execução.
CORBA define APIs para a localização de meta-dados, que
definem as interfaces dos servidores para a geração dos
parâmetros, para invocação remota e para o retorno dos
dados;
• Interface Repository APIs (IR): permitem obter e modificar
a
descrição
registrados,
parâmetros
de
todas
os
que
as
métodos
eles
interfaces
dos
que
suportam
eles
utilizam.
O
componentes
e
os
Repositório
de
Interfaces é uma base de dados distribuída, que contém
as definições das interfaces no formato da IDL;
• ORB
Interface:
locais,
exemplo,
que
consiste
podem
CORBA
em
ser
fornece
algumas
úteis
APIs
para
serviços
a
para
para
serviços
aplicação.
Por
converter
uma
referência de um objeto em uma string, e vice-versa.
54
Capítulo 4 – Computação Distribuída
O suporte para invocações estáticas e dinâmicas oferece um
alto poder de programação para a computação distribuída de
CORBA. As invocações estáticas são mais fáceis de programar e
possuem
um
desempenho
melhor
[Orfali,
1998].
As
invocações
dinâmicas fornecem uma alta flexibilidade, embora sejam mais
difíceis na programação; são muito úteis para se descobrir
serviços em tempo de execução.
Os servidores não podem estabelecer a diferença entre as
invocações estáticas ou dinâmicas, pois ambas possuem a mesma
semântica. Em ambos os casos, o ORB localiza o adaptador do
objeto remoto, transmite os parâmetros, e transfere o controle
para a implementação do objeto, através dos stubs do servidor
(skeletons).
O
lado
do
servidor
[Orfali,
1998]
possui
a
seguinte estrutura:
• Server IDL Stubs (Static Skeletons): fornecem interfaces
estáticas para cada serviço exportado pelo servidor.
Esses stubs também são criados pelo compilador IDL;
• Dynamic Skeleton Interface (DSI): foi introduzida com a
versão
CORBA
2.0
e
fornece
mecanismos
de
ligação
(binding) em tempo de execução, para servidores que
necessitam manipular requisições de objetos, que não
possuem
stubs
nem
skeletons
compilados.
O
DSI
do
serviços
de
servidor é equivalente ao DII do cliente;
• Object
Adapter:
localiza-se
no
topo
dos
comunicação do ORB e recebe as requisições dos serviços
antes dos objetos do servidor. Ele provê um ambiente de
execução
para
a
instanciação
dos
objetos
dos
servidores, para a passagem das requisições e para a
atribuição de identificadores únicos para cada objeto;
• Implementation Repository (IR): fornece um repositório de
informações sobre as classes que um objeto suporta, os
objetos
que
estão
instanciados
e
os
identificadores
únicos de cada um. É utilizado, também, para armazenar
informações
adicionais,
associadas
com
as
55
Capítulo 4 – Computação Distribuída
implementações
de
cada
ORB,
entre
elas:
segurança,
dados administrativos, entre outras;
• ORB
Interface:
consiste
em
algumas
APIs
para
serviços
locais, que são idênticas àquelas fornecidas para o
cliente.
Como mencionado anteriormente, a interoperabilidade em CORBA
se apresenta através do sistema operacional, rede e linguagem
de programação.
A
macro
arquitetura
das
aplicações
CORBA,
conhecida
como
Object Management Architecture (OMA), foi a forma adotada pela
OMG para dividir a complexidade da arquitetura inicial, sendo
assim estabelecida, a divisão, em quatro grupos diferentes: o
ORB,
os
Objetos
de
Serviços,
as
Facilidades
Comuns
e
os
Objetos de Aplicação. A Figura 6 mostra esta arquitetura.
Objetos de
Aplicação
Facilidades Comuns
ORB
Objetos de Serviços
Figura 6 – Object Management Architecture.
Além do ORB, que já foi descrito anteriormente, os objetos de
serviços
possuem
coleções
de
complexas,
grande
componentes
determinando
importância
definidos
um
nível
com
na
arquitetura.
interfaces
superior
nos
IDL
graus
São
mais
de
complexidade dos objetos CORBA. Pode-se pensar em um objeto de
serviço como sendo um complemento às funcionalidades de um
56
Capítulo 4 – Computação Distribuída
ORB.
Estas
IDLs
mais
complexas
são
conhecidas
como
CORBAservices [OMG, 1996], [Orfali, 1998].
Os objetos de serviço são utilizados para criar componentes,
atribuir-lhes nomes, inicializá-los, entre outras coisas. Em
princípio,
o
número
aumentou
já
OMG
definiu
para
onze
serviços-padrão.
dezesseis.
A
seguir,
Hoje,
são
este
listados
esses serviços [Orfali, 1998]:
• Nomeação
(Naming):
permite
que
componentes
localizem
outros componentes através do nome. Este serviço também
permite
que
objetos
sejam
registrados
em
diretórios
existentes na rede, incluindo X.500, DCE, NIS+, Novell
NDS e Internet LDAP;
• Eventos
(Event):
permite
que
objetos
registrem,
dinamicamente, o interesse em eventos específicos do
ambiente. O serviço define um objeto chamado de Event
Channel,
que
coleta
e
distribui
eventos
entre
os
componentes da rede;
• Ciclo
de
Vida
(Life
Cycle):
define
operações
para
a
criação, cópia, movimentação e exclusão de componentes
no ambiente;
• Persistência
(Persistence):
armazenar,
fornece
persistentemente,
uma
interface
componentes
para
em
uma
variedade de servidores de armazenamento – incluindo
Bancos de Dados Orientados a Objetos (ODBMS), Bancos de
dados Relacionais (RDBMS) e arquivos simples;
• Transação
(Transaction):
objetos
define
recuperáveis,
efetivação
em
assegurando
duas
as
baseado
fases
a
coordenação
no
(aninhadas
propriedades
de
entre
protocolo
e
de
agrupadas),
atomicidade,
consistência, isolação e durabilidade;
• Controle de Concorrência (Concurrency Control): provê um
gerenciador
de
bloqueio,
que
bloqueia
componentes para threads ou transações;
recursos
ou
57
Capítulo 4 – Computação Distribuída
• Relacionamento (Relationship): fornece uma maneira de se
criar
associações
entre
componentes.
Provê,
também,
mecanismos para se percorrer associações de grupos de
componentes. Pode-se usar este serviço para reforçar
restrições de integridade referencial, entre outros;
• Externalização
(Externalization):
fornece
um
mecanismo
padrão para transferência de dados entre componentes,
utilizando streams;
• Consulta
(Query):
fornece
operações
de
consultas
para
objetos. É um super conjunto do padrão SQL. É baseado
na especificação SQL3 e na Object Query Language (OQL),
do grupo Object Database Management Group (ODMG);
• Licença (Licensing): provê operações para a medição do uso
de componentes, para garantir a compensação de seu uso.
O serviço suporta qualquer modelo de controle de uso em
qualquer ponto do ciclo de vida do componente;
• Propriedades (Properties): fornece operações que permitem
associar
valores
nominais
(ou
propriedades)
com
qualquer componente. A utilização deste serviço permite
a associação dinâmica de uma propriedade com o estado
de um componente;
• Tempo (Time): fornece interfaces para a sincronização de
tempo em um ambiente de objetos distribuídos. Também
oferece operação para se definir e gerenciar eventos
disparados por tempo;
• Segurança (Security): fornece um framework completo para a
segurança
autenticação,
de
objetos
listas
confidenciabilidade.
de
Também
distribuídos.
controle
gerencia
de
a
Suporta
acesso
e
delegação
de
credenciais entre objetos;
• Negociação (Trading): possibilita a localização de objetos
através dos tipos de serviços oferecidos;
58
Capítulo 4 – Computação Distribuída
• Coleção
(Collection):
criação
e
fornece
manipulação
interfaces
das
coleções
CORBA
para
a
mais
comuns,
genericamente;
• Notificação (Notification): é uma extensão do serviço de
eventos
que
inclui
refinamentos,
como
qualidade
de
enriquece
o
serviço, filtros, entre outros.
A
utilização
de
todos
esses
serviços
comportamento de objetos em um ambiente distribuído.
O
terceiro
grupo
CORBAFacilities,
que
define
as
são,
por
facilidades
definição,
comuns,
ou
coleções
de
componentes que proporcionam serviços para serem utilizados
diretamente
pelos
complexidade
objetos
dos
de
objetos
aplicações.
de
Não
negócios,
possuem
mas
a
englobam
funcionalidades mais ricas do que as dos objetos de serviço
[Orfali, 1998]. As facilidades comuns, que estão atualmente em
desenvolvimento, incluem agentes móveis, comunicação de dados,
fluxo
de
negócios.
trabalho,
As
firewalls
facilidades
e
frameworks
comuns
constituem
para
um
objetos
projeto
de
sem
término. O projeto continuará até que o OMG defina todas as
interfaces para cada serviço distribuído, até que se tenha
conhecimento
e
para
outros
que
ainda
serão
desenvolvidos
[Souza, 2001].
Os objetos de aplicações são componentes específicos para
aplicações,
voltadas
ao
usuário
final.
Assim,
os
objetos
definidos com base na IDL ficam disponíveis no ORB, para serem
utilizados diretamente na construção dos aplicativos. Apesar
de sua similaridade com as facilidades comuns, os objetos de
negócios são mais complexos, conseguindo representar objetos
reais
existentes
no
dia-a-dia
de
um
usuário
final.
Orfali
[1998] cita alguns exemplos de objetos de negócios: cliente,
ordem de pagamento, dinheiro, carro, paciente, conta corrente,
entre outros.
59
Capítulo 4 – Computação Distribuída
4.3 Resumo
Este
capítulo
apresentou
um
breve
estudo
da
evolução
da
computação distribuída, desde a utilização dos mainframes, até
a
época
atual,
integrados
à
com
a
utilização
Internet.
Também
dos
sistemas
introduziu
distribuídos
conceitos,
como
middleware, e descreveu, de forma detalhada, o tipo específico
de
middleware,
conhecido
como
ORB.
O
ORB
é
o
principal
componente das aplicações distribuídas nos dias de hoje e é o
elemento chave de diversas plataformas existentes. Por último,
foi apresentada, em detalhes, a plataforma distribuída CORBA,
discutindo seus princípios, sua arquitetura e seus principais
elementos. O capítulo seguinte descreverá as ferramentas CASE,
considerada como um elemento essencial a fim de automatizar as
tarefas de desenvolvimento, em especial, o desenvolvimento de
software baseado em componentes distribuídos.
Capítulo 5
Ferramentas CASE
5.1 Introdução
O Instituto de Engenharia de Software americano [SEI, 1999c]
relata
que,
desde
os
primeiros
desenvolvimento
de
necessidade
utilização
engenheiro
de
de
software,
software
já
de
dias
existia
das
atividades
de
uma
consciência
da
ferramentas
na
otimização
para
de
auxiliar
suas
o
tarefas.
Inicialmente, a concentração estava em ferramentas de suporte
à
execução
montadores
dos
e
programas,
processadores
como
de
tradutores,
macro.
compiladores,
Entretanto,
com
o
crescimento dos recursos computacionais aliados à complexidade
do
software,
ferramentas
motivou-se
com
novas
a
necessidade
de
funcionalidades.
expansão
Em
dessas
particular,
a
utilização de sistemas interativos de tempo compartilhado no
desenvolvimento de software, encorajou a criação de editores
de programas, debuggers e analisadores de código [SEI, 1999c].
À medida que os computadores iam se tornando mais confiáveis
e
mais
utilizados,
a
necessidade
desenvolvimento
de
software
desenvolvimento
de
software
de
uma
tornava-se
passou
a
ampla
aparente.
ser
visto
noção
do
Assim,
o
como
[SEI,
1999c]:
•
Uma
atividade
significativos,
projetar
uma
de
a
larga
fim
solução
escala
de
que
envolve
identificar
apropriada,
os
esforços
requisitos,
implementar
esta
61
Capítulo 5 – Ferramentas CASE
solução,
testa-lá
e,
finalmente,
documentar
as
funcionalidades do produto final antes de se colocar em
produção;
•
Um
processo
a
longo
prazo,
no
qual
o
seu
principal
produto, o software, necessita de melhorias contínuas
durante todo o seu ciclo de vida. As implicações dessa
visão são que a estrutura do software deve permitir a
inclusão de novas funcionalidades de forma facilitada e,
além disso, as informações referentes aos requisitos,
projeto, implementação e testes, devem ser armazenadas e
disponibilizadas de forma detalhada, a fim de auxiliar
as tarefas de manutenção. Adicionalmente, as diversas
versões dos artefatos produzidos durante todo o projeto
devem
ser
mantidas,
de
modo
que
qualquer
informação
necessária para o grupo de desenvolvimento possa ser
obtida sem maiores problemas; e, finalmente, como
•
Uma atividade coletiva, que envolve a interação entre um
grupo de participantes durante cada etapa do ciclo de
vida. Assim, esses participantes devem poder cooperar
entre
si,
de
maneira
controlada,
e
possuir
visões
consistentes de determinados aspectos do projeto.
A visão de desenvolvimento de software como um processo de
larga escala e a longo prazo resultou no desenvolvimento de
uma
variedade
tarefa
de
[Humphrey,
limitadas,
não
ferramentas
1989].
oferecendo
que
ofereciam
Inicialmente,
muitos
as
recursos
suporte
a
esta
ferramentas
eram
a
este
suporte.
Entretanto, dois importantes avanços resultaram na melhoria
das funcionalidades dessas ferramentas, a saber [SEI, 1999c]:
•
Pesquisas na área de processos de desenvolvimento de
software, as quais deram origem ao crescimento do número
de
métodos
de
projeto
(por
exemplo,
programação
e
análise estruturada), que passaram a ser utilizados como
base
para
o
desenvolvimento.
Esses
métodos
foram
62
Capítulo 5 – Ferramentas CASE
idealmente,
apropriados
para
serem
automatizados
por
ferramentas de suporte, em cada etapa de sua execução,
tendo
notações
gráficas
associadas
e
uma
grande
variedade de artefatos associados (diagramas, anotações
e documentações), necessários para serem armazenados e
documentados.
•
Os recursos computacionais oferecidos pelas máquinas.
Com o avanço destes recursos, começou-se a explorar,
efetivamente, a capacidade de armazenamento de dados, o
aumento do poder de processamento e os recursos mais
sofisticados,
visualização
oferecidos
gráfica,
pelos
capazes
mecanismos
de
exibir
para
gráficos,
modelos de análise e projeto e uma série de diagramas.
A partir das funcionalidades obtidas com a utilização destas
ferramentas, pôde-se obter uma definição mais precisa do termo
ferramenta
CASE.
Segundo
Pressman
[2001],
ferramentas
de
engenharia de software apoiadas por computador (Computer-Aided
Software Engineering, CASE) auxiliam gerentes e profissionais
de engenharia de software em todas atividades associadas com o
processo
de
desenvolvimento.
Automatizam
as
atividades
de
gestão de projetos, gerenciam todos os artefatos produzidos ao
longo do processo e assistem aos engenheiros de software em
seu trabalho de análise, projeto, implementação e teste.
A
área
de
CASE
conseqüentemente,
descrever
toolkits,
maneira
estas
tem
se
desenvolvido
diferentes
terminologias
ferramentas.
workbenches
inconsistente.
e
Termos
ambientes
Assim,
muito
uma
têm
são
usadas
como
sido
taxonomia
CASE torna-se extremamente necessária.
rapidamente
e,
para
ferramentas,
utilizados
de
de
ferramentas
63
Capítulo 5 – Ferramentas CASE
Diversas taxonomias podem ser encontradas na literatura. Em
[SEI,
1999c],
os
autores
dividem
as
ferramentas
em
três
grupos:
•
Ferramentas
de
natureza
interativa
(por
exemplo,
uma
ferramenta que ofereça suporte a um determinado método
de
desenvolvimento)
categoria
classes
CASE,
(por
são,
e
as
exemplo,
algumas
enquanto
que
que
não
se
encaixam
um
compilador).
vezes,
chamadas
as
últimas
As
de
são
nesta
primeiras
ferramentas
chamadas
de
ferramentas de desenvolvimento.
•
Ferramentas que oferecem suporte as atividades iniciais
do ciclo de vida do projeto de software (como análise de
requisitos) e as que são utilizadas em fases posteriores
do ciclo de vida (como compiladores e ferramentas de
teste).
As
primeiras
classes
são,
algumas
vezes,
chamadas de ferramentas CASE front-end, enquanto que as
últimas são chamadas de back-end.
•
Ferramentas que são utilizadas para uma etapa específica
do ciclo de vida de desenvolvimento (como, por exemplo,
uma ferramenta de análise de requisitos ou codificação)
e as que são comuns a uma série de etapas do ciclo de
vida (como, por exemplo, ferramentas de documentação e
gerenciamento de configuração).
Sommerville [2000] e Pressman [2001] definem uma taxonomia de
ferramentas
CASE
mais
abrangente,
utilizando
como
base
o
critério de função. A partir deste critério, as ferramentas
são
agrupadas
incluindo
gestão
de
de
engenharia
processo,
acordo
de
com
processo
análise
de
dezesseis
de
funcionalidades,
negócio,
risco,
entre
modelagem
outras.
e
Esse
critério é o que será utilizado neste trabalho.
A seção seguinte apresenta a ferramenta MVCASE que se encaixa
na
taxonomia
de
análise
e
projeto,
segundo
o
critério
de
64
Capítulo 5 – Ferramentas CASE
função, e que oferece suporte ao desenvolvimento de software
baseado em componentes distribuídos.
5.2 Ferramentas de Análise e Projeto
Segundo Pressman [2001], as ferramentas de análise e projeto
permitem ao engenheiro de software criar modelos do sistema a
ser construído. Os modelos contêm uma representação dos dados,
funções
e
comportamento
caracterizações
do
(referentes
projeto
de
à
análise)
dados,
e
informações
arquiteturais, e descrições dos componentes e interfaces.
5.2.1 MVCASE
A ferramenta MVCASE [Barrére, 1999], [Prado, 2000], [Prado,
2001], [Almeida, 2002], [Almeida, 2002a] é uma ferramenta que
provê
técnicas
gráficas
e
textuais
para
o
engenheiro
de
software. Com efeito, este especifica o sistema, em um alto
nível de abstração, e gera código dessas especificações, por
exemplo, em linguagens como Java, usando os benefícios da UML,
a
qual
permite
ao
desenvolvedor
trabalhar
com
diferentes
em
descrições
visões no desenvolvimento de sistemas.
As
especificações
criadas
são
armazenadas
textuais em uma linguagem de modelagem. Estas descrições são
as representações dos modelos do sistema, contendo cada parte
do mesmo.
A ferramenta MVCASE é totalmente escrita na linguagem Java,
usando a tecnologia Java 2, da Sun Microsystems, e a Java
Foundation Classes (JFC), a qual oferece suporte a interface
livre de plataforma.
No estágio atual, a MVCASE suporta técnicas para persistência
e criação de objetos distribuídos, em uma arquitetura de três
camadas.
Usando
desenvolvedor
objetos
pode
contendo
os
três
separar
regras
de
níveis
os
da
objetos
negócio
e
em
especificação,
objetos
objetos
o
clientes,
que
provêem
serviços, como um banco de dados. Estes objetos podem ser
65
Capítulo 5 – Ferramentas CASE
distribuídos
em
diferentes
plataformas,
criando
aplicações
cliente e servidor em um alto nível de abstração. Componentes
Distribuídos
podem
ser
criados
com
a
tecnologia
Enterprise
Java Beans (EJB) [Sun, 2002], suportada pela ferramenta. Esta
tecnologia
permite
desenvolver
aplicações
reutilizando
componentes, deixando tarefas como conectividade, segurança e
transações gerenciadas pelo servidor, o qual as realiza de
forma transparente, para o usuário ou o desenvolvedor.
Segue-se
uma
apresentação
das
principais
notações
UML
suportadas pela MVCASE.
5.2.2 Notações UML suportadas pela MVCASE
Segundo os autores da UML [Rumbaugh, 1999], os diagramas podem
ser divididos em dois grupos: estruturais e comportamentais,
conforme mostram, respectivamente, as Tabelas 2 e 3.
Tabela 2 - Diagramas Estruturais.
Diagramas Estruturais
Diagrama de Classes
Diagrama de Objetos
Diagrama de Componentes
Diagrama de Implantação
Tabela 3 - Diagramas Comportamentais.
Diagramas Comportamentais
Diagrama de Caso de Uso
Diagrama de Seqüência
Diagrama de Colaboração
Diagrama de Estados
Diagrama de Atividades
Os
diagramas
estruturais
são
utilizados
para
visualizar,
especificar, construir e documentar os aspectos estáticos de
um sistema. Os aspectos estáticos de um sistema podem ser
66
Capítulo 5 – Ferramentas CASE
encarados como uma representação de seu esqueleto e estruturas
relativamente estáveis [Rumbaugh, 1999].
Os diagramas comportamentais são utilizados para visualizar,
especificar, construir e documentar os aspectos dinâmicos de
um
sistema.
Os
aspectos
dinâmicos
de
um
sistema
são
considerados como uma representação de suas partes que sofrem
alterações [Rumbaugh, 1999].
Dentre os principais diagramas estruturais suportados pela
Ferramenta
MVCASE,
destacam-se:
o
Diagrama
de
Classes
e
o
Diagrama de Componentes. O Diagrama de Classes representa um
conjunto
de
classes,
interfaces
e
colaborações
e
seus
relacionamentos. A Figura 7 mostra um exemplo deste diagrama.
Figura 7 - Diagrama de Classes.
O Diagrama de Componentes mostra um conjunto de componentes,
interfaces
e
seus
relacionamentos.
exemplo deste diagrama.
A
Figura
8
mostra
um
67
Capítulo 5 – Ferramentas CASE
Figura 8 - Diagrama de Componentes.
No grupo dos diagramas comportamentais, podem ser citados
como
primordiais
para
o
desenvolvimento
de
aplicações,
o
Diagrama de Caso de Uso e o Diagrama de Seqüência. O Diagrama
de Caso de Uso mostra um conjunto de casos de uso e atores e
seus relacionamentos, enquanto o Diagrama de Seqüência tem por
objetivo
mostrar
os
cenários
de
execução
das
operações
ao
longo do tempo e modelar as conexões de mensagens entre os
objetos [Rumbaugh, 1999].
A Figura 9 mostra um exemplo de Diagrama de Caso de Uso e o
seu correspondente Diagrama de Seqüência do curso normal.
Figura 9 - Diagrama de Caso de Uso e Seqüência.
68
Capítulo 5 – Ferramentas CASE
5.3 Resumo
Este capítulo introduziu as ferramentas CASE consideradas como
um
elemento
primordial
no
desenvolvimento
de
software,
auxiliando o engenheiro de software em todas as atividades
associadas
introduziu
com
a
o
processo
taxonomia
dessas
de
desenvolvimento.
ferramentas,
em
Também
especial,
a
baseada no critério de função como elemento chave. Por fim,
foi apresentada a ferramenta MVCASE, onde se apóia toda a
abordagem
de
desenvolvimento
de
software
baseado
em
componentes distribuídos, objetivo deste trabalho. O capítulo
seguinte apresenta, em detalhes, a abordagem proposta.
Capítulo 6
Uma Abordagem para o
Desenvolvimento de Software
Baseado em Componentes
Distribuídos
6.1 Introdução
Há muito vem se formando uma consciência na comunidade de
engenharia de software de que, a fim de se obter produtos com
alta qualidade e que sejam economicamente viáveis, torna-se
extremamente necessário um conjunto sistemático de processos,
técnicas e ferramentas. Nesse conjunto, a reutilização está
entre as técnicas mais relevantes. Parte-se do princípio, de
que, reutilizando partes bem especificadas, desenvolvidas e
testadas,
maior
pode-se
construir
confiabilidade.
técnicas
têm
sido
Ao
software
longo
propostas
em
dos
para
menor
últimos
favorecer
a
tempo
anos,
e
com
muitas
reutilização.
Dentre estas técnicas, destacam-se: a engenharia de domínio,
frameworks,
padrões
e
componentes.
Entretanto,
o
o
desenvolvimento
que
falta
nesse
baseado
contexto
é
em
uma
maneira sistemática e progressiva de realizar a reutilização.
Assim,
motivado
principalmente
reutilização
e
apresenta
resultados
os
distribuição
de
de
pelos
objetos,
pesquisa
e
a
princípios
este
proposta
de
capítulo
de
uma
70
Capítulo 6 – Abordagem de DBCD
Abordagem
para
o
Desenvolvimento
de
Software
Baseado
em
Componentes Distribuídos (DBCD).
6.2 Mecanismos da Abordagem
Após a pesquisa de diferentes métodos, técnicas e ferramentas
disponíveis
na
literatura
[D’Souza,
1999],
[Perspective,
2000], [Cheesman, 2000], [Jacobson, 2001], [Rational, 2001],
[Objecteering, 2001], decidiu-se pela utilização de Catalysis,
como
método
Middleware,
de
como
desenvolvimento
camada
baseado
adicional
entre
em
componentes;
o
cliente
e
o
servidor; framework e padrões, para facilitar a distribuição
dos componentes e o acesso ao banco de dados.
Esses mecanismos foram integrados numa abordagem, orientando
o engenheiro de software tanto no processo de desenvolvimento
dos
componentes
desenvolvimento
de
das
um
domínio
aplicações
do
que
problema
os
quanto
reutilizam.
no
Para
automatizar parte das tarefas de desenvolvimento, a abordagem
utiliza
a
ferramenta
MVCASE,
sobre
a
qual
se
apóiam
o
desenvolvimento e a reutilização dos componentes.
6.2.1 Método Catalysis
A abordagem de DBCD proposta baseia-se no método Catalysis,
principalmente, pela clara distinção entre as funcionalidades
dos seus três níveis: Domínio do Problema, onde é dada ênfase
no
entendimento
do
problema,
especificando-se
“o
quê”
o
sistema deve atender para solucionar o problema; Especificação
dos Componentes, onde é descrito o comportamento do sistema de
uma forma não ambígua; e, Projeto Interno dos Componentes,
onde
se
define
“como”
serão
implementados
os
requisitos
especificados para os componentes, além da forte ênfase nos
conceitos
de
abstração
e
refinamento,
utilizados
para
representar os relacionamentos essenciais entre os diversos
artefatos
do
sistema,
obtidos
durante
o
processo
de
desenvolvimento. A ênfase no refinamento dos artefatos cria
71
Capítulo 6 – Abordagem de DBCD
uma série de fatorações, extensões e transformações que visam
o rastreamento dos requisitos até o código.
A integração de Catalysis na abordagem de DBCD foi feita
através
da
definição
de
passos
para
o
desenvolvimento
dos
componentes, correspondentes a cada um destes níveis, conforme
resume a Tabela 4.
Tabela 4 - Catalysis versus Abordagem de DBCD.
Níveis do Método Catalysis
Passos da Abordagem de DBCD
Domínio do Problema
Definir Problema
Especificação dos Componentes
Especificar Componentes
Projeto Interno dos Componentes
Projetar Componentes
Implementar Componentes
Cada um destes passos da abordagem serão apresentados, em
detalhes, na seção 6.3.
6.2.2 Middleware
Conforme
foi
apresentado
no
capítulo
4,
sobre
computação
distribuída, diferentemente das arquiteturas cliente/servidor
de duas camadas, onde o cliente identifica e se sincroniza
diretamente
com
o
servidor
requisitado,
o
conceito
de
middleware assume o papel da camada adicional entre o cliente
e o servidor nas aplicações multicamadas e nas aplicações com
objetos distribuídos.
A abordagem de DBCD utiliza o middleware como uma camada
intermediária, para permitir a distribuição dos componentes
através da rede e oferecer uma estrutura para sua localização
e comunicação, ocultando detalhes de linguagem de programação,
sistema operacional e hardware.
6.2.3 Framework e Padrões
A
fim
de
construir
componentes
de
software
mais
seguros,
confiáveis, fáceis de manter e de reutilizar, a abordagem de
DBCD utiliza um framework baseado em padrões. Esse framework
foi desenvolvido com objetivo de orientar o processo de acesso
a
banco
de
dados
relacional
e
evitar
o
entrelaçamento
de
72
Capítulo 6 – Abordagem de DBCD
código
com
diferentes
propósitos,
neste
caso,
código
de
negócio com código de acesso a banco de dados.
6.2.3.1 Framework Persistence
Utilizando os princípios dos padrões apresentados em [Yoder,
1998], para mapeamento de objetos de negócio para banco de
dados relacional, desenvolveu-se o framework Persistence.
Esse framework é composto, basicamente, de quatro componentes
específicos e de outros componentes pertencentes à biblioteca
da
linguagem
Java.
A
Figura
10
mostra
os
4
componentes
específicos e suas dependências. O componente ConnectionPool,
através de sua interface IConnectionPool, realiza a gerência e
conexão
com
componente
o
banco
de
DriversUtil,
dados
com
utilizado
base
em
na
aplicação.
definições
O
eXtensible
Markup Language (XML) [W3C, 2001], contém as informações dos
drivers de banco de dados suportados, disponibilizadas através
de
sua
interface
IDriverUtil.
O
componente
TableManager
gerencia o mapeamento de um objeto para tabelas do banco de
dados,
disponibilizando
ITableManager.
O
seus
componente
métodos
persistente
pela
interface
da
estrutura
FacadePersistent, através de sua interface IPersistentObject,
disponibiliza os valores que devem ser adicionados ao banco de
dados, passando parâmetros ao componente TableManager.
Figura 10 - Framework Persistence.
73
Capítulo 6 – Abordagem de DBCD
A utilização de padrões em sistemas complexos de software
permite que soluções previamente testadas sejam reutilizadas,
tornando
o
sistema
mais
compreensível,
flexível,
fácil
de
desenvolver e manter.
Deste
modo,
a
fim
relacionadas
à
utiliza
padrão
o
de
facilitar
distribuição
a
dos
realização
componentes,
Distributed
Adapters
de
a
tarefas
abordagem
Pattern
(DAP),
apresentado, anteriormente, no capítulo 3.
6.2.4 Ferramenta MVCASE
Ferramentas CASE têm sido empregadas, com sucesso, no projeto
ou
reprojeto
de
sistemas
a
serem
reconstruídos.
Dentre
as
ferramentas CASE, destaca-se, neste trabalho, a MVCASE, que
suporta a especificação do sistema usando a notação UML e foi
estendida
para
oferecer
suporte
a
abordagem
de
utiliza
a
ferramenta
DBCD
aqui
MVCASE
para
apresentada.
A
abordagem
construir
e
de
DBCD
reutilizar
os
componentes
de
um
domínio
do
problema, através de um middleware. Uma vez especificados os
componentes
de
especificações
especificamente
um
em
domínio,
uma
Java,
pode-se
linguagem
tornando-os
gerar
código
orientada
a
disponíveis
dessas
objetos,
em
um
a
este
repositório de componentes para posterior reutilização.
O
estágio
inicial
da
ferramenta
MVCASE,
anterior
trabalho, permitia ao engenheiro de software especificar os
diagramas
Componentes
de
Caso
e
de
de
Uso,
Seqüência,
Implantação.
Porém,
Classes,
para
Estados,
modelar
os
componentes, conforme o método de DBC Catalysis, tornava-se
necessária a adição de outros artefatos, específicos de DBC,
ainda não disponíveis na ferramenta. Assim, estes artefatos
foram desenvolvidos, permitindo a especificação do Modelo de
Colaboração, Framework de Modelos e Modelo de Aplicação do
Framework, conforme previsto em Catalysis, e essencial para a
abordagem proposta.
74
Capítulo 6 – Abordagem de DBCD
6.2.4.1 Modelo de Colaboração
A Figura 11 mostra um Modelo de Colaboração [D’Souza, 1999],
representando a coleção de objetos participantes e as ações.
Em
Catalysis,
os
informações
e
representar
um
objetos
representam
funcionalidades,
evento,
um
conjunto
as
ações
enquanto
tarefa,
mensagem
ou
de
podem
atividade,
relacionada ao objeto. No Modelo de Colaboração da Figura 11,
o retângulo (Manager e Customer) corresponde aos objetos e as
elipses
representam
KeepEmployee,
às
ações
(KeepTask,
ConsultTaskAccomplished,
KeepCustomer,
ConsultTaskPending,
KeepServiceOrder).
Figura 11 - Modelo de Colaboração.
6.2.4.2
Framework
de
Modelos
e
Modelo
de
Aplicação do Framework
O
método
nível,
Catalysis
como
particionadas
considera
especificações
e
e
reutilizadas,
que
descrições
projetos,
ao
de
também
contrário
da
mais
alto
podem
ser
convencional
reutilização de código. Esses elementos reutilizáveis de mais
alto nível são chamados de Framework de Modelos.
75
Capítulo 6 – Abordagem de DBCD
Um
Framework de Modelos
genérico,
que
contém
possui
alguns
a
tipos
estrutura
e
suas
de
um
pacote
características.
Esses tipos e características podem ser definidos por meio de
placeholders, representados pelos sinais de <>, que consistem
em
definições
aplicação
do
genéricas
domínio
a
serem
[D’Souza,
instanciadas
1999],
conforme
[Gimenes,
a
2000].
A
Figura 12 mostra este framework com os seus tipos genéricos.
Figura 12 - Framework de Modelos.
Quando um
Framework de Modelos
é
aplicado,
os
tipos
com
placeholders são substituídos, para que se possa obter uma
versão do framework especializado para a aplicação desejada. O
artefato disponibilizado a partir dessa aplicação do Framework
de Modelos é o Modelo de Aplicação do Framework. A Figura 13
mostra este modelo, onde os tipos genéricos foram substituídos
pelos
tipos
específicos,
Employee e Task.
no
caso,
Customer,
ServiceOrder,
76
Capítulo 6 – Abordagem de DBCD
Figura 13 - Modelo de Aplicação do Framework.
6.2.4.3
Wizard
para
Geração
de
Código
dos
Componentes
Outra extensão realizada na ferramenta MVCASE foi a adição de
recursos,
para
implementação
auxiliar
dos
engenheiro
componentes
desenvolvido
um
processo
DBCD,
de
o
wizard
para
realizando
de
software
distribuídos.
Assim,
automatizar
parcialmente
a
de
geração
código
na
foi
o
dos
componentes e suas respectivas interfaces, assim como o código
dos stubs e skeletons. A Figura 14 mostra este wizard.
Inicialmente,
o
engenheiro
de
software
seleciona
os
componentes do domínio disponíveis na ferramenta. Em seguida,
especifica-se os componentes correspondentes a estrutura do
padrão
DAP,
ou
seja,
os
adaptadores
origem
e
destino
(SourceAdapter e TargetAdapter) e o Facade. Uma vez realizados
esses passos, gera-se o código Java e IDL dos componentes e
suas
interfaces.
compilados
componentes.
a
fim
Por
de
fim,
se
os
obter
códigos
a
em
Java
implementação
e
IDL
são
final
dos
77
Capítulo 6 – Abordagem de DBCD
Figura 14 - Wizard para geração de código dos componentes.
6.3 Abordagem de Desenvolvimento de Software
Baseado em Componentes Distribuídos
Integrando
as
técnicas
princípios
de
middleware,
Distributed
definiu-se
Adapters
uma
do
método
o
Pattern
abordagem
Catalysis
framework
(DAP),
que
na
suporta
de
Persistence
ferramenta
o
DBC,
os
e
o
MVCASE,
Desenvolvimento
de
Software Baseado em Componentes Distribuídos (DBCD).
A abordagem foi dividida em duas etapas, conforme mostra a
Figura
15,
utilizando
a
notação
SADT
[Ross,
1977].
Numa
primeira etapa, a abordagem parte dos requisitos de um domínio
do problema e produz os componentes numa linguagem orientada a
objetos
(desenvolvimento
para
a
reutilização).
Uma
vez
implementados, os componentes são armazenados num repositório
para
posterior
engenheiro
componentes
de
de
reutilização.
software,
um
na
domínio
Numa
etapa
ferramenta
do
subseqüente,
MVCASE,
problema
consulta
disponíveis
o
os
no
repositório. Após a identificação dos componentes necessários,
constroem-se as aplicações que os reutilizam (desenvolvimento
78
Capítulo 6 – Abordagem de DBCD
com reutilização). Conforme mostra a Figura 15, os principais
mecanismos
da
abordagem
são:
a
ferramenta
MVCASE
e
o
engenheiro de software. A abordagem é orientada pelo framework
Persistence,
DAP,
um
por
técnicas
Middleware
e,
do
método
Catalysis,
finalmente,
pelo
pelo
padrão
repositório
de
cada
da
componentes.
Segue-se
uma
apresentação
detalhada
de
etapa
abordagem.
Figura 15 - Abordagem de DBCD.
6.3.1 Desenvolver Componentes Distribuídos
Nesta etapa, que corresponde ao padrão Distributed Component
Development Pattern (DCDP) [Almeida, 2002b], os componentes do
domínio do problema são construídos em quatro passos: Definir
Problema,
Especificar
Componentes,
Projetar
Componentes
e
Implementar Componentes, conforme mostra a Figura 16. Os três
primeiros passos correspondem, em parte, aos três primeiros
níveis de Catalysis, conforme é mostrado à direita da figura.
79
Capítulo 6 – Abordagem de DBCD
No
último
passo,
a
implementação
física
dos
componentes
é
realizada.
Figura 16 - Passos do Desenvolvimento dos Componentes
Distribuídos.
Segue-se uma apresentação de cada passo da etapa Desenvolver
Componentes Distribuídos. Para facilitar o entendimento das
entradas, saídas e controles de cada passo, será utilizado
como exemplo um Domínio do Problema de Ordem de Serviços (OS)
de uma empresa do ramo de computação.
As aplicações do domínio de Ordem de Serviços se dividem em
três grandes módulos: o primeiro, Clientes, é responsável pelo
cadastro e notificação dos clientes de uma determinada ordem
de
serviço;
o
segundo,
Funcionários,
é
responsável
pelo
cadastro de funcionários e controle das tarefas da ordem de
serviço; o terceiro, Relatórios, é responsável pela emissão de
relatórios para a gerência, relacionados com a consulta de
tarefas
realizadas
e
pendentes,
ordens
de
serviços
de
determinado cliente, e dos funcionários responsáveis por cada
tarefa.
80
Capítulo 6 – Abordagem de DBCD
6.3.1.1 Definir Problema
Neste
primeiro
passo
entendimento
do
componentes
devem
Inicialmente,
usando
problema,
são
técnicas
da
atender
abordagem
dada
especificando-se
para
identificados
como
é
os
storyboards
no
quê”
os
“o
solucionar
o
requisitos
ou
ênfase
do
mind-maps
problema.
domínio,
[Pressman,
2001], visando representar as diferentes situações e cenários
do
domínio
do
problema.
Em
identificados são especificados em
seguida,
os
requisitos
Modelos de Colaborações,
representando a coleção de ações e os objetos participantes.
Finalmente,
os
Modelos
de
Colaborações
são
refinados
em
Modelos de Casos de Uso.
A Figura 17 resume o primeiro passo da abordagem, onde um
mind-map, definido na identificação dos requisitos do domínio
Ordem de Serviços, é especificado num Modelo de Colaboração,
e, posteriormente, refinado e particionado em um Modelo de
Casos de Uso, visando diminuir a complexidade e melhorar o
entendimento do domínio do problema.
Figura 17 - Primeiro Passo da Abordagem: Definir Problema.
81
Capítulo 6 – Abordagem de DBCD
6.3.1.2 Especificar Componentes
Este passo corresponde ao segundo nível de Catalysis, onde é
descrito o comportamento externo do sistema de uma forma não
ambígua. Na ferramenta CASE, o engenheiro de software refina
as
especificações
do
passo
anterior,
visando
obter
as
modelos
do
especificações dos componentes.
Esse
passo
domínio
do
tem
início
problema.
O
com
o
refinamento
Modelo
de
Tipos
dos
é
especificado,
conforme mostra a Figura 18, mostrando atributos e operações
dos tipos de objetos, sem se preocupar com a implementação.
Ainda neste passo, pode-se utilizar o dicionário de dados,
para especificar cada tipo encontrado, e a Object Constraint
Language (OCL) [OMG, 2001], para detalhar o comportamento dos
objetos, sem ambigüidades.
Figura 18 - Modelo de Tipos do passo Especificar
Componentes.
Uma vez identificados e especificados, os tipos são agrupados
em Framework de Modelos. Framework de Modelos são projetados
em
um
alto
genérico
nível
que
de
pode
abstração,
ser
estabelecendo
importado,
com
um
esquema
substituições
e
extensões, de modo a gerar aplicações específicas [D’Souza,
1999].
A
concebido
artefato
Figura
como
um
19
mostra
Framework
reutilizável
da
este
de
fase
framework.
Modelos,
de
Adicionalmente
este
projeto.
se
Como
torna
o
um
projeto
representa a maior parte das decisões que vão estar no código
82
Capítulo 6 – Abordagem de DBCD
final, pode-se especificar esses frameworks num alto nível de
abstração e oferecer um processo para refiná-los até o nível
de um conjunto de componentes interoperáveis [D’Souza, 1999].
Figura 19 - Framework de Modelos do domínio Ordem de
Serviços.
Os tipos com nomes entre os sinais <> são definidos como
placeholders. Esses tipos podem ser substituídos em aplicações
específicas. O conceito é similar ao de extensibilidade de
classes
no
paradigma
orientado
a
objetos.
O
Framework
de
Modelos do domínio Ordem de Serviços pode ser reutilizado em
diversas aplicações do domínio. A Figura 20 mostra o Modelo de
Aplicação
do
Framework
deste
domínio.
Neste
framework,
os
tipos com placeholders são substituídos pelos seus respectivos
tipos.
Figura 20 - Modelo de Aplicação do Framework.
83
Capítulo 6 – Abordagem de DBCD
Ainda
neste
passo,
os
Modelos
de
Casos
de
Uso
do
passo
anterior são refinados em Modelos de Interações, representados
pelos diagramas de seqüências, para detalhar os cenários de
utilização
dos
componentes
nas
diferentes
aplicações
do
domínio do problema.
Em
resumo,
as
atividades
deste
passo,
realizadas
pelo
engenheiro de software, na ferramenta MVCASE, compreendem a
especificação do:
a) Modelo de Tipos;
b) Framework de Modelos;
c) Modelo de Aplicação do Framework;
d) Modelos de Interações, representados pelos diagramas de
seqüência, baseados nos Modelos de Casos de Uso.
Estes modelos são utilizados no próximo passo da abordagem,
para obter o projeto interno dos componentes.
6.3.1.3 Projetar Componentes
Neste
passo,
interno
dos
Catalysis,
o
engenheiro
componentes,
e
especifica
de
software
conforme
outros
o
realiza
terceiro
requisitos
não
o
projeto
nível
de
funcionais,
destacando-se: arquitetura distribuída, tolerância a falhas,
caching e persistência.
Inicialmente, os Modelos de Tipos são refinados em Modelos de
Classes, onde são modeladas as classes e seus relacionamentos,
levando em consideração a definição dos componentes com suas
interfaces. A Figura 21 mostra parte do Modelo de Classes do
domínio
de
representados
Ordem
de
através
Serviços.
dos
Os
Modelos
diagramas
de
de
Interações,
seqüência,
são
refinados para mostrar detalhes de projeto dos comportamentos
dos métodos em cada classe.
84
Capítulo 6 – Abordagem de DBCD
Figura 21 - Modelo de Classes obtido do Modelo de Tipos.
A
partir
do
Modelo
de
Classes,
utiliza-se
o
Distributed
Adapters Pattern (DAP) para projetar o Modelo de Componentes,
onde a organização e as dependências entre os componentes são
definidas.
6.3.1.3.1 Aplicando o DAP
A Figura 22 mostra o projeto do Modelo de Componentes após a
aplicação
abstraem
interface
do
as
DAP.
regras
Os
componentes
de
ICustomer
negócio
abstrai
o
Source
do
e
domínio
comportamento
CustomerTarget
do
do
problema.
A
componente
CustomerTarget num cenário distribuído. Tanto esta interface
como
os
componentes,
Source
e
CustomerTarget,
não
possuem
código de distribuição. Esses três elementos constituem uma
camada independente de distribuição, conforme é mostrado na
parte
superior
da
Figura.
Os
demais
componentes
estão
conectados a uma API específica de distribuição e encapsulam
os detalhes de comunicação.
85
Capítulo 6 – Abordagem de DBCD
Figura 22 - Modelo de Componentes após aplicar o DAP.
Uma vez projetados os componentes, pode-se projetar outros
requisitos não funcionais.
6.3.1.3.2 Outros requisitos não funcionais
Os adaptadores anteriormente apresentados tratam com detalhes
básicos de distribuição e ocultam estes detalhes do código de
negócio e de interface. Estes podem, também, adicionar outros
requisitos não funcionais, mantendo a integridade da camada
independente de distribuição. Nesta seção, será mostrado como
os adaptadores podem realizar a adição destes requisitos, que
podem ser úteis para projetar componentes distribuídos [Alves,
2001a].
i. Tolerância a Falhas. O componente SourceAdapter não possui
mecanismo de tolerância a falhas. Assim, se ocorrer um erro de
comunicação
simplesmente,
ou
se
gera
o
uma
servidor
exceção
estiver
de
indisponível,
comunicação.
No
este,
entanto,
este componente pode, adicionalmente, implementar mecanismos
de tolerância a falhas.
86
Capítulo 6 – Abordagem de DBCD
Se o componente SourceAdapter recebe uma exceção remota
quando interage com o TargetAdapter, ele pode implementar a
política
de
tentar
contactar
o
TargetAdapter
novamente
durante um certo período de tempo, ou tentar contactar outro
TargetAdapter.
Esta
política
pode
ser
implementada
pelo
SourceAdapter de maneira transparente à camada independente
de distribuição.
ii.
Caching.
Algumas
operações
podem
retornar
uma
considerável quantidade de dados, entretanto somente parte
deles será útil em determinado momento. Enviar todos os dados
de uma só vez para o cliente pode não ser desejável, uma vez
que pode causar um impacto negativo de performance na rede.
Uma possível solução é enviar um cache com parte dos dados
necessários e transferir mais dados à medida em que uma falha
ocorra.
Um
componente
SourceAdapter
pode
implementar
este
comportamento de caching. Quando uma operação de consulta
retorna muitas entradas, parte destas são utilizadas para
inicializar um SourceAdapter. Um cliente, por exemplo, um
Servlet, pode obter as entradas deste adaptador.
Quando uma falha ocorre num SourceAdapter, este contacta o
TargetAdapter,
a
fim
de
obter
mais
entradas.
Este
comportamento de caching é implementado pelo SourceAdapter de
forma totalmente transparente ao cliente.
iii. Persistência dos Dados. A fim de facilitar o acesso a
banco de dados, o engenheiro de software pode reutilizar os
componentes
do
Framework
Persistence,
apresentado,
anteriormente, na seção 6.2.
Em
resumo,
os
principais
artefatos
e
a
seqüência
de
atividades do passo Projetar Componentes incluem:
a) Refinamento dos Modelos de Tipos em Modelos de Classes;
b) Refinamento dos Modelos de Interações; e
c) Criação do Modelo de Componentes.
87
Capítulo 6 – Abordagem de DBCD
6.3.1.4 Implementar Componentes
Neste passo, o engenheiro de software define a tecnologia de
distribuição e, então, utiliza o gerador de código, da MVCASE,
para
otimizar
projetados.
as
tarefas
Nesta
de
implementação
situação,
CORBA
dos
foi
componentes
escolhida
como
tecnologia de distribuição, porém, outras tecnologias, como
RMI,
JAMP
[Trevelin,
2001]
e
JINI
[Sun,
2002b],
também
poderiam ser utilizadas.
Assim, para cada componente, têm-se os stubs, skeletons e as
interfaces
que
disponibilizam
os
seus
serviços.
Esses
componentes são customizados pelo engenheiro de software e, em
seguida, são armazenados no repositório de componentes, a fim
de serem reutilizados no desenvolvimento das aplicações. Os
aspectos envolvendo os testes dos componentes são discutidos
na seção 6.4.
A
Figura
23
mostra
o
processo
de
geração
de
código
dos
componentes projetados na MVCASE.
Figura 23 - Geração de código na ferramenta MVCASE.
Uma vez construídos os componentes do domínio do problema,
passa-se para a segunda etapa da abordagem de DBCD, onde o
88
Capítulo 6 – Abordagem de DBCD
engenheiro de software desenvolve as aplicações que reutilizam
estes componentes.
6.3.2 Desenvolver Aplicações Distribuídas
A
Figura
24
mostra
os
passos
para
o
desenvolvimento
das
aplicações. Parte-se dos requisitos da aplicação e procede-se
com
o
ciclo
Especificar
de
desenvolvimento
Aplicação,
Projetar
normal,
Aplicação
que
compreende:
e
Implementar
Aplicação. Os componentes construídos, do domínio do problema,
ficam
disponíveis
componentes.
Do
para
mesmo
reutilização
modo
que
no
no
repositório
desenvolvimento
de
dos
componentes, a MVCASE é o principal mecanismo para auxiliar o
engenheiro de software durante o desenvolvimento.
Figura 24 - Desenvolvimento das Aplicações Distribuídas.
Para
melhor
compreensão
destas
etapas,
é
apresentada
uma
aplicação que registra, via Web, um cliente do domínio Ordem
de Serviços, cujos componentes foram construídos.
89
Capítulo 6 – Abordagem de DBCD
6.3.2.1 Especificar Aplicação
Este
passo
tem
início
com
o
entendimento
do
problema,
identificando-se os requisitos da aplicação. Antes de iniciar
a
especificação
dos
requisitos
da
aplicação,
na
MVCASE,
o
engenheiro de software importa os componentes do domínio do
problema, no caso Ordem de Serviços, que estão disponíveis no
repositório, para reutilização. Em seguida, os requisitos são
especificados
em
Modelos
de
Casos
de
Uso
e
Digramas
de
Seqüência.
6.3.2.2 Projetar Aplicação
As
especificações
do
passo
anterior
são
refinadas
pelo
engenheiro de software, a fim de obter o projeto da aplicação.
Neste
passo,
arquitetura
os
requisitos
distribuída
e
não
à
funcionais,
persistência
relacionados
dos
dados,
à
são
especificados.
Assim, continuando o processo de modelagem, o engenheiro de
software
especifica
o
modelo
de
componentes
da
aplicação.
Neste caso, o componente ServletAddCustomer foi desenvolvido,
de modo a reutilizar os serviços dos componentes do domínio
Ordem de Serviços. A Figura 25 mostra os três componentes
reutilizados na aplicação de registro de um cliente.
Figura 25 - Componentes Reutilizados para Aplicação Registrar
Cliente.
90
Capítulo 6 – Abordagem de DBCD
Em seguida, os componentes FacadePersistent, TableManager,
DriversUtil e ConnectionPool, do
framework Persistence, são
adicionados para tratar do acesso ao banco de dados, conforme
mostra a Figura 26.
Figura 26 - Projeto da Aplicação Distribuída.
Uma vez realizado o projeto da aplicação, o engenheiro de
software prepara o ambiente para sua execução.
6.3.2.2.1 Preparar Ambiente
Para distribuir uma aplicação é necessária a escolha de uma
particular plataforma. Para esta plataforma, existem algumas
informações
de
configuração,
como
localização
do
servidor,
número de porta, entre outras.
A
Figura
27
estruturada,
utilizando
mostra
através
um
como
da
a
aplicação
extensão
middleware,
por
do
distribuída
modelo
exemplo,
CORBA,
Object
a
é
Web,
fim
de
acomodar os repositórios de componentes. Na primeira camada,
tem-se
a
HyperText
interface
da
Transfer
Protocol
enviadas
e
Web.
segunda
Na
recebidas
dos
camada,
aplicação.
(HTTP),
Servlets,
o
Através
servidor
as
da
requisições
disponíveis
web
comunicação
no
são
Servidor
comunica-se
com
o
91
Capítulo 6 – Abordagem de DBCD
Servidor de Componentes, o qual disponibiliza os componentes
do
domínio
do
problema
armazenados
no
repositório.
Esta
comunicação é realizada via Object Request Broker (ORB). Na
terceira camada está o banco de dados com seu servidor. A
comunicação entre o Servidor de Componentes e o Servidor de
Banco de Dados, via Java Database Connectivity (JDBC), permite
o acesso aos serviços de banco de dados.
Figura 27 - Modelo Object Web Estendido.
6.3.2.3 Implementar Aplicação
Por último, baseado no projeto da aplicação, o engenheiro de
software utiliza o gerador de código da MVCASE para realizar
sua
implementação
e,
em
seguida,
realiza
as
adaptações
necessárias. A Figura 28 mostra parte do código gerado para
aplicação de registrar um cliente.
92
Capítulo 6 – Abordagem de DBCD
Figura 28 - Implementação da Aplicação Registrar
Cliente.
Uma vez concluído o passo Implementar Aplicação, o engenheiro
de software realiza os testes envolvendo as aplicações.
6.4
Testes
envolvendo
os
componentes
e
as
aplicações
Os testes dos componentes e aplicações são realizados em três
etapas:
teste
consistência
dos
com
o
componentes
domínio
e
individuais,
teste
das
teste
de
aplicações
que
reutilizam os componentes desenvolvidos.
i. Dentro de um particular domínio, cada componente é testado
individualmente através da construção de um simples caso de
teste, que permite validar as funcionalidades exercidas pelo
componente.
ii. Em seguida, são realizados os testes para verificar a
consistência interna entre os componentes do domínio.
iii.
Por
fim,
antes
de
serem
colocadas
em
produção,
as
aplicações são submetidas a uma longa série de testes.
O
domínio
abordagem,
de
Ordem
foi
apresentadas.
Os
de
testado
testes
Serviços,
construído
servindo-se
auxiliaram
dessas
a
utilizando
três
corrigir
a
etapas
erros
em
93
Capítulo 6 – Abordagem de DBCD
diferentes fases do processo de desenvolvimento, resultando em
melhorias em cada etapa da abordagem e no refinamento dos
mecanismos de integração.
6.5 Avaliação da Abordagem
Segundo
a
hipótese
levantada
por
Kitchenham
[1995],
que
ressalta que um bom estudo de caso, apesar de não possuir o
rigor dos experimentos formais, pode ser adequado para avaliar
os benefícios advindos da utilização de um método ou processo
em um determinado contexto, o domínio de Ordem de Serviços foi
desenvolvido e analisado. Esta seção descreve este processo,
discutindo sua viabilidade e utilidade.
6.5.1 Introdução
Conforme Kitchenham [1995], um bom estudo de caso pode prover
informações suficientes para auxiliar a julgar se um método
específico irá trazer benefícios ou não em um contexto. O
estudo de caso descrito neste capítulo está de acordo com a
definição dada pela autora para estudo de caso, uma vez que
foi
aplicado
desenvolvimento
Ordem
de
em
um
de
Serviços,
projeto
típico,
componentes
e
não
e
que
é
aplicações
apresenta
o
projeto
de
no
domínio
de
replicação,
o
que
é
necessário no caso de experimentos formais.
6.5.2 A abordagem
Para a realização do estudo de caso, seguiu-se a sistemática
apresentada
em
[Kitchenhan,
1995],
que
sugere
três
etapas
distintas na elaboração de um estudo de caso:
•
Planejamento: Consiste na definição do estudo de caso,
identificando-se os participantes e os objetivos a serem
alcançados;
94
Capítulo 6 – Abordagem de DBCD
•
Monitoração: Refere-se ao acompanhamento da execução de
cada etapa do estudo, registrando-se o tempo de duração
e os resultados obtidos;
•
Avaliação dos resultados: Corresponde à descrição dos
resultados gerais obtidos no estudo, utilizando os dados
da monitoração.
6.5.2.1 Planejamento
Um
projeto
abordagem,
piloto
com
o
foi
estabelecido
objetivo
de
se
para
a
desenvolver
aplicação
da
componentes
e
aplicações para o domínio de Ordem de Serviços.
Estabeleceu-se que todas as etapas constantes da abordagem
seriam realizadas e, ao final, ter-se-ia uma validação, ainda
informal,
das
vantagens
e
desvantagens
oferecidas
com
a
utilização da abordagem.
Os mecanismos utilizados pela abordagem foram:
a)
Java, como linguagem de implementação;
b)
HTML
e
Servlets,
para
criação
de
interfaces
de
usuário através da internet;
c)
MySQL, para persistência dos dados;
d)
CORBA, como tecnologia de distribuição.
Os participantes do processo foram dois estudantes de pósgraduação (E1 e E2), com um ano de experiência nos mecanismos
mencionados.
6.5.2.2 Monitoração
Durante a fase de monitoração, procurou-se registrar o tempo e
os
resultados
registros
obtidos
foram
feitos
de
cada
com
o
etapa
da
objetivo
abordagem.
de
permitir
Estes
uma
avaliação dos resultados deste estudo.
Inicialmente, com base nos requisitos do domínio do problema,
E1 e E2 realizaram uma análise inicial do domínio, a fim de
95
Capítulo 6 – Abordagem de DBCD
obter seu entendimento. Em seguida, já com a abordagem em
mãos, estes realizaram sua execução passo a passo. Na etapa
Definir
Problema,
os
requisitos
do
domínio
foram
identificados, utilizando a técnica de mind-maps. Com base nos
requisitos
do
colaboração
domínio,
e,
em
foram
seguida,
especificados
os
modelos
de
os
modelos
casos
de
de
uso.
Primeiramente, um modelo de caso de uso global foi definido e,
em seguida, este modelo foi particionado em pacotes, com seus
respectivos modelos (ex: pacote cliente, tarefa).
A partir do refinamento das especificações do passo anterior,
E1 e E2 iniciaram o passo subseqüente. Neste passo, foram
desenvolvidos o modelo de tipos, o framework de modelos, o
modelo de aplicação do framework e os modelos de interações
para cada caso de uso.
Após a conclusão da especificação dos componentes, E1 e E2
iniciaram seu projeto. O modelo de tipos da etapa anterior
foi,
inicialmente,
refinado
no
modelo
de
classes.
O
mesmo
procedimento de refinamento adotado para os modelos de caso de
uso foi adotado. Em seguida, o padrão DAP foi aplicado para
cada classe de negócio identificada. Adicionalmente, outros
requisitos
não
funcionais
foram
projetados,
como
caching
e
persistência. Os modelos de interações da etapa anterior foram
refinados, adicionando as classes com a estrutura do DAP. Por
último, E1 e E2 criaram o modelo de componentes do domínio.
Uma
vez
realizaram
Tabela
5
projetados
sua
resume
os
componentes
implementação
os
etapa da abordagem.
artefatos
e,
em
do
domínio,
seguida,
os
disponibilizados
E1
e
testes.
na
E2
A
primeira
96
Capítulo 6 – Abordagem de DBCD
Tabela 5 - Artefatos disponibilizados.
Etapa
Definir Problema
Especificar Componentes
Projetar Componentes
Implementar Componentes
Artefatos
Qt.
Mind-Map
Modelo de Colaboração
Modelo de Casos de Uso
Modelo de Tipos
Dicionário de Dados
Framework de Modelos
Modelo de Aplicação do
Framework
Modelo de Interação
Modelo de Classes
Modelo de Interação
Modelo de Componentes
Interfaces
Componentes
1
1
1
1
1
1
1
18
5
18
5
16
24
Após a conclusão da primeira etapa, E1 e E2 iniciaram a etapa
subseqüente.
aplicações
aplicações
através
O
desenvolvimento
resultaram
e
do
3812
num
linhas
programa
total
de
wc
dos
de
código
(word
componentes
24
e
suas
componentes,
desenvolvidas,
count)
do
18
medidas
UNIX,
não
contabilizando as linhas em branco, comentários e bibliotecas
do Java utilizadas. O tempo total de desenvolvimento foi de 60
horas e 13 minutos.
6.5.2.3 Avaliação dos Resultados
Após esta avaliação, identificou-se a possibilidade de que,
com
a
utilização
da
abordagem
proposta,
a
qual
orienta
o
engenheiro de software no desenvolvimento dos componentes e
aplicações de um domínio, pode-se obter, ao fim do processo,
um software de melhor qualidade, comparada a uma abordagem adhoc.
Utilizando a abordagem, obtêm-se os seguintes benefícios:
i.
Modularidade:
a
abordagem
permite
separar,
sistematicamente, os aspectos de distribuição e persistência,
evitando o entrelaçamento de código com diferentes propósitos;
ii. Reutilização: através dos artefatos disponibilizados,
a abordagem permite a reutilização desde modelos de alto nível
97
Capítulo 6 – Abordagem de DBCD
de abstração (Framework de Modelos) até código, otimizando e
melhorando as tarefas de desenvolvimento;
iii.
Automação
parcial:
com
o
suporte
da
ferramenta
MVCASE, grande parte das atividades propostas pela abordagem
podem ser executadas automaticamente;
iv.
Definir
componentes
de
mudanças
forma
no
código
minimizada,
de
através
comunicação
da
dos
utilização
do
padrão DAP.
Mesmo
com
as
vantagens
listadas
acima,
as
seguintes
desvantagens foram identificadas:
i.
Commercial
abordagem
foi
off-the
shelf
inicialmente
(COTS):
projetada
o
modo
não
como
a
considera
a
possibilidade de utilizar componentes adquiridos de terceiros;
ii. Número incremental de componentes: de modo a utilizar
o padrão DAP, torna-se necessária a utilização de um par de
adaptadores,
nomeação.
assim
Por
serem
como
componentes
estruturas
de
inicialização
canônicas,
estas
podem
e
ser
geradas através da automação parcial utilizando a ferramenta
MVCASE.
6.6 Resumo
Este
capítulo
descreveu
Software
Baseado
pesquisa
deste
em
a
Abordagem
Componentes
trabalho,
de
Desenvolvimento
Distribuídos,
apresentando
os
objetivo
mecanismos
de
de
que
oferecem suporte a sua execução e discutindo, detalhadamente,
suas
duas
grandes
etapas.
Em
seguida,
foi
apresentada
a
abordagem utilizada para o processo de teste e, por fim, foi
discutido
um
processo
inicial
de
validação,
ao
qual
a
abordagem foi submetida.
O capítulo seguinte apresenta um estudo experimental, que
analisa a viabilidade de aplicação da abordagem proposta no
desenvolvimento
distribuídos.
de
software
baseado
em
componentes
Capítulo 7
Estudo Experimental
7.1 Introdução
Com o término da década de 90, houve um crescimento acelerado
do
número
de
métodos,
técnicas
e
ferramentas,
cada
uma,
oferecendo melhorias em determinadas etapas do software, como
no
processo
adoção
de
desenvolvimento
inadequada
e
e
manutenção.
desenfreada
desses
Entretanto,
mecanismos
a
pode
resultar em grandes problemas para os seus usuários finais e
empresas.
Tendo
em
vista
esses
fatores,
pesquisas
sugerem
[Basili,
1986], [Basili, 1993], [Kitchenham, 1995], [Wohlin, 2000] a
necessidade
de
um
rigoroso
e
sistemático
processo
experimental, a fim de avaliar novas tecnologias e compará-las
com outras já existentes, antes de colocá-las em produção,
assim como mensurar os seus impactos nas empresas, processos e
produtos.
Deste modo, este capítulo apresenta um estudo experimental
que avalia a viabilidade de utilização da abordagem proposta
para
o
desenvolvimento
de
software
baseado
em
componentes
distribuídos.
Antes
de
discutir
o
processo
experimental
adotado,
é
necessário introduzir algumas definições, de modo a obter um
melhor
entendimento
dos
seus
elementos.
A
seção
seguinte
99
Capítulo 7 – Estudo Experimental
apresenta
essas
definições
e
alguns
exemplos,
a
fim
de
estudar
os
variáveis
de
melhorar a sua compreensão.
7.2 Terminologia Utilizada
Quando
um
experimento
resultados
quando
se
é
realizado,
diversificam
deseja-se
algumas
das
entrada para um processo. Segundo [Wohlin, 2000], existem dois
tipos
de
variáveis
em
um
experimento:
independente
e
dependente, conforme mostra a Figura 29.
Variáveis
Independentes
Variável
Dependente
Processo
Figura 29 – Tipos de Variáveis em um Experimento.
A variável objeto de estudo, a qual se deseja analisar os
efeitos de mudanças das variáveis independentes, é chamada de
variável
dependente
ou
variável
de
resposta.
Geralmente,
existe apenas uma variável dependente em um experimento. Em
contrapartida,
manipuladas
todas
e
as
variáveis
controladas,
em
são
um
processo,
chamadas
de
que
são
variáveis
independentes. O exemplo a seguir, extraído de [Wohlin, 2000],
serve para realçar essas definições.
Ex1:
Deseja-se
estudar
os
efeitos
de
um
novo
método
de
desenvolvimento sobre a produtividade das pessoas. Assim, é
necessário
efetuar
a
escolha
para
introduzir
um
método
orientado a objetos ou uma abordagem funcional. A variável
dependente,
neste
exemplo,
é
a
produtividade.
As
variáveis
independentes são: o método de desenvolvimento, a experiência
das pessoas, as ferramentas de suporte e o ambiente utilizado
para execução.
Em um experimento, estuda-se o efeito de mudanças de uma ou
mais variáveis independentes. Essas variáveis são chamadas de
fatores. As demais variáveis independentes são controladas em
um
nível
fixo
durante
o
experimento,
permitindo,
assim,
100
Capítulo 7 – Estudo Experimental
verificar
se
um
esperado. Um
fator
ou
tratamento
outra
variável
causa
o
efeito
é um valor particular do fator. O
exemplo a seguir [Wohlin, 2000] permite diferenciar essas duas
novas definições.
Ex2: O fator no experimento citado em Ex1 é o método de
desenvolvimento, uma vez que se deseja estudar os efeitos de
sua
mudança.
tratamentos
Ainda
para
neste
o
experimento,
fator:
o
velho
são
e
utilizados
o
novo
dois
método
de
através
da
desenvolvimento.
Os
tratamentos
são
inicialmente
aplicados
combinação de objetos e participantes. Um objeto pode ser, por
exemplo, um documento que deve ser revisado com diferentes
técnicas de inspeção. As pessoas que aplicam o tratamento são
chamadas de participantes. O exemplo três apresenta de forma
resumida essas definições [Wohlin, 2000].
Ex3: Os objetos, no experimento descrito anteriormente, são
os
programas
a
serem
desenvolvidos
e
os
participantes
correspondem à equipe responsável pelo desenvolvimento.
Um experimento consiste em um conjunto de testes, onde cada
teste
é
uma
combinação
de
tratamentos,
objetos
e
participantes. O exemplo quatro resume essa última definição
[Wohlin, 2000].
Ex4:
Um
teste
(participantes)
pode
utilizam
ser
o
aquele
novo
em
método
que
de
n
pessoas
desenvolvimento
(tratamento) para desenvolver um programa x (objeto).
Após a definição das terminologias utilizadas na área de
engenharia
de
software
experimental,
será
apresentado
um
estudo utilizado para avaliar a viabilidade da abordagem de
desenvolvimento
de
software
baseado
em
componentes
distribuídos.
7.3 Estudo Experimental
Segundo [Wohlin, 2000], a realização de um estudo experimental
pode ser dividida em cinco fases: a definição, o planejamento,
101
Capítulo 7 – Estudo Experimental
a execução, a análise e o empacotamento do estudo. A definição
é a primeira fase, onde se define o experimento em função do
problema,
objetivos
e
metas.
O
planejamento
envolve
a
descrição do perfil dos participantes, dos instrumentos, do
processo de execução e uma avaliação dos problemas que podem
vir a ocorrer durante sua execução. A execução consiste na
realização
do
utilizando
estudo
os
experimental
instrumentos
e
pelos
o
participantes,
processo
definidos
anteriormente. A fase de análise consiste na organização dos
resultados gerados pelos participantes durante a execução e a
realização de inferências sobre estes resultados. Finalmente,
o empacotamento consiste na organização e armazenamento dos
artefatos previamente construídos.
O plano de experimento apresentado a seguir segue o modelo
proposto
por
[Wohlin,
2000].
As
etapas
de
definição
e
planejamento, apresentadas nas próximas seções, são descritas
em tempo verbal futuro, simbolizando a precedência do plano à
execução.
7.3.1 Definição do Estudo Experimental
Objeto de Estudo: a utilização da abordagem no projeto de
desenvolvimento
de
software
baseado
em
componentes
distribuídos, para avaliação do comportamento deste projeto.
Objetivo:
abordagem
identificar
no
a
viabilidade
desenvolvimento
de
de
utilização
software
da
baseado
em
utilização
da
componentes distribuídos.
Foco
de
abordagem
Qualidade:
proposta,
os
ganhos
medidos
obtidos
através
do
pela
número
de
modelos,
número de classes, número de componentes, número de grupos
para
classificação
dos
componentes,
número
de
aplicações,
tempo de desenvolvimento e as dificuldades encontradas pelos
usuários em seu entendimento e utilização.
Perspectiva: o estudo será desenvolvido sob o ponto de vista
do
pesquisador,
avaliando
a
viabilidade
de
utilização
da
102
Capítulo 7 – Estudo Experimental
abordagem, tendo em vista a continuidade no desenvolvimento
das pesquisas relacionadas com a mesma.
Contexto:
o
desenvolvimento
componentes
distribuídos,
requisitos
especificados
de
definido
pela
software
em
baseado
laboratório,
equipe
de
em
com
definição
os
do
experimento baseado em projetos reais. O estudo será conduzido
no formato de múltiplos testes sobre um objeto.
Assim, utilizando uma notação baseada em Goal Question Metric
Paradigm (GQM) [Basili, 1994], temos:
Analisar
a
utilização
da
abordagem
no
desenvolvimento
de
software baseado em componentes distribuídos
Com
o
propósito
de
caracterizar
a
viabilidade
de
sua
utilização e continuidade de desenvolvimento
Referente
aos
ganhos
decorrentes
de
sua
utilização
de
software
e
as
baseado
em
dificuldades de seu emprego
Do ponto de vista do pesquisador
No
contexto
do
desenvolvimento
componentes distribuídos.
Uma vez definido o experimento, a seção seguinte apresenta o
seu planejamento.
7.3.2 Planejamento do Estudo Experimental
Após a definição do experimento, a fase de planejamento se
inicia. A definição do experimento determina a base para o
experimento, ou seja, o “porquê” da realização do experimento,
enquanto
que
a
fase
de
planejamento
define
“como”
o
experimento será conduzido.
Segundo
[Wohlin,
experimento
pode
2000],
ser
a
fase
de
em
seis
dividida
planejamento
passos.
de
um
Baseado
na
definição do experimento, realiza-se a seleção do contexto,
onde é selecionado o ambiente para o qual o experimento será
executado. Em seguida, são feitas a formulação da hipótese e a
seleção das variáveis independentes e dependentes. A seleção
dos
participantes
é
efetuada.
O
projeto
experimental
é
103
Capítulo 7 – Estudo Experimental
escolhido baseado nas hipóteses e variáveis selecionadas. Em
seguida, a etapa de instrumentação realiza a preparação para a
implementação
do
experimento.
Por
último,
a
validação
é
realizada, a fim de viabilizar o experimento.
Em
seguida,
será
experimental,
apresentado
contemplando
o
planejamento
estas
seis
do
etapas
estudo
definidas
anteriormente, adotando a organização apresentada em [Barros,
2002].
Contexto: o objetivo deste estudo é avaliar a viabilidade da
utilização da abordagem de desenvolvimento de software baseado
em componentes distribuídos. Os participantes do estudo serão
requisitados a atuar como engenheiros de software de um mesmo
projeto
de
desenvolvimento,
disponibilizados
anteriormente.
cujos
Uma
requisitos
parte
dos
serão
participantes
receberá um treinamento para utilização da abordagem, enquanto
os
demais
utilizarão
apenas
os
conhecimentos
adquiridos
da
indústria ou universidade.
Treinamento:
o
treinamento
dos
participantes
que
irão
utilizar a abordagem será realizado em sala de aula e em um
laboratório de uma universidade, dividido em quatro sessões,
com duração estimada de quatro horas cada uma. Na primeira
sessão,
será
apresentada
a
ferramenta
MVCASE,
demonstrando
todas as suas funcionalidades oferecidas. Em seguida, serão
apresentados os principais mecanismos utilizados na abordagem.
Concluída esta sessão, a abordagem será exemplificada passo a
passo, acompanhada de sua utilização num caso de uso. Por
último,
na
quarta
desenvolvimento
de
sessão,
um
os
projeto
participantes
de
pequeno
realizarão
porte,
o
utilizando
todo o treinamento ministrado.
Projeto Piloto: antes da realização do estudo, será realizado
um
projeto
planejamento.
projeto.
Um
piloto
Apenas
com
a
dois
participante
mesma
estrutura
participantes
receberá
o
irão
definida
executar
treinamento
neste
este
para
utilização da abordagem e utilizará a mesma no desenvolvimento
104
Capítulo 7 – Estudo Experimental
do
projeto
proposto.
desenvolvimento
com
durante
sua
formação
participantes
utilizarão
documento
e
irão
O
base
outro
em
participante
seus
conhecimentos
acadêmica
o
contar
mesmo
com
um
realizará
e
adquiridos
profissional.
material
descrito
acompanhamento
o
Os
neste
integral
do
idealizador do estudo. Deste modo, o projeto piloto será um
estudo baseado em observação, servindo para detectar problemas
e aprimorar o material planejado antes da sua utilização.
Participantes: os participantes do estudo serão um conjunto
de desenvolvedores de software. O estudo será executado em um
ambiente acadêmico.
Instrumentação:
cada
participante
deverá
atuar
como
engenheiro de software, responsável pelo desenvolvimento do
projeto.
(QT1),
Todos
a
fim
experiência.
os
de
Os
participantes
obter
receberão
informações
participantes
sobre
treinados
um
questionário
sua
na
formação
utilização
e
da
abordagem irão receber um kit [Almeida, 2002c] contendo um
estudo de caso, contemplando todos os passos da abordagem, e a
ferramenta MVCASE, para execução da proposta. Este kit ainda
inclui
um
questionário
(QT2)
para
avaliação
do
nível
de
satisfação dos participantes na utilização desta abordagem.
Estes
dois
questionários
encontram-se
no
Apêndice
deste
trabalho.
Critérios: o foco de qualidade do estudo exige critérios que
avaliem os ganhos proporcionados pela utilização da abordagem
de
desenvolvimento
de
software
baseado
em
componentes
distribuídos e as dificuldades encontradas pelos usuários na
sua utilização. Os ganhos obtidos pela utilização da abordagem
serão avaliados quantitativamente (número de modelos, número
de
classes,
número
de
componentes,
número
de
grupos
para
classificação dos componentes, número de aplicações e tempo de
desenvolvimento). As dificuldades encontradas pelos usuários
na utilização da abordagem serão avaliadas através de dados
qualitativos, caracterizados no questionário QT2.
105
Capítulo 7 – Estudo Experimental
Hipótese Nula, H0: a hipótese nula é uma afirmativa que o
estudo experimental tem como objetivo negar. Neste estudo, a
hipótese nula determina que a utilização da abordagem para o
desenvolvimento
de
distribuídos
produz
utilização.
não
De
software
acordo
baseado
benefícios
com
os
que
em
componentes
justifiquem
critérios
a
sua
selecionados,
as
seguintes hipóteses podem ser definidas:
H0: µnúmero
de modelos sem abordagem
= µnúmero
de modelos com abordagem
H0: µnúmero
de classes sem abordagem
= µnúmero
de classes com abordagem
H0: µnúmero
de componentes sem abordagem
H0: µnúmero
de grupos para classificação dos componentes sem abordagem
= µnúmero
de componentes com abordagem
= µnúmero
de
grupos para classificação dos componentes com abordagem
H0: µnúmero
H0: µtempo
= µnúmero
de aplicações sem abordagem
de desenvolvimento sem abordagem
de aplicações com abordagem
= µtempo
de desenvolvimento com abordagem
Hipótese Alternativa: a hipótese alternativa é uma afirmativa
que
nega
objetivo
a
hipótese
provar
a
nula.
O
estudo
hipótese
experimental
alternativa,
tem
como
contrariando
a
hipótese nula. Neste estudo, a hipótese alternativa determina
que os participantes do estudo que utilizarem a abordagem de
desenvolvimento
de
software
baseado
em
componentes
distribuídos terão resultados superiores aos participantes que
utilizarem uma abordagem ad-hoc. De acordo com os critérios
selecionados, as seguintes hipóteses podem ser definidas:
H1: µnúmero
de modelos sem abordagem
< µnúmero
de modelos com abordagem
H2: µnúmero
de classes sem abordagem
< µnúmero
de classes com abordagem
H3: µnúmero
de componentes sem abordagem
H4: µnúmero
de grupos para classificação dos componentes sem abordagem
< µnúmero
de componentes com abordagem
< µnúmero
de
grupos para classificação dos componentes com abordagem
H5: µnúmero
H6: µtempo
de aplicações sem abordagem
< µnúmero
de desenvolvimento sem abordagem
de aplicações com abordagem
> µtempo
de desenvolvimento com abordagem
Variáveis Independentes: a principal variável independente do
estudo
é
um
indicador,
que
informa
se
o
participante
do
experimento utilizou ou não a abordagem de desenvolvimento de
106
Capítulo 7 – Estudo Experimental
software baseado em componentes distribuídos. A formação e a
experiência
dos
participantes,
coletadas
através
do
questionário QT1, também são informações independentes, que
poderão ser utilizadas durante a análise, para formação de
blocos.
Variáveis Dependentes: as variáveis dependentes são número de
modelos, número de classes, número de componentes, número de
grupos
para
classificação
dos
componentes,
número
de
aplicações e tempo de desenvolvimento.
Análise Qualitativa: tem o objetivo de avaliar a dificuldade
de aplicação da abordagem proposta e a qualidade do material
utilizado no estudo. Essa análise será realizada através do
questionário QT2. Esse questionário será de suma importância,
uma vez que, através de sua utilização, será possível avaliar
as
dificuldades
utilização
da
abordagem,
disponibilizado
realizar
encontradas
e
o
melhorias
do
nesses
pelos
avaliar
a
treinamento,
artefatos,
participantes
utilização
assim
a
fim
com
a
do
material
como,
permitir
de
replicar
o
experimento no futuro.
Seleção Randômica: esta técnica pode ser utilizada na seleção
dos participantes. Idealmente, os indivíduos que realizarão o
estudo devem ser selecionados aleatoriamente dentre o conjunto
de candidatos a participantes. Entretanto, a única ressalva
que se tem é a de que os mesmos sejam desenvolvedores de
software.
Balanceamento:
participantes
durante
serão
a
realização
distribuídos
em
do
estudo,
quantidade
similar
os
na
utilização da abordagem proposta e na utilização da abordagem
ad-hoc.
Validade Interna do estudo: a validade interna de um estudo é
definida
como
a
capacidade
de
um
novo
estudo
repetir
o
comportamento do estudo atual, com os mesmos participantes e
objetos com os quais este foi executado. A validade interna do
estudo é dependente do número de participantes que o executam.
107
Capítulo 7 – Estudo Experimental
Neste
estudo,
deseja-se
contar
com,
pelo
menos,
oito
participantes, o que garante um bom nível de validação interna
[Barros, 2002]. Certamente, um número maior de participantes
melhoraria a validade interna do estudo. Outro ponto que pode
influenciar o resultado é a troca de informações entre os
participantes. A fim de evitar este problema, requisitou-se,
explicitamente, que os participantes não troquem informações a
respeito do projeto.
Validade Externa do estudo: a validade externa do estudo mede
sua capacidade de ser afetada com a generalização [Wohlin,
2000], ou seja, essa validade mede a capacidade de refletir o
mesmo
comportamento
em
outros
grupos
de
pesquisas,
além
daquele em que o estudo foi aplicado. A validade externa do
estudo
é
avaliar
considerada
a
suficiente,
viabilidade
desenvolvimento
distribuídos.
de
de
aplicação
software
Demonstrada
visto
que
este
da
abordagem
baseado
esta
em
viabilidade,
objetiva
de
componentes
novos
estudos
podem ser planejados, a fim de refinar e melhorar a abordagem.
Validade de Construção do estudo: a validade de construção do
estudo se refere à relação entre a teoria que se deseja provar
e os instrumentos e participantes do estudo [Wohlin, 2000].
Neste
estudo,
relativamente
assim,
a
foi
escolhido
conhecido
utilização
e
da
de
um
fácil
experiência
domínio
do
problema
entendimento,
evitando,
dos
participantes
no
domínio. Esta escolha evita que experiências anteriores gerem
uma interpretação incorreta do impacto da abordagem proposta.
Validade de Conclusão do estudo: a validade de conclusão do
estudo
mede
a
determinando,
conclusões
relação
assim,
[Wohlin,
entre
a
o
tratamento
capacidade
2000].
Esta
do
e
o
estudo
conclusão
será
resultado,
de
gerar
traçada
a
partir da utilização do procedimento paramétrico de análise
estatística baseado na distribuição T [Wohlin, 2000].
108
Capítulo 7 – Estudo Experimental
7.3.3 Projeto Utilizado no Estudo Experimental
O
projeto
utilizado
no
estudo
experimental
foi
o
desenvolvimento de componentes e aplicações para um domínio de
comércio eletrônico, restringido para operações de compra e
venda de livros através da Internet, conforme resume a Figura
30.
A livraria NewTime, especializada em livros de matemática, computação,
física e química, deseja informatizar o seu processo de compra e venda de
livros, atuando através da Internet.
A livraria necessita de um software que permita realizar as seguintes
funcionalidades:
•
Cadastro, alteração, exclusão e consulta de seus clientes;
•
Cadastro, alteração, exclusão e consulta de seus livros com os
respectivos gêneros associados;
•
Cadastro, alteração, exclusão e consulta de seus fornecedores;
•
Compra de livros pelo cliente, desde que o mesmo esteja previamente
cadastrado. Caso a livraria não possua o livro em estoque, é
enviada uma requisição aos fornecedores e a compra é colocada no
estado de espera até que ocorra uma notificação por parte dos
fornecedores. Uma vez realizada essa notificação, a compra é
efetuada;
•
Emissão de relatórios para gerência, informando os livros vendidos e
sua respectiva quantidade;
Emissão de histórico das compras de um cliente.
•
Figura 30 - Descrição do Projeto de Desenvolvimento.
7.3.4 Instanciação do Estudo Experimental
Seleção dos Participantes: para a execução do estudo, foram
selecionados os participantes dentre os alunos dos cursos de
Graduação em Ciência da Computação e Engenharia de Computação,
e Mestrado em Ciência da Computação da Universidade Federal de
São Carlos, na linha de pesquisa de Sistemas Distribuídos.
Estes
participantes
indicadas,
visto
participantes
representando
atendem
que
são
foram
um
às
restrições
desenvolvedores
selecionados
subconjunto
não
de
por
aleatório
previamente
software.
Os
conveniência,
do
universo
de
alunos.
Capacidade Aleatória: a seleção dos participantes do estudo
não
foi
indivíduos
aleatória,
para
o
pois
considerou
estudo.
De
a
disponibilidade
posse
dos
nomes
dos
dos
109
Capítulo 7 – Estudo Experimental
participantes, os alunos de Graduação ficaram incumbidos de
utilizar
a
abordagem
e
os
alunos
de
sistemas
distribuídos
usariam os conhecimentos adquiridos ao longo de sua formação
acadêmica e profissional.
Mecanismos de Análise: para avaliação das hipóteses do estudo
serão utilizados mecanismos de estatísticas descritivas, como,
por exemplo, a Média.
7.3.5 Execução do Estudo Experimental
Realização: o estudo experimental foi realizado durante parte
de
um
curso
Distribuídos,
2002,
na
de
graduação
durante
o
Universidade
e
segundo
pós-graduação
semestre
Federal
de
do
São
em
Sistemas
ano
letivo
Carlos.
O
de
prazo
estipulado para execução do estudo foi de 1 mês.
Treinamento:
os
participantes
que
realizaram
o
estudo
experimental utilizando a abordagem foram treinados antes da
realização
do
estudo.
O
treinamento
durou
20
horas,
sendo
dividido em quatro sessões de 4 horas, ocupando quatro aulas
do referido curso de graduação.
Participantes:
os
participantes
incluíram
os
alunos
da
graduação e os alunos do programa de pós-graduação em Sistemas
Distribuídos.
Dos
8
participantes,
constavam
6
alunos
de
Mestrado e 2 alunos de Graduação. Cinco participantes possuíam
experiência de desenvolvimento, ou em ambiente acadêmico ou
industrial, enquanto os demais participantes possuíam pouca
experiência. A Tabela 6 apresenta um resumo da formação e da
experiência dos participantes do estudo experimental.
110
Capítulo 7 – Estudo Experimental
Tabela 6 - Perfil dos Participantes do Estudo Experimental.
ID
Utilizou a Abordagem
Formação
Experiência de
Desenvolvimento
1
Sim
Mestrando
Academia (3 projetos)
2
Sim
Mestrando
Indústria (3 projetos)
3
Sim
Graduando
Academia (2 projetos)
4
Sim
Graduando
Academia (1 projeto)
5
Não
Mestrando
Academia (1 projeto)
6
Não
Mestrando
Academia (3 projetos)
7
Não
Mestrando
Indústria (3 projetos)
8
Não
Mestrando
Academia (1 projeto)
Custo do Estudo: como os participantes do estudo experimental
foram
alunos
da
própria
Universidade
e
os
equipamentos
utilizados foram os computadores dos laboratórios, o custo do
de realização do estudo experimental se concentrou no custo de
planejamento.
Custo de Planejamento: o planejamento é, certamente, a etapa
mais
custosa
para
realização
de
um
estudo
experimental
[Travassos, 2002]. O planejamento do estudo de viabilidade da
abordagem de DBCD se estendeu durante dois meses e dezoito
dias, entre outubro e dezembro do ano de 2002. Durante este
período, foram geradas três versões do plano experimental.
7.3.6
Análise
dos
Resultados
do
Estudo
Experimental
Avaliação do Treinamento: o treinamento foi aplicado apenas
para
os
participantes
que
utilizaram
a
abordagem
no
experimento. O treinamento ocupou vinte horas, conforme foi
planejado; sendo expositivo, utilizando um conjunto de slides
e, ao final, foi realizado um caso de uso de pequeno porte,
para um melhor entendimento da abordagem. Um participante (ID
4) sugeriu a necessidade de mais treinamento, em virtude dos
diversos mecanismos utilizados na abordagem.
111
Capítulo 7 – Estudo Experimental
Avaliação Quantitativa: a análise quantitativa foi separada
em seis análises independentes: número de modelos, número de
classes, número de componentes, número de aplicações, tempo de
desenvolvimento
e
número
de
grupos
para
classificação
dos
componentes. Cada uma destas análises foi realizada através da
utilização de estatísticas descritivas.
Estatísticas
Descritivas:
tendo
coletado
as
informações
necessárias, passou-se para a etapa de análise. Inicialmente,
foi
realizado
um
agrupamento
dos
dados
obtidos
pelos
participantes do experimento. As Tabelas 7 e 8 apresentam,
respectivamente, os resultados obtidos por cada participante
utilizando
a
abordagem
e
a
abordagem
ad-hoc
para
o
desenvolvimento de software.
Tabela 7 - Resultados obtidos por cada participante utilizando
a abordagem.
ID
Modelos
Classes
Componentes
Aplicações
Tempo
Num.
Grupos
1
17
21
15
19
12h
2
2
17
20
15
19
9h 26m
2
3
17
20
15
19
20h 46m
2
4
17
20
15
19
20h 52m
2
Tabela 8 - Resultados obtidos por cada participante utilizando
a abordagem ad-hoc.
ID
Modelos
Classes
Componentes
Aplicações
Tempo
Num.
Grupos
5
0
3
3
19
27h 15m
1
6
0
3
3
19
26h
1
7
0
3
3
19
13h 50m
1
8
2
3
3
19
41h
1
Após
o
agrupamento,
a
média
foi
aplicada
para
os
dois
conjuntos de dados e analisada, conforme mostra a Tabela 9. O
desvio padrão foi desconsiderado em virtude do pequeno número
de participantes, o que o tornaria inexpressivo.
112
Capítulo 7 – Estudo Experimental
Tabela 9 - Média dos resultados obtidos pelos dois grupos.
Artefatos
Média
Abordagem
Ad-Hoc
Modelos
17
0,5
Classes
Componentes
Aplicações
20,25
3
15
3
19
19
Tempo
15h 46m
27h 12m
Num. Grupos
2
1
i. Modelos. A média dos modelos obtidos (Mind-Maps, Modelo de
Colaboração,
Modelo
de
Casos
de
Uso,
Modelo
de
Tipos,
Framework de Modelos, Modelo de Aplicação do Framework, Modelo
de
Classes
e
Modelo
participantes
que
de
Componentes)
utilizaram
a
especificada
abordagem
pelos
(17),
foi
extremamente superior aos que utilizaram a abordagem ad-hoc
(0,5).
Isto
se
desenvolvimento
etapa.
Com
deve
ao
desses
a
fato
da
artefatos,
utilização
da
abordagem
explicitar
progressivamente,
abordagem
ad-hoc,
a
o
cada
apenas
um
participante (ID 8) especificou os modelos de casos de uso e
de classes, mesmo sendo um dos menos experientes. Os demais
participantes
partiram
logo
para
a
tomada
de
decisões
relativas a implementação, descartando as tarefas de análise.
ii. Classes e Componentes. A média dos participantes que
utilizaram a abordagem, também foi superior, no que se refere
ao
número
de
classes
e
componentes.
Este
critério
é
extremamente importante, uma vez que existia o interesse em
identificar as estruturas de análise, projeto e implementação
resultantes. Em relação às classes, um grande problema pode
ser notado com a utilização da abordagem ad-hoc. As classes
especificadas (3) estavam altamente entrelaçadas com códigos
de diferentes propósitos, neste caso, código de distribuição,
tratamento de exceções e acesso a banco de dados, dificultando
a distinção entre classes de análise e projeto. Por outro
lado,
com
a
utilização
da
abordagem,
as
classes
113
Capítulo 7 – Estudo Experimental
(aproximadamente
através
da
20)
tinham
utilização
do
suas
padrão
funções
DAP
com
bem
definidas,
suas
classes
de
negócio e de distribuição e do framework Persistence com as
classes de acesso a banco de dados. A mesma análise se aplica
aos componentes.
iii. Aplicações e Tempo de Desenvolvimento. Os dois grupos
desenvolveram a mesma média de aplicações (19) reutilizando os
componentes. Porém, mesmo com uma série de etapas a serem
realizadas,
com
a
utilização
da
abordagem
(quatro
no
desenvolvimento dos componentes e três no desenvolvimento das
aplicações),
a
média
obtida
do
tempo
de
desenvolvimento
(aproximadamente 15 horas e 46 minutos) foi inferior ao da
abordagem ad-hoc (aproximadamente 27 horas e 12 minutos). Este
fato pode ser explicado pela orientação dada de como proceder
com questões relativas a especificação dos requisitos, projeto
dos componentes, distribuição, acesso a banco de dados e como
desenvolver as aplicações reutilizando os componentes.
iv.
Grupos
para
classificação
dos
componentes.
Com
a
utilização da abordagem, obtêm-se, ao fim do processo, uma
clara distinção entre dois tipos de componentes: de negócio e
de infra-estrutura (componentes de acesso a banco de dados e
distribuição), facilitando as possíveis tarefas de manutenção.
Por outro lado, devido ao entrelaçamento de código, com a
utilização da abordagem ad-hoc, ficou difícil a classificação
dos componentes seguindo um determinado critério. Assim, os
componentes foram classificados apenas como de uma categoria,
neste caso, de negócio.
Conclusão:
embora
os
testes
estatísticos
não
tenham
sido
conclusivos, estes indicam que a abordagem de desenvolvimento
de
software
baseado
em
componentes
distribuídos
pode
ser
viável no auxílio do engenheiro de software no desenvolvimento
de suas tarefas. Entretanto, além de outros estudos, conforme
o
descrito
neste
capítulo,
são
necessários
melhorias
no
sentido de facilitar a utilização da abordagem proposta. A
114
Capítulo 7 – Estudo Experimental
seguir é apresentada uma análise qualitativa, realizada com o
intuito
de
apresentar
novas
direções
de
pesquisa
e
de
aprimoramento da abordagem.
Avaliação Qualitativa: a seguir, são resumidos os resultados
da análise qualitativa sobre a utilidade da abordagem proposta
e
sobre
a
qualidade
experimental.
Esta
do
material
análise
se
utilizado
baseia
nas
no
estudo
respostas
ao
questionário QT2, apresentado no apêndice.
Utilidade da Abordagem: dos 4 participantes que aplicaram a
abordagem
no
indicaram
que
desenvolvimento
a
abordagem
do
projeto
utilizada
proposto,
foi
útil
todos
para
sua
conclusão. Um participante (ID 4) ressaltou a necessidade de
que,
na
etapa,
estrutura
do
Projetar
padrão
DAP
Componentes,
já
estejam
as
classes
disponíveis,
a
com
fim
a
de
evitar sua criação repetidamente disponibilizando, assim, um
template para reutilização.
Qualidade do Material: apenas um participante ressaltou que o
treinamento
ministrado
foi
suficiente
para
aplicação
da
abordagem. Os demais participantes ressaltaram a necessidade
de mais treinamento, principalmente, o desenvolvimento de um
projeto completo, não apenas de um caso de uso de aplicação.
Além disso, três participantes requisitaram melhorias no Kit
de Treinamento, particularmente, na etapa de implementação dos
componentes e aplicações.
7.3.7 Lições Aprendidas
Em
uma
replicação
do
experimento,
alguns
pontos
devem
ser
considerados, vistos como limitações de sua primeira execução.
Aprimoramento do Treinamento: sugere-se, para uma replicação
do
experimento,
o
desenvolvimento
de
um
projeto
completo,
sendo executado, passo a passo, pelos participantes, antes da
execução do experimento. Além de exibir maiores detalhes de
implementação e configuração dos componentes e aplicações, que
não ficaram completamente claros nessa primeira versão.
115
Capítulo 7 – Estudo Experimental
Instrumentação: alguns participantes expressaram a ocorrência
de determinados problemas com a ferramenta MVCASE, no momento
de
desenvolvimento
do
projeto.
Assim,
sugere-se,
numa
replicação do experimento, a execução de um projeto real, a
fim de evitar problemas durante o andamento do experimento.
Por fim, dois participantes explicitaram a necessidade de um
help on-line, disponível pela ferramenta, a fim de auxiliar em
determinadas tarefas.
7.4 Resumo
Este
capítulo
apresentou
o
planejamento,
a
execução
e
a
análise dos resultados de um estudo experimental que avaliou a
viabilidade de utilização da abordagem de desenvolvimento de
software
baseado
em
componentes
distribuídos.
O
estudo
analisou a capacidade de engenheiros de software concluírem um
projeto hipotético com características mais favoráveis do que
sem o auxílio da abordagem.
Apesar de possuir uma população reduzida (8 participantes), a
análise dos resultados mostra indícios de que a utilização da
abordagem pode ser viável, assim como aponta algumas direções
em que a pesquisa deve evoluir. Entretanto, replicações deste
estudo, em diferentes contextos, são ainda necessárias para a
efetiva
identificação
de
problemas
e
aprimoramento
da
abordagem.
O capítulo seguinte apresenta as considerações finais sobre o
trabalho, assim como suas principais contribuições, trabalhos
relacionados e algumas perspectivas de trabalhos futuros.
Capítulo 8
Conclusões
8.1 Sobre o Trabalho
Este
projeto
de
Desenvolvimento
pesquisa
de
resultou
Software
numa
Baseado
Abordagem
em
de
Componentes
Distribuídos, que integra diversos mecanismos, orientando o
engenheiro
de
software
tanto
no
desenvolvimento,
quanto
na
reutilização dos componentes de um domínio do problema.
A integração dos mecanismos, na ferramenta MVCASE, tornou
possível o desenvolvimento dos componentes e aplicações numa
plataforma
distribuída.
Embora
estes
mecanismos
existam
na
literatura, ainda existe uma carência de métodos e ferramentas
que
integrem
e
desenvolvimento
auxiliem
de
o
software
engenheiro
baseado
de
software
em
no
componentes
distribuídos, automatizando parte de suas tarefas.
Adicionalmente,
um
estudo
experimental
foi
definido,
planejado, executado e analisado, mostrando a viabilidade de
utilização da abordagem proposta.
Outra contribuição deste projeto foi a extensão do modelo de
distribuição Object Web, abordando a utilização de servidores
de
componentes
com
seus
repositórios,
permitindo
uma
maior
reutilização no desenvolvimento das aplicações, não tratado no
modelo original.
117
Capítulo 8 – Conclusões
8.2 Principais Contribuições
Embora
existam
diferentes
métodos
de
DBC
disponíveis
na
literatura, conforme foi apresentado no Capítulo 2 (vide seção
2.4.4),
este
permitir
ao
trabalho
engenheiro
diferencia-se,
principalmente,
por
de
desenvolvimento
dos
software
o
componentes e das aplicações de forma incremental, integrando
os
princípios
padrões,
além
de
de
reutilização,
permitir
o
middleware,
acréscimo
de
frameworks
requisitos
e
não
funcionais, como distribuição, tolerância à falhas, caching e
persistência, à medida que se tornem necessários.
As
principais
contribuições
desta
dissertação
podem
ser
divididas em três categorias: a definição de uma abordagem de
desenvolvimento
de
software
baseado
em
componentes
distribuídos, a extensão da ferramenta MVCASE e a definição, o
planejamento
e
a
execução
de
um
estudo
experimental
para
analisar a viabilidade de utilização da abordagem proposta. A
seguir, essas contribuições são classificadas segundo estas
categorias:
i. Definição de uma Abordagem de Desenvolvimento de Software
Baseado em Componentes Distribuídos
-
a definição de uma abordagem de desenvolvimento de
software
baseado
em
componentes
distribuídos,
integrada numa ferramenta CASE, automatizando parte
das suas tarefas;
-
um
padrão
para
o
desenvolvimento
dos
componentes
distribuídos [Almeida, 2002b];
-
um framework baseado em padrões para tratar o acesso
a banco de dados.
ii. Extensão da Ferramenta MVCASE
-
a
extensão
da
específicos
de
Framework
de
ferramenta
DBC,
como
Modelos
e
MVCASE,
Modelo
Modelo
com
de
de
artefatos
Colaboração,
Aplicação
do
118
Capítulo 8 – Conclusões
Framework,
permitindo
a
especificação
dos
componentes, conforme previsto no método Catalysis;
-
a
automatização
de
parte
das
atividades
de
implementação dos componentes, com a utilização de
Wizards para geração de código dos componentes e suas
respectivas interfaces, assim como o código dos stubs
e skeletons.
iii.
Definição,
Planejamento
e
a
Execução
de
um
Estudo
Experimental na área de Desenvolvimento de Software Baseado em
Componentes Distribuídos
-
a definição, o planejamento e a execução de um estudo
experimental,
para
análise
da
viabilidade
de
aplicação da abordagem de desenvolvimento de software
baseado em componentes distribuídos;
-
o empacotamento do estudo experimental, para análise
de viabilidade da abordagem proposta. O pacote do
experimento inclui todos os documentos e instrumentos
utilizados
durante
as
fases
de
definição,
planejamento e execução, com o objetivo de facilitar
sua replicação no futuro.
8.3 Trabalhos Relacionados
Alguns trabalhos similares a este existem na literatura. Nesta
seção,
são
apresentados
alguns
deles,
enfatizando
suas
diferenças e similaridades em relação à abordagem proposta.
8.3.1 A proposta de Guimarães [1999]
Em [Guimarães, 1999], os autores descrevem uma estratégia de
desenvolvimento de sistemas orientado a objetos distribuídos,
dividida em três passos: Especificação do Sistema Distribuído,
onde o sistema é modelado usando a notação UML; Distribuição
dos
Objetos,
onde
é
definida
a
arquitetura
do
sistema
119
Capítulo 8 – Conclusões
distribuído baseado nos serviços e frameworks disponíveis na
plataforma JAMP; e, Implementação do Sistema Distribuído, onde
é realizada a sua implementação, a partir das especificações
dos
passos
proposta
anteriores.
por
utilizar
Esta
abordagem
frameworks
difere
da
disponíveis
na
abordagem
plataforma
JAMP, onde se apóia toda a estratégia, além de trabalhar com
objetos,
e
não
componentes,
diminuindo
a
reutilização
no
desenvolvimento das aplicações.
8.3.2 A proposta de Clement [2002]
Em
Clement
[2002],
desenvolvimento
distribuídos,
é
de
apresentada
sistemas
utilizando
uma
estratégia
baseado
Programação
em
para
o
componentes
Orientada
a
Aspectos
(POA) para descrever e implementar as dependências entre os
componentes. Os autores utilizam o processo de modelagem de
sistemas baseado em componentes proposto em [Cheesman, 2000].
Este
processo
foi
estendido
utilizando
POA
nas
fases
de
especificação dos componentes e de suas interfaces e durante a
implementação
dos
componentes.
Comparada
com
a
proposta
de
Clement, a abordagem de DBCD define uma abordagem incremental
para
o
desenvolvimento
distribuídos,
iniciando
identificando
seus
presente
de
software
na
fase
elementos
materialização
e
em
de
baseado
em
componentes
concepção
do
relacionamentos,
componentes
de
domínio,
até
sua
software,
independente de tecnologia de distribuição. Por outro lado, a
abordagem de DBCD permite a reutilização não apenas de código,
como também de modelos de alto nível de abstração (Framework
de Modelos). Além disso, a abordagem define, sistematicamente,
o
modo
de
se
realizar
o
desenvolvimento
das
aplicações
reutilizando os componentes.
8.3.3 Outras Ferramentas
A
Rational
Rose
[Objecteering,
[Rational,
2001]
são
2001]
ferramentas
e
a
CASE
Objecteering/UML
que
oferecem
uma
120
Capítulo 8 – Conclusões
grande
variedade
desenvolvimento
de
recursos,
de
software
de
modo
baseado
a
suportar
em
o
componentes
distribuídos. Essas ferramentas suportam a especificação do
sistema
utilizando
a
notação
UML
e
geram
código
dessas
especificações. Comparada com essas duas ferramentas, a MVCASE
difere-se
por
ter
um
editor
visual,
também
encontrado
em
outros ambientes, como o JBuilder [Borland, 2002], permitindo
um rápido desenvolvimento das aplicações. Por fim, por ser uma
ferramenta acadêmica, a MVCASE é totalmente livre de licença
de utilização.
8.4 Trabalhos Futuros
Com base nos resultados obtidos no estudo de caso realizado e
na
análise
do
relacionadas
estudo
à
necessárias
experimental,
literatura
tanto
à
além
existente,
abordagem
de
constatações
algumas
proposta
quanto
melhorias
à
ferramenta
MVCASE foram evidenciadas. Assim, as seguintes direções surgem
como perspectivas de trabalhos futuros:
i. Commercial-Off-The-Shelf (COTS). Atualmente, a comunidade
de engenharia de software adotou o consenso da viabilidade de
utilização de COTS no desenvolvimento de sistemas de software.
Deste
modo,
este
trabalho
sugere
uma
pesquisa
na
área
de
engenharia de requisitos e COTS, a fim de permitir a extensão
da abordagem com a utilização de COTS. Assim, será possível ao
engenheiro
de
software
desenvolver
as
aplicações
de
dois
modos: o primeiro, desenvolvendo os componentes a partir dos
requisitos do domínio do problema, e, o segundo, adquirindo os
componentes de terceiros.
ii.
Programação
Orientada
a
Aspectos.
Mesmo
separando
os
requisitos não funcionais, como distribuição e persistência,
através
da
utilização
Persistence,
entrelaçamento
de
padrões
identificou-se,
de
código
ao
com
(DAP)
fim
e
do
diferentes
do
framework
processo,
um
propósitos,
121
Capítulo 8 – Conclusões
principalmente, código de tratamento de exceções com código de
distribuição
e
acesso
a
banco
de
dados.
Deste
modo,
este
projeto sugere um reprojeto da abordagem com a utilização da
programação orientada a aspectos, de modo a evitar, com a
utilização
da
abordagem,
diferentes
propósitos.
o
entrelaçamento
Além
disso,
de
código
sugere-se,
com
também,
o
desenvolvimento e a utilização de um framework de requisitos
não funcionais baseado em aspectos, que permita ao engenheiro
de
software
acrescentar
requisitos,
como
distribuição,
controle de concorrência, segurança e acesso a banco de dados,
progressivamente, à medida em que se tornem necessários.
iii.
atual,
Aspectos
a
Relacionados
abordagem,
à
Distribuição.
basicamente,
utiliza
o
No
seu
estado
middleware
como
infraestrutura para localização e comunicação dos componentes.
Deste modo, a inclusão de outras características, intrínsecas
de distribuição, mostra-se bastante promissoras. Dentre estas,
destacam-se:
a
utilização
de
mecanismos
eficientes
de
tolerância a falhas, caching e balanceamento de carga.
iv. Armazenamento e Busca dos Componentes. O modo atual com
que a ferramenta MVCASE efetua o armazenamento dos componentes
torna
sua
reutilização
armazenamento
artefatos
das
muito
limitada.
informações
disponibilizados
em
Por
referentes
um
arquivo
utilizar
aos
de
o
diversos
modelagem,
o
intercâmbio de informações entre domínios diferentes torna-se
extremamente
prejudicado.
Deste
modo,
pesquisas
devem
ser
realizadas, a fim de identificar uma infraestrutura para o
armazenamento
processo
de
sistemática,
de
todos
os
desenvolvimento
levando-se
em
artefatos
e
produzidos
efetuar
consideração
a
busca
a
durante
de
o
forma
necessidade
de
distribuição. Entretanto, como apresentado anteriormente, no
capítulo 2, seção 2.5, a questão de armazenamento e busca de
componentes
não
é
um
processo
trivial.
Diversas
abordagens
122
Capítulo 8 – Conclusões
existentes utilizando agentes, mecanismos para introspecção e
engenhos
de
buscas
a
visão
aspectos:
elemento
falham,
de
componente
implementacional
reutilização
efetivo.
principalmente,
e
Deste
a
devido
essencialmente
carência
modo,
as
de
um
a
dois
como
um
processo
de
pesquisas
conduzidas
nesta área devem levar em consideração estes dois aspectos.
v.
Padrões
de
Software.
Outra
extensão
extremamente
necessária na ferramenta MVCASE, a fim de otimizar as tarefas
de
desenvolvimento,
é
o
suporte
a
padrões
de
software.
Pesquisas devem ser conduzidas para permitir a reutilização de
padrões
já
existentes,
como,
por
exemplo,
os
padrões
do
catálogo do Gamma, e oferecer a possibilidade do engenheiro de
software
desenvolver
novos
padrões
e
armazenar
estas
estruturas para futura reutilização.
vi. Estudo Experimental. Por fim, sugere-se a repetição do
estudo experimental descrito no Capítulo 7 com um número maior
de
participantes,
em
diferentes
contextos,
considerando
as
evoluções propostas pelos participantes do estudo previamente
realizado.
8.5 Contribuições Acadêmicas
O conhecimento adquirido ao longo desse trabalho possibilitou
alcançar os seguintes resultados:
-
[Almeida,
2002]
Integradora
de
Ferramenta
Tecnologias
MVCase
para
o
-
Uma
Ferramenta
Desenvolvimento
de
Componentes Distribuídos, In XVI Simpósio Brasileiro de
Engenharia
de
Software,
Sessão
de
Ferramentas,
Gramado/RS, 2002.
-
[Almeida,
Tool
for
2002a]
MVCase:
Distributed
An
Integrating
Technologies
Component-Based
Software
Development, In The 6Th Asia-Pacific Network Operations
123
Capítulo 8 – Conclusões
and Management Symposium, Proceedings of IEEE, Poster
Session, Jeju Island, Korea, 2002.
-
[Almeida,
2002b]
DCDP:
Development
Pattern,
Conference
on
In
Pattern
A
The
Distributed
Second
Languages
Component
Latin
of
American
Programming
(SugarLoafPlop), Writers Workshops, Itaipava/RJ, 2002.
-
[Almeida,
2002d]
Development
Students
Distributed
Strategy,
in
In
The
Object-Oriented
Component-Based
12Th
Workshop
Systems
Software
for
PhD
(PhDOOS).
In
Conjunction With the 16Th European Conference on Object
Oriented
Programming
(ECOOP),
Málaga-Espanha.
Lecture
Notes in Computer Science (LNCS), Springer-Verlag, 2002.
-
[Almeida,
2002e]
Distributed
Component-Based
Software
Development Strategy Integrated by MVCase Tool, In The
Second Ibero-American Symposium on Software Engineering
and Knowledge Engineering, Salvador/BA, 2002.
-
[Almeida,
2002f]
Desenvolvimento
Integrando
de
Software
Tecnologias
Baseado
em
para
o
Componentes
Distribuídos, In Simpósio Brasileiro de Engenharia de
Software (SBES) - VII Workshop de Teses em Engenharia de
Software (WTES), Gramado/RS, 2002.
-
[Almeida, 2003] IPM: An Incremental Process Model for
Distributed Component-Based Software Development, In The
5th International Conference On Enterprise Information
Systems (ICEIS), Angers, França, ACM Press, 2003.
-
[Almeida,
2003a]
Componentes,
Engenharia
Developers’
CIO
de
Software
Magazine,
Baseada
pp.
em
26-30,
janeiro, Brasil, 2003.
-
[Bianchini,
Pervasive
2002a]
Computing
Devices
and
Monitoring
Software
Tool
Agents,
using
In
International Conference on Security and Management, Las
Vegas, EUA, 2002.
-
[Bianchini,
2002b]
Intelligent
Software
Devices
Agents,
Monitoring
In
XXVIII
Tool
using
Conferência
124
Capítulo 8 – Conclusões
Latinoamericana
de
Informática
(CLEI),
Montevidéu,
Uruguai, 2002.
-
[Bianchini,
Plataform,
2002c]
In
Distributed
International
Software
Conference
on
Agents
Computer
Science Software Engineering Information Technology eBusiness and Applications (CSITeA), Foz do Iguaçu, 2002.
Referências Bibliográficas
[Alexander, 1977] Alexander, C., et. al. A Pattern Language.
New York, Oxford University Press, 1977.
[Almeida, 2002] Almeida, E., S., Lucrédio, D., Bianchini, C.,
P., Prado, A., F., Trevelin, L., C. Ferramenta
MVCase
-
Uma
Tecnologias
Componentes
Ferramenta
para
o
Integradora
Desenvolvimento
Distribuídos,
XVI
de
de
Simpósio
Brasileiro de Engenharia de Software, Sessão de
Ferramentas, Gramado/RS, 2002.
[Almeida, 2002a] Almeida, E., S., Bianchini, C., P., Prado,
A., F., Trevelin, L., C. MVCase: An Integrating
Technologies
Tool
for
Distributed
Component-
Based Software Development, In The 6Th Asia Pacific
Network
Operations
and
Management
Symposium, Proceedings of IEEE, Poster Session,
2002, Jeju Island, Korea.
[Almeida, 2002b] Almeida, E., S., Bianchini, C., P., Prado,
A., F., Trevelin, L., C. DCDP: A Distributed
Component
Development
Pattern,
In
The
Second
Latin American Conference on Pattern Languages
of
Programming
(SugarLoafPlop),
Workshops, 2002, Itaipava/RJ, Brazil.
Writers
126
Referências Bibliográficas
[Almeida, 2002c] Almeida, E., S., Lucrédio, D., Prado, A., F.,
Trevelin, L., C. Estratégia de Desenvolvimento
de Software Baseado em Componentes Distribuídos:
Kit de Treinamento, Universidade Federal de São
Carlos,
Departamento
de
Computação,
Kit
Experimental, 2002.
[Almeida, 2002d] Almeida, E., S., Bianchini, C., P., Prado,
A., F., Trevelin, L., C. Distributed ComponentBased Software Development Strategy, In The 12Th
Workshop
for
PhD
Students
in
Object-Oriented
Systems (PhDOOS). In Conjunction With the 16Th
European
Programming
Notes
in
Conference
on
(ECOOP),
Málaga,
Computer
Science
Object
Oriented
Espanha.
(LNCS)
Lecture
Springer-
Verlag, 2002.
[Almeida, 2002e] Almeida, E., S., Bianchini, C., P., Prado,
A., F., Trevelin, L., C. Distributed ComponentBased Software Development Strategy Integrated
by
MVCase
Tool,
In
The
Second
Ibero-American
Symposium on Software Engineering and Knowledge
Engineering, Salvador/BA, Brazil, 2002.
[Almeida, 2002f] Almeida, E., S., Prado, A., F., Trevelin, L.,
C. Integrando Tecnologias para o Desenvolvimento
de Software Baseado em Componentes Distribuídos,
In Simpósio Brasileiro de Engenharia de Software
(SBES) - VII Workshop de Teses em Engenharia de
Software (WTES), Gramado/RS, Brasil, 2002.
[Almeida, 2002g] Almeida, E., S. Desenvolvimento de Software
Baseado em Componentes Distribuídos, Exame de
Qualificação de Mestrado, Universidade Federal
de São Carlos, Departamento de Computação, 2002.
[Almeida, 2003] Almeida, E., S., Bianchini, C., P., Prado, A.,
F., Trevelin, L., C. IPM: An Incremental Process
127
Referências Bibliográficas
Model for Distributed Component-Based Software
Development, In The 5th International Conference
On
Enterprise
Information
Systems
(ICEIS),
Angers, França, ACM Press, 2003.
[Almeida, 2003a] Almeida, E., S., Prado, A., F., Trevelin, L.,
C.
Engenharia
de
Software
Baseada
em
Componentes, Developers’ CIO Magazine, pp. 2630, janeiro, Brasil, 2003.
[Alves,
2001]
Alves,
V.,
Borba,
P.
Distributed
Adapters
Pattern: A Design Pattern for Object-Oriented
Distributed
American
Applications,
Conference
Programming
on
In
The
Pattern
(SugarLoafPlop),
First
Latin
Languages
Rio
de
of
Janeiro,
Brasil, 2001.
[Alves, 2001a] Alves, V., Borba, P. An Implementation Method
for Distributed Object-Oriented Applications, XV
Simpósio Brasileiro de Engenharia de Software,
Rio de Janeiro/RJ, 2001.
[Alves, 2001] Alves, C., Castro, J. CRE: A Systematic Method
for
COTS
Brasileiro
Components
de
Selection,
Engenharia
de
XV
Software,
Simpósio
Rio
de
Janeiro/RJ, 2001.
[Barrére, 1999] Barrére, T., S. CASE com Múltiplas Visões de
Requisitos
Automática
de
em
Software
Java
–
e
MVCASE.
Implementação
Dissertação
de
Mestrado. Universidade Federal de São Carlos,
junho, 1999.
[Barros,
2001]
Barros,
M.,
O.
Gerenciamento
de
Projetos
Baseado em Cenários: Uma Abordagem de Modelagem
Dinâmica e Simulação, PhD Thesis, Universidade
Federal do Rio de Janeiro, 2001.
128
Referências Bibliográficas
[Barros, 2002] Barros, M., O., Werner, C., M., L., Travassos,
G., H. Um Estudo Experimental sobre a Utilização
de Modelagem e Simulação no Apoio à Gerência de
Projetos, XVI Simpósio Brasileiro de Engenharia
de Software, Gramado/RS, 2002.
[Basili,
1986]
Basili,
V.,
Experimentation
Transactions
on
R.,
Selby,
in
Software
Software
R.,
Hutchens,
Engineering,
Engineering
D.
IEEE
(invited
paper), July 1986.
[Basili, 1991] Basili, V., R., Caldiera, G. Methodological and
Architectural Issues in the Experience Factory,
presented
at
the
Software
Eng.
Laboratory
Workshop, December 1991.
[Basili, 1993] Basili, V., R., Rombach, D., Selby, R.
The
Experimental Paradigm in Software Engineering.
(Eds): Experimental Software Engineering Issues:
Critical
Assessment
and
Future
Directions,
International Workshop, Dagstuhl, Germany, 1992.
Springer-Verlag,
Lecture
Notes
in
Computer
Science (LNCS), Number 706, 1993.
[Basili, 1994] Basili, V., R., Caldiera, G., Rombach, D. The
Experience
Factory.
Encyclopedia
of
Software
Engineering. Wiley 1994.
[Ben-Natan] Ben-Natan, R. CORBA A Guide to the Common Object
Request Broker Architecture. Mc-Graw-Hill, 1995.
[Bernstein, 1996] Bernstein, P., A., et. al. Middleware: A
Model for Distributed Services. Communications
of the ACM, volume 39, No. 2, p. 86-97, 1996.
[Bianchini, 2002a] Bianchini, C., P., Fontes, D., S., Almeida,
E., S., Prado, A., F. Devices Monitoring Tool
using Pervasive Computing and Software Agents,
129
Referências Bibliográficas
In
International
Conference
on
Security
and
Management, Las Vegas, EUA, 2002.
[Bianchini, 2002b] Bianchini, C., P., Almeida, E., S., Prado,
A., F. Devices Monitoring Tool using Intelligent
Software
Agents.
In
Latinoamericana
XXVIII
de
Conferência
Informática
(CLEI),
Montevidéu, Uruguai, 2002.
[Bianchini, 2002c] Bianchini, C., P., Fontes, D., S., Almeida,
E.,
S.,
Prado,
A.,
F.
Distributed
Software
Agents Plataform, In International Conference on
Computer
Science
Information
Software
Technology
Engineering
e-Business
and
Applications (CSITeA), Foz do Iguaçu, Brazil,
2002.
[Boertin,
2001]
Boertin,
N.,
Evaluation
of
Methods,
Sixth
In
Steen,
M.,
Jonkers.,
H.
Component-Based
Development
CAiSE/IFIP8.1
International
Workshop on Evaluation of Modeling Methods in
Systems Analysis and Design, 2001.
[Booch, 1994] Booch, G. Object-Oriented Analysis and Design
with Applications. Benjamin/Cummings, 1994.
[Borland, 2002] Borland. JBuilder the Leading Java development
solution.
Disponivel
site
Borland,
URL:
http://www.borland.com/jbuilder/. Consultado em
13/12/2002.
[Bray,
1997]
Bray,
M.
Technology
Middleware.
Review
Disponível
site
Software
(January,
1997),
URL:
http://www.sei.cmu.edu/str/descriptions/middlewa
re.html. Consultado em 23/06/2001.
[Brown, 1998] Brown, A., Wallnau, K.
The Current State of
CBSE, IEEE Software, Oct 1998.
130
Referências Bibliográficas
[CADA, 2000] Hubbers, J., W., Verhoef, D. CADA CBD Method, In
Workshop
Component-Based
Development.
Ordina
Institute for Research and Innovation, 2000.
[CBSE,
2002]
5th
ICSE
Workshop
Engineering:
Assembly,
on
Component-Based
Benchmarks
In
for
conjunction
Software
Predictable
with
24th
the
International Conference on Software Engineering
(ICSE), May 2002.
[Cheesman, 2000] Cheesman, J., Daniels, J. UML Components: A
Simple
Process
Software.
for
Specifying
Addison-Wesley.
Component-Based
USA,
1nd
edition,
2000.
[Chen, 2000] Chen, Q., et al. Multi-Agent Cooperation, Dynamic
Workflow and XML for E-Commerce Automation, In
4th
International
Conference
on
Autonomous
Agents, Barcelona, Spain, 2000.
[Clement, 2002] Clement, P., J., Sánchez, F., Pérez, M., A.,
2002.
Modeling
with
UML
Component-based
and
Aspect Oriented Programming Systems, In The 7th
Workshop for Component-Oriented Programming. In
conjunction with the 16th European Conference on
Object-Oriented Programming (ECOOP), 2002.
[COMET,
1997]
Solberg,
A.,
Berre,
A.,
J.
Component
Based
Methodology Handbook. Norway: SINTEF, 1997.
[Councill, 2001] Councill, B., Heineman, G., T. Definition of
a
Software
Component
Component-Based
and
Software
its
Elements,
Engineering:
In
Putting
the Pieces Together, Addison-Wesley, 2001.
[CSC, 1995] Catalyst Methodology (Internal Document), Computer
Sciences Corporation, 1995.
131
Referências Bibliográficas
[D’Souza,
1999]
D’Souza,
D.,
F.,
Wills,
Components,
and
Frameworks
C.,
A.
with
Objects,
UML
–
The
Catalysis Approach. Addison-Wesley, 1999.
[Duclos, 2002] Duclos, F., Estublier, J., Morat, P. Describing
and Using Non Functional Aspects in Component
Based
Applications,
Conference
on
In
1st
International
Aspect-Oriented
Software
Development, University of Twente, Enschede, The
Netherlands, 2002.
[Eckerson,
1995]
Eckerson,
W.,
Client/Server
Scalability,
W.,
et.
al.
Three
Architectures:
Performance,
Client/Server
and
Applications.
Tier
Achieving
Efficiency
Open
in
Information
Systems, volume 10, No. 1, p. 20, 1995.
[Elias, 2002] Elias, G., S. SOS: A Framework for Distribution,
Management
and
Evolution
of
Component-Based
Software Systems over Open Networks. PhD Thesis.
Federal University of Pernambuco. June, 2002.
[Elrad, 2001] Elrad, T., Filman, R., E., Bader, A. AspectOriented Programming, Communications of the ACM,
2001.
[Emmerich,
2002]
Emmerich,
Technologies
and
W.
their
Distributed
Software
Component
Engineering
Implications, In 24th International Conference
on Software Engineering (ICSE). Orlando, USA,
2002.
[Fischer, 1993] Fischer, G. Shared Knowledge in Cooperative
Problem-Solving Systems—Integrating Adaptive and
Adaptable
Components,
In
M.
Schneider-
Hufschmidt, T. Kuehme & U. Malinowski (eds.),
Adaptive
User
Interfaces:
Principles
and
132
Referências Bibliográficas
Practice,
Elsevier
Science
Publishers,
Amsterdam, pp. 49–68.
[Gamma, 1995] Gamma, E., Helm, R., Johnson, R., Vlissides, J.
Design Patterns: Elements of Reusable ObjectOriented Software. Addison-Wesley, 1995.
[Gimenes,
2000]
Gimenes,
Carniello,
I.,
A.
O
Barroca,
Processo
L.,
de
Huzita,
E.,
Desenvolvimento
Baseado em Componentes Através de Exemplos, VIII
Escola de Informática da SBC Sul, Editora da
UFRGS, 147-178, 2000.
[Griss,
1996]
Griss,
M.,
Architecture,
L.
Systematic
Process
and
Software
Reuse:
Organization
are
Crucial, Fusion Newsletter, HP Laboratories, Oct
1996.
[Griss, 1998] Griss, M., L., et. al, Software Reuse: Nemesis
or
Nirvana?,
Systems,
In
Languages
Object-Oriented
and
Programming
Applications
(OOPSLA),
Vancouver, British Columbia, Canada, 1998.
[Griss, 2000] Griss, M., L. Implementing Product-Line Features
by
Composing
Component
Aspects,
In
First
International Software Product-Line Conference,
Denver, Aug 2000.
[Griss, 2001] Griss, M., L. CBSE Success Factors: Integrating
Architecture,
Component-Based
Process
Software
and
Organization,
Engineering:
In
Putting
the Pieces Together, Addison-Wesley, 2001.
[Griss,
2001a]
Griss,
Generation
M.,
L.
Software
Software
Agents
Components,
In
as
Next
Component-
Based Software Engineering: Putting the Pieces
Together, Addison-Wesley, 2001.
[Griss, 2002] Griss, M., L., Cowan, D. Making Software Agent
Technology Available to Enterprise Applications,
133
Referências Bibliográficas
In 1st International Workshop on Challenges in
Open Agent Systems, AAMAS'02, Bologna, Italy,
July 2002.
[Griss, 2002a] Griss, M., L., Cowan, D., Kessler, R., Remick,
B.,
Burg,
B.
A
Robust
Environment
for
Agent
Deployment, In First International Workshop on
Challenges
in
Open
Agent
Systems,
AAMAS'02,
Bologna, Italy, July 2002.
[Guimarães, 1999] Guimarães, M., P., Prado, A., F., Trevelin,
L.,
C.
Development
of
Object
Oriented
Distributed Systems (DOODS) using Frameworks of
the JAMP plataform, In First Workshop on Web
Engineering,
in
conjunction
with
the
19th
International Conference in Software Engineering
(ICSE), 1999.
[Hampshire,
1999]
Hampshire,
Desenvolvimento
P.,
et
al.
de
Software
O
Futuro
no
do
Brasil.
Developers' CIOMagazine, No. 40, ano 4, p. 1014, 1999.
[Heineman, 2001] Heineman, G., T., Council, W., T. ComponentBased Software Engineering: Putting the Pieces
Together, Addison-Wesley. 2001.
[Heineman, 2001a] Heineman, G., T. Building Instead of Buying:
A
Rebuttal,
Engineering:
In
Putting
Component-Based
the
Pieces
Software
Together,
Addison-Wesley, 2001.
[Hissam, 2002] Hissam, S., A., Seacord, R., C., Lewis, G., A.
Building Systems from Commercial Components, In
24th
International
Engineering
USA, 2002.
(ICSE),
Conference
Tutorial
on
Notes.
Software
Orlando,
134
Referências Bibliográficas
[Horstmann, 2001] Horstmann, C., Cornell, Gary. Core Java 2,
Volume II: Advanced Features (5th Edition). Sun
Microsystems Press, 2001.
[Humphrey,
1989]
Humphrey,
W.,
S.
CASE
Planning
and
the
Software Process. Software Engineering Institute
(SEI), Technical Report, May 1989.
[ICSR, 2002] 7th International Conference on Software Reuse
(ICSR), Austin, Texas, USA. April 2002.
[Jacobson,
1992]
Jacobson,
Software
I.,
et.
Engineering
–
al.
Object-Oriented
A
Use
Case-Driven
approach, Reading, MA: Addison-Wesley, 1992.
[Jacobson, 2001] Jacobson, I., et. al. The Unified Software
Development
Process.
Addison-Wesley.
USA,
4nd
edition, 2001.
[Johnson,
1992]
Johnson,
Patterns,
R.
In
Documenting
Frameworks
Object-Oriented
Using
Programming
Systems, Languages, and Applications (OOPSLA),
Vancouver, British Columbia, Canada, 1992.
[Kiczales,
1997]
Kiczales,
Programming,
In
Object-Oriented
Notes
in
G.,
et.
11th
al.
European
Programming
Computer
Aspect-Oriented
Science
Conference
(ECOOP),
(LNCS),
on
Lecture
Springer-
Verlag, Finland, 1997.
[Kiczales, 2001] Kiczales, G., et. al. An Overview of AspectJ,
In 15th European Conference on Object-Oriented
Programming (ECOOP), Lecture Notes in Computer
Science (LNCS), Springer-Verlag, Hungary, 2001.
[Kienzle, 2002] Kienzle, J., Guerraoui, R. AOP: Does It Make
Sense? The Case of Concurrency and Failures, In
16th
European
Conference
on
Object-Oriented
Programming (ECOOP), Lecture Notes in Computer
135
Referências Bibliográficas
Science
(LNCS),
Springer-Verlag,
pp.
37-61.
Málaga, Spain, 2002.
[Kitchenham, 1995] Kitchenham, B., Pickard, P., Pfleeger, S.,
L. Case Studies for Method and Tool Evaluation,
IEEE Software, vol. 11, no. 4, pp. 52-62, July
1995.
[Kobra, 2000] Atkinson, C., et. al. Component-Based Software
Engineering:The
KobrA
International
Approach,
Workshop
on
In
3rd
Component-based
Software Engineering: Reflection on Practice, in
conjunction
Conference
with
on
the
22th
Software
International
Engineering
(ICSE).
Limerick, Ireland, 2000.
[Krueger,
1992]
Krueger,
C.
Software
Reuse.
ACM
Computing
Surveys, v.24, n.2.
[Lieberherr,
1994]
Lieberherr,
Object-Oriented
K.,
J.,
et.
Programming
Customization,
in
al.
using
Communications
Adaptive
Graph-Based
of
the
ACM,
1994.
[Linthicum,
1997]
Linthicum,
Middleware.
Enterprise
D.,
S.
Next
Disponível
magazine
Generation
site
(September,
www.dbmsmag.com/9709d14.html.
Intelligent
1997),
URL:
Consultado
em
23/05/2001.
[Lipson, 2001] Lipson, H., F., Mead, N., R., Moore, A., P. Can
We
Ever
Build
Components?.
Survivable
Software
Systems
Engineering
from
COTS
Institute
(SEI), Technical Note, 2001.
[Mehta,
2002]
Mehta,
A.,
Heineman,
G.,
T.
Evolving
Legacy
System Features into Fine-Grained Components, In
24th
Internation
Conference
on
Engineering (ICSE). ACM Press, 2002.
Software
136
Referências Bibliográficas
[Microsoft, 2002] COM: Delivering on the Promises of Component
Technology.
Disponível
site
Microsoft
Technologies,
URL:
http://www.microsoft.com/com/.
Consultado
em
07/11/2002.
[Mitre, 1998] MITRE. Recommendations for Using DCE, DCOM, and
CORBA
from
Middleware.
Computer
Disponível
Systems
Clearingho,
site
Engineering
SOE
Center
Information
URL:
http://dii-
sw.ncr.disa.mil/coe/toppics/atd/recommend/all.pd
f. Consultado em 17/03/2001. April, 1998.
[Mowbray,
1995]
Mowbray,
CORBA
T.,
Systems
J.,
Zahavi,
Integration
R.
The
Using
Essential
Distributed
Objects. John Wiley & Sons, 1995.
[Oberndorf, 1997] Oberndorf, P. Facilitating Component-Based
Software Engineering: COTS and Open Systems, In
Fifth International Symposium on Assessment of
Software Tools. June 1997.
[Objecteering,
2001]
Tool.
Objecteering
Disponivel
Software.
site
Objecteering/UML
Objecteering
URL:http://www.objecteering.com.
Software,
Consultado
em
10/07/2002.
[OMG, 1996] Object Management Group. The Common Object Request
Broker: Architecture and Specification, revision
2.4.
Disponível
site
OMG
(1996),
URL:
http://www.omg.org/technology/documents/formal/c
orbaiiop.htm. Consultado em 10/04/2001.
[OMG, 2001] Object Management Group. Unified Modeling Language
1.4
specification.
Management
Disponível
Group,
site
Object
URL:
http://www.omg.org/technology/documents/formal/u
ml.htm. Consultado em 01/12/2002.
137
Referências Bibliográficas
[OMG,
2002]
Object
(CCM)
Management
3.0.
Group.
Disponível
Group,
Corba
site
URL:
Component
Object
Model
Management
http://www.omg.org/cgi-
bin/doc?formal/02-06-65.
Consultado
em
07/11/2002.
[Ommering, 2002] Ommering, R., V. Building Product Populations
with Software Components, In 24th Internation
Conference
on
Software
Engineering
(ICSE).
Orlando, Flórida. 2002.
[Orfali,
1998]
Orfali,
R.,
Harkey,
D.
Client/Server
Programming with Java and CORBA. John Wiley &
Sons, Second Edition, 1998.
[Otte,
1996]
Otte,
R.,
CORBA
Patrick,
The
P.,
Common
Roy,
M.
Object
Understanding
Request
Broker
Architecture. Prentice Hall PTR, 1996.
[Perspective,
2000]
Select
Perspective:
practical
methodology
generation
applications.
Active
Archive
Princeton
for
Softech’s
delivering
Disponível
Solutions
site
Company,
next
The
URL:
http://www. princetonsoftech.com. Consultado em
10/06/2002.
[Poulin,
2001]
Poulin,
J.,
S.
Measurement
and
Metrics
for
Software Components, In Component-Based Software
Engineering:
Putting
the
Pieces
Together,
Addison-Wesley, 2001.
[Prado, 2000] Prado, A, F., Lucrédio, D. MVCASE: Ferramenta
CASE
Orientada
Brasileiro
de
a
Objetos,
Engenharia
de
XIV
Simpósio
Software,
João
Pessoa/PB, 2000.
[Prado, 2001] Prado, A, F., Lucrédio, D. Ferramenta MVCASE Estágio
Construção
Atual:
de
Especificação,
Componentes,
Projeto
XV
e
Simpósio
138
Referências Bibliográficas
Brasileiro
de
Engenharia
de
Software,
Rio
de
Janeiro, 2001.
[Pressman,
2001]
Pressman,
R.,
S.
Software
Engineering:
A
Practitioner's Approach. McGraw-Hill 2001.
[Prieto-Diaz,
1990]
Prieto-Diaz,
Analysis
and
R.,
Software
Arango,
System
G.
Domain
Modeling.
IEEE
Computer Society, Press Tutorial, 1990.
[Rational, 2001] Rational the Software Development Company.
Rational Rose Tool. Disponível site Rational the
Software
Development
Company,
http://www.rational.com/rose.
URL:
Consultado
em
10/07/2001.
[Ross, 1977] Ross, D., T. Structured Analysis (SA): A language
for
communicating
Ideas,
IEEE
Transaction
on
Software Engineering, 1977.
[Rumbaugh,
1991]
Rumbaugh,
R.
Object-Oriented
Modeling
and
Design. Prentice Hall, 1991.
[Rumbaugh, 2002] Rumbaugh, J., Jacobson, I., Booch, G. The
Unified
Modeling
Language
Reference
Manual.
Addison-Wesley, 1999.
[Sametinger, 1997] Sametinger, J.
Software Engineering with
Reusable Components. Springer-Verlag, 1997.
[Seacord, 1999] Seacord, R., C. Software Engineering Component
Repositories,
In
Component-Based
conjunction
International
Software
with
the
Workshop
Engineering,
21th
on
in
International
Conference on Software Engineering (ICSE). Los
Angeles, USA, 1999.
[SEI,
1999a]
Software
Engineering
Institute
(SEI).
Domain
Analysis. Disponível site Software Engineering
Institute
(SEI),
Engineering
Practices,
URL:http://www.sei.cmu.edu/domain-
1999,
139
Referências Bibliográficas
engineering/domain_anal.html.
Consultado
em
10/07/2001.
[SEI,
1999b]
Software
Engineering
Design.
Disponível
Institute
(SEI),
Institute
site
(SEI).
Software
Engineering
Domain
Engineering
Practices,
1999,
URL:http://www.sei.cmu.edu/domainengineering/domain_design.html.
Consultado
em
10/07/2001.
[SEI, 1999c] Software Engineering Institute (SEI). ComputerAided Software Engineering (CASE) Environments.
Disponível site Software Engineering Institute
(SEI),
Engineering
Practices,
1999,
URL:http://www.sei.cmu.edu/legacy/case/case_what
is.html. Consultado em 25/11/2002.
[Sharman, 1999] Sharman, T.
Development
Software
E-Commerce Components, Software
Online,
Vol.7.
Development
Disponível
Online,
site
URL:
http://www.sdmagazine.com/articles/1999/9908/990
8a/9908a.htm. Consultado em 10/08/2002.
[Simos, 1996] Simos, M. Organization Domain Modeling (ODM):
Domain
Engineering
Object-Oriented
as
a
Co-Methodology
Fusion
Techniques.
to
Newsletter,
v.4 1996, Hewlett-Packard Laboratories, pp 1316.
[Soares,
2002]
Soares,
Implementing
Aspects
with
S.,
Laureano,
Distribution
AspectJ,
In
E.,
and
17th
Borba,
P.
Persistence
Conference
on
Object-Oriented Programming, Systems, Languages,
and Applications (OOPSLA), ACM Press, 2002.
[Sommerville, 2000] Sommerville, I. Software Engineering (6th
Edition). Pearson Education, August 2000.
140
Referências Bibliográficas
[Souza, 2001] Souza, H, L. Estudo de modelos de serviços para
middleware e proposta de extensões à plataforma
JAMP.
Dissertação
de
Mestrado.
Universidade
Federal de São Carlos, junho de 2001.
[Stojanovic, 2001] Stojanovic, Z., Dahanayake, A., Sol, H. A
Methodology Framework for Component-Based System
Development
Support,
In
CAiSE/IFIP8.1
Sixth
International Workshop on Evaluation of Modeling
Methods in Systems Analysis and Design, 2001.
[Sun,
2002]
Java
Technologies.
Disponível
site
Sun
Microsystems, URL: http://java.sun.com/products.
Consultado em 07/11/2002.
[Sun, 2002a] Java Remote Method Invocation (RMI). Disponível
site
Sun
Microsystems,
URL:
http://
http://java.sun.com/products/jdk/rmi/index.html.
Consultado em 07/11/2002.
[Sun,
2002b]
Jini
Network
Technology.
Disponível
site
Microsystems,
Sun
URL:
http://wwws.sun.com/software/jini/.
Consultado
em 07/11/2002.
[Szyperski, 1998] Szyperski, C. Component Software – Beyond
Object-Oriented Programming. Addison-Wesley and
ACM Press, 1998.
[Tran, 1997] Tran, V., Liu, D. A Procurement-centric Model for
Engineering
Component-based
Software
Systems.
Proceedings of the Fifth International Symposium
on Assessment of Software Tool. June 1997.
[Travassos, 2002] Travassos, G., H., Gurov, D., Amaral, E.
Introdução
Experimental.
à
Engenharia
Relatório
de
Técnico,
Federal do Rio de Janeiro. 2002.
Software
Universidade
141
Referências Bibliográficas
[Trevelin, 2001] Trevelin, L., C., Ferreira, M. M., Souza, L.
F., H. JAMP - Java Architecture For Multimedia
Processing. Universidade Federal de São Carlos.
2001.
[Van
Solingen,
1999]
Van
Solingen,
R.,
Berghout,
E.
The
Goal/Question/Metric Method: A Practical Guide
for Quality Improvement of Software Development,
McGrawn Hill, 1999.
[Wang, 2001] Wang, N., Schmidt, D., C., O’Ryan, C. Overview of
the CORBA Component Model, in Component-Based
Software
Engineering:
Putting
the
Pieces
Together, Addison-Wesley, 2001.
[WCOP, 2002] 7th International Workshop on Component-Oriented
Programming (WCOP) in conjunction with the 16th
European
Conference
on
Object-Oriented
Programming (ECOOP), Málaga, Spain, 2002.
[Weinreich,
2001]
Weinreich,
Models
and
R.,
Sametinger,
Component
Principles,
in
Engineering:
Putting
J.
Services:
Component
Concepts
Component-Based
the
and
Software
Pieces
Together,
Addison-Wesley, 2001.
[Werner,
2000]
Werner,
C.,
Desenvolvimento
M.,
L.,
Baseado
em
Braga,
R.,
M.
Componentes,
XIV
Simpósio Brasileiro de Engenharia de Software,
Minicursos e Tutoriais, João Pessoa/PB, 2000.
[Werner,
2000a]
Werner,
C.,
M.,
L.,
and
et.
al.
Projeto
Odyssey. Universidade Federal do Rio de Janeiro,
2000.
Disponível
site
Projeto
Odyssey,
URL:
http://www.cos.ufrj.br/~odyssey/.
[Wills,
2001]
Wills,
Catalysis
A.,
C.
Components
Techniques
Infrastructures,
In
for
and
Connectors:
Designing
Component-Based
Component
Software
142
Referências Bibliográficas
Engineering:
Putting
the
Pieces
Together,
Addison-Wesley, 2001.
[Williams,
2001]
Williams,
J.
The
Components,
In
Engineering:
Putting
Business
Case
Component-Based
the
for
Software
Pieces
Together,
Addison-Wesley, 2001.
[Wohlin, 2000] Wohlin, C., Runeson, P., Höst, M., Ohlsson, C.,
Regnell,
B.,
Wesslén,
Software
Engineering:
A.
an
Experimentation
Introduction,
in
Kluver
Academic Publishers, Norwell, MA, 2000.
[W3C, 2001] W3C - World Wide Web Consortium. Extensible Markup
Language (XML) 1.0 Second Edition. Disponível
site
W3C
-
World
Wide
Web
Consortium,
URL:
http://www.w3.org/TR/2000/REC-xml-2000-10-06.
Consultado em 10/07/2001.
[Yoder, 1998] Yoder, J., W., Johnson, R., E., Wilson, Q., D.
Connecting
Databases,
Business
In
Objects
Pattern
to
Languages
Relational
of
Programs
(PLoP), Monticello, Illinois, USA,1998.
[Yoder, 2002] Yoder, J., W. Software Patterns, In The Second
Latin American Conference on Pattern Languages
of Programming (SugarLoafPlop), Tutorial Notes,
Rio de Janeiro, Brasil, 2002.
[Yunwen, 2001] Yunwen, Y. Supporting Component-Based Software
Development
Systems,
PhD
with
Active
Thesis,
Component
University
Repository
of
Colorado,
2001.
[Yunwen, 2002] Yunwen, Y., Fischer, G. Supporting Reuse by
Delivering
Task-Relevant
and
Personalized
Information, In 24th International Conference on
Software Engineering. Orlando, USA, 2002.
Referências Bibliográficas
143
[Zelkowitz, 1997] Zelkowitz, M., V., Wallace, D. Experimental
Validation in Software Engineering, Conference
on Empirical Assessment in Software Engineering,
Keele University, Staffordshire, UK, March 1997.
Apêndice
QT1 - QUESTIONÁRIO INDIVIDUAL PARA PARTICIPANTES DO
EXPERIMENTO
ID: ______
Técnica utilizada: ( ) Ad-hoc
( ) Abordagem de DBCD
Domínio: _____________________________________
Data: ___/___/_______
Curso: ( ) Ciência da Computação ( ) Bacharelado em Informática ( ) Processamento de
dados
( ) Outros __________________________
Nível: ( ) Graduação
Horário ( ) Diurno
( ) Mestrado
( ) Noturno
( ) Doutorado
( ) Especialização
Período atual: _____ do total de ____ semestres
Em qual das categorias abaixo você melhor se encaixa, enquanto desenvolvedor?
( ) Não tenho experiência em desenvolvimento de sistemas desse tipo (sistemas comerciais)
( ) Desenvolvi alguns projetos desse tipo durante disciplinas de graduação/pós-graduação,
usando análise estruturada/essencial
( ) Desenvolvi alguns projetos desse tipo durante disciplinas de graduação/pós-graduação,
usando análise orientada a objetos
( ) Desenvolvi, profissionalmente, alguns projetos nesse domínio (até 3)
( ) Desenvolvi, profissionalmente, muitos projetos nesse domínio (mais de 4)
( ) Outros, especifique: __________________________________________________
Por favor, informe quais disciplinas você já cursou na área de análise de sistemas/engenharia
de software
___________________________________________________________________________
145
Apêndice
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Conhece linguagens orientadas a objetos? ______ Quais?
____________________________________________
Conhece alguma tecnologia de distribuição? ______ Quais?
____________________________________________
Marque sua experiência ou as atividades (cargos) que já exerceu ou exerce, na área de
desenvolvimento de componentes de software:
( ) Desenvolvedor de Componentes
( ) Desenvolvedor de Aplicações (com componentes)
( ) Arquiteto de Software
( ) Gerente de projeto baseado em componentes
( ) Professor (universitário) de informática (disciplinas relacionadas ao DBC)
( ) Outras: ________
Já participou do desenvolvimento de quantas aplicações utilizando alguma técnica de DBC?
Grande Complexidade:
( )Nenhum
( ) De 1 a 2
( ) Entre 3 e 7
( )Maior que 7
( ) De 1 a 2
( ) Entre 3 e 7
( )Maior que 7
( ) Entre 3 e 7
( )Maior que 7
Média Complexidade:
( )Nenhum
Pequeno Complexidade:
( )Nenhum
( ) De 1 a 2
Relacione os domínios de aplicações dos projetos que você participou utilizando os conceitos
e técnicas de DBC. (Coloque na ordem decrescente de experiência)
(Exemplos de domínio de aplicações: educacional, hospitalar, administrativo, financeiro, científico)
R._____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
Se for o caso, em quais fases do ciclo de vida do desenvolvimento de componentes já
participou?
( ) Especificação de Requisitos
( ) Projeto
( ) Implementação
( ) Teste
( ) Manutenção
( ) Outra (especificar):_____
146
Apêndice
Como você classificaria seu entendimento em relação a componentes de software
(conceituação, objetivos e viabilidade do componente):
( ) Excelente
( ) Alto
( ) Bom
( ) Médio
( ) Baixo
( ) Nenhum
Marque os subitens (e a quantidade a eles referentes), que dizem respeito a seu grau de
treinamento relacionados com o desenvolvimento de componentes de software:
Cursos (até 8 hs):
( ) Nenhum
( ) De 1 a 2
( ) Entre 3 e 7
( ) >7
( ) De 1 a 2
( ) Entre 3 e 7
( ) >7
( ) Entre 3 e 7
( ) >7
( ) Entre 3 e 7
( ) >7
( ) Entre 3 e 7
( ) >7
Cursos (até 40 hs):
( ) Nenhum
Cursos (mais de 40 hs):
( ) Nenhum
( ) De 1 a 2
Simpósios/Congressos:
( ) Nenhum
( ) De 1 a 2
Publicações de artigos nacionais:
( ) Nenhum
( ) De 1 a 2
Publicações de artigos internacionais:
( ) Nenhum
( ) De 1 a 2
( ) Entre 3 e 7
( ) >7
Qual sua maior área de interesse:
( ) Engenharia de Software
( ) Inteligência Artificial
computadores
( ) Computação Gráfica
( ) Redes/Sistemas Distribuídos ( ) Banco de Dados
( ) Hipermídia
( ) Arquitetura de
( ) Outros : _______________________________
Observações ou comentários: (favor anotar no verso, caso o espaço abaixo seja insuficiente)
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
147
Apêndice
Coleta de Tempo para desenvolvimento do projeto
Data
Início
Término
Resumo das Atividades:
Atividade
Tempo
(pessoas/hora)
Atividades
Total de
horas
Apêndice
148
QT2 – QUESTIONÁRIO INDIVIDUAL PARA PARTICIPANTES DO
EXPERIMENTO
ID: ______
Técnica utilizada: AD-HOC
Quanto ao documento de requisitos do projeto, responda:
1) Você teve alguma dificuldade em entender os requisitos? Quais?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
2) Você encontrou algum requisito em duplicidade? Quais?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
3) Você encontrou requisitos vagos ou inconsistentes, que merecem ser mais bem detalhados?
Quais?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
4) Comentários adicionais
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Quanto à modelagem, projeto e implementação usando a técnica AD-HOC, responda:
5) Quais as dificuldades encontradas na fase de análise (justificar)
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Apêndice
149
6) Quais as dificuldades encontradas na fase de projeto (justificar)
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
7) Quais as dificuldades encontradas na fase de implementação?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
8) Quais as maiores dificuldades para conclusão do projeto?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Outras dificuldades:
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Apêndice
150
QT2 - QUESTIONÁRIO INDIVIDUAL PARA PARTICIPANTES DO
EXPERIMENTO
ID: _______
Técnica utilizada: Abordagem de DBCD
Quanto ao documento de requisitos do domínio de comércio eletrônico, responda:
1) Você teve alguma dificuldade em entender os requisitos? Quais?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
2) Você encontrou algum requisito em duplicidade? Quais?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
3) Você encontrou requisitos vagos ou inconsistentes, que merecem ser mais bem detalhados?
Quais?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
4) Comentários adicionais
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Quanto à utilização da abordagem de DBCD, responda:
5) Quais as dificuldades encontradas no entendimento da abordagem (justificar)
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Apêndice
151
6) Quais as dificuldades encontradas para utilização da abordagem?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
7) Quais as dificuldades encontradas utilizando a ferramenta MVCASE? Especifique, por
exemplo, se o treinamento foi suficiente para cobrir os aspectos necessários para
desenvolvimento do projeto? Problemas de instalação, da linguagem, etc...
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
________________________________________________________________________
Outras dificuldades:
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________