geracao automatica assistida iu marcelo mrack
TRANSCRIPT
<Título> - <Subtítulo> slide 1 de xx
Geração Automática e Assistida de Interfaces de
Usuárioaluno Marcelo Mrack
orientador Prof. PhD Álvaro Freitas Moreiraco-orientador Prof. D. Marcelo Soares Pimenta
Instituto de Informática – PPGC – MestradoUniversidade Federal do Rio Grande do Sul
junho/2008
SumárioPARTE 1
1. Introdução2. Motivação3. Interfaces de Usuário
PARTE 2
4. MBUIDEPARTE 3
5. Merlin6. Estudo de Caso
PARTE 4
7. Conclusões
Introdução Contextualização
Esta apresentação resume o trabalho de pesquisa realizado durante o Programa de Pós-Graduação em Computação do Instituto de Informática da UFRGS e que teve como ênfase o projeto Merlin, que vem sendo desenvolvido desde 2001
O Merlin é um software para geração automatizada de Interfaces de Usuário (IU) que segue as premissas das MBUIDE, e que tem foco específico no mercado profissional de desenvolvimento de sistemas
Objetivos Apresentar o conceito de geração de IU defendido pelas
MBUIDE e um panorama geral dessa tecnologia na atualidade Detalhar as bases do projeto Merlin e sua relação com as
demais MBUIDE, buscando evidenciar os seus diferenciais Apresentar um pequeno Estudo de Caso, onde o Merlin é
utilizado para gerar uma IU de baixa complexidade Mostrar os resultados obtidos até o momento, os pontos em
aberto e os direcionamentos da pesquisa
Motivação
Experiência Profissional A criação de UI, principalmente em sistemas de banco
de dados, é uma tarefa repetitiva, cansativa em com baixos índices de reuso
Custo Expressivo para a Criação das IU De forma geral, pesquisas demonstram que os custos de
criação de IU são significativos, mesmo na atualidade
Quanto custa a IU nos sistemas em geral
Sistema CompletoInterface do Usuário
100%100%
50%50%
User Interface Software Tools; MEYERS (1994,2002)
Interfaces de Usuário
Cenário Atual na Criação de IU Escrita de código-fonte
Programador escreve código-fonte usando API de um toolkit gráfico
Uso de ferramentas WYSIWYG Programador usa o conceito de arrastar e soltar elementos de IU
Uso de assistentes de criação Wizards coletam informações do meio do sistema e geram código-
fonte
Geração Automatizada Templates
– Esqueletos de código substituíveis otimizam a programação Model Driven Architecture (MDA)
– Cartuchos de geração transformam modelos abstratos em código
Interfaces de Usuário
Problemas Recorrentes nas Abordagens Descritas Tempo elevado de construção de estruturas genéricas
Quanto custa criar um template realmente genérico?
Demora nas alterações Como refatorar artefatos gerados se o código já foi alterado
manualmente?
Falta de reuso Posso reusar o rótulo “Nome do cliente” em projetos diferentes?
Gerência de código Código template ou não? E a versão? Onde é utilizado?
Refatoração E se o template contiver erros?
Interfaces de Usuário
Tipos de Interfaces de Usuário Uso Geral
São interfaces de usuário que não têm relação específica com os dados do sistema, e são orientadas para satisfazer as mais variadas regras de negócio
Devido a sua generalidade, a automação de geração dessas IU é reduzida
Interfaces CRUD Acrônimo do inglês Create, Retrieve, Update and Delete, são IU
destinadas a visualizar e manipular os dados existentes na aplicação
Por possuírem uma relação muito forte com os dados do sistema, tendem a ser beneficiadas por recursos de geração automatizada
Presentes em 100% dos sistemas que operam sobre banco de dados
Interfaces de Usuário Tipos de Interfaces CRUD
Um-Para-Um São as IU mais simples, e todos os elementos da IU existem em
função de um objeto de dados com propriedades primitivas ou com associações de cardinalidade máxima igual a 1 no destino
EXEMPLO: Tela de cadastro de um produto Um-Para-Muitos (Mestre-Detalhes)
De média complexidade, os elementos da IU representam objetos de dados com associações de cardinalidade maior que 1 no destino, e exatamente 1 na origem
EXEMPLO: Tela de cadastro de uma nota fiscal e seus itens Muitos-Para-Muitos
De alta complexidade, representam dados relacionados por estruturas com cardinalidade maior que 1 em ambas extremidades
Na prática, durante a implementação, são transformadas em IU Um-Para-Muitos isomórficas
EXEMPLO: Tela de cadastro de cursos e disciplinas
Conceito Básico de Geração das IU CRUDMapeamento de um objeto de dados para uma IU CRUD simples
Interfaces de Usuário
codigo = “RH0001” : Stringnome = “Marcelo Mrack” : Stringativo = true : booleandataDeNascimento = 02/10/1977 : Dateobservacoes = null : String
: Funcionario
Interfaces de Usuário
Foco do Software Proposto 100% das interfaces CRUD elementares com custo zero
de configuração 100% das interfaces CRUD com algum trabalho de
configuração que tenha melhor custo-benefício do que as abordagens existentes
Abrangência da ferramenta Merlin descrita no trabalho
IU
CRUD em geral50%50%
30%30%
CRUD elementar18%18%
Sistema completo
100%100%
Merlin: Um Novo Horizonte na Criação de Telas de Cadastro; MRACK (2007)
MBUIDE
Model-Based User Interface Development Environment (MBUIDE) São ferramentas que objetivam produzir IU através do
uso de modelos declarativos de alto nível Os modelos são processados por um mecanismo de
transformação que tem como resultado as IU do sistema São semelhantes à tecnologia MDA, porém:
Dão grande ênfase para a geração de IU Valem-se de de processos, linguagens e mecanismos de
transformação proprietários Seguem metodologias próprias de trabalho
MBUIDE Origens nas Antigas UIMS
User Interface Management System (UIMS) Início dos anos 80 Primeira alternativa utilizada para produzir IU sem escrever
diretamente código-fonte Características das UIMS
Focada no resultado final pela visão do desenvolvedor e sem processos ou metodologias claras de trabalho
Sem grande preocupação com integrações ou refatoramento
Utilização de linguagens ou sintaxes próprias Uso de diagramas de estados e transições para modelar o
diálogo entre o usuário e o sistema Resultados das UIMS
Geração dos principais menus do sistema, caixas de diálogo, mensagens simples e invocação de funções pré-determinadas
MBUIDE
Evolução Grande crescimento entre os anos 80 e 90 Evolução das linguagens e sintaxes de especificação mais
ricas Separação de conceitos: Elementos de IU, Tarefas, Dados,
etc.
Modelos Formam a base das MBUIDE Estruturas declarativas que armazenam aspectos relevantes
do sistema a ser gerado e que, em conjunto, podem detalhar todas as informações necessárias para geração de uma aplicação
Definidos, os modelos servem como entrada para os mecanismos de geração da MBUIDE que, através de ciclos evolutivos e incrementais, produz as IU do sistema
MBUIDE Tipos de Modelos
1. Modelo de Dados Semelhante a um modelo relacional, foca os dados persistentes da aplicação
2. Modelo de Domínio Extende o Modelo de Dados, agregando conceitos semelhantes a OO
3. Modelo de Tarefas Foca as regras de negócio da aplicação e as operações e restrições
relacionadas
4. Modelo de Apresentação Dá ênfase para os elementos gráficos da IU Abstract Interface Object (AIO) e Concrete Interface Object (CIO) são suportados
5. Modelo de Diálogo Correlato ao Modelo de Tarefas, focaliza a conversação do usuário com a IU
6. Modelo de Usuário Define aspectos de personalização da IU para determinados usuários ou grupos
7. Modelo de Aplicação Efetua a ligação das IU com o meio externo da aplicação
8. Modelo de Plataforma Variante do Modelo de Aplicação, foca mais detalhes do ambiente operacional
9. Modelo de Contexto Semelhante ao Modelo de Usuário, enfatiza aspectos dependentes do uso do
sistema
MBUIDE
Exemplos de Modelos de MBUIDE
BODART, LEHEUREUX e VANDERDONCKT (1994)
e MRACK (2007)
Modelos de Apresentação Modelo de Tarefas na TRIDENT
DEFINE INTERACTION-OBJECT ID_Label; WORDING IS "Id."; MNEMONIC IS "I"; PROMPT IS ":"; IS INSTANCE OF Label; IS COMPONENT OF Customer_GroupBox;
DEFINE INTERACTION-OBJECT Id_EditBox; MAX-LENGTH IS 6; LINEARITY SIMPLE; IS INSTANCE OF EditBox; IS COMPONENT OF Customer_GroupBox; IS ATTACHED TO Cust_id;
@Properties(“mnemonic=I;”)@Group(“Customer”)@Length(max=6)String id;
Merlin (2007)
TRIDENT (1994)
|||
>>
>>
|||
>>
|||
>>
|||
Acess and Manage Patient Information
Manage Patiente InformationIdentification
InsertLogin
InsertPassword
RequestPatient File
VisualizePictures
VisualizeText
AddInformation
DeleteInformation
Manage Patiente Medical File
Visualize Patiente Medical File Modify Patiente Medical File
Monitor Real Time Patient Information
CloseSession
Adaptado de SOUCHON, LIMBOURG e VANDERDONCK (2002)
MBUIDE
Arquitetura das MBUIDE
Adaptado de PINHEIRO (2001)
(1) TEALLACH e TADEUS (2) TRIDENT e METAGEN (3) MERLIN e MECANO
Conjunto demodelos
Gerador de código-fonte
Compilador
Código principal da aplicação
Código gerado paraum toolkit gráfico
específico
Aplicação final
Conjunto demodelos
Gerador de código intermediário
Compilador
Código principal da aplicação
Subconjuntootimizado
dos modelos
Aplicação final
Conjunto demodelos
Compilador
Código principal da aplicação
Aplicação final
Interpretador de tempo de execução
Interpretador de tempo de execução
Biblioteca do toolkit gráfico específico
Biblioteca do toolkit gráfico específico
Biblioteca do toolkit gráfico específico
Arquitetura geral das MBUIDE em relação ao processo de geração da IU
MBUIDE
Visão Geral das Arquiteturas das MBUIDE1. Geradores de código-fonte
Aplicação final não possui dependência dos modelos da MBUIDE MBUIDE deve (ou deveria) se preocupar com refatoração de código-
fonte Menor flexibilidade à mudanças, usando abordagem “uma via” Maior desempenho da aplicação final (devido compilação total)
2. Geração de código intermediário Menor dependência dos modelos da MBUIDE Problemas de sincronização duplicados, devido 2 pontos de integração Possível melhor desempenho
3. Geradores de tempo de execução (abordagem do Merlin) Total dependência dos modelos da MBUIDE Prototipação instantânea Praticamente não sofrem problemas de refatoração Possível pior desempenho
MBUIDE
Processo de Desenvolvimento
Criaçãodos
modelos
Nova IU
Adiçãode
funcionalidades
Geração deversões
preliminares
Detalhamentos
de maisbaixo nível
Geração da IU ou
código-fontefinal
Ajustes eintegração
com orestante
do sistema
IU Completa
Refatoração
Processo geral de desenvolvimento de IU usando MBUIDE (notação BPMN)
AbstraçãoMaior Menor
MBUIDE
Vantagens Padronização e centralização de atividades Trabalhos realizados em mais alto nível Respostas rápidas nos primeiros ciclos de
desenvolvimento
Problemas Recorrentes Sintaxes e notações complicadas Linguagens e metodologias proprietárias Busca pela generalidade, implicando em modelos
demasiadamente complexos e instáveis Reuso de soluções não alcançado com praticidade Fraco suporte à refatoração e evolução dos modelos Desequilíbrio entre a pesquisa e a aplicação de conceitos
Merlin É uma MBUIDE com Ênfase no Cenário Profissional que:
1. Tem foco específico em interfaces CRUD Na versão corrente suporta CRUD simples, do tipo Um-Para-Um
2. Utiliza uma estrutura única para o armazenamento dos seus modelos Na prática, os modelos são as próprias classes compiladas da aplicação
3. Não gera nenhum tipo de código-fonte A transformação dos modelos em IU ocorre totalmente em tempo de execução
4. Vale-se de heurísticas plugáveis para geração da IU Podendo serem definidas em linguagem nativa ou usando mecanismos externos
5. Utiliza um conjunto realimentado de configurações Inferência de comportamento com base em informações históricas e taxas de acerto
6. É neutra em relação a pacote gráfico e ambiente de uso Web, desktop ou dispositivos móveis podem ser alcançados
7. Possui uma arquitetura focada em reuso e integração de tecnologias Baseada na plataforma Java, inúmeras tecnologias correlatas podem ser acopladas
Merlin Origens
Projeto Metagen na UNISC Iniciado em 2001, era uma MBUIDE rudimentar Gerava interfaces CRUD Um-Para-Um e Um-Para-Muitos Foi utilizado com sucesso em sistemas profissionais de médio porte Ênfase no Modelo de Dados Utilizava código intermediário para os modelos
Carências do Metagen Linguagem VB, Delphi e Kylix
Sem suporte Web, não era multi-plataforma e não permitia distribuição
Sem definição clara de modelos Orientação a Objetos não era utilizada Pouca preocupação com padrões e tecnologias de mercado Reuso baseado em cópia e ajustes de configuração Layout de IU sem grande flexibilidade
Merlin
Típica Interface CRUD Gerada pelo Metagen (2003)Interface CRUD Um-Para-Um de média complexidade gerada pelo
Metagen
Agrupamentos
simples
Layout essencialmen
tetabular
Dependências de
preenchimento
Máscaras e tamanhos
Ligação básica de
funções de negócio
Operações CRUD
essenciais
Merlin Iniciado em 2004, é a Continuação do Projeto
Metagen Uso da linguagem Java
Franco crescimento Suporte Web, Desktop, multi-plataforma Orientação a Objetos
Separação de conceitos Modelos claros
– Modelo de Domínio– Modelo de Tarefas– Modelo de Apresentação, com suporte AIO e CIO– Modelo de Diálogo– Modelo de Usuário
Pouca aderência dos outros modelos devido uso da Java
Flexibilidade total no layout da IU Foco em reuso de configurações e integração de tecnologias Geração da IU totalmente em tempo de execução
Merlin
Características Modelos
O Merlin utiliza 5 tipos de modelos para geração das IU, todos orbitando sobre o Modelo de Domínio
Descritos através da própria linguagem Java, com o recurso conhecido como Metadata Facility, ou simplesmente Anotações (JSR 175)
Os modelos nada mais são do que as classes da aplicação (com ênfase nas de persistência) enriquecidas com Anotações, as quais:
– São definidas pelo próprio Merlin– Podem ser reutilizadas de outros frameworks de mercado– Podem ser criadas pelo próprio programador
Como os modelos são as classes da aplicação e como as Anotações associadas são preservadas após a compilação do sistema, o Merlin não exige estruturas externas para armazenamento de configurações
Merlin
Características Modelos no Merlin, um exemplo
@Caption(“Cadastro de Cliente Pessoa Física”)class Cliente extends Pessoa implements IPessoaFisica { @Agent( event={“focusLost”}, action={“habilitarCartao”} condition={“length>0”}) float salario; @NotNull boolean cartaoCredito; @Email @Column(length=“40”) @Property(“foreground=Color.blue”) @Order(after=“nome”) String email; @Caption(“UF”) Estado estado; @RenderAs(Lookup.class) Cidade cidade;}
12
345678
Uma classe de persistência utilizada como base de um conjunto de modelos
91011121314151617
18
Merlin
Características Modelos no Merlin, um exemplo
@Caption(“Cadastro de Cliente Pessoa Física”)class Cliente extends Pessoa implements IPessoaFisica { @Agent( event={“focusLost”}, action={“habilitarCartao”} condition={“length>0”}) float salario; @NotNull boolean cartaoCredito; @Email @Column(length=“40”) @Property(“foreground=Color.blue”) @Order(after=“nome”) String email; @Caption(“UF”) Estado estado; @RenderAs(Lookup.class) Cidade cidade;}
12
345678
Uma classe de persistência utilizada como base de um conjunto de modelos
91011121314151617
18
Características Arquitetura
Aplicação final
Estrutura geral de funcionamento do software Merlin
Merlin
Modelos
Interpretador de Tempo de
Execução
IU Gerada
Classes da Aplicação
Anotações
Heurísticas
Resolvedores
AIO CIO Toolkit Gráfico
Histórico
Estimativas
Meio Externo
Características Processo de desenvolvimento
Desenvolvimento de IU utilizando o software Merlin
Merlin
2
1
3 4 5 6
7
IDE
Aplicação
Tempo de execuçãoTempo de projeto
1Programador usa IDE
2Programador cria classes
3Programador insere anotações
4Programador compila sistema
5Merlin interpreta modelos
6 IU gerada pelo Merlin
7Usuáirio utiliza o sistema final
Legenda
Merlin
Funcionalidades Heurísticas plugáveis
Nada mais são do que algoritmos que transformam as informações dos modelos nas características desejadas para a IU
Escritos em linguagem Java, Groovy, BeanShell ou delegados a mecanismos externos
– JBoss Drools é uma máquina de processamento de regras de produção (um Sistema Especialista) que pode ser usado para inferir resultados com base nas classes anotadas do sistema (modelos).
– A estrutura do Merlin permite integrações desse tipo, seja com delegação total, ou com um sistema híbrido de resolução de informações de geração
Merlin
Funcionalidades Heurísticas plugáveis, um exemplo
Implementando uma heurística simples em código JavaUma nova anotação
public @interface Capitalized {}
Uma classe decorada
class Cliente {
@Capitalized String nome;}
Um resolvedor simples em código Groovy instrumentado + BeanShell@ResolverFor(Capitalized.class)class CapitalizedResolver extends AbstractResolver
{
void resolve(Object source, Object destination) { if (source.contains(annotation)) { set(“destination.text”, StringUtil.capitalize(destination)) }}
Merlin
Funcionalidades Layout customizável
Por heurísticas– Regras de usabilidade são aplicadas nos algoritmos internos– Novas heurísticas podem ser criadas
Por anotações Por design manual
Merlin
Funcionalidades Layout customizado por anotações (um elemento de IU)
Redefinindo a ordem de controles e a posição de labels na tela
A classe de dadosA tela
class Cliente { @Order(after=“observacoes”) String nome; float salario; @Caption(pos=Caption.TOP_LEFT) String observacoes;}
Cadastro de ClienteCadastro de Cliente
Salário
123456
Nome
Observações
72
5Observações
Merlin
Funcionalidades Layout customizado por anotações (uma IU inteira)
Redefinindo a ordem de controles e a posição de labels na tela
A classe de dadosA tela
@Caption(pos=Caption.TOP_LEFT)class Cliente { @Order(after=“observacoes”) String nome; float salario; String observacoes;}
Cadastro de ClienteCadastro de Cliente
Salário
123456
Nome
Observações
7
Diferenciais Similaridades e sinônimos
Utilizando similaridades e sinônimos para geração da IU
Merlin
class Cliente {
@RenderAs(JTextArea.class)
String observacao;}class Produto { String observacoes;}
class NotaFiscal { String obs;}
Observação
Cliente
Observações
Produto
Obs
Nota Fiscal
Modelo de Domínio A
Modelo de Domínio B
Modelo de Domínio C
Sinônimo
Similar
Diferenciais Integração com ferramentas (plugins)
Edição Textual Assistida é uma tendência de mercado– Parsing de expressões e captura de erros– Preenchimento automático de informações– Navegação entre modelos– Code folding (Dobras de código no editor de texto)
Assistência de edição de modelos no Eclipse IDE
Merlin
The event focosLost cannot be recognized.
Available events are: focusLost focusGain see others...
focusLost
{ “focosLost” }
Merlin
Diferenciais API enxuta, dois métodos essenciais para o programador
getInstance(toolkit)– Obtém uma instância do gerador para o toolkit gráfico
desejado createIU(objeto, params)
– Retorna uma IU CRUD completa
Integração com tecnologias Java, Groovy, BeanShell Java Annotations Object Constraint Language (OCL) e Expression Language (EL) Web Beans, Seam, EJB, WebServices Hibernate, JPA, Beans Binding, Bean Validation, Hibernate Validator Toolkits Gráficos: Swing (JSF, GWT, SWT) Eclipse IDE
Merlin
Diferenciais Configuração realimentada
Durante o uso, o mecanismo interpretador agrega informações de classes de sistemas já desenvolvidos, e com base nessas informações históricas, infere novos valores de geração
Na eventualidade de uma ação do gerador for inadequada, o programador utiliza a premissa de Configuração por Exceção e insere uma anotação com o comportamento desejado
Essas novas informações entram para o sistema de histórico que, com base em taxas de acertos e erros, adequa-se ao ambiente de desenvolvimento
Configuração distribuída Diversos sistemas podem ser interconectados, de forma que as
informações de geração propaguem-se entre eles Bases de informações podem ser formadas e compartilhadas,
maximizando o poder de geração
Classloaders em um servidor de aplicação
Merlin
Diferenciais Configuração realimentada
Implementando o mecanismo de histórico em servidores de aplicação através da navegação entre os classloaders do container
Root LIBs classes
S1
S2
Sn
C1
C2
Cn
classes
classes
classes
C = Classloader
S = Sistema
LIB = Pacote de classes
Root = Bootstrap classloader
Legenda
Merlin
Diferenciais Configuração realimentada
Implementando o mecanismo de histórico em servidores de aplicação através da navegação entre os classloaders do container
Histórico
Classloaders em um servidor de aplicação
Root LIBs classes
S1
S2
Sn
C1
C2
Cn
classes
classes
classes
Merlin
Diferenciais Configuração distribuída
Como pode ser implementada a distruição da configuração entre diversos sistemas
Uma base federada distribuída de configurações
Grupo 1
S1
S2
S3
Grupo 2
S1
S2
S3
Grupo 3
S1
S2
S3
Federação 2Federação 1
Estudo de Caso
Geração de uma Interface CRUD simples1. Definir um conjunto de classes, que é a base do Modelo
de Domínio2. Gerar uma Interface CRUD para esse Modelo de
Domínio3. Refatorar o sistema, inserindo anotações sobre as
classes, as quais vão evoluir o Modelo de Domínio e formar os outros modelos
4. Efetuar uma nova geração da IU CRUD e comparar os resultados
Estudo de Caso
1. Criando uma classe simples Criar código-fonte da classe-base de geração (Modelo
de Domínio)Uma classe simples, base do Modelo de Domíniopublic class Cliente {
String nome;String sexo;Date dataDeNascimento;String descricao;String observacoes;boolean ativo;boolean vip;String email;
}
123456789
10
2. Gerar a Interface CRUD Passo 1 – Código da aplicação principal
Estudo de Caso
Código-fonte da aplicação principal
123456789
10
Passo 1
public class TesteMerlin {
public static void main(String[] s) { IMerlin m = Merlin.getInstance(SWING); JPanel crud = (JPanel) m.createIU(new Cliente()); JFrame frame = new Frame(“TesteMerlin”); frame.add(crud,CENTER); frame.setVisible(true); }}'
Interface CRUD simples resultante
Passo 2
Estudo de Caso
2. Gerar a Interface CRUD Passo 2 – Resultado da geração da IU
TesteMerlinPainel de mensagens
Adequação de textos
Correção ortográfica
Layout tabular
Controles de IU por tipo de
dado
Heurísticas de tamanho
Não gerado pela
ferramenta
Estudo de Caso
3. Refatorar e Evoluir o Sistema• Adicionando a enumeração Sexo e evoluindo a classe
PessoaNovas classes, anotações e regras de negócio (classes Sexo e Pessoa)public enum Sexo {
NAO_DECLARADO, MASCULINO, FEMININO}
public class Pessoa {@Agent(event = { "focusLost" }, action = { "proposeEmail" })@NotNullString nome = "marcelo";public Sexo sexo = Sexo.MASCULINO;@Agent(property = { "foreground=Color.blue" }, binder = DateToTextComponentBinder.class)Date dataDeNascimento = new Date(1977-1900,9,02);
}
123456789
10
1112
Estudo de Caso
3. Refatorar e Evoluir o Sistema• Evoluindo a classe Cliente
Novas classes, anotações e regras de negócio (classe Cliente)
@Caption("Cadastro de Clientes")public class Cliente extends Pessoa {
@Agent(event = { "focusLost" },action = { "isPreferencial" })@Caption("Salário (R$)") int salario;@Order(after = "observacoes") String descricao;@RenderAs(CHECKBOX) @Dependence("descricao")@Agent(property = { "selected=true" })String observacoes;@Dependence(“[:alnum:]")@Order(Order.FIRST)@Agent(property = { "selected=true;" })boolean ativo;@RenderAs(value = JTextField.class, binder = BooleanToTextComponentBinder.class)@Order(LAST)boolean vip = true;@Order(after = "nome") @NotNull @Length(min=12) String email;
}
12
3456789
10111213
141516
17
Estudo de Caso
3. Refatorar e Evoluir o Sistema• Adicionando a classe AlgumasRegras
Novas classes, anotações e regras de negócio (classe AlgumasRegras)public class AlgumasRegras {
@In Context ctx;
public void isPreferencial() {ctx.eval("$vip.text=$salario.text>1500 ?
'SIM':'NÃO'");}
public void proposeEmail() {
ctx.eval("$email.text=$nome.text.trim+'@merlin.com'");}
}
123456789
101112
Estudo de Caso
4. Efetuar uma nova geração Essas alterações poderiam ter sido feitas com o sistema
em execuçãoInterface CRUD simples resultante após as refatorações e melhorias
TesteMerlinPainel de
mensagens preenchidas
Campo Ativo é o primeiro da tela
Preenchimento pela regra associada
Formatação de data customizada
Campos obrigatórios em
destaque
Rótulo customizado e
regra de negócio
Campo Observações
agora é CheckBox
Desabilitado devido
dependência
Tipo multivalorado
Campo booleano com formatação especial e regra
de negócio aplicada
Estudo de Caso
4. Efetuar uma nova geração Comparando as duas IU
Interfaces CRUD antes (esquerda) e depois (direita) da evolução do sistema
TesteMerlin TesteMerlin
Conclusões
Este Trabalho Apresentou Interfaces de Usuário
Um panorama sobre os custos de criação das IU em sistemas, principalmente as que operam sobre banco de dados
Uma divisão simplista das IU, com ênfase nas CRUD, objeto do trabalho
As tecnologias comumente utilizadas para criar esses tipos de IU Os problemas recorrentes nas abordagens comumente utilizadas
Tecnologia MBUIDE Origem e proposta das MBUIDE Elementos básicos das MBUIDE, como seus modelos e geradores
integrados Distinção entre os tipos de modelos suportados pelas MBUIDE Arquitetura geral e processo de desenvolvimento de IU nessa
tecnologia Problemas recorrentes nas MBUIDE
Conclusões
Este Trabalho Apresentou Projeto Merlin, uma nova proposta nas área das MBUIDE
Origens do projeto e objetivos Caraterísticas gerais, arquitetura e processo de desenvolvimento
de IU Funcionalidades adicionais frente outras MBUIDE
– Similaridades e sinônimos– Heurísticas plugáveis descritas em linguagem comum ao
programador Capacidades de integração com ferramentas e tecnologias
correlatas Mecanismo de configurações realimentado e distribuído como
diferencial
Conclusões
Problemas em Aberto Suporte CRUD Um-Para-Muitos e Muitos-Para-Muitos Finalizar suporte à OCL e EL Maximizar algoritmos de layout integrados
Atualmente, somente o layout tabular é suportado
Implementar suporte para outros pacotes gráficos além do Swing
Desenvolver plugins para integração com ferramentas
Trabalhos Futuros Sistema de configuração realimentada
Gerência de propagação, segurança, estimativas e outros Possível trabalho de doutorado
Agradecimentos CAPES
Pela bolsa de estudos durante o período da pesquisa Orientadores
Pela dedicação, paciência, disponibilidade e sinceridade nas opiniões
UFRGS Pelos espaços de estudo, biblioteca e laboratórios
Medicina Hospital de Clínicas de Curitiba e Cristo Redentor de Porto
Alegre Pelo tratamento durante os longos 8 anos de quimioterapia
Hospital Amaral Carvalho de Jaú – SP Pelo excelente trabalho e acompanhamento no meu transplante de
medula
Doador de Medula Óssea A quem devo a vida