|
|
 |
| Tecnologias :: Visual FoxPro |
 |
|
| |
|
| Modelagem de Objetos Visual FoxPro: Visual UML |
Por José Luis Santana Blasco, artigo originalmente publicado na revista UTMag/RapoZine. |
Por que uma ferramenta de modelagem de objetos?
Com a chegada da programação orientada à objetos na versão 3.0 do Visual FoxPro, muitas das técnicas que empregavamoas para desenvolver nossas aplicações tornáram-se completamente obsoletas. No princípio, era difícil saber qual era o método mais confiável, ou qual o objeto mais adequado, para escrever nosso código funcional nos objetos que o VFP nos proporcionava. com o tempo, empenhamos em aprender que a verdadeira potência da OOP não está nos objetos visuais, e sim nos objetos não visuais, que são os que realmente movem nossas aplicações. Quando superamos esta fase, chegamoa na fase em que empenhamos em programar as regras de nosso negócio dentro dos chamados objetos de negócio. Nossas aplicações começam a funcionar comu uma grande caixa de diálogo entre objetos em diferentes designs . Quando chegamos a esta situação, ou empregamos uma ferramenta que nos ajude a ter todos os nossos objetos de baixo nível, ou nosso projeto terá grandes possibilidades de ser um de muitos projetos orientados à objetos que não chegam ao final de seu desenvolvimento, ou chegam com uma estranha combinação de programação funcional e orientada à objetos de manutenção impossível.
Uma vez que temos cheado a este ponto nós deparamos com duas perguntas:
Qual metodologia empregar?
Que tipo de aplicação podemos empregar esta metodologia?
A primeira pergunda é cada vez mais fácil de responder. A linguagem Unificada de Modelagem, ou UML como é mais conhecida, que se converteu em um padrão da indústria desde que as principais metodologias de modelagem de objetos foram integradas nesta linguagem graças ao trabalho de Rumbaugh, Boock e Jacobson, e graças ao interesse da empresa Rational Software Corporation. Esta linguagem permite definir todos os aspectos e fases do desenvolvimento do software, desde as fases iniciais de análise até as fases finais de implementação, tudo isto de forma precisa, completa, detalhada, e com total independência das ferramentas de software que se vá empregar em sua programação.
A segunda pergunta é um pouco mais complicada de responder, em especial se nosso foco não se centraliza exclusivamente no desenvolviemento em VFP. Devido a grande difusão que está alcançando a UML, existem no mercado uma grande quantidade de produtos que permitem realizar os diagramas e artefatos que requerem UML, e em muitos casos, permitem também realizar a geração de código fonte das classes modeladas, ou realizar a leitura dos arquivos de definição de classes de uma determinada linguagem, e criar os diagramas UML destas classes. Este último é conhecido como engenharia reversa.
Se nos centralizarmos em ferramentas que sejam capazes de gerar código VFP, ou que possam ler os arquivos de definição de classes do VFP, o número de aplicações se reduzem bastante, caindo este número à duas aplicações: MS Visual Modeler e Visual UML.
MS Visual Modeler é uma aplicação que faz parte do pacote MS Visual Studio 6.0 Enterprise. É uma versão muito reduzida do excelente produto Rational Rose, porém cumpre sua função se nosso interesse se concentra unicamente na documentação de nossas classes, em uma modelagem simples. Uma das atualizações do Visual Studio incorporou um assistente para ser utilizado desde que tenha o Visual FoxPro. Visto que não vem com a versão 7.0. e visto que a MS está potencializando como ferramenta de modelagem o produto MS Visio, não comentaremos mais sobre este produto no artigo.
Conforme dito no parágrafo anterior, o Visual UML sobra como única alternativa possível em ser a nossa ferramenta de desenho que pedimos que seja capaz de gerar e ler código VFP. A opção de gerar código nos irá permitir, em fases avançadas de nosso design, criar a estrutura das bibliotecas de classes VFP que tinhamos definido no modelo. Enquanto que a opção de ler as bibliotecas de classes do VFP nos permitirá atualizar nosso modelo com as modificações introduzidas no VFP, ou criar um novo modelo de classes já existentes para, por exemplo, realizar um processo de reprodução.
O que o Visual UML nos oferece?
O Visual UML nos oferece a possibilidade de criar tudo e cada um dos artefatos e diagramas que se definir na especificação da UML 1.3, mantendo todos os componentes amarrados por meio de um repositório, o que pode auxiliar para redefinir qualquer aspecto do modelo, visualizando imediatamente todos os objetos afetados do modelo que tenham relação com nossa mudança.
Nos oferece também um grande número de possibilidades de exportação da informação gerada, podendo portar nossos diagramas aos formatos gráficos mais conhecidos, publicação em HTML, e inclui exportação para XML.
A importação, é bem mais limitada à princípio que a exportação, nos permite trazer dados de outros diagramas gerados com o Visual UML, e do padrão de definição XML, empregando este método como um sistema de importação de outras aplicações de modelagem. De todas as formas, se fecha pela falta de possibilidades de importação de modelos de arquivos nativos de outras ferramentas de modelagem tão comuns como Rational Rose ou ambas.
Nosso interesse por esta ferramenta se foca em suas capacidades de gerar e ler definições de classes no VFP. Visual UML, sem dúvidas, não está orientada unicamente ao mundo Fox, como boa ferramenta de modelagem, é completamente independente de linguagem de programação que iremos empregar na fase de desenvolvimento.
Mesmo com esta independência, Visual UML permite indicar a linguagem que se empregará no desenvolvimento, o que nos permitirá a definição de todas aquelas particularidades que tenha a linguagem eleita, como podem ser os tipos de dados, classes base disponíveis, formas de definição das propriedades e métodos das classes, etc.
O números de linguagens disponíveis supera na versão atual os 20, encontrando-se entre elas o recente C#. Vale destacar, que a definição da linguagem se realiza no nível do modelo, e não no nível de classe ou componente.
No futura, seria bom que o pessoal do Visual UML mudasse essa característica, para acomodar melhor a ferramenta ao futuro acerca da programação, em que o programador escolhe qual linguagem de programação mais adequada para cada componente, conforme a filosofia do Visual Studio .NET. De qualquer maneira, temos diferentes soluções neste aspecto, que inicialmente somente serão visívelmente afetados os desenhos mais avançados.
Um aspecto de destaque neste produto é o suporte que se dá, tanto no Visual Modeler, a responsável pelo produto Visual UML, é EPS Software, responsável pelos módulos específicos do Visual FoxPro. AS consultas realizadas são respondidas com prontidão e de forma muito profissional, sejam as duvidas técnicas ou erros detectados na aplicação. Nestas últimas, em geral, existe um tempo muito pequeno desde que se detectca e se comunicam ao suporte até que saia a atualização para resolve-las, e estas atualizações é comum incorporar além da solução de problemas até novas melhorias no produto.
Por último cabe destacar de forma muito positiva as amplas possibilidades de expansão e personalização como as que foram adotadas no produto, e permitem ao usuário personalizar a aplicação conforme suas necessidades. Essas possibilidades podemos dividi-las em dois grupos: extensão de opções e programação do produto.
O primeiro grupo se refere as possibilidades que tem o Visual UML de incorporar ao mecanismo de extensão do UML 1.3: os esteriótipos. Essas possibilidades de extensão se implementa mediante a possibilidade de incorporar nossos próprios esteriótipos em suas listas destacáveis oferecidas pelo Visual UML.
O segundo grupo faz referencia as possibilidades que tem a ferramenta de ser programada por meio de Jscript, VBScript e VBA. O Visual UML orerece uma completa hierárquia de objetos que permitem a extensão sem limites da ferramenta empregando estas linguagens de programação.
Devemos levar em conta que nem todas as possibilidades expostas até este ponto estão disponíveis em todas as versões do Visual UML, sendo as citadas as que se encontram na versão Visual UML 2.9 Plus for Visual FoxPro.
Como se trabalha com o Visual UML?
A primeira coisa que devemos fazer ao iniciar a aplicação é criar um novo modelo. Um modelo em Visual UML é algo semelhante aos projetos de Visual FoxPro, agrupa todos os componentes que criamos, porém com uma grande diferença, o arquivo .uml armazenará dentro todos e cada um dos artefatos e diagramas quer criamos.
Antes de criar o aquivo do modelo, o Visual UML também nos soliciára um dado adicional : Qual ferramentas iremos empregar para gerar o código?.
Esta pergunta não nos deve preucupar neste momento, pois pelo que comprovei não nos condiciona na modelagem inicial, e podemos trocar a resposta quando necessitarmos (nas fases finais de desenho), inclusive podemos mudar nossas respostas quantas vezes desejarmos ao longo da criação do modelo, o que nos permitirá a definição das características particulares de cada linguagem em todas nossas classes, no caso de trabalharmos com várias linguagens.
Uma vez criado o modelo em branco, o Visual UML nos oferece uma TreeView com todos os possíveis artefatos e diagramas que o programa pode realizar.
O Visual UML nãos nos dirige em momento nenhum na criação dos diagramas e dos artefatos, seremos nos quem iremos criar cada diagrama segundo nossas necessidades de modelagem. Quando criamos artefatos, e seja de forma independente ou a medida da necessidade para a realização de nossos diagramas, o sistema nos oferecerá esses artefatos em qualquer diagrama que se possa empregar, atuando a aplicação comu um completo reposítório que vai amarrando cada peça que introduzirmos no modelo.
Esta flexibilidade oferecida na criação do modelo, nos permite realizar protótipos de forma muito rápida, seguindo unicamente as especificações básicas da UML que nós necessitarmos, para posteriormente, quando o modelo está construído está definico, realizamos um refinamento de todos os artefatos e diagramas, para incluir toda a informação que necessita a ferramenta para gerar corretamente as classes que desenhamos e na linguagem que escolhemos.
UML é muito extensa, e o pessoal do Visual Object Modelers tenham pretendido que seu produto permita modelar até o último detalhe da linguagem. Para eles, atrás de todos os artefatos e diagramas que podemos fazer com o aplicativo, "esconde-se" uma infinidade de janelas de diálogo aninhadas, centenas de pageframes, unidas a estas por sua vez uma grande quantidade de caixas de verificação, grids, e combos, todos eles buscando permitir ao usuário descrever com precisão o que oferece o UML 1.3 os artefatos que intervêem em um modelo.
Com isto não quero dizer que o Visual UML seja uma aplicação difícil de aprender, porém dado que é uma ferramenta muito extensa em opções e muito configurável, é necessário dedicar-lhe muito tempo para tirar toda vantagem possível de suas múltiplas opções.
A geração de código VFP
Uma vez que produzimos o modelos e temos definidas as classes que queremos incorporar em nosso sistema, é o momento de empregar o módulo de geração de código para que este nos crie as bibliotecas e as classes que desenhamos.
Tanto o gerador de código, bem como, o módulo de engenharia reversa são na realidade aplicações de VFP desenvolvidas por uma empresa bem conhecida dentro do mundo Fox: EPS Software Corp..
O processo de geração de código seque o modelo dos assistentes que traz o VFP, o que resulta na extrema facilidade de aprendizado. Os passos para criar as classes á partir de nosso modelo são os sequintes:
1. Selecionar o modelo de onde trazemos as classes e a biblioteca de destino das classes.
2. Selecionar as classes do modelo que desejamos que sejam geradas.
3a. Selecionar as classes que desejamos que herdem cada uma das classes a serem geradas.
3b. Selecionar a classe das que desejamos que herdem as classes que havemos indicados em 3a.
4a. Resolver conflitos de nomes.
4b. Resolver conflitos de herança.
5. Gerar código.
Se bem que o processo de geração de código o resultado é sensível e efetivo, quando o modelo chega a um tamanho considerável, a geração de código resultate é morosa, devido realizar-se a geração biblioteca à biblioteca, visto que não permite indicar individualmente a biblioteca de classe de onde deve armazenar cada classe.
Por outro lado temos que ressaltar uma limitação do gerador de código, dependendo de nossas necessidades, poder ser mais ou menos importante. O gerador de código somente trabalha com bibliotecas VCX, da qual não é possível gerar classes que herdem tipos básicos do VFP como Session, Relation ou Cursor, por exemplo.
Resultado curioso comprovar esta limitação que não se encontra na definição do modelo, o que nos daria uma solução alternativa, porém custosa, criando nosso próprio gerador para essas classes por meio das ferramentas de programação que oferece o aplicativo.
A importação do VFP
A importação do VFP pode ser feita tanto de classes como de bases de dados, visto que ambos os artefatos podem ser modelados por meio da UML.
A importação de classes segue um caminho similar ao da geração de código, com uma interfaze baseada no modelo dos assistentes nativos do VFP, que faz com que seja muito intuítiva trabalhar com ela. Neste caso se podemos importar múltiplas bibiliotecas de uma vez(desde que sejam VCX) ou incluir abrir um projeto e que o assistente pegue as classes dele.
A importação de bases de dados de Visual FoxPro se faz através do ODBC ou OLE DB pois está limitado pelas opções dos controladores. No caso do ODBC , entre as limitações que encontramos está a impossibilidade de trabalhar com as chaves estrangeiras armazendas nos DBC do VFP, porque no final da importação resulta em uma série de entidades de classe não relacionadas. Se a conexão que estabelecermos pelo OLE DB(somente disponível se trabalharmos com VFP7) esta limitação não existe e o Visual UML nos gera um completo diagrama com todas as relacões que tenhamos estabelecido.
Conclusões
Neste artigo desejei apresentar um produto que quanto mais se conhece mais agrada ao desenvolvedor, pois realmente o resultado é uma grande ajuda para essa difícil tarefa que criar aplicações para nossos clientes. Tudo nesta vidda é melhorável, e na minha opinião existem dois aspectos que exigem uma urgente melhoria no produto: a implementação dos packages, e a interface.
É difícil encontrar um aspecto de UML que não está contemplado no Visual UML, porém ainda podemos encontrar alguns que não cumprem completamente com a especificação UML 1.3. O caso mais destacável é o dos packages e os diagramas de packages. Nos packages do Visual UML não podemos definir visibilidade, devido a implementação reduzir-se a um simples agrupamento de artefatos, o que deixa muito limitada sua utilidade em comparação com a utilidade que poderiam ter se seguir as especificações . No WebSite do produto (www.visualobject.com) já há varios meses anuciando a versão 3.0, que segundo indicam, esta característica estará solucionada. A versão 3.0 do produto é esperada que saia este mês.
Quando pensamos em trabalhar com Visual UML devemos oferecer um processo de acomodação e internamento do controles da aplicação. O comportamento de alguns dos controles utilizados na aplicação não respondem aos padrões já estabelecidos por outras aplicações. Se foram introduzidas ligeiras variacões nas respostas oferecidas pelos controles básicos nas aplicações Windows que podem ser o grid, as caixas de lista, apesar de não afetar o funcionamento da aplicação, que obrigam um pequeno esforço de aprendizado por parte do usuário, o que em outras aplicações não existe. A estas mudanças de comportamento, também podemos juntar as mudanças no aspecto visual, onde tãopouco se seguem os padrões atuais do Windows, podendo dar a impressão de uma aplicação antiga quando não é, pois os controles lembram visualmente os do MS Word 6.0.
Um estúdio que manteve a interface, em vez de buscar uma interface menos carregada, sem o emprego de controles diferentes, ou por ocultação de opções que se poderiam aplicar, o que melhoraria muito a usabilidade do produto, se bem que levo muito em conta que isto é uma tarefa difícil sem sacrificar parte da flexibilidade oferecida pelo produto atualmente.
Estes dois comentários são apenas dois pequenos detalhes dentre de uma aplicação ne no mundo Fox é a única em seu gênero, uma ferramenta que nos permite fazermos mais facilmente o trabalho cada vez mais difícil de desenhar nossas aplicações.
José Luis Santana Blasco (Alicante, Espanha), desenvolveu sea primeira aplicação com o basic do Spectrum 48K. Apos um período de três anos dedicado a obter a Engenharia técnica em Gestão de Informática pela Universidade de Alicante, voltou ao mundo da informática real e inicialmente teve contato com FoxPro 2.0 Lan, na empresa TABIMED, o que será o princípio de uma grande amizade que já dura mais de 9 anos.Frequenta habitualmente os fóruns de Visual FoxPro em Espanhol, onde gosta de trocar conhecimento e ao mesmo tempo adquirido com eles. Sempre disposto a aprender coisas novas de quase tudo. Pode ser contactado em jlsantana@tabimed.cam.es.
topo
|
|
|
