Geracao Automatica Assistida Iu Marcelo Mrack

58
<Título> - <Subtítulo> slide 1 de xx Geração Automática e Assistida de Interfaces de Usuário aluno Marcelo Mrack orientador Prof. PhD Álvaro Freitas Moreira co-orientador Prof. D. Marcelo Soares Pimenta Instituto de Informática – PPGC – Mestrad Universidade Federal do Rio Grande do Su junho/200

Transcript of Geracao Automatica Assistida Iu Marcelo Mrack

<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

PARTE 1

1. Introdução2. Motivação3. Interfaces de Usuário

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)

PARTE 2

4. MBUIDE

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

PARTE 3

5. Merlin6. Estudo de Caso

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

PARTE 4

7. Conclusões

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

<Título> - <Subtítulo> slide 58 de xx

Fim

Geração Automática e Assistida de Interfaces de

UsuárioMarcelo Mrack