Utilizando Metamodelo de Interação

Humano-Computador para geração

automática de Interfaces de Usuário
em Android

aluna Isabella de Melo Freitas

orientadora Prof. Sofia Costa Paiva

Grupo de Pesquisa em Engenharia de Software –

GES – Graduação Universidade Federal de
<Título> - <Subtítulo> slideSão
1 de João del Rei
xx Abril/2018
 Sumário

PARTE 1
1. Introdução
2. Motivação
3. Interfaces de Usuário
PARTE 2
4. Geração Automática de Interface
5. MDA
PARTE 3
6. Visão geral da Abordagem
7. Estereótipos de Interface
8. Metamodelo de IHC
PARTE 4
9. Conclusões
 PARTE 1

1. Introdução
2. Motivação
3. Interfaces de Usuário
Introdução

Contextualização
Esta apresentação resume o trabalho de pesquisa sendo realizado na Iniciação
Científica da autora

Objetivos
Apresentar o conceito de geração de IU defendido pelas MDA e um
panorama geral dessa tecnologia na atualidade

Detalhar as bases da abordagem de modelos para geração de interfaces de

usuário

Apresentar o conceito de esteréotipos de Interfaces de Usuário e sua

importância na criação de modelos

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 é 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 I U nos sistemas em geral

Sistema Completo 100%

Interface do Usuário 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
 São as IU mais simples, e todos os elementos da IU existem em função de
 Um-Para-Um
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
Interfaces de Usuário
 Conceito Básico de Geração das IU CRUD
Mapeamento de um objeto de dados para uma I U CRUD simples

: Funcionario

codigo = “RH0001” : String

nome = “Marcelo Mrack” :
String ativo = true : boolean
dataDeNascimento = 02/10/1977 : Date
observacoes = null : String
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
Sistema completo 100%
100
%
50
IU 30 50%
%%
18
%
CRUD
Merlin: Umem
Novogeral
Horizonte na30%
Criação de Telas de Cadastro; MRACK (2007)

CRUD elementar 18%

 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
Modelos de Apresentação Modelo de Tarefas na TRIDENT

TRIDENT (1994)
DEFINE INTERACTION-OBJECT ID_Label; Acess and Manage Patient
WORDING IS " I d . " ; Information
MNEMONIC IS " I " ;
>> >
PROMPT IS " : " ;
>
IS INSTANCE OF Identification
Manage Patiente Information
Label; Close
IS COMPONENT OF Sessio
| ||
DEFINE
Customer_GroupB
INTERACTION-OBJECT Id_EditBox; n
MAX-LENGTH IS 6 ;
ox; | ||
LINEARITY SIMPLE; Inser Insert
IS INSTANCE OF EditBox; t Passwor Manage Patiente Medical File
Logi d Monitor Real Time Patient Information
IS COMPONENT OF Customer_GroupBox; IS
ATTACHED TO Cust_id; n > >
> >
Visualize Patiente Medical Modify Patiente Medical File
Merlin (2007) Request File
Patient || | || |
@Properties(“mnemonic=I;”) File
@Group(“Customer”)
@Length(max=6) Visualiz Visualiz Add Delete
String i d ; e e Text Informatio Informatio
Pictures n n
BODART, LEHEUREUX e Adaptado de SOUCHON, LIMBOURG e VANDERDONCK (2002)
VANDERDONCKT
(1994)
e MRACK (2007)
MBUIDE
 Arquitetura das MBUIDE
Arquitetura geral das MBUIDE em relação ao processo de geração da IU

(1)TEALLACH e TADEUS (2) TRIDENT e METAGEN (3) MERLIN e

MECANO
Conjunto Código principal Conjunto Código principal Código principal
Conjunto
de da aplicação de da aplicação da aplicação
de
modelos modelos modelos

Gerador de Gerador de
Interpretador de Interpretador de
código- código
tempo de tempo de
fonte intermediário
execução execução

Código gerado Subconjunt

para um toolkit o otimizado
gráfico específico dos
modelos

Biblioteca do Biblioteca do Biblioteca do

Compilador Compilador Compilador
toolkit gráfico toolkit gráfico toolkit gráfico
específico específico específico

Aplicação final Aplicação final Aplicação final

Adaptado de PINHEIRO (2001)

MBUIDE
 Visão Geral das Arquiteturas das
MBUIDE
1. 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
Processo geral de desenvolvimento de I U usando MBUIDE (notação BPMN )

Nova IU

Refatoração

Ajustes e
Geração da
Criação Adição Geração de Detalham entos integração
IU ou
dos de versões de mais com o
código-fonte
m odelos funcio prelim inares baixo nível restante
final
nalida do sistema
des

M aior Abstração M enor IU Completa

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. Merlin
6. 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
Layout
essencialmen
te tabular Operações
CRUD
essenciais
Máscaras
e
Dependências
tamanhos
de Ligação
preenchiment básica de
o funções de
Agrupamento negócio
s simples
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ística
s
 O Merlin utiliza 5 tipos de modelos para geração das IU, todos orbitando
 Modelos
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
Uma classe de persistência utilizada como base de um conjunto de modelos
1
2 class Cl i e n t e extends Pessoa implements IPessoaFisica {
3
4
5
6
7 float salario;
8
9 boolean c arta oCre di to;
10
11
12
13 S t r i n g e m a i l ;
14
15 Estado estado;
16
17 Cidade cidade;
18 }
Merlin
 Características
 Modelos no Merlin, um exemplo
Uma classe de persistência utilizada como base de um conjunto de modelos
1 @Caption(“Cadastro de Cl i e n t e Pessoa F í s i c a ” )
2 class Cl i e n t e extends Pessoa implements IPessoaFisica {
3 @Agent( e v e n t = { “ f o cu s L o s t ” },
4
5 action={“habilitarCartao”}
6 condition={“length>0”})
7 float salario;
8 @NotNull
9 boolean
10 ca rta oCre dit o;
11 @Email @Column(length=“40”)
12 @Property(“foreground=Color.blue” )
13 @Order(after=“nome”)
14 S t r i n g e ma i l ;
15 @Capt i on( “ UF
16 ” )
17 Estado estado;
18 } @Render As( Lookup. cl as
s)
Cidade cidade;
 Merlin
 Características
 Arquitetura
Estrutura geral de funcionamento do software Merlin
Histórico
M odelos

Classes da Aplicação

Anotações

Estimativas
Heurísticas
I nterpretador IU Gerada
Resolvedores de Tempo de
Execução

Meio AIO CIO Toolkit

Ex terno
Gráfico
Aplicação final
 Merlin
 Características
 Processo de desenvolvimento
Desenvolvimento de I U utilizando o software Merlin

Legenda
1
1 Programador usa IDE
7
E
ID

o
ã
ç
a
ic
pl
A
2 Programador cria classes
3 Programador insere anotações
4 Programador compila sistema
2 3 4 5 6 5 Merlin interpreta modelos
Tempo de projeto Tempo de execução 6 IU gerada pelo Merlin
7 Usuáirio utiliza o sistema final
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 Java
Uma nova anotação Um resolvedor simples em código Groovy instrumentado + BeanShell
p u b l i c @interface @ResolverFor(Capitalized.class )
C a p it a lize d { } class CapitalizedResolver extends AbstractResolver {

void resolve(Object source, Object d e s t i n a t i o n )

{ i f ( s ou r c e . c on t ai ns ( an n ot a t i on ) ) {
set(“destination.text”,
StringUtil.capitalize(destination))
Uma classe decorada
}
class C l i e n t e {
}
@Capitalized
S t r i n g nome;
}
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 telade Cliente
Cadastro A classe
1 class C lde
i e ndados
te {
Salário
2 @Order(after=“observacoes”)
Observações
3 S t r i n g nome;
Observações 4 float salario;
5 5 @Caption(pos=Caption.TOP_LEFT)
6 S t r i n g observacoes;
7 }
2 Nome
Merlin
 Funcionalidades
 Layout customizado por anotações (uma IU inteira)
Redefinindo a ordem de controles e a posição de labels na tela

A tela A classe de dados

Cadastro de Cliente 1 @Caption(pos=Caption.TOP_LEFT)
Salário 2 class C l i e n te {
3 @Order(after=“observacoes”)
Observações 4 S t r i n g nome;
5 float salario;
6 S t r i n g observacoes;
7 }
Nome
Merlin
 Diferenciais
 Similaridades e sinônimos
Utilizando similaridades e sinônimos para geração da I U

Modelo de Domínio A Cliente

class C l i e n t e Observação
Similar
{ @RenderAs(JTextArea.cla P roduto
ss) S t r i n g observacao; Observações
}
Modelo de Domínio B Nota Fiscal

class Produto Obs

{ String
observacoes; Sinônimo
}

Modelo de Domínio
C
class NotaFiscal {
S t r i n g obs;
}
Merlin
 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

{ “focosLost” }

The event focosLost cannot be recognized.

Available events are:

focusLost
focusLost
focusGain
see others...
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
 c reateIU(obj et o, 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
 Diferenciai
s 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
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

Classloaders em um servidor de aplicação

Legenda
Roo LIB class Root = Bootstrap classloader
t s es LIB = Pacote de classes
C = Classloader
C S class
es S = Sistema
1 1
class
es
C S
class
2 2 es

C S
n n
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

Classloaders em um servidor de aplicação

Roo LIB class

t s es

C S class
es
1 1
class Histórico
es
C S
class
2 2 es

C S
n n
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

Federação Federação 2
1
Grupo Grupo Grupo
1 2 3
S S S
S2 S2 S
S 3 S 3
S1 3
2
1 1
Estudo de Caso
 Geração de uma Interface CRUD simples
1. Definir um conjunto de classes, que é a base do Modelo de
Domínio
2. Gerar uma Interface CRUD para esse Modelo de Domínio
3. 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ínio
2 S t r i n g nome;
1 p u b l i c class C l i e n te {
3 String
4 sexo;
5 Date
6 dataDeNasci
7 mento;
8 S t r i n g descri cao;
9 S t r i n g observacoes;
boolean a t i v o ;
10 }
boolean v i p ;
String email;
Estudo de Caso
2. Gerar a Interface CRUD
 Passo 1– Código da aplicação
principal
Código-fonte da aplicação principal
2
1 p u b l i c class TesteMerlin {
3 p u b l i c s t a t i c void m a i n ( S t r i n g [ ] s ) {
4 I M e r l i n m = Merlin.getInstance(SWING);
5 JPanel crud = (JPanel) m.createIU(new C l i e n t e ( ) ) ;
6 JFrame frame = new Frame(“TesteMerlin”);
7 frame.add(crud,CENTER);
8 frame.setVisible(true);
9 }
10 } '

Passo
1
Estudo de Caso
2. Gerar a Interface CRUD
 Passo 2 – Resultado da geração da
IU
Interface CRUD simples resultante
TesteM erlin
Painel de Controles de
mensage IU por tipo de
ns dado

Adequação
de textos Heurísticas
de
tamanho
Correção
ortográfic
a Não gerado
pela
Layout tabular ferramenta

Passo
2
Estudo de Caso
3. Refatorar e Evoluir o Sistema
• Adicionando a enumeração Sexo e evoluindo a classe
Pessoa
Novas classes, anotações e regras de negócio (classes Sexo e Pessoa)
2 NAO_DECLARADO, MASCULINO, FEMININO
1 public enum Sexo {
3}
4
5public class Pessoa {
6 @Agent(event = { "focusLost" } , a c ti o n = { "proposeEmail" } )
7 @NotNull
8 S t r i n g nome = "marcelo";
9 p u b l i c Sexo sexo = Sexo.MASCULINO;
1 @Agent(property = { "foreground=Color.blue" } , binder =
0 DateToTextComponentBinder.class)
1 Date dataDeNascimento = new Date(1977-1900,9,02);
1 }
12
Estudo de Caso
3. Refatorar e Evoluir o
Sistema
Novas
• classes, anotações
Evoluindo e regras
a classe C l i e nde
t e negócio (classe Cliente)
1 @Caption("Cadastro de C l i e n t e s " )
2 p u b l i c class C l i e n t e extends Pessoa {
3 @Agent(event = { " f ocusLost " } , a c t i o n = { " i s P r e f e r e n c i a l " })
4 @Caption("Salário ( R $ ) " ) i n t s a l a r i o ;
5 @Order(after = "observacoes") S t r i n g descricao;
6 @RenderAs(CHECKBOX) @Dependence("descricao")
7 @Agent(property = { " s elec t ed=t rue" } )
8 S t r i n g observacoes;
9 @Dependence(“[:alnum:]")
10@Order(Order.FIRST)
11@Agent(property = { " s e l e c t e d = t r u e ; " } )
12boolean a t i v o ;
13 @RenderAs(value = J Te x t F i e l d . c l a s s , binder =
BooleanToTextComponentBinder.class)
14@Order(LAST)
15boolean v i p = t r u e ;
16@Order( after = "nome") @NotNull @Length(min=12)
String email;
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)

1 p u b l i c class AlgumasRegras {
2
3 @In Context c t x ;
4
5 p u b l i c void i s P r e f e r e n c i a l ( )
6 { ctx.eval("$vip.text=$salario.text>1500 ?
7 'SIM':'NÃO'");
8 }
9 p u b l i c void proposeEmail()
1 { ctx .e va l ( "$e m a i l . te xt= $ no m e.te xt.tri m + ' @ me r l i n .co m '
0 " );
11 }
12 }
Estudo de Caso
4. Efetuar uma nova geração
 Essas alterações poderiam ter sido feitas com o sistema em
execução
Interface CRUD simples resultante
Painel de mensagens após as refatorações e melhorias
TesteM erlin Campos obrigatórios
preenchidas em destaque

Campo Ativo é
Tipo multivalorado
o primeiro da
tela
Preenchimento Rótulo customizado
pela regra e regra de
associada negócio

Formatação de data Campo booleano

customizada com formatação
especial e regra
de negócio
Campo aplicada
Observações
agora é CheckBox
Desabilitado devido
dependência
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
Fim

Geração Automática e Assistida

de Interfaces de Usuário
Marcelo Mrack

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

xx
Sobre o autor
 Marcelo Mrack, mmrack@gmail.com
 30 anos, 9 em TI, 6 em Java
 Bacharel em C. Computação, UNISC – 2001
 Mestre em C. Computação, UFRGS – 2008
 Atuação em projetos web e desktop n camadas
 Diretor de P&D na 3Layer Tecnologia
 Arquiteto JBoss na LM2
 Consultor e instrutor Java EE
 Especialidades: IHC, Patterns, geradores, PU Ágil e
UML
 http://merlin.dev.java.net
 http://telasdecadastro.blogspot.com