integrando padrões através de meta-modelos - Departamento de ...

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA APLICADA
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO
INTEGRANDO PADRÕES
ATRAVÉS DE META-MODELOS
LYRENE FERNANDES DA SILVA
DISSERTAÇÃO DE MESTRADO
Orientadora: Virgínia C. Carneiro de Paula
2002

Lyrene Fernandes da Silva
INTEGRANDO PADRÕES
ATRAVÉS DE META-MODELOS
Dissertação apresentada ao Departamento de Informática
e Matemática Aplicada da Universidade Federal do Rio
Grande do Norte, como requisito parcial à obtenção do
título de Mestre em Sistemas e Computação.
Área de concentração: Engenharia de Software
Orientadora: Profª. Virgínia C. Carneiro de Paula
Universidade Federal do Rio Grande do
Norte
Natal
Universidade Federal do Rio Grande do Norte
2002

Aos meus pais, Edilson e Graça,
que empenham suas vidas na
realização de meus ideais.
iii

SUMÁRIO
LISTA DE FIGURAS ............................................................................................. VII
LISTA DE TABELAS................................................................................................ X
RESUMO...................................................................................................................XI
ABSTRACT............................................................................................................. XII
1. INTRODUÇÃO ...................................................................................................1
1.1 OBJETIVOS ...........................................................................................................3
1.2 ESTRUTURA DA DISSERTAÇÃO..............................................................................4
2. ESTADO DA ARTE............................................................................................6
2.1 ARQUITETURA DE SOFTWARE ...............................................................................6
2.1.1 Estilos ou Padrões Arquiteturais...................................................................9
2.1.2 Visões .........................................................................................................16
2.2 LINGUAGENS UTILIZADAS ..................................................................................18
2.2.1 UML...........................................................................................................19
2.2.2 Linguagem de Especificação Z....................................................................21
2.2.3 Utilizando UML e Z....................................................................................21
2.3 CORBA.............................................................................................................22
2.3.1 Considerações Iniciais................................................................................22
2.3.2 Arquitetura de Gerenciamento de Objetos ..................................................24
2.3.3 Estrutura de CORBA ..................................................................................27
2.3.4 Objetos de uma Aplicação ..........................................................................30
2.4 CONCLUSÕES .....................................................................................................31
3. UM META-MODELO PARA MODELAR UMA FAMÍLIA DE
APLICAÇÕES DISTRIBUÍDAS..............................................................................33
3.1 METODOLOGIA...................................................................................................34
3.2 NOTAÇÃO E TERMINOLOGIA ...............................................................................36
3.3 UM META-MODELO PARA MODELAR ESTILOS .....................................................37
3.3.1 Estrutura Estática.......................................................................................43
iv

3.3.2 Estrutura Dinâmica ....................................................................................54
3.3.3 Estereótipos................................................................................................57
3.4 UM META-MODELO PARA MODELAR ARQUITETURAS EM CAMADAS....................59
3.4.1 Estrutura Estática.......................................................................................59
3.4.2 Estrutura Dinâmica ....................................................................................62
3.4.3 Variações do Estilo Camadas .....................................................................63
3.5 UM META-MODELO PARA MODELAR APLICAÇÕES BASEADAS EM CORBA..........66
3.5.1 Estrutura Estática.......................................................................................67
3.5.2 Estrutura Dinâmica ....................................................................................80
3.6 UM META-MODELO PARA MODELAR UMA FAMÍLIA DE APLICAÇÕES DISTRIBUÍDAS
................................................................................................................................82
3.6.1 Estrutura Estática.......................................................................................83
3.6.2 Estrutura Dinâmica ....................................................................................88
3.7 CONCLUSÕES .....................................................................................................89
4. ESTUDO DE CASO..........................................................................................90
4.1 DEFINIÇÃO DO ESTUDO DE CASO ........................................................................90
4.2 UTILIZANDO O META-MODELO PARA MODELAR UMA FAMÍLIA DE APLICAÇÕES
DISTRIBUÍDAS..........................................................................................................91
4.3 CONCLUSÕES .....................................................................................................98
5. TRABALHOS CORRELATOS..........................................................................100
5.1 HOFMEISTER, NORD E SONI..............................................................................100
5.2 DI NITTO E ROSENBLUM...................................................................................101
5.3 EGYED, MEHTA E MEDVIDOVIC........................................................................102
5.4 BUSCHMANN, MEUNIER, ROHNERT, SOMMERLAD E STAL .................................102
5.5 GAMMA, HELM, JOHNSON E VLISSIDES.............................................................103
5.6 CONCLUSÕES ...................................................................................................103
6. CONCLUSÕES E TRABALHOS FUTUROS ...................................................104
6.1 RESULTADOS OBTIDOS.....................................................................................105
6.1.1 Definição dos Meta-modelos.....................................................................105
6.1.2 Modelagem dos Meta-modelos em UML ...................................................107
6.1.3 Especificação dos Meta-modelos em Z......................................................107
6.2 TRABALHOS FUTUROS......................................................................................107
v

6.2.1 Extensões para os Próprios Meta-modelos e a Abordagem em Geral........108
6.2.3 Extensões Quanto a Ferramentas..............................................................108
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................110
ANEXO A - ANÁLISE DA UML COMO LINGUAGEM DE DESCRIÇÃO DE
ARQUITETURA.....................................................................................................115
ANEXO B - ESPECIFICAÇÃO FORMAL EM Z DO META-MODELO PARA
MODELAR ESTILOS. ...........................................................................................118
ANEXO C - ESPECIFICAÇÃO FORMAL EM Z DO META-MODELO PARA
MODELAR ARQUITETURAS EM CAMADAS..................................................122
ANEXO D - ESPECIFICAÇÃO FORMAL EM Z DO META-MODELO PARA
MODELAR APLICAÇÕES BASEADAS EM CORBA – CORBA COMO UM
CONECTOR DA ARQUITETURA. ......................................................................126
ANEXO E - ESPECIFICAÇÃO FORMAL EM Z DO META-MODELO PARA
MODELAR APLICAÇÕES BASEADAS EM CORBA – CORBA COMO UM
COMPONENTE DA ARQUITETURA. ................................................................130
ANEXO F - ESPECIFICAÇÃO FORMAL EM Z DO META-MODELO PARA
MODELAR UMA FAMÍLIA DE APLICAÇÕES DISTRIBUÍDAS COM
MIDDLEWARE CORBA. .......................................................................................135
vi

LISTA DE FIGURAS
FIGURA 1-1 - Transformação do conhecimento durante o desenvolvimento de
software.................................................................................................................1
FIGURA 1-2 - Primeira abordagem de refinamento.......................................................3
FIGURA 2-1 - Diagrama de caixas e linhas representando uma arquitetura. ..................8
FIGURA 2-2 - Duas abordagens de refinamento. ........................................................12
FIGURA 2-3 - Uma arquitetura em camadas para aplicações de negócio.....................14
FIGURA 2-4 - O modelo de referência da OMA. ........................................................25
FIGURA 2-5 - Relação entre a arquitetura OMA e a arquitetura em camadas..............26
FIGURA 2-6 - Modelo de referencia OMA - Uso de interfaces. ..................................26
FIGURA 2-7 - Requisição enviada através do ORB. ...................................................27
FIGURA 2-8 - Estrutura de um ORB. .........................................................................28
FIGURA 2-9 - Modos de invocação de operações. ......................................................31
FIGURA 3-1 - Relação entre os meta-modelos desenvolvidos.....................................35
FIGURA 3-2 - Elementos de modelo UML utilizados. ................................................37
FIGURA 3-3 - Meta-modelo da visão conceitual da arquitetura...................................37
FIGURA 3-4 - Mudanças nas agregações existentes no meta-modelo..........................38
FIGURA 3-5 - Exemplo das agregações modificadas no meta-modelo. .......................39
FIGURA 3-6 - Estrutura estática de um meta-modelo para especificar estilos..............43
FIGURA 3-7 - Esquema Configuração........................................................................45
FIGURA 3-8 - Esquema Componentes........................................................................46
FIGURA 3-9 - Esquema Porta_rec. .............................................................................47
FIGURA 3-10 - Esquema Porta_exp. ..........................................................................48
FIGURA 3-11 - Esquema Conectores..........................................................................49
FIGURA 3-12 - Esquema PapelIN. .............................................................................51
FIGURA 3-13 - Esquema Papel OUT..........................................................................52
FIGURA 3-14 - Esquema Propriedade ........................................................................54
FIGURA 3-15 - Diagrama de seqüência para conexão assíncrona................................55
FIGURA 3-16 - Diagrama de seqüência para conexão síncrona...................................55
FIGURA 3-17 - Diagrama de seqüência para conexão síncrona...................................56
FIGURA 3-18 - Diagrama de seqüência para a ligação entre papéis. ...........................56
FIGURA 3-19 - Diagrama de estados para conexão assíncrona. ..................................56
vii

FIGURA 3-20 - Diagrama de estados para conexão síncrona.......................................57
FIGURA 3-21 - Diagrama de estados para conexão síncrona deferida. ........................57
FIGURA 3-22 - Estereótipos para representação através de caixas e linhas. ................58
FIGURA 3-23 - Instanciação para criar um meta-modelo para modelar arquiteturas em
camadas...............................................................................................................59
FIGURA 3-24 - Exemplo da organização de camadas. ................................................60
FIGURA 3-25 - Esquema Configuração_camadas.......................................................61
FIGURA 3-26 - Estrutura estática do meta-modelo para modelar arquiteturas de
software em camadas...........................................................................................62
FIGURA 3-27 - Esquema Configuração_Camadas......................................................64
FIGURA 3-28 - Instanciação para criar um meta-modelo para modelar aplicações
baseadas em CORBA. .........................................................................................66
FIGURA 3-29 - Exemplo de arquitetura em que CORBA é um conector.....................68
FIGURA 3-30 - Estrutura estática do meta-modelo para modelar aplicações baseadas no
middleware CORBA. ..........................................................................................69
FIGURA 3-31 - Esquema da Configuração_CORBA. .................................................70
FIGURA 3-32 - Esquema do Componente CORBA. ...................................................71
FIGURA 3-33 - Esquema da Porta Divulgadora..........................................................71
FIGURA 3-34 - Esquema Conectores_C. ....................................................................72
FIGURA 3-35 - Esquema PapelIN_C..........................................................................72
FIGURA 3-36 - Exemplo de arquitetura em que CORBA é um componente. ..............73
FIGURA 3-37 - Estrutura estática do meta-modelo para modelar aplicações baseadas no
middleware CORBA. ..........................................................................................74
FIGURA 3-38 - Esquema da Configuração_CORBA. .................................................77
FIGURA 3-39 - Diagrama de seqüência para conexão assíncrona................................80
FIGURA 3-40 - Diagrama de seqüência para conexão síncrona...................................80
FIGURA 3-41 - Diagrama de seqüência para conexão síncrona...................................81
FIGURA 3-42 - Instanciação para criar um meta-modelo para modelar aplicações
baseadas em CORBA e no estilo camadas. ..........................................................82
FIGURA 3-43 - Classe e esquema da Configuração_Camadas. ...................................83
FIGURA 3-44 - Classe e esquema da Configuração_CORBA. ....................................84
FIGURA 3-45 - Classe Configuração_Camadas_CORBA...........................................84
FIGURA 3-46 - Esquema da Configuração_Camadas_CORBA. .................................85
viii

FIGURA 3-47 - Classe e esquema do Componente na
Configuração_Camadas_CORBA........................................................................86
FIGURA 3-48 - Classe e esquema do conector na Configuração_Camadas_CORBA. .87
FIGURA 3-49 - Classe e esquema do Papel_IN na Configuração_Camadas _CORBA.
............................................................................................................................87
FIGURA 3-50 - Estrutura estática do meta-modelo para modelar uma família de
aplicações distribuídas.........................................................................................88
FIGURA 4-1 - Diagrama de casos de uso para a aplicação Caixa Eletrônico. ..............90
FIGURA 4-2 - Arquitetura da aplicação Caixa Eletrônico. ..........................................94
FIGURA 4-3 - Arquitetura da aplicação Caixa Eletrônico. ..........................................95
FIGURA 4-4 - Classes da aplicação Caixa Eletrônico. ................................................96
FIGURA 4-5 - Diagrama de objetos para a aplicação Caixa Eletrônico. ......................97
FIGURA 4-6 - Diagrama de sequência para a função Saldo do Caixa Eletrônico.........98
ix

LISTA DE TABELAS
TABELA 2-1 - Comparação de termos de arquitetura de software...............................10
TABELA 3-1 - CORBA como conector X CORBA como componente.......................79
TABELA 4-1 - Descrição dos casos de uso .................................................................91
x

RESUMO
A área de arquitetura de software vem desempenhando um papel fundamental no
desenvolvimento de sistemas. Seu objetivo inicial de oferecer uma visão geral do
sistema, dando suporte ao gerenciamento de projetos, expandiu-se enormemente, e a
tendência atual é de que ela reduz o gap existente entre a análise e a implementação,
cobrindo todas as fases do design.
Isto significa, porém, que é necessário aproximar ou tornar fácil a evolução dos
modelos construídos em cada fase do desenvolvimento para a fase seguinte, sem que
nenhum detalhe se perca ou se deturpe. Assim, torna-se possível desenvolver sistemas
que retratam uma realidade pretendida, que satisfazem a usuários e a clientes, e que, por
outro lado, ajudam a equipe de desenvolvimento por prover aspectos favoráveis à
manutenibilidade e reusabilidade.
Esta dissertação apresenta um meta-modelo para projetar arquiteturas em
camadas de aplicações baseadas em CORBA (Common Object Request Broker
Architecture). O meta-modelo retrata uma arquitetura com seus componentes,
conectores e possíveis combinações entre eles, projetada em uma linguagem de fácil
entendimento e aprendizagem, a UML (Unified Modeling Language). Ele oferece, ao
usuário (o projetista), facilidades para entender e desenvolver aplicações desta família
de sistemas, pois é um modelo pronto para ser instanciado, resultando na arquitetura
detalhada de aplicações específicas e genéricas, ou refinado, resultando em modelos que
agregam características que os aproxima da implementação e podem ser, igualmente,
instanciados ou refinados.
xi

ABSTRACT
The area of software architecture is playing a fundamental role in the development of
systems. Its initial objective of offers a general view of the system, supporting the
administration of projects, expanded vastly, and the current tendency is that it reduces
the existent gap between the analysis and the implementation, covering all the phases of
the design.
This means, however, that is necessary to approximate or to turn easy the
evolution of the models built in each phase of the design for the following phase,
without any detail getting lost or changed. This way, it is possible to develop systems
that depict an intended reality, that satisfy users and customers, and that, on the other
hand, help the development team, by providing favorable aspects to the manutenability
and reusability.
This dissertation presents a meta-model to project architectures in layers of
applications based on CORBA (Common Object Request Broker Architecture). The
meta-model portrays an architecture with its components, connectors and possible
combinations among them, projected in a language of easy understanding and learning,
UML (Unified Modeling Language). It offers, to the user (the designer), means to
understand and to develop applications of this family of systems, because it is a ready
model to be instanced, resulting in the detailed architecture of specific and generic
applications, or refined, resulting in models that join characteristics that approximates
them of the implementation and they can be, equally, instanced or refined.
xii

1. INTRODUÇÃO
Sistemas de Software estão cada vez mais presentes no cotidiano das pessoas.
Atividades comuns, como fazer um trabalho escolar, corresponder-se com amigos e até
se divertir, ou complexas, como atividades científicas, industriais, comerciais e
militares, são realizadas por meio de software. A nossa dependência e a popularidade da
tecnologia impulsionam a construção de sistemas complexos, heterogêneos, que devem
ser executados em múltiplas plataformas e prover serviços ininterruptos. A demanda por
software que atenda a estes requisitos cresce rapidamente, exigindo que as comunidades
de engenheiros e pesquisadores elaborem técnicas, métodos e ferramentas que ajudem
no desenvolvimento dele.
Grande parte das pesquisas na área de engenharia de software tem enfocado
técnicas que diminuam o gap existente entre o mundo real e o modelo computacional
que o implementa. Muitas destas técnicas se baseiam na criação de modelos e de
linguagens menos ou mais abstratas, tentando oferecer ao projetista uma maneira
gradual de transformar requisitos em software, e assim retratar de maneira fiel uma
realidade pretendida, como mostramos na FIG. 1-1.
Mundo
Real
Engenharia de
Requisitos
Design
Implementação
FIGURA 1-1 - Transformação do conhecimento durante o desenvolvimento de software.
No ciclo de vida do software, as fases de análise, design, implementação e
manutenção são realizadas com a construção de modelos. Após definir os problemas e
levantar soluções conceituais, durante a análise, inicia-se a fase de design, responsável
por mapear os conceitos para soluções computacionais. Tais soluções são, a princípio,
abstratas e devem ser refinadas até um nível passível de implementação. Estando pronto
para ser utilizado (executado), o software deve está apto a ser modificado para
acomodar novos requisitos ou mesmo alterar os existentes. Oferecer modificabilidade
ao software garante um maior tempo útil para ele.
1

A arquitetura de um sistema é um dos primeiros modelos a serem elaborados
durante a fase de design. Ela oferece um maior entendimento da aplicação por dividi-la
em um conjunto de componentes que interagem entre si, para realizar parte de uma, uma
ou várias funcionalidades do sistema [52]. Além disso, a área de arquitetura de software
coloca a disposição métodos que garantem menores custos e tempo no
desenvolvimento. Ela emprega uma abordagem focada em reusabilidade de
componentes ou estilos arquiteturais já existentes, e permite que vários times trabalhem
paralelamente em partes (subsistemas) diferentes do sistema.
Desta forma, a complexidade intrínseca dos sistemas de software atuais pode ser
melhor gerenciada. A divisão de um sistema em subsistemas menores e menos
complexos provê uma maneira de fazer com que o desenvolvedor concentre seus
esforços em partes especializadas em algum serviço, permitindo que eles sejam
completos e validados. Entretanto, projetar a arquitetura de um sistema é uma tarefa
complexa, que envolve conhecimentos do domínio, de tecnologias de design e de
implementação.
Padrões e visões são, comumente, utilizados para alcançar os benefícios
propostos pela arquitetura de software [27]. As visões representam os diferentes
interesses (funcionais, não-funcionais e organizacionais) dos participantes do projeto,
denominados stakeholders. Elas ajudam a gerenciar a complexidade intrínseca aos
sistemas [27]. Os padrões retratam soluções para problemas específicos recorrentes
durante o design ou implementação de um sistema. Vários deles já foram documentados
e disponibilizados, de maneira a popularizar soluções existentes [6][21]. Durante o
design, eles podem ter um nível de generalidade mais alto ou mais baixo, e são
denominados, respectivamente, padrão arquitetural (ou estilos) e padrão de design.
A disponibilização de padrões retrata o reuso da experiência adquirida para
resolução de um problema a um certo nível de generalidade. A utilização de padrões no
desenvolvimento de sistemas requer metodologia e perspicácia. Na FIG. 1-2, vemos que
conduzir o desenvolvimento a partir de um estilo, passando pela arquitetura de um
produto até o design detalhado dele é uma tarefa árdua, pois o gap existente entre estas
tarefas de design é extenso, e garantir a consistência entre eles é difícil. Esta tarefa é
igualmente árdua cada vez que um produto diferente tem que ser desenvolvido.
Na FIG. 1-2 [18], vemos como uma arquitetura de família (ou estilo) é refinada
para a modelagem de um produto específico. Ao instanciar a arquitetura da família
obtém-se a arquitetura de um produto, que por sua vez deve ser refinada para que se
2

alcance um nível mais detalhado de design (design do produto ou arquitetura detalhada
do produto), e assim mais próximo da implementação. Entretanto, é difícil garantir que
após este refinamento a arquitetura detalhada do produto é consistente com a arquitetura
da família daquele produto.
Arquitetura da Família Fácil
Instanciação
Difícil
Arquitetura do Produto
Difícil
Refinamento
Design do Produto
Feito uma vez
Feito várias vezes
FIGURA 1-2 - Primeira abordagem de refinamento.
Outro fator que pode dificultar a garantia da consistência entre estes modelos é a
linguagem ou linguagens utilizadas para representá-los. Diferentes modelos são,
normalmente, construídos por especialistas diferentes, em linguagens de representação
diferentes. Esta atitude tem o benefício de que os modelos são mais adequadamente
modelados. Entretanto, isto compromete a comunicação e interação entre os projetistas,
e gera a atividade extra de ter que traduzir uma linguagem para outra, expondo-se a
cometer outros erros.
Neste trabalho, estamos tratando especificamente da família de aplicações
estruturadas em camadas que utilizam CORBA como plataforma de middleware. Esta
família de sistemas é caracterizada pelo estilo camadas e pelas restrições arquiteturais
impostas por CORBA. CORBA fornece uma solução para a questão de distribuição e
interoperabilidade entre sistemas, estando mais relacionado às características do nível
de implementação. Entretanto, algumas características de implementação devem ser
consideradas em níveis iniciais do design, pois podem influenciar ou afetar as decisões
de mais alto nível [15]. Decisões que, se não consideradas antecipadamente, podem
resultar em implementações que não retratam a arquitetura, e assim, gerar sérios
problemas durante a fase de manutenção do software.
1.1 Objetivos
O presente trabalho apresenta um meta-modelo para o design detalhado de uma família
de sistemas. Esta família representa o conjunto de aplicações estruturadas em camadas e
3

que são distribuídas utilizando o middleware CORBA. Nós adotamos o estilo camadas
porque ele é uma solução globalmente aceita para estruturar um sistema de software
[27][29][52] e CORBA por ser um padrão para interoperabilidade d sistemas
distribuídos.
O meta-modelo retrata uma arquitetura com seus componentes, conectores e
possíveis combinações entre eles, projetada em uma linguagem de fácil entendimento e
aprendizagem, a UML (Unified Modeling Language). Ele objetiva facilitar o design de
arquiteturas de software, por resolver ou esclarecer todas as restrições impostas por um
ou mais estilos e aproximar o design da arquitetura a fases mais detalhadas do design.
Com o meta-modelo, queremos que o tempo e os custos de desenvolver uma aplicação
distribuída sejam reduzidos por não haver o (re) trabalho de se identificar e descrever
cada um dos fatores definidos nele.
A documentação do meta-modelo consiste de um conjunto de artefatos, que
juntos oferecem todo o entendimento necessário para elaborar a arquitetura de um
sistema desta família. Os artefatos são os seguintes: descrição estática através do
diagrama de classes da UML; especificação formal desta estrutura estática na linguagem
de especificação Z; e descrição dinâmica através dos diagramas de seqüência e de
estados. Para exemplificar como e quando utilizar o meta-modelo, nós realizamos um
estudo de caso e mostramos as facilidades oferecidas pelo meta-modelo proposto.
A dissertação e os artefatos construídos fornecem subsídios para criação de uma
ferramenta apta a permitir a construção e validação de arquiteturas baseadas em estilos,
e especificamente no estilo camadas e CORBA. Veja, a seguir, a estrutura e organização
desta dissertação.
1.2 Estrutura da Dissertação
Esta dissertação está estruturada e organizada da seguinte maneira:
Capítulo 2: Estado da Arte – Neste capítulo apresentamos as principais tecnologias que
estão envolvidas na elaboração da dissertação. São elas: Arquitetura de Software;
CORBA e; as Linguagens, UML e Z, que foram utilizadas para documentar o metamodelo.
Expomos os conceitos fundamentais peculiares a cada uma delas e como estes
nos ajudaram a atingir os objetivos propostos.
4

Capítulo 3: Um Meta-modelo para Modelar uma Família de Aplicações Distribuídas –
Neste capítulo apresentamos a metodologia utilizada para elaborar o meta-modelo e os
vários artefatos construídos durante o desenvolvimento dele e destacamos a sua
flexibilidade e utilidade.
Capítulo 4: Estudo de Caso – Neste capítulo apresentamos um estudo de caso para
demonstrar como utilizar o meta-modelo no desenvolvimento de aplicações práticas.
Capítulo 5: Trabalhos Correlatos – Neste capítulo apresentamos alguns trabalhos que
possuem os mesmos objetivos ou influenciam esta dissertação, e as diferenças entre
eles.
Capítulo 6: Conclusões e Trabalhos Futuros – Neste capítulo apresentamos nossas
conclusões, os resultados que obtivemos com o a construção do meta-modelo e os
futuros trabalhos que podem ser desenvolvidos a partir deste trabalho de dissertação.
5

2. ESTADO DA ARTE
Este trabalho de dissertação foi influenciado por trabalhos em várias áreas: arquitetura
de software e seus estilos e visões; reuso de software; sistemas distribuídos com
middleware CORBA; padrões de design; e modelagem e especificação de software. O
foco de nossa dissertação está em arquitetura de software. Elaborar meta-modelos como
o que estamos propondo ajuda o arquiteto a desempenhar suas atividades de design e de
gerenciamento.
Neste capítulo, apresentamos o embasamento teórico que fundamenta este
trabalho de dissertação. Os conceitos e as características relevantes de cada uma das
tecnologias envolvidas são apresentados. Mostramos como estas tecnologias
influenciam e/ou colaboram para elaboração do meta-modelo que estamos propondo.
2.1 Arquitetura de Software
A arquitetura de software retrata uma solução computacional de alto nível através de
componentes computacionais. Ela surgiu para diminuir o gap existente entre a análise e
o design por representar, através destes componentes, todos os requisitos funcionais e
não-funcionais descobertos durante a análise [52]. Os requisitos funcionais são aqueles
relacionados à funcionalidade do sistema e os requisitos não funcionais são requisitos
associados aos atributos de qualidade do sistema, tais como, usabilidade, segurança,
reusabilidade, flexibilidade etc.
A arquitetura de software é responsável por mapear o modelo conceitual do
mundo real para um modelo computacional, passível de ser refinado e implementado
em fases posteriores. O modelo do mundo real é o modelo do domínio, ele representa
um problema a ser resolvido computacionalmente. Nesta dissertação, utilizamos o
termo mundo real para denotar todas as necessidades e elementos do domínio a serem
implementados por um software. O modelo computacional é o modelo dos elementos e
solução implementada para o problema proposto. Com a arquitetura, o mundo real pode
ser representado de maneira mais fiel, dando origem a sistemas mais reais.
Atualmente, a área de arquitetura de software engloba mais que um modelo de
alto nível. Pesquisas mais recentes têm colocado a arquitetura de software como meio
de chegar à implementação, dando suporte a todas as fases de design existentes entre a
6

análise e a implementação [12][27]. Desta forma, a arquitetura deixa de ser somente um
modelo inicial abstrato e passa a representar modelos genéricos que retratam este
modelo inicial em níveis mais baixos, em termos de subsistemas. Ela passa a ser um
modelo com vários níveis de abstração, se for visto sob a visão do sistema completo. O
nível mais alto denominado arquitetura de software e os níveis subseqüentes até um
nível muito baixo que possa ser diretamente implementado, denominado de arquitetura
detalhada. Nós utilizaremos esta terminologia para designar estes diferentes níveis de
arquitetura.
A arquitetura de um sistema computacional é uma estrutura ou conjunto de
estruturas que incluem componentes de software, suas propriedades, externamente
visíveis, e os relacionamentos entre estes componentes [52].
• Componentes são entidades computacionais ou de armazenamento de dados. Em
uma arquitetura eles podem ser tão pequenos quanto um simples procedimento
ou tão grandes como uma aplicação inteira [35]. Alguns exemplos são: módulos,
subsistemas, sistemas, objetos, processos, bibliotecas, bancos de dados etc. Eles
interagem através de pontos de interação denominados, portas. As portas são
elementos dissociados dos componentes que as possuem.
• Relacionamentos são representados pelos conectores. Os conectores são
entidades usadas para modelar as interações entre componentes e as regras que
governam estas interações. Eles podem ser implementados como dispositivos
compiláveis separadamente dos componentes, mas também podem se manifestar
como variáveis compartilhadas, buffers, estrutura de dados dinâmica, seqüência
de chamadas de procedimento, protocolos cliente-servidor, pipes etc [35]. Eles
interagem através de pontos de interação denominados de papéis. Os papéis,
assim como as portas, são elementos dissociados dos conectores que os
possuem.
• Propriedades são informações que indicam o comportamento (a semântica) dos
componentes, e como eles estão aptos a interagir com o mundo externo.
A arquitetura é um modelo de alto nível de generalidade que fornece, através de
seus componentes e interconexões, um melhor entendimento das partes que constituirão
o software, de como elas se relacionam entre si e de como estão organizadas,
fornecendo a estrutura global do sistema e de seus subsistemas constituintes. Isto
possibilita ao projetista: gerenciar a complexidade do sistema; gerenciar o projeto do
7

sistema; tomar certas decisões de design e implementação, antecipadamente; e prevenir
e/ou remediar problemas que podem acontecer durante o design, implementação e
manutenção. Para tanto, o arquiteto deve ter um conhecimento geral sobre: as diversas
fases de design; as tecnologias que podem ser utilizadas em cada uma das fases; o
contexto no qual o sistema está inserido; a Organização (Empresa ou Companhia) e seus
interesses; e maneiras de liderar e gerenciar a equipe de desenvolvimento [7][27].
Normalmente, arquiteturas são documentos informais, representados através de
diagramas de caixas-e-linhas e textos explicativos. Porém, estes diagramas não possuem
a semântica nem a sintaxe bem definidas, como por exemplo a arquitetura na FIG. 2-1.
Para dar suporte à descrição, análise e testes de arquiteturas, surgiram nos últimos anos
várias linguagens especificamente para estes propósitos, denominadas ADLs
(Architecture Description Language). As ADLs são linguagens usualmente formais que
tiveram origem nos anos 70 com as linguagens de interconexão de módulos (MIL) [1].
Como exemplos, temos: Rapide [31], Unicom [51], ZCL [45], C2 [36], Darwin [33],
Wright [1] etc. Muitas delas têm ferramentas que dão suporte a análise de vários
aspectos arquiteturais e, assim, ajudam o arquiteto a realizar suas tarefas.
P1
P5
A
B
C
P2 P3 P4
D
FIGURA 2-1 - Diagrama de caixas e linhas representando uma arquitetura.
Por outro lado, existem as linguagens de modelagem de objetos que têm tido
sucesso na representação tanto de implementações quanto de domínios, provendo uma
maneira natural de transformar esta modelagem em implementação, dentre elas, a UML.
Mas, discute-se se estas linguagens são adequadas para descrição arquitetural [25][37].
Na Seção 2.2, apresentamos a UML e mostramos como ela se adequa aos propósitos da
arquitetura de software.
A arquitetura de software fornece uma abstração que permite a reusabilidade de
componentes com alto ou com baixo nível de generalidade, provendo o reuso de
estruturas inteiras. Estruturas que podem estar relacionadas a um domínio, a uma
família de produtos ou a semântica de componentes e conectores coexistentes em uma
8

arquitetura [6][21]. Na Seção 2.1.1, nós detalhamos estas estruturas. Além disto, uma
arquitetura pode ser analisada sob diferentes perspectivas, ou visões [2][27]. Na Seção
2.1.2, nós apresentamos uma abordagem sobre visões arquiteturais.
2.1.1 Estilos ou Padrões Arquiteturais
Como definido por Christopher Alexander em [6] e [11] “Cada padrão decreve um
problema que ocorre repetidamente outras vezes em nosso ambiente, e então descreve o
núcleo da solução para aquele problema, de maneira que se possa reutilizar esta
solução um milhão de vezes depois, sem o esforço inicial”.
Os padrões são bastante utilizados em todas as fases da engenharia de software.
Inicialmente, nos anos 60 a 80 as pesquisas estavam focadas no nível de implementação
e padrões de programação foram largamente estudados e definidos [52]. Agora que o
nível de implementação é um nível bem entendido o foco passou a ser estruturas mais
abstratas. O conceito de padrões pode ser, novamente, aplicado de maneira a prover
maiores facilidades nesta fase mais abstrata.
Com a construção de arquiteturas e a experiência adquirida nesta atividade,
padrões arquiteturais foram identificados e empregados em diversos sistemas e
domínios [22][27]. Um padrão arquitetural ou estilo define uma família de sistemas em
termos de sua organização estrutural [6][22]. Ele define o vocabulário de componentes e
conectores que podem ser usados em instâncias daquele estilo, juntamente com um
conjunto de restrições de como eles podem ser combinados.
O uso de estilos proporciona diversas vantagens para a fase de design tais como,
documenta a experiência de projetos de arquiteturas já provadas, provê vocabulário e
entendimento comum, ajuda a construir arquiteturas de software complexas e
heterogêneas, provê um esqueleto de comportamento funcional e ajuda a gerenciar a
complexidade de sistemas [6]. Eles estão sendo largamente utilizados, puros ou híbridos
[52]. Estilos arquiteturais puros são os próprios estilos em sua forma primária.
Arquiteturas híbridas ou heterogêneas são aquelas que integram vários estilos para
descrição do sistema. A maioria dos sistemas é descrita por uma arquitetura
heterogênea.
O uso de estilos depende exclusivamente das características (requisitos de
qualidade) que o sistema ou subsistema deverá apresentar (SHAW, GARLAN, e
BUSCHMANN in [5]) [30]. Não se deve, em hipótese alguma, escolher um estilo e
9

adaptar o sistema a este estilo, pois desta forma, o modelo obtido não retrata a realidade
pretendida. Os exemplos de estilos mais conhecidos são: Pipe and Filters, Camadas,
Cliente-Servidor, Repositórios, Eventos dentre outros.
Há duas outras categorias de padrões no contexto da arquitetura [27]:
• Arquitetura de referência ou Arquitetura de software de domínio específico –
são estilos que se aplicam a domínios de aplicação específicos. Eles definem
como a funcionalidade do domínio é mapeada para os elementos da arquitetura.
• Arquitetura de linha de produto - são estilos que se aplicam a um conjunto de
produtos de uma organização ou companhia.
Estas categorias de padrões não são mutuamente exclusivos. Uma arquitetura de
referência, uma arquitetura de linha de produto e uma arquitetura de software podem
utilizar um estilo arquitetural em seu projeto. Similarmente, uma arquitetura de linha de
produto ou uma arquitetura de software podem ser baseadas em uma arquitetura de
referência. E uma arquitetura de software pode ser parte de uma linha de produto
usando a arquitetura de linha de produto para o seu design. Na TAB. 2-1, apresentamos
um resumo das características de cada um destes termos, definidos em [27].
Termo
Estilo ou padrão arquitetural
(geralmente não está relacionada a
um domínio específico)
Arquitetura de referência ou
arquitetura de domínio específico
(aplicada a um domínio particular)
Arquitetura de linha de produto
(aplicada a um conjunto de produtos
em uma organização)
Arquitetura de software (aplicada a
um sistema ou produto)
TABELA 2-1
Comparação de termos de arquitetura de software.
Define tipos de
elementos e
como eles
interagem
Define um
mapeamento de
funcionalidade
para elementos
da arquitetura
Define
instâncias de
elementos de
arquitetura
Sim Algumas vezes Não
Sim Sim Não
Sim Sim Algumas vezes
Sim Sim Sim
10

Assim, um padrão pode ser instanciado, resultando em um outro padrão. Em
[23], Garlan define uma abordagem de refinamento baseada em estilos. Nesta
abordagem, usa-se a idéia de sub-estilo e tenta-se identificar se um sistema projetado
baseado num estilo X poderia ser projetado baseado em outro estilo Y. A idéia de subestilos
(super-estilos) é a mesma utilizada na orientação a objetos para sub-classe
(super-classe). Um sub-estilo é um estilo mais refinado que o estilo a partir do qual ele
foi criado. Muitos dos sub-estilos podem ser entendidos como restrições adicionais na
sintaxe de um estilo mais geral [23]. Eles provêem o reuso de descrições arquiteturais
existentes e uma organização de estilos que podem guiar o arquiteto na seleção de um
paradigma apropriado para um domínio de aplicação particular [15][16].
Outros termos que permeiam a arquitetura de software são: padrão de design e
arquitetura de família. Um padrão de design pode ou não ser relevante para a arquitetura
de software. Quando ele descreve as interações entre elementos arquiteturais, considerase
que ele é parte da arquitetura de software. Quando ele descreve a estrutura e as
interações dentro dos elementos arquiteturais, ele é parte do design detalhado. A
arquitetura de família é um termo utilizado para denotar uma arquitetura que representa
um conjunto de sistemas que possuem algumas similaridades. Ela pode se referir a um
estilo, arquitetura de referência ou arquitetura de linha de produto.
A disponibilização de padrões em geral retrata o reuso da experiência adquirida
para resolução de um problema a um certo nível de generalidade. Entretanto, utilizar
padrões no desenvolvimento de sistemas requer, em geral, metodologia e perspicácia.
Para desenvolver um sistema a partir de um estilo é necessário, primeiramente,
instanciar este estilo para elaborar a arquitetura do produto que se deseja desenvolver,
veja na FIG 2-2a [18]. E depois, detalhar esta arquitetura para a obtenção de um modelo
passível de ser implementado (arquitetura detalhada).
A arquitetura detalhada reflete as características da arquitetura do produto mas
também retrata as características intrínsecas das tecnologias de implementação
escolhidas para a codificação. Estas características podem influenciar ou afetar as
decisões tomadas durante o design da arquitetura. Elas são características referentes à
estrutura e ao comportamento dos componentes de mais alto nível, podendo resultar em
implementações que não retratam a arquitetura. Assim, é difícil manter a consistência
entre estas arquiteturas. E é igualmente difícil cada vez que um produto diferente tem
que ser desenvolvido, veja na FIG. 2-2a.
11

a)
Estilo
Fácil
Instanciação
Difícil
Arquitetura do Produto
Difícil
Refinamento
Estilo
Refinamento
Difícil
b)
Fácil
Instanciação
Médio
Design Detalhado
do Produto
Arquitetura do Produto
Difícil
Refinamento
Design Detalhado
do Estilo
Fácil
Instanciação
Design Detalhado
do Produto
Feito uma vez
Feito várias vezes
FIGURA 2-2 - Duas abordagens de refinamento.
Conduzir o desenvolvimento a partir de um estilo, passando pela arquitetura de
um produto até o design detalhado dele é uma tarefa árdua. Egyed et al. [18] propõe
uma solução para este problema. A solução consiste em detalhar a arquitetura do estilo
(veja na FIG. 2-2b). Esta tarefa é igualmente árdua, porém os artefatos desta arquitetura
detalhada tornam o design detalhado do produto uma tarefa amena. Assim, o design
detalhado do estilo pode ser reutilizado inúmeras vezes durante o desenvolvimento de
produtos diferentes, garantindo mais facilidade no desenvolvimento destes produtos e
maior consistência entre o estilo e a arquitetura detalhada de um produto baseada neste.
Nós adotamos esta solução. Nesta dissertação, definimos a arquitetura e o design
de uma família de sistemas através de um meta-modelo. A família de sistemas é
caracterizada pelas propriedades definidas pelo estilo camadas e pelo middleware
CORBA. O estilo camadas favorece a reusabilidade de componentes especializados em
fornecer algum tipo de serviço como por exemplo, serviços de comunicação entre
sistemas, segurança, aplicações específicas etc. A seguir, na Seção 2.1.1.1, maiores
detalhes do estilo camadas são apresentados.
2.1.1.1 Estilo Camadas
O estilo camadas organiza o software em camadas hierárquicas. Cada camada é
construída em cima de uma outra mais geral [29]. Uma camada pode ser, livremente,
definida como um conjunto de (sub)sistemas com o mesmo grau de generalidade.
12

Camadas mais altas são específicas da aplicação, camadas mais baixas são de propósitos
gerais, ou seja, utilizadas por diferentes aplicações.
Tradicionalmente, as interações ocorrem somente entre camadas adjacentes.
Cada camada provê serviços para a camada de cima e funciona como cliente para a
camada de baixo. Os sistemas constituintes de cada camada podem ser, também,
estruturados em outras camadas ou seguir algum outro estilo arquitetural existente, puro
ou heterogêneo. Esta decisão dependerá da complexidade e características globais de
cada uma das camadas [52].
Um exemplo clássico deste estilo é o padrão OSI da ISO para redes de
computadores, onde cada camada é responsável por um aspecto específico da
comunicação entre computadores, dos detalhes de transmissão de bits (sinais elétricos)
pelo meio físico até o alto nível lógico da aplicação.
O estilo camadas agrega aos sistemas várias propriedades desejáveis [52]:
• Oferece suporte ao design baseado em níveis crescentes de abstração - isto
permite implementadores dividirem um problema complexo em uma seqüência
de passos incrementais;
• Oferece suporte a mudanças - pois cada camada interage somente com suas
camadas adjacentes, então mudanças em uma camada afetam no máximo duas
outras camadas;
• Oferece suporte ao reuso - diferentes implementações de uma mesma camada
podem ser usadas, desde que elas possuam as mesmas interfaces para as
camadas adjacentes;
• A segurança pode ser suportada por camadas específicas para este serviço.
Porém, sistemas em camadas também possuem algumas desvantagens [52]:
• Nem todos os sistemas são facilmente estruturados em camadas;
• Para os sistemas que podem ser estruturados em camadas a questão de
desempenho é delicada, pois há um certo tempo e processamento desperdiçado
na comunicação entre camadas;
• Falhas em uma camada podem tornar o sistema indisponível, já que cada
camada funciona como intermediária para comunicação de duas outras camadas.
13

Um exemplo de arquitetura para aplicações de software é a arquitetura de quatro
camadas apresentada por Jacobson et al. [29], mostrada na FIG. 2-3. O número de
camadas, o nome e o conteúdo delas não é fixo, e variam de situação para situação, são
elas:
• Sistemas de aplicação (ou simplesmente aplicação) - Cada aplicação oferece um
conjunto coerente de casos de uso para algum usuário final. Aplicações podem
interoperar diretamente com outras através de suas interfaces ou, também,
interoperar indiretamente através de algum serviço ou objeto provido por um
sistema em alguma das camadas mais baixas, tais como um Object Request
Broker (ORB), sistema operacional, ou serviços específicos do negócio.
• Sistemas Específicos do Negócio - Contém um número de sistemas de
componentes específicos para o tipo de negócio. Tais sistemas de componentes
oferecem casos de uso e componentes objetos para os desenvolvedores
construírem aplicações e são, freqüentemente, reusáveis pelas aplicações
desenvolvidas por um domínio de reuso particular.
• Middleware - Oferece sistemas de componentes que provêm classes de utilidade
e serviços independentes da plataforma tais como computação de objeto
distribuído em ambientes heterogêneos. Esta camada contém sistemas de
componentes para construtores GUI (Graphical User Interface), interfaces para
sistemas gerenciadores de banco de dados, serviços do sistema operacional
independente de plataforma, ORBs e componentes OLE.
• Software do Sistema - Específico da plataforma, contém o software para a
infraestrutura atual tal como sistema operacional, interfaces para hardware
específico e assim por diante.
Sistemas de aplicação
Sistemas específicos do negócio
Middleware
Software do sistema
FIGURA 2-3 - Uma arquitetura em camadas para aplicações de negócio.
14

Estas camadas são estruturais e representam um sistema, completamente, sob um
ponto de vista de alta granularidade, devendo assim ser refinadas até um nível de
abstração onde sejam, apropriadamente, implementadas em uma linguagem de
programação. Componentes podem ter níveis de granularidade diferentes tais como
pequeno, médio e grande. Os pequenos são, em geral, mais fáceis de desenvolver e mais
difíceis de compor. Eles são similares às classes de objeto e são, normalmente, de
propósito geral. Componentes médios e grandes são mais difíceis de desenvolver porém
a composição deles é mais fácil do que a de componentes pequenos. Estes são
geralmente de propósito específico a um domínio. Componentes maiores são
constituídos de componentes menores [19].
Outro exemplo do uso deste estilo é a Arquitetura de Gerenciamento de Objetos
(OMA) definida pelo OMG (Object Manegement Group) para integrar aplicações
distribuídas. Esta arquitetura fornece o grau de transparência desejado para construir
sistemas distribuídos sem se preocupar com problemas complexos tais como a
distribuição e heterogeneidade de plataformas [8][41][42]. Na Seção 2.3 apresentamos
maiores detalhes desta arquitetura.
Na literatura, algumas variantes do estilo camadas são comumente encontradas,
como por exemplo [6]:
• Relaxed Layered System que é menos restritivo sobre a relação entre camadas.
Cada camada pode interagir com outras camadas que não estão adjacentes a ela,
imediatamente abaixo ou acima. Uma camada pode também ser parcialmente
opaca, isto significa que alguns serviços só são visíveis para a camada
imediatamente superior, mas outros são visíveis para qualquer camada.
• Layering Through Inheritance, onde camadas mais baixas são implementadas
como classes básicas. As camadas de nível mais alto requisitam serviços das
camadas mais baixas por herdar a implementação destas camadas.
Conseqüentemente, elas podem requisitar serviços das classes básicas. Uma
vantagem deste esquema é que as camadas mais altas podem modificar os
serviços das classes básicas de acordo com suas necessidades. Por outro lado, a
relação de herança conduz a uma ligação muito forte entre camadas de nível
baixo e nível alto.
• Outras variantes podem ser obtidas por modificar o tipo das camadas – que pode
ser black, white ou gray, o tipo de comunicação – push, pull e callback, o modo
de comunicação – síncrono, assíncrono, sícrono deferido, ou o sentido da
15

comunicação entre elas – top-down e bottom-up entre camadas adjacentes ou
não-adjacentes.
2.1.2 Visões
Como definido por IEEE Draft Standard 1471, uma visão endereça um ou mais
interesses de um stakeholder (desenvolvedor, usuário, cliente, etc) do sistema [17].
Genericamente estes interesses são funcionais, não-funcionais e organizacionais. Assim,
uma visão pode fornecer informações sobre os requisitos, a organização, as pessoas, a
tecnologia, o histórico de mudanças, a estrutura do produto, suas transições etc.,
utilizando-se de alguma linguagem para descrever seus aspectos de interesse, seja esta
uma linguagem natural, gráfica ou formal.
No livro intitulado Applied Software Architecture [27] são definidas quatro
visões arquiteturais. Este livro é fruto da experiência de seus autores na área de
arquitetura de software, e constitui um guia detalhado e prático para as tarefas de
arquitetura de software. Seus autores tendo como ponto de partida os aspectos
necessários para a criação da arquitetura de um sistema, criaram quatro meta-modelos
retratando estas características, ou visões arquiteturais. Cada uma delas pode ser
utilizada separadamente e endereça diferentes interesses da arquitetura. São elas:
Visão conceitual – Descreve o sistema em termos de seus elementos de design e as
relações entre eles (configuração). Nesta visão, a funcionalidade do sistema é mapeada
para os elementos da arquitetura chamados componentes, com a coordenação e troca de
dados mapeada por elementos chamados conectores. Os componentes e os conectores
possuem pontos de interação denominados portas e papéis, respectivamente. Cada porta
e papel está associado a um protocolo que define como as operações de entrada e saída
são ordenadas.
A Visão Conceitual é a visão relevante para este trabalho de dissertação. A partir
dela nós definimos o meta-modelo proposto por esta dissertação. Detalhes desta visão e
da relação dela com o meta-modelo são apresentados na Seção 3.3.
Visão de módulo – Nesta visão, os componentes e conectores da visão conceitual são
mapeados para subsistemas e módulos, e estes organizados em camadas. O foco desta
16

visão é como a solução conceitual pode ser realizada pelas tecnologias e plataformas de
software atuais.
Os subsistemas correspondem aos componentes conceituais de mais alto nível.
São componentes que podem ser decompostos em outros componentes e conectores, ele
pode conter outros subsistemas ou módulos. Um módulo pode corresponder a um único
elemento conceitual (componente, porta, conector, ou papel) ou a um conjunto deles,
eles podem ser decompostos em outros módulos, mas neste caso o módulo pai é um
container.
Os módulos encapsulam dados e operações para prover/requerer um serviço, que
é definido pela interface que o módulo provê/requer. Camadas organizam os módulos
em uma hierarquia e também provêem/requerem interfaces.
Visão de execução – Descreve como módulos são mapeados para os elementos providos
pela plataforma de execução, e como estes são mapeadas para a arquitetura de
hardware. A visão de execução define as entidades de tempo de execução e seus
atributos.
É necessário realizar uma análise das plataformas de hardware e software que
serão utilizadas. Para a plataforma de hardware é necessário listar os componentes de
hardware utilizados no sistema e a topologia e interconexão destes componentes. Para a
plataforma de software é necessário conhecer a infraestrutura de software que está entre
o produto e a plataforma de hardware, geralmente o Sistema Operacional. Então,
mapeia-se os componentes conceituais e módulos para estes elementos da plataforma,
geralmente módulos são assinados para entidades de execução, e a maneira que eles se
comunicam.
Visão de código – Determina a organização do código fonte dentro de código objeto,
bibliotecas e binários por mapear os elementos das visões de Módulo e de Execução
para componentes de código e organizá-los. Tal mapeamento pode variar com a
linguagem de programação utilizada. O objetivo principal desta visão é facilitar a
construção, integração, instalação e teste do sistema, respeitando a integridade das
outras três visões.
17

Estas quatro visões representam o mínimo a considerar quando se deseja projetar
a arquitetura de um sistema de software. Em [27], encontramos, também, um processo
para o desenvolvimento de arquiteturas utilizando estes meta-modelos.
Outras visões normalmente consideradas durante todo o design são as visões
estática e dinâmica. A visão estática, fornece os elementos da arquitetura e como eles
estão relacionados. A visão dinâmica, oferece como estes elementos interagem entre si e
como funcionam.
A notação utilizada para especificar estas visões foi a notação definida pela
UML. Embora a UML seja mais utilizada para descrever aspectos do nível mais
detalhado do design, ela dá suporte à descrição da maioria dos conceitos que se desejava
nesta abordagem, e a vantagem de usar uma notação padronizada e bem entendida se
sobrepôs à desvantagem dela não dar suporte a alguns dos conceitos arquiteturais. Na
Seção 2.2, nós apresentaremos um pouco desta linguagem e as vantagens que ela pode
trazer para o design de arquiteturas de software.
2.2 Linguagens Utilizadas
As linguagens de representação desempenham um papel fundamental durante o
desenvolvimento de um sistema de software. Elas são responsáveis por transmitir todos
os detalhes do design para os diversos stakeholders de maneira amigável, clara e nãoambígua.
Além de documentar todo o design para futuras manutenções.
Entretanto, uma única linguagem dificilmente apresenta todas estas
características numa intensidade satisfatória para todos os stakeholders. Há diferentes
interesses nas diversas fases do design e os desenvolvedores de cada fase estão mais
habituados a certas linguagens estando menos receptivos a outras.
Com o intuito de oferecer maior representatividade e comunicabilidade ao metamodelo
que estamos propondo, nós utilizamos a UML. A UML pode ser utilizada nas
diversas fases do design e é um bom meio de comunicação entre os projetistas, tanto por
ser muito difundida quanto por ser facilmente entendida e aprendida.
No entanto, reconhecemos o valor do formalismo para especificar a arquitetura
de um sistema específico ou, no nosso caso, de estilos arquiteturais. Formalizar um
estilo arquitetural tem, no mínimo, dois propósitos: tornar preciso os vocabulários,
padrões e arquiteturas de referência agora usados informalmente por projetistas; e para
18

elucidar uma parte do espaço arquitetural por mostrar como diferentes arquiteturas
podem ser tratadas como especializações de uma abstração comum [52].
A seguir, apresentamos as linguagens utilizadas neste trabalho de dissertação. A
linguagem de modelagem UML, na Seção 2.2.1, e a linguagem de especificação formal
Z, na Seção 2.2.2.
2.2.1 UML
A UML (Unified Modeling Language) surgiu por volta de 1995 com o intuito de
padronizar uma linguagem para modelagem de sistemas. Ela se estende a qualquer tipo
de sistema e se propõe a dar suporte a todo o processo de desenvolvimento de software
[4].
A UML é composta por um conjunto de nove diagramas com sintaxe e
semântica bem definidas. São eles: Diagrama de casos de uso, de classes, de objetos, de
seqüência, de colaboração, de estados, de atividades, de implantação e de componentes.
Cada um deles retrata aspectos diferentes do sistema. Conjuntamente eles retratam os
diferentes aspectos (visões) do sistema. Uma descrição detalhada da UML pode ser
encontrada em [20][46].
A UML vem sendo largamente utilizada pelas diversas subáreas da engenharia
de software devido a sua expressividade e flexibilidade. Pesquisadores da área de
arquitetura de software têm mostrado grande interesse em integrar a UML às técnicas e
linguagens existentes para descrição de arquiteturas [34][48][49]. Ela, também vem
sendo analisada para verificar se ela atende aos requisitos arquiteturais e como ela pode
ser utilizada para tal propósito [9][25][37].
Entretanto, uma arquitetura apresenta um conjunto de características que devem
ser modeladas por linguagens de descrição adequadas, as ADLs, apresentada na Seção
2.1 [10][37]. A UML representa boa parte destas características embora não seja uma
ADL [34][53]. No ANEXO A, apresentamos uma análise comparativa entre UML e as
ADLs.
Um dos aspectos importantes não satisfeito pela UML é quanto à descrição de
estilos. Este aspecto é endereçado, apenas, parcialmente pela UML. A UML não possui
estilos pré-definidos, e nem mesmo o conceito de estilos. Entretanto, devido a sua
flexibilidade, a UML é capaz de descrever qualquer tipo de sistema a qualquer nível de
19

abstração, englobando tanto seus aspectos estáticos quanto dinâmicos. Assim, é possível
representar meta-modelos e a partir destes, estilos [53].
Estes meta-modelos podem ser instanciados para arquiteturas específicas,
obtendo-se arquiteturas descritas em nível de projeto seguindo algum padrão
arquitetural específico. A representação de estilos em UML pode proporcionar maior
consistência entre arquiteturas de software e modelos de design, além de oferecer
melhor comunicação entre arquitetos e projetistas.
Para que esta prática traga os benefícios almejados é necessário que os estilos
sejam modelados de maneira bastante fiel, sem que se perca nenhuma das propriedades
definidas por eles. A descrição de restrições é um ponto muito importante para os
estilos. As restrições devem ser descritas de maneira precisa, sendo necessário utilizar
linguagens semi-formais ou formais, já que o suporte à descrição destas restrições dado
pela UML é somente através de “Notas” (elemento definido pela UML).
2.2.1.1 Terminologia
Embora utilize uma notação e terminologia idêntica a utilizada pelo paradigma de
orientação a objetos, a UML é uma linguagem cujo propósito é modelar qualquer tipo
de sistema, em qualquer nível de abstração. Neste caso, um diagrama de classes pode
representar elementos: de alta abstração, onde seus atributos e métodos representam, de
maneira geral, as suas características e funcionalidades; ou de baixa abstração, prontos
para serem traduzidos em linguagens de programação e então, serem executados. Não
há uma concordância em como representar arquiteturas através da UML. Em [25] são
apresentadas várias abordagens.
Para retratar um sistema, a UML também utiliza visões. Cada um de seus
diagramas, é considerado uma visão [17], já que representam aspectos e interesses
diferentes. E há também, a visão estática e a visão dinâmica. A primeira representada
pelos diagramas de casos de uso e de classes, e a segunda pelos outros diagramas.
Na UML, o termo componente é utilizado, porém possui uma conotação
diferente da empregada pela arquitetura de software. Para a UML um componente é um
elemento de código podendo ser uma biblioteca, um executável, um banco de dados etc,
ou seja, pode ser o código de um único objeto ou de um agrupamento deles. Enquanto
que, como definimos na Seção 2.1, para a arquitetura de software um componente é um
20

elemento computacional abstrato, pode até ser um objeto, mas não um código de
software.
2.2.2 Linguagem de Especificação Z
A linguagem Z é uma linguagem formal baseada na teoria dos conjuntos [58]. Z
adiciona a noção básica de teoria dos conjuntos a idéia de que os objetos em seu
universo podem ser classificados em diferentes tipos, e que não há sobreposição entre
tipos distintos.
Outra característica de Z é uma estrutura, conhecida como esquema. Os
esquemas nos permitem agrupar descrições de objetos dentro de unidades nomeadas que
podem ser referenciadas em todas as partes da especificação [58][59]. Nós utilizamos a
linguagem Z para especificar os elementos arquiteturais definidos no meta-modelo,
destacando as restrições que foram pobremente modeladas ou não modeladas pela
UML.
A escolha desta linguagem em lugar de uma ADL ou da OCL (Object
Constraints Language) [47], que possui maior integração com a UML, deve-se às suas
características intrínsecas que nos permite atingir o nosso propósito que é especificar
livremente os elementos arquiteturais através dos seus atributos e restrições. Para
oferecer suporte a utilização da linguagem Z, nós utilizamos a ferramenta Z-Eves [43]
versão 2.1. Z-Eves permitiu-nos realizar uma verificação de tipos da especificação.
Para utilizar uma ADL nós precisaríamos fazer um estudo rigoroso de quais
ADLs dão suporte à descrição de estilos sem impor um modelo arquitetural diferente do
definido pela visão conceitual apresentado na Seção 2.1.2. A OCL, por sua vez, é uma
linguagem estereotipada que serviria ao nosso propósito, mas ela não possui as
ferramentas de análise que Z possui.
2.2.3 Utilizando UML e Z
Nesta dissertação, utilizamos o diagrama de classes da UML para descrever e retratar a
estrutura estática do meta-modelo, objeto de nosso estudo. Os elementos arquiteturais
definidos em UML foram também definidos em Z. A especificação em Z acrescenta
algumas restrições vitais que não podem ou são pobremente definidas em UML. Os
21

diagramas de seqüências e estados da UML foram utilizados para descrever a estrutura
dinâmica deste meta-modelo.
A utilização destas duas linguagens objetiva oferecer ao meta-modelo, tanto
facilidade de entendimento e aprendizagem quanto suporte formal, favorecendo e
facilitando a divulgação do próprio meta-modelo e futuramente a criação de ferramentas
que automatizem e integrem estas especificações.
2.3 CORBA
CORBA (Common Object Request Broker Architeture) é uma plataforma de
middleware que tem a função de realizar a comunicação entre aplicações que são
executadas em um ambiente distribuído e heterogêneo [41][42]. CORBA despontou
como padrão e está sendo muito utilizado, uma vez que a necessidade de se ter uma
tecnologia de objetos distribuídos para construção de aplicações baseadas no modelo
cliente/servidor se tornou uma realidade nos dias atuais. No mercado, já podem ser
encontradas algumas implementações do padrão CORBA, sendo as mais conhecidas
VisiBroker [57], OrbixWeb [28] e ORBacus [40].
CORBA foi escolhido como plataforma nesse trabalho porque apresenta a
vantagem de possibilitar o desenvolvimento de aplicações cujos componentes são
escritos em diversas linguagens de programação e por ser um padrão independente de
plataformas de software. O fato de CORBA ser um padrão aberto faz dele um modelo
dominante, uma vez que esta característica facilita a obtenção de um maior grau de
flexibilidade e escalabilidade, que são requisitos fundamentais para sistemas
distribuídos [32].
Na Seção 2.3.1, apresentamos alguns termos e conceitos utilizados no contexto
de CORBA e da arquitetura de software que, algumas vezes, assumem significados
diferentes. Nas seções 2.3.3 e 2.3.4, nós detalhamos CORBA levando em consideração
as características relevantes para esta dissertação.
2.3.1 Considerações Iniciais
CORBA é, geralmente, referenciado como um padrão e não como uma arquitetura, pois
ele apresenta um esquema de distribuição genérico, que serve como base para a
22

construção de muitas configurações específicas [12]. Como apresentamos na Seção
2.1.1, TAB. 2-1, uma arquitetura de software define instâncias para os seus elementos,
diferentemente de CORBA. De acordo com a TAB. 2-1, CORBA pode ser referenciado
como um padrão ou como uma arquitetura de referência, pois ele define uma
funcionalidade para os seus elementos.
CORBA surgiu no contexto da orientação a objetos. Com o intuito de aproveitar
os benefícios deste paradigma, principalmente, a noção de encapsulamento dos dados e
da implementação de um objeto atrás de sua interface [3]. Por estar no âmbito da
orientação a objetos, a terminologia utilizada no contexto de CORBA é diferente da
utilizada na Arquitetura de software ou, às vezes, é a mesma terminologia porém com
uma conotação diferente. Estes dois contextos possuem níveis de abstração diferentes,
mas seus conceitos podem ser relacionados [12]:
• No contexto de CORBA, fala-se somente de objetos, ou de componentes mas,
neste caso, denotam um objeto ou o código que o implementa. Os componentes
são objetos escritos em uma linguagem de programação prontos para serem
executados. Os objetos podem ser um cliente ou uma implementação de objeto
denominada, servidor. Cada componente, em CORBA, tem duas partes
disjuntas, uma funcional e uma que interage com o mundo externo, a interface.
Na arquitetura de software um componente é mais que um objeto, como definido
na Seção 2.1, mas assim como CORBA, ela considera um componente como
duas partes disjuntas, o componente e seus pontos de interação, as portas.
• CORBA impõe um único tipo de interação, a semântica de chamada de
procedimento. Através deste tipo de interação pode-se representar (simular)
qualquer tipo de interação. Na arquitetura de software, os conectores podem vir
a ser representados por chamadas de procedimento, mas poderiam ser
representadas de outras maneiras também, tais como pipes etc.
Assim, CORBA é uma instância de um padrão mais genérico, para a
implementação utilizando o paradigma de orientação a objetos, sendo, assim, uma
solução de implementação. Como um objeto pode representar/simular o comportamento
de qualquer tipo de componente arquitetural, pode-se considerar um componente em
CORBA como sendo uma entidade de alta abstração, mas neste caso, para ser
implementado ele tem que ser refinado/instanciado [12].
23

Outro termo comumente utilizado no contexto de CORBA e arquitetura de
software mas com significados diferentes é o termo “Arquitetura de CORBA”. A
arquitetura de CORBA, no contexto de arquitetura de software, denota como CORBA
está estruturado internamente e como ele interage com o mundo externo, no caso,
clientes e servidores. Entretanto, no contexto de CORBA, este termo é, também,
utilizado para denotar como construir aplicações que utilizam CORBA ou, como
construir implementações de CORBA [27].
Nesta dissertação adotamos a terminologia utilizada por CORBA, mas levando
em consideração as diferenças e similaridades comentadas aqui.
2.3.2 Arquitetura de Gerenciamento de Objetos
A OMA (Object Management Architecture) foi definida pela OMG (Object
Management Group) para integrar aplicações. A OMA agrupa o conjunto de objetos
CORBA (Common Object Request Broker Architecture) em serviços e facilidades que
oferecem suporte para o desenvolvimento de aplicações que usam objetos CORBA
[8][41][42][44]. Os principais componentes da OMA podem ser visualizados como na
FIG 2-8 e são assim descritos:
• ORB CORBA (Object Request Broker) - Ele provê a infraestrutura necessária
para que os objetos façam e recebam requisições transparentemente, em um
ambiente distribuído e heterogêneo. O ORB fornece convenções para nomear,
localizar, ligar e interagir com objetos, provendo portabilidade e
interoperabilidade aos sistemas.
• Serviços CORBA – São coleções de serviços que dão suporte a funções comuns
de sistemas distribuídos. Como por exemplo, serviços de nomes, de eventos de
trading etc. Os serviços provêem consistência para as aplicações e ajudam a
aumentar a produtividade do programador, já que estes poderão concentrar seus
esforços em seus objetos (os da aplicação), sem ter que se preocupar com
serviços em nível de sistema.
• Objetos Facilidades – É uma coleção de facilidades e objetos comuns que
provêem um conjunto de funções de aplicação genérica que podem ser
configuradas para os requisitos específicos de uma aplicação. São facilidades
como impressão, gerenciamento de documentos, banco de dados, correio
eletrônico etc.
24

• Objetos do Domínio – Representam áreas verticais que provêem funcionalidades
de interesse direto do usuário final em domínios de aplicação particulares. Por
exemplo, objetos de negócio para banco, finanças, objetos de planilhas
eletrônicas, e componentes GUI (Graphical User Interface).
• Objetos da Aplicação – São os objetos que formam o centro de uma aplicação
compatível com CORBA, eles são denominados objetos de negócio. O conjunto
de objetos da aplicação é formado por objetos cliente e servidor, consumidores
finais desta arquitetura provida pela OMG, que irão utilizar os componentes da
arquitetura para realizar suas interações [32].
Objetos específicos da
aplicação não padronizados
Objetos específicos do
domínio vertical
Objetos Facilidades
Horizontais
Interfaces de Aplicação
Interfaces de Domínio
CORBA ORB
Interface de serviços CORBA
Interfaces de Facilidades
Corba
Serviços de objetos
comuns
FIGURA 2-4 - O modelo de referência da OMA.
A arquitetura OMA é uma arquitetura em camadas, e seus componentes
possuem uma correlação com as camadas da arquitetura definida na Seção 2.1, FIG. 2-
3. Os objetos da aplicação correspondem à camada de sistemas da aplicação, os objetos
do domínio e os objetos facilidades correspondem à camada de sistemas específicos do
negócio e os serviços CORBA e o CORBA ORB à camada middleware. A camada
Software do sistema corresponde ao sistema operacional utilizado, sendo que a OMA é
uma arquitetura independente de plataforma, veja na FIG. 2-5.
25

Objetos da aplicação
Objetos do domínio
Objetos facilidades
Serviços Corba
ORB
Sistema operacional
OMA
Sistemas de aplicação
Específico do negócio
Middleware
Software do sistema
Arquitetura em
camadas genérica
FIGURA 2-5 - Relação entre a arquitetura OMA e a arquitetura em camadas.
Entretanto, na arquitetura OMA, a tradicional comunicação entre camadas
adjacentes não acontece. Todos os componentes desta arquitetura podem requisitar
serviços, através do componente ORB, a qualquer um dos componentes que estejam
abaixo deles, ou seja, possuem um nível de generalidade mais alto. A arquitetura OMA,
segue as restrições do modelo Layering Through Inheritance (apresentado na Seção
2.1.1), pois os objetos de nível mais alto usam as suas interfaces e as interfaces dos
níveis mais baixos por virtude da herança de interfaces.
Na FIG. 2-6, retratamos o uso de interfaces utilizadas pela OMA para interação
entre os componentes desta arquitetura em camadas. Por exemplo, os objetos da
aplicação podem ter acesso às interfaces definidas pelos objetos do domínio, facilidades
e de serviço. Assim, eles podem interagir, através do ORB, com cada um destes objetos.
Objetos da
aplicação
OS
AI
CF
DI
Objetos do
domínio
OS
DI
... ...
CF
Objetos
facilidade
CF
OS
Object Request Broker
...
Object
framework
OS
Objetos de
serviço
OS
OS:Serviços do objeto
CF: Facilidades comum
DI: Interfaces do domínio
AI: Interfaces da aplicação
FIGURA 2-6 - Modelo de referencia OMA - Uso de interfaces.
O papel de CORBA na OMA é implementar a função do ORB
(ROSENBERGER in [32]). CORBA é composto de um conjunto de componentes que
26

juntos provêem o suporte necessário para obter interoperabilidade entre componentes,
independentemente, de plataforma e linguagem de programação. Em uma requisição de
serviços, CORBA é responsável pela localização do objeto ao qual se destina a
requisição, pelo envio dos parâmetros da requisição no formato aceito por este objeto, e
pelo retorno de parâmetros de saída da requisição, se houver, para o cliente. CORBA
torna todas estas tarefas transparentes para os objetos cliente e servidor. Na FIG. 2-7,
mostramos uma requisição de um cliente sendo enviada através do CORBA a um
servidor.
Cliente
Requisição
Servidor
(Implementção do
Objeto)
ORB
(Object Request Broker)
FIGURA 2-7 - Requisição enviada através do ORB.
Qualquer software que forneça as interfaces e os serviços especificados para
oferecer transparência à distribuição e heterogeneidade, pode ser considerado um ORB.
Assim, ORBs diferentes podem apresentar características de implementação diferentes,
resultando em serviços prestados a objetos e clientes com qualidades e propriedades
diferentes.
2.3.3 Estrutura de CORBA
Na FIG. 2-8, apresentamos a estrutura de um ORB e suas interfaces, através das quais
acontece a interação com os clientes e com as implementações de objetos. Descrevemos
cada um dos elementos desta estrutura para que possamos, posteriormente, apresentar as
características que afetam o mundo externo, ou seja, clientes e servidores.
27

Cliente
Implementação de Objeto
Interface de
Invocação
Dinâmica
Stub IDL
Cliente
Interface
ORB
Esqueleto
Estático
Esqueleto de
Invocação
Dinâmica
Adaptador
de Objeto
Repositório de
Interfaces
Núcleo ORB
Repositório de
Implementações
FIGURA 2-8 - Estrutura de um ORB.
• Núcleo ORB (ORB Core) oferece os mecanismos de representação de objetos e
de comunicação, tornando o processamento e a execução das requisições
possível. A estrutura de CORBA permite que as diferenças entre os núcleos
tornem-se completamente transparentes através da sobreposição dos
componentes de CORBA ao núcleo ORB.
• Stubs Cliente provêem as interfaces estáticas para os serviços dos objetos. Estes
stubs pré-compilados definem como os clientes invocam estaticamente os
serviços correspondentes no servidor. O Stub, do ponto de vista do cliente, é um
proxy local para um objeto servidor remoto. Os serviços fornecidos por um
objeto são definidos usando IDL (Interface Definition Language). Através da
definição em IDL do objeto são gerados os stubs, cliente e servidor, usando um
compilador IDL. Um cliente tem de ter um stub IDL para cada interface que use
no servidor. O stub inclui código para fazer marshalling, isto é, codificação e
decodificação das operações e os seus parâmetros numa mensagem que possa
ser enviada ao servidor. O Stub Cliente permite que o programador, ao invocar
um método de um serviço remoto, não precise se preocupar com protocolos e
marshalling.
• Interface de invocação dinâmica (Dynamic Invocation Interface - DII) permite
especificar e construir pedidos durante a execução, em vez de o fazer através de
stubs. A DII é necessária quando a interface do objeto não é conhecida durante a
compilação. Através do mecanismo DII, um objeto é ativado por uma chamada
ou por uma série de chamadas ao ORB, onde o método e os parâmetros são
especificados. É de responsabilidade do cliente especificar os tipos dos
parâmetros e os resultados esperados.
• CORBA define uma API padrão (Application Protocol Interface) para procurar
os meta-dados que definem a interface do servidor, a geração de parâmetros, a
28

ealização dos pedidos e a recepção dos resultados. Para se construir uma
invocação dinâmica são necessários 6 passos: descobrir os novos objetos através
dos serviços de Nomes e Trading; descobrir suas interfaces; obter a completa
definição do método; criar uma lista de argumentos; criar a solicitação; e fazer a
chamada.
• Interface ORB consiste de um conjunto de APIs para serviços locais que podem
ser de interesse para a aplicação, como por exemplo, converter uma referência a
um objeto numa string e vice-versa.
• Esqueleto estático (Stubs IDL do servidor, skeleton) provê as interfaces estáticas
para os serviços exportados pelo objeto. Estes stubs, como os stubs clientes, são
criados usando um compilador de IDL.
• Esqueleto dinâmico (Interface skeleton dinâmica - DSI) provê um mecanismo
para os servidores que precisem lidar com invocações de métodos em objetos
que não têm skeletons IDL. Quando uma mensagem é recebida, o DSI analisa os
valores dos parâmetros de modo a descobrir o receptor, ou seja, o objeto e o
método. Os skeletons dinâmicos são muito úteis para gerar implementações de
objetos em linguagens script ou interpretadas, dinamicamente. Por outro lado, os
skeletons normais são definidos para um objeto particular e esperam uma
implementação para cada método definido em IDL.
• Adaptador de objetos é responsável por ativar e desativar implementações de
objetos, manter o registro das implementações, promover a requisição de
métodos e garantir a segurança da interação entre os elementos envolvidos em
uma requisição.
• Repositórios de interfaces e de implementações armazenam informações sobre
as interfaces e os objetos instalados para disponibilizá-las aos clientes e às
implementações de objetos, respectivamente.
CORBA é uma arquitetura complexa já que se propõe a tratar todos os requisitos
de transparência necessários em um ambiente heterogêneo e distribuído. Detalhes do
funcionamento desta arquitetura podem ser encontrados em [8][32][41][42][44]. Não
nos detemos a estes detalhes no presente trabalho porque o nosso foco é como e quais
informações são necessárias para uma aplicação interagir com outras em um ambiente
distribuído e heterogêneo utilizando CORBA.
29

Usamos CORBA como uma caixa preta que nos provê serviços para interação
com outras aplicações ou objetos. Assim, na Seção 2.3.4, mostramos quais informações
devem ser fornecidas e quais podem ser requisitadas desta caixa preta.
2.3.4 Objetos de uma Aplicação
2.3.4.1 O Cliente
Clientes são aplicações ou processos que requisitam serviços de algum outro objeto
(servidor). Para chamar serviços remotos, clientes enviam requisições para o ORB.
Depois que a operação é executada eles recebem respostas ou exceções do ORB.
Exceções são mensagens indicando algum erro ocorrido impedindo a execução do
serviço requisitado. A interação entre clientes e servidores é baseada em um modelo
dinâmico onde servidores também podem agir como clientes, diferentemente da noção
tradicional da arquitetura cliente-servidor [6].
Os clientes não conhecem a localização dos servidores que eles acessam. Isto
permite a adição de novos serviços e a mudança de serviços existentes para outros
locais, enquanto o sistema está em execução. Entretanto, o cliente deve conhecer a
referência do objeto que irá lhe fornecer um serviço. A referência de objeto é atribuída
pelo ORB durante a criação dele, ela é a identificação de um objeto CORBA. Esta
referência pode ser obtida no Repositório de interfaces, que também deve ser conhecido.
Os clientes podem requisitar serviços de três modos: síncrono, síncrono deferido
e assíncrono, veja na FIG. 2-9 [60]:
• O modo síncrono tem a forma de chamadas a funções remotas (Remote
Procedure Calls), na qual o objeto aguarda a resposta a um serviço requisitado.
• O modo síncrono deferido permite que os clientes recebam a resposta do
servidor algum tempo depois de terem efetuado o pedido, sem que seja
necessário bloquear a execução do cliente. Este modo só pode ser usado através
das Interfaces de invocação dinâmica.
• Por fim, o modo assíncrono permite que o cliente execute uma operação no
servidor sem esperar uma resposta ou que a operação termine.
30

Invoke()
Send()
Onewayinvoke()
wait
Get-response()
Síncrono
Síncrono
Deferido
Assíncrono
FIGURA 2-9 - Modos de invocação de operações.
2.3.4.2 A Implementação do Objeto (Servidor)
Um servidor implementa objetos que expõem suas funcionalidades através de uma
linguagem de definição de interfaces denominada, IDL. Estas interfaces consistem de
operações e atributos. Geralmente, elas são agrupadas em um arquivo de interfaces de
acordo com a similaridade de suas semânticas. Servidores oferecem serviços comuns
para muitos domínios de aplicação ou implementam funcionalidades específicas para
um único domínio de aplicação ou tarefa.
Quando um servidor é iniciado, ele primeiro se registra no ORB, ou seja,
disponibiliza os serviços que ele está apto a oferecer, e recebe uma referência que irá
identificá-lo. Para disponibilizar este serviço, ele insere a sua referência em um
repositório, ficando apto a receber requisições. O ORB guarda todas as informações
necessárias em seus repositórios. Quando um cliente precisa de um serviço, ele envia a
requisição para o ORB local. O ORB verifica, em seus repositórios, onde está o servidor
requisitado, e repassa a requisição para este servidor seguindo o protocolo necessário.
Depois que o serviço é executado ou alguma exceção ocorrer, o servidor retorna o
resultado/exceção para o ORB e este para o cliente.
2.4 Conclusões
Neste capítulo, apresentamos as principais tecnologias que influenciam nossa pesquisa:
arquitetura de software, linguagens de modelagem e especificação, e CORBA. Os
termos e conceitos definidos aqui são utilizados no restante desta dissertação. Como
apresentamos, muitos destes conceitos são utilizados no contexto da Arquitetura de
31

software, da UML e de CORBA, de maneira diferenciada. Entender qual a diferença
entre eles e como eles podem estar relacionados é necessário para um bom
entendimento dos capítulos seguintes.
32

3. UM META-MODELO PARA MODELAR UMA FAMÍLIA DE
APLICAÇÕES DISTRIBUÍDAS
“Um meta-modelo é um modelo genérico através do qual podem ser definidos outros
modelos genéricos ou específicos” [27].
Neste trabalho de dissertação, estamos propondo um meta-modelo para modelar
uma família de aplicações distribuídas. Esta família de sistemas é caracterizada pelas
restrições impostas pelo estilo camadas e pelas restrições impostas pela utilização do
padrão CORBA, apresentados respectivamente nas Seções 2.1.1.1 e 2.3. Através deste
meta-modelo oferecemos, ao projetista, informações arquiteturais inerentes a integração
destes dois padrões. As informações oferecidas dizem respeito à arquitetura e a
arquitetura detalhada desta família de sistemas.
Como apresentamos na Seção 2.2.1.1, FIG. 2-4, oferecer a arquitetura detalhada
de uma família de sistemas provê uma maneira mais natural de transformar estilos em
arquiteturas detalhadas de um produto específico. Através de meta-modelos podemos
realizar a idéia de sub-estilos e, assim, documentar a partir de um estilo, subtipos dele.
Por exemplo, as variações do estilo camadas citadas na Seção 2.1.1.1 podem ser
consideradas sub-estilos do estilo camadas. Recursivamente, podemos utilizar a mesma
abordagem para criar subtipos destes sub-estilos. Podemos, também, refinar cada um
destes estilos e sub-estilos, de maneira a obter uma arquitetura mais detalhada,
(utilizando elementos do nível de design, especificado em UML, por exemplo),
preservando as propriedades arquiteturais.
Assim, um meta-modelo pode ser:
• Instanciado, para o desenvolvimento da arquitetura de um sistema específico
com aquelas características genéricas iniciais, ou para a definição de sub-estilos.
Instanciar significa criar um elemento específico a partir de um outro mais
genérico. O elemento específico herda todos as características do elemento
genérico;
• Refinado, para se aproximar dos detalhes de implementação. Refinar significa
criar um elemento com nível de abstração menor que o elemento genérico,
acrescentando características que se aproximam da implementação.
33

Para elaborar um Meta-Modelo para projetar uma família de aplicações distribuídas:
• Aplicamos alguns conceitos e técnicas empregadas na arquitetura de software,
tais como, os estilos e visões;
• Consideramos características impostas pelo middleware CORBA e pelo estilo
camadas, tais como, restrições estruturais e comportamentais; e
• Empregamos a UML como meio de documentá-lo e difundi-lo, e a linguagem Z
como meio de especificar características não especificadas ou ambiguamente
especificadas pela UML.
Assim, este meta-modelo esclarece todas as restrições impostas pelo estilo
camadas e por CORBA. Ele resolve os conflitos que surgem ao colocar estes dois
padrões juntos e aproxima o design da arquitetura a modelos mais detalhados do design,
por utilizar uma única linguagem para mapear ambas as abstrações.
Neste capítulo, apresentamos: a metodologia utilizada para a elaboração do
meta-modelo proposto, na Seção 3.1; a terminologia e notação utilizadas para
documentar este meta-modelo, na Seção 3.2; e como empregamos as tecnologias
apresentadas no Capítulo 2 e os artefatos construídos para alcançar o objetivo proposto,
nas Seções 3.3, 3.4, 3.5 e 3.6.
3.1 Metodologia
Para elaborar o meta-modelo proposto, desenvolvemos três outros meta-modelos que
podem ser, igualmente instanciados e/ou refinados. Cada um deles representa um grupo
de características com maior ou menor grau de generalidade, indicando domínios de
aplicação diferentes. Na FIG. 3-1, apresentamos como estes meta-modelos estão
relacionados um com o outro, indicando também, a seqüência em que foram construídos
e a abrangência relativa do domínio a que eles se aplicam.
34

2 -
Meta-modelo para
modelar arq em camadas
4- e distribuídas
Meta-modelo para Meta-modelo para
modelar arq. 3- modelar arq.
em camadas baseadas em CORBA
Especificação em UML e Z
1-
Meta-modelo para modelar estilos
Visão Conceitual
FIGURA 3-1 - Relação entre os meta-modelos desenvolvidos.
Na FIG. 3-1, o plano abaixo da pirâmide, em cinza na figura, representa a visão
conceitual definida em [27], apresentada na seção 2.1.2. A Visão Conceitual embasa
todos os meta-modelos aqui desenvolvidos, pois eles herdam os elementos e a estrutura
global desta visão, ou meta-modelo. Nós realizamos algumas modificações na visão
conceitual para que ela dê suporte à descrição de estilos. Estas mudanças resultaram em
um meta-modelo para modelar estilos, representado pela base da pirâmide na FIG 3-1.
A estrutura estática foi especificada através do diagrama de classes da UML e em Z. A
estrutura dinâmica foi modelada através dos diagramas de estados e de interações da
UML.
Os meta-modelos para modelar arquiteturas em camadas e para modelar
aplicações que utilizam CORBA são baseados neste meta-modelo inicial, representados
na FIG 3-1 pela segunda camada da pirâmide. Realizamos duas instanciações
independentes, por adicionar em uma as características impostas pelo estilo camadas e,
na outra, pelo padrão CORBA.
O topo da pirâmide representa o principal objetivo deste trabalho de dissertação.
Ele foi igualmente instanciado, desta vez, herdando características dos dois metamodelos
distintos anteriormente citados. Entretanto, para absorver as características
destes dois meta-modelos foi necessário realizar alguns ajustes para que ambos possam
coexistir num mesmo sistema.
Todos estes meta-modelos são detalhadamente explicados nas próximas seções.
Cada um deles é representado através de suas estruturas estática e dinâmica em UML e
da especificação formal em Z das restrições impostas aos elementos do meta-modelo.
35

3.2 Notação e Terminologia
Para documentar o meta-modelo aqui proposto, escolhemos a linguagem UML. Como
apresentamos na Seção 2.2.1, a UML oferece várias vantagens para a descrição de
arquiteturas, em especial: a comunicabilidade; a facilidade de aprendê-la e entendê-la; e
a forma natural de transformar um nível mais abstrato em implementação. Entretanto, a
UML não é uma ADL [37][53]. Assim, é necessário fazer um mapeamento dos
elementos arquiteturais para a notação definida pela UML.
Os principais elementos arquiteturais são: componentes, conectores e
configuração. Para representá-los nós utilizamos os elementos de modelos definidos
pela UML - Classes, Objetos e Relacionamentos – da seguinte maneira, veja na FIG. 3-
2:
• Componente 1 : É uma entidade computacional ou de armazenamento de dados,
como definimos na Seção 2.1. Um componente possui uma interface para
interação com o mundo externo que ocorre através de pontos de interação
denominados, portas. Nós representamos os componentes através de classes e
suas portas através de classes agregadas. Assim, podemos representá-los como
entidades de primeira classe e retratar suas estruturas, propriedades e
comportamentos. As propriedades podem ser representadas por atributos ou por
associações. O comportamento pode ser descrito através de diagramas
dinâmicos. E a generalização pode ser utilizada para relacionar um conjunto de
tipos de componentes ou de portas.
• Conector: É a relação que denota a comunicação entre componentes. Os pontos
de interação dos conectores são denominados papéis. Os conectores e seus
papéis são representados através de classes. Da mesma maneira, que os
componentes e portas, eles são entidades de primeira classe. Assim eles podem
ser tão simples ou tão complexos quanto se queira. Para realizar a comunicação
os papéis são ligados às portas através do relacionamento de associação.
• Configuração: A configuração é retratada como um gráfico de componentes e
conectores. Ela define os tipos de componentes e conectores e restringe como
instâncias destes tipos podem ser interconectadas. Nós representamos a
1 Nesta dissertação utilizamos o termo componente para denotar os componentes arquiteturais e não a
noção de componentes oferecida pela UML, apresentada na Seção 2.2.1.1.
36

configuração, também, através de classes. Esta classe agrega as classes
representantes do componente e do conector.
Classe
Atributo
Operação
Classes
Objeto
Objetos
Relacionamentos
FIGURA 3-2 - Elementos de modelo UML utilizados.
Além disto, nós utilizamos os objetos, definidos pela UML, para representar
instâncias dos elementos arquiteturais para a modelagem de aplicações específicas.
A desvantagem desta abordagem é que modelar todos os elementos através da
mesma representação gráfica, através de classes, causa uma certa perda de
representatividade ou confusão visual [25].
3.3 Um Meta-modelo para Modelar Estilos
A visão conceitual definida por Hofmeister et al. [27], apresentada na Seção 2.1.2, foi
utilizada como modelo base para definição dos meta-modelos que estamos propondo
nesta dissertação. Esta visão (FIG. 3-3) pode ser instanciada para criação de qualquer
arquitetura, visto que, ela apresenta os elementos genéricos e fundamentais para tal
tarefa. A partir desta visão, pode-se elaborar arquiteturas com diferentes tipos de
componentes, conectores e protocolos.
Configuração
0..1
*
*
Componente
0..1
*
0..1
1
1
0..1
*
* *
Conector
0..1
0..1
liga
*
*
* *
Porta * conecta * Papel
*
*
obedece
obedece
1 1
*
*
liga
Protocolo
FIGURA 3-3 - Meta-modelo da visão conceitual da arquitetura.
37

Como mostramos na FIG. 3-3, o elemento Configuração é composto por vários
Componentes e Conectores que por sua vez também podem ser compostos por outros
Componentes e Conectores. Cada Componente é composto por Portas e cada Conector é
composto de Papéis. A conexão entre componentes ocorre através da conexão entre suas
portas e papéis de algum conector ou através da ligação direta entre portas, neste último
caso quando um componente composto se comunica com algum de seus componentes
internos. Um papel também pode está ligado diretamente a um papel de outro conector.
Para que uma conexão entre portas e papéis ocorra, estes devem obedecer a um mesmo
protocolo. O protocolo especifica regras para a comunicação tais como os tipos de
dados suportados, quem lê, o que lê, aonde lê etc.
Assim como as arquiteturas, um estilo é constituído de um vocabulário, que
descreve os tipos de componentes e conectores, uma configuração, e um protocolo. A
configuração de um estilo é uma instância do modelo da FIG. 3-3 para o vocabulário e
restrições desejadas. A visão conceitual fornece algumas restrições genéricas. Cada
estilo deve herdar estas restrições básicas e estabelecer as propriedades intrínsecas ao
próprio estilo. Estas características são de estrutura, de comportamento, e/ou de
vocabulário. Entretanto, para oferecer um suporte mais adequado para especificar
arquiteturas caracterizadas por estilos, nós propomos algumas alterações à visão
conceitual definida por Hofmeister et al. [27]. São elas:
1) Substituímos as agregações existentes entre ‘Componente e Componente’,
‘Conector e Conector’, ‘Componente e Conector’ e ‘Conector e Componente’
pelas agregações entre ‘Componente e Configuração’ e entre ‘Conector e
Configuração’. Assim, através deste meta-modelo damos suporte a composição
de componentes e conectores, também suportada pela visão conceitual, e a
heterogeneidade de estilos.
Configuração
0..1
*
*
Componente
1
*
0..1
1
1
1
...
1
1
0..1
*
* *
Conector
0..1
FIGURA 3-4 - Mudanças nas agregações existentes no meta-modelo.
38

A visão conceitual suporta heterogeneidade de componentes, conectores e
protocolo, visto que, ao instanciar esta visão pode-se obter uma arquitetura com
diferentes tipos de componentes interagindo e se comportando de várias maneiras, onde
cada conexão pode obedecer a um protocolo diferente. Entretanto, ela não dá suporte a
heterogeneidade de estilos, pois se forem estabelecidas regras ou restrições para os
elementos arquiteturais então todas as instâncias destes elementos terão a mesma
sintaxe e semântica.
Com a alteração que realizamos, oferecemos um leque maior de possibilidades
para a composição dos elementos. Agora, um componente/conector composto é um
elemento que possui uma configuração interna, que por sua vez possui um conjunto de
componentes e conectores com tipos determinados por esta configuração interna. As
restrições impostas pela configuração interna podem ser idênticas às impostas pela
configuração “externa” mas também podem ser diferentes.
Para que sejam diferentes, consideramos que a agregação existente entre
Componente/Conector e a Configuração é sempre realizada com relação a Configuração
genérica e não a configuração instanciada. Como apresentamos na FIG. 3-5, a
configuração em camadas é uma configuração que possui camadas como os seus
componentes. Estas camadas, por sua vez, podem possuir uma configuração interna,
podendo ser uma configuração em camadas ou de outro tipo.
Configuração
1
1 *
Camadas
Configuração_
Camadas
1
FIGURA 3-5 - Exemplo das agregações modificadas no meta-modelo.
Para um maior entendimento, é válido fazermos algumas observações:
1.1 Cada componente/conector deve ser uma entidade auto-contida, com baixo
acoplamento e alta coesão, para que seja mais facilmente reutilizados. Assim, se
considerarmos que um componente/conector, possui um conjunto de componentes e
conectores, como definido pela Visão Conceitual, então: a) a configuração externa
tem que fazer o controle das interações e estruturação destes componentes e
39

conectores internos ou; b) o componente/conector composto tem que fazer este
gerenciamento.
a) Para o primeiro caso, quando os componentes/conectores forem reutilizados, a
informação de sua organização interna se perde ou tem que ser buscada na
configuração. Ou seja, eles não são auto-contidos.
b) Para o segundo caso, o componente/conector composto tem que desempenhar o
papel da configuração e pode não ser tão flexível ou restritivo quanto deve, pois
está se ocupando de atividades extras às suas funcionalidades.
1.2 Uma configuração é única num certo contexto. Por exemplo, se A é uma
configuração caracterizada pelo estilo Camadas e B pelo estilo Pipe and Filter, A e
B se comunicarão através de um conector que:
a) pertence a A ou a B. Pertencendo a A, por exemplo, então o outro componente
com o qual este conector está conectado pertence a B. Entretanto, um conector
conecta dois ou mais componentes de uma mesma configuração e não de
configurações diferentes, sendo inviável esta alternativa. Ou;
b) não pertence nem a A nem a B. Então pertence a uma terceira configuração que
gerencia esta comunicação. No entanto, no meta-modelo a conexão é realizada
entre portas e papéis, como configurações não possuem portas, então as
configurações A e B devem está “empacotadas”, representando os componentes
desta terceira configuração. Enfim, configurações não interagem com
componentes, conectores ou configurações, elas são únicas num determinado
contexto.
Nós consideramos que um componente/conector composto é aquele que possui,
internamente, um conjunto de elementos arquiteturais estruturados segundo
alguma configuração interna. Assim, os componentes/conectores compostos
podem fazer parte da configuração interna para que possam interagir com os
componentes/conectores internos. Vale lembrar que uma configuração é um
elemento que estabelece restrições para a organização e comunicação dos
componentes.
2) A ligação que existe entre portas, na Visão Conceitual, foi eliminada. Esta mudança
fornece maior flexibilidade à comunicação entre um componente composto e os seus
40

componentes internos. Assim, a comunicação é realizada através de um conector,
podendo ser tão simples ou tão complexa quanto se queira.
No caso da ligação entre portas como definido na Visão Conceitual, as portas
ligadas precisam invocar explicitamente uma operação que não lhes pertence. Por
exemplo, se A é um componente composto e B pertence à configuração interna de A,
então se A quiser requisitar um serviço de B, a porta de A que está ligada à porta de B
tem que explicitamente invocar a operação da porta de B da seguinte maneira
B.portax.operação() ou seja a porta do componente A conhece a porta e o componente
com o qual ele interage e vice-versa. Assim, se B for reutilizado, é necessário modificar
as operações declaradas nesta sua porta para que ele se comunique com um outro
componente C, por exemplo.
Através da mudança que realizamos, os componentes compostos e internos
passam a ter maior independência, pois eles não precisam conhecer os componentes
com os quais interagem. Este é o papel do conector que realiza a conexão entre eles.
Assim, um componente pode ser reutilizado sem que seja necessário modificar alguma
estrutura interna, basta garantir que existe um conector capaz de fazer a comunicação.
3) Um componente oferece e requisita serviços através de suas portas. Consideramos
que há uma porta para cada serviço requisitado ou oferecido. Desta forma, não
limitamos o componente/conector a um processamento seqüencial, pois assim eles
podem tratar várias requisições ao mesmo tempo, dependendo apenas da tecnologia que
o implementa.
4) Consideramos que há dois tipos de portas uma que recebe requisições, podendo
enviar respostas, e outra que envia requisições, podendo receber respostas,
denominadas, respectivamente, Receptor (Porta_rec) e Expedidor (Porta_exp). Um
componente pode ter N portas, cada uma assume um único tipo. Sendo assim as portas
Receptoras oferecem serviços e as Expedidoras requisitam serviços de/para o
componente que as possui.
5) Consideramos que há dois tipos de papéis, um de entrada e outro de saída,
denominados Papel IN e Papel OUT. O Papel IN lê requisições, ou escreve respostas, de
uma porta Expedidora e escreve-as, ou as lê, em uma porta Receptora. Um conector
possui N papéis sendo que haverá pelo menos um de cada tipo.
41

6) Um conector conhece todas as portas com as quais os seus papéis estão ligados.
Como visto, estamos considerando algumas características de implementação.
Porém estas características podem afetar a arquitetura. Por exemplo, na mudança 3,
consideramos uma porta para cada serviço prestado ou requisitado tendo em vista que o
componente pode ter uma execução em paralelo. Caso não considerássemos isto em
fases iniciais do design então o modelo na fase detalhada não retrataria a arquitetura, e
posteriormente na fase de manutenção seria mais difícil identificar e corrigir os erros e
conseqüentemente evoluir o sistema.
Assim, a estrutura estática de um meta-modelo capaz de ser refinado para a
elaboração de arquiteturas caracterizadas por um estilo específico foi desenvolvido e é
apresentado a seguir, na FIG. 3-6.
42

3.3.1 Estrutura Estática
Configuração
1
Conjunto de Componentes
Conjunto de Conectores
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Comp-Comp
1
Serviço()
{Serviços();
Requisitar();
Responder()}
Requisitar()
{Porta_exp.Requisitar()}
Responder()
{Porta_rec.Responder()}
Receber(req)
{Componentes.Serviço()}
*
Componentes
Id_com
Conjunto de Serv_req
Conjunto de Serv_ofer
Conjunto de Porta_rec
Conjunto de Porta_exp
Conf
Serviço()
Requisitar()
Responder()
{ou}
1
*
Porta
1
1
* conexão *
*
*
obedece
obedece
1
1 *
Conectores
Id_con
Conjunto de PapelIn
Conjunto de PapelOUT
Conjunto de pares Port_rec-PapOUT
Conjunto de pares Port_exp-PapIN
Conjunto de pares Pap-pap
Conf
Serviço()
Enviar()
{ou}
1
*
Papel
*
*
liga
Serviço()
{...
Enviar()}
Enviar()
{Papel OUT.Escrever(req);
Papel IN. Escrever(resp)}
Ler(resp)
{Porta_rec.Responder();
Conector.Serviço();}
Escrever(req)
{Porta_rec.Receber(req)}
Porta_rec
Id_rec
Serv-Ofer
Propr
Receber(resp)
{Componentes.Serviço()}
Receber(req)
Responder()
Porta_exp
Id_exp
Serv_req
Propr
Requisitar()
Receber(resp)
1 1
Protocolo
Papel IN
Id_in
Propr
Porta_exp
PapelOUT
Ler(req)
Escrever(resp)
Papel OUT
Id_out
Propr
Porta_rec
PapelIN
Ler(resp)
Escrever(req)
Ler(req)
{Porta_exp.Requisitar();
Conector.Serviço();}
Escrever(resp)
Porta_exp.Receber(resp)}
FIGURA 3-6 - Estrutura estática de um meta-modelo para especificar estilos.
Na FIG 3-6, apresentamos a estrutura estática do meta-modelo. O meta-modelo,
assim como a visão conceitual, define os elementos arquiteturais e as possíveis
combinações entre eles. A seguir, explicamos cada um destes elementos e mostramos as
restrições impostas por eles. A linguagem de especificação Z é utilizada para descrever
estes elementos.
3.3.1.1 Configuração
Como apresentamos em seções anteriores, a configuração é uma entidade que estabelece
as restrições estruturais ou organizacionais de uma arquitetura. Para desempenhar sua
função, a configuração deve determinar: quais componentes e conectores a constituem;
43

quais portas estão conectadas a quais papéis; quais papéis estão ligados a quais outros
papéis; e quais componentes se comunicam com quais componentes. Então, a
configuração possui os seguintes atributos ou características:
• Conjunto de Componentes (através das agregações);
• Conjunto de Conectores (através das agregações);
• Conjunto de relações entre Porta Receptora e Papel OUT (através das
agregações);
• Conjunto de relações entre Porta Expedidora e Papel IN (através das
agregações);
• Conjunto de relações entre PapelIN e PapelOUT (através das agregações); e
• Conjunto de relações entre Componentes.
E estabelece as seguintes restrições para os seus atributos:
• Em uma configuração não existem duas instâncias de Componentes com o
mesmo identificador;
• Em uma configuração não existem duas instâncias de Conectores com o mesmo
identificador;
• Cada Componente deve estar relacionado a pelo menos um outro Componente;
• Todas as relações Porta-Papel existentes na configuração pertencem ao conjunto
de relações Porta-Papel de qualquer conector pertencente à configuração, e a
porta pertence a qualquer componente da configuração;
• Cada Papel relacionado a outro é um PapIN ou PapOUT de algum conector
pertencente à configuração;
• Para todas as relações entre Componentes Comp-Comp:
o Os Componentes pertencem à configuração;
o O primeiro componente da relação requisita um serviço e o segundo
oferece este serviço, ou seja, as semânticas destes serviços são iguais;
o Existe pelo menos um conector com seus papéis ligados às portas
daqueles Componentes.
O esquema Z, a seguir, representa este elemento com seus atributos (declaração) e
restrições (predicados).
44

§
comp_comp: Componentes © Componentes
[PORTA, PAPEL, SERVICO, COMPONENTE, CONECTOR, INTERFACE, CONFIGURAÇÂO,
PAPELIN, PAPELOUT]
§
comp: ¨ Componentes
Configuração ¡£¡¢¡¢¡¢¡¤¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¤¡¦¡£¡¢¡¢¡¢¡¥¡¢¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡
¢¡
con: ¨ Conectores
§
port_pap1: Porta_rec © PapelOUT
§
port_pap2: Porta_exp © PapelIN
§
pap_pap: PapelIN © PapelOUT
§
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡
c1, c2: Componentes c1 comp c2 comp
§¥
c1 . id_comp = c2 . id_comp c1 = c2
§¥
§
c1, c2: Conectores c1 con c2 §
con
c1 . id_con = c2 . id_con c1 = §¥ c2
x: Componentes x §
comp
z: Componentes z z x comp x z comp_comp §¥ comp_comp
x: Porta_rec; y: x y PapelOUT §
port_pap1
cp: Componentes; cn: Conectores cp comp cn § x y
con
cn . port_pap1 x cp . §¥ in_port
x: Porta_exp; y: x y PapelIN §
port_pap2
cp: Componentes; cn: Conectores cp comp cn §
con
y cn . port_pap2 x cp . out_port
§¥ x
x: PapelIN; y: x y PapelOUT §
pap_pap
z, w: Conectores z con w §
con
x z . in_pap y w . out_pap w . id_con z . §¥ id_con
x, y: Componentes x comp y x y comp §
comp_comp
z, w: SERVICO z x . serv_req w y . §
serv_ofer
z = w
k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT;
§
§
o: l n PapelIN k . m o port_pap1 k . §
port_pap2
l y . in_port m x out_port .
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-7 - Esquema Configuração.
3.3.1.2 Componentes
Os componentes são as entidades provedoras e requisitantes de serviços num sistema.
Eles provêem os serviços requisitados a eles por realizar alguma tarefa internamente e
por requisitarem outros serviços a outros componentes.
Seus atributos são os seguintes:
• Identificador;
• Conjunto de Portas Receptoras (através da agregação);
• Conjunto de Portas Expedidoras (através da agregação);
• Conjunto de Serviços a serem requisitados (através da agregação);
45

§
conf: ¨ CONFIGURAÇÂO
• Conjunto de serviços a serem oferecidos (através da agregação);
• Configuração interna (através da agregação).
As restrições impostas a estes atributos são:
• Não há duas instâncias de portas com o mesmo identificador;
• Todos os serviços oferecidos nas portas receptoras pertencem aos serviços
oferecidos do componente;
• Todos os serviços requisitados nas portas expedidoras pertencem aos serviços
requisitados do componente; e
• Se o componente for composto, ou seja, possuir uma configuração, então este
componente pode pertencer ao conjunto de componentes desta configuração
interna.
O esquema Z, a seguir, representa este elemento com seus atributos e restrições.
Componentes¡£¡¢¡¢¡¤¡¢¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¤¡¢¡¢¡¥¡¢¡¢¡£¡¦¡¢¡¤¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡
§ ¢¡
id_comp: § COMPONENTE
¨ in_port: Porta_rec
out_port: ¨ Porta_exp
§
serv_req, serv_ofer: ¨ SERVICO
§
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡ §¥
c1, c2: Porta_rec c1 in_port c2 §
in_port
c1 . id_port_rec = c2 . id_port_rec c1 = §¥ c2
c1, c2: Porta_exp c1 out_port c2 §
out_port
c1 . id_port_exp = c2 . id_port_exp c1 = c2
x: SERVICO; y: Porta_rec y in_port x = y . serv_ofer x serv_ofer
§¥
§¥
x: SERVICO; y: Porta_exp y out_port x = y . serv_req x serv_req
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-8 - Esquema Componentes.
§
conf < 2
As operações básicas realizadas por um componente são:
• Serviço() – Esta operação refere-se a qualquer funcionalidade implementada
pelo componente. Lembrando que, para realizar estas funcionalidades ele pode
requisitar outros serviços a outros componentes e responder ao serviço
requisitado.
o Serviço() {Serviços(); Requisitar(); Responder()}
46

id_port_rec: PORTA
§
serv_ofer: SERVICO
§
propr: Propriedade
§
• Requisitar() – A operação Requisitar() indica que o componente deve pedir a
alguma de suas portas para que ela requisite um serviço.
o Requisitar() {Porta_exp.Requisitar(req)}
• Responder() – A operação Responder() indica que o componente pede a alguma
de suas portas para enviar uma resposta a algum serviço requisitado a ele.
o Responder(){Porta_rec.Responder(resp)}
Um componente pode possuir inúmeras portas, receptoras e expedidoras.
3.3.1.3 Portas Receptoras
As portas receptoras são pontos de interação que representam os serviços oferecidos
pelo componente. Elas recebem requisições realizadas por outros componentes. Em
nosso caso, consideramos que cada porta é responsável por um serviço. Assim um
componente pode receber mais de uma requisição ao mesmo tempo, dependendo apenas
da tecnologia que for utilizada para a implementação do sistema. Os atributos das portas
receptoras são: Identificador, Serviço a oferecer e Propriedades. O esquema Z, a seguir,
representa este elemento.
¢¡ Porta_rec¡£¡¢¡¢¡¢¡¥¡¢¡¢¡¤¡¢¡¥¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡£¡¦¡¢¡¥¡¢¡¢¡£¡¡£¡¢¡¦¡£¡¢¡¢¡¢¡
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-9 - Esquema Porta_rec.
As operações básicas realizadas por uma porta receptora são:
• Receber(req) – Esta operação pede ao componente que a contém para executar
um serviço específico passado como parâmetro.
o Receber(req) {Componente.Serviço()}
• Responder(resp) – Indica que a porta recebeu do componente que a contém uma
resposta a um serviço que foi requisitado anteriormente. Esta operação é iniciada
pelo próprio componente.
o Responder(resp){resposta=resp}
47

id_port_exp: PORTA §
§
serv_req: § SERVICO
propr: Propriedade
3.3.1.4 Portas Expedidoras
As portas expedidoras são pontos de interação que representam os serviços dos quais o
componente é cliente . Elas enviam requisições a outros componentes. Assim como para
as portas Receptoras, consideramos que cada porta expedidora é responsável por enviar
apenas um serviço. Os atributos das portas expedidoras são: Identificador, Serviço a
requisitar e Propriedades. O esquema Z, a seguir, representa este elemento.
¢¡ Porta_exp¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡£¡¦¡¢¡£¡¡£¡¦¡¢¡£¡¢¡¢¡¥¡¡£¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¡
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-10 - Esquema Porta_exp.
As operações básicas realizadas por uma porta expedidora são:
• Receber(resp) – Esta operação repassa ao componente que a contém uma
resposta adquirida para um serviço específico requisitado anteriormente.
o Receber(resp) {Componente.Serviço()}
• Requisitar(req) – Indica que a porta recebeu do componente que a contém um
pedido para requisitar um serviço a outro componente. Esta operação é iniciada
pelo próprio componente.
o Requisitar(req){requisição=req}
3.3.1.5 Conectores
Os componentes são independentes uns dos outros. Cada componente não deve
conhecer (acessar diretamente) os componentes com os quais ele interage. Apenas a
configuração e os conectores possuem este conhecimento (através dos pares port-pap1,
port-pap2, comp-comp e pap-pap).
Além de transferir as requisições de um componente para outro, os conectores
podem realizar alguma tarefa adicional para melhorar a comunicação entre componentes
como por exemplo, transformar tipos de dados, verificar se o componente no final do
conector está ativo e apto a receber requisições, segurança etc. Os atributos do conector
são:
48

§
conf: CONFIGURAÇÂO
§ c1 . id_outpap = c2 . id_outpap c1 = c2
• Identificador;
• Conjunto de papéis de entrada (através da agregação);
• Conjunto de papéis de saída (através da agregação);
• Conjunto de relações entre papéis (através da agregação);
• Conjunto de relações entre porta e papel (através da agregação); e
• Configuração interna (através da agregação).
As restrições impostas a estes atributos são:
• Não há duas instâncias de papéis com o mesmo identificador;
• Deve existir pelo menos um papel de entrada e um de saída;
• Para todas as relações entre papéis um deles não pertence ao conector e o outro
pertence;
• Todos os papéis das relações port-pap1 e port-pap2 pertencem ao conector; e
• Se o conector for composto, ou seja, possuir uma configuração, então este
conector pode pertencer ao conjunto de conectores desta configuração interna.
O esquema Z, a seguir, representa este elemento com seus atributos e restrições.
Conectores ¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¦¡£¡¢¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡£¡
§ ¢¡
id_con: § CONECTOR
¨ in_pap: PapelIN
out_pap: ¨ PapelOUT §
§
port_pap1: © Porta_rec § PapelOUT
port_pap2: © Porta_exp § PapelIN
pap_pap: © PapelIN PapelOUT
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡
c1, c2: PapelIN c1 in_pap c2 in_pap
§
§¥
c1 . id_inpap = c2 . id_inpap c1 = c2
§¥
c1, c2: PapelOUT c1 out_pap c2 out_pap
§
in_pap
out_pap §
x: Porta_rec; y: PapelOUT x y port_pap1 y out_pap
§¥
§¥
x: Porta_exp; y: x y PapelIN port_pap2 y in_pap
x: PapelIN; y: PapelOUT x y pap_pap
§¥
x in_pap y out_pap x in_pap y out_pap
§
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-11 - Esquema Conectores.
§
conf < 2
49

Os conectores são representados, neste meta-modelo, como conectores de
primeira ordem. Conectores de primeira ordem são componentes que possuem a
funcionalidade específica de efetivar a comunicação entre dois ou mais componentes
[52]. A vantagem de tratar conectores como entidades ativas da configuração é que eles
ocultam todos os detalhes de comunicação para que os componentes se preocupem
somente com suas funcionalidades e eles podem exercer vários tipos de comunicação
sem afetar os componentes, por exemplo, chamada de procedimento, acesso de dados,
linkagem, stream, evento, arbitrator, adaptador e distribuidor [38].
Assim como os componentes, os conectores podem ser compostos, contendo
alguma configuração internamente. Esta configuração é constituída de componentes e
conectores, de maneira idêntica aos componentes compostos. Nos últimos anos, muitas
pesquisas vem sendo realizadas tendo como foco os conectores. Como a adaptação de
componentes é em muitas vezes inviável, investir no mecanismo de comunicação, ou seja
nos conectores, é uma forma de adaptar um sistema para que ele permaneça operável sem
ter que adaptar os componentes. Esta promete ser uma técnica poderosa para composição
de sistemas [14][24][38]. Além de considerar os conectores como entidades de primeira
ordem, GARLAN (1998) defende que é importante prover operadores para compor novos
conectores a conectores já modelados. Na Seção 3.6, nós definimos uma abordagem para
comunicação de componentes baseada em um conector CORBA.
As operações realizadas pelos conectores são:
• Serviço() – Esta operação indica as funcionalidades que um conector pode
desempenhar. Lembrando que a função principal do conector é realizar a
comunicação entre dois componentes, ou seja transmitir uma mensagem lida
pelo papel de entrada e escrevê-la num papel de saída, esta tarefa foi
denominada Enviar.
o Serviço() {...; Enviar()}
• Enviar() – Indica que o conector recebeu uma requisição ou uma resposta e está
repassando-a para um papel adequado, de entrada ou de saída dependendo do
modo da mensagem.
o Enviar(){PapelOUT.escrever(req); PapelIN_escrever(resp)}
Os conectores, através de seus pontos de interação denominados Papéis,
interagem com os componentes. Assim como as portas, os papéis são de dois tipos,
Papel IN e Papel OUT.
50

§
id_inpap: PAPEL
§
outpap: ¨ PapelOUT
3.3.1.6 Papel IN
O PapelIN é um ponto de interação do conector. Ele é responsável por ler as requisições
de uma porta Expedidora e/ou escrever respostas nesta porta. Sendo assim, o papel é o
elemento que de fato interage com o componente. Para isto, ele possui os seguintes
atributos:
• Identificador;
• Propriedades;
• Conjunto de portas expedidoras (Porta_exp); e
• Conjunto de papéis de saída (PapelOUT).
As restrições impostas aos atributos são:
• Cada Port_exp relacionada a um PapelIN possui propriedades “iguais” às
propriedades do PapelIN; e
• Cada PapelOUT relacionado a um PapelIN possui propriedades “iguais” às
propriedades do PapelIN.
O esquema Z, a seguir, representa este elemento.
¢¡ PapelIN¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¢¡¥¡¢¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¥¡¤¡¢¡¢¡¢¡£¡¢¡¦¡£¡¢¡¤¡¢¡
§
propr: Propriedade
§
port_exp: ¨ Porta_exp
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡
x: Porta_exp x port_exp x . propr = propr
§¥
§¥
x: PapelOUT x outpap x . propr = propr
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¤¡¢¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-12 - Esquema PapelIN.
As operações realizadas pelo PapelIn são:
• Ler(req) – Indica que o papel está apto a ler as requisições que foram feitas por
uma certa porta expedidora com a qual este papel está conectado, e repassa esta
requisição para o conector que a contém para que se necessário ele realize
alguma tarefa e repasse a requisição/resposta para o papel que irá finalizar a
transmissão.
51

§
id_outpap: PAPEL
§
inpap: ¨ PapelIN
§¥
x: PapelIN x inpap x . propr = propr
o Ler(req){Expedidor.Requisitar(req); Conector.Serviço()}
• Escrever(resp) – Indica que o papel está apto a escrever as respostas
encaminhadas por uma certa porta receptora em uma porta expedidora.
o Escrever(resp){Expedidor.Receber(resp)}
3.3.1.7 Papel OUT
O PapelOUT é um ponto de interação do conector. Ele é responsável por escrever as
requisições em uma porta Receptora e/ou ler respostas desta porta. Para isto ele possui
os seguintes atributos:
• Identificador;
• Propriedades;
• Conjunto de portas receptoras (Porta_rec); e
• Conjunto de papéis de entrada (PapelIN).
As restrições impostas aos atributos são:
• Cada Port_rec relacionada a um PapelOUT possui propriedades “iguais” às
propriedades do PapelOUT; e
• Cada PapelIN relacionado a um PapelOUT possui propriedades “iguais” às
propriedades do PapelOUT.
O esquema Z, a seguir, representa este elemento.
¢¡ PapelOUT ¡¢¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¦¡¢¡¤¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡
§
propr: Propriedade
§
port_rec: ¨ Porta_rec
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-13 - Esquema Papel OUT.
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡
x: Porta_rec x port_rec x . propr = propr
§¥
As operações realizadas pelo PapelOUT são:
• Ler(resp) – Indica que o papel está apto a ler as respostas que foram oferecidas
por uma certa porta receptora com a qual este papel está conectado, e repassa
52

esta resposta para o conector que a contém para que se necessário ele realize
alguma tarefa e repasse a resposta para o papel que irá finalizar a transmissão.
o Ler(resp){Receptor.Responder(resp);Conector.Serviço()}
• Escrever(req) – Indica que o papel está apto a escrever as requisições
encaminhadas por uma certa porta expedidora em uma porta receptora com a
qual ele está conectada.
o Escrever(req){Receptor.Receber(req)}
3.3.1.8 Protocolo
Os Papéis e as Portas devem obedecer a um protocolo para que a comunicação
realmente aconteça. Assim como a configuração, o protocolo é um elemento que
gerencia um certo conjunto de restrições na arquitetura. Ele é responsável por
determinar as regras de comunicação: como ocorre a comunicação; quais propriedades
são necessárias para que uma porta esteja conectada a um papel; e quem inicia a leitura
ou escrita. Deve-se garantir que Papéis IN só interagem com portas Expedidoras ou
papéis OUT e que Papéis OUT com portas Receptoras ou papéis IN e que as
propriedades dos dados passados entre Portas e Papéis são idênticas ou compatíveis.
Desta forma, algumas informações relativas ao protocolo são distribuídas nos
outros elementos arquiteturais. No elemento Protocolo, definimos as propriedades. Elas
indicam a semântica e sintaxe das mensagens que transitam entre portas e papéis. Os
atributos mais genéricos são:
• Direção: Entrada ou Saída;
• Modo: Notificação ou Requisição;
• Tipo: Real, Inteiro ou String; e
• Sincronização: Síncrono, Assíncrono, Síncrono Deferido.
O esquema Z, a seguir, representa este elemento:
53

dir: DIR §
§
mode: § MODE
type: TYPE
§
Synchonize: SYNCHRONIZATION
DIR :: entry exit
TYPE :: real integer string
MODE :: reply rereply
SYNCHRONIZATION :: Synchrono Assynchrono Defered_Synchrono
¢¡ Propriedade¡¢¡¥¡¢¡¤¡¢¡¢¡¥¡¢¡¢¡¢¡£¡¦¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¦¡¤¡¢¡£¡¢¡¢¡¢¡¥¡¢¡¢¡¤¡¢¡
¡¢¡¤¡¢¡¢¡£¡¦¡¢¡£¡¢¡¢¡¢¡¢¡£¡¢¡¢¡¥¡¢¡¢¡¢¡¤¡¥¡¢¡¢¡¢¡¢¡¥¡¢¡¢¡£¡¢¡¢¡¢¡¢¡£¡¦¡¢¡¤¡¢¡
FIGURA 3-14 - Esquema Propriedade
A seguir, apresentamos a estrutura dinâmica do meta-modelo. A informação
referente a seqüência de leitura e escrita nas portas e papéis é mostrado nos diagramas
de seqüência e é retratado no diagrama de classes pelas operações de leitura e escrita
dos papéis. Esta seqüência de leitura e escrita pode ser realizada de uma das quatro
formas abaixo:
a) O papel IN lê da porta OUT e o papel OUT escreve na porta IN;
b) O papel IN lê da porta OUT e a porta IN lê do papel OUT;
c) A porta OUT escreve no papel IN e o papel OUT escreve na porta IN e;
d) A porta OUT escreve no papel IN e a porta IN lê do papel OUT.
Como nós achamos mais conveniente que o conector tenha total controle sobre a
conexão então o melhor método é o descrito pela primeira forma apresentada, a), em
que o conector verifica se há novas requisições a serem realizadas e as lê. Esta forma
oferece uma maior independência aos componentes.
3.3.2 Estrutura Dinâmica
3.3.2.1 Diagramas de Sequências
Os diagramas de seqüência foram utilizados para retratar como acontecem:
• A conexão entre componentes, retratada no diagrama de classes pela associação
denominada conexão entre portas e papéis e;
• A ligação entre conectores, retratada no diagrama de classes pela associação
recursiva denominada liga, entre papéis.
54

Considerando que, papéis IN lêem ou escrevem em portas OUT e papéis OUT
escrevem ou lêem em portas IN, como retratamos na Seção 3.3.1.8 a), a seguir
apresentamos como ocorrem as conexões quando os tipos de sincronização são
assíncrono, síncrono ou síncrono deferido.
1) Assíncrono – Neste diagrama, o Componente1 requisita um serviço a uma de suas
portas expedidoras e continua seus serviços. O Conector1 é responsável por ler esta
requisição e encaminhá-la para uma porta receptora através de seus papéis de entrada e
saída. A porta receptora, por sua vez, inicia o serviço requisitado no componente que a
contém.
Componente1 Porta_exp1 Papel IN1 Conector1 Papel OUT1 Porta_rec1 Componente2
Serviço()
Requisitar()
Serviço()
Ler(req)
Serviço()
Serviço()
Enviar()
Escrever
(req)
Receber
(req)
Serviço()
Serviço()
FIGURA 3-15 - Diagrama de seqüência para conexão assíncrona.
2) Síncrono – O modo síncrono acontece de maneira similar ao assíncrono. Entretanto,
neste caso, o componente que requisita o serviço fica bloqueado até que uma resposta
seja recebida.
Componente1 Porta_exp1 Papel IN1 Conector1 Papel OUT1 Porta_rec1 Componente2
Serviço()
Requisitar()
Ler(req)
Serviço()
Serviço()
Enviar()
Escrever
(req)
Receber
(req)
Serviço()
Receber
(resp)
Escrever
(resp)
Enviar()
Serviço() Ler(resp) Responder()
Serviço()
FIGURA 3-16 - Diagrama de seqüência para conexão síncrona.
3) Síncrono Deferido – O modo síncrono deferido é semelhante ao modo síncrono.
Entretanto, neste caso, embora o serviço requisitado necessite de uma resposta, o
componente que o requisitou continua seus serviços e recebe esta resposta em qualquer
tempo futuro.
55

Componente1 Porta_exp1 Papel IN1 Conector1 Papel OUT1 Porta_rec1 Componente2
Serviço()
Requisitar()
Serviço()
Ler(req)
Serviço()
Serviço()
Enviar()
Escrever
(req)
Receber
(req)
Serviço()
Receber
(resp)
Serviço()
Escrever
(resp)
Enviar()
Serviço() Ler(resp) Responder()
Serviço()
FIGURA 3-17 - Diagrama de seqüência para conexão síncrona.
A seguir, na FIG. 3-18, retratamos como ocorre a ligação entre papéis.
Considere que o conector N é um conector composto que agrega uma configuração que,
por sua vez, possui um conector N 1. A ligação é simplesmente um envio de requisições
de um papel de um conector para o papel de outro conector.
PapelIN1 ConectorN PapelOUT1 PapelIN2 ConectorN 1
PapelOUT2
Ler(req)
Escreve(req)
Enviar()
Serviço()
Escrever(req)
Enviar()
FIGURA 3-18 - Diagrama de seqüência para a ligação entre papéis.
3.3.2.2 Diagramas de Estados
Os diagramas de estados, a seguir, são diagramas que representam os estados da
classe Componente. De acordo com o tipo de sincronização, o componente pode
assumir um conjunto diferente de possíveis estados.
1) Comunicação Assíncrona - Os estados assumidos são Executando e Requisitando. O
componente não aguarda respostas nem responde aos serviços requisitados a ele.
Executando
Serviço
executado
Requisitando
Serviço
requisitado
FIGURA 3-19 - Diagrama de estados para conexão assíncrona.
56

2) Comunicação Síncrona - Os estados assumidos são Executando, Respondendo,
Requisitando, Aguardando e Recebendo Resposta. Neste caso, após requisitar um
serviço o componente só estará apto a executar alguma outra atividade depois de
receber uma resposta àquele serviço.
Executando
Serviço
executado
Respondendo
Serviço
requisitado
Resposta
obtida
Requisitando
Recebendo
resposta
Requisição realizada
Aguardando
FIGURA 3-20 - Diagrama de estados para conexão síncrona.
3) Comunicação Síncrona Deferida - Os estados assumidos são Executando,
Respondendo, Requisitando e Recebendo Resposta. Neste caso, o componente não
aguarda respostas mais as recebe em algum momento.
Executando
Serviço
executado
Respondendo
Serviço
requisitado
Resposta
obtida
Requisitando
Recebendo
resposta
Requisição realizada
Executando
FIGURA 3-21 - Diagrama de estados para conexão síncrona deferida.
3.3.3 Estereótipos
Através dos estereótipos, a UML permite estender os elementos de modelo que ela
define com conceitos específicos do domínio. Eles são, geralmente, formas
especializadas de algum tipo de modelo definido na UML. Através deles, o arquiteto
pode, por exemplo, trabalhar com diagramas de caixas e linhas, pois estes possuirão
sintaxe e semântica bem definidas em UML. Os estereótipos ajudam a melhor visualizar
e descrever um projeto de software.
57

Para facilitar a visualização e distinção dos elementos arquiteturais nós
definimos alguns estereótipos. Para representar:
• A classe ! Configuração usamos um pacote estereotipado com o nome , FIG. 3-22a);
• As classes Componente e ! Conector definimos retângulos menores para o
conector e maiores para os componentes. Além do tamanho, eles são
diferenciados pelos pontos de interação que possuem, portas ou papéis, FIG. 3-
22b) e c).
• A classe ! Porta_rec usamos triângulos com o vértice apontado para o
componente, FIG. 3-22 d).
• A classe ! Porta_exp usamos triângulos com a base próxima ao componente,
FIG. 3-22 e).
• A classe ! PapelIN usamos triângulos fechados com o vértice apontado para o
conector, FIG. 3-22 f).
• A classe ! PapelOUT usamos triângulos fechados com a base próxima ao
componente, FIG. 3-22 g).
a) Configuração b) Componente c) Conector
d) Porta_rec e) Porta_exp f) PapelIN g) PapelOUT
FIGURA 3-22 - Estereótipos para representação através de caixas e linhas.
Nesta seção, apresentamos um meta-modelo que denominamos meta-modelo
para modelar estilos. Este meta-modelo, pode ser utilizado como base para a criação de
arquiteturas que não seguem as restrições de nenhum estilo, como também definido pela
Visão Conceitual, ou utilizado como base para modelar estilos. Nas próximas seções,
apresentamos alguns padrões modelados segundo as características deste meta-modelo.
No ANEXO B, a especificação formal completa deste meta-modelo é apresentada.
58

3.4 Um Meta-modelo para Modelar Arquiteturas em Camadas
Para elaborar um meta-modelo para modelar arquiteturas em camadas, instanciamos o
meta-modelo apresentado na Seção 3.3, e acrescentamos as características intrínsecas a
este estilo. As características impostas pelo Estilo Camadas são características
estruturais e de interação. A seguir, apresentamos que características são estas e como
elas são incluídas no meta-modelo instanciado.
Meta-modelo para
modelar estilos
Meta-modelo para
modelar arquiteturas
em camadas
FIGURA 3-23 - Instanciação para criar um meta-modelo para modelar arquiteturas em camadas.
O vocabulário definido pelo estilo camadas é: Configuração em Camadas para
denotar Configuração e Camadas para Componentes. Os outros elementos permanecem
com o mesmo vocabulário. A seguir, definimos cada um destes elementos indicando as
restrições impostas por este estilo.
3.4.1 Estrutura Estática
3.4.1.1 Configuração em Camadas
A configuração em camadas é um agrupamento de camadas e conectores organizados
hierarquicamente. Para tanto, a organização dos componentes se baseia no sentido da
comunicação que, mais usualmente, é TopDown, ou seja, cada camada requisita
serviços das camadas mais baixas e a conexão ocorre entre camadas adjacentes.
Para fazer o controle desta hierarquia, nós relacionamos cada camada a um
determinado nível. O nível indica quais camadas são adjacentes e quais são de nível
mais baixo ou mais alto. Por exemplo, se A, B e C são camadas, podemos ter a seguinte
configuração, veja a FIG. 3-24: (A,1),(B,1),(C,2), onde a camada C está relacionada ao
nível 2 e as camadas A e B estão relacionadas ao nível 1. O estilo não faz nenhuma
59

estrição quanto a comunicação entre camadas em um mesmo nível, então pode haver
ou não comunicação entre elas. Um exemplo típico de camadas em um mesmo nível de
generalidade, são as camadas TCP e UDP na arquitetura de redes, elas implementam o
mesmo serviço de maneiras diferentes.
C
A
B
FIGURA 3-24 - Exemplo da organização de camadas.
Para gerenciar estas conexões, a configuração em camadas precisa conhecer,
além das informações conhecidas pela configuração, do meta-modelo da Seção 3.3, o
tipo de interação e a relação entre componentes e níveis.
Características da Configuração em Camadas:
• Características da Configuração;
• Conjunto de relações entre Camada e Nível;
• Define um tipo de interação – top1, que é a interação no sentido TopDown entre
camadas adjacentes.
Restrições:
• Restrições da Configuração;
• Os componentes relacionados aos níveis pertencem à configuração;
• Só há um tipo de interação que é top1; e
• Este tipo de interação estabelece que uma camada só pode está relacionada com
suas camadas adjacentes no sentido TopDown.
60

Configuração
%
tipo_interação: COMUNICAÇÃO
(
%
nível: Componentes & '
x: Componentes; y: ' -/. x0 y1 2 nível 3 x 2 comp
(,+
4 . +
x, y: Componentes - x 2 comp 5 y 2 comp 5 . x0 y1 2 comp_comp
(
COMUNICAÇÃO ::" top1
#¢$ Configuração_Camadas $¢$¢$¢$¢$£$¢$¤$¢$¢$¢$¢$£$¢$¦$¥$¤$¢$¢$¢$£$¢$¦$£$¢$¤$¢$¦$
)¢*¢*¤*¢*¢*£*¦*¢*£*¢*¢*¢*¢*£*¢*
3 nível x = nível y + 11 (
6¢*¢*¤*¢*¢*£*¦*¢*£*¢*¢*¢*¢*£*¢*¢*¥*¢*¢*¢*¤*¥*¢*¢*¢*¢*¥*¢*¢*£*¢*¢*¢*¢*£*¦*¢*¤*¢*
FIGURA 3-25 - Esquema Configuração_camadas.
(
tipo_interação = top1
3.4.1.2 Camadas
Assim como os componentes da configuração, na Seção 3.3, as camadas são as
entidades provedoras e solicitadoras de serviços no sistema. Elas herdam todos as
características dos Componentes e não acrescentam ou modificam nenhuma
característica ou restrição. Apenas o vocabulário utilizado para componentes é
modificado, emprega-se o nome Camadas para denotá-los.
Entretanto, uma característica intrínseca às camadas é que, normalmente, elas
são componentes de alta granularidade que devem, em momentos posteriores do design,
ser refinados. Assim, uma camada, geralmente, contém alguma configuração interna,
híbrida ou padronizada. Os componentes do meta-modelo, na Seção 3.3, dão suporte a
esta característica.
Assim como as camadas, as portas, os conectores, os papéis e o protocolo se
comportam de maneira idêntica aos elementos anteriormente apresentados na Seção 3.3.
No ANEXO B, apresentamos a especificação completa deste meta-modelo.
A seguir, na FIG. 3-26, apresentamos a estrutura estática do meta-modelo aqui
definido. Nesta figura, utilizamos a cor preta para destacar as alterações que foram
realizadas no meta-modelo apresentado na Seção 3.3.3, para que ele dê suporte a
especificação arquiteturas em camadas; e a cor cinza para representar o próprio metamodelo
da Seção 3.3.3.
61

Configuração
1
Conjunto de Componentes
Conjunto de Conectores
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Comp-Comp
Nível
Tipo_interação
1
*
Componentes
Id_com
Conjunto de Serv_req
Conjunto de Serv_ofer
Conjunto de Porta_rec
Conjunto de Porta_exp
Conf
Serviço()
Requisitar()
Responder()
1
*
Porta
1
1
* conexão *
*
*
obedece
obedece
1
1 *
Conectores
Id_con
Conjunto de PapelIn
Conjunto de PapelOUT
Conjunto de pares Port_rec-PapOUT
Conjunto de pares Port_exp-PapIN
Conjunto de pares Pap-pap
Conf
Serviço()
Enviar()
1
*
Papel
*
*
liga
{ou}
{ou}
Porta_rec
Id_rec
Serv-Ofer
Propr
Receber(req)
Responder()
Porta_exp
Id_exp
Serv_req
Propr
Requisitar()
Receber(resp)
1 1
Protocolo
Papel IN
Id_in
Propr
Porta_exp
PapelOUT
Ler(req)
Escrever(resp)
Papel OUT
Id_out
Propr
Porta_rec
PapelIN
Ler(resp)
Escrever(req)
FIGURA 3-26 - Estrutura estática do meta-modelo para modelar arquiteturas de software em
camadas.
3.4.2 Estrutura Dinâmica
A estrutura dinâmica deste meta-modelo é idêntica a descrição oferecida na Seção 3.3.
A seguir, oferecemos algumas variações do estilo camadas, quanto ao modo de
interação.
62

3.4.3 Variações do Estilo Camadas
Como definimos na Seção 2.1.1.1, o estilo camadas pode se apresentar de maneira
diferenciada da maneira convencional. Estas variações ocorrem, principalmente, com
relação ao tipo de interação existente entre as camadas. Além de TopDown entre
camadas adjacentes, as interações podem ocorrer no sentido BottomUp ou em ambos os
sentidos e entre camadas não-adjacente ou em ambos. Assim temos um total de 6 tipos
de interações passíveis de ocorrer: Camadas adjacentes-BottomUp, Camadas adjacentes-
TopDown, Camadas adjacentes-BottomUp-TopDown, Camadas não-adjacentes-
BottomUp, Camadas não-adjacentes-TopDown, Camadas não-adjacentes-BottomUp-
TopDown.
Assim como mostrado na Seção 3.4.1, o único elemento que sofre alterações no
meta-modelo é o elemento Configuração, neste caso Configuração em Camadas, onde
adicionamos estas outras maneiras de interação. A estrutura estática e dinâmica,
representadas pelos diagramas da UML, não sofrem nenhuma alteração, visto que estes
diagramas não representam estas informações tão detalhadamente como os esquemas Z.
De maneira idêntica ao que definimos na Seção 3.4.1, para dar suporte a estes tipos de
interação, a configuração em camadas possui as seguintes características e restrições
adicionais:
Características da Configuração em Camadas:
• Características da Configuração;
• Conjunto de relações entre Camada e Nível; e
• Define um tipo de interação – top1,top1, top2, topbot1, topbot2, bot1, bot2.
Restrições:
• Restrições da Configuração;
• Os componentes relacionados aos níveis pertencem à configuração;
• Há seis tipos de interação:
• O top1 estabelece que uma camada só pode estar relacionada com suas camadas
adjacentes no sentido TopDown;
• O bot1 estabelece que uma camada só pode estar relacionada com suas camadas
adjacentes no sentido BottomUp;
63

Configuração
(
tipo_interação: COMUNICAÇÃO
(
(
nível: Componentes & '
( 4 . +
x, y: Componentes - x 2 comp 5 y 2 comp 5 . x0 y1 2 comp_comp
( 4 . +
x, y: Componentes - x 2 comp 5 y 2 comp 5 . x0 y1 2 comp_comp
( 4 . +
x, y: Componentes - x 2 comp 5 y 2 comp 5 . x0 y1 2 comp_comp
( 4 . +
x, y: Componentes - x 2 comp 5 y 2 comp 5 . x0 y1 2 comp_comp
( 4 . +
x, y: Componentes - x 2 comp 5 y 2 comp 5 . x0 y1 2 comp_comp
• O topbot1 estabelece que uma camada só pode estar relacionada com suas
camadas adjacentes no sentido TopDown e BottomUp;
• O top2 estabelece que uma camada pode estar relacionada com suas camadas
adjacentes ou não- adjacentes no sentido TopDown;
• O bot2 estabelece que uma camada pode estar relacionada com suas camadas
adjacentes ou não- adjacentes no sentido BottomUp; e
• O topbot2 estabelece que uma camada pode estar relacionada com suas camadas
adjacentes ou não- adjacentes no sentido TopDown e BottomUp.
Esquema Z:
::7 COMUNICAÇÃO 8 top1 8 top2 8 topbot1 8 bot1 8 bot2
9 * topbot2
Configuração_Camadas *¢*¢*¢*¢*£*¢*¤*¢*¢*¢*¢*£*¢*¦*¥*¤*¢*¢*¢*£*¢*¦*£*¢*¤*¢*¦*
)¢*¢*¤*¢*¢*£*¦*¢*£*¢*¢*¢*¢*£*¢*
x: Componentes; y: ' -/. x0 y1 2 nível 3 x 2 comp
(
(,+
tipo_interação = bot1 .
3 nível x = nível y - 111 (;:
(
tipo_interação = topbot1 .
3 nível x = nível y + 1 nível x = nível y - 111 (
. tipo_interação = topbot2
(;:
3 nível x ? nível y11 (
. tipo_interação = top2 (
(;:
. +
x, y: Componentes - x 2 comp 5 y 2 comp 5 . x0 y1 2 comp_comp
4
3 nível x @ nível y1>1 (
6¢*¢*¤*¢*¢*£*¦*¢*£*¢*¢*¢*¢*£*¢*¢*¥*¢*¢*¢*¤*¥*¢*¢*¢*¢*¥*¢*¢*£*¢*¢*¢*¢*£*¦*¢*¤*¢*
FIGURA 3-27 - Esquema Configuração_Camadas.
Nesta Seção, apresentamos um meta-modelo para modelar arquiteturas em
camadas. Este meta-modelo é uma instância do meta-modelo apresentado na Seção 3.3.
As restrições, quanto a estrutura e interação, impostas pelo estilo camadas foram
adicionadas a esta instância. O meta-modelo tem a função de retratar e assim, facilitar a
64

modelagem de arquiteturas que possam ser estruturadas em camadas. No ANEXO C,
apresentamos a especificação completa em Z.
65

3.5 Um Meta-modelo para Modelar Aplicações Baseadas em CORBA
Para elaborar um meta-modelo para modelar aplicações baseadas em CORBA,
instanciamos o meta-modelo apresentado na Seção 3.3 (meta-modelo para modelar
estilos) e acrescentamos as características que CORBA impõe às aplicações que o
utilizam, como na FIG. 3-28. As características impostas por CORBA são
características estruturais e de interação. A seguir, apresentamos que características são
estas e como elas podem ser incluídas no meta-modelo instanciado.
Meta-modelo para
modelar estilos
Meta-modelo para
modelar aplicações
baseadas em CORBA
FIGURA 3-28 - Instanciação para criar um meta-modelo para modelar aplicações baseadas em
CORBA.
Como apresentamos na Seção 2.3, CORBA é um padrão para implementação,
mas ele afeta algumas decisões arquiteturais. CORBA impõe:
• Os tipos de sincronização, que devem ser Síncrono, Assíncrono ou Síncrono
Deferido;
• O tipo de comunicação ocorre, basicamente, através da chamada de
procedimento, visto que este padrão é baseado no paradigma de orientação a
objetos;
• Uma estrutura não hierárquica, onde o ORB intermedia qualquer
comunicação;
• Exige que os componentes servidores da aplicação possuam uma interface
escrita na linguagem IDL e que estes componentes divulguem estas
interfaces.
Assim, dependendo das características da arquitetura a ser construída, a decisão
de utilizar CORBA como plataforma de middleware, pode fazer com que a
implementação gerada não seja condizente com a arquitetura elaborada, pois os tipos de
66

comunicação e estruturas podem ser incompatíveis. A seguir, apresentamos a estrutura
estática do Meta-modelo para modelar aplicações baseadas em CORBA.
3.5.1 Estrutura Estática
Em um nível arquitetural, podemos representar CORBA como um componente da
arquitetura ou como um conector da arquitetura, visto que ele tem a função específica
de realizar a comunicação entre componentes num ambiente distribuído e heterogêneo.
Seja um componente ou um conector, CORBA é um elemento composto cuja
configuração interna contém os elementos definidos na Seção 2.3.3, FIG. 2-8,
Repositórios, ORB e Interfaces. Nesta configuração, o cliente e a implementação de
objeto representam os componentes que requisitam e oferecem serviços no metamodelo,
respectivamente. Nas seções seguintes, nós apresentamos estas duas
abordagens e mostramos as vantagens e desvantagens de cada uma delas.
3.5.1.1 CORBA como um Conector da Arquitetura
Como CORBA intermedia todas as interações entre os componentes da aplicação, e
possui a função específica de realizar a comunicação entre componentes num ambiente
distribuído e heterogêneo, então, na arquitetura, ele pode ser representado por um
conector entre estes componentes. As restrições impostas nesta abordagem são:
• Os conectores assumem o tipo definido pelo padrão CORBA, ou seja, teremos
conectores CORBA;
• O conector CORBA possui um papel de entrada responsável por ler as
requisições de registro nas portas dos componentes que desejam divulgar seus
serviços e iniciar o próprio registro;
• Para disponibilizar suas interfaces cada componente deve possuir uma porta
expedidora que interage com o conector CORBA para divulgar os serviços que
aquele componente está apto a oferecer.
Como exemplo, veja a FIG. 3-29, onde nós utilizamos os estereótipos definidos
na Seção 3.3.3. Nesta figura, os servidores A, B e C, através de alguma de suas portas
expedidoras, registram seus serviços no conector CORBA 1, CORBA 2 e CORBA 3,
respectivamente. Um cliente A pode requisitar estes serviços através de uma requisição
67

interceptada pelo conector CORBA 1 e CORBA 2. O conector CORBA 2 publica
serviços no conector CORBA 3, possibilitando, desta maneira, a requisição destes
serviços pelo Cliente B.
Configuração: Conf_CORBA
Cliente A
2
CORBA 1
CORBA 2
2
1
1
Servidor A
Servidor B
1
Cliente B
CORBA 3
2
1
Servidor C
1 - Publicação de serviço
2 - Requisição de serviço
FIGURA 3-29 - Exemplo de arquitetura em que CORBA é um conector.
Na FIG. 3-30, apresentamos a estrutura estática para esta abordagem. Nesta
figura, utilizamos o mesmo esquema de cores utilizado na Seção 3.4.1.2.
68

Configuração_CORBA:Configuração
Conjunto de Componente_C
Conjunto de Conectores_C
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Com-Com
1 1
*
Componentes_C
Id_com
Conjunto de Serv_req
Conjunto de Serv_ofer
Conjunto de Porta_rec
Conjunto de Porta_exp
Conjunto de Porta_div
Conf
Serviço()
Requisitar()
Responder()
1
*
Porta
1
1
* conexão *
* *
obedece
Serviço()
Enviar()
obedece
*
Conectores_C
1
1
Id_con
Conjunto de PapelIn
Conjunto de PapelOUT
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto de pares Pap-pap
Conf
1
*
Papel
*
*
liga
{ou}
{ou}
Porta_div
Interfaces IDL
Receber(req)
Registrar(interface)
Porta_rec
Id_rec
Serv-Ofer
Propr
Receber(req)
Responder()
Porta_exp
Id_exp
Serv_req
Propr
Requisitar()
Receber(resp)
1 1
Protocolo
Papel IN_C
Id_in
Propr
Porta_exp
Porta_div
PapelOUT
Ler(req)
Escrever(resp)
Papel OUT
Id_out
Propr
Porta_rec
PapelIN
Ler(resp)
Escrever(req)
FIGURA 3-30 - Estrutura estática do meta-modelo para modelar aplicações baseadas no
middleware CORBA.
A seguir, explicamos cada um dos elementos da FIG. 3-30 e oferecemos as
restrições impostas por eles. A linguagem de especificação Z é utilizada para descrever
estes elementos.
3.5.1.1.1 Configuração_CORBA
A configuração_CORBA é idêntica a configuração definida na Seção 3.3. O
vocabulário a ser utilizado é o mesmo com exceção do conector que o denominamos de
69

C
port_pap3: Porta_div D PapelIN
C
C
C
C
C
C
C
Conectores_C e do componente que o denominamos de Componentes_C. Os atributos
adicionados à configuração definida na Seção 3.3 são:
• Conjunto de relações entre Porta divulgadora e Papel de entrada.
Restrições
• Todas as relações entre Porta_divulgadora e PapelIN existentes na configuração
pertencem ao conjunto de relações entre Porta_divulgadora e PapelIN de algum
conector pertencente à configuração e a porta pertence a qualquer componente
da configuração; e
• Para todos os pares Comp-Comp, o segundo componente deve ter uma porta
divulgadora que registrou o serviço que o componente está oferecendo.
O esquema Z, a seguir, representa este elemento com seus atributos e restrições.
A¢B Configuração_CORBA B¤B¢B¢B¢B¢B£B¢B¢B¢B¥B¤B¢B¢B¢B¥B¢B¢B¢B£BB£B¦B¢B£B¢B¢B¥B¢B
C
Configuração
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B E
F x: Porta_div; y: PapelIN | (x, y) G port_pap3
C
H I cp: Componentes; cn: Conectores | cp G comp J cn G con
C
H (x, y) G cn . port_pap3 J x G cp . div_port
C F x, y: Componentes | x G comp J y G comp J (x, y) G comp_comp
p: PapelIN; j: Porta_div
| (l, G n) k . port_pap1
(m, o) G k . port_pap2 J
(j, p) G k . port_pap3
H (l G y . in_port J m G x . out_port J j G y . div_port))
J
H I z, w: SERVICO | z G x . serv_req J w G y . serv_ofer
C
z = w C H
(I k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT; o,
J
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B¢B¥B¢B¢B¢B¤B¥B¢B¢B¢B¢B¥B¢B¢B£B¢B¢B¢B¢B£B¦B¢B¤B¢B
K
FIGURA 3-31 - Esquema da Configuração_CORBA.
3.5.1.1.2 Componentes_C
Os componentes possuem portas receptoras e expedidoras idênticas as definidas na
Seção 3.3. Porém, para disponibilizar os serviços que estão aptos a oferecer, estes
componentes possuem uma porta expedidora responsável por este serviço. Nós
denominamos esta porta de porta divulgadora. As características deste elemento são:
• Características dos Componentes;
• Conjunto de portas divulgadoras (através da agregação)
70

C
div_port: L Porta_div
Porta_exp
C
interface: INTERFACE
C
As restrições impostas a este atributo são:
• As restrições dos Componentes; e
• Não há duas instâncias de portas divulgadoras com o mesmo identificador;
Os esquemas Z, a seguir, representam estes elementos com seus atributos e restrições:
A¢B Componentes_CB¢B¢B¢B£BB£B¢B¦B£B¢B¢B¢B¢B£B¢B¢B¢B¥B¦B£B¢B¤B¢B¢B¢B¥B¢B¢B¢B
C
Componentes
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B C
E
c1, c2: Porta_div M c1 G div_port J c2 G div_port
C F
c1 . id_port_exp = c2 . id_port_exp N c1 = c2
H
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B¢B¥B¢B¢B¢B¤B¥B¢B¢B¢B¢B¥B¢B¢B£B¢B¢B¢B¢B£B¦B¢B¤B¢B
K
FIGURA 3-32 - Esquema do Componente CORBA.
A porta divulgadora é idêntica a uma porta expedidora. Ela possui um
identificador e é responsável por registrar as interfaces IDL no conector CORBA.
Assim, ela possui o atributo interface, como mostramos na FIG. 3-30 e no esquema a
seguir (FIG. 3-33). A operação que ela realiza é mostrada abaixo:
• Registrar(serviço) {IDL = serviço;}
A¢B Porta_divB¢B¢B¢B¢B£B¢B¦B£B¢B¤B¢B¦B£B¢B¢B¢B¥B¤B¢B¢B¢B¥B¢B¢B¢B£B¢B¤B¦B¢B£B¢B¢B
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B¢B¥B¢B¢B¢B¤B¥B¢B¢B¢B¢B¥B¢B¢B£B¢B¢B¢B¢B£B¦B¢B¤B¢B
K
FIGURA 3-33 - Esquema da Porta Divulgadora.
As portas receptoras e expedidoras não sofrem nenhuma alteração, elas são
como apresentamos na Seção 3.3.
3.5.1.1.3 Conectores_C
Os conectores e seus papéis são idênticos aos definidos na Seção 3.3 com exceção da
adição do conjunto de relações entre as portas divulgadoras e papéisIN, no conector e
no PapelIN. Contudo, este conector encapsula todos os componentes definidos pela
arquitetura CORBA, como mostramos na Seção 2.3.3, FIG. 2-8. A seguir, apresentamos
os esquemas Conectores_C e PapelIN_C.
71

port_pap3: Porta_div D PapelIN
C
F x: Porta_div; y: PapelIN MPO xQ yR G port_pap3 H y G in_pap
C
port_div: L Porta_div
C
F x: Porta_div M x G port_div H x . propr = propr
C
A¢B Conectores_C B¤B¢B¢B¢B¢B¥B¢B¢B£BB¥B¢B¢B£B¢B¦B£B¢B¤B¦B¢B£B¢B¢B¢B¢B¥B¤B¢B
C
Conectores
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B¢B¥B¢B¢B¢B¤B¥B¢B¢B¢B¢B¥B¢B¢B£B¢B¢B¢B¢B£B¦B¢B¤B¢B
K
FIGURA 3-34 - Esquema Conectores_C.
E B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B
A¢B PapelIN_CB¢B¢B¢B¢B£B¢B¢B¢B¢B£B¢B¢B¥B¢B¢B¤B¦B£B¢B¢B¥B¢B¢B¢B¤B¢B¢B¥B¢B
C
PapelIN
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B¢B¥B¢B¢B¢B¤B¥B¢B¢B¢B¢B¥B¢B¢B£B¢B¢B¢B¢B£B¦B¢B¤B¢B
K
FIGURA 3-35 - Esquema PapelIN_C.
E B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B
No Anexo D apresentamos a especificação completa para esta abordagem.
3.5.1.2 CORBA como um Componente da Arquitetura
CORBA pode ser representado por um componente na arquitetura. Esta é uma tendência
quando se modela uma aplicação baseada em CORBA. Neste caso, para um
componente interagir com outro ele interage com um componente CORBA e este com o
componente final da interação. Neste caso, há algumas restrições impostas quanto à
estrutura e à interação:
• Há dois tipos de componentes, um componente da aplicação e um componente
CORBA;
• Os conectores realizam a comunicação entre componentes da aplicação e
componentes CORBA ou entre componentes CORBA, neste último caso os
conectores são, geralmente, denominados de ponte (Bridge);
• A estrutura é similar a uma estrela em que o componente CORBA se encontra
intermediando todas as interações; e
• Para disponibilizar suas interfaces cada componente deve possuir uma porta
expedidora que interage com CORBA para divulgar os serviços que aquele
componente está apto a oferecer.
Como exemplo veja a FIG. 3-36. Nesta figura, o servidor A, através de alguma
de suas portas expedidoras, registra os serviços que está apto a oferecer no componente
72

CORBA 1. O componente CORBA 1 pode também registrar os serviços que foram
registrados nele em um outro componente CORBA. Os clientes A e B podem requisitar
estes serviços através de uma requisição ao componente CORBA 1 e CORBA 2,
respectivamente, ou seja CORBA representa o componente servidor destes serviços.
Utilizamos as denominações cliente e servidor para denotar os componentes da
aplicação, lembrando que eles podem desempenhar ambos os papéis: cliente quando
requisita serviços e servidor quando oferece serviços.
Configuração: Conf_CORBA
2 2
Cliente A CORBA 1 Servidor A
1
1
Cliente B
2
CORBA 2
1 - Publicação de serviço
2 - Requisição de serviço
FIGURA 3-36 - Exemplo de arquitetura em que CORBA é um componente.
Na FIG. 3-37 apresentamos a estrutura estática para esta abordagem. O mesmo
esquema de cores definido na seção anterior é utilizado.
73

Configuração_CORBA: Configuração
1
Conjunto de Comp da Aplicação
Conjunto de Comp CORBA
Conjunto de Conectores
Conjunto de Pontes
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Comp-Corb
Conjunto dos pares Corb-Comp
Conjunto dos pares Corb-Corb
1
Comp_CORBA
Conjunto de Porta_div
Comp_da aplicação
Conjunto de Porta_div
{ou}
*
Componentes
Id_com
Conjunto de Serv_req
Conjunto de Serv_ofer
Conjunto de Porta_rec
Conjunto de Porta_exp
Conf
Serviço()
Requisitar()
Responder()
1
*
Porta
1
1
Serviço()
Enviar()
* conexão *
* *
obedece
obedece
1
1 *
Conectores
Id_con
Conjunto de PapelIn
Conjunto de PapelOUT
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto de pares Pap-pap
Conf
1
*
Papel
*
*
liga
Ponte
{ou}
{ou}
Porta_div
Interfaces IDL
Receber(req)
Registrar(interface)
Porta_rec
Id_rec
Serv-Ofer
Propr
Receber(req)
Responder()
Porta_exp
Id_exp
Serv_req
Propr
Requisitar()
Receber(resp)
1 1
Protocolo
Papel IN
Id_in
Propr
Porta_exp
Porta_div
PapelOUT
Ler(req)
Escrever(resp)
Papel OUT
Id_out
Propr
Porta_rec
PapelIN
Ler(resp)
Escrever(req)
FIGURA 3-37 - Estrutura estática do meta-modelo para modelar aplicações baseadas no
middleware CORBA.
A seguir, explicamos cada um dos elementos da FIG. 3-37 e oferecemos as
restrições impostas por eles. A linguagem de especificação Z é utilizada para descrever
estes elementos.
3.5.1.2.1 Configuração_CORBA
A configuração_CORBA possui dois tipos de componentes, os componentes da
aplicação (ou simplesmente componentes) e os componentes CORBA. Embora eles não
estejam apresentando nenhuma diferença quanto aos atributos e operações, eles são
74

componentes bastante distintos semanticamente. A comunicação entre componentes
ocorre sempre entre um componente da aplicação e um componente CORBA, ou entre
componentes CORBA, neste último caso o vocabulário utilizado é Ponte para denotar o
conector que realiza esta comunicação. A estrutura imposta por esta configuração é
centralizada nos componentes CORBA. Os atributos adicionados e modificados à
configuração definida na Seção 3.3 são:
• Conjunto de componentes CORBA (através da agregação);
• Conjunto de conectores ponte (através da agregação);
• Conjunto de pares Corb-Corb;
• Conjunto de pares Comp-Corb;
• Conjunto de pares Corb-Comp; e
• Conjunto de relações entre portas divulgadoras e papéis de entrada (através da
agregação).
As restrições impostas a estes elementos são:
• Em uma configuração não existem dois Componentes CORBA com o mesmo
identificador;
• Em uma configuração não existem dois Conectores Ponte com o mesmo
identificador;
• Para todas as relações entre Componentes, Comp-Corb e Corb-Comp:
o Os Componentes pertencem à configuração e um deles é um componente
da aplicação e o outro um componente CORBA;
o O primeiro componente da relação requisita um serviço e o segundo
oferece este serviço, ou seja, as semânticas destes serviços são iguais; e
o Existe pelo menos um conector com seus papéis ligados as portas destes
Componentes;
• Para todas as relações entre Componentes, Corb-Corb:
o Os Componentes pertencem ao conjunto de componentes CORBA da
Configuração_CORBA;
o O primeiro Componente requisita um serviço e o segundo oferece este
serviço, ou seja, as semânticas destes serviços são iguais;
o Existe pelo menos um conector ponte com seus papéis ligados as portas
destes Componentes; e
75

C
corb_corb: Comp_CORBA D Comp_CORBA
C
C
C
C
C
C
C
• Todas as relações entre portas divulgadoras e papéis de entrada existentes na
configuração pertencem ao conjunto de relações entre Porta_divulgadora e Papel
de entrada de algum conector pertencente à configuração e a porta pertence a
algum componente de aplicação da configuração.
Como modificamos o vocabulário utilizado para os componentes da aplicação e
modificamos, também, a maneira em que os componentes estão relacionados, então
reescrevemos o esquema Z para este elemento e o apresentamos a seguir.
Configuração_CORBA B¤B¢B¢B¢B¢B£B¢B¢B¢B¥B¤B¢B¢B¢B¥B¢B¢B¢B£BB£B¦B¢B£B¢B¢B¥B¢B
CA¢B L comp: C Comp_da_aplicação
L corb: C Comp_CORBA
L con: C Conectores
port_pap1: D Porta_rec C PapelOUT
port_pap2: D Porta_exp C PapelIN
port_pap3: D Porta_div C PapelIN
pap_pap: D PapelIN C PapelOUT
corb_comp: D Comp_CORBA Comp_da_aplicação
C
comp_corb: Comp_da_aplicação D Comp_CORBA
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B C
E
c1, c2: Comp_da_aplicação M c1 G comp J c2 G comp
C F
c1 . id_comp = c2 . id_comp N c1 = c2
C H
c1, c2: Comp_CORBA M c1 G corb J c2 G corb
C H c1 . id_comp = c2 . id_comp N c1 = c2
F
F c1, c2: Conectores M c1 G con J c2 G con
C
C
c1 . id_con = c2 . id_con N c1 = c2
C F x: Comp_da_aplicação M x G comp
H
HI z: Comp_CORBA M z G corb HSO zQ xR G corb_comp T O xQ zR G comp_corb
C
F x: Porta_rec; y: PapelOUT MUO xQ yR G port_pap1
C
C
cp: Comp_da_aplicação; cn: Conectores M cp G comp J cn G con
HI
HO xQ yR G cn . port_pap1 J x G cp . in_port
F x: Porta_exp; y: PapelIN MUO xQ yR G port_pap2
C
C
cp: Comp_da_aplicação; cn: Conectores M cp G comp J cn G con
HI
HO xQ yR G cn . port_pap2 J x G cp . out_port
F x: Porta_div; y: PapelIN MPO xQ yR G port_pap3
C
HI cp: Comp_da_aplicação; cn: Conectores M cp G comp J cn G con
C
HO xQ yR G cn . port_pap3 J x G cp . div_port
F x: PapelIN; y: PapelOUT MPO xQ yR G pap_pap
C
HI z, w: Conectores M z G con J w G con
C
H x G z . in_pap J y G w . out_pap J w . id_con V z . id_con
C F x: Comp_CORBA; y: Comp_da_aplicação
C HI z, w: SERVICO M z G x . serv_req J w G y . serv_ofer
z = w H
o, p: PapelIN; q: Porta_div
J OI k, j: Conectores; l, r: Porta_rec; m: Porta_exp; n, s: PapelOUT;
C M x G corb J y G comp J O xQ yR G corb_comp
76

C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
C
lQ nR G k . port_pap1 MPO
O mQ oR G k . port_pap2 J
O qQ pR G j . port_pap3
J O rQ sR G j . port_pap1
J
l G y . in_port HO
m G x . out_port
J q G y . div_port
J
J r G x . in_portRR
C F x: Comp_da_aplicação; y: Comp_CORBA
C HI z, w: SERVICO M z G x . serv_req J w G y . serv_ofer
OI k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT;
J
o: MUO lQ nR G PapelIN k . J O mQ oR G port_pap1 k . port_pap2
H z = w
C M x G comp J y G corb J O xQ yR G comp_corb
HO l G y . in_port J m G x . out_portRR
C HI z, w: SERVICO M z G x . serv_req J w G y . serv_ofer
OI k, j: Conectores; l, r: Porta_rec; m: Porta_exp; n, s: PapelOUT;
J
o, p: PapelIN; q:
MPO lQ nR G
Porta_div
k . port_pap1
H z = w
O mQ oR G k . port_pap2 J
O qQ pR G j . port_pap3
J O rQ sR G j . port_pap1
J
l G y . in_port HO
m G x . out_port
J q G y . div_port
J
C F x, y: Comp_CORBA M x G corb J y G corb J O xQ yR G corb_corb
B¢B¤B¢B¢B£B¦B¢B£B¢B¢B¢B¢B£B¢B¢B¥B¢B¢B¢B¤B¥B¢B¢B¢B¢B¥B¢B¢B£B¢B¢B¢B¢B£B¦B¢B¤B¢B
K
FIGURA 3-38 - Esquema da Configuração_CORBA.
J r G x . in_portRR
3.5.1.2.2 Componente
Os componentes podem assumir um dos dois tipos: CORBA ou da aplicação. Em
ambos os casos, os componentes possuem portas receptoras e expedidoras idênticas as
definidas na Seção 3.5.1.1.2. O esquema destes componentes são iguais, no nível de
abstração que estamos trabalhando. Entretanto, como dissemos antes, eles possuem
semânticas bastante diferentes.
As portas expedidoras e receptoras não sofrem nenhuma alteração ao que foi
definido na Seção 3.3. A porta divulgadora adicionada, também, nesta abordagem é
igual a definidas na Seção 3.5.1.1.2.
77

3.5.1.2.3 Conectores
Os conectores, as pontes e os seus respectivos papéis são idênticos aos definidos na
Seção 3.3. No ANEXO E apresentamos a especificação completa para esta abordagem.
3.5.1.3 CORBA como Conector X CORBA como Componente
A duas abordagens apresentadas nas Seções 3.5.1.1 e 3.5.1.2 representam diferentes
maneiras de modelar a arquitetura de aplicações que utilizam CORBA. Nestas duas
abordagens, CORBA impõe características diferentes à estrutura da configuração e à
maneira de interação entre os componentes.
Como vimos na Seção 3.5.1.1, modelar CORBA como um conector da
arquitetura exige:
• Tal como na abordagem anterior, a definição de uma porta, que nós
denominamos de porta divulgadora, responsável por requisitar a um conector
CORBA que um serviço seja publicado e, assim, tornado disponível.
• A definição de conectores CORBA, que foi realizada simplesmente pela
mudança no vocabulário utilizado. Embora nós tenhamos assumido que o
conector CORBA possui a mesma sintaxe dos conectores definidos na Seção
3.3.3, em níveis mais detalhados do design este conector se apresenta
diferentemente. Internamente ele é definido pelos elementos apresentados na
Seção 2.3.3, FIG. 2-8, e trata de toda a complexidade inerente a comunicação
entre componentes distribuídos e heterogêneos.
Por sua vez, como vimos na Seção 3.5.1.2, modelar CORBA como um
componente da arquitetura exige:
• A distinção entre componentes da aplicação e componentes CORBA. Pois os
componentes CORBA são aqueles cuja função é intermediar a comunicação.
Sendo assim, o componente CORBA é o componente servidor das requisições
dos componentes da aplicação, e é o componente cliente quando ele interage
com um componente em busca de um serviço que foi antes publicado nele
mesmo.
78

• A definição de uma porta, que nós denominamos de porta divulgadora,
responsável por requisitar a um componente CORBA que um serviço seja
publicado e, assim, tornado disponível.
• A distinção entre conectores e pontes. As pontes são conectores específicos para
a comunicação entre componentes CORBA. Embora nós tenhamos assumido
que o conector ponte possui a mesma sintaxe dos conectores definidos na Seção
3.3.3, em níveis mais detalhados do design este conector pode se apresentar
diferentemente. Porém este não é nosso objeto de estudo.
• Que a estrutura seja centralizada, em que um componente CORBA intermedia
todas as interações. Isto exige que a arquitetura da aplicação possa ser
igualmente estruturada.
Na TAB. 3-1, apresentamos um resumo destas características.
TABELA 3-1
CORBA como conector X CORBA como componente.
Conector_CORBA Componente_CORBA
Estrutura - Estrutura centralizada
Componente - Da aplicação e CORBA
Conector CORBA Conector e Ponte
Portas Porta divulgadora Porta divulgadora
Papéis - -
A primeira abordagem, exige menos restrições e são de menor impacto ao Metamodelo
para modelar estilos. Tendo em vista a necessidade de maior flexibilidade nos
meta-modelos, para que eles possam acomodar características de outros padrões, nós
adotamos a primeira abordagem. Há uma tendência recente em tratar os middlewares
como conectores [12][14][15]. Tratá-los como componentes acrescenta um nível de
indireção na arquitetura, pois é necessário definir um outro conector para ligar o
middleware aos componentes. Na Seção 3.5.2, apresentamos a estrutura dinâmica da
abordagem adotada.
79

3.5.2 Estrutura Dinâmica
Como discutimos na Seção 3.5.1.3, a abordagem apresentada na Seção 3.5.1.1 é a mais
adequada para os propósitos desta dissertação. A seguir, apresentamos a estrutura
dinâmica para esta abordagem.
3.5.2.1 Diagramas de Sequências
A seqüência de interações ocorre de maneira similar ao que apresentamos na
Seção 3.3.2.1. Entretanto, quando se utiliza CORBA os componentes que oferecem
serviços precisam divulgar estes serviços no conector CORBA, para torná-los
disponíveis aos clientes. A seguir, apresentamos como ocorrem as conexões quando os
tipos de sincronização são assíncrono, síncrono ou síncrono deferido.
1) Assíncrono
Cliente Porta_exp1 Papel IN
Conector_
CORBA
Papel OUT
Porta_rec
Porta_div
Servidor
Serviço()
Serviço()
Serviço()
Serviço()
Ler(req)
registrar(IDL)
Requisitar()
Serviço()
Ler(req)
Serviço()
Serviço()
Enviar()
Escrever
(req)
Receber
(req)
Serviço()
2) Síncrono
FIGURA 3-39 - Diagrama de seqüência para conexão assíncrona.
Cliente Porta_exp1 Papel IN
Conector_
CORBA
Papel OUT
Porta_rec
Porta_div
Servidor
Serviço()
Serviço()
Serviço()
Ler(req)
registrar(IDL)
Serviço()
Requisitar()
Ler(req)
Serviço()
Serviço()
Enviar()
Escrever
(req)
Receber
(req)
Serviço()
Receber
(resp)
Escrever
(resp)
Enviar()
Serviço()
Serviço()
Ler(resp)
Responder()
FIGURA 3-40 - Diagrama de seqüência para conexão síncrona.
80

3) Síncrono Deferido
Cliente Porta_exp1 Papel IN
Conector_
CORBA
Papel OUT
Porta_rec
Porta_div
Servidor
Serviço()
Serviço()
Serviço()
Ler(req)
registrar(IDL)
Serviço()
Requisitar()
Serviço()
Ler(req)
Serviço()
Serviço()
Enviar()
Escrever
(req)
Receber
(req)
Serviço()
Receber
(resp)
Escrever
(resp)
Enviar()
Serviço()
Serviço()
Ler(resp)
Responder()
FIGURA 3-41 - Diagrama de seqüência para conexão síncrona.
Nesta Seção, apresentamos duas abordagens de meta-modelo para modelar
aplicações que utilizam CORBA, considerar CORBA como um conector ou como um
componente da arquitetura. CORBA impõe algumas restrições arquiteturais, a maneira
como utilizá-lo na arquitetura também revela algumas restrições. Assim, a integração de
CORBA ao projeto de um sistema deve ser realizada em fases iniciais da arquitetura
pois, realizá-la durante a implementação, por pessoas com visão somente de
implementação, pode afetar completamente a arquitetura antes definida.
A seguir, na Seção 3.6, apresentamos um meta-modelo para modelar arquiteturas
em camadas e que utilizam CORBA. Para isto, adotamos a abordagem de CORBA
como um conector na arquitetura. A seguir, apresentamos porque tomamos esta decisão.
81

3.6 Um Meta-modelo para Modelar uma Família de Aplicações
Distribuídas
Para elaborar um meta-modelo para a modelagem de arquiteturas em camadas de
aplicações baseadas em CORBA, nós instanciamos os meta-modelos apresentados nas
Seções 3.4 e 3.5, o meta-modelo para modelar arquiteturas em camadas e o metamodelo
para modelar aplicações baseadas em CORBA, respectivamente. Este metamodelo
resultante deve agregar as características de ambos os meta-modelos
anteriormente citados, veja na FIG. 3-42. Assim, é necessário analisar como satisfazer
ambos os conjuntos de restrições, sem invalidar nenhum deles.
Meta-modelo para
modelar arquiteturas
em camadas
Meta-modelo para
modelar aplicações
baseadas em CORBA
Meta-modelo para
modelar aplicações
baseadas no estilo
camadas e em CORBA
FIGURA 3-42 - Instanciação para criar um meta-modelo para modelar aplicações baseadas em
CORBA e no estilo camadas.
O estilo camadas é caracterizado por organizar os componentes de uma
arquitetura de acordo com o nível de generalidade deles, compondo uma estrutura
hierárquica. As interações ocorrem, em geral, entre camadas adjacentes, no sentido Top-
Down, podendo ocorrer também entre camadas adjacentes nos sentidos Top-Down,
Bottom-Up ou ambos; e entre camadas não-adjacentes nos mesmos sentidos, como
vimos na Seção 3.3.2.
As aplicações distribuídas com middleware CORBA representam uma família de
produtos que impõe, em resumo, o modelo cliente-servidor dinâmico e que os
componentes servidores registrem seus serviços no CORBA. Ele requer, também, que
os componentes possam oferecer serviços com um dos três tipos de sincronização:
síncrono, síncrono deferido e assíncrono.
Cada um destes conjuntos de características foi especificado em meta-modelos
distintos, como apresentamos nas Seções 3.4 e 3.5. Eles ajudam no design de
arquiteturas com características do estilo camadas ou com características de aplicações
82

^
Configuração
^
^
^
j db
x, y: Componentes c x h comp k y h comp k d xf yg h comp_comp
^ ^
j db
x, y: Componentes c x h comp k y h comp k d xf yg h comp_comp
^ ^
^
que utilizam CORBA. Entretanto, não ajudam no design de aplicações com ambas as
características, pois a estruturação imposta pelo estilo camadas não é prevista pelas
aplicações que utilizam CORBA e vice-versa.
A seguir, apresentamos como as características e restrições de ambos os modelos
foram agregadas para dar origem a um meta-modelo capaz de retratar o design
detalhado de arquiteturas desta família de aplicações.
3.6.1 Estrutura Estática
3.6.1.1 Configuração
Como apresentamos na Seção 3.4, o estilo camadas impõe restrições estruturais à
configuração. A estrutura estática do meta-modelo, descrito na seção 3.4.1, apresenta
mudanças no elemento configuração, com relação ao meta-modelo descrito na Seção
3.3. Esta mudança diz respeito ao tipo de interação que pode ocorrer entre os
componentes e a uma propriedade denominada nível, utilizada para fazer o controle da
hierarquia da estrutura. Na FIG. 3-43, apresentamos a classe e o esquema Z da
Configuração_Camadas, definidos na Seção 3.4.
WYX Configuração_Camadas XZX[X\XZX[X[XZX\X[X[XZX\X]XZX\X[XZX[XZXZX[XZX
Configuração_Camadas:
Configuração
Conjunto de Componentes
Conjunto de Conectores
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Com-Com
Nível
Tipo_interação
nível: Componentes _ ` ^
XZX[X\X]X\X[X\XPX[X\X]X\X[XPX ^Yb a
x: Componentes; ` ced xf yg h y: i nível h x comp
^
tipo_interação: COMUNICAÇÃO
d tipo_interação = bot1 ^ ^
db
x, y: Componentes c x h comp k y h comp k d xf yg h comp_comp
i nível x = nível y - 1gg j
d tipo_interação = topbot1 ^ ^[l
db
x, y: Componentes c x h comp k y h comp k d xf yg h comp_comp
j
d tipo_interação = top1
^ ^[l
db
x, y: Componentes c x h comp k y h comp k d xf yg h comp_comp
j
i nível x = nível y + 1 l nível x = nível y - 1gg
i nível x = nível y + 1gg
^[l d tipo_interação = bot2
i nível x m nível ygng
^[l d tipo_interação = topbot2
i nível x o nível ygg
d tipo_interação = top2
^ ^[l
db
x, y: Componentes c x h comp k y h comp k d xf yg h comp_comp
i nível x p nível ygng j
XZX[X\X]X\X[X\XPX[X\X]X\X[XPX\X[XZX[X\XZX]X\X[XZX[XZXZX[X\XZX[X[XZXZXZX
q
FIGURA 3-43 - Classe e esquema da Configuração_Camadas.
83

^
^
k dt k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT; o,
^ ^
^ ^
^ ^
Na Seção 3.5.1.1, apresentamos um meta-modelo para modelar aplicações
baseadas em CORBA que não interfere na estrutura de uma configuração. Porém, nesta
abordagem, há a adição de um novo atributo que permite a interação entre uma nova
porta, denominada porta divulgadora, e papéis de entrada. Essa interação restringe o
modo de interação como um todo, pois como explicamos na Seção 3.5.1.1, um
componente só pode requisitar um serviço a um outro se este outro componente
divulgar este serviço no conector CORBA que os une. Na FIG. 3-44, apresentamos a
classe e o esquema Z da Configuração_CORBA definida na Seção 3.5.1.1.
Configuração_CORBA
^
Configuração
^
port_pap3: Porta_div r PapelIN
WYX Configuração_CORBAX\X]X\X[XZXZX[X\X]X\X[XPX\X[XZX[X\XPX[X\XZX
Conjunto de Componentes_C
Conjunto de Conectores_C
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Com-Com
XZX\X[XZX[X\X[XPX\X[XZX[X\XPX ^Yb a
x: Porta_div; y: csd xf yg h PapelIN
^ ist
port_pap3
cp: Componentes; cn: c Conectores h cp k comp h cn con
xf yg h cn . port_pap3 k x h cp . div_port
^Yb
x, y: Componentes c x h comp k y h comp k d xf yg h comp_comp
iYd
ist z, w: SERVICO c z h x . serv_req k w h y . serv_ofer
^
i z = w
p: PapelIN; j: Porta_div
lf ng h k . port_pap1
k d mf og h k . port_pap2
ced
d jf pg h k . port_pap3 k
i[d l h y . in_port k m h x . out_port k j h y . div_portgg
FIGURA 3-44 - Classe e esquema da Configuração_CORBA.
q XZX\X[XZX[X\X[XPX\X[XZX[X\XPX[X\X]X\X[XZXZX[X\X]X\XZX]X\X[XZX[X\X
As características intrínsecas a estas duas configurações são disjuntas, não
interferem uma na outra. Assim, a reunião destas características é possível e satisfaz a
ambos os meta-modelos. A configuração resultante da herança destas características,
denominada de Configuração_Camadas_CORBA, é apresentado a seguir, nas FIG. 3-45
e 3-47.
Configuração_Camadas_CORBA:
Configuração
Conjunto de Componentes
Conjunto de Conectores_CORBA
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Com-Com
Nível
Tipo_interação
FIGURA 3-45 - Classe Configuração_Camadas_CORBA.
84

w
Configuração
w
port_pap3: Porta_div z PapelIN
ƒ w ~| } ~ x „ y€ w
„ x, y: Componentes x comp y comp comp_comp
w ƒ ~|
x, y: Componentes } x comp „ y comp „ ~ x y€ comp_comp
ƒ w ~| } ~ x „ y€ w
„ x, y: Componentes x comp y comp comp_comp
ƒ w ~| } ~ x „ y€ w
„ x, y: Componentes x comp y comp comp_comp
ƒ w ~| } ~ x „ y€ w
„ x, y: Componentes x comp y comp comp_comp
ƒ w ~| } ~ x „ y€ w
„ x, y: Componentes x comp y comp comp_comp
w
w
u¢v Configuração_Camadas_CORBA v¢v¢v£vv£v¢v¢v¢v¢v¥v¢v¢v¤v¢v£v¢v¦v£v¢v¢v¢v¢v
w
nível: Componentes x y
w
tipo_interação: COMUNICAÇÃO
v¢v¤v¢v¢v£v¦v¢v£v¢v¢v¢v¢v£v¢v {
w¥| y x y€ ‚ w }P~
~
x: Componentes; y: nível x comp
tipo_interação = bot1
‚ nível x = nível y - 1€€
w… ~ tipo_interação = topbot1
‚ nível x = nível y + 1 nível x = nível y - 1€€
w… ~ tipo_interação = topbot2
port_pap3
nível x ‡ nível y€€ w… ‚
tipo_interação = top2 ~
‚ nível x ˆ nível y€>€
w¥| }P~ x y€
‚‰ „ } w
‚~ y€ w „ x
x: Porta_div; y: PapelIN
cp: Componentes; cn: Conectores cp comp cn con
cn . port_pap3 x cp . div_port
x, y: Componentes } x comp „ y comp „ ~ x y€ comp_comp
w
w¥|
z, w: SERVICO } z x . serv_req „ w y . serv_ofer
‚‰
p: PapelIN; j: Porta_div
‚ z = w
w „ ~‰ k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT; o,
w }P~ l n€ k . port_pap1
„ ~ m o€ k . port_pap2
w
„ ~ j p€ k . port_pap3
w
w
l y . in_port „ m x . out_port „ j y . div_port€>€
‚~
v¢v¤v¢v¢v£v¦v¢v£v¢v¢v¢v¢v£v¢v¢v¥v¢v¢v¢v¤v¥v¢v¢v¢v¢v¥v¢v¢v£v¢v¢v¢v¢v£v¦v
Š
FIGURA 3-46 - Esquema da Configuração_Camadas_CORBA.
Por outro lado, adotar a abordagem de CORBA como um componente da
arquitetura, tornaria a integração destes dois padrões inviável. Utilizar CORBA como
um componente induz uma estrutura não-hierárquica, em que os componentes CORBA
intermediam todas as interações. Assim, o meta-modelo para modelar arquiteturas em
camadas teria que adotar, sempre, a interação TopDown-BottomUP entre camadas não
adjacentes. Não podendo ocorrer a interação mais tradicional que é entre camadas
adjacentes no sentido TopDown.
85

3.6.1.2 Componentes
Como apresentamos na Seção 3.4, o estilo camadas não impõe nenhuma restrição aos
componentes e portas, definidos na Seção 3.3, exceto pelo vocabulário.
Por sua vez, no meta-modelo definido na Seção 3.5.1.1, o componente possui
um tipo de porta a mais do que definimos na Seção 3.3, a porta divulgadora. O
componente precisa garantir que cada porta divulgadora possui um identificador único.
Esta alteração não tem impacto no meta-modelo para modelar arquiteturas em camadas,
podendo, assim, coexistirem num único componente. Na FIG. 3-47, apresentamos a
classe que representa o componente na Configuração_Camadas_CORBA e o esquema Z
destacando as alterações realizadas.
Componentes
Id_com
Conjunto de Serv_req
Conjunto de Serv_ofer
Conjunto de Porta_rec
Conjunto de Porta_exp
Conjunto de Porta_div
Conf
Serviço()
Requisitar()
Responder()
ComponentesŒ[Œ[ŒZŒ\Œ[ŒZŒ[Œ\Œ]Œ\Œ[ŒZŒ[Œ\ŒZŒ[ŒZŒZŒ[Œ[ŒZŒ\Œ]Œ
‹YŒ
Ž div_port: Porta_div
YŒZŒ[Œ\Œ]Œ\Œ[ŒZŒZŒ[ŒZŒ[Œ\ŒZŒ]Œ
c1, c2: Porta_div c1 ’ div_port “ c2 ’ div_port
” c1 . id_port_exp = c2 . id_port_exp • c1 = c2
‘
ŒZŒ[Œ\Œ]Œ\Œ[ŒZŒZŒ[ŒZŒ[Œ\ŒZŒ]Œ\Œ[ŒZŒ[Œ\ŒPŒ[Œ\ŒZŒ[Œ[Œ—Œ[Œ[ŒZŒ\Œ[Œ[Œ—Œ[ŒZŒ
–
FIGURA 3-47 - Classe e esquema do Componente na Configuração_Camadas_CORBA.
3.6.1.3 Conectores
Como apresentamos na Seção 3.4, o estilo camadas não impõe nenhuma restrição aos
conectores e papéis, definidos na Seção 3.3. O meta-modelo para modelar aplicações
baseadas em CORBA, não impõe restrições aos conectores e papéis. Porém com a
adição da Porta divulgadora, o conector precisa garantir que os papéis de entrada podem
se relacionar com portas divulgadoras. As classes e os esquemas dos conectores e papéis
na Configuração CORBA são idênticos aos da Configuração_Camadas_CORBA. Nas
FIG. 3-48 e 3-50, apresentamos a classe e o esquema do conector e do papel na
Configuração_Camadas_CORBA, respectivamente.
86

Conectores
Id_con
Conjunto de PapelIn
Conjunto de PapelOUT
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto de pares Pap-pap
Conf
Serviço()
Enviar()
Conectoresv¦v£v¢v¢v¢v¥v¢v¤v¢v¢v¥v¢v¢v¢v£v¦v¤v¢v¢v£v
wu¢v w port_pap3: z Porta_div { v¢v¢v¢v¤v¢v¥v¢v¢v£v¢v¦v¤v¢v£v
PapelIN
x: Porta_div; y: PapelIN }˜~ x y€ port_pap3 ‚ y in_pap
w¥|
v¢v¢v¢v¤v¢v¥v¢v v£v¢v¦v¤v¢v£v¢v¦v£v¢v¢v¢v¢v£v¢v¢v¢v¥v¢v¥v¢v
{
FIGURA 3-48 - Classe e esquema do conector na Configuração_Camadas_CORBA.
Papel IN
Id_in
Propr
Porta_exp
Porta_div
PapelOUT
Ler(req)
Escrever(resp)
PapelINv£v¢v¢v¤v¢v¥v¢v¢v¢v¢v¥v¢v¤v¢v¢v¥v¢v¢v
wu¢v w port_div: { v¢v¢v¢v£v¢v¦v£vv£v¢v¦v£v¢v¢v
Porta_div
x: Porta_div } x port_div ‚ x . propr = propr
w¥|
v¢v¢v¢v£v¢v¦v£vv£v¢v¦v£v¢v¢v¢v¥v¤v¢v¢v¢v¥v¢v¢v¢v£v
Š
FIGURA 3-49 - Classe e esquema do Papel_IN na Configuração_Camadas _CORBA.
Com estas alterações, apresentamos , na FIG. 3-50, a estrutura estática do metamodelo
para modelar esta família de aplicações distribuídas.
87

Configuração_Camadas_CORBA:
Configuração
Conjunto de Componentes
Conjunto de Conectores
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto dos pares Pap-Pap
Conjunto dos pares Com-Com
1
Nível
Tipo_interação
1
*
Componentes
Id_com
Conjunto de Serv_req
Conjunto de Serv_ofer
Conjunto de Porta_rec
Conjunto de Porta_exp
Conjunto de Porta_div
Conf
Serviço()
Requisitar()
Responder()
1
*
Porta
1
1
Serviço()
Enviar()
* conexão *
* *
obedece
obedece
1
1 *
Conectores
Id_con
Conjunto de PapelIn
Conjunto de PapelOUT
Conjunto dos pares Port_rec-PapOUT
Conjunto dos pares Port_exp-PapIN
Conjunto dos pares Port_div-PapIN
Conjunto de pares Pap-pap
Conf
1
*
Papel
*
*
liga
{ou}
{ou}
Porta_div
Interfaces IDL
Receber(req)
Registrar(interface)
Porta_rec
Id_rec
Serv-Ofer
Propr
Receber(req)
Responder()
Porta_exp
Id_exp
Serv_req
Propr
Requisitar()
Receber(resp)
1 1
Protocolo
Papel IN
Id_in
Propr
Porta_exp
Porta_div
PapelOUT
Ler(req)
Escrever(resp)
Papel OUT
Id_out
Propr
Porta_rec
PapelIN
Ler(resp)
Escrever(req)
FIGURA 3-50 - Estrutura estática do meta-modelo para modelar uma família de aplicações
distribuídas.
3.6.2 Estrutura Dinâmica
A estrutura dinâmica deste meta-modelo é idêntica a estrutura dinâmica do metamodelo
para modelar aplicações baseadas em CORBA, apresentada na Seção 3.5.2,
visto que, a estrutura dinâmica do meta-modelo para modelar arquiteturas em camadas é
idêntica a estrutura dinâmica do meta-modelo para modelar estilos.
Nesta Seção, apresentamos um meta-modelo para modelar uma família de
aplicações distribuídas. Esta família é caracterizada pela estrutura hierárquica imposta
88

pelo estilo camadas e pela utilização do middleware CORBA. Este meta-modelo pode
ser instanciado ou refinado para a criação de arquiteturas específicas ou para a criação
de meta-modelos que agregam outras características.
3.7 Conclusões
Neste capítulo, apresentamos um meta-modelo para modelar uma família de aplicações
distribuídas, objetivo principal deste trabalho de dissertação. Para definirmos este metamodelo,
fizemos um estudo cuidadoso de quais características ele deveria apresentar e
como modelar estas características de maneira clara e representativa.
Apresentamos a metodologia utilizada para alcançar nossos propósitos, os vários
meta-modelos definidos para chegarmos a uma definição mais precisa e genérica e
como cada um deles foi definido ou instanciado a partir de um outro mais genérico.
Todos estes meta-modelos representam uma visão arquitetural de um sistema ou
família deles. Porém, a utilização da UML permite que esta arquitetura seja
gradualmente refinada até chegar a um nível detalhado de design, podendo ser
implementado. O refinamento gradual da arquitetura até a implementação garante maior
consistência entre estes modelos e assim, maior facilidade para realizar a manutenção
do sistema, permitindo um maior tempo de vida para sistemas passíveis de serem
modificados para atender aos requisitos dos usuários.
No capítulo 4, a seguir, apresentamos um estudo de caso. Este estudo de caso
demonstra como aplicar o meta-modelo a projetos práticos e representa uma instância
do meta-modelo apresentado na Seção 3.6.
89

4. ESTUDO DE CASO
Neste capítulo, definimos um estudo de caso para demonstrar a aplicação do metamodelo
apresentado na Seção 3.6. Utilizamos a notação definida pela UML e os
estereótipos que apresentamos na Seção 3.3.3.
4.1 Definição do Estudo de Caso
Escolhemos um estudo de caso cujo domínio é de conhecimento público: a aplicação de
caixa eletrônico. Assim, facilitamos o entendimento do leitor e focamos a utilização do
meta-modelo ao invés de nos determos a detalhes sobre a aplicação em si.
A aplicação Caixa Eletrônico simula as funcionalidades de um caixa eletrônico,
em que o usuário pode sacar dinheiro, tirar o extrato e o saldo, realizar pagamentos e
transferências, e requisitar cheques. Na FIG. 4-1, apresentamos a funcionalidade do
sistema através do diagrama de casos de uso definido pela UML, e na TAB. 4-1,
fornecemos uma breve descrição destes casos de uso.
Sacar
Tirar saldo
Tirar extrato
Cliente
Realizar pagamento
Realizar transferência
Requisitar Cheques
FIGURA 4-1 - Diagrama de casos de uso para a aplicação Caixa Eletrônico.
90

Nome do caso de uso
Sacar
Tirar saldo
Tirar extrato
Realizar transferência
Realizar pagamento
Requisitar cheque
TABELA 4-1
Descrição dos Casos de Uso.
Quem inicia o
caso de uso
Cliente
Cliente
Cliente
Cliente
Cliente
Cliente
Descrição do caso de uso
O cliente deve informar sua senha. O sistema
verifica os dados do cliente, bem como a senha,
faz a contagem do dinheiro se o cliente possuir
saldo suficiente, e debita o valor mais as tarifas
da conta.
O cliente deve informar sua senha. O sistema
verifica os dados do cliente, bem como a senha,
e emite o recibo de saldo.
O cliente deve informar sua senha, e as datas
para o extrato. O sistema verifica os dados do
cliente, bem como a senha, emite o recibo de
extrato, e debita as tarifas da conta.
O cliente deve informar sua senha, a data para a
transferência, e as informações da conta para a
qual o dinheiro deve ser transferido. O sistema
verifica os dados do cliente, bem como a senha,
realiza a transferência, emite o recibo de
transferência, e debita o valor e as tarifas da
conta.
O cliente deve informar sua senha, a data para o
pagamento, e as informações da conta para a
qual o dinheiro deve ser pago. O sistema verifica
os dados do cliente, bem como a senha, realiza a
pagamento, emite o recibo de pagamento e
debita o valor e as tarifas da conta.
O cliente deve informar sua senha e a
quantidade de cheques que ele deseja.O sistema
verifica os dados do cliente, bem como a senha,
emite os cheques se a conta do cliente permitir o
uso de cheques e debita as tarifas da conta.
4.2 Utilizando o Meta-modelo para Modelar uma Família de
Aplicações Distribuídas.
A aplicação Caixa Eletrônico é uma aplicação tipicamente distribuída. Os componentes
que compõem esta aplicação podem ser executados em plataformas de hardware e
software diferentes e devem interagir entre si para fornecer uma funcionalidade ao
cliente.
91

As funcionalidades desta aplicação, mostradas através dos casos de uso,
apresentam atividades em comum, como por exemplo, a verificação e análise da senha
do cliente, a emissão de recibos, o débito de taxas na conta do cliente, dentre outras.
Assim, cada uma delas pode ser atribuída a componentes diferentes da aplicação,
permitindo que eles sejam organizados de acordo com o nível de generalidade que
possuem, e mais facilmente reutilizados.
Considerando um alto nível de abstração, definimos os seguintes componentes e
suas respectivas funcionalidades para a aplicação Caixa Eletrônico:
• Saldo – O componente Saldo interage com o cliente para obter as informações
necessárias para a emissão de saldo, e requisita o saldo ao componente Emissor
de recibos.
• Extrato - O componente Extrato interage com o cliente para obter as
informações necessárias para a emissão de extrato, e requisita o extrato ao
componente Emissor de recibos.
• Transferência - O componente Transferência interage com o cliente para obter as
informações necessárias para realizar uma transferência, e requisita um recibo ao
componente Emissor de recibos e a transferência ao componente Registrador de
mudanças de saldo entre contas.
• Pagamento - O componente Pagamento interage com o cliente para obter as
informações necessárias para realizar um Pagamento, e requisita um recibo ao
componente Emissor de recibos e o pagamento ao componente Registrador de
mudanças de saldo entre contas.
• Cheque - O componente Cheque interage com o cliente para obter as
informações necessárias para a emissão de cheque, e requisita a impressão de
cheques ao componente Emissor de cheque, e aguarda uma resposta.
• Saque - O componente Saque interage com o cliente para obter as informações
necessárias para sacar dinheiro, e requisita o saque ao componente Contador de
dinheiro, e aguarda uma resposta.
• Emissor de recibos – O componente Emissor de recibos recebe as informações
necessárias e requisita, ao componente Buscador de informações do cliente, a
verificação dos dados do cliente. Este componente, também, requisita, ao
componente Registrador de mudanças de saldo entre contas, a mudança do saldo
do cliente em virtude das tarifas cobradas pela emissão de extrato. Após receber
92

uma resposta, este componente emite o recibo referente ao que lhe foi
requisitado.
• Registrador de mudanças de saldo entre contas – Requisita, ao buscador de
informações do cliente, mudanças nos dados do cliente em relação a uma das
operações do caixa eletrônico.
• Emissor de cheques - Recebe as informações necessárias, e requisita, ao
componente Buscador de Informações do cliente, a permissão para emitir
cheques. Quando ele obtém essa permissão, ele imprime a quantidade de
cheques requisitada.
• Contador de dinheiro – Recebe as informações necessárias, e requisita, ao
componente Buscador de Informações do cliente, a permissão para realizar o
saque. Quando ele obtém essa permissão, ele conta o dinheiro e emite.
• Buscador de informações do cliente – Recebe as informações necessárias e
requisita, ao componente Verificador de senha, a decriptação e análise da senha
oferecida, com respeito à senha cadastrada. Este componente, também, requisita,
ao componente Alterador de informações do cliente, a mudança em alguns dados
do cliente quando necessário. Isto, normalmente, ocorre quando é necessário
modificar o saldo do cliente com respeito as operações de saque, pagamento,
transferência, extrato e cheque e as respectivas tarifas cobradas por cada uma
delas. Se este componente obtiver uma resposta positiva então ele oferece uma
resposta ao componente que o requisitou.
• Alterador de informações do cliente – Recebe as informações a serem alteradas e
oferece uma resposta quando realiza as alterações.
• Verificador de senha – Recebe as informações necessárias e analisa a senha
oferecida com relação à senha cadastrada. Ao terminar a análise, este
componente envia uma resposta para o componente que fez a requisição.
Nós utilizamos o middleware CORBA para tratar a distribuição e o estilo camadas para
organizar, hierarquicamente, os componentes. Portanto, podemos utilizar o metamodelo
definido na Seção 3.6 para modelar esta aplicação. Na FIG. 4-2, apresentamos a
arquitetura desta aplicação, através dos estereótipos apresentados na Seção 3.3.3.
93

Caixa Eletrônico: Configuração_Camadas_CORBA
Nível 4
Saldo
Extrato Transferência Pagamento Cheque Saque
Nível 3
Registrador de
Emissor de recibos mudanças de saldo Emissor de cheques Contador de dinheiro
entre contas
Nível 2
Buscador de info do cliente
Alterador de info do
cliente
Nível 1
Verificador de senha
FIGURA 4-2 - Arquitetura da aplicação Caixa Eletrônico.
Na FIG. 4-2, apresentamos a arquitetura da aplicação Caixa Eletrônico. Esta
arquitetura é uma Configuração_Camadas_CORBA constituída de quatro níveis,
representados pelas faixas na cor cinza, e 13 camadas ou componentes, representados
pelos retângulos etiquetados. Cada componente está relacionado a um único nível. Os
componentes do quarto nível são componentes que interagem diretamente com o
usuário e fornecem as funcionalidades da aplicação.
Os conectores indicam a interação no sentido Top-Down entre camadas
adjacentes. Desta forma os componentes dos níveis mais altos requisitam serviços aos
componentes dos níveis mais baixos. Para esta aplicação, consideramos a comunicação
Síncrona, em que cada componente interrompe seu processamento até obter uma
resposta ao serviço requisitado. Por exemplo, o componente Saldo só efetivará sua
funcionalidade após obter resposta do componente emissor de recibos que por sua vez
só enviará esta resposta quando o componente Buscador de Informações do Cliente lhe
enviar uma resposta e assim sucessivamente.
Na configuração retratada na FIG. 4-2, definimos um Conector_CORBA para
cada interação entre dois componentes. Entretanto, um único conector entre os
componentes de níveis adjacentes é suficiente para realizar as interações desejadas, pois
um conector CORBA suporta o registro de inúmeros serviços de e para componentes
diferentes. Na FIG. 4-3, apresentamos esta abordagem.
94

Caixa Eletrônico: Configuração_Camadas_CORBA
Nível 4
Saldo
Extrato Transferência Pagamento Cheque Saque
CORBA
Nível 3
Registrador de
Emissor de recibos mudanças de saldo Emissor de cheques Contador de dinheiro
entre contas
CORBA
Nível 2
Buscador de info do cliente
Alterador de info do
cliente
CORBA
Nível 1
Verificador de senha
FIGURA 4-3 - Arquitetura da aplicação Caixa Eletrônico.
Utilizar um único Conector_CORBA para realizar as interações entre
componentes de níveis adjacentes torna a arquitetura mais clara. Entretanto, esta decisão
tem impacto quando se consideram níveis de design mais detalhados. Por ora,
consideramos esta abordagem, apresentada na FIG. 4-3, mais adequada para este
trabalho de dissertação.
Na FIG. 4-4, apresentamos algumas das classes da Aplicação Caixa Eletrônico,
segundo os atributos definidos no Meta-modelo. Na FIG. 4-5, apresentamos uma parte
da arquitetura da aplicação através do diagrama de objetos da UML, que teve como base
o diagrama de classes definido na Seção 3.6.
95

Saldo: Componentes
Extrato: Componentes
Saque: Componentes
Pagamento: Componentes
Id_com: Saldo
Serv_req: {Info Saldo}
Serv_ofer: {Saldo}
Porta_rec: {}
Porta_exp: {P2}
Porta_div: {}
Conf: {}
Saldo()
Requisitar()
Responder()
Cheque: Componentes
Id_com: Cheque
Serv_req: {Info Cheq, Cheq}
Serv_ofer: {Cheque}
Porta_rec: {}
Porta_exp: {P2}
Porta_div: {}
Conf: {}
Cheque()
Requisitar()
Responder()
Id_com: Extrato
Serv_req: {Info Extrato}
Serv_ofer: {Extrato}
Porta_rec: {}
Porta_exp: {P2}
Porta_div: {}
Conf: {}
Extrato()
Requisitar()
Responder()
Transferência: Componentes
Id_com: Transferência
Serv_req: {Info Transf,
Transf}
Serv_ofer: {Transferência}
Porta_rec: {}
Porta_exp: {P2,P3}
Porta_div: {}
Conf: {}
Transferência()
Requisitar()
Responder()
Id_com: Saque
Serv_req: {Info Saque}
Serv_ofer: {Saque}
Porta_rec: {}
Porta_exp: {P2}
Porta_div: {}
Conf: {}
Saque()
Requisitar()
Responder()
Emissor_de_Recibos:
Componentes
Id_com: Emissor_de_Recibos
Serv_req: {InfoDados,
Reg_Mud}
Serv_ofer: {InfoSaldo,
InfExtrato, InfoTransf, InfoPag}
Porta_rec: {P1,P2,P3,P4,}
Porta_exp: {P6}
Porta_div: {P5}
Conf: {}
InfoSaldo()...
Requisitar()
Responder()
Id_com: Pagamento
Serv_req: {Info Pag, Pag}
Serv_ofer: {Pagamento}
Porta_rec: {}
Porta_exp: {P2,P3}
Porta_div: {}
Conf: {}
Pagamento()
Requisitar()
Responder()
Reg_Mud_Saldo_:
Componentes
Id_com: Reg_Mud_Saldo_
Serv_req: {MudSaldo,
InfoDados}
Serv_ofer: {Reg_Mud}
Porta_rec: {P1,P2}
Porta_exp: {P4}
Porta_div: {P3}
Conf: {}
MudSaldo() ...
Requisitar()
Responder()
Emis_Cheque: Componentes
Cont_Dinheir: Componentes
Busca_Info: Componentes
Altera_Info: Componentes
Id_com: Emis_Cheque
Serv_req: {InfoDados}
Serv_ofer: {ImpCheque}
Porta_rec: {P1}
Porta_exp: {P2}
Porta_div: {P3}
Conf: {}
ImpCheque()
Requisitar()
Responder()
Id_com: Cont_Dinheiro
Serv_req: {InfoDados}
Serv_ofer: {Cont Dinheiro}
Porta_rec: {P1}
Porta_exp: {P2}
Porta_div: {P3}
Conf: {}
ContDinheiro()
Requisitar()
Responder()
Id_com: Busc_Info_do_Cliente
Serv_req: {Ver_Senha,
MudDados}
Serv_ofer: {InfoDados}
Porta_rec: {P1,P2,P3,P4}
Porta_exp: {P5}
Porta_div: {P6}
Conf: {}
InfoDados()
Requisitar()
Responder()
Id_com: Altera_Info_do_Cliente
Serv_req: {}
Serv_ofer: {MudDados}
Porta_rec: {P1}
Porta_exp: {}
Porta_div: {P2}
Conf: {}
MudDados()
Requisitar()
Responder()
Ver_Senha: Componentes
Id_com: Ver_senha
Serv_req: {}
Serv_ofer: {Ver_Senha}
Porta_rec: {P1}
Porta_exp: {}
Porta_div: {P2}
Conf: {}
Ver_Senha()
Requisitar()
Responder()
FIGURA 4-4 - Classes da aplicação Caixa Eletrônico.
96

Caixa
Eletrônico:
Configuração
Saldo:
Componentes
Extrato:
Componentes
Transferência:
Componentes
...
P2:
Porta_exp
P2:
Porta_exp
P2:
Porta_exp
P3:
Porta_exp
P1:
PapelIN
Con1:
Conector_
CORBA
P2:
PapelOUT
P3:
PapelIN
P1:
Porta_rec
P2:
Porta_rec
P3:
Porta_rec
P5:
Porta_div
P1:
Porta_rec
P2:
Porta_rec
P3:
Porta_div
Emissor de
recibos:
Componentes
Registrador de
mudanças de saldo
entre contas:
Componentes
P6:
Porta_exp
P4:
Porta_exp
P1:
PapelIN
Con2:
Conectores
P2:
PapelOUT
P3:
PapelIN
P1:
Porta_rec
P2:
Porta_rec
P3
Porta_rec
P4:
Porta_rec
P6:
Porta_div
Buscador de
info do cliente:
Componentes
P5:
Porta_exp
...
FIGURA 4-5 - Diagrama de objetos para a aplicação Caixa Eletrônico.
97

O diagrama de seqüência, a seguir, retrata a seqüência de interações entre os
componentes para realizar a funcionalidade Tirar Saldo. Este diagrama de seqüência é
uma instância do diagrama de seqüência da FIG. 3-40, na Seção 3.5.2.1. Entretanto,
para realizar esta funcionalidade, há interações entre quatro componentes, Saldo,
Emissor de recibos, Buscador de informações do cliente e Verificador de senha. Como
dissemos anteriormente, a comunicação é Síncrona, assim, o componente saldo aguarda
uma resposta para que se torne apto a realizar outras requisições de saldo.
Saldo Porta_exp1 Papel IN
Conector_
CORBA
Papel OUT
Porta_rec
Porta_div
Emissor de
recibos
Serviço()
Registrar()
Registrar()
Ler(req)
registrar(IDL)
Serviço()
Requisitar()
Receber
(resp)
Ler(req)
Escrever
(resp)
Serviço()
Enviar()
Serviço()
Enviar()
Serviço()
Serviço()
Escrever
(req)
Ler(resp)
Receber
(req)
Responder()
Serviço()
...
FIGURA 4-6 - Diagrama de sequência para a função Saldo do Caixa Eletrônico.
O diagrama de objetos, FIG. 4-5, e o diagrama de seqüência, FIG. 4-6 respeitam
as características e restrições definidas pelos diagramas da FIG. 3-30 e 3-41,
respectivamente.
Igualmente, os estados assumidos pelos componentes desta aplicação são os
mesmos definidos, genericamente, na Seção 3.3.2.2, FIG. 3-20, onde o estado
Executando representa um estado genérico de execução de qualquer serviço, este estado
pode ser renomeado pelas atividades de responsabilidade de um certo componente.
4.3 Conclusões
Neste capítulo, apresentamos um estudo de caso para a aplicação do meta-modelo
definido na Seção 3.6. Como vimos neste estudo de caso, é necessário que a aplicação
que se deseja modelar possua as características definidas pelo meta-modelo, ou seja, a
98

aplicação deve ser passível de ser estruturada em camadas e deve-se ter a necessidade
de torná-la distribuída.
Aplicar este meta-modelo, tanto quanto os outros definidos nas seções
anteriores, é uma tarefa de instanciação. Instanciar um modelo exige, do projetista,
atenção para que ele não defina elementos e características não previstos pelo modelo
genérico. A utilização dos estereótipos facilita a modelagem do diagrama de classes e de
seqüência.
99

5. TRABALHOS CORRELATOS
Nós propomos um meta-modelo para modelar uma família de aplicações distribuídas.
Este meta-modelo tem a função de oferecer, ao projetista, as informações intrínsecas a
esta família que são relevantes e fundamentais para a construção de arquiteturas de
produtos desta família. O meta-modelo provê tais informações em uma linguagem de
fácil entendimento e aprendizagem, possibilitando a divulgação, o uso e o reuso das
informações de um projeto já efetivado.
Muito tem se investido em pesquisas na área de Arquitetura de Software, e
especificamente em estilos e padrões arquiteturais como meio de facilitar o processo de
desenvolvimento de software e de prover maior manutenibilidade aos sistemas
construídos. Neste Capítulo, apresentamos alguns trabalhos que são resultados desta
busca por melhores métodos e técnicas para a arquitetura de software e resumimos as
deficiências destes esforços em endereçar a questão central desta dissertação.
5.1 Hofmeister, Nord e Soni
Como apresentamos no Capítulo 2, o livro intitulado “ Applied Software Architecture” ,
cujos autores são Hofmeister, Nord e Soni [27], é fruto da experiência destes
pesquisadores na área de arquitetura de software, e constitui um guia detalhado e prático
para as tarefas de arquitetura de software. Seus autores, tendo como ponto de partida os
aspectos necessários para a criação da arquitetura de um sistema, criaram quatro metamodelos
retratando estas características, ou visões arquiteturais. Cada uma delas pode
ser utilizada separadamente e endereça diferentes interesses da arquitetura.
A visão conceitual influenciou enormemente o trabalho aqui proposto. Esta
visão foi a base para definição dos meta_modelos construídos. Entretanto, para
satisfazer os aspectos intrínsecos aos estilos arquiteturais foi necessário realizar algumas
alterações nesta visão, como apresentamos no Capítulo 3. Para retratar a arquitetura de
uma maneira mais detalhada foi necessário, também, acrescentar os atributos e
operações básicas para interação entre componentes e utilizar a linguagem de
especificação Z para retratar as restrições mais claramente do que permitido pela UML.
Apesar de reconhecer os limites impostos, Hofmeister, Nordi e Soni também utilizaram
a UML como notação para definir estas visões.
100

A visão de módulo, definida por Hofmeister, Nordi e Soni, possui similaridade
com o meta-modelo para modelar arquiteturas em camadas, no que diz respeito a
preocupação em organizar a arquitetura do sistema em camadas. Entretanto, esta
abordagem é bastante diferente da abordagem definida pelo estilo camadas. O estilo
camadas estabelece que camadas são os componentes desta arquitetura enquanto que na
visão de módulo as camadas representam um conjunto de módulos que por sua vez
podem corresponder a um único elemento conceitual (componente, porta, conector, ou
papel) ou a um conjunto deles. Na visão de módulo, diferentemente do estabelecido
pelo estilo camadas, nenhuma restrição quanto à interação entre camadas é feita. Desta
forma, a visão de módulo se distingue completamente do que propomos com o metamodelo
para modelar arquiteturas em camadas.
5.2 Di Nitto e Rosenblum
Dois trabalhos realizados por Di Nitto e Rosenblum [15][16] retratam a preocupação de
antecipadamente tomar algumas decisões do nível de implementação durante o design
da arquitetura. Eles apontam a escolha do middleware relevante arquiteturalmente, pois
diferentes middlewares impõem restrições arquiteturais diferentes, e estas restrições
devem ser consistentes com a arquitetura da aplicação.
Eles realizaram alguns estudos de caso que comprovaram esta preocupação. Um
deles foi tentar integrar o estilo pipe-and-filter com os middlewares CORBA e JEDI.
JEDI [13] é um middleware baseado em eventos. O resultado que eles obtiveram foi que
CORBA induz um estilo arquitetural que é compatível com o estilo pipe-and-filter,
enquanto JEDI induz um estilo arquitetural que é incompatível ou difícil de conciliar
com o estilo pipe-and-filter.
Estes trabalhos nos motivaram a realizar o presente trabalho de dissertação. Nós
temos a mesma preocupação, porém além de investigar se o estilo camadas é consistente
com o estilo induzido pelo padrão CORBA, nós elaboramos uma solução para integrarlos
e fornecemos esta solução em forma de meta-modelo que pode ser facilmente
utilizado para criar produtos que apresentem as restrições que eles impõem.
101

5.3 Egyed, Mehta e Medvidovic
Um trabalho recente de Egyed, Medvidovic e Mehta também foi motivador para o
presente trabalho de dissertação, “ Software Connectors and Refinement in Family
Architectures” [18]. Neste trabalho os autores definem uma maneira de refinar e evoluir
uma arquitetura de família até alcançar a arquitetura detalhada de um produto específico
daquela família. Nós apresentamos esta abordagem no Capítulo 2.
Entretanto, este é um trabalho em desenvolvimento. Eles não apresentaram
estudos de caso que demonstrem a teoria definida. Nesta dissertação, nós definimos os
meta-modelos em um nível um pouco mais detalhado que a arquitetura de software
propriamente dita. O uso da UML e do paradigma de orientação a objetos, facilita este
refinamento, permitindo uma transformação mais gradual.
5.4 Buschmann, Meunier, Rohnert, Sommerlad e Stal
No livro intitulado “ A System of Patterns – Pattern-Oriented Software Architecture”
[6], Bushmann et al. catalogaram vários padrões arquiteturais e de design comumente
utilizados tais como, Camadas, Pipe-and-Filter, Cliente-Servidor etc. Eles adotaram o
esquema de três partes, contexto, problema e solução para descrever cada um dos
padrões. Além disto, utilizam o modelo de objetos da OMT [50] (Object Modeling
Technique) e o diagrama de seqüência de mensagens (Message Sequence Charts) [26]
padronizado no domínio de telecomunicações.
Buschmann et al., também, definiram um sistema de padrões. O sistema de
padrões mostra como combinar padrões individuais para construir estruturas
heterogêneas. Um sistema de padrões para a arquitetura de software, segundo a própria
definição dos autores, é uma coleção de padrões para arquitetura de software,
juntamente com um guia para sua implementação, combinação e uso prático no
desenvolvimento de software.
Embora tenhamos a intenção de divulgar os padrões que nós utilizamos, este não
é nosso foco, nem tampouco, catalogar padrões. A nossa proposta também não é definir
novos padrões apesar de integrarmos dois padrões bastante distintos. A integração que
realizamos entre o estilo camadas e as restrições impostas pelo padrão CORBA é uma
solução que auxilia no design de sistemas que possuam ambas as características mas
102

não é um padrão que pode ser classificado para ser utilizado em um domínio específico
e para resolver um determinado problema. Apesar de documentar o estilo camadas, e
outros padrões, Buschmann et al. não retratou o estilo em termos de configuração,
componentes, conectores, portas e papéis como nós realizamos através da definição dos
meta-modelos.
5.5 Gamma, Helm, Johnson e Vlissides
O livro intitulado “ Design Patterns – Elements of Reusable Object-Oriented Software”
[21] é uma das principais referências sobre padrões. Este livro é um catálogo de padrões
de design. Como dissemos na Seção 5.4, esta abordagem se distingue completamente
dos nossos propósitos.
5.6 Conclusões
No Capítulo 5, apresentamos os principais trabalhos correlatos a esta dissertação. Estes
trabalhos são trabalhos tradicionais, como o de Gamma et al., Buschmann et al. e
Hofmeister et al. [27], ou ainda em desenvolvimento, como os de Egyed et al. e Di Nitto
et al.. Cada um deles é correlato a esta dissertação por apresentar algum sub-objetivo em
comum. Porém não encontramos na literatura uma abordagem que se proponha a cobrir
todos os pontos que tratamos com a utilização dos meta-modelos elaborados.
A proposta de facilitar o design de arquiteturas e o refinamento delas, através de
um meta-modelo que pode ser instanciado para definição de famílias de aplicações ou
de produtos específicos, é uma abordagem que ajuda projetistas experientes e leigos a
desenvolverem sistemas manuteníveis.
103

6. CONCLUSÕES E TRABALHOS FUTUROS
Nesta dissertação, apresentamos uma abordagem para desenvolver um sistema a partir
de sua arquitetura, diminuindo o gap e as dificuldades encontradas em transformar
modelos do nível abstrato em modelos de um nível de abstração menor. Levantamos,
também, decisões normalmente consideradas como de nível de implementação que se
não são tomadas antecipadamente em nível arquitetural, podem afetar negativamente o
ciclo de vida do software.
A elaboração dos meta-modelos construídos foi fruto destas preocupações. Com
a elaboração deste meta-modelo, nós alcançamos vários resultados de grande relevância
para a arquitetura e a engenharia de software como um todo. Nossas principais
contribuições são apresentadas na Seção 6.1.
O estudo de caso que realizamos com base no meta-modelo para modelar uma
família de aplicações distribuídas, apresentado no Capítulo 4, teve resultados
satisfatórios para a efetivação desta abordagem. Conseguimos facilmente projetar a
arquitetura de uma aplicação bancária, por aplicar as características do meta-modelo,
quanto aos componentes e formas de integração, para integrar os componentes e
fornecer a funcionalidade desejada.
Desenvolvemos esta abordagem para um domínio específico, relativo às
aplicações em camadas e que utilizam CORBA. Entretanto, a abordagem desenvolvida
pode ser difundida e realizada para diversos domínios e aplicada, pelo menos, aos
padrões arquiteturais mais conhecidos como Pipe-and-filter, Blackboard, Eventos etc.
Tendo como base esta dissertação e especificamente o meta-modelo para modelar
estilos, definido na Seção 3.3, torna-se mais fácil desenvolver estes novos metamodelos.
Disponibilizá-los na forma de meta-modelos, por sua vez, torna mais fácil
integrar cada um deles a outros padrões.
Como apresentamos no Capítulo 5, a abordagem focada nesta dissertação está
relacionada a trabalhos bastante diferentes. Entretanto, todos eles são trabalhos que
motivaram e embasaram este. Através de soluções específicas para alguns problemas,
como a difusão de padrões e visões arquiteturais, ou a solução para refinar uma
arquitetura de família, e alguns problemas levantados, como os conflitos existentes entre
os diversos middlewares e estilos, nós conseguimos reunir e elaborar uma solução que
abrange todos estes problemas.
104

Esta solução representa o início de uma série de pesquisas que podem ser
realizadas para melhorar os métodos e técnicas existentes para o desenvolvimento de
sistemas de software de qualidade. Na Seção 6.2 nós apresentamos algumas sugestões
para trabalhos futuros.
6.1 Resultados Obtidos
6.1.1 Definição dos Meta-modelos
Cada um dos meta-modelos elaborados e apresentados no Capítulo 3 oferece um
conjunto de características intrínsecas a um determinado domínio. Cada um deles ajuda
na modelagem detalhada de um sistema que possui tais características. Estas
características são retratadas através das linguagens UML e Z e através da explicação
textual. Oferecemos o mínimo de informações considerado suficiente e necessário para
que um leigo ou especialista esteja apto a modelar suas aplicações, tendo como base
algum destes meta-modelos. Cada um dos meta-modelos elaborados são em si uma
contribuição para a comunidade de engenheiros de software.
• Um meta-modelo para modelar estilos - Este meta-modelo é um modelo
genérico para modelagem de estilos ou de arquiteturas específicas, sem
restrições impostas por estilos, tal como a visão conceitual definida por
Hofmeister et al. [27]. Entretanto com a definição dos atributos e operações, e do
diagrama de seqüências elaborado para este meta-modelo, nós fazemos algumas
restrições quanto ao protocolo utilizado, a maneira em que portas e papéis estão
conectados e como componentes se comunicam entre si.
• Um meta-modelo para modelar arquiteturas em camadas - Este metamodelo
retrata as características e restrições impostas pelo estilo camadas.
Apesar do estilo camadas ser bastante conhecido, na literatura, os trabalhos que
o descrevem são, em geral, bastante sucintos e foi difícil reunir informações
suficientes para elaborar o meta-modelo.
105

• Um meta-modelo para modelar aplicações que utilizam CORBA - Este
meta-modelo retrata as características e restrições impostas por CORBA. Na
Seção 3.5, apresentamos duas abordagens para retratar CORBA em uma
arquitetura, CORBA como um componente e CORBA como um conector na
arquitetura. Apresentamos as vantagens e desvantagens de cada uma destas
abordagens. A escolha entre elas deve ser cuidadosa, e deve ter em vista as
características do sistema, pois esta escolha pode afetar drasticamente a
arquitetura de um sistema.
• Um meta-modelo para modelar arquiteturas em camadas e distribuídas -
Este meta-modelo integra os conjuntos de restrições impostos pelo estilo
camadas e pelo padrão CORBA, oferecendo informações para modelagem de
uma família de aplicações. Para tanto, adotamos a solução de considerar
CORBA como conector da arquitetura. Desta maneira, ambas as características
podem coexistir em um mesmo modelo.
Os meta-modelos oferecem informações para modelar sub-estilos e arquiteturas
em termos de seus elementos arquiteturais, componentes, conectores, portas e papéis e
modelar, também, estes elementos em termos de atributos e operações. Assim, uma
arquitetura pode ser refinada de uma maneira mais gradual. A nossa proposta é utilizar
os meta-modelos e os estereótipos definidos, de maneira a cobrir as fases de design da
arquitetura (de alto nível de abstração) e o início da fase de design detalhado.
Utilizar os estereótipos para modelar a arquitetura de alto nível, e o diagrama de
classes e seqüência para modelar a arquitetura em um nível mais detalhado é uma
solução para documentar o projeto de um sistema de software. Por enquanto, é
necessário que o projetista seja cuidadoso enquanto realiza a modelagem, pois ele
precisa garantir que os modelos de classe e de estereótipos são consistentes entre si e
consistentes com o meta-modelo que deu origem a eles. Entretanto, esta solução pode
ser automatizada. Esta dissertação pode ser considerada um ponto inicial para criação de
uma ferramenta que automatize a definição de sub-estilos ou de arquiteturas de sistemas
práticos.
106

6.1.2 Modelagem dos Meta-modelos em UML
A escolha da UML para modelar os meta-modelos não foi aleatória. A UML possui
várias características que contribuíram para alcançarmos estes resultados. Utilizá-la
significa proporcionar maior facilidade para as pessoas entenderem e utilizarem os
meta-modelos, pois a UML é fácil de entender e utilizar, é muito difundida,
pesquisadores de diversas áreas têm interesse em integrá-la a métodos e técnicas mais
consistentes e há muito interesse comercial em desenvolver ferramentas que auxiliem
em sua utilização em todas as fases do desenvolvimento de software.
Com a definição dos meta-modelos oferecemos suporte para que a UML
descreva estilos. Como apresentamos na Seção 2.2, a UML não descreve estilos, ou seja
a UML não possui estilos pré-definidos, e nem mesmo o conceito de estilos. Através do
meta-modelo para modelar estilos oferecemos os elementos necessários para descrever
estilos.
6.1.3 Especificação dos Meta-modelos em Z
A especificação dos meta-modelos na linguagem de especificação Z, por sua vez,
objetiva retratar as restrições que não foram ou foram pobremente retratadas pela UML.
As especificações documentam o meta-modelo formalmente. Isto proporciona, ao
projetista, maior facilidade para gerar especificações de produtos baseados nestes metamodelos,
ou seja, o projetista pode reutilizar a especificação ou os tipos definidos pelos
esquemas para criar a especificação de produtos específicos ou sub-estilos.
6.2 Trabalhos Futuros
Vários trabalhos podem ser desenvolvidos a partir desta dissertação. Nós dividimos
estes trabalhos em duas categorias: aqueles relacionados aos próprios meta-modelos e a
abordagem em geral; e aqueles relacionados a ferramentas que facilitem a modelagem e
garantam a consistência entre os vários modelos criados durante o desenvolvimento de
software.
107

6.2.1 Extensões para os Próprios Meta-modelos e a Abordagem em Geral
• Especificar outros estilos e sub-estilos – Por documentar e disponibilizar estilos
em uma linguagem representativa, os meta-modelos podem ser mais facilmente
utilizados. Assim, os estilos podem ser melhor divulgados e utilizados tanto por
pessoas leigas quanto por especialistas. Disponibilizar outros estilos como os
disponibilizados aqui, facilita o uso deles e a composição ou integração deles
com outros.
• Realizar mais estudos de caso – Uma maneira efetiva de melhorar os metamodelos
é aplicá-los a sistemas de software maiores, e avaliar quão bem eles
estão aptos a satisfazer as necessidades de sistemas práticos.
• Estender a especificação em Z – A especificação em Z pode ser estendida para
englobar os estados e a semântica dos elementos arquiteturais. Além disto, é
interessante gerar casos de teste, provas e simulações para a especificação, pois
nós realizamos apenas as verificações de tipos.
• Utilizar os meta-modelos durante a engenharia de software – Nesta dissertação,
propomos os meta-modelos como um artefato que torna a evolução de
arquiteturas um trabalho menos árduo. Entretanto, desenvolver uma metodologia
para o desenvolvimento baseado nestes meta-modelos é crucial para o bom uso
deles. É necessário definir de maneira exata como refinar os meta-modelos para
que eles atinjam um nível de abstração que possa, realmente ser implementado.
• Utilizar os meta-modelos durante a engenharia reversa – De maneira similar,
uma abordagem pode ser criada para transformar modelos implementados em
arquiteturas de software de alta abstração.
6.2.3 Extensões Quanto a Ferramentas
• Ferramentas que integrem os artefatos dos meta-modelos – É de grande
relevância desenvolver ferramentas que integrem os estereótipos definidos aos
diagramas de classes e estes aos diagramas dinâmicos e todos a especificação
formal em Z. É necessário garantir a consistência entre estes modelos.
• Ferramentas que dêem suporte a descrição de estilos baseados nestes metamodelos
– Uma ferramenta que permita a definição de outros estilos tendo como
108

ase o meta-modelo para modelar estilos, permitir a integração de dois ou mais
estilos pré-definidos e, também, a definição de novos elementos adicionais. Com
isto, é possível criar uma biblioteca de estilos pré-definidos, que podem ser
utilizados, ou melhor, reutilizados para a construção de arquiteturas baseadas
neles.
• Ferramentas que dêem suporte à descrição de arquiteturas específicas baseadas
nestes meta-modelos – Uma ferramenta que dê suporte a definição de sistemas
baseados em uma biblioteca de estilos pré-definidos e que possibilite o
refinamento deles, da arquitetura até um nível passível de implementação.
Garantir a consistência entre os diversos artefatos e entre os modelos gerados em
níveis de abstração diferentes tornaria o processo de desenvolvimento mais
efetivo.
109

REFERÊNCIAS BIBLIOGRÁFICAS
[1] ALLEN, R., GARLAN, D.. A formal basis for architectural connection. ACM
Transactions on Software Engineering and Methodology, vol. 6, no. 3, p. 213-
249, July 1997.
[2] BACHMANN, Felix, BASS, Len, CHASTEK, Gary, DONOHOE, Pat e
PERUZZI, Fabio. The architecture based design method. Techinical Report,
Carnegie Mellon University, Pittsburgh, PA, 2000.
[3] BATISTA, Thaís Vasconcelos. Programação concorrente e distribuída – O
padrão CORBA. Notas de aula. UFRN.
[4] BOOCH, Grady, RUMBAUGH, James e JACOBSON, Ivar. The Unified
Modeling Language User Guide. Addison Wesley, 1999.
[5] BOSCH, Jan. Design & Use of Software Architectures. Addison Wesley, 2000.
[6] BREDEMEYER, Dana e MALAN, Ruth. The role of the architect in software
development. Technical report, http://www.bredemeyer.com/role.pdf, 1999.
[7] BUSCHMANN, Frank, MEUNIER, Regine, ROHNERT, Hans, SOMMERLAD,
Peter, STAL, Michael. A system of patterns – Pattern-Oriented Software
Architecture. Wiley, 1996.
[8] CARDOSO, Gustavo D., CARDOSO, Mércia e FRANCIOLI. Capítulo 9 – O
padrão Corba: uma arquitetura baseada em objetos distribuídos.
www.nautilus.com.br/~francioli/
[9] CHENG. Shang-Wen e GARLAN. David. Mapping architectural concepts to
UML-RT. International Conference on Parallel and Distributed Processing
Techniques and Applications, Monte Carlo Resort, Las Vegas, Nevada, USA,
June, 2001.
[10] CLEMENTS, Paul. A survey of architecture description languages. Eighth
International Workshop on Software Specification and Design, Germany, march
1996.
[11] COPLIEN, James. Foundation of pattern concepts and pattern writing. Tutorial,
XV Simpósio Brasileiro em Engenharia de Software, RJ, Brasil, 2001.
110

[12] CUESTA, Carlos E., FUENTE Pablo De La, SOLÓRZANO Manuel Barrio. An
architectural perspective of the static invocation in CORBA. WICSA1 First
Working IFIP Conference on Software Architecture, San Antonio, TX - USA,
February 22-24, 1999. http://www.ece.utexas.edu/~perry/prof/wicsa1/final/quintero.pdf.
[13] CUGOLA, G., DI NITTO, E. e FUGGETTA, A.. Exploiting na event-based
infrastructure to develop complex distributed systems. Proc. 20 th International
Conference on Software Engineering, Kyoto, Japan, pp. 261-270, April 1998.
[14] DASHOFY, Eric, MEDIVIDOVIC, Nenad e TAYLOR, Richard N.. Using offthe-shelf
middleware to implement connectors in distributed software
architectures, ICSE, Los Angeles CA, 1999.
[15] DI NITTO, Elisabetta e ROSENBLUM, David. Exploiting ADLs to Specify
Architectural Syles Induced by Middleware Infrastructures. 21 st International
Conference on Software Engineering (ICSE’ 99), Los Angeles, CA, pp. 13-22,
1999.
[16] DI NITTO, Elisabetta e ROSENBLUM, David. On the role of style in selecting
middleware and underwear. Proceedings os the ICSE’ 99 Workshop on
Engineering Distributed Objects (EDO’ 99), Los Angeles, CA, May 17-18, 1999.
[17] EGYED, Alexander. Integrating Architectural Views in UML. Technical report,
USC/CSE-99-TR-514, march 1999.
[18] EGYED, Alexander, MEHTA, Nikunj e MEDVIDOVIC, Nenad. Software
Connectors and Refinement in Family Architectures. 3º International Workshop –
Software Architectures for Product Families, Las Palmas de Gran Canria, Spain,
March 15-17, 2000.
[19] FARIAS, Cléver R.G., SINDEREN, Marten V. and PIRES, Luís Ferreira. A
Systematic Approach for Component-Based Software Development. In proceeding
of the seventh European Concurrent Engineering Conference, Leicester-United
Kingdom, pp.127-131, april/2000.
[20] FURLAN, José Davi. Modelagem de Objetos através da UML – The Unified
Modeling Language, São Paulo, Makron Books, 1998.
[21] GAMMA, Erich, HELM, Richard, JOHNSON, Ralph e VLISSIDES, John.
Design Patterns – Elements of Reusable Object-Oriented Software. Addison
Wesley, 1995.
111

[22] GARLAN, David, ALLEN, R., OCKERBLOOM, J.. Exploiting style in
architectural design environments. In Proceedings of SIGSOFT’ 94. Foundations
of Software Engineering, pp. 175-188, New Orleans, Louisiana, USA, December
1994.
[23] GARLAN, David. Style-based refinament for software architecture. Proceedings
of SIGSOFT '93: Symposium on the Foundations of Software Engineering,
December, 1993.
[24] GARLAN, David. Higher-order connectors. Workshop on Compositional
Sotware Architrectures, Monterey, CA, 1998.
[25] GARLAN, David, CHENG, Shang-Wen, KOMPANEK, Andrew. Reconciling
the needs of architectural description with object-modeling notations. To Appear.
Science of Computer Programming Journal, Special UML Edition, Elsevier
Science, 2001.
[26] GRABOWSKI, J., GRAUBMANN, P., RUDOLPH, E. The Standardization of
Message Sequence Charts. In Software Engineering Standards Symposium,
Brighton, UK, 1993.
[27] HOFMEISTER, Christine, NORD, Robert, SONI, Dilip. Applied Software
Architecture. Addison Wesley, 2000.
[28] IONA Technologies PLC. Orbix 3.1 – The Iternet ORB. 1999.
www.iona.com/info/products/docs/oweb-whitepaper2.pdf
[29] JACOBSON, Ivar, GRISS, Martin and JONSSON, Patrick. Software Reuse.
Addison Wesley, 1997.
[30] KLEIN, Mark e KAZMAN, Rick. Attribute-based Architectural Styles.
CMU/SEI-99-TR-022, 1999.
[31] LUCKHAM, D.C., VERA, J.. An event-based architecture definition language.
IEEE Transactions on Software Engineering, vol.21, no. 9, pp. 717-734,
September 1995.
[32] MACÊDO, Rodrigo C.. Internet Trader – Um Serviço para Localização de
Objetos Distribuídos na Internet. Dissertação de Mestrado, UFPE, 2000.
[33] MAGEE, J., KRAMER. Dynamic structure in software architectures. In
Poceedings of ACM SIGSOFT’ 96. Fourth Symposium on the Foundations of
Software Engineering (FSE4), pp.3-14, San Francisco, CA, Octuber 1996.
112

[34] MARANHÃO, Dina. Integração da Linguagem de descrição de arquitetura
software ZCL com UML. Relatório de Graduação, UFRN, junho, 2000.
[35] MEDVIDOVIC, Nenad. Architecture-based specification-time software
evolution. Dissertation, University of California, Irvine, CA, 1999.
[36] MEDVIDOVIC, N., ROSENBLUM, D. S., TAYLOR, R. N. A Language and
Enviroment for Architecture-Based Software Development and Evolution. In
Proceedings of the 1999 International Conference on Software Engineering, pp.
44-53, 1999.
[37] MEDVIDOVIC, Nenad and TAYLOR, Richard N.. A Classification and
Comparison Framework for Software Architecture Description Languages. IEEE
Transactions on Software Engineering (TSE), Volume 26, Number 1, pp. 70-93,
January 2000.
[38] MEHTA, Nikunj R., MEDVIDOVIC, Nenad e PHADKE, Sandeep. Towards a
taxonomy of software connectors. ICSE 2000, Proceedings of the 22nd
International Conference on on Software Engineering, pp. 178-187, June 4-11,
2000, Limerick Ireland. ACM, 2000.
[39] Microsoft Corporation. DCOM Technical Overview. 1996.
[40] Object Oriented Concepts – OOC. ORBacus for C++ and Java. 2000.
[41] OMG. A discussion of the object management architecture. www.omg.org
[42] OMG. The object model. www.omg.org
[43] ORA Canada. Software Manual for Windows Z/EVES. Version 2.1, July 2000.
www.ora.on.ca/z-eves/zbrowser.html
[44] ORFALI, Robert e HARKEY, Dan. Client/Server Programming with Java and
CORBA. 2 nd , Wiley, 1998.
[45] PAULA, Virgínia C.C. de. ZCL. A formal framework for specifying dynamic
distributed software architectures. Tese de Doutorado, Universidade Federal de
Pernambuco, Recife, 1999.
[46] RATIONAL. UML Sumary. Versão 1.1, 09/1997. http://www.rational.com/uml
[47] RATIONAL. Especificación del Lenguaje de Restricciones para Objetos.
Versión 1.1, 09/1997. http://www.software.ibm.com/ad/ocl
[48] ROBBINS, Jason, REDMILES, David, ROSEMBLUM, David. Integrating C2
with the Unified Modeling Language. From the Proceedings of the 1997
California Software Symposium, Invirne, CA, November 1997.
113

[49] ROBBINS, Jason, MEDVIDOVIC, Nenad, REDMILES, David, ROSEMBLUM,
David. Integrating architecture description languages with a standard design
method. 20 th International Conference on Software Engineering, Kyoto, Japan,
April 1998.
[50] RUMBAUGH, J., BLAHA. M., PREMERLANI, F., EDDY, F., LORENSEN, W.
. Object-Oriented Modeling and Design, Prentice Hall, 1991.
[51] SHAW, M., DELINE, R., KLEIN, D.V., ROSS, T.L., YOUNG, D.M.
ZELESNIK, G.. Abstractions for software architecture and tools to support them.
IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 314-335, April
1995.
[52] SHAW, Mary, GARLAN, David. Software Architecture – Perspectives on an
Emerging Discipline. Prentice-Hall, 1996.
[53] SILVA, Lyrene F. e PAULA, Virgínia C.C. de. A Arquitetura de Software e a
UML. I Workshop Técnico-Científico – 15 Aos Dimap, UFRN, Brazil, 2000.
[54] SILVA, Lyrene F. e PAULA, Virgínia C.C. de. Arquitetura em Camadas para o
Desenvolvimento Baseado em Componentes. I Workshop sobre Desenvolvimento
Baseado em Componentes, Maringá-PR, Junho 2001.
[55] Sun. A New Approach to Distributed Computing. Microsystems. Inc. 1998.
[56] Sun. Making Distributed Applications Simple and Dynamic. Microsystems. Inc.
1998.
[57] Visigenic Software, Inc., Visibroker for Java. Reference Manual. Version 3.0,
1997.
[58] WOODCOCK, Jim e DAVIES, Jim. Using Z – Specification, Refinement, and
Proof. Prentice Hall, 1996.
[59] WORDSWORTH, J. B. Software Development with Z. Addison Wesley, 1993.
[60] YANG, Zhonghua e DUDDY, Keith. CORBA- A Plataform for Distributed
Object Computing (A State-of-the-Art Report on OMG/CORBA) Operating
Systems Review, vol.30, nº2, Abril, 1996.
114

ANEXO A
- ANÁLISE DA UML COMO LINGUAGEM DE
DESCRIÇÃO DE ARQUITETURA
Esta análise foi parte de um trabalho que nós desenvolvemos na disciplina
Arquitetura de Software e apresentamos no I Workshop Técnico-Científico – 15
Anos Dimap, 2000.
A UML consiste de um conjunto de diagramas pouco integrados, que juntos tentam
oferecer uma visão completa do sistema, dando suporte a todo o processo de
desenvolvimento de sistemas. No entanto, estes diagramas podem ser utilizados da
maneira que melhor se adequar ao desenvolvedor. Pode-se utilizar todos ou apenas
alguns diagramas com nível de detalhamento variado. Esta flexibilidade faz com que
muitos desenvolvedores tentem utilizá-la para descrição de arquiteturas.
Embora não seja uma ADL, a UML, através de seus diagramas, pode representar
parcialmente os aspectos arquiteturais de um sistema, com a vantagem de poder evoluir
gradativamente, expandindo e/ou detalhando, para representar os aspectos
comportamentais até chegar ao nível de implementação.
Apesar de ser capaz de retratar a estrutura gráfica de uma arquitetura, a UML
não pode substituir uma ADL pois, é impossibilitada de desenvolver as funções
avaliativas oferecidas pelas linguagens de descrição de arquiteturas.
Para ter uma visão do quanto a UML se distancia de uma ADL, o questionário
avaliativo [10] de ADLs, foi aplicado à UML. Este questionário é estruturado nas
seguintes categorias: orientado a sistema, orientado a linguagem e orientado a
processos. Como a seguir:
1 - Características orientadas a sistema
São características relacionadas à aplicabilidade do sistema, derivadas da descrição da
arquitetura.
• Permite a descrição de estilos: A UML permite a descrição de estilos através de
meta-modelos. Porém, estes modelos não se encontram ainda a disposição,
constituindo um trabalho interessante a ser realizado.
115

• Que classes de sistema pode ser representado, arquiteturas dinâmicas,
distribuídas, hardware de tempo-real, software de tempo-real: A UML se propõe
a representar qualquer tipo de sistema.
Sob estes aspectos a UML satisfaz, ainda, parcialmente aos requisitos exigidos de uma
ADL.
2 - Características orientadas a linguagem
São características da linguagem em si, independente dos sistemas descritos por ela.
Estes atributos incluem o tipo de informação, geralmente, encontrada no manual de
referência da linguagem. São elas:
• Formalismo: UML não é uma linguagem formal, entretanto possui sua sintaxe e
semântica bem definidas. A sintaxe da representação gráfica é especificada por
um mapeamento dos elementos gráficos em elementos de um modelo semântico
subjacente. A sintaxe e semântica deste modelo subjacente é especificado semiformalmente
via um meta-modelo, texto descritivo e restrições [49]. As
restrições semânticas são expressadas em OCL (Object Constraints Language)
que é uma linguagem textual baseada na lógica de predicados de primeiraordem.
• Completude: UML permite a especificação de sistemas a qualquer nível de
completude, inclusive a nível arquitetural.
• Consistência: UML não provê mecanismos para garantir a consistência de seus
diagramas.
• Escopo da linguagem: UML pode representar informações de hardware, de
software e de documentação e relacionamentos entre eles.
• História de design: UML provê uma boa documentação gráfica de design da
arquitetura.
• Visões: UML suporta várias visões.
• Escalabilidade: UML admite hierarquia, capacidade de subconjunto e herança.
• Poder expressivo: UML trabalha com orientação a objetos.
Sob este aspecto, a UML pode ser referenciada para descrever arquiteturas mas, não
pode ser referenciada como linguagem de descrição de arquitetura pois não é uma
linguagem formal nem provê artifícios para garantir a consistência entre os modelos
(diagramas).
116

3 - Características orientadas a processos
São características de um processo relacionadas ao uso da linguagem para criar, validar,
analisar e refinar uma descrição de arquitetura e construir uma aplicação a partir dela.
São elas:
• Suporte de criação de arquitetura: UML possui editores gráficos.
• Suporte de validação de arquitetura: Não possui.
• Suporte de refinamento da arquitetura: UML permite desenvolvimento
incremental de um sistema. Mas não provê nenhuma ferramenta que garanta a
consistência entre os modelos.
• Suporte de análise de arquitetura: Não possui.
• Aplicação de construção: A ferramenta Rational Rose, para edição de modelos
em UML, é capaz de mapear os modelos construídos para uma linguagem de
programação (escreve os cabeçalhos das classes, e possibilita o desenvolvedor a
escrever o conteúdo delas) e assim, compilar e executar estas linguagens.
Sob este aspecto a UML não provê os principais requisitos, que são ferramentas para
validação e análise de arquiteturas.
Considerações Finais
A UML fornece recursos padronizados (diagramas) para modelagem de sistemas
computacionais. Esta linguagem de modelagem pode ser utilizada para representar,
graficamente, arquiteturas de software. Por outro lado, ela não é capaz, ainda, de
oferecer todo o subsídio que uma linguagem de descrição de arquitetura possui. Isto é
uma questão de tempo, pois existe um grande interesse de pesquisadores em adaptar ou
expandir a UML para que atenda eficientemente estes requisitos.
Vários trabalhos procuram integrar a UML a linguagens formais e/ou linguagens de
descrição de arquiteturas já existentes [34][48][49]. Assim, tentam atrair a parcela de
desenvolvedores que primam por uma linguagem fácil de entender e manipular como a
UML, ao contrário da maioria de linguagens formais que possuem uma sintaxe mais
complicada. Assim, une-se a avaliação analítica, geralmente focada pelos pesquisadores
acadêmicos, com a facilidade de expressão, geralmente focada pelo mundo comercial e
industrial.
117

dir: DIR ž
ž
mode: ž MODE
type: TYPE
ž
Synchonize: SYNCHRONIZATION
serv_ofer: SERVICO ž
ž
propr: Propriedade
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Porta_exp¢¥¢¢¢¤¥¢¢¢£¦¢££¦¢£¢¢¥£¢¢¢¢¥¢¢£
Ϣ
id_port_exp: PORTA ž
ž
serv_req: ž SERVICO
propr: Propriedade
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Componentes£¢¢¤¢¥¢¢¢¢¥¢¤¢¢¥¢¢£¦¢¤¢£¢¢¥¢¢¢¤¥
Ϣ
# conf § 2 Ÿ
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
ANEXO B - ESPECIFICAÇÃO FORMAL EM Z DO META-
MODELO PARA MODELAR ESTILOS.
[PORTA, PAPEL, SERVICO, COMPONENTE, CONECTOR, INTERFACE, CONFIGURAÇÃO,
PAPELIN, PAPELOUT]
DIR ::š entry › exit
TYPE ::š real › integer › string
MODE ::š reply › rereply
SYNCHRONIZATION ::š Synchrono › Assynchrono › Defered_Synchrono
œ¢ Propriedade¢¥¢¤¢¢¥¢¢¢£¦¤¢¢£¦¢£¢¦¤¢£¢¢¢¥¢¢¤¢
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Porta_rec£¢¢¢¥¢¢¤¢¥¢¢¢£¦¢¤¢£¦¢¥¢¢££¢¦£¢¢¢
žœ¢ id_port_rec: PORTA
ž
ž
ž
ž
ž
id_comp: COMPONENTE
in_port: Porta_rec
out_port: Porta_exp
serv_req, serv_ofer: SERVICO
conf: CONFIGURAÇÃO
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
c1, c2: Porta_rec › c1 £ in_port ¤ c2 £ in_port
ž
ž¥¢
c1 . id_port_rec = c2 . id_port_rec ¦ c1 = c2
ž¥¢ ¥
c1, c2: › Porta_exp £ c1 ¤ out_port £ c2 ž out_port
c1 . id_port_exp = c2 . id_port_exp ¦ c1 = c2
ž¥¢
x: SERVICO; y: Porta_rec › y £ in_port ¥ x = y . serv_ofer ¦ x £ serv_ofer
¥
x: SERVICO; y: Porta_exp › y £ out_port ¥ x = y . serv_req ¦ x £ serv_req
ž¥¢
118

ž
id_inpap: PAPEL
ž¥¢
x: Porta_exp › x £ port_exp ¥ x . propr = propr
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
PapelOUT ¢¢¢£¢¢¢¢£¦¢£¢¢¢¢£¢¢¥¦¢¤¢£¢¢¥¢¢¢¤¥
Ϣ
ž
id_outpap: PAPEL
ž¥¢
x: PapelIN › x £ inpap ¥ x . propr = propr
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
RelacPapelPAPEL¢¢£¢¦£¢¢¢¢£¢¢¢¥¢¢¢£¢¢¢¢£¦¢¤¢£¦
Ϣ
Atr2: PAPELOUT ¨ PAPELIN
ž
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
ž
papIN = dom papin
Atr2 £ papOUT ¨ papIN
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
ž
ž port_exp: Porta_exp
outpap: PAPELOUT
PapelIN¢£¢¢¢¢£¢¢¢¥¢¢¢£¢¢¢¢£¦¢¥¤¢¢¢£¢¦£¢¤¢
Ϣ
propr: Propriedade
ž
¡ ¢¤¢¢£¦¢£¢¢¢¢£¢
propr: Propriedade ž
ž
port_rec: ž Porta_rec
inpap: PapelIN
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
x: Porta_rec › x £ port_rec ¥ x . propr = propr
ž¥¢
papIN: PAPELIN
ž
papOUT: PAPELOUT
ž
papin: PAPELIN ¨ PapelIN
ž
papout: PAPELOUT ¨ PapelOUT
ž
ž
Atr1: ¨ PAPELIN PAPELOUT
ž
papOUT = dom papout
ž
Atr1 £ papIN ¨ papOUT
119

ž ¥ c1 . id_outpap = c2 . id_outpap ¦ c1 = c2
# conf § 2 Ÿ
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
ž
ž in_pap: PapelIN
out_pap: PapelOUT
Conectores ¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¢£¢¦£¢¢¢¢£¢¢¢¢£
žœ¢ id_con: CONECTOR
ž
port_pap1: Porta_rec © PapelOUT
ž
conf:
CONFIGURAÇÃO
ž
pap_pap: PapelIN © PapelOUT
ž
port_pap2: Porta_exp © PapelIN
¢¤¢¢£¦¢£¢¢¢¢£¢ ž¥¢
¡
c1, c2: › PapelIN £ c1 ¤ in_pap £ c2 ž in_pap
c1 . id_inpap = c2 . id_inpap ¦ c1 = c2
ž¥¢
c1, c2: PapelOUT › c1 £ out_pap ¤ c2 £ out_pap
¥
in_pap ª « ž
ž
ª « ž¥¢ out_pap
x: Porta_rec; y: ›U¬ x­ y® £ PapelOUT ¥ port_pap1 £ y ž¥¢ out_pap
x: Porta_exp; y: ›U¬ x­ y® £ PapelIN ¥ port_pap2 £ y ž¥¢ in_pap
x: PapelIN; y: ›P¬ x­ y® £ PapelOUT ž ¥
pap_pap
¯ x ¤ in_pap £ y ° out_pap £ x ¤ in_pap ¯ y out_pap
120

ž
comp_comp: Componentes © Componentes
ž
ž
ž
ž
ž
ž
ž
B1: COMPONENTE © CONFIGURAÇÃO
¡
ž
¢¤¢¢£¦¢£¢¢¢¢£¢
conf = dom conf1 ž
ž
con = dom con1
B1 £ comp © conf Ÿ
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Configuração £¢¢¢¤¢¢£¢¢¥¢¢¤¦£¢¢¢¥¢¢¤¢¢£¦¢£¢¢
žœ¢ comp: Componentes
ž
con:
Conectores
port_pap1: Porta_rec © PapelOUT
ž
port_pap2: Porta_exp © PapelIN
ž
ž
pap_pap: © PapelIN PapelOUT
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
c1, c2: Componentes › c1 £ comp ¤ c2 £ comp
ž
ž¥¢
c1 . id_comp = c2 . id_comp ¦ c1 = c2
ž¥¢ ¥
c1, c2: › Conectores £ c1 ¤ con £ c2 ž ¥
con
c1 . id_con = c2 . ¦ id_con c1 = ž¥¢ c2
x: › Componentes £ x ž comp
z: Componentes › z £ comp ¥¬ z­ x® £ comp_comp ° ¬ x­ z® £ comp_comp
ž¥¢
x: Porta_rec; y: PapelOUT
¥±
x­ y® £ port_pap1
ž ¥± cp: Componentes; cn: Conectores › cp £ comp ¤ cn £ con
›U¬
¥¬ x­ y® £ cn . port_pap1 ¤ x £ cp . in_port
x: Porta_exp; y: PapelIN ›U¬ x­ y® £ port_pap2
ž
ž¥¢
cp: Componentes; cn: Conectores › cp £ comp ¤ cn £ con
¥±
¥¬ x­ y® £ cn . port_pap2 ¤ x £ cp . out_port
x: PapelIN; y: PapelOUT ›P¬ x­ y® £ pap_pap
ž¥¢
¥± z, w: Conectores › z £ con ¤ w £ con
ž
¥ x £ z . in_pap ¤ y £ w . out_pap ¤ w . id_con ª z . id_con
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
ž¥¢
¥± z, w: SERVICO › z £ x . serv_req ¤ w £ y . serv_ofer
ž
± k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT;
¤
o: ›U¬ l­ n® £ PapelIN k . ¤ ¬ m­ o® £ port_pap1 k . port_pap2
¥ z = w
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
RelacCONFConf¢¢¢£¦¢££¦¢£¢¢¥¢¤¦¢£¢¢¢¢£¢¢¢¢¥¢
žœ¢ conf: ž CONFIGURAÇÃO
conf1: ¨ CONFIGURAÇÃO Configuração
¥¬ l £ y . in_port ¤ m £ x . out_port®®
ž
ž
con: CONECTOR
comp: COMPONENTE
con1: CONECTOR ¨ Conectores
ž
comp1: COMPONENTE ¨ Componentes
ž
A: CONFIGURAÇÃO © CONECTOR
ž
ž
A1: © CONECTOR ž CONFIGURAÇÃO
B: © CONFIGURAÇÃO COMPONENTE
ž
comp = dom comp1
A £ conf © con ž
ž
£ A1 © con ž conf
£ B © conf comp
121

dir: DIR ž
ž
mode: ž MODE
type: TYPE
ž
Synchonize: SYNCHRONIZATION
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Porta_rec£¢¢¢¥¢¢¤¢¥¢¢¢£¦¢¤¢£¦¢¥¢¢££¢¦£¢¢¢
Ϣ
id_port_rec: PORTA ž
ž
serv_ofer: ž SERVICO
propr: Propriedade
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Porta_exp¢¥¢¢¢¤¥¢¢¢£¦¢££¦¢£¢¢¥£¢¢¢¢¥¢¢£
Ϣ
id_port_exp: PORTA ž
ž
serv_req: ž SERVICO
propr: Propriedade
# conf § 2
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
ANEXO C - ESPECIFICAÇÃO FORMAL EM Z DO META-
MODELO PARA MODELAR ARQUITETURAS EM CAMADAS.
[PORTA, PAPEL, SERVICO, COMPONENTE, CONECTOR, CONFIGURAÇÃO, PAPELOUT,
PAPELIN]
COMUNICAÇÃO ::š top1 › top2 › topbot1 › topbot2 › bot1 › bot2
DIR ::š entry › exit
TYPE ::š real › integer › string
MODE ::š reply › rereply
SYNCHRONIZATION ::š Synchrono › Assynchrono › Defered_Synchrono
œ¢ Propriedade¢¥¢¤¢¢¥¢¢¢£¦¤¢¢£¦¢£¢¦¤¢£¢¢¢¥¢¢¤¢
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Componentes£¢¢¤¢¥¢¢¢¢¥¢¤¢¢¥¢¢£¦¢¤¢£¢¢¥¢¢¢¤¥
žœ¢ id_comp: COMPONENTE
ž
ž
ž
ž
in_port: Porta_rec
out_port: Porta_exp
serv_req, serv_ofer: SERVICO
conf: CONFIGURAÇÃO
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
c1, c2: Porta_rec › c1 £ in_port ¤ c2 £ in_port
ž¥¢
¥ c1 . id_port_rec = c2 . id_port_rec ¦ c1 = c2
ž¥¢
ž
c1, c2: › Porta_exp £ c1 ¤ out_port £ c2 ž out_port
c1 . id_port_exp = c2 . id_port_exp ¦ c1 = c2
ž¥¢ ¥
x: SERVICO; y: › Porta_rec £ y ¥ in_port x = y . ¦ serv_ofer £ x ž¥¢ serv_ofer
x: SERVICO; y: › Porta_exp £ y ¥ out_port x = y . ¦ serv_req £ x serv_req
122

ž
id_inpap: PAPEL
ž¥¢
x: Porta_exp › x £ port_exp ¥ x . propr = propr
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
PapelOUT ¢¢¢£¢¢¢¢£¦¢£¢¢¢¢£¢¢¥¦¢¤¢£¢¢¥¢¢¢¤¥
Ϣ
ž
id_outpap: PAPEL
ž¥¢
x: PapelIN › x £ inpap ¥ x . propr = propr
ž ¥ c1 . id_outpap = c2 . id_outpap ¦ c1 = c2
# conf § 2 Ÿ
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¤¢¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
ž
ž port_exp: Porta_exp
outpap: PAPELOUT
PapelIN¢£¢¢¢¢£¢¢¢¥¢¢¢£¢¢¢¢£¦¢¥¤¢¢¢£¢¦£¢¤¢
Ϣ
propr: Propriedade
ž
¡ ¢¤¢¢£¦¢£¢¢¢¢£¢
propr: Propriedade ž
ž
port_rec: ž Porta_rec
inpap: PapelIN
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
x: Porta_rec › x £ port_rec ¥ x . propr = propr
ž¥¢
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Conectores ¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¦£¢¢¢¢¤¥¢¢¢£
žœ¢ id_con: CONECTOR
ž
ž in_pap: PapelIN
out_pap: PapelOUT
ž
port_pap1: Porta_rec © PapelOUT
ž
conf:
CONFIGURAÇÃO
ž
pap_pap: PapelIN © PapelOUT
ž
port_pap2: Porta_exp © PapelIN
¢¤¢¢£¦¢£¢¢¢¢£¢ ž¥¢
¡
c1, c2: › PapelIN £ c1 ¤ in_pap £ c2 ž in_pap
c1 . id_inpap = c2 . id_inpap ¦ c1 = c2
ž¥¢ ¥
c1, c2: › PapelOUT £ c1 ¤ out_pap £ c2 out_pap
in_pap ª « ž
out_pap ª « ž¥¢
ž
x: PapelIN; y: ›P¬ x­ y® £ PapelOUT ž pap_pap
x ¯ in_pap ¤ y £ out_pap ° x £ in_pap ¤ y ¯ out_pap
¥
123

ž
comp_comp: Componentes © Componentes
ž
ž
ž
ž
ž
ž
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
RelacCONFConf¢¢¢£¦¢££¦¢£¢¢¥¢¤¦¢£¢¢¢¢£¢¢¢¢¥¢
Ϣ
B1: COMPONENTE © CONFIGURAÇÃO
¡
ž
¢¤¢¢£¦¢£¢¢¢¢£¢
conf = dom conf1
ž
con = dom con1
ž
B1 £ comp © conf
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
Configuração £¢¢¢¤¢¢£¢¢¥¢¢¤¦£¢¢¢¥¢¢¤¢¢£¦¢£¢¢
žœ¢ comp: Componentes
ž
con:
Conectores
port_pap1: Porta_rec © PapelOUT
ž
port_pap2: Porta_exp © PapelIN
ž
pap_pap: PapelIN © PapelOUT
ž
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
c1, c2: Componentes › c1 £ comp ¤ c2 £ comp
ž
ž¥¢
c1 . id_comp = c2 . id_comp ¦ c1 = c2
ž¥¢ ¥
c1, c2: › Conectores £ c1 ¤ con £ c2 ž ¥
con
c1 . id_con = c2 . ¦ id_con c1 = ž¥¢ c2
x: › Componentes £ x ž comp
z: Componentes › z £ comp ¥¬ z­ x® £ comp_comp ° ¬ x­ z® £ comp_comp
ž¥¢
x: Porta_rec; y: PapelOUT ›U¬ x­ y® £ port_pap1
¥±
¥± cp: Componentes; cn: Conectores › cp £ comp ¤ cn £ con
ž
¥¬ x­ y® £ cn . port_pap1 ¤ x £ cp . in_port
x: Porta_exp; y: PapelIN ›U¬ x­ y® £ port_pap2
ž
ž¥¢
cp: Componentes; cn: Conectores › cp £ comp ¤ cn £ con
¥±
¥¬ x­ y® £ cn . port_pap2 ¤ x £ cp . out_port
x: PapelIN; y: PapelOUT ›P¬ x­ y® £ pap_pap
ž¥¢
¥± z, w: Conectores › z £ con ¤ w £ con
ž
¥ x £ z . in_pap ¤ y £ w . out_pap ¤ w . id_con ª z . id_con
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
ž
ž¥¢
z, w: SERVICO › z £ x . serv_req ¤ w £ y . serv_ofer
¥±
± k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT;
¤
o: ›U¬ l­ n® £ PapelIN k . ¤ ¬ m­ o® £ port_pap1 k . port_pap2
¥ z = w
conf:
ž
con:
ž
¥¬ l £ y . in_port ¤ m £ x . out_port®®
CONFIGURAÇÃO
conf1: CONFIGURAÇÃO ¨ Configuração
ž
ž CONECTOR
con1: ¨ CONECTOR Conectores
ž
comp:
COMPONENTE
comp1: COMPONENTE ¨ Componentes
ž
A: CONFIGURAÇÃO © CONECTOR
ž
A1: CONECTOR © CONFIGURAÇÃO
ž
ž
B: © CONFIGURAÇÃO COMPONENTE
ž
comp = dom comp1
A £ conf © con
ž
A1 £ con © conf ž
ž
£ B © conf comp
124

Configuração
ž
tipo_interação: COMUNICAÇÃO
ž
ž
nível: Componentes ¨ ²
³ ¬¢
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
ž
ž
ž ³ ¬¢
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
³ ¬¢
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
ž
ž
³ ¬¢
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
ž
ž
³ ¬¢
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
ž
ž
³ ¬¢
x, y: Componentes › x £ comp ¤ y £ comp ¤ ¬ x­ y® £ comp_comp
ž
ž
¢¤¢¢£¦¢£¢¢¢¢£¢¢¥¢¢¢¤¥¢¢¢¢¥¢¢£¢¢¢¢£¦¢¤¢
Ÿ
œ¢ Configuração_Camadas ¢¢¢¢£¢¤¢¢¢¢£¢¦¥¤¢¢¢£¢¦£¢¤¢¦
¢¤¢¢£¦¢£¢¢¢¢£¢ ¡
x: Componentes; y: ² ›P¬ x­ y® £ nível ¥ x £ comp
ž
ž¥¢
tipo_interação = bot1 ¬
¥ nível x = nível y - 1®®
ž ° ¬ tipo_interação = topbot1
¥ nível x = nível y + 1 ° nível x = nível y - 1®®
ž ° ¬ tipo_interação = topbot2
¥ nível x ª nível y®®
ž ° ¬ tipo_interação = top2
¥ nível x ´ nível y®>®
125

dir: DIR
¹
mode: MODE ¹
¹
type: TYPE
¹
Synchronize: SYNCHRONIZATION
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_rec¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸¥¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸£¸¦¸¢¸¥¸¢¸¢¸£¸¸£¸¢¸¦¸£¸¢¸¢¸¢¸
·¢¸
id_port_rec: PORTA
¹
serv_ofer: SERVICO ¹
¹
propr: Propriedade
serv_req: SERVICO
¹
propr: Propriedade
¹
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_div¸¢¸¢¸¢¸¢¸£¸¢¸¦¸£¸¢¸¤¸¢¸¦¸£¸¢¸¢¸¢¸¥¸¤¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¢¸¤¸¦¸¢¸£¸¢¸¢¸
·¢¸
Porta_exp ¹
¹
interface: INTERFACE
º ¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
ANEXO D - ESPECIFICAÇÃO FORMAL EM Z DO META-
MODELO PARA MODELAR APLICAÇÕES BASEADAS EM CORBA
– CORBA COMO UM CONECTOR DA ARQUITETURA.
[PORTA, PAPEL, SERVICO, COMPONENTE, CONECTOR, INTERFACE, CONFIGURAÇÃO,
PAPELIN, PAPELOUT]
DIR ::µ entry exit
TYPE ::µ real integer string
MODE ::µ reply rereply
SYNCHRONIZATION ::µ Synchrono Assynchrono Defered_Synchrono
·¢¸ Propriedade¸¢¸¥¸¢¸¤¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¦¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¦¸¤¸¢¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_exp¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸£¸¦¸¢¸£¸¸£¸¦¸¢¸£¸¢¸¢¸¥¸¸£¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¸
¹ ·¢¸
id_port_exp: PORTA
126

¹
conf: » CONFIGURAÇÃO
¹
# conf  2
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
PapelIN_C¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¤¸¦¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¦¸
·¢¸
¹
id_inpap: PAPEL
¹
outpap: » PAPELOUT
¹
inpap: » PapelIN_C
x: PapelIN_C x ¾ inpap À x . propr = propr
¹¥½
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Componentes_C¸¢¸¢¸¢¸£¸¸£¸¢¸¦¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¥¸¦¸£¸¢¸¤¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¢¸
¹ ·¢¸
id_comp: ¹ COMPONENTE
» in_port: Porta_rec
out_port: » Porta_exp
¹
div_port: » Porta_div
¹
¹
serv_req, serv_ofer: » SERVICO
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: Porta_rec c1 ¾ in_port ¿ c2 ¾ in_port
¹
¹¥½
c1 . id_port_rec = c2 . id_port_rec Á c1 = c2
¹¥½ À
c1, c2: Porta_exp ¾ c1 ¿ out_port ¾ c2 ¹ À
out_port
c1 . id_port_exp = c2 . Á id_port_exp c1 = ¹¥½ c2
c1, c2: Porta_div ¾ c1 ¿ div_port ¾ c2 ¹ div_port
c1 . id_port_exp = c2 . id_port_exp Á c1 = c2
¹¥½
x: SERVICO; y: Porta_rec y ¾ in_port À x = y . serv_ofer Á x ¾ serv_ofer
À
¹¥½
x: SERVICO; y: Porta_exp y ¾ out_port À x = y . serv_req Á x ¾ serv_req
¹
propr: Propriedade
port_exp: » Porta_exp
¹
port_div: » Porta_div
¹
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
x: Porta_exp x ¾ port_exp À x . propr = propr
¹¥½
¹¥½
x: Porta_div ¾ x À port_div x . propr = propr
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
PapelOUT ¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¦¸¢¸¤¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸
¹ ·¢¸
id_outpap: PAPEL
¹
propr: Propriedade
¹
port_rec: » Porta_rec
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
x: Porta_rec x ¾ port_rec À x . propr = propr
¹¥½
127

¹
conf: » CONFIGURAÇÃO
¹ À x Ç in_pap ¿ y ¾ out_pap È x ¾ in_pap ¿ y Ç out_pap
# conf  2 º
¹
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
Conectores_C ¸¤¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¸¥¸¢¸¢¸£¸¢¸¦¸£¸¢¸¤¸¦¸¢¸£¸¢¸¢¸¢¸¢¸¥¸¤¸¢¸¢¸¢¸
¹ ·¢¸
id_con: ¹ CONECTOR
» in_pap: PapelIN_C
out_pap: » PapelOUT
¹
port_pap1: Porta_rec à PapelOUT
¹
port_pap2: Porta_exp à PapelIN_C
¹
¹
port_pap3: Ã Porta_div PapelIN_C
¹
pap_pap: PapelIN_C Ã PapelOUT
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: PapelIN_C c1 ¾ in_pap ¿ c2 ¾ in_pap
¹¥½
À c1 . id_inpap = c2 . id_inpap Á c1 = c2
¹¥½
¹
c1, c2: PapelOUT ¾ c1 ¿ out_pap ¾ c2 ¹ out_pap
c1 . id_outpap = c2 . id_outpap Á c1 = c2
¹¥½
x: PapelIN_C; y: PapelOUT PÄ xÅ yÆ ¾ pap_pap
À
in_pap É Ê ¹
¹
É Ê ¹¥½out_pap x: Porta_rec; y: UÄ xÅ yÆ ¾ PapelOUT À port_pap1 ¾ y ¹¥½ out_pap
x: Porta_exp; y: UÄ xÅ yÆ ¾ PapelIN_C À port_pap2 ¾ y ¹¥½ in_pap
x: PapelIN_C; y: PÄ xÅ yÆ ¾ PapelOUT pap_pap
¹ À x Ç in_pap ¿ y ¾ out_pap È x ¾ in_pap ¿ y Ç out_pap
128

¹
comp_comp: Componentes_C Ã Componentes_C
¹ ¿ ÄË k: Conectores_C; l: Porta_rec; m: Porta_exp; n: PapelOUT; o,
¿ Ä jÅ pÆ ¾ k . port_pap3
¹
À Ä l ¾ y . in_port ¿ m ¾ x . out_port ¿ j ¾ y . div_portÆ>Æ
º
¹
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
¹
comp: » Componentes_C
Configuração_CORBA ¸¤¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¥¸¤¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¸£¸¦¸¢¸£¸¢¸¢¸¥¸¢¸
·¢¸
con: » Conectores_C ¹
¹
port_pap1: Ã Porta_rec PapelOUT
port_pap2: Porta_exp à PapelIN_C
¹
port_pap3: Porta_div à PapelIN_C
¹
¹
pap_pap: PapelIN_C Ã PapelOUT
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¹¥½
¼
c1, c2: Componentes_C ¾ c1 ¿ comp ¾ c2 ¹ comp
c1 . id_comp = c2 . id_comp Á c1 = c2
¹¥½
c1, c2: Conectores_C c1 ¾ con ¿ c2 ¾ con
À
À c1 . id_con = c2 . id_con Á c1 = c2
¹
x: Componentes_C x ¾ comp
¹
¹¥½
z: Componentes_C z ¾ comp À Ä zÅ xÆ ¾ comp_comp È Ä xÅ zÆ ¾ comp_comp
¹¥½ ÀË
x: Porta_rec; y: UÄ xÅ yÆ ¾ PapelOUT ¹ port_pap1
cp: Componentes_C; cn: Conectores_C cp ¾ comp ¿ cn ¾ con
¹ À Ä xÅ yÆ ¾ cn . port_pap1 ¿ x ¾ cp . in_port
ÀË
x: Porta_exp; y: PapelIN_C UÄ xÅ yÆ ¾ port_pap2
¹¥½
ÀË cp: Componentes_C; cn: Conectores_C cp ¾ comp ¿ cn ¾ con
¹
¹
Ä xÅ yÆ ¾ cn . port_pap2 ¿ x ¾ cp . out_port
¹¥½ À
x: Porta_div; y: UÄ xÅ yÆ ¾ PapelIN_C ¹ port_pap3
cp: Componentes_C; cn: Conectores_C cp ¾ comp ¿ cn ¾ con
¹ À Ä xÅ yÆ ¾ cn . port_pap3 ¿ x ¾ cp . div_port
ÀË
x: PapelIN_C; y: PapelOUT PÄ xÅ yÆ ¾ pap_pap
¹¥½
ÀË z, w: Conectores_C z ¾ con ¿ w ¾ con
¹
¹
x ¾ z . in_pap ¿ y ¾ w . out_pap ¿ w . id_con É z . id_con
¹¥½ À
x, y: Componentes_C ¾ x ¿ comp ¾ y ¿ Ä xÅ yÆ ¾ comp ¹ comp_comp
z, w: SERVICO z ¾ x . serv_req ¿ w ¾ y . serv_ofer
¹ À z = w
ÀË
¹
p: PapelIN_C; j: Porta_div
PÄ lÅ nÆ ¾ k . port_pap1
¹
¿ Ä mÅ oÆ ¾ k . port_pap2
¹
129

dir: DIR ¹
¹
mode: ¹ MODE
type: TYPE
¹
Synchronize: SYNCHRONIZATION
serv_ofer: SERVICO ¹
¹
propr: Propriedade
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_exp¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸£¸¦¸¢¸£¸¸£¸¦¸¢¸£¸¢¸¢¸¥¸¸£¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¸
·¢¸
id_port_exp: PORTA ¹
¹
serv_req: ¹ SERVICO
propr: Propriedade
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_div¸¢¸¢¸¢¸¢¸£¸¢¸¦¸£¸¢¸¤¸¢¸¦¸£¸¢¸¢¸¢¸¥¸¤¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¢¸¤¸¦¸¢¸£¸¢¸¢¸
·¢¸
Porta_exp ¹
¹
interface: INTERFACE
º ¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
ANEXO E - ESPECIFICAÇÃO FORMAL EM Z DO META-
MODELO PARA MODELAR APLICAÇÕES BASEADAS EM CORBA
– CORBA COMO UM COMPONENTE DA ARQUITETURA.
[PORTA, PAPEL, SERVICO, COMPONENTE, CONECTOR, INTERFACE, CONFIGURAÇÃO,
PAPELIN, PAPELOUT]
DIR ::µ entry exit
TYPE ::µ real integer string
MODE ::µ reply rereply
SYNCHRONIZATION ::µ Synchrono Assynchrono Defered_Synchrono
·¢¸ Propriedade¸¢¸¥¸¢¸¤¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¦¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¦¸¤¸¢¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_rec¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸¥¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸£¸¦¸¢¸¥¸¢¸¢¸£¸¸£¸¢¸¦¸£¸¢¸¢¸¢¸
¹ ·¢¸
id_port_rec: PORTA
130

¹
conf: » CONFIGURAÇÃO
¹
# conf  2
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Comp_da_aplicação¸¤¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¥¸¢¸¤¸¢¸¢¸¥¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸
·¢¸
¹
div_port: » Porta_div
¹ À c1 . id_port_exp = c2 . id_port_exp Á c1 = c2
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Comp_CORBA ¸¤¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¥¸¢¸¤¸¢¸¢¸¥¸¢¸
·¢¸
¹
div_port: » Porta_div
x: Porta_div x ¾ port_div À x . propr = propr
º
¹¥½
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
·¢¸ Componentes¸£¸¢¸¢¸¤¸¢¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¤¸¢¸¢¸¥¸¢¸¢¸£¸¦¸¢¸¤¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸
¹
id_comp: COMPONENTE
in_port: » Porta_rec ¹
¹
» out_port: Porta_exp
¹
serv_req, serv_ofer: » SERVICO
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: Porta_rec c1 ¾ in_port ¿ c2 ¾ in_port
¹¥½
À c1 . id_port_rec = c2 . id_port_rec Á c1 = c2
¹¥½
¹
c1, c2: Porta_exp ¾ c1 ¿ out_port ¾ c2 ¹ out_port
c1 . id_port_exp = c2 . id_port_exp Á c1 = c2
¹¥½
x: SERVICO; y: Porta_rec y ¾ in_port À x = y . serv_ofer Á x ¾ serv_ofer
À
¹¥½
x: SERVICO; y: Porta_exp y ¾ out_port À x = y . serv_req Á x ¾ serv_req
¹
Componentes
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: Porta_div c1 ¾ div_port ¿ c2 ¾ div_port
¹¥½
¹
Componentes
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¹¥½
¼
c1, c2: Porta_div ¾ c1 ¿ div_port ¾ c2 ¹ div_port
c1 . id_port_exp = c2 . id_port_exp Á c1 = c2
À
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
PapelIN¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¥¸¤¸¢¸¢¸¢¸£¸¢¸¦¸£¸¢¸¤¸¢¸
¹ ·¢¸
id_inpap: PAPEL
¹
propr: Propriedade
port_exp: » Porta_exp ¹
¹
» port_div: ¹ Porta_div
» outpap: ¼ ¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸
PAPELOUT
¹¥½
x: Porta_exp x ¾ port_exp À x . propr = propr
131

¹
id_outpap: PAPEL
¹
inpap: » PapelIN
¹¥½
x: PapelIN x ¾ inpap À x . propr = propr
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Conectores ¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¢¸£¸¢¸¦¸£¸¢¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸£¸
·¢¸
¹
conf: » CONFIGURAÇÃO
¹ À c1 . id_outpap = c2 . id_outpap Á c1 = c2
# conf  2
¹
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
·¢¸ PapelOUT ¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¦¸¢¸¤¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸
¹
propr: Propriedade
¹
port_rec: » Porta_rec
¼ ¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸
¹¥½
x: Porta_rec x ¾ port_rec À x . propr = propr
¹
id_con: CONECTOR
¹
in_pap: » PapelIN
out_pap: » PapelOUT
¹
port_pap1: Porta_rec à PapelOUT
¹
port_pap2: Porta_exp à PapelIN
¹
¹
port_pap3: Ã Porta_div PapelIN
¹
pap_pap: PapelIN Ã PapelOUT
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: PapelIN c1 ¾ in_pap ¿ c2 ¾ in_pap
¹¥½
À c1 . id_inpap = c2 . id_inpap Á c1 = c2
¹
c1, c2: PapelOUT c1 ¾ out_pap ¿ c2 ¾ out_pap
¹¥½
in_pap É Ê ¹
out_pap É Ê ¹
x: PapelIN; y: PapelOUT PÄ xÅ yÆ ¾ pap_pap
¹¥½
¹ À x Ç in_pap ¿ y ¾ out_pap È x ¾ in_pap ¿ y Ç out_pap
132

¹
comp_comp: Componentes à Componentes
o: PapelIN UÄ lÅ nÆ ¾ k . port_pap1 ¿ Ä mÅ oÆ ¾ k . port_pap2
¹
À Ä l ¾ y . in_port ¿ m ¾ x . out_portÆÆ
¹
¹
corb_corb: Comp_CORBA Ã Comp_CORBA
¹¥½
x: Porta_rec; y: PapelOUT UÄ xÅ yÆ ¾ port_pap1
Configuração ¸£¸¢¸¢¸¢¸¤¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¤¸¦¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸
¹ ·¢¸
» comp: ¹ Componentes
» con: ¹ Conectores
port_pap1: Ã Porta_rec ¹ PapelOUT
port_pap2: Ã Porta_exp PapelIN
¹
pap_pap: PapelIN Ã PapelOUT
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: Componentes c1 ¾ comp ¿ c2 ¾ comp
¹
¹¥½
c1 . id_comp = c2 . id_comp Á c1 = c2
¹¥½ À
c1, c2: Conectores ¾ c1 ¿ con ¾ c2 ¹ À
con
c1 . id_con = c2 . Á id_con c1 = ¹¥½ c2
x: Componentes ¾ x ¹ comp
z: Componentes z ¾ comp À Ä zÅ xÆ ¾ comp_comp È Ä xÅ zÆ ¾ comp_comp
¹¥½
x: Porta_rec; y: PapelOUT UÄ xÅ yÆ ¾ port_pap1
ÀË
ÀË cp: Componentes; cn: Conectores cp ¾ comp ¿ cn ¾ con
¹
À Ä xÅ yÆ ¾ cn . port_pap1 ¿ x ¾ cp . in_port
¹¥½
¹
x: Porta_exp; y: UÄ xÅ yÆ ¾ PapelIN ¹ ÀË
port_pap2
cp: Componentes; cn: Conectores ¾ cp ¿ comp ¾ cn ¹ con
Ä xÅ yÆ ¾ cn . port_pap2 ¿ x ¾ cp . out_port
¹¥½
x: PapelIN; y: PapelOUT PÄ xÅ yÆ ¾ pap_pap
À
ÀË z, w: Conectores z ¾ con ¿ w ¾ con
¹
À x ¾ z . in_pap ¿ y ¾ w . out_pap ¿ w . id_con É z . id_con
¹¥½
¹
x, y: Componentes ¾ x ¿ comp ¾ y ¿ Ä xÅ yÆ ¾ comp ¹ ÀË
comp_comp
z, w: SERVICO ¾ z x . ¿ serv_req ¾ w y . ¹ serv_ofer
z = w ¹ ¿ ÄË k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT;
À
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Configuração_CORBA ¸¤¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¥¸¤¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¸£¸¦¸¢¸£¸¢¸¢¸¥¸¢¸
¹ ·¢¸
» comp: Comp_da_aplicação
corb: » Comp_CORBA
¹
con: » Conectores
¹
port_pap1: Porta_rec à PapelOUT
¹
¹
port_pap2: Ã Porta_exp ¹ PapelIN
port_pap3: Ã Porta_div PapelIN
pap_pap: PapelIN Ã PapelOUT
¹
¹
corb_comp: Ã Comp_CORBA ¹ Comp_da_aplicação
comp_corb: Ã Comp_da_aplicação Comp_CORBA
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: Comp_da_aplicação c1 ¾ comp ¿ c2 ¾ comp
¹
¹¥½
c1 . id_comp = c2 . id_comp Á c1 = c2
¹¥½ À
c1, c2: Comp_CORBA ¾ c1 ¿ corb ¾ c2 ¹ corb
c1 . id_comp = c2 . id_comp Á c1 = c2
¹¥½
c1, c2: Conectores c1 ¾ con ¿ c2 ¾ con
À
À c1 . id_con = c2 . id_con Á c1 = c2
¹
x: Comp_da_aplicação x ¾ comp
¹
¹¥½
z: Comp_CORBA z ¾ corb À Ä zÅ xÆ ¾ corb_comp È Ä xÅ zÆ ¾ comp_corb
ÀË
133

¹ À x ¾ z . in_pap ¿ y ¾ w . out_pap ¿ w . id_con É z . id_con
¹ ¿ ÄË k, j: Conectores; l, r: Porta_rec; m: Porta_exp; n, s: PapelOUT;
¹ ¿ q ¾ y . div_port
¹
o: PapelIN UÄ lÅ nÆ ¾ k . port_pap1 ¿ Ä mÅ oÆ ¾ k . port_pap2
¹ ¿ ÄË k, j: Conectores; l, r: Porta_rec; m: Porta_exp; n, s: PapelOUT;
¿ q ¾ y . div_port
¹
¿ r ¾ x . in_portÆÆ
¹
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
ÀË cp: Comp_da_aplicação; cn: Conectores cp ¾ comp ¿ cn ¾ con
¹
À Ä xÅ yÆ ¾ cn . port_pap1 ¿ x ¾ cp . in_port
¹
x: Porta_exp; y: PapelIN UÄ xÅ yÆ ¾ port_pap2
¹
¹¥½
cp: Comp_da_aplicação; cn: Conectores cp ¾ comp ¿ cn ¾ con
ÀË
¹ À Ä xÅ yÆ ¾ cn . port_pap2 ¿ x ¾ cp . out_port
x: Porta_div; y: PapelIN PÄ xÅ yÆ ¾ port_pap3
¹
¹¥½
cp: Comp_da_aplicação; cn: Conectores cp ¾ comp ¿ cn ¾ con
¹ ÀË
Ä xÅ yÆ ¾ cn . port_pap3 ¿ x ¾ cp . div_port
¹¥½
x: PapelIN; y: PapelOUT PÄ
À
yÆ ¾ pap_pap
xÅ
¹ ÀË z, w: Conectores z ¾ con ¿ w ¾ con
¹¥½
x: Comp_CORBA; y: Comp_da_aplicação
¹ x ¾ corb ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ corb_comp
ÀË z, w: SERVICO z ¾ x . serv_req ¿ w ¾ y . serv_ofer
¹
¹
z = w À
¹
o, p: PapelIN; q: Porta_div
PÄ lÅ nÆ ¾ k . port_pap1
¹
¹
Ä mÅ oÆ ¾ k . port_pap2
¹ ¿
Ä qÅ pÆ ¾ j . port_pap3
¹ ¿ Ä
¿
sÆ ¾ j . port_pap1
¹ rÅ
Ä l ¾ y . in_port ¹ ¿
À
¾ m x . out_port
¿ r ¾ x . in_portÆÆ
¹
x ¾ comp ¿ y ¾ corb ¿ Ä xÅ yÆ ¾ comp_corb
¹
¹¥½
x: Comp_da_aplicação; y: Comp_CORBA
ÀË z, w: SERVICO z ¾ x . serv_req ¿ w ¾ y . serv_ofer
¹
À z = w
¹
¹ ¿ ÄË k: Conectores; l: Porta_rec; m: Porta_exp; n: PapelOUT;
À Ä l ¾ y . in_port ¿ m ¾ x . out_portÆÆ
¹¥½
¹
x, y: Comp_CORBA ¾ x ¿ corb ¾ y ¿ Ä xÅ yÆ ¾ corb corb_corb
ÀË z, w: SERVICO z ¾ x . serv_req ¿ w ¾ y . serv_ofer
¹
¹
z = w À
¹
o, p: PapelIN; q: Porta_div
PÄ lÅ nÆ ¾ k . port_pap1
¹
¿ Ä mÅ oÆ ¾ k . port_pap2
¹
¿ Ä qÅ pÆ ¾ j . port_pap3
¹
¹
Ä rÅ sÆ ¾ j . port_pap1
¹ ¿
Ä l ¾ y . in_port ¹ ¿ m ¾ x . out_port
À
134

dir: DIR ¹
¹
mode: ¹ MODE
type: TYPE
¹
Synchronize: SYNCHRONIZATION
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_rec¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸£¸¦¸¢¸£¸¸£¸¦¸¢¸¥¸¢¸¢¸£¸¸£¸¢¸¦¸£¸¢¸¢¸¢¸
·¢¸
id_port_rec: PORTA ¹
¹
serv_ofer: ¹ SERVICO
propr: Propriedade
serv_req: SERVICO ¹
¹
propr: Propriedade
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_div¸¢¸¢¸¢¸¢¸£¸¢¸¦¸£¸¢¸¤¸¢¸¦¸£¸¢¸¢¸¢¸¥¸¤¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¢¸¤¸¦¸¢¸£¸¢¸¢¸
·¢¸
Porta_exp ¹
¹
interface: INTERFACE
º ¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
ANEXO F - ESPECIFICAÇÃO FORMAL EM Z DO META-
MODELO PARA MODELAR UMA FAMÍLIA DE APLICAÇÕES
DISTRIBUÍDAS COM MIDDLEWARE CORBA.
[PORTA, PAPEL, SERVICO, COMPONENTE, CONECTOR, INTERFACE, CONFIGURAÇÃO,
PAPELIN, PAPELOUT]
COMUNICAÇÃO ::µ top1 top2 topbot1 topbot2 bot1 bot2
DIR ::µ entry exit
TYPE ::µ real integer string
MODE ::µ reply rereply
SYNCHRONIZATION ::µ Synchrono Assynchrono Defered_Synchrono
·¢¸ Propriedade¸¢¸¥¸¢¸¤¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¦¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¦¸¤¸¢¸£¸¢¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Porta_exp¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸£¸¦¸¢¸£¸¸£¸¦¸¢¸£¸¢¸¢¸¥¸¸£¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¸
¹ ·¢¸
id_port_exp: PORTA
135

¹
conf: » CONFIGURAÇÃO
¹
# conf  2
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
PapelIN_C¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¤¸¦¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¦¸
·¢¸
¹
id_inpap: PAPEL
¹
outpap: » PAPELOUT
¹
inpap: » PapelIN_C
x: PapelIN_C x ¾ inpap À x . propr = propr
¹¥½
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Componentes_C¸¢¸¢¸¢¸£¸¸£¸¢¸¦¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¥¸¦¸£¸¢¸¤¸¢¸¢¸¢¸¥¸¢¸¢¸¢¸£¸¢¸
¹ ·¢¸
id_comp: ¹ COMPONENTE
» in_port: Porta_rec
out_port: » Porta_exp
¹
div_port: » Porta_div
¹
¹
serv_req, serv_ofer: » SERVICO
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: Porta_rec c1 ¾ in_port ¿ c2 ¾ in_port
¹
¹¥½
c1 . id_port_rec = c2 . id_port_rec Á c1 = c2
¹¥½ À
c1, c2: Porta_exp ¾ c1 ¿ out_port ¾ c2 ¹ À
out_port
c1 . id_port_exp = c2 . Á id_port_exp c1 = ¹¥½ c2
c1, c2: Porta_div ¾ c1 ¿ div_port ¾ c2 ¹ div_port
c1 . id_port_exp = c2 . id_port_exp Á c1 = c2
¹¥½
x: SERVICO; y: Porta_rec y ¾ in_port À x = y . serv_ofer Á x ¾ serv_ofer
À
¹¥½
x: SERVICO; y: Porta_exp y ¾ out_port À x = y . serv_req Á x ¾ serv_req
¹
propr: Propriedade
port_exp: » Porta_exp
¹
port_div: » Porta_div
¹
¸¤¸¢¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
x: Porta_exp x ¾ port_exp À x . propr = propr
¹¥½
¹¥½
x: Porta_div ¾ x À port_div x . propr = propr
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
PapelOUT ¸¢¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¦¸¢¸¤¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸
¹ ·¢¸
id_outpap: PAPEL
¹
propr: Propriedade
¹
port_rec: » Porta_rec
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
x: Porta_rec x ¾ port_rec À x . propr = propr
¹¥½
136

¹
conf: » CONFIGURAÇÃO
¹ À x Ç in_pap ¿ y ¾ out_pap È x ¾ in_pap ¿ y Ç out_pap
¹
# conf  2
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
º
Configuração_CORBA_Camadas ¸¢¸¢¸£¸¸£¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸¤¸¢¸£¸¢¸¦¸£¸¢¸¢¸¢¸¢¸£¸¢¸
·¢¸
comp_comp: Componentes_C Ã Componentes_C
¹
¹
nível: Ì Í
Componentes_C
¹
tipo_interação: COMUNICAÇÃO
¹¥½
x: PapelIN_C; y: PapelOUT PÄ xÅ yÆ ¾ pap_pap
Conectores_C ¸¤¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¸¥¸¢¸¢¸£¸¢¸¦¸£¸¢¸¤¸¦¸¢¸£¸¢¸¢¸¢¸¢¸¥¸¤¸¢¸¢¸¢¸
¹ ·¢¸
id_con: ¹ CONECTOR
» in_pap: PapelIN_C
out_pap: » PapelOUT
¹
port_pap1: Porta_rec à PapelOUT
¹
port_pap2: Porta_exp à PapelIN_C
¹
¹
port_pap3: Ã Porta_div PapelIN_C
¹
pap_pap: PapelIN_C Ã PapelOUT
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¼
c1, c2: PapelIN_C c1 ¾ in_pap ¿ c2 ¾ in_pap
¹¥½
À c1 . id_inpap = c2 . id_inpap Á c1 = c2
¹¥½
¹
c1, c2: PapelOUT ¾ c1 ¿ out_pap ¾ c2 ¹ out_pap
c1 . id_outpap = c2 . id_outpap Á c1 = c2
¹¥½
x: PapelIN_C; y: PapelOUT PÄ xÅ yÆ ¾ pap_pap
À
in_pap É Ê ¹
¹
É Ê ¹¥½out_pap x: Porta_rec; y: UÄ xÅ yÆ ¾ PapelOUT À port_pap1 ¾ y ¹¥½ out_pap
x: Porta_exp; y: UÄ xÅ yÆ ¾ PapelIN_C À port_pap2 ¾ y ¹¥½ in_pap
x: PapelIN_C; y: PÄ xÅ yÆ ¾ PapelOUT pap_pap
¹ À x Ç in_pap ¿ y ¾ out_pap È x ¾ in_pap ¿ y Ç out_pap
comp: » Componentes_C ¹
¹
» con: ¹ Conectores_C
port_pap1: Ã Porta_rec ¹ PapelOUT
port_pap2: Ã Porta_exp ¹ PapelIN_C
port_pap3: Ã Porta_div PapelIN_C
¹
pap_pap: PapelIN_C Ã PapelOUT
¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸ ¹¥½
¼
c1, c2: Componentes_C ¾ c1 ¿ comp ¾ c2 ¹ comp
c1 . id_comp = c2 . id_comp Á c1 = c2
¹¥½
c1, c2: Conectores_C c1 ¾ con ¿ c2 ¾ con
À
À c1 . id_con = c2 . id_con Á c1 = c2
¹
x: Componentes_C x ¾ comp
¹
¹¥½
z: Componentes_C z ¾ comp À Ä zÅ xÆ ¾ comp_comp È Ä xÅ zÆ ¾ comp_comp
¹¥½
x: Porta_rec; y: PapelOUT UÄ xÅ yÆ ¾ port_pap1
ÀË
ÀË cp: Componentes_C; cn: Conectores_C cp ¾ comp ¿ cn ¾ con
¹
¹
Ä xÅ yÆ ¾ cn . port_pap1 ¿ x ¾ cp . in_port
¹¥½ À
x: Porta_exp; y: UÄ xÅ yÆ ¾ PapelIN_C ¹ port_pap2
cp: Componentes_C; cn: Conectores_C cp ¾ comp ¿ cn ¾ con
¹ À Ä xÅ yÆ ¾ cn . port_pap2 ¿ x ¾ cp . out_port
ÀË
x: Porta_div; y: PapelIN_C UÄ xÅ yÆ ¾ port_pap3
¹¥½
ÀË cp: Componentes_C; cn: Conectores_C cp ¾ comp ¿ cn ¾ con
¹
¹
Ä xÅ yÆ ¾ cn . port_pap3 ¿ x ¾ cp . div_port
À
137

¹ ¿ ÄË k: Conectores_C; l: Porta_rec; m: Porta_exp; n: PapelOUT; o,
¹ ¿ Ä jÅ pÆ ¾ k . port_pap3
¹ ΠĽ
x, y: Componentes_C x ¾ comp ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ comp_comp
¹ ΠĽ
x, y: Componentes_C x ¾ comp ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ comp_comp
¹ ΠĽ
x, y: Componentes_C x ¾ comp ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ comp_comp
¹ ΠĽ
x, y: Componentes_C x ¾ comp ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ comp_comp
ΠĽ
x, y: Componentes_C x ¾ comp ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ comp_comp
¹
¹
nível x Ï nível yÆ>Æ º ¸¢¸¤¸¢¸¢¸£¸¦¸¢¸£¸¢¸¢¸¢¸¢¸£¸¢¸¢¸¥¸¢¸¢¸¢¸¤¸¥¸¢¸¢¸¢¸¢¸¥¸¢¸¢¸£¸¢¸¢¸¢¸¢¸£¸¦¸¢¸¤¸¢¸
À
ÀË z, w: Conectores_C z ¾ con ¿ w ¾ con
¹
À x ¾ z . in_pap ¿ y ¾ w . out_pap ¿ w . id_con É z . id_con
¹
x, y: Componentes_C x ¾ comp ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ comp_comp
¹¥½
¹ ÀË z, w: SERVICO z ¾ x . serv_req ¿ w ¾ y . serv_ofer
¹ À z = w
¹
p: PapelIN_C; j: Porta_div
¹ PÄ lÅ nÆ ¾ k . port_pap1
¹ ¿ Ä mÅ oÆ ¾ k . port_pap2
À Ä l ¾ y . in_port ¿ m ¾ x . out_port ¿ j ¾ y . div_portÆ>Æ
¹¥½
¹
x: Componentes_C; Í UÄ xÅ yÆ ¾ y: À nível ¾ x comp
¹ Ä tipo_interação = bot1
À nível x = nível y - 1ÆÆ ¹
È Ä tipo_interação = topbot1
¹
ΠĽ
x, y: Componentes_C x ¾ comp ¿ y ¾ comp ¿ Ä xÅ yÆ ¾ comp_comp
¹
¹
nível x = nível y + 1 È nível x = nível y - 1ÆÆ ¹
¹
Ä tipo_interação = topbot2 È
À nível x É nível yÆÆ ¹
È Ä tipo_interação = top2
¹
138