Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Aspectos importantes de uma metodologia para desenvolvimento de software com objetos distribuídos Juliana Pelandré Gravena TG-01-2000 Maringá - Paraná Brasil

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática i Aspectos importantes de uma metodologia para desenvolvimento de software com objetos distribuídos Juliana Pelandré Gravena TG-01-2000 Trabalho de Graduação apresentado ao Curso de Ciência da Computação, do Centro de Tecnologia, da Universidade Estadual de Maringá. Orientadora: Profa. Dra. Elisa Hatsue Moriya Huzita Maringá - Paraná 2000

ii Juliana Pelandré Gravena Aspectos importantes de uma metodologia para desenvolvimento de software com objetos distribuídos Este exemplar corresponde à redação final da monografia aprovada como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação da Universidade Estadual de Maringá, pela comissão formada pelos professores: Orientadora: Profa. Dra. Elisa Hatsue Moriya Huzita Departamento de Informática, CTC, DIN Profa. Dra. Tânia Fátima Calvi Tait Departamento de Informática, CTC, DIN Profa. Maria Madalena Dias Departamento de Informática, CTC, DIN Maringá, Dezembro de 2000

iii Agradecimentos Agradeço primeiramente a Deus que permitiu a conclusão de mais essa fase na minha vida. Agradeço a minha família, especialmente a minha mãe Joana, a minha irmã Beatriz e aos meus avós Francisco e Maria, pelo apoio, incentivo e paciência durante o tempo em que precisei me dedicar para a realização dos trabalhos. Sei que muitas vezes me tornei ausente e distante principalmente quando estava preocupada com os estudos. Agradeço, ao Danillo que foi o maior incentivador, e a pessoa mais presente não só no desenvolvimento desse trabalho, mas durante toda a graduação. E nas horas mais difíceis onde eu queria mesmo era desistir, lá estava ele para me dar forças para continuar. Que Deus permita que um dia eu possa retribuir tudo o que ele foi e continua sendo para mim. Aos amigos que fiz durante esses 4 anos, e que continuarão sempre presentes nos meus pensamentos especialmente: Luciano, Paulinha, Renato, Dequech, Gustavo, Suzete e Daniella Patricia sei que agora cada um segue seu caminho e esses anos da graduação vão ficar para trás, mas com certeza não serão esquecidos. Houve muitos momentos de realizações e de uma forma ou de outra chegamos ao fim dessa fase. Desejo boa sorte a todos e um futuro de sucesso. A minha orientadora Profa. Elisa Hatsue Moriya Huzita, pelo apoio, paciência e esforço dedicados no desenvolvimento desse trabalho. Aos professores Marcio Eduardo Delamaro e Edmundo Sérgio Spoto, que além de professores tornaram-se grandes amigos e com certeza vão estar sempre nas minhas lembranças. Aprendemos nessa vida que a verdadeira amizade se conquista através das ações e sinceridades embora muitas vezes só nos resta lembrar que foi bom o pouco que durou.

iv Resumo A busca por inovações, os avanços tecnológicos e a utilização de aplicações cada vez mais complexas têm impulsionado os estudos referentes a sistemas distribuídos. Percebendo o interesse por parte da comunidade de engenharia de software, emergente no que se refere a esse tipo de sistemas, surgiu a motivação pelo estudo das características e problemas de um sistema distribuído com o objetivo de propor uma representação adequada aos modelos elaborados durante o processo de desenvolvimento dos mesmos. Assim, foram efetuados estudos de metodologias para desenvolvimento de software, em particular: Unified Software Development Process e MOOPP (Metodologia Orientada a objeto para processamento paralelo), afim de, analisar os recursos oferecidos pelas mesmas para tratar os aspectos relacionados a sistemas distribuídos. Dentre as adequações a serem realizadas foram propostas as fases para um processo de desenvolvimento de software distribuído, bem como as atividades importantes em cada uma dessas fases. Além disso, foi proposta uma representação adequada, pelo nosso entendimento, levando em consideração as características de um sistema distribuído. Como forma de validar essas adequações foi especificado um sistema de controle de eventos científicos, como exemplo.

v Abstract The search for innovations, the technological progresses and the use of applications more and more complex they have been impelling the referring studies to distributed systems. The growing use of nets of computers that come happening due to the increase in the search for innovations, to the technological progresses and the use of applications more and more complex have been impelling the referring studies to distributed systems. The emergent interest of that type of systems have motivated studies about the characteristics and problems of a distributed system with the aim to proposing a more adequate representation for the models that will be elaborated during development of them. Studies of methodologies for software development, were made in particular by: Unified Software Development Process and MOOPP, aiming to evaluate the resources offered by them regard to the aspects of distributed systems. Among the adaptations that will accomplished, the definition of the phase for a process of development of distributed software were proposed, as well as the main activities in each one. Besides, an appropriate representation was proposed taking in account the characteristics of a distributed system. Finally, case study was accomplished aiming to validate the adaptations, which were proposed.

vi Índice 1.INTRODUÇÃO 1 1.1 MOTIVAÇÃO 1 1.2 OBJETIVOS DO TRABALHO 3 1.3 ORGANIZAÇÃO DO TRABALHO 3 2. SISTEMAS DISTRIBUÍDOS 4 2.1 INTRODUÇÃO 4 2.2 ESTRUTURA BÁSICA DE UM SISTEMA DISTRIBUÍDO 4 2.3 PRINCIAPAIS CARACTERÍSTICAS 5 2.3.1 SUPORTE AOS RECURSOS COMPARTILHADOS 5 2.3.2 MAIOR GRAU DE ABERTURA DO SISTEMA 6 2.3.3 CONCORRÊNCIA 6 2.3.4 TOLERÂNCIA A FALHAS 7 2.3.5 TRANSPARÊNCIA 7 2.4 PRINCIPAIS PROBLEMAS 8 2.4.1 PROBLEMAS DE COMIUNICAÇÃO 8 2.4.2 PROBLEMAS DE SINCRONIZAÇÃO 8 2.4.3 QUEDAS 9 2.5 CONSIDERAÇÕES FINAIS 9 3.OBJETOS DISTRIBUÍDOS E COMPONENTES 10 3.1 INTRODUÇÃO 10 3.2 OBJETOS DISTRIBUÍDOS 11 3.2.1 PRINCIPAIS CARACTERÍSTICAS DOS OBJETOS DISTRIBUÍDOS 11 3.2.2 TENDÊNCIAS 12 3.3 DESENVOLVIMENTO BASEADO EM COMPONENTES 14 3.3.1 CARACTERÍSTICAS DE UM COMPONENTE 14

vii 3.3.2 ALGUMAS VANTAGENS DA UTILIZAÇÃO DE COMPONENTES 15 3.4 CONSIDERAÇÕES FINAIS 16 4. METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 17 4.1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 17 4.2 UNIFIED PROCESS 17 4.2.1 PRINCIPAIS CARACTERÍSTICAS 18 4.2.2 CICLO DE VIDA DO UNIFIED PROCESS 20 4.2.3 MODELOS 22 4.3 MOOPP 24 4.3.1 FASES 27 4.4 CONSIDERAÇÕES FINAIS 28 5. MDSODI 29 5.1 INTRODUÇÃO 29 5.2 FASES 29 5.2.1 REQUISITOS 29 5.2.2 ANÁLISE 32 5.2.3 PROJETO 34 5.2.4 IMPLEMENTAÇÃO 35 5.2.5 TESTES 36 5.3 REPRESENTAÇÕES 36 5.4 SISTEMA EXEMPLO 41 5.5 ESPECIFICAÇÃO DO SISTEMA EXEMPLO 43 5.5.1 DIAGRAMA DE DOMÍNIO 43 5.5.2 DIAGRAMAS DE USE-CASES 44 5.5.3 DIAGRAMA DE CLASSES 48 5.5.4 DIAGRAMA DE SUBSISTEMAS 48 5.5.5 DIAGRAMAS DE COLABORAÇÃO 51 5.5.6 DIAGRAMAS DE SEQUÊNCIA 55

viii 6. CONCLUSÕES 61 REFERÊNCIAS BIBLIOGRÁFICAS 63 BIBLIOGRAFIA 64 APÊNDICE A A.1 A.1 CÓDIGO DO CADASTRO DO SISTEMA DE CONTROLE DE EVENTOS A.1

ix Índice de figuras Figura 2.1 Estrutura básica de um sistema distribuído 5 Figura 4.1- Ciclo de vida do Unified Software Development Process 20 Figura 4.2- Objetos exclusivos 25 Figura 4.3- Objetos parcialmente paralelos 25 Figura 4.4 Objetos totalmente paralelos 26 Figura 4.5 Classes exclusivas 26 Figura 4.6 Ciclo de vida 26 Figura 5.1 Modelo de domínio 43 Figura 5.2 Controle de reservas 44 Figura 5.3 Emissão de relatório final 45 Figura 5.4 Controle da programação para divulgação do evento 45 Figura 5.5 Confecção de anais 46 Figura 5.6 Controle de presença para emissão de certificados 46 Figura 5.7 Submissão de trabalhos e cadastro de trabalhos aceitos 46 Figura 5.8 Cadastro de participantes e emissão de crachás 47 Figura 5.9 Controle financeiro 47 Figura 5.10 Diagrama de classes 49 Figura 5.11 Diagrama de subsistemas 50 Figura 5.12 Diagrama de colaboração cadastrar participantes 51 Figura 5.13 Diagrama de colaboração confeccionar anais 51 Figura 5.14 Diagrama de colaboração contabilizar despesas 52 Figura 5.15 Diagrama de colaboração contabilizar presença 52 Figura 5.16 Diagrama de colaboração contabilizar receitas 52 Figura 5.17 Diagrama de colaboração controlar programação 53 Figura 5.18 Diagrama de colaboração distribuir trabalhos 53 Figura 5.19 Diagrama de colaboração emitir certificados 53 Figura 5.20 Diagrama de colaboração emitir crachás 54 Figura 5.21 Diagrama de colaboração emitir relatório final 54

x Figura 5.22 Diagrama de colaboração reservar hotel 54 Figura 5.23 Digrama de colaboração reservar passagens 55 Figura 5.24 Diagrama de colaboração selecionar trabalhos 56 Figura 5.25 Diagrama de seqüência cadastrar participantes 56 Figura 5.26 Diagrama de seqüência confeccionar anais 56 Figura 5.27 Diagrama de seqüência contabilizar despesas 56 Figura 5.28 Diagrama de seqüência contabilizar presença 57 Figura 5.29 Diagrama de colaboração contabilizar receitas 52 Figura 5.30 Diagrama de seqüência controlar programação 57 Figura 5.31 Diagrama de seqüência distribuir trabalhos 58 Figura 5.32 Diagrama de seqüência emitir certificados 58 Figura 5.33 Diagrama de seqüência emitir crachás 58 Figura 5.34 Diagrama de seqüência emitir relatório final 59 Figura 5.35 Diagrama de seqüência reservar hotel 59 Figura 5.36 Digrama de seqüência reservar passagens 60 Figura 5.37 Diagrama de seqüência selecionar trabalho 60

xi Índice de tabelas Tabela 5.1 Ordem de execução de use-cases seqüenciais 31 Tabela 5.2 Tabela comparativa entre os tipos de use-cases 36 Tabela 5.3 Tabela comparativa entre os tipos de atores 37 Tabela 5.4 Tabela comparativa entre os tipos de classes 38 Tabela 5.5 Tabela comparativa entre os tipos de relacionamentos 41 Tabela 5.6 Ordem de execução dos use-cases seqüências 44

1 Capítulo 1 Introdução 1.1 Motivação Atualmente, tem se deixado de lado, ou pelo menos diminuído, o interesse por aplicações monousuário e a atuação tem se voltado em direção a aplicações que envolvem a utilização de redes de computadores. Isso vem ocorrendo, principalmente devido ao aumento na procura por inovações, pelos avanços tecnológicos que têm ocorrido bem como ao desenvolvimento e utilização de aplicações cada vez mais complexas. Nesse contexto o estudo relacionado ao desenvolvimento de sistemas distribuídos, tem se tornado cada vez mais atraente. Sistemas distribuídos consistem em uma coleção de computadores autônomos ligados por uma rede, buscando-se desta forma coordenar as atividades, de maneira eficiente, além de propiciar o compartilhamento de recursos [Cou96]. Esse tipo de sistema suporta um número muito maior de aplicações quando comparado aos sistemas monousuários, o que vem intensificando sua utilização. A eficiência desses sistemas em comparação com os sistemas convencionais pode ser notada pelas características diferenciadas que os mesmos proporcionam: (i) suporte aos recursos compartilhados quer sejam de hardware quanto de software; (ii) maior grau de abertura do sistema permitindo a inclusão ou exclusão de serviços compartilhados sem prejudicar a performance do sistema; (iii) tolerância a falhas tanto de hardware quanto de software; (iv) transparência permitindo que o usuário utilize as vantagens de se trabalhar com um sistema distribuído, mas visualize o sistema como uma única máquina e (v) concorrência o que permite que mais de um programa seja executado simultaneamente.

2 Contudo, como não poderia deixar de ser, apresentam alguns problemas que na maioria das vezes chegam a ser mais complexos do que os que ocorrem com os sistemas convencionais. Esses problemas, devem ser tratados diferenciadamente, a fim de evitar maiores complicações futuras. São eles: (i) problemas de comunicação: os computadores precisam se comunicar para executarem suas tarefas para isso é necessário a utilização de mecanismos específicos, síncronos ou assíncronos; (ii) sincronização: em um sistema distribuído as tarefas podem ocorrer concorrentemente sendo portanto, importante delimitar o início e o fim de tarefas que concorrem na utilização de recursos e (iii) quedas: é importante entender os tipos de mecanismos que podem ser utilizados na recuperação de um sistema distribuído. Portanto projetistas devem considerar esses aspectos quando do desenvolvimento de software distribuído. A comunidade de engenharia de software tem se preocupado no longo dos tempos, em desenvolver estudos a fim de oferecer técnicas/ferramentas adequadas que ofereçam o suporte necessário ao desenvolvimento de software de acordo com diferentes paradigmas. Esta trajetória teve início com a abordagem estruturada, a abordagem OO, a abordagem baseada em componentes e com fortes tendências a ser baseada em agentes. Os estudos realizados mostraram a importância da utilização do paradigma de orientação a objetos, conceitos de sistemas baseados em componentes e objetos distribuídos [Bro97], [Orf96], [Huz95], [Jac99], [Sam98] para o desenvolvimento de sistemas distribuídos. Isso se deve ao fato de que os mesmos proporcionam recursos, tais como: reusabilidade, composição, extensibilidade e portabilidade, que permitem atender as características desse tipo de sistema. Logo, percebe-se a importância da utilização de uma metodologia de desenvolvimento de software, adequada para a especificação de tais tipos de sistemas, principalmente devido a sua complexidade.

3 1.2 Objetivos do trabalho O objetivo geral do trabalho é propor a definição de um método de desenvolvimento de software, que permita representar os aspectos importantes a serem considerados no desenvolvimento de software distribuído. Além da metodologia o trabalho também propõe representações gráficas para a elaboração de modelos gerados durante o desenvolvimento de software. Como forma de validar a metodologia proposta é apresentado um sistema exemplo, especificado segundo a proposta. 1.3 Organização do trabalho No capítulo 02 são apresentados os conceitos básicos sobre sistemas distribuídos; suas características e seus problemas. No capítulo 03 estão apresentados os conceitos relacionados a objetos distribuídos e componentes, associando-os às características dos sistemas distribuídos. No capítulo 04 são apresentados os conceitos de processo de desenvolvimento de software e como uma visão geral das metodologias estudadas: Unified Software Development Process e MOOPP (Metodologia orientada a objeto para processamento paralelo). No capítulo 05 é apresentada a proposta da Metodologia para Desenvolvimento de Software Distribuído MDSODI; suas fases e as propostas de representações. Além disso, é especificado um sistema exemplo. No capítulo 06 é apresentada a conclusão do presente trabalho. No apêndice A é apresentada implementação da parte referente ao cadastro do sistema exemplo, implementado em Java.

4 Capítulo 2 Sistemas Distribuídos 2.1 Introdução Sistemas distribuídos consistem em uma coleção de computadores autônomos ligados por uma rede, buscando-se desta forma coordenar as atividades, de maneira eficiente, além de propiciar o compartilhamento de recursos, quer sejam de hardware ou de software [Cou96]. A crescente utilização de redes de computadores, assim como de computadores cada vez mais potentes aliados ao desenvolvimento de aplicações mais complexas contribuíram para impulsionar o interesse por estudos relacionados a software distribuído. Um outro fator que vem popularizando a utilização dos sistemas distribuídos é o fato do mesmo oferecer suporte a diversos tipos de aplicações: aplicações comerciais concorrentes, demais aplicações que trabalhem com acesso concorrente às informações em banco de dados, aplicações que envolvem compartilhamento de informações, entre outras. 2.2 Estrutura básica de um sistema distribuído Um sistema distribuído é constituído basicamente por: servidores de arquivo, computadores pessoais, estações de trabalho e outros servidores, como por exemplo, impressão e login ligados em rede. A Figura 2.1, apresentada a seguir, extraída de [Cou96] ilustra simplificadamente a estrutura de um sistema distribuído.

5 estação de trabalho estação de trabalho estação de trabalho estação de trabalho computador pessoal LAN (Local Area Network) computador pessoal computador pessoal WAN (Wide Area Network) servidores de arquivo servidores de login, impressão e outros computador pessoal Figura 2.1-Estrutura básica de um sistema distribuído 2.3 Principais características Os sistemas distribuídos se distinguem dos tradicionais, basicamente, devido às características descritas a seguir. 2.3.1 Suporte aos recursos compartilhados Permitem que recursos tanto de hardware, como impressoras, scanner, ou mesmo de software, sejam utilizados de forma compartilhada entre os usuários. É interessante lembrar que esse compartilhamento de recursos é permitido entre todos os usuários que estejam conectados ao sistema, o que oferece muitas vantagens, sendo as principais: compartilhamento de recursos de custo elevado entre os usuários e compartilhamento de dados que sejam de interesse comum a mais de um usuário.

6 2.3.2 Maior grau de abertura do sistema Os sistemas distribuídos permitem que novos serviços compartilhados possam ser adicionados sem com isso prejudicar os serviços existentes. Essa característica, torna o sistema receptivo a modificações, mais flexível que os sistemas convencionais, sem que para isso sejam necessárias modificações complexas no sistema. Segundo [Cou96] um sistema aberto apresenta algumas características: possuírem interface pública e poderem ser construídos a partir de hardware e software de diferentes fornecedores, sem com isso acarretar problemas para o sistema. 2.3.3 Concorrência Os processos em um sistema distribuído podem trabalhar concorrentemente e paralelamente, o que permite a execução de vários programas simultaneamente, sem com isto afetar o desempenho do sistema. A concorrência, segundo [Bac97], pode ocorrer de duas formas: As atividades concorrentes podem trabalhar de forma conjunta, cooperando para atingir um objetivo comum; Em outros casos as atividades concorrentes são completamente independentes e têm seus métodos executados em um sistema comum e assim, precisarão competir para a utilização dos recursos. Quando se trata de concorrência em sistemas distribuídos deve-se tratar os aspectos relacionados à sincronização. Os acessos que ocorrem de forma concorrente assim como as atualizações feitas em recursos compartilhados devem ser atividades sincronizadas. Com a utilização dos clocks objetiva-se evitar falhas na execução das tarefas concorrentes, delimitando o ponto inicial e final de execução.

7 2.3.4 Tolerância a falhas Diferente de um sistema centralizado onde o sistema se torna não disponível frente a uma falha de hardware, nesses sistemas o usuário pode simplesmente mudar de estação e continuar a realização de suas atividades normalmente, a partir do ponto em que estava quando a falha ocorreu. A recuperação de falhas de software, utiliza a técnica conhecida como rollback, que permite que o estado em que o sistema se encontrava possa ser recuperado a partir do ponto em que estava quando uma falha foi detectada. Essas facilidades de recuperação impulsionam o uso de tais sistemas, principalmente por facilitar a manutenção da integridade das informações com as quais se está trabalhando. 2.3.5 Transparência Segundo [Cou96] a transparência em um sistema distribuído permite ao usuário enxergar um sistema distribuído como uma única máquina e não como uma coleção de componentes independentes. Isso faz com que o sistema apresente um desempenho melhor quando comparado aos sistemas de tempo compartilhado (timesharing) que possuam apenas um processador. Segundo o Manual da Ansa [Cou96], existem oito formas de transparências que podem ocorrer. As duas formas mais importantes, principalmente quando se trata de um sistema distribuído são: transparência de acesso e transparência de localização, as quais estão brevemente descritas a seguir: Transparência de acesso: permite que as informações de objetos, independentemente de sua localização, sejam acessadas através de operações similares; Transparência de localização: permite que se acesse informações de objetos sem que para isso seja necessário saber a respeito de sua localização no sistema.

8 2.4 Principais problemas Apesar de suportar um domínio muito maior de aplicações do que os sistemas monousuários, os sistemas distribuídos também apresentam problemas que, na grande maioria das vezes, quando ocorrem, são mais complexos, e por isso precisam ser tratados diferentemente. Os principais estão apresentados, sucintamente, a seguir: 2.4.1 Problemas de comunicação Para executarem suas tarefas os sistemas distribuídos precisam se comunicar. Para isso faz-se necessário a utilização de mecanismos específicos para a transmissão dos dados. Os mecanismos podem ser de dois tipos: Síncronos: corresponde aos casos onde o emissor espera depois de transmitir uma mensagem até que o receptor realize uma operação de recepção. Um processamento seqüencial, como o caso de processamento de uma fila é um tipo de mecanismo que trabalha sincronamente; Assíncronos: nesse tipo de mecanismo a mensagem é colocada em uma fila de mensagens esperando que o receptor aceite-as e enquanto isto o processo emissor pode realizar a transmissão de outras mensagens. As ferramentas de e-mail trabalham de forma assíncrona. 2.4.2 Problemas de sincronização A possibilidade de compartilhamento de recursos oferecida pelos sistemas distribuídos, bem como a concorrência, podem levar a problemas de sincronização. A utilização de recursos compartilhados exige mecanismos que controlem a execução das tarefas. Assim, por exemplo, a execução de uma tarefa em um processo que depende de resultados ou recursos oriundos de outra tarefa só poderá ocorrer quando os mesmos estiverem disponíveis, resultando assim na sincronização entre os processos.

9 Muitas vezes pode-se ter associado à sincronização temporizadores altamente precisos, que podem gerar interrupção a fim de controlar a execução das tarefas. Isso pode ser associado à ordem de clocks que o sistema operacional pode estar submetido. A precisão do temporizador utilizado é um fator essencial já que qualquer falha, por menor que seja, pode afetar a execução dos processos. 2.4.3 Quedas Como os sistemas envolvem a utilização de mais de um recurso simultaneamente, conseqüentemente, está mais propenso a quedas. Para que o usuário obtenha maior segurança é importante a utilização de mecanismos que facilitem a recuperação de um sistema distribuído, após essas quedas. A recuperação pode ser em nível de hardware, ou de software. Em nível de hardware ocorreria de forma a permitir que o usuário continue seu trabalho no ponto em que estava em outra máquina. Já em nível de software, proporciona ao usuário que o mesmo recupere a tarefa a partir do ponto em que estava antes da falha, e possa prosseguir seu trabalho. 2.5 Considerações finais Como se pode perceber é crescente o interesse por estudos em sistemas distribuídos e a principal justificativa para isso, são as características diferenciadas quando comparados aos sistemas monousuários. As características e os problemas apresentados mostram que os sistemas distribuídos são bastante complexos o que conseqüentemente fica refletido também no desenvolvimento do software que daria suporte aos usuários. Assim, observa-se a necessidade de tratar aspectos desse tipo de sistema já nas fases iniciais do projeto. Neste trabalho consideram-se os seguintes aspectos de um sistema distribuído: paralelismo/concorrência, distribuição, comunicação e sincronização.

10 Capítulo 3 Objetos Distribuídos e Componentes 3.1 Introdução O trabalho em questão trata de sistemas distribuídos, que não é um tipo de sistema simples, na verdade, pelo contrário, trata-se de sistemas bastante complexos, como se pode perceber pelas características e problemas expostos no capítulo 02. Pensando nesses aspectos, da complexidade e da compatibilidade de características buscou-se conceitos/ tecnologias que oferecessem o suporte necessário aos sistemas descritos. A utilização de conceitos de orientação a objeto associados a componentes e objetos distribuídos mostraram-se propícios para o desenvolvimento do trabalho, conforme se observa nos parágrafos que se seguem. Segundo [HUZ95] a abordagem OO permite uma exploração implícita do paralelismo, o que está intimamente relacionado ao encapsulamento de dados, oferece mecanismos para tratar da sincronização entre objetos além do que proporciona suporte a concorrência. Como se pode perceber, essas características estão intimamente relacionadas aos sistemas distribuídos. A metodologia OO proporciona uma série de outras vantagens, sendo as principais: facilidade de aplicar técnicas de reusabilidade, facilidade de manutenção, proximidades das situações com eventos do mundo real, modularidade e extensibilidade. Em se tratando de um sistema distribuído, cada parte que o compõe pode ser entendida como um componente organizado de forma distribuída no sistema, por esse motivo, percebemos uma conveniência em se adotar técnicas de objetos distribuídos e desenvolvimento baseado em componentes (CBD), no presente trabalho.

11 3.2 Objetos distribuídos Objetos distribuídos são na verdade objetos que se encontram distribuídos pela rede, que interagem e se comunicam de alguma forma. Esse conceito nos permite associar técnicas de objetos distribuídos aos sistemas distribuídos. Segundo [Wei98] A tecnologia de objetos distribuídos é capaz de revolucionar a computação cliente servidor, por produzir software com desenvolvimento rápido e fácil por parte dos programadores, que sejam de fácil utilização pelos usuários e de fácil gerenciamento pelos administradores do sistema. Assim, a tecnologia de objetos distribuídos permite a criação de sistemas cliente/ servidor mais flexíveis, visto que os dados são encapsulados nos objetos que ficam distribuídos pela rede, o que facilita a localização destes em qualquer parte do sistema. 3.2.1 Principais características dos objetos distribuídos Um objeto possui muitas características que favorecem a sua utilização quando se pensa em especificação e implementação de um sistema. As principais são: encapsulamento, abstração, herança, polimorfismo e principalmente o reuso. Existem também muitos outros motivos, particulares à distribuição dos objetos que tornam interessante associar objetos distribuídos a sistemas distribuídos. Segundo [SAM98], [Orf96] os principais seriam: Flexibilidade e distribuição dos dados: tudo o que se refere a dados são encapsulados dentro dos objetos, permitindo-se dessa forma que seja localizado em qualquer parte de um sistema distribuído, por qualquer outro objeto ou processo. Isso aumenta a interação entre os objetos já que a informação não fica restrita a um local específico, ao contrário, pode ser acessado em qualquer parte da rede onde o objeto estiver localizado;

12 Independência da plataforma e do sistema operacional: permite que um mesmo objeto tenha seus métodos executados em diferentes plataformas e diferentes sistemas operacionais; Independência no gerenciamento de informações: os objetos ficam distribuídos em locais variados na rede, o que lhe confere a independência no sentido de que cada qual pode se auto-gerenciar, além de gerenciar os recursos sob seu controle. Um outro fator associado à independência é o fato de se poder alterar ou mesmo modificar a localização de um objeto sem que isso afete seu desempenho no sistema como um todo; Transparência: os clientes não precisam de informações a respeito de onde o objeto se localiza ou mesmo em que sistema operacional é executado, pode ser na mesma máquina ou em qualquer outra distribuída pela rede, sem interferir no desempenho; Interoperabilidade entre os objetos, independente dos sistemas operacionais; Reuso em outra aplicação, sem a necessidade de mudanças significativas. 3.2.2 Tendências Em um sistema distribuído, a comunicação, a independência de plataformas e a interoperabilidade são aspectos importantes que devem ser considerados. Embora a tecnologia de objetos distribuídos ofereça recursos para dar suporte a essas características, é necessário a utilização de um padrão de comunicação. Os padrões foram desenvolvidos buscando facilitar e melhorar a qualidade da interação entre os diversos objetos distribuídos pela rede. Com base nisso os padrões estabelecem regras de como criar, armazenar e definir objetos de forma a facilitar a comunicação mesmo que em ambientes distintos.

13 Na luta pela padronização alguns grandes grupos lideram o mercado, sendo eles a Sun Microsytsem desenvolvedora da JINI [Orf96], a Microsoft desenvolvedora da arquitetura DCOM 1 [Orf96], a OMG 2 que desenvolveu a arquitetura CORBA 3 [Orf96], entre outras. A arquitetura JINI é um ambiente de computação distribuído, trata-se de um grupo de clientes e serviços que se comunicam através de protocolos JINI. É um conjunto de aplicações escritas em Java que se comunicam através de Java RMI 4. Sua utilização é interessante visto que facilita a utilização de objetos distribuídos associados à linguagem Java. O padrão DCOM utiliza o COM 5 como meio de comunicação entre os objetos distribuídos pela rede. Aqui, é interessante ressaltar que enquanto o CORBA pode ser utilizado em qualquer plataforma sem grandes problemas o DCOM apresenta deficiências quando utilizado em um sistema operacional diferente do Windows. O padrão CORBA vem sendo o mais utilizado atualmente. Utiliza como elo de comunicação um ORB 6 através do qual especifica uma arquitetura completa para a comunicação entre quaisquer objetos distribuídos pela rede. Isto faz com que o CORBA venha se tornando um padrão, principalmente pela sua flexibilidade e portabilidade, características importantes quando se fala em objetos distribuídos. A arquitetura CORBA oferece alguns componentes, sendo um deles a IDL (linguagem de definição de interface) estabelecida pela OMG, e tem como função especificar os objetos, definindo sua interface. É estabelecido um padrão no desenvolvimento das interfaces dos objetos, o que permite que a comunicação entre os objetos seja realizada independente da linguagem de programação utilizada na implementação. 1 DCOM- Distributed Commom Object Model 2 OMG- Object Managment Group 3 CORBA- Commom Object Request Broker Architeture 4 RMI- Remote Method Invocation 5 COM- Component Object Model 6 ORB- Object Request Broker