Integração dos frameworks JHotDraw e OCEAN para a produção de objetos visuais a partir do framework OCEAN.

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CENTRO TECNOLÓGICO

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO

INTEGRAÇÃO DOS FRAMEWORKS JHOTDRAW E OCEAN PARA A PRODUÇÃO DE OBJETOS VISUAIS A PARTIR DO FRAMEWORK OCEAN.

JOÃO DE AMORIM JUNIOR

Trabalho apresentado como parte das exigências do Curso de Ciências da Computação, da Universidade Federal de Santa Catarina, para a obtenção do grau de Bacharel.

Banca Examinadora:

Prof.º Frank Augusto Siqueira Prof º. Leandro José Komosinski Prof ˚. Ricardo Pereira e Silva Prof º. Vitório Bruno Mazzola

Prof º. Ricardo Pereira e Silva

Orientador

FLORIANÓPOLIS

Agradecimentos

Aos meus pais, João e Iloir, por tudo que fazem e já fizeram por mim. A minha irmã Katiucia por acreditar em mim.

A todos os parentes e amigos que torcem por mim.

Em especial aos colegas Ademir Coelho e Thiago Spina Machado, companheiros mais próximos de projeto, pela grande ajuda que forneceram.

Aos também colegas Otavio Fuck Pereira e Roberto Silvino Cunha demais parceiros de projeto.

Em especial também, ao Professor Ricardo Pereira e Silva por ter me orientado neste trabalho e pela dedicação, paciência e auxílio a mim concedido.

Resumo

O reuso de software é uma das alternativas utilizadas na Engenharia de Software para melhorar a qualidade do software e desenvolvê-lo no menor tempo possível. Frameworks são artefatos de software flexíveis e extensíveis, utilizados como ponto de partida para o desenvolvimento de novos artefatos. OCEAN é um framework desenvolvido com o intuito de suportar o desenvolvimento de ambientes flexíveis de suporte ao desenvolvimento de software. OCEAN foi implementado em SmallTalk, que é uma linguagem interpretada, e está passando por uma reengenharia, com o objetivo de migrá-lo para Java.

Para dar suporte ao desenvolvimento de editores gráficos ao OCEAN, será utilizado o framework JHotDraw, que é um framework voltado ao desenvolvimento de editores gráficos bidimensionais. A intenção é entender as características de JHotDraw para que se possa usufruir seus pontos fortes, viabilizando seu uso em conjunto com o framework OCEAN. O objetivo é integrar os dois frameworks, para que seja suportada a geração das visões dos elementos conceituais tratados em OCEAN.

Abstract

The software reuse is one of alternatives used in Software Engineering to improve the software quality and to develop it in the smallest possible time. Frameworks are flexible and extensible software artifacts used how starting point for new artifact development. OCEAN is a framework developed with intention to support the development of flexible environments to software development supporting. OCEAN was implemented in Smalltalk that is one interpreted programming language, and it is passing to reengineering, with objective to change it to Java.

To give support for graphical editors development to OCEAN, it will be used the framework JHotDraw, that it is a framework intended to the development of two dimensions graphical editors. The intention is to understand the JHotDraw characteristics to usufruct their strong points, and make possible their use together the OCEAN framework. The objective is to integrate the two frameworks, to support the creation of the OCEAN conceptual elements views.

Sumário

Lista de Abreviaturas...7

1 Introdução...8

1.1 O Problema...9

1.2 O Projeto...10

1.3 Organização do Texto da Monografia...10

2 Frameworks...11 2.1 Frameworks e Padrões...11 2.2 Características...13 2.3 Classificação...14 2.4 Utilização de Frameworks...15 2.5 Vantagens e Desvantagens...16 3 O Framework OCEAN...18 3.1 O Padrão MVC ...18 3.2 Estrutura Básica ………...……….….... 20 4 O Framework JHotDraw...……...23 4.1 Características...23 4.2 Estrutura...24 4.3 Processo de Desenvolvimento...26

4.4 Padrões de Projeto do JHotDraw...27

4.4.1 O Padrão Observer ...28 4.4.2 O Padrão Decorator ...28 4.4.3 O Padrão Composite...28 4.4.4 O Padrão Strategy...30 4.4.5 O Padrão State...31 4.4.6 O Método Template...32

4.4.7 O Método Fabrica (Factory)...34

4.4.8 O Padrão Protótipo (Prototype)...34

4.5 Aplicação Desenvolvida a partir do JHotDraw...35

4.5.2 Implementação...36

5 Integração do JHotDraw na Estrutura Gráfica do OCEAN...38

5.1 Adaptações Necessárias ...38

5.2 Roteiro de Criação de Editores ...45

5.3 Outros Editores Desenvolvidos ...50

5.3.1 Diagrama de Seqüência ...53

6 Conclusão...61

Referências Bibliográficas...62

Lista de Abreviaturas

• GUI – Interface Gráfica com o Usuário • MVC – Model-View-Controller

• UML – Unified Modelling Language (Linguagem de Modelagem Unificada) • DFD – Diagrama de Fluxo de Dados

1 Introdução

A Engenharia de Software é um ramo da Ciência da Computação que se preocupa em estabelecer meios sistemáticos de desenvolvimento de software, visando a maximização da qualidade e da produtividade desta atividade.

A noção de qualidade de software não se resume a um único fator, mas a um conjunto de fatores que reunidos caracterizam-na, como correção, robustez, estendibilidade, eficiência, compatibilidade, integridade, entre outros. Outro fator não mencionado anteriormente, e que se dará maior ênfase neste trabalho, será a reusabilidade.

Um software reusável pode ser totalmente, ou apenas em parte, utilizado em novas aplicações. Este reuso não se resume a código, mas também a concepções de projeto, como idéias e experiência. Um dos princípios importantes da Engenharia de Software é o da modularidade. Com base neste princípio, o software é construído como uma composição de módulos, facilitando a sua manutenção, e favorecendo o reuso de partes do software.

Já há algum tempo, a indústria de software vem vivenciando um paradoxo: os programas estão cada vez mais complexos, e o tempo e o custo de desenvolvimento devem ser cada vez menores. O reuso de artefatos de software previamente construídos é uma ferramenta de grande valia no processo de melhora da qualidade de software, diminuindo o tempo de desenvolvimento e garantindo uma maior estabilidade do sistema.

O reuso implica em um menor esforço: mesmo em um novo desenvolvimento, não será necessário começar da estaca zero. Cada software desenvolvido tem seu detalhe particular, mas a atividade em que ele é empregado é semelhante à de vários outros softwares. Assim, é possível desenvolver este software com base em algum (ou alguns) outros já existentes que forneçam funcionalidades que esta nova aplicação necessita.

O reuso garante ainda uma maior proteção ao software, através do uso de artefatos componíveis, compreensíveis e cujas interfaces sejam estáveis. Os artefatos reusáveis tendem a ter uma depuração maior, evitando a propagação de falhas e resultando em um software com menos erros.

Uma das técnicas de reuso não apenas de código, mas também de elementos das etapas de análise e projeto, são os frameworks. Um framework é uma estrutura de classes inter-relacionadas, que corresponde a uma implementação incompleta para um conjunto de aplicações

de um determinado domínio. Esta estrutura de classes deve ser adaptada para a geração de aplicações específicas [JOH 92]. Esta ferramenta extensível, flexível, e que garante alta reutilização, pode ser definida como um ponto de partida para aplicações de uma mesma família de problemas.

Frameworks orientados a objetos focam no reuso de classes, através de composição e herança, que são características importantes do paradigma OO. Pela composição, classes concretas prontas são encaixadas no sistema. A herança prega o reuso de interfaces ou classe concretas, mas não com o objetivo de gerar instâncias, mas sim de especialização.

O framework OCEAN está voltado para a construção de ambientes de desenvolvimento de software, que manuseiam especificações de projeto. Ele foi desenvolvido durante o doutorado de Ricardo Pereira e Silva para a produção de um ambiente flexível de suporte ao desenvolvimento e uso de frameworks e componentes. Na elaboração de OCEAN foi utilizado o framework HotDraw para dar suporte ao desenvolvimento de editores gráficos.

1.1 O Problema

O framework OCEAN foi desenvolvido na linguagem SmallTalk, linguagem esta que é interpretada, o que torna OCEAN menos eficiente do que se este fosse desenvolvidos sob um outro tipo de linguagem de programação, como Java, por exemplo.

Desta forma, uma reengenharia do framework OCEAN está sendo executada, tendo como resultado esperado uma nova versão em Java, para melhorar em muitos aspectos a sua eficiência. Com essa nova versão em Java, o suporte ao desenvolvimento de editores gráficos em OCEAN deve continuar sendo fornecido, mas o framework HotDraw deve ser substituído, devendo ser utilizado um framework escrito em Java, que apresente as características que HotDraw fornece, ainda que de maneira diferente.

1.2 O Projeto

JHotDraw é um framework de editores gráficos desenvolvido na linguagem Java, assim optou-se pela sua adoção como framework gráfico no OCEAN . O objetivo deste projeto é integrar o framework JHotDraw ao framework OCEAN, viabilizando o uso conjunto dos mesmos, para dar suporte a criação de objetos visuais dos elementos conceituais tratados em

OCEAN. A idéia é demonstrar as etapas do processo de desenvolvimento de uma tarefa que envolveu dois frameworks distintos OCEAN e JHotDraw, tendo que ser levada em consideração a complexidade individual de ambos e a relacionada à integração dos dois artefatos de software.

1.3 Organização do Texto da Monografia

A presente monografia é constituída de seis capítulos. No capítulo 2 são tratadas os frameworks, suas características, vantagens e desvantagens. No capítulo 3 dar-se-á uma visão sobre o framework OCEAN. O capítulo 4 apresenta o framework JHotDraw. No capítulo 5 é tratada a integração do JHotDraw na estrutura gráfica do framework OCEAN. A conclusão se encontra no capítulo 6. E por fim, nos anexos se encontram os códigos-fonte do primeiro diagrama desenvolvido.

2 Frameworks

Um framework é uma implementação ou uma estrutura de classes inacabada, de forma proposital, que generaliza um domínio de aplicação, podendo ser desenvolvidas diferentes aplicações pertencentes a um único domínio. Para generalizar este domínio de aplicações, é desenvolvida uma especificação que pode ser usada por todas as demais implementações. Esta especificação é um framework para este domínio.

O projeto de um framework define a arquitetura de classes e o fluxo de controle (seqüência de invocação de métodos) das futuras aplicações. Isto resulta em uma perda de liberdade de escolha da arquitetura da aplicação, mas o reuso é favorecido através das características que podem ser acrescidas (estendibilidade) e da possibilidade de se alterar o que já existe (alterabilidade).

Diferente de uma biblioteca de classes, frameworks não provem somente componentes, mas também uma estrutura para integração entre os componentes, a interoperação dos componentes, e muitas vezes o esqueleto básico da aplicação. Um esqueleto não é passivo como uma biblioteca de classe, mas tem seu próprio caminho de execução de que o código do componente definido pelo usuário é chamado.

2.1 Frameworks e Padrões

Os frameworks fazem uso em sua arquitetura de classes de um grande aliado no favorecimento do reuso que são os padrões de projeto.

Padrões de projeto definem um conjunto de soluções anteriormente utilizadas e amplamente testadas para problemas recorrentes no desenvolvimento de aplicações e artefatos de software OO. Cada padrão existente é uma descrição de um problema e sua solução (podendo esta ser aplicada em muitas situações) que sugere como aplicá-lo e discute as suas vantagens e desvantagens.

Padrões não expressam idéias de projeto novas, eles tentam codificar conhecimento e princípios já conhecidos e que funcionam. Através de um padrão conhecido, os projetistas podem discutir princípios complexos ou idéias de projeto a partir do nome do padrão. O nome é utilizado como referência a um problema de projeto, a sua solução e as suas conseqüências. Cada padrão

descreve objetos e classes que se comunicam e podem ser adaptados para resolver problemas gerais de projeto em um contexto particular.

Padrões capturam a essência de uma idéia que projetistas experientes usaram diversas vezes para resolver um problema comum, abstraindo-se da situação específica. Por isso, os padrões de projeto são independentes da aplicação e tem que ser mapeados para uma situação específica antes de serem implementados.

A descrição do padrão identifica qual o problema que o mesmo visa solucionar e em que contexto ele pode ser aplicado. A solução descreve o padrão, isto é, os elementos que o constituem, seus relacionamentos e responsabilidades. Como um padrão deve poder ser aplicado nas mais diferentes situações, a descrição não pode ser baseada num exemplo concreto. Ao contrário, deve de forma abstrata mostrar a organização geral da estrutura de classes e objetos que resolvem o problema. Porém, para fins ilustrativos, um exemplo de uma aplicação do padrão pode ser incluído na descrição.

As conseqüências do uso do padrão podem incluir o impacto que o padrão traz em termos de flexibilidade, estendibilidade e portabilidade, informações sobre características de espaço e tempo e questões sobre implementação em alguma linguagem de programação específica. Explicitar essas considerações é importante, pois certas características de um padrão podem torná-lo inapropriado a um contexto específico, como por exemplo, uma aplicação que demande um tempo de resposta muito baixo. Além disso, se mais de uma solução estiver disponível, essas informações podem ser usadas para que seja selecionada a opção mais adequada.

Os padrões registram as experiências de projetos conquistadas ao longo de esforços de desenvolvimento anteriores, permitindo que se reutilize as soluções encontradas em aplicações posteriores e evitando que seja necessário “reinventar a roda”. Cada padrão representa uma solução encontrada para um problema freqüente de projeto, auxiliando a produção de software reutilizável e flexível, buscando garantir um maior desacoplamento às classes.

Os desenvolvedores inúmeras vezes se deparam com problemas em seus projetos de software que já haviam sido constatados em desenvolvimentos anteriores, problemas estes que são típicos de situações específicas. Havendo uma solução comprovada para estes problemas, é possível capturá-la dentro de um padrão de projeto. Este padrão de projeto descreve o problema, de um âmbito específico, reusando a solução anteriormente encontrada. Este padrão determina

uma denominação significante para o tipo de problema que ele ajuda a resolver, fazendo com que outros desenvolvedores sejam comunicados desta solução e possam usá-la.

Os frameworks freqüentemente dependem de padrões de projeto para auxiliar no alcance da flexibilidade do propósito geral do projeto da aplicação. Os padrões introduzem caminhos indiretos e abstrações, as quais o desenvolvedor utiliza internamente em suas próprias classes e componentes para compor seu sistema.

2.2 Características

Um framework é um esqueleto de implementação de uma aplicação ou de um subsistema de aplicação, em um domínio de problema particular. É composto de classes abstratas e concretas e provê um modelo de interação ou colaboração entre as instâncias de classes definidas pelo framework. Um framework é utilizado através de configuração ou conexão de classes concretas e derivação de novas classes concretas a partir de classes abstratas do framework. (WIRFS-BROCK, 1990). Um framework pode produzir vários tipos de artefatos de software como aplicações, outros frameworks ou componentes.

Frameworks são flexíveis porque suas classes também o são. A flexibilidade que os frameworks apresentam é conseguida em pontos específicos, os hot spots. Hot spots são as partes da estrutura de classes de um framework que devem ser mantidas flexíveis, para possibilitar sua adaptação a diferentes aplicações do domínio. (SIL, 98).

Mas os frameworks também oferecem pontos fixos que definem a arquitetura geral de um sistema, os frozen spots. Neles, os componentes básicos, bem como os relacionamentos entre os mesmos permanecem fixos em todas as instanciações do framework de aplicação. Tais pontos são os pontos de estabilidade do artefato.

O projeto do framework deve prever onde exatamente devem ser efetuadas as alterações da estrutura de classes. Os frameworks se baseiam no princípio de Hollywood ("Don't call us, we'll call you"), ou seja, inversão de controle. Esta inversão de controle permite que o framework (e não a aplicação) determine que métodos invocar em resposta a eventos externos.

Isto significa que os eles não são chamados, mas sim chamam um conjunto de métodos pré-definidos (métodos hooks), e é neste ponto em que o comportamento específico da nova aplicação será inserido, através da herança e do polimorfismo (sobrescrição de métodos). Os

métodos hooks (que implementam os hot spots) formam, em conjunto com métodos templates (que implementam os frozen spots), um ponto de flexibilidade dos frameworks. Métodos hooks podem ser redefinidos pela aplicação e são utilizados pelos métodos templates que implementam de forma genérica um algoritmo.

Um framework se destina a gerar diferentes aplicações para um domínio, desta forma, precisa conter uma descrição dos conceitos deste domínio. As classes abstratas de um framework são os repositórios dos conceitos gerais do domínio de aplicação. Neste contexto, o método de uma classe abstrata pode ser deixado propositalmente incompleto para que sua definição seja acabada na geração de uma aplicação. Apenas atributos a serem utilizados por um domínio, em termos ideais, devem estar completamente definidos em classes abstratas.(SILVA, 2000a).

A característica de generalização leva muitas vezes os frameworks a se tornarem difíceis de compreender, bem como de utilizar. Isto porque, para atender a um determinado domínio de problema ou permitir o desenvolvimento de um conjunto de aplicações diferentes, os frameworks necessitam abranger um grande conteúdo do mesmo. (KLABUNDE, 2000).

A grande complexidade de um framework diz respeito ao seu desenvolvimento e uso. Para desenvolvê-lo existe a necessidade de se produzir uma abstração de um domínio de aplicações adequada a diferentes aplicações, e que seja flexível. Para usar um framework é preciso entendê-lo. Isto implica em compreender sua estrutura, o que geralmente demanda um certo tempo, podendo ter uma alta complexidade. Todavia, este problema pode ser minimizado com o uso de cookbooks (que são descrições de como se utilizar um framework), através do acesso a documentação de projeto, ou em último caso, analisando-se o código.

2.3 Classificação

Os frameworks podem ser classificados de acordo com o seu uso, dimensão e finalidade. Quanto ao uso, eles podem ser do tipo caixa-branca, caixa-preta ou caixa-cinza. Os frameworks do tipo caixa-branca é dirigido à arquitetura. Há a produção de subclasses das classes abstratas com funcionalidades necessárias a aplicação do usuário através de herança.

Os frameworks do tipo caixa-preta são dirigidos a dados, favorecendo o reuso através de composição, com a instanciação das classes do framework para criação de novas classes. O usuário não é totalmente livre para criar ou alterar funcionalidades a partir da criação de classes,

uma vez que o controle da aplicação é definido nas classes do framework e não nas classes do usuário (SILVA, 2000a).

Os frameworks do tipo caixa-cinza são uma combinação das possibilidades anteriores. Apresentam inicialmente partes prontas, permitindo que sejam inseridas novas funcionalidades a partir da criação de classes. Este tipo de framework não somente fornece subclasses concretas, mas permite a criação de novas subclasses concretas.

Quanto à dimensão, os frameworks podem ser de uma ou de múltiplas classes. O framework de uma classe é constituído de uma classe parametrizável ou abstrata ou alterável. Já o de múltiplas classes possui um conjunto de classes inter-relacionadas.

Quanto à finalidade, os frameworks podem servir para a geração de aplicações completas, onde toda a estrutura de uma aplicação está no framework, ou para suportar a produção de unidades funcionais, cujo objetivo é desenvolver funcionalidades específicas, podendo prover apenas parte de uma aplicação (como interface, armazenamento de dados, entre outros).

2.4 Utilização de Frameworks

A finalidade básica de um framework é sua reutilização na produção de diferentes aplicações, minimizando tempo e esforço requeridos para isto. Desta forma, procura ser uma descrição aproximada do domínio, construída a partir das informações até então disponíveis (SILVA, 2000a).

O primeiro passo no uso de um framework no desenvolvimento de uma aplicação é o aprendizado, por parte do desenvolvedor, de como usar o framework. O desenvolvedor precisa conhecer os recursos que o framework disponibiliza para evitar esforços desnecessários durante o desenvolvimento da aplicação. (SILVA, 2000b).

A utilização ideal de frameworks consiste em completar ou alterar procedimentos e estruturas de dados neles presentes. Sob esta ótica, uma aplicação gerada sob um framework não deveria incluir classes que não fossem subclasses de classes do framework. Todavia, como um framework nunca é uma descrição completa de um domínio, é possível que a construção de aplicações por um framework leve à obtenção de novos conhecimentos do domínio tratado, indisponíveis durante a sua construção (SILVA, 2000a).

Cabe observar que, além do desenvolvimento de aplicações a partir de frameworks, estes também podem servir de base para o desenvolvimento de outros frameworks ou fazer parte do desenvolvimento de novos frameworks (KLABUNDE, 2000).

2.5 Vantagens e Desvantagens

Antes de se utilizar um framework, é importante que sejam entendidos seus pontos fortes e fracos, qual o alvo das aplicações a que ele se refere, seus componentes e estrutura, o seu processo de desenvolvimento, seus padrões de projeto fundamentais e suas técnicas de programação.

Um Framework auxilia no desenvolvimento de uma aplicação de maneira oportuna e customizada às exigências do usuário. Esta aplicação se beneficia da robustez e da estabilidade conseguida através de um artefato maduro. Frameworks encapsulam implementações voláteis em interfaces estáveis provendo assim modularidade ao software produzido. Esta modularidade auxilia na melhora da qualidade do produto, reduzindo o impacto causado por mudanças no projeto ou na implementação.

As interfaces estáveis fornecidas por um framework definem estruturas genéricas que permitem a sua reutilização em inúmeras aplicações. Com o reuso da estrutura de um framework são conseguidas melhoras consideráveis na produtividade, juntamente com o aumento de outras características desejáveis como performance, interoperabilidade, robustez e qualidade das aplicações desenvolvidas.

Os métodos hooks e os hot spots favorecem a expansão das interfaces estáveis de uma aplicação. A estendibilidade fornecida por um framework é fundamental para que possam ser asseguradas as adaptações de comportamentos genéricos e de características de um domínio de aplicações a uma nova específica aplicação desenvolvida com base no framework.

Todavia, a decisão de se utilizar um artefato desta complexidade acarreta em um custo do aprendizado e entendimento das interações e limitações do framework. Em sua maioria, os frameworks são componentes de software particularmente complexos, que apresentam um alto nível de abstração.

O entendimento de um framework apresenta certa dificuldade, e a depuração de seu código é muitas vezes incômoda, devido à inversão de controle. Embora ofereçam algumas

facilidades de customização, os frameworks geralmente impõem algumas restrições, podendo requer técnicas especiais de programação, principalmente quando se deseja acrescer alguma funcionalidade levemente fora do escopo definido pelo framework.

A manutenção de frameworks é uma tarefa difícil, isto porque se faz necessário um profundo conhecimento da estrutura do framework e das relações existentes entre suas classes. Atualmente, nenhum padrão para o projeto, desenvolvimento, documentação e uso de frameworks foi desenvolvido e adotado pela comunidade de desenvolvimento de software. Mesmo as metodologias de desenvolvimento existentes não podem ser consideradas um padrão. Com isto, o desenvolvimento, manutenção e uso de frameworks ficam prejudicados.

A integração de dois ou mais frameworks também apresenta uma dificuldade extra. Algumas aplicações são baseadas na integração de vários frameworks (por exemplo, um framework para a interface gráfica com o usuário e outro para a persistência dos objetos). Integrar frameworks geralmente não é uma tarefa das mais triviais, isto porque, a maioria dos frameworks é desenvolvida com o enfoque na estendibilidade interna e não na integração com outros frameworks.

Analisando o enfoque específico desta monografia, que é a integração entre dois frameworks distintos, OCEAN e JHotDraw, cabe ressaltar que esta tarefa também envolveu um grande esforço em todas as etapas do seu processo de desenvolvimento, desde o entendimento de cada framework, com suas complexidades individuais, até a integração dos dois artefatos de software propriamente dita. OCEAN possui sua própria estrutura, todavia precisou-se adaptar e respeitar as restrições impostas por JHotDraw. Questões mais específicas sobre esta característica serão abordadas em capítulos posteriores.

3 O Framework OCEAN

O framework OCEAN é voltado à produção de diferentes ambientes de desenvolvimento de software. Ele possibilita o desenvolvimento de ambientes que manipulem diferentes estruturas de especificação e apresentem diferentes funcionalidades. É um framework do tipo caixa-cinza, constituído por superclasses que são abstratas, ou seja, classes que tratam de definições genéricas de elementos, e também por classes concretas que implementam elementos específicos.

OCEAN teve seu desenvolvimento motivado pela necessidade de produzir um ambiente flexível que suportasse o desenvolvimento e uso de frameworks e componentes. Este framework generaliza as características de ambientes de desenvolvimento de software e suporta o desenvolvimento de ambientes em geral, não se restringindo aos relacionados a frameworks e componentes.

Um ambiente desenvolvido a partir do framework OCEAN possui como única classe específica uma subclasse concreta de EnvironmentManager, que é uma classe abstrata. Todas as demais classes que compuserem o ambiente poderão ser reutilizadas no desenvolvimento de outros ambientes. Através de uma subclasse de EnvironmentManager são definidas características específicas de um ambiente, tais como, o tipo de especificações que serão tratadas, o mecanismo de visualização e edição associado a cada modelo e conceito que o mesmo trata, o mecanismo de armazenamento de especificações que utiliza, e quais as ferramentas utilizáveis para manipular especificações.

OCEAN possui características em sua estrutura que lhe conferem flexibilidade para suportar o desenvolvimento de ambientes diferentes, como suporte a criação de estruturas de documentos, suporte a edição semântica de especificações (criação e remoção de modelos e conceitos; alteração, transferência e fusão de conceitos, entre outros) e suporte a composição de ações de edição complexas através de ferramentas (por exemplo, a ferramenta de inserção de padrões de projeto em um artefato de software em desenvolvimento).

3.1 O Padrão MVC

O padrão Model-View-Controller (MVC) é uma estratégia de desenvolvimento de software, onde a aplicação é separada e analisada em três partes distintas: o modelo (model), a

visão (view) e o controlador (controller). O modelo corresponde à estrutura de armazenamento e tratamento dos dados específicos da aplicação. A visão é a representação visual destes dados. O controlador tem a responsabilidade de gerenciar os dispositivos de entrada de dados, recebendo os eventos da entrada e traduzindo em serviços para o modelo ou para a visão. A arquitetura MVC é amplamente utilizada em sistemas que utilizam interfaces gráficas.

Uma das características principais e a que se apresenta como a mais importante do padrão MVC é a separação da estrutura da informação (dados) de sua representação visual. Isto permite que se possa apresentar visualmente de diversas formas (visão) diferentes um mesmo conjunto de dados (modelo).

O Modelo representa uma entidade ou abstração que parte diretamente do domínio da aplicação ou da sua implementação. Este modelo não deve conter informações externas a ele próprio, como uma representação gráfica específica que será exibida, por exemplo. As definições de como serão exibidas as representações visuais são encontradas nas classes views. É permitido que um modelo tenha mais de um tipo de visualização. Cada modelo criado onde seja necessária uma representação gráfica deverá ter associada uma visão específica. Sempre que o modelo sofrer alterações, sua visualização deve ser também alterada, refletindo a mudança.

A separação entre o modelo e a visão acarreta em uma maior flexibilidade do sistema (ao se modificar a apresentação visual não é necessário alterar a estrutura de um elemento), além de estimular o reuso, pelo fato das partes constituintes do sistema estarem claramente separadas, podendo elas ser reusadas de maneira conjunta ou separada, nos contextos mais distintos. A separação do tratamento da entrada de dados por parte do usuário (controlador) também fornece flexibilidade a esta parte do sistema sem que sejam afetadas as demais partes.

A estrutura dos documentos definida através do framework OCEAN se baseia no padrão MVC. Assim documentos possuem a definição de sua estrutura em separado de sua apresentação visual. O modelo é representado pelas especificações e elementos de especificações. O framework gráfico JHotDraw, analisado mais detalhadamente no próximo capítulo, também segue o padrão MVC. O objetivo principal deste trabalho foi fazer com que o JHotDraw pudesse ser usado para gerar as visões dos elementos conceituais tratados no OCEAN, bem como desempenhar o papel do controlador.

É interessante destacar que na arquitetura do OCEAN, o modelo não cria diretamente a sua visão correspondente, e sim, a visão associada àquele modelo pergunta ao mesmo se ela pode

ser criada. Quem dá o sinal verde ou não para a criação da visão é o modelo. No exemplo mais específico de um diagrama de classes desenvolvido no ambiente SEA, com a ferramenta de criação da figura de classe ativada na barra de ferramentas, quando se clica com o mouse na área de desenho do editor esta ação é o editor tenta criar a figura a ser exibida juntamente com o seu modelo associado, mas o framework OCEAN (as classes do modelo) é que são consultadas e permitem ou não a concretização da operação com sucesso.

3.2 Estrutura Básica

É interessante ressaltar as partes da estrutura do framework OCEAN que lhe conferem flexibilidade para suportar o desenvolvimento de ambientes diferentes. O framework OCEAN apresenta um conjunto de superclasses abstratas que definem a estrutura das especificações que podem ser manipuladas por ambientes desenvolvidos sob este framework (Figura 3.1). Tal estrutura de classes suporta a criação de estruturas de especificação distintas, através da definição de subclasses concretas. Uma especificação (uma instância de subclasse de Specification) agrega elementos de especificação (instâncias de subclasses de ConceptualModel e Concept), podendo estes ser conceitos ou modelos. Uma especificação registra associações de sustentação e referência entre pares de elementos de especificação, isto é, um elemento de especificação pode estar associado a outros elementos de especificação.

Na estrutura de documentos sob o framework OCEAN foram definidas classes de projeto para organizar as associações entre uma instância de especificação e as instâncias de elementos de especificações que compõem esta especificação, que são SpecificationElementHolder e RelationshipTable. Quando uma instância de especificação é criada, é criado um conjunto de instâncias de SpecificationElementHolder para o repositório de modelos e um outro conjunto para o repositório de conceitos.

Para que seja desenvolvida uma estrutura de especificação deve ser definido um conjunto de tipos de modelos (que serão subclasses concretas de ConceptualModel), um conjunto de tipos de conceitos (que serão subclasses concretas de Concept) e uma rede de associações entre os elementos pertencentes a estes conjuntos. A estrutura de um tipo de modelo é definida com base nos tipos de conceito que o modelo referencia.

O ambiente SEA foi desenvolvido como uma extensão da estrutura de classes do framework OCEAN e tem como objetivo o desenvolvimento e uso de artefatos de software que possam ser reutilizáveis. Este ambiente provê suporte ao desenvolvimento de software, possibilitando a utilização integrada das abordagens de desenvolvimento orientado a componentes e baseado em frameworks, incluindo a utilização de padrões de projeto, seguindo o paradigma de orientação a objetos. O desenvolvimento de aplicações, frameworks e componentes no ambiente SEA consiste em construir a especificação de projeto dos artefatos (através de UML) e converter tal especificação em código, de maneira automatizada.

Como os documentos sob o OCEAN seguem o padrão MVC, todo o processo de construção e modificação de especificações do ambiente SEA ocorre sobre a estrutura conceitual das especificações (correspondente ao modelo), e se refletem em sua apresentação visual (correspondente à visão). Com base neste princípio, o ambiente provê algumas funcionalidades de edição semântica, como a cópia de elementos em uma área de transferência e a posterior colagem destes elementos em uma parte diferente da mesma ou de outra especificação. O ambiente suporta ainda alteração simultânea de especificações distintas.

Uma especificação OO do ambiente SEA, por exemplo, utiliza diagrama de classes (um tipo de modelo), que referencia classes, mas não pode referenciar estados (isto é, instancias deste tipo de conceito). Um conceito designa as unidades de informação do domínio de modelagem tratado. No caso da modelagem OO, exemplos de tipos de conceitos são classe, atributo, método,

etc. Para cada tipo de conceito tratado, existe uma subclasse concreta de Concept correspondente. Os diferentes modelos referenciam instâncias destas classes.

Um modelo de uma especificação, como um diagrama de classes, por exemplo, possui uma estrutura de informações (as classes, os atributos, os métodos, etc.) e uma ou mais representações visuais para esta estrutura (representação gráfica, textual, etc.). A expressão modelo conceitual e a expressão modelo se referem à estrutura de informações. No ambiente SEA existe uma subclasse concreta de ConceptualModel associada a cada tipo de modelo. Um modelo de uma especificação é uma instância de uma dessas subclasses.

Cada modelo possui um editor gráfico associado, que contém a representação visual do modelo em questão. Um modelo agrega uma instância de subclasse de SpecificationDrawing, que agrega instâncias de Figures (subclasses de CompositeFigure, LineFigure, TextFigure, etc., todas classes do framework JHotDraw), cada instância associada a um conceito (que corresponde à representação visual de um conceito no diagrama gráfico associado ao modelo). Cada Figure implementa a interface ConceptualFigure devendo declarar os métodos para definir e retornar o conceito associado à figura, bem como o método redraw, para redesenhar a figura quando ocorrem mudanças.

A criação de um conceito durante a edição de um modelo (por exemplo, a criação de uma classe durante a edição de um diagrama de classes) ocorre pela ação de uma ferramenta do editor gráfico do modelo. O método de criação de conceito da classe ConceptualModel é invocado na atuação das ferramentas de criação de conceitos do editor gráfico. A invocação de criação do conceito é repassada para a especificação.

O conceito que é retornado pela criação do conceito através da especificação é submetido a um teste de duplicidade em relação ao conjunto de conceitos de mesmo tipo que são referenciados pelo modelo, antes de ser incluído no conjunto de conceitos referenciados. Caso este processo não apresente falha, após a criação do conceito é criada a figura associada ao mesmo e esta é incluída no diagrama gráfico do modelo que está sendo editado.

4 O Framework JHotDraw

A utilização de frameworks por parte de programadores Java é algo freqüente, mesmo que estes não entendam totalmente os artefatos utilizados. O framework JFC Swing é um conjunto de classes que Java fornece para o desenvolvimento de interfaces gráficas com o usuário. Ele pode ser usado para a criação dos elementos gráficos em muitas aplicações, mas não fornece uma estrutura consistente que permita associar semântica aos elementos gráficos.

Um framework mais específico relacionado a este contexto é o JHotDraw, o qual objetiva aplicações para desenho técnico e gráfico estruturado, além de layouts de trabalho na internet – isto é, é voltado para o desenvolvimento de editores gráficos bidimensionais com semântica associada aos elementos gráficos. JHotDraw é a versão produzida por Thomas Eggenschwiler e Erich Gamma para Java do framework HotDraw, que foi desenvolvido em SmallTalk por Kent Beck e Ward Cunningham.

O framework JHotDraw oferece suporte mais agradável para desenvolver editores gráficos para aplicações que necessitem deste tipo de recurso. Ele demonstra o poder dos frameworks e sua usabilidade no seu domínio de aplicação.

4.1 Características

Em contraste com o JFC Swing, o JHotDraw define um esqueleto básico para um editor baseado em GUI com ferramentas dentro da paleta de ferramentas, diferentes visões, figuras gráficas definidas pelo usuário, e suporte para salvar, ler, e imprimir desenhos. O framework pode ser adaptado usando herança e combinando componentes.

Atrás da janela de desenho principal, JHotDraw oferece sustentação para os diferentes tipos de janelas, tais como editores de texto. Com algum conhecimento da estrutura de JHotDraw, você pode estender o framework para incluir alguma funcionalidade faltante.

JHotDraw foi um dos primeiros projetos de desenvolvimento de software projetado explicitamente para o reuso e para classificar um framework. Ele é um framework do tipo caixa-cinza, e é fortemente baseado em padrões de projeto. Suporta características do JFC Swing como janelas com diversos frames internos, painéis (panes) divididos, barra de rolagens, barra de ferramentas, e menus pop-up.

O núcleo do JHotDraw é todo definido através de interfaces. Para se compreender e desenvolver uma aplicação com o JHotDraw, basicamente se faz necessário atentar para as seguintes estruturas (Figura 4.1):

- A hierarquia de Figure.

- As interfaces Drawing e DrawingView. - A interface DrawingEditor.

- A utilização de Tools.

Figura 4.1 – Estrutura básica de classes e interfaces do framework JHotDraw

4.2 Estrutura

Todas as classes e interfaces do JHotDraw são organizadas em pacotes, de acordo com suas funcionalidades. Se o objetivo do usuário do framework for desenvolver uma aplicação específica própria, ele deve usar uma janela dedicada para o desenho, a janela de edição (DrawWindow), que é subclasse de javax.swing.JFrame. Esta janela contém uma ou mais frames

internos, cada um associado com uma visão de desenho (DrawingView). Esta visão é uma subclasse de javax.swing.JPanel, e representa uma área onde pode ser exibido um desenho que representa visualmente um modelo (Drawing), e aceita entradas do usuário (DrawingEditor).

Mudanças ocorridas no desenho são propagadas para a visão que tem a responsabilidade de atualizar todos os gráficos. O desenho consiste de figuras (Figure), que sabem desenhar a si próprias e podem ser containeres para outras figuras. Cada figura possui Handles, os quais definem pontos de acesso e determinam como interagir com a figura. Geralmente a janela de desenho possui uma ferramenta (Tool) ativa na paleta de ferramentas, a qual opera em um desenho associado com a visão de desenho atual (Figura 4.2).

JHotDraw fornece a idéia de Constraints que permitem definir restrições de comportamento a uma figura. Como exemplo, em uma figura de conexão, LineConnection, podem ser definidas restrições para esta figura, tais como a figura que ela origina e a sua figura de destino. Cabe citar que JHotDraw fornece ainda as interfaces DrawingChangeListener e FigureChangeListener. Os objetos que as implementam são responsáveis pelo monitoramento de mudanças nos drawings e nas figures, respectivamente.

Figura 4.2 – Estrutura de classes e interfaces básicas do JHotDraw

4.3 Processo de Desenvolvimento

Primeiramente, JHotDraw permite que o usuário (do framework) crie suas próprias figuras gráficas e símbolos para suas aplicações. Pode-se refinar o comportamento das figuras predefinidas (como AbstractFigure, CompositeFigure e AttributeFigure) através da criação de subclasses a partir delas e da sobrescrição de alguns métodos, como draw( ). Porém a criação de subclasses irá aumentar o número total de classes no sistema, e deve-se ter o cuidado de manter a estrutura da hierarquia de herança.

Posteriormente, o usuário desenvolve suas próprias ferramentas para criar figuras e manipulá-las de acordo com os requisitos da aplicação. São pontos de partida para esta característica, por exemplo, CreationTool, ConnectionTool, TextTool, entre outros.

Após isso, há a criação da atual GUI e a sua integração com a nova aplicação. JHotDraw já inclui um esqueleto básico de aplicação (por exemplo, DrawApplication, ou ainda MDI_ DrawApplication que suporta vários frames internos). Pode-se ainda, incluir menus (createMenus( ), por exemplo) na aplicação desenvolvida. Uma GUI completa é criada no momento em que a aplicação é instanciada, em tempo de execução, e há uma chamada ao método open( ). Caso a intenção do usuário de JHotDraw seja criar uma aplicação embutida em outra, ou desenvolver uma estrutura de classes que não necessite ser uma aplicação diretamente, a maneira de se inicializar tais estruturas será diferente, devendo ser analisado cada ambiente específico.

4.4 Padrões de Projeto do JHotDraw

Como já mencionado em capítulos anteriores, o framework JHotDraw está baseado no paradigma MVC, que separa a lógica da aplicação do usuário da dependência de interface. A visão (V) é geralmente responsável por mostrar a informação na interface do usuário; o controlador (C) assegura a interação do usuário com a funcionalidade da aplicação. O modelo (M) se situa atrás da visão e do controlador e consiste na lógica da aplicação e dados. A visão é notificada das mudanças nos dados.

O modelo do JHotDraw é representado pela interface Drawing. Ela é um container de Figures (representação visual de um modelo), é a abstração das figuras que compõem a visão. A visão é concebida através da interface DrawingView. Ela exibe a representação gráfica do Drawing, isto é, desenha as figuras propriamente ditas. A interface DrawingEditor representa o controlador que controla as ferramentas e as atualizações necessárias ocorridas com relação ao seu conteúdo exibido.

Geralmente, devem ser fornecidos um modelo próprio de objetos e adicionadas figuras para representar graficamente estes objetos. O JHotDraw se torna uma visão, e em parte também um controlador, oferecendo ferramentas para gerenciar as interações do usuário e manipular objetos gráficos. Por sua vez, as mudanças em um objeto gráfico devem ser refletidas no modelo do objeto. É possível se desenvolver as ferramentas que contêm a lógica da aplicação e negociar com o modelo do objeto diretamente.

São identificados oito padrões de projeto compondo a estrutura do JHotDraw. Na seqüência eles serão detalhados. O diagrama de modelo inicialmente desenvolvido na integração

entre OCEAN e JHotDraw foi o diagrama de classes, por ser o mais difundido e intuitivo. Com isso, os exemplos utilizados para comentar os padrões de projeto do JHotDraw serão baseados na estrutura do diagrama de classes.

Cabe ressaltar que os padrões descrevem a estrutura do framework, em forma hierárquica, possibilitando o entendimento de cada uma de suas abstrações de maneira fragmentada. Mas este aspecto se reflete em um agravante no momento em que a aplicação apresenta um grande número de padrões, dificultando ao desenvolvedor a formulação de uma visão de conjunto da aplicação. Além disso, convém mencionar que a falta de uma documentação mais detalhada sobre o JHotDraw também foi um fator que dificultou o entendimento maior e de maneira mais rápida do framework.

4.4.1 O Padrão Observer

O padrão Observer é usado para manter dependência de estado entre objetos sem que estes necessitem de um acoplamento direto. Quando alguma mudança num objeto observado ocorre, estes comunicam os seus observadores de que a alteração ocorreu, seguindo um único e simples protocolo de notificação de alterações. Este padrão é usado para desacoplar um drawing das suas visões e para habilitar múltiplas visões.

4.4.2 O Padrão Decorator

O padrão Decorator permite a definição da existência de objetos de decoração em outros objetos. Estes são distintos, mas para quem interage com eles parece que são um único objeto. No exemplo do diagrama de classes, ao se mover uma figura de associação com decorações de cardinalidade na área de desenho de um editor, as decorações são movidas juntamente com a figura.

4.4.3 O Padrão Composite

Um dos principais padrões de projeto encontrados no JHotDraw é o composite. A idéia por atrás deste padrão é que um container consiste em diversos componentes do mesmo tipo

básico, mas é tratado como um único componente. Todo o comportamento no formulário de chamadas de método é delegado do container para suas partes. Tipicamente, um componente cliente é inconsciente e acaba usando uma composição dos elementos em vez de um único componente. Esta técnica de encapsulamento permite a construção de um composite, como o CompositeFigure, com uma estrutura hierárquica dos componentes em que todos os componentes agem e reagem como uma unidade, facilitando o seu tratamento. Como exemplo, tem-se StandardDrawing. Ela é uma subclasse de CompositeFigure, que consiste no desenho de outras figuras, mas ela mesma é uma figura (Figura 4.3).

Normalmente os CompositeFigures não tem nenhuma representação visual no seu domínio, mas simplesmente apontam para as figuras de seus filhos. Contudo, uma representação visual de uma classe deve avaliar sua apresentação visual total e adicionar sua própria exposição gráfica do container. Um GraphicalCompositeFigure é um CompositeFigure que delega também sua representação visual para dedicadas figuras gráficas. Se um AttributeFigure (ou uma subclasse) forem usados como figuras gráficas, então o GraphicalCompositeFigure pode também armazenar atributos assim como a informação das cores e da fonte.

Para a criação da figura de classe, por exemplo, só foi preciso herdar todo o comportamento fornecido de GraphicalCompositeFigure e conter um TextFigure para o nome da classe, e uma figura para cada atributo e método.

Mas a composição não fornece liberdade para a criação de subclasses de classes pré-existentes na estrutura do framework. Somente o que está disponível pode ser composto. Além disso, por causa da natureza dinâmica do padrão, pode ser difícil a ação de debugar uma aplicação desenvolvida.

Figura 4.3 – Estrutura de classes com o Padrão Composite

4.4.4 O Padrão Strategy

A figura gráfica para representar uma figura de classe só é responsável por desenhar a figura. Ela não sabe como o ClassFigure deve ser externado ou como seus sub-componentes devem ser arranjados graficamente. De fato, a representação gráfica é independente do algoritmo de disposição. Conseqüentemente, o algoritmo de disposição é separado do ClassFigure e encapsulado em um componente externo, o qual examina o controle e tem acesso em larga escala a seu componente anfitrião. Se um ClassFigure tiver que ser externado, ele delega esta tarefa a um FigureLayoutStrategy, que contem a lógica de andamento de todos os elementos filhos de ClassFigure e arranja aqueles elementos (Figura 4.4). Este mecanismo é similar ao java.awt.LayoutManager para arranjar o conteúdo de um java.awt.Window, e esta separação entre algoritmo e o contexto foi descrita em um padrão de projeto denominado Strategy

(estratégia). O Strategy dá a flexibilidade de trocar dinamicamente o comportamento em tempo de execução e aumentar a reusabilidade do algoritmo.

Figura 4.4 – Estrutura de classes com o Padrão Strategy

4.4.5 O Padrão State

JHotDraw fornece diversas ferramentas na paleta de ferramentas, que podem ser usadas para selecionar, manipular, ou criar uma figura. Às vezes é necessário conceber uma outra opção definindo sua própria ferramenta. Um ClassFigure contem diversas outras TextFigures para o nome, os atributos, e os métodos da classe. Caso seja necessário editar alguma das TextFigures, será preciso utilizar o CustomSelectionTool. Isto porque a ferramenta de seleção (SelectionTool) ativa apenas o container selecionado, não tratando de nenhum dos TextFigures contidos nele. O CustomSelectionTool cumpre essa finalidade e trata também dos menus pop-up em figuras. A ferramenta de seleção é derivada dele e sobrescreve os métodos handleMouseDoubleClick( ) e de handleMouseClick( ). Após isso, caso ocorra um duplo clique, essa ferramenta ativa uma TextTool, que é responsável pela edição de texto.

De maneira ideal, as visões (DrawingView) devem ser independentes da ferramenta ativa, assim mesmo havendo troca nas ferramentas, e as expressões se tornando, ou não, complicadas

não será necessário distinguir entre elas. Com o padrão de projeto State, você separa o estado de seu contexto fazendo destes estados seus próprios objetos com interfaces definidas que o contexto pode usar. Dessa forma, a introdução do DelegationSelectionTool é justamente um outro estado para a visão como um contexto. A visão aceita a entrada do usuário como usual, mas delega-a para uma ferramenta. A ferramenta sabe o que fazer com a entrada do usuário e executa sua tarefa conseqüentemente (Figura 4.5).

O padrão de projeto State é similar ao padrão Strategy já que ambos delegam o comportamento aos objetos especializados, mas têm finalidades diferentes. O Strategy separa um objeto de um algoritmo e faz o algoritmo reusável; O State separa e extrai o comportamento interno tornando-o facilmente extensível e permutável.

Figura 4.5 – Estrutura de classes com o Padrão State

Classes devem ser mostradas em um diagrama, que deve conter também os relacionamentos entre aquelas classes. Uma figura de AssociationLineConnection representa uma associação linear entre duas classes, e pode ser mudada em uma associação direcional ou em uma agregação. Uma figura InheritanceLineConnection representa um relacionamento de herança com uma seta que inicia na subclasse e aponta para a superclasse. Um LineConnection fornece os métodos connectEnd( ) e o disconnectEnd( ) como métodos Template (Figura 4.6).

Um método Template é um outro padrão de projeto e define uma seqüência de comando, que deve sempre ser executada. Dentro dessa seqüência do comando, outros métodos são chamados em determinados momentos. As subclasses podem então enganchar (hook) instruções adicionais específicas da aplicação sem mudar o comportamento geral.

Um exemplo de um método Template pode ser encontrado em AttributeFigure, onde o método draw( ) define uma rotina de desenho e chama o método drawBackground( ) e o drawFrame( ), que foram sobrescritos nas suas subclasses, tais como RectangleFigure.

4.4.7 O Método Fábrica (Factory)

Este padrão de projeto é usado com freqüência no JHotDraw, especialmente ao criar componentes customizados de interface com o usuário como menus e ferramentas. Muitos métodos Factory podem ser encontrados em DrawApplication, como createTools( ) e createMenus( ), que por sua vez chamam createFileMenu( ), createEditMenu( ), e assim por diante. Dependendo da granularidade da customização, podem ser acrescidas mudanças dentro do método apropriado de criação. Para fornecer a ferramentas de criação de classes e das relações de associações e herança entre elas, foi necessário sobrescrever o método createTools( ) no editor específico do diagrama de classes.

4.4.8 O padrão Protótipo (Prototype)

No método createTools( ) cada ferramenta está inicializada com um exemplo da figura que se pretende criar. Cada ferramenta de criação no JHotDraw usa a figura original como exemplo para criar instâncias duplicadas. Este conceito é conhecido como o padrão de projeto protótipo. O mecanismo básico do método clone( ) é definido em AbstractFigure, onde uma cópia da instância é criada usando a serialização fornecida por Java.

A serialização é uma maneira fácil para escrever uma árvore inteira do objeto e lê-la mais tarde. Uma cópia profunda da figura original é criada também, e contém duplicatas de todos os objetos referenciados. Assim, a figura original e sua cópia não compartilham nenhuma referência de objeto. Por exemplo, uma ClassFigure não serializa os menus associados ao contexto. Estes devem ser inicializados durante a des-serialização.

Além disso, leitura e escrita de desenhos com suas figuras gráficas contidas também podem simplesmente usar o mecanismo de serialização. JHotDraw tem também seu próprio mecanismo para armazenar objetos no disco e restaurá-los. Cada figura implementa a interface Storable e fornece sua própria implementação de como se escrever no disco e ler novamente dele. A informação escrita contém o nome da classe e os valores de todos os atributos como Strings. Obviamente, a ordem em que os valores dos atributos são escritos e lidos é de suma importância. Com o nome da classe, o JHotDraw cria uma nova instância de Drawing usando o mecanismo da

reflexão de Java. Neste caso, o construtor default é chamado com uma lista vazia como parâmetro.

4.5 Aplicação Desenvolvida a partir do JHotDraw

Com o intuito de verificar na prática as funcionalidades do framework JHotDraw, tendo como base um desenvolvimento sucinto, porém interessante, foi projetado um diagrama de fluxo de dados, como uma aplicação básica. Primeiramente, será apresentada uma breve descrição sobre DFDs.

4.5.1 DFD

O Diagrama de Fluxo de Dados é um modelo funcional de representação do fluxo que os dados seguem numa determinada aplicação ou sistema. Nele são descritos de forma textual o que cada função faz. Permite imaginar um sistema como uma rede de processos funcionais que são interligados por "dutos" (Setas) e "tanques de armazenamento" de dados (Bolhas).

Cada fluxo pode ser considerado como um cano por onde passam pacotes de dados. Referenciamos o cano de fluxo de dados identificando os processos, entidades, ou depósitos de dados das suas extremidades, mas anotando uma descrição do conteúdo de cada fluxo ao longo de sua extensão. A descrição escolhida deve ser a mais significativa possível para os usuários que vão fazer a revisão do diagrama de fluxo de dados (de acordo com o fato de ser uma descrição lógica).

No paradigma OO, sua utilização é questionável, haja vista que os processos não são relacionados a classes. Com isso, um mapeamento direto entre as funcionalidades e o esquema de classes não é conseguido. Este foi o motivo de não ter sido utilizado em UML (linguagem de modelagem unificada), que é a linguagem de especificação mais difundida entre os desenvolvedores OO atualmente.

4.5.2 Implementação

Com base no JHotDraw 5.3.1, foi desenvolvida uma pequena aplicação para a construção de um DFD. Cabe aqui ressaltar que esta tarefa, ainda que pareça trivial, foi de grande valia no processo de entendimento da estrutura do framework JHotDraw. Nesta etapa inicial do desenvolvimento, três classes foram declaradas: Bolha, BolhaFigure e DFDApplication.

A classe Bolha (Figura A-1) representa o modelo da bolha, isto é, o conceito do tanque de armazenamento de dados. Ela implementa a interface Java java.io.Serializable, para que possam ser salvos e recuperados os diagramas que forem confeccionados.

A classe BolhaFigure (Figura A-2) representa a figura relacionada ao modelo bolha. Ela é uma subclasse de GraphicalCompositeFigure. Cada BolhaFigure representa uma Bolha existente, e tendo-se a Bolha consegue-se saber qual a figura relacionada, mas partindo-se da BolhaFigure, também é possível se obter qual o conceito bolha relacionado (Figura 4.7).

A noção das setas do DFD não foi mapeada em uma classe, pelo motivo do JHotDraw fornecer previamente um tipo de figura que é uma seta. Como estas setas não apresentam grandes funcionalidades empregadas, não houve a necessidade da criação de uma classe para representar o seu conceito.

Por último, tem-se a classe DFDApplication (Figura A-3) que é responsável por mostrar a interface em que os elementos gráficos serão trabalhados. Ela herda de MDI_DrawApplication, e possui o método main. Ao ser executada a aplicação, é possível se criar bolhas (representadas graficamente por elipses) e interconectá-las através de setas. Ambas opções (seta e bolha) se encontram na paleta de ferramentas. Cada bolha é identificada por seu nome, e a seta, a princípio não apresenta identificação ou texto relacionado. (Figura 4.8).

Esta aplicação é rudimentar, mas com ela pode-se verificar na prática os passos para o desenvolvimento de uma aplicação básica a partir do framework JHotDraw, quais as classes que devem ser herdadas e quais métodos podem ser sobrescritos.

Esta atividade inicial serviu de base para o desafio foco que é o suporte aos editores gráficos de modelos no framework OCEAN, com base no JHotDraw e em suas classes.

5 Integração do JHotDraw na Estrutura Gráfica do OCEAN

A razão principal da escolha de utilizar o JHotDraw como sustentação para a estrutura gráfica do framework OCEAN, foi o fato já mencionado anteriormente de que ele é a versão em Java do framework HotDraw, que era o framework gráfico utilizado por OCEAN na versão SmallTalk. O intuito era que as alterações em OCEAN fossem as menores possíveis para viabilizar a mudança de um framework gráfico para outro. Como JHotDraw advém do HotDraw, muitas das idéias do framework antecessor se mantiveram na nova versão, mas também muitas alterações ocorreram, principalmente no que se refere às características particulares de cada linguagem.

5.1 Adaptações necessárias

Um dos primeiros obstáculos encontrados no desenvolvimento da estrutura suporte aos editores foi a necessidade de se definir a estratégia de exibição de cada editor, embutido em outra janela. Na estrutura de classes do framework OCEAN a classe AuxWindowAppModel foi concebida com o propósito de ser um recipiente para a exibição dos editores gráficos em janela única. Isto porque o ambiente VisualWorks 2.0, usado para gerar a primeira versão do framework OCEAN em Smalltalk, não tinha a possibilidade de gerar aplicações com múltiplas janelas de edição executando.

Ao se adotar a utilização do JHotDraw para dar suporte à estrutura gráfica em OCEAN, foi definido que esta idéia da AuxWindowAppModel seria mantida para que a obtenção de uma versão inicial funcional fosse facilitada. Com isso as subclasses desenvolvidas no framework OCEAN para dar suporte a editores gráficos de modelos, que usam diretamente as classes do JHotDraw, tiveram que ser adaptadas para que a exibição destes editores fosse feita embutido nesta janela alvo.

Por isso, não foi possível utilizar a estrutura básica e bem mais intuitiva da classe DrawApplication fornecida por JHotDraw, haja vista que esta se refere a uma aplicação única e independente, com o seu próprio Frame (que é uma janela com seu próprio título e borda). Para a necessidade de se exibir editores em frames internos, embutidos em um frame principal (no caso, a janela principal do ambiente SEA), foi seguido o padrão da utilização do Panel

AuxWindowAppModel que é colocado como conteúdo de um frame interno que faz parte da estrutura do OCEAN, o OceanInternalFrame.

Cada editor tem a sua window que é subclasse de uma janela auxiliar para editores e contém informações sobre o Drawing, o DrawingView e o DrawingEditor da especificação, é a EditorAuxWindow. Esta janela herda de AuxWindowAppModel, e é nela que o editor propriamente dito (com sua área de desenho) é embutido. A janela principal do ambiente SEA apresenta um recipiente denominado workspace, e é nele que o suporte a múltiplos frames internos é concebido, e o editor poderá ser o conteúdo de um frame (Figura 5.1).

Figura 5.1 – Estrutura de classes das janelas de exibição dos editores

Outra característica da integração do JHotDraw com OCEAN, que merece ser comentada, é o método redraw, que utiliza o padrão Observer. Ao se ocorrer uma mudança em alguma janela de um diagrama, ou mesmo em uma janela de edição específica de um modelo, todas as demais janelas são atualizadas com a alteração.

Quando uma figura é criada, ela mesma se registra como observadora do conceito associado a ela. No momento em que alguma alteração ocorre, os métodos de tratamento de uma ação da figura (como um duplo clique do mouse, por exemplo) realizam a ação específica daquele evento. Neste momento, as classes gráficas interagem com o núcleo do framework OCEAN, isto é, com as classes dos modelos envolvidos. O modelo recebe a requisição correspondente a determinada ação, e este faz o tratamento à sua maneira. Posteriormente, ele notifica as figuras, que estão observando mudanças nos conceitos, de que os mesmos sofreram alterações (criação ou atualização).

Para cada modelo OO suportado na atual versão Java do framework OCEAN, foram definidas e implementadas as classes necessárias à definição dos editores para os modelos. Entre eles podem ser destacados o ModeloDeObjetos (Diagrama de Classe), Cenario (Diagrama de Sequência), UseCaseDiagram (Diagrama de Casos de Uso), DTE (Diagrama de Transição de Estados), etc. Primeiramente o foco das atividades de trabalho foi direcionado ao ModeloDeObjetos, o Diagrama de Classes, por ser o mais intuitivo e utilizado nas modelagens OO.

Foram definidas cinco classes básicas que dão suporte aos editores gráficos de modelos no framework OCEAN: SpecificationDrawing, SpecificationDrawingView, SpecificationEditor. Cada novo editor de modelo deve possuir subclasses específicas das classes anteriormente mencionadas (para o exemplo do Diagrama de Classes, foram definidas as classes MObjDrawing, MObjDrawingView, MObjEditor).

As figuras também são de fundamental importância para a confecção de um editor gráfico de modelo. Cada editor terá quantas figuras específicas forem necessárias para representar os conceitos que o seu modelo correspondente suporta. Para o diagrama de Classes, foram criadas as figuras MObjClassFigure e MObjInheritanceLineFigure, para representar os conceitos de Classe e Herança, respectivamente. Elas herdam de SpecificationCompositeFigure e SpecificationLineFigure, respectivamente. Cada figura declara o método relatedConceptClass que retorna a classe conceito associado àquela figura (Figura 5.2).

Figura 5.2 – Estrutura de classes das Figures, como MObjClassFigure

A classe SpecificationEditor é subclasse de javax.swing.JPanel e implementa as interfaces DrawingEditor e PaletteListener. Esta classe representa o editor propriamente dito, gerenciando as visões dos conceitos que compõem o modelo, isto é, os diferentes objetos gráficos que participam do editor. Tem suporte a paleta de ferramentas, cujas ações podem criar, editar ou remover conceitos dos modelos (Figura 5.6).

A utilização da ferramenta de seleção foi adaptada para fornecer uma característica diferente daquela que o JHotDraw disponibiliza como padrão. Quando se deseja editar um modelo específico, como uma classe, por exemplo, não será a figura que será diretamente editada, e sim uma interface para edição do modelo. O método handleMouseDoubleClick da ferramenta foi sobrescrito, de tal forma que a visão pede para o framework OCEAN editar o modelo da figura selecionada, através de uma outra interface de edição. Como já mencionado anteriormente, uma mudança no modelo é refletida na visão, pois o modelo avisa as figuras que elas devem se atualizar (Figura 5.3).

Figura 5.3 – Atualização propagada em ambos visão e modelo

A classe SpecificationDrawingView é subclasse de StandardDrawingView (classe esta que implementa a interface DrawingView, que fornece métodos para desenhar as figuras e tratar as suas mudanças) (Figura 5.4). A classe SpecificationDrawing herda de StandardDrawing, que implementa a interface Drawing. Um Drawing é basicamente um recipiente de figuras (Figura 5.5).

Figura 5.4 – Estrutura de classes DrawingView

Cada SpecificationEditor que é criado recebe uma visão que ele deve mostrar (SpecificationDrawingView). Caso nenhuma visão tenha sido passada, são criadas a Drawing e a DrawingView iniciais através dos métodos createSpecificationDrawing e createDrawingViewObject. Estes métodos são abstratos, cabendo a cada editor específico (MObjEditor, por exemplo) definir o corpo de cada um para que seja criado o drawing e a visão do mesmo específica para o editor em questão (Figura 5.6).

Figura 5.6 – Estrutura de classes DrawingEditor

Outra característica incorporada ao editor se refere a figuras de ligação órfãs. Como ilustração, no editor do diagrama de classe, sempre que uma figura de classe é removida, as linhas de associações e herança que estejam ligadas a ela deixam também de existir. Isto foi conseguido com a sobrescrição do método orphan na classe SpecificationDrawing.

Após a definição das classes, foram realizados testes com os editores criados (inicialmente somente o Diagrama de Classes, pois este foi o que mais tempo consumiu, devido à aprendizagem necessária de utilização do JHotDraw e de suas estruturas). O Diagrama de Classes funcionou normalmente, podendo ser acrescentadas classes com atributos e métodos, bem como relações entre classes (herança, agregação, dependência, etc.) (Figura 5.7).

Figura 5.7 – Editor de Diagrama de Classes

5.2 Roteiro de Criação de Editores

O desenvolvimento e a utilização de frameworks são tarefas complexas e, por isso, uma boa documentação é imprescindível. Tal documentação deve conter informações sobre o domínio tratado pelo framework, sua estrutura e seu funcionamento. A notação UML de um framework é uma valiosa fonte de informação sobre o mesmo. Existe ainda a forma de documentação mais elementar, que é a disponibilização do código fonte aos usuários.

Uma outra maneira de documentar um framework é a que ensina a usá-lo para gerar aplicações específicas. Esse tipo de documentação não tem o intuito de esclarecer aspectos de projeto, e sim descrever o processo de criação de aplicações sob o framework. Um exemplo desse tipo de documentação é o cookbook.