Variabilidade em Interfaces de Usuário em Linhas de Produto de Software baseadas na Web: um Estudo Exploratório

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO GUSTAVO SCHMID DE JESUS Variabilidade em Interfaces de Usuário em Linhas de Produto de Software baseadas na Web: um Estudo Exploratório Trabalho de Graduação. Prof. Dr. Ingrid Oliveira de Nunes Orientador Porto Alegre, janeiro de 2014

CIP CATALOGAÇÃO NA PUBLICAÇÃO de Jesus, Gustavo Schmid Variabilidade em Interfaces de Usuário em Linhas de Produto de Software baseadas na Web: um Estudo Exploratório / Gustavo Schmid de Jesus. Porto Alegre: Graduação em Ciência da Computação da UFRGS, 2014. 52 f.: il. Trabalho de Conclusão (bacharelado) Universidade Federal do Rio Grande do Sul. BACHARELADO EM CIÊNCIAS DA COMPUTAÇÃO, Porto Alegre, BR RS, 2014. Orientador: Ingrid Oliveira de Nunes. 1. Linha de produto de software. 2. Interface de usuário. 3. Automatização. 4. Model based user interface design. I. de Nunes, Ingrid Oliveira. II. Título. UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. Carlos Alexandre Netto Vice-Reitor: Prof. Rui Vicente Oppermann Pró-Reitora de Graduação: Prof a. Valquiria Link Bassani Diretor do Instituto de Informática: Prof. Luís da Cunha Lamb Coordenador do CIC: Prof. Raul Fernando Weber Bibliotecária-Chefe do Instituto de Informática: Beatriz Regina Bastos Haro

SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS.................... 5 LISTA DE FIGURAS............................... 7 LISTA DE TABELAS.............................. 9 RESUMO..................................... 11 1 INTRODUÇÃO................................ 13 1.1 Contextualização e Motivação........................ 13 1.2 Estado-da-arte e Limitações......................... 14 1.3 Este trabalho................................. 14 1.4 Objetivos................................... 14 1.5 Estrutura................................... 15 2 FUNDAMENTAÇÃO TEÓRICA...................... 17 2.1 Linha de Produto de Software........................ 17 2.1.1 Reuso.................................... 18 2.1.2 Manutenção................................. 18 2.1.3 Custo.................................... 18 2.2 Trabalhos Relacionados........................... 19 2.3 Tecnologias.................................. 21 2.3.1 S.P.L.O.T.................................. 21 2.3.2 Ruby e Ruby on Rails............................ 21 2.3.3 XML..................................... 23 2.3.4 HTML.................................... 24 2.4 Considerações Finais............................. 25 3 ESTUDO DE CASO............................. 27 3.1 Escopo..................................... 27 3.1.1 Modelo de features............................. 29 3.2 Desafios na IU................................. 29 3.3 Considerações Finais............................. 32 4 SOLUÇÃO.................................. 33 4.1 Breve descrição dos problemas....................... 33 4.2 Técnica proposta - PG-Constraint...................... 33 4.2.1 Origem................................... 34 4.2.2 Objetivo................................... 34

4.2.3 Restrições.................................. 34 4.2.4 Modelagem da solução........................... 35 4.2.5 Algoritmo.................................. 38 4.3 Resultados................................... 41 4.3.1 Exemplo 1.................................. 41 4.3.2 Exemplo 2.................................. 42 4.3.3 Exemplo 3.................................. 43 4.3.4 Exemplo 4.................................. 44 4.4 Considerações Finais............................. 44 5 DISCUSSÃO................................. 45 5.1 Abordagens Existentes............................ 45 5.1.1 Criação manual............................... 45 5.1.2 Criação automatizada - Algoritmos comuns................ 46 5.1.3 Criação automatizada - MBUID...................... 46 5.2 Possíveis Soluções............................... 47 5.2.1 Pontos Positivos............................... 47 5.2.2 Pontos Negativos.............................. 47 5.3 Sugestões de pesquisa............................ 48 5.4 Considerações Finais............................. 48 6 CONCLUSÃO................................ 49 6.1 Contribuições................................. 49 6.2 Trabalhos Futuros.............................. 49 REFERÊNCIAS................................. 51

LISTA DE ABREVIATURAS E SIGLAS SPL SPLC PFE SPLS UI MBUID CBGUI HTML XML PG PU GUI Software Product Line Software Product Line Conference Product Family Engineering Software Product Line Series User Interface Model Based User Interface Design Constrained Based Graphic User Interface Hypertext Markup Language Extensible Markup Language Presentation Group Presentation Unit Graphical User Interface

LISTA DE FIGURAS Figura 2.1: Custo acumulado X número de sistemas, fonte: (Pohl e Linden 2005) 19 Figura 2.2: Exemplo de solução baseada em modelos (MBUID)......... 20 Figura 2.3: Representação dos modelos e de suas transformações da solução baseada em modelos (MBUID), fonte: (Pleuss et al. 2012)........... 20 Figura 2.4: Principais funcionalidades da ferramenta S.P.L.O.T.......... 21 Figura 2.5: Exemplo de código em Ruby retirado do trabalho........... 22 Figura 2.6: Exemplo de código em XML, fonte: (XML code example 2013)... 24 Figura 2.7: Exemplo de código em html, fonte: (HTML code example 2013).. 25 Figura 3.1: IU do cliente de email Gmail...................... 28 Figura 3.2: Interação entre Engenharia de Domínio e Engenharia de Aplicação na derivação de produtos, fonte: (Hauptmann et al. 2010)....... 28 Figura 3.3: Modelo de features da LPS Webmail, fonte: (17)........... 29 Figura 3.4: IU do produto da LPS Webmail com todas features.......... 30 Figura 3.5: IU do produto da LPS Webmail com apenas as features obrigatórias. 31 Figura 3.6: Exemplo de IU sem plugin youtube e calendário........... 31 Figura 3.7: Exemplo de IU sem links e propaganda................ 32 Figura 4.1: Exemplo de modelo AUI do método MBUID, fonte: (Pleuss et al. 2012) 35 Figura 4.2: Modelo de clusters de uma loja web, fonte: (Pleuss et al. 2012)... 37 Figura 4.3: Formato do documento XML..................... 38 Figura 4.4: Algoritmo da técnica PG-Constraint.................. 39 Figura 4.5: Algoritmos auxiliares da técnica PG-Constraint............ 40 Figura 4.6: Resultado do Exemplo 1 da técnica PG-Constraint.......... 41 Figura 4.7: Resultado do Exemplo 2 da técnica PG-Constraint.......... 42 Figura 4.8: Resultado do Exemplo 3 da técnica PG-Constraint.......... 43 Figura 4.9: Resultado do Exemplo 4 da técnica PG-Constraint.......... 44

LISTA DE TABELAS Tabela 4.1: Tabela de posições para a LPS Webmail................ 36 Tabela 4.2: Tabela PG-Constraint referente a figura 3.4.............. 37 Tabela 4.3: Tabela PG-Constraint do Exemplo 1.................. 41 Tabela 4.4: Tabela PG-Constraint do Exemplo 2.................. 42 Tabela 4.5: Tabela PG-Constraint do Exemplo 3.................. 43 Tabela 4.6: Tabela PG-Constraint do Exemplo 4.................. 44

RESUMO Linhas de Produto de Software (LPS) é uma recente e promissora abordagem para desenvolvimento de famílias de sistemas que compartilham um núcleo comum, promovendo o reuso em larga escala e consequentemente alguns benefícios tais como menor tempo e custo de desenvolvimento. A principal característica de uma LPS é a variabilidade de sistemas que ela pode produzir, considerando as diferentes funcionalidades que um sistema pode possuir. Entretanto, existe uma área que é pouco explorada que é a variabilidade em interfaces de usuário (IU). O grande diferencial da variabilidade, nesse contexto, é que a combinação de funcionalidades cria um número exponencial de configurações. Desta forma, projetar uma interface adequada para todas as configurações é inviável do ponto de vista prático. Este trabalho consiste de uma pesquisa de um novo algoritmo utilizando como base um estudo exploratório para identificar os principais desafios e limitações das abordagens atuais no contexto de variabilidade de IU s em LPS s. Utilizando como base a implementação de uma LPS baseada em um sistema Web, é explorada a utilização de técnicas atuais para a implementação dessa variabilidade neste caso de uso particular em conjunto de algumas modificações feitas nestas técnicas para otimizar este processo. Com base no estudo desenvolvido, discutem-se quais lições foram aprendidas, os pontos positivos e negativos da técnica desenvolvida, uma conclusão sobre o estudo realizado e possíveis direções para trabalhos futuros que queiram contribuir nesta área de pesquisa. Palavras-chave: Linha de produto de software, interface de usuário, automatização, model based user interface design.

13 1 INTRODUÇÃO Neste trabalho apresenta-se uma pesquisa de um novo algoritmo que busca otimizar o conjunto atual de algoritmos responsáveis por criar a IU de produtos de uma LPS de forma semi-automática. Analisa-se as principais técnicas existentes com o intuito de identificar os principais problemas de cada uma, com isto é sugerido uma nova técnica que busque solucionar tais problemas. 1.1 Contextualização e Motivação Linha de Produto de Software (LPS) é uma abordagem recente na engenharia de software com sua primeira conferência datando de 1996 (Product Family Engineering - PFE) na Europa e 2000 (Software Product Line Series - SPLS) nos EUA, sendo representado atualmente pela Software Product Line Conference (SPLC) (Software Product Line Conference 2013). LPS pode ser visto como um conjunto de algoritmos e modelos de engenharia de software, utilizados para produzir um sistema capaz de produzir uma família de sistemas, possibilitando a criação de diferentes Software Products que possuam características em comum. Devido a essa família de sistemas, sua principal característica é a variabilidade de seus produtos. Essa variabilidade cria a necessidade de gerenciamento das diferentes features presentes na LPS, tratando assim da variabilidade de configurações possíveis que forma cada produto único entre seus irmãos. Devido a necessidade de gerenciar produtos com diferentes conjuntos de features, surge um problema que consiste em definir um método de produção de software de modo que seja criado de forma sistemática e semi-automática, o produto escolhido por um conjunto de features. Considerando que cada produto é formado por uma parte lógica e outra visual, podemos dividir o problema original em dois, que seriam: Derivação da lógica do produto Derivação da IU 1 do produto De acordo com (Hallvard 2002), para construir a parte lógica do produto existem técnicas já comprovadas que produzem bons resultados, como por exemplo Compilação Condicional, Programação Orientada a Feature, Padrões de Design entre outras. Entretanto quando se considera a IU percebe-se que existem técnicas automáticas, mas o resultado produzido por elas não é satisfatório para grande maioria dos aplicativos existentes. 1 Interface de Usuário

14 1.2 Estado-da-arte e Limitações Atualmente, para produzir boas IU s (intuitivas e de fácil uso) a solução atual que produz o melhor resultado é utilizar pessoas especializadas, por exemplo projetistas de software. Essas pessoas possuem o papel de executar as modificações necessárias de cada IU manualmente para cada produto, criando-se assim uma dependência do produto com esse projetista, pois quando for necessário modificar algo na LPS que modifique a interface de algum produto, não existirá maneira de garantir a funcionalidade do produto pois não existe um rastreamento da feature com a interface modificada. Na tentativa de automatizar esse processo de derivação de produtos temos como principal área de pesquisa a Engenharia de Software dirigida a Modelos (MDSE, do inglês Model-Driven Software Engineering) (19), que quando aplicado a LPS trata da Engenharia de Linha de Produto de Software dirigida a Modelo (MDSPLE, do inglês Model- Driven Software Product Line Engineering) (2). Os algoritmos que utilizam modelos são muito eficientes para derivar a parte lógica dos produtos e até mesmo interfaces de aplicações mais simples como formulários, mas apresentam limitações quando os produtos requerem um nível de customização muito grande aliado de uma boa usabilidade. Podemos citar como exemplo de aplicativo que necessita de muitas customizações um jogo para celular que deve considerar os diferentes tipos de celulares, com suas entradas de dados, tamanho e resolução de telas distintas, entre outros fatores. 1.3 Este trabalho Neste estudo exploratório é feito um estudo utilizando uma LPS desenvolvida para a plataforma Web como uma aplicação de exemplo. Apresenta-se primeiro alguns dos principais problemas do processo de derivação de IU s dos produtos da LPS e após uma técnica que tentará solucionar estes problemas. Utilizando os conceitos de desenvolvimento baseado em modelos, com foco na técnica MBUID (do inglês, Model Based User Interface Design) será discutido uma possibilidade de integração entre a técnica desenvolvida e o MBUID. Como principal fonte de motivação deste estudo temos o artigo (Pleuss et al. 2012) que apresenta os diferentes produtos de uma LPS com seus diferentes níveis de modificação manual da IU devido aos diferentes requisitos do mesmo sistema. Esse estudo mostrou que a área de derivação de IU de modo automatizado necessita de mais pesquisa e experimentação. 1.4 Objetivos Por se tratar de um estudo exploratório, os objetivos focam na pesquisa de novos métodos que busquem solucionar problemas já existentes e instigar novas fronteiras de investigação na área de automatização de IU s para LPS s. Como primeiro objetivo tem-se a criação e experimentação de um novo método para criação semi-automática de IU s para LPS s. Primeiramente é feito uma discussão dos principais problemas encontrados na produção automática de IU dos métodos utilizados atualmente. Após apresentam-se os problemas que essas técnicas se propôem a resolver seguido da técnica proposta neste trabalho para solucionar alguns desses problemas. O segundo e final objetivo é mostrar os resultados da técnica utilizada, de modo que

15 com estes resultados seja possível detectar pontos positivos e negativos do método proposto para que ele possa auxiliar com novas direções para pesquisas e incitar novas investigações no processo de automatização de IU s para LPS s. 1.5 Estrutura Apresenta-se a seguir a estrutura dos capítulos deste trabalho, sumarizando o que é tratado em cada um. Capítulo 2 Apresenta-se a fundamentação teórica necessária para o entendimento deste estudo e uma visão resumida dos principais processos e vantagens da utilização de LPS. Capítulo 3 Apresenta-se a aplicação utilizada como estudo de caso seguido da identificação dos problemas que foram investigados. Capítulo 4 Apresenta-se a técnica desenvolvida neste estudo, apresentando suas restrições de uso, seus modelos e seu algoritmo. Capítulo 5 Apresenta-se os desafios identificados no desenvolvimento de IU s e as lições aprendidas no estudo exploratório realizado. Capítulo 6 Conclue-se o estudo apresentado retomando o contexto do estudo de caso desenvolvido, seguido das contribuições da técnica apresentada e por fim apresentase as sugestões de pesquisa para trabalhos futuros.

16

17 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são abordados os principais conceitos e ferramentas utilizados no desenvolvimento do estudo de caso e da técnica desenvolvida para implementar o gerador semi-automático de IU para LPS. Para um melhor entendimento deste trabalho, é necessário uma introdução dos principais conceitos que são tratados neste estudo. Explica-se o suficiente para o entendimento deste estudo, para maiores informações é recomendado a pesquisa da bibliografia indicada em cada tópico. 2.1 Linha de Produto de Software De acordo com (Clements e Northrop 2001), LPS é definida por um conjunto de sistemas de software que compartilha um conjunto comum de features gerenciáveis que satisfaz uma necessidade específica de um segmento de mercado ou missão e é desenvolvida a partir de um conjunto comum de features de maneira prescrita. Com esta definição em mãos, pode-se verificar que um dos principais requisitos da LPS é criar e gerenciar essa variabilidade de produtos que podem ser produzidos automaticamente com a escolha das features desejadas. Para definir-se uma LPS é necessário a implementação de dois processos sobre a família de produtos escolhida. Apresenta-se agora os processos com uma breve explicação sobre cada um. Engenharia de Domínio Nesse processo é definido e criado os aspectos comuns e variáveis da LPS. Os principais artefatos criados nessa etapa são: (1) um Modelo de Features (Kang et al. 1990), (2) um conjunto de Artefatos do Domínio, e (3) um Mapeamento de Features que relaciona features com seus respectivos artefatos de domínio. Engenharia de Aplicação Nesse processo é feita a derivação dos possíveis produtos da LPS. Este processo é composto por: (1) uma Configuração do Produto que é uma lista das features selecionadas para o produto desejado, e (2) o processo de Derivação do Produto caracterizado por utilizar o mapeamento das features com a configuração do produto para derivar o produto final utilizando-se dos artefatos de domínio. Esse processo normalmente é mais trivial se comparado com a Engenharia de Domínio. De acordo com (Hauptmann et al. 2010), outras vantagens da utilização de LPS é a redução no esforço de desenvolvimento, redução no custo dos produtos e aumento na qualidade do software. Apresenta-se a seguir os fatores que tornam essas vantagens possíveis.

18 2.1.1 Reuso De acordo com (Frakes e Fox 1995), reuso possibilita diminuir os custos de desenvolvimento e ao mesmo tempo aumentar a qualidade do software, além disso evitamos criar código extra para realizar a mesma tarefa em sistemas diferentes. A qualidade do software aumenta pois o código é utilizado e por consequência executado e testado diversas vezes em sistemas distintos, aumentando assim sua confiabilidade. O reuso também facilita a manutenção do software pois ao se detectar uma falha em uma feature, basta resolver o problema uma vez que a solução se replica para todos os produtos. 2.1.2 Manutenção De acordo com (Stafford 2003), manutenção de software é toda modificação feita depois que o produto está pronto. É uma tarefa recorrente para qualquer sistema visto que os requisitos estão em constante mudança. Com a utilização de LPS e por consequência de reuso de software, não é mais necessário a manutenção separada de cada sistema quando trabalhamos com as funcionalidades obrigatórias, pois todos os sistemas filhos utilizam a mesma base de desenvolvimento. A manutenção de uma funcionalidade afeta todos os filhos da LPS que compartilham aquela funcionalidade, facilitando a manutenção de múltiplos sistemas e diminuindo o tempo e a taxa de erros que naturalmente pode ocorrer cada vez que se modifica um programa. 2.1.3 Custo Utilizando como base os estudos apresentandos em (Pohl e Linden 2005), LPS além de poupar custos com reuso e facilidade na etapa de manutenção dos sistemas, ocorre uma diminuição de custo quando consideramos que para cada novo sistema, basta selecionar as funcionalidades desejadas que a LPS se ocupa de criar o produto final. Deve-se perceber que o custo de desenvolvimento da plataforma da LPS possui um custo relativamente alto, deste modo um ganho de custo só ocorre por volta do terceiro sistema desenvolvido. Na Figura 2.1 apresenta-se um gráfico relacionando o custo acumulado com o número de sistemas desenvolvidos, comparando sistemas desenvolvidos separadamente com sistemas desenvolvidos utilizando uma LPS.

19 Figura 2.1: Custo acumulado X número de sistemas, fonte: (Pohl e Linden 2005) Apresenta-se agora alguns trabalhos relacionados que discutem possíveis soluções para a criação de IU de forma automática para LPS. 2.2 Trabalhos Relacionados Como motivação deste estudo tem-se (Pleuss et al. 2012), o qual apresenta exemplos de produtos de uma LPS e o nível de customização manual na IU que cada produto possui. No mesmo ano que foi publicado esse estudo, o mesmo autor publicou o artigo (Pleuss et al. 2012) onde ele apresenta uma maneira semi-automatizada de modelar a customização de cada produto mantendo a rastreabilidade de cada elemento visual da IU com a sua respectiva feature. A técnica utilizada nesse artigo faz parte da Engenharia de Linha de Produto de Software dirigida a Modelo (MDSPLE, do inglês Model-Driven Software Product Line Engineering). Desenvolvimento de IU baseado em modelos é um conjunto de conceitos da área de interação humano-computador (IHC) e Engenharia de Software (ES) para modelar IU s. MBUID é um algoritmo introduzido pela comunidade de IHC que utiliza diferentes tipos de modelos para focar em conceitos diferentes em níveis de abstração diferentes. Na Figura 2.2 é apresentado o diagrama da solução resumida do algoritmo MBUID.

20 Figura 2.2: Exemplo de solução baseada em modelos (MBUID) Na Figura 2.3 são apresentados os modelos utilizados no estudo feito por (Pleuss et al. 2012), com as respectivas transformações entre modelos até a construção da IU do produto. Figura 2.3: Representação dos modelos e de suas transformações da solução baseada em modelos (MBUID), fonte: (Pleuss et al. 2012) A técnica MBUID consiste na criação de um modelo abstrato da IU do produto que se deseja derivar, a partir deste modelo inicial são feitas transformações para outros modelos e escolhas em cada modelo que possibilitam a customização de alguns atributos de interface. Uma discussão completa com exemplos sobre os modelos e algoritmos contidos no método MBUID está presente em (Hauptmann et al. 2010).

21 2.3 Tecnologias A seguir, apresenta-se as principais tecnologias utilizadas no desenvolvimento deste estudo de caso. 2.3.1 S.P.L.O.T S.P.L.O.T (17) é uma aplicação para a plataforma web que facilita a criação e edição de modelos de features, além de outras ferramentas como a configuração de produtos baseada em algum modelo do seu repositório. Na Figura 2.4, apresenta-se a IU do sistema S.P.L.O.T com suas principais funcionalidades. Figura 2.4: Principais funcionalidades da ferramenta S.P.L.O.T Essa ferramenta foi escolhida por não ter custos para utiliza-lá além de ser de fácil uso. 2.3.2 Ruby e Ruby on Rails Ruby é uma linguagem interpretada utilizada para programação orientada a objetos, criada por Yukihiro Matusomoto. Ele mesmo a qualifica como sendo "simples, direto ao ponto, extensível e portável". Ruby foi desenvolvida com o objetivo de criar uma linguagem que utilizasse os melhores aspectos de cada uma das mais famosas linguagens. Com uma sintaxe simples e limpa, Ruby foi parcialmente inspirada por Eiffel e Ada enquanto que o tratamento de exceções possue similaridades com Java e Python. A Figura 2.5 traz um exemplo de código escrito em Ruby retirado da implementação deste trabalho.

22 # s e t s t h e p o s i t i o n of a PG # copy i t s a p p e a r a n c e s i n c u r r e n t P o s i t i o n L I s t t o f i n a l P o s i t i o n L i s t d e f d e f i n e P g P o s i t i o n ( pg, f i n a l P o s i t i o n L i s t, c u r r e n t P o s i t i o n L i s t ) c u r r e n t P o s i t i o n L i s t. e a c h _ w i t h _ i n d e x do pos, i n d e x i f c u r r e n t P o s i t i o n L i s t [ i n d e x ] and pos. i d == pg. i d f i n a l P o s i t i o n L i s t [ i n d e x ] = pg end end r e t u r n f i n a l P o s i t i o n L i s t end # r e t u r n s t r u e i f t h e p o s i t i o n i s n o t o c c u p i e d d e f p o s i t i o n I s F r e e? ( p o s i t i o n, p o s i t i o n L i s t ) i f p o s i t i o n > 0 p o s i t i o n L i s t [ p o s i t i o n ]. n i l?? t r u e : f a l s e e l s e f a l s e end end # r e t u r n s t r u e i f t h e PG p o s i t i o n has a l r e a d y been d e f i n e d d e f p g I s D e f i n e d? ( pg, f i n a l P o s i t i o n L i s t ) f i n a l P o s i t i o n L i s t. e a c h _ w i t h _ i n d e x do pos, i n d e x i f f i n a l P o s i t i o n L i s t [ i n d e x ] == pg end end end r e t u r n r e t u r n f a l s e t r u e Figura 2.5: Exemplo de código em Ruby retirado do trabalho Ruby foi a linguagem de programação escolhida para desenvolver a implementação deste trabalho pois possui um framework para desenvolvimento de aplicações para web muito prático e de ampla divulgação atualmente, o Ruby on Rails. Para maiores informações sobre Ruby, a principal referência se encontra em (Matsumoto 2013). Ruby on Rails é um framework para a linguagem Ruby, tendo seu foco no desenvolvimento de aplicações para a web, sendo considerado hoje um dos mais produtivos frameworks do seu segmento (Hibbs e Tate 2006). Ele utiliza o padrão de projeto MVC 1, este por sua vez é um padrão de arquitetura de software muito utilizado para aplicativos da plataforma web devido a sua estrutura arquitetural que modela bem o esquema cliente/servidor. Os principais recursos do RoR 2 são: Meta-programação Esta técnica serve para criar programas que por sua vez criam outros programas, por exemplo, o que ocorre em uma LPS. 1 Model View Controller 2 Ruby on Rails

23 Active Record Funciona como uma camada de abstração ao acesso ao BD 3, permitindo que com uma só linguagem seja possível a descrição do BD para plataformas distintas. Convenção sobre configuração Como o próprio nome já diz, utilizando-se de convenções perde-se menos tempo configurando o ambiente e mais tempo criando código, bastando para isso apenas conhecer os padrões do RoR. 2.3.3 XML "extensive Markup Language", ou XML é uma linguagem de programação extensiva, ou seja, pode-se definir novos elementos utilizando apenas marcadores do tipo «"e»". Ela é muito utilizada para descrever arquivos que contenham uma grande quantidade de informação e que estejam organizados da maneira necessária e especificada pelo usuário. O uso mais comum do XML é definir um formato de arquivo (DTD, do ingles Data Type Definition) e após cria-se um programa que faça a leitura destes arquivos. XML é utilizado principalmente com a funcionalidade de ser uma forma de intercambio de informação padrão, desta maneira todos podem utilizar uma mesma linguagem para trocar informação. Para maiores informacoes sobre XML e tecnologias afins, recomendo a referência (4). Na Figura 2.6 apresento um arquivo XML, neste caso se trata de um arquivo que armazena os produtos de um café da manha, com seus respectivos preços e valores calóricos. 3 Banco de Dados

24 < b reakfast_menu > <food > <name> B e l g i a n Waffles </ name> < p r i c e >$5. 9 5 < / p r i c e > < c a l o r i e s >650 </ c a l o r i e s > </ food > <food > <name> S t r a w b e r r y B e l g i a n Waffles </ name> < p r i c e >$7. 9 5 < / p r i c e > < c a l o r i e s >900 </ c a l o r i e s > </ food > <food > <name>berry Berry B e l g i a n Waffles </ name> < p r i c e >$8. 9 5 < / p r i c e > < c a l o r i e s >900 </ c a l o r i e s > </ food > <food > <name> French Toast </ name> < p r i c e >$4. 5 0 < / p r i c e > < c a l o r i e s >600 </ c a l o r i e s > </ food > <food > <name> Homestyle B r e a k f a s t </ name> < p r i c e >$6. 9 5 < / p r i c e > < c a l o r i e s >950 </ c a l o r i e s > </ food > </ b reakfast_menu > Figura 2.6: Exemplo de código em XML, fonte: (XML code example 2013) Escolheu-se XML pois é um padrão bem conhecido de linguagem de descrição de arquivos e apresenta várias ferramentas que auxiliam na leitura e criação de arquivos com sua notação. 2.3.4 HTML HTML é a sigla para Hypertext Markup Language, que traduzido para o português significa "Linguagem de marcação para Hipertexto". Hipertexto é o nome utilizado para designar páginas da web que possuam grande quantidade de caracteres e dados em geral. HTML é a principal linguagem utilizada para descrever páginas e portanto IU para sistemas da plataforma web, por isso foi escolhida para implementar a IU neste trabalho. Outro exemplo bem conhecido e muito utilizado para atualizar páginas em HTML é a linguagem Javascript. Javascript executa no lado do cliente modificando a visualização da interface sem que uma requisição extra ao servidor da página seja necessária. A seguir, na Figura 2.7, um exemplo de código escrito em HTML, neste caso é uma página da web com um título e alguns títulos e parágrafos.

25 <HTML> <HEAD> <TITLE> T i t u l o da pagina </ TITLE> </HEAD> <BODY BGCOLOR=" FFFFFF" > <CENTER><IMG SRC=" c l o u d s. j p g " ALIGN="BOTTOM"> </CENTER> <a h r e f =" h t t p : / / s o m e g r e a t s i t e. com"> l i n k </ a> l i n k p a r a o u t r o s i t e <H1> I s s o e um c a b e c a l h o </H1> <H2> I s s o e um c a b e c a l h o medio </H2> Mande me e m a i l p a r a <a h r e f =" m a i l t o : support@exemplo. com"> support@exemplo. com </ a> <P> I s s o e um novo p a r a g r a f o! <P> <B> I s s o e um novo p a r a g r a f o, em n e g r i t o! </b> </BODY> </HTML> Figura 2.7: Exemplo de código em html, fonte: (HTML code example 2013) 2.4 Considerações Finais Neste capítulo se apresentou os principais conceitos e tecnologias que trabalhados no desenvolvimento deste estudo. Apresentou-se resumidamente o que constitue uma LPS, seus dois principais processos, seus artefatos de software e as principais vantagens de seu uso. Viu-se também um trabalho relacionado que trata sobre desenvolvimento baseado em modelos (Hauptmann et al. 2010) que utiliza a técnica MBUID, além de ferramentas e tecnologias relacionadas a esse trabalho. No próximo capítulo é apresentado o estudo de caso composto por uma LPS, utilizando exemplos de produtos para mostrar os problemas que este estudo se propõe a solucionar.

26

27 3 ESTUDO DE CASO Neste capítulo se apresenta o estudo de caso que é composto por uma LPS que será implementada. Finaliza-se o capítulo com os desafios de IU investigados neste estudo. 3.1 Escopo Devido a natureza deste trabalho, deve-se escolher uma aplicação que sirva de estudo para teste da técnica proposta. A LPS escolhida é denominada Webmail e é composta por um cliente de emails para a plataforma web. Escolheu-se essa aplicação por dois motivos principais, que são: 1 - Grande número de usuários Clientes de email são ferramentas muito comuns atualmente, pois a necessidade de um correio virtual é cada dia maior, por isto o número de usuários está em constante aumento. Além disso, praticamente não existe restrição para o tipo de usuário dessas ferramentas, tem-se então desde crianças a idosos utilizando-a. Esses dois fatores dão um grande suporte para futuras avaliações da técnica proposta no capítulo 4 pois existe o potencial de opiniões e requisitos de diversos tipos de usuários. 2 - Grande número de features Por ser uma ferramenta utilizada com frequência, é comum a integração de outras ferramentas no cliente de email, por exemplo sistemas de mensagem instantânea, calendários, repositório de arquivos, entre outros. Essa característica possibilita um alto nível de variabilidade dos produtos possíveis o que aumenta o desafio da técnica e facilita encontrar problemas relacionados a IU. Na Figura 3.1 é apresentado um exemplo de um cliente de email para plataforma web, o aplicativo Gmail popularmente conhecido com diversas features integradas. Para realizar este estudo escolheu-se a plataforma web pois a motivação se originou nos estudos realizados com uma LPS de uma ferramenta de gerência de universidades que possui diversas modificações na sua IU devido a requisitos distintos de cada universidade. Além disso, o autor deste trabalho possui experiência com a linguagem Ruby e com o framework RoR 1. Como visto na seção 2.2, este estudo tem como foco o processo de transformação de modelos, desde um nível abstrato até chegar a um modelo mais concreto que possibilita a criação da IU implementada na linguagem escolhida, esse processo faz parte da Engenharia de Aplicação. Viu-se na seção 2.1, que para a construção de LPS é necessário 1 Ruby on Rails

28 Figura 3.1: IU do cliente de email Gmail o desenvolvimento de dois principais processos, a Engenharia de Domínio e a Engenharia de Aplicação. Na Figura 3.2 é apresentado um resumo do processo de derivação de produtos numa LPS. Figura 3.2: Interação entre Engenharia de Domínio e Engenharia de Aplicação na derivação de produtos, fonte: (Hauptmann et al. 2010) A Figura 3.2 deve ser lida da esquerda para direita e de cima para baixo. Ela representa os dois processos na coluna da esquerda e seus elementos no topo. O próximo passo é apresentar o modelo de features da LPS Webmail pois é com ele que se inicia a Engenharia de Aplicação necessária na criação do produto de software de uma LPS.

29 3.1.1 Modelo de features O modelo de features é o que representa o modelo de variabilidade de uma LPS. Com ele é possível definir o conjunto de features do produto que se deseja criar, além disso ele é o primeiro modelo utilizado na derivação de um produto, seja para o processo de criação da parte lógica quanto da parte visual do produto final. Na Figura 3.3 é apresentado o modelo de features da LPS Webmail. Figura 3.3: Modelo de features da LPS Webmail, fonte: (17) Na Figura 3.3 pode-se verificar todo o conjunto de features dos possíveis produtos da LPS. Para uma melhor compreensão sobre o diagrama apresentado e entendimento das regras e notações presentes neste modelo, recomenda-se a leitura de (Kang et al. 1990). De forma resumida, pode-se dizer que as esferas escuras representam features obrigatórias e as esferas claras features opcionais. Apresenta-se a seguir a IU de alguns produtos dessa LPS para motivar os problemas tratados neste trabalho. Primeiro mostra-se um produto com todas as features do Webmail, seguido do produto com apenas as features obrigatórias e mais dois exemplos de produtos com variações no conjunto de features selecionadas. 3.2 Desafios na IU Para mostrar os problemas que são tratados neste estudo, apresenta-se primeiro a IU do produto que contêm todas as features da LPS seguido do produto com menor número de features, ou seja, apenas as obrigatórias. A partir do primeiro produto apresentado

30 (completo) apresenta-se a IU de dois produtos diferentes com um número menor de features. O algoritmo utilizado para posicionamento das unidades de apresentação (PU, do inglês Presentation Unit) na derivação da IU do produto é uma simples remoção dos módulos da tela, ou seja, cada feature que possui uma PU na IU possui sua posição fixa (a mesma posição para todos os produtos da LPS). É apresentado na Figura 3.4 a IU do produto com todas features do Webmail. Figura 3.4: IU do produto da LPS Webmail com todas features A IU apresentada na Figura 3.4 não apresenta nenhum problema pois esta é a IU planejada do produto, ou seja, a IU ideal. A seguir, na Figura 3.5 apresenta-se a IU do produto com apenas as features obrigatórias.

31 Figura 3.5: IU do produto da LPS Webmail com apenas as features obrigatórias Apresenta-se a seguir, na Figura 3.6 e na Figura 3.7 alguns problemas que aparecem quando retira-se algumas features. Figura 3.6: Exemplo de IU sem plugin youtube e calendário

32 Figura 3.7: Exemplo de IU sem links e propaganda Com a análise da Figura 3.6 e da Figura 3.7 é possível concluir que definir a posição das PU s fixa para todos os produtos da LPS não é um método eficiente de criar a IU do produto. Isto pois quando uma certa feature não é selecionada, no seu lugar não aparece coisa alguma. Deste modo diversos espaços em branco surgem na IU o que prejudica o seu uso e introduzem pelo menos dois problemas, que são: Problema 1: Desperdício de espaço Ocorre um grande desperdício de espaço de tela quando existem espaços em branco. Uma solução para este problema é reorganizar os PU s da tela de forma que aquilo que é de maior importância (prioridade) possa ocupar uma área maior na IU. Desta maneira é possível estender alguns módulos para evitar os espaços em branco dos PU s não selecionados. Problema 2: Baixa usabilidade Os espaços em branco criados pelas features faltantes tornam a IU pouco ortogonal e podem confudir o usuário. A IU perde um pouco de sua comunicabilidade e se torna não ergonômica, o que desencoraja o uso do produto principalmente se existem outros aplicativos que resolvem o mesmo problema mas apresentam uma IU mais amigável e com seus elementos bem dispostos. 3.3 Considerações Finais Neste capítulo apresentou-se o escopo deste estudo com o detalhamento da LPS que será utilizada como estudo de caso da técnica proposta, analisando a IU considerada ideal e alguns problemas que surgem quando utiliza-se um algoritmo simples de posicionamento de PU s para derivar a IU dos produtos. No próximo capítulo é apresentado em detalhes a técnica desenvolvida, com uma explicação de suas restrições de uso, seus modelos e seus algoritmos. Também apresentase um resumo breve da técnica MBUID e como o método proposto deriva e se adapta a ela.

33 4 SOLUÇÃO Neste capítulo é apresentado a técnica desenvolvida que sugere uma possível solucão para os problemas apresentados na seção 3.2. Este capítulo inicia-se com uma breve descrição dos problemas de IU que estão relacionados a técnica, seguido de uma descrição detalhada do método proposto. 4.1 Breve descrição dos problemas Antes de apresentar a técnica, é importante identificar quais são os principais problemas que ela se propôe a resolver e que as técnicas utilizadas atualmente não resolvem. Problema 1: Espaços em branco Esse problema se refere aos espaços em branco que surgem quando a posição de cada PU é fixa para a LPS, deste modo quando uma feature que possui uma PU na tela não é selecionada para o produto, no seu lugar não aparece nada. Problema 2: Posição dos PU s Esse problema é um requisito necessário para a customização de PU s de modo que seja possível definir a posição individual de cada PU dentro de um conjunto de posições possíveis, de acordo com o layout da aplicação. Considerando os problemas apresentados, mostra-se em detalhes a solução desenvolvida para resolver estes problemas. 4.2 Técnica proposta - PG-Constraint O nome PG-Constraint pode ser dividido em duas partes, PG e Constraint. PG é a sigla do inglês Presentation Group que traduzido para o português significa "Grupo de Apresentação". Neste trabalho um grupo de apresentação é um cluster que precisa ter uma representação na IU do produto, sendo ele representado por um PU. Constraint é uma palavra do inglês que significa restrição, são as restrições que modelam as customizações do método. Para definir a técnica em poucas palavras, pode-se dizer que ela se resume na utilização de uma tabela para representar cada PG da IU do produto que se está derivando, onde para cada PG é possível definir um conjunto de restrições que definem alguns atributos desejados na IU final.

34 4.2.1 Origem A técnica PG-Constraint possui suas raízes no método MBUID. Pode-se ver na Figura 2.3 que o processo MBUID é composto por várias etapas, cada etapa com um propósito e modelos distintos. A derivação de um produto inicia com um modelo abstrato de IU (AUI, do inglês Abstract User Interface), seguida de um processo de clusterização que possui o objetivo de dividir o modelo de features da LPS em PU s que transforma o AUI num modelo de cluster. Deste modelo de cluster é executado um processo automatizado para criar um modelo de navegação que passa por outro processo automatizado afim de criar dois modelos intermediários, um modelo de navegação e um modelo de apresentação. O modelo de navegação serve para gerenciar a navegação entre as telas do produto final, por isto não é contemplado neste estudo. O modelo de apresentação contém as PU s porém num nível ainda abstrato, desta forma é necessário a transformação deste modelo para um modelo concreto de apresentação (CUI, do inglês Concrete User Interface). Depois de criado este modelo concreto é executado a última transformação para a linguagem de IU desejada. 4.2.2 Objetivo A técnica PG-Constraint foi proposta com o objetivo de fornecer um nível de customização de IU não contemplado na técnica MBUID que foi verificada e implementada em (Hauptmann et al. 2010). A técnica foi criada com o intuito de que uma futura integração com o método MBUID seja possível, de modo que um novo nível de customização esteja disponível, mantendo-se os outros benefícios. A técnica visa resolver os problemas de posicionamento de PG s e aproveitamento de espaço de tela pois verificou-se que a técnica MBUID é muito eficiente para trabalhar com a estrutura e disposição de itens dentro de um dado PG, entretanto ela não possui uma maneira intuitiva e direta de escolher o posicionamento e atributos relacionados ao posicionamento entre os PG s da IU. A seguir, apresenta-se as principais restrições da técnica PG-Constraint. 4.2.3 Restrições Devido a natureza do trabalho (estudo exploratório), a técnica desenvolvida possui algumas restrições pois ela trata de um estudo de caso específico, logo existem algumas restrições que tornam a técnica um pouco menos genérica do que o desejado. A seguir apresenta-se algumas das restrições consideradas. Limite de PG s Para simplificar a técnica/problema, definiu-se que não é possível selecionar mais PG s para a IU do que o número de posições possíveis para os módulos. Essa restrição pode ser eliminada se for aceito que um ou mais PG s selecionados podem não aparecer na IU final. Layout das posições Por restrição de layout temos o Grid Layout onde cada posição possui bem definido seus vizinhos na vertical e horizontal. A utilização de layouts diferentes é uma das sugestões para trabalhos futuros. Extensibilidade Este item possui duas restrições relacionadas, a primeira se refere a restrição de cada PG só poder ser extendido para uma direção, vertical ou horizontal. A segunda diz respeito as restrições inerentes ao layout utilizado, por exemplo, um

35 PG na posição no canto esquerdo da tela que deseja se extender por toda a tela horizontalmente não poderá estar presente apenas nos extremos mas de forma contínua, ou seja, presente também nas posições intermediárias. A seguir é apresentado os modelos desenvolvidos que possibilitam a implementação e o entendimento completo da técnica PG-Constraint. 4.2.4 Modelagem da solução Para explicar a origem da modelagem desenvolvida é necessário primeiro explicar os passos iniciais da técnica MBUID e indicar onde se inserem os modelos desenvolvidos da técnica PG-Constraint. Os principais passos do MBUID estão representados na Figura 2.3, a seguir explica-se brevemente alguns deles. Passo 1: Conhecer o feature model Para derivar qualquer produto de qualquer LPS é necessário primeiramente um modelo com as features que a LPS disponibiliza. Pode-se ver o modelo de features na Figura 3.3. Passo 2: Criação do modelo AUI Nesta etapa é desenvolvido uma espécie de árvore que representa os possíveis itens de IU que as features do modelo de features representam. Pode-se ver um exemplo de modelo AUI na Figura 4.1. Figura 4.1: Exemplo de modelo AUI do método MBUID, fonte: (Pleuss et al. 2012) Passo 3: Criação do modelo de clusters/pg s O modelo de clusters é criado a partir do modelo AUI, nele é possível representar os PG s que farão parte do produto final, de modo que aqui é possível customizar a estrutura interna de cada PG. Um exemplo de modelo de cluster construído sobre o modelo AUI é apresentado na Figura 4.2. Com o modelo de clusters já definido, o próximo passo do MBUID é desenvolver o modelo navegacional abstrato para depois uní-lo com o modelo de clusters para produzir o modelo navegacional e o modelo de apresentação. É na etapa de criação do modelo navegacional abstrato que a técnica PG-Constraint se distancia da MBUID, pois ela trata

36 apenas da disposição de PU s na IU, diferente do MBUID que trata da navegação e da composição interna de cada PU. Com o modelo de clusters é possível mapear cada PU selecionado para uma tabela de modo que seja possível definir algumas restrições para o posicionamento dos PU s. Antes de apresentar essa tabela é necessário mostrar um desenho que apresente as posições de tela que cada PU pode ocupar, pois isto será um fator importante no algoritmo de customização. A seguir, a tabela de posições utilizada neste estudo de caso. 4.2.4.1 Tabela de Posições A tabela de posições deste estudo não está representada em forma de tabela mas ela pode ser representada por uma. A principal função dessa tabela é servir como um guia responsável por identificar todas as possíveis posições que cada PG pode ocupar. Utilizando essa tabela, o modelo de clusters e as restrições desejadas é possível a criação automatizada da tabela PG-Constraint. Pode-se ver na na Tabela 4.1 as possíveis posições para PG s deste estudo de caso, a LPS Webmail. Tabela 4.1: Tabela de posições para a LPS Webmail Além de definir as possíveis posições dos PG s, essa tabela possui mais duas funções. A primeira é identificar quais são os vizinhos na vertical e na horizontal de cada posição, a segunda é armazenar as restrições de extensibilidade. Essa funções extras são discutidas com mais detalhe na seção de trabalhos futuros do próximo capítulo. A seguir, apresentase a tabela PG-Constraint que dá nome a técnica desenvolvida, todas as customizações possíveis estão representadas nela. 4.2.4.2 Tabela PG-Constraint A tabela PG-Constraint é o principal modelo da técnica pois é nela que estão as restrições que definirão as posições finais dos PG s. Ela armazena todos os grupos de apresentação (PG s) selecionados no modelo de cluster e que vão compor o produto final. Para entender melhor o seu uso primeiro é preciso definir o que é um PG. Tanto para a PG-Constraint quanto para o método MBUID, um PG é um cluster, sendo esse cluster podendo ser composto internamente por um ou mais clusters e/ou fragmentos, este conceito está definido em (Botterweck 2006). Para uma visualização do conceito de cluster e fragmento, apresenta-se a seguir um exemplo de modelo de clusters e fragmentos na Figura 4.2.

37 Figura 4.2: Modelo de clusters de uma loja web, fonte: (Pleuss et al. 2012) A principal função da tabela PG-Constraint é definir as restrições de cada PG. Apresenta-se a Tabela 4.2 que representa a IU do produto representado na Figura 3.4, ou seja, o produto com todas as features da LPS Webmail. Tabela 4.2: Tabela PG-Constraint referente a figura 3.4 Explica-se agora os atributos dessa tabela. Atributo 1: Fixo Esse atributo é utilizado para definir se o PG pode ou não mudar de posição na IU final. Caso ele esteja ativo, o atributo posição2 e posição3 devem ser nulos. Atributo 2: Extensível O atributo extensível se refere a possibilidade de extensão do PG. Para este atributo são possíveis três estados: desativado, ativo-horizontal e ativovertical. A extensão de PG s é utilizada para evitar o desperdício de espaço na tela e dar prioridade a aquelas features mais prioritárias. Atributo 3: Prioridade Apesar de não ser o primeiro atributo da tabela, prioridade certamente é o atributo que possui maior impacto no algoritmo da técnica PG- Constraint. A prioridade ajuda a definir a ordem de colocação dos PG s na tela além de definir quem irá ocupar uma dada posição de tela quando uma ou mais PG s possuem prioridades distintas. Atributo 4: Posição(1,2,3) O atributo posição(1,2,3) representa as posições que se aceita que o PG possa ocupar na IU final. Eles possuem ordem de prioridade da seguinte forma: posicao1 > posicao2 > posicao3. Para todo PG não fixo é necessário a escolha de pelo menos posicao1 e posicao2 pois uma realocação do PG não fixo deve ser possível. Pode-se perceber que é possível estender essa tabela de modo a adicionar mais atributos para aumentar o nível de customização da técnica, o que acarretaria mudanças no algoritmo da técnica. A seguir o último modelo da técnica PG-Constraint.

38 4.2.4.3 Modelo Concreto - XML O modelo concreto é o modelo mais próximo da linguagem de implementação da IU, é a partir dele que será criado o código para a linguagem final de IU, neste caso de estudo a linguagem HTML. Para representar este modelo escolheu-se utilizar um arquivo no formato XML pois ele é um formato muito divulgado, de fácil entendimento e com muitas ferramentas existentes para fazer sua leitura. Na Figura 4.3 é apresentado o modelo do DTD (Data Type Definition) do arquivo XML dado a tabela de PG-Constraint da Figura 4.2. Figura 4.3: Formato do documento XML A seguir é apresentado o algoritmo desenvolvido para a técnica PG-Constraint. 4.2.5 Algoritmo Nesta seção mostra-se em detalhes o algoritmo responsável por calcular a posição e extensão dos PG s escolhidos e representados na tabela PG-Constraint. Se fosse necessário definir o algoritmo em poucas palavras, pode-se dizer que ele consiste em transformar a tabela de posições e a tabela PG-Constraint em um modelo final que pode ser representado por um arquivo XML. Com este arquivo é possível o desenvolvimento da IU final na linguagem desejada bastando apenas a utilização de algum leitor de XML que se encontra com facilidade na literatura. Na Figura 4.4 apresenta-se a função principal do algoritmo e na Figura 4.5 as duas funções auxiliares, a Extende e Realoca.

39 Figura 4.4: Algoritmo da técnica PG-Constraint 4.2.5.1 Validação da tabela PG-Constraint Para o correto funcionamento da técnica desenvolvida é necessário a definição de algumas regras quanto ao formato do conteúdo presente na tabela PG-Constraint, os passos: Passo 1.A.1: Dois PG s não podem compartilhar posição1 Essa restrição define que dois PG s quaisquers não podem ter definidos como posição1 uma mesma posição. Essa validação não é obrigatória, mas evita um erro comum de sobreposição de PG s e elimina mais um fator de aleatoriedade no resultado final da IU. Passo 1.A.2: Dois PG s não podem ser iguais (fixo,prioridade) Essa restrição existe para evitar casos onde por exemplo, tem-se dois PG s, fixos e de mesma prioridade que podem ser estendidos. Criando esta restrição não existe dúvida sobre qual PG sofrerá a estensão. Passo 1.B.1: Cada PG não fixo deve possuir pelo menos duas posições Essa validação não é obrigatória para o funcionamento do algoritmo, entretanto é altamente recomendada pois caso um PG não fixo tenha que ser movida, a posição final do PG poderá estar dentro do conjunto de posições especificado na tabela.

40 Figura 4.5: Algoritmos auxiliares da técnica PG-Constraint Apresenta-se agora como é feito o cálculo da posição e estensão dos módulos. 4.2.5.2 Cálculo da posicão e extensão dos PG s Depois que a tabela PG-Constraint está validada, o próximo passo é posicionar os PG s nas posições representadas pela tabela de posições da Figura 4.1. A seguir apresentase os últimos passos do algoritmo: Passo 2: Guardar em cada posição o respectivo PG ocupado Neste passo é armazenado em uma variável qual PG está contido em cada uma das posições de tela possíveis. O procedimento é ler todas as entradas da tabela PG-Constraint, e para cada atributo posição1, relacionar o PG com a posição escolhida. Passo 3: Contar o número de posições livres Neste passo é feita a contagem de quantas posições não estão ocupadas para definir quantas estensões de PG s serão possíveis. O procedimento é muito simples, basta ler a variável resultante do passo 2 e para cada posição sem um PG relacionado soma-se um ao número total de posições livres. Passos 4 e 5: Posicionar PG s por ordem de prioridade Os passos 4 e 5 são semelhantes, o principal fator que os diferencia é o tipo de PG que está sendo posicionado, no passo 5 toma-se os PG s fixos e no passo 6 os não fixos. Primeiramente é selecionado todos os PG s fixos e ordena-se eles de acordo com suas prioridades. Inicia-se pelo PG de maior prioridade e fixo, se verifica se é possível sua extensão, se a resposta for positiva deve-se tentar estender o PG. Caso a posição necessária para a estensão estiver ocupada, procura-se movimentar quem estiver ocupando se sua prioridade for menor que a PG que está sendo estendida. A saída deste algoritmo é uma lista das posições com cada posição contendo o seu respectivo PG que o ocupa. Com esta lista é possível criar o arquivo XML que poderá ser utilizado para criar a IU final. A seguir, os resultados da técnica aplicado ao Webmail.

41 4.3 Resultados Apresenta-se, nesta seção, os resultados da técnica PG-Constraint para os quatro exemplos apresentados no capítulo 3, o estudo de caso. 4.3.1 Exemplo 1 O primeiro exemplo é composto pelo produto com todas as features da LPS Webmail, como aparece na Figura 3.4. Tabela 4.3: Tabela PG-Constraint do Exemplo 1 Resultado da tela com o algoritmo PG-Constraint: Figura 4.6: Resultado do Exemplo 1 da técnica PG-Constraint