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
ii
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
iii
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
iv
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
v
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
vi
ANEXO 5– CÓDIGO GERADO PELO PROTÓTIPO ... 79 REFERÊNCIAS BIBLIOGRÁFICAS ... 81
vii
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
viii
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
ix
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
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 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.
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;
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.
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
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.
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;
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.
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.
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)))
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 RATIONAL
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 PETAL
(object Class <string> quid <indent> superclasses <list> operations <list> class_attributes <list> used_nodes <list> realized_interfaces <list> exportControl <string> language <string> stereotype <string> )
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;
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.
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 : Long sexo : M ou F
dataDoNascimento : 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
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.
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 Corpo
Cabeç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.
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 – ESPECIALIZAÇÃO.
Pagamento PagamentoComDinheiro PagamentocomCheque 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
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.
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.
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
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.
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.
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 dadchamando-os relacional por objetchamando-os. Porém, esse tipo de banco de dadchamando-os 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;
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.
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.
Quadro 5 – EXEMPLOS DE COMANDOS DO BANCO JASMINE
CreateStore h] dbName database] userName user] passwd password]
[-envFile [-envFile] [-numberOfPages] [-pageSize pageSize] storeName {fileName}...
ExtendSore h] dbName database] userName user] passwd password]
[-envFile [-envFile] [-numberOfPages Pages] [-wait] storeName {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 está especificada, o comando não é executada e todos os outros opções espeficidadas serão ignorada.
[-dbName database] : o nome da base de dados para ser 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.
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 CLASSES
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
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 LINGUAGEM 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.
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.
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.
Figura 9 - DIAGRAMA DE CLASSES DO PROTÓTIPO 1 0..* TRole Name : String Supplier : String Cardinality : String Create( ) GetSupplier( ) GetName( ) 1 TRRFile FLine : Integer FCountAbreParenteses : Integer FCountFechaParenteses : Integer SL : TStringList Dictionary : TDictionary SLODQL GetObjectName( ) CountToken( ) DeleteSubStr( ) ReadMethods( ) ReadSuperClasse( ) ReadAttributes( ) ReadAssociations( ) ReadParameters( ) ReadDependencys( ) Destroy( ) ReadClasses( ) IsValid( ) Create( ) RetiraCifrao( ) ODQLGeneration( ) 1..* 1 0..* TAssociation Name : String RoleA : Role RoleB : Role Create( ) 1 0..* 1 0..* TDependency Name : String Supplier : String SupplierCardinality : String ClientCardinality : String Create( ) GetSupplier( ) GetName( ) 1 TDictionary Associations : Association Classes : Classe Create( ) Destroy( ) LiberaMemoria( ) 1 1..* 1 0..* 1..* 1 0..* 1..* TClasse Name : String SuperClass : String SuperClassRelationName : String Attributes : Attribute Methods : Method Dependencys : Dependency Create( ) Destroy( ) GetName( ) GetSuperClass( ) 1 0..* 1 1..* 0..* TMethod Name : String Retorno : String = Void Visible : String
Parameters : Attribute = TList.Create Create( ) Destroy( ) GetResult( ) GetName( ) 1 0..* TAttribute Name : String Tipo : String Visible : String Create( ) GetTipo( ) GetName( ) GetDefault( ) 1..* 0..*
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;
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;
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-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 : Analista Dictionaty : 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)
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 ODQL
: Analista : TRRFile : TClasse : TAttribute : TDependency : TMethod : TRole
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.
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