1. U NIVERSIDADE F EDERAL DE G OIS I NSTITUTO DE I NFORMTICAS OFIA L ARISSA DA C OSTAUma Abordagem Baseada em Modelos para Construo Automtica deInterfaces de Usurio para Sistemas deInformaoGoinia 2011

2. S OFIA L ARISSA DA C OSTAUma Abordagem Baseada em Modelos para Construo Automtica deInterfaces de Usurio para Sistemas deInformao Dissertao apresentada ao Programa de PsGraduao do Instituto de Informtica da Universidade Federal de Gois, como requisito parcial para obteno do ttulo de Mestre em Computao. rea de concentrao: Sistemas de Informao. Orientador: Prof. Juliano Lopes de Oliveira Goinia2011 3. Todos os direitos reservados. proibida a reproduo total ou parcial dotrabalho sem autorizao da universidade, do autor e do orientador(a).Soa Larissa da CostaGraduou-se em Cincia da Computao na UFT - Fundao UniversidadeFederal do Tocantins. Durante sua graduao, foi Desenvolvedora Web daTecnoplace Gesto e Tecnologia. Durante o mestrado na UFG, foi bolsistada CAPES e desenvolveu pesquisa no projeto Estratgias e Mtodos paraMelhorias de Software. 4. Deus, sem a qual no posso viver.Aos meus pais, pelo incentivo e apoio incondicional.Ao Glesio, pelo amor e compreenso. 5. AgradecimentosA Deus, por ter me dado a oportunidade de concluir esta etapa. Por ter meiluminado e concedido sabedoria. Sem Ele nada posso.Aos meus pais, Abner e Jeane, pelo amor e apoio em todos os momentos. Pelasconversas ao m do dia, pela preocupao e pelos momentos de distrao. Na distnciaem que estivemos nestes dois anos pude perceber o quanto so valiosos em minha vida,obrigada por tudo!A minha irm Deyse, que mesmo distante se fez presente, pela ateno e carinhoem todos os momentos.Ao Glesio, pelo amor, carinho, ateno, apoio e compreenso durante estes doisanos. Agradeo pelo incentivo! Por sua famlia que me acolheu em muitos momentos.s minhas tias Elenice e Noemi, por terem me acolhido nestes dois anos,obrigada pela amizade, pacincia e ateno.Ao meu orientador, professor Juliano, pela pacincia e orientao, por ter trans-mitido conhecimentos que sero importantes durante minha vida prossional, e por serum exemplo para cada um de seus alunos na formao de novos conhecimentos.Aos meus colegas do grupo de pesquisa do Mestrado, Valdemar e Luiz, queauxiliaram nos momentos de estudo e pela amizade. Aos colegas de mestrado, Fabiana,Patrcia, Marcelo, Adriana, Elisabete e Daniel por terem caminhado junto comigo nestajornada, pelos conhecimentos partilhados e pelos momentos de distrao.Aos professores do INF, pelos ensinamentos e auxlio. Aos funcionrios domestrado do INF, pelos trabalhos realizados com presteza. CAPES, pelo apoio nanceiro. 6. Porque o SENHOR d a sabedoria; da sua boca que vem o conheci-mento e o entendimento. Provrbios 2:6 , Bblia Sagrada, Edio Almeida Corrigida e Revisada. 7. ResumoDa Costa, Soa Larissa. Uma Abordagem Baseada em Modelos para Cons-truo Automtica de Interfaces de Usurio para Sistemas de Informao .Goinia, 2011. 114p. Dissertao de Mestrado. Instituto de Informtica, Univer-sidade Federal de Gois.A construo de interfaces de usurio para Sistemas de Informao (SI) envolve mode-lagem e codicao de aspectos de aparncia (apresentao) e comportamento (forma deinterao). Este trabalho prope uma abordagem baseada em modelos para construodessas interfaces com o apoio de ferramentas de transformao automtica de modelose de gerao de cdigo de interface. A abordagem utiliza o conceito de Esteretipo deInterface, introduzido neste trabalho, que identica, em alto nvel de abstrao, carac-tersticas de aparncia e comportamento de interfaces, independentemente da aplicaodo Sistema de Informao subjacente. Uma taxonomia para elementos de interface pro-posta como base para a denio de esteretipos, juntamente com um mecanismo paraespecicao do comportamento da interface, que permite expressar aes e restriessobre esteretipos de interface de maneira precisa, objetiva e independente da plataformade implementao da interface. Tambm proposta uma arquitetura para um componentede software que gerencia a construo de interfaces baseada em modelos. A arquiteturadene como este componente pode ser integrado ao processo de desenvolvimento de SI.A abordagem para construo baseada em modelos proposta neste trabalho traz benef-cios em termos de esforo e custo de construo facilitando a manuteno e a evoluode interfaces de usurio em SI. Alm disso, o uso de esteretipos promove a consistnciae a padronizao, tanto da apresentao quanto do comportamento das interfaces, melho-rando a usabilidade de SI.PalavraschaveInterfaces de Usurio para Sistemas de Informao; Modelagem de Interfacede Usurio; Esteretipo de Interface; Construo Automtica de Interfaces de Usuriobaseada em Modelos. 8. Abstract Da Costa, Soa Larissa. A Model-Based Approach to User Interfaces Auto- matic Building for Information Systems. Goinia, 2011. 114p. MSc. Disserta- tion. Instituto de Informtica, Universidade Federal de Gois.Building user interfaces for Information Systems (IS) involves modeling and coding ap-pearance (presentation) and behavioral (interaction) aspects. This work presents a model-based approach to building these interfaces using tools for automatic transformation ofmodels and for interface code generation. The proposed approach applies the conceptof Interface Stereotype, introduced in this work, which identies, in a high level of abs-traction, features of user interface (UI) appearance and behavior, independently of theunderlying IS application. A taxonomy of interface elements is proposed as the basisfor stereotype denition, along with a interface behavior specication mechanism, whichallows expressing actions and restrictions on the stereotypes by precise, objective andindependently from the interface implementation platform. It is also proposed a architec-ture for a software component which manages model-based user interfaces building. Thearchitecture denes how this component can be integrated in IS development process.The approach for model-based user interface development proposed in this work bringsbenets in effort and cost construction terms, facilitating the maintenance and the evolu-tion of user interface of IS. Futhermore, the use of stereotypes promotes consistency andstandardization of both presentation and behavior of interfaces, improving usability of IS.KeywordsUser interface of Information Systems; User interface modeling; InterfaceStereotype; Model-based User Interface automatic building. 9. SumrioLista de Figuras10Lista de Tabelas121 Introduo131.1 Diculdades para Gerao Automtica de IU 131.2 Objetivos do Trabalho 171.3 Contribuies do Trabalho 171.4 Metodologia de Desenvolvimento do Trabalho181.5 Organizao do Trabalho 192 Desenvolvimento de IU Baseado em Modelos212.1 Engenharia de Interfaces de Usurio 212.2 Abordagens para construo de IU baseada em modelos 242.3 Requisitos para Construo de IU em SI252.3.1Requisitos de Organizao252.3.2Requisitos de Decomposio 262.3.3Requisitos de Mapeamento 272.3.4Requisitos de Abstrao272.3.5Requisitos de Conformidade 282.4 Correlao entre Desaos e Requisitos para abordagens de Construo de IU 282.5 Comparao entre abordagens 293 Metamodelos para IU 323.1 Metamodelo de Domnio 323.2 Metamodelo de IHC 353.2.1Aspecto de Apresentao de IHC 363.2.2Aspecto de Comportamento de IHC393.2.3Esteretipo de Interface 403.2.4Exemplo de Utilizao do Metamodelo de IHC 433.2.5Correlao entre Apresentao e Comportamento de IU443.3 Metamodelo de Apresentao464 Arquitetura para um Sistema de Gerncia de IU 504.1 Viso geral da Arquitetura do Framework de Gesto de SI 504.2 Viso geral da Arquitetura do componente para Gerncia de IU524.3 Viso Lgica do Pacote Modelo 544.3.1Pacote Metamodelo de IHC 544.3.2Pacote Metamodelo de Apresentao56 10. 4.3.3 Pacote Transformador Domnio para Interface Abstrata 564.3.4 Pacote Transformador Interface Abstrata para Concreta594.3.5 Pacote Interpretador de Interface Final614.4 Comunicao entre os pacotes 625 Construo Automtica de IU Baseada em Modelos 665.1 Viso Geral da Abordagem Proposta665.2 Modelagem de Esteretipo de Interface685.2.1 Esteretipo de Portal Corporativo685.2.2 Esteretipo de Contedo de Pgina Inicial715.2.3 Esteretipo CRUD 735.3 Transformao de Domnio em Interface Abstrata 765.4 Transformao de Interface Abstrata em Interface Concreta785.5 Interpretao da Interface Concreta para Execuo805.6 Integrao da Abordagem com a Construo de SI 816 Concluses 896.1 Consideraes Finais 896.2 Contribuies926.3 Limitaes 936.4 Trabalhos Futuros93Referncias Bibliogrcas95A Regras de Transformao entre Modelos 103A.1 Regras de Mapeamento do Metamodelo de Domnio para o Metamodelo de IHCempregando o Esteretipo Formulrio 103A.2 Regras de Mapeamento do Metamodelo de IHC para o Metamodelo de Apresen-tao 107 11. Lista de Figuras2.1Engenharia de IU Dirigida por Modelos (adaptada de [5]) 232.2Requisitos para Abordagens de Construo de IU baseada em Modelos 263.1Metamodelo de Domnio (adaptado de [15])333.2Exemplo de Aplicao do Metamodelo de Domnio 353.3Metamodelo de IHC 373.4Exemplo de Esteretipo - Formulrio 423.5Exemplo de Aplicao do Metamodelo de IHC 443.6Metamodelo de IU concreta 463.7Exemplo de Aplicao do Metamodelo de Apresentao494.1Viso Geral da Arquitetura do Framework para Gesto de SI 514.2Viso Geral da Arquitetura para gerncia de IU534.3Viso Lgica do Metamodelo de IHC 554.4Viso Lgica do Metamodelo de Apresentao574.5Viso Lgica do Transformador Domnio para Interface Abstrata 584.6Viso Lgica do Transformador Interface Abstrata para Concreta604.7Viso Lgica do Pacote ManagedBeans do Interpretador624.8Viso Lgica do Pacote Interface Final do Interpretador 634.9Processo de Construo de IU utilizando o componente projetado644.10 Processo de Execuo de IU utilizando o componente projetado655.1Cenrios para gerao de IU baseada em modelos675.2Esteretipo de Interface Portal 695.3Modelagem do Esteretipo de Interface Portal705.4Fachada de regras para Portal 715.5Esteretipo de Interface Contedo de Pgina Inicial 725.6Fachada do Esteretipo de Interface Contedo de Pgina Inicial735.7Modelagem do Esteretipo de Interface CRUD755.8Esteretipo de Interface CRUD 765.9Fachada de regras para Interfaces CRUD775.10 Template em JSF para Esteretipo Formulrio 785.11 Interface Abstrata gerada para Pessoa 795.12 Modelagem de Domnio do Portal de uma empresa 805.13 Portal de uma empresa 83 (a) Site com Portal de uma empresa83 (b) Interface Abstrata gerada para Portal de uma empresa835.14 Interface Concreta gerada para Pessoa 845.15 Interface Concreta gerada para Portal de uma empresa85 12. 5.16 Ciclo de vida de IU em SI 865.17 Integrao entre os aspectos de Domnio de Negcio e Interface de Usurio 875.18 Integrao entre os aspectos de Processo de Negcio com Domnio de Negcio e Interface de Usurio88A.1Mapeamento do Elemento de Negcio para um Esteretipo Formulrio 103A.2Mapeamento de um Atributo Alfanumrico para uma Questo Aberta 104A.3Mapeamento de um Atributo Numrico para uma Questo Aberta 104A.4Mapeamento de um Atributo Data para uma Questo Aberta 105A.5Mapeamento de um Atributo Binrio para uma Questo Aberta105A.6Mapeamento de um Atributo Enumerado para uma Questo Fechada 106A.7Mapeamento de uma Regra para uma Ao Externa106A.8Mapeamento do Esteretipo de Interface para Template 107A.9Mapeamento da QuestaoAberta para PainelEntradaTexto108A.10 Mapeamento da QuestaoAberta para PainelEntradaData 108A.11 Mapeamento da QuestaoFechada para PainelEntradaEnum109A.12 Mapeamento da QuestaoFechada para PainelEntradaBoolean 109A.13 Mapeamento da QuestaoFechada para PainelEntradaLista 110A.14 Mapeamento da QuestaoFechada para PainelEntradaRadio 110A.15 Mapeamento da QuestaoFechada para PainelEntradaChecarMultiplos 111A.16 Mapeamento de InformacaoServico para PainelNavegacaoBotao111A.17 Mapeamento de InformacaoServico para PainelNavegacaoLink 112A.18 Mapeamento de InformacaoServico para PainelNavegacaoMenu 112A.19 Mapeamento de InformacaoFeedback para PainelInfoFeedback 113A.20 Mapeamento de InformacaoTextual para PainelInfoTextual 113A.21 Mapeamento de InformacaoPopulacao para PainelInfoPopulacao 114 13. Lista de Tabelas1.1 Desaos para Construo de IU Baseada em Modelos 152.1 Comparao entre as Abordagens para Construo de IU Baseada emModelos304.1 Regras de Mapeamento do pacote Transformador Domnio para InterfaceAbstrata 584.2 Regras de Mapeamento do pacote Transformador Interface Abstrata paraConcreta 606.1 Associao dos Requisitos com a abordagem proposta neste trabalho91 14. CAPTULO 1Introduo Interfaces de Usurio (IU) so componentes que permitem a interao entrepessoas e um sistema computacional [39]. Apesar de signicativos avanos obtidos pelacomunidade de pesquisa em IU, construir interfaces de alta qualidade um desao aindapresente [30]. Abordagens automatizadas para construo de IU podem ajudar a enfrentar essedesao, trazendo benefcios no apenas em termos de produtividade, mas tambm emrelao qualidade das IU geradas, alm do maior controle para sua evoluo. Este trabalho prope uma abordagem baseada em modelos para automatizar aconstruo de IU para Sistemas de Informao (SI), isto , sistemas que possuem coleesde dados e de processos que coletam, armazenam, transformam e distribuem informaespor meio de uma interface grca [63].1.1 Diculdades para Gerao Automtica de IUA gerao de IU para aplicaes interativas de SI engloba a modelagem detarefas e informaes que o usurio necessita manipular, dos relacionamentos entre tarefase informaes, e da forma utilizada pelo usurio para realizar cada tarefa. A complexidadedessa modelagem, e da implementao dos modelos resultantes, torna o processo deconstruo de IU para SI difcil, caro e propenso a erros. De fato, questes relativas aIU podem consumir mais de 50% do tempo de desenvolvimento de SI [30].H duas abordagens principais para desenvolvimento de IU [18]: o mapeamentomanual das necessidades do usurio para linguagens computacionais; e a construoautomatizada a partir de modelos. O foco deste trabalho est nesta ltima abordagem.O desenvolvimento de IU baseado em modelos [66, 9], denido como oprocesso de criar e renar modelos visando a gerao de IU. O uso de modelos aumenta onvel de abstrao, ajudando o usurio a entender com mais clareza como os requisitos sotransformados em interfaces, e tambm facilita a reutilizao de conceitos de interfacesem outros projetos [1, 37]. Esta abordagem tem sido foco de muitas pesquisas queresultaram no desenvolvimento de diversas ferramentas [58, 66]. 15. 1.1 Diculdades para Gerao Automtica de IU14Esforos recentes para construo de IU baseada em modelos tm focado namodelagem em alto nvel de abstrao e na gerao automtica do cdigo, de formaa modelar IU sem a dependncia de um especialista em usabilidade e a obter maiorecincia que a programao manual de IU [22].Apesar dos avanos obtidos, ainda no possvel criar automaticamente soluescompletas para IU [72, 76, 38, 45]. Por exemplo, um dos princpios de projeto de IU a separao entre o cdigo de interface e a lgica da aplicao [44], mas este princpiono tem sido considerado pelas abordagens de gerao de IU. Em muitas abordagens, odesign de IU ainda um subproduto acidental ou oportunstico da construo de software.Mesmo com a existncia de abordagens automatizadas, grande parte das IU ainda desenvolvida com construo manual de cdigo e utilizao de modelos de baixo nvelpor desenvolvedores que no conhecem o domnio da aplicao e as necessidades dosusurios [4].A qualidade das IU geradas ainda inferior das manufaturadas, e a necessidadede personalizao das IU geradas contribui para dicultar este problema. Outros desaosna construo de IU so a modelagem de um vasto conjunto de eventos relacionados aocomportamento de IU; a falta de apoio decomposio dos elementos da interface, a mde serem reutilizados; e a diculdade de integrao de IU geradas com a lgica de negciode SI subjacentes.Nesse sentido, buscou-se compreender os desaos existentes no desenvolvi-mento de IU baseado em modelos, de forma a compreender quais problemas devem seratacados na evoluo das atuais abordagens.A Tabela 1.1 sumariza os desaos identicados nesta seo. Diante da diversi-dade de trabalhos com abordagens para o desenvolvimento de IU baseado em modelos, um desao identicar qual deles possui as propriedades necessrias para construir IUpara SI. Antes disso, torna-se indispensvel extrair um conjunto de caractersticas quedescrevam aspectos de apresentao e comportamento de IU bem como sobrelevem osdesaos mencionados.A Engenharia de IU requer uma linguagem estruturada para a descrio deIU (desao 1 da Tabela 1.1). Isto signica que os modelos devem ser descritos emuma linguagem no-ambgua e visual de forma que seja possvel compreender quaisrequisitos devem ser considerados na descrio de IU. Isto tambm torna possvel ocompartilhamento das informaes dos modelos entre diferentes ferramentas [72].Ferramentas para o desenvolvimento de IU baseado em modelos tentam produzirautomaticamente uma interface de usurio concreta a partir de um modelo abstrato. Emgeral, elas atingem esse propsito com um sucesso limitado. A razo para esta limitaotem sido identicada como o problema do mapeamento [56] (desao 2), que consiste nadiculdade de criar uma ligao entre elementos abstratos e elementos concretos dentro 16. 1.1 Diculdades para Gerao Automtica de IU 15 Tabela 1.1: Desaos para Construo de IU Baseada em Modelos Nmero Desaos do Desao 1Linguagem Estruturada para descrio de IU 2Problema do Mapeamento 3Processo de Embelezamento 4Especicao do Leiaute 5Informaes dos conceitos do domnio para a construo de IU 6Apoio decomposio de IU 7Separao de preocupaes 8Correlao dos modelos envolvidos 9Integrao de IU com os demais aspectos de SI 10 Integrao de padres de IHC e desenvolvimento de IU baseada emmodelosde um modelo de interfaces. Esse problema resulta da imprecisa compreenso de quaiscaractersticas e atributos dos elementos abstratos governam a criao dessas ligaes[33]. As transformaes de um modelo abstrato para as IU propriamente ditas tmum sucesso limitado, devido diculdade do mapeamento entre os diferentes nveis deabstrao, causada pela falta de compreenso sobre as ligaes entre as caractersticas dosmodelos-origem e dos modelos-destino [56]. Os modelos de apresentao, em geral, apenas esboam o leiaute de IU, eno fornecem recursos sucientes para renar a interface. Esta preocupao emergequando surge a necessidade de lidar com os gostos e preferncias dos usurios, ou paraseguir alguma orientao de estilo, que so preocupaes do processo de embelezamento[38, 72, 52] (desao 3). Outra diculdade para a construo de IU baseada em modelos consiste na es-pecicao de leiaute (desao 4), que considerado um problema complexo [76]. Outrasinformaes, como objetos de dados, seus tipos, domnio dos valores, relacionamentos,restries operacionais, entre outros fatores, tm alguma contribuio para a constituiode IU. Mas estas informaes ainda no tem sido completamente enfatizadas e discutidasantes da modelagem de IU [76, 72] (desao 5). Apoiar a decomposio de IU, disponibilizando os elementos de IU existentespara outros projetos outro desao na construo de IU (desao 6). Com a superaodeste desao sero alcanados benefcios em termos de reusabilidade e produtividadeno desenvolvimento de IU. As atuais tcnicas de modelagem de IU carecem de ummecanismo intuitivo para descrever diretamente a composio e apresentao da interfacecom os conceitos abstratos relacionados [72]. O princpio de separao de preocupaes para a modelagem de um sistema 17. 1.1 Diculdades para Gerao Automtica de IU16(desao 7) representa um desao para a abordagem baseada em modelos, uma vez quea maioria dos conceitos de IHC no pode ser facilmente descrito independentemente deoutros conceitos do domnio do sistema e, geralmente, cada aspecto do sistema tem umimpacto sobre os usurios. Assim, os modelos devem englobar completa e separadamentea estrutura e o comportamento da interface, sem considerar aspectos pertinentes aodomnio da aplicao [27, 72].A prpria complexidade dos modelos tem afetado a usabilidade das abordagensexistentes, causando diculdade para identicar o subconjunto de modelos que se aplicamem cada caso (desao 8). Ainda mais, quanto mais modelos forem aplicados, maior sera correlao entre os modelos, enquanto mantida sua separao. Isto pode resultar nareduo da atratividade e viabilidade da metodologia por completo, j que a aplicaode um certo subconjunto de modelos no garante que todos os detalhes necessrios aofuncionamento do Sistema de Informao sero gerados [72].Mas, ao mesmo tempo que os modelos devem tratar do aspecto de IHC demaneira separada, o desenvolvimento de IU baseado em modelos deve ser integrado aorestante da arquitetura da aplicao (desao 9), para permitir desempenho e escalabilidadeconvenientes, considerando especialmente os requisitos de produtos comerciais [72, 38].Algumas propostas para conciliar as disciplinas de IHC e Engenharia de Soft-ware no contexto do desenvolvimento baseado em modelos tm sido feitas [12, 23], masas ferramentas existentes no so apropriadas para este propsito [37]. Esta lacuna torna-se ainda maior no contexto de SI quando a disciplina de Modelagem de Processo de Neg-cio includa. Assim, integrar a construo de IU ao restante de SI ainda um desao(desao 10).A utilizao de padres de interao juntamente com o desenvolvimento deIU baseado em modelos aumenta a efetividade e produtividade, j que a maioria dasabordagens recentes de Engenharia de Software combinam padres e modelos [21].Mtodos de IHC (Interao Humano- Computador) no tm sido sucientementeutilizados em todo o ciclo de vida do software [37]. Existe uma lacuna entre os conceitose padres de IHC e a gerao automtica de IU. necessria uma descrio mais formalde padres de IHC [60] para que sejam combinados com a transformao automatizadade modelos e gerao de cdigo de IU.Por essas razes, e embora as ferramentas de desenvolvimento de IU baseadasem modelos sejam mais sosticadas que as ferramentas de gerao anteriores, elas no setornaram amplamente populares na indstria de software [37]. Muitos desenvolvedoresainda usam construtores de leiaute, toolkits e linguagens de programao para construirIU para sistemas interativos.Portanto, para compreender e solucionar os desaos envolvidos na construode IU baseada em modelos preciso entender que caractersticas de aparncia e com- 18. 1.2 Objetivos do Trabalho 17portamento esto envolvidas na construo de IU e como representar estas caractersticasem um metamodelo conceitual. Tambm necessrio compreender como construir umcomponente que permita a gerao automtica de IU a partir de tal metamodelo, e em quemomento do ciclo de vida de um software o componente ir atuar. Esses e outros assuntospertinentes a geracao de IU sao tratados no presente trabalho, para um contexto particular:o de Sistemas de Informao (SI).1.2Objetivos do Trabalho O principal objetivo deste trabalho propor uma abordagem baseada em modelospara construo e evoluo de IU para SI. Esta abordagem deve envolver um conjunto demetamodelos para construo de IU e uma arquitetura de um componente de software queauxilie na gerao automatizada. A abordagem proposta supera algumas das limitaes das abordagens atuais,seguindo os princpios da Engenharia de IU baseada em modelos. Aspectos estruturaise tecnolgicos de software, especialmente quanto apresentao das informaes e aocomportamento do SI em resposta interao dos usurios so contemplados nestaabordagem.1.3Contribuies do Trabalho Para alcanar os objetivos propostos, este trabalho contribui com uma compreen-so de como produzir abordagens baseadas em modelos para desenvolvimento de IU.Neste sentido, a partir dos desaos identicados nesta rea de pesquisa, foi gerado umconjunto de requisitos para abordagens de construo de IU baseada em modelos. Foi proposta uma abordagem que atende a estes requisitos por meio de umconjunto de metamodelos para construo de IU e de uma arquitetura de componente desoftware baseada em esteretipos. O desenvolvimento da abordagem proposta originousolues para alguns desaos relacionados Engenharia de IU baseada em modelos,dentre os quais se destacam: A denio de um Metamodelo de IHC que contempla requisitos para a descriode IU no contexto de SI, permitindo a decomposio dos componentes de IU e adescrio dos seus comportamentos [14, 25]; O projeto de um componente de software que implementa uma soluo para oproblema da transformao entre modelo abstrato e componentes concretos de IU[15]; 19. 1.4 Metodologia de Desenvolvimento do Trabalho18 A integrao entre a arquitetura do componente de IU e os demais componentes deSI, relacionando esta abordagem com todo o processo de desenvolvimento de SI[25, 34].Os resultados deste trabalho foram obtidos no contexto de uma macro-arquiteturade framework baseado em modelos para gesto de SI desenvolvida pelo Grupo dePesquisa em Engenharia de Software e Banco de Dados do INF/UFG [2]. A integraodo componente de gerncia de IU, aqui descrito, com os demais componentes daquelaarquitetura pode ser vista em [15, 19].Durante o desenvolvimento do trabalho foram escritos artigos descrevendo re-sultados parciais deste projeto de pesquisa. Um artigo foi publicado no III Workshop deTeses e Dissertaes em Sistemas de Informao [14], dois artigos foram publicados noPrimeiro Workshop Brasileiro de Desenvolvimento de Software Dirigido por Modelos[15, 34], um foi publicado no VIII Encontro Anual de Computao [25], e outro artigofoi aceito para publicao no VII Simpsio Brasileiro de Sistemas de Informao [19].1.4 Metodologia de Desenvolvimento do Trabalho O desenvolvimento desta pesquisa foi baseado em cinco grandes atividades: (1)Fundamentao Terica; (2) Eliciao de Requisitos; (3) Design; (4) Avaliao; e (5)Documentao. As atividades 1 a 4 foram realizadas de forma sequencial, e a atividade 5foi desenvolvida concorrentemente s demais atividades. A Fundamentao Terica envolveu uma reviso de literatura com a nalidade deinvestigar abordagens para gerao automtica de IU. Esta investigao foi fundamentadanas seguintes questes de pesquisa: 1. Quais requisitos devem ser atendidos em uma abordagem de construo de IUbaseada em modelos? 2. Quais so as caractersticas de aparncia e comportamento envolvidas na construode IU para SI? 3. Como representar estas caractersticas em um modelo conceitual? 4. Como construir uma ferramenta que permita a gerao automtica de interfaces deusurio a partir de tal modelo? A partir destas questes, foi realizada a reviso por meio da busca nas basesbibliogrcas da ACM, IEEE e Scopus. Foram encontradas algumas abordagens paraconstruo de IU baseada em modelos, que esto relatados na Seo 2.2. A atividade de Eliciao de Requisitos identicou os requisitos necessriospara a gerao de IU no contexto de SI, denindo os objetivos da abordagem proposta 20. 1.5 Organizao do Trabalho 19neste trabalho. Na busca por resposta primeira questo de pesquisa, foi elaborada umataxonomia de requisitos para abordagens de construo de IU baseada em modelos,apresentada na Seo 2.3. Com base nestes requisitos, foi realizada comparao entreas abordagens identicadas na reviso bibliogrca, discutida na Seo 2.5. Foramdesenvolvidos metamodelos que trazem as caractersticas identicadas pela segunda eterceira questes de pesquisa apresentados no Captulo 3.A atividade de Design especicou o projeto arquitetural e detalhado de umcomponente de software que realiza a gerao de IU para SI, contemplando os requisitosidenticados na atividade anterior. Em resposta quarta questo de pesquisa, no Captulo4 foi especicado um componente de software que gerencia a construo de IU com basena abordagem desenvolvida neste trabalho.A Avaliao da abordagem foi efetuada atravs de uma prova de conceitoenvolvendo a demonstrao da utilizao do componente para a gerao de IU em SI,apresentada no Captulo 5.1.5Organizao do Trabalho Este captulo apresentou os principais conceitos e discutiu os desaos encontra-dos em abordagens de construo baseada em modelos. Tambm foram apresentados osobjetivos, contribuies e a metodologia de desenvolvimento deste trabalho. O Captulo 2 apresenta conceitos fundamentais relacionados construo de IUe, com base nos desaos discutidos no Captulo 1, dene uma srie de requisitos quedevem ser atendidos nestas abordagens para que os desaos citados sejam superados.O captulo tambm compara as abordagens atuais em relao aos requisitos expostos,identicando aqueles que no foram resolvidos. O Captulo 3 descreve os metamodelos desenvolvidos neste trabalho. O Meta-modelo de Domnio descreve os conceitos do negcio. O Metamodelo de IHC introduz oconceito de Esteretipo de Interface e os aspectos de apresentao e de comportamento deIU considerados neste conceito. O captulo tambm apresenta uma extenso do Metamo-delo de Apresentao [17], proposto para trabalhar de forma conjunta com o Metamodelode IHC na gerao automatizada de IU. O Captulo 4 explica a arquitetura de software proposta para a construoautomatizada de IU em SI. So exploradas diferentes vises arquiteturais complementaresque sintetizam a abordagem proposta para gerao de IU para SI. O Captulo 5 discute cenrios que ilustram a utilizao da arquitetura de softwarepara gerncia de IU. O captulo discute a aplicao da abordagem proposta em termos daidenticao de Esteretipos de IU para SI, e da utilizao da arquitetura para construode IU para SI baseada em Esteretipos de IU. 21. 1.5 Organizao do Trabalho20 Finalmente, o Captulo 6 apresenta as consideraes nais deste trabalho depesquisa. So discutidas as contribuies e limitaes do trabalho, bem como uma listade extenses que poderiam melhorar ou complementar os resultados aqui apresentados. 22. CAPTULO 2Desenvolvimento de IU Baseado em Modelos por meio de Interfaces de Usurio (IU) que acontece a interao entre osenvolvidos nos SI. A interao do usurio com a aplicao denida como as aesque tomam lugar entre o ser humano e a interface, na qual esta atua como uma ligaopara comunicao com a funcionalidade do sistema de software subjacente a m derealizar uma tarefa particular [69]. Portanto, no processo de interao existem trs atoresprincipais: o sistema de software (aplicao), o usurio e a interface entre eles.O desenvolvimento de IU compreende, minimamente, a modelagem de aspectosde apresentao e de comportamento da interface. A modelagem de apresentao corres-ponde descrio da aparncia das informaes da aplicao, e de como elas so apre-sentadas para o usurio. Este aspecto depende diretamente das informaes que seromanipuladas por meio da interface.J a modelagem de aspectos de comportamento consiste na descrio da formapela qual a interface responde s interaes do usurio com a aplicao. O comportamentoda interface inuenciado pelo tipo de aplicao manipulado. Espera-se, por exemplo,que aplicaes do mesmo tipo tenham comportamentos similares.Este captulo discute os avanos j obtidos e as limitaes atuais das abordagenspara gerao de IU baseada em modelos. Para isso, so analisados: (i) os conceitosfundamentais da Engenharia de IU; (ii) os desaos para a construo de IU baseada emmodelos; e (iii) os requisitos que devem ser encontrados em abordagens de construode IU baseada em modelos para SI. O captulo apresenta, ainda, uma comparao entreabordagens para construo de IU encontradas na literatura.2.1 Engenharia de Interfaces de Usurio A necessidade de automatizar a construo de IU e de ter uma metodologia paraseu desenvolvimento durante todo o ciclo de vida de SI, considerando os tradicionaisconceitos de Engenharia de Software, levou ao surgimento da Engenharia de Interfaces deUsurio [73]. Esta engenharia uma disciplina que pesquisa e desenvolve solues para osdesaos emergentes na modelagem de IU baseada em modelos, tais como a complexidade 23. 2.1 Engenharia de Interfaces de Usurio 22dos dispositivos e estilos de interao, a multiplicidade de ambientes de trabalho, adiversidade de contextos de uso, e a heterogeneidade de arquiteturas de software. O conhecimento gerado por esta disciplina, situada na interseco entre as dis-ciplinas de Engenharia de Software, Interao Homem-Computador e Fatores Humanos,est voltado, principalmente, para a pesquisa de metodologias para desenvolver IU, con-siderando todo o ciclo de vida do software [73]. A Engenharia de IU busca o desenvolvimento de metodologias que contemplemuma srie de modelos que representam as diferentes facetas de IU [74]. A abordagem baseada em modelos foi introduzida para apoiar a especicaoe design de sistemas interativos em um nvel semntico, conceitual e abstrato, comouma alternativa para lidar com questes de baixo nvel de implementao no comeodo ciclo de vida de desenvolvimento [1]. Os modelos se tornam artefatos vivos queservem como entrada para ferramentas de gerao de cdigo, diminuindo o esforo dosdesenvolvedores. No entanto, o emprego desta abordagem requer uma linguagem para especicarmodelos, denindo transformaes e descrevendo metamodelos. O uso de modelos per-mite aos desenvolvedores manter e desenvolver componentes complexos encapsuladosem modelos e mapeamentos, simplicando, assim, o processo de desenvolvimento [4]. As bases da Engenharia de IU baseadas em modelos so estabelecidas peloframework de referncia CAMELEON (Context Aware Modelling for Enabling andLeveraging Effective interactiON) [9], que cobre tanto o tempo de design como o tempode execuo de IU multi-plataforma, provendo uma estrutura conceitual que apoia odesenvolvimento de IU para uma ampla variedade de dispositivos computacionais. O framework de referncia CAMELEON foi proposto como uma abordagempara desenvolvimento de IU multi-contexto, com uma estrutura conceitual que decompeo desenvolvimento de IU em quatro passos, resumidos na Figura 2.1. 1. Modelagem de tarefas e conceitos: descreve as tarefas de usurio e os conceitos dedomnio, da forma como so requeridos pelas tarefas a serem realizadas. 2. Modelagem de Interface de Usurio abstrata: dene os componentes abstratosindividuais e agrupadores, o esquema de navegao, e os objetos de interaoabstrata. 3. Modelagem de Interface de Usurio concreta: realiza uma interface de usurioabstrata em um contexto de uso com base em objetos concretos de interao. Apesarde denir o leiaute dos widgets e a navegao da interface, o modelo concreto ainda um prottipo da interface de usurio. 4. Construo da Interface de Usurio nal: cria a interface de usurio, ou seja, aquelaque executada em um ambiente especco. 24. 2.1 Engenharia de Interfaces de Usurio 23Figura 2.1: Engenharia de IU Dirigida por Modelos (adaptada de[5])A Modelagem de Tarefas e Conceitos envolve a descrio das tarefas de usurioe os conceitos orientados ao domnio requeridos para a realizao das tarefas. Para isto, necessrio produzir um modelo de tarefas e um modelo de domnio.Para modelar o domnio necessrio descrever as classes de objetos manipuladaspelos usurios enquanto interagem com o sistema. Tipicamente so utilizados diagramasde classes da UML, modelo entidade-relacionamento ou um modelo orientado a objetos.A modelagem de tarefas de usurio uma tcnica bem compreendida e ampla-mente aceita nas atividades do design de IU centrado no usurio [74, 50, 61]. Ela envolvea descrio das tarefas que o usurio deve desempenhar a m de alcanar um objetivoquando interage com um sistema computacional, e o relacionamento entre estas tarefas.Tipicamente elas so decompostas em uma hierarquia de tarefas. Tarefas que so sujeitasa outras tarefas so consideradas tarefas dependentes, e aquelas que no tem uma conexoimediata com outras tarefas so tarefas independentes [64]. Muitos modelos de tarefas tmsido propostos na literatura e alguns dos principais modelos so descritos e comparadosem [32].Os demais passos Modelagem da Interface de Usurio Abstrata, Modelagemda Interface de Usurio Concreta e Construo de Interface de Usurio Final envolvema modelagem de IU e os passos para a sua construo.A abordagem da construo de IU baseada em modelos apresenta vantagenssignicativas com relao abordagem de mapeamento manual de necessidades de IUpara linguagens de programao. O uso de modelos de alto nvel de abstrao permiterepresentar de forma mais clara os requisitos dos usurios com relao s IU. A facilidadeem modelar interfaces por no especialistas motiva o uso de modelos, alm de permitirque designers sejam capazes de focar mais em aspectos de IHC e menos em detalhes de 25. 2.2 Abordagens para construo de IU baseada em modelos24implementao [4].2.2 Abordagens para construo de IU baseada em mo-delosExistem diferentes abordagens para modelagem de IU encontradas na literatura[59, 10, 16, 69, 76, 41]. Nos ltimos anos muitos esforos tm sido realizados paradesenvolver abordagens baseada em modelos para automatizar a construo de IU [54,26, 42, 5, 22, 17, 36, 8, 20, 37, 43, 65, 31].No entanto, a falta de consenso sobre os modelos mais adequados para descreverIU tem sido uma barreira para o uso intensivo de Engenharia de IU. Nenhum mtodo temrealmente emergido como uma referncia para a criao do software de IU [72, 1].Essa falta de consenso pode ser explicada pela ausncia de padres universais deIHC, mas tambm porque as intenes e os objetivos das IU podem variar largamente deuma aplicao interativa para outra.Existem vrios mtodos que instanciam um modelo de interao para representarIU para plataformas especcas. Como consequncia, a migrao para outras plataforma uma tarefa difcil. USIXML [33] e UMLi [16] denem a interao de maneira abstrata.Porm, estas abordagens conseguem denir apenas IU genricas, e no esto integradasem um processo de gerao de cdigo completo. Assim, elas deveriam especicar comoa interface de usurio apropriadamente conectada funcionalidade do sistema [69].Os desaos de modelagem de interao fomentaram a criao de uma multiplici-dade de linguagens de padres de IHC [70, 71, 23, 44, 7, 68]. No entanto, estas linguagensno so mutuamente compatveis. Faltam descries precisas dos elementos de interaoe de como eles devem se comportar em uma implementao da soluo [40].Especialistas de IHC, do domnio da aplicao, e de engenharia de softwaredeveriam poder expressar suas habilidades na forma de padres, j que a comunicaoem equipes interdisciplinares um dos principais desaos dos praticantes de IHC [40].A unio dos conceitos de padro de interao com os de descrio de IU, permiteformar padres concretos de interao [37]. A Biblioteca de Padres para Design deInterao, apresentada em [70], identica contextos de design, necessidades do usurioe da aplicao. J em [44] so denidos quinze Padres de Layout de Tela para RIA (RichInternet Applications). 26. 2.3 Requisitos para Construo de IU em SI252.3Requisitos para Construo de IU em SI Uma descrio de IU em alto nvel realizada de maneira adequada com ummetamodelo de IU que especique as caractersticas essenciais para o projeto de IHC.Um metamodelo de IU (ou de IHC) deveria contemplar [45]: Um conjunto de termos precisamente denidos sobre IHC; Denies estruturadas da aplicao de conceitos de IHC para a criao de mode-los; Alta expressividade, permitindo descrever cada aspecto da interao; Coerncia e interoperabilidade do resultado da modelagem; Independncia de tecnologias e de formas de armazenamento; Escalabilidade, oferecendo meios de denio de diferentes nveis de abstrao. Um aspecto importante para um metamodelo a sua capacidade de incorporarpadres de projeto, ou seja, solues provadas para problemas recorrentes. Padres deprojeto de interao focam na soluo de problemas de usabilidade dos sistemas. Essespadres se correlacionam e se complementam, formando um acervo de boas prticas deinterao que podem ser aplicadas em diversos projetos de IU de forma consistente [45]. Com base nestas propriedades, e nas diculdades citadas na Seo 1.1, possvelidenticar um conjunto de requisitos para abordagens de construo de IU baseada emmodelos para SI [72, 45, 35, 76, 38, 51, 60]. Estes requisitos foram organizados em umataxonomia de Requisitos para Abordagens de Construo de IU Baseadas em Modelos,que apresentada na Figura 2.2.Figura 2.2: Requisitos para Abordagens de Construo de IUbaseada em ModelosOs requisitos foram divididos em cinco classes relacionadas ao desenvolvimentode interfaces baseado em modelos: Organizao, Decomposio, Mapeamento, Abstraoe Conformidade. 27. 2.3 Requisitos para Construo de IU em SI262.3.1 Requisitos de Organizao A classe de requisitos Organizao agrupa os requisitos associados organizaoda construo de IU, e suas caractersticas so Embelezamento, Composio e Separao. O requisito de Embelezamento diz respeito ao apoio que a abordagem deconstruo de IU deve oferecer para que as IU geradas sejam embelezadas e renadasao longo do ciclo de vida. O embelezamento envolve detalhes de aparncia da interface, como o tipo etamanho da fonte, cor de fundo, imagens de cones, posicionamento dos componentes,entre outros detalhes relacionados esttica de IU. A Composio diz respeito ao agrupamento de elementos no leiaute da inter-face. A disposio dos elementos na interface depende da importncia de cada um doselementos e de caractersticas de usabilidade. A construo de IU envolve os conceitos do domnio da aplicao, porm estaspreocupaes devem ser consideradas de maneira separada. Esta Separao favorece amanuteno dos conceitos do negcio e das IU de forma isolada.2.3.2 Requisitos de Decomposio A classe de requisitos Decomposio rene as seguintes caractersticas rela-cionadas subdiviso dos componentes de IU: Propsito, Agrupamento e Padronizao. Existem IU com diferentes propsitos, e ter uma biblioteca onde esto identica-dos alguns dos Propsitos recorrentes de IU pode auxiliar na produtividade da construode IU. Um dos propsitos mais utilizados em SI so as IU do tipo CRUD (Create, Read,Update, Delete), empregadas para a manipulao de informaes do negcio. O conceito de elemento dominante, aquele que faz o Agrupamento de elementossimples para a formao de elementos mais complexos, pode solucionar problemasrecorrentes nas IU. Elementos isolados no tem um propsito para utilizao, contudo,reunidos com um objetivo eles se tornam reutiliveis em outros contextos semelhantes,favorecendo a produtividade na construo de IU e promovendo a Padronizao daaparncia e do comportamento das IU.2.3.3 Requisitos de Mapeamento A classe de requisitos Mapeamento diz respeito aos requisitos necessrios para atransformao de modelos para a construo automatizada de IU. Clareza, Flexibilidadee Direo so caractersticas desta propriedade. Para que os modelos sejam utilizados com ecincia, as regras de transformaodevem ser especicadas de forma clara e precisa entre o metamodelo abstrato e sua 28. 2.4 Correlao entre Desaos e Requisitos para abordagens de Construo de IU 27especicao concreta. Alm disso, alguns componentes abstratos podem ter mais de ummapeamento para elementos concretos, e deve-se possibilitar a Flexibilidade de congurareste mapeamento.A Direo observada quando os mapeamentos so realizados da maneiraadequada, de uma representao mais abstrata para uma mais concreta.2.3.4 Requisitos de Abstrao A classe de requisitos Abstrao apresenta as caractersticas esperadas para queuma abordagem seja independente de uma tecnologia especca. O requisito de Generalidade est relacionado com a manuteno de um alto nvelde abstrao e generalidade nos modelos empregados para especicao de IU, o quetorna esta especicao independente de tecnologia. O requisito de Estrutura deve ser observado pela especicao estruturada demeta-caractersticas para construo de IU. Dessa forma, as abordagens para construode IU deveriam oferecer um conjunto de termos precisamente denidos sobre IHC,abrangendo conceitos de apresentao e comportamento de IU.2.3.5 Requisitos de ConformidadeA classe de requisitos Conformidade diz respeito a construir as IU de acordocom a necessidade das aplicaes. Para isto, as caractersticas de Contextualizao eCorrelao so esperadas.A Correlao envolve a associao entre as funcionalidades e conceitos donegcio com a especicao da interface, de modo que seja possvel compreender quaisconceitos e funcionalidades do negcio devem estar presentes na interface de usurio.A Contextualizao tem a preocupao de apresentar a interface de formaadequada ao domnio das informaes do negcio, seus tipos e relacionamentos.2.4Correlao entre Desaos e Requisitos para aborda- gens de Construo de IU Os desaos identicados na Seo 1.1 guiaram o desenvolvimento dos requisitospara abordagens de construo de IU baseada em modelos, apresentados na Seo 2.3. O Desao 1, relacionado a necessidade de ter uma linguagem estruturada paradescrio de IU, est relacionado com o requisito Estrutura, da Classe Abstrao, queprev uma descrio estruturada das meta-caractersticas para construo de IU. 29. 2.5 Comparao entre abordagens 28O Desao 2, que diz respeito ao problema do mapeamento entre modelos, estrelacionado com os requisitos da classe Mapeamento: Clareza, Flexibilidade e Direo.A presena destes requisitos possibilitam o mapeamento adequado na aplicao deabordagens de construo de IU baseada em modelos.O Desao 3 considera o embelezamento das IU, e ele considerado pelo req-uisito de Embelezamento da classe Organizao. O Desao 4, que corresponde a especi-cao do leiaute, relacionado com o requisito de Composio da classe Organizao,que preocupa-se com a disposio dos elementos nas IU.O Desao 5, relacionado as informaes do domnio da aplicao consideradaspara a construo de IU, est relacionado pelo requisito de Contextualizao da classeConformidade, que prev que estas informaes de domnio devem ser consideradas deforma separada na construo de IU.O Desao 6, que corresponde ao apoio decomposio de IU, consideradopela classe Decomposio, composta pelos requisitos de Propsito, Agrupamento ePadronizao. O Desao 7 considera a separao de preocupaes, e est relacionadocom o requisito Separao da classe Organizao.O Desao 8 compreende a correlao entre os modelos envolvidos na abor-dagem. Este desao relacionado ao requisito de Correlao da classe Conformidade.A integrao entre os demais aspectos envolvidos na construo de SI, que o Desao 9,est relacionado com a classe de Conformidade.O Desao 10, que corresponde a integrao de padres de IHC e o desenvolvi-mento de IU baseado em modelos, considerado pelo requisito de Generalidade da classeAbstrao. Deste modo, para que padres de IHC sejam agregados ao desenvolvimento deIU baseado em modelos, necessrio considerar os modelos independentes de tecnologiacom os padres de IHC, que tambm so abstrados de forma genrica. Esta agregaopossibilita reutilizao de padres e qualidade nas IU geradas automaticamente.2.5 Comparao entre abordagens Na busca por abordagens para construo de IU baseada em modelos recentes(2007 2010), que possuem maior subconjunto de requisitos para o contexto de SI, foramselecionados alguns trabalhos relevantes, baseando-se nos seguintes critrios: ser umaabordagem baseada em modelos, ser aplicvel a IU WIMP (windows, icons, menus andpointers), e ter uma implementao da proposta. A seguir, so analisadas as abordagensde construo de IU, de forma semelhante ao trabalho de [35]. A Tabela 2.1 apresenta a comparao das abordagens em relao aos requisitosapresentados na Seo 2.3. Os campos preenchidos com ++ indicam que o critrioem questo foi totalmente atendido na abordagem, isto , houve preocupao em exibir 30. 2.5 Comparao entre abordagens 29o requisito na abordagem. Os campos preenchidos com + apontam que o critrioem discusso foi atendido de forma parcial, ou seja, algumas partes do requisito soatendidas. J os campos preenchidos com - indicam que o critrio no foi atendidopela abordagem, isto , o requisito ausente na abordagem, ou na descrio dela. Tabela 2.1: Comparao entre as Abordagens para Construo de IU Baseada em Modelos Requisitos para Malai Metamodelo GDIG Modelo Metamodelo Abordagem Abordagens de [5] Conceitual [17] Abstrato de para Apli- baseada Construo de de Discurso Interaocaes Web em IMML IU[22, 55][69] [8] [13] Embelezamento - ---+ - (Organizao) Composio+ -+-+++ (Organizao) Separao (Or- +-+-- ++ ganizao) Propsito (De- ++ ++ +++ + ++ composio) Agrupamento - -++ +++++ (Decomposio) Padronizao+++++++++ (Decomposio) Clareza (Mapea- ++---++++ mento) Flexibilidade - -+++ + (Mapeamento) Direo (Mapea- - ---+ ++ mento) Generalidade++++ +++ ++++ (Abstrao) Estrutura (Abs- - ++ ++ -++++ trao) Contextualizao +-++ ++ + (Conformidade) Correlao- -+-+ ++ (Conformidade)Legenda: -: No atendido; +: Parcialmente Atendido; ++: Totalmente atendido Entre os metamodelos citados, se destacam o Metamodelo de Aplicaes Webe a Abordagem baseada em IMML, por atenderem a um maior nmero de requisitos. OMalai [5] o mais aderente ao CAMELEON. No Metamodelo Conceitual de Discurso[22, 6, 55] nota-se maior poder de expresso em termos de interao, visto que o uso deatos comunicativos torna esta iniciativa mais prxima da comunicao humana. 31. 2.5 Comparao entre abordagens30O Modelo Abstrato de Interao [69] o mais abrangente em termos de deniode taxonomia para as formas de interao. J o Metamodelo de Interface [17] maisrestrito em seu objetivo, mas apresenta uma ferramenta para gerao automtica de IU.As interfaces geradas so integradas, embora no acopladas, ao restante do cdigo de SI.O Modelo de Domnio e de Interao [13] relaciona a lgica de negcio interface, emostra a aplicao de regras de transformao para a gerao de IU.Como mostra a Tabela 2.1, Malai e o Modelo Abstrato de Interao no fornecemuma denio estruturada dos conceitos, dicultando a compreenso do relacionamentoentre os padres de interao e da forma como estes so aplicados, pois o metamodelo descrito apenas textualmente.O conceito de elemento dominante, sendo um auxlio para a organizao doselementos na interface bem como dos comportamentos esperados, no previsto noMetamodelo Conceitual de Discurso, nem no Malai. O Modelo Abstrato de Interaoutiliza parcialmente este conceito, j que ele empregado apenas para o aspecto deapresentao da interface. Na abordagem baseada em IMML, o conceito de elementodominante aparece apenas em nvel concreto, onde so produzidos templates para aproduo do cdigo nal.Alm disso, no h preocupao com a separao da descrio dos elementosde IU com os conceitos da lgica de negcio no Modelo Abstrato de Interao, noMetamodelo Conceitual de Discurso e no Metamodelo de Aplicao Web. Eles tambmno correlacionam a modelagem da interface com a lgica de negcio e preocupam-separcialmente com o formato e tipos de dados do negcio. Isto torna o desenvolvimento deIU isolado do restante do desenvolvimento da aplicao.A preocupao com o renamento da interface, bem como com aspectos deestilo, so propriedades que so deixadas em segundo plano, ou ainda ignoradas pelosmetamodelos aqui discutidos. No fcil alterar o comportamento e a aparncia dainterface modelada, mas isto faz com que o processo de manuteno seja caro e propensoa erros.Com o Metamodelo de Interface possvel gerar apenas um tipo de interface(CRUD). Tambm no Metamodelo de Aplicao Web podem ser construdos apenasalguns esteretipos: formulrio, pesquisa, lista e mestre-detalhe.O Metamodelo de Discurso traz conceitos interessantes de comunicao, masno o suciente para expressar como o sistema computacional ir se comportar aps ainterao com o usurio. A abordagem baseada em IMML interessante nesse sentido,pois dene um conjunto de estruturas de interao, que organizam as aes executadaspelo usurio.O Metamodelo de Aplicao Web o nico que no auxilia a especicao docomportamento. Os demais metamodelos, com exceo do Metamodelo de Interface, so 32. 2.5 Comparao entre abordagens 31baseados em mquina de estados nita para a especicao dos aspectos comportamentaisda interface. Apesar de existirem muitas iniciativas para construo de IU baseada em mode-los, no h consenso sobre qual metamodelo melhor representa as caractersticas de IU.Neste captulo foram extradas caractersticas de qualidade para metamodelos de IU nocontexto de SI, reunindo primitivas de modelagem apresentadas em diferentes trabalhos. Aps a anlise da Tabela 2.1, conclui-se que os trabalhos existentes no atendempor completo as caractersticas de qualidade identicadas. Esta avaliao motivou adenio de uma nova abordagem com um conjunto de metamodelos que busquematender a estes requisitos de qualidade. O conjunto de metamodelos produzidos para estaabordagem apresentado no prximo captulo. 33. CAPTULO 3Metamodelos para IUUm metamodelo dene uma linguagem de modelagem para escrever modelos dedeterminado domnio. Os trs metamodelos apresentados neste captudo foram projetadospara atender aos requisitos para construo de IU em SI apresentados no Captulo 2.O Metamodelo de Domnio (Seo 3.1) descreve os dados do negcio e as regrasassociadas, que sero aplicadas pelo Sistema de Informao.O conceito de Esteretipo de Interface, introduzido no Metamodelo de IHC(Seo 3.2), possibilita a modelagem de IU em um nvel abstrato, facilitando sua reu-tilizao em uma ampla gama de SI.J o Metamodelo de Apresentao (Seo 3.3) permite a descrio de IU emum nvel concreto. Ele estende a proposta de [17], trabalhando em conjunto com oMetamodelo de IHC na gerao automatizada de IU.3.1Metamodelo de Domnio Um Sistema de Informao pode ser descrito por um conjunto de metadadosde contexto de negcio. O Metamodelo de Domnio de Negcio, proposto em [15],representa esses metadados, possibilitando a descrio dos conceitos do negcio. OMetamodelo apresentado na Figura 3.1 uma extenso do Modelo de Meta-ObjetosComplexos [17], que por sua vez, uma extenso do Modelo Entidade-Relacionamento. Os principais construtores do Metamodelo de Domnio denem tipos especcosde Elementos de Negcio: Entidade, Entidade Fraca, Consulta e Relacionamento. Uma Entidade descreve um conceito de negcio de um Sistema de Informao.Uma Entidade Fraca um conceito do negcio que depende de um relacionamento comoutros conceitos para ser identicado. Um Relacionamento representa a associao de dois elementos de negcio,independente de sua natureza; por exemplo, possvel associar dois Relacionamentos,distintos ou no. Dentro de um Relacionamento, cada elemento de negcio associadodeve ter um Papel. 34. 3.1 Metamodelo de Domnio33 Figura 3.1: Metamodelo de Domnio (adaptado de [15]) Uma Consulta representa uma viso de uma combinao de determinados ele-mentos de negcio, com um subconjunto de seus atributos, sendo equivalente ao conceitode Viso do modelo Relacional de dados. Este tipo de construtor permite a criao e oacesso a dados derivados no contexto de SI. Elementos do Negcio podem especializar-se em outros elementos. Por exemplo,uma entidade pode se especializar em outra entidade, conforme o conceito de Heranada Orientao a Objetos. A especializao de elementos permite a identicao desubconjuntos de elementos que so de interesse para os SI. Regras de Negcio so denidas sobre um Elemento do Negcio. Existemmecanismos especcos que abordam a construo destas regras, que podem referenciardiversos Elementos do Negcio a partir de um elemento base sobre o qual a regra denida [2]. Todo Elemento do Negcio possui um nmero arbitrrio de Atributos, os quaispossuem as seguintes propriedades: mnemnico, que identica o atributo; cardinalidade 35. 3.1 Metamodelo de Domnio34mnima e mxima, que representa, respectivamente, o nmero mnimo e mximo devalores que o atributo pode ter; ehParteChave, que indica se o atributo faz parte dacomposio de algum atributo identicador do Elemento de Negcio; ehUnico, quedetermina se o atributo um identicador, ou seja, no pode haver dois valores iguaispara este atributo no mesmo Elemento de Negcio. O Metamodelo de Domnio dene uma taxonomia para os Atributos de Elemen-tos do Negcio: Composto, representa uma agregao de atributos. Alfanumrico, representa informaes textuais. Tem como propriedade o tamanho mximo do texto e um valor default (opcional). Binrio, representa informaes de arquivos binrios. Tem como propriedades extenso (tipo do arquivo), aplicativo (indica qual aplicativo tem a preferncia para abrir o binrio) e plataforma (determina a plataforma necessria para abrir o binrio). Data, representa dados temporais. Tem como propriedades valor default opcional, menor valor e maior valor. Numrico, representa informaes numricas. Tem como propriedade: menor valor, maior valor, valor default, preciso e tamanho mximo. Atravs da pro- priedade preciso pode-se identicar se o atributo numrico inteiro (preciso igual a 0) ou real (preciso maior que 0). Enumerado, representa informaes que assumem valores discretos. Um atributo Enumerado deve estar associado a um Domnio Enumerado, que dene o conjunto de Valores Enumerados. A utilizao destes conceitos facilita a reutilizao de domnios enumerados por todas as aplicaes de SI. Por exemplo, pode existir mais de um atributo que empregue o mesmo domnio enumerado. Os valores enumerados devem ter a propriedade valor, que armazena o contedo do valor enumerado. Para exemplicar o uso do Metamodelo de Domnio, considere o Elementode Negcio Pessoa, presente em inmeros SI. Esse elemento pode ser representadocomo uma Entidade Pessoa, conforme mostra a Figura 3.2. Neste exemplo, a entidadepossui os seguintes atributos (com seus respectivos domnios): Nome (alfanumrico), CPF(numrico), Data de Nascimento (data), Idade (numrico), Naturalidade (composto) que composto por Estado (enumerado) e Cidade (enumerado). A regra Valida Pessoa denida sobre a entidade pessoa, sendo uma regra quevalida os atributos da entidade Pessoa. Por exemplo, um dos itens vericados por estaregra poderia ser a consistncia entre a cidade e o respectivo estado no atributo compostoNaturalidade. O Metamodelo de Domnio representa a descrio dos conceitos do negcio quesero maninpulados no Sistema de Informao atravs da interface de usurio. Porm, 36. 3.2 Metamodelo de IHC35Figura 3.2: Exemplo de Aplicao do Metamodelo de Domnionecessrio considerar como estas informaes sero apresentadas na interface, e qual areao da interface para cada ao do usurio. Dete modo, a prxima seo apresenta ummetamodelo que considera estas questes para a representao dos conceitos de negcioem IU de SI.3.2 Metamodelo de IHC O objetivo do Metamodelo de IHC descrever as caractersticas de apresentaoe comportamento de IU para SI em nvel abstrato. Estas IU so baseadas em cones,menus, ponteiros e janelas (WIMP, do ingls Windows, Icons, Menus and Pointers), fazemuso intensivo de informaes estruturadas armazenadas em bancos de dados, e organizamas tarefas relacionadas aos processos de negcio de forma que faam sentido para osusurios [63]. O escopo de aplicao desse metamodelo abrange um vasto conjunto de apli-caes de SI. No entanto, este escopo restrito o suciente para ser adequadamente repre-sentado por um nico Metamodelo de IHC, descrevendo de forma integrada os aspectosde aparncia e comportamento das IU. Estes dois aspectos so tradados por componentes separados dentro do meta-modelo, no intuito de isolar as propriedades de cada aspecto, mas so integrados comoum nico metamodelo para que seja explcita a maneira pela qual ambos os aspectos secorrelacionam, representando IU complexas no mbito de SI. O metamodelo proposto especica IU em alto nvel de abstrao e generalidade,integrando conceitos e padres j consolidados pela comunidade de IHC, a m de 37. 3.2 Metamodelo de IHC36proporcionar a gerao automtica do cdigo de IU. A Figura 3.3 exibe a estrutura doMetamodelo de IHC para especicao de IU. O pacote Apresentao representa osaspectos de aparncia de IU; no pacote Comportamento esto os metadados que permitemrepresentar as aes em IU. O pacote Esteretipo de Interface rene os metadadosenvolvidos para integrar este conceito com a apresentao e comportamento de IU. O conceito-chave do Metamodelo de IHC o de Esteretipo de Interface, ousimplesmente Esteretipo, que consiste em uma abstrao da inteno da interface, inde-pendente da aplicao ou do Sistema de Informao subjacente. Assim, cada esteretipo um elemento dominante de interface, organizando a apresentao dos elementos sub-ordinados e seus respectivos comportamentos. A denio estrutural da composio dos esteretipos est baseada em umataxonomia para elementos abstratos de interface de usurio. Essa taxonomia correspondeao Aspecto de Apresentao do metamodelo. O comportamento dos esteretipos denido com base em um mecanismo paraespecicao de aes associadas a eventos de interface, representando o Aspecto deComportamento do metamodelo. A ligao entre o comportamento e os elementos de interface, que formamum esteretipo, representada atravs das correlaes entre eventos capturados peloselementos de apresentao e aes que descrevem o comportamento de reao ao evento. A taxonomia de elementos de interface permite a especicao conceitual de IU,independentemente dos objetos reais de interao. Para cada elemento dessa taxonomiaso denidos padres de interao tpicos, baseados na literatura de IHC [69, 55, 70, 44].Assim, cada elemento de interface tem um comportamento esperado, que pode serestendido a partir da associao do elemento a cada esteretipo de interface.3.2.1Aspecto de Apresentao de IHC Para cada interface, determinado conceito de negcio de SI deve ser apresentadocom um propsito especco. Um Elemento de Interao (ou Elemento de IHC), umconstrutor que descreve o tipo de elemento de interface utilizado para a comunicao entreo sistema e o usurio. A taxonomia denida para os Elementos de Interao possibilita a reutilizaodesses elementos entre diversas aplicaes de SI, uma vez que estes elementos so umadenio genrica de que tipo de comunicao pode ser realizada na interface. Um Elemento de Interao do tipo Agrupador representa uma composio deelementos de interao. Esses elementos complexos auxiliam na organizao estrutural dainterface, bem como no agrupamento de informaes relacionadas, a m de que o usuriopossa perceber melhor o contexto da informao. 38. 3.2 Metamodelo de IHC 37Figura 3.3: Metamodelo de IHC 39. 3.2 Metamodelo de IHC38 Um Elemento de Interao do tipo Bsico encapsula uma unidade essencial decomunicao do sistema com o usurio, da mesma forma que ocorre no conceito de atoscomunicativos [22]. Elementos Bsicos se dividem em dois tipos: Questo e Informao. Um componente bsico do tipo Informao um elemento que deve apenasapresentar contedo informativo ao usurio. Conforme conceitos do Modelo Abstratode Interao [69], as informaes podem ser classicadas como Texto, apenas para nsde conhecimento do usurio; Populao, consistindo em um conjunto de instncias dedeterminado conceito do negcio; Servio, que executa uma funcionalidade; Visual,querepresenta imagens ou vdeos; ou Feedback, apresentando a resposta do sistema a umainterao do usurio. Por exemplo, um elemento de negcio Notcia uma informao do tipo Texto.Um conjunto de Notcias forma uma informao do tipo Populao. Um boto com ortulo Salvar uma informao do tipo servio, pois comunica ao usurio que interagircom este elemento conduzir o sistema a executar a ao Salvar. Uma gura ou fotoexibida na interface um tipo de informao visual. Um exemplo de informao do tipofeedback uma caixa de alerta exibida ao usurio, noticando uma resposta do sistema alguma ao do usurio. Uma Questo um elemento que comunica ao usurio um questionamento querequer uma resposta (interao) do usurio, que pode ser uma edio ou uma inserode dados. Assim, um elemento questo deve conter uma identicao dos dados a seremmanipulados pelo usurio (rtulo) e um espao para manipulao dos valores dos dados,denido conforme o domnio da informao especicado no contexto de negcio. Aresposta deve pertencer a este mesmo domnio de informao, que pode ser, conformea taxonomia denida em [69]: enumerado, alfanumrico, numrico, data ou binrio. Uma Questo pode ser de dois tipos: Aberta ou Fechada. Uma questo per-tencente ao domnio Enumerado uma Questo Fechada, pela qual o usurio escolheruma resposta dentre os dados desse domnio apresentados na interface. Questes que per-tencem aos demais domnios (alfanumrico, numrico, data e binrio) so do tipo Aberta. Ambos os tipos de questo necessitam da informao de cardinalidade, presenteno Metamodelo de Domnio, para que seja disponibilizado espao adequado para ousurio responder questo na interface. A cardinalidade de uma questo um par de nmeros inteiros que dene aquantidade mnima e mxima de dados que o usurio deve fornecer. Se a cardinalidademnima for igual a zero, ento a resposta da questo no obrigatria. Se a cardinalidademxima for maior que um, ento necessrio um elemento do tipo agrupador queorganize o espao adequado para que seja permitido ao usurio entrar com a quantidadede informao necessria. Os componentes especcos para a interface que representaro cada tipo de 40. 3.2 Metamodelo de IHC39questo devem ser denidos em nvel concreto, no Metamodelo de Apresentao, con-forme discute a Seo 3.3.3.2.2Aspecto de Comportamento de IHCDentre as diferentes formas de descrever a interao do usurio, os modelosbaseados em Mquina de Estados so muito empregados, e podem ser derivados domodelo de discurso [28]. O Metamodelo de IHC contm a especicao de uma mquinade estados nita para descrever a interao, ou seja, a forma de reao da interface emresposta interao do usurio. Por meio do conceito de Elemento de IHC, pode serenumerado um conjunto de eventos de elemento para o Esteretipo. Cada um deles irdisparar uma ao.Um evento consiste em uma ao que ocorre na interface em determinadoelemento de interao, podendo provir tanto do usurio como do sistema. Estes Eventosde Elemento, uma vez ocorridos, devem disparar a execuo de uma Ao.Dentre os possveis Eventos de Usurio existem eventos de Entrada de Dados,relacionados aos elementos do tipo questo do aspecto de apresentao; de Navegao,que so eventos relacionados a elementos de servio que possibilitam alterar o estadoda interface; e de Solicitao, que so eventos relacionados a elementos de servio queacionam aes externas.A ocorrncia de um evento de elemento no Esteretipo caracteriza uma intera-o. As interaes ocorrem em um Estado, que consiste em um conjunto de propriedadesdo sistema perceptveis para o usurio. Conforme o Estado em que a interface se encon-tra, haver um conjunto de Eventos que so de interesse do Esteretipo.Um estado deve ter uma identicao e, dentro de um Esteretipo, um nicoestado deve ser identicado como estado inicial da interface. O fato de o Esteretipoter estados e, durante sua execuo estar em um estado, permite que a interface seja quasimodal, para prevenir o erro do usurio. Quasi modal um estado no qual o usurio precisafazer alguma ao fsica constante, a m de manter o sistema naquele estado, de modoque no se esquea que a interface est naquele modo. Um exemplo o uso da tecla shiftdo teclado [57].O metamodelo permite denir um conjunto de Eventos de Elemento, que sopredenidos para cada Elemento de Interao.Eventos podem ocasionar a transio de um estado para outro. Para cada estadodeve haver um conjunto de comportamentos em resposta aos eventos de usurio. Dada aocorrncia de um evento, vericado se o evento de interesse no estado corrente. Casoseja, acionado um comportamento atravs da ao habilitada para aquela interao noestado corrente. 41. 3.2 Metamodelo de IHC40Dada a ocorrncia de um evento em certo estado, seu comportamento executadovia Ao. Para cada evento de elemento (ou evento estereotipado, apresentado na Seo3.2.3) em um estado, deve haver uma ao correspondente. Uma Ao consiste em umconjunto de comandos, restringidos por condies, que devem ser executados a partir domomento em que um evento observado.As aes caracterizam o comportamento executado aps uma interao dousurio. Elas podem ser de Interface ou Externa. A primeira executada pela interface,uma vez que sua execuo no necessita do conhecimento da aplicao ou de outrosistema externo. Dois tipos notveis de ao de interface so as aes de navegao, querealizam a transio entre interfaces, e a aes de transio de estados, que possibilitam apassagem de um estado para outro em uma mesma interface.As aes externas so aquelas implementadas pela aplicao subjacente ou poroutro sistema externo, mas so especicadas na modelagem de IU. Como as aes exter-nas so especicadas de forma isolada do comportamento de interface, estas podem serreutilizadas sempre que necessrio. Por exemplo, uma ao que possibilita a consulta deum determinado tipo de informao do negcio pode ser utilizada em vrios esteretipos.3.2.3Esteretipo de Interface Em geral, os SI possuem funcionalidades e necessidades comuns de apresentaode informao. O conceito de Esteretipo de Interface permite capturar essas similari-dades dos SI no que diz respeito a IU. Um Esteretipo modela uma forma de apresentaoassociada a um comportamento de interface recorrentes em diferentes aplicaes de SI[14]. Este conceito integra e estende os conceitos de Contexto de Design [70] e dePadres de Layout de Tela [44]. O conceito de contexto de design est relacionado com opropsito da interface, ou ainda o tipo de aplicao desenvolvida. Os contextos de designapresentam alguns tipos de aplicao para determinados domnios, separados em trscategorias: Tipos de Sites, Experincia do Usurio e Tipos de Pgina. Por exemplo, portale aplicao Web so tipos de site identicados. Gerenciador de Informaes e Assistncia(suporte) so do tipo Experincia do Usurio. Blog, Artigo e Contato so Tipos de Pginaidenticados. J os padres de layout de tela [44] abstraem alguns formatos de apresentaode IU, independente do domnio a que se aplicam. So identicados 15 padres de tela,dentre eles Mestre-detalhe, que permite ao usurio permanecer na mesma tela enquantonavega entre os itens; Planilha, que oferece fcil edio, adio, visualizao e totalizao;Formulrio e Portal. Do mesmo modo, um esteretipo deve abstrair a aparncia de IUjuntamente com seu comportamento. 42. 3.2 Metamodelo de IHC41Por meio do Esteretipo de Interface possvel abstrair as tarefas e interaescom o usurio, bem como a forma de apresentao das informaes para uma determinadatarefa. Cada Esteretipo deve determinar a forma de apresentao das informaes paradeterminada necessidade de SI, bem como o comportamento da interface a cada interaocom o usurio.Por exemplo, formulrios possibilitam a entrada de dados na aplicao pelousurio; planilhas apresentam um conjunto de registros de determinado elemento denegcio; portais Web apresentam uma ampla variedade de informaes organizadas emsubsites, que podem conter funcionalidades especcas.Um Esteretipo de Interface deve ter uma identicao nica e conter elementosabstratos de interao. O esteretipo organiza esses elementos em relao s propriedadesde apresentao e comportamento. Como um esteretipo pode ser reutilizado como umelemento de outro esteretipo, possvel denir elementos complexos de IHC. A partirde Esteretipos simples podem ser gerados tipos de Esteretipos mais complexos eimportantes para SI, tais como pginas de consulta, planilhas, portais Web, e relatriosmestre-detalhe.Um Esteretipo descreve IU para aplicaes tpicas de SI. Nele so denidoselementos-chave, comuns a todas as instncias do esteretipo, deixando-se em aberto oselementos especcos de cada instncia. Esses elementos so preenchidos conforme osconceitos de negcio da aplicao selecionada.Um Esteretipo de Interface deve conter pelo menos um Elemento de Interao.Assim, um Elemento de Interao presente em determinado Esteretipo caracterizaum Elemento Estereotipado. Este elemento deve possuir um nmero de sequncia,possibilitando que o Esteretipo organize seus elementos conforme a ordem especicada.Os comportamentos do esteretipo devem ser denidos atravs da especicaode aes. Uma Ao pode envolver apenas a interface, como transio de estados,navegao e feedback ao usurio, no necessitando da interveno da aplicao para serexecutada. Logo, este tipo de comportamento especicado como ao de interface.Uma vez que um Elemento de Interao associado a um esteretipo, este ele-mento pode estender os eventos de elemento com Eventos Estereotipados, possibilitandoassociar outra ao que ser executada aps a ocorrncia do evento.As aes de interface so predenidas pelo esteretipo, j que estas no neces-sitam do conhecimento da aplicao para sua execuo. Logo, todas as intncias do es-teretipo executaro o mesmo comportamento para aes de interface.J as aes que dependem da aplicao, ou de outros sistemas, so especicadaspelo esteretipo como aes externas. O mecanismo para especicao de aes explicado na Seo 3.2.2.O emprego do conceito de Esteretipo para a denio de IU promove a reuti- 43. 3.2 Metamodelo de IHC 42lizao. A abstrao da apresentao e do comportamento de interfaces em esteretipospermite que os elementos abstrados sejam instanciados em diferentes aplicaes de di-versos SI. Isto eleva a produtividade, j que a instanciao de esteretipos faz com que asinterfaces sejam produzidas mais rapidamente por reaproveitar a aparncia e comporta-mento de IU com os mesmos propsitos. Alm disso, tendo-se abstrado em um esteretipo a apresentao e o compor-tamento de uma classe de IU, promove-se a padronizao e consistncia, uma vez que ainstanciao de qualquer interface ir gerar a mesma apresentao e o mesmo comporta-mento, com os mesmos propsitos denidos pelo esteretipo. Um exemplo simples de aplicao do conceito de Esteretipo de Interface oFormulrio, um tipo de interface muito utilizado em SI. O Esteretipo Formulrio temo objetivo de receber informaes do usurio para que a aplicao possa process-las earmazen-las. A Figura 3.4 apresenta uma abstrao da forma de apresentao de um For-mulrio. O elemento Ttulo um agrupador que apresenta o elemento de negcio noqual se aplica o Formulrio. Este agrupador contm outro agrupador, que composto porelementos de interao do tipo Questo, j que o objetivo do esteretipo a entrada dedados por parte do usurio.Figura 3.4: Exemplo de Esteretipo - Formulrio O nmero de questes a serem colocadas no formulrio ir variar conforme oelemento de negcio a ser representado na interface, ou seja, para cada elemento denegcio haver um nmero diferente de questes no formulrio. Tambm faz parte doesteretipo Formulrio um agrupador com elementos de interao do tipo Servio, queacionaro as regras de processamento, implementadas pela aplicao subjacente, para asaes predenidas pelo esteretipo. 44. 3.2 Metamodelo de IHC 43 O Esteretipo dene o comportamento especicado por meio dessas aes.Para o esteretipo Formulrio, as aes necessrias so: Salvar, Limpar e Cancelar. Aao Salvar deve implementar uma funo que armazene as informaes fornecidas pelousurio. Essas informaes so encapsuladas em um Elemento de Negcio representadono esteretipo. A ao Limpar deve apagar todas as informaes que o usurio colocou noformulrio. A ao Cancelar far com que seja fechado o formulrio sem salvar qualquerinformao. Como as aes Limpar e Cancelar independem da aplicao, elas sopredenidas pelo prprio esteretipo, sendo especicadas como aes de interface.3.2.4Exemplo de Utilizao do Metamodelo de IHC Um exemplo de utilizao do Metamodelo de IHC para a modelagem de IU apresentado na Figura 3.5. Neste exemplo, o elemento de negcio (entidade Pessoa),apresentada na Seo 3.1, foi o alvo da modelagem de IHC com base no esteretipo deFormulrio.Figura 3.5: Exemplo de Aplicao do Metamodelo de IHC O esteretipo Formulrio associa os elementos de interao do tipo questoaos atributos do elemento de negcio (entidade Pessoa). O mapeamento realizado entreo Metamodelo de Domnio e o Metamodelo de IHC discutido no Apndice A.1.Os atributos foram mapeados para as respectivas questes: Nome (Questo Aberta),Data de Nascimento (Questo Aberta), CPF (Questo Aberta), Naturalidade (Agrupador)composto por Estado (Questo Fechada) e Cidade (Questo Fechada), e Idade (QuestoAberta). Nota-se que, no elemento de negcio, uma Cidade deve pertencer a determinadoEstado. necessrio colocar um Evento que monitore a seleo do Estado, para que ento 45. 3.2 Metamodelo de IHC44seja apresentado ao usurio o conjunto de Cidades pertencentes a ele. Logo, adicionada interface a ao CarregaCidade, que ser responsvel por observar o Estado selecionadoe disponibilizar as Cidades que pertencem ao Estado.As demais aes associadas ao esteretipo Formulrio j foram consideradas naSeo 3.2.3.3.2.5Correlao entre Apresentao e Comportamento de IU Tanto a apresentao quanto o comportamento da interface so modelados deforma abstrata, atravs de metadados. Porm, estes aspectos no podem ser consideradosisoladamente. Cada Elemento de IHC pode ter diferentes formas de interao. Entretanto,o tipo de elemento determina qual comportamento deve ser executado. Para cada Ele-mento de IHC haver um conjunto de Eventos de Elemento que disparam as aes padrodo elemento. Por exemplo, um elemento do tipo questo pode ter como padro o eventoMudana, e a este evento estar associada uma ao externa associada a uma regra devalidao do Domnio de Negcio. Isto signica que em todas as instncias do elementode IHC questo que acontecer o evento Mudana ser executada a ao de validao. Porm, para um Elemento de IHC presente em um Esteretipo, ou seja, um Ele-mento Estereotipado, pode haver um conjunto de Eventos Estereotipados cuja ocorrnciapode alterar a ao a ser disparada, possibilitando estender a denio do comportamentopara o Elemento Estereotipado. Por exemplo, para o evento Mudana citado acima,pode ser alterada a ao que deve ser disparada para uma ao externa nomeada comoCalcular. Assim, se um Elemento de IHC pertence a vrios Esteretipos, tem-se vriosElementos Estereotipados, e estes, por sua vez, podem ter comportamentos variados, deacordo com a especicao do esteretipo. Por exemplo, um elemento do tipo questoaberta em um esteretipo formulrio dispara uma ao de preencher um outro elementodo tipo questo. J este mesmo elemento questo aberta, em um esteretipo de Login,dispara uma ao de validao. Outra considerao importante que os eventos de entrada de dados acontecemnos elementos questo aberta e questo fechada. Isto , um elemento questo aberta oufechada requer que o usurio realize uma interao que transfere informaes para ainterface do sistema. A Resposta dada pelo usurio nestes elementos ocorre por meio doseventos de entrada de dados pelo usurio em resposta a uma questo aberta ou fechada.J os eventos de solicitao ocorrem em elementos de informao do tipo servio, umavez que este tipo de elemento aguarda que o usurio acione-o para disparar a execuo deuma ao. 46. 3.3 Metamodelo de Apresentao 45 Os demais tipos de elemento de Informao no tm por objetivo habilitareventos para realizao de aes externas, uma vez que apenas comunicam informaesdo sistema. Entretanto, estes tipos de elemento podem habilitar aes de transio deestados e de navegao, j que estas aes apenas auxiliaro o usurio a encontrar asinformaes desejadas. Por exemplo, um trecho de texto que contenha ligaes queconduzem a outras partes do texto (hipertexto). O conjunto de estados de uma IU deve ser especicado pelo seu Esteretipo,ou seja, todas as IU que so instncias do mesmo Esteretipo devem possuir o mesmoconjunto de estados, e as mesmas aes. A diferena est na implementao das aesexternas, com o objetivo de que cada instncia de determinado Esteretipo implemente asaes especicadas com as particularidades requeridas pela respectiva aplicao. Como exemplo, temos as aes do esteretipo Formulrio, apresentado na Seo3.2.3, que possui as aes internas Cancelar e Limpar com comportamento comum atodas as instncias de Formulrio, e a ao Salvar que ter uma implementao para asparticularidades de cada instncia de Formulrio. Os metadados do Metamodelo de IHC so abstratos o suciente para que sejamproduzidas descries de interfaces independente de uma tecnologia. Para que seja geradauma interface, existem informaes especcas da plataforma computacional que devemser consideradas. Estas questes so tratadas em outro metamodelo, apresentado a seguir.3.3 Metamodelo de Apresentao O objetivo do Metamodelo de Apresentao representar a Interface Concreta,isto , os elementos de interface especcos para uma determinada plataforma. Estemetamodelo estende o Metamodelo de Interface proposto em [17], possibilitando agerao de outros tipos de interface, alm de interfaces do tipo CRUD. Assim como ometamodelo original, a extenso tambm especca para IU baseadas em WIMP. A Figura 3.6 apresenta o Metamodelo de Apresentao para SI. Este metamodelo composto por Templates, que so a representao concreta dos Esteretipos de Interfaceem determinada plataforma. O pacote Aplicao, externo ao metamodelo, representa algica de negcio das aplicaes de SI. O mapeamento entre o Metamodelo de IHC e oMetamodelo de Apresentao exibido no Apndice A.2. Um Template conhecido como uma descrio visual da apresentao de umaaplicao ou documento, padronizando a aparncia [76]. Neste trabalho este conceitovai alm, representando no apenas a apresentao visual de interfaces com o mesmopropsito, como tambm o comportamento esperado desta interface. Um Template possui um Idioma que o descreve. Uma mesma aplicao pode serexecutada em diferentes Idiomas. Para que a interface de usurio possa ser apresentada 47. 3.3 Metamodelo de Apresentao 46 Figura 3.6: Metamodelo de IU concretaem diversos idiomas, o Template deve prover apoio para internacionalizao, de acordocom o idioma da aplicao subjacente. Uma vez que os metadados do domnio de negcio so descritos em diversosidiomas, o template deve identicar em qual deles a aplicao deve ser executada. Assim,o template deve enviar esta informao para o domnio de negcio, a m de que os dadosdo domnio sejam repassados no idioma adequado. Este mecanismo de apoio internacionalizao das aplicaes geradas prtico,por fornecer apoio gerao de aplicaes multi-idioma de maneira simples. Um Template uma composio de Paineis. Painel o conceito concreto paraos Elementos de Interao da interface que devem transmitir informaes ou receberinteraes do usurio. Existem quatro tipos de Painel: Painel de Entrada, Painel deNavegao, Painel de Sada e Painel Composto, de forma que possvel representarcomponentes de variados tipos. Painel de entrada o elemento que recebe informaes do usurio para seremarmazenadas na aplicao de SI. Ele ainda deve ser restringido pela cardinalidade, formatoe domnio. Isto , estas informaes, contidas no Domnio do Negcio e mapeadas para 48. 3.3 Metamodelo de Apresentao47elemento de IHC, auxiliam na implementao de paineis que no permitem a entrada dedados que no pertencem ao domnio, formato e cardinalidade requeridos pelo contextode negcio. Deste modo, atendido o critrio de usabilidade de proteo a erros [3], porser um mecanismo que evita erros de entrada de dados por parte dos usurios.O painel de navegao aciona uma ao aps a interao do usurio. Painelde sada apresenta informaes ao usurio e no esperam qualquer interao. O painelcomposto uma composio de vrios painis.Conceitos de Estilo e Leiaute devem ser considerados em nvel concreto, e paraisto eles foram associados ao conceito de Painel. Estilo a descrio da aparncia dedeterminado painel em termos de tamanho (em porcentagem), tipo de fonte, cor, corde fundo, bordas, entre outros conceitos. O estilo deve ser descrito no formato CSS(Cascating Style Sheets) [75]. O leiaute est relacionado com o posicionamento dospaineis na interface. Um arquivo JSF deve ter a posio de cada painel, e informaesem CSS complementam a descrio do leiaute.H dois tipos de Regras que devem surgir do mapeamento do conceito de Aodo nvel abstrato: Regras de Interface e Regras de Aplicao. As regras de interfaceso aquelas que independem da lgica da aplicao para serem executadas, e as regras deaplicao so aquelas que sero implementadas pela aplicao de SI.As regras so denidas atravs de uma API (Application Programming Inter-face). Elas devem encapsular um Objeto de Navegao que conduz as informaesnecessrias da interface para a regra de aplicao a ser executada. Este objeto deve con-ter o elemento de negcio manipulado na interface, bem como as informaes requeridaspela aplicao para que as regras sejam executadas adequadamente. Por exemplo, paraque uma regra de transio de interfaces seja executada adequadamente, necessrio en-viar a informao de qual ser a prxima interface a ser executada.O comportamento , ento, especicado conceitualmente, atravs de regras quedenem uma API, sem especicar a sua forma de implementao. As regras devem serimplementadas pela aplicao ou sistemas externos, que devem implementar a fachadadenida pelo pacote Aplicao para as regras solicitadas pela interface. Isto garante aexistncia de um comportamento para cada interao que requer uma funcionalidadeda aplicao, sem determinar como ser a implementao deste comportamento pelaaplicao.A implementao das regras de aplicao deve ser realizada pela aplicao ousistemas externos, de forma semelhante ao mecanismo de regras de negcio propostopor [2]. Dentre as regras de aplicao, destacam-se as Regras de Validao (conforme ataxonomia de [69] e a denio do framework de gesto de SI [2] ).Para a implementao das regras de interface, o Template oferece uma interfaceque manipula estas regras, implementando o padro de projeto Faade, facilitando a 49. 3.3 Metamodelo de Apresentao48utilizao das regras de interface.A aplicao ou o template implementam as regras denidas na API do es-teretipo, e estas regras devem ser invocadas por meio de uma fachada, fazendo comque a lgica de IU que isolada da aplicao. Isto torna a gerao de SI integrada aoponto de vista da IHC e, ao mesmo tempo, desacoplada, uma vez que cada aspecto dosistema (interface e aplicao) tratado de maneira separada.Dessa forma, o comportamento da interface pode ser relacionado com a lgicade negcio da aplicao subjacente. Cada tipo de template deve implementar a classeTemplate, denindo seus elementos e associando-os ao comportamento descrito na APIde regras por meio da fachada. Essa API pode ser implementada pela aplicao subjacentepor meio da fachada Regras de Aplicao (que dene a Lgica de Negcio).A descrio do comportamento por meio de uma API torna a integrao dainterface de usurio com a lgica de negcio uma tarefa mais simples de ser realizada.Isto ocorre por meio da implementao do padro de projeto Faade, que dene umainterface de nvel mais alto para as regras.A Figura 3.7 exibe um exemplo de aplicao do Metamodelo de Apresentao,que a representao concreta dos dados abstratos da Figura 3.5. Em relao ao Metamo-delo de IHC, este exemplo apresenta a classe CadastraPessoa, que uma implementaode Template. Esta classe possui a implementao dos mtodos necessrios para executaras funcionalidades requeridas pelo usurio: limpar e cancelar, que so regras de interface,e salvar, que uma regra de aplicao invocada pelo template. Ainda para o caso espec-co do exemplo em questo, h a regra de aplicao Carrega Cidade, que invocada pormeio do painel Estado.Com a descrio concreta da interface, deve existir um mecanismo queinterprete-a a m de gerar a interface nal para o usurio. Isto requer uma arquiteturade software que apoie o emprego dos metamodelos aqui propostos. O prximo captuloapresenta a arquitetura de um componente para gerenciar o processo de construo de IUbaseado nos metamodelos descritos neste captulo. 50. 3.3 Metamodelo de Apresentao 49Figura 3.7: Exemplo de Aplicao do Metamodelo de Apresenta-o 51. CAPTULO 4Arquitetura para um Sistema de Gerncia de IU A arquitetura para gerncia de IU proposta neste captulo traz um conjunto devises arquiteturais com o objetivo de descrever os diferentes aspectos de um componentede gerncia de IU. Esta arquitetura supera algumas limitaes das abordagens atuais, demodo a administrar a complexidade da construo de IU baseada em modelos para SI. Esta soluo arquitetural faz parte de uma macro-arquitetura de frameworkbaseado em modelos para gesto de SI, onde diferentes aspectos de SI so considerados[2]. Uma viso geral desta macro-arquitetura apresentada na Seo 4.1. A interface deusurio um destes aspectos. Porm estes aspectos devem ser integrados para que formemum Sistema de Informao executvel. Uma viso geral da arquitetura para gerncia de IU apresentada na Seo 4.2. ASeo 4.3 explana a Viso Lgica do mdulo Modelo, mostrando como os metamodelosapresentados no Captulo 3 so empregados para a gerao automtica de IU. Finalmentea Seo 4.4 apresenta a forma de comunicao entre os pacotes do mdulo Modelo.4.1 Viso geral da Arquitetura do Framework de Gestode SI O Grupo de Pesquisa em Engenharia de Software do Instituto de Informtica(INF) da Universidade Federal de Gois tem investido um grande esforo de pesquisa nosentido de construir componentes para apoiar o desenvolvimento de software que contem-plem os diversos aspectos de Sistemas de Informao. Neste sentido, um framework paradesenvolvimento de software especco de domnio foi construdo para apoiar a sntesede SI baseado em modelos de alto-nvel [2, 15, 34]. O framework para gesto de SI desenvolvido pelo Grupo de Pesquisa do INFteve uma primeira verso [2] e atualmente encontra-se em evoluo, j que algumasdiculdades foram encontradas [25]. A ideia bsica deste framework que existem trs aspectos primordiais para oprojeto de SI, a saber: dados, processos e interface de usurio [15], e estes podem ser 52. 4.1 Viso geral da Arquitetura do Framework de Gesto de SI 51tratados de maneira separada, por especialistas que tratam das peculiaridades de cadaaspecto. Porm, eles devem ser integrados de forma adequada formando um Sistema deInformao. A Figura 4.1 apresenta os componentes deste framework.Figura 4.1: Viso Geral da Arquitetura do Framework paraGesto de SINa Figura 4.1 observa-se que cada um dos componentes do framework trataum aspecto de um Sistema de Informao. Como pode-se observar, um Sistema deInformao composto por um Domnio de Negcio, que compreende os dados donegcio e as regras associadas que sero modicadas e aplicadas pelo SI. As regras sotratadas pelo mecanismo proposto em [2].Um Sistema de Informao tambm contm um Processo de Negcio, queorganiza as aes e tarefas para gerar e modicar dados de negcio, melhorando acompreenso das atividades e seus relacionamentos. Estas so aplicaes predenidaspara SI, ou seja, qualquer Sistema de Informao compreende estas duas aplicaes. Almdisso, SI contm Aplicaes Especcas do negcio, j que dependendo do domnio daaplicao podem surgir necessidades especcas que devem ser consideradas.Deste modo, este trabalho prope o componente para Gerncia de IU, queutiliza as informaes contidas nos demais aspectos de SI para gerar interfaces e acionarfuncionalidades. O restante deste captulo descreve as caractersticas deste componente. 53. 4.2