2.2 conceito mbuide

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
AMBIENTE PARA DESENVOLVIMENTO DE SISTEMAS
BASEADO NO CONCEITO MBUIDE
DAVI EDUARDO BORGES WALL
BLUMENAU
2012
2012/1-10
DAVI EDUARDO BORGES WALL
AMBIENTE PARA DESENVOLVIMENTO DE SISTEMAS
BASEADO NO CONCEITO MBUIDE
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Ciência
da Computação — Bacharelado.
Prof. Jacques Robert Heckmann , Mestre - Orientador
BLUMENAU
2012
2012/1-10
AMBIENTE PARA DESENVOLVIMENTO DE SISTEMAS
BASEADO NO CONCEITO MBUIDE
Por
DAVI EDUARDO BORGES WALL
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
Presidente:
______________________________________________________
Prof. Jacques Robert Heckmann, Mestre – Orientador, FURB
Membro:
______________________________________________________
Prof. Everaldo Artur Grahl, Mestre – FURB
Membro:
______________________________________________________
Prof. Marcel Hugo, Mestre – FURB
Blumenau, 10 de julho de 2012
Dedico este trabalho à minha família, que me
deu o suporte de que precisava, e a meu pai
que faleceu durante o início dos trabalhos.
AGRADECIMENTOS
A Deus, pela benção concedida a minha família.
À minha família, que me deu total apoio por todo esse período.
Aos meus amigos, pelas felizes distrações que me proporcionaram.
Ao meu orientador, Jacques Heckmann, por ter me colocado no caminho certo.
A cerveja é a prova viva que Deus nos ama e
nos quer ver felizes.
Benjamin Franklin
RESUMO
Este trabalho apresenta um ambiente para desenvolvimento de sistemas de informação sem a
geração de código fonte. O ambiente é composto por duas ferramentas que são a base para a
definição e geração de um sistema de informação. Na ferramenta modeladora, o
desenvolvedor pode definir módulos, interfaces de usuário e controles visuais que integrarão o
sistema. As informações de cada um desses componentes do sistema são salvas em um banco
de dados que representa o modelo de domínio do sistema. A ferramenta interpretadora,
quando executada, conecta-se ao banco de dados e carrega as informações do modelo de
domínio em memória, montando o sistema de informação para o usuário final.
Plavras-chave: Desenvolvimento de interfaces de usuário, Geração de sistemas, Interface de
usuário, Sistema de informação.
ABSTRACT
This work presents an environment for software development that doesn’t require source code
generation. The environment consists in two tools used to define and generate an information
system software. Using a modeling tool, software developers can define modules, user
interfaces and interface controls that will be part of the software. The information of each of
these system components are saved into a DBMS that represents the system domain. The
interpretation tool goes in action, connecting to the DBMS and loading all system domain
information in memory then generating the end-user software system.
Key-words: Model-based user interface development, Software automation, User interface,
Information systems.
LISTA DE ILUSTRAÇÕES
Quadro 1 – Simbologia para representar multiplicidades ........................................................ 22
Figura 1 – Tipos de conectividade de associações ................................................................... 22
Figura 2 – Modelo de apresentação da ferramenta Tadeus ...................................................... 23
Figura 3 – Modelo de apresentação da ferramenta Teallach .................................................... 24
Figura 4 – Mapeamento das definições para a IU do Merlin ................................................... 25
Quadro 2 – Requisitos funcionais da ferramenta modeladora .................................................. 26
Quadro 3 – Requisitos funcionais da ferramenta interpretadora .............................................. 26
Quadro 4 – Requisitos não funcionais do ambiente de desenvolvimento ................................ 27
Figura 5 – Diagrama de casos de uso da ferramenta modeladora ............................................ 28
Figura 6 – Diagrama de casos de uso da ferramenta interpretadora ......................................... 28
Quadro 5 – Caso de uso manter módulos ................................................................................. 29
Quadro 6 – Caso de uso manter IUs ......................................................................................... 30
Quadro 7 – Caso de uso manter controles visuais .................................................................... 31
Quadro 8 – Caso de uso manter pastas ..................................................................................... 32
Figura 7 – Diagrama de atividades do UC05 ........................................................................... 33
Figura 8 – Diagrama de classes do modelo de domínio ........................................................... 35
Figura 9 – DER do modelo de dados ........................................................................................ 36
Quadro 9 – Mapeamento classe x tabela .................................................................................. 37
Quadro 10 – Dicionário de dados ............................................................................................. 37
Quadro 11 – Propriedades da IU .............................................................................................. 38
Quadro 12 – Objetivos de cada tipo de controle visual ............................................................ 38
Quadro 13 – Propriedades comuns entre as definições de controle ......................................... 38
Quadro 14 – Propriedades das pastas ....................................................................................... 39
Figura 10 – Exemplo de um diagrama de classes com relacionamento um para muitos ......... 40
Figura 11 – Resultado obtido ao definir o relacionamento um para muitos ............................ 40
Figura 12 – Exemplo de um diagrama de classes com relacionamento muitos para muitos ... 41
Figura 13 – Resultado obtido ao definir um relacionamento muitos para muitos .................... 41
Figura 14 – Exemplo de um diagrama de classes com relacionamento um para um ............... 42
Figura 15 – Resultado obtido ao definir um relacionamento um para um ............................... 42
Figura 16 – Exemplo de montagem de filtro de pasta .............................................................. 43
Figura 17 – Resultado obtido na aplicação do filtro de pasta ................................................... 43
Figura 18 – Criar conexão ........................................................................................................ 44
Figura 19 – Cadastro de IUs e controles visuais ...................................................................... 45
Figura 20 – Cadastro de módulos e pastas ............................................................................... 45
Figura 21 – Componentes do interpretador do ambiente ......................................................... 46
Quadro 15 – Legenda ............................................................................................................... 46
Quadro 16 – Método OnExpanding da Treeview ............................................................ 47
Quadro 17 – Método ListNode chamado no evento OnExpanding da Treeview ........ 47
Quadro 18 – Método ListRecords ..................................................................................... 48
Quadro 19 – Método ListFolders ..................................................................................... 49
Quadro 20 – Método que inicia o processo carregamento o modelo de dados na memória .... 50
Quadro 21 – Método que carrega as definições de IUs ............................................................ 51
Quadro 22 – Método que carrega as definições dos controles visuais ..................................... 52
Quadro 23 – Método que carrega as definições dos módulos .................................................. 52
Quadro 24 – Método que carrega as definições das pastas ...................................................... 53
Figura 22 – Disposição dos controles visuais em duas colunas ............................................... 54
Quadro 25 – Método generatecontrols ......................................................................... 55
Figura 23 – Diagrama de classes do sistema de locação de carros........................................... 56
Figura 24 – Parametrização da conexão com o banco de dados .............................................. 57
Figura 25 – Abrir conexão com o banco de dados ................................................................... 57
Figura 26 – Propriedades do sistema listadas na árvore de navegação .................................... 58
Figura 27 – Inclusão de IUs...................................................................................................... 59
Figura 28 – Inclusão de controles visuais................................................................................. 60
Figura 29 – Inclusão de pastas do sistema ................................................................................ 61
Figura 30 – Inclusão de módulos do sistema............................................................................ 61
Figura 31 – Definição da pasta pessoa ..................................................................................... 62
Figura 32 – Definição da subpasta locação .............................................................................. 63
Figura 33 – Resultado obtido na definição das pastas pessoa e locação .................................. 63
Figura 34 – DER do modelo criado pelo ambiente .................................................................. 64
Quadro 26 – Comparativo dos modelos de alto nível implementados nas ferramentas ........... 66
LISTA DE SIGLAS
AIO – Abstract Interface Objects
CIO – Concrete Interface Objects
CRUD – Create, Retrieve, Update and Delete
DER – Diagrama de Entidade Relacional
IU – Interface de Usuário
IGU – Interface Gráfica de Usuário
MBUIDE – Model-Based User Interface Development Environment
PDV – Ponto de Venda
RAD – Rapid Application Development
SGBD – Sistema de Gerenciamento de Banco de Dados
UIMS – User Interface Management System
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 13
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 16
2.1 SISTEMAS DE INFORMAÇÃO...................................................................................... 16
2.2 CONCEITO MBUIDE ...................................................................................................... 17
2.2.1 Tipos de modelos de alto nível........................................................................................ 18
2.2.1.1 Modelo de domínio ....................................................................................................... 18
2.2.1.2 Modelo de tarefa ........................................................................................................... 19
2.2.1.3 Modelo de usuário ........................................................................................................ 19
2.2.1.4 Modelo de diálogo ........................................................................................................ 19
2.2.1.5 Modelo de apresentação ............................................................................................... 20
2.2.1.6 Modelo de aplicação e plataforma ................................................................................ 20
2.3 NAVEGAÇÃO DE REGISTROS EM ÁRVORES DE VISUALIZAÇÃO ..................... 21
2.4 DIAGRAMA DE CLASSES ............................................................................................. 21
2.5 TRABALHOS CORRELATOS ........................................................................................ 22
2.5.1 Tadeus ............................................................................................................................. 23
2.5.2 Teallach ........................................................................................................................... 24
2.5.3 Merlin .............................................................................................................................. 24
3 DESENVOLVIMENTO .................................................................................................... 26
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................... 26
3.2 ESPECIFICAÇÃO ............................................................................................................ 27
3.2.1 Diagramas de casos de uso.............................................................................................. 27
3.2.2 Diagrama de atividades ................................................................................................... 32
3.3 IMPLEMENTAÇÃO ........................................................................................................ 33
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 34
3.3.1.1 Modelo de domínio ....................................................................................................... 34
3.3.1.2 Ferramenta modeladora ................................................................................................ 44
3.3.1.3 Modelo de aplicação, diálogo e apresentação ............................................................... 46
3.3.1.4 Processo de carregamento do modelo de dados em memória ...................................... 49
3.3.1.5 Processo de geração de IUs .......................................................................................... 53
3.3.2 Operacionalidade da implementação .............................................................................. 56
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 64
4 CONCLUSÕES .................................................................................................................. 67
4.1 EXTENSÕES .................................................................................................................... 68
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 69
13
1 INTRODUÇÃO
A rápida evolução dos sistemas operacionais gráficos mudou a maneira como
Interfaces de Usuário (IU) são construídas. Contrastando com antigos sistemas baseados em
IU de modo caractere as modernas interfaces gráficas apresentam semântica padronizada,
elaborados mecanismos para tratamento de eventos e diversidade de elementos para interação
(GALITZ, 2002, p. 15).
As interfaces atuais são conhecidas como Interfaces Gráficas de Usuário (IGU) e dão
ao usuário alto poder de navegação e maior aptidão na resolução de tarefas. Todas essas
facilidades disponibilizadas ao usuário geram um preço alto para o desenvolvedor. Grande
parte do tempo é ocupado pelo trabalho de adição e posicionamento de controles em
formulários, código para validação de conteúdo, formatação e ajustes de aparência e
comportamento (MRACK, 2005, p. 12).
Ferramentas Rapid Application Development (RAD) ficaram famosas por proporcionar
soluções para agilizar o desenho de IUs através da utilização de toolkits gráficos. Toolkits
tipicamente provêem uma biblioteca de componentes interativos e um framework para
gerenciar a operação de interfaces construídas com esses componentes (MYERS, 1999, p.
06).
Muitas ferramentas RAD possuem assistentes de geração de interfaces do tipo Create,
Retrieve, Update and Delete (CRUD) que ajudam o desenvolvedor, passo a passo, a coletar
informações de seu modelo e associá-las aos componentes de interface. Mrack (2009, p. 32)
diz que “durante o desenvolvimento de aplicativos para banco de dados, é saliente a presença
das interfaces de edição e visualização de informações que são provenientes do SGBD, as
quais são simplesmente conhecidas como interfaces CRUD”.
De acordo com Schlungbaum (1996, p. 03), mesmo com todos estes avanços e
facilitadores que as ferramentas RAD proporcionam, a criação manual de IUs CRUD ainda
toma cerca de 50% de tempo de desenvolvimento de um sistema de informações. O processo
de automatização na criação de IUs pode ser utilizado como alternativa à criação de IUs
CRUD diretamente no toolkit gráfico. Uma abordagem desta alternativa é a utilização do
conceito Model-Based User Interface Development Environment (MBUIDE).
O conceito MBUIDE consiste em uma metodologia de desenvolvimento de sistemas
que possui o objetivo de oferecer aos desenvolvedores um alto nível de abstração para o
desenvolvimento de sistemas de informação (LAVÔR; LEITE, 2011). Em uma ferramenta
14
MBUIDE as características do sistema são divididas em modelos de alto nível, sendo seus
principais, o modelo de domínio e o modelo de apresentação. A maior parte dos sistemas
MBUIDE oferece soluções para criação de interfaces CRUD baseadas na geração de código
fonte. O programador alimenta o modelo de dados com informações sobre a definição do
sistema, enquanto uma rotina geradora de código fonte varre o modelo de dados gerando as
IUs prontas para compilação.
A utilização de ferramentas MBUIDE agiliza o processo de desenvolvimento de
sistemas e promove a padronização e o reuso de objetos. Uma vez construídos, testados e
validados, os objetos poderão ser reutilizados sem a necessidade de novos testes ostensivos.
Diante do exposto, neste trabalho propõe-se uma abordagem diferenciada utilizando
árvores de visualização para navegação de registros, enfocando a automatização de criação de
IUs CRUD em tempo de execução, sem a necessidade de geração de código fonte e utilizando
os conceitos da MBUIDE.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é desenvolver um ambiente para criação rápida de sistemas
de informação baseado nos conceitos de MBUIDE e sem geração de código fonte.
Os objetivos específicos do trabalho são:
a) desenvolver uma ferramenta para criação e manutenção dos modelos de domínio,
de diálogo, de aplicação e de apresentação;
b) desenvolver uma ferramenta interpretadora do modelo, responsável por apresentar
um sistema de informação ao usuário final.
1.2 ESTRUTURA DO TRABALHO
O texto está organizado em quatro capítulos. O segundo capítulo trata a fundamentação
teórica utilizada no desenvolvimento do trabalho. São abordados os conceitos de sistema de
informação, de MBUIDE e seus modelos de alto nível, de árvore de navegação em registros,
de diagramas de classe e conectividades e são apresentados três trabalhos correlatos. O
15
terceiro capítulo trata do desenvolvimento das ferramentas propostas, apresentando seus
requisitos funcionais e não funcionais, os diagramas de caso de uso, de classes e de
atividades. Nesse capítulo ainda são apresentadas as ferramentas utilizadas no processo de
desenvolvimento, a implementação e a operacionalidade do ambiente. Por fim, o quarto
capítulo apresenta as conclusões e possíveis extensões para este trabalho.
16
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo apresentam-se as características de um sistema de informação, o
conceito MBUIDE e seus modelos de alto nível, o conceito de navegação de registros em
árvore, o conceito de diagrama de classes e suas conectividades e, por fim, três trabalhos
correlatos.
2.1 SISTEMAS DE INFORMAÇÃO
Os sistemas de informação são parte crucial na organização das informações de
instituições em geral. Eles são utilizados como base para integração de informações,
gerenciamento e tomadas de decisões, agindo como fator de vantagem competitiva no mundo
dos negócios. De acordo com Tonsig (2003, p. 31), sistemas de informação são um
subsistema das organizações e são agentes de otimização dos processos da empresa.
Da mesma forma, eles também podem ser organizados em subsistemas menores, cada
qual com um objetivo específico. Um subsistema é um sistema cuja operação não depende
dos serviços fornecidos por outros subsistemas. Os subsistemas são compostos de módulos e
têm interfaces definidas, as quais são utilizadas para a comunicação entre subsistemas
(SOMMERVILLE, 2003, p. 183).
Rezende (2005, p. 12) classifica sistemas de informação de acordo com sua aplicação,
sendo uma delas, o sistema comercial. Para esses sistemas, Rezende (2005, p. 23) ainda
afirma que as funções organizacionais comuns de uma empresa estão decompostas em
módulos ou subsistemas, os quais podem apresentar-se de forma diferente de organização
para organização. Seguindo esta ótica, verifica-se que a arquitetura dos sistemas comerciais
atuais possui uma série de características em comum quando levada em conta seu objetivo,
sua modularidade e funcionalidade. Uma arquitetura de software indica como o software
funciona e como ele deve ser implementado (PETERS; PEDRYCZ, 2001, p. 180).
Como exemplo pode-se verificar os departamentos de recursos humanos e financeiro
em uma empresa hipotética. Ambos manipulam informações organizacionais distintas e não
necessariamente dependentes. Na utilização de um sistema de informação para o
gerenciamento de ambos, é comum a existência de um módulo para cada departamento.
17
Quando necessário, cria-se interfaces de comunicação entre os módulos a fim de atingir um
determinado objetivo.
2.2 CONCEITO MBUIDE
MBUIDE é a evolução do conceito de User Interface Management System (UIMS) que
foi o primeiro conceito de automatização de criação de IUs, o qual teve suas origens no início
da década de 1980. A UIMS foi a primeira alternativa em relação à construção manual de
interfaces de usuário, possibilitando aos programadores escrever aplicações em uma
linguagem de mais alto nível, ao invés de trabalhar diretamente com um toolkit gráfico
(MRACK, 2009, p. 18).
Em
vez
de
programar
IUs
diretamente
na
linguagem
de
programação,
desenvolvedores escreviam a especificação da IU em uma linguagem de alto nível. Essa
especificação é automaticamente traduzida em um programa executável ou interpretada em
tempo de execução a fim de gerar a interface apropriadamente (SCHLUNGBAUM, 1996, p.
12). Algumas UIMSs utilizaram declaração de procedimentos para definir aspectos funcionais
da IU. Baseado nessas informações era possível gerar automaticamente menus, caixas de
diálogo, molduras, entre outros (SZEKELY, 1996, p. 01).
Com a evolução das IGUs, os conjuntos de informações que denotam uma IU ficaram
mais complexos e detalhados. As UIMSs tiveram que englobar esta evolução a fim de
incorporar soluções para IGUs antes não existentes. Uma das soluções propostas é a utilização
de um modelo de domínio do sistema que é utilizado como fonte de dados para geração de
IUs, sendo esta a base para os sistemas que implementam o conceito MBUIDE.
Segundo Puerta (1997, p. 42), MBUIDE é um ambiente de software que suporta a
criação de interfaces sob uma linguagem de interface específica e é caracterizada pela
conectividade dos modelos e componentes dentro dela. MBUIDEs podem adquirir diferentes
características dependendo do seu foco de atuação.
Algumas características gerais encontradas em MBUIDEs são:
a) automatização da criação de IUs utilizando modelos de alto nível;
b) manutenção de um modelo de dados com definições do sistema;
c) disponibilização de um mecanismo de modelagem ou especificação de sistema,
seja com uma interface de modelagem própria, importação de dados ou utilização
18
de templates.
As MBUIDEs modernas agregam muito mais benefícios do que a automatização de
geração de IUs, podendo ainda automatizar a tarefa de criação de tabelas e campos no banco
de dados, gerenciamento dos dados e usuários e, ainda, partes da ajuda do sistema.
MBUIDE possui uma série de modelos de alto nível que estabelecem as formas de
trabalho que a solução irá suportar. Tais modelos têm como objetivo possibilitar a
especificação e análise de um sistema interativo (MRACK, 2009, p. 34).
2.2.1 Tipos de modelos de alto nível
Modelos de alto nível são características que podem ser agregadas ao sistema
MBUIDE. De fato, é a partir destes modelos que as ferramentas definem suas formas de
trabalho e, consequentemente, o processo de desenvolvimento a ser aplicado quando da sua
utilização (BODART, 1994). De acordo com Mrack (2009), Os modelos de alto nível não
possuem definição ou forma específica para a organização de suas informações, porém devese levar em conta um nível de abstração mais elevado na definição destes modelos.
2.2.1.1
Modelo de domínio
O modelo de domínio de um sistema MBUIDE é entendido como um conjunto de
informações que denotam um sistema de informação. Essas informações quando interpretadas
atuam sobre as características do sistema final e os detalhamentos dessas informações estão
ligados diretamente ao projeto do ambiente e seu funcionamento.
A partir do modelo de domínio são extraídas várias informações que, através de
heurísticas e algoritmos diversos, podem ser derivadas nos elementos que constituem os
formulários da aplicação. Conforme análises, os modelos de domínio vieram para englobar os
modelos de dados e são vistos como elementos essenciais nas MBUIDE atuais (MRACK,
2009, p. 21).
19
2.2.1.2
Modelo de tarefa
Por meio do modelo de tarefa são definidas as ações necessárias para atingir um
objetivo dentro do sistema. O modelo de tarefa deve permitir a modelagem da estrutura de
tarefas assim como o fluxo de informação entre elas. As tarefas podem ser hierarquicamente
divididas em sub-tarefas até chegarem a um nível elementar de ações.
2.2.1.3
Modelo de usuário
O modelo de usuário estabelece o perfil dos usuários finais do sistema (PRESSMAN,
2002, p. 397). Pode-se ainda complementar esta definição afirmando que o modelo de usuário
abrange todo tipo de informação referente ao gerenciamento dos usuários do sistema. De
acordo com Mrack (2009, p. 21), não existe uma definição quanto à forma de
desenvolvimento da solução, sendo a forma mais comum a implementação de rotinas para
controle de usuários.
Controle de usuários são rotinas de segurança que identificam o usuário através da
solicitação de informações como nome do usuário e senha para permitir acesso ao sistema.
Essas rotinas possibilitam ainda a implementação de permissões de acesso em diversos níveis.
As permissões de acesso inferem quais opções ou ações do sistema estarão disponíveis ao
usuário.
Pode-se ainda utilizar esses dados para salvar informações personalizadas de
preferência de uso e configurações de usabilidade definidas pelo próprio usuário durante a
utilização do sistema. É nesse modelo que devem ficar armazenados comportamentos e
especializações de tela, como teclas de atalho personalizadas, valores-padrão para controles
de tela baseados em perfil de usuário, informações referentes a controle de acesso e outras
características (SCHLUNGBAUM, 1996, p. 11).
2.2.1.4
Modelo de diálogo
O modelo de diálogo representa as ações que o usuário pode efetuar na interação com a
IU e as respostas que a IU deve reproduzir em relação a essas ações. Inclusão e exclusão são
20
algumas ações ligadas ao modelo de diálogo e o sistema deve ajustar-se de acordo quando
acionadas. Como exemplo é comum desabilitar a exclusão de registros no ato da inclusão de
um novo registro. Esses comportamentos garantem melhor usabilidade da IU e formas de
trabalho mais intuitivas para o usuário final.
2.2.1.5
Modelo de apresentação
O modelo de apresentação especifica a aparência no desenho das IUs. Neste modelo
são definidos os controles visuais de IUs e seus atributos. As características dos elementos
gráficos como leiaute de controles, posicionamento, tamanho, regras para redimensionamento,
esquema de cores, ordem de tabulação e outras relacionadas à aparência da IU são
centralizadas nesse modelo (MRACK, 2009, p. 23).
As ferramentas MBUIDE seguem duas diferentes abordagens na implementação do
modelo de apresentação. A estrutura Abstract Interface Objects (AIO) trabalha o modelo de
forma mais abstrata e as informações são mapeadas para os controles visuais no momento da
geração da IU. Esta estrutura detém certo nível de limitação no desenho de IUs, pois
eventualmente uma informação existente na AIO pode não estar disponível no toolkit gráfico.
A estrutura Concrete Interface Objects (CIO) trabalha ligada diretamente ao formato
de desenho do toolkit gráfico e muitas vezes utiliza-se de seus modelos declarativos. Altas
taxas de detalhamento desta estrutura permite a criação de IUs mais elaboradas em relação à
estrutura AIO. Algumas ferramentas MBUIDE definem o modelo de apresentação utilizando
a estrutura AIO e transportam essa estrutura para CIO seja para a geração de código fonte de
IUs ou para a geração de IUs em tempo de execução.
2.2.1.6
Modelo de aplicação e plataforma
Este modelo especifica características da aplicação e da plataforma na qual o sistema
está sendo executado. É considerado um subconjunto do modelo de domínio, estendendo
informações que vão desde a conexão ao banco de dados até detalhes sobre o toolkit gráfico.
21
2.3 NAVEGAÇÃO DE REGISTROS EM ÁRVORES DE VISUALIZAÇÃO
As plataformas atuais facilitaram o acesso às informações armazenadas em memória,
disponibilizando-as
em
componentes
visuais
amigáveis
e
intuitivos
ao
usuário.
Anteriormente, usuários precisavam memorizar e digitar diversos comandos para que
pudessem acessar ou executar arquivos. Agora, utilizam-se de árvores de visualização para
navegação em estruturas de arquivos do sistema.
Árvores de visualização são estruturas hierárquicas de galhos e folhas. Cada item na
árvore é chamado de nó e um nó pode ser uma folha ou um galho. Um nó galho pode conter
nós folhas ou galhos ou pode estar vazio (sem filhos). Uma folha é o ponto final na árvore
(ADOBE, 2009).
A árvore de visualização provê uma maneira de exibir informações em uma estrutura
hierárquica utilizando nós expansíveis (MICROSOFT CORPORATION, 2010). Da mesma
forma que árvores são utilizadas na visualização da estrutura de arquivos de um computador,
elas podem ser utilizadas para visualização de qualquer conjunto de informações que tenham
relacionamento entre si.
Ao estabelecer um relacionamento entre conjuntos de informações é possível utilizar
esse relacionamento como ponto de navegação em uma árvore de dados. Como exemplo
pode-se utilizar o relacionamento existente entre uma tabela de pedidos e uma tabela de itens
de pedido e listá-los hierarquicamente na árvore de visualização.
2.4 DIAGRAMA DE CLASSES
O diagrama de classes é utilizado na construção do modelo de classes desde o nível de
análise até o nível de especificação. De todos os diagramas UML, esse é o mais rico em
termos de notação (BEZERRA, 2002, p. 97).
Uma classe é uma descrição dos atributos, operações um de objeto e é representada
através de uma caixa com três compartimentos em sequência. No compartimento de topo
encontra-se a descrição da classe, no intermediário a lista de atributos e no inferior a lista de
operações. Os atributos correspondem às informações que um objeto armazena e as operações
são as ações que o mesmo realiza (BECKER. 2009, p. 16).
22
Para representar o fato de que objetos podem relacionar-se uns com os outros, existe
um outro elemento do diagrama de classes: a associação (BEZERRA, 2002, p. 99). Uma
associação é uma relação que permite especificar que objetos de uma classe se relacionam
com objetos de outra classe. A multiplicidade possibilita especificar quantos objetos de uma
classe podem ser associados a um objeto de outra classe. O quadro 1 mostra a simbologia
utilizada para representar multiplicidades.
As agregações são conhecidas como um tipo especial de associação. Elas definem uma
relação todo-parte entre dois objetos. As agregações são assimétricas e propagam o
comportamento exercido sobre o objeto todo para todos os objetos parte agregados. Em casos
onde os objetos parte não podem existir sem o objeto todo, utiliza-se um tipo mais forte de
agregação chamado de composição.
Nome
Simbologia
Apenas um
1
Zerou ou muitos
0..*
Um ou muitos
1..*
Zero ou um
0..1
Intervalo Específico
1i..1s
Fonte: Bezerra (2002, p. 100).
Quadro 1 – Simbologia para representar multiplicidades
As associações podem ser agrupadas em três grandes tipos de acordo com sua
conectividade: muitos para muitos, um para muitos e um para um (BEZERRA, 2002, p. 101).
A figura 1 ilustra os tipos de conectividade de associações.
Figura 1 – Tipos de conectividade de associações
2.5 TRABALHOS CORRELATOS
Algumas ferramentas proprietárias desempenham função similar ao ambiente proposto.
23
As ferramentas de automatização de sistemas criadas pela empresa Benner Sistemas
automatizam grande parte do processo de desenvolvimento de seus sistemas ERP. A
ferramenta Spider da empresa Quellon criou uma versão similar para sistemas web. Ambas
mantém um modelo de domínio utilizado como fonte para a geração de seus sistemas. Como
estas ferramentas foram criadas para uso interno, optou-se por focar em ferramentas
documentadas publicamente através de artigos científicos.
Nas seções 2.5.1, 2.5.2 e 2.5.3 são apresentadas as ferramentas Tadeus, Teallach e
Merlin, respectivamente.
2.5.1
Tadeus
Tadeus implementa os modelos de tarefas, de usuário, de domínio e de diálogo para
gerar interfaces de usuário (SCHLUNGBAUM, 1996, p. 7). Tadeus gera interfaces para
sistemas UIMS existentes utilizando um arquivo de descrição da IU. O modelo de usuário
descreve suas funções hierarquicamente através de atributos de tarefas independentes e
dependentes, ou seja, a IU se adapta de acordo com as relações definidas entre o modelo
usuário e o modelo de tarefas.
Com base nos modelos de tarefas, usuário e domínio é criado o modelo de diálogo.
Dois níveis de diálogo são descritos no modelo de diálogo de Tadeus: a navegação e o
processamento da IU. A IU final é gerada automaticamente a partir de modelos declarativos,
base de conhecimentos ergonômicos e uma interação final com o desenvolvedor a fim de
solicitar informações não específicas. A figura 2 demonstra o modelo de apresentação da
ferramenta.
Fonte: Schlungbaum (1996, p. 8).
Figura 2 – Modelo de apresentação da ferramenta Tadeus
24
2.5.2
Teallach
O Teallach é uma ferramenta MBUIDE específica para construção de IUs para
sistemas existentes e implementa os modelos de domínio, apresentação e tarefas. O modelo de
domínio reflete a estrutura, funcionalidade da aplicação, sua conectividade e interação. São
utilizados os conceitos especificados em Object Data Management Group (ODMG) para
garantir a independência de plataforma no modelo de domínio.
ODMG lista uma coleção de informações que abrangem desde problemas de IU até
métodos fundamentais utilizados para manipular todo tipo de componente existente no
modelo (GRIFFITHS, 2001, p. 33). A figura 3 demonstra a interface do modelo de
apresentação da ferramenta.
Fonte: Griffiths (2001).
Figura 3 – Modelo de apresentação da ferramenta Teallach
2.5.3
Merlin
Merlin é uma MBUIDE com ênfase na geração de interfaces CRUD. As características
fundamentais da ferramenta são a geração de IUs em tempo de execução, a configuração
norteada pela edição textual assistida dos modelos, uma base construída em padrões e
linguagens de mercado, reuso transparente, gerenciamento de configurações e a modelagem
centrada no modelo de domínio da aplicação (MRACK, 2009, p. 30). A figura 4 mostra a
geração de uma IU e seu mapeamento na ferramenta Merlin.
25
Fonte: Mrack (2009, p. 36).
Figura 4 – Mapeamento das definições para a IU do Merlin
26
3 DESENVOLVIMENTO
Apresentam-se a seguir os requisitos principais, diagramas, as especificações, a
implementação, um estudo de caso e por fim os resultados obtidos com a realização do
presente trabalho.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
De acordo com o objetivo proposto no trabalho, desenvolveu-se duas ferramentas
denominadas ferramenta modeladora e ferramenta interpretadora, sendo ambas parte do
ambiente. A ferramenta modeladora permite a especificação de sistemas em uma linguagem
de alto nível, ou seja, através do registro de informações sobre características do sistema. A
ferramenta interpretadora é responsável por carregar o modelo de domínio, interpretá-lo e
apresentar um sistema de informação para o usuário final.
Nos quadros 2 e 3 são apresentados os principais requisitos funcionais da ferramenta
modeladora e da ferramenta interpretadora respectivamente. No quadro 4 são apresentados os
requisitos não funcionais do ambiente.
REQUISITOS FUNCIONAIS – FERRAMENTA MODELADORA
RF01 – A ferramenta deve permitir o cadastro informações de módulos de sistema
RF02 – A ferramenta deve permitir o cadastro de informações de IUs
RF03 – A ferramenta deve permitir o cadastro de informações de controles visuais
RF04 – A ferramenta deve permitir o cadastro de informações de pastas do sistema
RF05 – A ferramenta deve permitir criar uma conexão com o banco de dados
Quadro 2 – Requisitos funcionais da ferramenta modeladora
REQUISITOS FUNCIONAIS – FERRAMENTA INTERPRETADORA
RF01 – A ferramenta deve carregar informações do modelo de domínio
RF02 – A ferramenta deve gerar IUs em tempo de execução
RF03 – A ferramenta deve permitir a navegação de registros em árvore de navegação
RF04 – A ferramenta deve permitir realizar operações de CRUD na IU
Quadro 3 – Requisitos funcionais da ferramenta interpretadora
27
REQUISITOS NÃO FUNCIONAIS
RNF01 – O ambiente deve utilizar banco de dados firebird 2.0 em diante
RNF03 – O ambiente deve ser desenvolvido em Delphi 7
RNF04 – O ambiente deve ser desenvolvido na plataforma Microsoft Windows XP
RNF05 – O ambiente deve disponibilizar um tipo de controle visual para armazenar dados do
tipo cadeia de caracteres
RNF06 – O ambiente deve disponibilizar controles visuais para manipular dados do tipo
alfanumérico, inteiro, real, lógico, data (dia, mês, ano), relacionamento entre tabelas e tipos
enumerados
Quadro 4 – Requisitos não funcionais do ambiente de desenvolvimento
3.2 ESPECIFICAÇÃO
É utilizada a UML como linguagem de especificação dos diagramas de caso de uso, de
classes e de atividades. Os diagramas de caso de uso e seus respectivos cenários são
detalhados na seção 3.2.1. Já na seção 3.2.2 é apresentado o diagrama de atividades da
ferramenta interpretadora.
3.2.1 Diagramas de casos de uso
A figura 5 mostra os casos de uso do ator programador para ferramenta modeladora. Já
a figura 6 mostra o caso de uso do usuário para a ferramenta interpretadora. Os diagramas
foram especificados utilizando-se a ferramenta ArgoUML.
28
Figura 5 – Diagrama de casos de uso da ferramenta modeladora
Figura 6 – Diagrama de casos de uso da ferramenta interpretadora
Nos quadros seguintes são apresentados os cenários principais, alternativos e de
exceções dos casos de uso da ferramenta modeladora. O caso de uso UC05 da ferramenta
interpretadora são representados por um diagrama de atividades na seção 3.2.2.
29
UC01 - Manter módulo
Objetivo: Manter informações sobre módulos de sistema
Pré-condições: Modelo de domínio deve existir e registro selecionado
Pós-condições: Informações dos módulos incluídas/alteradas/excluídas corretamente na
base de dados
Cenário principal:
1. Sistema apresenta interface de manutenção módulos de sistema
2. Usuário clica no botão inserir módulo
3. Usuário informa o nome do módulo
4. Usuário informa o caption do módulo
5. Usuário pressiona salvar
6. Sistema valida a existência de um módulo com mesmo nome
7. Sistema salva as informações
* No passo 3, o usuário pode cancelar o processo
Cenário alternativo:
Excluir: No passo 1 do cenário principal, caso usuário opte por excluir:
1. Sistema exclui o registro selecionado
Alterar: No passo1 do cenário principal, caso usuário altere alguma propriedade
do módulo:
1. Sistema habilita modo de edição
2. Usuário pressiona salvar
3. Sistema salva as informações
* No passo 1 o usuário pode cancelar o processo
Cenário exceção:
No passo 5 do cenário principal, caso seja identificado a existência de um módulo de
mesmo nome:
1. Sistema cancela o processo
2. Sistema apresenta uma mensagem solicitando que o usuário altere o nome
do módulo
3. Retorna ao passo 3 do cenário principal
Quadro 5 – Caso de uso manter módulos
30
UC02 - Manter IUs
Objetivo: Manter informações sobre IUs
Pré-condições: O modelo de domínio deve existir e registro selecionado
Pós-condições: Informações das IUs incluídas/alteradas/excluídas corretamente na base
de dados
Cenário principal:
1. Sistema apresenta interface para manutenção de IUs
2. Usuário clica no botão inserir IU
3. Usuário informa o nome da IU
4. Usuário pressiona salvar
5. Sistema valida a existência de uma IU de mesmo nome
6. Sistema salva as informações
7. Sistema insere a tabela para referenciar a IU no banco de dados
* No passo 3, o usuário pode cancelar o processo
Cenário alternativo:
Excluir: No passo 1 do cenário principal, caso usuário opte por excluir:
1. Sistema exclui o registro posicionado
Alterar: No passo 1 do cenário principal, caso usuário altere alguma propriedade
da IU:
1. Sistema habilita modo de edição
2. Usuário pressiona salvar
3. Sistema salva as informações
* No passo 1 o usuário pode cancelar o processo
Cenário exceção:
No passo 5 do cenário principal, caso seja identificado a existência de uma IU de mesmo
nome:
1. Sistema cancela o processo
2. Sistema apresenta uma mensagem solicitando que o usuário altere o nome
da IU
3. Retorna ao passo 3 do cenário principal
Quadro 6 – Caso de uso manter IUs
31
UC03 – Manter controles visuais
Objetivo: Manter informações sobre controles visuais das IUs
Pré-condições: Uma IU deve existir e registro selecionado
Pós-condições: Informações dos controles visuais incluídas/alteradas/excluídas
corretamente na base de dados
Cenário principal:
1. Sistema apresenta interface de manutenção de controles visuais das IUs
2. Usuário clica no botão inserir controle visual
3. Usuário informa o nome do controle visual
4. Usuário informa as propriedades do controle visual
5. Usuário pressiona salvar
6. Sistema valida a existência de um controle visual de mesmo nome
7. Sistema salva as informações
8. Sistema insere o campo para referenciar o controle visual no banco de dados
* Nos passos 3 e 4, o usuário pode cancelar o processo
Cenário alternativo:
Excluir: No passo 1 do cenário principal, caso usuário opte por excluir:
1. Sistema exclui o registro posicionado
Alterar: No passo 1 do cenário principal, caso usuário altere alguma propriedade
do controle visual:
1. Sistema habilita modo de edição
2. Usuário pressiona salvar
3. Sistema salva as informações
* No passo 1 o usuário pode cancelar o processo
Cenário exceção:
No passo 6 do cenário principal, caso seja identificado a existência de um controle visual
de mesmo nome:
1. Sistema cancela o processo
2. Sistema apresenta uma mensagem solicitando que o usuário altere o nome
do controle
3. Retorna ao passo 3 do cenário principal
Quadro 7 – Caso de uso manter controles visuais
32
UC04 - Manter pastas
Objetivo: Manter informações sobre pastas do sistema
Pré-condições: O modelo de domínio deve existir e registro selecionado
Pós-condições: Informações das pastas incluídas/alteradas/excluídas corretamente na
base de dados
Cenário principal:
1. Sistema apresenta interface para manutenção de pastas
2. Usuário clica no botão inserir pasta
3. Usuário informa o nome da pasta
4. Usuário informa as propriedades da pasta
5. Usuário pressiona salvar
6. Sistema valida a existência de uma pasta de mesmo nome
7. Sistema salva as informações
* No passos 3 e 4, o usuário pode cancelar o processo
Cenário alternativo:
Excluir: No passo 1 do cenário principal, caso usuário opte por excluir:
1. Sistema exclui o registro posicionado
Alterar: No passo 1 do cenário principal, caso usuário altere alguma propriedade
da pasta:
1. Sistema habilita modo de edição
2. Usuário pressiona salvar
3. Sistema salva as informações
* No passo 2 o usuário pode cancelar o processo
Cenário exceção:
No passo 6 do cenário principal, caso seja identificado a existência de uma pasta de
mesmo nome:
1. Sistema cancela o processo
2. Sistema apresenta uma mensagem solicitando que o usuário altere o nome
da IU
3. Retorna ao passo 3 do cenário principal
Quadro 8 – Caso de uso manter pastas
3.2.2 Diagrama de atividades
Esta seção apresenta o diagrama de atividades da ferramenta interpretadora. Na figura
7 é ilustrado o processo executado pelo interpretador ao ser executado pelo usuário.
33
Figura 7 – Diagrama de atividades do UC05
3.3 IMPLEMENTAÇÃO
Esta seção apresenta as ferramentas e técnicas utilizadas no desenvolvimento do
trabalho proposto. São apresentados o ambiente de desenvolvimento, a linguagem de
programação, o banco de dados, o modelo de domínio, a ferramenta modeladora, o modelo de
aplicação, apresentação e diálogo, as técnicas para carregamento do modelo em memória, as
34
técnicas para montagem da árvore de navegação de registros, as técnicas para geração de
interfaces e por fim, a ferramenta interpretadora.
3.3.1 Técnicas e ferramentas utilizadas
Para implementação do ambiente utilizou-se a linguagem de programação Delphi no
ambiente Embarcadero RAD Studio XE2 e o banco de dados Firebird. A escolha da
ferramenta está ligada à facilidade de implementação de sistemas gráficos e o seu
conhecimento prévio. Delphi é uma linguagem de programação muito bem conceituada no
mercado, seu ambiente possui os mais variados componentes e bibliotecas, sendo a facilidade
de programação para banco de dados uma das características que consagrou essa linguagem
de programação.
Firebird é um SGBD desenhado para atuar em diferentes plataformas como Linux,
Windows e diversos tipos de plataforma Unix.
3.3.1.1 Modelo de domínio
O modelo de domínio é referenciado por um modelo de diagrama de classes, definido
de forma a armazenar informações necessárias para a geração do sistema de informação e
suas IUs CRUD. A figura 8 demonstra o diagrama de classes do modelo proposto para o
ambiente. O diagrama de classes foi obtido através de uma ferramenta geradora de diagramas
existente dentro do ambiente RAD Studio XE2, capaz de ler a estrutura de classes dentro do
código fonte do projeto.
35
Figura 8 – Diagrama de classes do modelo de domínio
O diagrama de classes foi montado de forma a proporcionar rápido acesso às
informações do sistema. O diagrama possui duas classes principais, a classe TMemStruct e a
36
classe TMemObj. A classe TMemStruct foi construída para servir como uma lista de objetos,
sendo a base para as classes TSystemInterfaces, TInterfaceFields, TSystemFolders,
TSystemModules.
Essas classes representam as tabelas do modelo de domínio.
A classe TMemObj é a base para as classes que serão parte integrante das listas em
memória, sendo estas as classes TInterfaceField, TSystemInterface, TSystemFolder e
TSystemModule.
Essas classes representam os registros das tabelas do modelo de domínio. A
relação da lista com os itens da lista é dada pela associação existente entre TMemStruct e
TMemObj.
O conjunto de listas, itens e seus relacionamentos formam o modelo de domínio em
memória. Os dados do modelo são utilizados como consulta pelo interpretador, evitando o
acesso ao banco de dados sempre que um dado do modelo precisa ser lido. A figura 9
demonstra o Diagrama de Entidades Relacional (DER) criado a partir da estrutura apresentada
no diagrama de classes da figura 8.
Figura 9 – DER do modelo de dados
O modelo foi criado tomando-se como base o mecanismo de funcionamento do
modelo de apresentação da ferramenta interpretadora e levando-se em conta a navegação de
registros em árvore. O modelo de dados localiza-se no mesmo banco de dados utilizado para
armazenar as informações do sistema especificado. Isso permite que a ferramenta modeladora
gerencie e mantenha este banco de dados. O quadro 9 demonstra a forma de mapeamento do
37
modelo de classes para o modelo de dados na arquitetura. O quadro 10 apresenta o dicionário
de dados referente ao DER apresentado na figura 9.
Classe (figura 8)
TSystemModule
TSystemFolder
TSystemInterface
TFormFilterCondition
TInterfaceField
Mapeamento (figura 9)
SystemModules.
SystemFolder.
SystemInterface.
SystemFolderFilter
SystemFields.
Quadro 9 – Mapeamento classe x tabela
Campo
HANDLE
NAME
PARAMS
Campo
HANDLE
NAME
CLASS
INTERFACE
PARAMS
SYSTEMINTERFACE
Descrição
Chave primária
Nome da IU
Parâmetros da IU
SYSTEMFIELD
Descrição
Chave primária
Nome do controle visual
Tipo do controle visual
IU na qual o controle pertence
Parâmetros do controle visual
Campo
HANDLE
NAME
INTERFACE
MODULE
FOLDER
PARAMS
SYSTEMFOLDER
Descrição
Chave primária
Nome da pasta
IU listada na pasta
Módulo na qual a pasta será listada
Pasta superior (se existir)
Parâmetros da pasta
Campo
HANDLE
NAME
PARAMS
SYSTEMMODULE
Descrição
Chave primária
Nome do módulo
Parâmetros do módulo
SYSTEMFOLDERFILTER
Campo
Descrição
HANDLE
Chave primária
INTERFACE
IU utilizada no filtro
FIELD
Campo que será filtrado
FOLDER
Pasta utilizada no filtro
OPERATION
Operação (=,<>,>=,<=)
CONDITION
Valor do filtro
PARAMS
Parâmetros adicionais do filtro
Quadro 10 – Dicionário de dados
38
A tabela systeminterfaces armazena dados referentes ao modelo de diálogo do
ambiente. Para isso, cada registro da tabela systeminterfaces faz referência a uma IU. O
quadro 11 mostra as propriedades da IU implementadas neste ambiente.
Propriedade
Create
Update
Delete
Tipo
Lógico
Lógico
Lógico
Interfaces de Usuário
Objetivo
Permitir adicionar registros a partir desta interface.
Permitir alterar registros na interface.
Permitir a exclusão de registros na interface.
Quadro 11 – Propriedades da IU
A entidade systemfields armazena informações referentes ao modelo de
apresentação. Cada controle definido no modelo possui uma representação visual na IU. Uma
série de propriedades e diferentes comportamentos podem ser configurados para cada tipo de
controle, de acordo com a característica de cada dado que ele irá manipular. Este modelo
define seis diferentes tipos de controles visuais, cada qual com o objetivo de manipular um
tipo de dado na IU gerada. O quadro 12 demonstra os objetivos para cada tipo de controle
visual que pode ser definido no ambiente e o quadro 13 apresenta as propriedades em comum
para todos os tipos de controles.
Tipo de controle
Literal
Número
Lógico
Data/Hora
Relacionamento
Lista
Controles Visuais
Objetivo
Manipular tipos de dados alfanuméricos.
Manipular tipos dados inteiros ou fracionários.
Manipular tipos dados lógicos (boleanos).
Manipular tipos de dados data e hora.
Manipular relacionamento entre interfaces.
Manipular tipos enumerados.
Quadro 12 – Objetivos de cada tipo de controle visual
Propriedade
Name
Valor
Literal
Mandatory
Lógico
Insertonly
Lógico
Readonly
Initwith
Caption
Lógico
Lógico
Literal
Order
Inteiro
Propriedades em comum
Objetivo
Nome do controle visual. Propriedade também
utilizada para criação do campo no banco de dados.
Define obrigatoriedade de preenchimento para este
campo.
Define que este campo somente será visível na
inserção de registros.
Define este campo como somente leitura.
Define inicialização para o campo.
Informação descritiva do controle visual. Mostra
para o usuário que tipo de informação esse dado
manipula.
Sequência em que o controle visual aparece na IU.
Quadro 13 – Propriedades comuns entre as definições de controle
39
A entidade systemfolders armazena as informações que são utilizadas para
complementar o modelo de diálogo e define as pastas do sistema especificado. A utilização do
conceito pastas está ligada ao componente de navegação de registros em árvore. Nesse
conceito, uma pasta é um galho e um registro pode ser um galho ou uma folha.
As pastas quando expandidas disparam um comando de consulta para o banco de
dados e os registros retornados são listados como nós filhos da pasta expandida. Este
comando de consulta é montado dinamicamente utilizando as propriedades informadas na
definição da pasta na ferramenta modeladora. O quadro 14 mostra as propriedades das pastas.
Propriedade
Caption
Interface
Listfield
Module
Folder
Linkfield
Pastas
Objetivo
Descritivo da pasta.
Indica Interface listada ao expandir a pasta.
Indica o campo da interface que será listado na pasta.
Indica qual módulo esta pasta poderá ser visualizada .
Indica a existência de um relacionamento com a pasta superior.
Indica o campo de relacionamento com a IU listada na pasta
superior.
Quadro 14 – Propriedades das pastas
Utilizando dados de relacionamentos entre interfaces contidas no modelo de dados as
pastas podem ainda criar um mecanismo intuitivo de navegação entre conjuntos de
informações. A sequência de figuras a seguir ilustram a forma de abordagem dos diferentes
tipos de conectividades na ferramenta interpretadora. As figuras 10 e 11 ilustram o resultado
obtido ao definir as entidades pessoa e telefone e seu relacionamento um para muitos. As
figuras 12 e 13 mostram o resultado obtido ao definir as entidades funcionário e
departamento
e seu relacionamento muitos para muitos. Já as figuras 14 e 15 ilustram o
resultado obtido ao definir as entidades fatura e recibo e seu relacionamento um para um.
40
Figura 10 – Exemplo de um diagrama de classes com relacionamento um para muitos
Figura 11 – Resultado obtido ao definir o relacionamento um para muitos
41
Figura 12 – Exemplo de um diagrama de classes com relacionamento muitos para muitos
Figura 13 – Resultado obtido ao definir um relacionamento muitos para muitos
42
Figura 14 – Exemplo de um diagrama de classes com relacionamento um para um
Figura 15 – Resultado obtido ao definir um relacionamento um para um
A entidade Systemfolderfilters armazena dados que podem ser utilizados como
filtro de pastas. Caso exista um filtro para a pasta, ele será inserido na montagem do comando
de consulta. Estes filtros são disponibilizados ao selecionar uma pasta na árvore de
navegação. A figura 16 mostra um exemplo de definição de filtro de pastas e a figura 17
mostra o resultado obtido com esta definição.
43
Figura 16 – Exemplo de montagem de filtro de pasta
Figura 17 – Resultado obtido na aplicação do filtro de pasta
A entidade systemmodule armazena as informações sobre os módulos do modelo e
classifica os subsistemas existentes.
44
3.3.1.2 Ferramenta modeladora
A ferramenta modeladora é um sistema de cadastro e gerenciamento de informações
que compõe o modelo de dados proposto. Através dela, o desenvolvedor especifica as IUs, os
controles visuais, as pastas e os módulos do sistema. A ferramenta agrega ainda funções de
manutenção, integridade do modelo e conexão ao banco de dados.
A opção criar conexão solicita as informações necessárias para a conexão com o banco
de dados e as salva em um arquivo de extensão conn. Este arquivo contém informações sobre
o caminho da base de dados, a segurança de acesso e as configurações que dizem respeito às
propriedades de conexão do banco de dados. A figura 18 mostra o formulário de criar
conexão.
Figura 18 – Criar conexão
O nome da conexão é utilizado para nomear o arquivo de conexão gerado. No campo
arquivo do banco informa-se o caminho do arquivo físico da base de dados Firebird e os
campos usuário e senha dizem respeito ao usuário e senha de segurança de acesso ao banco de
dados. As figuras 19 e 20 mostram o cadastro de IUs, controles visuais, pastas e módulos na
ferramenta modeladora.
45
Figura 19 – Cadastro de IUs e controles visuais
Figura 20 – Cadastro de módulos e pastas
46
3.3.1.3 Modelo de aplicação, diálogo e apresentação
A ferramenta interpretadora engloba o modelo de aplicação, diálogo e apresentação,
sendo estes implementados no componente FormMain. O modelo de apresentação é definido
utilizando-se a estrutura AIO, onde o programador define as características dos campos na
ferramenta modeladora. Estas características são passadas para os controles visuais na sua
criação.
O componente FormMain é um container do sistema propriamente dito e consiste de
um formulário que possui 3 componentes principais, o controle de páginas, a árvore de
visualização e a área destinada à fixação da IU gerada. Cada componente exerce uma função
específica e a interação entre eles torna a ferramenta interpretadora o próprio sistema final. A
figura 21 mostra a disposição dos componentes mencionados na montagem do sistema e no
quadro 15 é apresentada a legenda que identifica os componentes da figura 21.
Figura 21 – Componentes do interpretador do ambiente
1
2
3
4
Legenda
Componente FormMain.
Controle de páginas (Módulos do sistema)
Árvore de navegação em registros
IU gerada
Quadro 15 – Legenda
47
O controle de páginas, também conhecido como PageControl, é um componente
visual que apresenta páginas sobrepostas acessíveis através de uma orelha, permitindo ao
usuário selecionar a página clicando na orelha que aparece no topo do componente. Isso
permite que o componente FormMain organize os módulos de sistema como páginas de um
PageControl
possibilitando ao usuário rápida transição entre os módulos do sistema.
Cada módulo do sistema possui uma árvore de navegação de registros e uma área
designada para a IU. A árvore de navegação de registros é implementada utilizando os
eventos que o componente TreeView disponibiliza. Eventos são recursos de componentes
utilizados para notificar agentes externos quando uma determinada ação é exercida. Os
eventos mais importantes dentre os utilizados são os eventos OnExpanding e OnChange que
são responsáveis pela listagem e interação dos registros com a IU respectivamente.
O evento OnExpanding é disparado quando um nó da árvore é expandido e nele são
implementadas as rotinas que listam os registros na árvore. O evento OnChange é disparado
quando o usuário seleciona um nó da árvore. Selecionando-se um nó do tipo registro é
apresentada a interface na qual o nó referencia na área designada à IU gerada. Existe grande
interação entre a IU e a árvore de visualização. A ação de uma delas pode gerar uma reação
em outra. Esse grande nível de interação possibilita maior automatização no processo de
consulta e geração da IU. O quadro 16 detalha a chamada do evento OnExpanding da
Treeview.
Os quadros 17, 18 e 19 detalham os métodos ListNode, ListRecords e
ListFolders
chamados dentro do evento OnExpanding respectivamente.
procedure TFormMain.tvTreeExpanding(Sender: TObject;
Node: TTreeNode; var AllowExpansion: Boolean);
Begin
Node.Selected := True;
ListNode(Node);
end;
Quadro 16 – Método OnExpanding da Treeview
procedure TFormMain.ListNode(Node: TTreeNode);
begin
if Assigned(Node) then
begin
if TObject(Node.Data) is TFolderData then
ListRecords(Node)
else
ListFolders(Node);
end;
end;
Quadro 17 – Método ListNode chamado no evento OnExpanding da Treeview
48
procedure TFormMain.ListRecords(Node: TTreeNode);
var
QTree: TQuery;
NodeAux: TTreeNode;
i, iField: Integer;
sFields, sFieldsOrder: String;
sWhere: String;
FRecord: TRecordData;
Query: TSQLQuery;
SL: TStringList;
begin
Query := TSQLQuery.Create(nil);
SL := TStringList.Create;
try
Query.SQLConnection := DM.SQLConn;
Query.SQL.Text := TFolderData(Node.Data).SQL;
Query.Open;
if (Query.Eof) then
TreeViewNewRecord(node)
else
begin
DM.SystemFolders.GetListFolders(TFolderData(Node.Data).SystemFolder.Han
dle, SL);
while not Query.EOF do
begin
NodeAux := tvTree.Items.AddChild(node,
Query.FieldByName(TFolderData(Node.Data).SystemFolder.Params.Values['LI
STFIELD']).AsString);
FRecord := TRecordData.Create;
FRecord.Handle := Query.FieldByName('HANDLE').AsInteger;
FRecord.SytemInterface :=
TFolderData(Node.Data).SystemFolder.SystemInterface;
NodeAux.HasChildren := SL.Count <> 0;
NodeAux.Data := FRecord;
Query.Next;
end;
end;
finally
SL.Free;
Query.Free;
end;
End;
Quadro 18 – Método ListRecords
49
procedure TFormMain.ListFolders(Node: TTreeNode);
var
SL: TStringList;
HandleParentFolder: Integer;
i: Integer;
NodeAux: TTreeNode;
FolderData: TFolderData;
begin
if not Assigned(Node) then
HandleParentFolder := 0
else
HandleParentFolder :=
TFolderData(Node.Parent.Data).SystemFolder.Handle;
SL := TStringList.Create;
try
DM.SystemFolders.GetListFolders(HandleParentFolder, SL);
for i:=0 to SL.Count-1 do
begin
FolderData := TFolderData.Create;
FolderData.SystemFolder := TSystemFolder(SL.Objects[i]);
FolderData.SQL:='SELECT * FROM '+
FolderData.SystemFolder.SystemInterface.Name;
if Assigned(Node) then
FolderData.SQLWhere :=
FolderData.SystemFolder.Params.Values['LINKFIELD']
+ ' = '+ IntToStr(TRecordData(Node.Data).Handle);
NodeAux := tvTree.Items.AddChild(Node,
FolderData.SystemFolder.Params.Values['CAPTION']);
NodeAux.HasChildren := True;
NodeAux.Data := FolderData;
end;
finally
SL.Free;
end;
end;
Quadro 19 – Método ListFolders
3.3.1.4 Processo de carregamento do modelo de dados em memória
O componente FormMain cria o objeto DataModule que se conecta no banco de dados
do modelo. As informações necessárias para efetuar a conexão estão no arquivo de conexão
criado pela ferramenta modeladora. O nome do arquivo deve ser passado como parâmetro na
execução da ferramenta interpretadora.
Depois de efetuada a consistência das informações contidas no arquivo de conexão, o
objeto DataModule abre uma conexão com o banco de dados e executa o procedimento start
que iniciará o processo para carregar o modelo para memória. O quadro 20 mostra o método
start.
50
1. procedure TDM.Start;
2. var
3.
InitFile: String;
4.
SL : TStringList;
5. begin
6.
DoMessage('Iniciando o sistema...');
7.
if (ParamCount = 0) then //
8.
raise Exception.Create(errRUN001);
9.
Initfile:= IncludeTrailingBackslash(
10. ExtractFileDir(Application.ExeName));
11. Initfile := Initfile +ParamStr(1) + '.conn';
12. if not FileExists(InitFile) then
13.
raise Exception.CreateFmt(errRUN002);
14. SQLConn.Params.LoadFromFile(InitFile);
15. DoMessage('Carregando definições do modelo de dados...');
16. try
17.
LoadInterfaceDefinition;
18.
LoadInterfaceFieldDefinition;
19.
LoadModulesDefinition;
20.
LoadSystemFoldersDefinition;
21. except
22.
raise Exception.Create(errRUN002);
23. end;
24. end;
Quadro 20 – Método que inicia o processo carregamento o modelo de dados na memória
O método start testa a existência do arquivo de configuração do banco de dados e
repassa as informações para o objeto de conexão SQLConn. O objeto SQLConn está contido no
DataModule
DoMessage
e é responsável por manter uma conexão ativa com o banco de dados. O método
(linha 6) envia uma informação para a camada visual informando ao usuário qual
etapa da inicialização está sendo processada.
Em seguida são chamados os métodos responsáveis por carregar o modelo lógico. O
método LoadInterfaceDefinition (linha 17) carrega as definições de IUs no objeto
SystemInterface
como mostrado no quadro 21.
51
1. procedure TDM.LoadInterfaceDefinition;
2. var
3.
SystemInterface: TSystemInterface;
4.
SQLQuery: TSQLQuery;
5. begin
6.
SQLQuery := TSQLQuery.Create(nil);
7.
try
8.
SQLQuery.SQLConnection := SQLConn;
9.
SQLQuery.SQL.Text := 'SELECT * FROM SYSTEMINTERFACES';
10.
SQLQuery.Open;
11.
while not SQLQuery.Eof do
12.
begin
13.
SystemInterface := TSystemInterface.Create;
14.
SystemInterface.Handle:=
15.SQLQuery.FieldByName('HANDLE').AsInteger;
16.
SystemInterface.Name:=SQLQuery.FieldByName('NAME').AsString;
17.SystemInterface.Params.Text:=SQLQuery.FieldByName('PARAMS').AsString;
18.
FSystemInterfaces.AddObject(SystemInterface);
19.
SQLQuery.Next;
20.
end;
21. finally
22.
SQLQuery.Free;
23. end;
24.end;
Quadro 21 – Método que carrega as definições de IUs
O objeto SQLQuery efetua uma consulta na tabela SystemInterfaces e através de um
laço, os dados coletados são repassados para o objeto SystemInterface. Em seguida, o
objeto SytemInterface é adicionado no objeto FSystemInterfaces (linha 18) que funciona
como uma lista das interfaces do modelo em memória.
Formam
o
modelo
lógico
do
FSystemInterfaceFields, FSystemModules
sistema
as
listas
FSystemInterfaces,
e FSystemFolders. Cada qual armazenando
dados referentes a um componente do sistema. A ferramenta interpretadora percorre o modelo
lógico sempre que precisar consultar um dado do modelo.
Os demais métodos, chamados na sequência, utilizam o mesmo estilo de programação
para carregar seus objetos e listas em memória. Os quadros 22, 23 e 24 mostram os códigos
dos
métodos
LoadInterfaceFieldDefinition,
LoadSystemFoldersDefinition.
LoadModulesDefinition
e
52
procedure TDM.LoadInterfaceFieldDefinition;
var
InterfaceField: TInterfaceField;
SQLQuery: TSQLQuery;
begin
SQLQuery := TSQLQuery.Create(nil);
try
SQLQuery.SQLConnection := SQLConn;
SQLQuery.SQL.Text := 'SELECT A.*,B.HANDLE HANDLEINTERFACE, '+
'B.NAME INTERFACENAME FROM SYSTEMFIELDS A, '+
'SYSTEMINTERFACES B WHERE A.INTERFACE = B.HANDLE';
SQLQuery.Open;
while not SQLQuery.Eof do
begin
InterfaceField := TInterfaceField.Create;
InterfaceField.Handle := SQLQuery.FieldByName('HANDLE').AsInteger;
InterfaceField.Name := SQLQuery.FieldByName('NAME').AsString;
InterfaceField.FieldClass :=
TFieldClass(SQLQuery.FieldByName('CLASS').AsInteger);
with FSystemInterfaces, SqlQuery do
InterfaceField.SystemInterface:=
TSystemInterface(Objects[IndexOfName(FieldByName('INTERFACENAME').AsString)
]);
InterfaceField.Params.Text :=
SQLQuery.FieldByName('PARAMS').AsString;
FInterfaceFields.AddObject(Interfacefield);
SQLQuery.Next;
end;
finally
SQLQuery.Free;
end;
end;
Quadro 22 – Método que carrega as definições dos controles visuais
procedure TDM.LoadModulesDefinition;
var
SystemModule: TSystemModule;
SQLQuery: TSQLQuery;
begin
SQLQuery := TSQLQuery.Create(nil);
try
SQLQuery.SQLConnection := SQLConn;
SQLQuery.SQL.Text := 'SELECT * FROM SYSTEMMODULES';
SQLQuery.Open;
while not SQLQuery.Eof do
begin
SystemModule := TSystemModule.Create;
SystemModule.Handle := SQLQuery.FieldByName('HANDLE').AsInteger;
SystemModule.Name := SQLQuery.FieldByName('NAME').AsString;
SystemModule.Params.Text := SQLQuery.FieldByName('PARAMS').AsString;
SystemModules.AddObject(SystemModule);
SQLQuery.Next;
end;
finally
SQLQuery.Free;
end;
end;
Quadro 23 – Método que carrega as definições dos módulos
53
procedure TDM.LoadSystemFoldersDefinition;
var
SystemFolder: TSystemFolder;
SQLQuery: TSQLQuery;
begin
SQLQuery := TSQLQuery.Create(nil);
try
SQLQuery.SQLConnection := SQLConn;
SQLQuery.SQL.Text := 'SELECT A.*,B.NAME INTERFACENAME, C.NAME
MODULENAME FROM SYSTEMFOLDERS A, SYSTEMINTERFACES B, SYSTEMMODULES C WHERE
A.INTERFACE = B.HANDLE AND A.MODULE = C.HANDLE';
SQLQuery.Open;
while not SQLQuery.Eof do
begin
SystemFolder := TSystemFolder.Create;
SystemFolder.Handle := SQLQuery.FieldByName('HANDLE').AsInteger;
SystemFolder.Name := SQLQuery.FieldByName('NAME').AsString;
SystemFolder.SystemInterface := TSystemInterface(
FSystemInterfaces.Objects[FSystemInterfaces.IndexOfName(
SQLQuery.FieldByName('INTERFACENAME').AsString)]);
SystemFolder.SystemModule := TSystemModule(
FSystemModules.Objec ts[FSystemModules.IndexOfName(
SQLQuery.FieldByName('MODULENAME').AsString)]);
SystemFolder.HandleParentFolder :=
SQLQuery.FieldByName('FOLDER').AsInteger;
SystemFolder.Params.Text := SQLQuery.FieldByName('PARAMS').AsString;
SystemFolders.AddObject(SystemFolder);
SQLQuery.Next;
end;
finally
SQLQuery.Free;
end;
end;
Quadro 24 – Método que carrega as definições das pastas
3.3.1.5 Processo de geração de IUs
O processo de geração de uma IU consiste em localizar seus campos em memória,
criá-los no formulário, associá-los ao banco e apresentá-los ao usuário. As IUs são
organizadas em duas colunas de controles visuais e não proporcionam ajuste automático de
redimensionamento de janela. Os controles visuais foram desenhados de forma a ocupar o
mínimo possível de espaço na IU. A figura 22 mostra a disposição dos controles visuais na
geração de uma IU.
54
Figura 22 – Disposição dos controles visuais em duas colunas
Durante a geração da IU, as informações do modelo são mapeadas para os controles
visuais. Sua tabulação segue a ordem informada na propriedade order, definida na ferramenta
modeladora e os botões encontrados no topo da IU permitem ao usuário efetuar operações
CRUD. O quadro 25 mostra o método generatecontrols responsável por gerar as IUs em
tempo de execução.
55
1. procedure TFormCRUD.GenerateControls;
2. var
3.
SL: TStringList;
4.
i : Integer;
5.
Control: TWinControl;
6.
FLabel: TLabel;
7.
YPos: Integer;
8.
InterfaceField: TInterfaceField;
9. begin
10. SL := TStringList.create;
11. try
12.
DM.InterfaceFields.GetListoffFields(FSystemInterface, SL);
13.
for i:=0 to SL.count-1 do
14.
begin
15.
InterfaceField := TInterfaceField(Sl.Objects[i]);
16.
case TInterfaceField(Sl.Objects[i]).FieldClass of
17.
fcString: Control := CreateStringControl(InterfaceField);
18.
fcNumber: Control := CreateNumberControl(InterfaceField);
19.
fcBoolean: Control := CreateBoolControl(InterfaceField);
20.
fcDate: Control := CreateDateTimeControl(InterfaceField);
21.
fcInterface: Control :=
22. CreateInterfaceControl(InterfaceField);
23.
fcList: Control := CreateListControl(InterfaceField);
24.
25.
end;
26.
FLabel := TLabel.Create(Self);
27.
FLabel.Caption :=
28.TInterfaceField(Sl.Objects[i]).Params.Values['CAPTION'];
29.
FLabel.Parent := Self;
30.
Control.Tag := Integer(FLabel);
31.
Control.Name := InterfaceField.Name;
32.
FFormControls.AddObject(InterfaceField.Name, Control);
33.
34.
Control.Width := FMaxWidth;
35.
end;
36. finally
37.
SL.Free;
38. end;
39.end;
Quadro 25 – Método generatecontrols
O método DM.InterfaceFields.GetListoffFields (linha 12) retorna a lista dos
campos da IU em memória. A lista é percorrida verificando-se os tipos de cada campo e
criando seus controles visuais correspondentes. Depois de finalizado este processo, cria-se um
componente TLabel para identificar o controle visual na IU e o adiciona na lista de controles
visuais da IU referenciada pelo objeto FFormControls.
56
3.3.2 Operacionalidade da implementação
Nesta seção são apresentadas algumas funcionalidades do ambiente através de um
estudo de caso. A figura 23 mostra o diagrama de classes de um sistema de locação de carros
utilizado neste estudo. É importante salientar que o DER é meramente para ilustrar o estudo
de caso, não havendo necessidade de sua existência para iniciar a modelagem na ferramenta
modeladora.
Figura 23 – Diagrama de classes do sistema de locação de carros
Ao acessar a ferramenta modeladora é necessário parametrizar uma conexão com o
banco de dados como mostrado na figura 24. Estas informações serão salvas em um arquivo
de conexão localizado no diretório onde está contido o executável.
57
Figura 24 – Parametrização da conexão com o banco de dados
Depois de criado o arquivo de conexão, deve-se abri-lo utilizando a opção abrir
arquivo de conexão. A figura 25 mostra o diálogo abrir conexão.
Figura 25 – Abrir conexão com o banco de dados
58
O usuário seleciona o arquivo de conexão desejado e pressiona o botão Abrir. Nesse
momento a ferramenta carrega a árvore de navegação com as propriedades do sistema como
demonstrado na figura 26.
Figura 26 – Propriedades do sistema listadas na árvore de navegação
Nesse momento inicia-se a modelagem do sistema propriamente dita. O processo de
modelagem consiste em mapear cada entidade do diagrama de classes para uma IU de
sistema. As propriedades das entidades e seus relacionamentos são mapeados para controles
visuais. Expandindo o nó interfaces na árvore de navegação, pode-se adicionar novas IUs ao
sistema. A figura 27 demonstra o processo de inclusão de uma IU.
59
Figura 27 – Inclusão de IUs
Ao acionar o botão Salvar, a ferramenta inclui a IU no modelo de domínio e cria uma
tabela no banco de dados para armazenar as informações que serão manipuladas pela IU.
Nesse estágio deve-se cadastrar as IUs fabricante, modelo, grupo, automovel,
locacao e pessoa.
Finalizado esse processo, nós são adicionados na árvore para referenciar cada IU
adicionada. Expandindo-se este nó possibilita a inclusão de controles visuais para a IU como
mostrado na figura 28.
60
Figura 28 – Inclusão de controles visuais
Neste estágio são definidas as propriedades e os comportamentos dos controles visuais.
A ferramenta modeladora cria um campo na tabela recém-criada para referenciar cada
controle visual de uma IU. No caso de um controle visual do tipo relacionamento, uma chave
estrangeira é criada automaticamente. Não recomenda-se executar a ferramenta interpretadora
durante a modelagem, isto pode ocasionar problemas de execução no sistema.
Finalizada a definição das IUs e controles visuais do sistema, faz-se necessário
disponibilizá-las no sistema através da definição das pastas e módulos do sistema. Para definir
pastas de sistema deve-se expandir o nó pastas, assim como para definir módulos de sistema
deve-se expandir o nó módulos na árvore de navegação. As figuras 29 e 30 mostram as IUs da
ferramenta modeladora responsáveis pelas definições de módulos e pastas do sistema
respectivamente.
61
Figura 29 – Inclusão de pastas do sistema
Figura 30 – Inclusão de módulos do sistema
As pastas são ligadas a subpastas pelo relacionamento existente entre as interfaces. As
propriedades Folder e Linkfield, quando informadas, definem a utilização do
62
relacionamento para criação de uma subpasta. A propriedade Folder indica a pasta superior e
a propriedade Linkfield indica qual o campo da IU definida na pasta superior será utilizado
para efetuar essa ligação. Tomando como exemplo as entidades pessoa e locação do modelo
de caso de uso demonstrado na figura 9, uma pessoa pode ter uma ou mais locações. Para
tanto, é necessário que na tabela de locação exista um campo de relacionamento com a tabela
pessoa.
Ao definir uma pasta para a interface pessoa pode-se utilizar o relacionamento da
interface locação para criar uma subpasta locação. Isto permite que os registros listados ao
expandir um nó com relacionamento sejam somente os registros obtidos pelo relacionamento
definido entre interfaces. As figuras 31 e 32 mostram respectivamente a modelagem da pasta
pessoas e da subpasta locação na ferramenta modeladora. A figura 33 demonstra o resultado
obtido na ferramenta interpretadora.
Figura 31 – Definição da pasta pessoa
63
Figura 32 – Definição da subpasta locação
Figura 33 – Resultado obtido na definição das pastas pessoa e locação
64
A figura 33 ainda demonstra a disposição das pastas no sistema, iniciando com a pasta
grupo no topo da árvore de navegação. Os registros são diferenciados pelo negrito e ao clicar
sobre eles é disparada a geração da IU associada. Verifica-se que expandindo um registro da
pasta grupo são listados os modelos cadastrados como econômicos. A segunda pasta lista os
registros de fabricantes e expandindo os registros pode-se navegar entre os modelos,
chegando no cadastro de automóveis. A última pasta lista registros das pessoas, expandindo
essa pasta é possível encontrar as locações feitas pela pessoa.
Finalizado o processo de definição do estudo de caso, a ferramenta criou um modelo
de dados de acordo com a figura 23. A figura 34 mostra o DER criado pelo ambiente. É
importante salientar que o DER da figura 23 foi criado manualmente utilizando a ferramenta
xcase.
Locacao
Pessoa
Handle:integer
Handle:integer
Nome:varchar(40)
Datahoralocacao:timestamp
Telefone:varchar(15)
Datahoradevolucao:timestamp
Endereco:varchar(50)
Datahoradevolucaoreal:timestamp
Automovel
Handle:integer
Km:integer
Valorlocacao:double precision
Valorcaucao:double precision
Fkpessoa:integer [pessoa.handle]
Fkautom ovel:integer [autom ovel.handle]
Placa:varchar(7)
Km:integer
Numportas:integer
Renavam:varchar(25)
Chassi:varchar(25)
Valorlocacao:double precision
Fkm odelo:integer [m odelo.handle]
Grupo
Handle:integer
Codigo:varchar(10)
Modelo
Nome:varchar(40)
Handle:integer
Nome:varchar(40)
Fabricante
Handle:integer
Fkfabricante:integer [fabricante.handle]
Fkgrupo:integer [grupo.handle]
Nome:varchar(40)
Figura 34 – DER do modelo criado pelo ambiente
3.4 RESULTADOS E DISCUSSÃO
O estudo de caso foi definido e interpretado com sucesso pelo ambiente. Diversos
testes foram efetuados a fim de verificar o funcionamento das propriedades listadas no quadro
13. Como exemplo pode-se exigir que o usuário informe a placa do automóvel durante o seu
cadastro ativando a propriedade mandatory do controle visual. Essas propriedades
automatizam boa parte das verificações necessárias no desenvolvimento de IUs como
65
consistência de dados e comportamento. Isso contribui de forma direta no desenvolvimento
rápido de sistemas informação.
A navegação de registros em árvore demonstrou-se funcional e intuitiva para o usuário.
Houve certa dificuldade de implementação da árvore de navegação de registros devido a
falhas de comportamento do componente TreeView. Em certos momentos o evento OnExpand
é chamado deliberadamente pelo componente TreeView entrando em laço infinito. Testes
efetuados fora da aplicação confirmaram o problema. Diferentes abordagens foram tomadas a
fim de superar esta falha. A solução para o problema foi encontrada desvinculando-se o
evento OnExpand do objeto TreeView na execução de determinadas funções.
Para verificar o funcionamento do ambiente em um contexto prático, importou-se a
tabela de clientes com cerca de 600 registros de uma base de dados existente para dentro da
base de dados criada pela ferramenta modeladora. O processo de geração do modelo deu-se
por ler a estrutura da tabela e replicá-la manualmente na ferramenta.
Foi criado um programa específico para executar a importação dos dados da tabela de
clientes para o modelo do ambiente. Efetuado o processo de importação, o ambiente
funcionou como esperado e sem erros. Neste processo descobriu-se que listar 600 ou mais
registros em uma árvore é confuso para o usuário e gera um pico de utilização de sistema
muito grande. Assim verificou-se que o ideal seria limitar a listagem dos registros em até 100.
Caso a listagem ultrapasse este valor, o sistema deve solicitar um filtro de pasta, corrigindo
assim este problema.
O ambiente possui características que o tornam similar às ferramentas Teallach e
Merlin, diferentemente da ferramenta Tadeus. A ferramenta Teallach define seu modelo de
apresentação através de uma interface de alto nível, sendo este o mesmo método utilizado pela
ferramenta modeladora. A ferramenta Merlin é uma das poucas ferramentas MBUIDE que
utilizam a abordagem de geração de interfaces em tempo de execução assim como a
ferramenta interpretadora. Já a ferramenta Tadeus define suas interfaces na linguagem do
toolkit gráfico e gera código fonte para aplicativos já existentes, uma abordagem muito
diferente do trabalho proposto. O quadro 26 mostra um comparativo entre os modelos
implementados pelos trabalhos correlatos e o ambiente proposto.
66
Teallach
Sim
Merlin
Sim
Tadeus
Sim
Ambiente proposto
Sim
Modelo de apresentação
Sim
Sim
Sim
Sim
Modelo de usuário
Não
Não
Não
Não
Modelo de diálogo
Sim
Sim
Sim
Sim
Modelo de plataforma
Não
Não
Não
Não
Modelo de aplicação
Não
Não
Sim
Sim
Modelo de tarefas
Sim
Não
Sim
Não
Modelo de domínio
Quadro 26 – Comparativo dos modelos de alto nível implementados nas ferramentas
O quadro 26 foi compilado baseando-se em informações obtidas através de artigos e
trabalhos publicados pelos autores das ferramentas. A falta de acesso a estas ferramentas,
impede uma avaliação minuciosa dos modelos implementados.
Verifica-se a existência de 3 modelos de alto nível presentes nas ferramentas
apresentadas no quadro 26. São eles o modelo de domínio, de apresentação e de diálogo.
Esses modelos servem como alicerce para construção do ambiente MBUIDE, pois eles lidam
diretamente com a construção de IUs e seus controles. A inexistência de algum deles irá
refletir diretamente na capacidade de automatização da ferramenta. O restante dos modelos
podem ser implementados de acordo com a necessidade e não necessariamente dependem uns
dos outros.
67
4 CONCLUSÕES
Pode-se concluir que os objetivos propostos foram alcançados com êxito. O conceito
MBUIDE provê grande vantagem na automatização de IUs na área de desenvolvimento de
sistemas de informação. A exemplo disso verifica-se a rápida implementação do estudo de
caso proposto na figura 23. Levou-se cerca de 30 minutos para implementá-lo na ferramenta
modeladora sem que erros fossem introduzidos.
É fato que existe a necessidade de um bom refinamento do ambiente no caso de sua
utilização como um produto comercial. Mesmo assim é possível verificar o potencial existente
neste tipo de ferramenta. Verificou-se que é possível não somente automatizar a criação de
IUs, mas também diversas etapas do desenvolvimento de arquitetura de um sistema de
informação. A utilização de árvores de navegação de registros ajudou a deixar a solução
proposta para o ambiente mais simples e concisa, possibilitando ainda, um modelo de
navegação mais intuitivo para o usuário final.
O ambiente demonstrou economia de tempo no desenvolvimento de sistemas.
Enquanto o sistema é modelado pode-se verificar o seu resultado final sem a necessidade de
geração de código fonte para compilação. Esta abordagem ainda abre a possibilidade de
automatização de diversos outros componentes do sistema como geração automática de
relatórios e gerenciamento de usuários. O nível de automatização proporcionado pelo conceito
MBUIDE pode engessar o programador no desenvolvimento de sistemas. Ele está limitado às
funcionalidades disponibilizadas pela ferramenta, não podendo estender estas características.
Verifica-se certo nível de limitação proporcionado pelo ambiente. Seu sistema de
geração de interfaces suporta somente um formato de IU. Arquiteturas que fogem tal
especificação ou que necessitam de IUs mais refinadas e complexas tais como sistemas de
Ponto de Venda (PDV), não são suportadas pelo ambiente.
Um ponto importante de limitação é a falta de consistência das informações
cadastradas na ferramenta modeladora. Caso alguma informação esteja incorreta pode-se
gerar erros de execução na ferramenta interpretadora. O ambiente ainda não permite alterar o
ícone, a imagem da tela de apresentação e o título do sistema.
68
4.1 EXTENSÕES
Como extensão para este trabalho sugere-se o refinamento na geração de interfaces
utilizando critérios ergonômicos de usabilidade. Teclas de atalho para navegação em controles
visuais da IU, utilização de templates para IUs, alteração de cores e fontes, maior
maleabilidade na disposição de controles visuais, utilização de campos para manipulação de
imagens, são algumas idéias de melhorias para o ambiente.
A implementação de um modelo de usuários permitiria ao sistema o gerenciamento de
usuários e de permissões de acesso. Outra sugestão é a criação de um mecanismo que
possibilitasse ao programador acrescentar um filtro de pasta durante a modelagem. Isso
permitiria ao ambiente suportar o relacionamento do tipo herança entre entidades.
Também sugere-se a criação de um modelo de tarefas, onde o programador pode
implementar o modelo de negócio na interface da ferramenta através da utilização de macros
de sistema. Tecnologia similar às macros VBA conhecidas das ferramentas Microsoft. Ainda,
como sugestão, a criação de um módulo para geração de relatórios baseado no modelo de
dados. O programador definiria o tipo de relatório e selecionaria os campos de listagem dentre
os disponíveis no próprio modelo de dados.
69
REFERÊNCIAS BIBLIOGRÁFICAS
ADOBE. Using data-driven controls. [S.l.], 2009. Disponível em:
<http://livedocs.adobe.com/flex/3/html/help.html?content=dpcontrols_8.html>. Acesso em:
27 maio 2010.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de
Janeiro: Campus, 2002.
BODART, François et al. A model-based approach to presentation: a continuum from task
analysis to prototype. In: DESIGN, SPECIFICATION AND VERIFICATION OF
INTERACTIVE SYSTEMS. 1., 1994, Italy. Proceedings... Bocca di Magra: Springer, 1994.
p. 77-94.
GALITZ, Wilbert. The essential guide to user interface design and introduction to GUI
design principles and techniques. 2nd ed. New York: John Wiley and Sons, 2002.
GRIFFITHS, Tony et al. Teallach: a model-based user interface development environment for
object databases. Interacting With Computers, Edinburgh, v. 14, n. 1, p. 31-68, 2001.
LAVÔR, Renato B.; LEITE, Jair C. Ferramenta para modelagem de interação e interface de
usuário. In: CONGRESSO IBERO-AMERICANO EM ENGENHARIA DE SOFTWARE. 1.,
2011, Rio de Janeiro. Anais... Rio de Janeiro: [s.n.], 2011. p. 52-68.
MICROSOFT CORPORATION. Treeview overview. [S.l.], 2010. Disponível em:
<http://msdn.microsoft.com/en-us/library/ms747277.aspx>. Acesso em: 26 maio 2010.
MRACK, Marcelo. Interfaces de usuário em tempo de execução. 2005. 95 f. Trabalho
(Pós-graduação em Computação) – Programa de pós-graduação em computação,
Universidade Federal do Rio Grande do Sul, Porto Alegre.
______. Geração automática e assistida de interfaces de usuário. 2009. 79 f. Dissertação
(Mestrado em Ciência da Computação) – Curso de Pós-graduação em Ciência da
Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre.
MYERS, Brad; HUDSON, Scott E.; PAUSCH, Randy. Past, present and future of user
interface software tools. ACM Transactions on Computer-Human Interaction, New York,
v. 2, n. 1, p. 64-103, 1995.
PETERS, James; PEDRYCZ, Witold. Engenharia de software: teoria e prática. Tradução
Ana Patrícia Machado de Pinho Garcia. Rio de Janeiro: Campus, 2001.
PRESSMAN, Roger S. Engenharia de software. Tradução José Carlos Barbosa dos Santos.
São Paulo: Makron Books, 1995.
70
PUERTA, Angel. A model-based interface development environment. IEEE Software
Magazine, Washington DC, v. 14, n. 4, p. 40-47, July/Aug. 1997. Disponível em:
<http://www.arpuerta.com/pdf/ieee97.pdf>. Acesso em: 26 maio 2010.
REZENDE, Denis A. Engenharia de software e sistemas de informação. 3. ed. Rio de
Janeiro, Brasport, 2005.
SCHLUNGBAUM, Egbert. Model-based user interface software tools: current state of
declarative models. [S.l], 1996. Disponível em:
<http://smartech.gatech.edu/xmlui/handle/1853/3516>. Acesso em: 25 março 2012.
SOMMERVILLE, Ian. Engenharia de software. 6. ed. Tradução Mauricio de Andrade. São
Paulo: Pearson Addison-Wesley, 2003.
SZEKELY, Pedro. Retrospective and challenges for model-based interface development. In:
DESIGN, SPECIFICATION AND VERIFICATION OF INTERACTIVE SYSTEMS, 3.,
1996, Berlin. Proceedings... Berlin: [s.n.], 1996, p. 1-27.
TONSIG, Sérgio L. Engenharia de software: análise e projeto de sistemas. São Paulo:
Futura, 2003.