Sistemas Distribuídos Configuráveis
3.1. Objetos Distribuídos
3.1.1. Orientação a Objetos
dados locais, os ambientes orientados a objetos baseiam a sua programação em elementos chamados de objetos, os quais são componentes de software que encapsulam tanto os dados como as operações que atuam sobre esses dados (figura 5). Um objeto, que na maioria das propostas é um ente totalmente isolado dos outros, permite a modificação do seu estado interno (dados) unicamente através da invocação de uma das operações contidas na definição do mesmo. A execução de uma das operações internas, com a informação de parâmetros necessária, é chamada de invocação de um método sobre o objeto. Todo objeto é uma instância concreta de alguma classe, possuindo o mesmo conjunto de operações e representação interna que todos os objetos criados a partir dessa classe. Uma classe é a extensão natural do conceito de tipo de dados, podendo ser considerada uma fôrma, ou especificação, baseada na qual os objetos são criados.
Métodos Implementação dos Métodos Estado Interno
(Dados)
Figura 5. Estrutura de um Objeto
Quando um sistema de software manipula só dados e funções como objetos, é chamado de sistema baseado em objetos. Quando os objetos são abstraídos em classes com propriedades de herança e polimorfismo, o sistema é dito orientado a objetos. Desta forma, um sistema de
software orientado a objetos deve prover todos os quatro mecanismos listados a seguir:
a) Encapsulamento: Esconde ou torna privados os detalhes de implementação dos objetos, tornando públicas só as abstrações necessárias para utilizar o objeto. Os objetos se comunicam através de interfaces bem definidas, de modo que as mudanças no seu estado permanecem localizadas dentro do objeto.
b) Abstração: Separa as propriedades essenciais para escrever o software com algum propósito, das propriedades que são irrelevantes a esse propósito. A abstração permite separar a interface do objeto, da sua implementação.
existentes. Como foi dito, uma classe é um molde para uma coleção de objetos com estrutura de dados e comportamento similares. Uma subclasse herda as operações da classe superior, podendo modificá-las ou estende-las com operações adicionais, para criar níveis maiores de especialização. De fato, a herança estabelece uma hierarquia de classes que estimula o reaproveitamento do software visando a organização e simplicidade implícitas. d) Polimorfismo: É uma outra característica bastante útil que permite que uma mensagem
enviada a um objeto possa ter diferentes resultados, dependendo de como o objeto interpreta o pedido. Consiste no uso da mesma operação, em instâncias de classes relacionadas mas distintas, permitindo que a maioria das operações da classe superior possam ser utilizadas nas classes inferiores. Isto possibilita que mesmo que uma operação faça sentido na classe superior e na inferior, as implementações em cada uma delas possam ser distintas, de forma a alterar o seu comportamento.
A orientação a objetos permite um rápido desenvolvimento graças ao mecanismo de herança, que permite que novas peças de código herdem os comportamentos de projetos e códigos existentes. Deve-se notar que o projeto, e não simplesmente o código, pode ser reutilizado, sendo esta uma característica essencial. Uma vez que um objeto é projetado, escrito, depurado e usado em uma determinada aplicação, a sua utilidade aumenta já que ele foi verificado e testado, sendo potencialmente mais confiável. Devido a que os sistemas orientados a objetos podem ser implementados gradualmente, a sua manutenção pode também ser reduzida. Uma vez postos em funcionamento, os sistemas continuam sendo paulatinamente melhorados, com efeitos localizados dentro dos objetos da aplicação. Tudo isto, graças às características de encapsulamento e abstração encontradas na programação orientada a objetos. Aliás, é importante mencionar que os sistemas orientados a objetos raramente mudam a sua estrutura global. É comum, em muitos casos, somente a evolução contínua dos objetos neles contidos.
No entanto, o verdadeiro poder do software orientado a objetos reside na construção de
frameworks específicos para as aplicações em desenvolvimento. Um framework é um projeto para uma aplicação genérica que não só incorpora o código, mas também as interações entre os módulos de código. Em resumo, pode se dizer que a programação orientada a objetos resolve três problemas principais que são enfrentados no desenvolvimento de software:
• A necessidade de desenvolver novos sistemas rápida, incremental e interativamente. • A necessidade de reutilizar componentes já testados.
• A necessidade de reduzir os custos de manutenção na fase de funcionamento.
3.1.2. Alternativas
A distribuição em um modelo orientado a objetos gera uma série de problemas que dificultam a implementação completa do paradigma na sua forma tradicional. As maiores considerações que tem que ser levadas em conta, para o caso dos sistemas distribuídos, são as listadas a seguir:
a) Herança: Os custos envolvidos na busca dentro da hierarquia de classes através do sistema distribuído, inviabilizam as vantagens obtidas com a adoção desta técnica.
b) Verificação de Tipo: As linguagens orientadas a objetos não possuem verificação de tipo estática. No caso distribuído, devido ao seu tratamento remoto, isto pode gerar erros indesejáveis em tempo de execução.
c) Gerenciamento: Parte da funcionalidade no gerenciamento de uma linguagem orientada a objetos está determinada pela hierarquia de classes que descreve o comportamento dos objetos requeridos por uma aplicação, não existindo uma descrição explícita da estrutura do programa. Isto se contrapõe com a descrição explícita da relação entre os elementos, importante em ambientes distribuídos.
d) Granularidade de Concorrência: Basicamente se tem dois casos, no primeiro a granularidade de concorrência coincide com o objeto, e no segundo, um objeto pode suportar várias threads de execução simultânea.
e) Falhas Parciais: São as falhas introduzidas em operações que não exigem maiores cuidados, requerendo mecanismos adicionais de tratamento que vão desde a simples detecção de falhas, até tolerância a falhas transparente.
f) Localização de Objetos: No caso de métodos herdados ou delegados, é necessária a existência de mecanismos que garantam a correta informação da localização dos objetos. A localização deve atuar de forma transparente aos objetos e aos mecanismos de interação. O modelo tradicional define a orientação a objetos como o resultado de misturar objetos, classes e herança, sendo esta visão fortemente dependente dos mecanismos usados para obter tais propriedades. Uma abordagem paralela, é ter a orientação a objetos como o resultado de combinar encapsulamento, abstração de dados e polimorfismo. Esta última visão oferece as mesmas propriedades, sem as dificuldades de implementação associadas, sendo duas as
alternativas que se mostram mais viáveis para este caso: a delegação direta e a composição hierárquica[60]. Estado Métodos Estado Métodos Estado Métodos Estado Métodos Delegação Direta Composição Hierárquica
Figura 6. Delegação Direta e Composição Hierárquica
DELEGAÇÃO DIRETA
A delegação consiste na transferência direta da responsabilidade do tratamento de um método de um objeto para outro (figura 6). Não impõe restrições quanto às relações existentes entre os objetos encapsulados, já que não se baseia na hierarquia de classes nem em nenhuma outra forma de relação entre objetos. Como não existe o mecanismo de herança que permita o compartilhamento de dados locais pelas classes relacionadas, deve ocorrer a delegação explícita das informações locais na transferência dos métodos. Isto leva a que a transferência de um método possa requerer um tratamento local, tanto para condicionar os parâmetros como para informar as variáveis de estado locais.
No caso distribuído, esta abordagem tem duas deficiências principais: não fica claro como podem ser construídos objetos complexos que encapsulem atividades internas paralelas, e, falta uma definição explícita da relação existente entre os objetos que determine a descrição do programa como composto por vários objetos.
COMPOSIÇÃO HIERÁRQUICA
sua relação (ou delegação) interna fixa e determinada na sua definição (figura 6). O objeto composto consiste de uma casca que provê uma definição de mais alto nível para os objetos internos ativos que funcionam cooperativamente. Neste caso, a propriedade da herança ocorre no âmbito da interface antes que na implementação. A composição pode ser feita com base em objetos estritamente encapsulados ou objetos não-estritamente encapsulados. Devido a que os objetos estritamente encapsulados oferecem uma interface bem definida para os serviços utilizados e oferecidos pelo objeto, assim como uma definição clara dos tipos de dados e formas de interação empregadas, são mais adequados para o caso distribuído.
As propriedades obtidas com a herança, como a reutilização e o compartilhamento de recursos, podem também ser obtidas pela composição hierárquica, sem mencionar a abstração natural que este conceito facilita na composição de sistemas complexos.