POMA: A Pattern-Oriented and Model-Driven Architecture

Transcription

1 Joural Title: Software - Practice ad Experiece POMA: A Patter-Orieted ad Model-Drive Architecture Mohamed Taleb (, 2), Ahmed Seffah () ad Alai Abra (2) () Huma-Cetered Software Egieerig Group Departmet of Computer Sciece ad Software Egieerig Cocordia Uiversity, Motreal, Quebec, Caada Telephoe: + (54) ext Fax: mtaleb@ecs.cocordia.ca seffah@cse.cocordia.ca (2) Software Egieerig & Iformatio Techology Departmet, École de Techologie Supérieure (ÉTS), Motreal, Quebec, Caada Telephoe: + (54) Fax: alai.abra@etsmtl.ca Abstract Day-to-day experiece suggests that it is ot eough to approach a complex desig armed with desig tips, guidelies, ad hits. Developers must also be able to use prove solutios emergig from the best desig practices to solve ew desig challeges. Without these, the desiger will ot be able to properly apply guidelies or take full advatage of the power of techology, resultig i poor performace, poor scalability, ad poor usability. Furthermore, the desiger may reivet the wheel whe attemptig to implemet a desig solutio. A umber of desig problems cotiue to arise, such as: () decouplig the various aspects of iteractive systems (for example, busiess logic, the UI, avigatio, ad iformatio architecture; ad (2) isolatig platform specifics from the cocers commo to all iteractive systems. I the cotext of a proposal for a Patter-Orieted ad Model-Drive Architecture (POMA) for iteractive systems, this paper idetifies a extesive list of patters categories, ad types of models aimed at providig a pool of prove solutios to these problems. The models of patters spa several levels of abstractio, such as domai, task, dialog, presetatio, ad layout. The proposed POMA architecture illustrates how several idividual models ca be combied at differet levels of abstractio ito heterogeeous structures, which ca the be used as buildig blocks i the developmet of iteractive systems. First, we describe the architectural levels ad the categories of patters, as well as the various relatioships betwee patters; secod, we propose five categories of models to address the problems described above which are associated with creatig a iteractive system. Third, we preset the proposed POMA architecture. Fourth, we preset a case study to illustrate ad clarify the core ideas of our approach ad its practical relevace. Keywords: Patters, Models, Architecture, Iteractive Systems, Compositio, Mappig, Trasformatio, POD, MDA, POMA. Itroductio Durig the past two decades, research o iteractive system ad user iterface (UI) egieerig has resulted i a set of desig priciples ad developmet frameworks which costitute a major cotributio, ot oly to facilitate the developmet ad maiteace of iteractive systems, but also to promote the stadardizatio, portability, ad ergoomic "usability (ease of use) of the iteractive systems beig developed. Some of these priciples are:

2 A precise defiitio of the UI aimed at: (i) presetig the output to the user; (ii) gatherig user etries to trasmit them to the iteractive system procedures that will treat them; (iii) hadlig the dialog sequece; The separatio of cocers, especially decouplig the UI from the system sematics; The defiitio of reusable ad stadardized UI compoets; Decetralizatio of dialog maagemet, help, ad errors across the various compoets of a iteractive system; Programmig drive by evets. Ideed, a iteractive system is a program with which the user egages i coversatio (dialog) i order to accomplish tasks. A iteractive system cosists of two parts: the software, which is referred to as the iteractive applicatio, ad the hardware, which supports the executio of the software part. The software (iteractive applicatio) ca, i tur, be divided ito two sub-parts: the UI, ad the algorithms that costitute the sematics of the iteractive system. The hardware i a iteractive system cosists of iput ad output devices ad various maagers (device drivers) which provide physical support to the executio of the iteractive applicatio. At the same time, a UI ca be see as a meas by which the user ad the machie ca exchage data. For example, the scree o which data are displayed is a medium for usermachie iteractio ad for feedback i respose to the user s actios. Therefore, a UI is part of a iteractive applicatio which: Presets the output to the user, Collects the user s iputs ad trasmits them to the iteractive system that treats them, ad Hadles the dialog sequece. Based o these priciples, several iteractive system architectural models have bee itroduced. Buschma et al. defie architectural models as [4]: the structure of the subsystems ad compoets of a system ad the relatioships betwee them typically represeted i differet views to show the relevat fuctioal ad o fuctioal properties. This defiitio itroduces the mai architectural compoets (for istace, subsystems, compoets, ad coectors) ad covers the ways i which to represet them, icludig both fuctioal ad ofuctioal requiremets, by meas of a set of views. A umber of architectures specific to iteractive systems have bee proposed, e.g. Seeheim model [55; 48], Model-View-Cotroller (MVC) [43], Aget Multi-Faceted (AMF) [54], which is a extesio of MVC, Arch/Sliky [47], Presetatio Abstractio Cotrol (PAC) [44; 45], PAC-Amadeus, ad Model-View-Preseter (MVP) [27]. Most of these architectures cosist of three mai elemets: () abstractio or model; (2) cotrol or dialog; ad (3) presetatio. Their goal is to improve ad facilitate the desig of iteractive systems. However, eve though the priciple of separatig a iteractive system ito compoets has its desig merits, it ca also be a source of serious adaptability ad usability problems i systems which provide fast, frequet, ad itesive sematic feedback: the commuicatio betwee the view ad the model makes the iteractive system highly coupled ad complex. Amog the problems preseted by the architectures quoted above are:

3 No guidelie is provided to ecourage the desiger to cosider other aspects of the dialog that are importat to the user, such as assistace or error-hadlig; Lack of facilitatio of the use of costraits for the desig ad descriptio of the iterface, whe these costraits are a great importace to the desiger [49; 50; 5; 52; 53; 46]; The architectural models are poorly located i relatio to the life cycle of the UI, which ca lead, i particular, to difficulties cocerig the passage of the problem aalysis (aalysis of user eeds), expressed geerally i terms of tasks ad iteractio sequeces, ad to the cocepts put forward by these architectures (agets, presetatio compoets, dialog compoets). Architectural patters have bee proposed to alleviate some of these problems, ad ideed were itroduced based o the followig observatio by Alexader: Each patter describes a problem that occurs costatly i our eviromet, ad thus describes the heart of the solutio to this problem, i such a way that we ca use this solutio millios of times, but ever do it twice the same way [40]. Such a patter provides, o oe level, a pool of prove solutios to may of the recurrig problems listed above. The Patter-Orieted Software Architecture is a example of a ew approach which shows how to combie idividual patters ito heterogeeous structures ad, as such, ca be used to facilitate a costructive istatiatio of a system architecture. Patters provide various beefits, such as: Well-established solutios to architectural problems, Help i documetig architectural desig decisios, ad Facilitatio of commuicatio betwee users through a commo vocabulary. However, we ote that the emergece of patters i the architectural developmet of iteractive systems has ot solved some problems associated with this developmet. Amog the challegig problems we address i this paper are the followig: (a) Decouplig of the various aspects of iteractive systems, such as busiess logic, UI, avigatio, ad iformatio architecture; (b) Isolatio of the platform-specific problems from the cocers commo to all iteractive systems. I 200, the Object Maagemet Group itroduced the Model-Drive Architecture (MDA) iitiative as a architecture to system specificatio ad iteroperability based o the use of formal models (i.e. defied ad formalized models). The mai idea behid MDA is to specify busiess logic i the form of abstract models. These models are the mapped (partly automatically) accordig to a set of trasformatio rules to differet platforms. The models are usually described by UML i a formalized maer which ca be used as iput for tools to perform the trasformatio process. Ideed, a model is a formal descriptio of some key aspects of a system, from a specific viewpoit. As such, a model always presets a abstractio of the "real" thig, by igorig or deliberately suppressig those aspects that would ot of iterest to a user of that model. Differet modelig costructs focus attetio by igorig certai thigs [35]. For example, a architectural model of a complex system might focus o its cocurrecy aspects, while a

4 fiacial model of a busiess might focus o projected reveues. Model sytax icludes graphical or tabular otatios ad text. D Souza [35] has idetified key opportuities ad modelig challeges, ad illustrated how the model ad the architecture of MDA could be used to eable large-scale model-drive itegratio. The advatages of the models are as follows: They make it easier to validate the correctess of a model. They make it easier to produce implemetatios o multiple platforms. Itegratio/iteroperability across platforms is better defied. Geeric mappigs/patters ca be shared by may desigs. They costitute a iteractive system of tool-supported solutios. However, we ote that the model-drive approach has some weakesses as well: MDA does ot provide a stadard for the specificatio of mappigs: differet implemetatios of mappigs ca geerate very differet code ad models, which ca create depedecies betwee the system ad the mappig solutio used. Desigers must take ito accout a diversity of platforms which exhibit drastically differet capabilities. For example, Persoal Digital Assistats (PDAs) use a pebased iput mechaism ad have average scree size i the rage of 3 iches. The architectural models must be located ad compared to the life cycle of the UI: i particular, difficulties may arise related to the problem aalysis (aalyzig user eeds), expressed geerally i terms of tasks ad iteractio sequeces, ad to the cocepts proposed by these architectures (agets, presetatio compoets, ad dialog compoets). Our research goal ca be stated as follows: a ew architecture to facilitate the developmet ad migratio of iteractive systems while improvig their usability ad quality. To pursue this goal, it is ecessary to defie a systematic architecture, supported by a CASE tool, to glue patters together. I this paper, we idetify some of the fudametals of such a architecture ad we preset a architecture called the Patter-Orieted ad Model-Drive Architecture (POMA) (Figure 4). We also preset a evaluatio of the feasibility of some phases of this architecture, such as compositio ad mappig patters, ad trasformatio models to create platform-idepedet models (PIM) ad platform-specific models (PSM). Figure summarizes the architectural patters ad models that were combied to obtai the POMA architecture. Figure : Architectural Patters ad Models

5 I this paper, we propose a architectural model which combies two key approaches: modeldrive ad patter-orieted. First, we describe architectural levels ad categories of patters, as well as the various relatioships betwee patters. These relatioships are used ext to combie ad map several categories of patters to create a patter-orieted desig for a iteractive system, as well as to show how to geerate specific implemetatios suitable for differet platforms from the same patter-orieted desig. Secod, we propose five categories of models (Domai model, Task model, Dialog model, Presetatio model, ad Layout model) which address problems such as: (a) decouplig the various aspects of iteractive systems, such as busiess logic, UI, avigatio, ad iformatio architecture; ad (b) isolatig the platform-specific problems from the cocers commo to all iteractive systems. Third, the proposed Patter-Orieted ad Model-Drive Architecture (POMA) illustrates how the idividual models metioed above ca be combied at differet levels of abstractio ito heterogeeous structures to be used as buildig blocks i the developmet of iteractive systems. Fourth, we preset a case study to illustrate our approach ad its practical relevace. Fially, we provide a coclusio o the research carried out ad commet o its evolutio i the future. 2. Patters ad Patter-Orieted Architecture 2.. About Patters The idea of usig patters i system desig ad egieerig is ot ew. It has its roots i the popular work, Gag of Four [2]. Collectios of patters iclude patters for UI (UI) desig [3; 4; 5], patters for avigatio i a large iformatio architecture, ad patters for visualizig ad presetig iformatio. More recetly, the cocept of the usability patter has bee itroduced ad discussed as a tool for esurig the usability of developed systems [6; 7; 8]. A usability patter is a prove solutio for a User Cetered Desig (UCD) problem that recurs i differet cotexts. The primary goal of usability patters i geeral is to create a ivetory of solutios to help UI desigers to tackle UI developmet problems which are commo ad difficult to solve [9] Architectural Levels ad Categories of Patters A umber of patter laguages have bee suggested, such as i Va Duye s The Desig of Sites [0], Welie s Iteractio Desig Patters [5], ad Tidwell s UI Patters ad Techiques [3]. I additio, specific laguages have bee proposed, such as i Laakso s UI Desig Patters [3] ad the UPADE Laguage [29]. Moreover, various specialized collectios of patters have bee published, icludig patters for Web page layout desig [3; 4; 5], patters for avigatio aroud iformatio architectures, ad patters for visualizig ad presetig iformatio. I our work here, we illustrate how these existig collectios of patters ca be used as buildig blocks i the cotext of the proposed six-layer architecture. A iformal survey coducted i 2004 by the HSCE Research Group at Cocordia Uiversity idetified at least six architectural levels ad six categories of patters which ca be used to create a patter-orieted iteractive system architecture. Table illustrates these six levels of architecture for a iteractive system, icludig the correspodig categories of patters, ad gives examples of patters i each category.

6 Architectural Level ad Category of Patters Iformatio This category of patters describes differet coceptual models ad architectures for orgaizig the uderlyig cotet across multiple pages, servers, ad computers. Such patters provide solutios to questios such as which iformatio ca or should be preseted o which device. This category of patters is described i [39]. Iteroperability This category of patters describes decouplig the layers of a Iteractive system; i particular, betwee the cotet, the dialog, ad the views or presetatio layers. These patters are geerally extesios of the Gamma desig patters, such as MVC (Model, View, ad Cotroller) observer ad commad actio patters. Commuicatio ad iteroperability patters are useful for facilitatig the mappig of a desig betwee platforms. Visualizatio This category of patters describes differet visual represetatios ad metaphors for groupig ad displayig iformatio i cogitively accessible chuks. They maily defie the format ad cotet of the visualizatio, i.e. the graphical scee, ad, as such, relate primarily to data ad mappig trasforms. Navigatio This category of patters describes prove techiques for avigatig withi ad/or betwee a set of pages ad chuks of iformatio. This list is far from exhaustive, but helps to commuicate the flavor ad abstractio level of desig patters for avigatio. Iteractio This category of patters describes the iteractio mechaisms that ca be used to achieve tasks ad the visual effects they have o the scee; as such, they relate primarily to graphical ad rederig trasforms. Presetatio This category of patters describes solutios for how the cotets or the related services are visually orgaized ito workig surfaces, the effective layout of multiple iformatio spaces, ad the relatioship betwee them. These patters defie the physical ad logical layout suitable for specific iteractive systems. Examples of patters - Referece Model patter - Data Colum patter - Cascaded Table patter - Relatioal Graph patter - Proxy Tuple patter - Expressio patter - Schudler patter - Operator patter - Rederer patter - Productio Rule patter - Camera patter - Adapter patter - Bridge patter - Builder patter - Decorator patter - Façade patter - Factory patter - Method patter - Mediator patter - Memeto patter - Prototype patter - Proxy patter - Sigleto patter - State patter - Strategy patter - Visitor patter - Favorite Collectio patter - Bookmark patter - Frequetly Visited Page patter - Navigatio Space Map patter - Shortcut patter - Breadcrumb patter - Idex Browsig patter - Cotextual (temporary) horizotal meu at top patter - Cotextual (temporary) vertical meu at right patter - Iformatio portal patter - Permaet horizotal meu at top patter - Permaet vertical meu at left patter - Progressive filterig patter - Shallow meus patter - Simple uiversal patter - Split avigatio patter - Sub-sites patter - User-drive patter - Alphabetical idex patter - Key-word search patter - Itelliget agets patter - Cotaier avigatio patter - Deeply embedded meus patter - Hybrid approach patter - Refreshed shallow vertical meus patter - Search patter - Executive Summary patter - Actio Butto patter - Guided Tour patter - Pagig patter - Pull-dow Butto patter - Slideshow patter - Steppig patter - Wizard patter - Carrousel patter - Table Filter patter - Detail O Demad patter - Collector patter - I place Replacemet patter - List Builder patter - List Etry View patter - Overview by Detail patter - Part Selector patter - Tabs patter - Table Sorter patter - Thumbail patter - View Table : Architectural levels ad categories of patters

7 Each of these six categories of patters is discussed below, ad examples are provided. Iformatio patters A iformatio patter, also called a iformatio architectural patter (Figure 2), expresses a fudametal structural orgaizatio or schema of iformatio. It provides a set of predefied subsystems (iformatio spaces or chuks), specifies their resposibilities, ad icludes rules ad guidelies for orgaizig the relatioships betwee them. A iformatio patter is everythig that happes i a sigle iformatio space or chuk. With aother patter, the cotet of a system is orgaized i a sequece i which all the iformatio spaces or chuks are arraged as peers, ad every space or chuk is accessible from all the others. This is very commo o simple sites, where there are oly a few stadard topics, such as: Home, About Us, Cotact Us, ad Products. Iformatio which aturally flows as a arrative, time lie, or i a logical order is ideal for sequetial treatmet. A idex structure is like the flat structure, with a additioal list of cotets. A idex is ofte orgaized i such a way as to make its cotet easier to fid. For example, a list of files i a Web directory (the idex page), a idex of people's ames ordered by last ame, etc. Dictioaries ad phoe books are both very large idices. The Hub-ad-Spoke patter is useful for multiple, distict, liear workflows. A good example would be a system, where the user returs to his ibox at several poits, e.g. after readig a message, after sedig a message, or after addig a ew cotact. A multidimesioal hierarchy is oe i which there are may ways of browsig the same cotet. I a way, several hierarchies may coexist, overlaid o the same cotet. The structure of the cotet ca appear to be differet, depedig o the user s task (search, browse). A typical example would be a site like Amazo, which lets you browse books by gere or by title, ad also lets you search by keyword. Each of these hierarchies correspods to a property of the cotet, ad each ca be useful, depedig o the user s situatio. A strict hierarchy is a specializatio of the multi-dimesioal hierarchy, ad describes a system where a lower-level page ca oly be accessed via its paret. Figure 2: Examples of Iformatio Patters

8 Iteroperability patters Iteroperability patters are useful for decouplig the way these differet categories of patters are orgaized, the way iformatio is preseted to the user, ad the user who iteracts with the iformatio cotet. Patters i this category geerally describe the capability of differet programs to exchage data via a commo set of exchage formats, to read ad write uder the same file formats, ad to use the same protocols. Gamma et al. [2] offer a large catalog of patters for dealig with such problems. Examples of patters applicable to iteractive systems iclude: Adapter, Bridge, Builder, Decorator, Factory Method, Mediator, Memeto, Prototype, Proxy, Sigleto, State, Strategy, ad Visitor [2]. The Adapter patter is very commo, ot oly to remote cliet/server programmig, but also to ay situatio i which there is oe class ad it is desirable to reuse that class, but where the system iterface does ot match the class iterface. Figure 3 illustrates how a adapter works. I this figure, the Cliet wats to ivoke the method request() i the Target iterface. Sice the Adaptee class has o request() method, it is the job of Adapter to covert the request to a available matchig method. Here, the Adapter coverts the method request() call ito the Adaptee method specificrequest() call. The Adapter performs this coversio for each method that eeds adaptig. This is also kow as Wrapperig. Cliet Adapter Request() Adaptee Target Request() Adaptee SpecificRequest() Visualizatio patters Figure 3: Adapter patter Iformatio visualizatio patters allow users to browse iformatio spaces ad focus quickly o items of iterest. Visualizatio patters ca help i avoidig iformatio overload, a fudametal issue to tackle, especially for large databases, Web sites, ad portals, as they ca access millios of documets. The desiger must cosider how best to map the cotets ito a visual represetatio which coveys iformatio to the user while facilitatig exploratio of the cotet. I additio, the desiger must udertake dyamic actios to limit the amout of iformatio the user receives, while at the same time keepig the user iformed about the cotet as a whole. Several iformatio visualizatio patters geerally combie i such a way that the uderlyig cotet ca be orgaized ito distict coceptual spaces or workig surfaces which are sematically liked to oe aother. For example, depedig o the purpose of the site, users ca access several kids of "pages", such as articles, URLs, products, etc. They typically collect several of these items for

9 a specific task, such as comparig, buyig, goig to a page, sedig a page to others, etc. Users must be able to visualize their "collectio". The followig are some of the iformatio visualizatio patters for displayig such collectios: Favorite, Bookmark, Frequetly Visited Page, Prefereces, ad Navigable Spaces Map. This category of patters provides a map to a large amout of cotet which ca be too much to be preseted reasoably i a sigle view. The cotet ca be orgaized ito distict coceptual spaces or workig surfaces which are sematically liked, so that it is atural ad meaigful to go from oe to aother. The map i Figure 4 is a example of this category of patters. Figure 4: The Navigatio Spaces Map patter implemeted usig Tree Hyperbolic, a sophisticated visualizatio techique. Navigatio patters Navigatio patters help the user move easily ad i a straightforward maer betwee iformatio chuks ad their represetatios. They ca obviously reduce the user s memory load [7; ]. See [3; 5; 29; 9] for a exhaustive list of avigatio patters. The Liear Navigatio patter is suitable whe a user wats a simple way to avigate from oe page to the ext i a liear fashio, i.e. move through a sequece of pages. The Idex Browsig patter is similar, ad allows a user to avigate directly from oe item to the ext ad back. The orderig ca be based o a rakig. For every item preseted to the user, a avigatio widget allows the user to choose the ext or previous item i the list. The orderig criterio should be visible (ad be user-cofigurable). To support orietatio, the curret item umber ad total umber of items should be clearly visible. A breadcrumb (Figure 5) is a widely used patter which helps users to kow where they are i a hierarchical structure ad to avigate back up to higher levels i the hierarchy. It shows the hierarchical path from the top level to the curret page ad makes each step clickable. Figure 5: Breadcrumb patter

10 Iteractio patters This category of iteractio patters provides basic iformatio o iteractio style, maily o how to use cotrols such as buttos, lists of items, meus, dialog boxes, etc. This category of patters is used wheever users eed to take a importat actio that is relevat i the curret cotext of the page they are viewig. Users must be made aware of the importace of the actio i relatio to other actios o the page or site. To view/act o a liear-ordered set of items, the Steppig patter (Figure 6) allows users to go to the ext ad previous task or object by clickig o the 'ext' or 'previous' liks. The 'ext' lik takes the users to the ext item i the sequece, while the 'previous' lik takes them a step back. It is recommeded that a 'ext' or 'previous' lik be placed close to the object to which it belogs, preferably above the object so that users do ot have to scroll to it. Make sure the ext/previous liks are always placed i the same locatio, so that users clickig through a list do ot have to move the mouse poiter. The covetio, at least i wester cultures, is to place the 'previous' lik o the left ad the ext lik o the right. Presetatio patters Figure 6: Steppig patter The authors of techical documets discovered log before iteractive systems were iveted that users appreciate short "chuks" of iformatio [6]. Patters i this category, called Presetatio patters, also suggest differet ways for displayig chuks of iformatio ad ways for groupig them i pages. Presetatio patters also defie the look ad feel of iteractive systems, while at the same time defiig the physical ad logical layout suitable for specific systems, such as home pages, lists, ad tables. For example, how log does it take to determie whether or ot a documet cotais relevat iformatio? This questio is a critical desig issue, i particular for resource-costraied (small) devices.

11 Patters i this category use a grid, which is a techique take from prit desig, but which is easily applicable to iteractive system desig as well. I its strictest form, a grid is literally a grid of X by Y pixels. The elemets o the page are the placed o the cell borderlies ad aliged overall o horizotal ad vertical lies. A grid is a cosistet system i which to place objects. I the literature o prit desig, there are may variatios of grids, most of them based o modular ad colum grids. Ofte, a mix of both types of grids will be used. A example of a grid i Figure 7 is used to create several dialog box patters. Figure 7: A example of a grid A example of these types of patters is the Executive Summary patter. Our Executive Summary patter gives users a preview of the uderlyig iformatio before they sped time dowloadig, browsig, ad readig large amouts of iformatio (Figure 8) Patter Compositio Figure 8: Example of a structural patter: Executive Summary A platform-idepedet patter-orieted desig exploits several relatioships betwee patters. Gamma et al. [2] emphasize that defiig the list of related patters as part of the descriptio of a patter is a key otio i the compositio of patters ad their uses. Zimmer [5] implemets this idea by dividig the relatios betwee the patters of the Gamma catalog

12 ito three types: X is similar to Y, X uses Y, ad Variats of X use Y. These types are, i practice, relatioships betwee patters i a specific cotext; i other words, they are relatioships betwee istaces of patters. Based o Zimmer s defiitios [5], we defie five types of relatioships betwee patters. Similar Two patters (X, Y) are similar, or equivalet, if ad oly if X ad Y ca be replaced by each other i a certai compositio. This meas that X ad Y are patters of the same category ad they provide differet solutios to the same problem i the same cotext. As illustrated i Figure 9, the Idex Browsig ad Meu Bar patters are similar. They both provide avigatioal support i the cotext of a medium-sized iteractive system. Figure 9: Similar patters extracted from the OMG site Competitor Two patters (X, Y) are competitors if X ad Y caot be used at the same time for desigig the same artifact relatioship that applies to two patters of the same patter category. Two patters are competitors if ad oly if they are similar ad iterchageable. For example, the Web patters Coveiet Toolbar ad Idex Browsig are competitors (Figure 0). The Idex Browsig patter ca be used as a shortcut toolbar that allows a user to directly access a set of commo services from ay iteractive system. The Coveiet Toolbar, which provides the same solutio, is geerally cosidered more appropriate. Figure 0: Two Competitor patters

13 Super-ordiate A patter X is a super-ordiate of patter Y, which meas that patter Y is used as a buildig block to create patter X. A example is the Home Page patter, which is geerally composed of several other patters (Figure ). Figure : Home Page patter with sub-ordiate patters Sub-ordiate (X, Y) are sub-ordiate if ad oly if X is embeddable i Y. Y is also called a superordiate of X. This relatioship is importat i the process of mappig patter-orieted desig from oe platform to aother. For example, the Coveiet Toolbar patter (Figure ) is a sub-ordiate of the Home Page patter for either a PDA or desktop system. Implemetatios of this patter are differet for differet devices. Neighborig Two patters (X, Y) are eighborig if X ad Y belog to the same patter category. For example, the Sequetial ad Hierarchical patters are eighborig because they belog to the same category of patters, ad eighborig patters may iclude the set of patters for desigig a specific page such as a home page (Figure ) Patter Mappig Aother compoet i our architectural framework is the cocept of patter mappig. Patter mappig is the process of creatig a desig of specific models for each platform called platform-specific model (PSM) from the PIM ad mappig rules which are described below. Usig a desktop system as a startig poit, it is possible to redesig it for other platforms. The origial set of patters used i the system is mapped or replaced, i order to redesig ad reimplemet the system ad, i particular, the UI for mobile or Persoal Digital Assistat (PDA) systems. Sice patters hold iformatio about desig solutios ad cotext of use, platform capabilities ad costraits are implicitly addressed i the trasformed patters.

14 To illustrate patter mappig, we describe here the effect of scree size o the selectio ad use of patters. Differet platforms use differet scree sizes, ad these differet scree sizes afford differet types ad variats of patters. The problem to resolve whe mappig a patter-orieted desig (POD) is how the chage i scree size betwee two platforms affects redesig at the patter level. The amout of iformatio that ca be displayed o a give platform scree is determied by a combiatio of area ad umber of pixels. The total differece i iformatio capacity betwee platforms will be somewhere betwee these two measures: 20 times the area ad 0 times the pixels. To map the desktop display architecture to the PDA display architecture, the optios are as follows:. To reduce the size of the architecture, it is ecessary to reduce sigificatly both the umber of pages ad the quatity of iformatio per page. 2. To hold the architecture size costat (i.e. topics or pages), it is ecessary to sigificatly reduce the quatity of iformatio per page (by a factor of about 0 to 20). 3. To retai all the iformatio i the desktop architecture, it is ecessary to sigificatly icrease the size of the architecture, sice the PDA ca hold less iformatio per page. The choice of mappig will deped o the size of the architecture ad the value of the iformatio: - For small desktop architectures, the desig strategy ca be weighted either toward reducig iformatio if the iformatio is ot importat, or toward icreasig the umber of pages if the iformatio is importat. - For medium ad large desktop architectures, it is ecessary to weight the desig strategy heavily toward reducig the quatity of iformatio, otherwise the architecture size ad umber of levels would rapidly explode out of cotrol. Fially, we ca cosider mappig patters ad graphical objects i the cotext of the amout of chage that must be applied to the desktop desig or architecture to fit it ito a PDA format. The followig is the list of mappig rules we suggest:. Idetical: No chage to the origial desig. For example, drop-dow meus ca usually be copied from a desktop to a PDA without ay desig chages. 2. Scalable: Chages to the size of the origial desig or to the umber of items i the origial desig. For example, a log horizotal meu ca be adapted to a PDA by reducig the umber of meu elemets. 3. Multiple: Repeatig the origial desig, either simultaeously or sequetially. For example, a sigle log meu ca be trasformed ito a series of shorter meus. 4. Fudametal: Chage the ature of the origial desig. For example, permaet lefthad vertical meus are useful o desktop displays, but are ot practical o most PDAs. I mappig to a PDA, left-had meus ormally eed to be replaced with a alterative such as a drop-dow meu. These mappig rules ca be used by desigers i the selectio of patters, especially whe differet patters apply for oe platform but ot for aother, whe the cost of adaptig or purchasig a patter is high, or whe the applicability of a patter (kowig how ad whe to apply a patter) is questioable.

15 This list of four mappig rules is especially relevat to the automatio of cross-platform desig mappig, sice the desigs that are easiest to map are those that require the least mappig. The category of patters therefore idetifies where huma itervetio will be eeded for desig decisios i the mappig process. I additio, whe buildig a desktop desig for which a PDA versio is also plaed, the category of patters idicates which patters to use i the desktop desig to allow easy mappig to the PDA desig. Figure 2 illustrates some of the avigatio desig patters used i the home page of a desktop-based system. Oce these patters are idetified i the desktop-based system, they ca be mapped or replaced by others i a PDA versio. Figure 2: Patters extracted from the CBC News site Figure 3 demostrates the redesiged iterface of the CBC site for migratig to a PDA platform. The permaet horizotal meu patter at the top (P5) i the origial desktop UI were repositioed to a shorter horizotal meu patter (P5s). I order to accommodate this chage o the small PDA scree, the three differet horizotal meus had to be shorteed, ad oly importat avigatio items were used. The keyword search patter (P3) remais as a keyword search. The permaet vertical meu o the left (P6) was redesiged to a dropdow meu (P5). The drop-dow meu i the PDA desig also icludes the meu headigs, What s o today? ad Olie features from the temporary vertical meu (P3) i the origial desktop desig. Fially, the iformatio portal (P4), which is the first item that captures the user s attetio, was redesiged as a smaller iformatio portal (P4s). Figure 3: Migratio of the CBC site to a PDA Platform usig Patter Mappig

16 3. Models ad Model-Drive Desig: Categorizatio ad Trasformatio 3.. About Models As the complexity of iteractive systems grows, the role of models is becomig essetial for dealig with the umerous aspects ivolved i their developmet ad maiteace processes. Models allow the relevat aspects of a system to be captured from a give perspective ad at a specific level of abstractio. I a model-drive UI desig approach, various models are used to describe the relevat aspects of the UI. May facets exist, as well as related models. Desig is a assembly of parts which realizes a specificatio. A model of a system is a specificatio of that system ad its eviromet for some purpose. Models cosist of a set of elemets with a graphical ad/or textual represetatio [56]. The idea behid model-drive desig is to create differet models of a system at differet levels of abstractio, ad to use trasformatios of the models to produce the implemetatio of the iteractive systems. A umber of distict models have bee suggested i the followig work: the OMG s Model-Drive Architecture [3, 4, 5, 6, 7], Si Alhir s Uderstadig the Model Drive Architecture (MDA), Methods & Tools [8], Paterò s Model-Based Desig ad Evaluatio of Iteractive Systems [22], Vaderdockt s Task Modelig i Multiple Cotexts of Use [23], Msheik s Compositioal Structured Compoet Model: Hadlig Selective Fuctioal Compositio [30], Puerta s Modelig Tasks with Mechaisms [24]. I our work here, we ivestigate how these existig collectios of models ca be used as buildig blocks i the cotext of the five levels of the proposed POMA architecture. Our approach focuses o a subset of the proposed models ad cosists of: a domai model, a task model, a dialog model, a presetatio model, ad a layout model. I the work reported i the ext sectio, we describe how these models ca be used at five levels of the proposed POMA architecture to create a model-drive architecture for iteractive systems Model Categorizatio A categorizatio of models is proposed ext. Examples of models are also preseted to illustrate the eed to map ad/or to trasform several types of models to provide solutios to complex problems at the five architectural levels. Domai Model The Domai model is sometimes called a busiess model. It ecapsulates the importat etities of a system domai alog with their attributes, methods, ad relatioships [3]. Withi the scope of UI developmet, it defies the objects ad fuctioalities accessed by the user

17 via the iterface. Such a model is geerally developed usig the iformatio collected durig the busiess ad fuctioal requiremets stage. The iformatio defies the list of data ad features or operatios to be performed i various ways, i.e. by differet users o differet platforms. The first model-based approaches used a Domai model to drive the UI at rutime. I this cotext, the Domai model would describe the system i geeral, ad iclude some specific iformatio for the UI. For example, the Domai model [3] would iclude: a class hierarchy of objects which exist i the system, the properties of the objects, actios which ca be performed o the objects, uits of iformatio (parameters) required by the actios, ad pre- ad post-coditios for the actios. Domai models should represet the importat etities alog with their attributes, methods, ad relatioships. Cosequetly, the oly real way to itegrate UI ad system developmet is the simultaeous use of the data model. That is why recet model-based approaches iclude a Domai model kow from the system egieerig methods. Four other models: Task, Dialog, Presetatio, ad Layout, have the Domai model as a iput. Figure 4 is a example of implemetatio of the Logi patter. Figure 4: Logi view of the system o the laptop platform Figure 5 is a example of the implemetatio of the Logi patter. Figure 5: Logi view of the system o the PDA platform

18 Task model The Task model makes it possible to describe how tasks ca be performed to reach the user s goals whe iteractig with a iteractive system [22]. Usig this model, desigers ca develop itegrated descriptios of the system from a fuctioal ad iteractive poit of view. Task models are typically tasks ad subtasks hierarchically decomposed ito atomic actios [23]. I additio, the relatioships betwee tasks are described with the executio order or depedecies betwee peer tasks. The tasks may cotai attributes about their importace, their duratio of executio, ad their frequecy of use. For our purposes, we reuse the followig defiitio: A task is a goal, alog with the ordered set of tasks ad actios that would satisfy it i the appropriate cotext. [3] This defiitio highlights the itertwiig ature of tasks ad goals. Actios are required to satisfy goals. Furthermore, the defiitio allows the decompositio of tasks ito sub-tasks, ad there exists some orderig amog the sub-tasks ad actios. I order to support this defiitio, we eed to add the defiitios of goal, actio, ad artifact: A goal is a itetio to chage or maitai the state of a artifact (based o [3]). A actio is ay act which has the effect of chagig or maitaiig the state of a artifact (based o [3]). A artifact is a object which is essetial for a task. Without this object, the task caot be performed; the state of this artifact is usually chaged i the course of performace of a task. Artifacts are real thigs which exist i the cotext of task performace. I busiess, artifacts are modeled as objects ad represeted i the busiess model. This implies a close relatioship betwee the Task model ad the busiess model. With these defiitios, we ca derive the iformatio that eeds to be represeted i a Task model. Accordig to [3], the descriptio of oe task icludes: Oe goal, A o-empty set of actios or other tasks which are ecessary to achieve the goal, A pla of how to select actios or tasks, ad A model of a artifact, which is iflueced by the task. Cosequetly, the developmet of the Task model ad the Domai model is iterrelated. Oe of the goals of model-based approaches is to support user-cetered iterface desig. Therefore, they must eable the UI desiger to create the various Task models. Three other models: Dialog, Presetatio, ad Layout, have the Domai ad Task models as iputs. Figure 6 represets the structure of the Task model of the evirometal maagemet system. As show i Figure 6, the Logi, Multi-Value Iput Form ad Fid patters ca be used i order to complete the Task model at the lower levels.

19 Figure 6: Coarse-graied Task model of the evirometal maagemet system

20 Dialog Model This model makes it possible to provide dialog styles to perform tasks ad to provide prove techiques for the dialog. The Dialog model defies the avigatioal structure of the UI. It is a more specific model ad ca be derived i good measure from the more abstract Task, User, ad Domai models. A dialog model is used to describe the huma-computer coversatio. It specifies whe the ed-user ca ivoke commads, fuctios, ad iteractio media, whe the ed-user ca select or specify iputs, ad whe the computer ca query the ed-user ad preset iformatio [26]. I other words, the Dialog model describes the sequecig of iput tokes, output tokes, ad the way i which they are iterleaved. It describes the sytactical structure of huma-computer iteractio. The iput ad output tokes are lexical elemets. Therefore, i particular, this model specifies the user commads, iteractio techiques, iterface resposes, ad commad sequeces permitted by the iterface durig user sessios. Two other models, Presetatio ad Layout, have the Domai, Task, ad Dialog models as iputs. Figure 7 depicts the various dialog view iteractios of the evirometal maagemet system s suggested dialog graph structure for the laptop ad PDA platforms. Figure 7: Dialog Graph of the evirometal maagemet system for the laptop ad PDA platforms

21 Presetatio Model The Presetatio Model describes the visual appearace of the UI [3]. This model exists at two levels of abstractio: the abstract ad the cocrete. I fact, they defie the appearace ad the form of presetatio of the system o the iteractive system providig solutios as to how the cotets or related services ca be visually orgaized ito workig surfaces, the effective layout of multiple iformatio spaces, ad the relatioship betwee them. Moreover, they defie the physical ad logical layout suitable for specific iteractive systems such as home pages, lists, ad tables. A Presetatio model describes the costructs that ca appear o a ed-user s display, their layout characteristics, ad the visual depedecies amog them. The displays of most systems cosist of a static part ad a dyamic part. The static part icludes the presetatio of the stadard widgets like buttos, meus, ad list boxes. Typically, the static part remais fixed durig the rutime of the iteractive system, except for state chages like eable/disable, visible/ivisible. The dyamic part displays system-depedet data, which typically chage durig rutime (e.g. the system geerates output iformatio, while the ed-user costructs system-specific data). The former provides a abstract view of a geeric iterface, which represets correspodig Task ad Dialog models. Aother model, Layout, has the Domai, Task, Dialog, ad Presetatio models as iputs. Figure 23 portrays the presetatio model. Layout Model A Layout model costitutes a cocrete istace of a iterface. It cosists of a series of UI compoets which defies the visual layout of a UI ad the detailed dialogs for a specific platform ad cotext of use. There may be may cocrete istaces of a Layout model which ca be derived from Presetatio ad Dialog models. This model makes it possible to provide coceptual models ad architectures for orgaizig the uderlyig cotet across multiple pages, servers, databases, ad computers. It is cocered with the look ad feel of iteractive systems ad with the costructio of a geeral drawig area (e.g. a cavas widget), ad all the outputs iside a cavas must be programmed usig a geeral-purpose programmig laguage ad a low-level graphical library. Figure 23 portrays the layout model Trasformatio Rules Model trasformatio is the process of covertig oe or more models called source models to a output model the target model of the same system. Trasformatios may combie elemets of differet source models i order to build a target model. Trasformatio rules apply to all the types of models listed above. The followig steps make up the list of trasformatio rules suggested i [7], ad are cosidered as part of our framework:. Maitai trackig structures of all class istaces where eeded 2. Maitai trackig structures for Associatio populatios where eeded 3. Support state-machie sematics 4. Eforce Evet orderig 5. Preserve Actio atomicity

22 6. Provide a mappig for all aalysis elemets, icludig: Domai, Domai Service Class, Attribute, Associatio, Iheritace, Associative Class, Class Service State, Evet, Trasitio, Superstate, Substate All Actio-modelig elemets The trasformatios betwee models [8] provide a path which eables the automated implemetatio of a system to be derived from the various models defied for it.

23 4. POMA Architecture 4. Overview of POMA The proposed architecture cosists of six architectural levels of models usig patters (Figure 8) ad UML specificatios of system architecture for iteractive systems developmet called POMA (Patter-Orieted ad Model-Drive Architecture). POMA eables us to specify ad build iteractive systems. It is a architecture which supports both ovices ad experts i system developmet. The architecture of system developmet (Figure 8) icludes: A library of patters by category used i the architecture with their selectio, compositio, ad mappig; The various models that we propose for the developmet of iteractive systems with their trasformatio (PIM to PIM, ad PSM to PSM) ad their mappigs which are: PIM to PSM. POMA is based o: Six architectural levels ad categories of patters; Te models, five of which are [POMA.PIM] ad five others which are [POMA.PSM]; Four types of relatios used i POMA architecture, which are:. Compositio: used to combie differet patters to produce a [POMA.PIM] by applyig the compositio rules 2. Mappig: used to build a [POMA.PIM] which becomes a [POMA.PSM] by applyig the mappig rules 3. Trasformatio: used to establish the relatioship betwee two models (PIM or PSM) by applyig the trasformatio rules 4. Geeratio: is used to geerate the source code of the whole system by applyig the geeratio code rules The directio i which to read the POMA architecture i Figure 8 is as follows: Vertically, it is about the compositio of the patters to produce te PIM ad PSM models. Horizotally, it is about the compositio ad mappig of the patters to produce five PIM ad five PSM models, ad the geeratio of the source code of the whole system (ot icluded i this research).

24 Figure 8: POMA architecture for iteractive systems developmet

25 5. Illustrative case study This sectio presets a case study which describes the desig of a o-fuctioal UI prototype of a simplified evirometal maagemet system (Figure 23), illustratig ad clarifyig the core ideas of our approach ad its practical relevace. It ca also be used by a object-orieted desiger to lear how to use desig patters. This evirometal maagemet system allows the aalysis of the eviromet, its evolutio ad its ecoomic ad social dimesios, ad proposes some idicators of performace. The mai objectives of evirometal maagemet are the treatmet ad distributio of water, improvig air quality, moitorig oise, the treatmet of waste, moitorig the health of faua ad flora, moitorig lad use, preservig coastal ad marie eviromets, ad maagig atural ad techological risks (Figure 23). Note that oly a simplified versio of the evirometal maagemet system will be developed here. The system ad correspodig models will ot be tailored to differet platform or user roles. The mai purpose of the example is to show that models cosist of a series of model trasformatios, i which mappigs from abstract to cocrete models must be specified. I additio, it illustrates how patters are used to establish the various models, as well as to trasform oe model ito aother while respectig the patters compositio rules described above ad the patters mappig rules. We preset below a geeral overview of the PIM ad PSM models of the evirometal maagemet system i applyig the patter compositio steps ad mappig rules, as well as the trasformatio rules for these five models. The details of this illustrative case study are preseted i the Appedix, i which the followig five models represetig the same system are illustrated o a laptop platform ad o a PDA platform: Domai model, Task model, Dialog model, Presetatio model, ad Layout model of the POMA architecture. Table 2 lists the patters that will be used by the system. Patter Name Model Type Problem Logi Domai The user s idetity eeds to be autheticated i order to be allowed access to protected data ad/or to perform authorized operatios. Multi-Value Iput Form Domai The user eeds to eter a umber of related values. These values ca be of differet data types, such as date, strig, or real. Submit Domai The user eeds to submit coordiates to the autheticatio process to access the system. Feedback Domai The user eeds help cocerig the use of the Logi Form. Close Domai The eed to close the system from the Logi form Fid (Search, Browse, Executive Summary) Task The eed to fid idicators related to the task cocered, to fid evirometal patters related to the idicators, ad to fid a presetatio tool to display the results of the idicators ad the evirometal patters Path (Breadcrumb) Task The eed to costruct ad display the path that combies the data source, task, ad/or subtask Idex Browsig Task The eed to display all idicators listed as idex

26 browsig to avigate ad select the desired oes Adapter Task The eed to covert the iterface of a class ito aother iterface that cliets expect; a adapter lets classes work together which could ot otherwise do so because of iterface icompatibility Builder Task The eed to separate the costructio of a complex object from its represetatio, so that the same costructio process ca create differet represetatios List Task The eed to display the iformatio usig forms Table Task The eed to display the iformatio i tables Map Task The eed to display the iformatio i geographic maps Graph Task The eed to display the iformatio i graphs Home Page Task The eed to defie the layout of a iteractive system home page, which is importat because the home page is the iteractive system iterface with the world ad the startig poit for most user visits Wizard (Welie, 2004) Dialog The user wats to achieve a sigle goal, but several decisios ad actios eed to be take cosecutively before the goal ca be achieved. Recursive Activatio (Paterò, 2000) Dialog The user wats to activate ad maipulate several istaces of a dialog view. Uambiguous Format Presetatio The user eeds to eter data, but may be ufamiliar with the structure of the iformatio ad/or its sytax. Form Presetatio The user must provide structural textual iformatio to the system. The data to be provided are logically related. House Style (Tidwell, 2004) Layout Usually, the system cosists of several pages/widows. The user should have the impressio that it all hags together ad looks like oe etity. Table 2: Patter Summary To visualize the models, we have used a exteded versio of the CocurTaskTree (CTT) otatio. I additio to the predefied types, we have ehaced the CTT by addig a fifth type: The Patter Task. Figure 9 shows the graphical represetatio of the patter. Figure 9: Patter symbol

27 The [POMA.PIM]-idepedet model of the evirometal maagemet system is obtaied by composig patters betwee them ad by takig ito accout the patters compositio rules see Figure 20. <<Features>> Logi Coordiates ShowLogiPrompt() Neighborig <<Features>> Close CloseForm() Super-Ordiate / Neighborig Navigatio 0 0 Super-Ordiate Iput Fields Coordiates <<Features>> Multi-ValueIput UserName : Character Set Chai : Character Set PassWord : Character Set ShowForm() IputValues() Super-Ordiate <<Features>> Submit SubmitActio() Neighborig Neighborig Neighborig Neighborig / Compititor/ Similar Neighborig / Super-Ordiate <<Features>> Feedback GetFeedback() Autheticate Fields Coordiates UserList Userame : Character Set Chai : Character Set Password : Character Set VerifyCoordiates() 0 Iteractio Path Patter IdexBrowsig Patter Fid Patters Search Patter Browse Patter Executive Summary Patter Neighborig Neighborig / Super-Ordiate Iteroperability Neighborig / Super-Ordiate / Sub-Ordiate Presetatio Adapter Patter Builder Patter Neighborig List Patter Table Patter Map Patter Graph Patter HomePage Patter <<Dialog>> Wizard Set of Dialog Views Neigborig <<Dialog>> Recursive Activatio Source Dialog View Creator Tasks Target Dialog Views Neigborig Iput Fields <<Presetatio>> Form Neigborig <<Presetatio>> Uambiguous Format Datatype := Datatype(Iput Field) <<Layout>> House Style Choose colors, fots Figure 20: UML diagram of the PIM Model of the evirometal maagemet system

28 The mappig rules of the patters of the evirometal maagemet system for laptop ad PDA platforms are listed i Table 3. HCI patters of the Microsoft platform Type of mappig Replacemet patters for the laptop platform Replacemet patters for the PDA platform P. Logi Idetical P. Logi P. Logi P2. Multi-value Idetical, Scalable, P2. Multi-value Iput P2. Multi-value Iput Iput Fudametal P3. Submit Scalable or fudametal P3. Submit P3.s. Submit (smaller butto) P4. Feedback Idetical, Fudametal P4. Feedback P4. Feedback P4.. Previous P4.2. Next P5. Close Idetical P5. Close P4. Close P6. Fid (Search, Browse, Executive Summary) P7. Path (Breadcrumb) Idetical, Scalable Idetical, Scalable (Laptop) -Scalable or fudametal (PDA) P6. Fid (Search, Browse, Executive Summary P6. Fid (Search, Browse, Executive Summary) P7. Path (Breadcrumb) - P7.s. Shorter Breadcrumb Trial - P7.2. Drop-dow History meu P8. Idex Browsig Idetical P8. Idex Browsig P8. Drop-dow meu P9. Adapter Idetical P9. Adapter P9. Adapter P0. Builder Idetical P0. Builder P0. Builder P. List Idetical P. List P. List P2. Table Idetical P2. Table P2. Table P3. Map Idetical P3. Map P3. Map P4. Graph Idetical P4. Graph P4. Graph P5. Home Page Idetical P5. Home Page P5. Home Page P6. Wizard Idetical P6. Wizard P6. Wizard P7. Recursive Activatio Idetical P7. Recursive Activatio P7. Recursive Activatio P8. Uambiguous Format Idetical P8. Uambiguous Format P8. Uambiguous Format P9. Form Idetical P9. Form P9. Form P20. House Style Idetical P20. House Style P20. House Style Table 3: Example of patter mappig of the of the evirometal maagemet system model for laptop ad PDA platforms

29 After the mappig, we obtai the PSM Model of the evirometal maagemet system for the laptop platform see Figure 2 for the UML diagram of the PSM evirometal maagemet system model for the laptop platform. <<Features>> Logi ShowLogiPrompt() <<Features>> Close CloseForm() <<Features>> Multi-ValueIput UserName : Character Set Chai : Character Set PassWord : Character Set ShowForm() IputValues() <<Features>> Feedback GetFeedback() Navigatio 0 0 <<Features>> Submit SubmitActio() UserList Userame : Character Set Chai : Character Set Password : Character Set VerifyCoordiates() 0 Iteractio Path Patter IdexBrowsig Patter Fid Patters Search Patter Browse Patter Executive Summary Patter Iteroperability Presetatio Adapter Patter Builder Patter List Patter Table Patter Map Patter Graph Patter HomePage Patter <<Dialog>> Wizard <<Dialog>> Recursive Activatio <<Presetatio>> Form <<Presetatio>> Uambiguous Format <<Layout>> House Style Figure 2: UML diagram of the PSM evirometal maagemet system model for the laptop platform

30 After the mappig, we obtai the PSM evirometal maagemet system model for the PDA platform see the UML diagram of the PSM evirometal maagemet system model for the PDA platform i Figure 22. <<Features>> Logi ShowLogiPrompt() <<Features>> Close CloseForm() <<Features>> Multi-ValueIput UserName : Character Set Chai : Character Set PassWord : Character Set ShowForm() IputValues() <<Features>> Feedback GetFeedback() Previous Next Navigatio 0 0 <<Features>> Submit SubmitActio() UserList Userame : Character Set Chai : Character Set Password : Character Set VerifyCoordiates() 0 Iteractio Path Patter IdexBrowsig Patter Fid Patters Search Patter Browse Patter Executive Summary Patter Iteroperability Presetatio Adapter Patter Builder Patter List Patter Table Patter Map Patter Graph Patter HomePage Patter <<Dialog>> Wizard <<Dialog>> Recursive Activatio <<Presetatio>> Form <<Presetatio>> Uambiguous Format <<Layout>> House Style Figure 22: UML diagram of the PSM evirometal maagemet system model for the PDA platform

31 A fial UI of the evirometal maagemet system is show i Figure 23. Figure 23: Screeshot of the evirometal maagemet system for the laptop platform 6. Coclusio I this paper, our discussio focused o a architectural model combiig two key approaches: model-drive ad patter-orieted. We first describe a architectural level ad categories of patters (Navigatio patters, Iteractio patters, Visualizatio patters, Presetatio patters, Iteroperability patters, ad Iformatio patters), as well as the various relatioships betwee patters. These relatioships are used to combie ad map several types of patters to create a patter-orieted desig for iteractive systems, as well as to show how to geerate specific implemetatios suitable for differet platforms from the same patter-orieted desig. The, we proposed five categories of models (Domai model, Task model, Dialog model, Presetatio model, ad Layout model) to address some of the challegig problems, such as: (a) decouplig the various aspects of iteractive systems, such as busiess logic, UI, avigatio, ad iformatio architecture; ad (b) isolatig platformspecific problems from the cocers commo to all iteractive systems. Fially, we preseted a case study to illustrate ad clarify the core ideas of our approach ad its practical relevace. The Model-View-Cotroller (MVC), Model-View-Preseter (MVP), Presetatio-Abstractio- Cotrol (PAC), Seeheim, Arch/Sliky, PAC-Amadeus, ad POMA architectures are similar i may ways, but each has evolved to address a slightly differet cocer. By becomig familiar