software de integraÇÃo da ferramenta...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
SOFTWARE DE INTEGRAÇÃO DA FERRAMENTA CASE RATIONAL ROSE COM O BANCO DE DADOS JASMINE
TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO À UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS CRÉDITOS NA
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CIÊNCIAS DA COMPUTAÇÃO — BACHARELADO
RÔMULO BENDINI MADALENA
BLUMENAU, DEZEMBRO/2001
2001/2-44
ii
SOFTWARE DE INTEGRAÇÃO DA FERRAMENTA CASE RATIONAL ROSE COM O BANCO DE DADOS JASMINE
RÔMULO BENDINI MADALENA
ESTE TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS NA DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM CIÊNCIAS DA COMPUTAÇÃO
Prof. Everaldo Artur Grahl — Orientador na FURB
Prof. José Roque Voltolini da Silva — Coordenador do TCC
BANCA EXAMINADORA
Prof. Everaldo Artur Grahl Prof. Marcel Hugo Dr. Oscar Dalfovo
iii
AGRADECIMENTO
Primeiramente agradeço ao meu pai por ter dado a oportunidade de estudar e realizar
este trabalho. À minha mãe por ter me apoiado nas piores dificuldades.
Agradeço ao meu orientador mestre e professor Everaldo Artur Grahl.
Agradeço ao Professor Marcel Hugo e o Professor Oscar Dalfovo por participar da
banca, dando sugestões para aperfeiçoar o trabalho.
Também não podendo esquecer aos amigos Paulo Yukio Kano e Tony Westerich que
me apoiaram para a realização do trabalho.
Agradecimento especial ao Mauricio Martins, Sales Executive Information
Management da Computer Associates, pela sua atenção as minhas dificuldades encontradas
no trabalho.
iv
SUMÁRIO
AGRADECIMENTO ............................................................................................................... III
LISTA DE QUADROS ......................................................................................................... VIII
LISTA DE QUADROS ......................................................................................................... VIII
RESUMO .................................................................................................................................IX
ABSTRACT ..............................................................................................................................X
1 INTRODUÇÃO.....................................................................................................................1
1.1 OBJETIVOS........................................................................................................................2
1.2 ORGANIZAÇÃO DO TEXTO...........................................................................................3
2 ORIENTAÇÃO A OBJETOS ...............................................................................................4
2.1 INTRODUÇÃO...................................................................................................................4
2.2 UNIFIED MODELING LANGUAGE ...............................................................................5
2.3 FERRAMENTA CASE RATIONAL ROSE......................................................................7
2.3.1 MDL – MODEL................................................................................................................8
2.4 MODELO E META-MODELO........................................................................................11
2.5 DIAGRAMA DE CLASSES.............................................................................................12
2.5.1 ATRIBUTO ....................................................................................................................13
2.5.2 OPERAÇÕES .................................................................................................................14
2.5.3 ASSOCIAÇÃO ...............................................................................................................14
2.5.3.1 AGREGAÇÃO/COMPOSIÇÃO..................................................................................15
2.5.3.2 GENERALIZAÇÃO.....................................................................................................16
2.5.4 DEPENDÊNCIA.............................................................................................................17
3 BANCO DE DADOS ORIENTADO A OBJETOS............................................................19
v
3.1 DIFERENÇAS ENTRE OS BANCOS DE DADOS RELACIONAIS E OS
ORIENTADOS A OBJETOS ...........................................................................................21
3.2 O BANCO DE DADOS ORIENTADO A OBJETOS JASMINE....................................22
3.2.1 AS CLASSES DEFINIDAS NO JASMINE...................................................................23
3.2.2 LINGUAGEM ODQL ....................................................................................................24
3.2.2.1 DEPÓSITO – ALOCANDO ESPAÇO FISICO...........................................................24
3.2.2.2 CLASS FAMILY..........................................................................................................25
3.2.2.3 UTILIZANDO SCRIPTS ODQL PARA CRIAÇÃO DE CLASSES E SUAS
CARACTERÍSTICAS..................................................................................................26
4 DESENVOLVIMENTO DO TRABALHO ........................................................................28
4.1 REQUISITOS PRINCIPAIS DO PROBLEMA ...............................................................28
4.2 ESPECIFICAÇÃO ............................................................................................................28
4.2.1 DIAGRAMA DE CASOS DE USO ...............................................................................28
4.2.2 DIAGRAMA DE CLASSES ..........................................................................................29
4.2.3 DIAGRAMA DE SEQUÊNCIA.....................................................................................34
4.3 IMPLEMENTAÇÃO ........................................................................................................35
4.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS...........................................................36
4.3.1.1 LEITURA DO ARQUIVO MDL DO RATIONAL ROSE..........................................36
4.3.1.2 AMBIENTE DE GERAção DE CÓDIGO FONTE ODQL.........................................36
4.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO......................................................37
4.3.2.1 ESTUDO DE CASO.....................................................................................................37
4.4 RESULTADOS E DISCUSSÃO ......................................................................................46
5 CONCLUSÕES ...................................................................................................................48
5.1 EXTENSÕES ....................................................................................................................49
ANEXO 1- BNF PARA CRIAR UMA CLASSE EM ODQL.................................................50
ANEXO 2- CÓDIGO FONTE PARA LER O ARQUIVO MDL............................................52
vi
ANEXO 3- CÓDIGO FONTE EM DELPHI PARA GERAR O CODIGO ODQL ................62
ANEXO 4- ARQUIVO MDL DO ESTUDO DE CASO.........................................................64
ANEXO 5– CÓDIGO GERADO PELO PROTÓTIPO...........................................................79
REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................................81
vii
LISTA DE FIGURAS
Figura 1 - TELA PRINCIPAL DO CASE RATIONAL ROSE.................................................8
Figura 2 - – EXEMPLO DE UM DIAGRAMA DE CLASSE ................................................13
Figura 3 - EXEMPLO DE ATRIBUTOS NO RATIONAL ROSE .........................................13
Figura 4 - ASSOCIAÇÃO BÁSICA ENTRE DUAS CLASSES ............................................14
Figura 5 - OBJETO COMPOSTO E SEUS COMPONENTES...............................................15
Figura 6 - HIERARQUIA DE GENERALIZAÇÃO – ESPECIALIZAÇÃO..........................16
Figura 7 - EXEMPLO DE DEPENDÊNCIA ...........................................................................18
Figura 8 - DIAGRAMA DE CASO DE USO DO PROTÓTIPO ............................................29
Figura 9 - DIAGRAMA DE CLASSES DO PROTÓTIPO .....................................................30
Figura 13 - DIAGRAMA DE SEQUÊNCIA – LER ARQUIVO MDL...................................34
Figura 11 - DIAGRAMA DE SEQÜÊNCIA – GERAR CODIGO ODQL .............................35
Figura 12 - CONFIGURAÇÃO DA FERRAMENTA CASE RATIONAL ROSE.................38
Figura 13 - DIAGRAMA DE CLASSE DO ESTUDO DE CASO..........................................39
Figura 14 - TELA DA ÁRVORE DAS CLASSES E ARQUIVO MDL.................................40
Figura 15 - TELA DA ÁRVORE DAS ASSOCIAÇÕES........................................................41
Figura 16 – TELA DA CLASSE FAMÍLIA DENTRO DO PROTÓTIPO .............................42
Figura 17 - TELA DO CÓDIGO ODQL..................................................................................43
Figura 18 - TELA PARA EXECUTAR O ARQUIVO BAT...................................................44
Figura 19 - EXECUTAR O BANCO JASMINE .....................................................................44
Figura 20 - TELA PARA ENTRA EM UMA CONEXÃO .....................................................45
Figura 21 - TELA DO BANCO JASMINE COM AS CLASSES CRIADAS.........................46
viii
LISTA DE QUADROS
Quadro 1 - ARQUIVO FONTE DO MDL.................................................................................9
Quadro 2 - ESTRUTURA GLOBAL DO ARQUIVO MDL DO RATIONAL.......................10
Quadro 3 - DETALHAMENTO DO LOGICALCATEGORY................................................10
Quadro 4 - DETALHAMENTO DO OBJECT CLASS DO OBJECT PETAL.......................10
Quadro 5 – EXEMPLOS DE COMANDOS DO BANCO JASMINE ....................................25
Quadro 6 – SINTAXE DO COMANDO DEFINECLASS DA LINGUAGEM ODQL..........27
Quadro 7 - ESTUDO DE CASO..............................................................................................37
ix
RESUMO
O objetivo principal deste trabalho foi desenvolver um software de geração de código
para o banco de dados orientado a objeto Jasmine a partir dos arquivos gerados pela
ferramenta CASE Rational Rose. O software contruído obtem o diagrama de classes a partir
de um arquivo gerado pela ferramenta CASE Rational Rose e traduz estes dados para a
linguagem ODQL do Banco de Dados Jasmine.
x
ABSTRACT
The main goal of this work was to develop a code generation software for the
objectiorinted database Jasmine from the files generated by CASE tool Rational Rose. The
built software obtains the classes diagram starting from a file generated by the CASE tool
Rational Rose and translates these data for ODQL language of Jasmine Database.
1
1 INTRODUÇÃO A Orientação a Objetos (OO) é uma técnica de desenvolvimento de software que
utiliza abstração para dissimular a tarefa de programação, escondendo detalhes irrelevantes e
reduzindo o número de itens a serem tratados simultaneamente (Rumbaugh, 1994).
Os seres humanos vêem o mundo conforme os objetos são modelados em seu ambiente
e com este conhecimento a orientação a objeto proporciona uma maior modelagem real do
problema. Um benefício que esta técnica apresenta é uma correspondência com o mundo real,
visualizando objetos da natureza conforme são, individualizados e caracterizados com
finalidade própria.
Segundo Rumbaugh (1994), é evidente a necessidade da modelagem no processo de
desenvolvimento de software. Os modelos nos dão uma visão funcional do sistema, permitem
modificações, inclusões e testes. Assim como a planta de uma casa, os modelos orientam no
processo de construção ou renovação de um sistema. Bons modelos são essência para
comunicação entre os desenvolvedores, asseguram maior fidelidade à realidade que está
sendo modelada e podem suportar o aumento de complexidade de um sistema.
A Linguagem Unificada de Modelagem (Unified Modeling Language - UML) é uma
linguagem para especificação, visualização, construção e documentação de modelos de
sistemas de software. Ela é usada desde a especificação da análise de requisitos até a
finalização com a fase de testes.
A ferramenta CASE (Computer Aided Software Engeneerig) Rational Rose fornece
suporte a UML. Segundo Ballmann (2000), o Rational Rose é uma ferramenta para análise,
modelagem, projeto e construção de sistemas orientados a objeto. Dentre os diagramas
suportados pelo Rational Rose destacam-se o Diagrama de Casos de Uso, o Diagrama de
Classes e o Diagrama de Seqüência. Após a especificação em UML na ferramenta Rational
Rose o mesmo gera um arquivo (Model - MDL) que possui as informações sobre as classes,
atributos, categorias, hierarquias e associações entre as classes especificadas.
A empresa Rational foi pioneira no desenvolvimento da UML que se transformou na
notação padrão usada na ferramenta Rational Rose para especificar, visualizar e construir
artefatos de software e sistemas.
2
Normalmente as ferramentas CASE permitem gerar arquivos de Banco de Dados
tradicionais e relacionais como o Sistema Gerenciador de banco de dados (SGDB) Oracle,
porém seria muito interessante que fosse gerado para Banco de dados Orientado a objetos
(BDOO).
Desde a década de 60 a tecnologia de orientação a objetos vem ganhando cada vez
mais ferramentas para banco de dados orientado a objetos e uma delas é o Jasmine. A
arquitetura do Jasmine é orientada a objetos na sua concepção. Suas aplicações são
executadas na estação de trabalho enquanto o servidor gerencia os dados e retorna apenas os
dados solicitados. Esta estrutura é conhecida como cliente/servidor. Diversas linguagens de
programação podem trabalhar com os objetos do Jasmine.
Segundo Uessler (1999), o Jasmine possui uma interface simples e integrada, para
desenho do banco de dados e aplicações, fazendo integral uso dos recursos da UML. As
classes do Jasmine são implementadas em famílias (Class Family - CF), sendo que as CF
podem ser reutilizadas em outras CF, desde que não haja ambigüidade de nomes de classes.
As CF são agrupadas em uma hierarquia originando uma ramificação ou um conjunto de
ramificações. Uma classe pode se relacionar com qualquer outra através de agregações, mas
só pode herdar atributos e procedimentos de outra classe se ambas estiverem definidas na
mesma CF.
1.1 OBJETIVOS
O objetivo principal deste trabalho foi desenvolver um software de geração de código
para o banco de dados orientado a objeto Jasmine a partir dos arquivos gerados pela
ferramenta CASE Rational Rose.
Os objetivos específicos desse trabalho são:
a) obter dados referentes à definição de classes a partir dos arquivos gerados pelo
Rational Rose;
b) traduzir os dados obtidos para a linguagem ODQL.
3
1.2 ORGANIZAÇÃO DO TEXTO
No capítulo 1 são apresentados a introdução, bem como os objetivos deste trabalho.
No capítulo 2 são mostrados a introdução a orientação a objetos, os conceitos básicos
da UML, comentários sobre a ferramenta CASE Rational Rose e seu arquivo texto MDL.
No capítulo 3 são apresentados considerações sobre o banco de dados orientado a
objetos, o banco Jasmine e sua linguagem nativa ODQL.
No capítulo 4 é apresentado o desenvolvimento do trabalho, incluindo a descrição da
especificação e da implementação do protótipo.
Por fim, no capítulo 5 é apresentada a conclusão do trabalho e também sugestões para
as extensões deste trabalho.
4
2 ORIENTAÇÃO A OBJETOS
2.1 INTRODUÇÃO
Segundo Martin (1992), orientação a objetos (OO) pode ser definida como uma técnica
que modela o mundo em termos de objetos que possuem propriedades, comportamento e
eventos que alteram o estado dos objetos. Objetos interagem com outros objetos de maneira
formal. A orientação a objetos surgiu como um novo paradigma de desenvolvimento que
trazia inúmeras vantagens, como a reutilização e a facilidade de manutenção, mas não foi
concebida por uma única pessoa, mas sim por várias pessoas pesquisando sobre o assunto
desde os anos 60 até o momento. As pessoas que mais se destacaram foram Larry Constatine,
Edsger Dijkstra, David Parnas, Grady Booch, Ivar Jacobson, Peter Coad, Edward Yourdon,
Shlaer, James Rumbaugh e Wirfs-Brock.
OO é uma tecnologia de integração de áreas diversas: Interface de Usuário (IU), Banco
de Dados, Análise e Projeto de Sistemas e a própria programação em si. Além disso, a
tecnologia OO promove desenvolvimento de sistemas com as seguintes qualidades: correção,
robustez, extensibilidade, reusabilidade, compatibilidade, representando, portanto, um
paradigma de desenvolvimento de software, que fornece facilidades para a construção de
sistemas com uma representação mais próxima do mundo real.
A orientação a objetos traz vários benefícios no desenvolvimento e manutenção de
software. As vantagens estão divididas em dois grupos. No primeiro, as “vantagens diretas”,
aquelas que representam conseqüências diretas da adoção da Orientação a Objetos e, no
segundo grupo, as “vantagens reais”, estarão aquelas que são de fato a tecnologia.
As vantagens diretas são:
a) maior facilidade para reutilização de código e por conseqüência do projeto;
b) possibilidade do desenvolvedor trabalhar em um nível mais elevado de abstração;
c) utilização de um único padrão conceitual durante todo o processo de criação de
software.
5
As vantagens reais são:
a) ciclo de vida mais longo para os softwares;
b) desenvolvimento acelerado de softwares;
c) possibilidade de se construir sistema muito mais complexo, pela incorporação de
funções prontas;
d) menor custo para desenvolvimento e manutenção de softwares.
Segundo WinBlad (1990), OO é constituída dos seguintes mecanismos básicos :
objetos, mensagens e métodos, classes, herança, instâncias. Alguns conceitos que se destacam
são: abstração, encapsulamento, polimorfismo, persistência.
2.2 UNIFIED MODELING LANGUAGE
O grande problema do desenvolvimento de novos sistemas utilizando a orientação a
objetos nas fases de análise de requisitos, análise de sistemas e projeto é que não existe uma
notação padronizada e realmente eficaz que abranja qualquer tipo de aplicação que se deseje.
Cada simbologia existente possui seus próprios conceitos, gráficos e terminologias, resultando
numa grande confusão, especialmente para aqueles que querem utilizar a orientação a objetos
não só sabendo para que lado aponta a seta de um relacionamento, mas sabendo criar modelos
de qualidade para ajudá-los a construir e manter sistemas cada vez mais eficazes.
De acordo com Furlan (1998), quando a UML foi lançada, muitos desenvolvedores da
área da orientação a objetos ficaram entusiasmados já que essa padronização proposta pela
UML era o tipo de força que eles sempre esperaram.
A UML surgiu em meados de 1996 com o propósito de criar uma notação padronizada
para modelagem de sistemas orientados a objetos. A UML é o resultado do trabalho conjunto
dos maiores metodologistas da atualidade, na tentativa de criar uma notação unificada para
descrever sistemas de software. O esforço liderado por Grady Booch, James Rumbaugh e Ivar
Jacobson resultou na versão 1.0 da UML publicada em 13 de janeiro de 1997, e adotada com
padrão pelo OMG (Object Management Group) no mesmo ano.
Para estabelecer a UML, os desenvolvedores e a Rational (empresa da ferramenta
CASE Rational Rose) perceberam que a linguagem teria que estar disponível para todos.
6
Conseqüentemente, a linguagem não é proprietária e é aberta a todos. As companhias são
livres para utilizá-la com seus próprios métodos. Empresas de software são livres para criarem
ferramentas para a utilização da UML. Autores são encorajados a escrever sobre o assunto
Durante 1996, algumas companhias associaram-se a Rational para formar um consórcio de
parceiros da UML. Estas organizações reconheceram a UML como estratégica para seus
negócios e estão dispostas a contribuir para a definição da UML. Naturalmente estas estão
interessadas em privilegiar suas áreas de atuação na definição. Estas diferentes companhias
até janeiro de 1997 eram: Digital Equipment Corporation, HP, I-Logix, Intellicorp, IBM,
ICON computing, MCI Systemhouse, Microsoft, Oracle, Texas Instruments, Unisys, e claro, a
Rational. Estas companhias estão também dando suporte na proposta de adaptar a UML como
padrão para linguagens de modelagem no OMG.
Segundo Furlan (1998), a UML é a linguagem padrão para especificar, visualizar,
documentar e construir artefatos de um sistema e pode ser utilizada com todos os processos ao
longo do ciclo de desenvolvimento e através de diferentes tecnologias de implementação.
Buscou-se unificar as perspectivas entre os diversos tipos de sistemas e fases de
desenvolvimento de forma que permitisse levar adiante determinados projetos que antes não
eram possíveis pelos métodos existentes. A UML é uma linguagem de modelagem, não uma
metodologia. Muitas metodologias consistem, pelo menos em principio, de uma linguagem de
modelagem e um procedimento de uso dessa linguagem – a UML não prescreve
explicitamente esse procedimento de utilização. Em muitas formas, a linguagem de
modelagem composta por sintaxe e semântica é a porção mais importante do método, sendo
certamente a parte chave na comunicação.
Segundo Page-Jones (2001), a UML não tenta substituir definições textuais de classes
e seus métodos. Em lugar disso, a linguagem prôve uma estrutura gráfica para a organização
de construções de projeto e daí define cada construção por meio de um texto apropriado.
Os autores da UML relatam as metas que estabeleceram para si próprios ao
desenvolverem a linguagem. As sete afirmações de objetivos foram extraídas dos próprios
autores principais da UML:
a) prover aos usuários uma linguagem de modelagem visual expressiva e pronta para
uso, de forma que eles possam desenvolver e intercambiar modelos significativos;
7
b) prover mecanismos de extensibilidade e especialização para ampliar os conceitos
centrais;
c) ser independente de linguagens de programação e processos de desenvolvimento
particulares;
d) prover uma base formal para entendimento da linguagem de modelagem;
e) estimular o crescimento do mercado de ferramentas OO;
f) suportar conceitos de desenvolvimento de nível mais alto, tais como colaborações,
estruturas, modelos e componentes;
g) integrar as melhores práticas.
Segundo Fowler (2000), as ferramentas mais utilizadas para suportar a UML são
Rational Rose CASE tool, Paradigm Plus CASE tool, ObjectTime tool, Rhapsody (I-logix),
Visual CASE (Stimgray), UML Visio Template.
2.3 FERRAMENTA CASE RATIONAL ROSE
Segundo Ballmann (2000), uma ferramenta CASE (Computer Aided Software
Engineering), é uma ferramenta de apoio ao processo de desenvolvimento de software, não a
solução mágica para os problemas da área. As primeiras ferramentas CASE objetivaram
apenas a automação do desenho de diagramas e o armazenamento de informação básica
desses diagramas. Posteriormente, essas ferramentas passaram por uma revolução, assim
como também o conceito de desenvolvimento de software. A partir daí, tais ferramentas
como, por exemplo, o Rational Rose passaram a abranger os conceitos de ciclo de vida,
dicionários de dados e checagem automática de especificação, surgindo assim, as ferramentas
que hoje estão no mercado.
O Rational Rose é uma ferramenta para análise, modelagem, projeto e construção de
sistema orientado a objeto. Dentre os diagramas suportados pelo Rose destacam-se o
Diagrama de Casos de Usos, o Diagrama de Classes e o Diagrama de seqüência. O Rational
Rose é uma ferramenta de modelagem orientada a objeto, possuindo uma interface bem
amigável. Além de suportar a UML, também é possível modelar utilizando os métodos Booch
e OMT.
8
A figura 1 ilustra a tela principal da ferramenta Rational Rose, com um diagrama de
classe aberto.
Figura 1 - TELA PRINCIPAL DO CASE RATIONAL ROSE
2.3.1 MDL – MODEL
A ferramenta CASE Rational Rose gera um arquivo ASCII com a extensão MDL. As
especificações na linguagem MDL permitem recuperar o projeto orientado a objeto do
sistema na ferramenta Rational Rose.
Todas as classes, operações, métodos, atributos, em fim todas as características de cada
diagrama de classes são armazenadas neste arquivo texto com a extensão MDL, conforme
ilustrado na quadro 1.
9
Quadro 1 - ARQUIVO FONTE DO MDL root_category (object Class_Category "Logical View" quid "3A390A9E01B9" exportControl "Public" global TRUE subsystem "Component View" quidu "3A390A9E01BB" logical_models (list unit_reference_list (object Class "Gente" quid "3A390AA50050" class_attributes (list class_attribute_list (object ClassAttribute "Rg" quid "3A390AD80294") (object ClassAttribute "nome" quid "3A390AE0026C") (object ClassAttribute "endereço" quid "3A390AE50082") (object ClassAttribute "fone" quid "3A390AE50090") (object ClassAttribute "CPF" quid "3A390AEA0046"))) (object Class "Professor" quid "3A390AA9005A" superclasses (list inheritance_relationship_list (object Inheritance_Relationship quid "3A390B370348" supplier "Gente" quidu "3A390AA50050")) class_attributes (list class_attribute_list (object ClassAttribute "carteira trabalho" quid "3A390B0B015E") (object ClassAttribute "salário" quid "3A390B11000A"))) uid 0)) class_attributes (list class_attribute_list (object ClassAttribute "data inicio" quid "3A390B6D000A") (object ClassAttribute "data fim" quid "3A390B7801EA") (object ClassAttribute "valor total" quid "3A390B7B0082") (object ClassAttribute "forma pagto" quid "3A390B880320"))) (object Class "Habilitação" quid "3A390AB501FE" operations (list Operations (object Operation "verificar habilitação" quid "3A3910C3029E" concurrency "Sequential" opExportControl "Public" uid 0)))
10
O arquivo MDL contém uma linguagem que se chama Object Petal. Linguagem tem
várias versões disponíveis, mas o objetivo do protótipo é ler o object Petal versão 4.0. A
estrutura global do arquivo MDL está ilustrada no quadro 2.
Quadro 2 - ESTRUTURA GLOBAL DO ARQUIVO MDL DO RATIO NAL petalfile-> petal design petal-> ( object Petal version <number> _written <ident> charSet <number>) <design>-> ( object Design "logical View" is_unit TRUE is_loaded TRUE quid <ident> defaults <defaults> root_usecase_package <UseCaseCaterory> root_category <logicalCategory> root_subsystem <SubSystem> process_structure <processes> properties <properties> )
O arquivo MDL contém o diagrama de classe do seu Modelo e analisando o quadro 2,
a palavra logicalCategory é onde se encontra todo o detalhamento do Diagrama de Classe de
seu projeto. O quadro 3 mostra este detalhamento.
Quadro 3 - DETALHAMENTO DO LOGICALCATEGORY <logicalCategory>-> (object Class_Category "Logical View" quid <ident> exportControl <string> ... logical_models <list> logical_presentations <list> properties <properties> )
Dentro do logicalCategory está especificado o Object Class onde estão todos os
detalhes da classe. A palavra reservada Object Class indica que após haverá toda a descrição
do objeto especificado no Rational Rose. No quadro 4 está o detalhamento do Object Class.
Quadro 4 - DETALHAMENTO DO OBJECT CLASS DO OBJECT P ETAL (object Class <string> quid <indent> superclasses <list> operations <list> class_attributes <list> used_nodes <list> realized_interfaces <list> exportControl <string> language <string> stereotype <string> )
11
2.4 MODELO E META-MODELO
Segundo Prebianca (1998), o esforço inicial da definição da UML concentrou-se na
identificação e definição da semântica de conceitos fundamentais (a construção de blocos do
modelo orientado a objetos). Estes conceitos são produtos do desenvolvimento de processos,e
devem ser tratados entre as diferentes partes envolvidas em um projeto.
Para facilitar este trabalho de definição e ajudar na formalização da UML, todos os
diferentes conceitos têm sido modelados usando um subconjunto. Esta definição de
recursividade, chamada meta-modelo, tem a dupla vantagem de permitir a classificação de
conceitos através de nível de abstração, por complexidade e através do domínio da aplicação,
enquanto também garante uma notação com um poder expressivo de representação.
Segundo Nau (1998), para a UML suprir o seu propósito geral, que é de ser uma
linguagem de modelagem gráfica para o desenvolvimento orientado a objetos (para as fases
de análise e projeto), a UML disponibiliza uma série de diagramas para que seja possível
levantar a especificação dos requisitos, a estrutura estática, a parte dinâmica ou
comportamental, e os aspectos de implementação do sistema ou artefato do sistema.
Segue a relação dos diagramas disponibilizados pela UML, com uma breve descrição
apresentada por (Muller, 1997):
a) diagrama de Classe (Class Diagram) – representa estrutura estática em termos de
classes e relacionamento;
b) diagrama de Atividade (Activity Diagram) – representa o comportamento de uma
operação como um conjunto de ações;
c) diagrama de Colaboração (Collaborations Diagram) – é uma representação
espacial dos objetos, links e interações;
d) diagrama de Componentes (Components Diagram) – representa os componentes
físicos de uma aplicação;
e) diagrama de Distribuição (Deployment Diagram) – representa a distribuição de
componentes nas partes particulares do hardware;
f) diagrama de Objetos (Objects Diagram) – representa objetos e seus
12
relacionamentos e corresponde a simplificados diagramas de colaboração que não
representam transmissão de mensagem;
g) diagrama de Seqüência (Sequence Diagram) – é uma representação temporal dos
objetos e suas interações;
h) diagrama de Estados (StateChart Diagram) – representa o comportamento de uma
classe em termos de estados;
i) diagrama de Casos de Uso (Use Case Diagram) – representa as funções de um
sistema do ponto de vista de um usuário.
Na prática, a UML é simplesmente outra representação gráfica de um modelo
semântico comum. Porém, combinando os elementos mais úteis dos métodos orientados a
objetos, e estendendo a notação para cobrir aspectos novos de desenvolvimento de sistema.
Seguindo o foco deste trabalho, a seguir serão apresentados mais detalhes sobre o
diagrama de classe.
2.5 DIAGRAMA DE CLASSES
O diagrama de classes demonstra a estrutura estática das classes de um sistema onde
estas representam as “coisas” que são gerenciadas pela aplicação modelada. Classes podem se
relacionar com outras de diversas maneiras.
A associação, dependência, generalização, e pacotes, são mostrados no diagrama de
classe juntamente com as suas estruturas internas, que são os atributos e operações. O
diagrama de classes é considerado estático já que a estrutura descrita é sempre valida em
qualquer ponto do ciclo da vida do sistema. Um sistema normalmente possui alguns
diagramas de classes, já que não são todas as classes que estão inseridas em um único
diagrama e umas certas classes podem participar de vários diagramas de classes.
Uma classe num diagrama pode ser diretamente implementada utilizando-se uma
linguagem de programação orientada a objetos que tenha suporte direto para construção de
classes. Para criar um diagrama de classes, as classes têm que estar identificadas, descritas e
relacionadas entre si, como mostra a figura 2.
13
Figura 2 - – EXEMPLO DE UM DIAGRAMA DE CLASSE
Companhia de Aluguel de Veículos Caminhão Carro Sport Carro de Passeio
0..1
Veículo Alugado
Tipos de Veiculos
0..*
1
1
Cliente
1..*Contrato de Aluguel
0..1
refere a
0..*
1
possui
1
1..*
possui
2.5.1 ATRIBUTO
Segundo Furlan (1998), atributo é a menor unidade que em si possui significância
própria e inter-relacionada com o conceito lógico da classe a qual pertence. Apresenta um
princípio de atomicidade, ou seja, armazenamento de um valor simples em uma célula.
Figura 3 - EXEMPLO DE ATRIBUTOS NO RATIONAL ROSE
Indivíduo
códigoDoIndivíduo : Longsexo : M ou FdataDoNascimento : data
Mesmo sendo uma propriedade nomeada de um tipo, os detalhes das expressões de
atributos não são especificados pela UML, ficando a cargo da sintaxe de expressão suportada
pelo ambiente de desenvolvimento da aplicação.
Um atributo é mostrado como uma seqüência de caracteres que pode ser analisada
gramaticalmente nas varias propriedades de elementos cuja sintaxe padrão é: Visibilidade
NomeDoAtributo: TipoDeExpressão = ValorINicial {Propriedade}.
14
2.5.2 OPERAÇÕES
De acordo com Fowler (2000), operações são processos que a classe sabe realizar.
Operações correspondem claramente a métodos em uma classe. No nível de especificação, as
operações correspondem a métodos públicos. Normalmente, você não mostra as operações
que simplesmente manipulam atributos, porque elas podem ser freqüentemente inferidas.
A sintaxe completa da UML para as operações é visibilidade nome (lista-de-
parâmetros):expressão-de-tipo-de-retorno {string-de-propriedades}.
2.5.3 ASSOCIAÇÃO
Uma associação representa relacionamentos estruturais entre classes de objetos. A
figura 4 mostra um exemplo de associação.
Figura 4 - ASSOCIAÇÃO BÁSICA ENTRE DUAS CLASSES
Fonte: Page-Jones (2001)
Segundo Muller (1997), este relacionamento é representado graficamente através de
um caminho entre os símbolos das classes. O caminho pode possuir vários ornamentos
gráficos anexados, estes ornamentos representam as propriedades da associação.
É exibido próximo ao caminho (mas não próximo suficiente a um fim de associação
para ser confundido com um nome de papel de associação) como uma string do nome. Este
string do nome pode ser um triângulo sólido preto opcional nele, o qual apontará para a
direção que o nome deve ser lido. A seta da direção do nome não tem significado semântico,
ela é meramente descritiva. As classes na associação são ordenadas como indicado pela seta
de direção do nome.
15
2.5.3.1 AGREGAÇÃO/COMPOSIÇÃO
Segundo Page-Jones (2001), composição é uma estrutura comum em sistemas de
software, orientados ou não a objetos, devido ao fato de que muitos objetos compostos
aparecem no dia-a-dia. Por exemplo, um cachorro é uma composição contendo uma cabeça,
um corpo, um rabo e quatro patas (uma em cada extremo). Outras composições são mais
conceituais ou específicas de software: por exemplo, uma mensagem de e-mail é uma
composição contendo um cabeçalho e alguns parágrafos de texto. Por sua vez, o cabeçalho é
uma composição do nome do remetente, do nome do destinatário, do título da mensagem e de
algum outro e-stuff (item eletrônico).
Figura 5 - OBJETO COMPOSTO E SEUS COMPONENTES
um CorpoCabeça Um Rabo Patas
Cachoro
Segundo Larman (2000), agregação é um tipo de associação usado para modelar
relacionamentos todo-partes entre coisas. O todo é geralmente chamado composto, porém as
partes não têm um nome padronizado - é comum usar parte ou componente.
Semelhante à composição, a agregação é uma construção familiar por meio da qual os
sistemas de software representam estruturas da vida real.
Deve-se representar uma agregação quando:
a) o tempo de vida da parte está vinculado ao tempo de vida do composto – existe uma
dependência criação-destruição da parte em relação ao todo;
b) existe uma relação física todo-partes óbvia, ou um agrupamento lógico;
c) algumas propriedades do composto se propagam para as partes, tais como sua
localização;
d) operações aplicadas ao composto se propagam para as partes, tais como destruição,
movimentação, gravação.
16
Os benefícios em mostrar agregações são:
a) ela esclarece as restrições existentes no domínio com relação à existência aceitável
da parte independente do todo;
b) operações – tais como copiar ou excluir – aplicadas para o todo, freqüentemente, se
propagam para as partes.
2.5.3.2 GENERALIZAÇÃO
De acordo com Fowler (2000), um exemplo típico de generalização envolve clientes,
pessoas físicas e jurídicas.
Elas têm diferenças, mas também muitas semelhanças. As semelhanças podem ser
colocadas em uma classe geral clientes (o supertipo), como ClientePessoaFísica e
ClientePessoaJuridica como subtipo.
Este fenômeno também esta sujeito a diferentes interpretações em diferentes níveis de
modelagem. Conceitualmente, podemos dizer que ClientePessoaJurídica é um subtipo de
Cliente se todas as instâncias de ClientePessoaJurídica também são, por definição, instâncias
de Cliente. Um ClientePessoaJurídica é, então, um tipo especial de Cliente. A idéia-chave é
que tudo que está relacionado a um Cliente – associação, atributos, operações – também seja
verdadeiro para um ClientePessoaJurídica.
Figura 6 - HIERARQUIA DE GENERALIZAÇÃO – ESPECIALIZ AÇÃO.
Pagamento
PagamentoComDinheiroPagamentocomCheque
PagamentocomCartãodeCredito
supertipo - conceito mais geral
Subtipo - conceito mais especializado
Segundo Furlan (1998), uma superclasse é criada para representar a essência da idéia
sobre subclasse expressando os modos diferentes que tais essências são percebidas. Pela
definição da UML, generalização é “um relacionamento de taximonia entre um elemento mais
17
geral e um elemento mais específico que é completamente consistente com o primeiro
elemento somando-a informação adicional especializada”. São usados para classes, pacotes,
casos de usos e outros elementos.
No diagrama de classe, a generalização é mostrada como uma linha sólida do elemento
mais específico, uma subclasse, ao elemento mais geral, uma superclasse, com um triângulo
vazio ao término do caminho que satisfaz o elemento mais geral. Um grupo de caminhos de
generalização para uma determinada superclasse pode ser apresentado como uma árvore com
um segmento compartilhado, inclusive triângulo, para a superclasse, ramificando-se em
caminhos múltiplos a cada subclasse. Se vários arcos de generalização compartilham a mesma
etiqueta, representam a mesma dimensão de generalização de superclasse; etiquetas diferentes
definem dimensões independentes de generalização. A figura 6 mostra um exemplo de
generalização.
2.5.4 DEPENDÊNCIA
Segundo Fowler (2000), existe dependência entre dois elementos se mudanças na
definição de um elemento possam causar mudanças ao outro. Nas classes, as dependências
existem por varias razões:
a) uma classe manda uma mensagem para outra;
b) uma classe tem outra como parte de seus dados;
c) uma classe menciona uma outra como um parâmetro para uma operação.
De acordo com Furlan (1998), uma dependência indica a ocorrência de um
relacionamento semântico entre dois ou mais elementos do modelo onde uma classe Cliente é
dependente de alguns serviços da classe Fornecedora, mas não tem uma dependência
estrutural interna com esse fornecedor. Indica uma situação na qual uma mudança em um
elemento (elemento independente) pode afetar outro elemento da dependência (elemento
dependente). Os clientes de uma classe podem ter tanto instâncias como subclasse, sendo útil
definir interfaces diferentes para cada um desses tipos.
18
Figura 7 - EXEMPLO DE DEPENDÊNCIA
Fornecedor Cliente
Dependência é mostrada com uma seta tracejada de um elemento de modelo para
outro, do Fornecedor para o Cliente (classe apontada para seta). Durante o desenho, é comum
estabelecer uma relação ente Cliente e Fornecedor onde o Cliente sabe sobre o Fornecedor,
mas não vice-versa. A seta pode ser etiquetada com um estereótipo, assim como com um
nome. Se um dos elementos é uma nota ou restrição então a seta é suprimida.
A forma mais comum de dependência geral é encontrada quando uma operação
definida em uma classe Cliente assume um argumento (um valor específico que corresponde a
um parâmetro) de algum outro tipo de classe. Na figura 7 pode ser mostrado um exemplo de
dependência.
19
3 BANCO DE DADOS ORIENTADO A OBJETOS
Segundo Khoshafian (1994), ainda que um consenso esteja começando a se formar
sobre o que é orientação a objeto, sobre bancos de dados orientados a objeto ainda há alguma
confusão. No entanto, há alguns conceitos muitos específicos de orientação a objeto que
proporcionam benefícios para a prototipação, modelagem e programação de aplicações
avançadas.
Segundo Jacobson (1994), a definição do termo “banco de dados orientado a objeto”
não está bem clara. Para definir melhor o assunto ele associa às seguintes características de
um banco de dados orientado a objeto (BDOO):
a) persistência de dados: o armazenamento de dados num banco de dados persiste
mesmo quando o sistema de gerenciamento de banco de dados (Database
Management - DBMS) não está operando;
b) herança: isto é natural dentro de um grupo de entidades do mundo real e suas
classes. Tipo e subtipos são herdados entres os objetos definidos;
c) abstração de tipos de dados (Abstract Data Type – ADT): os sistemas de orientação
a objetos possibilitam aos objetos possuir atributos próprios. Isto é feito com os
mecanismos de ADT que escondem o armazenamento físico das informações do
usuário, mas disponibiliza um conjunto de métodos públicos através dos quais o
usuário manipula os atributos dos objetos;
d) interface gráfica (opcional): já que objetos podem ter uma estrutura complicada,
algum mecanismo especial de apresentação pode ser necessário para permitir uma
visão melhor ao usuário;
e) identificação de objetos: entidades num modelo relacional são muitas vezes
identificadas pelos valores das chaves. Quando acorre alteração de uma chave é
criada uma nova entidade. Num sistema orientado a objetos, os objetos são
conhecidos através de um único identificador, quando eles são criados não são mais
alterados. Qualquer objeto pode ser referenciado via esta identificação de objeto.
O uso de banco de dados orientados a objetos é um fator emergente que integra banco
de dados e tecnologia de orientação a objeto. Por um lado, a necessidade de realizar
manipulações complexas para os bancos de dados existentes e uma nova geração de
20
aplicações de bancos de dados geralmente requisita mais diretamente um banco de dados
orientado a objeto. Por outro lado, aplicações de linguagens orientadas a objeto e sistemas
estão exigindo capacidades de bancos de dados, tais como continuidade, simultaneidade e
transações, dos seus ambientes. Estas necessidades estão levando à criação de sistemas
poderosos, chamados bancos de dados orientados a objetos.
Os bancos de dados orientados a objeto iniciaram-se primeiramente em projetos de
pesquisa nas universidades e centros de pesquisa. Em meados dos anos 80, eles começaram a
se tornar produtos comercialmente viáveis.
Os bancos de dados orientados a objeto integram a orientação a objeto com aptidões de
bancos de dados. Através de construções orientadas a objeto, os usuários podem esconder os
detalhes de implementação de seus módulos, compartilhar a referência a objetos e expandir
seus sistemas através de módulos existentes. A funcionalidade de bancos de dados é
necessária para assegurar o compartilhamento concomitante e a continuidade das informações
nas aplicações. Através dos bancos de dados, os usuários podem obter o estado em que os
objetos se encontram, e estar atualizados entre as várias solicitações de programa, e vários
usuários podem ao mesmo tempo compartilhar a mesma informação. Os bancos de dados
orientados a objeto combinam os benefícios e conceitos da orientação a objeto com a
funcionalidade dos bancos de dados. Portanto, bancos de dados orientados a objetos são uma
extensão destes dois conceitos.
Segundo Uessler (1999), os bancos de dados convencionais não são flexíveis ou
suficientemente eficientes em sistemas onde o esquema de dados tende a mudar com
freqüência e os dados são complexos ou multidimensionais. Bancos de dados orientados a
objetos são sistemas que permitem armazenar e recuperar objetos e prover facilidades para
manipular objetos armazenados, assim como permitem armazenar em banco de dados, um
objeto completo como se estivesse na memória principal, sem a necessidade de alterar a
estrutura e forma de representação do objeto. Acredita-se que seja o grande diferencial que
atrai uma considerável quantidade de desenvolvedores insatisfeitos com os banco de dados
convencionais.
21
3.1 DIFERENÇAS ENTRE OS BANCOS DE DADOS RELACIONAIS E OS ORIENTADOS A OBJETOS
Segundo Fagundes (2001), os bancos de dados relacionais (RDBMS) usam uma
arquitetura tabular ou matricial onde os dados são referenciados através de linhas e colunas,
enquanto os bancos de dados orientados a objetos (ODBMS) podem ser inteligentes
combinando lógica e os dados. Nos relacionais as tabelas são definidas tendo como base a
teoria da normalização evitando a redundância dos dados e facilitando a pesquisa e
atualizações. Os orientados a objetos possuem métodos, classes e outros mecanismos do
modelo de orientação por objetos. Os objetos são ativos já que podem conter lógicas,
enquanto os relacionais são passivos necessitando de um programa para manipular os dados.
O mercado é dominado pelos relacionais, posições reforçadas pelo fracasso dos bancos
orientados a objetos no passado.
Entretanto, com as novas aplicações multimídia e da Internet com o uso da linguagem
Java os bancos de dados orientados a objetos estão se posicionando como uma boa opção
tecnológica.
Os dados dos bancos relacionais são descritos em 2-D, através de linhas e colunas. A
linguagem SQL (Structure Query Language) é um padrão aberto para consulta e manipulação
dos bancos de dados relacionais de todos os fornecedores. O SQL permite que os sistemas
relacionais desenvolvidos por muitos fornecedores possam se comunicar entre si e acessar
banco de dados comuns. Em contra partida, os bancos de dados orientados a objetos não
possuem uma linguagem padrão dificultando a inter-operacionalidade entre os bancos de
dados de diferentes fornecedores.
Para definir as tabelas dos bancos relacionais é utilizado o processo de normalização,
que consiste em definir nas tabelas apenas os dados que sejam únicos para a entidade descrita
e definindo relacionamentos para outras tabelas também normalizadas. Os bancos relacionais
estão fundamentados em uma forte teoria matemática e ferramentas bem desenvolvidas.
Enquanto os bancos orientados a objetos não possuem uma forte teoria como apoio e não
existem ferramentas que descrevam o modelo de objetos.
22
Com o crescimento do mercado de multimídia, vídeo game e aplicações Web que
utilizam a linguagem orientada a objetos Java, o uso de bancos orientados a objetos está
crescendo. Para atender essa demanda os fornecedores de bancos de dados relacionais estão
introduzindo facilidades de armazenamento de objetos em seus bancos de dados, chamando-
os de banco de dados relacional por objetos. Porém, esse tipo de banco de dados não é
possível otimizar queries a objetos, fazer indexação direta dos objetos e usar os algoritmos de
pesquisa do banco para buscar novos objetos. Somente um banco de dados orientado a objetos
puro pode manipular objetos.
Os bancos de dados tradicionais foram desenvolvidos para empresas relativamente
estáveis com grandes volumes de dados de baixa complexidade. Em um ambiente dinâmico
com dados complexos na forma de vídeo, áudio, imagens e textos são necessários um novo
modelo de banco de dados. A vantagem do banco orientado a objetos é a lógica contida no
objeto e a possibilidade de ser reutilizado várias vezes em diversas aplicações.
3.2 O BANCO DE DADOS ORIENTADO A OBJETOS JASMINE
Segundo Uessler (1999), em 1997, a Computer Associates lançou o BDOO Jasmine.
Baseado no banco de dados ODB-II da Jujitsu, o BDOO Jasmine incorpora uma série de
classes pré-definidas para exploração de recursos multimídia como vídeo, som, coordenadas
espaciais, mapas, além dos tipos de dados tradicionais dos SGBDR.
O Jasmine possui bibliotecas de classes pré-definidas, que podem ser utilizadas em
qualquer aplicação. Além dos tipos de dados normalmente utilizados em bancos de dados
convencionais, o Jasmine possui classes para manipulação de dados multimídia.
A criação das classes é feito no ambiente Jasmine Studio, porém o acesso aos objetos
pode ser feito através de bibliotecas de classes para Java, C/C++, ActiveX, ODQL e
desenvolvimento de aplicações para Internet via Weblink.
As Class Family que o banco de dados Jasmine possui são:
a) mediaCF – possui definição de classes multimídias;
b) sqlCF – grupos de classes para acesso aos dados de um SGBDR via gateway
23
Jasmine;
c) weblink – classes definidas para o desenvolvimento de aplicações para acesso via
internet;
d) jadelibCF – conjunto de classes do ambiente de desenvolvimento que não está
disponível em nenhum aplicativo (apenas para uso do próprio banco de dados).
As classes são implementadas em famílias, sendo que as CF podem ser reutilizadas em
outras CF, desde que não haja ambigüidade de nomes de classes. As CF são agrupadas em
uma hierarquia originando uma ramificação ou um conjunto de ramificações. Uma classe
pode se relacionar com qualquer outra através de agregações, mas só pode herdar atributos e
procedimentos de outras classes se ambas estiverem definidas na mesma CF.
O Jasmine tem muitas tecnologias incorporadas para acesso a internet, que estão
relacionadas a seguir: com/com+, corba, java, mapi, orb, xml.
3.2.1 AS CLASSES DEFINIDAS NO JASMINE
O Jasmine permite a fácil criação de classes, via ambiente totalmente visual ou pela
linguagem ODQL. O ambiente visual permite ao desenvolvedor e mantenedor a rápida
visualização da classe. Na figura 21, um exemplo claro da facilidade de visualização e criação
destas classes e todas as hierarquias da classe. Na janela de navegação de classe, é possível
visualizar a definição da classe, suas instâncias (objetos), consultas relativas a classe e
métodos desenvolvidos.
Na janela do navegador de classe, é possível visualizar todas as classes pertencentes a
uma respectiva Class Family. No lado esquerdo as classes (representadas por um ícone em
forma de caixa na cor amarela) e sua hierarquia (na forma de árvore) e na janela da direita,
todos os objetos (instâncias) (representado pelo mesmo ícone de classe, porém na cor
vermelha) para cada classe bem como suas consultas pré-definidas, métodos e superclasse das
quais herdam atributos e métodos. Para se criar uma nova classe basta que se clique na janela
da esquerda com o botão direito e selecionar o item new subclass.
24
3.2.2 LINGUAGEM ODQL
Segundo Khoshafian (1999), a linguagem ODQL é um componente muito importante
para a operabilidade do banco Jasmine, pois nesta linguagem você manipula qualquer objeto,
classes, instâncias, métodos.
Para que o banco compile suas rotinas, por exemplo, criar as classes, precisa antes
criar uma base de dados. O Jasmine se liga em dois conceitos:
a) depósitos;
b) família de classes;
3.2.2.1 DEPÓSITO – ALOCANDO ESPAÇO FISICO
Um depósito (no jasmine é chamado de Store) é um recipiente físico onde definições
de métodos e classes e os objetos criados são armazenados. Cada depósito é implementado
através de um ou mais arquivos físicos. Em geral, cada aplicação tem seu próprio depósito,
embora isto não seja obrigatório. Caso haja necessidade de mais espaço, o depósito pode ser
expandido.
Para criar manualmente este depósito é executado comando CreateStore no prompt do
NT. Um exemplo prático deste comando seria:
a) createStore empresaStore %JAS_SYSTEM%\jasmine\data\empresaStore01;
As funções relacionadas com a manipulação do Store seriam:
a) createStore – cria um depósito;
b) deleteStore – apaga um depósito;
c) extendStore – expande um depósito;
d) listStore – lista todos os depósitos criados, inclusive as pré-instaladas.
No quadro 5 está apresentanda a sintaxe dos comandos internos do banco Jasmine.
25
Quadro 5 – EXEMPLOS DE COMANDOS DO BANCO JASMINE CreateStore [-h] [-dbName database] [-userName user] [-passwd password] [-envFile envFile] [-numberOfPages] [-pageSize pageSi ze] storeName {fileName}... ExtendSore [-h] [-dbName database] [-userName user] [-passwd password] [-envFile envFile] [-numberOfPages Pages] [-wait] sto reName {fileName}... DeleteSore [-h] [-dbName database] [-userName user] [-passwd password] [-envFile envFile] [-force] [-wait] storeName ListStore [-h] [-dbName database] [-userName user] [-passwd password] [-envFile envFile] [toreName] Explicação dos argumentos e opções [-h] : mostra a sintaxe do comando, se está opção e stá especificada, o comando não é executada e todos os outros opções es peficidadas serão ignorada. [-dbName database] : o nome da base de dados para s er conectado [-userName user] : o nome do usuário [-passwd password] : a senha do usuário
[-envFile envFile] : nome do arquivo o ambiente do cliente ; se omitido, a variável de ambiente de JAS_ENVFILE é usada. [-numberOfPages Pages] : numero de paginas para ser alocado [-wait] : se usado o deposito, espera até que esteja disponível storeName : nome do depósito fileName : os arquivos que são usados pela extensão do depósito (devem especificar pelo menos um arquivo) nameCF : nome de classe família nameStore : nome do deposito
3.2.2.2 CLASS FAMILY
Uma Class Family é uma coleção de classes. Nomes de classes devem ser únicos
dentro de uma família, mas famílias diferentes podem ter classes com o mesmo nome. Cada
classe pertence a apenas uma Class Family. Cada Class Family está armazenada em um único
depósito, mas um depósito pode ter várias delas. O nome de uma Class Family deve ser único
dentro de um depósito.
26
A herança está limitada a classes da mesma Class Family, com exceção da classe
composite, que pode ser herdada por todas as outras. Relacionamentos podem ser feitos entre
classes de diferentes Class Family.
Para se referir a uma classe deve-se se referir a Class Family dela. Se a Class Family
não for especificada explicitamente será utilizada a última Class Family declarada como
padrão. Por exemplo, se a Class Family tiver o nome de “EmpresaCF” e a classe o nome
“Funcionário”, esta deve ser referenciada por “EmpresaCF::Funcionário”.
Para criar uma Class Family, deve-se executar o programa “createcf” no prompt do
NT.
3.2.2.3 UTILIZANDO SCRIPTS ODQL PARA CRIAÇÃO DE CLA SSES E SUAS CARACTERÍSTICAS.
Segundo Khoshafian (1999), Object Database Query Language (ODQL) é uma
linguagem utilizada pelo Jasmine para criar classes, métodos e objetos. Um script consiste em
um arquivo ASCII de extensão odql. O comando “defaultCF” define a família que será padrão
(ou seja, se no nome da classe não for informada a família, será usada a padrão).
Para executar um script, no prompt do NT, execute o comando “codqlie”. O comando
é o interpretador de código fonte ODQL, e pode ser usado sem carregar um arquivo. Como é
um interpretador, se houver uma falha, todas as linhas de código antes do erro serão
executadas normalmente, e as alterações salvas no banco. Para evitar isto, deve-se iniciar uma
transação explicitamente.
Na linguagem ODQL utilizada pelo Jasmine, não existem tipos básicos. Apenas
existem classes. Estas classes podem ser definidas pelo usuário, ou serem pré-definidas. Entre
as classes pré-definidas, dois grupos são importantes que é a classe atômica e de coleção.
A classe atômica é representada por Integer, Decimal, Real, Date, String,
ByteSequence, Boolean. As classes de coleção, como o nome indica, representam uma
coleção de objetos de uma outra classe. São Bag, Set, List, Array.
27
Para definir uma nova classe, deve-se usar o comando “defineClass” dentro do código
fonte ODQL. No comando você também pode definir os atributos da classe. O atributo tem
propriedades que podem ser definidas em dois níveis, que são “class” e a “instance”. A
sintaxe do comando “defineClass” pode ser vista no quadro 6.
Quadro 6 – SINTAXE DO COMANDO DEFINECLASS DA LINGUA GEM ODQL DefineClass class-identifier [super : class-identifier [ {. Class-identifier}…]] [description : string-contant] { [maxInstanceSize : Size ;] characteristics };
A linguagem ODQL dá suporte para a criação de métodos dentro das classes. A
declaração de métodos não é obrigatória, e pode ser acrescentada depois. O tipo de retorno
pode ser “Void” ou um tipo. Cada parâmetro pode ser definido como tipo “nome” onde tipo é
um tipo de dados e nome é o nome do parâmetro.
No banco Jasmine os métodos podem estar definidos em quatro níveis:
a) Class – define métodos de clase;
b) Instance – define métodos que serão aplicados a instâncias;
c) Instance collection – aplicados a uma coleção de instâncias de uma classe;
d) Class collection – aplicados a uma coleção classes, onde cada classe tem a
definição do método.
28
4 DESENVOLVIMENTO DO TRABALHO
4.1 REQUISITOS PRINCIPAIS DO PROBLEMA
O que se pretende com o trabalho é facilitar a migração de uma especificação gerada
na ferramenta CASE Rational Rose para um Banco de Dados Orientado a Objetos. Optou-se
pelo BDOO Jasmine que usa a linguagem ODQL.
As informações sobre o diagrama de classe do Rational Rose estão descritas em uma
linguagem chamada Object Petal, com isto teve que ter uma especificação da linguagem para
saber onde estão as informações desejadas.
O banco de dados Jasmine tem internamente um compilador para a linguagem ODQL,
mas para compilar precisaria descrever a sintaxe e a semântica corretamente, para que o banco
não rejeitasse o arquivo texto. Junto com o livro Khoshafian (1999) obteve-se a BNF (Bakus
Nauer Form) da linguagem ODQL, visto no anexo1, para se basear e comparar com o código
fonte gerado pelo protótipo.
4.2 ESPECIFICAÇÃO
Nesta seção será apresentada a especificação do protótipo de software para a
integração da ferramenta Rational Rose com o Jasmine.
4.2.1 DIAGRAMA DE CASOS DE USO
O protótipo foi desenvolvido utilizando a orientação a objetos. Optou-se por utilizar a
notação UML. Existem dois casos de uso principais sendo que no primeiro o analista faz a
leitura do arquivo MDL e no segundo o analista gera o código fonte ODQL das classes que
foram lidas no MDL. A figura 8 apresenta o diagrama de caso de uso para o protótipo.
29
Figura 8 - DIAGRAMA DE CASO DE USO DO PROTÓTIPO
Gerar Codigo ODQL
Ler arquivo MDL
Analista
4.2.2 DIAGRAMA DE CLASSES
No desenvolvimento do protótipo foram identificadas oito classes que são utilizadas
para armazenar as informações do arquivo MDL da ferramenta CASE e posteriormente gerar
o código fonte ODQL. A figura 9 mostra o diagrama de classes do protótipo.
30
Figura 9 - DIAGRAMA DE CLASSES DO PROTÓTIPO
1
0..*TRole
Name : StringSupplier : StringCardinality : String
Create( )GetSupplier( )GetName( )
1
TRRFile
FLine : IntegerFCountAbreParenteses : IntegerFCountFechaParenteses : IntegerSL : TStringListDictionary : TDictionarySLODQL
GetObjectName( )CountToken( )DeleteSubStr( )ReadMethods( )ReadSuperClasse( )ReadAttributes( )ReadAssociations( )ReadParameters( )ReadDependencys( )Destroy( )ReadClasses( )IsValid( )Create( )RetiraCifrao( )ODQLGeneration( )
1..*
1
0..*TAssociation
Name : StringRoleA : RoleRoleB : Role
Create( )
1
0..*
1 0..*
TDependency
Name : StringSupplier : StringSupplierCardinality : StringClientCardinality : String
Create( )GetSupplier( )GetName( )
1
TDictionary
Associations : AssociationClasses : Classe
Create( )Destroy( )LiberaMemoria( )
1
1..*
1
0..*
1..*
10..*1..*
TClasse
Name : StringSuperClass : StringSuperClassRelationName : StringAttributes : AttributeMethods : MethodDependencys : Dependency
Create( )Destroy( )GetName( )GetSuperClass( )
1 0..*
1
1..*
0..* TMethod
Name : StringRetorno : String = VoidVisible : StringParameters : Attribute = TList.Create
Create( )Destroy( )GetResult( )GetName( )
10..*
TAttribute
Name : StringTipo : StringVisible : String
Create( )GetTipo( )GetName( )GetDefault( )
1..*
0..*
31
A classe TRRFile é responsável por ler as informações do arquivo MDL da ferramenta
CASE Rational Rose, assim tendo seus atributos e métodos.
Os atributos e os métodos da classe TRRFile são:
a) Fline – contém o valor do número da linha do arquivo texto aberto;
b) FCountAbreParanteses – contém a quantidade de parênteses abertos contido pelo
arquivo fonte MDL;
c) FcountFechaParenteses – contém a quantidade de parênteses fechados contido pelo
arquivo fonte MDL;
d) SL – contém o arquivo texto MDL, que é uma lista de string;
e) Dictionary – contém a classe TDictionary;
f) SLODQL – contém o arquivo texto ODQL;
g) GetObjectName() – função que retorna o nome do objeto referido pelo parâmetro,
retirando os caracteres de controle da linguagem object Pascal;
h) CountToken() – função que retorna a quantidade de token;
i) DeleteSubStr() – função que retorna uma string sem o caracter recebido como
parâmetro;
j) ReadMethods() – procedure responsável por ler os métodos do diagrama de classe
especificado pelo Rational Rose;
k) ReadSuperClasses() – procedure responsável por ler a super classe de uma classe;
l) ReadAttributes() – procedure responsável por ler os atributos da classe;
m) ReadAssociations() – procedure responsável por ler as associações entre duas
classes especificadas;
n) ReadParameters() – procedure responsável por ler os parâmetros e resultados dos
métodos descritos no arquivo MDL;
o) ReadDependecys() – procedure responsável por ler as relações entre as classes no
diagrama de classe;
p) Create() – operação responsável por criar a classe TRRFile;
q) Destroy() – libera o espaço em memória que a classe está utilizando;
r) ReadClasses() – procedure responsável por ler as classes contidas no arquivo texto
MDL;
s) RetiraCifrao() – função que retira um “$” de um string e retorna um string;
32
t) OdqlGeneration() – função para gerar o código fonte ODQL.
Os atributos e métodos da classe TDictionary são:
a) Associations – contém uma lista de TAssociation;
b) Classes – contém uma lista de Tclasse;
c) Create() - operação responsável por criar uma instância a classe TDictionaty;
d) Destroy() - libera o espaço em memória que a classe está utilizando;
e) LiberaMemoria() – procedure responsável por liberar memória alocada para as
associações e para as classes.
Os atributos e métodos da classe TClasse são:
a) Name – contém o nome da classe;
b) SuperClass – contém o nome da classe filha da relação generalização;
c) SuperClassRelationName – contém o nome da relação do atributo SuperClass;
d) Attributes – contém uma lista de atributos;
e) Methods – contém uma lista de métodos;
f) Dependencys – contem uma lista de relações;
g) Create() - operação responsável por criar uma instância a classe TClasse;
h) Destroy() - libera o espaço em memória que a classe está utilizando;
i) Getname() – método para pegar o Name;
j) GetSuperClass() – método para pegar o SuperClass().
Os atributos e métodos da classe TAssociation são:
a) Nome – descritivo da associação;
b) RoleA – contém a classe TRole;
c) RoleB – contém a classe TRole;
d) Create() - operação responsável por criar uma instância a classe TAssociation.
Os atributos e métodos da classe TRole são:
a) Name – contém o nome da regra da relação;
b) Supplier - contém a descrição do regra;
c) Cardinality – contém a cardinalidade em cada regra;
e) Create() - operação responsável por criar uma instância a classe TRole;
33
f) GetSupplier() – método para pegar o Supplier;
g) Getname() – método para pegar o Name.
Os atributos e métodos da classe TAttribute são:
a) Name – Nome do atributo da classe;
b) Tipo – Tipo do atributo da classe;
c) Visible – Tipo de visibilidade da classe;
d) Create() - operação responsável por criar uma instância a classe TAttribute;
e) GetTipo() – método para pegar o Tipo;
f) GetName() – método para pegar o Name;
g) GetDefault() – método para pegar o valor Default;
Os atributos e métodos da classe TMethod são:
a) Name: nome do método;
b) Result – tipo de resultado do método;
c) Visible – tipo de visibilidade do método;
d) Parameters – contém uma lista de parâmetros do método;
e) Create() - operação responsável por criar uma instância a classe TMethod;
f) Destroy() - libera o espaço em memória que a classe está utilizando.
g) GetResult() – método para pegar o Result;
h) GetName() – método para pegar o Name.
Os atributos e métodos da classe TDependency são:
a) Name – contém o nome da relação entre duas classes;
b) Supplier – contém o descritivo da relação;
c) SupplierCardinality – contém a cardinalidade da primeira classe da relação;
d) ClientCardinality – contém a cardinalidade da segunda classe da relação;
e) Create() - operação responsável por criar uma instância a classe TDependency.
f) GetSupplier() – método para pegar o Supplier;
g) GetName() – método para pegar o Name.
Para simplificar a implementação, todas as agregações do modelo foram
implementadas através de listas com acesso público. Desta forma, qualquer parte do código-
34
fonte que possuir acesso a um objeto da classe-todo, consegue também acessar objetos da
classe-parte (exemplo: TAssociation e TRole).
4.2.3 DIAGRAMA DE SEQUÊNCIA
Segundo Hafemann (2000), um diagrama de seqüência mostra a colaboração dinâmica
entre vários objetos de um sistema. O mais importante aspecto deste diagrama é que a partir
dele percebe-se a seqüência de mensagens enviadas entre os objetos. Ele mostra a interação
entre os objetos, algumas coisa que acontecerá em um ponto específico da execução do
sistema.O diagrama de seqüência da leitura do arquivo MDL é visualizado na figura 13.
Observa-se no diagrama que o analista interage com o protótipo, sendo primeiramente
disparado a criação da classe TRRFile, que consiste o arquivo MDL. Após a criação da classe
TRRFile são disparados todas as classes.
Figura 10 - DIAGRAMA DE SEQUÊNCIA – LER ARQUIVO MDL
Analista : AnalistaDictionaty : TDictionary
RRFile : TRRFile
Classes : TClasse
Association : TAssociation
Role : TRole Dependency : TDependency
Attibute : TAttribute
Method : TMethod
Create ( Create (
IsValid (
LiberaMemoria (
ReadClasses ( Create (
Create (
Create (
Create (
Create (
Create (
ReadMethods (Classe)
ReadAttributes
ReadDependencys
ReadAssociations (Dictionary)
RetiraCifrao (String)
35
Na geração do código ODQL é mostrado na figura 11 o diagrama de seqüência. O
analista dispara uma mensagem para a classe TRRfile para a geração do código. A classe
Rrfile dispara mensagens para as outra classes envolvidas para a geração do código.
Figura 11 - DIAGRAMA DE SEQÜÊNCIA – GERAR CODIGO OD QL
: Analista : TRRFile : TClasse : TAttribute : TMethod : TRole : TDependency
ODQLGeneration (String, String) GetName ( )
GetSuperClass ( )
GetTipo ( )
GetName ( )
GetDefault ( )
GetResult ( )
GetName ( )
GetTipo ( )
GetName ( )
GetSupplier ( )
GetName ( )
GetSupplier ( )
GetName ( )
GetName ( )
GetName ( )
4.3 IMPLEMENTAÇÃO
Considerações sobre as técnicas utilizadas para implementação do protótipo, bem
como a forma de operação do mesmo, serão apresentadas nesta seção.
36
4.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS
O protótipo de software que permite a integração da ferramenta CASE Rational Rose
com o banco de dados Jasmine foi desenvolvido utilizando o ambiente de desenvolvimento
Borland Delphi 5.0 com a linguagem de programação Object Pascal.
No desenvolvimento do protótipo foi utilizada a orientação a objeto com o auxilio da
técnica UML, permitindo uma visão bem clara dos componentes que compõe o protótipo,
além de facilitar a manutenção do código fonte.
A seguir serão apresentados detalhes sobre a leitura do arquivo MDL e sobre o
ambiente de geração do código fonte ODQL.
4.3.1.1 LEITURA DO ARQUIVO MDL DO RATIONAL ROSE
O arquivo texto MDL contém uma estrutura bem definida por parte da ferramenta
CASE Rational Rose, contendo palavras reservadas do arquivo MDL, dando possibilidade de
identificação da informação desejada. Por exemplo, a palavra reservada “object Class”
identifica que logo após deverá conter o nome da classe especificada dentro do ambiente
Logical View do Rational Rose. Tendo identificado todas as palavras reservadas do arquivo
MDL, você poderá identificar as classes, atributos, métodos e relações entre as classes.
No anexo 2 é apresentado um trecho da unit que tem como objetivo ler o arquivo
MDL.
4.3.1.2 AMBIENTE DE GERAÇÃO DE CÓDIGO FONTE ODQL
O ambiente de geração de código fonte ODQL foi baseado na BNF da linguagem
nativa do banco de dados Jasmine. No anexo 5 é apresentado o código fonte da procedure
GerarcdigoODQL1Click.
Na seção seguinte são apresentados os passos de configuração da ferramenta Rational
Rose e operação do protótipo para que seja feita a geração do código fonte através do
protótipo.
37
4.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO
O processo para a geração do código fonte utilizando o protótipo está dividido em três
partes:
a) criação do diagrama de classes na ferramenta CASE Rational Rose;
b) geração do código fonte através do protótipo;
c) compilar o arquivo gerado no banco de dados Jasmine.
4.3.2.1 ESTUDO DE CASO
Para exemplificar a utilização do protótipo foi elaborado um estudo de caso de um
controle de pesca, obtido de exercícios de Análise de Sistemas e Projeto I do Professor
Everaldo Artur Grahl (Universidade Regional de Blumenau - FURB). O enunciado do estudo
de caso é mostrado no quadro 7.
Quadro 7 - ESTUDO DE CASO Uma entidade ambientalista resolve decidiu criar um banco de dados de informações de pesca para disponibilizar dados a pescadores, entidades de pesquisa e a comunidade em geral. Foi realizado um Censo onde foram coletadas as seguintes informações: Dados sobre embarcações: proprietário, nome da embarcação, comprimento, inscrição na capitania dos portos, ano construção. O proprietário poderá ser uma pessoa física ou jurídica, no primeiro caso, serão armazenados seu nome, endereço, CPF, apelido, município, e no segundo caso, nome, endereço, CNPJ, município; As embarcações podem ser para pesca artesanal ou industrial. Quando for barco para pescaria industrial, devem ser armazenados dados como a capacidade de estocagem e se possui tanque de isca. No caso da pesca artesanal devem ser informados o tipo de material do casco e o tipo de propulsão do barco (motor, vela, remo, etc.); Para cada embarcação serão armazenados os diversos tipos de petrechos de pesca utilizados (rede, caniço, etc.) e também o tipo de conservação do pescado (refrigerado, sem refrigeração, etc.) Cabe aos pesquisadores o cadastramento das espécies de animais encontrados na área marítima considerada pelo sistema (litoral Catarinense). Os fiscais vão informar os dados coletados sobre as pescas, que foram anotados nos pontos de desembarque, registrando a data, hora, embarcação e para cada espécie capturada, será registrado seu nome vulgar, quantidade em quilos e petrecho utilizado para captura. Ao informar um nome vulgar, o sistema irá automaticamente associá-lo a espécie correspondente. Sobre as pescas realizadas (desembarques), o sistema disponibilizará somente estatísticas aos pesquisadores, informando, para cada espécie a quantidade total pescada por período (ano/mês).
38
Antes de iniciar a criação do diagrama de classes, no Rational Rose, deve-se configurar
a ferramenta para trabalhar com o método unificado, que pode ser acessada através do menu
View, mostrado na figura 12. Em relação aos nomes dos atributos, classes, métodos e relações,
não serão possíveis colocar acentuação, pois a linguagem ODQL tem restrições para acento.
Figura 12 - CONFIGURAÇÃO DA FERRAMENTA CASE RATIONA L ROSE
Primeiramente foi criado o diagrama de classe no Rational Rose, salvando-o em um
diretório qualquer. A figura 13 apresenta o diagrama de classes para este estudo de caso.
Após esta operação, executa-se o protótipo. Uma vez dentro do protótipo, indica-se
onde se encontra o diagrama de classe clicando no botão “abrir um arquivo MDL”. O
protótipo vai varrer todo o arquivo MDL, mostrando os dados do diagrama de classes e suas
relações. No anexo 4 encontra-se o arquivo MDL do estudo de caso.
As classes do diagrama de classes são relacionadas em uma árvore mostrada no canto
esquerdo superior da tela do protótipo, mostrado na figura 14. Você pode selecionar qualquer
39
uma das classes para consultar os atributos, métodos e relações. As relações entre as classes
do protótipo mostram somente as “Associações”, “Agregação”, “Dependência” e
“Generalização”. Os atributos, métodos e relações podem ser vistos na figura 15.
Na tela inferior do protótipo aparece um “Memo” do arquivo fonte do MDL,
aparecendo a estrutura que o Rational Rose gera após uma especificação de seus diagramas.
Figura 13 - DIAGRAMA DE CLASSE DO ESTUDO DE CASO
Ao lado da árvore das classes existe mais uma árvore de associações, onde visa
mostrar as associações entre as classes envolvidas no diagrama de classes menos a
“generalização”. Quando você define uma generalização na ferramenta Rational Rose, você
não coloca suas cardinalidades entre as pontas das duas classes. Com isto o protótipo mostra o
“Role A” e o “Role B”, que você definiu no CASE. No protótipo você pode percorrer toda a
árvore selecionando cada nome da associação e ao lado você tem o “Role A” e o “Role B” da
associação selecionada, pode ser visualizado na figura 15.
40
Figura 14 - TELA DA ÁRVORE DAS CLASSES E ARQUIVO MD L
Para gerar o código fonte do ODQL no banco Jasmine, você precisa antes gerar o
depósito e a classe família onde serão incluídos as classes dentro do Jasmine. Você pressiona
o botão “Gerar Classe Família” para entrar na tela de criação do depósito e define a Class
Family, o depósito (Store), mostrado na figura 16.
Abaixo dos campos do Store e Class Family aparece um campo Memo mostrando os
comandos básicos para executar o processo de criação da classe família definida pelo usuário.
O primeiro comando “jaslockstat.exe” força o banco travar sua base de dados para que o
desenvolvedor possa criar e deletar seus depósitos e suas Class Family.
O comando “createStore TCC %JAS_SYSTEM%\jasmine\data\TCC” cria o depósito
com o nome de “TCC” no diretório setado pelo banco Jasmine. O comando também mostrado
na figura 16, “createcf TCC2001CF TCC” visa criar a Class Family com o nome
41
“TCC2001CF”, que depois dentro do banco você pode manipular. O comando “codqlie -
execFile TCC.odql” compila o código fonte gerado pelo protótipo.
O botão “Salvar”, mostrado na figura 16, salva os comandos descritos anteriormente
em um arquivo bat.
Figura 15 - TELA DA ÁRVORE DAS ASSOCIAÇÕES
42
Figura 16 – TELA DA CLASSE FAMÍLIA DENTRO DO PROTÓT IPO
No menu principal tem o item “Ferramentas – Gerar código ODQL”, você executa
para que se crie o código fonte ODQL, mostrado na figura 17. Este código gerado contém a
criação das classes descritas no arquivo MDL, juntamente com os atributos, métodos e
relações entre suas classes. O botão “Salvar” na tela, salva o arquivo ODQL em um arquivo
texto no próprio diretório que você salvou o arquivo bat. O nome do arquivo ODQL é o
mesmo que o nome do “Store”. Se não ocorrer nenhum erro de gravação em disco, aparecerá
uma mensagem confirmando sua gravação com sucesso.
43
Figura 17 - TELA DO CÓDIGO ODQL
Depois de gerado o script ODQL visto no anexo 5, Passa-se a acessar o menu
“Ferramentas – Compilar arquivo ODQL”, para executar o arquivo bat criado dentro do
protótipo, que pode ser visto na figura 15. No decorrer do processo do arquivo bat, vai ser
mostrado o resultado de cada comando. Por exemplo, quando você executa o comando
“ jaslockstat.exe” vai aparecer no prompt o resultado.
Se os comandos executarem com sucesso, o banco está pronto para receber classes no
seu depósito. Para que o depósito e a Class Family, sejam criados, o usuário tem que se
conectar no banco Jasmine e em seguida sair do banco, mostrado na figura 17.
44
Figura 18 - TELA PARA EXECUTAR O ARQUIVO BAT
Figura 19 - EXECUTAR O BANCO JASMINE
45
Após entrar no banco Jasmine você precisa se logar no banco. Podem existir várias
conexões. A figura 20 mostra a tela para entrar em uma conexão.
Figura 20 - TELA PARA ENTRA EM UMA CONEXÃO
O resultado do código ODQL compilado pelo banco é mostrado na figura 21. Na tela
do Jasmine “Jasmine Class Brower” é mostrado ao lado esquerdo todas as classes criadas a
partir do arquivo MDL. Mais ao lado são mostrados os métodos da classe selecionada. Na tela
“Jasmine Class Property Inspector” são mostrados seus atributos na classe selecionada e suas
relações com as outras classes.
46
Figura 21 - TELA DO BANCO JASMINE COM AS CLASSES CRIADAS
4.4 RESULTADOS E DISCUSSÃO
Algumas limitações do presente protótipo são:
a) o tipo de método das classes gerados no arquivo ODQL é em nível de instância, não
dando suporte em nível de classe e em nível de coleção;
b) na leitura do arquivo fonte MDL, fica limitado a obtenção de algumas
características do diagrama de classe não sendo possível caracterisiticas como
stereotype da classe, containment do atributo, stereotype da relação entre classes,
detalhes sobre as regras da relação e também sobre pacotes;
c) outra limitação é com referência apenas a geração do código-fonte na linguagem
ODQL.
47
Para a implementação da interface, leitura e geração do código fonte foi utilizado a
ferramenta Delphi 5.0 respectivamente com seus componentes e a linguagem de programação
Object Pascal. Na tela principal mostrado na figura 14 é composta de vários componentes que
é um MainMenu, um ImageList, um Opendialog, um ToolBar, um TreeView, um ListView,
dois PagesControl e um Memo para visualizar o arquivo fonte MDL.
48
5 CONCLUSÕES
Com relação ao protótipo, ele atingiu o seu objetivo principal, o qual era a obtenção do
diagrama de classes a partir do arquivo fonte MDL do Rational Rose e a geração do código
ODQL para a criação de classes, atributos, métodos e relacionamentos entre classes.
A ferramenta CASE Rational Rose tem um repositório em um arquivo texto chamado
Object Petal. O arquivo está organizado de tal forma que o desenvolvedor tem acesso a
qualquer informação dos diagramas especificados pela ferramenta.
A configuração e a conexão do Banco de Dados Jasmine é consideravelmente fácil,
mesmo sendo restrito a sua documentação. A linguagem ODQL do banco Jasmine é uma
ferramenta indispensável para o banco, porém tem algumas limitações como, por exemplo,
não permite algumas acentuações nos nomes das classes, atributos e métodos. Também
constatou-se que se o desenvolvedor nomear um atributo “Data”, a linguagem ODQL não
aceita, dizendo que a palavra “Data” é reservada a linguagem.
Em relação a outros trabalhos já desenvolvidos nesta linha pode-se comentar que este
trabalho seguiu os objetivos pretendidos pelo trabalho do Kramel (2000). Naquele trabalho o
objetivo foi a geração de código CDL (Class Definition Language) para banco de dados
Caché a partir do repositório da ferramenta CASE System Architect. No presente trabalho o
objetivo foi a geração do código ODQL para o banco Jasmine a partir do arquivo MDL da
ferramenta CASE Rational Rose. Já em relação ao trabalho de Wehrmeister (2001), o mesmo
se mostrou mais amplo porque permite a geração para qualquer linguagem.
O trabalho do Uessler (1999), obteve-se muito aproveitoso, pois as informações sobre
o banco Jasmine facilitaram para a realização deste trabalho.
Uma das vantagens do trabalho é a integração da Ferramenta CASE Rational Rose
para o BDOO Jasmine, porque dá maior suporte ao analista que, apenas precisa especificar
qualquer aplicação que por sua vez gera a base de dados para o banco Jasmine.
As dificuldades encontradas ao longo do trabalho foram primeiramente a técnica e o
algoritimo para a leitura do arquivo MDL do CASE Rational Rose. Outra dificuldade
49
encontrada foi em relação ao banco Jasmine. O banco Jasmine não permite manipular os Store
e a Class Family sem antes travar o banco com o comando “JaslockStat”, com isto teve que
manipular o banco Jasmine com muita percistência, pois a documentação encontrada não
relata estes detalhes.
5.1 EXTENSÕES
Para extensões deste trabalho sugere-se:
a) especificar uma metalinguagem para ler a BNF do ODQL;
b) possibilitar que o protótipo crie os métodos no nível de classe e no nível de coleção;
c) possibilitar também que o usuário possa criar as próprias procedures em ODQL
para que o banco Jasmine compile para já incorporar nas classes criadas.
50
ANEXO 1- BNF PARA CRIAR UMA CLASSE EM ODQL defineClass-command->defineClass class-identifier [ super «:» class-identifier [{«,» class-identifier}...]] [descriptio n «:» string-constant] «{» [maxInstanceSize «:» size «;»] caracteristics « }» «;» class-identifier->[class-family-name «::»] class-na me class-family-name->name name->alphabetic {alphanumeric}...| «'» alphabetic{ alphanumeric}...«'» /* maximum 32 characters in total*/ alphabetic->{A..Z|a..z|«_»} alphanumeric->{0..9|A..Z|a..z|«_»} class-name->name string-constant->«"»[{character-representation}...] «"» character-representation->/* a printable character other than " or \, or one of the special characters \\,\",\a, \b, \f, \n, \r,\t,\v, or an octal code written as \o, \oo, or \ooo, or a haxadecimal code written as \xhh*/ size->digits /*the size in KB;value 4 to 256, inclu sive */ digits->{0..9}... characteristics->[{level «:» { characteristic «;» } ...}...}...] level->class | instance | collection-type «<» class | instance «>» collection-type->Bag|set|List|array characteristic-> property-definition | method-defin ition property-definition->data-type property-name proper ty-details data-type->simple-data-type | collection-type-quali fied «<» simple-data-type «>» iterator «<» simple-data-type «>» simple-data-type->composite-class-identifier [class ] | literal-data-type composite-class-identifier->class-identifier literal-data-type->Boolean|ByteSequence [«[»length «]»]|Date|Decimal «[»precision «,» scale «]»|Integer|Real|String [«[» length «]»] length->digits precision->digits scale->digits collection-type-qualified->Bag|Set|List|array «[»di gits «]»
51
property-name->name property-details->[mandatory «:»] [default«:» const ant] [description «:» string-constant] [ unique«:»] constant->single-constant | collection-constant single-constant->boolean-constant|bytesequence-cons tant|decimal-constant|integer-constant|real-contant|string-conta nt|nil boolean-constant->true|false bytesequence-constant->«X» «"» {hexchar hex-char}.. .«"» hexchar->{0..9|a..f} decimal-constant->[sign]{digits «.» digits | «.» di gits | digits «.»} sing->«+» | «-» integer-constant->[sing]digits real-contant->decimal-constant «e» sing digits collection-constant->[collection-type] «{» [ single -constant-list]«}» single-constant-list->single-constant[{«,»single-co nstant}...] method-definition->return-class method-name «(» [pa rameter-specification-list] «)» method-details return-class->specific-return-class | void specific-return-class->data-type method-name->name parameter-specification-list->parameter-specificati on [{«,»parameter-specication}...] parameter-specification->data-type parameter-name [ «:=»constant] parameter-name->name method-details->[description «:» string-constant] buildClass-command->buildClass{class-identifier}... «;»
52
ANEXO 2- CÓDIGO FONTE PARA LER O ARQUIVO MDL
unit URRFile; interface uses Classes, UDictionary, UClasse, UAssociation, URol e, UAttribute, UMethod, UDependency; const DEF_VERSION = ' version 40 )'; DEF_LOGICAL_VIEW = 'object Class_Categ ory "Logical View"'; DEF_CLASS = 'object Class '; DEF_QUID = 'quid'; DEF_OPERATION = 'operations'; DEF_RESULT = 'result'; DEF_OPERATION_VISIBLE = 'opExportControl'; DEF_ATTRIBUTE_VISIBLE = 'exportControl'; DEF_SUPER_CLASS = 'superclasses'; DEF_SUPPLIER = 'supplier'; DEF_INHERITANCE = 'object Inheritance _Relationship'; DEF_ATTRIBUTE = 'object ClassAttrib ute '; DEF_OPERATION_NAME = 'object Operation ' ; DEF_DEPENDENCY = 'object Uses_Relati onship'; DEF_OBJ_PARAMETER = 'object Parameter'; DEF_OBJ_ASSOCIATION = 'object Association '; DEF_TYPE = 'type'; DEF_INITIAL_VALUE = 'initv'; DEF_CLASS_ATTRIBUTES = 'class_attributes'; DEF_PARAMETERS = 'parameters'; DEF_ROLE_LIST = 'list role_list'; DEF_OBJECT_ROLE = 'object Role'; DEF_OBJECT_ROLE_SUPPLIER = 'supplier '; DEF_OBJECT_ROLE_CARDINALITY = 'client_cardinality (value cardinality '; DEF_USED_NODES = 'used_nodes'; DEF_SUPPLIER_CARDINALITY = 'supplier_cardinali ty (value cardinality '; DEF_CLIENT_CARDINALITY = 'client_cardinality (value cardinality '; DEF_SUPPLIER_RELATION_NAME = 'label'; DEF_AGGREGATE = 'is_aggregate '; type TRRFile = class private FLine: Integer; FCountAbreParenteses, FCountFechaParenteses: Integer; function GetObjectName(Def, Str: String): Strin g; function CountToken(Token, S: string): Integer; function DeleteSubStr(SubStr, Str: String): Str ing; procedure ReadMethods(var Classe: TClasse); procedure ReadSuperClasses(var Classe: TClasse) ; procedure ReadAttributes(var Classe: TClasse); procedure ReadAssociations(var Dictionary: TDic tionary);
53
procedure ReadParameters(var Method: TMethod); procedure ReadDependencys(var Classe: TClasse); function RetiraCifrao(const S: String): String; public SL: TStringList; SLODQL: TStringList; Dictionary: TDictionary; constructor Create; destructor Destroy; override; function IsValid: Boolean; procedure ReadClasses; procedure ODQLGeneration(const NomeArquivo, CFN ame: String); end; implementation { TRRFile } function TRRFile.CountToken(Token, S: string): Inte ger; var P, Count: Integer; begin Count:= 0; P:= Pos(Token, S); while P > 0 do begin Count:= Count + 1; Delete(S, P, Length(Token)); P:= Pos(Token, S); end; Result:= Count; end; constructor TRRFile.Create; begin SL:= TStringList.Create; SLODQL:= TStringList.Create; Dictionary:= TDictionary.Create; end; destructor TRRFile.Destroy; begin Dictionary.Free; SL.Free; SLODQL.Free; inherited Destroy; end; procedure TRRFile.ReadClasses; var Classe: TClasse; begin FLine:= 0; while (FLine <= SL.Count-1) do begin // Logical View if (Pos(DEF_LOGICAL_VIEW, SL[FLine]) > 0) then
54
begin Classe:= nil; FCountAbreParenteses:= 0; FCountFechaParenteses:= 0; repeat FCountAbreParenteses:= CountToken('(', SL[ FLine]) + FCountAbreParenteses; FCountFechaParenteses:= CountToken(')', SL[ FLine]) + FCountFechaParenteses; // Operation if (Pos(DEF_OPERATION, SL[FLine]) > 0) then ReadMethods(Classe) else // Super-Class if (Pos(DEF_SUPER_CLASS, SL[FLine]) > 0) then ReadSuperClasses(Classe) else // Attribute if (Pos(DEF_CLASS_ATTRIBUTES, SL[FLine] ) > 0) then ReadAttributes(Classe) else // Relations if (Pos(DEF_USED_NODES, SL[FLine]) > 0) then ReadDependencys(Classe) else // Class if (Pos(DEF_CLASS, SL[FLine]) > 0) then begin if (Classe <> nil) then Dictionary.Classes.Add(Classe); Classe:= TClasse.Create; Classe.Name:= GetObjectName(DEF_C LASS, SL[FLine]); FLine:= FLine + 1; end else // Association if (Pos(DEF_OBJ_ASSOCIATION, SL[F Line]) > 0) then ReadAssociations(Dictionary) else FLine:= FLine + 1; until (FCountAbreParenteses = FCountFechaPare nteses); if Classe <> nil then Dictionary.Classes.Add(Classe); end; FLine:= FLine + 1; end; end; function TRRFile.GetObjectName(Def, Str: String): S tring; var P: Integer; begin {retira #9} Str:= DeleteSubStr(#9, Str); P:= Pos(DEF,str); Delete(Str, 1, P + Length(Def)-1); {retira as aspas} Str:= DeleteSubStr('"', Str); {retira espacos}
55
Str:= DeleteSubStr(' ', Str); {retira )} Result:= DeleteSubStr(')', Str); end; function TRRFile.RetiraCifrao(const S: String): Str ing; var I: Integer; Retirados: Integer; begin Result:= S; Retirados:= 0; for I:= 1 to Length(S) do if S[I] = '$' then begin Delete(Result, I-Retirados, 1); Retirados:= Retirados + 1; end; end; procedure TRRFile.ReadAssociations(var Dictionary: TDictionary{; var S: string}); var CountAbreParenteses, CountFechaParenteses: Integer; C1, C2:integer; //soma o parentes da 1º linha que ja foram somados Association: TAssociation; Role: TRole; RoleAux: TRole; begin Association:= nil; CountAbreParenteses:=0; CountFechaParenteses:=0; C1:= CountToken('(', SL[FLine]); C2:= CountToken(')', SL[FLine]); repeat CountAbreParenteses:= CountToken('(', SL[FLine ]) + CountAbreParenteses; CountFechaParenteses:= CountToken(')', SL[FLine ]) + CountFechaParenteses; if (Pos(DEF_OBJ_ASSOCIATION, SL[FLine]) > 0) th en begin if Association <> nil then begin { Corrige a cardinalidade } if Association.RoleB.Cardinality <> '1' the n begin RoleAux:= Association.RoleA; Association.RoleA:= Association.RoleB; Association.RoleB:= RoleAux; end; Dictionary.Associations.Add(Association); end; Association:= TAssociation.Create; Association.Name:= RetiraCifrao(GetObjectName (DEF_OBJ_ASSOCIATION, SL[FLine])); end else if (Pos({DEF_ROLE_LIST}DEF_OBJECT_ROLE, SL[FL ine]) > 0) then // list role_list begin
56
Role:= TRole.Create; Role.Name:= RetiraCifrao(GetObjectName({DEF _ROLE_LIST}DEF_OBJECT_ROLE, SL[FLine])); if Association.RoleA = nil then Association.RoleA:= Role else Association.RoleB:= Role; end else if (Pos(DEF_OBJECT_ROLE_SUPPLIER, SL[FLine] ) > 0) then //supplier "Logical View: begin if Association.RoleB = nil then Association.RoleA.Supplier:= GetObjectN ame(DEF_OBJECT_ROLE_SUPPLIER, SL[FLine]) else Association.RoleB.Supplier:= GetObjectN ame(DEF_OBJECT_ROLE_SUPPLIER, SL[FLine]); end else if (Pos(DEF_OBJECT_ROLE_CARDINALITY, SL[F Line]) > 0) then begin if Association.RoleB = nil then Association.RoleA.Cardinality:= GetObjectName(DEF_OBJECT_ROLE_CARDINALITY, SL[FLine ]) else Association.RoleB.Cardinality:= GetObjectName(DEF_OBJECT_ROLE_CARDINALITY, SL[FLine ]); end else if (Pos(DEF_AGGREGATE, SL[FLine]) > 0) then begin if Association.RoleB = nil then Association.RoleA.IsAggregate:= Tru e else Association.RoleB.IsAggregate:= Tru e; end; FLine:= FLine + 1; until (CountAbreParenteses = CountFechaParenteses ); if Association <> nil then begin { Corrige a cardinalidade } if Association.RoleB.Cardinality <> '1' then begin RoleAux:= Association.RoleA; Association.RoleA:= Association.RoleB; Association.RoleB:= RoleAux; end; Dictionary.Associations.Add(Association); end; FCountAbreParenteses:= CountAbreParenteses + FC ountAbreParenteses - C1; FCountFechaParenteses:= CountFechaParenteses + FC ountFechaParenteses - C2; end; procedure TRRFile.ReadAttributes(var Classe: TClass e); var CountAbreParenteses,
57
CountFechaParenteses: Integer; C1, C2: Integer; //soma o parentes da 1º linha qu e ja foram somados Attribute: TAttribute; begin Attribute:= nil; CountAbreParenteses:= 0; CountFechaParenteses:= 0; C1:= CountToken('(', SL[FLine]); C2:= CountToken(')', SL[FLine]); repeat CountAbreParenteses:= CountToken('(', SL[FLine ]) + CountAbreParenteses; CountFechaParenteses:= CountToken(')', SL[FLine ]) + CountFechaParenteses; if (Pos(DEF_TYPE, SL[FLine]) > 0) then Attribute.Tipo:= GetObjectName(DEF_TYPE, SL[ FLine]); if (Pos(DEF_ATTRIBUTE_VISIBLE, SL[FLine]) > 0) then Attribute.Visible:= GetObjectName(DEF_ATTRIBU TE_VISIBLE, SL[FLine]); if (Pos(DEF_INITIAL_VALUE, SL[FLine]) > 0) then Attribute.Default:= GetObjectName(DEF_INITIAL _VALUE, SL[FLine]); if (Pos(DEF_ATTRIBUTE, SL[FLine]) > 0) then begin if Attribute <> nil then Classe.Attributes.Add(Attribute); Attribute:= TAttribute.Create; Attribute.Name:= GetObjectName(DEF_ATTRIBUTE, SL[FLine]); end; FLine:= FLine + 1; until (CountAbreParenteses = CountFechaParenteses ) or (CountAbreParenteses = CountFechaParenteses-1); if Attribute <> nil then Classe.Attributes.Add(Attribute); FCountAbreParenteses:= CountAbreParenteses + FC ountAbreParenteses - C1; FCountFechaParenteses:= CountFechaParenteses + FC ountFechaParenteses - C2; end; procedure TRRFile.ReadMethods(var Classe: TClasse); var CountAbreParenteses, CountFechaParenteses: Integer; C1, C2: Integer; //soma o parentes da 1º linha qu e ja foram somados Method: TMethod; begin Method:= nil; CountAbreParenteses:= 0; CountFechaParenteses:= 0; C1:= CountToken('(', SL[FLine]); C2:= CountToken(')', SL[FLine]); repeat CountAbreParenteses:= CountToken('(', SL[FLine ]) + CountAbreParenteses; CountFechaParenteses:= CountToken(')', SL[FLine ]) + CountFechaParenteses; if (Pos(DEF_RESULT, SL[FLine]) > 0) then Method.Retorno:= GetObjectName(DEF_RESULT, SL [FLine]); if (Pos(DEF_OPERATION_VISIBLE, SL[FLine]) > 0) then Method.Visible:= GetObjectName(DEF_OPERATION_ VISIBLE, SL[FLine]); if (Pos(DEF_PARAMETERS, SL[FLine]) > 0) then if (Method <> nil) then begin CountAbreParenteses:= CountAbreParenteses - CountToken('(', SL[FLine]);
58
ReadParameters(Method); end; if (Pos(DEF_OPERATION_NAME, SL[FLine]) > 0) the n begin if (Method <> nil) then Classe.Methods.Add(Method); Method:= TMethod.Create; Method.Name:= GetObjectName(DEF_OPERATION_NAM E, SL[FLine]); end; FLine:= FLine + 1; until (CountAbreParenteses <= CountFechaParentese s); if (Method <> nil) then Classe.Methods.Add(Method); FCountAbreParenteses:= CountAbreParenteses + FC ountAbreParenteses - C1; FCountFechaParenteses:= CountFechaParenteses + FC ountFechaParenteses - C2; end; procedure TRRFile.ReadParameters(var Method: TMetho d{; var S: String}); var CountAbreParenteses, CountFechaParenteses: Integer; Attribute: TAttribute; begin Attribute:= nil; CountAbreParenteses:= 0; CountFechaParenteses:= 0; repeat CountAbreParenteses:= CountToken('(', SL[FLine ]) + CountAbreParenteses; CountFechaParenteses:= CountToken(')', SL[FLine ]) + CountFechaParenteses; if (Pos(DEF_TYPE, SL[FLine]) > 0) then Attribute.Tipo:= GetObjectName(DEF_TYPE, SL[F Line]); if (Pos(DEF_OBJ_PARAMETER, SL[FLine]) > 0) then begin if (Attribute <> nil) then Method.Parameters.Add(Attribute); Attribute:= TAttribute.Create; Attribute.Name:= GetObjectName(DEF_OBJ_PARAME TER, SL[FLine]); end; FLine:= FLine + 1; until (CountAbreParenteses <= CountFechaParentese s); FLine:= FLine - 1; if Attribute <> nil then Method.Parameters.Add(Attribute); end; procedure TRRFile.ReadSuperClasses(var Classe: TCla sse{; var S: String}); var CountAbreParenteses, CountFechaParenteses: Integer; C1, C2: Integer; //soma o parentes da 1º linha qu e ja foram somados begin CountAbreParenteses:= 0; CountFechaParenteses:= 0; C1:= CountToken('(', SL[FLine]); C2:= CountToken(')', SL[FLine]); repeat CountAbreParenteses:= CountToken('(', SL[FLine ]) + CountAbreParenteses;
59
CountFechaParenteses:= CountToken(')', SL[FLine ]) + CountFechaParenteses; if (Pos(DEF_SUPPLIER, SL[FLine]) > 0) then Classe.SuperClass:= GetObjectName(DEF_SUPPLIE R, SL[FLine]); if (Pos(DEF_SUPPLIER_RELATION_NAME, SL[FLine]) > 0) then Classe.SuperClassRelationName:= GetObjectName (DEF_SUPPLIER_RELATION_NAME, SL[FLine]); FLine:= FLine + 1; until (CountAbreParenteses = CountFechaParenteses ) or (CountAbreParenteses = CountFechaParenteses-1); FCountAbreParenteses:= CountAbreParenteses + FC ountAbreParenteses - C1; FCountFechaParenteses:= CountFechaParenteses + FC ountFechaParenteses - C2; end; procedure TRRFile.ReadDependencys(var Classe: TClas se); var CountAbreParenteses, CountFechaParenteses: Integer; C1, C2: Integer; //soma o parentes da 1º linha qu e ja foram somados Dependency: TDependency; begin Dependency:= nil; CountAbreParenteses:= 0; CountFechaParenteses:= 0; C1:= CountToken('(', SL[FLine]); C2:= CountToken(')', SL[FLine]); repeat CountAbreParenteses:= CountToken('(', SL[FLine ]) + CountAbreParenteses; CountFechaParenteses:= CountToken(')', SL[FLine ]) + CountFechaParenteses; if (Pos(DEF_SUPPLIER, SL[FLine]) > 0) and not ( Pos(DEF_SUPPLIER_CARDINALITY, SL[FLine]) > 0) then Dependency.Supplier:= GetObjectName(DEF_SUPPL IER, SL[FLine]); if (Pos(DEF_SUPPLIER_CARDINALITY, SL[FLine]) > 0) then Dependency.SupplierCardinality:= GetObjectNam e(DEF_SUPPLIER_CARDINALITY, SL[FLine]); if (Pos(DEF_CLIENT_CARDINALITY, SL[FLine]) > 0) then Dependency.ClientCardinality:= GetObjectName( DEF_CLIENT_CARDINALITY, SL[FLine]); if (Pos(DEF_DEPENDENCY, SL[FLine]) > 0) then begin if (Dependency <> nil) then Classe.Dependencys.Add(Dependency); Dependency:= TDependency.Create; Dependency.Name:= RetiraCifrao(GetObjectName( DEF_DEPENDENCY, SL[FLine])); end; FLine:= FLine + 1; until (CountAbreParenteses <= CountFechaParentese s); if (Dependency <> nil) then Classe.Dependencys.Add(Dependency); FCountAbreParenteses:= CountAbreParenteses + FC ountAbreParenteses - C1; FCountFechaParenteses:= CountFechaParenteses + FC ountFechaParenteses - C2; end; function TRRFile.DeleteSubStr(SubStr, Str: String): String; var P: Integer; begin P:= Pos(SubStr, Str);
60
while (P > 0) do begin Delete(Str, P, 1); P:= Pos(SubStr, Str); end; Result:= Str; end; function TRRFile.IsValid: Boolean; begin Result:= (SL[2] = DEF_VERSION); end; procedure TRRFile.ODQLGeneration(const NomeArquivo, CFName: String); var I, J, K: Integer; Linha: String; procedure DeleteStr(var S: String; Index: Integer ; Count:Integer); begin Delete(S, Index, Count); end; begin with SLODQL do begin Clear; for I:= 0 to (Dictionary.Classes.Count-1) do begin { Define a classe família default } Add('defaultCF ' + CFName + ';'); { Define a classe } Linha:= 'defineClass ' + TClasse(Dictionary.C lasses[I]).GetName; if (TClasse(Dictionary.Classes[I]).GetSuperCl ass <> '') then Linha:= Linha + ' super: ' + TClasse(Dictio nary.Classes[I]).GetSuperClass; Add(Linha); Add('{'); Add(#9 + 'instance:'); { Define os atributos da classe } for J:= 0 to (TClasse(Dictionary.Classes[I]). Attributes.Count-1) do begin Linha:= #9#9 + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetTipo + #9#9 + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetName; if TAttribute(TClasse(Dictionary.Classes[I] ).Attributes[J]).GetDefault <> '' then if TAttribute(TClasse(Dictionary.Classes[ I]).Attributes[J]).GetTipo = 'String' then Linha:= Linha + #9 + 'default: "' + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetDefault + '"' else Linha:= Linha + #9 + 'default: ' + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetDefault; Linha:= Linha + ';'; Add(Linha); end; { Define os métodos da classe } for J:= 0 to (TClasse(Dictionary.Classes[I]). Methods.Count-1) do
61
begin Linha:= #9#9 + TMethod(TClasse(Dictionary.C lasses[I]).Methods[J]).GetResult + #9#9 + TMethod(TClasse(Dictionary.C lasses[I]).Methods[J]).GetName + #9 + '('; { Define os parâmetros do método } for K:= 0 to (TMethod(TClasse(Dictionary.Classes[I]).Methods[J]) .Parameters.Count-1) do Linha:= Linha + TAttribute(TMethod(TClasse(Dictionary.Classes[I ]).Methods[J]).Parameters[K]).GetTipo + ' ' + TAttribute(TMethod(TClasse(Dictionary.Classes[I]).M ethods[J]).Parameters[K]).GetName + ', '; if (TMethod(TClasse(Dictionary.Classes[I]). Methods[J]).Parameters.Count > 0) then DeleteStr(Linha, Length(Linha)-1, 2); Linha:= Linha + ');'; Add(Linha); end; { Define as relações - Dependências } for J:= 0 to (TClasse(Dictionary.Classes[I]). Dependencys.Count-1) do begin Linha:= #9#9 + CFName + '::' + TDependency(TClasse(Dictionary.Classes[I]).Dependen cys[J]).GetSupplier + #9#9 + TDependency(TClasse(Dictionary.Classes[I]).Dependen cys[J]).GetName + ';'; Add(Linha); end; { Define as relações - Associações } for J:= 0 to (Dictionary.Associations.Count-1 ) do begin if (TAssociation(Dictionary.Associations[J] ).RoleA.GetSupplier = TClasse(Dictionary.Classes[I]).GetName) then begin Linha:= #9#9 + CFName + '::' + TAssociation(Dictionary.As sociations[J]).RoleB.GetSupplier + #9#9 + TAssociation(Dictionary.As sociations[J]).RoleA.GetName + ';'; Add(Linha); end; end; Add('};'); Add(''); // Insere uma linha em branco end; { Define o comando de criação das classes } Linha:= 'buildClass '; for I:= 0 to (Dictionary.Classes.Count-1) do Linha:= Linha + CFName + '::' + TClasse(Dicti onary.Classes[I]).GetName + ' '; Linha:= Linha + ';'; Add(Linha); end; end; end.
62
ANEXO 3- CÓDIGO FONTE EM DELPHI PARA GERAR O CODIGO ODQL
procedure TRRFile.ODQLGeneration(const NomeArquivo, CFName: String); var I, J, K: Integer; Linha: String; procedure DeleteStr(var S: String; Index: Integer ; Count:Integer); begin Delete(S, Index, Count); end; begin with SLODQL do begin Clear; for I:= 0 to (Dictionary.Classes.Count-1) do begin { Define a classe família default } Add('defaultCF ' + CFName + ';'); { Define a classe } Linha:= 'defineClass ' + TClasse(Dictionary.C lasses[I]).GetName; if (TClasse(Dictionary.Classes[I]).GetSuperCl ass <> '') then Linha:= Linha + ' super: ' + TClasse(Dictio nary.Classes[I]) .GetSuperClass; Add(Linha); Add('{'); Add(#9 + 'instance:'); { Define os atributos da classe } for J:= 0 to (TClasse(Dictionary.Classes[I]). Attributes.Count-1) do begin Linha:= #9#9 + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetTipo + #9#9 + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetName; if TAttribute(TClasse(Dictionary.Classes[I] ).Attributes[J]). GetDefault <> '' then if TAttribute(TClasse(Dictionary.Classes[ I]).Attributes[J]). GetTipo = 'String' then Linha:= Linha + #9 + 'default: "' + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetDefault + '"' else Linha:= Linha + #9 + 'default: ' + TAttribute(TClasse(Dictionary.Classes[I]).Attribute s[J]).GetDefault; Linha:= Linha + ';'; Add(Linha); end; { Define os métodos da classe } for J:= 0 to (TClasse(Dictionary.Classes[I]). Methods.Count-1) do begin Linha:= #9#9 + TMethod(TClasse(Dictionary.C lasses[I]).Methods[J]). GetResult + #9#9 + TMethod(TClasse(Dictionary.C lasses[I]).Methods[J]). GetName + #9 + '('; { Define os parâmetros do método } for K:= 0 to
63
(TMethod(TClasse(Dictionary.Classes[I]).Methods[J]) .Parameters.Count-1) do Linha:= Linha + TAttribute(TMethod(TClasse(Dictionary.Classes[I]).M ethods[J]).Parameters[K]) .GetTipo + ' ' + TAttribute(TMethod(TClasse(Dictionary.Classes[I]).M ethods[J]).Parameters[K]) .GetName + ', '; if (TMethod(TClasse(Dictionary.Classes[I]).Methods[J]) .Parameters.Count > 0) then DeleteStr(Linha, Length(Linha)-1, 2); Linha:= Linha + ');'; Add(Linha); end; { Define as relações - Dependências } for J:= 0 to (TClasse(Dictionary.Classes[I]). Dependencys.Count-1) do begin Linha:= #9#9 + CFName + '::' + TDependency(TClasse(Dictionary.Classes[I]).Dependen cys[J]).GetSupplier + #9#9 + TDependency(TClasse(Dictionary.Classes[I]).Dependen cys[J]).GetName + ';'; Add(Linha); end; { Define as relações - Associações } for J:= 0 to (Dictionary.Associations.Count-1 ) do begin if (TAssociation(Dictionary.Associations[J] ).RoleA.GetSupplier = TClasse(Dictionary.Classes[I]).GetName) then begin Linha:= #9#9 + CFName + '::' + TAssociation(Dictionary.Associations[J]).RoleB.GetS upplier + #9#9 + TAssociation(Dictionary.Associations[J]).RoleA.GetN ame + ';'; Add(Linha); end; end; Add('};'); { Define o comando de criação da classe } Add(''); // Insere uma linha em branco end; { Define o comando de criação das classes } Linha:= 'buildClass '; for I:= 0 to (Dictionary.Classes.Count-1) do Linha:= Linha + CFName + '::' + TClasse(Dictionary. Classes[I]).GetName + ' '; Linha:= Linha + ';'; Add(Linha); end; end;
64
ANEXO 4- ARQUIVO MDL DO ESTUDO DE CASO
Root_category (object Class_Category "Logical View " quid "3B25EEBA0245" exportControl "Public" global TRUE subsystem "Component View" quidu "3B25EEBA0281" logical_models (list unit_reference_list (object Class "Embarcacao" quid "3B25F04403B6" operations (list Operations (object Operation "Obter Embarcação" quid "3B25F9A002B2" concurrency "Sequential" opExportControl "Public" uid 0) (object Operation "Verificar Embarcação" quid "3B25FA6B01A4" concurrency "Sequential" opExportControl "Public" uid 0)) class_attributes (list class_attribute_list (object ClassAttribute "Codigo_emb" quid "3B25F08E0000") (object ClassAttribute "Nome_emb" quid "3B25F0B702B2") (object ClassAttribute "Comprimento_emb" quid "3B25F0BA03D4") (object ClassAttribute "Captania_emb" quid "3B25F0C502B2") (object ClassAttribute "Ano_emb" quid "3B25F0D102D0") (object ClassAttribute "Conservacao_emb" quid "3B25F5DA0370"))) (object Class "Artesanal" quid "3B25F0DC01EA" superclasses (list inheritance_relationship_list (object Inheritance_Relationship quid "3B25F0E40122" label "Nome" supplier "Embarcacao" quidu "3B25F04403B6")) class_attributes (list class_attribute_list (object ClassAttribute "Casco_emb" quid "3B25F0FD0000") (object ClassAttribute "Propulsao_emb" quid "3B25F1020262"))) (object Class "Industrial" quid "3B25F0DF01FE" superclasses (list inheritance_relationship_list (object Inheritance_Relationship quid "3B25F0E60172" supplier "Embarcacao" quidu "3B25F04403B6"))
65
class_attributes (list class_attribute_list (object ClassAttribute "Estocagem_emb" quid "3B25F12A01AE") (object ClassAttribute "TIsca_emb" quid "3B25F1320118"))) (object Class "Proprietario" quid "3B25F16D01B8" class_attributes (list class_attribute_list (object ClassAttribute "Codigo_pro" quid "3B25F17A029E") (object ClassAttribute "Nome_pro" quid "3B25F17F02DA") (object ClassAttribute "Endereco_pro" quid "3B25F18A0032") (object ClassAttribute "CPF_pro" quid "3B25F18E033E") (object ClassAttribute "Apelido_pro" quid "3B25F195035C") (object ClassAttribute "Municipio_pro" quid "3B25F19B0050"))) (object Class "Pretechos" quid "3B25F20E005A" operations (list Operations (object Operation "Obter Pretecho" quid "3B25F9C5017C" concurrency "Sequential" opExportControl "Public" uid 0) (object Operation "Verificar Pretechos" quid "3B25FADA00C8" concurrency "Sequential" opExportControl "Public" uid 0)) class_attributes (list class_attribute_list (object ClassAttribute "Tipo_pre" quid "3B25F2170398"))) (object Class "Conservacao" quid "3B25F22A01EA" class_attributes (list class_attribute_list (object ClassAttribute "Tipo_con" quid "3B25F238006E"))) (object Class "Especie" quid "3B25F26E0064" operations (list Operations (object Operation "Obter Espécie" quid "3B25F8A50384" concurrency "Sequential" opExportControl "Public" uid 0) (object Operation "Verificar Espécie" quid "3B25FAAE0096" concurrency "Sequential" opExportControl "Public" uid 0)) class_attributes (list class_attribute_list (object ClassAttribute "Codigo_esp" quid "3B25F27703A2")
66
(object ClassAttribute "Cientifico_esp" quid "3B25F2BD008C") (object ClassAttribute "Popular_esp" quid "3B25F2C5017C"))) (object Class "Coletas" quid "3B25F2DE02EE" operations (list Operations (object Operation "Obter Coletas" quid "3B25F83302C6" concurrency "Sequential" opExportControl "Public" uid 0) (object Operation "Criar Coleta" quid "3B25FA4E00FA" concurrency "Sequential" opExportControl "Public" uid 0)) class_attributes (list class_attribute_list (object ClassAttribute "Data_col" quid "3B25F2E50348") (object ClassAttribute "Hora_col" quid "3B25F2F202EE"))) (object Class "Coletas_itens" quid "3B25F40E00A0" operations (list Operations (object Operation "Obter Quantidade" quid "3B25F8540370" concurrency "Sequential" opExportControl "Public" uid 0) (object Operation "Criar Item" quid "3B25FA910104" concurrency "Sequential" opExportControl "Public" uid 0) (object Operation "Calcular Qtde por Espécie" quid "3B25FD2800A0" concurrency "Sequential" opExportControl "Public" uid 0) (object Operation "Calcular Qtde por Embarcaç ão" quid "3B25FD520230" concurrency "Sequential" opExportControl "Public" uid 0)) class_attributes (list class_attribute_list (object ClassAttribute "Quantidade_PIt" quid "3B25F42A0262"))) (object Association "$UNNAMED$24" quid "3B25F3F80168" roles (list role_list (object Role "$UNNAMED$25" quid "3B25F3F901FE" supplier "Conservacao" quidu "3B25F22A01EA" is_navigable TRUE) (object Role "$UNNAMED$26"
67
quid "3B25F3F901FF" supplier "Embarcacao" quidu "3B25F04403B6" is_navigable TRUE))) (object Association "$UNNAMED$27" quid "3B25F4900118" roles (list role_list (object Role "$UNNAMED$28" quid "3B25F491006E" supplier "Especie" quidu "3B25F26E0064" client_cardinality (value cardinality "1") is_navigable TRUE) (object Role "$UNNAMED$29" quid "3B25F491006F" supplier "Coletas_itens" quidu "3B25F40E00A0" client_cardinality (value cardinality "0..n") is_navigable TRUE))) (object Association "$UNNAMED$30" quid "3B25F4CE015E" roles (list role_list (object Role "$UNNAMED$31" quid "3B25F4CE02A8" supplier "Embarcacao" quidu "3B25F04403B6" client_cardinality (value cardinality "1..n") is_navigable TRUE is_aggregate TRUE) (object Role "$UNNAMED$32" quid "3B25F4CE02DA" supplier "Proprietario" quidu "3B25F16D01B8" client_cardinality (value cardinality "1") is_navigable TRUE))) (object Association "$UNNAMED$33" quid "3B25F50900AA" roles (list role_list (object Role "$UNNAMED$34" quid "3B25F509033E" supplier "Coletas" quidu "3B25F2DE02EE" client_cardinality (value cardinality "1") is_navigable TRUE is_aggregate TRUE) (object Role "$UNNAMED$35" quid "3B25F509033F" supplier "Coletas_itens" quidu "3B25F40E00A0" client_cardinality (value cardinality "1..n") Containment "By Value" is_navigable TRUE))) (object Association "$UNNAMED$36" quid "3B25F5C200DC" roles (list role_list (object Role "$UNNAMED$37" quid "3B25F5C30140"
68
supplier "Embarcacao" quidu "3B25F04403B6" client_cardinality (value cardinality "1") is_navigable TRUE) (object Role "$UNNAMED$38" quid "3B25F5C30172" supplier "Pretechos" quidu "3B25F20E005A" client_cardinality (value cardinality "1..n") is_navigable TRUE))) (object Association "$UNNAMED$39" quid "3B25F66203A2" roles (list role_list (object Role "$UNNAMED$40" quid "3B25F66301E0" supplier "Coletas_itens" quidu "3B25F40E00A0" client_cardinality (value cardinality "0..n") is_navigable TRUE) (object Role "$UNNAMED$41" quid "3B25F66301E1" supplier "Pretechos" quidu "3B25F20E005A" client_cardinality (value cardinality "1") is_navigable TRUE))) (object Association "$UNNAMED$42" quid "3B25F71001EA" roles (list role_list (object Role "$UNNAMED$43" quid "3B25F7110140" supplier "Coletas" quidu "3B25F2DE02EE" client_cardinality (value cardinality "1..n") is_navigable TRUE) (object Role "$UNNAMED$44" quid "3B25F7110172" supplier "Embarcacao" quidu "3B25F04403B6" client_cardinality (value cardinality "1") is_navigable TRUE)))) logical_presentations (list unit_reference_list (object ClassDiagram "Main" quid "3B25EEBB00F0" title "Main" zoom 100 max_height 28350 max_width 21600 origin_x 0 origin_y 0 items (list diagram_item_list (object ClassView "Class" "Artesanal" @77 IncludeAttribute TRUE IncludeOperation TRUE location (224, 1680) label (object ItemLabel Parent_View @77 location (63, 1580)
69
nlines 1 max_width 321 justify 0 label "Artesanal") quidu "3B25F0DC01EA" compartment (object Compartment Parent_View @77 location (59, 1637) anchor 2 nlines 3 max_width 337) width 348 height 222 annotation 8 autoResize TRUE) (object ClassView "Class" "Industrial" @78 IncludeAttribute TRUE IncludeOperation TRUE location (672, 1680) label (object ItemLabel Parent_View @78 location (501, 1580) nlines 1 max_width 340 justify 0 label "Industrial") quidu "3B25F0DF01FE" compartment (object Compartment Parent_View @78 location (497, 1637) anchor 2 nlines 3 max_width 356) width 368 height 222 annotation 8 autoResize TRUE) (object ClassView "Class" "Especie" @79 IncludeAttribute TRUE IncludeOperation TRUE location (1936, 896) label (object ItemLabel Parent_View @79 location (1754, 726) nlines 1 max_width 362 justify 0 label "Especie") quidu "3B25F26E0064" compartment (object Compartment Parent_View @79 location (1749, 783) anchor 2 nlines 6 max_width 381) width 392 height 362
70
annotation 8 autoResize TRUE) (object ClassView "Class" "Proprietario" @80 IncludeAttribute TRUE IncludeOperation TRUE location (384, 256) label (object ItemLabel Parent_View @80 location (238, 62) nlines 1 max_width 290 justify 0 label "Proprietario") quidu "3B25F16D01B8" compartment (object Compartment Parent_View @80 location (236, 119) anchor 2 nlines 7 max_width 303) width 314 height 410 annotation 8 autoResize TRUE) (object ClassView "Class" "Pretechos" @81 IncludeAttribute TRUE IncludeOperation TRUE location (1152, 1440) label (object ItemLabel Parent_View @81 location (954, 1317) nlines 1 max_width 395 justify 0 label "Pretechos") quidu "3B25F20E005A" compartment (object Compartment Parent_View @81 location (947, 1374) anchor 2 nlines 4 max_width 406) width 428 height 268 annotation 8 autoResize TRUE) (object ClassView "Class" "Coletas_itens" @82 IncludeAttribute TRUE IncludeOperation TRUE location (1152, 896) label (object ItemLabel Parent_View @82 location (858, 725) nlines 1 max_width 586 justify 0 label "Coletas_itens")
71
quidu "3B25F40E00A0" compartment (object Compartment Parent_View @82 location (844, 782) anchor 2 nlines 6 max_width 612) width 634 height 364 annotation 8 autoResize TRUE) (object AssociationViewNew "$UNNAMED$27" @83 location (1604, 896) quidu "3B25F4900118" roleview_list (list RoleViews (object RoleView "$UNNAMED$28" @84 Parent_View @83 location (324, 160) quidu "3B25F491006E" client @83 supplier @79 line_style 0 label (object SegLabel @85 Parent_View @84 location (1709, 843) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1" pctDist 0.778761 height 54 orientation 0)) (object RoleView "$UNNAMED$29" @86 Parent_View @83 location (324, 160) quidu "3B25F491006F" client @83 supplier @82 line_style 0 label (object SegLabel @87 Parent_View @86 location (1518, 843) font (object Font size 10 face "helvetica" bold FALSE
72
italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "0..*" pctDist 0.637168 height 54 orientation 1)))) (object AssociationViewNew "$UNNAMED$39" @88 location (1152, 1191) quidu "3B25F66203A2" roleview_list (list RoleViews (object RoleView "$UNNAMED$40" @89 Parent_View @88 location (-272, -153) quidu "3B25F66301E0" client @88 supplier @82 line_style 0 label (object SegLabel @90 Parent_View @89 location (1206, 1129) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "0..*" pctDist 0.560000 height 54 orientation 1)) (object RoleView "$UNNAMED$41" @91 Parent_View @88 location (-272, -153) quidu "3B25F66301E1" client @88 supplier @81 line_style 0 label (object SegLabel @92 Parent_View @91 location (1190, 1274) font (object Font
73
size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1" pctDist 0.724490 height 38 orientation 0)))) (object ClassView "Class" "Coletas" @93 IncludeAttribute TRUE IncludeOperation TRUE location (1152, 336) label (object ItemLabel Parent_View @93 location (993, 189) nlines 1 max_width 316 justify 0 label "Coletas") quidu "3B25F2DE02EE" compartment (object Compartment Parent_View @93 location (990, 246) anchor 2 nlines 5 max_width 331) width 342 height 316 annotation 8 autoResize TRUE) (object AssociationViewNew "$UNNAMED$33" @94 location (1152, 603) quidu "3B25F50900AA" roleview_list (list RoleViews (object RoleView "$UNNAMED$34" @95 Parent_View @94 location (-128, -133) quidu "3B25F509033E" client @94 supplier @93 line_style 0 label (object SegLabel @96 Parent_View @95 location (1099, 526) font (object Font size 10 face "helvetica" bold FALSE
74
italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1" pctDist 0.719298 height 54 orientation 0)) (object RoleView "$UNNAMED$35" @97 Parent_View @94 location (-128, -133) quidu "3B25F509033F" client @94 supplier @82 line_style 0 label (object SegLabel @98 Parent_View @97 location (1099, 679) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1..*" pctDist 0.695906 height 54 orientation 1)))) (object ClassView "Class" "Embarcacao" @99 IncludeAttribute TRUE IncludeOperation TRUE location (384, 976) label (object ItemLabel Parent_View @99 location (166, 735) nlines 1 max_width 434 justify 0 label "Embarcacao") quidu "3B25F04403B6" compartment (object Compartment Parent_View @99 location (158, 792)
75
anchor 2 nlines 9 max_width 459) width 470 height 504 annotation 8 autoResize TRUE) (object InheritView "Nome" @100 quidu "3B25F0E40122" client @77 supplier @99 line_style 0) (object InheritView "" @101 quidu "3B25F0E60172" client @78 supplier @99 line_style 0) (object AssociationViewNew "$UNNAMED$30" @102 location (384, 592) quidu "3B25F4CE015E" roleview_list (list RoleViews (object RoleView "$UNNAMED$31" @103 Parent_View @102 location (-48, -720) quidu "3B25F4CE02A8" client @102 supplier @99 line_style 0 label (object SegLabel @104 Parent_View @103 location (330, 679) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1..*" pctDist 0.661869 height 55 orientation 1)) (object RoleView "$UNNAMED$32" @105 Parent_View @102 location (-48, -720) quidu "3B25F4CE02DA" client @102 supplier @80 line_style 0 label (object SegLabel @106
76
Parent_View @105 location (329, 492) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1" pctDist 0.770600 height 56 orientation 0)))) (object AssociationViewNew "$UNNAMED$36" @107 location (778, 1213) quidu "3B25F5C200DC" roleview_list (list RoleViews (object RoleView "$UNNAMED$37" @108 Parent_View @107 location (-1110, 45) quidu "3B25F5C30140" client @107 supplier @99 line_style 0 label (object SegLabel @109 Parent_View @108 location (657, 1197) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1" pctDist 0.612162 height 49 orientation 0)) (object RoleView "$UNNAMED$38" @110 Parent_View @107 location (-1110, 45) quidu "3B25F5C30172" client @107
77
supplier @81 line_style 0 label (object SegLabel @111 Parent_View @110 location (882, 1337) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1..*" pctDist 0.824903 height 53 orientation 1)))) (object AssociationViewNew "$UNNAMED$42" @112 location (799, 628) quidu "3B25F71001EA" roleview_list (list RoleViews (object RoleView "$UNNAMED$43" @113 Parent_View @112 location (-97, 132) quidu "3B25F7110140" client @112 supplier @93 line_style 0 label (object SegLabel @114 Parent_View @113 location (972, 540) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1..*" pctDist 0.805946 height 44 orientation 1)) (object RoleView "$UNNAMED$44" @115 Parent_View @112
78
location (-97, 132) quidu "3B25F7110172" client @112 supplier @99 line_style 0 label (object SegLabel @116 Parent_View @115 location (664, 791) font (object Font size 10 face "helvetica" bold FALSE italics FALSE underline FALSE strike FALSE color 0 default_color TRUE) anchor 2 anchor_loc 1 nlines 1 max_width 15 justify 0 label "1" pctDist 0.888806 height 39 orientation 0))))))))
79
ANEXO 5– CÓDIGO GERADO PELO PROTÓTIPO defaultCF TCC2001CF; defineClass Embarcacao { instance: String Codigo_emb; String Nome_emb; String Comprimento_emb; String Captania_emb; String Ano_emb; String Conservacao_emb; Void ObterEmbarcação (); Void VerificarEmbarcação (); TCC2001CF::Proprietario UNNAMED30; TCC2001CF::Pretechos UNNAMED36; }; defaultCF TCC2001CF; defineClass Artesanal super: Embarcacao { instance: String Casco_emb; String Propulsao_emb; }; defaultCF TCC2001CF; defineClass Industrial super: Embarcacao { instance: String Estocagem_emb; String TIsca_emb; }; defaultCF TCC2001CF; defineClass Proprietario { instance: String Codigo_pro; String Nome_pro; String Endereco_pro; String CPF_pro; String Apelido_pro; String Municipio_pro; }; defaultCF TCC2001CF; defineClass Pretechos { instance: String Tipo_pre; Void ObterPretecho (); Void VerificarPretechos (); }; defaultCF TCC2001CF; defineClass Conservacao
80
{ instance: String Tipo_con; TCC2001CF::Embarcacao UNNAMED25; }; defaultCF TCC2001CF; defineClass Especie { instance: String Codigo_esp; String Cientifico_esp; String Popular_esp; Void ObterEspécie (); Void VerificarEspécie (); TCC2001CF::Coletas_itens UNNAMED28; }; defaultCF TCC2001CF; defineClass Coletas { instance: String Data_col; String Hora_col; Void ObterColetas (); Void CriarColeta (); TCC2001CF::Coletas_itens UNNAMED34; TCC2001CF::Embarcacao UNNAMED43; }; defaultCF TCC2001CF; defineClass Coletas_itens { instance: String Quantidade_PIt; Void ObterQuantidade (); Void CriarItem (); Void CalcularQtdeporEspécie (); Void CalcularQtdeporEmbarcação (); TCC2001CF::Pretechos UNNAMED40; }; buildClass TCC2001CF::Embarcacao TCC2001CF::Artesan al TCC2001CF::Industrial TCC2001CF::Proprietario TCC2001CF::Pretechos TCC200 1CF::Conservacao TCC2001CF::Especie TCC2001CF::Coletas TCC2001CF::Co letas_itens ;
81
REFERÊNCIAS BIBLIOGRÁFICAS
BALLMANN, Vanderlei. Protótipo de ferramenta case para geração de código C++ e
diagrama de classes. 2000. 61 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências
da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,
Blumenau.
CANTU, Marcos. Dominando o Delphi 5. a Bíblia. São Paulo: Makron Books, 2000.
COMPUTER, Associates. CA-Jasmine, dez. 1997. Disponível em: <http://www.ca.com>.
Acesso em: 10 jun. 2001.
FAGUNDES, Eduardo. Quais as diferenças entre os bancos de dados relacionais e os
orientado a objetos?, jan. 2001. Disponível em:
<http://www.efagundes.com/disc1_to.htm#0000001e>. Acesso em: 14 mai. 2001.
FOWLER, Martin; SCOTT, Kendall. UML essencial: um breve guia para a linguagem-
padrão de modelagem de objetos. Porto Alegre: Bookman, 2000.
FURLAN, José Davi. Modelagem de objetos através da UML – the unified modeling
language. São Paulo: Makron Books, 1998.
JACOBSON, Ivar; MAGNOS, Cristenson; PATRIK, Johnson. Object-oriented software
engineering. USA: The Reverside Printing Co. 1992.
HAFEMANN, Lodemar José. Protótipo de gerador de código fonte baseado em
diagramas de sequências. 2000. 56 f. Trabalho de Conclusão de Curso (Bacharelado em
Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau, Blumenau.
KHOSHAFIAN, Setrag. Banco de dados orientado a objetos. Rio de Janeiro: Infobook,
1994.
82
KHOSHAFIAN, Setrag; DASANANDA, Surapol; MINASSIAN, Norayr. The Jasmine
Object Database: Multimedia Apllications for the Web. San Francisco: Morgan Kaufmann
Publishers, 1999.
KRAMEL, Danilo. Protótipo de software para a geração de código CDL através do
repositório da ferramenta CASE System Architect. 2000. 92 f. Trabalho de Conclusão de
Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais,
Universidade Regional de Blumenau, Blumenau.
LARMAN, Craig. Utilizando UML e padrões: Uma introdução à análise e ao projeto
Orientados a Objetos. Porto Alegre: Bookman, 2000.
MARTIN, James;Odell, James J. Object-Oriented Analysis and Desing. New Jersey:
Prentice-Hill Inc., 1992.
MULLER, Pierre-Alain. Instant UML. Canadá: Wrox Press Ltd., 1997.
NAU, Rodrigo Dadam. Protótipo de uma ferramenta CASE para a fase de análise da
proposta UML (Unified Modeling Language). 1998. 73 f. Trabalho de Conclusão de Curso
(Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais,
Universidade Regional de Blumenau, Blumenau.
OLIVEIRA, Adeliza; MEDEIROS, Marcelo. Delphi 5: conceitos básicos. Florianópolis:
Advanced Ed., 2000.
PAGE-JONES, Meilir. Fundamentos do desenho Orientado a Objetos com UML. São
Paulo: Makron Books, 2001.
PREBIANCA, Jefferson Luiz. Protótipo de uma ferramenta CASE para especificação do
modelo funcional segundo a proposta UML. 1998. 87 f. Trabalho de Conclusão de Curso
(Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais,
Universidade Regional de Blumenau, Blumenau.
RATIONAL, Software Corporation. Rational Rose, jun. 1997. Disponível em:
<http://www.rational.com>. Acesso em: 05 jun. 2001.
83
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro:
Campus, 1994.
UESSLER, Sidney. Estudo das características de banco de dados orientado a objetos
Jasmine. 1999. 61 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da
Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau,
Blumenau.
WEHRMEISTER, Marco Aurélio. Software para geração de código fonte a partir do
repositório da ferramenta case System Architect. 2000. 117 f. Trabalho de Conclusão de
Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais,
Universidade Regional de Blumenau, Blumenau.
WINBLAD, Ann L.; EDWARDS, Samuel D.; KING, Davi R. Object Oriented Software.
Addison-Wesley Publishing Company, 1990.