A UML-Based Design Environment for Interactive Applications

PauloPinheirodaSilvaandNormanW.PatonDepartmentofComputerScience,UniversityofManchester

OxfordRoad,ManchesterM139PL,England,UK.

e-mail:{pinheirp,norm}@cs.man.ac.ukAbstract

TheUnifiedModelingLanguage(UML)canbeusedformodellingboththestructureandbehaviourofsoft-wareapplications.However,althoughUMLsupportsmanydifferentmodellingnotations,minimalsupportisprovidedforuserinterface(UI)design.TheUni-fiedModelingLanguageforInteractiveApplications(UMLi)isanextensionofUMLthatprovidessup-portforUIdesign.UMLihasauserinterfacedia-gramformodellingabstractUIpresentationsandanextendedactivitydiagramthatprovidesconstructorsformodellingcommonUIbehaviours.ThispaperpresentsthesupportprovidedforUIdesignbytheUMLidesignenvironment.DesignerscanusetheenvironmenttomodelapplicationsandtheirUIsusingUMLanditsextensionsinUMLi.Thetoolprovidesfacilitiesformodellinginteractionobjects,andthecollaborationoftheseinteractionobjectswithdomainobjects.

1Introduction

UML[4]hasquicklybecomeestablishedastheprin-cipalobjectmodellinglanguage,andasanofficialstan-dard,benefitsfromtheendorsementoftheOMG[15].However,althoughUMLcanbeseenasquiteacom-prehensivemodellinglanguage,withmanyinterrelateddiagramsfordescribingthestructureandbehaviourofanapplicationatdifferentlevelsofabstraction,verylittleattentionhasbeenpaidtotheneedsofuserin-terfacedesignersinUML.Asaresult,attemptstode-velopuserinterfacesinUMLtendtocomeupagainstmodellingchallengesthatareabarriertothenaturalexpressionofinterfacefeatures[12,7,17].

Theneedforeffective,abstractmodellingfacilitiesforuserinterfaceshaslongbeenrecognised[14,3],andaresearchcommunityhasbeenworkingonuserinterfacemanagementsystems[11]andmodel-based

userinterfacedevelopmentenvironments(MB-UIDEs)[21,6]forover10years.However,althoughthisre-searchactivityhasidentifiedeffectivetechniquesformodellingtasksanddialogue,interfacedesignmeth-odshavegenerallybeenpoorlyintegratedwithotheraspectsofapplicationdesign,andtherearefewwidelyacceptedmodelsornotations.

TheaimoftheUMLiprojectistoinvestigatetech-niquesforeasingthedesignofuserinterfacesinUML.AcasestudyintheuseofstandardUMLformod-ellinguserinterfaceapplications[7]revealedvariousproblemsdescribinguserinterfacefunctionalitiesusingtheexistingfacilitiesofUML.ThishasgivenrisetothedesignofsomeminimalextensionstoUML,col-lectivelyknownasUMLi,thatarespecificallytargetedattheneedsofuserinterfacemodellers[8].Theem-phasisinUMLiisonsupportingthedevelopmentofform-basedinteractiveinterfacestoapplicationsmod-elledusingtheexistingfacilitiesofUML.Indeed,mostdataintensiveinteractivesystemsarebasedonforms,e.g.,databaseapplicationsandwebapplications[25].However,fullyasimportantastheidentificationofappropriatemodellingfacilitiesisthedevelopmentofeffectiveenvironmentsinwhichtodevelopthemod-els.SeveraltoolshavebeendevelopedforcreatingandmanagingUMLmodels(e.g.,[19,20,23]),andMB-UIDEsarethemselvesoftenassociatedwithinterac-tivemodeldevelopmenttools(e.g.,[1,2,13,18,22]).ThefocusofthispaperisonthedevelopmentofamodellingenvironmentforUMLi.AsUMLiisanex-tensionofUML,mostapplicationdevelopmentwithinUMLiusestheexistingfacilitiesofUML.Assuch,itseemsnaturaltodevelopatoolforUMLiasanexten-sionofanexistingdevelopmentenvironmentforUML,andinfacttheUMLienvironmentisanextensionofARGO[20].

ThispaperdemonstratesthataUMLi-basedtoolcanprovideadesignenvironment:

•whereuserinterfacesandtheirmainstreamappli-cationscanbemodelledinanintegratedway;•thatfacilitatesthedesignofactivitydiagramsthataresimultaneouslysupportedbyinteractionanddomainobjects.

Therefore,theimplementationofthefeaturesofUMLiinatoolcananticipateinthedesigntheneedtospecifyverypreciselytherelationshipbetweeninterac-tionanddomainobjects.Intheabsenceofsuchsup-port,thisintegrationisoftenacostlytaskperformedintheimplementation.

Thispaperhasthefollowingstructure.AnoverviewofUMLiisprovidedinSection2.GenericaspectsoftheUMLitoolarepresentedinSection3.Toolsup-portforthemodellingofUIpresentationsisdescribedinSection4.Toolsupportformodellinginteractiveap-plicationcontrol-flowanddata-flowusingactivitydia-gramsispresentedinSections5and6.ToolsupportformodellingthecollaborationbetweeninteractionanddomainobjectsispresentedinSection7.ConclusionsarepresentedinSection8.Throughoutthepaper,somefamiliaritywithUMLnotationandterminologyisassumed.

2UMLiOverview

ThefeaturesofUMLiareillustratedinthispaperthroughthedescriptionofthemodelsusedforspecify-ingtheConnectUIuserinterfacepresentedinFigure1.Thisuserinterfaceiswheresystemusersprovidetheirloginnameandpasswordtogainaccesstosystem’sser-vices.Thisisarudimentaryexample,butitsufficestoillustratestheUMLimodellingenvironment.AmoresubstantialUMLimodelispresentedin[8].

AUMLimodeldescribingstructuralaspectsofConnectUIispresentedinSection2.1,andaUMLimodeldescribingdynamicaspectsofConnectUIisgiveninSection2.2.FurtherdetailsoftheUMLicanbeobtainedin[8]andintheUMLihome-pageathttp://img.cs.man.ac.uk/umli,fromwhichthemodellingenvironmentdescribedinthispapercanbedownloaded.

2.1ModellingUserInterfacePresentations

UMLprovidesclassandobjectdiagramsformod-ellingstructuralaspectsofsoftware.TheuseofthesediagramsforUIdesignpresentssomedifficulties.Forinstance,theidentificationofinteractionobjectrolesandcontainmentsmaynotbeeasyinobjectdia-grams[7].

Figure1.TheConnectUIuserinterfaceofalibrarysystem.

TheuserinterfacediagraminFigure2isanabstractpresentationmodeloftheConnectUI.TheUIdiagramconstructorsarespecialisedUMLclassescalledInter-actionObjects.Thus,aUIdiagramisaspecialisationofaclassdiagram.TheUIdiagraminFigure2providesexamplesofmostoftheInteractionObjectsspecifiedinUMLi.AnInputter,∇,isresponsibleforreceivinginformationfromusers.ADisplayer,󰀅,isresponsi-bleforsendingvisualinformationtousers.AnEdi-tor,󰀈,issimultaneouslyanInputterandaDisplayer.AnActionInvoker,

,isanInteractionObjectthatcancontainsotherIn-teractionObjects.AFreeContainer,

Figure3.AnextendedactivitydiagramdescribingbehaviouralaspectsoftheConnectUI.

loginTextandpasswordTextplaythesameabstractroleasInputters.

2.2ModellingUserInterfaceBehaviours

TheactivitydiagraminFigure3isadescriptionofthebehaviouroftheConnectUI.Broadlyspeaking,activitiesdescribetheactionsthatcanbeperformedusingtheUI.Thetransitionsdescribethepossiblewaysofexecutingactivities.Further,objectflowsspecifyhowobjectsareusedbyactionsinactivities.

UMLiprovidesstereotypedinteractionobjectflowstodescribebehavioursthatareoftenperformedinUIs.Forexample,the󰀊presents󰀋interactionob-jectflowinFigure3specifiesthattheConnectUIFreeContaineranditscontainedinteractionobjectsarepresentedwhentheConnectactivityisenabled,andthattheyarehiddenwhentheConnectactiv-ityisdisabled.Further,the󰀊interacts󰀋interac-tionobjectflowinFigure3specifiesthatuserscaninteractwiththepasswordTextInputterwhentheUserQuery.setPassword(getValue())ActionStateisenabled.UMLispecifiesthreeotherstereotypesforin-teractionobjectflowsinadditiontothe󰀊presents󰀋and󰀊interacts󰀋stereotypes:the󰀊cancels󰀋stereo-typeforcancellingtheexecutionofanactivity,the󰀊confirms󰀋stereotypeforconfirmingtheendofop-tionaldecisions,andthe󰀊activates󰀋stereotypefortriggeringtheexecutionofActionStates.

TheintroductionofSelectionStatesisanothercon-tributionofUMLiformodellingUIs.Forinstance,theOrderIndependentState,⊕,inFigure3specifiesthatitstwoselectablestates,inthiscase,thetwoAction-StatesconnectedtotheOrderIndependentStatebyRe-turnTransitions,

,mustbeexecutedonceeach,butmaybecarriedoutinanyorder.UMLispecifiestwoothercategoriesofSelectionStatenotusedinFigure3:

OptionalStateandRepeatableState.

Activitydiagramswithoutobjectflowscanbecon-sideredascontrol-flowmodels.Indeed,adescriptionofthepossibletransitionsbetweenactivitiesmodelstheapplicationworkflow.Activitydiagramswithobjectflowsalsomodelcollaborationsbetweenobjects.Inthiscase,theseactivitydiagramscanbeconsideredasdata-flowmodels.Thedistinctionbetweencontrol-flowanddata-flowmodelsisnotnormallyrelevant,sincebothofthemaretypicallyrequiredduringaUIde-sign.However,thedistinctionisemphasisedherebe-causetheUMLitoolhasdistinctfacilitiesformodellingcontrol-flowanddata-flow.ThefacilitiesofUMLiforcontrol-flowmodellingarediscussedinSection5,andthosefordata-flowmodellingarediscussedinSection6.

3ImplementingtheUMLiTool

Therearemanycomputer-aidedsoftwareengineer-ing(CASE)toolsforUML,e.g.RationalRose[19],Together[23]andARGO[20].ThissectionexplainshowthefeaturesofUMLihavebeenimplementedinARGO[20].

3.1ARGOOverview

TherearetwocharacteristicsofARGOthathaveguidedourdecisiontobuildonthisspecificUMLtool:•ARGOisopensourcesoftware.Thus,wemayhavethechancetoimplementthefeaturesofUMLiwithoutrelyingonthesometimeslimitedextensionmechanismsoccasionallyprovidedbyotherUML-basedtools.

•TheARGOobjectmodelusedforhandlingUMLmodelsatruntimeconformswiththeOMGUML1.3specification[15].

Figure4.AsnapshotoftheARGOuserinterface.

TheARGOuserinterfaceisshowninFigure4,wheretherearefourdistinctpanels:

•Editingpanel.ThispanelislocatedatthetoprightofFigure4,andiswhereUMLidiagramsareconstructed.Thispaneliscomposedoftheworkingareaandtheselectionbox.Theselectionboxisusedforselectingaconstructorcreatororanoperator.Constructorcreatorsareusedforaddingnewcomponentstotheworkingarea.Operatorsareusedformodifyingconstructorsalreadycre-atedintheworkingarea.Thecontentsofthese-lectionbox,intermsofconstructorcreatorsandoperators,dependsonthekindofdiagramthatisbeingedited.Forinstance,theselectionboxinFigure4containstheconstructorcreatorsforUIdiagrams,sincethisisthekindofdiagrambeingedited.

•Navigationpanel.ThispanelislocatedatthetopleftofFigure4.FromthispaneldesignerscannavigatethroughtheentireUMLmodel,switchingfromonediagramordiagramelementtoanother.

Forinstance,byselectinganewdiagraminthenavigationpaneladesignercansettheselecteddiagramasthecurrentoneintheeditingpanel.•Detailpanel.ThispanelislocatedatthebottomrightofFigure4.Inthispaneldesignerscaninter-actwithelementsoftheUMLmodelandARGOenvironmentthatmaynotberepresentedgraphi-callyintheeditingpanel.Differentkindsofinfor-mationcanbespecifiedinthispanel.Adifferentformisprovidedforeachkindofinformationthatcanbespecified.Theseformsareselectedusingthedetailpaneltabs,i.e.ToDoItem,PropertiesandStyle,asshowninFigure4.InthecaseofUMLi,weareparticularlyinterestedintheproper-tiesform,wheredesignerscanprovideadditionalinformationforUMLiconstructors.Thecontentofthepropertiesformisbasedontheselectedcom-ponentofthecurrentdiagram,ifany.Forexam-ple,thepropertiesforminFigure4showsdetailsabouttheselectedloginTextInputter.Ifnocom-ponentisselected,thepropertypaneldisplaysthepropertyofthecurrentdiagram.

•ToDopanel.ThispanelislocatedatthebottomleftofFigure4.DesigncriticsprovidedbyARGOarepresentedinthispanel.ThisisapossibleplaceforimplementingsomeconstraintsspecifiedintheUMLimodel.Indeed,ratherthanenforcingtheconstructionofconsistentUMLmodelsfromthebeginning,ARGOprovidesnon-compulsorycriti-cismfacilitiesthatmayprovideguidanceforbuild-ingconsistentmodelsinanincrementalway.TheversionofARGOthatimplementstheUMLiex-tensions,v.0.8.1,doesnotmakeuseoftheARGOcriticismfacilities.

FromthisdescriptionoftheARGOuserinterfacewecanseethatUMLimodelsarebuiltintheeditingpanel.Moreover,detailedinformationconcerningthemodelsisnormallyprovidedinthepropertyform.Therefore,UMLifeaturesaremainlybasedonextendedfunction-alitiesimplementedintheeditingpanelandpropertyform.

3.2ImplementingARGOi

TheversionofARGOthatprovidestheUMLifacil-itiesiscalledARGOi.Ahigh-leveldescriptionoftheARGOarchitectureisrequiredtoexplaintheimple-mentationofARGOi.ThecomponentsofARGOarepresentedinFigure5.There,thepackagesarecom-posedofJava/Swingclassesthatmayhavetheirownsub-packages.ThesepackageshavethefollowingrolesinARGO.

Figure5.Atop-levelpackageviewoftheARGOarchitecture.

•TheGraphEditingFramework(GEF)packageprovidesagenericsetofgraphicalconstructorsforimplementingdiagrams,nodesandedges.•TheNovosoftUML(NSUML)packageimplementstheUMLobjectmodel.Additionally,thepackage

providesthefacilityofsavingandloadingUMLobjectmodelsintheOMGXMLmetadatainter-change(XMI)format[15].

•AnXMLparserpackageisusedbyNSUMLclassesforloadingobjectmodelsfromXMIfiles.•TheARGOpackageiscomposedofextendGEFclasses.TheseARGOclassesprovideeditablegraphicalrepresentationsfortheNSUMLobjects.Moreover,theyarethegraphicalelementsusedintheeditingpanel.

TheUMLiimplementationhasextendedclassesintheARGOandtheNSUMLpackagesdescribedabove.TheARGOpackagehasbeenextendedtoprovidethefollowingfacilitiesformodellingUMLidiagrams.•Editingfacilitiesforuserinterfacediagrams,asdiscussedinSection4;

•Editingfacilitiesinactivitydiagramsformodellingselectionstates,initialinteractionstatesandinter-actionobjectflows,asinSections5and6;•Wizardsinactivitydiagramsfordesigningcontrol-flow,asdiscussedinSection5;

•Wizardsinactivitydiagramsformodellinginter-actionobjectflows,asdiscussedinSection6.TheNSUMLpackagehasbeenextendedtosupporttheUMLimetamodel[5].TheNSUMLpackagehasalsobeenextendedtosupportthegenerationandread-ingofUMLiXMIdocumenttypedefinition(DTD)conformantfiles[15].Thispartoftheimplementa-tionbenefitssignificantlyfromtheprincipleadoptedinUMLiofextending,butnotmodifying,theUMLspecification.EveryXMLfilethatconformswiththeUMLXMIDTDalsoconformswiththeUMLiXMIDTD.

Atthispoint,wecanrecallthatoneofthedifficultiesofusingexistingMB-UIDEsisthateachdevelopmentenvironmentusesadifferentsetofnotationsformod-ellingUIs[6].ThismeansthatUImodelsbuiltbyoneMB-UIDEcannotbeusedbyanotheroneduetotheintrinsicdifficultyoftranslatingmodelsbuiltoverdif-ferentnotations.Forinstance,MASTERMIND[22],JANUS[1],Teallach[2]andMOBI-D[18]cannotin-terchangetheirmodels,evenpartially.WiththeuseofXMIfiles,UML-basedtoolscaninterchangemodels.ItisevenexpectedthatUML-basedtoolscaneventuallysharemodelsinacollaborativeanddistributeddevel-opmentenvironment.IntermsofUMLi,thismodelinterchangeabilitymeansthatUMLi-basedtoolscanuse,withoutanytranslation,partialUMLmodelsof

interactiveapplications,evenwhenthesehavebeende-velopedusinganotherenvironment.

4PresentationModellingSupport

AsnapshotoftheARGOiuserinterfacewhenmod-ellingaUIdiagramispresentedinFigure4,whichshowsthemodellingoftheConnectUIdiagramfromFigure2.TheimplementationtechniquesusedinthisUMLi-specificdiagramarethesameasforotherUMLdiagrams.Forinstance,thesametechniqueisusedforimplementinginteractionobjectcontainmentinUIdi-agramsandstatecontainmentinstatechartdiagrams.Inthissection,wepresentthespecificsofUIdiagrameditors,ratherthangenericimplementationdetailsofARGO.

ThedecisionaboutthecontentofeachdiagramisoneofthefirstproblemsfacingtheimplementorofaUIdiagrameditor.Infact,thediagramconceptisnotex-plicitlyspecifiedinUML.Forinstance,theclassesofanapplicationcanbemodelledinasingleclassdiagramorinseveralclassdiagrams.InARGOi,aUIdiagramhasexactlyoneFreeContainer.Indeed,aFreeContainerisautomaticallycreatedwhenitsUIdiagramiscreated,andaUIdiagramisdeletedwhenitsFreeContainerisdeleted.Forthisreason,thereisnoFreeContainercreatorintheselectionboxoftheUIdiagrameditor,aswecanseeinFigure4.

ThedecisionthataUIdiagramshouldcontainex-actlyoneFreeContainermayfacilitatetheselectionofaFreeContainerinlarge-scalemodels.Indeed,navigationpanelsinUML-toolsareusuallyorganisedarounddiagrams.Thus,FreeContainerscanbese-lectedthroughtheselectionoftheirUIdiagramsinnavigationpanels.Otherwise,asearchfacilitywouldberequiredtolocatetheUIdiagramofaspecificFreeContainer.

InteractionobjectsthatarenotFreeContainersareaddedtoaUIdiagramusingoneoftheconstructorcreatorsintheselectionbox.Interactionobjectcon-tainmentisinitiallyspecifiedbythepositionofthecur-sorontheworkingareaoftheeditingpanelwhenthepointer-devicebuttonispressed.Thus,interactionob-jectsareaddedintotheinnermostContainerrelatedtotheselectedposition.Designerscanmodifyinter-actionobjectcontainmentbydragginganddroppinginteractionobjects.

Interactionobjectplacement(incontrastwithcon-tainment)isnotrelevantinUIdiagrams,sincelayoutisnormallymoreaconcretepresentationconcernthananabstractpresentationone[6].Therefore,theUIdi-agramsneedtoberefinedintoconcretepresentations.Thegenerationofconcretepresentationsfromanab-

stractpresentationmodelispartiallydescribedin[7].Theproblemofhowbesttomapabstractinteractionobjectsontoconcreteinteractionobjects,however,isstillaresearchproblem[24].

5Control-flowModellingSupport

Activitydiagramelementscanbeaddedtodiagramsusingtheselectionbox.Alternatively,activitydiagramelementscanbeaddedusingthetemporal-relationwiz-ardpresentedinthissection.

ThiswizardisbasedontaskmodeltechniquesthatexploitextensionstoUMLactivitydiagramsformod-ellingcontrol-flow.Infact,taskmodellingisawellestablishedtechniqueformodellingthebehaviourofinteractiveapplications[10,16].Designerscanbuildataskhierarchythatmodelsthecontrol-flowoftheappli-cationbydecomposingtasksintosubtasksandspecify-ingtemporalrelationsbetweenthesubtasks.InUMLi,applicationcontrol-flowcanbemodelledbyactivitydi-agrams.However,activitydiagramstendtobelessabstractthantaskmodels.Inparticular,inter-objecttransitionsinactivitydiagramstendtobemorecom-plextomodelthantemporalrelationsintaskmodels.Infact,thedifficultyofmodellinginter-objecttransi-tionsusingthestatechartconstructorswasanticipatedbyHarelandGery[9]whenstatechartswereadoptedbyUML.Thetemporal-relationwizardinARGOipro-videsatleasttwobenefitsformodellingactivitydia-grams.

1.Itcanreducetheeffortofmodellingcontrol-flowusingUML.Theselectionofoneofthewizard’soptionscreatesacompletesetofconstructorsre-quiredformodellingthebehaviouroftemporalre-lationsinataskmodel.2.ItexploitsthepotentialofSelectionStatesandRe-turnTransitions(asintroducedinSection2.2)formodellingabstractinter-objecttransitions,simpli-fyingthecontrol-flowmodellingprocessinUML-basedtools.Indeed,afacilityformodellingOr-derIndependentStates,OptionalStatesandRepeat-ableStatesmakesthecontrol-flowmodellingpro-cessmoresimilartothetaskmodellingprocessinUI-specificdevelopmentenvironmentssuchasCTTE[16],MOBI-D[18]andTeallach[2].Thetemporal-relationwizardappearseverytimeanodeinanactivitydiagramisselected,suchasforthestateSinFigure6(b).ThewizardistheiconographicmenutotherightofS.WecanseethesamestateSinFigure6(a)beforeitwasselected.TheotherwizardsinFigure6(b)arestandardactivitydiagramwizardsof

ARGO.Thetemporal-relationwizardhassixoptionsthatperformthefollowingactions:

(a)(b)

Figure6.(a)TheunselectedSstate.(b)TheselectedSstatealongwiththeARGOitemporal-relationwizardonitsright.

•Sequentialoption(→):Thisoptionbuildsanac-tivityconnectedtothecurrentnodebyatran-sition.ThisactionisrepresentedgraphicallyinFigure7(a).

•Concurrentoption(󰀆):Thisoptionbuildstwoac-tivities,ajoin,andafork.Atransitionconnectsthecurrentnodetothefork.Eachactivitybuilthastwotransitions:onecomingfromthefork,andonegoingtothejoin.ThisactionisrepresentedgraphicallyinFigure7(b).•Choiceoption(

Figure8.ThemodellingoftheactivitydiagraminFigure3.

that:(1)canhaveaninteractionstereotype;and(2)canbeconnectedtoCompositeStates,SelectionStatesandActionStates.

Themodellingofobjectflowsandinteractionob-jectflowsmaynotbeasimpletask.SelectingaClassi-fier,i.e.,aClass,UseCaseorInteractionObject,toplaythetyperoleinaninteractionobjectflowcanbecom-plexduetothenumberofClassifiersusuallyavailableininteractiveapplicationdesigns.Further,selectingaproperstereotypeforaninteractiveobjectflowmaybecomplexduetotherichsemanticsoftheUMLiinterac-tionstereotypes.Forinstance,the󰀊presents󰀋inter-actionstereotypespecifiesaFreeContainercontext[5].ARGOiprovidesfacilitiestocopewiththecomplex-ityofselectingtypesandstereotypesforinteractionobjectflows.Aprecisedescriptionofthesefacilities,however,isintentionallyavoidedheresinceitrequiresapartialdescriptionoftheUMLimetamodel[5].How-ever,examplesofthesefacilitiescanbeprovidedusingtheactivitydiagraminFigure3.

providedasoptionsinthecomboboxofinteractionobjectflows.Forinstance,Figure8showshowthecomboboxinthepropertiesformcanbeusedtospec-ifythetypeoftheobjectflowthatisbeingaddedtotheConnectActivity.There,theoptionsinthecombobox,e.g.,BookClassandSelectServicesUseCase,areClassifiersalreadyspecifiedinthemodelsofthelibrarysystem.Consideringthistypespecificationap-proach,ARGOicananalysethecurrentstateoftheUMLimodeltofilterthoseClassifiersthatcannotbeatypefortheselectedinteractionobjectflow.Twoex-amplesoftheUMLimodelaspectsanalysedbyARGOiforfilteringClassifiersarethefollowing:

•FreeContainercontext.InFigure3wecanseetheuseoftheConnectUIFreeContainerasa󰀊presents󰀋interactionobjectflowoftheConnectactivity.Thismeansthatonlythefollow-inginteractionobjectsinthemodelscanbemadeavailableforselectionasatypeofinteractionob-jectflowsusedbyactivitieswithintheConnectactivity:

1.ThePrimitiveInteractionObjectscontainedbyConnectUI(seeFigure2);

6.1SelectingTypesforInteractionObjectFlows

ClassifiersspecifiedinthecurrentUMLimodelsare

2.TheFreeContainers.Indeed,thisprovidestheabilitytocreatenewFreeContainercon-texts.•ActionInvokerroles.AninstanceofaPrimitiveIn-teractionObjectshouldnotplaymorethanoneroleinaFreeContainer,e.g.,

Figure9.AnattempttodeletetheConnectUIFreeContainercantriggertheintegrationwizard.

8Conclusions

integrationwizard(Section7).

ComparedwithmostMB-UIDEs,ARGOicanpro-videthefollowingdistinctivebenefits:

•Agraphicalnotationformodellinginter-modelre-lationships,suchasthe󰀊presents󰀋objectflowshowninFigure3,whichexplicitlylinksthepre-sentationmodelofaUIwiththeactivitydiagrammodellingtheUI’sbehaviour.Relationshipsbe-tweencontrol-flowmodels(e.g.,taskmodels,ac-tivitydiagrams)andstructuralmodels(e.g.,classdiagrams,UIdiagrams)aremodelledinanon-graphicalwayinTeallach[2]andMOBI-D[18].•ItallowstheconstructionofdomainmodelsalongwiththeconstructionofUImodels.

ThereareMB-UIDEsthatintegrateaUIdesignenvironmentwithamainstreamCASEtool.Forin-stance,JANUS[1]usesTogether[23]forbuildingitsmodels,andAME[13]usestheOODevelopToolforbuildingitsmodels.However,ARGOimodelscanprovidemorecomprehensivespecificationofUIsthan

ThispapershowsthattheUMLispecificationcanbeeffectivelyimplementedinaUML-baseddesignen-vironment.Moreover,thispapershowsthatARGOi,aUMLi-basedtool,canprovidesupportformodellingacompleteinteractiveapplicationexploitingtheUMLispecification.

ComparedwithotherUMLtools(e.g.,RationalRose[19],Together[23],ARGO[20]),ARGOiprovidesadditionaltoolsupportfor:

•modellingabstractuserinterfacepresentationsus-ingtheUMLiuserinterfacediagram(Section4);•modellingcommonUIbehavioursusingthetemporal-relationwizardthatexploitstheuseoftheUMLiSelectionStates(Section5);

•modellinginanexplicitandeffectivewaythecol-laborationbetweeninteractionanddomainob-jects(Section6);

•preserving,whenmodelled,theintegrationbe-tweeninteractionanddomainobjectsusingthe

AMEandJANUSmodels.Indeed,ARGOiprovidesagenericapproachformodellingandrelatingstruc-turalanddynamicaspectsofinteractiveapplications(Sections5and6).TheAMEandJANUSapproachesformodellingUIsarequitelimitedfordescribingthebehaviouralaspectsofUIs.Indeed,theseapproachesarebasedontheidentificationoftheoperationsthatcanbeexecutedbyeachinteractionobjectratherthanmodellingtheapplicationworkflowinanabstractway.Inthecontextofuserinterfacestodataintensiveapplications,UMLiandARGOiprovidethefollowingbenefits:

•integrationofUIdesignwithdatamodellingthroughclassdiagrams;

•comprehensivesupportforthemodellingofdataflowduringactivities;

•supportforform-basedinterfaces,whicharepre-dominantformostdatabaseinterfaces;

•backwardcompatibilitywithexistingUMLmod-els,inwhichmanydataintensiveapplicationsarealreadydesigned.

UMLihasbeendevelopedaspartofanongoingproject.Thenextactivitiesoftheprojectare:•Themodellingofalarge-scaleinteractiveapplica-tionusingARGOi;

•TheimplementationofaUIsoftwaregeneratorinARGOi.

Acknowledgements.ThefirstauthorissponsoredbyConselhoNacionaldeDesenvolvimentoCient´ıficoeTecnol´ogico-CNPq(Brazil)–Grant200153/98-6.

References

[1]H.Balzert,F.Hofmann,V.Kruschinski,and

C.Niemann.TheJANUSApplicationDevelop-mentEnvironment—GeneratingMorethantheUserInterface.InComputer-AidedDesignofUserInterfaces,pages183–206,Namur,Belgium,1996.NamurUniversityPress.[2]P.Barclay,T.Griffiths,J.McKirdy,N.Pa-ton,R.Cooper,andJ.Kennedy.TheTeallachTool:UsingModelsforFlexibleUserInterfaceDesign.InProceedingsofCADUI’99,pages139–157,Louvain-la-Neuve,Belgium,October1999.Kluwer.

[3]D.Benyon,T.Green,andD.Bental.Conceptual

ModellingforHumanComputerInteractionusingERMIA.Springer,London,UK,1999.[4]G.Booch,J.Rumbaugh,andI.Jacobson.The

UnifiedModelingLanguageUserGuide.Addison-Wesley,Reading,MA,1999.[5]P.PinheirodaSilva.OntheSemanticsofthe

UnifiedModelingLanguageforInteractiveAppli-cations.Inpreparation.[6]P.PinheirodaSilva.UserInterfaceDeclarative

ModelsandDevelopmentEnvironments:ASur-vey.InProceedingsofDSV-IS2000,LNCS,pages207–226,Limerick,Ireland,June2000.Springer-Verlag.[7]P.PinheirodaSilvaandN.Paton.UserIn-terfaceModellingwithUML.InProceedingsofthe10thEuropean-JapaneseConferenceonInfor-mationModellingandKnowledgeRepresentation,Saariselk¨a,Finland,May2000.IOSPress.(Toappear).[8]P.PinheirodaSilvaandN.Paton.UMLi:The

UnifiedModelingLanguageforInteractiveAppli-cations.InProceedingsofUML2000,volume1939ofLNCS,pages117–132,York,UK,October2000.Springer.[9]D.HarelandE.Gery.ExecutableObjectModel-ingwithStatecharts.IEEEComputer,30(7):31–42,1997.P.Johnson.HumanComputerInteraction:Psy-chology,TaskAnalysisandSoftwareEngineering.McGraw-Hill,Maidenhead,UK,1992.A.Kilgour.Theoryandpracticeinuserinterface

managementsystems.InformationandSoftwareTechnology,29:171–175,1987.S.Kovacevic.UMLandUserInterfaceModeling.

InProceedingsofUML’98,pages235–244,Mul-house,France,June1998.ESSAIM.C.M¨artin.SoftwareLifeCycleAutomationfor

InteractiveApplications:TheAMEDesignEnvi-ronment.InComputer-AidedDesignofUserIn-terfaces,pages57–74,Namur,Belgium,1996.Na-murUniversityPress.B.Myers.UserInterfaceSoftwareTools.ACM

Trans.Computer-HumanInteraction,2(1):64–103,March1995.

[10][11][12][13][14][15]ObjectManagementGroup.OMGUnifiedMod-elingLanguageSpecification,June1999.Version1.3.[16]F.Patern`o.Model-BasedDesignandEvaluation

ofInteractiveApplications.Springer,Berlin,1999.[17]F.Patern`o.TowardsaUMLforInteractive

Systems.InProceedingsofEHCI2001,LNCS,Toronto,Canada,May2001.Springer.(Toap-pear).[18]A.Puerta.Amodel-basedinterfacedevelopment

environment.IEEESoftware,August:40–47,1997.[19]T.Quatrani.VisualModelingwithRationalRose

andUML.Addison-Wesley,1998.[20]J.Robbins,D.Hilbert,andD.Redmiles.ARGO:

ADesignEnvironmentforEvolvingSoftwareAr-chitectures.InProceedingsofICSE’97,pages600–601,Boston,MA,May1997.ACMPress.[21]P.Szekely.RetrospectiveandChallenges

forModel-BasedInterfaceDevelopment.InComputer-AidedDesignofUserInterfaces,pagesxxi–xliv,Namur,Belgium,1996.NamurUniver-sityPress.[22]P.Szekely,P.Sukaviriya,P.Castells,J.Muthuku-marasamy,andE.Salcher.DeclarativeInter-faceModelsforUserInterfaceConstructionTools:theMASTERMINDApproach.InEngineeringforHuman-ComputerInteraction,pages120–150,London,UK,1996.Chapman&Hall.[23]TogetherSoft.http://www.togethersoft.com.[24]J.Vanderdonckt.Advice-givingsystemsforselect-inginteractionobjects.InUserInterfacestoDataIntensiveSystems(UIDIS),pages152–157,Edin-burgh,UnitedKingdom,1999.IEEEComputerSociety.[25]M.Zloof.SelectedIngedientsinEnd-UserPro-gramming.InProceedingsoftheWorkingCon-ferenceonAdvanceVisualInterfaces(AVI’98),pages30–35,L’Aquila,Italy,May1998.ACMPress.