Informações Principais
     Resumo
     Abstract
     Introdução
     Conclusão
     Download
  
  
  
 
Introdução
 
 
Acadêmico(a): Fabiano Oss
Título: Protótipo de Software para Geração de Sistemas Distribuídos Utilizando Técnicas de Design Patterns
 
Introdução:
Com o aumento da complexidade dos sistemas, desenvolvê-los tornou-se uma tarefa muito difícil. Um dos fatores que gera esta dificuldade é que muitas vezes o entendimento do problema não está muito claro. Além disso, há uma escassez grande na documentação dos problemas e nas soluções encontradas para solucioná-los (Cagnin, 1999). Isso acarreta problemas que muitas vezes se repetem e geram esforços adicionais para a implementação de suas soluções. As tentativas de reuso das boas soluções e do acúmulo de experiências sobre determinados problemas são, na maioria das vezes, iniciativas isoladas de alguns desenvolvedores. Estudos mostram que quando especialistas trabalham em um problema particular é raro que inventem novas soluções completamente diferentes das já existentes para resolvê-los. Diferentes soluções de projeto são por eles conhecidas como novos problemas e, freqüentemente lembram de outros similares e reusam as soluções antigas, pensando em pares “solução/problema” (Cagnin, 1999). Segundo Kroth (2000), o reuso de software é uma abordagem dentro da Engenharia de Software que enfoca o reaproveitamento sistemático das três fases do desenvolvimento de sistemas: análise, projeto e codificação. Atualmente, o reuso apresenta resultados mais concretos na fase de codificação, devido à existência de bibliotecas de classes e de componentes disponíveis em larga escala. A fase de análise tem uma prática de reuso mais restrita, pois não possui tecnologia suficientemente madura. Uma das técnicas existentes para facilitar o reuso de software é a orientação a objetos (Booch, 1994). Entretanto, a simples adoção da tecnologia de objetos, sem a existência de um padrão de reuso explícito e um processo de desenvolvimento de software orientado ao reuso, provavelmente não fornecerá o sucesso esperado no reuso em larga escala. Em outras palavras, a simples adoção da tecnologia de objetos não traz vantagens de reuso, fazendo-se necessário um processo específico que forneça o reuso de software (Jacobson, 1997). Outras técnicas que propõem o reuso de uma aplicação incluem padrões de codificação denominados de framework e padrões de análise definidos com Design Patterns. Um framework, segundo Taligent (1999), é uma estrutura de classes inter-relacionadas, que constitui uma implementação inacabada, para um conjunto de aplicações de um domínio. Além de permitir a reutilização de um conjunto de classes, um framework também minimiza o esforço de desenvolvimento de novas aplicações, pois já contém a definição de arquitetura gerada a partir dele bem como, tem predefinido o fluxo de controle da aplicação. Os Design Patterns, chamados de padrões de projetos constituem um novo mecanismo para expressar experiências na elaboração de projetos orientados a objetos. Este padrão deveria descrever um problema que ocorre várias elaborar uma solução reutilizável para ele, de modo que não necessite se preocupar novamente, com a solução do problema nas novas implementações (Gamma, 1995). Segundo Jacobsen (1999), o padrão Design Patterns, gera um registro das experiências passadas, de forma que estes moldes resolvam problemas de projeto específicos e tornam estes projetos mais flexíveis, elegantes e reutilizáveis. A meta desses padrões, é a criação de uma linguagem comum, que permita uma comunicação efetiva no que se refere à troca de experiências sobre problemas e suas soluções. Desta forma, soluções que se aplicaram a situações particulares, podem ser novamente aplicadas em situações semelhantes por outros desenvolvedores, para que os Design Patterns não fiquem armazenados em bibliotecas escritas em uma linguagem proprietária, o que impede que está solução seja utilizada por sistemas heterogêneos. A solução seria a utilização de uma estrutura de documentos que se torna independente do meio de distribuição. Segundo Laurent (1999), a Extensive Markup Language (XML) provê uma linguagem padrão para descrição de dados, que possui uma série de pontos fortes, dentre os quais: extensibilidade; auto descritivo; fácil manutenção; simplicidade; portabilidade; entre outros. A linguagem XML pode ser utilizada para trocar informações entre as organizações (Marchal, 2000). Desta forma esses modelos não ficam dependentes de um fornecedor específico, o que é positivo quando se pensa em interligar soluções. Segundo Albert Einsten, a necessidade é o fator gerador ou motivador dos novos paradigmas. Em se tratando de desenvolvimento de sistemas não é diferente. As arquiteturas de desenvolvimento sofreram uma grande evolução desde o início da informática. De arquiteturas Monolíticas ou Centralizadas, para arquiteturas Cliente/Servidor ancoradas pelos Sistemas Gerenciadores de Banco de Dados (SGDB) e atualmente para arquiteturas de Objetos Distribuídos, onde de acordo com Lima (2001), os componentes de um sistema assim construídos não precisam estar localizados necessariamente na mesma máquina. Dentre as arquiteturas de objetos distribuídos, os mais utilizados atualmente são (Lima, 2001): a) Common Object Request Broker Architecture (CORBA); b) Java Remote Method Invocation and Specification (Java/RMI); c) Distributed Component Object Model (DCOM). Neste trabalho será utilizada a arquitetura CORBA devido ao fato de ser a únicas entre as todas as apresentadas que permite uma interoperabilidade sobre sistemas distribuídos heterogêneos. Para que essas técnicas citadas sejam realmente utilizadas com o sucesso esperado é necessário especificá-las em uma linguagem de modelagem de objetos. Para Furlan (1998), a Unified Modeling Language (UML) é a linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema que pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação. Existem diversas ferramentas CASE que possuem suporte a linguagem UML, como é o caso do Rational Rose, que será empregada neste trabalho.