Escolar Documentos
Profissional Documentos
Cultura Documentos
Resumo:
1
Professora Associada, Universidade Estadual de Maringá*
Departamento de Informática
Av. Colombo, 5790 87020-900 Maringá-PR, Brasil
itana@din.uem.br
http://www.din.uem.br/~itana
2
Lecturer, Department of Computing
The Open University
Milton Keynes MK7 6AA, Inglaterra
l.barroca@open.ac.uk
http://mcs.open.ac.uk/lmb3
3
Professora Associada, emhuzita@ din.uem.br
http://www.din.uem.br/~emhuzita
4
Mestranda, DCA-FEE-Unicamp
6.1 Introdução
A engenharia de software tem por objetivo tanto a melhoria da qualidade dos produtos e
processos de software quanto o aumento da produtividade e redução dos custos e
esforços para produção de software. Assim, a definição de técnicas de desenvolvimento
de software que enfatizem princípios como extensibilidade, flexibilidade e
principalmente reutilização, dentre outros, é de grande relevância no contexto da
engenharia de software.
A seção 6.2 apresenta o conceito de componente. A seção 6.3 apresenta uma descrição
sumária do sistema exemplo. A seção 6.4 apresenta um PCDB baseado no Catalysis. As
seções seguintes seguem as fases definidas no PCDB, apresentado na seção 6.4, que
são: especificação de requisitos, especificação do sistema, projeto da arquitetura e
projeto interno dos componentes. Finalmente, na seção 6.9, apresentamos os
comentários finais.
5
Component Based Development.
6
Unified Modelling Laguage.
7
[D’SO99] é a referência básica para o método Catalysis. Informações sobre o método também podem
ser encontradas em http://www.catalysis.org.
6.2 Componentes
Um componente é definido como uma unidade de software independente, que encapsula
dentro de si seu projeto e implementação, e oferece interfaces bem definidas para o
meio externo. Por meio destas interfaces, um componente pode se unir a outros
componentes e dar origem aos sistemas baseados em componentes [D’SO 99]. Um
componente apresenta interfaces que separam sua especificação da implementação.
Essas interfaces não permitem que os usuários conheçam os detalhes de implementação
do componente. A especificação de um componente é, normalmente, publicada
separadamente de seu código fonte por meio da especificação das interfaces oferecidas
por ele.
Componentes de software podem ser constituídos por componentes mais simples, assim
o processo de construção de componentes pode ser considerado como recursivo. Nesse
contexto, um componente pode ser não apenas código pronto para reutilização mas
também unidades de projeto que têm significado próprio. A exemplo, frameworks
podem ser vistos como componentes flexíveis, em nível de projeto.
Para que a reutilização de componentes seja possível é preciso que estes sejam
adaptáveis. O projeto de um componente deve ser conduzido de tal forma que além de
tornar a sua execução correta e eficiente, deve ser genérico para que se torne adaptável a
vários propósitos e não somente ao propósito ao qual será primeiramente aplicado
[D’SO 99].
Muitas vezes pode ser útil entender a distinção entre objeto, no contexto do paradigma
de orientação a objetos, e componente. Um componente geralmente trabalha com outros
para apoiar uma particular ação em nível de negócio (caso de uso) enquanto um objeto
geralmente representa uma instância de um conceito do negócio[D’SO 99]. A princípio,
o nível de granulosidade de um componente é maior do que o de um objeto.
Para uma ilustração simples, a figura 6.10 mostra um sistema baseado em componentes
construído a partir da paleta de beans (componentes) do VisualAge® [ITE 99]. A
aplicação tem uma lista de partes e uma entrada para adicionar partes à lista. Para
construir a aplicação são selecionados da paleta de componentes do VisualAge® os
seguintes componentes: um campo de texto, dois botões, uma lista e dois rótulos. Estes
componentes são selecionados e adicionados na área de projeto, podendo ser adequados
as suas cores, tamanhos e fontes, como o projetista desejar. Em seguida, os
componentes são associados às funções que devem realizar. Assim, o botão Exit e a
Janela da aplicação são associados ao método dispose(), indicando que ao acionar o
botão ou o X no canto superior direito da janela, esta deverá ser fechada. Da mesma
forma o botão Add é associado a um método add(string) da List of Parts, tomando como
entrada o string contido na caixa de texto com o rótulo Part.
Caixa de texto
Part
Add
List of Parts
Rótulos Botões
Exit
dispose() dispose()
Lista
Uma vez entendida as características desejadas pelo cliente, deve-se elaborar o projeto
correspondente. A elaboração do projeto constitui-se de várias etapas como: elaborar o
projeto arquitetônico, estrutural, elétrico e hidráulico. Note que diferentes profissionais
podem estar envolvidos, cada um em sua especialidade (ex. o engenheiro civil, o
arquiteto e o engenheiro elétrico). Ao projeto elaborado estará associada uma obra a ser
construída, que na verdade consistirá na execução de várias tarefas. Dentre as tarefas
(normalmente já predefinidas no caso da construção civil), podem ser destacadas: fazer
a terraplanagem, madeiramento, levantar paredes, azulejar, efetuar pintura, entre outros.
Essas tarefas são executadas por mestre de obras, pedreiro, azulejista e eletricista. Para a
execução dessas tarefas, deve-se definir e alocar os recursos materiais e humanos
necessários, agendar essas tarefas, além de monitorar a execução destas tarefas.
Especificação de
Requisitos
Contexto do sistema
Cenários
Projeto de interface
Especificação do do usuário
sistema
Modelo de tipos e
especificações de operações
Fluxo de diálogo,
protótipo, usabilidade
Descrever o comportamento externo do sistema
através do modelo de domínio do problema
Dicionário
Plataforma,
arquitetura física
Projeto da arquitetura
Arquitetura de
aplicação lógica
Mapeamento de classes,
Especificações de transações, etc.
classe e interface
Projeto interno dos
componentes
Implementação e teste
8
Montar é utilizado como tradução de “to assemble”. A semântica desejada é a de montar componentes
de forma similiar a como montamos quebra-cabeças.
1. Construir1 – construir o modelo do domínio para captar termos, regras e
tarefas do domínio.
2. Construir2-3 – refinar o modelo do domínio para especificar o sistema
construindo o modelo de tipos do domínio. O mapa de recuperação é
definido de maneira top-down.
3. Construir4-5 – particionar e refinar para construir os modelos de projeto.
Novamente, o mapa de recuperação é definido a partir do modelo de tipos do
sistema, que é distribuído através dos componentes de projeto encontrados.
Construir 1 Montar 1
Refinamento: Construir 2
mapeando da
Montar 5
especificação ao
domínio
Especificação do sistema :
comportamentos e modelo de tipos
Refinamento, recuperação:
mapeamento dos componentes
internos para especificação do Construir 4
sistema
Montar 3
Montar 2
Construir 5
Construir
Contratar Realizar Pagar
serviço obras serviço
Construtora Cliente
Obra
Tipo de objeto
CasaCentro:
Obra
Construtora
CasaPraia:
Obra
Obra
Cliente Gerente
Instâncias de objetos
Ocorrência de ações
Informar Andamento
Cliente Gerência de
Construção Civil
Estudar Viabilidade
Contratar Serviço
Gerência
Comercial
Requisitar Orçamento Gerenciar Obra
Realizar Pagamento
Gerência Gerência Gerência de
Financeira Pessoal Materiais
Solicitar Material
Fornecedor
Paga
1..*
Possui Possui
Cliente Serviço Fatura
1..*
1..*
1..*
Reponsável por Administra
Gerência Financeira
Gerência Comercial
Gerência de Materiais
Gerência Pessoal
A construtora usa um sistema de software para gerenciar as obras. A partir desse ponto
passa-se a pensar no comportamento do software a ser desenvolvido, pois até agora foi
tratada a modelagem do domínio no qual o software está inserido. Assim, refinando a
ação Gerenciar obras do domínio apresentado na figura 6.5, obtemos o diagrama de
casos de uso mostrado na figura 6.7.
Elaborar Projeto
Hidráulico
Projetar Estrutura
Rebocar
Engenheiro Construir Alicerce
Civil Levantar Paredes
<<inclui>>
<<inclui>>
<<inclui>>
<<inclui>> <<inclui>>
Terraplanar e Alinhar Colocar Teto
Terreno
Construir <<inclui>>
<<inclui>> <<estende>>
Telha de Fibra
Construir Telhado
Mestre de
Obras Fazer Madeiramento <<estende>>
Telha de Cerâmica
Pedreiro
Carpinteiro
Eletricista Encanador
9
Note que o estereótipo <<inclui>> substitui o relacionamento estereótipo <<usa>> na versão mais
recente de UML. Veja [Rum99] e [Boo99] para detalhes e exemplos de utilização.
10
O diagrama correspondente não contém a seta tracejada pois usamos uma versão anterior da ferramenta
Rational Rose® que não suporta a seta tracejada.
O diagrama de casos de uso não representa a seqüência das ações. Esta representação
pode ser obtida por meio de diagramas de seqüência, que mostram os vários cenários
em que as ações podem ocorrer. As barras horizontais representam as ocorrências das
ações e as barras verticais representam instâncias de objetos. A figura 6.9 mostra o
arquiteto Jonas numa ação iterativa de projetar a arquitetura, em seguida o engenheiro
civil Paulo realiza o projeto estrutural e hidráulico para então o engenheiro elétrico
Rogério realizar o projeto elétrico. Após isso, o engenheiro civil Paulo envia mensagem
ao mestre de obras Sérgio para terraplanar, que em seguida envia mensagem ao pedreiro
Marcos que também participa desta ação, e assim por diante. O paralelismo entre as
barras horizontais representa o correspondente paralelismo das ações. A pequena elipse
hachuriada representa o início de uma ação.
O modelo estático de tipos para o software Gerenciador de Obras, obtido a partir dos
diagramas de casos de uso, diagrama de tipos e diagramas de seqüência, desenvolvidos
na seção anterior, é representado na figura 6.10.
Viabilidade
Atende 0..*
Implementa
Projeto Possui Necessidade_Cliente
1..* 1..*
1..*
1..*
Desempenho
Custo arquiteto
Avalia Estima
Possui Tarefa
1..* Utiliza engenheiro elétrico
1..* Material
0..* 1..*
eletricista
encanador
carpinteiro
Gerenciador de Obras
Viabilidade
Atende 0..*
Implementa
Projetar Projeto Possui
1..*
Necessidade_Cliente
Auxiliar
1..*
Arquiteto Arquitetura
1..*
Pedreiro
na construção
Arquitetônico Estrutural Hidráulico Elétrico
TelhadoCerâmica TelhadoFibra
Obra
1..*
Elaborar Realizar
Engenheiro Elétrico Projeto Desempenho
arquiteto
Instalação Eletricista
Elétrico Avalia Estima
Custo
Elétrica
Possui Tarefa
1..* Utiliza
1..* engenheiroelétrico
0..* 1..* Material
Registra Emprega engenheiro civil
Agenda
RegistrodeExecução
mestre de obras
Projetar e
1..*
Possui Cargo
Realizar
Pessoa
Monitorar 0..* 0..*
pedreiro Instalação
Engenheiro Civil Encanador
a Construção Hidráulica
eletricista
encanador
carpinteiro
Conduzir Fazer
Mestre de Obras a Construção Madeiramento Carpinteiro
do Telhado
A cada um dos tipos do modelo de tipos estão associados atributos e ações inerentes a
estes. A figura 6.12 ilustra exemp los de atributos e ações dos tipos
Necessidade_Cliente, Obra e Custo.
«type»
«type» Custo
Necessidade_cliente
-custo_final : Real
-tipo_casa : enumerate = (plana, sobrado) -padrão : enumerate = (A, B, C, D)
-custo_limite : Real +estabelece_padrão(padrão_escolhido : enumerate)
+estabelece_custo(valor : Real) +estabele_custo_individual(valor : Real)
«type»
Obra
-nome : String
-custo_total : Real
+insere_tarefa(nova_tarefa : Tarefa)
Catalysis [D’SO 99] sugere que o projeto da arquitetura de um sistema de software seja
dividido em duas partes relacionadas:
?? arquitetura de aplicação – diz respeito a como particionar a própria aplicação
em um conjunto de componentes que colaboram entre si. Nesse aspecto estão
relacionados as questões de adoção de um estilo de arquitetura (ex.
elementos, portas e conectores) e de utilização de componentes heterogêneos;
?? arquitetura técnica – descreve a estrutura de pacotes considerando uma infra-
estrutura de comunicação entre os pacotes, tomando os componentes em um
nível de granulosidade maior. A arquitetura técnica define, além de eventuais
detalhes de hardware e protocolos, o mecanismo de comunicação entre os
componentes a ser utilizado (ex. CORBA, Java/RMI e COM) [ORF 96, PRI
99].
Elaborando
Projetos Definindo e
Arquiteto e Engenheiro
Alocando
Elétrico Recursos
Engenheiro Civil
Agendando
Monitorando
Tarefas
Tarefas
Executando
Tarefas
Uma divisão vertical mais refinada do Gerenciador de Obras é mostrada na figura 6.14,
que toma como base o modelo de colaboração obtido anteriormente. A elaboração
desses diagramas oferece uma outra abstração do sistema forçando o projetista a refletir
sobre as perspectivas externas de diferentes categorias de usuários (ou subsistemas) e
sobre como melhor agrupar os serviços do sistema para atender essas perspectivas.
Elaborando Projetos Definindo e Alocando Recursos Agendando Tarefas Executando Tarefas Monitorando Tarefas
Definindo Tarefas
Definição dos projetos básicos para a construção de uma obra: projetos arquitetônico, estrutural, hidráulico e elétrico
A composição de pacotes, por exemplo, envolve a análise dos tipos e ações importadas
de diferentes pacotes para verificar a compatibilidade e como se pode dar a junção
desses de modo a obter um resultado consistente. [D’SO 99] apresenta algumas regras
de composição de modelos, porém esse problema é complexo e demanda estudos mais
detalhados. O problema é, de certa forma, similar ao problema de integração de objetos
ou dados [SPA 94, GIM 97].
Elaborando Projetos Agendando Tarefas Executando Tarefas Monitorando Tarefas
Definindo e Alocando Recursos
engenheiro elétrico
Agenda
Pessoa
engenheiro civil
Registro de Execução
Pessoa Cargo Desempenho
Necessidade_Cliente
mestre de obras
Tarefa
pedreiro
eletricista
Material
encanador
carpinteiro
Definindo Tarefa
Tarefa
Obra Projeto
O método Catalysis [D’SO 99] considera que descrições de mais alto nível como
especificações e projetos também podem ser particionadas e reutilizadas, ao contrário da
convencional reutilização de código. Esses elementos reutilizáveis de mais alto nível
são chamados de frameworks de modelos11 . Frameworks são representados como
pacotes genéricos 12 que podem ser importados substituindo-se os elementos genéricos
pelos elementos específicos da aplicação, quando apropriado.
O framework de agenda de tarefas, apresentado na figura 6.16, foi obtido por meio de
uma análise comparativa entre gerenciadores de sistemas de workflow e gerenciadores
de processo de software, tomando como base um padrão de gerenciadores de processo
desenvolvido anteriormente[GIM 99]. No contexto destes sistemas, o diagrama de
pacotes para o gerenciador de processos de software foi desenvolvido identificado-se
também o pacote Agendando Tarefas. As análises realizadas mostraram o potencial de
reutilização desse pacote, assim ele foi especificado e projetado, seguindo os conceitos
de framework de modelos, para que pudesse ser reutilizado em outros sistemas como
estamos fazendo para o Gerenciador de Obras.
11
Framework de Modelo consiste na tradução, utilizada neste trabalho, para o termo Model Framework
apresentado pelo método Catalysis.
12
Esse pacote genérico é chamado no Catalysis de Framework ou Template Package.
PKG_AG_TAREFAS
FrSenha <FrCargo>
Engenheiro de
Gerente de Software -Car_Nome : String
Projeto +Valida() +Car_Remove()
+Car_Cria()
+Car_Altera()
Utiliza
0..n
Visualizar agenda 0..n Possui
<FrProjeto>
individual <FrIntAgenda>
<FrAtor> -Pro_Nome : String
-TFAtor : String +Pro_Remove()
-TFCargo : String 1..n 0..n
-Ator_Nome : String Possui +Pro_Cria()
-TFPai : String -Ator_Login : String +Pro_Altera()
-TFTarefa : String -Ator_Senha : String
-TFProjeto : String 1..n
+Ator_Remove()
Agendar tarefas -TFData_Ini : String
+Ator_Cria() 1..n Possui
-TFAndamento : String
-TFData_Ter : String +Ator_Altera()
-TFStatus : Slider
+Aplicar()
+Cancelar() 1
Possui
+Remover() <FrAgenda>
Visualizar todas as +Adiar()
tarefas agendadas +Agendar()
-Ag_Status : Int
+Ver_Alteracoes()
+Visualizar() -Ag_Data_Inicio : String
1..n -Ag_Data_Termino : String
+Status() 0..n 1..n
-Ag_Andamento : Int
+Atualiza_Pai()
+Desabilita() -/Ag_Duracao : Int
+Inicia() +Get_ID_Ator() <FrTarefa>
+Restaura() +Get_ID_Processo()
+Sair() +Get_ID_Cargo() -Tar_Nome : String
+Get_ID_Tarefa() +Tar_Remove()
+Tar_Cria()
+Tar_Altera()
Cargo Obra
FrCargo FrProjeto
Agenda
PKG_AG_TAREFA FrAgenda
refa
FrTa FrIntAgenda
FrAtor
Tarefa Pessoa
AgendaConsCivil
Standards de Colaboração
Para se construir sistemas a partir de componentes é necessário a existência de uma
standardização com a qual os desenvolvedores devem estar de acordo, assim como
existem standards para os componentes de hardware. Esses standards definem como os
componentes podem interoperar. Os standards podem ser classificados como
segue[D’SO 99]:
?? horizontais: incluem mecanismos e serviços tais como: request broker,
segurança, transações, diretórios, repositórios de interface. CORBA e COM
[ORF 96, PRI 99] é um exemplo de standard que oferece esses mecanismos;
?? verticais : incluem uma terminologia comum em relação aos conceitos
relacionados ao domínio para o qual o componente se aplica. Por exemplo, um
engenheiro civil deve ter o mesmo rótulo e significado para que componentes
que usam esses conceitos façam sentido juntos;
?? inter-componentes: definem os tipos de mecanismos de interação entre os
componentes. Por exemplo: conectores que apoiam operações de call and return
síncrono ou assíncrono e conectores com propagação implícita de eventos.
Kit de Componentes
Um kit de componentes é uma coleção de componentes projetados para trabalharem em
conjunto. Um kit de componentes é construído a partir de um conjunto de princípios que
forma o tipo de arquitetura de software do kit.
Catalysis [D’SO 99] aborda uma arquitetura de componentes que contém o seguinte
conjunto de princípios:
?? componentes: qualquer elemento que realiza uma tarefa bem definida, como
definido anteriormente;
?? portas: as interfaces expostas que definem os plugs (tomadas) e soquetes dos
componentes, locais por meio dos quais os componentes oferecem acesso aos
seus serviços e a partir dos quais eles acessam os serviços de outros. Um plug
pode ser conectado a qualquer soquete do tipo compatível usando um conector
adequado;
?? conectores: as conexões entre portas que permitem a montagem de uma
coleção de componentes para construir um produto de software ou um
componente maior. Conectores conectam portas.
Componentes Heterogêneos
Componentes heterogêneos são componentes que não foram projetados para trabalhar
em conjunto e que, não, foram necessariamente especificados para trabalhar em um
outro software que não aquele para o qual ele é empregado. Esse tipo de componente
pode ser utilizado em um sistema que não segue um tipo de arquitetura como definido
no item anterior pois ele não tem portas e conectores standardizados.
O ponto chave neste tipo de composição é encontrar uma arquitetura ad hoc que permita
a interoperação dos componentes. Componentes adicionais (glue components) podem
ser incorporados para executar funções complementares ou melhorar os serviços
oferecidos pelos componentes conectados.
6.8.2 Exemplos
A figura 6.18 [D’SO 99, WIL 99] ilustra a composição de um kit componentes por meio
de um sistema de componentes que simula uma coleção de peças de hardware.
O motor tem duas portas inícia e para que recebem informações dos botões aos quais
estão conectadas. Além disso, tem uma porta de saída velocidade que está conectada a
um medidor. A conexão entre os botões e o motor indica um tipo de conector em que a
ocorrência gerada por um compone nte ativa um método de outro componente enquanto
a conexão entre motor e medidor indica um tipo de conector por meio do qual um par de
valores é mantido continuamente em sincronização.
apertado
Botão
inicia
velocidade valor
Motor Medidor
para
Botão apertado
Departamentos
Pedidos de compras
Orçamentos
solicitados
Pagamentos
Vaor gasto
plug-ins
Solicitações de
Agendamento
Aplicação Agenda de
Tarefas
Solicitações de
armazenamento e
recuperação de dados
Servidor de
Banco de
Dados
Estudos mais detalhados ainda são necessários para melhor especificar a agenda de
tarefas como um componente com interfaces explícitas. A exemplo, note que os
métodos Agendar() e Visualizar() da classe AgendaConsCivil representam interfaces
externas potenciais para o componente agenda enquanto os demais métodos são
internos.
AgendaConsCivil