UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA

CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Pr incípios do Holoparadigma

por

JORGE LUIS VICTÓRIA BARBOSA

TI 748 CPGCC-UFRGS

Trabalho Individual III

Prof. Dr. Cláudio Fernando Resin Geyer Orientador

Porto Alegre, janeiro de 1999

2

Agradecimentos

Agradeço aos companheiros de viagem. Estamos compartilhando momentos muito interessantes. A viagem continua.

"Essa habili dade do homem em separar a si próprio do ambiente, bem como em dividir e distribuir as coisas, levou em última instância a um largo espectro de resultados negativos e destrutivos, pois ele perdeu a consciência do que estava fazendo e, deste modo, estendeu o processo de divisão além dos limites dentro dos quais este opera adequadamente. Em essência, o processo de divisão é uma maneira conveniente e útil de pensar sobre as coisas, principalmente no domínio das atividades práticas, técnicas e funcionais (por exemplo, dividir um terreno em diferentes campos onde várias safras serão culti vadas). Todavia, quando este modo de pensamento é aplicado de uma forma mais ampla à noção do homem a respeito de si mesmo e a respeito do mundo todo em que vive (isto é, à sua visão de mundo pessoal), então ele deixa de considerar as divisões resultantes como meramente úteis ou convenientes e começa a ver e a experimentar a si próprio, e ao seu mundo, como efetivamente constituídos de fragmentos separadamente existentes. Guiado por uma visão pessoal de mundo fragmentária, o homem então age no sentido de fracionar a si mesmo e ao mundo, de tal sorte que tudo parece corresponder ao seu modo de pensar. Ele assim obtém uma prova aparente de que é correta a sua visão de mundo fragmentária, embora, é claro, negligencie o fato de que é ele próprio, agindo de acordo com o seu modo de pensar, a causa da fragmentação que agora parece ter uma existência autônoma, independente da sua vontade e do seu desejo."

David Bohm, A Totalidade e a Ordem Implicada ([BOH 80, p.20-21])

"O homem solitário pensa sozinho e cria novos valores para a humanidade. Inventa assim novas regras morais e modifica a vida social. A personalidade criadora deve pensar e julgar por si mesma, porque o progresso moral da sociedade depende exclusivamente da sua independência. A não ser assim, a sociedade estará inexoravelmente votada ao malogro, e o ser humano privado da possibili dade de comunicar. Defino uma sociedade sadia por este laço duplo. Somente existe por seres independentes, mas profundamente unidos ao grupo."

Albert Einstein, Como vejo o mundo ([EIN 81, p.15])

"Es preciso que el hombre de ciencia deje de ser lo que hoy es con deplorable frecuencia: un bárbaro que sabe mucho de una cosa.... Todo aprieta para que se invente una nueva integrácion del saber, que hoy anda hecho pedazos por el mundo... Ha llegado a ser un asunto urgentísimo e inexcusable da la humanidad inventar una técnica para habérselas adecuadamente con la acumulación de saber que hoy posee. Si no encuentra maneras fáciles para dominar esa vegetación exuberante quedará el hombre ahogado por ella. Sobre la selva primaria de la vida vendría a yuxtaponerse esta selva secundaria de la ciencia, cuya intención era simpli ficar aquélla. Si la ciencia puso ordem en la vida, ahora será preciso poner también orden en la ciencia, organizarla - ya que no es posible reglamentarla-, hacer posible su perduración sana. Para ello hay que vitali zarla, esto es, dotarla de una forma compatible con la vida humana que la hizo y para la cual fue hecha. De otro modo - no vale recostarse en vagos optimismos - la ciencia se volatizará, el hombre se desinteresará de ella... Y el movimiento que lleva a la investigácion a disociarse indefinidamente en problemas particulares, a pulverizarse, exige una regulácion compensatoria - como sobreviene en todo organismo saludable - mediante un movimiento de dirección inversa que contraiga y retenga en un rigoroso sistema la ciencia centrífuga."

José Ortega y Gasset, Mision de la Universidad ([ORT 92, p.71-72])

3

Sumár io

Lista de Figuras..........................................................................................................5

L ista de Abreviaturas ................................................................................................7

Resumo........................................................................................................................8

Abstract .......................................................................................................................9

1 Introdução.........................................................................................................10

1.1 Tema.................................................................................................................10

1.2 Motivação.........................................................................................................10

1.3 Objetivos ..........................................................................................................13

1.4 Estrutura do Texto............................................................................................13

2 Gestação do Holoparadigma............................................................................14

2.1 Paralelismo Implícito........................................................................................14

2.2 Arquiteturas Distribuídas .................................................................................17

2.3 Distribuição Implícita.......................................................................................21

2.4 Multiparadigma e Arquitetura de Sofware.......................................................23

2.5 Regulagem da Fragmentação do Conhecimento ..............................................26

2.6 Paradigmas Holísticos......................................................................................28

2.7 Nascimento do Holoparadigma........................................................................31

2.8 Conclusões........................................................................................................32

3 Pr incípios do Holoparadigma..........................................................................35

3.1 Holosemântica..................................................................................................35

3.2 Ente...................................................................................................................37

3.2.1 Descrição do Ente..........................................................................................37

3.2.2 Classificação Organizacional .........................................................................37

3.2.3 Índices de Entes..............................................................................................39

3.2.4 Compartilhamento de Entes...........................................................................42

3.2.5 Distribuição de Entes.....................................................................................43

3.2.6 Mobili dade de Entes.......................................................................................44

3.2.7 Ciclo Existencial dos Entes............................................................................46

3.2.8 Formas de Criação dos Entes.........................................................................47

3.2.9 Formas de Extinção dos Entes.......................................................................49

3.3 Fatos.................................................................................................................50

4

3.4 Estilo Arquitetônico .........................................................................................51

3.5 Holomodelagem ...............................................................................................54

3.6 Holoplataforma.................................................................................................56

3.7 Estudo de uma aplicação: Automação Residencial ..........................................58

3.8 Conclusões........................................................................................................60

4 Conclusões.........................................................................................................63

Anexo Significado de palavras relacionadas com o Holoparadigma..................65

Bibliografia .................................................................................................................72

5

Lista de Figuras

FIGURA 2.1 - Exploração automática do paralelismo implícito...............................15

FIGURA 2.2 - Duplicacidade no uso dos paradigmas...............................................16

FIGURA 2.3 - Organização de um sistema computacional distribuído.....................17

FIGURA 2.4 - Classificação dos nodos das arquiteturas distribuídas........................18

FIGURA 2.5 - Classificação das arquiteturas de sistemas computacionais...............19

FIGURA 2.6 - Rede de computadores fictícia...........................................................20

FIGURA 2.7 - Rede como arquitetura distribuída.....................................................20

FIGURA 2.8 - Níveis de abstração da arquitetura distribuída...................................20

FIGURA 2.9 - Exploração automática da distribuição implícita...............................23

FIGURA 2.10 - Origem da distribuição implícita e da semântica distribuída.............23

FIGURA 2.11 - Comparação entre metodologias e arquitetura de software................25

FIGURA 2.12 - Evolução dos paradigmas de desenvolvimento de software..............29

FIGURA 2.13 - Evolução das técnicas de desenvolvimento de software....................29

FIGURA 2.14 - Harmonia dos princípios básicos dos paradigmas holísticos.............30

FIGURA 2.15 - Origem dos paradigmas holísticos.....................................................31

FIGURA 2.16 - Níveis de gestação do Holoparadigma...............................................32

FIGURA 3.1 - Gap semântico....................................................................................35

FIGURA 3.2 - Holosemântica aplicada a modelagem...............................................36

FIGURA 3.3 - Características dos entes.....................................................................37

FIGURA 3.4 - Exemplo de ente composto ................................................................38

FIGURA 3.5 - Classificação organizacional dos entes..............................................39

FIGURA 3.6 - Exemplo de ente compartilhado.........................................................43

FIGURA 3.7 - Exemplo de ente distribuído...............................................................44

FIGURA 3.8 - Exemplo de mobili dade......................................................................45

FIGURA 3.9 - Mobili dade física sem mobili dade lógica...........................................46

FIGURA 3.10 - Ciclo existencial de um ente ..............................................................47

FIGURA 3.11 - Criação de entes por agregação..........................................................48

FIGURA 3.12 - Criação de entes por clonagem...........................................................48

FIGURA 3.13 - Criação e extinção de entes por fragmentação...................................49

FIGURA 3.14 - Classificação dos fatos em Holo ........................................................50

FIGURA 3.15 - Modelo Blackboard............................................................................52

FIGURA 3.16 - Estilo arquitetônico de Holo...............................................................54

FIGURA 3.17 - Modelo computacional como um ente...............................................54

6

FIGURA 3.18 - Exemplo de limite de composição .....................................................55

FIGURA 3.19 - Holoplataforma...................................................................................56

FIGURA 3.20 - Residência utili zada na holomodelagem............................................59

FIGURA 3.21 - Residência como um ente composto..................................................59

FIGURA 3.22 - Organização de um país através de Holo ...........................................60

7

Lista de Abreviaturas

CAP Capítulo

EFE Ente Fisicamente Estático

EFM Ente Fisicamente Móvel

ELE Ente Logicamente Estático

ELM Ente Logicamente Móvel

INE Índices de Ente

LAN Local Area Network

NEC Número de Entes Componentes

NECE Número de Entes Componentes Elementares

NECO Número de Entes Componentes Compostos

NI Nível

NIA Nível de Abstração

NIC Nível de Composição

P Página

PAT Princípio da Abstração Tecnológica

PEM Princípio da Ergonometria Mental

PMU Princípio da Modelagem Universal

TEC Total de Entes Componentes

TECE Total de Entes Componentes Elementares

TECO Total de Entes Componentes Compostos

TONIA Total de Níveis de Abstração

TONIC Total de Níveis de Composição

WAN Wide Area Network

8

Resumo

Este trabalho contém os primeiros passos para criação de um paradigma de desenvolvimento de software denominado Holoparadigma. A primeira parte do texto aborda a gestação do paradigma. Nesta parte são descritas suas motivações e concepções intermediárias. Durante essa descrição são abordados vários temas de pesquisa, tais como: paralelismo implícito, arquiteturas distribuídas, distribuição implícita, multiparadigma, arquitetura de software e paradigmas holísticos. A segunda parte do trabalho apresenta os princípios básicos do Holoparadigma. Neste escopo é descrita sua semântica (holosemântica), suas principais abstrações (ente, fato e história), seu uso na modelagem (holomodelagem), suas plataformas de desenvolvimento e execução, seu estilo arquitetônico (blackboard, invocação implícita e invocação explícita) e sua aplicação na automação residencial.

Palavras-Chaves: Paradigma de Desenvolvimento de Software, Distribuição Implícita, Paradigma Holístico, Holoparadigma.

9

TITLE : Principles of Holoparadigm

Abstract

This work contains the first steps to create a new software development paradigm called Holoparadigm. The text's first part approaches the paradigm's gestation. This part describes its motivations and intermediary conceptions. During this description several research themes are approached, namely: implicit parallelism, distributed architectures, implicit distribution, multiparadigm, software architecture and holistic paradigms. The work's second part presents the Holoparadigm's basic principles. In this scope are described its semantic (holosemantic), its main abstractions (being, fact and history), its use in modeling (holomodeling), its development and execution plataforms, its architectural style (blackboard, implicit invocation and explicit invocation) and its application in automatization of residences.

Keywords: Software Development Paradigm, Implicit Distribution, Holistic Paradigm, Holoparadigm.

10

1 Introdução

1.1 Tema

O tema deste trabalho é o Holoparadigma (de forma abreviada, Holo). Holo é um novo paradigma para o desenvolvimento de software. A gênese e o desenvolvimento do Holoparadigma envolvem, especialmente, os seguintes tópicos de pesquisa: Multiparadigma ([BAR 98]), Arquitetura de Software ([SHA 96]) e Sistemas Distribuídos ([SHA 89]).

1.2 Motivação

A abstração é um dos principais instrumentos intelectuais do ser humano. Através dela, a mente humana capta apenas as informações relevantes de uma determinada realidade, ou seja, concentra esforços apenas no essencial e abstrai o restante. No universo dos computadores a abstração tem sido utili zada em larga escala. Neste contexto, sua principal função vem sendo a simpli ficação do uso dos sistemas computacionais. Por exemplo, a abstração criada através da linguagem Assembly simpli ficou o uso da linguagem de máquina. Por sua vez, as linguagens convencionais de alto nível abstrairam o Assembly mas, no entanto, mantiveram a essência imperativa da arquitetura Von Neumann. Em uma nova etapa, a criação dos paradigmas não convencionais (por exemplo, funcional, lógica e objetos) abstraiu a natureza imperativa do hardware e criou linguagens declarativas, as quais enfocam a descrição do problema em detrimento da descrição do controle da execução. Estas abstrações demandam a criação de camadas de software que simpli fiquem a realidade abstraída. Por exemplo, um montador concretiza a abstração Assembly. Por sua vez, um compilador concretiza a abstração linguagem de alto nível. Em alguns casos, a abstração linguagem declarativa necessita ainda de uma máquina abstrata para concretização de outra abstração, ou seja, o código virtual. Independentemente dos níveis de abstração utili zados, a força vital do sistema computacional possui sempre a mesma origem, ou seja, o hardware. A abstração aumenta o desempenho do usuário, mas exige vitalidade computacional para sua concretização.

O surgimento do processamento paralelo trouxe maior vitalidade para os sistemas computacionais. No entanto, trouxe também complexidade adicional para a fonte da vitalidade, ou seja, o hardware. O hardware paralelo permite a exploração do paralelismo à nível de execução. Neste nível, a paralelização do problema a ser processado já deve ter sido realizada. Sendo assim, o paralelismo deve ser propagado para as camadas de software criadas para simpli ficação do uso do computador, ou seja, o paralelismo deve ser manipulado através dos softwares básicos.

A essência da arquitetura Von Neumann consiste em um único fluxo de controle manipulando dados. Essa manipulação gera um único fluxo de dados. Sendo assim, Von Neumann criou uma arquitetura para processamento seqüencial. As primeiras abstrações criadas para simpli ficar o desenvolvimento de software mantiveram a mesma essência. As linguagens imperativas são essencialmente seqüencias, ou seja, não contém paralelismo implícito nas suas estruturas de controle. Sendo assim, a abstração do paralelismo é dificultada e sua manipulação explícita estimulada. Por outro lado, as linguagens declarativas abstraem a arquitetura Von Neumann e enfocam o universo dos

11

problemas a serem modelados. A descrição declarativa está permeada do paralelismo existente no universo modelado. Neste caso, a abstração do paralelismo é facilit ada e sua manipulação implícita estimulada. Surge assim, a primeira motivação:

Primeira Motivação - Paralelismo Implícito: A exploração automática do paralelismo implícito existente nos paradigmas não convencionais tem sido indicada como a melhor abstração para simpli ficar o uso do processamento paralelo.

A tecnologia dos sistemas computacionais tem sofrido fortes mudanças. Os avanços da microeletrônica vêm diminuindo o preço do hardware e aumentando seu poder computacional. Em especial, o advento do microprocessador ocasionou uma revolução na arquitetura dos computadores. Em complemento, o desenvolvimento de soluções eficientes para interconexão dos sistemas computacionais fez com que a área de redes de computadores assumisse uma posição de destaque. Nos últimos anos, o crescimento exponencial da Internet vem se destacando como um fenômeno tecnológico e de mercado. Neste contexto, as plataformas computacionais vêm migrando de sua natureza centralizada para uma nova realidade distribuída. Os sistemas distribuídos têm recebido cada vez mais dedicação tanto dos centros de pesquisa quanto das empresas da área de informática. Entre os novos tópicos de pesquisa surgidos merecem destaque: uso de redes de computadores como arquiteturas paralelas, mobili dade de código e dados através das redes, tolerância à falhas em sistemas distribuídos e tratamento da heterogeneidade de hardware nas redes de computadores.

Uma análise da situação atual e das perspectivas futuras do universo dos computadores permite a previsão de que em breve os sistemas computacionais serão compostos por uma grande variedade de estações de alto desempenho conectadas por redes de alta velocidade organizadas em topologias diversas (arquitetura distribuída). Este universo distribuído será a base para o desenvolvimento de sistemas computacionais. As novas características e potencialidades introduzidas pela realidade distribuída deverão ser exploradas. Seguindo as tendências da evolução dos computadores, os sistemas distribuídos necessitarão cada vez mais de abstrações que simpli fiquem seu uso. A criação de softwares (abstrações) que viabili zem o universo distribuído está se tornando uma das principais tarefas da ciência da computação. Neste contexto, o estudo de metodologias para o desenvolvimento de softwares distribuídos ocupa uma posição de destaque ([SHA 89]). De forma semelhante a exploração automática do paralelismo (primeira motivação), o principal problema para uso adequado da arquitetura distribuída consiste na determinação de um paradigma de desenvolvimento de software que possua na sua semântica o potencial para exploração automática da distribuição (distribuição implícita). Através da distribuição implícita, o desenvolvimento de abstrações distribuídas (softwares) será simpli ficada e estimulada. Sendo assim, destaca-se a segunda motivação:

Segunda Motivação - Arquiteturas Distr ibuídas: Em breve, as arquiteturas distribuídas serão a plataforma básica para o desenvolvimento de sistemas computacionais. Sendo assim, torna-se vital a criação de paradigmas de software que suportem de forma adequada a semântica distribuída.

Conforme salientado em [BAR 98], nos últimos anos vem crescendo o interesse da comunidade científica pela proposta multiparadigma, ou seja, a criação de novas técnicas de modelagem de software através da integração dos paradigmas considerados básicos (imperativo, lógica, funcional, orientado a objetos e orientado a agentes). O principal objetivo da modelagem multiparadigma consiste em transcender as limitações

12

e aproveitar os benefícios dos paradigmas básicos. Em complemento, nos últimos anos crescem também os esforços dedicados ao estudo da Arquitetura de Software ([GAR 95], [IEE 95], [SHA 96]). Esse tema de pesquisa busca soluções para os problemas encontrados nas atuais metodologias de desenvolvimento. Neste sentido, a arquitetura de sofware propõe a criação de técnicas de desenvolvimento baseadas em considerações sobre componentes de software e seus relacionamentos ([SHA 96, p.3]). A base para criação dessas técnicas é o estudo das atuais metodologias e padrões utili zados por elas. Através desse estudo, é proposta a transcendência dessas metodologias. Existe uma forte relação entre as áreas multiparadigma e arquitetura de software. Ambas propõem a criação de novas técnicas para o desenvolvimento de software. Neste contexto surge a terceira motivação:

Terceira Motivação - Arquitetura de Software/Multiparadigma: Atualmente, existe uma forte tendência da comunidade científica em rever as metodologias atuais para o desenvolvimento de software. Os temas de pesquisa multiparadigma e arquitetura de software são demonstrações recentes desse interesse.

O texto [BAR 98] analisa o impacto do uso da fragmentação como instrumento de domínio da complexidade. Naquele texto, destaca-se que o presente sucesso da ciência basea-se, em grande parte, na estratégia de fragmentação do conhecimento, ou seja, na criação de diversas áreas de especialização. Aquele texto salienta ainda, que na ciência da computação o paradigma fragmentação/especialização vem sendo bastante aplicado. Um dos principais resultados dessa realidade é a criação de vários paradigmas de desenvolvimento e uma quantidade enorme de linguagens de programação ([BAR 98, p.10]).

Ortega y Gasset em seu livro Mision de la Universidad, cuja primeira edição data de 1930, salienta a importância da criação de sínteses e sistematizações do saber ([ORT 92, p.72]). Afirma que o movimento que leva a investigação a dissociar-se indefinidamente em problemas particulares, a pulverizar-se, exige uma regulagem compensatória - como sobrevem em todo organismo saudável - mediante um movimento de direção inversa que contraia e retenha em um rigoroso sistema a ciência centrífuga. O texto [BAR 98] enfoca a proposta multiparadigma como a gênese de uma abordagem holística (paradigmas holísticos) para o desenvolvimento de sistemas computacionais. Sendo assim, [BAR 98] enfoca a proposta multiparadigma como uma regulagem compensatória para a tendência centrífuga de especialização dos paradigmas de desenvolvimento de sistemas computacionais. A abordagem da evolução científica como unificação e síntese de conhecimentos já adquiridos é bastante estimulante e reflete uma das principais tendências da ciência em diversas áreas. Surge assim a quarta motivação:

Quarta Motivação - Regulagem da Fragmentação do Conhecimento: A criação de propostas que unifiquem conhecimentos já existentes segue uma tendência de organização da evolução científica, ou seja, a regulagem da fragmentação do conhecimento através de abordagens holísticas que permitam sínteses.

As quatro motivações apresentadas estimularam a criação de uma proposta para um paradigma holístico de desenvolvimento de software ([BAR 98]) que contemple duas fortes tendências evolutivas do universo dos computadores, ou seja, arquiteturas distribuídas (hardware) e arquitetura de software/multiparadigma (software). O Holoparadigma é um paradigma holístico que possui uma semântica simples e distribuída. Desta forma, estimula-se a exploração da distribuição implícita desde a

13

modelagem dos sistemas computacionais. Além disso, contempla-se as vantagens introduzidas pela arquitetura de software e pelos modelos multiparadigma.

1.3 Objetivos

O objetivo geral deste trabalho é a criação de um novo paradigma de software denominado Holoparadigma. Neste sentido, pretende-se alcançar os seguintes objetivos específicos:

� pesquisar o estado da arte no tema arquitetura de software; � aprofundar os estudos sobre modelos multiparadigma iniciados em [BAR

98]; � definir a relação existente entre os temas arquitetura de software e

multiparadigma; � pesquisar o tema sistemas distr ibuídos estabelecendo as principais

características das arquiteturas distr ibuídas; � analisar o impacto do princípio de regulagem da fragmentação na evolução

dos paradigmas de software; � aprofundar o estudo sobre paradigmas holísticos iniciado em [BAR 98]

definindo a relação existente entre este tipo de paradigma e os temas arquitetura de software e multiparadigma;

� definir uma semântica simples que permita a modelagem holística proposta pelo Holoparadigma;

� definir uma semântica distr ibuída que permita a exploração da distribuição implícita proposta pelo Holoparadigma;

� propor um estilo arquitetônico ([SHA 96]) que suporte a semântica simples e distribuída pretendida pelo Holo;

� prever a contextualização, no universo dos computadores, do paradigma proposto. Neste sentido, assume posição de destaque a inserção natural do Holo na evolução dos sistemas computacionais;

� propor um sistema que suporte o desenvolvimento de software em Holo; � definir trabalhos futuros para concretização do Holoparadigma.

1.4 Estrutura do Texto

O texto é composto de quatro capítulos. O segundo capítulo apresenta a gestação do Holoparadigma, ou seja, os principais temas pesquisados e as principais considerações que motivaram o nascimento do Holo. O capítulo três descreve os princípios básicos do paradigma proposto. Destacam-se neste capítulo sua semântica, seu estilo arquitetônico e a descrição de uma aplicação. Finalmente, o capítulo quatro contém as conclusões deste trabalho. Merece destaque ainda o anexo contendo definições, obtidas em dicionários, dos termos usados no âmbito do Holoparadigma.

14

2 Gestação do Holoparadigma

Este capítulo descreve a gestação do Holoparadigma. As seções contém análises de tópicos que participaram da sua gênese e do seu crescimento. O estudo destes tópicos é vital para compreensão da proposta, pois insere o leitor no contexto onde Holo foi concebido, permitindo ainda uma percepção histórica da sua gestação e nascimento. A seção 2.1 analisa conceitos relacionados com paralelismo implícito. A seção 2.2 versa sobre sistemas distribuídos e propõe uma definição de arquiteturas distribuídas. Com base nas duas primeiras seções, a seção 2.3 define distribuição implícita. Por sua vez, a seção 2.4 discute os temas multiparadigma e arquitetura de software. Destaca-se naquela seção uma análise comparativa dos dois temas. Na seção 2.5 é analisado o fenômeno da fragmentação do conhecimento gerado pela tendência centrífuga da pesquisa científica. Aquela seção destaca a participação do Holoparadigma na evolução da ciência como instrumento de criação e organização do conhecimento humano. Tendo como base as duas seções anteriores, a seção 2.6 introduz o conceito de paradigma holístico para desenvolvimento de sistemas computacionais. A seção 2.7 sintetiza as demais seções e direciona a síntese para o nascimento do Holoparadigma. Os textos apresentados em cada seção contemplam a essência de cada tópico e contém diversas referências para aprofundamento dos estudos.

2.1 Paralelismo Implícito

Nos últimos anos o uso pleno do potencial de processamento disponível nas arquiteturas paralelas vem sendo buscado através do desenvolvimento de softwares que explorem o paralelismo de forma adequada. Essa exploração "adequada" envolve questões relacionadas com a filosofia do desenvolvimento de software. A execução paralela exige a existência de paralelismo à nível de execução. Este paralelismo chega até a plataforma de execução através de várias camadas de desenvolvimento de software. Sendo assim, surge a questão: onde encontra-se a gênese do paralelismo que será explorado a nível de execução? Em ressonância com essa questão surge outra: quais são as fontes que permitiram a gênese do paralelismo? A solução destas questões é primordial para compreensão do paralelismo como solução para o aumento do poder de processamento dos sistemas computacionais. Vários textos já abordaram este problema através de diversos enfoques ([BAR 96]).

Conforme analisado em [BAR 96, p.25], existem duas filosofias para exploração do paralelismo, ou seja, paralelismo implícito e explícito. O paralelismo explícito propõe a detecção do paralelismo pelo programador e sua inserção explícita nos programas através de mecanismos específicos de software. Por sua vez, o paralelismo implícito pretende a detecção automática do paralelismo e sua exploração através de mecanismos inseridos nos softwares básicos dos sistemas computacionais. Ambas filosofias dependem das questões apresentadas no parágrafo anterior. As estratégias para exploração explícita ou implícita do paralelismo somente podem ser definidas se, anteriormente, forem determinadas as fontes do paralelismo. Além disso, a facili dade com que uma ou outra solução é implementada depende do potencial de paralelismo disponível originalmente.

As fontes de paralelismo estão diretamente relacionadas com o universo que sofrerá a modelagem computacional. Neste caso, a palavra sofrerá parece bastante adequada, pois transmite a impressão de perda de informação que toda modelagem

15

impõe a realidade modelada. O processo de abstração utili zado na modelagem busca capturar os aspectos relevantes da realidade que devem ser inseridos no modelo. Com o intuito de viabili zar essa tarefa, foram criadas diversas metodologias baseadas em vários paradigmas de desenvolvimento de software. Conforme destacado em [BAR 98, p.10-11] a palavra paradigma possui diversas interpretações e pode ser melhor compreendida, no contexto deste trabalho, como um modelo ou padrão para percepção de um universo. Os textos [KUH 70] e [KUH 77] são adeqüados para aprofundamento dos estudos sobre paradigmas no âmbito da ciência.

As fontes de paralelismo estão relacionadas com os paradigmas utili zados para modelagem e, em última instância, estão relacionadas com o universo a ser modelado. Se o universo modelado não possuir naturalmente fontes de paralelismo, não importa o paradigma utili zado na sua modelagem, o modelo computacional resultante não possuirá paralelismo implícito. Por outro lado, se o universo modelado contiver paralelismo em potencial, o paradigma utili zado na modelagem deve transferi-lo para o modelo computacional, viabili zando assim sua exploração automática. A figura 2.1 representa a exploração automática do paralelismo implícito.

Realidade

Universo

ModeloComputacional

Fontes deParalelismo

Modelagem Subliminar do p aralelismo

Execução Paralela

Exploração automática do p aralelismo

Paralelismo Implícito

Semântica Paralela

FIGURA 2.1 - Exploração automática do paralelismo implícito

Conforme destacado em vários textos ([YAM 94], [BAR 96]) o paradigma imperativo dificulta a exploração automática do paralelismo. Este fato resulta da sua tendência em modelar o universo através de comandos imperativos, resultando assim, em vários níveis de dependências de dados e de controle ([BAR 93], [BAR 94]). Por outro lado, os paradigmas não convencionais estimulam a exploração automática do paralelismo através de sua modelagem que abstrai o controle da execução e enfoca a descrição do universo modelado (modelagem declarativa). Os paradigmas não convencionais tendem a refletir no modelo as fontes naturais de paralelismo existentes no universo. Por exemplo, o paradigma em lógica transmite para o modelo computacional o potencial de paralelismo que está implícito na abordagem lógica do universo (paralelismo OU e paralelismo E). Por sua vez, o paradigma orientado a objetos transmite o potencial de paralelismo que existe no universo quando modelado através da filosofia de objetos (paralelismo interobjetos - entre objetos; e paralelismo intraobjeto - entre métodos de um objeto). Torna-se interessante ressaltar que o mesmo

16

universo, modelado por paradigmas diferentes, introduzirá no modelo computacional diferentes fontes de paralelismo. Sendo assim, a opção pela forma de perceber o universo durante a modelagem (paradigma) influencia nas fontes de paralelismo que ficarão disponíveis no modelo. A figura 2.2 representa essa realidade para os paradigmas em lógica e orientado a objetos.

Realidade

Universo

Modelo em Lógica

Modelo Orientado a Objetos

Modelagem em Lógica: Paralelismo E e OU

Modelagem Orientada a Objetos:Paralelismo Intra e Inter Objetos

FIGURA 2.2 - Duplicidade no uso dos paradigmas

Neste ponto do texto, algumas constatações merecem ser destacadas: � a transmissão do potencial de paralelismo entre universo e modelo deve ser

subliminar, ou seja, o paralelismo deve ser refletido de forma natural e, até mesmo, inconsciente. Sendo assim, durante o processo de modelagem não serão criados empecilhos para posterior exploração automática do paralelismo. O paradigma deve suportar abstrações que transmitam as fontes de paralelismo do universo para o modelo. Neste caso, o paradigma deve possuir uma Semântica Paralela (figura 2.1). As abstrações utili zadas no paradigma devem carregar o paralelismo, ou seja, o paradigma deve estar permeado de paralelismo;

� o paralelismo possui sua gênese no universo modelado. Sendo assim, a exploração automática do paralelismo é um compromisso de toda a plataforma de software, desde a modelagem até a execução. As diversas camadas de software devem propagar as fontes de paralelismo desde o universo modelado até o hardware paralelo. Sendo assim, parece interessante que o desenvolvimento desses softwares seja orientado por esse objetivo em comum. Neste caso, todas as camadas de software devem utili zar a mesma semântica paralela como orientação no seu desenvolvimento;

� considerando-se que o paralelismo possui sua gênese no universo e que vários paradigmas podem ser utili zados para modelagem do mesmo universo (vários tipos de paralelismo no mesmo universo), parece que um interessante tópico de pesquisa seria a investigação da natureza do paralelismo existente na realidade onde residem os universos a serem modelados. Através dessa busca, poderiam ser detectadas as diversas oportunidades de paralelismo existentes na semântica da realidade. Um bom ponto de partida, seria o estudo das oportunidades de paralelismo implícito introduzidas pelos atuais paradigmas de software e uma tentativa de unificação dessas oportunidades através de um modelo que unisse os paradigmas (modelos multiparadigma).

17

2.2 Arquiteturas Distr ibuídas

Conforme definido em [SHA 89, p.1], um sistema computacional distr ibuído é um sistema composto de um conjunto de computadores (nodos de processamento) interconectados por uma rede de comunicação. A figura 2.3 mostra sua organização. Afirmam ainda Shatz e Wang, que o sistema distribuído é considerado fracamente acoplado porque os processadores comunicam-se trocando mensagens através da rede. Além disso, alguns dos nodos de processamento podem ser compostos de conjuntos de computadores, os quais podem se comunicar através de memória compartilhada. Através dessa afirmação, os autores destacam duas importantes características dos sistemas distribuídos, ou seja, a organização hierárquica e a heterogeneidade. Nos próximos parágrafos dessa seção a definição de Shatz e Wang será aperfeiçoada e o termo arquitetura distr ibuída será utili zado para nomear a nova organização computacional definida.

Nodo de Processamento

Rede de Comunicação

Nodo de Processamento

Nodo de Processamento

Nodo de Processamento

. . .

. . .

FIGURA 2.3 - Organização de um sistema computacional distribuído

No ponto de vista de Shatz e Wang, o nodo de um sistema distribuído pode ser composto de vários computadores. Sendo assim, o sistema distribuído fica restrito a apenas um nível hieráquico, conforme mostrado na figura 2.3. Por outro lado, em uma arquitetura distr ibuída um nodo pode ser composto de outros nodos. Sendo assim, a arquitetura distribuída é organizada em vários níveis hierárquicos. Cada nível é composto de vários nodos que se comunicam através de mensagens. Nos níveis mais básicos, a definição de Shatz e Wang será aplicada, ou seja, um nodo será composto de um conjunto de computadores, os quais também serão considerados nodos. Surgem assim, as seguintes definições:

� � Definição 1: Arquitetura Distr ibuída

Um arquitetura distribuída é uma organização computacional formada de nodos que se comunicam através de mensagens trocadas através de um meio de comunicação.

� � Definição 2: Nodo

Um nodo é o componente organizacional da arquitetura distribuída. � � Definição 3: Nodo Elementar

Um nodo elementar é um computador.

18

� � Definição 4: Nodo Composto

Um nodo composto é um nodo formado por outros nodos, os quais podem ser elementares e/ou compostos.

� � Definição 5: Nodo Homogêneo

Um nodo homogêneo é um nodo composto de nodos do mesmo tipo, ou seja, somente elementares ou somente compostos.

� � Definição 6: Nodo Heterogêneo

Um nodo heterogêneo é um nodo composto de nodos de tipos diferentes, ou seja, um ou mais nodos elementares misturados com um ou mais nodos compostos.

� � Definição 7: Nodo Homogêneo Básico ou Nodo Básico

Um nodo básico é um nodo composto de nodos elementares. � � Definição 8: Nodo Homogêneo Avançado ou Nodo Avançado

Um nodo avançado é um nodo composto de nodos compostos.

A figura 2.4 organiza hierarquicamente os possíveis tipos de nodos existentes em uma arquitetura distribuída.

Nodo

Composto Elementar

Homogêneo Heterogêneo

Básico Avançado

FIGURA 2.4 - Classificação dos nodos das arquiteturas distribuídas

Tendo como base as definições surge o primeiro postulado:

Postulado 1 - Equivalência Arquitetura Distr ibuída/Nodo Composto: Todo nodo composto equivale a uma arquitetura distribuída e vice-versa.

Através deste postulado deduz-se que os tipos de nodos compostos apresentados na figura 2.4 podem também ser utili zados para classificação das arquiteturas distribuídas. Além disso, considerando-se que um computador é uma arquitetura elementar pode-se utili zar a terceira definição para criar um segundo postulado:

Postulado 2 - Equivalência Arquitetura Elementar /Nodo Elementar : Todo nodo elementar equivale a uma arquitetura elementar e vice-versa.

19

Através de ambos postulados deduz-se que os tipos de nodos apresentados na figura 2.4 podem também ser utili zados para classificação das arquiteturas de sistemas computacionais. A figura 2.5 contém uma representação dessa classificação.

Arquitetura

Distribuída Elementar

Homogênea Heterogênea

Básica Avançada

FIGURA 2.5 - Classificação das arquiteturas de sistemas computacionais

A figura 2.6 apresenta uma rede de computadores fictícia composta de vinte e oito estações de trabalho organizadas em diversos níveis e topologias. Por sua vez, a figura 2.7 mostra a mesma rede como uma arquitetura distribuída destacando os diversos níveis de nodos. Em complemento, a figura 2.8 mostra a arquitetura distribuída do ponto de vista composicional sem levar em consideração as conexões entre as estações. Nesta figura utili za-se o círculo como representação de nodos compostos e o quadrado como representação de nodos elementares. A figura mostra a evolução dos detalhes da arquitetura na medida em que é decomposto cada nodo. Assim, ficam explícitos os vários níveis de abstração da arquitetura distribuída.

Nos últimos anos, o número de computadores e redes de comunicação vem aumentando de forma significativa. Além disso, cada vez mais a conexão dos computadores através das redes é estimulada. A presente realidade permite a previsão de que em um futuro próximo as redes de computadores, organizadas através de diversos níveis, constituirão a base para organização dos sistemas computacionais. Do ponto de vista de distribuição espacial, as redes podem ser classificadas em dois tipos, ou seja, LAN's (Local Area Networks) e WAN's (Wide Area Networks). Ambos os tipos podem ser organizados em arquiteturas distribuídas e representados através da notação mostrada nas figuras 2.6, 2.7 e 2.8. Tomando-se como exemplo as redes de computadores existentes em um país, pode-se considerar o país como o primeiro nodo da arquitetura distribuída (WAN nacional interligando os estados). Por sua vez, as WAN's de cada estado comporiam os nodos do segundo nível. Em um terceiro nível poderiam ser encontradas as WAN's dos municípios conectados à rede estadual. Por último, em cada município poderiam haver várias LAN's (universidades, empresas, ambientes domésticos, etc).

20

FIGURA 2.6 - Rede de computadores fictícia

FIGURA 2.7 - Rede como arquitetura distribuída

FIGURA 2.8 - Níveis de abstração da arquitetura distribuída

As principais vantagens introduzidas pelas arquiteturas distribuídas são: � Escalabili dade: o poder de processamento (poder das CPU's) de uma

arquitetura distribuída está diretamente relacionado com a quantidade e o poder dos seus nodos elementares. Sendo assim, o simples acréscimo de novos nodos ou a simples troca de nodos já existentes por outros mais poderosos aumenta o poder da arquitetura. Esta flexibili dade é valiosa para organização dos sistemas computacionais. A eficiência de uma arquitetura distribuída depende ainda da velocidade dos canais de comunicação e da qualidade dos softwares que

21

gerenciam o sistema. Neste sentido, a gerência da escalabili dade assume uma posição de destaque;

� Confiabili dade: a arquitetura distribuída é bastante confiável, pois permite a implementação de várias técnicas de tolerância à falhas baseadas na redundância introduzida pela existência de múltiplos nodos elementares (múltiplos recursos, tais como: processadores e discos). As características introduzidas pela arquiteturas distribuídas trazem novos problemas de confiabili dade que devem ser resolvidos por novas técnicas de tolerância à falhas. Por exemplo, o fluxo de mensagens entre nodos é uma fonte de falhas que deve ser cuidadosamente pesquisada. O simples envio de uma mensagem não significa sua recepção. Vários fenômenos criam riscos durante sua viagem entre emissor e receptor;

� Localidade: a natureza distribuída da arquitetura descrita nessa seção é bastante atraente para organização dos sistemas computacionais, pois permite a distribuição espacial dos recursos. Essa característica coincide com a forma da humanidade organizar suas instituições. Atualmente, os computadores estão distribuídos em vários níveis dentro de cada organização humana (países, estados, municípios, cidades, bairros, universidades, empresas, ambientes domésticos, etc). As arquiteturas distribuídas refletem de forma natural essa realidade.

2.3 Distr ibuição Implícita

Conforme analisado na seção 2.1 e mostrado na figura 2.1, a utili zação de uma semântica paralela permite a transferência das fontes de paralelismo do universo para o modelo computacional, facilit ando assim a exploração automática do paralelismo (paralelismo implícito). Por sua vez, a seção 2.2 define arquitetura distr ibuída e cria uma proposta para classificação dos sistemas computacionais (figura 2.5). Neste contexto, torna-se interessante uma análise da relação existente entre o paralelismo implícito e as arquiteturas distribuídas. Através dessa análise, surge uma das bases do Holoparadigma, ou seja, o conceito de distr ibuição implícita baseada em uma semântica distr ibuída.

A arquitetura de um computador é considerada paralela se contém mais de um processador de uso genérico. Basicamente, existem dois tipos de organização de arquiteturas paralelas, ou seja, arquiteturas com memória compartilhada ou com memória distribuída. Em ambas arquiteturas os processadores residem dentro de um único computador. Portanto, do ponto de vista da classificação apresentada na figura 2.5, ambas arquiteturas seriam consideradas elementares. Sendo assim, passam a existir dois tipos de arquiteturas elementares, ou seja, uniprocessadas e multiprocessadas. Uma arquitetura paralela com memória distribuída é semelhante a uma arquitetura distribuída composta de arquiteturas elementares uniprocessadas. Neste caso, cada arquitetura elementar equivale a um par processador/memória da arquitetura paralela. Em essência, essas arquiteturas diferenciam-se apenas pela distribuição espacial dos seus elementos componentes.

Através das afirmações do parágrafo anterior, surge a seguinte questão: onde se localizam as oportunidades para execução paralela em uma arquitetura distribuída? De forma complementar, surge uma segunda questão: como modelar as fontes de

22

paralelismo existentes nos universos de forma a potencializar a execução paralela nas arquiteturas distribuídas? Essa questão pode ser melhor compreendida através da figura 2.1. Naquela figura, se o bloco que representa a execução paralela for considerado uma arquitetura distribuída, a semântica paralela que permea todo o desenvolvimento de software deve estabelecer quais as fontes de paralelismo no universo serão mais adequadas para a arquitetura distribuída.

A natureza da arquitetura distribuída cria várias oportunidades para exploração do paralelismo. Cada nodo elementar pode atuar como um processador de uma arquitetura paralela. Sendo assim, podem ser criadas (consciente ou inconscientemente) várias topologias de arquiteturas paralelas. No entanto, a execução paralela como forma de aumentar o desempenho de programas não é o principal objetivo das arquiteturas distribuídas. Originalmente, a execução paralela surge como oportunidade, mas não como objetivo. Por outro lado, nos últimos anos vem aumentando o interesse na utili zação de arquiteturas distribuídas como arquiteturas paralelas. Este fenômeno possui várias motivações dentre as quais se destacam: a ploriferação de redes de computadores, o aumento subtancial do poder computacional das estações de trabalho, a subutili zação destas estações e o aumento da velocidade de transmissão nas redes de comunicação. Considerando-se que existe uma forte tendência no aumento da força dessas motivações, pode-se afirmar que existe uma forte tendência no aumento do interesse pela exploração do paralelismo em arquiteturas distribuídas.

No contexto das arquiteturas distribuídas, a execução paralela surge como uma das várias oportunidades a serem exploradas. Essa oportunidade deve ser pesquisada em conjunto com as demais. As arquiteturas distribuídas possuem características que introduzem diversas vantagens (o final da seção 2.2 salienta três delas). A exploração adequada, à nivel de execução, dessas características e oportunidades envolve as várias abstrações utili zadas no desenvolvimento dos sistemas computacionais. A análise realizada na seção 2.1 para exploração automática do paralelismo é válida também para exploração automática da distribuição. O potencial de distribuição existente no universo modelado deve ser transferido de forma subliminar para o modelo computacional. Sendo assim, surge a definição de distr ibuição implícita, ou seja, a exploração automática das caraterísticas distribuídas do universo modelado. Conforme analisado na seção 2.1, o p rocesso de exploração implícita demanda a criação de uma semântica, neste caso, uma semântica distr ibuída. Neste contexto, seria interessante o estudo das possíveis fontes de distribuição existentes no mundo real. Além disso, a semântica distribuída deve ser considerada durante a criação de paradigmas de software que almejem a exploração da distribuição implícita nos seus modelos computacionais. A figura 2.9 representa a exploração automática da distribuição implícita.

As figuras 2.1 e 2.9 são bastante semelhantes. Sendo assim, neste ponto do texto torna-se interessante o registro de algumas constatações que as diferenciam:

� a arquitetura distribuída é mais genérica do que a arquitetura paralela. Um computador paralelo equivale a uma arquitetura elementar no âmbito das arquiteturas distribuídas;

� a distribuição implícita envolve o paralelismo implícito, ou seja, o paralelismo implícito é uma das características a serem exploradas no âmbito da distribuição implícita. Por exemplo, o escalonamento de tarefas em arquiteturas paralelas com memória distribuída parece ser um caso particular de mobili dade em arquiteturas distr ibuídas ([IEE 98]). A mobili dade pode ser

23

motivada pela busca do aumento de desempenho (escalonamento paralelo), mas também por várias outras razões de funcionalidade (por exemplo, tolerância à falhas e uso eficiente de recursos localizados);

� a semântica distribuída envolve a semântica paralela, ou seja, a semântica paralela deve ser considerada e englobada pela criação de semânticas distribuídas.

Realidade

Universo

ModeloComputacional

Fontes deDistribuição

Modelagem Subliminar da distribuição

ArquiteturaDistribuída

Exploração automática da distribuição

Distribuição Implícita

SemânticaDistribuída

FIGURA 2.9 - Exploração automática da distribuição implícita

A figura 2.10 representa o surgimento do conceito de distribuição implícita. Conforme mostra a figura, suas principais motivações foram o paralelismo implícito e as arquiteturas distribuídas. A distribuição implícita é uma das concepções intermediárias que estimula a criação do Holoparadigma. Este fato é discutido na seção 2.7.

Paralelismo Implícito - Semântica Paralela

Distribuição Implícita -Semântica Distribuída

ArquiteturasDistribuídas

FIGURA 2.10 - Origem da distribuição implícita e da semântica distribuída

2.4 Multiparadigma e Arquitetura de Software

O desenvolvimento de software é baseado em abstrações. Essas abstrações possuem como base um paradigma, ou seja, uma forma de perceber e modelar o mundo real. No âmbito do paradigma são desenvolvidas metodologias, linguagens e ferramentas. Por exemplo, no contexto do paradigma orientado a objetos existem metodologias ([RUM 94]), linguagens de programação ([RUM 94, cap.15]) e

24

ferramentas (ambientes de desenvolvimento, compiladores, etc). Conforme salientado em [BAR 98, p.10], atualmente existem vários paradigmas de desenvolvimento de software e uma grande variedade de linguagens de programação. Os textos [FRI 92] e [BYT 95] apresentam a história da evolução das linguagens. Em complemento, em [BAR 98, cap.2] encontra-se uma descrição dos paradigmas básicos (imperativo, lógica, funcional, orientado a objetos e orientado a agentes).

Nos últimos anos vem crescendo o interesse da comunidade científica pelo tema de pesquisa multiparadigma ([HAI 86], [IEE 86], [PLA 91], [WEG 93], [MUL 95], [NGK 95], [CHA 97], [LEE 97], [BAR 98], [BAR 98a]) . Os pesquisadores deste tema propõem a criação de modelos de desenvolvimento de software através da unificação de paradigmas básicos. Através dessa proposta buscam dois objetivos, ou seja, a superação das limitações de cada paradigma e a exploração das suas características consideradas benéficas. Aconselha-se o texto [BAR 98] para aprofundamento dos estudos sobre o tema multiparadigma. Encontra-se naquele texto: uma descrição dos paradigmas básicos e suas limitações, o estudo de sete modelos multiparadigma e uma proposta de taxonomia multiparadigma. A filosofia da taxonomia proposta foi sugerida à comunidade científica na publicação [BAR 98a].

Conforme afirmam Shaw e Garlan ([SHA 96, p.1]), na medida em que aumentam o tamanho e a complexidade dos softwares, o projeto e a especificação da estrutura dos sistemas tornam-se mais significantes do que a escolha de algoritmos e estruturas de dados. Entre os tópicos relacionados com o projeto estrutural de sistemas destacam-se: organização do sistema como uma composição de elementos; protocolos de comunicação, sincronização e acesso a dados; distribuição física dos elementos; desempenho e evolução do sistema. Neste contexto, surge a arquitetura de software. Este tópico de pesquisa dedica-se a descrição dos elementos que compõem um sistema, as interações entre eles e os padrões que guiam sua composição.

Em [IEE 95, p.269] e [GAR 95, p.257] encontra-se a seguinte definição: arquitetura de software é a estrutura dos componentes de um programa/sistema, seus inter-relacionamentos e princípios e diretrizes que governam seu projeto e evolução. Em [SHA 96, p.3] encontra-se a seguinte afirmação: a arquitetura de um sistema de software o define em termos de componentes computacionais e interação entre estes componentes.

Merece destaque ainda, a distinção entre metodologias (por exemplo, análise e projeto orientado a objetos e análise e projeto estruturados [RUM 94, cap.12]) e arquiteturas de software apresentada em [IEE 95, p.270] e [GAR 95, p.258]. Ambas as técnicas dedicam-se a criação de modelos computacionais que reflitam, da melhor forma possível, o comportamento dos universos modelados (figura 2.1). Sem a utili zação de uma delas, a implementação será realizada sem modelagem, ou seja, de forma empírica e intuitiva (figura 2.11a). Por sua vez, uma metodologia convencional fornece um caminho para modelagem. Idealmente, uma metodologia define os passos que levam do universo até o modelo computacional. O sucesso das metodologias depende da sua capacidade em representar os requisitos do universo a ser modelado. Por exemplo, a metodologia orientada a objetos modela de forma adequada universos formados de objetos que trocam mensagens. Por outro lado, em um universo composto de entidades que representam conjuntos e que se relacionam através de operações, talvez uma metodologia baseada em entidades e relacionamentos ([BAT 92]) torne-se mais adequada. Normalmente, a modelagem de universos complexos envolve várias classes

25

de requisitos, ou seja, do ponto de vista das metodologias os universos complexos costumam ser heterogêneos. Sendo assim, uma única metodologia pode tornar-se insuficiente para modelagem de grandes sistemas computacionais (figura 2.11b). A arquitetura de software cria um espaço de modelagem onde podem ser realizadas negociações entre possíveis escolhas arquitetônicas para diferentes classes de requisitos no escopo do mesmo universo (figura 2.11c). Sendo assim, as diferentes características das metodologias e suas diversas habili dades para modelagem podem ser tratadas através de uma única técnica. A arquitetura de software propõe a unificação das metodologias através de uma nova filosofia de desenvolvimento baseada na pesquisa de elementos de software, sua composição e seu inter-relacionamento. Aconselha-se os textos [GAR 95], [IEE 95] e [SHA 96] para aprofundamento dos estudos sobre arquitetura de sofware. Em [IEE 95], destaca-se o artigo [SHA 95] que discute o tema e propõe um modelo de arquitetura de software denominado UniCon. O UniCon é apresentado também em [SHA 96, p.183]. O texto [GAR 92] destaca-se no estudo da composição.

Realidade

Implementação

Desenvolvimento empírico e intuitivo

Universo

RealidadeUniverso

Realidade

Implementação

Universo Requisitosda classe Y

Metodologia X Metodologia Y

Implementação

Arqu ietura de Software

Figura 2.11 (a) Figura 2.11 (b) Figura 2.11 (c)

Requisitosda classe X

FIGURA 2.11 - Comparação entre metodologias e arquitetura de software

Os modelos multiparadigma e a arquitetura de software possuem o mesmo objetivo, ou seja, o aperfeiçoamento das técnicas de desenvolvimento de softwares. Ambos temas de pesquisa buscam soluções através de uma revisão de propostas anteriores. Os modelos multiparadigma baseam-se no estudo dos paradigmas básicos. Por sua vez, a arquitetura de software basea-se no estudo das metodologias e técnicas de modelagem criadas pela engenharia de software. Através de uma análise mais profunda verifica-se que, em essência, a pesquisa multiparadigma e a arquitetura de software se confundem. As seguintes constatações corroboram essa afirmação:

� ambas dedicam-se ao aperfeiçoamento das abstrações utili zadas no desenvolvimento de software;

� as metodologias e técnicas pesquisadas pela arquitetura de software possuem como base os paradigmas pesquisados no âmbito da proposta multiparadigma. Existe uma forte relação entre os paradigmas e as metodologias de desenvolvimento de software;

26

ambas propostas buscam a síntese em suas áreas da ciência da computação. O tema multiparadigma busca sintetizar as descobertas realizadas no âmbito dos paradigmas de software. Por sua vez, a arquitetura de software busca sintetizar as descobertas da engenharia de software no âmbito das metodologias e técnicas de desenvolvimento;

recentes propostas consideradas da área de arquitetura de software se confundem com o tema multiparadigma. Por exemplo, a publicação [VRA 95] propõe um ambiente de desenvolvimento de softwares baseado na integração de múltiplos paradigmas através do modelo blackboard. Por sua vez, o texto [ZAV 96] propõe uma técnica para especificação de softwares baseada no tema multiparadigma. Em complemento, textos clássicos da arquitetura de software citam o tema multiparadigma (por exemplo, [SHA 96, p.164]).

Existe uma interessante distinção entre as áreas de pesquisa multiparadigma e arquitetura de software. A maioria das propostas relacionadas com o tema multiparadigma surgiram na comunidade que pesquisa linguagens de programação. Por exemplo, as seguintes propostas foram apresentadas na revista Computer Languages: [PLA 91], [NGK 95], [AMB 96], [CIA 96], [CHA 97], [HAN 97] e [LEE 97]. Por outro lado, as propostas de arquitetura de software surgem na comunidade que pesquisa engenharia de software. Por exemplo, os seguintes textos foram publicados na IEEE Transactions on Software Engineering: [SHA 95], [VRA 95] e [ZAV 96]. Além disso, em 1995 um volume dessa revista, contendo sete artigos, foi dedicado ao tema arquitetura de software ([IEE 95]). Ambas as áreas de pesquisa dedicam-se ao desenvolvimento de software. No entanto, tratam de níveis diferentes de abstração. A arquitetura enfoca a modelagem, posiciona-se assim em um alto nível de abstração. Por sua vez, as linguagens encontram-se em um baixo nível, pois enfocam a implementação. Aparentemente, ambos os temas poderiam ser unidos em uma única abordagem de pesquisa dedicada a criação de novos paradigmas de software. Esta nova abordagem seria guiada por dois princípios básicos, ou seja:

um paradigma orienta todo o desenvolvimento, desde a modelagem até a implementação. A semântica do paradigma deve permear todos os instrumentos a serem utili zados durante o desenvolvimento dos softwares;

a pesquisa de técnicas atuais de desenvolvimento de software é uma das principais fontes de informação para criação de novos paradigmas. Sendo assim, devem ser pesquisados os seguintes temas: paradigmas básicos ([BAR 98, cap.2]), criação de novos modelos de desenvolvimento através da unificação dos paradigmas já existentes (modelos multiparadigma [BAR 98, cap.3]), criação de novas técnicas de modelagem através do estudo das peças (componentes e conectores) de software (arquitetura de software [SHA 96]).

A percepção da convergência das pesquisas nos temas multiparadigma e arquitetura de software é uma das principais motivações para proposta de criação dos Paradigmas Holísticos (seção 2.6). Além disso, essa percepção é uma das bases do Holoparadigma (seção 2.7).

2.5 Regulagem da Fragmentação do Conhecimento

Conforme argumentado em [BAR 98, p.10], desde os primórdios a humanidade busca a compreensão do universo. Neste sentido, nos últimos séculos a ciência vem

27

alcançando contínuos sucessos. Em grande parte, o sucesso da ciência basea-se na estratégia de fragmentação do conhecimento, ou seja, na criação de diversas áreas de especialização. A fragmentação é uma solução natural para resolução de problemas complexos. No entanto, na medida em que a ciência estimula a fragmentação como instrumento de compreensão, estimula também a visão fragmentária como paradigma (modelo, padrão) do universo.

Albert Einstein no discurso pronunciado por ocasião do sexagêsimo aniversário de Max Planck analisa os princípios da pesquisa. Naquela abordagem ele salienta que, no âmbito da física, a extrema nitidez, a clareza e a certeza só se adquirem à custa de um imenso sacrifício, ou seja, a perda da visão de conjunto da realidade ([EIN 81, p.139]). Por sua vez, Ortega y Gasset ([ORT 92, p.72]), analisando o mesmo tema, salienta que todo esforço criador é uma especialização. No entanto, salienta ainda a necessidade da criação de sínteses do conhecimento. Destaca-se naquele texto a afirmação de que o movimento que leva a investigação a dissociar-se indefinidamente em problemas particulares exige uma regulagem compensatória. Essa regulagem deve ser realizada através de um movimento de direção inversa que contraía e retenha a tendência centrífuga da ciência. Ortega y Gasset estimula a criação de um talento científico dedicado à criação de sínteses e sistematizações. Ele o denomina de talento integrador. Merece destaque ainda, a abordagem de Ortega y Gasset, sob o título A barbárie da especialização, que enfoca o impacto da especialização/fragmentação do conhecimento nas distorções psicológicas do homem do século 20 ([ORT 87, cap.12]). Torna-se interessante ressaltar ainda, que tanto Einstein como Ortega y Gasset defenderam idéias holísticas também no âmbito da política. Ambos foram ativos defensores da criação da união européia, a qual gradualmente torna-se uma realidade. As opiniões de Einstein sob esse tema podem ser encontradas em [EIN 95]. Por sua vez, Ortega y Gasset iniciou a análise dessa questão na década de 30 ([ORT 87]) e complementou suas opiniões na década de 60 ([ORT 85]).

David Bohm afirma em [BOH 80, p.12] que a ciência carece de uma visão de mundo não-fragmentária. Afirma Bohm, que a abordagem que analisa o mundo em partes independentes não funciona bem na física moderna. Ele salienta que tanto na teoria da relatividade como na teoria quântica, noções que impliquem a totalidade indivisa de universo proporcionam um modo mais ordenado de considerar a natureza da realidade. Durante o primeiro capítulo do seu livro A Tolidade e a Ordem Implicada ([BOH 80]), David Bohm compara a fragmentação e a totalidade do ponto de vista de paradigmas para compreensão do universo. No âmbito desse tema, salientam-se ainda os diálogos publicados em [WEB 86], em especial, os textos [BOH 86] e [BOH 86a]. Vários outros textos abordam a questão fragmentação versus totalidade. Dentre eles destacam-se: [CAP 75], [CAP 82], [WIL 82], [GRO 94], [TAL 91] e [SOU 93].

Em [BAR 98, p.10], encontra-se a afirmação de que na ciência da computação o paradigma fragmentação/especialização vem sendo bastante utili zado para a solução de problemas. O desenvolvimento de sistemas computacionais destaca a fragmentação como instrumento de domínio da complexidade. A máxima "dividir para conquistar" atua como um arquétipo para a engenharia de software ([MAR 91, p.75]). A fragmentação/especialização vem estimulando a criação de diversos paradigmas de desenvolvimento de software e, em especial, a criação de uma quantidade enorme de linguagens de programação. A diversidade gerada pela ploriferação de paradigmas e linguagens é simbolizada pela torre de babel. Esse símbolo pode ser encontrado na capa

28

de todas as revistas Computer Languages e, em especial, em [FRI 92, título] e [MEI 88, p.211].

Conforme afirma Ortega e Gasset ([ORT 92, p.72]) a tendência centrífuga da ciência cria uma fragmentação do conhecimento. O autor defende a regulagem dessa tendência através da criação de sínteses. Conforme discutido na seção 2.4, no âmbito da ciência da computação, os temas de pesquisa multiparadigma e arquitetura de software atuam como sínteses em duas áreas de conhecimento, ou seja, linguagens de programação e modelagem de software. Além disso, ainda naquela seção defende-se a tese de que estes temas de pesquisa podem ser sintetizados em apenas uma frente de estudos, ou seja, paradigmas de desenvolvimento de software. A proposta de criação de paradigmas holísticos apresentada na próxima seção representa um esforço neste sentido. A regulagem da fragmentação do conhecimento na âmbito do desenvolvimento de softwares é uma forte motivação para criação do Holoparadigma.

2.6 Paradigmas Holísticos

Em [BAR 98, cap.2] são descritos cinco paradigmas de software, ou seja: paradigma imperativo, em lógica, funcional, orientado a objetos e orientado a agentes. Naquele texto, estes paradigmas são considerados básicos, pois servem de suporte para criação dos modelos multiparadigma. O texto [BAR 98] enfoca o universo multiparadigma como uma evolução bottom-up dos paradigmas básicos. A integração destes paradigmas é considerada uma solução para suas limitações e um caminho para criação de modelos mais genéricos. No entanto, a abordagem bottom-up limita os novos modelos aos paradigmas integrados. Esta constatação motiva o surgimento de novas abordagens para criação de paradigmas. Surge assim, a proposta top-down. Esta abordagem propõe a criação de novos paradigmas que suportem o desenvolvimento holístico de sistemas computacionais, ou seja, propõe a criação de paradigmas holísticos. A abordagem top-down estabelece que a criação de novos paradigma não deve considerar, inicialmente, as características dos paradigmas já existentes. Além disso, a criação deve partir de conceitos existentes no cotidiano e, logo após, procurar formas para sua implementação. Um paradigma holístico não pode ser criado pela integração de paradigmas básicos ou modelos multiparadigma. Sua criação depende de uma nova perspectiva baseada em uma visão universal e holística. No entanto, o estudo exaustivo das propostas atuais é indispensável para sua criação. A compreensão dos limites da proposta bottom-up cria o ambiente ideal para o surgimento da nova proposta. Além disso, sua implementação depende do uso de conceitos criados no universo bottom-up.

Conforme descrito em [BAR 98], a aplicação da abordagem top-down estabelece uma mudança no padrão evolutivo dos paradigmas de software. Atualmente, este padrão é baseado no enfoque bottom-up. Sendo assim, a nova visão top-down estabelece uma quebra de paradigma. Os modelos multiparadigma são permeados pela visão bottom-up. No entanto, seus objetivos coincidem com os da abordagem top-down, ou seja, criação de modelos mais amplos e eficientes. Baseado nesta perspectiva, pode-se perceber o universo multiparadigma como uma etapa intermediária na evolução dos paradigmas. A figura 2.12 representa essa realidade.

29

Evolução do s Paradigmas

Universo Multiparadigma (visão bottom-up )

Quebra do Paradigma Bottom-up

Paradigmas Holísticos (visão top-down)

Paradigmas Básicos

FIGURA 2.12 - Evolução dos paradigmas de desenvolvimento de software

Conforme descrito na seção 2.4, os temas de pesquisa multiparadigma e arquitetura de software se confundem. Ambos buscam a síntese em suas áreas da ciência da computação através da integração de propostas já existentes. Os modelos multiparadigma buscam a integração de paradigmas básicos e a arquitetura de software suporta a integração das metodologias de modelagem de sistemas. Em grande parte, a arquitetura de software segue o mesmo princípio bottom-up utili zado na pesquisa multiparadigma. Deste fato, surge a constatação de que várias limitações são compartilhadas por ambas propostas. A abordagem top-down, proposta pelos paradigmas holísticos, se aplica também a arquitetura de software. Além disso, a mudança de padrão evolutivo descrito para o tema multiparadigma envolve também a arquitetura de software. A figura 2.12 pode ser adaptada para inclusão da arquitetura de software. A figura 2.13 mostra essa adaptação, contextualizando os paradigmas holísticos na evolução das técnicas de desenvolvimento de software.

Evolução do Desenvolvimento de Software

Multiparadigma e Arquitetura de Software (visão bottom-up)

Quebra da Evolução Bottom-up

Paradigmas Holísticos (visão top-down)

Paradigmas Básicos e Metodo logias Convencionais

FIGURA 2.13 - Evolução das técnicas de desenvolvimento de software

Conforme descrito em [BAR 98, p.40], os princípios básicos de uma proposta estabelecem sua essência. Eles determinam seus objetivos mais amplos e permitem uma previsão dos resultados a serem alcançados. Além disso, os princípios básicos podem ser utili zados como guias durante sua implementação. Sempre que uma decisão tornar-se necessária, eles podem servir de auxílio na escolha da opção mais adequada. Um paradigma holístico possui três princípios básicos, ou seja:

30

� Pr incípio da Ergonometr ia Mental (PEM)

O PEM estabelece que um paradigma holístico deve possuir uma semântica simples. A simplicidade é inversamente proporcional à distância semântica entre a percepção cotidiana do universo e os conceitos utili zados no paradigma. Não importa a complexidade da proposta, desde que seja simples do ponto de vista humano. Um exemplo de aplicação do PEM é o paradigma orientado a objetos. Os conceitos utili zados neste paradigma são semanticamente simples (objeto, mensagem, herança, etc).

� Pr incípio da Abstração Tecnológica (PAT)

O PAT estabelece que um paradigma holístico deve abstrair-se da tecnologia computacional que será utili zada para sua implementação. Sendo assim, a semântica do paradigma deverá conter de forma implícita as características consideradas benéficas para a tecnologia desejada. Por exemplo, o paradigma poderá suportar naturalmente a exploração de paralelismo (semântica paralela) e a criação de sistemas distribuídos (semântica distribuída).

�� Pr incípio da Modelagem Universal (PMU)

O PMU estabelece que um paradigma holístico deve se adaptar naturalmente a modelagem de todos os tipos de sistemas computacionais. Este princípio constitui a essência do paradigma holístico e resulta da abordagem top-down. Normalmente, um paradigma básico suporta o desenvolvimento de qualquer tipo de sistema computacional. No entanto, seu enfoque é bastante específico (lógica, objetos, etc), dificultando assim, a modelagem de vários tipos de situações. Algumas vezes, a solução de um determinado tipo de problema através de um paradigma básico torna-se bastante artificial. Por exemplo, a aplicação do paradigma em lógica para a modelagem de sistemas matemáticos.

A figura 2.14 apresenta uma visão conjunta dos três princípios. A abordagem completa dos três cria um paradigma holístico. No entanto, pode acontecer de um paradigma contemplar apenas um dos princípios ou, até mesmo, dois deles. Neste caso, o paradigma não é holístico. Além disso, os princípios podem ser contemplados em diversos níveis de qualidade. Por exemplo, a orientação a objetos possui uma boa abordagem para o PEM. No entanto, falha no PMU, pois não trata de forma adequada das características do universo relacionadas com a matemática, lógica e psique.

PEM

PAT PMU

Paradigma Holístico

FIGURA 2.14 - Harmonia dos princípios básicos dos Paradigmas Holísticos

31

A criação de paradigmas holísticos permite a unificação dos temas de pesquisa multiparadigma e arquitetura de software, colaborando assim, para a regulagem da fragmentação do conhecimento através de sínteses proposta por Ortega y Gasset. A figura 2.15 representa a origem dos paradigmas holísticos. Conforme discutido na próxima seção, a proposta de paradigmas holísticos é uma das concepções intermediárias que servem de suporte para a criação do Holoparadigma.

Multiparadigma eArquitetura de Software

Paradigmas Holísticos

Regulagem da Fragmentação do Conhecimento

FIGURA 2.15 - Origem dos paradigmas holísticos

2.7 Nascimento do Holoparadigma

As seções anteriores apresentaram os temas que motivaram e nortearam a gestação do Holoparadigma. Conforme mostrado na figura 2.16, sua gestação pode ser visualizada em três níveis, ou seja:

� Nível Básico - Motivações Básicas: Neste nível encontram-se as quatro motivações básicas que estimularam a criação do Holoparadigma. Elas foram analisadas nas seções 2.1, 2.2, 2.4 e 2.5. As motivações podem ser organizadas em dois pares. Cada par origina uma concepção intermediária. O primeiro par motiva a criação da distribuíção implícita (figura 2.10). Por sua vez, o segundo par origina os paradigmas holísticos (figura 2.15);

� Nível Intermediár io - Concepções Intermediár ias: O segundo nível contém as duas concepções intermediárias que servem de suporte à criação do Holoparadigma. Elas foram discutidas nas seções 2.3 e 2.6;

� Nível Avançado - Concepção Final: No último nível encontra-se o Holoparadigma.

A figura 2.16 unifica as figuras 2.10 e 2.15. Além disso, sua organização equivale a organização das sete primeiras seções deste capítulo. O ramo da esquerda representa as três primeiras seções. O ramo da direita equivale as três seções seguintes. Por sua vez, a junção dos dois ramos representa a presente seção e o próximo capítulo. Em complemento, a figura 2.16 mostra as dependências existentes entre os principais temas de pesquisa envolvidos na criação do Holoparadigma. Os quatro temas posicionados no nível básico são independentes e constituem tópicos de pesquisa em contínuo avanço. Os dois temas localizados no nível intermediário dependem dos tópicos do nível básico. A setas representam as dependências entre eles. Avanços nas pesquisas das motivações básicas refletem nas concepções intermediárias. Finalmente, no nível avançado encontra-se o Holoparadigma, o qual depende diretamente das pesquisas nas concepções intermediárias e indiretamente das pesquisa nas motivações básicas.

32

Deve-se destacar ainda, que as concepções intermediárias constituem temas independentes. Sendo assim, vários tópicos de pesquisa podem surgir no escopo de cada uma delas. Por exemplo, vários tipos de paradigmas holísticos podem ser propostos. Por sua vez, a filosofia de distribuição implícita pode ser aplicada em paradigmas básicos e modelos multiparadigma. A proposta de criação do Holoparadigma integra ambas as concepções intermediárias na busca de um paradigma holístico que suporte distribuição implícita através de uma semântica distribuída.

Multiparadigma e Arquitetura de Software

Paradigmas Holísticos

Regulagem da Fragmentaçãodo Conhecimento

Paralelismo Implícito - Semântica Paralela

Distribuição Implícita -Semântica Distribuída

ArquiteturasDistribuídas

Holoparadigma

Nível Básico - Motivações Básicas

Nível Intermediário- Concepções Intermediárias

Nível AvançadoConcepção Final

FIGURA 2.16 - Níveis de gestação do Holoparadigma

2.8 Conclusões

Este capítulo abordou a gestação do Holoparadigma. Neste contexto, foram apresentados os temas de pesquisa que motivaram e nortearam seu desenvolvimento. As principais constatações e conclusões surgidas no decorrer do capítulo são apresentadas nessa seção. A leitura dos itens a seguir permite uma visão geral do capítulo dois.

� Seção 2.1 - Paralelismo Implícito: a exploração do paralelismo está relacionada com o universo a ser modelado. Se o universo não possuir fontes de paralelismo, não importa o paradigma utili zado, o modelo computacional resultante não possuirá paralelismo implícito. Por outro lado, se o universo modelado contiver paralelismo em potencial, o paradigma pode transferi-lo para o modelo computacional, viabili zando assim sua exploração automática. A transmissão do potencial de paralelismo entre universo e modelo pode ser subliminar, ou seja, o paralelismo pode ser refletido de forma natural e, até mesmo, inconsciente;

� Seção 2.2 - Arquiteturas Distr ibuídas: em um futuro próximo as redes de computadores constituirão a base para organização dos sistemas computacionais. Sendo assim, as arquiteturas distribuídas assumem uma posição de destaque. O poder de processamento de uma arquitetura distribuída está relacionado com a quantidade e o poder dos seus nodos elementares. A eficiência de uma arquitetura distribuída depende da velocidade dos canais de comunicação e da qualidade dos softwares que gerenciam o sistema. A arquitetura distribuída é bastante confiável, pois permite a implementação de

33

várias técnicas de tolerância à falhas baseadas na redundância introduzida pela existência de múltiplos nodos elementares. A natureza da arquitetura distribuída é bastante atraente para organização dos sistemas computacionais, pois permite a distribuição espacial dos recursos;

� Seção 2.3 - Distr ibuição Implícita: uma arquitetura paralela com memória distribuída é semelhante a uma arquitetura distribuída composta de arquiteturas elementares uniprocessadas. A execução paralela visando aumento de desempenho surge como uma das várias oportunidades a serem exploradas nas arquiteturas distribuídas. O potencial de distribuição existente no universo modelado pode ser transferido de forma subliminar para o modelo computacional (distribuição implícita). O processo de exploração implícita demanda a criação de uma semântica distribuída. A arquitetura distribuída é mais genérica do que a arquitetura paralela. A distribuição implícita envolve o paralelismo implícito, ou seja, o paralelismo implícito é uma das características a serem exploradas no âmbito da distribuição implícita. A semântica distribuída envolve a semântica paralela, ou seja, a semântica paralela deve ser considerada e englobada pela criação de semânticas distribuídas;

� Seção 2.4 - Multiparadigma e Arquitetura de Software: os modelos multiparadigma e a arquitetura de software possuem o mesmo objetivo, ou seja, o aperfeiçoamento das técnicas de desenvolvimento de softwares. Ambos temas de pesquisa buscam soluções através de uma revisão de propostas anteriores. Os modelos multiparadigma baseam-se no estudo dos paradigmas básicos. Por sua vez, a arquitetura de software basea-se no estudo das metodologias e técnicas de modelagem criadas pela engenharia de software. Através de uma análise mais profunda verifica-se que, em essência, a pesquisa multiparadigma e a arquitetura de software se confundem. Ambas propostas buscam a síntese em suas áreas da ciência da computação. O tema multiparadigma busca sintetizar as descobertas realizadas no âmbito dos paradigmas de software. Por sua vez, a arquitetura de software busca sintetizar as descobertas da engenharia de software no âmbito das metodologias e técnicas de desenvolvimento. Um paradigma deve orientar todo o desenvolvimento, desde a modelagem até a implementação. A semântica do paradigma deve permear todos os instrumentos a serem utili zados durante o desenvolvimento dos softwares;

� Seção 2.5 - Regulagem de Fragmentação do Conhecimento: em grande parte, o sucesso da ciência basea-se na estratégia de fragmentação do conhecimento, ou seja, na criação de diversas áreas de especialização. A fragmentação é uma solução natural para resolução de problemas complexos. No entanto, na medida em que a ciência estimula a fragmentação como instrumento de compreensão, estimula também a visão fragmentária como paradigma (modelo, padrão) do universo. O movimento que leva a investigação a dissociar-se indefinidamente em problemas particulares exige uma regulagem compensatória. Essa regulagem deve ser realizada através de um movimento de direção inversa que contraía e retenha a tendência centrífuga da ciência. Na ciência da computação o paradigma fragmentação/especialização vem sendo bastante utili zado para a solução de problemas. O desenvolvimento de sistemas computacionais destaca a fragmentação como instrumento de domínio da complexidade. No âmbito da ciência da computação, os temas de pesquisa

34

multiparadigma e arquitetura de software atuam como sínteses em duas áreas de conhecimento, ou seja, linguagens de programação e modelagem de software. Estes temas de pesquisa podem ser sintetizados em apenas uma frente de estudos, ou seja, paradigmas holísticos de desenvolvimento de software;

� Seção 2.6 - Paradigmas Holísticos: o universo multiparadigma atua como uma evolução bottom-up dos paradigmas básicos. No entanto, essa abordagem limita os modelos multiparadigma aos paradigmas integrados. A proposta top-down propõe a criação de novos paradigmas que suportem o desenvolvimento holístico de sistemas computacionais, ou seja, propõe a criação de paradigmas holísticos. A aplicação da abordagem top-down estabelece uma mudança no padrão evolutivo dos paradigmas de software. A arquitetura de software segue o mesmo princípio bottom-up utili zado na pesquisa multiparadigma e, portanto, compartilha das mesmas limitações. Portanto, a abordagem top-down proposta pelos paradigmas holísticos se aplica também a arquitetura de software. A criação de paradigmas holísticos permite a unificação dos temas de pesquisa multiparadigma e arquitetura de software, colaborando assim, para a regulagem da fragmentação do conhecimento através de sínteses;

� Seção 2.7 - Nascimento do Holoparadigma: a gestação do holoparadigma pode ser compreendida em três níveis (básico, intermediário e avançado). As motivações básicas são independentes e constituem tópicos de pesquisa em contínuo avanço. As concepções intermediárias também constituem temas de pesquisa independentes. A proposta de criação do Holoparadigma integra as concepções intermediárias na busca de um paradigma holístico que suporte distribuição implícita através de uma semântica distribuída.

O próximo capítulo apresenta os princípios do Holoparadigma. A compreensão dos temas apresentados durante o capítulo dois é essencial para compreensão das idéias apresentadas no capítulo três. As definições e conclusões surgidas no presente capítulo servem de base para criação do Holoparadigma.

35

3 Pr incípios do Holoparadigma

Este capítulo apresenta os princípios do Holoparadigma (de forma abreviada, Holo). Holo é um paradigma holístico de desenvolvimento de software que possui uma semântica distribuída. Através dessa semântica, Holo estimula a exploração automática das vantagens introduzidas pelas arquiteturas distribuídas. O estímulo à distribuição implícita é seu principal objetivo. O capítulo está organizado em oito seções. A primeira seção descreve a semântica de Holo, ou seja, a Holosemântica. A seção 3.2 contém vários tópicos relacionados com a unidade de modelagem usada em Holo, ou seja, o Ente. Por sua vez, a terceira seção analisa a unidade de informação proposta por Holo, ou seja, o Fato. A seção 3.4 apresenta o estilo arquitetônico que suporta a implementação em Holo. A quinta seção discute a Holomodelagem, ou seja, a modelagem de sistemas computacionais através de Holo. A sexta seção descreve sua plataforma de desenvolvimento e execução. Finalmente, a seção 3.7 propõe a aplicação do Holo na automação residencial.

3.1 Holosemântica

Um paradigma de software suporta a modelagem de sistemas computacionais. Com esse intuito, ele estabelece um conjunto de abstrações que serão utili zadas para criação dos modelos. A eficiência do paradigma está relacionado com a distância entre o significado das abstrações e o significado dos conceitos existentes no universo modelado. No âmbito da Engenharia de Software, essa distância é denominada gap semântico (figura 3.1). Um gap semântico pequeno significa que as abstrações são adeqüadas.

A semântica está relacionada com o significado. No caso dos paradigmas de software, a semântica estabelece o significado das abstrações do paradigma. Por exemplo, o paradigma orientado a objetos possui como principal abstração o objeto. No âmbito deste paradigma, objeto é a unidade de modelagem e significa qualquer realidade que possa ser organizada em uma unidade que encapsule a estrutura e o comportamento de dados ([RUM 94, p.2]).

Realidade

Universo

ModeloComputacional

ModelagemGap Semântico

FIGURA 3.1 - Gap semântico

36

A semântica do Holo é denominada Holosemântica. A holosemântica estabelece que a realidade é simples e pode ser compreendida através de duas unidades de modelagem, ou seja:

� Unidade de Existência - Ente: Toda existência é modelada através de um ente. A seção 3.2 descreve essa unidade;

� Unidade de Informação - Fato: Toda informação é modelada através de um fato. A seção 3.3 dedica-se ao estudo do fato.

A modelagem em Holo utili za somente essas unidades. Sendo assim, torna-se simples a criação e compreensão dos modelos computacionais. Destacam-se como os três principais objetivos da holosemântica:

� Pequeno gap semântico: A distância semântica entre as unidades de modelagem e a realidade é pequena. O termos ente e fato são usados no cotidiano, tornando-se assim, agradáveis para o uso humano. Por outro lado, ambos os termos não são vulgarmente usados. Eles não possuem vários significados e não são utili zados em larga escala. Tanto no cotidiano quanto no holoparadigma, ambos os termos possuem sempre o mesmo significado. Através de um pequeno gap semântico a holosemântica satisfaz o primeiro princípio dos paradigmas holísticos, ou seja, o princípio da ergonometria mental / PEM (seção 2.6);

� Semântica distr ibuída: A holosemântica é uma semântica distribuída (seção 2.3), ou seja, transmite de forma subliminar para o modelo, o potencial de distribuição existente no universo modelado. Conforme descrito nas seções 3.2 e 3.3, os entes e fatos estimulam a exploração automática da distribuição e do paralelismo. A holosemântica contempla o segundo princípio dos paradigmas holísticos, ou seja, a abstração tecnológica (PAT, seção 2.6);

� Semântica universal: A holosemântica suporta o terceiro princípio dos paradigmas holísticos, ou seja, a modelagem universal (PMU, seção 2.6). As unidades de modelagem do Holo podem ser usadas para a criação de todos os tipos de sistemas computacionais. Entes e fatos se adaptam naturalmente a todas as situações.

A figura 3.2 representa a aplicação da Holosemântica na modelagem de sistemas.

Reali dade

Un ive rso

Mod eloCo m pu tac io nal

Fo n tes d eDis tr ibu ição

En tes: Un idades de Ex is tênc iaFatos: Un idades de In fo rm ação

A rqu itetu raDis tr ibu íd a

Exp lo ração au to m ática da d is tr ib u ição

Dis tr ibu ição Im p líc i ta

Ho lo sem ân t ica(Sem ânt ica Dis tr ib u íd a)

Un idades de Mod elagem(pequeno gap sem ân tico )

FIGURA 3.2 - Holosemântica aplicada a modelagem

37

3.2 Ente

Esta seção dedica-se ao estudo da unidade de modelagem de existência, ou seja, o ente. A subseção 3.2.1 apresenta sua descrição. Por sua vez, a subseção 3.2.2 contempla a classificação organizacional dos entes. Na subseção 3.2.3 são apresentados os índices utili zados para descrição de entes. Em complemento, as demais subseções abordam os seguintes temas relacionados: seu compartilhamento, sua distribuição, sua mobili dade, seu ciclo existencial e suas formas de criação e extinção.

3.2.1 Descrição do Ente

O ente é a principal abstração do Holoparadigma. Ele atua como unidade de modelagem de existência. Toda existência é um ente, desde a mais simples até a mais complexa. O ente possui duas características básicas, ou seja, distinção e história (figura 3.3). Encontra-se a seguir uma descrição dessas caraterísticas:

� Distinção: Um ente existe de forma distinta, ou seja, ele pode ser distinguido do restante do universo. Sendo assim, a existência de um ente depende da percepção de quem distingue. Se uma distinção é percebida, existe um ente. A distinção está relacionada com níveis de abstração. Por exemplo, este texto é um ente. No entanto, em níveis mais baixos de abstração existem vários outros entes (capítulos, seções, subseções, parágrafos, frases e caracteres). A existência deles depende do nível de abstração com que o leitor percebe o texto. Um ente pode ser um objeto, um ser vivo, um software, um modelo computacional, uma organização, um grupo de entes e muitas outras existências;

� Histór ia: Um ente possui história, ou seja, ele é uma existência temporal. Um ente possui passado, presente e futuro. Desde sua criação inicia a construção de sua história, a qual evolui até sua extinção. A história é o passado de um ente. A principal característica da história é seu perfil monotônico, ou seja, ela evolui de forma coerente e sem contradições. Algumas constatações realizadas no presente entram para a história.

Distinção

Ente

História

EnteUNIVERSO

História

FIGURA 3.3 - Características dos entes

3.2.2 Classificação Organizacional

Os entes podem ser classificados de acordo com sua organização. Do ponto de vista organizacional, existem dois tipos de entes, ou seja:

38

� Ente Elementar : Um ente elementar é monolítico, ou seja, não é composto de partes (distinções). Um ente torna-se elementar quando não existe interesse em dividi-lo ou quando seu particionamento torna-se impossível;

� Ente Composto: Um ente composto é formado por outros entes, os quais são denominados entes componentes. Os entes componentes também podem ser compostos. Não existe limite para níveis de composição.

A figura 3.4 exempli fica a organização de um ente formado por três entes, dos quais dois compostos e um elementar. Cada ente composto é formados por três entes elementares. O entes compostos são representados por círculos, os elementares por retângulos e a história por um cubo. Conforme mostrado na figura, cada ente possui sua história. A história fica encapsulada no ente e, no caso dos entes compostos, é compartilhada pelos entes componentes. Os entes componentes participam da construção da história compartilhada e sofrem os reflexos das mudanças históricas.

História

História

História

História

História

História

História

História

História

História

Nível 0

Nível 1

Nível 2 Nível 2

FIGURA 3.4 - Exemplo de ente composto

Torna-se interessante uma comparação entre a organização das arquiteturas distribuídas, apresentada na seção 2.2, e as possíveis configurações de entes elementares e compostos. A unidade organizacional das arquiteturas distribuídas é o nodo. Existem dois tipos de nodos, ou seja, elementares e compostos. Sendo assim, existe uma equivalência entre nodos e entes. Além disso, os entes compostos podem ser classificados da mesma forma que os nodos compostos. Neste sentido, seria criada a seguinte classificação para entes compostos:

� Ente Homogêneo: Um ente homogêneo é um ente composto de entes do mesmo tipo, ou seja, somente elementares ou somente compostos;

� Ente Heterogêneo: Um ente heterogêneo é um ente composto de entes de tipos diferentes, ou seja, um ou mais entes elementares misturados com um ou mais entes compostos;

39

� Ente Homogêneo Básico ou Ente Básico: Um ente básico é um ente composto de entes elementares;

� Ente Homogêneo Avançado ou Ente Avançado: Um ente avançado é um ente composto de entes compostos.

A figura 3.5 apresenta a classificação organizacional dos entes. Por sua vez, a figura 2.4 mostra a classificação dos nodos de uma arquitetura distribuída. Conforme pode ser constatado através da comparação dessas figuras, a classificação de nodos e entes é idêntica.

Ente

Composto Elementar

Homogêneo Heterogêneo

Básico Avançado

FIGURA 3.5 - Classificação organizacional dos entes

3.2.3 Índices de Entes

Utili zando-se como base a classificação organizacional apresentada na seção 3.2.2, podem ser criados índices que facilit em a visualização e a descrição dos entes. Um Índice de Ente (INE) descreve algum aspecto relevante de um ente. A seguir são apresentados dez INEs:

� Nível de Abstração (NIA): Os entes compostos podem ser visualizados em vários níveis de abstração. O NIA estabelece o nível que deve ser usado para percepção de um ente. Os NIAs são numerados crescentemente, sendo que o nível mais alto de abstração é zero. Um ente elementar possui apenas um NIA, ou seja, o zero. Um ente composto possui pelo menos dois NIAs, ou seja, o zero e o um. O ente mostrado na figura 3.4 pode ser percebido em três NIAs. No NIA zero visualiza-se o ente como uma unidade, sem considerar sua composição. No NIA um percebe-se o ente como composto de dois entes compostos e um ente elementar. A figura mostra o NIA dois, ou seja, toda a composição do ente;

� Total de Níveis de Abstração (TONIA): O TONIA determina o total de níveis de abstração existentes em um ente. Um ente elementar possui um TONIA igual a 1. Por outro lado, o TONIA de um ente composto deve ser maior do que 1, no entanto, não possui limit e máximo. O TONIA estabelece o intervalo de variação do NIA de acordo com a regra 3.1.

40

0 � NIA � TONIA - 1 (3.1)

O ente mostrado na figura 3.4 possui um TONIA igual a 3. Aplicando a regra 3.1 descobre-se que seu NIA pode variar entre 0 e 2.

� Nível de Composição (NIC): O NIC determina a profundidade de visualização da composição de um ente. O NIC assemelha-se ao NIA, no entanto, enfoca a composição e aplica-se somente a entes compostos. Ambos os índices possuem sempre o mesmo valor, no entanto, não existe NIC zero. Os NICs são numerados a partir de um e crescem na medida em que desvenda-se a composição de um ente. O ente mostrado na figura 3.4 possui dois NICs. O NIC um mostra três entes componentes, dois compostos e um elementar. A figura visualiza o NIC dois. As seguintes regras podem ser utili zadas para relacionamento do indíce NIC com os índices NIA e TONIA:

NIC = NIA (3.2)

1 � NIC � TONIA - 1 (3.3)

Tendo como base a regra 3.2, sempre que for indiferente o enfoque do índice (composição ou abstração) será utili zado somente o termo nível e a abreviatura NI. Por exemplo, existem dois entes compostos e um ente elementar no nível um do ente mostrado na figura 3.4;

� Total de Níveis de Composição (TONIC): Este índice determina o total de níveis de composição existentes em um ente. Um ente elementar possui TONIC igual a 0. O TONIC de um ente composto possui valor mínimo igual a 1 e não possui limit e máximo. A seguinte regra relaciona os índices NIC e TONIC:

1 � NIC � TONIC (3.4)

Em complemento, as seguintes regras podem ser usadas para o relacionamento do TONIC com os índices NIA e TONIA:

0 � NIA � TONIC (3.5)

TONIC = TONIA -1 (3.6)

O ente mostrado na figura 3.4 possui um TONIC igual a 2. Aplicando-se as regras 3.4 e 3.5 determina-se que seu NIC pode variar entre 1 e 2 e seu NIA pode variar entre o e 2. Em complemento, a regra 3.6 determina que seu TONIA é 3.

� Número de Entes Componentes Elementares (NECE): O NECE determina o número de entes componentes elementares que se localizam em um determinado nível de um ente. O NECE pode ser obtido através da seguinte pergunta: quantos entes elementares surgem se desvendado um determinado nível? Um ente elementar não possui índice NECE. Por sua vez, nos entes compostos o NECE está sempre ligado a um nível. Por exemplo, na figura 3.4:

Se NI = 1 então NECE = 1

Se NI = 2 então NECE = 6

O NIA zero dos entes compostos não possui índice NECE.

41

� Número de Entes Componentes Compostos (NECO): Este índice indica o número de entes componentes compostos que se localizam em um determinado nível. Um ente elementar não possui índices NECO. Nos entes compostos o NECO está relacionado com um nível. Na figura 3.4:

Se NI = 1 então NECO = 2

Se NI = 2 então NECO = 0

O NIA zero dos entes compostos não possui índice NECO.

� Número de Entes Componentes (NEC): Este índice determina o número de entes componentes que se localizam em um determinado nível de um ente. Um ente elementar não possui índices NEC. Por sua vez, nos entes compostos o NEC deve estar relacionado com um nível. Por exemplo, na figura 3.4:

Se NI = 1 então NEC = 3

Se NI = 2 então NEC = 6

O NIA zero dos entes compostos não possui índice NEC. Além disso, em um determinado nível de um ente, a seguinte regra relaciona os índices NEC, NECO e NECE:

. NEC = NECO + NECE (3.7)

Por exemplo, na figura 3.4:

Se NI = 1 então NEC = NECO + NECE = 2 + 1 = 3

Se NI = 2 então NEC = NECO + NECE = 0 + 6 = 6

� Total de Entes Componentes Elementares (TECE): O índice TECE determina o número total de entes componentes elementares que existem em um ente. Todos os níveis de um ente são considerados. Por exemplo, o ente da figura 3.4 possui TECE igual a sete. Se o índice TECE é vinculado a um nível, determina o total de entes componentes elementares até o nível estabelecido. Por exemplo, no ente da figura 3.4:

Se NI = 1 então TECE = 1

Se NI = 2 então TECE = 7

O NIA zero não possui índice TECE. Além disso, o índice TECE do último nível de um ente é igual ao TECE do ente.

� Total de Entes Componentes Compostos (TECO): O índice TECO determina o número total de entes componentes compostos existentes em um ente. O índice TECO considera todos os níveis de um ente. Por exemplo, na figura 3.4 o ente possui TECO igual a dois. Se o índice TECO for associado a um nível de um ente, determina o total de entes componentes compostos até o nível previsto. Na figura 3.4:

Se NI = 1 então TECO = 2

Se NI = 2 então TECO = 2

42

O NIA zero não possui índice TECO. Além disso, o TECO do último nível de um ente é igual ao TECO do ente

� Total de Entes Componentes (TEC): Este índice determina o número total de entes componentes existentes em um ente. O índice TEC considera todos os níveis e ambos os tipos de entes (elementares e compostos). Por exemplo, o ente mostrado na figura 3.4 possui TEC igual a nove. Por outro lado, se o índice TEC for associado a um determinado nível de um ente, ele determina o número total de entes componentes existentes até o nível estabelecido. Por exemplo, na figura 3.4:

Se NI = 1 então TEC = 3

Se NI = 2 então TEC = 9

O NIA zero não possui índice TEC. Além disso, o índice TEC do último nível de um ente é igual ao índice TEC do ente. A seguinte regra relaciona os índices TEC, TECO e TECE:

. TEC = TECO + TECE (3.8)

Por exemplo, na figura 3.4:

TEC do ente = TECO do ente + TECE do ente = 2 + 7 = 9

Se NI = 1 então TEC = TECO + TECE = 2 + 1 = 3

Se NI = 2 então TEC = TECO + TECE = 2 + 7 = 9

3.2.4 Compartilhamento de Entes

Entes podem compartilhar entes. Um ente compartilhado é componente de dois ou mais entes compartilhadores. Um ente compartilhado pode ser elementar ou composto. Um ente elementar compartilhado, gera um compartilhamento elementar . Por sua vez, um ente composto compartilhado, gera um compartilhamento composto. Além disso, entes podem compartilhar vários entes. O número de entes compartilhados é denominado grau de compartilhamento. Quando os entes compartilhados são do mesmo tipo (elementares ou compostos), tem-se um compartilhamento homogêneo. Por outro lado, quando os entes compartilhados são de tipos diferentes surge um compartilhamento heterogêneo.

A figura 3.6 mostra três entes compartilhando um ente elementar. Este é um caso de compartilhamento elementar de grau um. Os compartilhamentos de grau um sempre são homogêneos. Conforme mostrado na figura, o ente compartilhado tem acesso a história dos entes compartilhadores. Sendo assim, torna-se um elo de ligação entre eles. Um ente compartilhado atua como um conector (semelhante aos conectores da arquitetura de software [SHA 95], [SHA 96]), o qual regula o fluxo de informações entre entes através de uma lógica própria.

Os índices de entes apresentados na seção 3.2.3 podem ser utili zados para descrição dos aspectos relevantes dos compartilhamentos. Neste caso, passam a ser chamados de índices de compartilhamento. A aplicação dos índices está baseada na analogia compartilhamento/ente. Essa analogia indica que o compartilhamento pode ser compreendido como um ente composto virtual. O compartilhamento equivale ao

43

nível de abstração zero de um ente. O grau de compartilhamento equivale ao TEC do nível um. Entes compostos podem ser compreendidos como conjuntos. Sendo assim, o compartilhamento pode ser tratado como a operação intersecção. Em futuros trabalhos a Teor ia dos Conjuntos ([LIP 78], [FIL 85]) será aplicada na análise dos entes e do compartilhamento entre eles.

História

História

História

História

História

História

História

História

História

História

Ente Compartilhado

FIGURA 3.6 - Exemplo de ente compartilhado

3.2.5 Distr ibuição de Entes

Conforme exposto na seção 3.1, a holosemântica estimula a exploração automática da distribuição. Além disso, na seção 3.2.2 foi ressaltada a semelhança entre a organização dos entes e dos nodos em arquiteturas distribuídas. Neste contexto, torna-se interessante destacar dois possíveis estados de distr ibuição que um ente pode assumir quando o hardware utili zado é uma arquitetura distribuída. Os estados são os seguintes:

� Centralizado: Um ente está centralizado quando localiza-se em apenas um nodo de uma arquitetura distribuída. Entes elementares estão sempre centralizados. Um ente composto está centralizado se todos seus entes componentes localizam-se no mesmo nodo;

� Distr ibuído: Um ente está distribuído quando localiza-se em mais de um nodo de uma arquitetura distribuída. Entes elementares não podem estar distribuídos. Um ente composto está distribuído se os entes componentes estão localizados em dois ou mais nodos de uma arquitetura distribuída.

Com base nos estados de distribuição surgem dois tipos de entes, ou seja:

� Ente Centralizado: Um ente centralizado encontra-se sempre centralizado;

44

� Ente Distr ibuído: Um ente distribuído pode encontrar-se distribuído ou centralizado. Sendo assim, pode-se afirmar que este tipo de ente possui potencial de distr ibuição. Todo ente que está distribuído é necessariamente distribuído.

A figura 3.7 exempli fica uma possível distribuição do ente apresentado na figura 3.4. Conforme mostra a figura 3.7, o ente encontra-se distribuído em dois nodos da arquitetura. A história de um ente distribuído é denominada histór ia distr ibuída. A forma de implementação da história distribuída depende do ambiente de execução (DSM, cliente/servidor, etc).

História

História

História

História

História

História

HistóriaHistória

História

História

Nodo 1 Nodo 2

Nível 0 Nível 1

Nível 2 Nível 2

FIGURA 3.7 - Exemplo de ente distribuído

3.2.6 Mobili dade de Entes

A mobili dade é a capacidade que permite o deslocamento de um ente. No âmbito do Holoparadigma existem dois tipos de mobili dade, ou seja:

� Mobili dade Lógica: A mobili dade lógica relaciona-se com o deslocamento a nível de modelagem, ou seja, sem considerações sobre a plataforma de execução. Neste contexto, um ente se move quando cruza uma ou mais fronteiras de entes;

� Mobili dade Física: A mobili dade física relaciona-se com o deslocamento entre nodos de uma arquitetura distribuída. Neste contexto, um ente se move quando desloca-se de um nodo para outro.

45

A figura 3.8 exempli fica uma possível mobili dade lógica no interior do ente inicialmente apresentado na figura 3.4. Conforme exempli ficado, após o deslocamento o ente móvel não possui mais acesso a história do ente abandonado (ente or igem). No entanto, ele passa a ter acesso a história do ente que o recebeu (ente destino). Neste caso, somente ocorrerá mobili dade física se os entes origem e destino estiverem alocados em diferentes nodos de uma arquitetura distribuída.

História

História

História História

História

História

História

História

História

História

Mobilidade

Nível 0

Nível 1

Nível 2

Nível 2

FIGURA 3.8 - Exemplo de mobili dade

As mobili dades lógica e física são independentes, ou seja, a ocorrência de um tipo de deslocamento não implica na ocorrência do outro. O fato da mobili dade lógica não implicar na mobili dade física é facilmente percebido considerando-se que, por exemplo, o ente mostrado na figura 3.8 pode estar localizado em apenas um nodo de uma arquitetura elementar. Por outro lado, o fato da mobili dade física não implicar na mobili dade lógica é mais sutil e merece atenção especial. Considere-se o ente distribuído mostrado na figura 3.7. Se o ente elementar localizado no nível um realizar um deslocamento físico conforme mostrado na figura 3.9, não haverá mobili dade lógica, apesar de ter ocorrido uma mobili dade física.

Do ponto de vista da mobili dade, os entes podem ser classificados em quatro tipos, ou seja:

� Ente Logicamente Estático (ELE): Ente que não possui a capacidade de mobili dade lógica;

� Ente Logicamente Móvel (ELM): Ente que possui a capacidade de mobili dade lógica;

� Ente Fisicamente Estático (EFE): Ente que não possui a capacidade de mobili dade física;

� Ente Fisicamente Móvel (EFM): Ente que possui a capacidade de mobili dade física.

46

Os dois primeiros tipos classificam os entes do ponto de vista da mobili dade lógica. Os outros dois os classificam do ponto de vista da mobili dade física. A descrição completa do potencial de deslocamento de um ente depende de sua classificação em ambas as mobili dades. Denomina-se ente estático aquele que é ELE e EFE. Por sua vez, denomina-se ente móvel aquele que é ELM e EFM. Além disso, em determinado escopo de discussão os termos estático e móvel podem estar obviamente relacionados com apenas um tipo de mobili dade. Neste caso, torna-se desnecessária a classificação completa, ou seja, a utili zação dos termos logicamente e fisicamente. Por exemplo, no âmbito da discussão do Holoparadigma como instrumento de modelagem, sem preocupações em relação à plataforma de execução, a mobili dade sempre será lógica.

História

História

História

História

História

História

HistóriaHistória

História

História

Nodo 1 Nodo 2

Nível 0 Nível 1

Nível 2 Nível 2

Mobili dade

FIGURA 3.9 - Mobili dade física sem mobili dade lógica

3.2.7 Ciclo Existencial dos Entes

O ciclo existencial de um ente consiste nas etapas percorridas durante sua existência. Este ciclo é composto de três etapas, ou seja: criação, existência e extinção. As etapas existencias são descritas a seguir e mostradas de forma esquemática na figura 3.10.

� Criação: Conforme analisado na seção 3.2.1 e mostrado na figura 3.3, a distinção é uma característica essencial dos entes. A criação de um ente ocorre quando ele passa a ser percebido, ou seja, distingüido. Um ente sempre é criado por outro ente. O ente que cria é denominado ente criador . Por sua vez, o ente que surge é denominado ente criado. A seção 3.2.8 apresenta as várias formas de criação de entes;

� Existência: Após a criação, inicia a existência do ente. Durante esse processo ele fica submetido a dinâmica dos entes. No seu interior podem ocorrer vários processos, tais como, criações, extinções, deslocamentos, distribuição, etc. Além disso, ele interage com os entes que existem ao seu redor e compartilha a história do ente no qual está inserido;

47

Extinção: Um ente deixa de existir quando ocorre sua extinção. Um ente pode ser extinto por outro ente. O ente que extingue é denominado ente extintor . Por sua vez o ente que deixa de existir é denominado ente extinto. Além disso, um ente pode se auto-extinguir, neste caso, ele é extintor e extinto. Este processo recebe o nome de auto-extinção. Existem várias formas de extinção, as quais serão descritas na seção 3.2.9.

Criação

Existência

Extinção

Tempo

0

FIGURA 3.10 - Ciclo existencial de um ente

3.2.8 Formas de Cr iação dos Entes

Os entes podem ser criados através das seguintes formas de criação:

Criação Or iginal: Ocorre quando o ente criado é original, ou seja, não é composto e nem baseado em entes já existentes. Quando criado, um ente or iginal não possui história. No entanto, sua criação no interior de outro ente faz com que ele compartilhe uma história já em andamento. A criação original de entes elementares é simples e envolve o surgimento de apenas um ente. Por outro lado, a criação original de um ente composto demanda a criação dos entes componentes, os quais por sua vez, podem também ser compostos. Sendo assim, a criação de um ente composto pode resultar na criação de vários entes organizados em vários níveis;

Criação por Agregação: Ocorre quando um ente composto é criado pela agregação de entes já existentes. Um ente criado por agregação não possui história prévia. No entanto, seus entes componentes possuem. Um ente criado por agregação é denominado ente agregador . Os entes que foram reunidos pelo ente agregador são denominados entes agregados. Antes da agregação, os entes agregados sempre estão em um mesmo nível de um ente composto. O ente agregador posiciona-se neste mesmo nível. Sendo assim, os entes agregados descem um nível de abstração. Se eles forem compostos, a mudança reflete em todos seus níveis de composição. Além disso, os entes agregados podem ser elementares e compostos. Denomina-se agregação homogênea quando os entes agregados são do mesmo tipo. Neste caso, surge um ente agregador homogêneo. Por sua vez, quando a agregação envolve entes de tipos diferentes ocorre uma agregação heterogêna e surge um ente agregador

48

heterogêneo. A figura 3.11 exempli fica a criação de um ente agregado no nível 1 do ente mostrado na figura 3.4;

História

História

História

História

História História

História

História

História

Nível 0

Nível 1

Nível 2

Nível 2

Nível 3

História

História

EnteAgregador

EntesAgregados

FIGURA 3.11 - Criação de entes por agregação

! Criação por Clonagem: A clonagem ocorre quando um ente já existente é replicado um determinado número de vezes. Os entes clones possuem, em todos os níveis, a mesma composição e a mesma história do ente clonado, ou seja, clonado e clones são idênticos. Logo após a clonagem, os clones passam a ter existência própria. A figura 3.12 exempli fica o processo de clonagem;

História

História

História

História

História

Nível 0

Nível 1

Nível 2

História

História

História

História

História

Nível 2

História História História

Clones

Ente Clonado

Clonagem

FIGURA 3.12 - Criação de entes por clonagem

49

" Criação por Fragmentação: Ocorre quando um ente composto já existente é fragmentado em dois ou mais entes. O ente fragmentado deixa de existir. Sendo assim, a fragmentação é também uma forma de extinção. Os entes criados por fragmentação são denominados entes fragmentos ou fragmentos. Os fragmentos herdam a história do ente fragmentado. Além disso, os fragmentos passam a existir no mesmo nível em que estava o ente que sofreu o processo de fragmentação. A figura 3.13 exempli fica a fragmentação de um dos entes compostos no nível 1 da figura 3.8. Neste caso, são criados dois novos entes.

História

História

História

História

História

História

História

HistóriaHistória

História

História

Nível 0Nível 1

Nível 2

Nível 2

Nível 2

Fragmentos

FIGURA 3.13 - Criação e extinção por fragmentação

3.2.9 Formas de Extinção dos Entes

Um ente pode ser extinto através das seguintes formas de extinção:

" Extinção Completa: Ocorre quando um ente é completamente extinto. A extinção completa de um ente elementar é simples. Por outro lado, a extinção de um ente composto demanda a extinção dos entes componentes, os quais podem também ser compostos. Neste caso, uma extinção completa pode envolver a eliminação de vários entes organizados em vários níveis;

" Extinção por Desagregação: Ocorre quando um ente composto é desagregado, ou seja, deixa de existir mas seus entes componentes permanecem. Neste caso, a história do ente extinto desaparece, não ocorrendo o mesmo com as histórias dos seus entes componentes. Os entes componentes passam a existir no nível do ente desagregado. Se eles forem compostos, a mudança reflete em todos seus níveis de composição;

50

# Extinção por Fragmentação: Ocorre quando um ente composto é fragmentado. Neste caso, o ente fragmentado é extinto e os fragmentos formam novos entes. Conforme descrito na seção 3.2.8, este tipo de extinção é também um processo de criação. A história do ente fragmentado não é extinta, pois seus fragmentos a herdam. A figura 3.13 exempli fica a extinção de um dos entes compostos no nível 1 da figura 3.8.

3.3 Fatos

Conforme analisado na seção 3.2, a realidade é composta de distinções, as quais em Holo são modeladas através de entes. No entanto, o mapeamento dos entes não é o bastante para realização de uma modelagem computacional. Os entes se diferenciam e relacionam. Assim, torna-se necessária também a modelagem das diferenciações e relacionamentos. Surgem assim, dois tipos básicos de informação sobre os entes, ou seja:

# Informação Existencial: Este tipo de informação descreve uma característica existencial de um ente, ou seja, uma característica de sua existência que independente de outros entes. As informações existenciais permitem a diferenciação entre entes. Por exemplo, as seguintes informações podem ser utili zadas para diferenciação dos seres humanos: idade, altura, sexo, cor do cabelo, etc;

# Informação Relacional: Este tipo de informação descreve uma característica relacional de um ente, ou seja, uma característica de sua relação com entes. As informações relacionais regulamentam a interação entre entes. Por exemplo, as seguintes informações descrevem a interação entre seres humanos: paternidade, fili ação, vínculo matrimonial, etc. Outro exemplo são as relações entre humanos e outros tipos de entes, por exemplo: vínculo empregatício (empresa empregadora), vínculo sindical (sindicato), vínculo residencial (casa onde vive), etc.

Em Holo ambos os tipos de informação são modeladas através de uma unidade denominada Fato. A utili zação de uma única unidade de modelagem de informação simpli fica a holosemântica. Os fatos podem ser classificados de acordo com o tipo de informação modelada. A figura 3.14 mostra a classificação dos fatos em Holo.

Fato

Relacional (Vínculo)

Existencial

Variável (Estado)

Constante (Característica)

Permanente

Temporário

FIGURA 3.14 - Classificação dos fatos em Holo

51

A seguir é apresentado um comentário sobre cada componente da figura 3.14. A descrição segue a mesma hierarquia da figura.

$ Fato: Unidade de modelagem de informação. Toda informação em Holo é um fato existencial ou relacional.

$ Existencial: Unidade de modelagem de informações existenciais. As informações que descrevem a existência de um ente são fatos existenciais, os quais podem ser constantes ou variáveis.

$ Constante (Característica): Um fato existencial constante é uma caraterística. As características dos entes não variam durante sua existência. Por exemplo, um ser humano possui como características: nome, sexo, etc.

$ Var iável (Estado): Um fato existencial variável é um estado. Os estados dos entes variam durante sua existência. Por exemplo, um ser humano possui como estados: idade, altura, etc.

$ Relacional (Vínculo): Unidade de modelagem de informações relacionais. Um fato relacional é um vínculo. Os vínculos permitem a modelagem da comunicação e sincronização entre entes. Um ente pode relacionar-se consigo mesmo (auto-vínculo). Além disso, um vínculo pode ser temporário ou permanente.

$ Temporár io: Um vínculo é considerado temporário se não acompanha toda a existência dos entes vinculados. Por exemplo, a comunicação entre seres humanos é um vínculo temporário.

$ Permanente: Um vínculo é dito permanente se acompanha toda a existência dos entes vinculados. Por exemplo, a relação pai e filho entre seres humanos é um vínculo permanente. Este tipo de vínculo assemelha-se a uma característica, pois ambos os tipos de fatos mantem-se constantes durante toda a existência de entes. No entanto, de forma distinta de uma característica, um vínculo modela informações em relação ao exterior dos entes.

3.4 Estilo Arquitetônico

Um paradigma de desenvolvimento de software cria abstrações que servem como instrumentos de modelagem da realidade. Em complemento, conforme pesquisado no âmbito da arquitetura de software ([SHA 96, cap.2]), existem vários estilos arquitetônicos para construção de programas de computadores. Um estilo arquitetônico define um padrão organizacional para a implementação de softwares. Em [SHA 96, p.20] encontra-se uma lista dos estilos mais comumente utili zados. As abstrações enfocam a organização do universo modelado. Por sua vez, um estilo enfoca uma implementação computacional. Sendo assim, um estilo implementa abstrações. Nem sempre as abstrações encontram um estilo que suporte sua implementação de forma adequada. A compatibili dade entre as abstrações e o estilo arquitetônico é de suma importância. Esta compatibili dade determina a simplicidade com que poderá ser realizada a conversão das abstrações (modelagem) para o estilo (implementação).

52

A implementação do Holoparadigma depende da escolha de um estilo arquitetônico que suporte de forma adequada suas principais abstrações. Em [SHA 96, p.26] encontra-se a descrição de um estilo denominado repositór io. Shaw e Garlan destacam que neste estilo existem dois tipos de componentes, ou seja:

% uma estrutura de dados central que representa o estado corrente; % uma coleção de componentes independentes que operam no armazenamento

central.

Além disso, merece destaque a afirmação de que a forma de interação entre o repositório e os componentes pode variar de forma significativa. Afirmam Shaw e Garlan que se o controle está baseado em um fluxo de entradas do sistema que selecionam os processos a serem executados, o repositório pode ser um banco de dados tradicional. Por outro lado, se o estado corrente da estrutura de dados central é a principal fonte de controle dos processos, o repositório pode ser um blackboard. A figura 3.15 mostra uma representação de um blackboard. Este estilo é composto de três partes, ou seja:

% Fontes de conhecimento (Knowledge Sources - KS): Parcelas independentes da aplicação que interagem somente através da estrutura de dados central;

% Estrutura de dados Blackboard: Estrutura de dados central que armazena o estado da resolução do problema. Os KS fazem alterações no blackboard, o qual avança de forma incremental na direção da solução do problema;

% Controle: Baseado completamente no estado do b lackboard. Os KS respondem à alterações na estrutura de dados central. Sendo assim, a invocação dos KS é completamente guiada pelo estado do blackboard.

Blackboard

KS1 KS2 KSn. . .

FIGURA 3.15 - Modelo Blackboard

Ainda no texto [SHA 96, p.23] encontra-se a descrição do estilo arquitetônico denominado invocação implícita. Neste estilo, os componentes do sistema não são invocados explicitamente. Em contra-partida, um componente pode anunciar eventos. Além disso, componentes podem registrar seu interesse em um determinado evento, associando um procedimento com ele. Quando o evento é anunciado, o sistema invoca todos os procedimentos que haviam registrado interesse por ele. Desta forma, o anúncio de um evento pode invocar de forma implícita vários procedimentos.

Conforme afirmam Shaw e Garlan, quando um componente anuncia um evento, não sabe quais componentes serão afetados. Sendo assim, os componentes não podem inferir a ordem de processamento ou mesmo quais serão os resultados do anúncio. Por

53

esta razão, a maioria dos sistemas que suportam invocação implícita também incluem a invocação explícita (chamada de procedimentos, etc) como forma alternativa de interação.

A flexibili dade introduzida pela invocação implícita estimula a reusabili dade, pois qualquer componente pode ser introduzido no sistema simplesmente pelo registro de seu interesse em um determinado evento. Além disso, a invocação implícita facilit a a evolução dos sistemas, pois componentes podem ser substituídos sem alteração de interfaces de outros componentes. A principal desvantagem consiste na abstração do controle pelos componentes, ou seja, o controle é encargo do sistema. Sendo assim, um componente não pode prever as conseqüências do anúncio de um evento. Outra desvantagem consiste na implementação da troca de dados pelos componentes. Algumas vezes dados podem ser passados com eventos, mas em outros torna-se necessário o uso de um repositório compartilhado.

Conforme descrito na seção 3.1, a holosemântica estabelece que a realidade é composta de entes e fatos. Além disso, a seção 3.2.1 salienta que as duas principais características de um ente são a distinção e a história. Sendo assim, destacam-se como as principais abstrações usadas em Holo:

& Ente: Abstração de existência (percepção de distinção); & Fato: Abstração de informação; & Histór ia: Abstração da evolução temporal de um ente.

Conforme mostra a figura 3.4, a organização de um ente composto assemelha-se a forma como os repositórios são organizados, ou seja, vários componentes que compartilham um armazenamento. No caso de um ente composto, os componentes são entes e o repositório é a história. Pretende-se que no âmbito do Holoparadigma, a história não sirva apenas para armazenamento de informações compartilhadas. Pretende-se que parte do controle dos entes seja responsabili dade da história. Sendo assim, torna-se interessante o uso do estilo blackboard para implementação de entes. Uma comparação entre as figuras 3.4 e 3.15 mostra as semelhanças existentes entre a organização dos entes e do modelo blackboard. Além disso, pretende-se que o controle realizado pela história seja baseado na invocação implícita. Este objetivo pode ser alcançado com a integração dos estilos blackboard e invocação implícita. Em [SHA 96, p.32] são descritas possibili dades para combinação de estilos arquitetônicos. Destaca-se na descrição o comentário sobre banco de dados ativos, ou seja, repositórios que ativam componentes através de invocação implícita. Nesta organização, os componentes registram interesse em áreas da base de dados. O banco de dados invoca automaticamente os componentes quando suas áreas de interesse sofrem alterações. Sendo assim, os bancos de dados ativos são uma integração dos estilos blackboard e invocação implícita. Eles permitem o controle de componentes através do compartilhamento de dados.

As limitações da invocação implícita são destacadas em [SHA 96, p.24]. Além disso, o uso da invocação explícita conjuntamente com a invocação implícita é salientado como uma solução para essas limitações. Em Holo ambos os tipos de invocação são usados. Os entes influenciam outros entes através da história (invocação implícita), mas também podem trocar informações diretamente (invocação explícita). Portanto, o estilo arquitetônico proposto em Holo envolve três estilos convencionais, ou

54

seja: blackboard, invocação implícita e invocação explícita. A figura 3.16 mostra o Holoestilo.

Ente 1 . . .

História

Ente 2 Ente n

Invocação Implícita

Invocação Explícita

Blackboard

FIGURA 3.16 - Estilo arquitetônico de Holo

3.5 Holomodelagem

O processo de criação de um modelo computacional para representação de um universo é conhecido como modelagem. A figura 3.1 mostra esse processo de forma genérica. Toda modelagem tem como base um paradigma de desenvolvimento de software. No paradigma são encontradas as abstrações que suportam a criação do modelo. A modelagem através de Holo é denominada Holomodelagem. Além disso, o modelo criado através do Holoparadigma é chamado Holomodelo.

No âmbito do Holoparadigma toda existência é um ente. Sendo assim, o Holomodelo pode ser percebido como um ente. O nível 0 deste ente representa o nível mais alto de abstração do modelo. Por sua vez, os níveis de abstração mais baixos representam os vários níveis de composição do holomodelo. A figura 3.17 mostra a visão do modelo computacional como um ente resultante da holomodelagem.

Realidade

Universo

Holomodelagem

Holomodelo no nível 0

FIGURA 3.17 - Modelo computacional como um ente

55

O holomodelagem é uma abordagem top-down. Após a definição do ente de mais alto nível de abstração (nível 0) torna-se necessária a definição dos seus entes componentes, os quais localizam-se no nível 1. Este processo de refinamento deve prosseguir até a definição de todos os níveis de composição do holomodelo. Sendo assim, a estrutura organizacional do holomodelo representa a organização do universo modelado. Através da holomodelagem os universos são sempre modelados como unidades (entes) que encapsulam unidades, as quais compartilham uma história. Durante a modelagem torna-se necessária a definição de limites de composição, ou seja, a criação de entes elementares que definam o término do refinamento. O limite de composição depende dos níveis finais de abstração a serem modelados. Por exemplo, o corpo humano pode ser percebido como um ente composto, o qual pode ser modelado em vários níveis. A figura 3.18 mostra um exemplo de holomodelagem do corpo humano. Uma modelagem em três níveis (figura 3.18a) pode estabelecer que o ente corpo possui seis entes componentes, ou seja: dois braços, duas pernas, uma cabeça e um tronco. Por sua vez, os entes componentes são compostos de entes elementares células. Neste caso, o limite de composição localiza-se nas células. No entanto, o limite poderia ser estendido para níveis mais baixos de abstração. Um célula poderia ser modelada em moléculas e as moléculas modeladas em átomos (figura 3.18b). Neste caso, o limite de composição seria estabelecido nos átomos e o corpo seria modelado em cinco níveis. Outros níveis de abstração poderiam ser criados. Por exemplo, algumas células do tronco poderiam ser organizadas em entes compostos denominados órgãos.

Corpo humano

Cabeça

Braço esquerdo

Tronco

Braço direito

Perna esquerda

Perna direita

n Células

n Células

n Células

n Células

n Células

n Células

Entes compostos Entes elementares

Limite de Composição Figura 3.18a

Corpo humano

Cabeça

Braço esquerdo

Tronco

Braço direito

Perna esquerda

Perna direita

n Células

n Células

n Células

n Células

n Células

n Células

Entes compostos Entes elementares

Limite de Composição

Figura 3.18b

n Moléculas

n Moléculas

n Moléculas

n Moléculas

n Moléculas

n Moléculas

n Átomos

n Átomos

n Átomos

n Átomos

n Átomos

n Átomos

FIGURA 3.18 - Exemplo de limite de composição

56

3.6 Holoplataforma

Uma plataforma é um conjunto de softwares e hardware que suportam o desenvolvimento e a execução de sistemas computacionais. A figura 3.19 apresenta a organização da plataforma proposta para o Holoparadigma. Ela recebe o nome de Holoplataforma. Conforme mostra a figura, a holoplataforma é composta de duas partes, ou seja:

' Plataforma de Desenvolvimento: Conjunto de ferramentas de software utili zadas na construção dos sistemas computacionais;

' Plataforma de Execução: Conjunto de hardware e software utili zado como suporte à execução de programas. A figura 3.19 mostra que a camada de software que interage com o hardware é denominada Ambiente de Execução.

O projeto de uma plataforma de desenvolvimento depende das abstrações a serem utili zadas na modelagem e implementação de programas. Sendo assim, ela é projetada e construída tendo como base um paradigma de desenvolvimento de software. O paradigma estabelece quais abstrações serão utili zadas. Por sua vez, a plataforma de desenvolvimento concretiza o sistema computacional usando as abstrações. A primeira etapa para construção deste tipo de plataforma consiste na definição de quais ferramentas serão suportadas e quais serão as interfaces entre elas.

Holocase

Especificação Formal

Conversor

Hololinguagem

Compilador

Código Virtual

Ambiente de Execução

Hardware

Holoparadigma Paradigmas Básicos

Conversor LinguagemOrientada a Objetos

ConversorLinguagemem Lógica

ConversorQualquer linguagem de um paradigma básico

Plataforma deDesenvolvimento

Plataforma de Execução

FIGURA 3.19 – Holoplataforma

A holoplataforma de desenvolvimento é composta de três ferramentas: ' Holocase: Uma ferramenta CASE que suporta as abstrações propostas em

Holo. A holocase permite que o usuário descreva o modelo com o uso de recursos gráficos. Com base nessa descrição é gerada automaticamente uma especificação formal para o modelo. Essa especificação descreve o modelo

57

de forma genérica. Ela será utili zada para concretização do modelo em um sistema computacional;

( Conversor : Uma ferramenta que converte a especificação formal gerada pela holocase em uma linguagem que suporte as abstrações de Holo. Essa linguagem é denominada hololinguagem. A especificação descreve de forma genérica o modelo computacional. Por sua vez, a linguagem suporta a descrição de baixo nível que implementa o modelo. Podem existir várias linguagens orientadas ao Holoparadigma. Neste caso, cada linguagem possui um conversor;

( Compilador : Uma ferramenta que compila a hololinguagem, gerando um código virtual. Esse código contém a descrição de mais baixo nível de abstração do modelo computacional. Com base nele é realizada a execução e são obtidos os resultados. O código virtual serve de entrada para a plataforma de execução.

A figura 3.19 mostra dois universos de paradigmas de desenvolvimento de software, ou seja, o Holoparadigma e o universo dos paradigmas considerados básicos ([BAR 98]). Conforme mostrado na figura, pretende-se que a especificação formal sirva como uma ponte para ligação entre o Holoparadigma e o universo de paradigmas básicos. Os modelos computacionais descritos em Holo tendem a ser mais abrangentes do que os modelos criados através dos paradigmas básicos. Esta característica resulta do direcionamento de Holo para suporte à arquitetura de software e multiparadigma (seção 2.4). Sendo Holo mais abrangente, sua especificação formal tende a suportar a descrição de modelos em paradigmas básicos, tais como, orientação a objetos e programação em lógica. Neste caso, a conversão da especificação formal de Holo para linguagens baseadas em paradigmas básicos depende da criação de conversores específicos para cada linguagem.

A figura 3.19 mostra ainda que o código virtual gerado no âmbito do Holoparadigma necessita de uma camada de software que atue como ambiente de execução. Esse ambiente deverá suportar características específicas do hardware a ser utili zado. As abstrações propostas no Holoparadigma são independentes de hardware. No entanto, existe uma forte orientação do paradigma para as arquiteturas distribuídas. Neste caso, se o hardware for uma arquitetura distribuída a plataforma de execução poderá suportar as seguintes características:

( Suporte à Mobili dade: A mobili dade física descrita na seção 3.2.6 necessita de suporte de hardware. O código virtual cria uma camada de abstração que facilit a o tratamento da mobili dade de entes;

( Suporte à Tolerância à Falhas: Conforme descrito no final da seção 2.2, as arquiteturas distribuídas são bastante confiáveis, pois permitem a implementação de técnicas de tolerência à falhas baseadas na redundância de nodos de processamento. Uma plataforma de execução para arquiteturas distribuídas pode desfrutar dessa vantagem;

( Suporte à Protocolos de Comunicação: Uma plataforma de execução para arquiteturas distribuídas necessita de protocolos de comunicação para gerência das mensagens trocadas entre nodos de processamento. Além disso, no caso de uma plataforma para Holo, torna-se necessária a criação de protocolos para comunicação entre os entes distribuídos;

58

) Suporte à Memór ia Compartilhada Distr ibuída: A utili zação de uma arquitetura distribuída como plataforma de execução para Holo envolve o gerenciamento de memória compartilhada distribuída (DSM - Distributed Shared Memory). Conforme exempli fica a figura 3.7, a distribuição envolve o compartilhamento de áreas de armazenamento entre entes localizados em nodos diferentes. Este compartilhamento resulta do necessário compartilhamento da história por entes que compõem o mesmo ente. O necessário tratamento da DSM em arquiteturas distribuídas é uma das caraterísticas mais interessantes e complexas introduzidas pelo Holoparadigma.

3.7 Estudo de uma aplicação: Automação Residencial

A criação de um nova proposta para solução de problemas traz consigo novas características que, normalmente, somente são descobertas durante sua aplicação em situações reais. Sendo assim, o uso de protótipos para validação de novas propostas é uma prática comum. No caso de novos paradigmas, torna-se interessante a avaliação de suas abstrações na solução de um problema real. Esta seção apresenta a aplicação do Holoparadigma na automação de residênciais.

Os avanços da microeletrônica e, em especial, o surgimento dos microprocessadores vêm fazendo com que os aparelhos eletrônicos tornem-se cada vez mais sofisticados. Televisores e vídeocassetes microprocessados são uma realidade. Além disso, estudos envolvendo vários outros aparelhos eletrodomésticos estão sendo desenvolvidos (por exemplo, geladeiras e fogões). Como complemento, em breve o acesso a Internet não ficará mais restrito a apenas computadores. Todos equipamentos que puderem obter vantagem da rede mundial de comunicação o farão. Sendo assim, não encontra-se muito distante a época em que as residênciais estarão repletas de equipamentos eletrônicos computadorizados, interligados e com acesso ao mundo externo através da rede Internet. Este tipo de residência pode ser percebido com uma arquitetura distribuída. A holomodelagem deste padrão de residência será descrita nos próximos parágrafos.

A figura 3.20 mostra um exemplo de uma residência composta de três dependências. Nela estão distribuídos seis equipamentos eletrônicos, os quais estão conectados por uma rede. Além disso, merece destaque que a família que vive na casa é composta de um casal e dois filhos. Conforme mostra a figura, a conexão da residência com o mundo externo encontra-se no microcomputador. Os equipamentos são todos microprocessados, ou seja, cada um deles atua como um nodo de uma arquitetura distribuída.

Em Holo, todas as existências são modeladas como entes. Portanto, através da holomodelagem pode-se considerar a residência como um ente composto. Por sua vez, os equipamentos eletrônicos e as pessoas da família podem ser considerados como entes elementares. Neste caso, os equipamentos e as pessoas compartilham uma história, ou seja, a história da casa. A figura 3.21 mostra essa situação. A história da casa cresceria na medida em que o tempo avançasse. Toda informação que fosse aprendida por um ente e fosse considerada relevante para todos os demais, seria colocada na história. Por exemplo, o número de pessoas que vive na casa, suas idades e datas de nascimento. Quando um novo equipamento eletrônico fosse adquirido e instalado, automaticamente passaria a fazer parte do ente composto e, portanto, passaria a ter acesso a história

59

compartilhada. Sendo assim, a simples instalação de um equipamento na casa faria com que ele se tornasse um equipamento específico daquela família, conhecendo todos os fatos históricos armazenados na história da residência. Do ponto de vista lógico, todos os entes elementares tem acesso a história. No entanto, do ponto de vista físiso ela deve estar armazenada em algum local da residência. Neste caso, o microcomputador poderia manter o armazenamento da história. Outra opção seria o uso de equipamentos específicos para gerenciamento da rede da residência e para armazenamento da história. A figura 3.19 mostra que o hardware e o ambiente de execução são componentes da plataforma de suporte ao Holo. No exemplo da residência como ente, o hardware seria uma arquitetura distribuída composta de sete nodos dos quais seis dedicados (eletrodomésticos) e um de uso genérico (microcomputador). O ambiente de execução suportaria o gerenciamento dos entes. Esse gerenciamento poderia envolver mobili dade, protocolos de comunicação, tolerância a falhas, escalonamento de tarefas, interface com o mundo externo, suporte a memória compartilhada distribuída, etc.

Sala

QuartoCozinha

Geladeira

Micro-ond as

Fogão Microcomputador

Televisão Vídeocassete

FIGURA 3.20 - Residência utili zada na holomodelagem

Sala

QuartoCozinha

Geladeira

Micro-ondas

Fogão Microcomputador

Televisão VídeocasseteHistória

FIGURA 3.21 - Residência como um ente composto

60

A modelagem mostrada na figura 3.21 poderia ser expandida. A casa poderia ser modelada como um ente componente de um bairro. Por sua vez, o bairro poderia fazer parte de uma cidade. A composição poderia ser estendida para vários outros níveis, tais como: município, estado, região e país. Cada nível teria sua história. Por exemplo, o bairro teria uma história que seria compartilhada por todas as residências localizadas nos seus limites. Quando uma família fosse residir em um bairro passaria a compartilhar sua história. No momento em que o ente residência passasse a existir, teria acesso a história compartilhada. A figura 3.22 mostra os vários níveis de composição possíveis na holomodelagem de um país.

BairroCidade

Município

Estado

País

FIGURA 3.21 - Organização de uma país através de Holo

3.8 Conclusões

Neste capítulo foram apresentados conceitos básicos relacionados com o Holoparadigma. Através dessa apresentação foram descritas as principais idéias que serão utili zadas como base para criação de uma especificação completa do paradigma. Encontra-se a seguir uma lista contendo as principais constatações e conclusões surgidas no decorrer do capítulo. A lista está organizada em itens que contemplam cada uma das seções.

* Seção 3.1 - Holosemântica: a eficiência de um paradigma está relacionado com a distância entre o significado das abstrações e o significado dos conceitos existentes no universo modelado. A holosemântica estabelece que a realidade é simples e pode ser compreendida através de duas unidades de modelagem, ou seja: unidade de existência (ente) e unidade de informação (fato);

* Seção 3.2 - Ente: o ente é a principal abstração do Holoparadigma. O ente possui duas características básicas, ou seja, distinção e história. Os entes são classificados de acordo com sua organização em entes elementares e

61

compostos. Existe uma equivalência entre a organização das arquiteturas distribuídas e a organização de entes no holoparadigma. A base dessa equivalência é a semelhança organizacional de nodos e entes. Os índices de entes descrevem aspectos relevantes dos entes e podem ser utili zados para sua descrição. Entes podem compartilhar entes. Um ente compartilhado é componente de dois ou mais entes. Quando o hardware a ser utili zado é uma arquitetura distribuída, um ente pode encontrar-se centralizado ou distribuído. A história de um ente distribuído é denominada história distribuída. No âmbito do Holoparadigma existem dois tipos de mobili dade, ou seja, mobili dade lógica e mobili dade física. As mobili dades lógica e física são independentes, ou seja, a ocorrência de um tipo de deslocamento não implica na ocorrência do outro. Do ponto de vista da mobili dade, os entes podem ser classificados em: logicamente estáticos, logicamenete móveis, fisicamente estáticos e fisicamente móveis. O ciclo existencial de um ente é composto de três etapas, ou seja: criação, existência e extinção. Existem quatro formas de criação de entes, ou seja: original, por agregação, por clonagem e por fragmentação. Quanto a extinção, existem três formas, ou seja: completa, por desagregação e por fragmentação;

+ Seção 3.3 - Fatos: o mapeamento dos entes não é o bastante para realização de uma modelagem computacional. Os entes se diferenciam e relacionam. Assim, torna-se necessária também a modelagem das diferenciações e relacionamentos. Surgem assim, dois tipos básicos de informação relacionada com os entes, informações existenciais e relacionais. A utili zação de uma única unidade de modelagem de informação simpli fica a holosemântica. Os fatos podem ser classificados de acordo com o tipo de informação modelada;

+ Seção 3.4 - Estilo Arquitetônico: existem vários estilos arquitetônicos para construção de programas de computadores. Nem sempre as abstrações encontram um estilo que suporte sua implementação de forma adequada. A compatibili dade entre as abstrações e o estilo arquitetônico é de suma importância. Esta compatibili dade determina a simplicidade com que poderá ser realizada a conversão das abstrações (modelagem) para o estilo (implementação). Entre os estilos destacam-se o repositório e a invocação implícita. A maioria dos sistemas que suportam invocação implícita também incluem a invocação explícita (chamada de procedimentos,etc) como forma alternativa de interação. A flexibili dade introduzida pela invocação implícita estimula a reusabili dade e facili dade a evolução dos sistemas. Em contra-partida, destacam-se como principal desvantagem a imprevisibili dade das conseqüências do anúncio de um evento. A organização de um ente composto assemelha-se a forma como os repositórios são organizados, ou seja, vários componentes que compartilham um armazenamento. No caso de um ente composto, os componentes são entes e o repositório é a história. Pretende-se que no âmbito do Holoparadigma, a história não sirva apenas para armazenamento de informações compartilhadas. Pretende-se que parte do controle dos entes seja responsabili dade da história. Sendo assim, torna-se interessante o uso do estilo blackboard para implementação de entes. Além disso, pretende-se que o controle realizado pela história seja baseado na invocação implícita. Este objetivo pode ser alcançado com a integração dos estilos blackboard e invocação implícita. Em Holo, as limitações impostas pela

62

invocação implícita são superadas pelo uso complementar da invocação explícita.

, Seção 3.5 - Holomodelagem:Toda modelagem tem como base um paradigma de desenvolvimento de software. A modelagem através de Holo é denominada Holomodelagem. Além disso, o modelo criado através do Holoparadigma é chamado Holomodelo. O holomodelo pode ser percebido como um ente. holomodelagem é uma abordagem top-down. Durante a modelagem torna-se necessária a definição de limites de composição, ou seja, a criação de entes elementares que definam o término do refinamento das composições;

, Seção 3.6 - Holoplataforma: uma plataforma é projetada e construída tendo como base um paradigma de desenvolvimento de software. O paradigma estabelece quais abstrações serão utili zadas. Por sua vez, a plataforma concretiza o sistema computacional usando as abstrações. A plataforma de desenvolvimento proposta para o Holoparadigma é composta de três ferramentas, ou seja: holocase, conversor e compilador. Pretende-se que a especificação formal gerada pelo holocase sirva como uma ponte para ligação entre o Holoparadigma e o universo de paradigmas básicos. As abstrações propostas no Holoparadigma são independentes de qualquer plataforma de hardware. No entanto, existe uma forte orientação do paradigma para as arquiteturas distribuídas ;

, Seção 3.7 - Estudo de uma aplicação: Automação Residencial: não encontra-se muito distante a época em que as residênciais estarão repletas de equipamentos eletrônicos computadorizados, interligados e com acesso ao mundo externo através da rede Internet. Este tipo de residência pode ser percebido com uma arquitetura distribuída. Através da holomodelagem pode-se considerar a residência como um ente composto. A holomodelagem de uma residência pode ser expandida visando o envolvimento de vários níveis de composição (bairro, cidade, estado, etc).

O próximo capítulo apresenta as conclusões finais deste trabalho.

63

4 Conclusões

Este trabalho dedicou-se a uma descrição dos conceitos básicos relacionados com o Holoparadigma. O capítulo dois apresentou a gestação do Holo, descrevendo suas principais motivações e concepções intermediárias. Por sua vez, o capítulo três abordou as principais idéias relacionadas com o paradigma. Destacam-se naquele capítulo: a descrição da holosemântica, uma visão das duas unidades de modelagem usadas em holo (entes e fatos), uma descrição da holomodelagem, uma análise da holoplataforma e o estudo de uma aplicação. Os principais resultados obtidos através desse trabalho foram:

- organização das motivações e concepções que servem de base para o Holoparadigma;

- criação e organização dos conceitos básicos do Holo; - revisão bibliográfica dos principais temas envolvidos na criação do paradigma,

tais como: arquitetura de software, multiparadigma, arquiteturas distribuídas, paradigmas de desenvolvimento, mobili dade e outros;

- documentação dos resultados obtidos até o presente momento no desenvolvimento do Holoparadigma;

- divulgação do Holo através da distribuição de partes do texto para pesquisadores interessados no trabalho. Além disso, várias figuras criadas no decorrer do texto serão utili zadas em apresentações para divulgação do Holoparadigma.

Merecem destaque como principais conclusões e constatações obtidas durante o desenvolvimento do trabalho:

- a viabili zação da distribuição implícita depende de dois fatores: a existência de potencial de distribuição no universo a ser modelado e o uso de um paradigma que possua uma semântica distribuída (transferência natural do potencial para o modelo);

- as arquiteturas distribuídas podem ser consideradas a base para organização dos sistemas computacionais. Sendo assim, o estudo de suas características como hardware da plataforma de execução do Holoparadigma assume uma posição de destaque;

- as arquiteturas distribuídas são mais genéricas e abrangem as arquiteturas paralelas. A execução paralela visando aumento de desempenho é uma das várias oportunidades a serem exploradas nas arquiteturas distribuídas;

- as pesquisa dos temas multiparadigma e arquitetura de software se confundem. O estudo conjunto de ambos os tópicos é de suma importância para criação do Holoparadigma. Este estudo envolve várias características consideradas essenciais em Holo, tais como, unificação de paradigmas básicos e composição;

- a regulagem da fragmentação do conhecimento na ciência da computação surge como um dos principais resultados da criação do Holoparadigma. Esta característica pode ser percebida pela constatação de que as pesquisas nos temas multiparadigma e arquitetura de software são regulagens nas áreas de

64

linguagens de programação e engenharia de software. Ambos os tópicos servem de base para Holo. Além disso, no Holoparadigma esses tópicos se fundem em um único tema de pesquisa, ou seja, os paradigmas holísticos. Sendo assim, Holo tende a aumentar a regulagem da fragmentação através do estudo conjunto dos temas multiparadigma e arquitetura de software;

. a holosemântica está baseada em três abstrações, ou seja: ente, fato e história. Entre elas, o ente destaca-se como a principal. A organização de um ente possui uma forte semelhança com a organização dos nodos de arquiteturas distribuídas. Está constatação estimula o uso do Holoparadigma para o desenvolvimento de softwares distribuídos;

. o estilo arquitetônico escolhido para concretização das abstrações de Holo contempla a integração de três estilos tradicionais, ou seja: blackboard, invocação implícita e invocação explícita.

Este texto contém os primeiros passos para criação de um novo paradigma de desenvolvimento de sistemas computacionais denominado Holoparadigma. As próximas atividades neste sentido serão as seguintes:

. Aperfeiçoamento da definição do paradigma: Devem ser criados padrões para especificação de entes (mesma filosofia de classes na orientação a objetos) e aprofundados os estudos sobre a especificação de fatos. A classificação de fatos discutida na seção 3.4 permite apenas uma visão inicial da organização das informações em Holo;

. Criação de uma notação gráfica: Deve ser criada uma notação gráfica para Holo (Holonotação). Essa notação será utili zada na holomodelagem e, em especial, na construção da holocase;

. Criação de uma especificação formal: Conforme mostra a figura 3.19, deve ser criada uma especificação formal para os modelos computacionais gerados em Holo. Essa especificação poderá ser gerada automaticamente pela holocase e poderá servir de elo entre o holoparadigma e os paradigmas básicos;

. Definição de uma linguagem de programação: Deve ser criada uma linguagem de programação baseada no holoparadigma. A figura 3.19 mostra a hololinguagem sendo derivada automaticamente da especificação formal. Essa tarefa será realizada por um conversor;

. Definição da conversão da especificação formal para a hololinguagem: A conversão da especificação formal para a hololinguagem demanda a definição de uma estratégia para realização dessa tarefa;

. Aplicação do holoparadigma: A aplicação descrita na seção 3.7 deve ser aperfeiçoada. A evolução de Holo ocasionará naturalmente esse aperfeiçoamento. Além disso, o holoparadigma deve ser aplicado na solução de outros problemas.

65

Anexo Significado de palavras relacionadas com o Holoparadigma

Fontes consultadas: /

Novo Dicionário Aurélio da Língua Portuguesa. Editora Nova Fronteira, 1986. 0

Michaelis - Moderno Dicionário da Língua Portuguesa. Editora Melhoramentos, 1998.

1 Oxford Advanced Learner's Dictionary. Oxford University Press, 1992.

2 Language Master model LM-6000. Franklin Electronic Publishers Inc, USA, 1991. Words from Merriam-Webster.

1) Agregação /

1. Ação ou efeito de agregar(-se). 2. Reunião em grupo; associação, aglomeração. 0

1. Ação ou efeito de agregar. 2. Algomeração, associação, conjunto, reunião. 3. propriedade que têm as moléculas de cada corpo de justapor-se ou reunir-se graças à força de coesão. 4. Processo de formar grupos demográficos pelo acúmulo de indivíduos através de imigração ou de aumento natural. 5. Grupo de população assim formado.

1 Não consta.

2 Aggregation: 1. a group, body, or mass composed of many distinct parts. 2. the collecting of units or parts into a mass or whole.

2) Clone /

[Do grego klón, 'broto'] Conjunto de indivíduos originários de outros por multiplicação assexual (divisão, enxertia, apomixia, etc). [Todos os membros de um clone têm o mesmo patrimônio genético].

0 [Do grego klón] Conjunto da progênie, produzida assexualmente, de um indivíduo, quer naturalmente (como os produtos de fissão repetida de um protozoário), quer vegetativamente (como na propagação de determinada planta por gemação ou mudas através de muitas gerações).

1 Clone: 1. (any of a) group of plants or organisms produced asexually from one ancestor. 2. computer designed to copy the functions of another model.

2 Clone: [Greek klon "twig"] 1. the offspring produced asexually from an individual (as a plant increased by grafting). 2. an individual grown from a single body cell or its parent and genetically identical to the parent. 3. one that appears to be a copy of an original form.

66

3) Composto 3

[Do latim compositu] 1. Constituído por dois ou mais elementos. 2. Substância ou corpo composto. 3. Complexo de várias coisas combinadas.

4 [Do latim compositu] 1. Que é formado por dois ou mais elementos. 2. Designativo do corpo resultante da combinação de vários elementos.

5 Composed: made up or formed from.

6 Não consta.

4) Distinção 3

[Do latim distinctione] 1. Ato ou efeito de distinguir(-se), diferença, separação. 2. Caracteres, características, qualidades, pelos quais uma pessoa ou uma coisa difere de outra.

4 [Do latim distinctione] 1. Ato ou efeito de distinguir. 2. Percepção da diferença entre pessoas ou coisas. 3. Sinal ou qualidade por que uma coisa se diferencia de outra. 4. Diferença, separação. 5. Sinal exterior destinado a evitar a confusão entre pessoas ou coisas.

5 Distinction: 1. Difference or contrast between one person / thing and another. 2. Separation of things or people into different groups according to quality, grade, etc.

6 Distinction: 1. the act of distinguishing a difference. 2. Difference. 3. a distinguishing quality or mark.

5) Distribuição 3

[Do latim distributione] 1. Ato de distribuir; repartição. 2. Classificação, disposição.

4 [Do latim distributione] 1. Ato ou efeito de distribuir; repartição. 2. Classificação. 3. Disposição, ordenamento.

5 Distr ibution: 1. (instance of) giving or being given to each several people. 2. (instance of the) positioning or allocation of items, features, etc within an area.

6 Distr ibution: 1. the act or process of distributing. 2. the position, arrangement, or frequency of occurrence (as of the members of a group) over an area or throughout a space or unit fo time.

67

6) Elementar 7

1. Relativo ou pertencente a elemento(s). 2. De composição ou funcionamento simples; primário, rudimentar. 3. Simples, fácil , claro. 4. Que está na base, essência, origem; essencial, fundamental, básico.

8 1. Que é da natureza do elemento ou que serve de elemento. 2. Principal, fundamental.

9 Elementary: 1. of or in the beginning stages (of a course of study). 2. dealing with the simplest facts (of a subject); basic. 3. easy to solver or answer.

: Elementary: simple, rudimentary.

7) Ente 7

[Do latim ente.] 1. Aquilo que existe; coisa, objeto, matéria, substância, ser. 2. Aquilo que supomos existir. 3. Tudo que é de maneira concreta, fática ou atual independentemente de, em qualquer nível, tornar-se objeto de reflexão.

8 [Do latim ente] 1. O que é, existe ou pode existir. 2. Ser. 3. Coisa, objeto, substância.

9 Being: 1. Existence. 2. One's essence or nature, self. 3. Living creature.

: Being: 1. existence, li fe. 2. the qualiti es or constitution of an existent thing. 3. a li ving thing.

8) Fato 7

[Do latim factu] 1. Coisa ou ação feita, sucesso, caso, acontecimento, feito. 2. Aquilo que realmente existe, que é real.

8 [Do latim factu] 1. Coisa ou ação feita. 2. Acontecimento, sucesso. 3. Aquilo de que se trata. 4. O que é real.

9 Fact: 1. Thing that is known to have happened or to be true or to exist. 2. Thing that is believed or claimed to be true. 3. What is true, reality.

: Fact: 1. the quality of being actual. 2. something that exists or occurs.

9) Fragmento 7

[Do latim fragmentu] 1. Cada um dos pedaços de uma coisa partida ou quebrada. 2. Parte de um todo; pedaço, fração.

8 [Do latim fragmentu] 1. Partículo isolada do todo. 2. Pequena fração. 3. Cada uma das pequenas partes em que se dividiu um todo.

68

; Fragment: 1. small part or piece broken off . 2. separate or incomplete part.

< Fragment: a part broken off , detached, or incomplete.

10) História =

[Do grego historía, pelo latim historia] 1. Narração metódica dos fatos notáveis ocorridos na vida dos povos, em particular, e na vida da humanidade, em geral. 2. Conjunto de conhecimentos adquiridos através da tradição e/ou por meio dos documentos, relativos à evolução, ao passado da humanidade. 3. Ciência e método que permitem adquirir e transmitir aqueles conhecimentos. 4. Estudo das origens e processos de uma arte, de uma ciência ou de um ramo do conhecimento. 5. Narração de acontecimentos, de ações, em geral cronologicamente dispostos. 6. Narração de fatos, acontecimentos ou particularidades relativas a um determinado assunto.

> [Do grego historía] 1. Narração ordenada, escrita, dos acontecimentos e atividades humanas ocorridas no passado. 2. Ramo da ciência que se ocupa de registrar cronologicamente, apreciar e explicar os fatos do passado da humanidade em geral, e das diversas nações, países e localidades em particular. 3. Os fatos do passado da humanidade registrados cronologicamente. 4. Exposição de fatos, sucessos ou particularidades relativas a determinado objeto digno de atenção pública.

; History: 1. Study of past events, especially the politi cal, social and economic development of a country, a continent or the world. 2. Past events, especially when considered as a whole. 3. Systematic description of past events. 4. Series of past events or experiences connected with an object, a person or a place.

< History: [Latin historia, from Greek, "inquiry, history", from histor, istor "knowing, learned"] 1. an account of events or facts pertinent to a situation. 2. a chronological record of significant events often with an explanation of their causes. 3. a branch of knowledge that records and explains past events. 4. events that form the subject matter of history.

11) Holismo =

[De hol(o)- + -ismo.] Tendência, que se supõe seja própria do Universo, a sintetizar unidades em totalidades organizadas.

> [De holo+ismo] 1. Doutrina que considera o organismo vivo como um todo indecomponível. 2. Compreensão da realidade em totalidades integradas onde cada elemento de um campo considerado reflete e contém todas as dimensões do campo, conforme a indicação de um holograma, evidenciando que a parte está no todo, assim como o todo está na parte, numa inter-relação constante, dinâmica e paradoxal.

; Não consta.

69

? Holism: 1. a theory that the universe and especially nature should be viewed as interacting wholes rather than as distinct parts.

12) Hol(o) @

[Do grego hólos, hóle, hólon.] Elemento de composição = Inteiro, completo.

A [Do grego holós] Elemento de composição = Introduz a idéia de totalidade.

B Não consta.

? Não consta.

13) Implícito @

[Do latim implicitu] 1. Que está envolvido, mas não de modo claro; tácito, subentendido.

A [Do latim implicitu] 1. Que está envolvido mas não expresso claramente; tácito. 2. Não expresso por palavras; subentendido.

B Implicit: Implied, but not expressed directly; not explicit.

? Implicit: Understood though not directly stated or expressed.

14) Mobili dade @

[Do latim mobilit ate] 1. Qualidade ou propriedade do que é móvel ou obedece às leis do movimento. 2. Facili dade de mover-se ou ser movido. 3. Facili dade com que se passa de um estado para outro; inconstância, volubili dade. 4. Facili dade de modificar-se ou variar.

A [Do latim mobilit ate] 1. Propriedade do que é móvel ou do que obedece às leis do movimento. 2. Deslocamento de indivíduos, grupos ou elementos culturais no espaço social. 3. Falta de estabili dade, de firmeza; inconstância.

B Mobili ty: being mobile.

? Não consta.

15) Paradigma @

[Do grego parádeigma, pelo latim paradigma.] Modelo, padrão, estalão.

A [Do grego parádeigma] 1. Modelo, padrão, protótipo. 2. Conjunto de unidades suscetíveis que aparecem num mesmo contexto, sendo, portanto, comutáveis e mutuamente exclusivas. No paradigma, as unidades têm, pelo menos, um traço em

70

comum (a forma, o valor ou ambos) que as relaciona, formando conjuntos abertos ou fechados, segundo a natureza das unidades.

C Paradigm: 1. Set of all the different forms of a word. 2. Type of, pattern, model.

D Paradigm: 1. model, pattern.

16) Paralelismo E

1. Posição de linhas ou superfícies paralelas. 2. Correspondência ou simetria entre duas ou mais coisas, comparável ao paralelismo das retas. 3. Correspondência de idéias ou opiniões.

F 1. Estado do que é paralelo. 2. Correspondência ou simetria entre duas coisas.

C Parallelism: state of being parallel; similarity.

D Não consta.

17) Semântica E

[Do grego semantiké, isto é, téchne semantiké, 'a arte da significação'] 1. Estudo das mudanças ou translações sofridas, no tempo e no espaço, pela significação das palavras; semasiologia, semantologia, semiótica. 2. O estudo da relação de significação dos signos e da representação do sentido dos enunciados.

F [Do grego semantiké, de sema] 1. Estudo da evolução do sentido das palavras através do tempo e do espaço; semiótica, semasiologia, sematologia.

C Semantic: 1. Of the meaning of words.

D Semantic: 1. of or relating to meaning.

18) Universal E

[Do latim universale] 1. Relativo ou pertencente ao universo, ao cosmo. 2. Que abarca toda a Terra, que se estende a tudo ou por toda parte; mundial. 3. Comum a todos os homens, ou a um grupo dado. 4. Que é aplicável a tudo. 5. Que advém de todos; geral. 6. Que não se atém a uma especialidade; que abrange quase por inteiro um campo de conhecimentos, de idéias, de aptidões, etc. 7. Que á adaptável ou ajustável de modo que possa atender a diferentes necessidades (de utili zação, tamanho, forma, etc.). 8. Diz-se de atributo que convém a todos os indivíduos de uma classe.

F 1. Geral, total. 2. Comum a todos. 3. Que abrange todas as coisas; que se estende a tudo. 4. Que provém de todos; que é efeito de todos. 5. Que tem o caráter de generalidade absoluta. 6. Composto de elementos tirados de várias fontes; variado, eclético.

71

G Universal: of, belonging to, affecting or done by all people or things in the world or in a particular group.

H Universal: 1. including, covering, or affecting the whole without limit or exception; unlimited, general. 2. present or occurring everywhere. 3. used or for use among all .

19) Vínculo I

[Do latim vinculu] 1. Tudo o que ata, liga ou aperta. 2. Ligação moral 3. Relação, subordinação.

J [Do latim vinculu] 1. Tudo o que ata, liga ou aperta. 2. Ligação moral. 3. Nexo jurídico que estabelece subordinação de uma coisa a outra. 4. Relação, subordinação.

G Não consta.

H Vinculum: 1. a unifying bond. 2. a straight horizontal mark placed over two or more members of a mathematical expression as a symbol of grouping.

72

Bibliografia

[AMB 96] AMBRIOLA, Vincenzo; CIGNONI, Giovanni A.; SEMINI; Laura. A Proposal to Merge Multiple Tuple Spaces, Object Orientation and Logic Programming. Computer Languages, v.22, n.2/3, p.79-93, july/october 1996.

[BAR 93] BARBOSA, Jorge L. V. Construção de Compiladores para Máquinas de Processamento Paralelo. Pelotas: UCPel, 1993. 73p. Monografia de Especialização.

[BAR 94] BARBOSA, Jorge L. V. Análise da Granulosidade de Tarefas para Processamento Paralelo. Porto Alegre: CPGCC-UFRGS, 1994. 93p. (Trabalho Individual, 376).

[BAR 96] BARBOSA, Jorge L. V. GRANLOG: Um Modelo para Análise Automática de Granulosidade na Programação em Lógic. Porto Alegre: CPGCC da UFRGS, 1996. 167p. Dissertação de Mestrado.

[BAR 98] BARBOSA, Jorge L. V. Paradigmas de Desenvolvimento de Sistemas Computacionais. Porto Alegre: CPGCC da UFRGS, 1998. 49p. (Trabalho Individual, 731).

[BAR 98a] BARBOSA, Jorge L. V.; GEYER, Cláudio F R. Taxonomia Multiparadigma. In: CONGRESO ARGENTINO DE CIENCIAS DE LA COMPUTACIÓN, 4., 1998, Neuquén. Proceedings... Neuquén: Universidad Nacional del Comahue, octubre 1998. 1162p. p.1162 (poster).

[BAT 92] BATINI, Carlo; CERI, Stefano; NAVA THE, Shamkant B. Conceptual Database Design: An Entity-Relantionship Approach. Redwood: The Benjamin/Cummings Publishing Company, 1992. 470p.

[BOH 80] BOHM, David. A Totalidade e a Ordem Implicada - Uma Nova Percepção da Realidade. São Paulo: Cultrix, 1980. 292p.

[BOH 86] BOHM, David. A Ordem Implícita e a Ordem Superimplícita. In: WEBER, Renée (eds.). Diálogos com Cientistas e Sábios - A Busca da Unidade. São Paulo: Cultrix, 1986. p.43-73.

[BOH 86a] BOHM, David. Criatividade: a assinatura da natureza. In: WEBER, Renée (eds.). Diálogos com Cientistas e Sábios - A Busca da Unidade. São Paulo: Cultrix, 1986. p.121-133.

[BYT 95] A Brief History of Programming Languages. Byte, p.121-122, september 1995.

[CAP 75] CAPRA, Fritjof. O Tao da Física. São Paulo: Cultrix, 1975. 260p.

[CAP 82] CAPRA, Fritjof. Ponto de Mutação - A Ciência, a Sociedade e a Cultura Emergente. São Paulo: Cultrix, 1982. 447p.

[CHA 97] CHAKRAVA RTY, Manuel M. T.; LOCK, Hendrik C. R. Towards the Uniform Implementation of Declarative Languages. Computer Languages, v.23, n.2-4, p.121-160, july-december 1997.

73

[CIA 96] CIAMPOLINI, A.; LAMMA, E.; STEFANELLI, C; MELLO, P. Distributed Logic Objects. Computer Languages, v.22, n.4, p. 237-258, december 1996.

[EIN 81] ENSTEIN, Albert. Como Vejo o Mundo. Rio de Janeiro: Nova Fronteira, 1981. 213p.

[EIN 95] ENSTEIN, Albert. Pan-Europa. In: MOREIRA, Ildeu C.; VIDEIRA, Antonio A. P. (eds.). Einstein e o Brasil . Rio de Janeiro: Editora UFRJ, 1995. p.71-75

[FIL 85] FILHO, Edgard de Alencar. Teor ia Elementar dos Conjuntos. São Paulo: Editora Nobel, 1985. 324p.

[FRI 92] FRIEDMAN, Linda W. From Babbage to Babel and Beyond: A Brief History of Programming Languages. Computer Languages, v.17, n.1, p. 1-17, 1992.

[GAR 92] GARLAN, David; KAISER, Gail E.; NOTKIN, David. Using Tool Abstraction to Compose Systems. Computer, New York, p.30-38, june 1992.

[GAR 95] GARLAN, David et al. Research Directions in Software Engineering. ACM Computing Surveys, v.27, n.2, p.257-276, june 1995.

[GRO 94] GROF, Stanislav. A Mente Holotrópica. Rio de Janeiro: Rocco, 1994. 279p.

[HAI 86] HAILPERN, Brent. Multiparadigm Research: A Survey of Nine Projects. IEEE Software, New York, v.3, n.1, p. 70-77, january 1986.

[HAN 97] HANUS, Michael. Lazy Narrowing with Simpli fication. Computer Languages, v.23, n.2-4, p.61-85, july-december 1997.

[IEE 95] IEEE Transactions on Software Engineering. New York, v.21, n.4, April 1995. (Special Issue on Software Architecture)

[IEE 86] IEEE Software. New York, January 1986. (Special Issue on Multiparadigm Languagens and Environments)

[IEE 98] IEEE Transactions on Software Engineering. New York, v.24, n.5, May 1998. (Special Issue on Mobilit y and Network-Aware Computing)

[KUH 70] KUHN, Thomas S. A Estrutura das Revoluções Científicas. São Paulo: Perspectiva, 1970. 257p.

[KUH 77] KUHN, Thomas S. Reconsiderações Acerca dos Paradigmas. In: KUHN, T. (ed.). A Tensão Essencial. Lisboa: Edições 70, 1977. p.353-382

[LEE 97] LEE, J. H. M.; PUN, P. K. C. Object Logic Integration: A Multiparadigm Design Methodology and a Programming Language. Computer Languages, v.23, n.1, p.25-42, april 1997.

[LIP 78] LIPSCHUTZ, Seymour. Teor ia dos Conjuntos. São Paulo: Editora McGraw-Hill , 1978. 337p.

74

[MAR 91] MARTIN, James; MCCLURE, Carma. Técnicas Estruturadas e Case. São Paulo: McGraw-Hill , 1991. 854p.

[MEI 88] MEIRELLES, Fernando de S. Informática: Novas Aplicações com Microcomputadores. São Paulo: McGraw-Hill , 1988. 444p.

[MUL 95] MULLER, Martin; MULLER, Tobias; ROY, Peter V. Multiparadigm Programming in Oz. In: SMITH, Donald; RIDOUX, Olivier; ROY, Peter V. (eds.). Visions for the Future of Logic Programming: Laying the Foundations for a Modern Sucessor of Prolog. Portland, Oregon, december 1995.

[NGK 95] NG, K. W.; LUK, C. K. I+: A Multiparadigm Language for Object-Oriented Declarative Programming. Computer Languages, v.21, n.2, p. 81-100, july 1995.

[ORT 85] ORTEGA y GASSEY, José. Europa y la Idea de Nacion. Madri: Alianza Editorial, 1985. 215p.

[ORT 87] ORTEGA y GASSEY, José. A Rebelião das Massas. São Paulo: Martins Fontes, 1987. 258p.

[ORT 92] ORTEGA y GASSEY, José. Mision de la Universidad. Madri: Alianza Editorial, 1992. 238p.

[PLA 91] PLACER, John. The Multiparadigm Language G. Computer Languages, v.16, n.3/4, p.235-258, 1991.

[RUM 94] RUMBAUGH, James; et al. Modelagem e Projetos Baseados em Objetos. Rio de Janeiro: Campus, 1994. 652p.

[SHA 89] SHATZ, Sol. M.; WANG Jia-Ping. Tutor ial: Distr ibuted-Software Engineering. New York: IEEE Computer Society Press, 1989. 279p.

[SHA 95] SHAW, M. et al. Abstractions for Software Architecture and Tools to Support Them. IEEE Transactions on Software Engineering, Washington, v.21, n.4, p.314-335, april 1995.

[SHA 96] SHAW, Mary; GARLAN, David. Software Architecture: Perspectives on an Emerging Discipline. New Jersey: Prentice-Hall , 1996. 242p.

[SOU 93] SOUSA, Walter. O Novo Paradigma - A Ciência a Procura da Verdadeira Luz. São Paulo: Cultrix, 1993. 145p.

[TAL 91] TALBOT, Michael. O Universo Holográfico. São Paulo: Best Seller, 1991. 390p.

[VRA 95] VRANES, Sanja; STANOJEVIC, Mladen. Integrating Multiple Paradigms within the Blackboard Framework. IEEE Transactions on Software Engineering, New York, v.21, n.3, p.244-262, march 1995.

[WEB 86] WEBER, Renée. Diálogos com Cientistas e Sábios - A Busca da Unidade. São Paulo: Cultrix, 1986. 302p.

75

[WEG 93] WEGNER, Peter. Tradeoffs between Reasoning and Modeling. In: AGHA, G.; WEGNER, P.; YONEZAWA, A. (eds.). Research Direction in Concurrent Object-Or iented Programming. Cambridge: Mit Press, 1993. p.22-41

[WIL 82] WILBER, Ken et al. O Paradigma Holográfico e outros Paradoxos - Uma Investigação nas Fronteiras da Ciência. São Paulo: Cultrix, 1982. 279p.

[YAM 94] YAMIN, Adenauer C. Um Ambiente Para Exploração de Paralelismo na Programação em Lógica. Porto Alegre: CPGCC da UFRGS, 1994. 204p. Dissertação de Mestrado.

[ZAV 96] ZAVE, Pamela; JACKSON, Michael. Where Do Operations Come From? A Multiparadigm Specification Technique. IEEE Transactions on Software Engineering, New York, v.22, n.7, p.508-528, july 1996.