De Requisitos a Prot´ otipos de UI: Uma Abordagem Semi Automatizada [From requirements to UI prototypes: a semi-automated approach] Rui Couto, Ant´ onio N. Ribeiro & Jos´ e C. Campos Departamento de Inform´ atica/Universidade do Minho & HASLab/INESC TEC, Braga, Portugal Resumo—Software development poses multiple challenges, from requirements specification to final software production. We have developed two approaches, focused on complementary aspects of the problem. On the one hand, SCARP supports obtaining architectural models (hence, business layer code) from requirements models. On the other, MODUS produces UI pro- totypes from architectural models. This work presents their inte- gration to obtain a development cycle going from requirements to executable prototypes, supported by semi-automated processes. I. I NTRODUC ¸˜ AO A Model-Driven Development Architecture (MDA) surge como uma alternativa aos processos tradicionais de desen- volvimento de software. Movendo o foco do c´ odigo para os modelos, ´ e poss´ ıvel fazer o desenvolvimento a um mais alto n´ ıvel de abstracc ¸˜ ao. Uma grande vantagem destas abordagens ´ e a possibilidade de produzir implementac ¸˜ oes de uma forma automatizada. Em trabalhos anteriores, desenvolvemos a abor- dagem SCARP [1], uma abordagem baseada em modelos, que inicia o desenvolvimento ao n´ ıvel dos modelos de requisitos. Similar ` a MDA, a Model-Based User Interface Development (MBUID) permite a produc ¸˜ ao de Interfaces com o Utilizador (IUs) com base em modelos. Neste contexto, desenvolvemos a abordagem MODUS [2], [3], que permite, a partir de modelos arquitecturais, produzir prot´ otipos execut´ aveis de IUs. Este trabalho explora a combinac ¸˜ ao das duas abordagens. Os outputs produzidos pelo SCARP s˜ ao compat´ ıveis com os inputs recebidos pelo MODUS. Desta forma, ´ e ent˜ ao poss´ ıvel obter prot´ otipos de IUs, com base em modelos de requisitos. II. SCARP A gerac ¸˜ ao de software baseada em modelos [4] baseia todo o processo de gerac ¸˜ ao de software na especificac ¸˜ ao e transformac ¸˜ ao de modelos. As vantagens deste tipo de abordagens s˜ ao a resoluc ¸˜ ao de problemas relacionados com produtividade, portabilidade, interoperabilidade e manutenc ¸˜ ao, uma vez que o foco do processo de desenvolvimento de software passa a ser os modelos. As implementac ¸˜ oes por sua vez, s˜ ao obtidas atrav´ es de ferramentas de transformac ¸˜ ao de modelos. Uma das lacunas da MDA ´ e o facto de iniciar o processo ao n´ ıvel arquitectural, havendo um hiato entre os requisitos e as arquitecturas. A abordagem SCARP (Scenario Based Rapid Software Prototyping) permite estender as vantagens das abordagens baseadas em modelos at´ e aos modelos de requisitos. Com base nestes modelos, formalizac ¸˜ oes de requisitos previamente identificados, ´ e feito um mapeamento para uma ontologia que, por um lado, fornece estruturac ¸˜ ao de conhecimento e, por outro, permite a an´ alise desse conhecimento. Com base nessas capacidades, ´ e ent˜ ao efectuada inferˆ encia de padr˜ oes de requisitos, identificando padr˜ oes j´ a documentados para os quais existe uma implementac ¸˜ ao conhecida, e feita a ponte para os padr˜ oes arquitecturais. Estes, por sua vez, podem ser instanciados e compostos de modo a obter uma soluc ¸˜ ao arquitectural. Partindo de um conjunto de modelos de re- quisitos, informac ¸˜ ao de dom´ ınio, e parametrizac ¸˜ ao por parte do utilizador, o SCARP ´ e capaz de produzir um modelo arquitectural que suporta os requisitos que o representam. III. MODUS A abordagem MODUS surge no contexto do MBUID, onde modelos arquitecturais s˜ ao utilizados para produzir prot´ otipos execut´ aveis de IUs. A framework de referˆ encia Cameleon [5] define quatro n´ ıveis de abstrac ¸˜ ao na gerac ¸˜ ao de interfaces: modelos de dom´ ınio e tarefas, modelos abstractos da IU, modelos concretos da IU e IUs finais. Apesar de comple- mentares ` as abordagens da secc ¸˜ ao anterior, as abordagens MBUID utilizam, assim, um conjunto de modelos distinto, o que dificulta a sua integrac ¸˜ ao. Um ponto comum ´ e a utilizac ¸˜ ao de modelos do dom´ ınio. Ao contr´ ario de outras abordagens MBUID que necessi- tam de uma especificac ¸˜ ao completa de todos os modelos envolvidos no processo, MODUS baseia-se na reutilizac ¸˜ ao do diagrama arquitectural da l´ ogica de neg´ ocio para um dado dom´ ınio conhecido. Este diagrama ser´ a o ponto de partida, no qual ser˜ ao identificados padr˜ oes ao n´ ıvel das classes, a partir de informac ¸˜ ao sobre o dom´ ınio da aplicac ¸˜ ao. Da mesma forma, informac ¸˜ ao sobre layouts ´ e fornecida pelo dom´ ınio, assim como templates, que podem ser ajustados pelo utilizador. A conjugac ¸˜ ao destes inputs, permite que o MODUS, a partir de um diagrama arquitectural, produza um prot´ otipo de interface execut´ avel [3] e de boa qualidade, tal como demonstrado por estudos com utilizadores [6]. IV. I NTEGRAC ¸˜ AO De modo a obter uma abordagem que permita semi- automatizar todo o ciclo de desenvolvimento, os outputs da abordagem SCARP s˜ ao fornecidos como input ` a abordagem